第3回：プロジェクトの初動を乗り切る (3/4)

TOP＞キャリアアップ＞ 3. プロジェクトにおいて各人に期待される役割

要求をシステム開発に正しく反映させるには

第３回：プロジェクトの初動を乗り切る
著者：ウルシステムズ河野正幸 2006/6/2

3. プロジェクトにおいて各人に期待される役割

   どんなプロジェクトでもプロジェクトの推進体制を準備段階で検討し、事前に関係者にどのような役割を果たして欲しいのかを伝えて根回しをしているはずです。しかし、それがあまりにも漠然とした抽象的な内容だと、適切な人たちにプロジェクトに参加してもらえない可能性がありますので注意が必要です。

   例えば、システムの利用部門の業務担当者に期待する役割としては「プロジェクトに必要な業務知識を提供する」「部門の代表者として要求に関する重大な意思決定をする」「他部門や社外の関係者の調整窓口となる」など様々なものが考えられます。これらを事前にきちんと関係部門に伝えて、それらの要件を満たす人材にプロジェクトに参加してもらうことが重要です。

   また役割については、キックオフミーティングの場などでプロジェクトマネジャから参加者に伝えて協力を要請することが普通ですが、一度伝えておけば参加者の「1人ひとり」が自分に期待された役割を十分に理解して作業できると安易に考えてしまうのはかなり危険です。

   なぜなら、「意思決定に関する権限の有無」「業務知識の深さ」「プロジェクトに参加することへのモチベーション」「チーム作業に参加する上での性格上の特性」などは参加者の1人ひとりで異なるので、その人がプロジェクトに最大限に貢献できるような役割をプロジェクトマネジャーが継続的に見極めながら、それを具体的に伝えるようにしないと、なかなかこちらが期待するパフォーマンスを発揮してもらうことが難しいからです。プロジェクトマネジャーはプロジェクト期間を通じて、参加者の1人ひとりに期待する役割を具体的に伝える努力を怠ってはなりません。

   人の役割に関してプロジェクトマネジャーが留意すべきことにはもう1つあります。それは、適切な人だけでプロジェクトを運営できるように環境を整備するということです。結局のところ「適切な人が関与しない限り、プロジェクトは最初から失敗する運命にある」といえます。極論のように聞こえるかもしれませんが、筆者の経験からしても残念ながらこれが真実だと思います。先に述べた「情報認知不全」という病は別の言い方をすれば「要求の品質が悪い」ということです。そして「要求の品質が悪い」ことの最も大きな原因は、正しい要求を提供できる適切な業務担当者がプロジェクトに参加していない、あるいは要求を正しく理解して実現できる開発者がプロジェクトに参加していないことなのです。

   参加者が期待した役割を満たせるか否かは2、3回も一緒に作業をしてみればすぐにわかることですが、このような「人の問題」は政治的・感情的にデリケートな力学が働いているので具体的な対処の行動を起こすには勇気が必要です。そのため、結局有効な手を打つことができずにずるずると放置されることになりがちです。

   しかし、プロジェクトの初期段階だからこそ、不適切な人に「バスから降りてもらう（注1）」ことがやり易いと考えることもできます。プロジェクト作業に散々時間を費やしたあげく「交代してほしい」と伝えられるよりも、深入りするまえに交代を告げられた方が、いわれた本人の感情的なダメージも少ないものです。「人の問題」に起因する要求の「品質問題」が致命傷になる前に、プロジェクトマネジャーは勇気を持ってなるべくはやい段階で適切に対処しなければなりません。

※注1： J.コリンズは「ビジョナリーカンパニー2」（日経BP社）で「偉大な企業への飛躍をもたらした経営者は、（中略）まずはじめに、適切な人をバスに乗せ、不適切な人をバスから降ろし、その後にどこに向かうべきかを決めている」と述べている

4. プロジェクトのマイルストーン

   プロジェクトが長く困難な道のりを乗り越えて最終目的地にたどり着くためには、要所要所で絶対に達成すべき中間目標（マイルストーン）を設けて、それを確実に達成しながら着実に前進することが必要です。PDCAサイクルを回すということは、つまりそういうことです。

   しかし、いくらマイルストーン目標を設定しても、チームがそれを共有していない、あるいは「絶対に達成するんだ」という強い意志を持って取り組んでいない場合にはまったく意味がありません。「目標を設定するからには必ずそれを達成する」ことをチームがコミットしなければ、マイルストーン目標はそれこそ「絵に描いた餅」に過ぎなくなってしまいます。

   マイルストーン目標を真剣に達成しようという意欲をチームが失ってしまうもっとも大きな原因は、プロジェクトの初期段階で目標を達成できないという失敗の体験を重ねてしまうことです。そして、それを許容してずるずると放置してしまうと、いつの間にかチームに「負け癖」がついてしまうのです。

   プロスポーツの世界などを見てもよくわかりますが、シーズン初期に「負け癖」がついたチームが途中で復活して優勝をする確率は非常に低いといわざるを得ません。したがって、プロジェクトの初期段階ではある程度「しきいの低い」目標を設定するなどの工夫をしてチームに「勝ち癖」をつけることを優先すべきです。そのような基盤をいったん作り上げてしまえば、自然とチームは責任を持ってより高いレベルの目標をクリアするようになるものです。

5. プロジェクトの優先事項

   要求開発において、チームは様々な局面で意思決定を迫られます。このときに関係者でで共有しておくと有効なのがプロジェクトの優先事項です。プロジェクトには「機能」「品質」「スケジュール」「コスト」「リソース」などの特性がありますが、これらには「必ずこの日までにリリースしなければならない」とか「費用の上限はここまで」とかいう制約が必ず付いているものです。特に「機能」「品質」と「スケジュール」「コスト」の制約事項は対立することが多く、これらのトレードオフをいかにとるのかにチームが四苦八苦することも少なくありません。

   なぜなら、こういった制約事項は関係者の利害に影響をおよぼすので、問題が発覚してからトレードオフを探ろうとしても、全員が納得できる落としどころを見つけ出すまでにどうしても時間も労力も必要となるからです。

   そして問題が重大であればあるほど、その意思決定の結果いかんでプロジェクトの方向性が大きく左右されるので、その間のプロジェクトの進捗は全く止まってしまうことになります。

   こういった事態を回避するためには、プロジェクトの初期段階で優先事項について関係者の合意を取り付けておくことが有効です。

   例えば、先に述べた5つのプロジェクト特性のそれぞれについての制約事項を明確にして「絶対に変更できない」「多少の調整の余地がある」「調整可能」の3レベル程度の優先順位を付けておくのです。そして、複数の要因が対立した場合には、この優先順位にもとづいて公正に判断を下すことをなるべく多くの人から約束を取り付けておきます。現実には全員の合意を取り付けることはなかなか困難ですが、それでも「何かをあきらめざるを得ない状況になったら何をあきらめられることができるか？」という問いに対する心の準備ができている場合とできていない場合では、圧倒的に前者の方が意思決定のスピードが速くなることは確かです。

前のページ 1 2 3 4 次のページ

著者プロフィール
ウルシステムズ株式会社河野正幸
山口大学経済学部経済学科卒業後、SIerにて製造業向けシステム開発プロジェクトマネジャーとして従事。2002年8月から現職。得意な分野として、オブジェクト指向分析／設計、開発方法論、プロジェクトマネジメント、製造業の業務などがある。

INDEX
第3回：プロジェクトの初動を乗り切る
	プロジェクトの初動を乗り切る
	プロジェクトの全体像を共有する
	3. プロジェクトにおいて各人に期待される役割
	6. 対象業務のコンテキスト

要求をシステム開発に正しく反映させるには
第1回	要求開発とは何か？
第2回	プロジェクトを成功させる秘訣
第3回	プロジェクトの初陣を乗り切る

ITILを活用したシステム管理

ITILを使ったサービスのすすめ

IT部門のための日本版SOX法対応準備
今やらなければ間に合わないコト

ERPコンサルタントのために
第1回	負けないERP提案
第2回	ERPの導入によってBRPを提供する
第3回	負けないERP提案のコツ
第4回	コンペティタの一歩上を行く提案活動