プロジェクトの構成要素を探す手順：意外と知らない構成管理の正体（2）

　前回は、プロジェクトのいつの時点においても、要求／タスク／成果物の依存関係とともに、コスト、障害情報なども把握し、プロジェクトオーナーに提示できなければならないと書きました。ここでの“要求”という言葉は、“要求仕様“という狭義の意味ではなく、まさに、プロジェクトに対するあらゆる要求を意味しています。一例を挙げますと、「プロジェクトを××までに、成功裏に完了すること」というのもここでの要求に含まれます。従って、この要求を実現するためには、まずは“計画”というタスクを行うことになるでしょう。そして、計画タスクからは、目的、スケジュール、予算等々について定義、記述した成果物ができあがります。

　ですから、構成要素には、皆さんが思われている以上に多くのものが含まれることになります。プロジェクトの規模によって、それぞれの構成要素の内容に違いはありますが（例えば、あるプロジェクトのプロジェクト計画は1ページの簡単なものかもしれませんが、別のプロジェクトでは50ページにも及ぶものかもしれません）、構成要素として検討しなければならないものにはそれほどのバリエーションはありません。

　それでは、まずは構成要素を探していく手順について述べます。

　構成要素を漏れなく発見するためには、まずはプロジェクトのハイレベルなタスクを認識します。そして、そのハイレベルなタスクをどのように実行するのか、何を実行するのかを掘り下げます。そのようにして抽出されたタスクに対してまた、what、howを問いかけていくのです。こうすることによって、プロジェクトにおける構成要素を漏れなく見つけ出します。

　ここまでを読まれて、あることにお気付きの方もかなりいるのではないかと思います。そうです。構成要素の発見とは、プロジェクトのWBS（Work Break down Structure）が正しく構築されている組織、プロジェクトにおいてはたやすいことなのです。

　図1に、構成要素の発見の悪い例を示します。この例では、ハイレベルなタスクから、いきなり成果物を抽出しようとしている個所が見られます。もちろん、個人レベルではすべてが頭の中で展開できて、いきなり成果物を漏れなく発見することができるという人もいるかもしれません。しかし、それではいつまでたっても組織として定着することがありません。ですので、最低でももう1段はタスクをブレークダウンし、それに対する成果物という視点で発見することをお勧めします。

図1 構成要素の発見（悪い例）

　図2に、構成要素発見の改善例として、図1のやり方から、お勧めのやり方にしたものの例を示します。

　私は、明らかに図2の方が漏れなく構成要素を発見していけそうな気がするのですが、皆さんはいかがでしょうか？

図2 構成要素の発見（改善例）

　さて、このような形で構成要素を無事発見することができた後は、およそ以下の手順で進めます。

• 構成要素の格納ディレクトリ体系の決定
• 各ディレクトリ、構成要素ごとの担当グループ、担当者の識別とアクセス権限の決定
• 構成管理環境の整備

　構成要素の格納ディレクトリ体系については、いままでいろんな組織、プロジェクトのものをみてきましたが、成果物の種類で分類している場合がほとんどのようです。私がお勧めする体系は、狭義の“要求”に関する、要求―タスク―成果物の関連を把握しやすくするために、要求ごとにディレクトリを作成し、そのサブディレクトリとして設計、実装、テストというディレクトリを作成するというものです。

　ただし、この場合には、ソースコードが複数の“実装“ディレクトリに分散してしまい、コンパイルに大変な手間を要することになります。この点に関しては、ツールを利用することで解決可能なことも多いのですが、ここでは、特定のツールに頼らない方法として、“要求”ごとのディレクトリのサブディレクトリとして、設計、テストというディレクトリを作成します。設計ディレクトリの中には、シーケンス図に代表されるような、ある要求を実現するために利用するクラスやモジュールが特定できるような設計成果物を格納します。ソースコードは、開発環境、開発言語に適したディレクトリ構成に格納するようにします。こうすることで、開発作業者への作業負荷をできるだけ少なくし、かつ成果物間の関連も維持、管理しやすいようにするのです。

　なお、狭義の要求―タスク（設計、実装、テスト）―成果物の連鎖にないものについては、極力WBSの構造に合わせたディレクトリ体系としています。理由は、上述と同じでタスクと成果物の関連を簡単に把握するためです。

　権限設定、環境整備につきましては、比較的一般的な内容であることと、突っ込んだ内容になると、どうしても使用するツールなどに依存した内容となるため、ここでは言及しません。

2）構成管理の実践

　さて、何とか構成要素が決まり、ディレクトリ体系も決まりました。ここからがやっと構成管理の実践ということになります。実践する内容とは、構成管理ガイドに記されているはずの、

• 変更管理
• ステータス管理
• 監査

となります。

　これらを行ううえで、重要なものがあります。それは、ベースラインです。上記の3つの活動は、結局のところ構成要素に対する変更を管理、監視するというものです。そして、この活動を開始するきっかけが、ベースラインとなります。ベースラインとは、構成要素全体に対する、ある時点でのステークホルダー全員の合意といえます。変更管理、ステータス管理、監査とは、このベースラインに対する包括的な変更管理にほかなりません。ベースラインのない状態での変更管理はないということです。

図3 ベースラインと変更管理

　図3は、プロジェクトライフサイクルにおけるベースラインと変更管理の在り方を示したものです。最初のベースラインを作るまでは、さまざまな手順によってさまざまな成果物が構成管理の仕組みの下に集められます。そして、ある時点、例えば要求定義が完了し、プロジェクトスケジュールに対する合意が得られた時点で、最初のベースラインとします。このベースラインに対するそれ以降に発生する追加、変更、削除は、すべて変更管理手順に従って行われます。

　最後に、リリース（納品）のためのベースラインを作成し、運用フェイズに移行した後も、改修などを行う際には、変更管理手順に従ってベースラインを保守していくことになります。

　 実際には、変更管理手順が、合意を確立する手順として効果的なものであるために、最初のベースラインを作成する前の段階から、変更管理手順を適用するケースも多く見かけます。しかし、変更管理の本質とは、ある合意に対する変更を管理し、新しい合意を適切に確立するための手順であるということを常に認識しておくことは重要です。明確な目的の達成のために管理する、ということが重要なわけですが、得てして管理すること自体が目的だという錯覚に陥りがちだからです。正しい目的のない状態での管理、ルールは、非常に簡単に崩壊してしまうのです。