ソフトウェア・プロジェクトのマネジメントを考える
〜ITベンチマーキングSIG〜

　デマルコとリスター（以下はD&Lと記述）は、共著「熊とワルツを」の中で、『リスクマネジメントとは問題が発生する前の抽象的な概念の段階で対策を考えるプロセスである』と説明し、『リスクマネジメントは大人のプロジェクトマネジメントである』と述べている。本稿では、最初に、D&Lのリスクマネジメントがどのように組み立てられているかを概観する。次に、現在、私たちがどのような枠組み(Framework)の中でシステム開発プロジェクトのマネジメントを行っているかを整理する。そして、現行の代表的な枠組みとD&Lのリスクマネジメント方法を対比して考察する。

---

1．D&Lが提唱するリスクマネジメントの方法
　D&Lは、あらゆるソフトウェア・プロジェクトにおいて、計画と現実の乖離の大部分を生みだす共通のリスクに、1)内在的なスケジュールの欠陥、2)要求の増大（要求の変更）、3)人員の離脱、4)仕様の崩壊、5)生産性の低迷、の5つを挙げている。そして、その内容と対処法を以下のように述べている。

1)スケジュールの欠陥は、計画と実績の乖離を生み出す最大の要因である。それゆえ、要求仕様に従ったソフトウェア製作量の見積りに基づいて開発スケジュールを検討し、自社や業界の開発実績を勘案して、完了期日の確度を高めるマネジメントが重要である。
2)要求の増大及び変更は、ソフトウェア・プロジェクトにとって不可避である。ソフトウェアを必要とする企業や公共サービス機関といった組織の活動の内容は時々刻々変化していく。この変化への追随に必要な機能の増大や変更に応じられないと、ソフトウェアが完成しても利用されなくなる。であるから、ソフトウェア開発工期の長さに応じて仕様変更の発生量を予測し、対処する時間と費用を計画に織り込む必要がある。
3)人員の離脱は、プロジェクト実行の途中でも起こる。プロジェクト要員が保有するシステム技術や知識・経験はプロジェクト運営の成否に影響する。要員交替に備えるために自社のプロジェクト実績と経験を活かして対処期間を推定し計画に織り込む。
4)仕様の崩壊は、起きたときにはプロジェクトが破綻する。プロジェクトの初期段階に行う要求仕様定義への合意は、利害が異なる関係者間で、お互いの我慢によって曖昧な状態で成立する場合がある。しかし、曖昧さを残した仕様からソフトウェアを曖昧に製作することはできない。プロジェクト業務を進行させ、入出力のデータフローとデータ要素のレベルで関係者間の合意を得ることが対処法である。曖昧さは改善されれば仕様の崩壊は防げる。そして、プロジェクト完了が見通せる。
5)生産性の低迷は、プロジェクト・チームの仕事の能力(performance)によって左右される。プロジェクト要員の個人差による仕事能力の影響をプロジェクト・チーム全体にならした結果では、チーム間の能力差がさほど大きくない。一定数のチーム全体にならした結果をデータ分析すると、このリスクによってプラス側・マイナス側にふれる生産性のばらつきはほぼ同じ確率になる。このリスクは平均期待値を手懸りにマネジメントできる。

　D&Lは、5つのリスクそれぞれに定量化したモデルを作成している。そして、5つのリスクをモンテカルロ・シミュレーションによって組み合わせて、ソフトウェア・プロジェクトの完成までの月数を予測し評価するリスクマネジメントの方法を提唱している。
　このリスクマネジメント（＝プロジェクトマネジメント）の方法はRISKOLOGYと命名され、ウェブ上で公開されている。D&Lによる共通の5つのリスクの内容は、他のリスクマネジメント方法でも似たような議論がされている。

　その一方で、D&Lは5つのリスクに関して、「これらのうち、真に仕事の遂行能力に関係するのは最後の１つだけである。他の４つは、（プロジェクトマネージャが）どんなに懸命に働いても、仕事をする能力があってもほとんど関係がない。」とも述べている。
　筆者はこの記述を読んで、私たちが取り組んでいるソフトウェアを中心とするシステム開発のプロジェクトマネジメントがどのように行われているかに関心を持った。
　次項では、この関心事を考察する。

2．ソフトウェア・プロジェクトに関するマネジメントの枠組み
　筆者のプロジェクトマネジメント経験は、主に製造業の生産管理システムの企画・開発業務で得ている。加えて、ユーザー系のシステム開発会社で、システムインテグレーションならびにソリューションの事業管理に携わった経験がある。こうした経験に基づいて、システム開発およびプロジェクトマネジメントに関する枠組みを整理する。

　D&Lは「ソフトウェア・プロジェクト」のマネジメントをリスクマネジメントの領域で前述のように論じた。筆者は、D&Lのソフトウェア・プロジェクトとは、「ソフトウェアを中心とするシステムの開発をプロジェクト組織で遂行する業務」であると理解している。本稿では、このような解釈で「ソフトウェア・プロジェクト」を用語として用いている。

　ソフトウェアおよびプロジェクトには、マネジメントに有効な規格がある。まず、ソフトウェアに関しては、ソフトウェアライフサイクルプロセス（SLCP）の定義がISO/IEC(および翻訳JIS)で規格化されている。このSLCP規格は、ソフトウェアを含むシステム、単体ソフトウェア製品およびソフトウェアサービスを取得するとき、ならびにソフトウェア製品の供給、開発、運用、保守を行うときに適用できる。

　日本では、このSLCP規格を包含した「共通フレーム」がガイドブックとして刊行されている。共通フレームは1994年に初版が発行され1998年に改訂されている。2007年に再度改訂された。共通フレームはそれぞれの刊行年が付されて名称される。最新の共通フレーム2007は、SLCP規格が定義する主ライフサイクルプロセスに企画プロセスと要件定義プロセスを付加している。この標準ガイドブックは、日本の情報サービス産業界の標準的な規範として利用促進されることが期待されている。
　次に、米国に本部を置くプロジェクトマネジメント協会が策定した「プロジェクトマネジメントの基礎知識体系（PMBOK）」は、グローバルにプロジェクトマネジメントのデファクトスタンダードとなっている。PMBOKは、1996年に初版が発行され、2000年および2003年と定期的に改訂されている。現時点では第3版が最新である。日本の情報サービス産業界ではPMBOKが様々な場面で登場する。例えば、(独法)情報処理推進機構（IPA）が発刊している高度情報化人材育成標準カリキュラムのプロジェクトマネージャのテキストは、PMBOKの9つの知識エリアを取り入れて全面的に内容が更新された。
　これら2つの規格（含むガイドブック）は、規格の誕生から改訂を経て、情報サービス産業界で普及してきたので、ソフトウェア・プロジェクトをマネジメントする枠組みとして考えることができる。例えば、共通フレームを水平軸、PMBOKを垂直軸に置くことによって、平面上でソフトウェア・プロジェクトをマネジメントする枠組みを組み立てることができる。

　プロジェクトは『独自の製品やサービスを創造するために実施される有期的な業務』（PMBOKの定義）である。通常、ソフトウェアでは開発業務がプロジェクト対象となり、開発プロセスの前後にプロジェクトの始点・終点が設定される。そして、独自の製品やサービスに必要なソフトウェアの開発を目的にして、プロジェクトの業務内容に目標が設定され、作業計画が立案されて実施される。
　共通フレーム2007では、ソフトウェアライフサイクルの主プロセスの内容が〔企画、要件定義、開発、運用、保守〕の個別プロセスならびに〔取得、供給、契約変更〕の契約・合意プロセスから構成されている。PMBOK 第3版では、9つの知識エリア〔統合、スコープ、タイム、コスト、品質、人的資源、コミュニケーション、リスク、調達〕が設定されている。これらの内容を2軸にしてソフトウェア・プロジェクトに関するマネジメントの現行の代表的な枠組みの内容を具体化できる｡
　勿論、ソフトウェア・プロジェクトのマネジメントを考えるための規格やガイドラインは種々ある。日本発のものとして、ソフトウェアでは、『ITプロジェクトの「見える化」』がプロセスを〔超上流、上流、中流、下流〕と中分類している。プロジェクトマネジメントでは、『P2M(プロジェクト＆プログラムマネジメント)』がプロジェクトマネジメントの知識能力体系を〔プロジェクトとプログラム〕の両面で構成している。これらの内容から違った枠組みをモデル化することもできる。（注：P2Mはプログラムを組織の全体使命を実現する複数のプロジェクトが有機的に結合された事業であると定義している）

　本稿では、共通フレーム2007とPMBOK第3版による枠組みを現行の代表とした。この枠組みによって、ソフトウェア開発の目的を特定すると共にプロジェクトの有期性を明確にすることができる。すなわち、関係者間の共通認識の下でプロジェクト運営が可能になる。
　次項は、ソフトウェア・プロジェクトのマネジメント枠組みと最初に紹介したD&Lのリスクマネジメントの方法とを対比して考察する。

3．ソフトウェア・プロジェクトの枠組みとD&Lのリスクマネジメント方法の対比
　組織の業務システム化を意思決定して、ソフトウェアを中心とするシステム開発を行い、運用へ移行していく大まかなシステム化プロセスを、ソフトウェア・プロジェクトの業務に着目して、一段階詳細化したサブプロセスに展開すると次のように整理できる。
　（i）業務システム化の目的・メリットの明確化⇒（ii）システム化の要求仕様の分析・定義⇒（iii）ソフトウェア要件の分析・定義⇒（iv）ソフトウェア設計・製作⇒（v）システムのテスト・移行⇒（vi）システム化結果の評価・確認⇒（vii）定常的な運用・保守

　このサブプロセスの中でソフトウェア・プロジェクトの始点・終点の位置を確認する。プロジェクトの終点（完了）は、サブプロセス（vi）で、システムの目的・目標を評価し、達成を確認して、完了させることができるので、ここが終点となる。
　プロジェクトの始点は、どこへ設定すればよいのだろうか。共通フレーム2007のソフトウェアライフサイクルプロセスは、企画、要求定義、開発の順序で各プロセスを進行させる。企画プロセスは、システム化構想の立案、システム化計画の立案等が内容である。要件定義プロセスは、利害関係者要件の定義が内容である。開発プロセスは、システム要件の定義、システム方式設計からソフトウェア要件定義、ソフトウェア設計・製作のプロセスへ移行していく。
 このように、共通フレーム2007がガイドするソフトウェアライフサイクルプロセスは、システム化サブプロセスの（i）業務システム化の目的・メリットの明確化をプロジェクトの始点とすることができるように構成されている。
　ソフトウェア・プロジェクトがライフサイクルプロセスのどこを始点にするかは、　PMBOK第3版が示す統合マネジメントおよびスコープマネジメントの内容で定めることが可能である。そして、工期、コスト、品質等の個別マネジメントへと具体化できる。

　共通フレームが2007版に改訂された重要な点は、業務遂行者の主語となっている企画者、要求定義者などと共通フレームを利用する実際の組織／役割との関係を表にして明確に示したことである。加えて、補足説明集の中で、要件定義の内容を〔事業、業務、システム〕に区分して、経営層と実務層の役割分担のモデルを示した。
　PMBOK第3版は、プログラムの定義を「調和の取れた方法でマネジメントする関連のあるプロジェクトのグループ」と説明している。基本的に、PMBOKはプロジェクトの始点から終点にいたる範囲内でプログラムを取り扱っている。

　本稿の第1項で述べたD&Lのリスクマネジメントでは、ソフトウェア・プロジェクト実行の局面で5つのリスクが顕在化した場合、プロジェクトマネージャが主体的に対処可能なリスクは5)生産性の低迷のみであると述べている。他の4つ(「1)〜4)」)のリスクに関しては、プロジェクト開始時点の前提条件の内容を検討して、準備できるリスク対処策を考え、実行計画に織り込む。リスクが顕在化したらその対処策の範囲で処置することを述べている。
　筆者は、プロジェクトマネージャが5つのリスクをいかに処置できるかは、業務システム化の作業プロセスの中で行われる意思決定への参加の程度に左右されると考えている。
　現行のプロジェクトマネジメントの枠組みが示すベンダの役割は、供給者及び開発者の立場に責任の主体があり、他の関連業務では支援者の役割を担うことになっている。この役割分担がD&Lのプロジェクトマネジメントにおいてプロジェクトマネージャが果たせる役割と符合していることが分かった。すなわち、プロジェクトの始点で与えられた前提条件の変化がリスクとなる場合は、プロジェクトを遂行するマネージャは大きく対処することができないことがマネジメントの枠組みとD&Lのリスクマネジメント方法の対比で理解できた。

　T-SIGは、多くの課題に解決策を提言してきた。2008年の活動では、プロジェクトマネジメントの仕組み、技術、人材育成・活用のジャンルで個別テーマが設定されてワーキンググループが課題解決に取り組んでいる。
　本稿では、情報サービス産業の分野において現行を代表するプロジェクトマネジメントの枠組みを整理した。そして、D&Lのリスクマネジメント方法を対比して両者を考察した。このような検討を継続して、より良いプロジェクトマネジメントに微力を尽くせないかと願っている。

終わり

IT-SIG，内容にご意見ある方、参加申し込みされたい方は こちらまでメールください。歓迎します。

ITベンチマーキングSIGホームページは こちら