目次
「イノベーション創造型」のプロマネとは？
本物のプロマネ」七つの条件
日経SYSTEMSの最新号（2016年2月号）の特集は「迫られるスキル変革」。
日経さんのタイムリーなテーマ選定にはいつもながら感心しつつ目次を見ると“「本物のプロマネ」七つの条件”（特集２）があった。
その記事の冒頭で３Ｋは「きつい・厳しい・帰れない」ではなく「感謝・感動・感激」だという言葉に私の期待は多いに膨らんだ。
しかし残念ながら８頁にわたる記事を読んでみると結局PMBOKから始まったモダンＰＭの話が中心。 勿論PMBOKの勘どころを軽くおさらいしたいなら読んでみる価値はあるが「スキル変革」「本物のプロマネ」というテーマから推測される内容とはちょっとかけ離れていたようだ。
最終頁で「今後はイノベーション創造型プロマネが重要になってくるだろう」とあったので「いよいよプロマネ4.0か？」とこれにも期待が膨らんだが、抽象的ななことしか書いてなかった為、結局中身はよくわからなかった。
そこで私なりに「イノベーション創造型プロマネ」を何回かに分けて深堀していきたいと思う。
私とプロマネの出合い
私が初めてプロマネになったのは大手精密機械メーカに入社して３年目の1983年。それ以降PMO、PFM、PPMを含めてプロジェクトマネジメント業務を30年以上やっている。
初めて体験したのは300人月/18か月の新規ソフトウエア開発プロジェクトだった。 当時はプロジェクトマネジャという言葉はなくソフトリーダなどと呼ばれていたが、とにかく無我夢中でやっていたらヨロヨロしながらもなんとか開発を終了させた。 当時はまだソフト屋が少なかったこともありそれ以降、新規開発プロジェクトが立ち上がるたびにプロマネをやらされる羽目に。 そして何回か修羅場を経験し10年ほどたつとようやくQCDを回せるようになった。 そして少しは自信がついてきたところでPMBOKが世の中に出てきたのだ。 私は早速読んでみたがその時の印象は以下のようなものだった。
- これをもっと早く読んでいたらあんなに苦労することはなかったのに
- こんな知識だけではプロジェクトはとても回せない
そうPMBOKはその名の通りプロジェクトマネジメントに関する知識体系、例えていうと準備運動にはなるがそれですぐに42kmのマラソンを走れるわけではないのだ。
ミッションとしてのプロジェクトマネジメント
イノベーションコンサルティングパートナー
私は特にモノ創り企業を対象に「イノベーションによる高付加価値経営を目指す経営者をパートナー（参謀）としてサポートする」ことをミッションにした経営コンサルタントだ。
2015年問題がなし崩し的に後ろにずれこむ中でオリパラが開催される2020年まではソフト産業の需給ひっ迫は続くかもしれないが、それ以降まで見据えるとなると単なる人月商売ではやっていけないとみるのが妥当だろう。 今のうちに自社ならではのオリジナルのサービス、あるいは他社に負けない強みを持ったサービス等、広義の高付加価値経営の基盤を仕込んでいく必要がある。
そのため私のミッションとしては経営者のパートナーとして
- ビジョンを明確にして社員に周知徹底する
- 洗練されたもの創り手法の導入（日経Systemsの「イノベーション創造型プロマネ」）
- 組織の成熟度の向上
以下順番に説明していく。
1. ビジョンを明確にして社員に周知徹底する
私のほうからイノベーションの方向性や技術予測を提供し、経営者とは自社の強みを更に強化できそうなテーマを一緒に検討し（場合によっては幹部を含め社員にも参加してもらう） 自分たちが目指す理想の姿を決めてもらう（これは経営者にしかでいない業務です）。 それをビジョンとして明確にしてそれを言葉にする（※１）。それを実現するための中期計画、単年度の事業計画（あるいは新規プロジェクトの目的、狙い、効果など）を作成してもらい全従業員に周知徹底させる。 どこまで従業員に浸透しているか、不安感はないか等が気になる経営者には必要に応じて第三者という立場から従業員と率直な意見交換を行うこともある。
-
（※１）何故言葉にするのか？ ブライアントレーシーによると「目標と行動計画を紙に書けば、それらを達成する可能性が10倍にも跳ね上がる」らしい。
2. 洗練されたもの創り手法の導入（「イノベーション創造型プロマネ」）
イノベーションを起こせる高付加価値経営を支えるようなプロマネ、それが日経SYSTEMSの記事で語ろうとしていた「イノベーション創造型プロマネ」ではないだろうか？
イノベーションというからには新規プロジェクトが多くなるだろう。 それを成功に導くプロジェクトマネジメントで最も大事なのは「複雑性の低減」。
よく「最近のプロジェクトは次第に複雑になっているので・・・」等の理由でプログラムマネジメント（PGM）やステアリングコミッティを設置して大掛かりな体制を作りますます自分の首を絞めていくという残念な事例を散見する。 そうではなくプロジェクトが単純化するまでプロトタイプを繰り返す。 PMBOK風にいうとWBSの中で数日単位のワークパッケージが全スコープで明確になるまで「試作して検証」し続けるのだ。（そのため新規開発にローリングウエーブ法は推奨してない）
その後は通常のウォータフォール開発に戻して業務を行っていく。 すなわちタイムマネジメントを行いCPM、EVMを駆使して推進していくのだ。 ただし途中で仕様や機能が変わる可能性がある場合、あるいは途中で変更を許容したい場合はアジャイル型開発（スクラムを推奨）を選択すればよいだろう。
スクラムに関しては別途説明させてもらうが、ウォータフォール開発とざっくりと比較すると
- スプリントの導入により多少の冗長性を持たせて変化に対応しやすいプロセスにする。
- スコープを決めてからリソース、期日が決まるのではなく定められたリソースと期日からスコープを決定していく。
- 実現するスコープは最も優先順位の高いものから行う。
面白いのはスクラムを開発プロセスに選定してもプロジェクト憲章がインセプションデッキに相当し、EVMがバーンダウンチャートになり、WBSがプロダクトバックログやユーザストーリマッピングにかわるが、PMBOKの基本的な考え方はそのまま生きるということだ。
開発手法としてはTDDなどのテストファーストやペアプログラミングが結果的に導入しやすくなる、あるいは導入せざるを得なくなるとも言える。 これらはウォータフォールでは日程、コスト上の問題から導入が難しかったはずだ。
このあたりのこともおいおい解説していきたい。
3. 組織の成熟度の向上
大規模な開発プロジェクトになると組織の成熟度が相応のレベルになっていることが成功の条件となる。 逆に言うといくら優秀なプロジェクトマネジャや開発メンバーをそろえても組織の成熟度が低いと失敗するケースが多い。 この傾向はプロジェクトが大規模になるほど相関が高くなる。 全く同じことがいえるのがオフショア開発だ。 「コストダウンのためにオフショア開発だ」と決める前に開発組織の成熟度を見直してみてはどうだろうか？ 下図は成熟度の類型をITコーディネータプロセスから抜粋したものだが、レベルの評価はどれも似たり寄ったりなのでCMM,CMMIを参考にすればよいだろう。
成熟度の比較
最後に
プロジェクトマネジメントシリーズの第一回目の投稿は日経Systemsの記事の特集２の“「本物のプロマネ」七つの条件”を取り上げ、そこで示唆されている「イノベーション創造型プロマネ」というものの実態を今後の投稿で模索していきたい。 一方で経営者の視点からどのように組織の成熟度を上げ、開発プロジェクトをQCDの観点からより正確に査定するにはどうすればよいかなどをこれまでの数百プロジェクトの査定経験を踏まえて解説していきたい。
2016年2月20日
