研究開発マネジメントノート

研究開発とそのマネジメントについてのいろいろ

試行

「イノベーション戦略の論理」(原田勉著)より

研究開発を成功させるにはどうしたらよいのか。すでに様々な経営戦略、組織運営の方法が提案されていますが、研究開発に関する限り、誰もが納得できる方法論は未確立のように思います。それはなぜなのか。おそらく最も大きな障害は、研究開発につきものの不確実性のせいで未来予測が困難なことなのではないか、という気がします。

未来の予測が困難であるなら、無理に予測しようとするのではなく、不確実性を前提として受け入れた上でどうすべきかを考える、というのもひとつの方法でしょう。原田勉著、「イノベーション戦略の論理 確率の経営とは何か」[文献1]では、不確実性を前提とするイノベーション戦略のポイントがまとめられており、実務家にとっても参考になる指摘が多いと感じましたので、以下にその内容のうち重要と感じた点をまとめたいと思います。

第1章、確率の経営――イノベーション確率最大化基準
・「短期効率性の追求には、不確実性はほとんど存在しない。・・・しかしながら、長期効率性の追求には、まだ実現していない不確実なイノベーションが付いて回るため、大きなリスクを伴うものになる。リスクのあるなかで、不確実な未来に向けてどのように決断すべきなのだろうか。この問題に何らかの決着をつけないかぎり、短期効率性と長期効率性との矛盾は解消せず、短期効率性を重視するがゆえに、長期的な適応力が低下するという結果になりがちだ。[p.8]」
・「不確実性の前では、合理性は無力である。戦略的思考や戦略的意思決定と呼ばれるものは、確実性のマネジメントにすぎない。[p.9]」
・「不確実性のなかでの意思決定では、結果そのものよりも、それを生み出すプロセスの合理性自体が問われなければならない。・・・プロセス合理性を追求しなければ、長期的には効率性は低下する。・・・プロセス合理性とは、より具体的にはイノベーションの成功確率を不断に高めていくということを意味する。・・・そこで必要なのは、結果が出る前に、イノベーション確率最大化基準によって経営のあり方を評価することだ。つまり、与えられた制約条件の下で、事前に想定されるイノベーション確率を最大化する取り組み、仕組み、制度になっているかどうかという基準で経営の合理性を判断するのである。[p.14-15]」
・「標準的な経営戦略論で論じられている戦略とは、・・・『組織能力活用型戦略』である。そこでは、いまある組織能力を所与として、効率的に活用することにより、利益を最大化することが目的となる。・・・この組織能力活用型戦略の問題点は、短期業績を上げることには効果がある一方、中長期的な企業の適応力を高めることには必ずしもつながらないという点にある。そこで必要なのは、いま所与としている組織能力自体をさらに高めていくことである。すなわち、『組織能力構築型戦略』である。本書のイノベーション戦略とは、この組織能力構築型戦略のことを指す。[p.17-18]」
・「イノベーション戦略は、既存の組織能力を最も効率的に活用するものではなく、将来を見越した先行投資を伴う。そのため、現在の競争優位にとっては必ずしもプラスにはならない活動が含まれることになる。すなわち、短期的な効率性はある程度までは犠牲にしなければならない。・・・重要なのは、どちらか一方だけを選択するというのではなく、組織能力の活用と構築の適切なバランスをとることだ。企業が成長するためには、この両方が必要なのである。[p.19]」

第2章、イノベーション確率とは
・「イノベーション経営にとって重要なのは、マクロでイノベーション確率を管理するという視点である。・・・ミクロのレベルで不確実なことも、マクロのレベルでは確実性が高くなる。これは、いわゆる大数の法則による結果である。・・・マクロ・レベルでの確率をできるだけ高めるためのマネジメントをここでは『確率管理』と呼ぶことにする。・・・その要諦は、個々の試行の立場に身をおかないという点にある。[p.29-31]」
・「効率的なイノベーション確率の管理には、①探索・試行の領域(イノベーション・ドメイン)を設定すること、②試行回数をできるだけ多くすること、③各試行の精度を高めること、の3つのプロセスが求められる・・・それに加え、④探索、試行の方向性を規定するメカニズムの是正(焦点化装置)も重要な課題になる。[p.36]」
・「もちろん、イノベーション確率は主観的確率であり、それは評価する者によって大きく異なることもある。イノベーション確率自体もまた実は不確実であり、サイコロの目の確率のように、客観的で確実な確率を事前に算出することはほぼ不可能に近い。それでも、組織のなかで知恵を絞って算出されたイノベーション確率を最大化する制度選択やそのための資源配分を実行すべきである。それが与えられた情報のなかでできる最善の方法なのである。[p.42]」
・「重要なのは、類似のプロジェクトが複数実施され、それによってナイト流不確実性が量的に代替されるという点[p.47]」。「ナイト流不確実性に対処するためのもう一つの方法は、決定を遅らせることだ。決定を遅らせることで新たな情報を獲得することができ、それによって不確実性を削減することができる。[p.48]」
・「主観的なイノベーション確率評価こそが、イノベーション遂行の鍵となる[p.52]」。「多数決は決断の根拠にはならない。多数決が有効なのは、大数の法則により、多数決が真実の確率をかなり正確に反映する場合のみである[p.54]」。「特に重要なのは、目利き能力をもった人材を選別し、彼らの評価を尊重するということである。・・・目利き能力のある人の多くに共通するのが、深く広い体験を重ねているという点にある[p.54]」。「多人数の多様な『井の中の蛙』を育成することで組織的に目利き能力を維持しようとする[p.58]」方法が考えられる。

第3章、イノベーション・ドメインの設定――探索領域を決定する
・要素技術は、「組織能力構築という観点からすると、①技術優位へのインパクト、②競争優位へのインパクト、の2つの軸で分類することが有益だ。[p.65]」
・「コア技術とは、技術優位、競争優位へのインパクトがともに大きい要素技術を指す。[p.66]」「コア技術以外の要素技術開発に予算を割り当てることが、大企業の場合、制度的に困難なのである。その結果、コア技術への投資のみが正当化され、コア以外の要素技術は硬直化することになる。・・・このことを回避するためには、あらかじめ研究開発における資源配分の枠を設定する必要がある。当然ながらコアへの資源配分は最も大きくなる。けれども、補完技術や周辺技術、場合によっては未利用技術への投資にも戦略的に一定の枠を確保しなければならない。そうでなければ、コア事業が立ち行かなくなったときに、次世代のコアの種がまったく育っていないという状況になってしまう。[p.82-83]」
・「『知識の地図』を明確に把握し、関係者の間で共有化することが、イノベーション・ドメインの設定には決定的に重要である。[p.88]」

第4章、探索のデザイン――探索の頻度と精度を高める
・「ジェームズ・マーチ・・・は、学習に伴う探索として、狭い領域での探索に特化した『深耕型探索』(exploitation)と、幅広い領域での探索を行う『拡散型探索』(exploration)という2種類に分類している。[p.91]」
・「拡散型探索は、深耕型探索と比べて不確実であり、努力が成果に結び付くとはかぎらない。・・・具体的にどこを探索すれば最善解を発見することができるのかについてまったく見当がつかない場合、組織メンバーをいかに動機づけ、イノベーション確率を高めていくのかが問題となる。・・・そこで重要なのは、『戦略的曖昧さ』を導入することであり、さらには失敗を許容する文化を構築することである。[p.96]」
・「戦略的曖昧さとは、不確実な領域にかぎっては、入口と出口のみを管理し、中間プロセスについては、細かな報告義務を課さないということである。[p.99]」
・「組織の長期的な成否が分かれるのは、・・・失敗をどのように評価するのかという点にある。減点主義の人事評価を実施している企業では、・・・加点よりも失点を避けることが重視され、幅広い探索を行うというインセンティブは失われてしまう。・・・本当にチャレンジを奨励したいのであれば、失敗をどのように評価するのかについて、明確な指針を示さなければならない。[p.100]」
・「ある領域での探索精度を高めるためには、それとトレード・オフの関係にある不確実性に対する探索頻度を量的に増加させることが鍵になる」。「下位レベルでの探索頻度を上げることで、上位レベルでの探索精度を高めることができる。」[p.106
・「探索モードの決定に際しては、結果の予測可能性と手続きの反復性という2つの次元によって評価し判断するのが有益であると思われる。[p.107]」予測可能性が高く、反復性も高い場合は、「組織メンバー間で協調し、分業しながら活動していくほうが効率的[p.108]」。予測可能性が低く、反復性が高い場合は、「拡散型探索に特化した組織メンバーによる協調的な探索活動が必要になる[p.110]。・・・そのためには、どこにどのような技術があるのかが明確でなければならない[p.113]」。3Mのテクノロジープラットフォームのような「見える化」が重要。予測可能性と反復性がともに低い場合は、「探索の重複によるコスト増を覚悟したうえで、並行して複数の組織メンバーに探索を行わせ、結果を競わせる[p.115]」。予測可能性が高く、反復性が低い場合、「探索は外部の業者に委託するほうが効率的[p.119]」。

第5章、探索の焦点を管理する
・要素技術の相互依存関係が掛け算の形になっている場合、ボトルネックの改善が重要[p.132]。
・要素技術の相互依存関係が足し算の形になっている場合、構成要素間の相互依存度は低く、強みの追求が重要[p.134]。
・知識の分類:リテラシー知識(技術を使いこなす知識)、専門知識、枠組み知識(知識が組織内のどこに存在しているかの知識)[p.142-143
・経営者に求められるのは、枠組み知識。「『現場を知らないことを知っている』経営者は、現場を知っている部下を信頼し、彼らの言うことに耳を傾けることで現場情報を把握する。なかには、本当のことを報告しない部下もいるため、嘘かどうかを見抜く観察力・洞察力も必要になる。また、部下の報告と数字との整合性のチェックも怠らない。・・・現場を知らないがゆえに現場を尊重し、自分の考えを押し付けることもしない。結果として、これがサーバント・リーダーシップといわれるものになっているのである。[p.144-145]」
・顧客情報については、営業情報(いつ、どれだけ買ったか、頻度といった情報)と、開発情報(用途および問題状況)を集めることが重要。[p.146
・「何を開発すべきかが明確ではない場合、トップダウンは機能しない。トップの技術的無知を押し付けることほど開発現場での弊害の大きなことはない。・・・したがって、トップダウンよりも、インフォーマルで自主的な情報交換のほうが効率的になる。それには、開発メンバーの自発的な行為によって開発の焦点が明確化されていくためのインフォーマルな仕組みづくりがポイントとなる。[p.149-150]」。情報交換会や技術展示会によるフェース・ツー・フェースのやり取りを促進させる仕組みが有効。

第6章、イノベーション戦略の実行――活用から構築へ
・「本書で対象としているイノベーション戦略は、不確実性のなかでの探索から構成されるため、短期効率性をある程度まで犠牲にすることによってはじめて成立する。したがって、このイノベーション戦略は、組織能力活用型戦略とトレード・オフの関係にある。・・・両者の間で適切なバランスを見出さなければならないということである。[p.162]」
・「組織能力の底上げなくして持続的競争優位を達成することは、何らかの法的保護がないかぎり不可能である。すなわち、競争戦略の愚直な実行は、競争優位の持続性を喪失させる大きな要因となる。[p.164
・「変化し続けることで、持続的または断続的競争優位は可能になる。これが、いわゆるリジリエント・カンパニーである。したがって、経営者は組織能力活用型戦略を実行することにより、一定水準以上の業績を達成しつつ、同時に、イノベーション戦略を遂行し、長期的な適応力の向上にも配慮しなければならない。[p.166]」
・「有限責任で長期的コミットメントのない株主は、企業の長期的適応力などには関心がない。・・・株主利益を重視したガバナンスを整備すればするほど、イノベーション戦略ではなく、組織能力活用型戦略のみを重視するという傾向が強くなる。・・・米国流のコーポレート・ガバナンスを取り入れること自体の誤りに気づかなければならない」。イノベーション戦略を、「買収ではなく内部開発の手法で・・・実行するためには、コーポレート・ガバナンスから隔離されたエリアをつくり出す以外に道はない。・・・短期業績への圧力が強い場合、実行可能な唯一のイノベーション戦略とは、間接イノベーション戦略である。『間接』というのは、自社で自らイノベーション戦略を実行し、探索していくのではなく、それを外部の企業に委託し、場合によってはその支援を行うというものである。[p.168-170]」
・「イノベーション戦略の実行には多様なかたちがありうるということだ。直接イノベーション戦略には、組織能力活用型戦略とのトレード・オフが必然的に伴い、実行には、イノベーション戦略への長期的なコミットメントが必要になる。そのためには、企業に対して長期的なコミットメントをする利害関係者の協力がなくてはならない。・・・イノベーション戦略の実行は、経営者がイノベーション戦略の重要性を認識し、それに対して長期的なコミットメントを決断していることが前提となる。経営者がイノベーション戦略に対して無責任であれば、イノベーション戦略を実行することはできない。そして、株主の場合とは異なり、経営者の無責任を回避する実行性の高い直接的な方法はない。[p.183-184]」
・「リスクを伴う高度な経営判断のよりどころは、それによってどれだけ儲かるのか、売上げが獲得できるのか、という財務的尺度であってはならない。そうではなくて、企業の掲げる理念にどれだけ寄与できるのか、という尺度から決断されなければならない。[p.187]」
・「理念とは掛け声ではなく、組織メンバー一人ひとりの行動を意識的、無意識的に規定する最も重要な組織能力としてとらえなければならない。[p.189]」
―――

イノベーションが不確実なものであるからとって、イノベーションを行う努力を避けていたのではその企業の将来は暗い、というのは多くの人が認めるところではないかと思います。しかし、不確実なことを実行することがいかに難しいか、ということもまた多くの人が実感されているのではないでしょうか。本書は、不確実性を前提として、では、何ができるのか、何が難しいのかが議論されている点、極めて示唆に富んでいるように思われました。もちろん、安易な解決策などあるはずもないのですが、地に足がついた議論をしたいと思えば、著者のアプローチは決して無視できるものではないと思います。

個人的には、本書に述べられた経営戦略の議論に加えて、第一線で技術開発を行う人々への動機づけもイノベーション確率の向上に果たす役割は大きいと思っています。本書では実務者の動機づけの問題については詳しくは議論されていませんが、著者が指摘する戦略上の問題と、動機付けの問題は、本質的な部分ではつながっているようにも思いました。イノベーションの実現というのは、本書の要素技術の相互依存関係の分析に従えば、各要素が掛け算の形になっている場合が多いように思います。そのボトルネックはどこにあるのか、どう改善すべきなのかは、実務者もよく考えておくべきでしょう。


文献1:原田勉著、「イノベーション戦略の論理 確率の経営とは何か」、中央公論新社、2014.

参考リンク



「製品開発をめぐる6つの誤解」(トムク、ライナーセンの論文より)

研究開発の進め方は、その前提やおかれた状況に応じて変えるべきである、ということは本ブログでも何度か触れました。しかし、「状況に応じて変える」ということはそう易しいことではありません。「技術」といってもその意味する範囲は広いので、技術や研究開発のことをある程度わかっているマネジャーでも、自らの経験や信念、先入観にこだわって判断を誤ることがあります。ステファン・トムク、ドナルド・ライナーセン著、「製品開発をめぐる6つの誤解」[文献1]では、製品開発(product development)と製造(manufacturing)を同じように扱うことによる誤りが述べられており、技術を知っていることの落とし穴を自覚する上で役に立つように思いましたので、その内容をまとめてみたいと思います。

著者らはまず、製品開発と製造は「根本から異なる。モノの製造では繰り返し作業が多く、活動は適度に予測がつき、一つの仕掛品が同時にいくつもの場所に存在することはありえない。これに対して製品開発では、独特の作業が多く、製品仕様は猫の目のように変わる。くわえて、コンピュータを使った先進的な設計やシミュレーションが普及し、製品自体にソフトウェアを組み込む例が多いなどの事情により、成果物はモノではなく情報なので、同時に複数の場所に存在しうる」と述べ、そうした製品開発をめぐる誤解を6つ示しています。

製品開発をめぐる6つの誤解

誤解1、リソースの稼働率を上げれば成果が上がる(High utilization of resources will improve performance.

著者らはリソースとして人材を主に考えているようです。「製品開発要員を手いっぱいの状態にすると、開発のスピードと効率、成果物の品質はどうしても落ちてしまい、稼働率をぎりぎりまで高めると深刻な副作用が生まれる。」と指摘し、マネジャーが副作用を軽視する3つの理由を挙げています。

・製品開発に本来伴う非定形性を十分に考慮していない

特に、非定形業務では稼働率が向上するにつれて、所要時間が劇的に伸びてしまうことを待ち行列理論に基づいて指摘しています。

・処理待ち案件がどうコストに影響するかを理解していない

「処理待ちのコストとリソースを待機させておくコストを比べて、適正なバランスを探りだす必要がある。」

・製品開発では仕掛品はまず目に見えない

「製品開発プロセスの『在庫』は主として、設計資料、試験の手順と結果、試作品づくりの指示内容といった情報」であり、これらは目に見えにくく、「目視も測定もできない問題に対処するのは非常に難しい。」

そして、上記問題の解決策として「非定形な業務プロセスの稼働にゆとりを持たせる」ことを指摘し、例えば以下のような方策を提示しています。

・3Mの15%ルール、グーグルの20%ルールなどのようなゆとりをつくる(ただし、運用のハードルが高い)

・業績評価の仕組みを改める:稼働率ではなく迅速性重視

・一部のリソースを増強する

・進行中のプロジェクト数を一定以下に抑える:開発案件の厳選、優先順位づけ

・仕掛品の存在を見えやすくする

誤解2、バッチ・サイズを大きくすると費用対効果が向上する(Processing work in large batches improves the economics of the development process.

要するに、まとめて処理すれば効率が上がる、という考え方が問題というわけです。「バッチ・サイズの縮小はリーン生産の大原則」であり、「バッチ・サイズが小さいと仕掛品の数が減り、すぐにフィードバックが得られるため、サイクル・タイムの短縮、品質と効率の向上につながる」と述べています。

誤解3、我々のプランには問題はない このままやり通そう(Our development plan is great; we just need to stick to it.

「毎日のように新鮮なひらめきが生まれ、状況が休みなく変化する製品イノベーションの現場では」、「プランとのずれを最小限に抑えるために中間目標や進捗を守れているかどうかをステップごとに細かく把握しようとする」発想では、成果を損ないかねない。「絞り込みの過程でそれぞれの候補を検証、改善するなかでは、判断が二転三転する。」「顧客ニーズもまた、早い段階では見極めにくいおそれがある。」従って、「プランはあくまでも仮定に基づく叩き台と位置づけ、検証結果が生まれるたび、経済面の前提が変わるたび、事業機会の評価が改まるたびに、たえず手直ししていくべきである。」

誤解4、プロジェクトは早く始めれば完了も早い(The sooner the project is started, the sooner it will be finished.

「マネジャーは遊休時間を忌み嫌う。少しの時間も無駄にするまいとして新しいプロジェクトを立ち上げる風潮がある。」「このような発想の下、プロジェクトの数が多すぎて精力的に推進するのが無理な状態を生んでしまうと、リソースの効果を弱める」。つまり、早く始めてもそれに注力できない状況では、完了が早くなるとは限らないということでしょう。

誤解5、製品の機能を増やした方が顧客は喜ぶ(The more features we put into a product, the more customers will like it.

この項目は、製品開発と製造の違いに基づく誤解というより、製品開発者が陥りがちな誤解の指摘だと思います。イノベーションのジレンマでのChristensenの指摘と同様、「多くの企業は革新性を発揮しようとするあまり、顧客にとっての価値や使いやすさといった大切な点を十分に検討しないまま、余計な機能を可能な限り設けてしまう。」ということです。著者らは、実際には「機能は少ないほうがよい」にもかかわらず、それが難しいのは、以下の2つの点で特別な努力を要するためであるとしています。

・問題点を明らかにする:問題をどれだけ特定できるかが、本当に意味ある少数の機能に重点を絞れるかどうかを大きく左右する。

・見えなくしたり(隠したり)、省いたりすべきものを見極める:開発チームはともすると「注目を集めたいという誘惑にかられる。」「どの機能を省くべきかを判断するのは、どの機能を盛り込むかを決めるのとおなじくらい重要」。

著者らは、このような見極めのためには顧客についての洞察や試行が効果的としています。

誤解6、初回でうまくいけばより成果が上がる(We will be more successful if we get it right the first time.

「初回でうまくいくように」というより、「一発でうまくいくように」という方が技術者の感覚に近いと思います。著者は、「開発チームは一度の失敗も許されない状況で、・・・最もリスクの小さいソリューションを選びがち」になり、「失敗を避けようと・・・プロセスをひたすら前に進める」「予想外の結果が出ると、・・・落ち度と見なされる」と指摘しています。そして、「試行と改善を矢継ぎ早にこなして失敗からすぐに学べる限りは、『最初は失敗しても構わない』と考えるほうが、望ましい戦略かもしれない。」と述べ、「早いうちに失敗する」ことの価値を強調しています。ただし、「この種の環境を設けるのは容易ではない」とも述べています。もちろん、なるべく失敗を避けるような準備は必要ですが、失敗を恐れず、あるいは様子見、確認のために試行することが重要であるとしていることには私も同感です。

以上をまとめると「製品開発は、情報を生み出す非定形の業務であるのに、それを製造と同じように扱っている」ことが根本の誤りであるということになりそうです(ちなみに、製品開発は情報を生み出す業務、という考え方は研究の本質を考える上で重要な視点だと思います)。このような指摘は、言われてみれば当たり前と思えるところもあるのですが、取り上げられた6つの誤解が著者らの多くの経験から引き出されたもの、という点で価値があると思います。自分では技術に詳しいと思っている人でもこのような誤解に陥る例があることは、技術者自らの考え方をチェックする上で有効でしょうし、製造経験の豊かな人がこのような誤解に基づいて開発の足を引っ張っているような場合に、どのように反論すべきかのヒントも与えてくれるように思います。

状況に応じて進め方を変えるというマネジメントの重要性は理解していても、それを実行することはそれほど容易なことではないと思います。その原因としては、まず何を変え、何を変えるべきでないかがはっきりわからないことが挙げられるでしょう。極言すれば絶対に変えてはいけないという普遍の原理はないのかもしれませんが、少なくともあまりコロコロと変えない方がよいものはあるように思います。しかし、常に正しいとは言い切れない原理(例えば製造のノウハウが製品開発に有用であると考えてしまうことなど)に安易に依存しているとすれば、それが間違っている可能性があることも認識しておくべきでしょう。本論文で述べられた「誤解」は、製造や開発というものがどう捉えられがちであり、どこに誤りの可能性があるかが示されている点、状況に応じたマネジメントを考える上で、示唆に富むものだと思います。



文献1:Stefan Thomke, Donald Reinertsen、ステファン・トムク、ドナルド・ライナーセン著、有賀裕子訳、「製品開発をめぐる6つの誤解 製造プロセスでの効率性は通用しない」、Diamond Harvard Business Review, 2012, 8月号、p.76.

原題 Six Myths of Product Development”, Harvard Business Review, May, 2012.

参考リンク<2013.1.14>


 

知的な失敗

不確実な対象を扱う研究開発(ノート2)では、「失敗」すなわち行動の結果が期待(予想)どおりにならないことがつきものです。今回は、マグレイス氏による論文「『知的失敗』の戦略」[文献1]に基づいて、「失敗」について考えてみたいと思います。

原著論文の題名は「Failing by Design」すなわち、「計画的に(by design)失敗する」、というような意味合いでしょうか。ちなみに、著者は「発見志向計画法」の提唱者であり、Christensenも取り上げている「創発的戦略」[文献2, p.277]についての研究も行なっている方です。著者はこの論文で、「不確実性の高い環境では、失敗は避けられないし、うまく管理すれば非常に役立つこともある」と述べ、「失敗から目をそらすのに代わる策は『知的な失敗(intelligent failure)』(Sitkinによる造語(1992))を設計することとしています。まずは論文のポイントをまとめてみます。

著者は、失敗は次のような点で役に立つと述べています。

・たくさん試せば成功する確率は上がる(当然、失敗も増えるはずですが、要は数多くの失敗をしないと成功できないということでしょう)。

・何が有効でないかを学べる(試行錯誤の結果として)。

・失敗により注目を集め対応の必要性をアピールできる結果、資源配分を受けやすくなる。

・不適格なリーダーの退任のきっかけになる。

・失敗経験により直観を磨きスキルを高めることができる。

やや皮肉っぽい項目もありますが、失敗が避けられないものだとすれば、失敗を気にして目をそらすだけでなく、できるだけうまく失敗し、失敗を利用するということも重要ということでしょう。

著者はそのために必要なこととして、以下に示す「失敗を生かすための7つの原則」を提示しています。

1、プロジェクトの開始前に成功と失敗を定義する。

プロジェクトに関わる人たちの間で、何をもって成功(失敗)とするか、何を期待(目的)とするかについての共通理解を持つことが必要。

2、前提を知識に変える。

先が読めない課題に取り組んでいる場合、最初に置いた前提(仮定-原著ではassumption)はほぼ確実に間違っていることを認識する必要があり、試行することが、よりよい前提を導き出す唯一の方法。

成功の基準となるものが、単なる期待なのか、ある前提のもとでの予想なのか、できるはずと思いこんでしまったことなのかははっきりさせておかないと、失敗から正しく教訓を学ぶことはできないでしょうし、チーム内での秩序が乱れることもある、ということのようです。

3、迅速であれ、失敗は早々にせよ。

早い段階や小さい段階での失敗には、試行の候補を絞り込む、退却が容易であるというメリットがある。失敗は人々のやる気を削いでしまうが、別のもっとおもしろみのあるプロジェクトに移るのであればポジティブに受け入れられる。

プロジェクトの要素のすべてを早い段階でチェックすること、プロトタイピングなども重要かもしれません。

4、被害を食い止め、損失を抑える

失敗がもたらす被害を小さく抑えるように試行を設計すべき。プロジェクトを中止する「撤退のステップ」を整備しておくことは有効。

5、不確定要素を制限する。

現在備わっている能力から遠く離れた分野では、試行から学ぶことは難しい。近い分野での試行の失敗からは学べることも多いし、成功の確率も高くなるはず。

6、知的な失敗を称える文化を育む。

失敗に終わっても罰しない環境をつくる。うまくいかないかもしれないことに取り組む意欲を大切にする(リスクをいとわない文化をつくる)。工場で効果を発揮するシックス・シグマなどの活動は研究所には向かないかもしれない。リーダーは失敗やそこから学んだことについて、進んで話をすべき。

7、学んだことを書きとめ、共有する。

どのような前提(仮説)が基になっているか、何が起こったのか、それは前提に対して何を意味しているのか、次回は何を行なうべきかを特定し、その教訓を共有することが重要。

以上が概要です。失敗を容認しなければならないこと、失敗した時の痛手は小さくなるようにすべきこと、失敗から学ぶ必要があることについて異論のある方はあまりいないと思いますが、上記の指摘は興味深い点があるものの個別の議論になっているようにも思われます。そこで、失敗への対応について私見もまじえて整理してみたいと思います。

失敗は研究開発にとって不可避のものであることは間違いないと言ってよいでしょう。ただし、研究活動を含む行動には、情報を得るための行動と、期待を実現させようとするための行動の2種類があることは認識しておく必要があります。前者は情報を得ることが目的ですから、期待通りの結果が得られなくても情報さえ得られれば成功ですが、後者は、期待通りにならなければ失敗ということになります。どんな場合でも行動をすれば何らかの情報が得られると考えると、問題になりやすいのは後者でしょう。となると、失敗しやすい行動において、期待することを実現させたい場合には、以下の2通りの対応が考えられると思います。

・失敗を少なくする(成功確率を上げる)

・失敗による損失を少なくする(あるいは、多くを学ぶようにする)

失敗を少なくするためには、予測の精度を上げるための情報を集めることが必要でしょう。その情報には当然、実際に行動して失敗することから得られる情報も含まれます。著者が指摘する、失敗を称えリスクテークを奨励する(上記6)、失敗から学んだことを伝える(上記7)は、行動を通じて情報を集め、生かすための方策と考えられます。また、失敗を未然に防ぐ(成功確率を上げる)ために、行動の目的が不明確であったり不統一なために起こる失敗を防止すること(上記1)や、不確定要素を制限する(上記5)という提案もなされています。

失敗による損失を少なくすることについては、著者らは、早い段階での失敗(上記3)と、被害を小さくすること(上記4)を提案しています。これは、言い換えれば小さい投資で早く結果がでるように行動(試行)をあらかじめ設計しておくことを奨励していると理解できるでしょう。さらに、プロジェクトからの撤退のステップを用意して撤退をしやすくしておくこと、多くのプロジェクトを用意して別のもっと面白いプロジェクトへの乗り換えを提案していることは重要ではないかと思います。要は、資源の投入を小さくし、失敗による損失を小さくすれば、相対的に失敗から得られるものの価値は高まるということです。

失敗から多くを学ぶことについて著者は、失敗から正しい教訓を導くために前提(仮定)を明確にしておくこと(上記2)、学びやすい分野に取り組むこと(上記5)を挙げています。エジソンは「私は失敗したことがない。うまくいかない10000通りの方法を見つけただけだ。」と言ったとされますが、うまくいかない方法を知識にするためにはただやみくもな試行をするだけではダメで、どういう前提でどういう仮定に基づいて試行(実行)したかをはじめとして、うまくいかない条件や原因を明確にして記録(記憶)しなければならない、ということも言っているように思います。著者が指摘する「前提を明確にする」ということは、正しい教訓を導き出す方法として重要ということなのではないでしょうか。実際に期待どおりのことが起こらなかった場合、その現実からつい目を背けたくなるものですが、その失敗を生かすためには前提や仮定のどれが違っていたのかを明確にする必要があるでしょう。そのためにはチェックすべき前提や仮定を最初から明確にしておくことは結果の迅速な判断、対処のために有効であると考えられます。こうした前提を整理しておけば、学ぶべきところの少ない単純ミスも早期に見分けられるかもしれません。ただし、最初の前提や仮定以外の因子が原因で失敗することも往々にしてありますので、最初に考えていた項目に囚われすぎてしまうことは問題だと思います。

なお、失敗から学ぶというと、次に同じような失敗をしないために失敗の原因を明確にし、教訓を得て将来に生かすという考え方がまず思い浮かぶのではないでしょうか。つまり

期待:Aという行動→Bという結果

失敗:Aという行動→Bという結果にならない

という失敗に対して、行動の中身や前提、考え方を見直してBという結果が得られるように行動を修正する、ということが行なわれると思います。しかし、実際には

失敗′:Aという行動→Cという結果

となる場合もあります。これも失敗には違いありませんが、こうした結果からは、単なる同じ失敗を繰り返さないための教訓以上のことが学べる場合があります。セレンディピティーによって失敗から新たな発見をする場合や、顧客の反応に学んで新たなマーケットを創造する場合(新市場型破壊的イノベーションなど)も、この種の失敗から学ぶことができる場合であって、こうした可能性も忘れてはいけないと思います。

いずれにしても、先が読めず変化が激しい世界では新たなことへの挑戦は必須です。この論文でも述べられていますが、まず失敗のリスクをとり、新しいことに挑戦することが必要です。Merckでは失敗した取り組みから早期に手を引いた研究者にストックオプションで報償する制度があるそうですし[文献3p.266,文献4]、「大失敗賞」という表彰を行なっている会社もあるそうです[文献5]。失敗に寛容であるためには、失敗というものの性質、失敗のもたらす影響、失敗から学べることについての理解が不可欠であるわけですが、失敗から得られるものの価値を高いものにすることで失敗に寛容なチャレンジングな環境が実現できるかもしれません。容易なことではないかもしれませんが、リスクをとることを促し、その結果として発生する失敗のマネジメントをうまく行なうことが、イノベーションの能力を高める上で重要なポイントのひとつなのではないかと思います。



文献1:リタ・ギュンター・マグレイス著、スコフィールド素子訳、「マイクロソフト、3Mが実践する『知的失敗』の戦略」、Diamond Harvard Business Review20117月号、p.24.

要約のみ:http://www.dhbr.net/magazine/article/201107_s02.html<2013.1.13リンク切れ>

原著は、Rita Gunther McGrath, “Failing by Design”, Harvard Business Review, Apr. 2011.

最初の部分のみ(登録すれば全文閲覧可):http://hbr.org/2011/04/failing-by-design/ar/1

文献2Christensen, C.M, Raynor, M.E, 2003、クレイトン・クリステンセン、マイケル・レイナー著、桜井祐子訳、「イノベーションへの解」、翔泳社、2003.

文献3Anthony, S.D., Johnson, M.W., Sinfield, J.V., Altman, E.J., 2008、スコット・アンソニー、マーク・ジョンソン、ジョセフ・シンフィールド、エリザベス・アルトマン著、栗原潔訳、「イノベーションへの解実践編」、翔泳社、2008.

文献4Arlene Weintraub, “Is Merck's Medicine Working?”, Businessweek, 2007.7.30.

http://www.businessweek.com/magazine/content/07_31/b4044063.htm

文献5:茂木俊輔、「太陽パーツ-大失敗賞 『前向きな大失敗に金一封』社員を明るくする表彰制度」、FoleAug.2010p.28.

https://www.forum-m.jp/ssldocs/members/fole/pdf/2010/1008/fole1008_7.pdf




参考リンク<2012.7.8追加>
 


 

記事検索
最新記事
プロフィール

元研究者

QRコード
QRコード
  • ライブドアブログ