まずは想像してみてほしい。「○○君、当社の命運をかけた本案件、ぜひ君に任せたい」――例えばあなたは、ある日突然、経営トップからこう言われたら、あなたは何と答えるだろう?「はい、お任せください!」と即座に答えられるだろうか? いや、躊躇するのが当たり前だろう。その案件が、以前に従事したことのある事業や、コンサルタントとして何度も経験した分野でもない限りは。
前のページで、速水君は深沢さんに「君がやらなければいけないのは、ソフトウェアのクラウド化対応だけか」と指摘されて、ようやく「事業として伸ばすことが求められている」という、ことの重大さに気付いた。しかし組織や業務について、大きな変革を伴うような重要な案件の場合、「既存事業」や「現在の業務の延長」ではないため、当初の目標を達成できずに終わってしまうリスクが高い。
現在は多くのビジネスマンがMBAを取得し、ビジネスの成功者の経験談、改革手法の実現例等にも容易にアクセスできる。それなのになぜ、その“難しさ”は変わらないのだろうか?
“変革の成功“には、「変革後の姿が優れていること」と、「変革後へスムーズに移行すること」という2つの要素が必要だからだ。より具体的に言えば、「変革後の姿が優れていること」とは、「ビジネスモデル、マーケティングやビジネスプロセス等が、競合や既存のやり方に比べどのような優位性があるか」である。
例としては、アスクルのSOHOをターゲットにした文房具翌日配達や、トヨタのカンバン方式導入などが挙げられる。アスクルは「細々した文具をいちいち買いに走るのは面倒」という庶務担当者の未発見のニーズをビジネスモデルに取り込み、トヨタは「後工程が必要な時に、必要なだけ生産をする」という考え方で、生産方式の在り方を大きく変えたのである。
一方、「変革後へスムーズに移行すること」とは、「曲がりなりにも機能している現在の事業の在り方にとらわれず、変革に対する抵抗に負けずに、どう変革後の姿を構築するか」である。アスクルの例で言えば、「社内でアスクルの立ち上げを任されたリーダーが、どのように社内外の関係者を説得し、リソースを確保し、受注や配送といった事業の仕組みを築いて行ったのか」ということである。
「変革後の優れた姿」については資料も多いが、「変革後への移行」については実践できるほど体系的に整理された資料は少ない。あっても「トップのリーダーシップが大切」といったような、属人的なエピソードにとどまるものが多い。後者は、言わば“改革の舞台裏”のことであるため、情報としてなかなか表には出てこないのだ。
しかし現実には、何千万円もかけて作成した素晴らしい改革案や事業プランの多くが、実行途上や実行前に挫折している。この事実が、後者のノウハウが、前者に劣らないほど重要であることを示している。もちろん変革後の姿を正しく描くことがまず重要であるが、移行に失敗すれば、素晴らしいプランも「絵に描いた餅」になってしまうのだ。
これを受けて、現在、多くのコンサルティングファームが、「戦略立案」から「実行支援」にサービスの重心を移しつつある。MBA取得者やコンサルタント出身者が増えたことで、企業側の戦略立案能力は高まってきた。しかし、「変革の実現」は立案とは異なるノウハウが求められる。そのため、コンサルティングファームを起用する理由として、彼らの有する“改革実現ノウハウ”がより重視されつつあるからだ。
そして本連載で解説する「プログラムマネジメント」とは、まさしく後者の「変革後への移行」のノウハウとなるものである。具体的には、変革を実現するために、
といった、“舞台裏に隠されたノウハウの集大成”である。
「変革実行の取り組み」は、従来「期限・予算の制約がある中で、要件・機能を実現する取り組み」である「プロジェクト」としてノウハウ化されてきた。しかし、建設やシステム開発など“アウトプットが明確な案件”を想定した「プロジェクト」と、変革実行という“より幅広い成果”を目指す「プログラム」では、案件の特性が大きく異なる。そのため、それぞれ異なるマネジメント方法が必要なのである。このため、プロジェクトマネジメントとは別の方法論として、日米欧各地域でプログラムマネジメント標準が開発されてきたのである。今、“競争力の源”として各地域で注目されているのだ。
前のページで紹介した事例「A社のクラウド事業の立ち上げ」も、「達成すべき目標と時点が設定されていたこと」は「プロジェクト」と共通だが、「新たな事業の柱となることが期待されており、これを成功させるためには組織や業務のあり方に大きな変更を要すること」と、「クラウド事業はA社内にまだ知見が少なく、目標達成のために責任者には大きな裁量が与えられる――言い換えれば、柔軟かつ積極的な計画変更が期待されること」は、「プロジェクト」にはない「プログラム」特有の要素である。
多くのプロジェクトは、“既存のビジネスの仕組み”――つまり組織やビジネスプロセス、ルールの中で行われる。受託開発プロジェクトであれば、営業が受注した後、要件定義、設計、開発、テストというステップで進んでいく。ある程度の規模の組織であれば、自社内で決められたルール、プロセスが存在し、それに従うことでスムーズにプロジェクトが遂行される。建設や新製品開発プロジェクトも同様である。
しかし、新規事業開発や企業合併といったプログラムレベルの案件になると、これまでのビジネスの枠組み、つまりマーケティングや開発の方針をはじめ、組織、ビジネスプロセスを再構築する必要が出てくる。逆に、こういった再構築の必要がなければ「変革」とは言えないのである。
また、マネジメント上の自由度についても違いがある。プロジェクトは原則として「計画通り」に進むことを良しとする。ベースラインの引き直しや、アプローチ自体を変更するのは「当初計画の失敗」を認めた上でのことになる。
一方、プログラムレベルの案件は、重要度が高く、期間も比較的長いため、事業環境や自社の戦略の変化といった外的要因に影響される。例えば、営業戦略の再構築の場合、同業他社が合併をすることでシェア順位に変化があれば、自社ではあらためて市場分析を行い、必要に応じて方針見直しを提案することが期待される。これも当初計画をなるべく遵守することが望ましいプロジェクトとは異なる点である。
すなわち、前のページで、速水君はクラウド事業の立ち上げを当初、プロジェクト的にとらえて、「ソフトウェアおよび、それを支えるインフラ基盤」というアウトプットを事業開始までに整備することをゴールとした。しかし、より経営トップに近い視点を持つ深沢は、「事業の目標は何か」を考え、営業方針やサービス開発など事業の構成要素を広くとらえるようアドバイスしたのである。
では速水君は今後、どのように事業を進めていけば良いのだろうか。次回から、プログラムマネジメントの6つの主要ノウハウを紹介していく。
次回、プログラムの「存在理由」であり、変革実現のもっとも重要な基礎となる「ベネフィット・マネジメント」から説明しよう。
PGM標準(第2版)をお持ちの方のために、今回の内容に関連する項目を紹介しておく。
清水 幸弥(しみず ゆきや)
日本ヒューレット・パッカード株式会社にてITコンサルタント、エンタープライズアーキテクチャやITガバナンス等のコンサルティング活動に従事。PMP、The Open Group Master Certified IT Architect
遠山 文規(とおやま ふみのり)
製造業・ベンチャー企業での研究開発、外資系ITコンサルティング会社でのコンサルティング・製品サポートでの経験を元に、開発現場の実務からIT導入までを得意分野とする。PMP
林 宏典(はやし ひろのり)
ジョージワシントン大PM修士コース終了。コンサルタントとしてPM、BPR、情報化計画等を専門とする。現在はデル株式会社で営業企画を担当中。PMP、PMS
Copyright © ITmedia, Inc. All Rights Reserved.