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

数多くのステークホルダーから多様な要求が寄せられる大規模プロジェクトでは、プロジェクトマネージャを支援する仕組みが不可欠だ。その具体的な方法を提唱する。

[岩本康弘，＠IT]

　第1回では、ITプロジェクトの厳しい情勢と、ユーザー主導型プロジェクトマネジメントの可能性について考察しました。今回は、プロジェクトマネージャ（PM）に任命されたユーザーPMが最初に直面する“体制作り”について考えてみたいと思います。

プロジェクト遂行のための機能的な体制

　さて、PMのミッションは極めて単純です。「計画されたスケジュールとコストを守りながら、品質要求を満たすシステムを構築する」ことです。ちなみにPMBOKでは、品質は制約三条件であるスコープ、タイム、コストのバランスを取ることによって決まる──と述べられています。

図1　プロジェクトの制約三条件──プロジェクトでは、トレードオフ関係にある「スコープ」「タイム」「コスト」のバランスを取る必要がある

　しかし、多様なステークホルダーが思い描いている抽象的なイメージを、スキルと経験が未知数のメンバーを中心とした開発体制で、予算枠に収めながら具現化するという仕事はそう容易なものではありません。

　各ステークホルダーの要求が不鮮明なのは仕方ないことですが、近年のITプロジェクトは要求そのものが従来よりも複雑化しており、スコープを明確にすることがますます難しくなっています。また、テクノロジのオープン化・マルチベンダ化など、適材適所や取捨選択の思想と反して、システム構築手法は従来以上に高度化しています。開発プロセスも、ウォーターフォールのように上から下への一方通行で工程の逆戻りは許容しない、というのは通用しません。開発途中の要求の変化や拡張はあって当然です。つまり、ある程度手戻りを想定して開発を進めなければなりません。

　わたしが以前在籍していた某金融機関でも、複数チームでの並行開発により極めてスピーディなリリースを実現していながらも、デグレードリスクと常に背中合わせでした。しかし、こういったギリギリの状況でもリリース直前まで要求の変化に対応することを求められていました。競争の激しい昨今、このような困難なプロジェクト運営を求められるのは必然であり、ユーザーとしては機能的なプロジェクト推進体制を整えることが必要になります。

　では、“機能的な体制”について考えてみましょう。

　プロジェクトの遂行にはPMの的確な判断と迅速な意思決定が必要です。そして、そのためにはスピーディな情報収集と分析、根拠に基づいた方向付けなどの能力が必要ですが、膨大かつ複雑な情報をPM単独でさばくのはまず不可能です。プロジェクトを成功させるには、PMを支援する相応の体制が必要なのです。わたしは、そのためのPM支援組織をプロジェクトの制御を担うという意味で、“プロジェクトコントロールチーム”と称しています。そして、ユーザー主導型プロジェクトマネジメントの遂行には、このPMを支援するプロジェクトコントロールチームが極めて有効だと考えています。

プロジェクトコントロールチームの構成

　では、プロジェクトコントロールチームの構成とはどのようなものが考えられるのか、例を示していきましょう。プロジェクトコントロールチームは下記の役割を持った少数のメンバーで構成します。

図2　プロジェクトコントロールチームの構成

　1人が複数の役割を担うことも可能ですが、プロジェクトコントロールチームのスコープには「あちらを立てれば、こちらが立たず」の二律相反関係が含まれており、けん制機能を働かせる意味でも兼任には注意が必要です。また、これらの担当者はプロジェクト期間中、ベンダを含む開発メンバー全員のコントロールを担うため、担当スコープについての相応の知識と同時に、コミュニケーション能力が必要になります。

A：要求管理担当

　プロジェクトにはさまざまなステークホルダーが存在するため、要求を一元的に管理しなければ混乱を招くことになります。また、上流フェイズですべての要求を網羅できればよいのですが、一般的には後工程で新たな要求や変更が少なからず発生するものです。このような場合、各要求を安易に受容したり、むげに拒否したりするのは避け、要求の妥当性や一貫性、矛盾点などを踏まえ、開発への影響や制約を十分考慮したうえで対応可否を検討する必要があります。このように要求管理担当は、プロジェクト期間中を通して要求事項全般を取りまとめることに専念します。

B：方式管理担当

　方式管理担当は技術面の統制を担いますが、そのポイントは“ポリシー”と“標準”の策定および運用です。ポリシーはアーキテクチャや言語、開発ツールの選択基準や、SLAの基準などを指します。標準は、コーディング規約や実装ガイドラインなどを指します。

　通常、開発ベンダは独自の規定や得意とする技術を保有しているため、ユーザーから特に指定がない場合は、プロジェクトにベンダプロセスが適用され、ベンダ依存性が高まるリスクが大きくなります。そのためユーザー側で規定を作成し、プロジェクトへ適用することで、品質の均一化や保守性の向上を図ることになります。

　また、生産性や品質ベースラインを策定し、評価、改善を繰り返すPDCAサイクルに乗せる運用なども効果的です。このように方式管理担当には、設計、実装、保守に関する広範な知識が要求されると共に、チームへの啓蒙といった草の根的な活動が求められます。

C：データベース管理担当（DBA）

　大規模システムやミッションクリティカル・システムの場合、DBAの設置は必須です。DBAの主な役割は、DB関連の標準化とガイドラインの策定、運用などが挙げられます。

　RDBに代表されるDBMSは、テーブル以外にもシーケンスやプロシージャ、トリガなどさまざまなDBオブジェクトを作成することができますが、明確にガイドラインを設けていない場合、品質や保守性の低下を招く恐れがあります。

　また、データベースで発生する問題は、傾向的にクリティカルなものが多いため、特に厳格な管理が必要になります。例えば、挿入・更新・参照などが極端に多いテーブルに対するINDEXの適用評価や、パーティショニングなどのチューニング支援、運用引き渡し前のDML、DDL、DCLの一元管理といった、開発現場でのデータベース関連事項全般を担います。