PMを支援するプロジェクトコントロールチーム：実践 ユーザー主導型プロジェクトマネジメント（2）（2/2 ページ）

[岩本康弘，＠IT]

D：標準化担当

　前述した方式管理担当のスコープは“要素技術の標準化”ですが、標準化担当のスコープは主にドキュメントや管理簿などの成果物になります。通常は開発ベンダに提示する納品ドキュメント一覧や、必要に応じて工程ごとに作成すべきドキュメント規定などを行います。できれば開発チーム間で記述レベルを統一するために、目次の大分類程度は規定すべきでしょう。なお、ドキュメント規定のポイントは「利用目的と対象読者の属性を考慮すること」と「必要最小限にとどめること」です。

　以前、ドキュメント専属チームを設置しているベンダが電話帳ほどもあるドキュメントを仕上げ、得意満面にレビューを求めてきたことがありました。当然、読み合わせで丸1日を要しましたが、押さえるべきポイントは数枚程度でした。このような作業は極めて非効率であり、重要事項を要約した文書を準備するなどして効率的なレビューを遂行する工夫があってしかるべきです。

　このように、標準化担当はさまざまな視点でドキュメントの統制を目的とした規定作りを行います。

E：構成管理担当

　構成管理担当は、マスタドキュメントやソースコードなどの、オフィシャルな成果物を統合的に管理する仕組みを提供、運営します。

　例えば、cvsやsubVersionなどのリポジトリ管理ツールを利用して、開発チームのリリース成果物を統合的に管理します。また、開発チーム間で作業するソースコードやドキュメントに競合が発生した場合の調整およびリリースソースの抜き出しや、リリースチームへの受け渡しなどの管理も行います。大規模プロジェクトなどにおけるマルチベンダ体制や、複数の案件が並行して推進されている場合は、専任の管理者が存在しないことで管理が非常に煩雑になり、デグレードを発生させるリスクが高くなります。

F：品質管理担当（QCA）

　品質管理担当は、単体テスト・結合テスト・総合テストなど試験工程や、UT・PT・CT・IT・ST……といった名称の定義、各試験工程のスコープ、成果物、評価基準などを定義します。また、それぞれの試験工程におけるバグ検出目標の設定や、バグ収束状況のレビューなどを適宜行います。

　ここで注意すべきことは「品質評価の基準は一意に定まらないものである」ということです。例えば、C言語やJava、jsp、PL/SQLなど、アーキテクチャに即したバグ検出目標や、クリティカルレベルなどを踏まえた評価基準などの考慮が必要です。さらに要件や仕様の不備、設計バグ、プログラムバグといった品質低下の要因を分析し、改善につなげることになります。

プロジェクトコントロールチームを機能させる

　では、この体制をどのように機能させるのか考えてみましょう。プロジェクトコントロールチームのメンバーはPMがスケジュール遅延やコスト超過を把握し、適切な意思決定ができるよう、おのおのが自身の範疇でプロジェクト内の情報収集、分析を行います。そして、得た情報をチーム内で共有し、制約三条件に影響するような問題についてはチームとして方向性を検討しPMの意思決定につなげることになります。

［1］ − 情報収集、分析

　プロジェクトコントロールチームのメンバーは、自身のスコープに関する情報収集や改善に主体的に取り組みます。例えば、関係者との定例会などを通して状況の把握や指示を行います。自身で解決できない問題や、スコープやスケジュール、コストといった制約三条件に影響する可能性のある問題が発生した場合、プロジェクトコントロールチームの定例会にエスカレーションし、チームメンバーで方向性を検討します。

［2］ − 方向付け

　プロジェクトコントロールチームの定例ミーティングで、［1］で生じた問題についての方向性を検討します。

　例えば、要求管理担当者から、ユーザー要求の変化が起案されたとします。少なくとも制約三条件への影響や、方式や品質といった他要素への影響などが予想される場合には、プロジェクトコントロールチームのミーティングに付議するのが望ましいでしょう。チームの担当者間で協議し、最終的にユーザーPMがプロジェクトの公式な方針として意思決定します。なお、当然ですが、スケジュール遅延や予算超過が生じてしまう場合には、ステアリングコミッティなどの上位機関に付議する必要があります。

［3］ − 展開

　プロジェクトコントロールチームで協議した結果をプロジェクトに展開する場合、ステークホルダーに対する交渉が必要になるケースがあります。前項の例では、ユーザー要求の変化により、開発スコープが拡大し、開発工程や品質への影響などが予想されます。プロジェクトコントロールチームでは、開発リソースの状況などを勘案して協議した結果、仕様取り込みの判断に至った後に、開発ベンダへの交渉や、ユーザーとのスケジュール調整、品質維持の対策などの手順を踏み、正式にプロジェクトへ展開することになります。

図3　プロジェクトコントロールチームの機能イメージ

　さて、今回はユーザー主導型プロジェクトの体制について考察してみました。PMを支援するプロジェクトコントロールチームには経営陣や上層部の理解、適任者の確保、教育などさまざまな課題がありますが、最も重要なのはPMの意識です。

　長く険しいプロジェクトを成功に導くためにはチームの連携プレーが必要です。ユーザーPMは独り善がりにならず、チームメンバーとの信頼関係を築き、何事もチームで解決するという意識を持って振る舞うことが必要です。

筆者プロフィール

岩本 康弘（いわもと やすひろ）

大学卒業後、プログラマからアーキテクトの道を歩み、エンジニアリング系や医療系、銀行系など多岐の分野にわたる分野のシステム構築に携わる。昨年まで某金融機関のシステム部門に在籍し、プロジェクトマネージャ兼アーキテクトとしてインターネットバンキングシステムの構築に従事。直近では基幹系システムの全面刷新プロジェクト（数千人月規模）を担当。EJBベースからPOJOベースへのマイグレーションに取り組み成功を収めている。

「実践 ユーザー主導型プロジェクトマネジメント」バックナンバー

• PMを支援するプロジェクトコントロールチーム
• ユーザー主導型プロジェクトマネジメントのススメ