今回読んだ本はこれ
エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング Kindle版 - Amazon アフィリエイトリンク
Chapter 1 - 思考のリファクタリング
個人の話
「エンジニアリング」とは
「実現の科学」といえる
要求に含まれる「曖昧さ」を減らして、実際のものとして具体化する（「具体性・明確さ」を増やす）行為
「不確実性を削減し、秩序を作る」
3 つの不確実性
- （環境不確実性）
- 方法不確実性
- 目的不確実性
- 通信不確実性（＝コミュニケーション不確実性）
重要な考え方
「どうしたら効率よく不確実性を減らしていけるのか」
人間にとってわからないことは「未来（環境不確実性）」と「他人（通信不確実性）」の 2 つなので、これらを少しでも減らしていくことが「実現」させる手段
わからないことをわかるようにするためには、情報を生み出すことが大事
これがエンジニアリング活動の本質の 1 つ
3 つの思考
- 論理的思考の盲点を知る
- 経験主義・仮説思考
- システム思考
これら 3 つの思考を使って、複雑な問題を簡単な問題に変換していくことを「思考のリファクタリング」と呼んでいる。
論理的思考の盲点を知る
論理的思考＝演繹的思考
ルールと事象から結果を導く
- ルールと事象を正しく認知できること
- 正しく演繹できること
これらが満たされない場合は正しくない結論が導かれてしまう
人間が正しく論理的に思考するためには
- 事実を正しく認知するために、いつ認知が歪むのかを知る
- 感情にとらわれず判断する
- 非論理的に考えてしまう瞬間を知る
- 人間は正しく事実を認知できないことを知る
経験主義・仮説思考
わからないことは確かめるしかない
未来が不確実なら、それを現在にするしかない
つまり、行動して結果を確かめてみるしかない
はい PDCA
「行動できることは何か」「行動の結果、起きたことを観察できるか」という視点が大事
コントロールできないものをコントロールしようとしても無駄
問題が明晰になっていないから解決できない
仮説を立てて検証することで、問題が明晰になって解決できるようになる
という考えを持とう
システム思考
「システム」とは、「要素同士が関係性を持つ一つのまとまり」※雑訳
関係性に注目して問題の構造を解き明かす考え方が、システム思考
一部分だけしか見ないと、局所最適のぶつかり合いが起きてしまう
それは見方の違いに起因するので、全体の関係性をちゃんと見よう
そのための考え方として、視野・視座・視点がある
結局、問題解決よりも問題発見のほうが難しい
人間の不完全さを受け入れる
3 つの思考はあくまでパッチ
不完全だということを知っていれば、自身の過ちに気づきやすくなる
特にコミュニケーションは不確実性が高い
Chapter 2 - メンタリングの技術
1 対 1 の人間関係の話
メンタリングとは
対話を通じてメンタリングする人（メンター）の思考力をメンタリングされる人（メンティー）に一時的に貸し出し、思考の幅を広げることで、その人の歪んだ認知を補正し、成長させていく手法
思考のリファクタリングの考え方をメンティーに適用することで、問題解決の力を育む
「自ら考える人材を作る」テクニック
メンタリングのテクニックが必要になるエンジニアリング活動の例
- コードレビュー
- ペアプロ
- 障害時ハンドリング
- チームマネジメント
メンターが行うこと
ある問題を、メンティにとって「答えはわからない」が「明確に次にすべき行動がわかる」状態に持っていくこと
メンターの解答はいらない
自律的な解決に導くだけ
パズルを一緒になって解くのではなく、解けるようにサポートする
メンターの解答はいらない
メンターは答えを出すな
- 傾聴
- 可視化
- リフレーミング
傾聴
相手の思考が整理され、前向きに考えられるように支援しつつ、会話を行う
メンティーの不安に共感するフェーズ
可視化
十分共感できると、少しずつ「問題の形」が見えてくる
これを感情から切り離して、客観的な問題へと変換していく
「問題の形」を何かしらに書き出して可視化することで、問題 vs 自分たちという構造にできる
同時に「明晰化」もしていく必要がある
- 事実と意見を分ける
- フォーカスポイント（焦点）をはっきりさせる
- 要素を分解して問題の範囲を限定し、順番に確認していく
- 衝突から比較可能への変換
- 悩んでいる＝いくつかの選択肢が比べられない
- 「パズルを解けるようにする」こと
リフレーミング
認知の枠組みを「認知フレーム」と呼び、その外側を「心理的な盲点」という
リフレーミング＝認知フレームを変えることで、問題解決を図る
特定のキーワードが会話中に出てくると、認知フレームが発見できるかもしれない
キーワードがなくても、前提を問うような質問を投げかけるといい
「◯◯が〜〜なのは、そもそもなんででしたっけ？」など
つまり、「この前提が必要」というフレームに囚われてしまっているので、それを外すイメージ
情報の非対称性によっても認知フレームが作られてしまう
心理的安全性
心理的安全性が高い状態とは、「対人リスクを伴う行動が増えている状態」のこと
対人リスクを伴う行動とは、個々人の関係性が損なわれる可能性のある行動のこと
例えば問題点の指摘、自分の弱みの開示、失敗の報告
この行動が取れるということは、相手との関係性は決して崩れないという確信がある
心理的安全性が高いと、問題に対して向き合う状況を生み出し、問題解決ができる
メンタリングにおいては心理的安全性が高い状態を構築していく必要がある
弱さや失敗が開示されることで、課題がはっきりしていく
Acknowledgement
承認
「存在承認」「行動承認」「結果承認」の 3 段階がある
メンティーを承認しているというメッセージを発し続ける必要がある
ストーリーテリング
抽象的な伝えたいことをわかりやすく理解してもらうために、実際にあった経験を物語として相手に追体験させ、理解を深めてもらうために「語る」手法のこと
重要なこと
「自己開示」：苦労や感情を包み隠さず伝えて感情を共有する
「価値観を共有」：同じ価値観を持つことの重要性を理解してくれる
ジョハリの窓
「自己開示」と「フィードバック」を受ける状況があって初めて開放の窓が広がる（未知の窓にアプローチできる）、つまり成長することを表している
行動に注目する
メンティーの内心は直接観察できない、行動を観察する
行動ができていないときは、その理由を突き止める
メンタルの問題にしない
メンターとメンティーで次の行動を合意するときは、 SMART というフレームワークを使うといい
「次にどんな行動をするか」以外の観測不可能な合意を取らないようにする
セルフマスタリー
メンタリングが進んでいくと、メンティーは自分自身をメンタリングできるようになる
これが「自ら考える人材」になったということで、「セルフマスタリー（自己熟達）」を得たと言える
そのために、メンターは「ゴール認識」させることが重要
漠然とした「◯◯だったらなぁ」から「◯◯になっている」というゴール認識まで持っていく
未来に行って見てきたような確信を持っていることから、「ゴールへのタイムマシンに乗った」状態と表現している
Chapter 3 - アジャイルなチームの原理
チームにおける不確実性の削減の話
自己組織化されたチーム
Chapter 2 までのやつは個人だった
これをチームに応用する
チームは自分のチームをメンタリングできるようになる＝チームマスタリーがある状態＝チームがアジャイルという状態にある
これを自己組織化されたチームと呼ぶ
ちなみにチームの全員がセルフマスタリーを獲得していなくてもいい
理想的な状態にはたどり着けないので、常に「どのようにしたら、もっと不確実性を減らせるだろうか」という問いを考え続ける
ウォーターフォールとの違い
プロジェクトマネジメントは、環境不確実性の中の「方法不確実性」と「目的不確実性」の一部をスコープとしているが、アジャイルなチームのスコープは「方法不確実性」「目的不確実性」「通信不確実性」のすべて
これにより、限定合理性と情報の非対称性をクリアしようとしている
だから一概に比べられない
アジャイルの歴史
はスキップ
Chapter 4 - 学習するチームと不確実性マネジメント
削減すべき不確実性を可視化する必要がある
- 方法不確実性 → スケジュール予測と見積もりの手法
- 目的不確実性 → 要求と仮説検証の手法
- 通信不確実性 → 振り返りの手法
をそれぞれ解説している
スクラム開発で一般におすすめされている手法が書いてある
Chapter 5 - 技術組織の力学とアーキテクチャ
組織における不確実性の削減の話
生産性を向上させるには
コミュニケーションコストが増大するのが足を引っ張っている
だから、組織全体でコミュニケーションの改善が必要で、その構造をリファクタリングしていく必要がある
- 権限の委譲と期待値調整
- 適切な組織・コミュニケーション・外部リソース調達の設計
- 全体感のあるゴールの設定と透明性の確保
- 技術的負債の可視化
権限委譲とアカウンタビリティ
権限が不明な状態は、上司の胸先三寸で差配できる＝最も不自由な状態
権限が移譲されていないと、持っている権限内のことしかできないので、マイクロマネジメントが必要になる
それは上司の処理能力に依存するため、結果的に情報処理能力が低い組織となる
権限委譲にはレベルがある
デリゲーションポーカーで権限の認識合わせをしてみるのもいい
- レベル 1：命令する
- レベル 2：説得する
- レベル 3：相談する
- レベル 4：合意する（ここで上司と部下の権限が同じになる）
- レベル 5：助言する
- レベル 6：尋ねる
- レベル 7：委任する
責任と権限は衝突する
例えば、品質を下げれば売上が上昇するという見込みがある人と、品質への責任がある人と衝突する
その場合は上位組織で解決されるが、それがどこまでエスカレーションされるかというのが「衝突の解消レベル」
エスカレーション階数が少ない＝解消レベルの低い問題にすることが肝要
解消レベルを抑えるには、コミュニケーションパターンの見直しが必要
「相互依存の同一化」→「事業とプロセスの同一化」→「戦略の同一化」
組織設計のポイントのまとめ
- 明示的な権限と責任の委譲を行う
- 権限と責任の不一致をなくす
- 権限同士の衝突を最小にする
- 権限の衝突解消レベルを最小にする
技術的負債の可視化
負債＝借り入れと考えると、別に悪いことだけじゃないな、と思われてしまう
アナロジーがよくない説もある
（とはいえ、経営者ならこういったアナロジーで物事の本質を捉えた気にならないでほしいとは思う）
技術的負債を「技術的負債」と呼ばせている原因
- 追加機能の情報非対称性
- 理想的なシステムと現実のシステムの差から技術的負債を計算しようとした
- 理想的なシステムに対する認識が経営者とエンジニアで異なると、計算がうまくいかない
- アーキテクチャが見えないという情報非対称性
- 技術的負債は、エンジニア以外からは見えない
幽霊の正体見たり枯れ尾花、見えてしまえば技術的負債ではなく、タスクの積み重ねでしかない
そのためには以下が必要
- エンジニアから経営者へのコミュニケーション（アーキテクチャの複雑性）
- 循環的複雑度とか
- 経営者からエンジニアへのコミュニケーション（将来要件の複雑性）
- ユビキタス言語の作成
- 非機能要件の可視化
- 仮説と戦略の可視化
取引コストと組織論
取引コスト理論というのがあるらしい
↑は 3 つに分類されるというもの
- 探索のコスト
- 交渉のコスト
- 監督のコスト
内部でのやり取りは取引コストが低いはずだが、独立した限定合理性を持っていると高くなる
エンジニアリング部門を独立させると、外部との取引と似たようなことが起こってしまう
そこで、機能横断チームを作ることで取引コストを最小限にして、意思決定のスピードと高いコミット意識を持つ状態にできる
目標管理と透明性
目標≠ノルマ
「目標による管理およびセルフコントロール」とあるように、内発的動機付けが重要
個人の目標設定を局所最適にしないために、OKR が活用されている
ちゃんと目標を伝える必要がある（透明性の確保）
同時に、みんなちゃんと理解できている必要があり、それをマネージャーは促すべき
信頼関係の構築が必要
Chapter 6 - 組織設計とアーキテクチャ
企業活動は、市場に存在する不確実性と、複数人の組織のコミュニケーションの不確実性とを相手にした「エンジニアリング」である
システムアーキテクチャと組織設計は、本質的に同じものである
どちらもビジネスを活発に行うための構造
逆コンウェイ作戦でいいアーキテクチャに変えていこう
マイクロサービス化もいいと思うよ
感想
「システム」の説明を考えたことがなかったので面白かった
「エンジニアリング」も然り
不確実性を減らすために、情報を生み出す
なるほどね〜
特に最近知りたかったことが Chapter 2 で、メンタリングの考え方・技術が参考になった
メンターは答えを出すのが仕事じゃない、解きほぐすことが重要
実際ちょっと試して効果があった
やっぱり人間に感情というものは早かったんや……
心理的安全性を「対人リスクを伴う行動が増えている状態」って言われると急にわかるようになってくるな
「コントロールできないものをコントロールしようとしても無駄」という話は林修先生が話してた「定数ではなく変数を動かす」という話やんな
このリンクの中の動画もおもろいから見て
Chapter 3 からは組織の話だけど、個人を対象とした「セルフマスタリー」がそのままチームにも応用できるのが目から鱗だった
スクラムは不確実性を減らすための方法だっていうのは知ってたけど、改めて読んで解像度が上がった
スクラムガイドをちゃんと読んでおきたくなった
Chapter 5、目標は最近自分の中でホットだったから嬉しい
でも能力開発目標には活かしづらいな
OKR は企業全体で 1 つの木になるようにつくる
……となっているが、最近はこれはアンチパターンになっているっぽい
カスケードではなくアラインすべきみたいに言われている
総括としては、全体的におもろかったなと
個人の話も参考になったし、それがチームにも応用できるのが面白い
たくさん参考にできるけど、今心に刻んでおくことは
メンターは答えを出すな
