Club-Zコラム第12回

【第12回】必要なのは仕組みの進化&深化

株式会社RDPi　　代表取締役　石橋　良造

2008.07.24

次に、プロジェクトの計画策定について考察します。CMMI では次のことができている必要があるとしています。

■見積もりを確立する
(1) プロジェクトの範囲を見積もる
(2) 作業成果物とタスクの属性の見積もりを確立する
(3) プロジェクトライフサイクルを定義する
(4) 工数と費用の見積もりを決定する

■プロジェクト計画を策定する
(5) 予算とスケジュールを確立する
(6) プロジェクトリスクを特定する
(7) データ管理について計画する
(8) プロジェクト資源について計画する
(9) 必要な知識とスキルについて計画する
(10) 利害関係者の関与を計画する
(11) プロジェクト計画を確立する

■計画に対するコミットメントを獲得する
(12) プロジェクトに影響を与える計画をレビューする
(13) 作業レベルと資源レベルの過不足を解消する
(14) 計画コミットメントを獲得する

数は多いですが、皆さんのところではほとんどの項目については何かしらの仕組みがあり、ある程度実施できているのではないでしょうか。ただ、これらはすべてプロジェクト作業（開発作業）が適切に抽出できていることが大前提です。見積もりをしたり、スケジュールを作成したり、リソースを調整したりするのは、適切な開発作業の抽出ができてこそはじめて意味を持ちます。適切に抽出された開発作業に対して、作業量を見積もり、関係者と調整し、作業の段取りを考えてスケジュール（線表）が完成するわけです。

したがって、開発作業を適切に抽出してスケジュール（線表）にするまでの作業過程を仕組みとして明確に定義することが重要です。図33を使ってこの作業過程を説明します。



要求仕様（外部仕様）と内部構造は相互に検証を繰り返しながら確定させます。前述のとおり、要求仕様は内部の振る舞いの裏付けが必要です。そして、製品内部の振る舞いが明確になるとともに、新規に作成しなければならないブロック／モジュール／ユニットや、既存のものからの変更内容などが確定します。新規作成分や既存からの変更分が明確になると、必要な開発作業も確定します。最後に必要な開発作業が明確になれば、メンバーや設備などの各種リソースや要求された日程などを考慮して、時間軸上に開発作業をプロットしてスケジュールという形になるわけです。

ここで、図33の一つひとつは逐次的に確定していくのではなく、隣り合ったもの同士が相互に調整をとりながら並行して確定していくことに注意してください。たとえば、与えられた要求仕様はすべて実現できるとは限らず、製品内部（内部構造）の振る舞いを検証した結果、仕様を変えたり制限を設けたりする必要が生じる可能性があります。また、ある特定の開発作業が確保できる工数、期間、担当者では対応できないという判断になる可能性もあります。この場合は、製品内部の振る舞いを変更することができないかどうかを検討し、できない場合は仕様を見直すことになります。このように、相互に調整を繰り返しながら、最後に適切なスケジュールになるのです。

ところで、この一連の作業を実施するのがシステム設計です。システム設計という言葉は抽象的で、会社によって、組織によって、そして、人によって意味や内容に差があることが多いものですが、個人技ではなく組織的に図33に示す過程が実施できていることがシステム設計ができているということです。したがって、システム設計ができているところは、これらの４つの成果物が相互に整合性を保証されており、スケジュール上の任意の開発作業から外部仕様までが相互に追跡可能な状態になっています。