アジャイルでイノベーションを引き起こせ - 集合知の力、衆愚の罠 -

集合知の力、衆愚の罠」を読んで考えてみたことをダラダラと書いていきます

集合知の力、衆愚の罠――人と組織にとって最もすばらしいことは何か

注意:タイトルは煽り成分が多めに入っております

集合知という名のイノベーション

本書でメインに取り上げられている”集合知”とは「集団の中から(個人では決して出てこない)新たな知恵や見識が生まれること」というモノみたいデス。

これは、いわゆるビジネス書なんかで取り上げられる”wikipedia:イノベーション”なんだろうな…と解釈出来るかと思うのです。

ちなみにイノベーションについてはwikipediaにもあるとおり、大きな変革を引き起こすきっかけとなる知恵みたいなもの…と考えればいいですかね(´・ω・`)

イノベーション(innovation)とは、物事の「新機軸」「新しい切り口」「新しい捉え方」「新しい活用法」(を創造する行為)のこと。新しい技術の発明だけではなく、新しいアイデアから社会的意義のある新たな価値を創造し、社会的に大きな変化をもたらす自発的な人・組織・社会の幅広い変革である。つまり、それまでのモノ、仕組みなどに対して、全く新しい技術や考え方を取り入れて新たな価値を生み出し、社会的に大きな変化を起こすことを指す

本書は一般的な組織・集団という範囲が広い(言葉を悪くすれば、多少ぼんやりとした)対象について集合知を引き起こすには…というコンセプトで書かれておりますが「会社(等の営利組織)でイノベーションを引き起こすには?」という視点、つまり「イノベーションを引き起こす会社、引き起こせずに没落していく会社」というサブサブタイトルをつけて読んでみたのです。

イノベーションを引き起こすには?

誤解を恐れずに本書をざっくりとまとめてしまうと、集合知を達成するためには次の各項目を常に意識&実践する必要があるYO!ってことをケーススタディを交えて繰り返し主張しているのデス(´・ω・`)

  • 傾聴する
  • 確信を保留する
  • システム全体を見る、多様な視点を求める
  • 他者への敬意を持ち、差異を識別する
  • 生じるものすべてを歓迎する
  • 「大いなるもの」に対する信頼

この各項目を内容を「イノベーションを引き起こすためには?」というオレオレ視点で強引に再編成してみると、以下のようにまとめることが出来るかな…と。

  • 現状の問題を正しく認識する
  • 批判も含めた多様な視点を受け入れる
  • 敵、味方の区分けを作らない
現状の問題を正しく認識する

過去の栄光に縋ることによる思い込みや、不安満載の未来を眺めることによる杞憂による空回りにとらわれることなく、きちんと現状を認識したうえで今何をすべきかを考えることが大事みたいです。

特に「確証バイアス」と呼ばれる"思い込み"によって前提条件として見えなくなってしまっているモノ、これを検討することはイノベーションを引き起こすことにとって重要なのではないかな…と、つまり常に現状を確認するという姿勢が大切になるということですかね。

批判も含めた多様な視点を受け入れる

「人は見たい物を見るようになりやすい」とはよく言われることですが、自分にとって批判的な意見や自分を保証してくれるモノを脅かす視点はなかった事にしたくなります。

その結果、重大な改善箇所を見落としたり思い込み的確証バイアスに取り込まれたりで重大な変革のタイミングを見逃してしまうことになりますデス(´・ω・`)

また、批判的な意見も受け入れまっせ(゚∀゚)ウエルカム!っていう姿勢を全面にアッピールすることで、様々な人が発言しやすくなり多様な意見が大量に出やすくなる→様々な知恵や改善ポイントが発見しやすくなる、というプラススパイラルが発生しやすくなるわけですね。

敵、味方の区分けを作らない

これは前述の「批判も受け入れる」という項目に関係するのですが「お前、俺の味方じゃない」みたいな区分けができると、「味方以外の意見→受け入れる必要なし」みたいな互いの意見を受け入れない困った環境が出来易くなるみたいです。

また敵・味方に分かれることで「互いに貶めるための批判的意見のぶつけ合い」という最悪な意見交換をはじめることとなり、お互いが尊重しあうという協力体制がどんどん崩れていってしまうというマイナススパイラルが発生するわけですね(´・ω・`)あとは坂道を転がり落ちるように組織が崩壊して行く…と。

また明示的な「敵・味方」な対立構造だけでなく、たとえば「平社員・管理職・経営層」みたいな対立構造に成り得るような区分けも危険っぽいですね。

さらに言えば、実際には分裂状態にも関わらず表面だけ取り繕って先延ばしたけども結局崩壊、というパターンのもあるみたいです(´Д`)

これってアジャイルの考え方じゃね?

…と、ある程度(半ば強引に)まとめてみるとこれってアジャイル的なポリシーに似ているじゃないかと思ってしまうのです。

たとえばアジャイル宣言を引用して項目化してみます

  • プロセスやツールよりも個人と対話
  • 包括的なドキュメントよりも動くソフトウェア
  • 契約交渉よりも顧客との協調
  • 計画に従うことよりも変化への対応

これらとリンク先にある12の原則をよく眺めてみると…本書で繰り返し重要視している各項目との関連性がみえてくるような気がします

そんなわけで(半ば無理矢理ひねり出した)前述のイノベーションを引き起こすための3項目を(素人丸出しの)アジャイル的視点で眺めてみます。

現状の問題を正しく認識する

細かくイテレーションを回して実際に動作する具体的なものを評価することで、現状(仕様と実情のギャップとか)の分析をきちんと行っていく事ができます。

これはPDCAid:hyukixが数年前に提唱してたDouble Loop教授設計プロセスモデル(教育分野だけども)みたいな現状確認の強化的なプロセスで実現しようとしているものにも似ている気がします。

また、計画順守のウォーターフォールな仕様や設計を「確証バイアス的思い込み」と解釈できるケースも結構見受けられる気もするのです。(といったら言い過ぎかもしれないけど)

それに比べて現状に基づいた変化を受け入れるアジャイル的姿勢はまさにコレに当てはまるのではないかな?と思うのです。

批判も含めた多様な視点を受け入れる

face to faceでの情報交換の徹底(朝会とか?)やペアプログラミングの活用など、アジャイルでは多様な視点の活用を重要視しているような気がします。

また、アジャイルと直接関連するかはわからないのですが、アジャイル的開発を謳っている環境では発言のしやすさなども重要視しているような気がします。

敵、味方の区分けを作らない

顧客との強調なんてまさにバッチリ当てはまっていると思うのです。

顧客は敵じゃなく互いに協力していく体制を作ることで、集団の協力によるプラスのスパイラルをつくっていくことが出来るのではないでしょうか?

まとめ

以上のようにアジャイル的な運営を行うことで会社組織はイノベーションを引き起こすことが出来るのではないか?というのが本書を読んだ個人的な感想デス(`・ω・´)

ただし、自分自身がアジャイルをあまりよく理解していないので(´・ω・`)この予感的なものを補強すべく週末に行えわれるATBCに参加してきたいと思います。

あとはアジャイル本とかをいくつか読んで体系的に理解してイカンとなぁ…と。とりあえずこの間衝動買いしたここらへんからかな?

アジャイル開発の本質とスケールアップ 変化に強い大規模開発を成功させる14のベストプラクティス (IT Architects’ Archive)

…以上です。詳しい人の突っ込み歓迎です(´・ω・`)是非ともお願いします。

おまけ

Amazonのレビューにもあるとおり、本書は若干読みづらい上に”愛”とか”癒し”とかの単語が踊り狂うので、個人的には読み進めるのに気力が必要でした。(衆愚のあたりはかなり整理されているので比較的読みやすかったのですが)

ただし、あくまで結果論ですがこの飽き性が”途中で投げ出さなかった”ってことは何か響くものがあったんだなぁ…と思っております。

玉石混淆すぎて何が玉かの選別が完全についてないのが困ったところですが(´・ω・`)

こういうとアレなんですが、まだ魔法と呼ばれていた頃の科学がこんな感じなのかなぁ…と読みながら思ったので、この分野の今後の発展次第で面白くなっていくと嬉しいな…と。

あと、購入当初にCGM系の何か?とか思ってたのは秘密です。

SOL(組織学習境界)って単語が踊っているあたりで気づけよ自分って感じですが(´・ω・`)まあ、面白かったので結果オーライです。