バックナンバー https://mat.lekumo.biz/ppf/cat9922971/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆イノベーションを抑える企業
イノベーションが必要だという主張に対して正面から否定することは難しい。なので、リスクがあるとか、足元を固める方が先決だといった話しになる。
しかし、もっと積極的な理由でイノベーションを抑えてしまうようなケースもないわけではない。たとえば、マクドナルドだ。
マクドナルドというと標準化というくらい高度な標準化を行っている企業だ。デイブ・グレイ、トーマス・ヴァンダー・ウォルが「コネクト」という本の中で、これまでのサービス業は企業が提供のルールを決めて顧客はそれに従ってサービスを受けていたが、今後のサービス業は企業と顧客が結びついて一緒に作り上げていく傾向が強くなっていくだろうという予測している。その中で、依然として企業がルールを決めて顧客を動かす特別な企業があるとし、その例として挙げられているのがマクドナルドだ。そのくらい、マクドナルドの標準化というのは進んでいる。
デイブ・グレイ、トーマス・ヴァンダー・ウォル(野村 恭彦監訳、牧野 聡訳)「コネクト ―企業と顧客が相互接続された未来の働き方」、オライリージャパン(2013)
標準化のメリットというか、目的はコストダウンすることである。そこにイノベーションを受け入れることは標準を崩すことであり、コストアップを意味する。そこで、マクドナルドはイノベーションを抑制している。
◆2つのプロジェクトマネジメント標準
プロジェクトマネジメントの標準というと米国のプロジェクトマネジメント協会(PMI)が作ったPMBOK(R)を思い浮かべる人が多いと思う。PMBOK(R)は1987年に原型ができ、1996年に標準として世に出された。その後、改版を重ね、現在は2012年に発表された第5版が最新版となっている。
PMBOK(R)の初版はその名前の通り、知識体系が中心で、ひとつのマネジメントがプロセスとして確立されているのはリスクマネジメントだけだった。その後、プロセス志向が強くなり、第3版からは形の上ではすべてのマネジメントがプロセスとして連結された(ただし、インプットやアウトプットが抽象度が高く、プロセスだとは言い難い面もある)。
プロセス的になってきた背景は2つあり、一つは知識体系をの使い方が固定化してきて、標準プロセスとして提供しても問題なくなってきたことがある。もう一つはPMBOK(R)の普及とともに底辺が広がり、認定資格と知識体系という組み合わせだけでは活用できなくなってきたことだ。
これに対して、日本プロジェクトマネジメント協会(PMAJ)が作ったP2Mという標準がある。こちらは基本的にプロセスはない。コンピテンシーという言い方をしているが、概念的な標準があり、それを利用者が解釈して実行するようになっている。
◆プロジェクトマネジメントの印象
プロジェクトはいまやどんな企業でもやっていますが、プロジェクトマネジメントの手法をきちんとやっている企業はIT企業やメーカの開発部門を除くとそんなに多くはないのが現状です。
これはプロジェクトマネジメントの手法がどんどん詳細化していき、原理原則がよく分からなくなってきたため、ちょっとしたプロジェクトには使いにくくなってきたという事情があります。
同じように、いろいろな革新の試みをプログラムとして取り組んでいる企業も増えてきました。著者がお付き合いしている企業でも、なんと呼ぶかは別にしてほとんどの企業でプログラム的活動が行われています。そのスパンは1~2年(中計レベル)のものから、4~5年かけてやるようなもの(ビジョン系)までさまざまです。
これらの活動をみていると、いろいろと知恵を絞って全体を管理しながら進めているのですが、「プログラムマネジメントを使えばもっとうまくできるのに」と思うことも少なくありません。
ただ、そういう提案をすると冒頭に述べたプロジェクトマネジメントの話になって、そんなマネジメントは自分たちのやっているプログラムには重いという話になります。
◆この連載の目的
でも、実際に見ていると、プログラムマネジメントと同じようなことをやっている部分も多く、その意味で決して重くはありません。残念なことに多くの企業で足らない部分は、統合し、全体最適をする、プログラムとしてもっとも肝になるところです。
これからイノベーションや未来創造と企業や事業の未来を創っていくような活動が増えてくるとプログラムに対するニーズはどんどん増えてくると思われます。
そこで、この連載ではプログラムをどのように進めていけばよいかについて、原理原則を解説してみたいと思います。ベースになっているのは、日本プロジェクトマネジメント協会が提唱しているP2Mというプログラムマネジメントのフレームワークと、そのフレームワークを実行するのに著者が使っているツールですが、説明はフレームワークやツールの説明ではなく、本質だけを抽出して自社でプログラムを実行されているやり方に折り込めるような形でお伝えしたいと考えています。
ということで、お読みいただければ幸いです。
(シナリオプラニング1/2はこちら)
◆シナリオとビジョン
前回、シナリオプラニングの歴史や必要性を説明し、シナリオプラニングの大まかな流れとして以下のようなものになるという説明をしました。
(1)描きたいシナリオの範囲を決めて、リサーチを行う
(2)分析をする
(3)情報を統合する
(4)ストーリーでプランを描く
(5)複数の選択肢を提示する
今回はこの手順をもう少し細かく見ていくことにします。まず、シナリオプラニングのゴールイメージですが、文字通りシナリオです。シナリオという言葉の意味ですが、ドラマのシナリオという言葉のイメージがあって、一つの筋書きをイメージする人が多いですが、シナリオプラニングのシナリオは複数の筋書きを意味します(この筋書きもシナリオと呼ぶことが多いので少しややこしいのですが)。
前回述べましたように、シナリオプラニングは従来、未来適応戦略を策定のための分析手法として位置付けられていました。つまり、未来適応のシナリオプラニングでは複数の選択肢を提示するところがゴールで、シナリオを使って妥当性のあるシナリオを選んで戦略を策定します。
これに対して、未来創造のシナリオプラニングではビジョン策定までを行うことがあります。つまり、もっとも望ましいシナリオを選んで将来ビジョンの描くわけです。
ビジョンの描き方については後で触れることにして、まず両方のシナリオプラニングに共通するシナリオを作るところまでの進め方を説明しましょう。
バックナンバー https://mat.lekumo.biz/ppf/cat9922971/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆はじめに
20回で一度ストップしたイノベーション戦略ノートを再開する。12月5日に「イノベーション力を身につける」というセミナーをやって、棚卸したネタが山ほどあるので、これから少しこのシリーズを書いて行こうと思っている。
第1弾として書きたいのは、第4回で、概念の紹介をしたレジリエンスという話である。一旦止まってしまったので、復活のテーマとしてもいいかなと思った次第だ。
【イノベーション戦略ノート:004】イノベーションを担う人材のスキルとマインド
◆イノベーションの現実
イノベーションに関する「組織の現実」を聞いていると、何かを提案して却下されたら、その件はそれで終わりというような感じの意見が目立つ。よく言えば潔いが、果たしてそんなものなのかとも思う。
イノベーションの本質をついた格言の一つは、「成功するまでやれば失敗はない」というものではないかと思う。こういうと、
組織はそんなに甘いものではない。一度失敗すれば次はない
という反論が飛んできそうだ。これも現実といえば聞こえがいいが、上位管理者と話をしてみるとそんなことはないという人が多い。失敗の仕方というか、失敗の後の態度によるというごく当たり前の考えの人が多い。すると、イノベーションの実行者は、ただ、単に一度打たれてへこたれているだけのようにも思える。
好川哲人
技術経営のコンサルタントとして、数々の新規事業開発や商品開発プロジェクトを支援、イノベーティブリーダーのトレーニングを手掛ける。「自分に適したマネジメントスタイルの確立」をコンセプトにしたサービスブランド「PMstyle」を立上げ、「本質を学ぶ」を売りにしたトレーニングの提供をしている。
最近のコメント