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

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

2012年05月

アジャイル、スクラム、研究開発

ソフトウェア開発の分野に「アジャイル」という手法があります。複雑性の高いソフト開発において、使い物になる製品をいかにうまく生み出すか、という視点から編み出された手法とのことですが、複雑性、不確実性を克服しようとする考え方は、研究開発の進め方とも大いに関わる内容を含んでいるのではないかと思われます。そこで、今回は研究開発マネジメントの視点から、「アジャイル」を考えてみたいと思います。

「アジャイル(agile)」とは、辞書には「機敏な」というような意味が出ていますが、ソフト開発においては適応的開発手法として、計画重視の開発手法の対極に位置づけられ[文献1]、その考え方は以下の「アジャイルソフトウェア開発宣言」にまとめられています。すなわち、「プロセスやツールよりも個人との対話を、包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を、価値とする。」という内容です[文献2、p.291]。なお、アジャイル開発手法のひとつである「スクラム」は、ラグビーのスクラムが語源で、野中郁次郎氏らの論文[文献3]からヒントを得たものとされています。

まずは、アジャイル開発の特徴を、アジャイルソフトウェア開発の12の原則[文献2、p.292]に従って見てみましょう。

1、顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。

2、要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。

3、動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。

4、ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。

5、意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。

6、情報を伝える最も効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。

7、動くソフトウェアこそが進捗の最も重要な尺度です。

8、アジャイル・プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。

9、技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。

10、シンプルさ(ムダなく作れる量を最大限にすること)が本質です。

11、最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。

12、チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。

この考え方の特徴は以下のようになると思われます。

・プロジェクト開始時に、実施すべきことをすべて計画することは不可能(複雑、不確実)。変更を受け入れることが顧客に価値のあるものを提供することにつながる。

・投入できる資源は限られており、その中で最も良いものを提供することに価値がある。

・やることとやらないことをはっきりさせておく。変更は受け入れるが、そのトレードオフも明確にする。

・問題を小さくシンプルにし、短い間隔で(優先度の高いものから部分的に)完成された製品(テスト済みの動くソフト)を提供することを繰り返して、全体を完成していく。この短い間隔の作業単位をイテレーション、スプリント、と呼ぶ。

・顧客とのコンタクトを密にし、部分的な完成品に対する顧客のフィードバックを歓迎し、計画変更は次の

作業単位の内容に取り入れる。

・作業の進捗と、作業のスピードは可視化され、顧客および作業チームに公開される。

・作業チームは、分業を前提とした狭い専門分野を担当するメンバーからなるのではなく、状況に応じて必要な作業をフレキシブルに分担したり手伝ったりできる構成にする。

・作業チームは、コミュニケーションを重視して、比較的少人数のメンバーで構成し、なるべく同じ仕事場、垣根のない仕事場で作業するようにする。

・作業内容はチームが決定し、作業単位毎の納入製品にもチームが責任を持つ。作業単位における作業内容には外部の者は口出しできない。すなわち、自己組織的なチームで作業を行なう。

具体的な進め方は、例えば「スクラム」では次のようになります[文献4]。

・チームは5~9人。

・スクラムマスターがプロジェクトの実施に責任を持つ。

・作業単位(スプリント)は30日。

・スプリントの開始時に1日かけて、プロジェクト要件と優先順位がつけられた「プロダクトバックログ」の説明と理解を行ない、スプリントで行なわれる作業を決めた「スプリントバックログ」を作成する。

・以後、毎日15分間の「日次スクラム」が全員参加で行なわれ、進捗と予定が報告され、調整が行なわれる。進捗状況は残作業量を可視化した「バーンダウンチャート」で行なわれる。

・各スプリントの終わりに、「スプリントレビューミーティング」が開催され、開発完了した成果物が発表され、顧客からのフィードバックを受ける。

・スプリント終了時にはチームで「スプリントレトロスペクティブミーティング」が行なわれ、前回のスプリントの反省と、次回への改善を議論する。

具体的な進め方はアジャイルの手法それぞれによって多少の違いがあるようですが、状況の変化を前提としてなるべくよい成果を得ようとすること、そのために顧客との連携を密にすること(頻度を多く、状況を可視化して真実を伝える)、内部の意思疎通が十分にとれた自己組織的なチームで作業にあたることが特徴と言えるでしょう。一般に、「プロセス運用の基盤となるメカニズムが広く知られている場合は、定義済みの(理論的な)モデリング手法を採用するのが一般的である。プロセスがその定義済みの手法にとって複雑すぎる場合は、経験的な手法を選択するのが適切である(Ogunnaike, Ray)」[文献4、p.3]と言われており、アジャイルの手法は、こうした経験的プロセス制御方法の実践法だと言えると思います。

研究開発においても、不確実性の克服は重要課題です。研究開始前には、すべてのことが明らかになっているわけではなく、結果や状況の変化によって研究計画は変更を強いられます。従って、アジャイル開発のような、変更に対して適応可能な手法は示唆に富むものと言えるでしょう。特に次の点は重要ではないでしょうか。

・最初からすべてを計画しようとせず、優先順位の高いものから取り組む。

・顧客(利害関係者)との連携と、合意形成。

・タスクを小さく分解する。

・頻繁な現状把握と可視化を行なう。

・計画の見直しを行なう。

・自己組織的なチーム(作業をチームが決める、自律性を持つ)により作業を進め、部外者はチームを信頼して邪魔をしない。

・そのかわり、コミュニケーションと報告(成果の提出も含めて)は頻繁に行ない、ありのままを報告することで利害関係者との信頼関係を構築し、計画修正の機会を持つ。

もちろんソフト開発とは異なり、作業単位を短い期間で区切り、その期間の終わりには完成された製品を作り上げることは、一般の研究開発のタイムスケジュールとは合わない場合があるかもしれません。しかし、研究課題をなるべく小さいタスクにブレークダウンし、重要なタスクから実施して、なるべく早い時期に製品に近い形の試作品を製造してみることは有効な場合が多いのではないでしょうか。研究開発におけるプロトタイピングの有効性はIDEOi.schoolでも強調されていますし(拙稿「東大式 世界を変えるイノベーションのつくりかた」参照)、多くの工程を含む研究開発では、ともかく最終製品まで作ってみることが非常に重要であることは私自身の経験に照らしてもそう思います。

アジャイル開発も、その他の研究開発も、複雑性や不確実性をマネジメントして成果を挙げようとする狙いは同じでしょう。有効な手法も、上記のように共通するものが多いと思われます。もちろん、異なる点はあるでしょうが、ソフト開発の分野でアジャイル開発の手法がそれなりに効果を挙げていることも事実のようです(もちろん、計画的なプロジェクト管理が必要ないというわけではなく、アジャイルの問題点の指摘や批判もありますが)。野中氏の知識創造理論から生まれた手法であるならなおのこと、複雑性、不確実性のマネジメント手法として、アジャイルから得られる示唆を真剣に考えてみてもよいように思います。



文献1:ウィキペディア、「アジャイルソフトウェア開発」、(2012.5.27確認)

http://ja.wikipedia.org/wiki/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E9%96%8B%E7%99%BA

文献2:Jonathan Rasmusson著(2010)、西村直人、角谷信太郎監訳、近藤修平、角掛拓未訳、「アジャイルサムライ――達人開発者への道」、オーム社、2011.

文献3:野中郁次郎、竹内弘高、"The New Product Development Game"Harvard Business Review 19861-2.

文献4:Ken Schwaber著(2004)、テクノロジックアート訳、長瀬嘉秀監修、「スクラム入門 アジャイルプロジェクトマネジメント」、日経BPソフトプレス、2004.

参考リンク<2012.7.8>



 


 

数値目標の功罪

「測定できないものは管理できない」という言葉があります。だから、物事はなるべく数値化して、数値目標により管理することが望ましい、という考え方の根拠としてよく目にするように思いますが、やや乱暴な使われ方をしている場合もあるのではないでしょうか。そこで今回は数値目標の効果について考えてみたいと思います。

あることの状態や結果を測定し、評価することは、ほとんどの場合有意義なことと言えるでしょう。得られた測定結果に基づいて、何らかの決断を行ったり、フィードバックしたりすることはビジネスの世界では必要なことです。しかし、その評価を数値に頼ることには問題があるという指摘もあります。まず、評価尺度や基準(目標)として数値を利用する場合の利点と問題点についてまとめてみたいと思います。

数値を評価尺度や目標として使う場合の利点には以下のようなものがあるでしょう。

・わかりやすい。

・違いが定量的に評価できる(条件による差や経時的な差の識別、目標との差の認識)。

・客観的な(評価に恣意性が入りにくい)印象がある→納得しやすい。

一方、問題点(注意点)には以下のようなものがあります。

・数値で表現しにくい要因がある。

・信頼性のある数字を求めるためには労力がかかることがある。

・バラツキが無視されることがある。

・測定、数値化の前提があることが忘れられる場合がある。

・無批判にルール化されやすい。

・数値化された要因のみが過度に注目され、他の要因が軽視されることがある。

・不確実な要因を考慮しにくい。

つまり、利点はわかりやすく信頼感がある点であり、問題点は、数値化されていないことや数値に現れにくいことへの注意がおろそかになる点であると考えられます。なぜ、数値化するとわかりやすくなるかと言えば、数値化の段階で現象を単純化しているためではないでしょうか。実際には複雑な現象であるにもかかわらずその一面のみを取り上げることで、その他の複雑な要因を無視する結果「わかりやすく」なると言ってもよいと思います。

もちろん、「わかりやすい」ことは必ずしも悪いことではありません。目標として数値を掲げれば、現状もはっきり認識できますし、目標に向かっての達成度も明確になり、努力を評価することもしやすくなるでしょう。これは管理する側にとっての利点でもあると同時に、管理される側にとっても努力の励みになったり、公平感を持ちやすいという利点もあるでしょう。また、部外者の理解も得やすくなるので、他者の説得や、他者からの協力を得る場面でも力を発揮するでしょう。しかし、その数値が本質を表現できていないとすれば、本質的な成功に結び付かない場合もあるはずです。

確かに、数値化に向いている業務はあるでしょう。また、数字があまりにも軽視されていることを問題視しなければならない場合もあるでしょう。無理にでも単純化することが問題の解決につながる場合もあるかもしれません。しかし、数値を使いたいなら、数値化することによる危険性も常に念頭に置き、安易な判断に流れていないかは自省しなければならないと思います。その数値が事態の本質を表わしているのか、数値化の段階で目をつぶった要因は本当に無視してよかったのかを吟味することは当然として、数値化によって新たな問題が発生しないかどうかに注意することは不可欠なのではないでしょうか。

研究開発の場合、評価尺度も、その効果的な測定手法も不明確なことが多く、数値化することが困難な場合が多いと思われます。このような数値化しにくい、あるいは測定しにくい業務を数値化しようとすると、どうしてもある種の仮定を置き、別の数値から目的の数値を導くことが必要になります。そうすると、その処理の過程に恣意性が入ってくることは避けられません。その結果、「我々が犯してきた失敗の背後にはいつも一見素晴らしく見えるスプレッドシートがある」(インテュイットの創立者スコット・クックによる)[文献1、p.237]という結果になりがちです。不確実性の高い業務において数字で評価することの困難さについてはノート12でも紹介しましたが、その数字が信頼に足るものでない可能性があると同時に、その数字を作るためにいわゆる「数字いじり」の努力を要する場合があることも問題でしょう。研究の着想段階から仮定が多く、恣意性の高い数字で計画をしている場合、その後の評価にも恣意的な要因が入ることになりますので、数字上は成功しても、実態はうまくいかないということが起こり得ます。数字で管理しようとするために、そんなあてにならない数字を作る努力をしなければならないとすれば、その努力を研究の遂行に向けることの方が余程効果がある可能性もあるのではないでしょうか。

また、前提が変わった場合の対応にも注意が必要です。前提が変わっているのに目標に反映させず、目標が現実的でなくなってしまうこともあり、ひどい場合には、前提を無視して目標に固執したり、場当たり的に変更したりする場合もあります。数値化された目標は安易にいじりやすくなってしまうとも言えるかもしれません。

加えて、人事評価が数値によって行なわれる場合には、数値化のリスクがさらに高まると思います。実務担当者は、評価対象の数字が本質から離れている場合にはそのことに気づいていることが多いものです。そんな数字を目標に掲げても、目標達成の意欲が上がることはあまり期待できないでしょう。さらに、人事評価をよくしようとして、その数値自体をコントロールしてしまうことも起こり得ます。その数値が業務の成果に正しく結び付けられていればよいのですが、複雑な業務の場合、管理されている数字を達成するために、管理されていないけれどもそれなりに重要な数字や、数値化できずに管理されていない要因を犠牲にすることも起こり得ます。それを防ぐためにはさらに管理の数字を増やす必要が生まれ、そうとするとその数字はさらに信用のできないものになったり、管理すべき数字が多くなりすぎて、数値化の利点である「わかりやすさ」が失われてしまう、といったことも起こります。

では、管理する側としてはどのようにすればよいのでしょうか。「測定できないものは管理できない」という言葉は、ドラッカーが言ったとされることもあるようですが、実際にはその裏付けはないようです[注]。ドラッカーは「測定可能と測定不可能なものとのバランスがマネジメント上の中心的で絶えず起こる問題だ」とし、「ビジネスでは、測定することが出来ない結果が重要」ということを言っているようで[文献2]、「データ化できるものだけでなく、データ化できないものを考えなければならない。データ化できないものについての配慮を忘れたデータ化は、組織を間違った方向へと導く。結果として間違った情報を伝える。しかもデータ化に成功するほど、それらデータ化したものにとらわれる。」[文献3]とも言っているようです。そもそも、「測定できないものは管理できない」には、何かを測定すべきであるとか、管理すべきであるという意味は含まれていません。測定できないけれども管理すべきであるものもあるでしょうし、管理のために測定できる数字を持ちださなければならないということも意味しないでしょう。そもそも管理の必要のないものについては無理に測定する必要もないはずです。

数字によって表わされる測定結果は、例えて言えば「影」のようなものではないでしょうか。物事の本質がよく見えない時には、その一面の情報である「影」から本質を推測するしかないかもしれませんが、数字はあくまでも「影」であって本質とは限らないことに注意が必要なのでしょう。もちろん、本質をなるべくよく表わす「影」を測定する努力は必要ですが、あくまで数字は「影」であることを忘れずに数値化することの利点と欠点をよく考えてマネジメントする必要があるのだと思います。


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

文献2:イグッチーさんのブログ(イグッチーの経営革新ブログ)より、「毎日のドラッカー 9月26日」、2010.9.30

http://ameblo.jp/iguchii1220/entry-10663135420.html

文献3:無者小路芥郎さんのブログ(塵と芥の思索室)より、「実践するドラッカー チーム編 その3」、2011.4.26.

http://plaza.rakuten.co.jp/yamaaki1015/diary/201104260000/


[注]「測定できないものは管理できない」という言葉は、Davila, T., Epstein, M.J., Shelton, R., 2006、トニー・ダビラ、マーク・J・エプスタイン、ロバート・シェルトン著、スカイライトコンサルティング訳、「イノベーションマネジメント」、英治出版、2007.p.17に、「『測定できないものは管理できない』という有名な言葉がある。」という形で書かれています。また、DeMarco “Controlling Software Projects: Management, Measurement, and Estimation”, 1982には「計測できないものは制御できない」という一文があるそうです。

参考リンク<2012.8.5追加>

 

 

利他性と協力

人間は本来的に利己的なのか、利他的なのか。これは仕事や社会生活における「協力」を考える上で、興味深い問題だと思います。非常に大雑把な捉え方をすると、経済学や経営学では人間を損得で動く利己的な存在として考え、その行動を予測したり制御したりすることが一般的だと思いますが、一方で、組織運営には協力も必要で、そのためにはある程度の自己犠牲を伴う利他的な行動も必要と考えられます。人間の本来的な性質としてはどちらなのでしょうか。

人間は生物として本来的に利己的であるという考え方は、ドーキンスの「利己的な遺伝子」によって広まった認識かもしれません。実は、この考え方はドーキンスの真意とは異なっているらしいのですが[文献1、2]、経済学の考え方によく馴染み、生物の協力行動や人間の振る舞いの予測に好都合だったこともあって、便利に使われるようになったのでしょう。しかし、人間は必ずしも利己的ではなく、本来的に協力する性質を持っており、しかもそれは進化に有利に作用する、という科学的知見も増えてきているといいます[文献3]。

ベンクラーによる文献[文献3]には人間や生物の利他性を裏付ける次のような例が挙げられています。

・協力行動に関する実験では、利己的に行動する人は30%、予測しやすい形で協力的な行動をとる人は50%、予測不可能な人が20%。

・ゲームを行う心理学実験において、事前に「力を合わせて課題を解決するゲーム」と伝えられたグループと、「どれだけ儲けられるかを競うゲーム」と伝えられたグループの行動を比較すると、「力を合わせるゲーム」と説明されたグループでは70%が協力的であり、「競うゲーム」と説明されたグループでは逆に70%が協力せず、ゲームの趣旨に影響される人が多いことがわかった。また、「力を合わせるゲーム」と説明された場合でも30%は利己的に振る舞い、人によって行動に差があることもわかった。

・野生のコヨーテとアナグマが協力して獲物を捕まえることが観察されている(獲物にありつけるのはどちらかであるにもかかわらず、協力する)。

・選挙で投票するかしないかには遺伝的要素が強く働くという。性格は部分的に遺伝することがわかっているので、誠実さのような性格が社会的に評価されるなら遺伝的に有利になる可能性がある。つまり、自己に多少の不利益があっても正しいことをしようとする性向や協力の文化は遺伝的特性であるとも言える。

・だれかに協力することは脳内の報酬系を活性化する。気持ちがよいから協力するという人間は存在する。

・だれかを信じる時、人は報われた気持ちになる。

・ハタネズミの研究では、脳のオキシトシン摂取能力が高い動物同士のほうが、信頼できるパートナーシップを築きやすいことがわかった。

・ビジネスの世界でもウィキペディアやユーザー投稿による評価サイト、オープンソースソフトなど人間が利己的であるという前提と相容れない事例がある。

一方、「協力行動を引き起こすことのできる基盤となるような、何らかの好社会性そのものが、遺伝的に備わっている」[文献4]という考え方もあるようです。長谷川氏によれば、ヒト固有の能力として、他者の心の状態を推測する能力、因果関係を理解してあることの原因を推定し、次に起こることを想像する能力があるといい、これらを組み合わせて世界に対して働きかけができるようになる[文献4]、とのことです。この考え方に従えば、利他行動が遺伝的に備わっていると考えるよりも、ヒトは協力行動を可能にする能力を遺伝的に身につけ、その能力の自然な発揮として協力行動が導かれる、とも考えることができるように思います。

いずれにしてもベンクラーの言うように、「いくつかの分野で、人間は想定されていた以上に協力的で私心がない、あるいは自己中心的な行動を慎むという証拠が見つかっている。結局のところ、人間はそれほど利己的ではないのかもしれない。」ということだと思われます。とすると、「何らかの協力システムを設計しながら、それをわずか30%の(利己的な人の)ためだけに最適化を図ろうとしているとすれば、人間としての可能性をたいそう無駄にしている」ことになるのでしょう。

にもかかわらず、人間を利己的ととらえるモデルはいまだ優勢です。その理由としてベンクラーは、1)人間が利己的であるのは部分的には真実である、2)そう信じることは歴史的に魅力があった、3)単純であり、理解し記憶しやすかった、4)今までそう教えられ、そう考えてきたので協力的な行動を見ても自己利益というレンズで解釈してしまう、という点を挙げています。人間の本質がどうなのか、今一度考え直してもる必要があるのではないかと思います。

さらにベンクラーは協力のシステムを構築するための7つのアイデアを紹介しています。

1)コミュニケーション:共感や信頼を高め解決策を見出しやすくなる。

2)フレーミングとその信憑性:どこに注目するか(フレーミング)によって人の反応は変わる。しかし、言い分に信憑性がなければ長続きしない。

3)共感と仲間意識:ただし、これは部外者を排除する力を秘めていることにも注意。

4)公平と道徳:人は公平に扱われたいと思うが、公平と平等は異なる。協力のシステムでは、規則よりも社会規範に基づく行動規範を共有することが重要。

5)報酬と罰:協力を育むには、人々を監視し、行動に応じて報酬や罰を与えるシステムではなく、参加者の「内発的動機」に訴えるシステムが不可欠。

6)評判と相互関係:相互関係に依存するシステムは長続きが難しい。他者からの評判を活用することが有効。

7)多様性:人間は十人十色であるから協力のシステムは柔軟でなければならない。

協力的環境づくりについては以前に別稿(協力的環境と研究-「不機嫌な職場」に学ぶ)でも考えてみましたが、人間の本性を利己的とみるか利他的とみるかは制度設計に大きな影響を与えるでしょう。確かに、今までの利己的な人間を想定したインセンティブや報酬、罰則を中心としたシステムは、それなりに有効に機能していたかもしれません。しかし、どうやら人間は利己的なだけではない、とすると、今までは人間の利己的な性質のみ、あるいは利己的な人間のみしか有効に活用できていなかった可能性があることはベンクラーも指摘するとおりでしょう。利他的な性質、協力的な性質を生かすことで、どのような成果が達成できるのかは今後の課題かもしれませんが、利己心に基づく社会システムの限界が顕になっている可能性も考えると、これからは利他性の活用も試みる価値があるように思われます。

ただし、人間はすべて利己的、あるいは利他的であると考えるモデルは単純にすぎるでしょう。実際には、すべての人が利己的な側面と利他的な側面を併せ持ち、その利己性、利他性の程度も様々なのではないでしょうか。一方、仕事の側にも、利己的側面が有効に作用する仕事と、利他的な協力が必要な仕事があるでしょう。人間の本性がどのようなものであるのかについて、現段階で結論を出すことは早計でしょうが、様々な仕事に対して、どんな人をどう配置してどのように動機づければよいかを考える場合には、人間は利己的な人ばかりではない、ということは大きなヒントになるのではないかと思います。

 

文献1:ウィキペディア「利己的遺伝子」(2012.5.13確認)

http://ja.wikipedia.org/wiki/%E5%88%A9%E5%B7%B1%E7%9A%84%E9%81%BA%E4%BC%9D%E5%AD%90

文献2:松岡正剛の千夜千冊、「リチャード・ドーキンス『利己的な遺伝子』」、2005.10.26

http://www.isis.ne.jp/mnn/senya/senya1069.html

文献3:Yochai Benkler、ヨハイ・ベンクラー著、編集部訳、「生物学、心理学、神経科学の知見が教える 利己的でない遺伝子」、Diamond Harvard Business Review, 2012, 2月号、p.8.

原著:”The Unselfish Gene”, Harvard Business Review, 2011, Jul-Aug.

文献4:長谷川眞理子、「利他の心の進化」、科学、vol.81, 2011, Jan., p.78.

 

 

複雑系経営(?)の効果

「複雑系」という概念自体はそれほど目新しいものではありませんが、マネジメントの分野でも時々「複雑系」の考え方が議論されることがあるようです。残念ながら「複雑系経営(マネジメント)」といえるほどの確立された分野が構築されるまでには至っていないようですが、「複雑系」は、科学分野だけでなく社会問題を扱う上でも重要な考え方だといえるのではないでしょうか。今回は、複雑系経営を取り上げたサルガト、マグレイスによる記事[文献1]の内容をまとめておきたいと思います。

「複雑系」とは、ウィキペディアによれば、「相互に関連する複数の要因が合わさって全体としてなんらかの性質(あるいはそういった性質から導かれる振る舞い)を見せる系であって、しかしその全体としての挙動は個々の要因や部分からは明らかでないようなものをいう」とのことで、「これらは狭い範囲かつ短期の予測は経験的要素から不可能ではないが、その予測の裏付けをより基本的な法則に還元して理解する(還元主義)のは困難である。系の持つ複雑性には非組織的複雑性と組織的複雑性の二つの種類がある。これらの区別は本質的に、要因の多さに起因するものを「組織化されていない」(disorganized) といい、対象とする系が(場合によってはきわめて限定的な要因しか持たないかもしれないが)創発性を示すことを「組織化された」(organized) と言っているものである。」とのことです[文献2]。ちなみに、「創発」とは、「部分の性質の単純な総和にとどまらない性質が、全体として現れることである。」[文献3]とされています。

マネジメントが上記のような「複雑系」の性格を持つものであることは、言われてみれば当たり前のような気もするのですが、実際にはそうした認識を忘れやすいことも事実ではないでしょうか。文献1では、「複雑系」の観点から見たマネジメント上の注意点として以下のような内容が述べられています(原著題名は「Learning To Live with Complexity」なので実践的な面がより強調されているように思います)。

著者は、「現在の企業経営は、30年前のそれとは根本的に異なっている。その最大の違いは、対応すべき複雑性のレベルにある。」としており、IT革命に起因し「かつては個々に独立していたシステムがいまや相互に関連・依存して」いると述べています。そして、まずは「複雑(Complex)であること」と「入り組んで(Complicated)いること」の違いを認識すべきであると指摘しています。すなわち、入り組んだシステムでは動いている部分が多くてもシステムの振る舞いは正確に予測できるのに対し、複雑系は、1)多元性(相互作用を起こす可能性がある要素の数)、2)相互依存性(要素がどれくらい関連しているか)、3)多様性(要素の種類がどれくらい幅があるか)が高いため、最初の状態が同じでも、システム内の各要素の相互作用に応じて結果が異なる可能性があるため、両者は同じようには理解できないといいます。

こうした複雑系のシステムにおいてよく直面する問題として、著者らは、次の点を挙げています。

1、予期せぬ結果を生む。そうなりそうな状況は以下のとおり。

・だれにもそのような意図がないにもかかわらず、事象間で相互作用が起こる。

・単一の事象ではなく、個々の要素が結びついたことで予期せぬ出来事が招かれる。(要素の一部に気付くことができても組み合わせや全体に及ぼす影響が予測できない)

・なぜそうしたかの理由が時代遅れになっているにもかかわらず、当時の方針や手順がそのまま存続している。

2、状況把握の難しさ

・一人の意思決定者が複雑系全体を把握するのは、不可能ではないにしても、大変難しい。

・他人の行動や自分自身の行動の影響を理解するにも、我々には認知限界というものがある。(大半のビジネスリーダーが、研究が示す以上の情報を入手して理解できると考えている。また、何か一つに集中すると、それ以外が見えなくなることもわかっている。)

・めったに起こらない珍事は、繰り返し起こる頻度が少ないため、システムにどのような影響が及ぶのかを学習できない。

そして、複雑性に対応する方法として次の点を指摘しています。

1、予測手法の改善

・特定の予測ツールを捨てる:現象の観察結果は他の現象の影響を被ることはないという考え方は問題。また、多くの分析ツールで用いられている、平均値や中央値から全体を推定できるという仮説も問題。

・システムの振る舞いをシミュレーションする:その複雑系に関する知見や各構成要素の相互作用について教えてくれるモデルを探す。

・データを過去、現在、将来に分けて、過去の知識に頼り過ぎた予測をしないようにする。

2、リスク・マネジメントを改善する

・正確な予測の必要性を制限あるいは排除する。ユーザーに決定権を与えて推測の必要性を少なくする方法もある。

・分離と冗長性を用いる。システムのどこかに不具合が生じた場合に、その構成要素を切り離す(分離)、他の要素が代替し合うように設計する(冗長性)。

・物語やホワット・イフ分析を利用する。あまりなさそうだが無視できない可能性や予期せぬ因果関係をデータの制約を受けない物語で考え、ホワット・イフ分析で反事実的な条件を問う。

・多面的検討を試みる。さまざまな方法を使い、さまざまな前提条件を設定し、さまざまなデータを集め、あるいは一つのデータをさまざまな角度から眺めて、問題に取り組む。

3、賢いトレードオフをつくる

・リアルオプションの手法を用いる。後に追加投資する権利を与えたうえで、比較的小規模な投資を行う。

・思考の多様性を確保する。変化や偏りに対応できる多種多様な人材を社内に確保しておく。

以上が概要です。はっきり申し上げて、簡単に使えて効果を挙げるような手法が提示されているわけではなく、複雑性への対応の困難さがより明らかになってしまうような内容かもしれません。しかし、現代の経営課題そのものの複雑性が高まっているとするならば、まずは複雑性のもたらす影響を認識した上で、それへの対応を試みることが必要だと考えます。少なくとも、複雑性の影響を軽視した従来の方法に固執することによる失敗は避けなければならないのではないでしょうか。とするなら、結局は、複雑系の現象は基本的に予測できないものであると認識し、その前提で行動し、結果にもとづいて行動を修正していくアプローチが好ましいことになるのでしょう。その中で、少しでも確度の高い予測モデルを作るために、また、問題点を早期に発見して対応するために、上記の対応方法が生きてくるように思われます。未来を見通す計画を立てて実行することよりも、仮説に基づいて実行し、俊敏に行動を変えていくやり方が研究マネジメントの多くの場面で有効なのではないかということは、今までもたびたび述べてきましたが、「複雑系」の観点からも同じ対応が求められている、ということになるのだと思います。

ただ、上記のような複雑系への対応そのものは研究開発を行なっている人にとってはそれほど違和感がないようにも思います。研究開発が本来的に持っている「不確実性」の原因が複雑系であることはよくあることですので、上記の注意点、手法は、研究の実務やマネジメントにそのまま適用可能であると言ってもよいでしょう。注意すべきなのは、複雑系に属する課題を、安易な還元主義で処理しようとしないこと、還元主義の立場で効果があるマネジメント手法を複雑系に安易に適用しようとしないことだと思われます。ひょっとすると、研究活動が経営層に理解してもらえない原因にも、こうした「複雑性」に関する認識の違いがあるのかもしれません。

さらに研究開発活動に対する重要な示唆として、「複雑系」の概念により、研究開発が抱える「不確実性」についての理解が深まる点が挙げられるのではないでしょうか。研究開発は本質的に不確実なもの、として理解されることが多いですが、その「不確実性」の原因のひとつが「複雑系」であると認識することによって、不確実性のコントロールがしやすくなる可能性があると思います。さらに、環境変化を単に「世の中の流れ、変化」による所与のものと考えるのではなく、「世の中の複雑性の高まりによる変化」ととらえることによって、時代の変化の本質をよりよく捉えることができるようになるのではないでしょうか。「複雑系」については、その知見から直ちに実践に結び付く手法を導くことは現状では難しそうですが、研究開発マネジメントにおける一つの重要な要因として認識し、その発展に注目しておく価値は高いのではないかと思います。


文献1:Gökçe Sargut, Rita Gunther McGrath、ギョクセ・サルガト、リタ・ギュンター・マグレイス著、編集部訳、「ビジネスリーダーの新しい経営学 [入門]複雑系のマネジメント」、Diamond Harvard Business Review, 2012, 1月号、p.118.

原著:Harvard Business Review, Sep., 2011.

文献2:ウィキペディア「複雑系」(2012.5.6確認)

http://ja.wikipedia.org/wiki/%E8%A4%87%E9%9B%91%E7%B3%BB

文献3:ウィキペディア「創発」(2012.5.6確認)

http://ja.wikipedia.org/wiki/%E5%89%B5%E7%99%BA



 


参考リンク<2012.7.8追加> 

 

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

元研究者

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