ITプロジェクトの各プロセスとは

先のエントリー（プロジェクトとプロダクトの関係）で説明したように、プロダクトライフサイクルの中に複数のITシステム開発プロジェクトが発生する。導入フェーズでは、MVP（ミニマム・バイアブル・プロダクト）と呼ばれる実用最小限のプロダクトをリリースする。成長・発展フェーズでは、機能追加・改修を行いリリースする。それぞれのリリース単位をプロジェクトでまとめて管理すると考えると分かりやすい。

ITシステム開発プロジェクトの開発管理モデルは、大きく2種類に分けて考えるのが現在の主流だ。

ウォーターフォール型モデル
アジャイル型モデル

1970年前後にウォーターフォール型の原型が提唱され、以降現在でも特に大規模開発プロジェクトではウォーターフォール型モデルで開発管理される事が多い。アジャイル型は、元々はウォーターフォール型で管理する際に発生する諸問題に対応するために提唱されたモデルで、小〜中規模開発プロジェクトで採用される事が多い開発管理モデルだ。今回のエントリーでは、開発管理モデルにかかわらず重要な「プロジェクト内の実質的プロセス群」について理解する。

ISO/IEC/IEEE で理解する「プロジェクト内で実質的に何を行っているか」

国際規格 ISO/IEC/IEEE では「12207」でソフトウェアのライフサイクルプロセスについて、「 29148」で Requirements（要件）についての指針を提供している。著作権の都合上図版をここで掲示することができないが、29148 内の図と 12207 の要素を使って、ITシステム開発プロジェクトで実質的に何を行っているかについて考えてみる。

a flow image of processes to make a system — 【注意事項】 2023年1月現在、ISO/IEC/IEEE 29148の最新版は 2018 版となっている。その中の重要な用語「Requirements」は、JIS等で「要求」と訳される事が多い。しかし一般実務的には「要件」という用語で語られる事が圧倒的に多いので以降「要件」で統一することとする。なお国際規格（英語）では「Requirements」の他に「Needs」という用語も用いられ、それぞれ明確に別の意味で用いられている。Requirementsを「要求」としてしまうとNeedsに合致する日本語がなくなってしまう。このあたりの苦悩についてはIPA「共通フレームワーク2013」の「 5.4.2：共通フレームで変更及び拡張した点」においても見て取れる。

まず①経営レベルの要件定義プロセスを行い、事業要件仕様（BRS: Business Requirements Specification）を決定する。このプロセスは市場や同業他社といった外部環境の動向をリサーチし、組織内の目標や方針を見極める「経営戦略」の一環である。そのため、開発現場では既にシステム開発の前提（自明のこと）として扱われる場合も多いが、経営戦略自体も試行錯誤が行われるプロセスである。近年ウォーターフォール型（開発工程・プロセスは上流から順に決定・実行され、各工程間の接続は文書により厳格に行う）の限界が語られる大きな原因のひとつは、プロダクトが持つべきすべての機能をライフサイクルの各工程でひとまとめにして決定・実行する事が、ビジネスの試行錯誤サイクルと親和性が良くないためである。

②ステークスホルダーレベルの要件定義プロセスでは、システムを利用するユーザを中心とした利害関係者が特定され、それぞれのユーザののニーズと、ユーザにとってのシステムの「ゴール」を定義する。また、ユーザごとのシステム利用シーン、利用方法などを優先順位とともに定義する。このレベルの要件定義には、業務ワークフロー及びフロー中にシステムが提供する機能リスト、運用シナリオも含む。このプロセスではステークホルダー要件仕様（StRS: Stakeholder Requirements Specification）を決定する。

③システム／ソフトウェアレベルの要件定義は、ステークホルダーレベルの要件定義を元に、システムを運用するにあたって必要な機能／非機能に落とし込み定義するプロセスだ。定義の中には、他のシステムとの境界や、インターフェースも含む。また、既存システムがある場合、業務プロセスやデータの移行手法やスケジュール、受入条件、テストケース／方法などの移行／運用・保守についても定義する。このプロセスではシステム要件仕様（SyRS: System Requirements Specification）及びソフトウェア要求仕様（SYS: Software Requirements Specification）を決定する。

④は、いわゆる広義の「開発」プロセス群で、アーキテクチャの設計、システム／ソフトウェアの設計、実装／単体試験、連結／連結試験を行う。設計〜試験については開発方式によって順不同となるため並列的に表記している。

①〜④のプロセスを経て、⑤移行・運用／保守プロセスに至る。このプロセスにより①で外部環境から受け取った（発見した）最上位の要求事項へのソリューションが提供される。

「プロジェクト内で実質的に何を行っているか」をシンプルに理解する

先の図をさらに抽象的にした図が下記となる。環境にあるニーズから課題を抽出（①②）し、システム化するための要件定義〜設計〜実装〜試験（③〜④）する。その成果物を移行・運用／保守（⑤）することにより、最初に抽出した課題へのソリューションを提供する。

なおこの①〜⑤のプロセスを大きな単位でまとめて順番に処理するのが「ウォーターフォール型モデル」で、小さな単位（例：機能単位等）で順番に処理するのが「アジャイル型モデル」だ。アジャイルは各プロセスを可能な限り小さい粒度にして、雪だるまを作るように繰り返し・繰り返しライフサイクルを重ねることで、プロダクトを成長させていく特徴がある。