『エスケープベロシティ』の解説シリーズの最後は実行力です。どんな優れた戦略も実際に実行できなければ意味がありません。成長カテゴリーにうまく参入し、素晴らしい製品を提供しているにもかかわらず、いまいち市場で成功できなかった例はITの世界でも結構思いあたるでしょう。
実行力の要素としては、広報宣伝力、営業力、トップマネージメントのカリスマ性や政財界でのコネ（これ大事ですね）等々、いろいろな要素があると思いますが、『エスケープベロシティ』は組織論にフォーカスして実行力を論じています（他の要素はモデル化しにくいので当然と言えば当然です）。
この実行力に関する章（第6章）の内容がちょっとわかりにくいという意見も聞きました。確かに、他の章と比較するとちょっと具体例が少ないのと、文章がこなれてなかったり、用語の不統一が見られたりという点はあるかもしれません。ちょっと裏話をするとこの章の内容は、ムーア氏がかなりぎりぎりになって全面的に書き直しているのです（これによって翻訳作業がかなり無駄になりました（泣））。そういう点から原文もイマイチ練り込み不足かなという気もします（翻訳者としてもがんばったつもりですが原文にない言葉を足すのは限界があります）。
しかし、内容的には『ライフサイクルイノベーション』の第3部の延長線上にあるので、それを先に読んでおくと多少はわかりやすいかもしれません。『ライフサイクルイノベーション』の第3部の基本的主張は、イノベーションのライフサイクルのステージにおいて、適したマネージメントや組織が異なるので、ひとつのソリューションのライフサイクルを通じて同じマネージメントがずっと担当するのではなく、イノベーションのステージごとに担当組織を変えていくべきだというものでした。この考え方は『エスケープベロシティ』でも同じです。
ここでいうイノベーションのステージは、「発明」（Invent）→「展開」（Deploy）→「最適化」（Optimize）となります。新しい製品やソリューションを作るのが「発明」、それを大規模なビジネスにしていくのが「展開」、そして、市場が成熟した後に無駄をできるだけ省いていくのが「最適化」です。
この3つのステージの具体的内容は、企業のビジネスモデルがコンプレックス・システム型かボリューム・オペレーション型かによって異なります（コンプレックス・システムとボリューム・オペレーションについては解説記事の第3回で簡単に説明しています）。
コンプレックス・システム型の場合は、「プロジェクト」→「プレイブック」→「プロダクト」と進んでいきます。Playbookとは文字通り脚本のことです。訳すとかえってわかりにくい気がしたので「プレイブック」とカナ書きで逃げました。種々雑多の「プロジェクト」から共通部分をシナリオ化したものです。ソリューション・パッケージと呼んだ方がわかりやすいかもしれません。個別のカスタムプロジェクトをできるだけ定型化し、最後は定型的な「プロダクト」にして効率性を最大化するというやり方は、代表的コンプレックス・システム型企業であるSIerやコンサルティング会社が成功するために不可欠です。
ボリューム・オペレーション型の場合は、「プロダクト」→「パートナー」→「プロセス」となります。よい製品（「プロダクト」）を作ったら、「パートナー」の輪を広げてエコシステムを作って市場を拡大していき、市場が十分に拡大したらば最後は「プロセス」を最適化してコストを削減していくというやり方です。iPodはクールな製品であったかもしれませんが、初登場時はあまり売れませんした。iPodが爆発的に売れ出したのはiTunesにおいてメジャーなレコード会社との「パートナー」シップを構築できてからです。一方、日本の消費者向け電子機器メーカーは、良い「プロダクト」はできるもののその後の「パートナー」作りでうまくいかないケースが多いと思われます（さらに最近では「プロダクト」の優秀性もちょっと怪しくなってたかもしれません）。
ここで重要なポイントは前述のとおり、各ステージごとに適した人材が異なるということです。「発明」のステージが得意なリーダーを「インベンター」と呼びます（これまた、「発明家」と訳すとかえってわかりにくくなるので敢えてカナ書きにしました）。同様に、展開ステージを得意とするリーダーを「デプロイヤー」、最適化を得意とするリーダーを「オプティマイザー」と呼びます。
たとえば、スティーブ・ジョブズは「インベンター」として（そして、おそらくは「デプロイヤー」）としてきわめて優秀でした。ティムクックが「オプティマイザー」（そして、おそらくは「デプロイヤー」）として優秀なのは確かですが、今のAppleに優秀な「インベンター」がいるのかどうかは微妙なところであります。元HPのCEOマーク・ハードは明らかに優秀な「オプティマイザー」ですが「インベンター」であるかどうかは微妙です。そうなってくると今のOracleのハードウェアビジネスを率いる人材としてハード氏が適任かどうかは議論の余地があるでしょう。Oracleのハードウェアビジネスで求められているのは成熟化した市場でコスト削減を行なうことではなく、Engineered Systemによる市場開拓であり「インベンター」が求められていると思うからであります（これはムーア氏の引用ではなく栗原の私見）。
さて、このモデルのもうひとつの重要なポイントに各ステージ間の移行（transition）を適切に行なうということがあります。これは、意識的に管理しないとステージ間の受け渡しがうまくいかないからです。典型的なケースとしては、「インベンター」は製品が市場に投入されると自分の仕事は終わりと思ってしまいますが「デプロイヤー」は市場での成功がある程度実証されない限り、大規模展開にコミットしてくれないでしょう。また、製品が普及して市場が成熟化し始めると、最適化のステージに移るべき（「オプティマイザー」に担当を渡すべき）時が来るのですが、稼ぎ頭の製品を担当して予算も潤沢に使える（そして、おそらくは結構なボーナスをもらえている）「デプロイヤー」は、そう簡単には担当を「オプティマイザー」に渡そうとはしないでしょう。
ということで、この各ステージの間をスムーズに移行させるタスクそのものを第4の要素として扱うことが提唱されています。この「移行」のタスクに秀でた人材を「オーケストレーター」と呼びます。「オーケストレーター」は社内調整を得意とするリーダーであり独自のスキルが必要です。「オーケストレーター」の仕事は基本的に社内指向なので外部からはあまり見えないと思います。しかし、「オーケストレーター」型の人材を擁しているか、さらに、その人材を適切なポジションにおけるかどうかが企業の実行力に大きな影響を与えると思います。
各ステージごとのリーダーに求められる資質をまとめたのが下の表になります。
ということで、『エスケープベロシティ』についてかなり駆け足で説明してきました。結構ややこしかったのではと思います。262ページという比較的コンパクトなビジネス書において13ものフレームワークが紹介されており、それを7回のブログ記事で紹介した当然ではあります。
『エスケープベロシティ』も全体的に見ると、各論としては比較的充実しているのですが、13のフレームワークをどう組み合わせるかという部分については（書いてないことはないのですが）ちょっと薄い気がします（それは次回作でということなのかもしれません）。
とは言え、13のフレームワークから自分の現在の状況に適したものをピックアップ、あるいは、5つの力の階層の中から自社の弱い部分をピックアップしして、現状分析と改善策を検討するというような使い方は有効かつ便利ではないかと思います。是非ご一読をお願いします。
関連記事：
- 【お知らせ】ジェフリームーアの最新作『エスケープベロシティ』を翻訳しました
- 拙訳ジェフリー・ムーア『エスケープ・ベロシティ』絶賛発売中です
- 『エスケープベロシティ』解説（第1回）：カテゴリー力（１）--凋落したカテゴリーで地位を築いても意味がない
- 『エスケープベロシティ』解説（第2回）：カテゴリー力（2）--抵抗勢力に打ち勝ち成長機会に投資する
- 『エスケープベロシティ』解説（第3回）：企業力（1）--自分は誰と競合しているのか
- 『エスケープベロシティ』解説（第4回）：企業力（2）--差別化要素と稼ぎ頭は違うよ、全然違うよ
- 『エスケープベロシティ』解説（第5回）：市場力--「牛後よりも鶏口」の戦略
- 『エスケープベロシティ』解説（第6回）：製品力--「クラス最高」を目指すのは敗者の賭け
ZDNet Japan編集部：本稿はブログ「栗原潔のIT弁理士日記」からの転載です。執筆者の栗原潔氏は、株式会社テックバイザージェイピー代表で弁理士。IT分野に特化した知財コンサルティングを提供しています。
Keep up with ZDNet Japan
ZDNet JapanはFacebookページ、Twitter、RSS、Newsletter（メールマガジン）でも情報を配信しています。現在閲覧中の記事は、画面下部の「Meebo Bar」を通じてソーシャルメディアで共有できます。
