プロセス１３：プロジェクトマネジメントノベル
レッスン１：プロジェクト立ち上げのポイントレビュー

◆ストーリーの復習

　Project1リアルタイムＯＳの開発プロジェクトは、Activty1〜5で立ち上げが完了した。いよいよ、これから計画に入る。その前に、今回は、立ち上げのポイントを復習してみよう。
　まず、簡単にストーリーを復習しておく。初芝というエレクトロニクスメーカがあり、そこで行っていたリアルタイムＯＳ　ＲＴ−ＸＰ上の事業スキルを活かして、組み込みソフトウエアの分野で新しい事業を行うベンチャー企業アステックを立ち上げた。アステックはＲＴ−ＸＰの事業に従事していた相楽が中心になって、社内ベンチャー制度を使って立ち上げたものだ。

　アステックは当面、自動車分野と、ロボット分野を狙って展開することにした。Activity1〜5はその自動車分野でのパートナーとして選んだホンダ自動車の電装メーカホンダ電子とのプロジェクトの立ち上げの様子を描いたものだ。


◆ポイント１：ステークホルダを明確にする
　プロジェクト立ち上げの最大のポイントはステークホルダを明確にすることである。ステークホルダの明確化というのはやさしいようで、実は結構難しい。このストーリーからも読み取れると思うが、

・本当のステークホルダがプロジェクトに関与しているとは限らない

・プロジェクトに参加しているメンバー（ＰＭＢＯＫ的にはこれもまた、ステークホルダである）によって、同じステークホルダとの影響関係が異なることが多い

・ステークホルダ間に関係があり、そこにプロジェクトから影響を与えようとした場合に、ステークホルダの関係が変わってしまうケースがある。

といった理由が挙げられる。これらのことを配慮し、ステークホルダの特定の際には、

・まず、プロジェクト目的から、プロジェクトとしてのスタンス（視座）を決め、そ
のスタンスで客観的にステークホルダの特定を行う

・影響力のネットワーク分析を行い、ステークホルダのクラスター図を作ってみる。
そして、そのクラスターのゲートキーパー（そのクラスターの代表になる人や組織）を特定する

といったことをやってみると比較的すっきりとすることが多い。


◆ポイント２：スコープ区分の明確化

　スコープ定義は本来計画プロセスでのマネジメント作業である。しかし、プロジェクトの目的は必ずしもオペレーショナルな目的であるとは限らない。従来から、研究開発のように目的探求と称されるプロジェクトタイプがあるが、これはオペレーショナルなレベルで考えられば目的を探していることになるが、プロジェクトそのものの目的を探しているわけではない。プロジェクトの目的はたとえば、「今後、１０年間、競合に対して優位性の保てるセンシング技術を３年以内に開発する」といった目的があるのだ。

　つまり、プロジェクトにはビジネス上の目的があり、その中で、オペレーショナルな目的が設定されると考えた方がわかりやすい。これは、プログラムと呼ばれることがある。

　最近では、研究開発に限らず、プログラム的な取り組みが重要になってきている。製品開発や経営革新、組織変革といった分野では従来からプログラムとして取り組むのが普通であるが、最近では、システム開発のような分野でもそのような取り組みが目立つようになってきた。

　原因はライフサイクルの短期化にあり、大きな計画を作るリスクが大きくなりすぎ、プログラムとして全体のコンセプトやビジョン、あるいは目的を決定し、その目的に向かってプロジェクトとして実行する内容を変えていくというやり方である。

　このような進め方をしようとした場合には、プロジェクト承認前にスコープを明確にして必要がある。スコープを明確にしないままでプロジェクトに取り組むと、収集がつかなくなるからだ。これは従来の言葉で言えば、スコープというより、制約条件、前提条件に近いものである。


◆ポイント３：ビジネスリスクとオペレーショナルリスクを区別する

　スコープと同様にプロジェクトのリスクにはオペレーショナルなリスク以外に、ビジネスリスクがある。今回のストーリーでいえば、たとえば、山口が当初心配していたＲＴ−ＸＰというＯＳを導入に対して、今までビジネスに対して主導権を持っていたアプリケーション部隊が主導権を奪われるのではないかという危機感を持ち、反発が起こり、プロジェクトがストップするのではないかというのはビジネスリスクである。これに対して、ＲＴ−ＸＰでは十分なアプリケーションのパフォーマンスが出ないのではないかというのはオペレーショナルなリスクである。

　リスクの想定をする場合には、まず、この２つのリスクを明確に分けることが肝心である。そのためには、リスク想定のフレームをよく考えてみる必要がある。たとえば、よくリスク想定のフレームワークとして、「技術」、「コスト」、「スケジュール」というフレームが使われる。このフレームはオペレーショナルなリスクを洗い出すためのフレームであり、たいていの場合、ＭＥＣＥなフレームになっている。しかし、ビジネスリスクにはあまり向かない。たとえば、プロジェクトの目的に対して、ＳＷＯＴ分析をかけるといった方が現実的である。

　立ち上げのときには、あまり、オペレーショナルなリスクは議論しないほうがよい。オペレーショナルなリスクは、計画に対して相対的に決まるものであり、あまり、立ち上げで考えておく意味はない。ビジネスリスクを中心に行うことが肝要である。


◆ポイント４：主要ステークホルダがプロセスを共有する

　このストーリーの状況は、プロジェクトとしては今後どのように進むかわからないと考えた方がよいような状況である。この状況では、ステークホルダ同士は綱引き状態にあるのが普通であり、何かを共有するというのは難しい。

　この状況で可能な共有は、プロセスを共有することである。今のプロジェクトマネジメントは米国のビジネス文化が根底にあり、また、相当大規模な仕事を通常では考えられないような期間で行うということが存在意義になっている。これが顕著に現れているのがガバナンスの問題である。

　簡単に言えば、プロジェクトの上位組織がすべてのガバナンスを持ち、それをプロジェクトに権限委譲している。その限りで、プロジェクトメンバーはプロジェクト組織の中では指揮命令系統を持っており、プロジェクトチームもその指揮命令系統の中にメンバーを加えていくことにより、出来上がり、あとは、モチベーションとリテンションを繰り返し、チームのパフォーマンスを上げていくというマネジメントになっている。

　ところが、このマインドシップは日本人のメンタリティには合わない。日本人のメンタリティとしては、構築プロセスを大切にする。ここを間違うとプロジェクトはまず、成功しない。

　このことはルールを明確にした形式的なマネジメントを行わないということではない。ルールをみんなできめ、明文化していくのだ。日本人はルールを決めることは苦手だと思っている人が多いが、そんなことはない。ルールを決めるスキルは米国人より高いと思う。そのよい例が「村の掟」である。「村の掟」というとビジネスでは「護送船団方式」という言葉がついて周り、ネガティブに聞こえるが、これは自立的に決められたルールである。このような遺伝子があるので、ルールを決めるプロセスを共有すると、非常に高いコミットメントを引き出すことができるのだ。


◆ポイント５：会議では対立点を指摘し、共通点を発見していく

　今回のストーリーの立ち上げフェーズでは、会議の中で出てくるさまざまな問題が明確な答えがないものが多い。このような場合には、だれもが確実とは思わない落とし処で合意形成をすることが必要になる。

　このためには、プロジェクトマネージャーがファシリテータになり、共通点を紡いでいくような会議の運営が求められる。

　以上の５点が立ち上げフェーズでのプロジェクトマネジメントのポイントである。もう一度、この点を意識しながら、ストーリーを読んでみてほしい。新たな発見があるかもしれない。

　次回からはまた、ストーリーに戻り、具体的な計画の策定に入っていく。

　
　（２００４．７．８号より）
購入はこちらまぐプレバナー