チンパンジーより良質の意思決定を。ファクトフルな組織を目指すには

話題の FACTFULNESS という書籍を読みました。

FACTFULNESS(ファクトフルネス)　10の思い込みを乗り越え、データを基に世界を正しく見る習慣

作者: ハンス・ロスリング,オーラ・ロスリング,アンナ・ロスリング・ロンランド,上杉周作,関美和
出版社/メーカー: 日経BP社
発売日: 2019/01/11
メディア: 単行本
この商品を含むブログ (1件) を見る

冒頭で世界に関する13の質問(それぞれ3択)を出し、その正解率が 33 % を下回っているという話を「チンパンジーが何も考えずに選択肢を選ぶよりも結果が悪い」と呼び替えることで、そのインパクトで口コミを呼び、本で伝えたいことが広く伝わるという広報戦略の意図を感じます。
よし、技術書典で出す本で「あなたは本能に従うとクアッカワラビーをこえることができません」とか使ってみよう。（嘘です）
記事のタイトルは煽ったわけではなくて、書籍にあわせた感じです。

多くの人は認知の歪みによって誤った理解をもとにした行動をするいきもので、著者はその中で重要とされる歪みを導く10の本能をまとめて、その1つ1つに対して

事例をもとに歪みを生む本能の説明
事実を元にして本能が歪んでいる事を説明
解決策を提示
まとめ

というスタイルで説明していっています。

雑にまとめると

認知の歪みを知ること
データを用いて歪みが歪みであったことを確認すること
- とはいえ数字だけではわからないこともあるので、現場を目にすることで事実も知ること
正しい前提を理解した上で必要な施策を立案し、対策すること

ということの重要性を伝えていることになります。
ネットで書評を読むと、信憑性に対して賛否両論あるようですが、大枠でこの考え自体は参考になると思ったので個人的には良書だと思いました。

そういえば最近読んだファーブル昆虫記でも、「ある昆虫があたかも人間と同じ心を持っているかのような振る舞いをしていること」に関する研究結果をみて自分で確かめたくなったファーブルが自身で実験を繰り返し、実はその振る舞いは心を持っているわけではない、ということを確認したエピソードがありました。※どの虫だか忘れてた。シデムシだったかな？

これも、バイアスをファクトで確認して認識を正す、というファクトフルな振る舞いなんでしょうね。

さて、本題です。
この書籍で紹介されている 10 の本能のうち 2 つだけ抜粋して組織に当てはめて考えてみることにしてみました。

10 の本能と組織

ネガティブ本能を抑えるには

悪いニュースのほうが広まりやすく、良いニュースは広まりにくい。
そのため、悪いイメージをいだきやすくなってしまう本能。

例えば、「運用エンジニア」のように、うまく運用していると周りからみて何も起こっていないように感じて感謝されにくい。
問題が発生した場合には、悪いイメージをもたれやすい。
これは「悪いニュースのほうが広まりやすく、良いニュースは広まりにくい」という状態だなと思います。

ちょうど、「運用☆ちゃん」でも似たような話がありました。

『運用☆ちゃん』～僕たちの平和を支える見えない守り神～Incident 000（序章） | リクナビNEXTジャーナル

ここで、不満のみをぶつけられている状況を見て何もせずほっておくという意思決定は、おそらく担当社員のエンゲージメントを下げることになるでしょう。

ここでは、成果が部外にもわかりやすくなるような事実を可視化する、社内広報で社内の様々な部署の仕事のつながりとそれぞれの役割の大切さを伝える、Kudo box など相互感謝が伝わる仕組みを導入する、などの施策が必要でしょう。

直線本能

グラフはまっすぐになるだろうという思い込み。
実際には様々な形になる。

例えば、技術的負債の影響を考えてみましょう。
短期的な利益のために必要な技術的負債を選択すること自体は間違いではありません。
ただ、そのあとの運用に関わる影響や、そこに関与する変数として所属する人への影響などを考えるとその負債の影響は直線よりもやや傾きを増しながら増えていくように思います。

例えば、循環的複雑度に着目した場合、

循環的複雑度	複雑さ	バグ混入率
10以下	シンプルなプログラム。リスクがほとんどない	25％
40以上	ほどほどの複雑さのコード。ややリスクがある	50％
50以上	かなり複雑なコード。リスクがある	70％
75以上	いかなる変更も誤修正を生む	98％

という状態はかなり急激に悪影響を及ぼしそうに見えます。
以下、引用元資料です。

循環的複雑度を活かしたバグ潜在リスクの軽減 - 現場のためのソフトウェア開発プロセス - たかのり日記

これに加えて、技術的負債の返済を先送りにし続けて負債が積み重なる環境には以下のような影響がでるはずです。

機能追加速度の低下
- プロダクトの進化が停滞しやすくなる
  - 売上が減る
  - 利益構造が悪くなる
  - 達成感が下がる
- 残業を増やして対応する
新しい技術スタックに変更できない
- セキュリティリスクが高まる
- 開発者のキャリア上のリスクになる

こういったサイクルが回り出し、

エンゲージメントの低下
エンジニアとしての労働環境の悪化

を招くことが想像できます。そうなると当然

エンゲージメントの低下・環境の悪化による離職率の向上
環境の悪化による採用難度の向上

という結果になります。
これらをすべて加味すると、その影響は直線ではないだろうということが想像できます。

これらを無視して「そうはいっても短期的な利益が大切だし、ビジネスのためなのでみんな我慢してくれるだろう」と負債の返却を見送る意思決定を繰り返すと・・・。

よりファクトフルな方法としては、これらを数字で表せることができるとよいのでしょう。
循環的複雑度等、コードの品質を計測できるもので常に計測可能な範囲の負債を可視化する。
さらにエンゲージメントの計測と、 1 on 1 による継続的な従業員モチベーションのモニタリングで、その影響が社員に出ていないかどうかを監視する。