改革を「スローガン」で終わらせない方法：失敗しない戦略実現術、プログラムマネジメント（3）（2/3 ページ）

[清水幸弥, 遠山文規, 林宏典，PMI日本支部 ポートフォリオ／プログラム研究会]

ブレストでヌケ・モレをチェック

　「確かに技術的な側面に考えが偏っていたな……。よし、まずは立ち上げチームに相談して何度かブレーンストーミングをやってみてから、チームリーダーの田村さんに上げてみよう」

　自席に戻ったは速水は、深沢のアドバイスを受け、さっそく立ち上げチームのメンバーの協力を得ることにした。声を掛けたのは営業本部の丹羽、サービス本部の今野、開発本部の城田である。そして数日後、速水は深沢のアドバイスが正しかったことを実感することになるのだった。

図1　A社の組織図

今野　「サービスの基盤となるITインフラやアプリケーションの準備については、速水が挙げてくれたものでだいたい足りているかもしれない。だが、サービスとして提供するとなると、ユーザーへのヘルプデスクなんかも必要になるよな？」

城田　「CRMパッケージの新バージョンについては、顧客環境へのインストールパッケージを前提に開発を進めてるわ。ただクラウドによるサービス提供となると、ソフトウェアコードの二重管理も大変になるし、今抱えている開発リソースだけでは足りなくなりそうね」

丹羽　「営業部門としては、新規顧客の獲得もさることながら、現在のライセンスバージョンを使っていただいている既存顧客の扱いも悩ましいんだよ。そのままバージョンアップしてもらうのか、クラウドバージョンを利用してもらうのか――X社のY部長は新し物好きだから、クラウドバージョンを使いたいと言ってくれるかもしれないがね。この問題をどうするかによって、今期の売上予測にも影響が出てくるんだよ」

城田　「あと、開発や初期トラブル対応のリソース問題はさておき、そもそもクラウド化したら、現在のライセンスバージョンの提供はいつまで続けることになるのかしら？」

　速水は、従来の「ライセンス製品の機能拡張プロジェクト」とは全く異なる次元の検討ポイントが出ていることに気づき始めていた。また、それぞれが異なる立場、異なる視点で意見を述べているため、全ての意見を適切に収束しようと考えた。そこでクラウド事業立ち上げのビジョンとも言える「ベネフィット」をもう一度、全員で確認することにした。

図2　ベネフィットとKPI

速水　「これがベネフィットをKPIまで落とし込んだものです。当初、3年後の目標は、『クラウド事業の売り上げがライセンス売り上げを超える』ことだったんですが、その後の議論で、『3年後にはライセンス販売を停止し、全てクラウド経由でのサービス提供とする』とより積極的な案にしたんでしたよね」

　ゴールを共有しておけば、立場は異なっても意見の方向性を統一できる――速水はいつか深沢からもらったアドバイスを信じ、このベネフィットを基に、まずは各参加メンバーがやるべきことを出し合い、それをグループ化して、全体の活動を体系化することを提案してその日の会議を終えた。その結果、その後の何度かのブレーンストーミングを経て、「やるべきこと」を次のようにグループ化し整理することができた。

1. 低コストなクラウド基盤の確立
2. 段階的なサービス機能の展開
3. 機能展開に合わせたサポート要員の育成
4. クラウド化に伴うITプロセス標準化
5. 新規中堅・中小企業への販売フォーカス
6. 既存顧客のクラウドへの切替促進

　「いいんじゃないか？ベネフィットとも整合が取れてきたようだ。これなら田村さんに上げてみても大丈夫だと思うよ」――数日後、深沢に整理したリストを見せたところ、笑顔で太鼓判を押してくれたのだった。

ベネフィットと整合性は取れているか？

　さて、前回はプログラムマネジメントにおける存在意義とも言える「ベネフィット」に焦点を当てた。今回は、その「ベネフィット」をどのように達成するのかについて解説していきたい。

　プログラムによって「ベネフィット」を達成するために何をしなければならないか――そのためには、プログラムにおける「コンポーネント」を洗い出す必要がある。各コンポーネントをベネフィット実現に向けて、合理的に構造化したものを「プログラム・アーキテクチャー」（注）と呼ぶ。

▼注：＠IT情報マネジメント編集部では「アーキテクチャ」に統一する表記ルールとしていますが、本記事については「PMI（R）」の標準用語にのっとり「アーキテクチャー」としました。：＠IT情報マネジメント編集部では「アーキテクチャ」に統一する表記ルールとしていますが、本記事については「PMI（R）」の標準用語にのっとり「アーキテクチャー」としました。

　「コンポーネント」というと何やら難しい言葉のようにも感じるが、簡単に言えば「プログラムを構成するプロジェクトやその他の活動全般」のことである。プロジェクトは何らかの成果物を作り出すことが前提だが、各プロジェクトの成果物がベネフィットの実現に無駄なく貢献しなければ意味がない。よって、各プロジェクトの成果物やその他の活動が有機的に組み合わさるよう、以下のように「プログラム・アーキテクチャー」を明確化し、より確実・合理的にプログラムを推進するのである。

図3　ベネフィット（左）と主要コンポーネントグループ（右）

　このように整理すると、最初に速水がイメージしていた「データセンターの準備」や「ITインフラの準備」「CRMアプリケーションのクラウド基盤への移行」といった活動は、「低コストなクラウド基盤確立」というコンポーネントの一部に過ぎないことが分かる。つまり、「クラウド事業の立ち上げ」をプログラムというレンズで見ると、「データセンターの準備」や「ITインフラの準備」といったことは、ベネフィット達成の必要条件ではあるが十分条件ではないのである。

　こうしたプログラムマネジメントの分かりやすい例として、メーカーにおける新規事業や新製品の立ち上げが挙げられる。例えば、自動車業界における電気自動車開発、航空機業界における新機種開発、PCメーカーによるタブレット端末事業への進出などは、その一例である。

　これらに共通して言えることは、プログラムが対象とする事業、もしくは製品の構成要素が非常に多岐にわたり、加えてそのライフサイクルが比較的、中長期にわたるということだ。こうした場合は、まずは「何をやるべきか」という構成要素を洗い出し、その上で“プログラムというレンズ”で見て、ベネフィット達成に必要な構成要素をひも付けて全体の整合性を取っていくのである。

　こうした広範囲の活動をチェックする視点として、「People」「Process」「Technology」という3つの要素が挙げられる。聞いたことのある読者も多くいることだろう。A社の例で言えば、クラウド基盤やサービス機能は「Technology」、それをサポートする要員は「People」、ITプロセス標準化は「Process」ということになる。洗い出した構成要素のヌケ・モレのチェックには、これらの視点は極めて有効である。

　プログラムマネジメントにおいて、さらに注目すべき点は「販売活動」といった通常「プロジェクト」では扱わない活動、つまり定常業務が入っていることである。A社の例で言えば、プログラムの目標を「3年後にはライセンス販売を停止し、全てクラウド経由でのサービス提供とする」ことに置いている。

　つまり、「クラウド事業立ち上げ」を“プログラムのスコープ”で見れば、、クラウド基盤の運用に掛かる「People」「Process」「Technology」を準備するだけではなく、「“クラウドを基盤とした事業運営”を行うための顧客基盤を獲得」しておかなかればならないことも、おのずと見えてくるのである。