Webシステム開発 の流れ

開発 会社に Web システム 開発 を依頼する場合、依頼者側からすると
「自分たちは web システム の素人なので難しい話は分からない」
「 開発会社は web システム 開発 の専門家なのだから任せておけば大丈夫」
と思いたくなるかもしれません。

しかし、開発 途中に依頼者側が気軽に要求した変更が、
開発 期間の長期化や追加料金の発生を招いてしまいかねません。
発注者側が Web システム 開発 のおおまかな流れを理解しておくことで
そのような事態を回避できます。

そこでこの記事では Webシステム の 開発 はどのような流れで進行するのか、
そして、なぜ依頼者側もその流れを知っておくべきなのか解説します。

発注者も Web システム 開発 の流れを知っておくべき理由

Web システム の 開発 フローを知らない状態で 開発 途中に気軽に機能追加を伝えても、
システム 開発 会社でそれに対応するとなると、開発 手法 によっては後戻り工数が発生し、
スケジュールの大幅な遅延と追加開発による追加コストが発生してしまいます。

また、発注者側と 開発 側の認識が食い違っていて、
どちらが正しいのかについての根拠となる書類がない場合、それが原因でトラブルとなり、
結果的に プロジェクト が途中で中断してしまうことにもなりかねません。

そのため、さまざまなトラブルを未然に防ぐためにも、
 Web システム 開発 にはどのような工程があり、
各工程において何をアウトプットするのか、
いつまでにアウトプットするか、
アウトプットのために発注者からどんな情報が必要かなどについて決めていなかった場合、
どのような問題があるかを事前に把握しておく必要があります。

依頼者側もあらかじめWeb システム 開発の流れを理解しておけば、依頼までの準備もしやすく、
システム開発 会社 とのコミュニケーションがスムーズになり、
制作も手戻りが少なく進行できます。

 Web システム の 開発 の流れ

 Web システム 開発 の工程は大きく

「 企画 」「 設計 」「 開発 」「 テスト 」「 検収 」 「 リリース 」

の５つに分類できます。
（運用・保守もありますが、ここでは説明を省略します。）

● 企画

企画 では、必要な機能やユーザーが求める要求をまとめて、
要件定義書を作成します。 Web システム を 開発 する目的やターゲット、
実現方法、予算、人員、期間などを決めて、それを元に後工程を決めていきます。

そのうえで、どういった機能を実装すべきか、
満たすべき性能はどういったものかなど、「何をつくるか」を明確にしていきます。
この段階で業務要件、機能要件のほか、
対応OSや対応ブラウザ、セキュリティ要件などの仕様も決めていきます。

企画 フェーズにおいて重要なことは、発注者側が Web システム 開発 の目的を明確にしておくことです。
十分な検討を行わずに システム開発会社に相談すると、
開発 途中で「いや、ここはこういう動きではない。」「実はこういう機能がほしかったんだけど。。。」
といったことが発生しやすくなります。
自分たちの目的を達成するためにはどういった要件が必要かを依頼者側でも明確にし、
システム 開発 会社側との認識のズレがないように注意しましょう。

●設計

設計 では機能だけでなくデザインについても同様に、
「どの場所にどんな機能を配置するか」
「どのようにページを移動させるか」
「各ページの親子関係はどうするか」
といった情報を要件定義で作成した内容を元にまとめ、
実際の制作物に近いイメージを作り上げます。

企画段階で作成された要件定義書の内容に沿った機能、デザインをドキュメント化します。
画面の見やすさや操作のしやすさなどを考慮し、操作画面のデザインも設計します。

デザイン 設計 はユーザーにとって使いやすいかどうかに関わってくる工程です。
また、 システム 開発 会社が一度に仕上げるというよりも、要件定義書を元にしつつ、
発注側に確認を取りながら制作物の実現方法や内容を固め、設計の完成度を高めていきます。

見た目のデザインという外部設計が決まったら、内部設計を行います。
内部設計ではユーザーの設定に対して Web システム の成果物とその処理手順を設計します。
システム 内部の動作や機能、データ、処理フローなどを開発者目線で設計します。

受注側と発注側でレビュー＆フィードバックを繰り返すことで、
より設計品質が高まっていくので、密なコミュニケーションをとることが重要です。
不安や懸念がある場合は対面、あるいはオンラインで打合せをすることで
後の工程でトラブルや手戻り、検討漏れを回避できます。

●開発

外部設計、内部設計が完了したら、決めた設計に合わせて プログラミング を進めていきます。
設計の段階で詳細を検討されていなかったり、
思い付きで機能追加や機能変更を システム 開発 会社に要求したりすると
設計のやり直しの発生や、ソフトウェアの内部構造の複雑化につながり、
制作期間の長期化やソフト品質の悪化につながります。
したがって少しでも 開発 効率を上げるためにも、設計は詳細に行うこと、
開発 途中の機能変更や追加は最小限にとどめることが重要です。

ただし、この工程までにどれだけ綿密に調査、設計を行ったとしても、
検討漏れ、要求漏れが発覚することは珍しいことではありません。
このとき、 システム開発 会社と
プロジェクト進行の共有や対話ができる環境が構築できていると、
仕様の変更の伝達がスムーズに行えます。

したがって制作フェーズでも システム開発 会社のお任せにしてしまうのではなく、
日ごろからコミュニケーションを欠かさないようにすることが重要です。

●テスト

バックエンド、フロントエンドともに 開発 がひととおり終わったら、
作り上げたプログラムが正しく動作するか、 テスト します。
テスト 環境と呼ばれる疑似本番環境を用意して行うのが一般的です。

個々のプログラムが要件を満たしているか、複数のプログラムでも異常が起こらないか、
 Web システム 全体が正常に動作するかの順にテストします。
最後に運用テストを実施し、Web システム 全体が問題なく動作するかを確認します。

開発した Web システム が実際の環境下で動くかどうか確認するための工程です。
実際の運用で使えるかどうか細かくチェックしていきます。
また、 Web システム が設計通りに動作するか確認することに加え、
当初の依頼の目的を満たしているかの、チェックも必要です。

●検収

システム開発 会社側でのテストを終えたらすぐにリリース、とはなりません。
要件定義で定めたことが満たされているかどうか、
発注者側にて運用 テスト ・ 検収 を行います。

発注者側は、制作されたサービスを見ると、
追加でほしくなった機能や改善のためのアイデアが往々にして出てきます。
そのこと自体は決して悪いことではありません。

しかし、上述の通り仕様が決まってから実装、テストまでには
非常に多くのステップ・工数が発生するため、リリース前に追加開発をしようと思うと、
スケジュールが大幅に後ろ倒しになる上、追加開発のコストが発生してしまいます。
無理して機能追加に対応しようとすると新たな不具合の追加や内部構造が複雑化し、
のちの機能追加が難しくなります。
そのため、要件定義で定められていない仕様に関しては、
基本的にリリース後にあらためて追加開発の要件を整理していく、という考え方が重要です。

●リリース

リリース では、 テスト が完了した成果物を実際の運用環境に移します。
何事もなく リリース されることが理想ではありますが、
さまざまな テスト を重ねて、発注者側も制作会社側も
リリース して問題ないと判断したにも関わらず、
ブラウザのバージョンやキャッシュ問題といったインターネットの特性上、
何かしらのトラブルが発生してしまう可能性があります。

そのため、 リリース 後に問題ないかを監視、
また何か問題があったときにすぐに対応ができるよう、
リリース 作業は集中的に行うことが一般的です。

このように、 Web システム 開発 は
企画 、 設計 、 開発 、 テスト 、 検収 、 リリース の
作業フローによって進められます。

依頼者が各工程の詳細まで理解することは難しいですが、
大まかな流れをつかんでおくことで、
後戻り工数の発生リスクが少ない状態で開発を進めることができます。

また、この各フローで発注者側がケアすべきことを理解しておくことで
トラブルの少ない Web システム 開発 につながりますので、この記事をぜひ、参考にしてください。