システム開発工程とは？発注者が知っておくべき流れやポイント

システム開発・導入を成功させるには、外部の開発会社へ依頼する場合でも、発注者側が実際の開発工程について理解しておくことが重要です。

この記事では、システム開発工程の具体的な流れや、正しいプロセスでシステム開発を行う必要性、システム開発を発注する際のポイントなどについて解説します。

➡︎【資料ダウンロード】アプリ開発の企画～発注の教科書

システム開発工程とは？

システム開発工程とは、システム開発を行う上で必要な一連のプロセスのことを指します。設計・開発・テストといったシステム開発を行う上で必要となるプロセスを工程として区切り、実際の開発もこの工程単位で進めていきます。

開発工程に沿って作業を進めるメリットは、開発の進捗が適切に把握でき、かつ、品質の高いサービスのリリースが可能になることです。

具体的なBad CaseとGood Caseをご紹介します。

[Bad Case]
工程をしっかり管理せずに開発を進めてしまうと、たとえば作成途中の設計書を完成版と勘違いして開発が進んでしまう、というようなことが起こりかねません。テストやリリース後に「◯◯の機能が要件と違う」というトラブルが発見される場合、設計からすべての作業がやり直しになってしまいます。

[Good Case]
工程ごとに開発を進める場合、各工程が完了するタイミングで、関係者が成果物に対して漏れがないか・誤りがないかをチェックする作業を設けることができます。手戻りを最小限に抑えながら、開発を進めることが可能です。

また、システム開発において重要なポイントは「ビジネスゴール」や「ユーザーゴール」など、システムを導入して何をしたいかをはじめに明確にしておくことです。さらに、企画段階で「コンセプト」「機能」「強み・優位性」などを設定しておくと、依頼する開発会社へ意図が伝わりやすくなります。

QCD（品質・コスト・納期）の制約から、当初の想定よりも提供機能を減らす（スコープアウト）場合もありますが、「何をしたいか」が明確ならば残すべき機能の判断はブレません。

➡︎【資料ダウンロード】アプリ開発の企画～発注の教科書

V字モデルとは？

V字モデルは、サービスの品質確保に向けて開発現場でよく利用される考え方です。プログラミング（単体テスト）工程を中心に、各開発工程で必要とされるテストをVの字に表しています。

図の左側が段階的に仕様を詳細化する工程、右側がそれらに対応するテスト工程です。高さが同一の工程はリンクしており、同じ詳細さのレベルを表しています。

例）基本設計では画面の基本的な構図・ボタン操作・遷移先などを設計するので、それらに対してシステムテストという工程を設け、「画面操作が適切に動作するか」という観点で検証する。

V字モデルを活用することで、開発工程で実施した内容を漏れなく検証でき、品質向上につながります。

➡︎【資料ダウンロード】アプリ開発の企画～発注の教科書

システム開発工程の具体的な流れ

では、システム開発の具体的な流れを工程ごとに詳しく解説します。

前提：プロジェクト計画

実際の開発をスタートする前準備として、プロジェクト全体のスケジュール、体制、サービス概要などを関係者で共有し、全体の目線合わせを行います。目的やゴールを明確にして開発者との認識の齟齬を防ぐため、必ず発注者も参加します。

• スケジュールの決定（開発/リリース計画とリリース後の保守・運用計画）
• 体制図の作成（発注側・受注側のコミュニケーションパス）
• サービス概要の決定（機能内容・範囲と非機能範囲）

要件定義

要件定義とは、システム開発で実装する範囲や内容（システム要件）を決定する工程です。発注者が求める要件を開発者側の視点からまとめ、定義します。この工程にも発注者は必ず参加し、開発者とともに要件を定めます。

今回実現する機能の一覧と概要、逆に今回は対象外となる範囲のそれぞれが明確化されることで、発注者と開発者が同じ目線でスタートラインに立つことができます。

• 機能要件（ソフトウェアやシステム開発において、発注者が求める「機能」のこと）の決定
• 非機能要件（「機能」以外のユーザビリティ、性能、拡張性、セキュリティなど）の決定

基本設計

要件定義の工程で決定した内容をもとに、システムに実装する機能を明確化・具体化する工程です。この工程が完了すると、画面構成・遷移先・入力内容といったサービスの全体像が可視化され、要件定義で洗い出した機能一覧の実現方法が明確化されます。

発注者と開発者の意見のすり合わせを行うため、この工程にも発注者は必ず参加します。ユーザーから見たときにどのような動作になるのかを決めるため、「外部設計」とも呼ばれます。

• 画面設計
  ・画面デザイン、遷移、バリデーション（入力チェック）
  ・特殊操作
• データ設計
  ・データベースに保存するデータ
  ・データベースのテーブル一覧化（実データだけでなく、アカウント情報やサイト画像などの補助情報も含む）
  ・画面からデータベースにデータを保存する処理(API)の一覧化
• インフラ設計

詳細設計

基本設計書をもとに、開発を行うエンジニアへ向けて「機能をどのように実装するのか」という設計を行う工程です。ユーザーから見えない部分の設計を行うため「内部設計」とも呼ばれます。

また、基本設計では「何をしたいか」を表現するのに対し、詳細設計では「どのように実現（実装）するか」を表現する違いがあります。具体的な実現方法を開発者が実装可能な状態まで落とし込む作業です。

基本的に開発者側が中心となって行いますが、定期的なミーティングを設け、発注者側も進捗や成果を確認しておくことが重要です。

• 画面処理設計
• API処理設計
• データベース論理設計
• バッチ処理設計

実装（開発）

詳細設計書に基づき、開発会社のエンジニアがプログラミングを行います。「作る・レビューする・改善する」の繰り返しにより機能を実装し、システムを作っていきます。

レビューとは、プログラムのソースコードを記述者とは別の人が査読し、誤りや改善点を見つけ出す取り組みです。レビューと改善を繰り返すことで、プログラムの品質を高めていきます。

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

テスト

開発が完了したら、作成したシステムが正しく動作するか確認するためのテストを行います。テストの種類は以下の通りで、上から順番に行います。

• 単体テスト（ホワイトボックステスト）
  システムの内部構造に重点を置くテスト手法。作成したプログラムを１行ずつテストし、ロジックが正しく動くことを確認する。
• 単体テスト（ブラックボックステスト）
  システムの外部仕様に重点を置くテスト手法。インプットに対して単体モジュールが正しいアウトプットを行うことを確認する。
• 結合テスト（内部結合テスト）
  システムを複数の意味あるサブシステムに分割し、サブシステム内の構成要素間（例：画面A→画面B）で正しくデータや操作の流れが連結されることを確認する。
• 結合テスト（外部結合テスト）
  サブシステム間（例：Web管理画面→アプリフロント）で情報や挙動が正しく連結されることを確認する。
• システムテスト
  基本設計の仕様に基づき次のポイントを確認する。
  　・画面間の遷移が期待通りに動作するか
  　・機能要件としてあげられた各機能が設計書の記載(期待値)通りに動作するか
  　・入力上限、性能負荷、故障発生時など正常時以外の挙動も同じく設計書の記載通りに動作するか
• 受け入れテスト
  発注者が実際の運用環境またはそれに近い環境でシステムを使用し、次のポイントを確認する。
  　・要件定義で定義された機能要件を満たすか
  　・発注側が期待したサービスレベルを提供できているか

リリース

各テストにより品質が保証されたら、実際の運用環境・ユーザーへリリース（公開）します。

保守・メンテナンス

リリース後の運用フェーズでは、システムの予期せぬトラブルへの対応や、安定稼働させるための定期的なメンテナンスを行います。保守・メンテナンス業務は社内の情報システム部門が担当することもあれば、システム開発会社が担当する場合もあります。

➡︎【資料ダウンロード】アプリ開発の企画～発注の教科書

正しいプロセスでシステム開発を行うメリット

では、なぜシステム開発はプロセスに沿って進める必要があるのでしょうか？ここでは、正しいプロセスでシステム開発を行うことによって得られる具体的なメリットについて解説します。

品質の向上

正しいプロセスに沿うことで、明確化された要件に基づいて開発が進められます。各工程での目標設定や管理が行いやすいため、設計段階で設定された高い品質を保ちやすいことがメリットです。また、各工程に対応した適切なテストが行われることも品質の向上につながります。

プロジェクトのスムーズな進行

事前に計画することで、プロジェクトをスムーズに進められます。予期せぬトラブルの発生リスクを減らしてスケジュールの遅延や追加費用を最小限に抑えられるため、予算内でプロジェクトを完遂させるためにも有効です。

また、リリース後の運用方針や予算を事前に決めておくことも重要です。運用開始後に想定外のコストが発生するリスクを防ぎます。

コミュニケーションの促進

各工程で進捗状況の報告や仕様確認などが行われることで、開発側・発注側で不明確な点が解消され円滑なコミュニケーションにつながります。

開発会社に丸投げするのではなく、発注者も基本的なシステム開発の知識を身につけ、こまめに状況を把握するなど主体的に参加することが重要です。双方で共通認識を持ちやすくなり、トラブルや失敗を回避できます。

➡︎【資料ダウンロード】アプリ開発の企画～発注の教科書

モンスターラボが提供する課題解決までのストーリー

モンスターラボは、豊富なデジタルプロダクト開発実績を活かし、開発規模の大小を問わずグローバルなインサイトと最先端の技術を駆使した効果的な戦略と開発環境を提供します。

モンスターラボが提供する課題解決のためのプロセスは、次の図の通り大きく3つのステージに分かれ、左から右へ向かって進行します。

Incubation Stage：仮説のビジネスモデル設計

まずはクライアントのビジネスを正しく理解し、ビジネスモデル戦略の立案など、上流工程からシステム開発をサポートします。

Incubation Stageでは共感・定義のフェーズでビジネスパートナーとしての観点から新たな着眼点を見出し、本質的な課題を導き出します。さらに、さまざまな調査で得たユーザーの生の声や行動データの分析を行い、あらゆる角度からアイデアを創出。着想された筋の良いアイデアについて、競合優位性・実現性・持続性の観点からビジネスモデルの仮説を組み立てます。

Adaptation Stage：ビジネスモデルを適応

Adaptation Stageでは、目的を達成するために必要最低限な機能を搭載した製品やサービスを作成します。実際にユーザーやクライアントに使用してもらい、製品やサービスに対するフィードバックを取得。追加機能の開発・実装や改善を繰り返し、ブラッシュアップしていきます。

Development Stage：事業・サービス開発

Development Stageでは、ここまでのステージで判明した要求を要件定義に落とし込み、勝機がある製品やサービスと判断される部分について、最適な開発手法を用いて実装します。優先順位の高い機能から開発を進め、ビジネスロードマップに合わせた素早いリリースとサービス拡充に貢献します。

このようなプロセスに沿って進めることで、ビジネスニーズに合わせた開発手法を取り入れ、上流工程からグロースハックまでワンストップでサポートすることが可能です。

➡︎【資料ダウンロード】アプリ開発の企画～発注の教科書

まとめ：システム開発を成功に導くには開発工程の理解が重要

システム開発の需要は高まり続けていますが、実際には失敗してしまうケースも少なくありません。これらの中には、発注者側と開発者側で適切にコミュニケーションが取れなかったことが要因となっている場合もあります。

本記事では、工程に沿って開発を進める必要性と、その具体的な中身を紹介してきました。発注者がシステム開発工程について理解し、関わるべき工程で要望を伝えたり、こまめに進捗を確認したりすることがシステム開発を成功へ導くための鍵となるでしょう。

システム開発の流れや発注者が参加すべき工程について理解した上で、開発会社と十分にコミュニケーションを取り、より良いシステムの共創を目指してみてはいかがでしょうか。

サービス・プロダクト開発を検討している企業ご担当者様へ

モンスターラボは、約20年にわたるサービス・プロダクト開発実績から得られたデジタル領域の知見や技術力を活かし、デジタルプロダクト開発事業を展開しています。

先端テクノロジーに対応した高度なIT人材があらゆるプラットフォーム上での開発を支援します。アジャイル開発とDevOpsによる柔軟な開発進行や、国内外のリソースを活用したスケーラブルな開発体制の構築も可能です。 また、リリース後の保守運用や品質向上支援まで伴走可能です。

モンスターラボが提供するサポートの詳しい概要は以下リンクをご確認ください。

➡︎モンスターラボのサービス概要はこちら

案件の相談はこちら