tech
U理論とアジャイルは根が同じ────U理論・中土井 僚(4)/西尾 泰和の「続・エンジニアの学び方」
サイボウズ・ラボの西尾 泰和さんが「エンジニアの学び方」について探求していく連載の第25回(これまでの連載一覧)。U理論の伝道師、中土井 僚さんにお話を伺うシリーズ(4)です。
本連載は、「WEB+DB PRESS Vol.80」(2014年4月24日発売)に掲載された「エンジニアの学び方──効率的に知識を得て,成果に結び付ける」の続編です。(編集部)
今回はインタビューは一旦お休みして、U理論がどういう文脈で生まれてきたのか、周囲の地図を得るために、一歩引いたところから描写してみたいと思います。
まずU理論がどの分野の理論なのかをきちんと説明する必要がありますね。U理論は経営学の理論です。著者のオットー・シャーマー(Otto Scharmer)はMIT Sloan School of Managementのシニア・レクチャラーとして、経営学、特に組織論を教えています。
学びを重視する戦略
ところで「経営戦略」という言葉でみなさんは何を連想するでしょうか? これは人によってだいぶ違います。ヘンリー・ミンツバーグ(Henry Mintzberg)は、「経営戦略」という言葉が10通りの意味で使われ、10の学派に分かれていると指摘しました[1]。
「U理論」のオットー・シャーマーや、彼と共著のある「学習する組織」のピーター・センゲ(Peter M. Senge)、日本人では「知識創造企業」の野中郁次郎などは、学習に重きをおく学派「ラーニング・スクール」に分類されています。この学派は「環境から効率よく学び、変化に適応することが重要」という考え方の学派です。
「環境から効率よく学び、変化に適応することが重要」と聞いて、どう思いますか? 当たり前だと感じるでしょうか。
他の学派の主張と比較してみましょう。例えば「デザイン・スクール」という学派は「自社の強み、弱みをしっかり分析して戦略を策定することが重要」と考えています。
これも、これだけを読むと当たり前だと感じるかもしれません。なので比較が重要なのです。2つの考え方を比較することで、書かれていないことが分かります。
「自社の強み、弱みをしっかり分析して戦略を策定することが重要」というとき、暗黙に「戦略の策定は事前に行われ、その後、それを実行する」という前提が入っています。実行フェーズで戦略の間違いに気づいたらどうするのか、環境からどう学ぶかの視点が抜けています。
逆に「環境から効率よく学び、変化に適応することが重要」というとき、暗黙に「環境は変化するものであり、事前に時間をかけて戦略を練ってもしかたがない」という前提が入っています。事前の戦略策定が軽視されているわけです。
「戦略の策定は事前に行われ、それを実行する。この事前の戦略策定をしっかりやることが大事」と考えるのか、「事前の戦略策定はあまり重要ではない。まず実行し、その結果から事後的にしっかり学ぶことが大事」と考えるのか、これはどちらが正解と言えるものではありません。
筆者はラーニング・スクールの考え方にとても親近感を抱いています。企業の経営だけでなく、エンジニア個人の「自分経営」に関しても、いかに環境から学び、変化に適応するかがとても大事だと感じているからです。だからこそ、この連載は「続・エンジニアの学び方」というタイトルなのです。
アジャイルとの関係
IT系のエンジニアには「アジャイル」という言葉を連想する人もいることでしょう。アジャイルという言葉の定義はあまり明確ではありませんが、「事前にしっかり仕様を設計して、それからそれを実装する」のではなく、「速やかに顧客に提供し、その結果から学んで仕様を変えていこう」という開発スタイルだと言ってよいでしょう。この2つの開発スタイルの関係は、上で説明したデザイン・スクールとラーニング・スクールの関係によく似ています。「効率よく学ぶこと」これがアジャイル開発の目的なのです。
アジャイル開発手法の中に「スクラム」という手法がありますが、これは実は野中郁次郎と竹内弘高による論文が由来です([2][3])。彼らがこの論文で提案した「スクラム」も効率よく学ぶことを目指した手法でした。戦略策定のフェーズと実行のフェーズを切り離してしまうのではなく、小さな「策定→実行→評価」のイテレーションを作り、それをオーバーラップさせ、たくさん繰り返すことで環境への適応をスピーディにすることを目指すわけです。これをソフトウェア開発の文脈に応用したものがアジャイル・スクラムです。設計→実装のフェーズと顧客評価のフェーズを切り離してしまうのではなく、「設計→実装→評価」を短いサイクルで繰り返すことで、顧客ニーズを効率よく学び、スピーディに適応することを目指すわけです。
「リーンスタートアップ」を連想した人もいるでしょう。これはなるべく早く「お金を払ってくれる顧客がいる」という仮説を検証することが重要だと考え、検証を実行できる最小限の製品をリリースすることで素早く仮説を検証することを提案しています。環境から効率よく学ぶことを目指しているわけです。
イノベーションはどうやって起こるのか
さて、「イノベーションはどうやって起こるのか」という問いについて考えてみましょう。この問いは経営学の大きなテーマのひとつであり、もちろん誰もまだ正解を見つけ出すことができていません。この問いに対して、いくつかの仮説的な「理論」が提案されている状況です。
例えば、野中郁次郎は「暗黙知と形式知を互いに変換することが重要だ」と考え、その具体的なプロセスとして「SECIモデル」を提唱しました([4])。SECIモデルは4通りの知識変換で構成されています(図1)。
- 暗黙知を暗黙知のまま共有する「共同化」(Socialization)
- 暗黙知を形式知に変換する「表出化」(Externalization)
- 形式知を他の形式知と結合する「連結化」(Combination)
- 形式知を個々人が習得し暗黙知とする「内面化」(Internalization)
この4つの知識変換をスパイラル状に繰り返すことで新しい知識が創りだされ、イノベーションが生み出される、というモデルです。そしてこのプロセスが起こりやすくなるように「場」を整備することが一番重要だと主張しました([5][6])。中でも共同化のSの場を重視し、PDCAサイクルの前にSを置くことが大事だと主張しています([3])。例えばホンダの「ワイガヤ」合宿などが共同化の場と言えるでしょう。
「場」をどうやって整備するのか
ところで、この「場」の整備ですが、具体的にはどうすれば良いのでしょう?
例えば旅館を借りきって社員を詰め込めば、それだけで共同化の「場」が生まれるかというと、そうではないわけです。どういうときにうまく「場」ができて、どういうときにうまくいかないのか? 何が邪魔をしているのか?
オットー・シャーマーのU理論はこの問いに関して答えを出そうとしています。彼は、場が深まっていく過程を4段階のレベルに分解し、それぞれのレベルの間にある3つの障壁を言語化しました(図2)。
- Voice of Judgement:既存の枠組みで評価してしまう「判断の声」
- Voice of Cynicism:既存の枠組みは変えられないという「あきらめの声」
- Voice of Fear:既存の枠組みを手放すことを恐れる「恐怖の声」
例えば、あなたが何か開発プロセスが改善されそうな新しいツールを見つけてワクワクしているとしましょう。それに対して「新しいツール? ダメダメ、どうせ一時の流行でしょ。よくあるじゃんそういうの」という声が聞こえてくるかもしれません。それが「判断の声」です。次に「このツールは良さそう……だけど、どうせこれを紹介しても上司の反対で導入されなくて、結局何も変わらないんだろうな……」という声、例えばこれが「あきらめの声」です。最後に「このツールを導入すれば、変化が起こる……だけど、それが本当に正しいんだろうか。今まで通りのやり方のほうが安全なのでは……」、例えばこれが「恐怖の声」です。
この3つの壁を乗り越えることで場が深まり、オットー・シャーマーの表現を使えば「ソーシャルフィールドが耕され」るわけです。そして耕された場から「未来が出現する」のです。オットー・シャーマーはPDCAサイクルを「過去からの学び」と呼び、新しいものを生み出すためにはUのプロセスをくぐり「『出現しつつある未来』からの学び」を行う必要があると説いています。
今回、まずU理論が経営学の理論であることを解説しました。次に、その経営学の中に、10個の学派があることと、その中の2つ、事前の計画を重んじるデザイン・スクールと素早い学びを重んじるラーニング・スクールについて解説しました。アジャイルやリーンが、ラーニング・スクールの考え方に近いことを確認し、「イノベーションはどうやって起こるのか」についてのラーニング・スクールの中での2つの仮説を解説しました。概念の位置関係が分かりやすくなったでしょうか?(つづく)
参考文献:
[1]「戦略サファリ 第2版」(ヘンリー・ミンツバーグ/ジョセフ・ランペル/ブルース・アルストランド、東洋経済新報社、2012年)
[2]「The New New Product Development Game」(野中 郁次郎/竹内 弘高、Harvard Business Review、1986年)
[3]「アジャイル開発とスクラム──顧客・技術・経営をつなぐ協調的ソフトウェア開発マネジメント」(野中 郁次郎/平鍋 健児、翔泳社、2013年)
[4]「A Dynamic Theory of Organizational Knowledge Creation」(野中 郁次郎、Organization science 5.1: 14-37、1994年)
[5]「The Concept of "Ba": Building A Foundation For Knowledge Creation」(野中 郁次郎、Knowledge Management: Critical Perspectives on Business and Management, 第 2 巻、2005年)
[6] 「実践知のリーダシップ──スクラムと知の場作り」(野中 郁次郎、AgileJapan 2010 基調講演、2010年)
「これを知りたい!」や「これはどう思うか?」などのご質問、ご相談を受け付けています。筆者、または担当編集の風穴まで、お気軽にお寄せください。(編集部)
謝辞:
◎Web+DB Press編集部(技術評論社)のご厚意により、本連載のタイトルを「続・エンジニアの学び方」とさせていただきました。ありがとうございました。
SNSシェア