システム開発の流れとは？発注者も知っておくべき各工程のポイントまとめ｜東京のWEB制作会社・ホームページ制作会社｜株式会社GIG

BLOG

ブログ

システム開発の流れとは？発注者も知っておくべき各工程のポイントまとめ

2019-03-02 制作・開発

制作会社にシステム開発を依頼する場合、「制作のプロなのだから丸投げしても大丈夫」という発想では、取り返しのつかないトラブルを招いてしまいかねません。
そのため、発注者側もシステム開発の流れを理解しておく必要があり、システム開発プロジェクトのいちメンバーであるという認識が重要です。

では、なぜ発注者側もシステム開発の流れを知っておくべきなのか、またシステム開発の工程にはどういったものがあるのか、詳しく見ていきましょう。

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

発注者もシステム開発の流れを知っておくべき理由、それは予期せぬ開発の進め方により、予期せぬ制作物が出来上がってしまうことを避けるためです。

システム開発という目に見えないものをつくる以上、何をどうつくりたいかを発注者側が正しく伝えることが重要です。しかし、システム開発では要件定義では決めきれないこともあるでしょう。だからと言って「開発期間が長いから、あとからでも修正できる」と思ったら大間違いです。

システム開発の工程には大きく分けて「ウォーターフォール型」と「アジャイル型」があります。ウォーターフォール型では開発工程を事前に明確にして進める方法に対し、アジャイル型ではスピードを重視し、実装と修正を繰り返していく方法があります。

もしウォーターフォール型での進め方でプロジェクトが進行し、開発途中で追加の要望に対応しようと思った場合、開発手法によっては後戻り工数が発生し、スケジュールの大幅な遅延と追加開発による追加コストが発生してしまいます。

一方でアジャイル開発で進めようと思った場合には、プロジェクト途中で発生した要望に対応できるかもしれませんが、発注者側と開発側の認識が合っていないと、エビデンスとなるドキュメントの不在、責任の所在が不明確といった理由でトラブルが絶えず、結果的にプロジェクトが途中で頓挫してしまう、というケースも珍しくありません。

そのため、様々なトラブルを未然に防ぐためにも、システム開発の各工程において発注者側と制作会社側とのコミュニケーションは非常に重要であり、各工程で何をいつまでに決めておくべきかを、発注者側も把握しておく必要があります。

システム開発の流れと各工程におけるポイントとは

では、システム開発はどういった流れで進行していき、各工程で発注者が知っておくべきポイントは何か、見ていきましょう。

STEP01. 要件定義

システム開発の最初のステップは、要件定義です。ウォーターフォール型であれば、この要件定義で決められたことがすべてと言っても過言ではありません。

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

要件定義フェーズにおいて重要なことは、発注者側がシステム開発の目的を明確にしておくことです。その場しのぎで必要な機能を洗い出していては、結果的に目的を達成できない意味のない制作物が生まれてしまいかねません。

そして、目的を達成するためにはどういった要件が必要かを自分たちの中でも明確にし、制作会社側との認識のズレがないように注意しましょう。

STEP02. 情報設計、画面設計（UI/UX）

要件定義をもとに、具体的にどういったWebサイトにしていくかを決めていくのが情報設計、画面設計のステップです。ディレクトリ構造の決定、ディレクトリマップの作成により、情報をどうグルーピングしていくかを明確にし、どういったサイトレイアウトにするのかをワイヤーフレームに落とし込んでいきます。

画面設計は実際に目に見える部分を設計していくため、主観的な意見が飛び交いやすいフェーズでもあります。発注者側はあらためて、システム開発の目的に振り返り、ターゲットユーザーに対してどういった行動を起こしてもらいたいかなど、ユーザー視点が欠落しないよう注意が必要です。

また予算に応じて制作会社ではプロトタイプを作成し、実際にどういった画面遷移をするのかを見ながら、UI/UXの精度を高めていく進め方もあります。

参考：
キーワード設計・アクセス解析の方法
 ヒューリスティック分析・評価とは
 競合分析・ユーザビリティ調査の方法

STEP03. システム設計、インフラ設計

要件定義、外部設計（情報設計・画面設計）をもとに、システムやインフラといった内部設計を進めていくのが3つめのステップです。データをどう取り扱うかなどのDB設計やAPI設計、バッジ処理設計などのシステム要件、またサーバ構成をどうするかなどを制作会社中心となって設計が進んでいきます。

本フェーズで発注者側が意識すべきことは、制作会社によっては発注側への確認・相談のないまま設計が進んでしまうケースもあるため、定例ミーティング等を通じて定期的に制作会社とのコミュニケーションをとることでしょう。

たとえばサーバ構成は、どれくらいの負荷を想定しているか、拡張性をどう担保するかなどをケアして設計すべきです。そのため、事業の特性やプロモーション計画によってアクセスが集中するときがあるにもかかわらず、それに耐えきれないサーバ構成で機会損失が発生した、ということが後々起こらないようケアしなければなりません。

参考：
求人ポータルのシステム開発の進め方
 CtoCマッチングシステム開発の進め方
 イベント管理システムの開発の進め方

STEP04. プログラミング

各設計をもとに、実際に実装を行います。発注者側からすると進捗が見えにくいフェーズのため、プロジェクト進行を可視化できるツールを用いて、制作会社と進捗共有ができるようにしておくとコミュニケーションコストが軽減され、プロジェクト進行がスムーズです。

なお、リリース後の引き継ぎや改修などを考慮し、どういった言語で実装するのかも発注者側もある程度把握しておいた方が良いでしょう。

参考記事：
インフラ構築クラウド構築（AWS、サーバ構築）の方法

STEP05. 単体テスト・結合テスト

実装されたプログラムが正しく動作するのかをテストします。通常、プログラム単体でのテストとプログラム同士が組み合わさった総合テストを行い、システム設計フェーズで定めたことが満たされているかを確認します。

発注者側は、システム開発ではプログラム実装工程において不具合（バグ）が往々にして発生することを理解し、定例MTG等を通じて、進捗状況を確認するようにしましょう。

STEP06. システム（総合）テスト

単体テスト・総合テストをクリアし、最終的に要件定義で定めた条件下で動作するかを、本番環境と同じ環境下でテストを行います。本フェーズも制作会社側でのテストになります。

STEP07. 運用テスト・検収

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

なお発注者側は、いざ検収で制作されたサービスを見ると、新たな気付きや追加で実装したい機能というのが往々にして出てきます。
しかし、上述の通り仕様が決まってから実装、テストは非常に多くのステップ・工数が発生するため、リリース前に追加開発をしようと思うと、スケジュールが大幅に後ろ倒しになるだけでなく、追加開発のコストが発生してしまいます。

そのため、要件定義で定められていない仕様に関しては、基本的にリリース後にあらためて追加開発の要件を整理していく、という考え方が重要です。

参考：
保守運用 / 内製化支援の方法
 コンテンツ企画・インタビュー制作の進め方

STEP08. リリース作業

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

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