はじめに
システム開発の成功には、エンジニアチームの経験と実績、適切なプロジェクト管理、トラブル発生時の対応力など、さまざまな要因が挙げられます。システム開発を経験したことがない人は、システム開発がどのように進んでいくのかイメージしにくいのではないでしょうか。
複雑に思えるシステム開発にも実は、いくつかの手法・メソッドが定義され、多くのシステム開発は、いずれかの手法・メソッドに沿って進められます。この記事では、日本で広く使われている標準的なシステム開発工程（ウォーターフォール）について、概要からメリット、注意点についてご紹介します。
システム開発工程とは
「開発工程」とは、システム（もしくはアプリ）を最小限の時間・コストかつ高品質で開発するための枠組みと言えます。
言い換えると、十分にテストされた高品質のシステムを迅速に開発できるようにするための、構造化されたフェーズです。開発工程の各工程（フェーズ）には、要件定義、設計、開発、テスト、リリース、運用・保守、新規・拡張開発（エンハンス）などがあります。
システム開発に必要な期間は、開発するシステムの規模にもよりますが、3ヶ月から6ヶ月、長い場合は1年以上かかることもあります。完成されるシステムがすべての要件を満たすようにするためには、開発工程のすべてのフェーズを正しく行う必要があります。
システム開発工程によって、プロジェクトの進捗管理や状況把握がしっかりとでき、開発するシステム（もしくはアプリ）の品質向上を期待することができます。
開発工程の仕組みと役割
繰り返しになりますが、開発工程を理解することによって、システム・アプリ開発にかかるコストや品質確保のために注意すべき点を把握しやすくなります。
一般的な開発工程のステップは以下の通りです。
- 要件定義
- 基本設計（外部設計）
- 詳細設計（内部設計）
- 開発（コーディング／プログラミング）
- テスト
- リリース
- 運用・保守
特に「1. 要件定義」は最初の段階でありながら、最も重要なフェーズだと考えれています。
要件定義は、プロジェクトの残りの部分の基準となり、完成したシステムが使い手（ユーザー）の期待に応えられるかどうかを左右する重要な役割を果たします。そのため、何よりもまずこの段階では、自分の意図や計画を率直に開発者（会社）と共有する必要があります。
それでは、開発工程の各フェーズについて、詳しくみていきます。
システム開発工程の各フェーズ
1. 要件定義
開発したいシステムによって、どのような課題を解決したいのか、何を実現したいのかを洗い出す＝定義するフェーズ（段階）です。
一見、自分の願望を伝えるだけのシンプルな作業に見えますが、多くの人がこの要件定義の段階で、関係者も含んだ網羅的な願望（要件）を伝えることができません。
よくある失敗例として、現場を知らない部門長が、「現場スタッフの作業を可視化して、フィードバックしやすいように、作業ログ取得システムを作ってほしい。」とリクエストするとします。
ここで重要なのが、この要件定義の段階で、現場から代表者が参加しているかどうかです。
ここでもし、現場代表者が参加していれば、「作業ログ取得はいいですが、作業をしたら、いちいちシステムに入力をしないといけないのは、非現実的です。現場スタッフの作業効率が下がります。」と、部門長のリクエストの懸念点を指摘してくれるはずです。もし、現場代表者がいなければ、部門長の要望だけをくみ取った「無用の長物」になりかねません。
「やっぱりこうしたい」に注意！
また、要件定義フェーズでは、漏れなく、ダブりなく要件を伝えることが必要です。もし、漏れがあると後々の開発フェーズで、「やっぱりこういう機能もほしい。」とリクエストがあると、開発者は混乱します。
これがシステム開発プロジェクトでよく問題視される「仕様変更」です。仕様変更はプロジェクトの期日に影響を及ぼすだけでなく、追加の費用発生など、様々なリスクを招きます。
実際、仕様変更を見越して、開発スケジュールを決めるプロジェクトマネージャーもいますが、開発を依頼する側は、漏れなくダブりなく（MECE）、要件定義できるよう心掛けることが大切です。
要件定義のフェーズでは、まず誰を参加させて、なにがどこまで必要か、誰のなんのためのシステムか、しっかり定義することが重要です。
2. 基本設計（外部設計）
基本設計（外部設計）とは、UI（ユーザーインターフェース）つまり、システムの操作画面などの「見た目・デザイン」を設計する段階です。
UIは、見栄えの良さだけ重視するのではなく、システム・アプリの操作性、効率性、アクセス性を最大限に高め、ユーザーの関わり方（UX：ユーザー・エクスペリエンス）に影響を与えます。そのため、ユーザーの視点から見ると、UIはシステム・アプリの性能を決定する重要な役割を果たしており、ユーザーにとってストレスなく使いやすい設計をすることが大切です。
このフェーズの成果物は、基本設計書となります。
3. 詳細設計（内部設計)
詳細設計（内部設計）とは、システム・アプリの「中身（機能・動作）」に関する設計です。開発言語、サーバー・データベース、APIとの連携など技術的な要素を中心に検討・設計されます。
家の設計に例えるならば、基本設計が外壁や内装＝「人の目に見える部分」の設計に対し、詳細設計では、「人の目に見えないが、家として機能するために必要なもの」を設計することになります。
このフェーズの成果物は、詳細設計書となります。
これまでの、「要件定義」「基本設計」「詳細設計」のことをまとめて、一般的に「上流工程」と呼ばれています。
4. 開発（コーディング／プログラミング）
開発のフェーズは、いよいよ「欲しいものを作る」フェーズです。この開発フェーズから、「下流工程」が始まります。
上流工程（要件定義と基本・詳細設計）で決定した仕様に沿って、開発者が開発を行います。
このフェーズでは、C++、PHP、Java、Ruby、Pythonなどの開発言語（プログラミング言語）で開発を行うほか、インフラ（サーバーやデータベース）部分の構築も行われいます。この開発フェーズと後述するテストフェーズで一番、時間と労力が必要とされます。
このフェーズの成果物は、実際のシステム・アプリやソースコード（プログラミングが記述されているファイル）などがあります。
5. テスト
テストフェーズでは、テスターと呼ばれる担当者が、作成したプログラム（システム・アプリ）を納品する前に、不具合（バグ）がないか・求めれている機能が正しく動作するかなどを検証します。
テストの過程で不具合（バグ）が発見されることも、もちろんあります。問題が発見された場合、テスターは開発者に通知し、開発者（プログラマー）は修正して、テスターが再度検証します。
さらにこのテストフェーズには複数種類のテストがあります。以下に代表的なテストの種類を紹介します。
ユニットテスト
ユニットテストとは、システム・アプリを構成する個々の機能（ユニット）を検証するテストです。例えば、勤怠管理システムを開発する場合、「従業員の勤怠を記録する機能」や「給与を計算する機能」はそれぞれ別のユニットとなります。
結合テスト
結合テストとは、上述した各ユニットを結合し、１つのグループとしてテストすることです。こちらも要件を満たしているか、不具合（バグ）がないかを検証します。
総合テスト
総合テストとは、システム・アプリ全体のテストです。統合テストと呼ばれることもあります。開発したシステム・アプリが完成品として機能するかを検証するテストになります。
運用テスト
システム・アプリを納品・リリースする前の最終工程です。 ユーザーが実際にシステム・アプリを操作したときに、期待通りに昨日するかを確認するためのテストです。総合テストとの違いは、運用テストでは実際のユーザーが操作するのに対し、総合テストでは実際ユーザーが関わないことが一般的です。
ここまで様々なテストを紹介しましたが、煩雑だと感じるのではないでしょうか。しかしながら、テストフェーズは、目的のシステム・アプリができているかどうかを確認するフェーズなので、とても重要です。
納品・リリース日を優先するために、テストフェーズをおろそかにすると、市場・ユーザーに「未完成」のシステム・アプリを届けることになります。そうなると、システム・アプリの評判が下がり、中長期的に失敗する可能性が高くなります。
6. リリース
システム・アプリは、上述した各テストで徹底的に検証され、品質が保証されたあと、実際の市場・ユーザーにリリース（公開）されます。実際のリリースでは、企業のビジネス戦略に応じて、予定されいてるすべての機能が一度にリリースされるわけではなく、段階的にリリースされることもあります。
7. 運用・保守
リリース後まもないシステム・アプリでは、予期せぬ不具合が発生することもあります。また実際に使ったユーザーのフィードバックをもとに、改修する必要があるかもしれません。
この運用・保守フェーズでは、システム・アプリが安定稼働するために、人員を確保することが必要です。開発時ほどの人員規模は必要ありませんが、不具合や急なトラブルに対応するためにも、運用・保守担当者が必要です。
以上のことから、システム・アプリ開発は「作って終わり」ではなく、作ったあともメンテナンスし続ける必要があることがわかります。
システム開発工程に従って開発を行うメリット
開発工程は、最終製品（システム・アプリ）の目的や、解決したい課題を明確にするためのものです。開発を成功させるために、関係者に対してロードマップの役割を果たします。
また、今後必要となる施策を計画するためのツールでもあります。すべてが前もって計画されていれば、プロジェクトはよりスムーズに進行します。開発工程は、プロジェクトマネージャーが進捗を把握することことを支援し、開発チームが予定・予算内で完成できるようにします。
開発工程にある各フェーズの成果物やトラブル対応についてのドキュメントが整備されていれば、新しいプロジェクトメンバーへの引継ぎや、プロジェクトが迷走し始めたときに役立ちます。
システム開発工程の注意点
システム・アプリ開発工程を参考にする際の注意点をいくつか紹介します。
不明瞭なコミュニケーション
要件定義は、既述のとおり、最も重要な段階です。開発の遅延や障害を避けるためには、すべての関係者がお互いに適切なコミュニケーションをとる必要があります。
度重なる仕様変更
プロジェクトが下流工程に入ってからの仕様変更は、当初の目的や製品（システム・アプリ）が変わることを意味します。仕様変更をリクエストする方は、ほんの一部分の変更だけだと認識していますが、開発側にとっては、そうではありません。一部分の変更は、連携する機能（ユニット）にも影響がでるため、大きな見直しと修正コストがかかります。その結果、スケジュールが遅延し、開発コストがかさんだりします。
そのため、できるだけ上流工程（要件定義、基本・詳細設計）で仕様を確定することが求められます。
どうしても仕様変更が必要な場合は、仕様変更にかかるリスクを把握した上で行いましょう。仕様によっては、リリース後の「運用・保守」フェーズで、修正・追加対応ができる場合があります。
まとめ
いかがでしたでしょうか。今回はシステム・アプリ開発工程の各フェーズの概要や必要性と注意点について紹介しました。
システム・アプリ開発には、リリース後の運用・保守も含めると、決して安くはない費用とある程度の期間がかかることがわかると思います。
開発・運用コストを抑えたい、開発人員を増やしたいなら、オフショア開発がおすすめ！
オフショア開発（offshore development）とは、システム・アプリ開発や、運用・保守などの業務を海外の開発企業にアウトソースすることです。
東南アジアなど、日本の人件費より安い海外人材を活用することにより、採用・教育などのコストを抑えることができます。
例えば、80万円／月の日本のエンジニア1名を確保する場合、ベトナムであれば、同じ費用で２～３人のエンジニアを確保することができます。
