はじめに
読んだ。
エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング
- 作者: 広木大地
- 出版社/メーカー: 技術評論社
- 発売日: 2018/02/22
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (1件) を見る
一周普通に読んだあと、内容を咀嚼しながら読み返してメモしていたらかなり時間がかかってしまった。
本当はメモ＋自分の考えみたいなのをブログに書きたかったのだけど、もはやほとんど引用で引用の範囲超えるんじゃねぇかって感じなのでブログには自分の感想＋サマリを書く。読書メモはgistにあげた。
（エンジニアリング組織論への招待の）はじめに
僕は、この本の主張とまんま一緒というわけではないけれど、「ソフトウェア開発とは不安との戦いだ」ということを考えていた。
まぁこのつらみは、実際はオープンソース初心者が、オープンソースを使って問題解決するときの不安を書いただけ。
とはいえ、このときから、仕事をする上でに不安って強敵だなぁ、ということは思っていた。それはソフトウェアの不確実性もそうだし、自分が知らないことを学ぶ時の不安もそう。その不安が納期をズラしていく。
僕はその不安を解消するようにチームに対して行動してきた。「何か不安に思っていることはありますか？」と問うようにしてきた。だって不安なまま仕事をするのはつらいからだ。（僕がそうだったからだ）
...
本書の「はじめに」では、解決しなければいけない課題はコードだけではなく、人々の思考や組織、ビジネスの「構造」こそリファクタリングしなければならず、それこそがエンジニアリングの本質だ(p3)と述べている。
そして、これらの根源は、「わからない」ことに対する不安です。（略）先が見えないという「不確実性」をどう扱うかを知ることができれば、「不安」は「競争力」に変わります。エンジニアリングに必要な思考は、まさにこの不確実性を力に変えるという点なのです。（p3）
不確実性をターゲットに、組織の推進に変えることこそがエンジニアリングだというのが本書の主張であることは間違いない。
そして僕がこれまでフォーカスしてきたことも、当たらずとも遠からずだったな、と思った。僕が今読むべき本だな、と思った。
Chapter1 思考のリファクタリング
ソフトウェア開発は「不確実」なものを向き合うものとして語られています。あるシステムというモノを作るとき、それはどのように作られるのか、どういう機能が必要なのかは、誰にもわからないからです。それを他者とのコミュニケーションを通じて実現していく。間違いがないほうが難しい。
そんな中、「不確実性」と向き合うために、思考をリファクタリングしましょう、というのがこの章の主題。
不確実なものに向かうというのは、「不安」を伴います。「わからない」ということは、それだけで自分自身を脅かす可能性を考えてしまうからです(p17)
不確実＝不安は、自分も感じていたものだった。
そしてわからないものは「未来」と「他人」であるとしている。未来は、周囲の環境、ビジネス的な要件が変更することかもしれないし、社会が変わることかもしれない。それを環境不確実性と呼び、コミュニケーションを行って削減する「他人」の不安を通信不確実性と呼んでいる。この分類は後でもよくでてくるのでおさえておく。
「コミュニケーション」「行動と観察」によって2つの不確実を削減して得た「情報」を持って、不確実は確実に近く。これを「エンジニアリング」の本質にあると述べている。
僕はよく、入社して2年ほど経った頃「仕事ってのはよくわからんことをガチャガチャ調べてなんとなくわかったかのようなことを言うことだ」なんて言ってたけど、あながち間違ってなかったと思います。
また、p19では「仕事と学力テスト」の違いを取り上げて、学力テストは決して「不確実なものを確実にする」力は必要とされていないことを指摘している。学力テストは原理原則、あるいは出題から帰納的なり演繹的なり正解を導き出す力が必要だ。不確実性を下げる能力はそもそも答えが決まっていないし、答えを得るために必要な情報も与えられているとも限らない。解く人数も1人ではない。
経験主義と仮説思考
仕事を進めるにはこの2つの考え方が必要であると述べている。
- 足りない情報を自分自身で集め、確かめ、検証、考察し、その結果から解決を行う「経験主義」
- 限定された情報から、全体像を想定し答えを導き出す「仮説思考」
ニュートン以来の科学哲学の根底を支えると同時に、「アジャイル」や「リーン」といった現代的なソフトウェア開発プロセスの基礎的な価値観として参照されています。(p22)
だからプロフェッショナルは2割の時間で8割終えて、不確実性を初期に下げようとする。
コントロールできるかできないか、観測できるかできないか。この4象限で物事を考え、「やってみなければわからない」だけの論理ではなく、「コントロールできるもの」を操作し、「観測できるもの」の結果をみることでしか、前に進むことができないことを意味しているのです（p42）
これ本当にそうで、僕はこれまで仕事で詰まった時に「まずはやってみるしかない、だってわからないんだもん」で進んできて、それで解決した部分もあるけど、何かコントロールできて何か観察できるかまで考えられてなかったなぁと思う。
経験思考と仮説主義により、問題を明晰化することが、不確実性の減少のために必要です。逆に、問題を正しく理解できていれば、それを解決することはきっと簡単。確かになぁ。
1章まとめ
まず、エンジニアリングとは「分からないものを分かるようにすること」、つまり不確実性を削減することそのものである。
そのための出発点として、人間の思考をリファクタリングするための3つの観点を紹介した。
- 論理的思考の盲点 … 論理的思考を正しく行うためには自分の認知のくせをつかむ必要がある
- 経験主義と仮説思考 … 不確実な仕事を前に進めるための2つの考え方
- 全体論とシステム思考 … 不確実な問題を解決するために、システム的に物事が関連していることを理解すること
上記のコアとなる考え方に加え、コミュニケーションの不確実性として、「情報の非対称性」「限定合理性」が発生してしまう。これらをできる限りなくしていくことも、チームとして大切なことだ。
以降の章は簡単に内容を紹介するにとどめておく。
Chapter2 メンタリングの技術
第2章のメンタリング技術を読んでいく。1章ではそもそもソフトウェア開発ではどのような不確実性が存在するのかを考えた。2章では不確実性の1つである人間相手にどのようにメンタリングしていくかを考えていく。
まずメンタリングとは何か。対話を通じて、メンタリングする人の思考力を一時的に貸し出し、思考の幅を広げていくことで、その人の歪んだ認知を補正し、次の行動を促し、成長させていく手法（p75）とある。
なぜメンタリングが必要かというと、ソフトウェア開発で個人が様々な問題にぶつかったとき、個人が本来発揮出来る実力を出せなくなってしまった場合、チームとしての生産性が低下するからだ。だからチームリーダーはチームメンバーを正しくメンタリングする必要がある。
メンタリングのゴールのmemberが自分自身で自律的に行動できることとし、傾聴・可視化・リフレーミングというテクニックを紹介している。
Chapter3 アジャイルなチームの原理
これまで、「思考のリファクタリング」「メンタリングの技術」と来て、エンジニアリングという不確実性を最小化する行為において、メンタリングが重要であるという話だった。ア ジャイルというプラクティスもまた、ソフトウェアの開発手法ではなく、メンタリング手法の一種であるという主張をしている本章を追いかける。
アジャイルを歴史的に振り返り、チームをメンタリングする技術、あるいはフレームワークであるということを述べている。アジャイルへのよくある誤解を通じて、そもそもアジャイルは状態であり、手法（だけ）ではないことを強調している。
Chapter4 学習するチームと不確実性マネジメント
存在する不確実性とどう向き合い、どうチームとして解決するかにフォーカスしている。
- 3つの不確実性
- 方法不確実性 … スケジュール予測と見積もりの手法
- 目的不確実性 … 要求と仮説検証の手法
- 通信不確実性 … 振り返りの手法
これら不確実なものに向き合うと、ひとは「不安」が生まれ、それを隠してしまう。不安によって隠れた不確実性をリストアップし、それらを比較しなければならない。
ここで出てくるプラクティスがアジャイルで出てくるプラクティスであるため、アジャイルがいかに不安と向き合うフレームワークであるかということがこの章からもわかる。
Chapter5 技術組織の力学とアーキテクチャ
最後の章ではこれまで考えてきた「チーム」か広げ、組織という枠で不確実性のマネジメントを考える。
技術的負債というものを取り上げ、技術的負債は実は経営層とエンジニア間での情報の非対称性であることを指摘する。
また、技術的負債と同じ見えないものであり、プラスの価値を引き出すものとしてシステムアーキテクチャを取り上げる。コンウェイの法則に習うと、システムアーキテクチャと組織設計は「似ている」のではなく本質的に同じものである。
| システム | 企業活動 | |
|---|---|---|
| 動きやすい仕事 | 影響範囲が限定されていて、変更しやすい部分の機能開発 | 権限が異常され、ゴール認識が高い |
| 動きにくい仕事 | 影響範囲が広く、変更しにくい箇所の機能開発 | 権限のレベルを超えて、取引コストが高い |
| 決定要因 | アーキテクチャ | 組織構造 |
アーキテクチャと組織構造はお互いに影響を与え合う。アーキテクチャと組織構造の関係に対して理解し、コミュニケーションを通じて、アーキテクチャと組織構造の両方をビジネスの向かうべき方向に一致する（p293）必要がある。
組織構造も、アーキテクチャも「構造」が与える力は見えづらい。必要なのは妥協でも、政治でも、卓越した技術力でもなく、組織やビジネス、プロセス、そしてシステムへの「エンジニアリング」が必要である、ということで本書を締めくくる。
おわりに
この本の何がすごいかって、一貫してソフトウェア開発における問題は「不確実性」にあり、その不確実性を人間と環境の不確実性に分類したこと。そしてコミュニケーションの不確実性を解決するために「個人へのメンタリング（Chapter2）」「チームにおける不確実性の解消（Chapter3）」「不確実性をマネジメントするアプローチ（Chapter4）」「組織の不確実性の解消（Chapter5）」という流れである。この一貫性が見事だ。
さらに、１つ１つのテーマについて、膨大な文献から、歴史的に紐解いているところも見事。知の巨人とはこういうことなのかと思い知った。知的好奇心モンスターですわ。著者のリファレンス記事を見てさらに驚く。
https://qiita.com/hirokidaichi/items/195d42ee056ea85a3150
この内容ボリュームに対して、サイズ自体は意外とコンパクトなのもすごい。
僕自身は、関わってきた規模から「チームに対する不確実性の解消」しか経験としてない。もがきながらやってきたアプローチは間違ってなかったんだなぁというのをこの本に肯定された気分。今後はSREチームとして、これまでより広い視野でプロダクト開発に関わっていく。組織構造やビジネス価値といった視点も持ちながら働いていきたい。
やっぱり「マネジメントだけ」「技術だけ」はありえないんだなぁと、思った。どっちもエンジニアリングなんだぜ、ということ。そしてその鍵はコミュニケーションなんだぜ、ということ。昔から漠然と思っていたことを言語化してもらえてすっきりした。いい本です。本当におすすめ。
