目標を管理する

キャリア

» 2008/10/28

　こんにちは。安藤大輔です。

　今回からは具体的にPMの役割について、前回のテーマに沿って進めていきたいと思います。

　前回のコラムでは、顧客にとっての目標、開発者（開発会社）にとっての目標、また関連会社の目標が絡み合って更に複雑化すると、PMにはそれぞれの関連者間の調整や目標の再設定、それに伴ってスコープ管理や要求管理が求められる、ということを述べました。

■目標とは？

　プロジェクトの目標はさまざまで、顧客のビジネスモデルに直接関わるもの（新規事業による売上向上や業務改善による原価削減など）もあれば、情報発信（企業Webサイトの構築・制作など）やわたしたちの生活に密接に関係しているもの（ライフラインの管理システムなど）などもあります。

　また、開発者側の目標、関わるメンバー個人の目標など、さまざまな目標が1つのプロジェクトの中に詰め込まれる（または関係する）こととなります。

　わたしは顧客の目標はもちろんのこと、これらすべての目標を達成して初めてプロジェクトが成功した、といえるのではないかと考えています。つまり、プロジェクトの目標（その達成）とはプロジェクトが成功するための必要条件なのではないか、と考えるようになりました。

■（PMに就く前に）頭で考えていたこと

　PMに就く前は特にプロジェクトの目標を明確に意識したことはありませんでした。それでもうまく回っていた（プロジェクトとしてはあまりうまくいっていませんでしたが……）のは、おそらくわたしが以前所属していた会社の業務プロセスがしっかりと整備されていたこともあったのではないかと思っています。

　あるいはまた与えられた仕事を淡々とこなすばかりで、プロジェクトの目標を意識する必要がそもそもなかったり、2次受託によって目標が見えなくなっていたことが考えられます。

　したがって考えていた目標といえば、自分が掲げた6カ月間目標（○○の技術を身につけるなど）や、所属部署の目標を達成する、ということくらいでした。

　そのためこのとき一般的によくいわれる目標管理の重要性についてはよく理解できていなかったのだと思います。

■実際に体験したこと

　実際にPMに就くようになって学んだことは、「プロジェクトの目標は明確にしておく」ということです。言葉にすると分かりやすく当然のことですが、わたし自身PMという立場を経験するようになってから「目標の明確性」がいかに重要かを痛感しました。

　目標が明確になっている場合と、そうでない場合で何が違うのでしょうか。明確になっている場合は、システムに求められる役割も明確になりますが、逆に明確でないと、「システムを開発することそのものが目標になる」ということに陥りがちです。

　システムを開発する、という面だけでいえば目標が明確になっていなくても（システムを開発することが目標になっていても）納品することはできますし、顧客が要求する品質（納期・コストも含めた）を守って、一見全員が満足するようにみえることもあります。

　しかし、実はこれではプロジェクトが成功したといえません。上で述べたように、プロジェクトの成功はプロジェクトの目標が達成されて初めてそうだといえるものです。「システムを開発すること＝プロジェクトの目標」という図式が本当に正しく顧客の目標を表したものであれば問題はありませんが、そうでない場合は一度しっかりと目標を定義する必要があります。　目標が明確になっていると、システムの立ち位置が明確になるため、誰がどのようにシステムを利用するか、といったことが決まりやすくなります。そのためシステムのスコープがぶれることも少ないですし、例えスコープを変更する要求が出たとしても、どのように変更したらよいか、変更しない方がよいか、ということを全員が合意の上で速やかに判断できるようになります。

　プロジェクトを開始するに当たり、まずは目標そのものを定義するところから始めなければなりませんが、特に注意すべきことは顧客の担当者が目標を理解していない（あるいはないがしろにしている）場合がある、ということです。

　実際に気がついたことは、思いつきでプロジェクトを始めているパターンが意外に多い、ということです。新規事業を始めるのだが事業計画がない（上場企業ではあり得ないと思うのですが……）、Webサイトを立てたいのだが企画がない、ということがよくあります。

　実はPMの仕事はここから始まっていて、目標は何なのか、システムが存在することによってどんな効果を見込むのか、ということを明確にする（Needsを顕在化する）ことがプロジェクト初期では非常に大切な仕事になります。　そしてこのプロジェクト目標に沿うように、プロジェクトチームの目標、各個人の目標へとブレークダウンされるように調整していきます。このような状況であれば、プロジェクトメンバーすべてが同じ方向を向いて活動することができ、高いパフォーマンスを発揮できる土壌が整うことになります。

　最後に、目標は保守する必要があるものです。プロジェクト初期の目標を明確にした段階から、プロジェクトが終了するまでに、顧客を取り巻くビジネス・マーケット・技術は変化するものです。

　これらの変化によって、顧客の要望も変化しますし、システムの実現性も変化します。場合によってはそのために目標自体を変更していく必要にも迫られます。

　こういった場合に備えて、目標管理・要求管理・スコープ管理プロセスを整えておくことが「目標を管理する」という点においてPMに求められる役割といえると思います。

■失敗したこと

　ここでわたしがPMを初めて務め、また今回記述したことを始め多くを学んだプロジェクトでの目標についての失敗談を紹介します。

　このプロジェクトは顧客（A社）と開発チーム（わたしが所属している会社）と、もう1つ、この2社の橋渡しをする会社（B社）が入っていました。つまり、わたしたちのチームは2次受託の形になっていました。

　B社のメンバーが主に初期コンサルティング、及び開発フェイズでのプロジェクトマネジメント（A社との窓口・予算管理）に責任を持ち、開発チームが実働部隊としての責任を持つことになっていました。

　開発するシステムについては、B社のメンバーが要件定義フェイズをほぼ完了しており（そのようにB社から報告を受けていました）、わたしたちはその定義された要件に従い、不足部分を補いつつ設計を進めるところからプロジェクトに参加すればよい、ということでした。

　そのような経緯及び2次受託ということもあり、特にこのシステムがA社のビジネスにどのように関わり合い、そして利益を生み出すか（このシステムはA社のビジネスモデルを実現するシステムでした）ということについては全く意識していませんでした。

　この状況でわたしたちが設計を進め、B社にレビューをしてもらいながら数カ月経ち、ひと段落したところでA社のレビューを受けることになりました。そこで待っていたのは「意図していることと全く違う」設計になっていた、ということでした。

　そのため数カ月の作業を一からやり直すことになり（というよりも要件定義からやり直すことになり）、A社にとっては納期の遅れ（機会損失）、わたしたちにとっては原価の大幅超過・システム化要件の肥大など、大変にインパクトの大きなミスにつながってしまいました。

　原因はさまざまあるのですが、最も大きなものは「目標の明確性」にあったのではないかと考えています。わたしたちにとってはB社が窓口であり、彼らしか見えず、そのため彼らのいうとおりにしていればプロジェクトの目標は問題なく達成できるはず、というように考えていました。

　実はこのとき（A社のレビューのとき）分かったのですが、プロジェクトの目標は明確になっておらず、A社のビジネスモデルも固まっているとはいい難い状況でした。そのような中で要件定義・設計を進めたため、いつの間にかシステムが独り歩きしており、気がついた時には顧客の要望を捉えきれていない状態になっていたわけです。

　その後、顧客のビジネスモデルも固まり、プロジェクトの目標も明確になり、要件定義を一から行うことでようやく顧客の要望を満たすシステムが構築できる状況に改善することができました。わたしたちはこのことを通してプロジェクトの目標を明確にすることの大切さを身をもって体験することとなりました。

■まとめ