📘

「エンジニアリング組織論への招待」を読んで

2022/01/08に公開

マネジメント

はじめに

「エンジニアリング組織論への招待」を読みました。
ITエンジニア本大賞2019 技術書部門大賞に選ばれ、各所で話題になっていた理由がよくわかる名著でした。
多くの人が抱える「なんとなくうまくいっていない気がする…」というモヤモヤ感を明確に言語化したうえで、それでは自分の場合はどうだろう、と自身の行動を顧みるきっかけをくれる本です。
非常に心に刺さる部分の多い本でしたので、気になった部分とその時考えたことを備忘録も兼ねてまとめました。

Chapter1 思考のリファクタリング

エンジニアリングとは

エンジニアリングの本質は「不確実性の効率的な削減」にある。何かを実現するにあたって「抽象的な指示」で要求を実現できる組織と、「具体的な指示」でしか要求を実現できない組織があるとすれば、前者はより大きな「不確実性」の処理ができる組織と言える。このような組織はそれぞれ「自己組織化（された組織）」、「マイクロマネジメント型組織」と呼ばれる。

不確実性について

不確実性には、環境不確実性（未来という不確実性）、通信不確実性（他人という不確実性）の2つがある。不確実性を削減するには、論理的思考の盲点を知ること、経験主義と仮説思考を知ること、システム思考を知ることなどが重要である。

論理的思考の盲点

論理的思考の前提として、事実を正しく認知することがあるが人間にはこれが難しい。
また、感情的になってしまう瞬間もある。

たとえば人は自分のアイデンティティの範囲を攻撃されると怒りを感じる。
アイデンティティの範囲には個人差があり、広い人は仲間思いに感じたり、あるいは怒りっぽく感じられることもある。

人間は必ずしも論理的に思考しないということを知り、「どんな時に非論理的な思考に陥るのか」に気付くことが大事。

情報の非対称性

同じ目的を持った集団でも、何かの情報を一方が知っていて、一方は知らないような状態がある。
そのような場合、自分は知っていることを相手は知らないかもしれないという前提を忘れてコミュニケーション不和が発生することがある。

限定合理性

個人的に最適な戦略が、全体にとって最適になるとは限らない。

経験主義と仮説思考を知ること。

経験主義とは、行動することによって不確実性を削減する考え方のこと。スクラムはこの主義に基づく。

この対極に位置するのが理性主義で、理性(理屈)によって判断すれば正しい結論に至ることができるという考え方。ウォーターフォールはこの主義に基づく。

仮説思考とは、この経験主義、理性主義のどちらにも当てはまらない考え方。
この仮説思考を用いて仮説検証すれば、より低コストに不確実性の削減が行えることがある（リアルオプション戦略）。

システム思考を知ること。

人は、問題を個人の責任にしたり、全体像を見失ってしまいがちである。
問題が、関係性にあるのではないかという視点を忘れないことが重要。

Chapter1 感想

自己組織化された組織とは、話題の「ティール組織」のことですね。「ティール組織」、ざっと概要だけしか把握していないのでまたしっかり読んでおきたいと思いつつ…。私自身はSIerで働いているわけですが、この「自己組織化」とは真逆の環境だな、変わっていかねばなるまいなと読書中つくづく感じました。

アイデンティティの範囲については思わず膝を打ってしまった…。同僚が古いテンプレートやツールを使っていたので「こっちのほうが使いやすいですよ」と勧めたら、ちょっと不機嫌になってしまって…みたいなこと、あるあるじゃないですか？そういう人は、そのツールやテンプレートで苦労した経験があったりして、思い入れがあって、アイデンティティをそこまで広げてしまっているんですね。

自分自身も、苦労して作ったアプリがレビューで色々指摘されると、頭ではわかっていても感情的にはムムッとなってしまう時があります…。特にレビューするときなんかは、気を付けよう。

「理性主義」に基づいたウォーターフォール開発…。新人の頃、否応なしに割振られたタスクとスケジュールを見ながら「これ、途中でトラブル起きたらどうなるんだろう？」なんて考えてたことを思い出します。こうしてみると、ウォーターフォール開発は不確実性のマネジメントを「バッファ」に全振りしてる感じでしょうかね（弊社だけ？）。

関連して「限定合理性」についてですが、まさに「あるある！」と叫びたくなるような内容。
私のかかわってきたプロジェクトだとPLや発注者はタスクの完了だけを見ていることが多いので、担当者には工数を過剰に見積もるインセンティブが発生します。さらに開発フェーズではコードレビューやユニットテストが採用されていないため、品質は許される限り低くなっていきます。負のインセンティブしかない…。

そもそも、普段の開発業務において開発者個人のレベルで成果物の品質を向上しようという試みはあまり必要とされませんし（それどころか、工数や既存機能と足並みそろえる等の理由でむしろ歓迎されないこともあります）開発者に対しては正の方向のインセンティブが働かないんですよね…。これは管理者(PL)が何か悪いということではなくて、仕組みがそうなっているような気がしています。

品質をより高く、期間をより短くする正の方向のインセンティブを上流工程だけでなく下流工程でも発生させられれば、かかわる全員がもっと幸せに働けるだろうにと思います。考えよう。

私自身がPLをやるときは余裕がなくともコードレビューはするようにしていて、問題点をあげつらうだけでなく、個人の小さい工夫を拾い上げられるように心がけています。開発者は言われた通りに作ってればいいんだ、っていう考えになってしまいがちな現状に対してのちょっとした抵抗です。

誰かのパフォーマンスが悪いとか、主体的に働いてくれないとか、そういう悩みを抱えたときは
その人の立場に立って、そういう風に振舞うことに合理性が生まれてしまっていないか考えてみるとよいですね。

Chapter2 メンタリングの技術

メンター/メンティの効果的な関係性

メンター制度を効果的に運用するには、
互いに弱さを見せられる謙虚な関係、互いに敬意を払う関係、お互いにメンティの成長期待を持っている信頼関係が重要である。

傾聴、可視化、リフレーミング

話を聞くときに、相手の感情への共感を表すこと。相手の話の内容を可視化すること。相手の思考の盲点を探索しながら質問すること。
これらに気を付けながら、相手の思考が整理されて前向きに考えられるように支援する意識を持ち会話をすることが重要。

心理的安全性

チームの生産性と深いかかわりがあるとされている。
対人リスクのある行動(問題点の指摘、失敗報告など)をとっても、関係性が損なわれることはないという信念がチームで共有されている状態のこと。
この状態だと、率直な対話が行われたり、責任感が向上したりといった良い影響がある。

心理的安全性を高める方法として、メンターが自身の失敗を開示したり、メンティに助言を求めることも効果的。

心理的安全性と責任感

メンターは、メンティをラーニングゾーン(心理的安全性高、責任感高)に導いて、成長を促す。
コンフォートゾーン（心理的安全性高、責任感低）だと生産性は上がらない。

心理的安全性とアクノレッジメント

メンタリングを効果的に行うために、メンターはメンティにアクノレッジメントを示し続ける必要がある。アクノレッジメントは「承認」を意味する。

「自分は相手のことを認めている」と思っても、それが具体的な行動を通じて相手に伝わっていなければ、アクノレッジメントは成立していないので注意。

アクノレッジメントには3つの段階があって、それぞれ以下の通り。

存在承認：相手が今ここに存在することがありがたいというメッセージ。笑顔で挨拶、前に行っていたことを覚えている、頑張っていることを励ますなど。
行動承認：ポジティブな行動をとった時に、言葉に出して伝える。行動が承認されているというメッセージを伝える。
結果承認：「すごい成果だね」など、主観とともに伝える。褒めると似ているが、それより範囲の広い承認行為ととらえる。

ジョハリの窓

まずは「自己開示」を行うことが必要。

内心ではなく行動に注目する

他人の内心は見ることはできない。見えないものはコントロールできない。
従って、「わかった？」は無意味な言葉だし、「心構えが甘い」というお叱りも無意味。

Chapter2 感想

所属企業にもメンター制度はあるのですが、優しい先輩と「最近どう？」みたいな毒にも薬にもならない会話をするだけの制度になってしまっています。別に悪くはないのですが、せっかく時間をかけるのだから、目的意識を持ってやったら効果高いのになあ…って思っていました。
メンタリングしてもらう側の立場でそんなことあんまり言えないよなという気持ちもあり…（心理的安全性が低いのか？）とりあえず、メンターの先輩に会ったときにこの本について話してみようかなと思います。

心理的安全性の話は数年前から流行っていますね。個人的にも非常に興味のあるテーマです。
アクノレッジメントの話、本文中にも書いてありましたが小学校で習うような「当たり前のこと」なんですよね。自分自身も、周りを見ても、第一段階の存在承認さえ充分にできていない気がします。
当たり前のことを当たり前にやるのが、意外に難しいものですね。

これを読んでから、人と話すときの笑顔、（ポジティブな）思ったことを口に出す、を心がけています、本当に。

Chapter3 アジャイルなチームの原理

アジャイル開発

ソフトウェアの大規模化・複雑化、マーケットの不確実性への対応のため発展した。日本国内は30～40、世界的には60～95％の普及率と大きく乖離。日本では納品契約を主体とした事業が大きく、7割以上のIT技術者がそれに参画しているため。

アジャイル開発は大規模プロジェクトに向かないというのは誤りで、むしろ真逆。

アジャイルは開発方式でなく、情報の不確実性が小さく、心理的安全性が高く、認知のゆがみが少なく…といった高い生産性を発揮できる状態であると考えるべき。

アジャイルソフトウェア開発宣言（従来重視されてきたもの⇒これから重視すべきもの）

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

Chapter3 感想

既にほかの書籍などを読み聞いたことがある話や、歴史の話が多かったので大幅に割愛しています。

「納品契約を主体とした事業」で働くエンジニアとして、受託開発案件にどのようにアジャイルを組み込めばいいのか頭を抱えています。アジャイルソフトウェア開発宣言の「従来重視されてきたもの」って、受託開発が重視する要素そのものですよね。アジャイルは開発方式ではないと考えれば、心理的安全性を高めたりといった施策もアジャイルを組み込んだと言えなくもないですけど…。

このチャプターではここが解決しなかったのでモヤモヤしてしまったんですが、後に何となくすっきりします。

Chapter4 学習するチームと不確実性マネジメント

スケジュールマネジメントの基本

スケジュール不安と、方法不確実性を削減するエンジニアリングである。
JUASの調査によれば、プロジェクトにかかわる期間は総作業時間の立方根に比例するとか。
総作業時間を人数で割ったものを理想工期、作業同士の依存関係による無駄を制限スラック、
見積もりの不確実性を吸収するための期間をプロジェクトバッファと呼ぶ。
できる限り早く、リリース可能日の予測精度を上げていくのがスケジュールマネジメントである。

制約

リソース制約ーこの作業はこの人にしかできない
依存制約ー作業間の依存関係
調整コスト

経験のないことを見積もる

その見積もりが、どの程度の確率で完了することを想定するのか？

エージェンシースラック

代理人が、依頼者より代理人個人の利益のために行動してしまうこと。
「さぼるほうが得。」
SIer出身のエンジニアが、見積もり通りには開発を進めるのだがどうにもパフォーマンスが出ていない気がする…などのとき、
経験上「納期に間に合わせること」へのプレッシャーが強く、悲観的な見積もりをしている。

スケジュール不安は見える化

低精度でも大丈夫なので、良い場合と悪い場合を見える化して経営判断をしやすくする。

スケジュール見積もりの各種アプローチ

CCPMアプローチ
多点見積もり
- 不安なタスクの順に問題解決することで、スケジュール不安を効果的に解消
相対見積もり
- 見積もりがノルマになってしまわないように
- 基準となるタスクをもとに相対的にタスクを見積もる
- プランニングポーカー
ヴェロシティ
- スプリント区切りでタスクの達成実績を数値化したもの
- 着地地点の予測に利用
- 相対見積もりを用いて測定する
  - 数値の大小は生産性との絶対的かかわりはない
- この値を目標にしたり、評価に使ったりする過ちは犯さない

不安に向き合う振り返り

振り返りは、参加者を絞り込まない。
不確実性に日々メンバーとともに向き合う。
不安を共有し、それに立ち向かうための場。

Chapter4 感想

アジャイルは開発手法ではない、がこのチャプターで腑に落ちました。
受託開発であってもこれらの不安への向き合い方は実践できますよね。

赤裸々な感想(まとまりなし)

スケジュール見積もりについて考えていて思ったが
そもそも、なぜ我々は「他の何を犠牲にしてでも納期だけは死守する」のだろうか。
システム開発がこんなにも納期にセンシティブである理由に、なにか真っ当なものがあるのか。
納期の優先順位が何より高い、というのはただの謎のしがらみなのではないか。
納期を守るために犠牲になるのはたいていソフトウェアの品質で、
納品物は時間をかけて作り上げられた包括的なドキュメント、手作業のテスト成績書とそのエビデンス、品質そこそこのソフトウェア。
「でもお客さん、この仕様でOKしたじゃないですか？」って言うために作るドキュメントって何なのか…
「顧客の課題を解決する」「顧客に価値を提供する」ということと、矛盾してはいないか。
この辺りをもっと会社の人と話し合えたらもっと我々良くなれそうだけど、伝え方が難しいな。

Chapter5 技術組織の力学とアーキテクチャ

組織の生産性

組織の生産性とは、組織の情報処理能力である。
理想的な情報処理能力の推移と、現実の情報処理能力の推移の差をコミュニケーションコストと呼ぶ。

権限と責任は表裏一体

不一致を起こすと、組織の情報処理能力は低下する。
権限はないのに、責任はある
権限はあるのに、責任はない
デリゲーションポーカーで権限移譲を面白く可視化できる。

技術的負債

開発者とその他のコミュニケーションのための言葉として使われ始めた。
「負債」という言葉のネガティブさが立場によって異なるので、しばしばコミュニケーションの非対称が発生する。
また技術的負債は目に見えないので、これも非対称の原因になる。

経営者とエンジニアの間で追加機能の見積もりに差が出るのは情報非対称性があるからで、
技術的負債はコミュニケーションの問題と言える。

根本的な問題が、個人の問題ではなく構造上の問題であることに気付けば、対立は消滅する。

Chapter5 感想

すごくいい言葉で終わって、読んでいた図書館でひとり涙ぐみました。
根本的な問題が構造にあると気付ければ、関わる人たちはその構造をなんとかするという同じ目標に立つ仲間になれるのかもしれません。
頑張ろう！2022年！