第29回プログラムマネジメント（後編）

オペレーションプログラム

オペレーションプログラムの事例として、オムロン株式会社が実施したパスネットプラグラムを紹介する。このプロジェクトは1999年1月～2000年10月までの1年10ケ月のプロジェクトで、関東鉄道事業者20社とメーカ5社が関係する共通運賃システム構築の一大プロジェクトで、オムロンが幹事会社として全体を取り仕切る複雑なプロジェクトであった。現在ではスイカなどの共通運賃システムは普通となっているが、当時は国内に参考となる事例もなく未知のプロジェクトであった。複数の駅務用の機器開発、複数の鉄道会社向けシステムの構築、新駅の追加によるシステム改変、20社の共通運賃のシステム化、さらには2000年問題への対応と様々なテーマ（プロジェクト）が存在し、全部で600テーマを1年10ケ月でやりきるという超難易度の高いプロジェクトであった。当初より、全テーマを実施するには人員が決定的に不足し開発プロジェクトがボトルネックになることはわかっていた。
そこでオムロンは、これらの600テーマを別々に扱わずプログラムの概念を取り入れ、全体の開発工数の削減とともに、パスネットプログラム内での共通化をできる限り推し進め品質を担保できる体制を整え実施した。
一つは、共通仕様をパスネットプログラムとして要件定義の前に作成し、その共通仕様をベースに鉄道事業者と交渉し、なるべく仕様からの逸脱する要求を抑え込んで開発ボリュームを極力低減する施策をとった。
もう一つは、社内・協力会社の開発メンバーを一か所に集めプログラムチームとして、縦軸に機器担当グループ、横軸に顧客向けプロジェクトを担うマトリクス体制を整え、その全体調整にPMOを組織化し、プログラム組織として開発効率化ができる体制を整備しス進めていった。　バラバラの600ものプロジェクトをプログラムという単位で扱うことで、プログラム内での作業量の削減、開発効率化、品質の担保を実現したのである。結果は驚くべき成果を実現し、当初不可能だと言われていたパスネットプログラムは600テーマどれも遅れを発生せず、すべてのシステムが予定通りに稼働したのである。不具合の発生率は1/20となり、システム稼働以降トラブル対応を想定して待機していた要員はほとんどやることがなかった。工数も計画段階よりも5％少ない工数で完遂できたのである。

戦略的プログラム：製品開発

製品開発にはライフサイクルでステージとういものが存在し、そのライフサイクルをどのように意識し扱うかによって、製品から得られる価値に大きな差が出る。
製品のライフサイクルにおいては通常、プロジェクトは製品開発を行うと決まった段階からプロジェクト化され組織においてもプロジェクトとして認識されるようになる。しかし、製品開発はもっと前の段階からの活動が存在し、その前の段階をどう過ごすかによって製品価値が大きく異なってくるのが常識である。その前の段階をプロジェクトと言わず、テーマや本来業務など異なる言葉で表現している企業は多いが、製品開発と密接な関係を持ち、その良し悪しによって製品価値が大きく違ってくるという現実を考えると、その段階もプロジェクトして扱う必要性がでてくる。製品開発は企業が投資するイノベーション活動の最たるものであるが、製品開発を意識決定する前の段階を"Front End of Innovation"と呼び、非常に混とんとしたステージとして認識される。　それて、製品化が決まり開発を組織として意思決定し推進するステージを"Back End of Innovation！"と呼び、通常の目標達成に向けたプロジェクト活動として認識される。

P２Mのプログラムマネジメントにおけるプロジェクトモデル定義から見ていくと前半はスキームモデル・プロジェクトに相当し後半がシステムモデル・プロジェクトとサービスモデル・プロジェクトに相当することになる。これを考えると、製品開発プロジェクトは開発ステージを切り出してプロジェクト定義するのではなく、製品開発をプログラムとして位置づけ、上流のスキームモデルプロジェクトからプロジェクトを意識しプロジェクトチームを編成し、下流のシステムモデルプロジェクト、サービスモデルプロジェクトつなげていくことがプログラムとしても一貫性を持ち、プログラム全体としてもガバナンスが効き成果を出しやすくなる。
そのような動きは医薬品開発プロジェクトなどにもみられる。上流段階で製品の価値をPoC（Proof of Concept）として見極めた後は、その製品ポテンシャルを考え、どのように市場展開をするかビジネス側面での検討が始まり、ここでいうシステムモデルプロジェクト以降のシナリオが組まれる。なぜなら、医薬品は一つの化合物が一つの疾患にしか効果ないとは限らず、様々な疾患に効果を期待できることが多い。ある特定の疾患の製品を最速で製品化し、そのあとは徐々に他の疾患に展開していくのか、主要な疾患に対して一気に承認を取りビジネスを急速に拡大していくのか、米国で疾患を申請し高い薬価を獲得した後に日本やEUに展開していくのかなど、様々なシナリオが検討され、その中で最良と思われるシナリオをベースにして複数の臨床試験プロジェクト、申請プロジェクト、適用拡大プロジェクトなどが計画されることになる。扱う化合物を一つのプログラムと捉え、その化合物の持つビジネスポテンシャルを理解し、競合他社の状況も視野に入れ、一つの化合物から最大の価値を獲得できるシナリオを計画し実施していくやり方は、まさにプログラムマネジメントに他ならない。

戦略的プログラム：業務変革

プログラムマネジメントの基本テーマは価値創造に焦点を定めた"戦略の実現"であるが、戦略の実現について述べたRandall Russellの言葉を引用する。
"戦略の85%は効果的に実施されない。なぜなら、戦略を実現する仕組みを組織活動の中に組み込まないからである"
この言葉にあるように実に多くの企業が戦略を実現できていない。そしてその理由を"戦略を実現する仕組みの欠如"にあることを指摘している。非常に明快で正確な表現である。多くの企業は残念ながら戦略を実現する仕組みというものを持っていない。しかし、このように言い切ってしまうと多分、多くの企業から反論を受けることになる。なぜなら通常、企業には経営企画部、事業戦略部、製品戦略部、など企業戦略を計画立案する機能組織が存在しているからである。ではなぜ85％もの戦略が実現しないのか、仕組みがないといっているのであろうか。重要なことは２点ある。一つは、仕組みとは組織を意味するものではないということ。一つは、戦略とは計画立案することではないということである。
これまで述べてきたように、価値創造の時代において戦略はプロジェクトによって実現されようとしている。そして多くの場合、そのプロジェクトは組織横断に動くことになる。従って戦略を実現する仕組みとは、組織を充実することではなく、戦略を実現するプロジェクトをどのように統治していくかにある。戦略を実現するプロジェクトの統治なくして、戦略の実現はありえないことになる。
以下に戦略を実現するプログラム・プロジェクトのモデルのイメージを示す。

プロジェクトには大きく２つのタイプのプロジェクトが存在する。一つは企業収益に直結する活動を行うビジネス（実業務）プロジェクトである。ビジネスプロジェクトの目的は、ビジネス収益の獲得であり、企業はそのプロジェクトの成果から得られる収益により存続が可能となる。もう一つのプロジェクトは変革プロジェクトであり、直接そこから収益を生むことは無い。変革プロジェクトの目的はビジネスモデルの構築、変革、改善である。企業のビジネス環境の改善が中心となる。企業の戦略は既存のビジネスモデルをビジネス環境に合わせ充分戦えるように再構築し、再構築されたビジネスモデルを通して実施されるビジネスプロジェクトが効果的に利益をもたらすことによって実現する。したがって、戦略を実現し勝ち残るためには、競争優位の差別化ができるビジネスモデルを確立し、そのビジネスモデルをとおして効果的に収益を得ることをしなくてはならないのである。仕組みとは、このプロジェクトモデルを実現することに他ならない。経営企画部などの企画機能は、このプロジェクトモデルに貢献するアクションを担う必要がある。
さて、もう一つの戦略の意味づけであるが、戦略を計画立案することだと定義したとたん、その戦略の実現は困難になる。戦略の定義には諸説あるが、筆者は戦略を計画とはとらえていない。戦略とは計画し、実行し、そのフィードバックを必要とするものと認識している。ヘンリー・ミンツバークは戦略とはクラフティングであると述べている。クラフティングと陶芸家が轆轤を回して茶碗や花瓶を創作する行為である。陶芸家は自分の描いているイメージ（計画）を実体化させるために粘土を練り、轆轤を回し陶芸品の形を自分の手を使って整えていく。自分の持つイメージを実体化させていくのである。その時に、粘土の固さや、きめ細かさなどを自分の手を通して感じ取り、変っていく形を見ながら、自分の持つイメージを実現できるように自分の手の力を変えていく作業を行う。つまり、現実のフィードバックを通して計画を微妙に変えながら、また徐々に変化していく陶器を見ることで自分のイメージを膨らませながら手の力加減をおこない、イメージを実現する。これがクラフティングであり、筆者の戦略のイメージに最も近い考え方である。以下に戦略の実現サイクルイメージを示す。

ここでわかるように、戦略を実現するにはビジネスモデルが必要であり、ビジネスモデルを実現するには、幾つかの要素が明確になっていなければならない。簡単に言えば、環境の変化を知ること、自分を知ること、自分の将来ビジョンを持つこと、この３つである。これら３つの要素をもとに、競争優位で差別化可能な自分達のビジネスモデルを定義し、そのビジネスモデルの実現に向かって変革プログラムを遂行していく。しかし、戦略の実現は一方通行ではなく、必ずフィードバックを必要とする。実行されるプログラムの過程を通して現実とのギャップを把握し、必要な微調整と改善を行うのである。これによりビジネスモデルはより環境にフィットしたものとなり成果も出やすくなっていく。さらにビジネスモデルの改善は変革プログラムからのフィードバックだけでなく、変り行くビジネス環境の変化をインプットとして行う必要もある。なぜなら、ビジネ環境の変化は企業のビジネスモデルの条件を決めている環境要因であり、ビジネス環境に適応したビジネスモデルこそがより高い価値を提供できるからである。
しかし、残念ながら多くの変革プログラムはこのように流れで実施されることはない。ほとんどの変革プログラムは場当たり的に遂行され、効果の出ない結果となっている。つまり、戦略を実現するためにプロジェクト統治が行われないのである。
戦略はプロジェクトにより実現される（少なくとも筆者はこのように考えているが）とすると、戦略とプロジェクトが密接に関係し結び付かねば意味が無い。戦略とプロジェクトが結びついていないと容易にこのような問題が発生する。多くのプロジェクトが戦略とかけ離れて実施されているケースをこれまで何度も見て来たが、下図の組織における課題解決のメカニズムを示しながらこの理由を説明する。

変革プロジェクトと称する多くのプロジェクトは部門における課題を解決するために実行されている。つまり、多くのプロジェクトは経営課題から紐解くことは無しに、部門における課題を解決するために行われることが多い。ただし、予算獲得のためにプロジェクトのお題目として、企業の戦略実現を目指す一翼を担うことを謳っているとは思うが戦略との整合性は怪しいものが実に多い。部門における課題はわりと明確であり、実施すべきテーマも容易に設定しやすく、プロジェクトは実施すべきテーマとして容易に切り出されやすい。他社事例をそのまま適用しようとするプロジェクトなどはその典型である。他社の真似をしてその恩恵を得ようとして戦略を実現できるのであれば、それほど簡単なものは無い。部門が戦略を理解してプロジェクトを実施しているケースもあろうが、戦略的課題になるほど企業としての根幹の問題に行き当たり、部門横断的な問題になるのが普通である。それを全て部門の課題としてプロジェクトを実施しては本質的な経営課題は解決されない。

戦略とは企業の抱える重要な経営課題を解決するための方策そのものであり、経営課題が不明確な中での戦略は意味を持たない。しかし、課題が大きくなると課題を解決するためのテーマを設定するのは容易なことではない。なぜならば、経営課題を解決すべき戦略も幾つかのオプションを持ち、またその戦略の実現方法も幾つかのオプションを持つためである。正解というものが存在せず、全てが仮説の範疇を出ることはない。さらに厄介なことは、戦略もまた企業環境の変化の影響を受けるものであり、環境の変化に応じて変えていかなくてはならない。このような環境下で戦略を実現するためには、戦略とプロジェクトが一体化され、お互いが連携して動き戦略が軌道修正されながら遂行される仕組みを支える仕組みが不可欠である。その仕組みこそがプログラムマネジメントである。プログラムマネジメントの意義は、単に複数のプロジェクトを統合してマネジメントすることではない。それは、プログラムマネジメントの一部の姿でしかない。最も重要なところは、戦略を紐解いて戦略を効果的に実現するためのプロジェクトを創造するところこそ、プログラムマネジメントの核心である。プロジェクトは目的志向の強い活動であり、途中から目的を変えることは容易ではない。プロジェクトを戦略の意図を持って的確に遂行させるには、最初から戦略の意図をプロジェクトの目的の中に植えつけることが最も好ましい。つまり、戦略のDNAをプロジェクトの中に埋め込むことこそが、戦略達成への基本である。今日のプロジェクトマネジメントにおいては、どのように(How)マネジメントするか以上に、何を(What)をマネジメントすべきかの方がはるかに重要となる。

もう一つプロジェクトが戦略を実現するための重要な要因として、プロジェクト遂行中における戦略との整合性の確認がある。プロジェクトを遂行しはじめると様々な問題に直面する。戦略性が高ければ高いほどプロジェクトが遭遇する問題の数は多くなる。その都度、問題解決を行っていかなくてはならないが、戦略実現のミッションを持ったプロジェクトと云えどもプロジェクトを放り出しておくと方向性がおかしくなる。プロジェクトでの問題の解決手段は幾通りもあり、全てが戦略実現のミッションをベースに解決されるとは限らない。プロジェクトマネジャーは自分のプロジェクトに都合が良いように解釈をして問題解決することもあろう。戦略を実現するためのプロジェクトが複数動いている場合は、その解決の結果が他プロジェクトへ悪影響を及ぼし、結果として部分最適的な解決方法が戦略を損なうことになるかもしれない。また、課題によってはプロジェクトだけでは解決できないものもあるが、それを無理やりプロジェクトの中だけで解決しようとし、方向性がおかしくなるようなこともあろう。このようにプロジェクトと戦略との整合性を損ねる要因は至る所に存在している。プロジェクトの問題解決の方向性を常にプロジェクトが与えられた戦略からのゴール設定に照らし合わされなくては戦略の達成は危うく、同時にプロジェクトが戦略との整合性を保って進められているかを定期的に確認する仕組みも必要である。プロジェクトマネジャーに全てをゆだねてはならない。それは戦略実現の放棄を意味する。プロジェクト統治とは戦略実現にむけて、常にプロジェクトの方向性を戦略に照らし合わせて確認し、必要に応じてプロジェクトの方向性に軌道修正を与えることである。その仕組みこそが重要であり、プログラムマネジメントでは戦略とプロジェクトが常にベクトルが合うようにプロジェクトを統治していかなくてはならない。