『エスケープベロシティ』解説（最終回）：実行力　〜どんな優れた戦略も実行できなければ意味はない〜

『エスケープベロシティ』の解説シリーズの最後は実行力です。どんな優れた戦略も実際に実行できなければ意味がありません。成長カテゴリーにうまく参入し、素晴らしい製品を提供しているにもかかわらず、いまいち市場で成功できなかった例は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冊のペースでできればと思っています（それ以上は時間的・体力的に苦しい）。別に翔泳社専属というわけではありませんので案件がありましたらよろしくお願いします＞出版社の皆様。