「自分がチャレンジする予定のプロジェクトでは、ゴール到達から成功失敗の判断まで半年かかることになっていますが、このような目標設定は適当ですか？」 今回は、この質問を取り上げよう。例によって、大学でプロジェクト・マネジメントの講義をしていた時、学生から出てきた問いである。そして、とても良い質問だ。 このときの講義のテーマは、「ミッション・プロファイリング」だった。この用語は、PMBOK Guideには出てこないので、なじみのない読者も多いかとは思う。プロジェクトにおけるミッション、すなわち使命を、その目的・ゴール及び目標（＝成功基準）などの観点から、分析・定義し文章化する作業である。その結果がプロジェクト・チャーターになる。 授業では特に目標設定の大切さを学生に教え、修士論文や就活を題材に、プロジェクトとしての目標を考える、簡単な演習を入れている。さらに、自分がこれから将来関わるであろうプロジェクトの内容を考えて、そのゴール・目的・目標を、簡単なプロジェクト・チャーターの形に書かせている。上記の質問は、その中から出てきたものだ。 この学生はどうやら、新しい技術を使った製品開発のプロジェクトにチャレンジしようと考えているらしい。プロジェクトがゴールに到達し、すなわち製品が無事に開発完了しても、それが本当に世の中に受けられるかどうか、売れて経済的にペイするかどうかは、その後半年ぐらいしないとわからない。そういう状況下で、プロジェクトの成功基準は、どのように考えるべきか? この質問を見て、私は3月に日経ビジネスオンラインが発表した、あるITプロジェクトの調査結果を思い出した。 「プロジェクト失敗の理由、15年前から変わらず」 http://business.nikkeibp.co.jp/atcl/opinion/15/100753/030700005/?P=1 という記事で、著者は日経コンピュータの元編集長・谷島宣之氏である。サブタイトルに、「1745事例を調査、成功率は52.8％」とある。簡潔ながら要点をついた、良い記事であると思うので、読まれることをお勧めする。 この記事によると、日経コンピュータ誌が2003年に行った第一回の調査や、その後、数年おきに行われた調査結果から見て、日本では明確にITプロジェクトの成功率が上がってきていると言う。それ自体はとても重要で、良いニュースだ。「成功率が上がった理由の一つはプロジェクトにおける定量管理の普及だ」と記事は書いている。また、「失敗理由の筆頭はシステムの『要件定義が不十分』」というのも、うなづける内容である。 ところで、この記事における「プロジェクトの成功」とは一体どのように定義されているのだろうか? それは、「品質、コスト、納期の3点を順守できたか」である。品質をスコープに読み替えると、つまり『鉄の三角形』を守ることができたか、と問うている訳だ。 実は、この日経コンピュータ誌と同様な調査を、米国ではStandish Groupという調査会社が'90年代から継続的に行ってきた。1994年以来、3年おきに発表された調査レポートでも、プロジェクトの成功率が問われ、そして徐々にあがってきている。それはプロジェクト・マネジメントの普及による成果だと解釈されている。ちなみに、Standish Group の定義は次のようになっている。 Successful: completed on time, on budget, with all specified features. Challenged: completed and operational, but over-budget, over time and with fewer features than specified. Failed: the project is cancelled before completion or never implemented. すなわち、品質・コスト・納期を計画通り満足して終わった「成功プロジェクト」と、完了したが 3 大制約条件を満たせなかった「困難なプロジェクト」、そして中断終了した「失敗プロジェクト」のクラスがある。2003年の調査では、成功プロジェクトの比率は34%だった。同じ2003年の日経コンピュータ誌調査では、日本の成功率は約27%だったから、日本は米国の後を追いかけている訳だ。 それはともかく、ここで問題にしたいのは、プロジェクトの成功を、コスト・品質・スケジュールの3点で定義していいのかということだ。それはいわば、プロマネ視点から見た成功、と言うことに過ぎない。鉄の三角形と言う大きな制約条件を満たした。それ自体は立派なことだ。だがプロジェクトとは、その成果物が価値を生み出して、初めて意義があるのではないか。 どんなに立派なシステムを開発しても、ユーザがちっとも使ってくれなかった。そういう事例は、しばしば起きる。立派な地方空港を建設したが、閑古鳥が鳴いている事例もある。「仏作って魂入れず」とは、まさにこのような状況だ。 プロマネの視点から見た、プロジェクト・マネジメントの成功だけで、プロジェクトの出来不出来を判断していいのか？ ここが問われている。新製品の完成後、世に受け入れられるかどうかは、半年ぐらい経ってみないとわからない、という最初の学生の質問は、まさにこの点をついているのだ。 そこで必要となるのが、アウトプットとアウトカムの区別である。アウトプットとは、プロジェクトが直接生み出す成果物である。それは情報システムだったり、橋だったり地方空港だったりする。 では、アウトカムとは何か? それはプロジェクトの成果物を活用することでもたらされる、変化である。情報システムで生み出される、新しい業務プロセスかもしれない。橋がかけられたことで生じる、地域交通の活性化かもしれない。地方空港のもたらす、新しい経済効果かもしれない。  図を見て欲しい。プロジェクトとは、インプットとして資機材等何らかのマテリアル、そして情報を受け取って、何らかのアウトプット=成果物を生み出す活動である。プロジェクト起動のトリガーとなるのは、何らかのオーダーなり受注であろう。プロジェクトを遂行するには、人々あるいは道具といったリソースが必要である。また、様々な要求事項や制約条件もあろう。途中段階や最後でのレポートも必要だろう。 アウトプットを生み出せば、プロジェクト自体は完了する。しかしビジネスとしては、その先に大事なステップがある。それは成果物を活用して、アウトカムを生み出すことだ。 このような構造を考えると、プロジェクトにはざっくりいって、2種類の成功があると考えられる。それは短期的成功と長期的成功だ。 プロジェクトの短期的成功とは、効率よくアウトプットを生み出すことである。プロマネ視点での成功といってもいい。これに対し、長期的成功とは、プロジェクトが価値あるアウトカムをもたらすことである。 英語ではよく、"do things right" と "do right things"という言い方で、この2つを区別する。Do things rightとは、ものごとを正しく（上手に）やること。Do right thingsとは、正しい（良い）ものごとを行うことを意味する。効率よく上手にやることが大切だが、価値あるものを作り出すことの方が、もっと重要だ。 これに関連して、KPIとKGIという言葉もあげておこう。KPI（Key Performance Indicator）とは、いうまでもないが、仕事のパフォーマンスを測るための主要なモノサシである。企業活動全体なら、売上高とか利益だとか総資本回転率といった尺度だ。何かをマネジメントしたかったら、対象を計測して数値化し、それを計画や過去の類似実績や標準値と比較し、改善活動を促していく。これが定石である。プロジェクト・マネジメントの場合ならば、進捗率だとか総工期などがあげられる。EVMS（Earned Value Management System）の中にも、CPI（Cost Performance Index）とかSPI（Schedule Performance Index）などの尺度が内蔵されているのは、ご存じの通りだ。 KGI（Key Goal Indicator）という言葉は、最近になってマーケティング、とくにWebマーケティングの分野で耳にするようになった。KPIが、途中のプロセスのパフォーマンスを表すのに対して、KGIはゴール＝結果の（たとえば顧客の購買率などの）よしあしを直接示す、という風に使われる。 もしこれを、KPIはアウトプットに関するモノサシで、KGIはアウトカムに関する尺度だ、と解釈できるなら、上に述べた説明とちょうど合致する。ただ、KGIはそれを支える複数のKPIのツリー状になっている、という解説も見受けられるので、必ずしもそうもいいきれない。まあ、Webマーケティングとプロジェクト・マネジメントという異なる分野での概念なので、違っていても当然かも知れないが。 いずれにしても大事なことは、プロジェクトの成功・不成功は、そのプロジェクトが完了した時点だけでは必ずしも決まらない、と認識することだ。あるいは、プロジェクトの価値は、そのプロジェクトだけを見ていても定まらない、と言いかえても良い。もしもその「プロジェクト」が、単にアウトプットを出すまでの射程距離を指すのなら、ということだが。そしてプロジェクトの成功を本気で心配するならば、「プロジェクト後」をケアしなければならない訳だ。だから、「ユニークな製品、サービスあるいは所産」を創造するまでをプロジェクトの範囲と考えると、プロジェクトの価値論はそこから抜け落ちてしまうことになる。 仏を作って魂を込めたいならば、プロジェクト後のアウトカムの活用まで面倒見なければならない。また、活用しやすいアウトプットの要件を、最初に定義し設計することからはじめなければいけない。ここが肝要なのだ。「与えられた要件とSOWから、コスト・納期・品質の制約内で、成果物を効率よく生み出す」ことがプロジェクト・マネージャーのスコープだとすると、魂を入れる仕事は、その外側、ないし上位にある。 プロマネの上位にあって、プロジェクトの価値を本当に作り上げるのは、じつは『プログラム・マネジメント』の仕事である。プロジェクトを起動し、プロマネを任命し、途中途中でプロマネを助け、評価し、成果物を受け取り、それを元に組織能力を変えていくのも、プログラム・マネジメントの仕事だ。完成しても価値を生まない、意味の無いアウトプットを作ろうとしている問題プロジェクトに中止を命ずるのも、プログラム・マネジメントだ。 そういう意味で、わたしたちの社会で本当に足りていないのは、プログラム・マネジメントの方なのである。そこの欠落を、プロジェクトのレベルで何とか解決しようともがいているプロマネが、あまりにも多い。それはとくに、要件定義から成果物構築までの段階を、ほとんどすべて外部にアウトソースしてしまう、IT分野に著しい傾向なのかも知れぬ。 多くの人は、「プログラム」とは同時に複数のプロジェクトを束ねたものだ、と理解しているようだ（米国PMIの定義）。しかし、わたしは、たとえ単一プロジェクトでも、プログラム・マネジメントは成立するし、必要だと考えている。プログラムとは、組織が新しい能力を獲得して成長するために行う活動の仕組みである（英国MSPの定義）。つまり、組織としての成長への経路を、一歩一歩進んでいくのが、プログラム・マネジメントだ。だから、もしもプログラム・マネジメントを日本語で強引に表すなら、『成長行程管理』という言葉が適切かも知れないと、夢想するのだ。あるいは、『戦略行程管理』の方が受けるかな？ ＜関連エントリ＞ →「プロジェクトにとって成功とは何か ～ESC Lille PM Seminarより」 https://brevis.exblog.jp/8567708/ （2008-09-05） ・・10年も前の記事ですが、今回の話の原点は、ここにあります。
by Tomoichi_Sato
| 2018-05-07 23:21
| プロジェクト・マネジメント
|
Comments(0)
|
検索
カテゴリ
著書・姉妹サイト
私のプロフィル My Profile
【著書】 「世界を動かすプロジェクトマネジメントの教科書  」「時間管理術 」(日経文庫)「BOM/部品表入門 (図解でわかる生産の実務) 」「リスク確率に基づくプロジェクト・マネジメントの研究 」【姉妹サイト】 マネジメントのテクノロジーを考える Tweet: tomoichi_sato 以前の記事
最新のコメント
最新のトラックバック
フォロー中のブログ
ブログパーツ
ファン
記事ランキング
ブログジャンル
画像一覧
|
