「エンジニアリング組織論への招待」[2018, 広木 大地]を読み始めました．
概要・まとめ
全体感
エンジニアリング組織論とは，本文によると「不確実性に向き合う」というたった１つの原則から，エンジニアリング問題の解決方法を体系的に捉える組織論です．
なので，5 つの CHAPTER で順番に不確実性について記述しています．
抽象的な説明から，具体的な説明が５回続きます．
CHAPTER 1 思考のリファクタリング
CHAPTER 2 メンタリングの技術
CHAPTER 3 アジャイルなチームの原理
CHAPTER 4 学習するチームと不確実性マネジメント
CHAPTER 5 技術組織の力学とアーキテクチャ
不確実性への対処方法を
個人の話，対話の話，チームの話(アジャイルとマネジメント)，組織の話
という順番で進んでいきます．
まとめ
CHAPTER 1 思考のリファクタリング
「思考のリファクタリング」」とは，「不確実性に向き合う」考え方．
エンジニアリングとは「実現」の科学
「実現」のはじめとおわり
ソフトウェアにおける実現とは，「曖昧さ」を減らし，「具体性・明確さ」を増やす行為
人間が正しく論理的に思考するには，以下の二つが必要
- 事実を正しく認知できる
- 感情にとらわれず判断できる
非論理的に考えない=論理的に考える 「人は正しく事実を認知できない．」ことを認知する
不確実性は，「未来」と「他人」である 「未来」=環境不確実性 -> 経験主義．仮説思考で対処する 「他人」=通信不確実性 -> コミュニケーションで対処する
- 情報の非対称性
- 同じ目的をもった集団で，何かの情報を片方の人が知っていて，もう片方がしらない状態
- 限定合理性
- 認知範囲や能力の限界から，限られた範囲でしか合理的な行動が取れない性質
- 個人的に最適な戦略が，全体にとって最適になるとは限らない
真に組織に求められるコミュニケーション能力とは，コミュニケーションの不確実性を減少させる能力のこと
CHAPTER 2 メンタリングの技術
「思考のリファクタリング」の考えかたを使い，対象となる人自体の考え方をすこしずつ変えることで，問題解決の力を育みます．
効果的なメンター・メンティの関係性
- 謙虚；お互いに弱さを見せられる
- 敬意：お互いに敬意を持っている
- 信頼：お互いにメンティ（自身）の成長期待を持っている
心理的安全性と責任による４つのメトリックス
メンティをラーニングゾーンに運ことがメンターの役割
ジャハリの窓
- 開放の窓 自分はわかっている，他人はわかっている
- 盲点の窓 自分はわかっていない，他人はわかっている
- 秘密の窓 自分はわかっている，他人はわかっていない
- 未知の窓 自分はわかっていない，他人はわかっていない
能力と成果はコントロールできない
習慣と行動はコントロールできる
CHAPTER 3 アジャイルなチームの原理
「アジャイル開発」はチーム全体に対してメンタリングを行い開発出力を向上させる方法論
「ソフトウェアをどのように作るか？」はアジャイルの主眼ではない
日本では，アジャイル実践者の数が圧倒的に少ない
アジャイル開発が必要とされた２つの理由
- ソフトウェアが大規模化・複雑化
- マーケットの複雑性に対応する
スケジュールとマーケットという２つの不安
- 目的不確実性
- 方法不確実性
アジャイルであるとは，
- 情報の非対称性が小さい
- 認知の歪みが少ない
- チームより小さい限定合理性が働かない
- 対人リスクを取れていて心理的安全性が高い
- 課題・不安に向き合い不確実性の削減が効率よくできている
- チーム全体のゴール認識レベルが高い
アジャイルな方法論
- 不安に向き合うこと
- 少人数の対話を重視する
- 役割を分けない
- 経験のみを知識に変える
- 意思決定を遅延する
- 価値の流れを最適化する
アジャイルの起点は「アジャイルへ至るために，私たちは何をすべきか」「どうしたら，もっとチームの抱える不確実性を減らしていけるのか」考えること
「アジャイルな方法論」を「チームメンタリング」する
「脱構築」とは，対話により自分たちの対立を解消し，再構築すること
外でうまくいっているなにかを探し出すことではなく，しっかりと自分たちをとりまく環境を観察すること，そして何か流行りのかっこよさを教条的に取り入れるのではなく，今何をすべきかをしっかりと周囲に対話していくこと．
それが，チームをアジャイルにする最も効率的な道
CHAPTER 4 学習するチームと不確実性マネジメント
不確実性マネジメント
不確実性とは
- 方法不確実性:スケジュール予測と見積もりの手法
- 目的不確実性:要求と仮説検証の手法
- 通信不確実性:振り返りの手法
スケジュール予測と不確実性
スケジュールマネジメントの基本
- 制約スラックを削減する
- 見積もりの予測可能性をあげる
- プロジェクトバッファの消費を可視化する
役割
不安への対処
- 目的不確実性にともなうマーケット不安に向き合う
- 方法不確実性にともなうスケジュール不安に向き合う
- 通信不確実性にともなう「情報の非対称性」を減らす
チームの学習
- スプリント計画
- デイリースクラム
- スプリントレビュー
- レトロスペクティブ
ゴール認識にはインセプションデッキを使う
権限と情報処理能力
上司のみが権限を持ち，部下に具体的で細かい指示をださなければならない組織は，情報処理能力が低い
部下にも権限があり，抽象的で自由度のある指示をだせる組織は，情報処理能力が高い
権限と組織設計からみる組織設計のポイント
- 明示的な権限と責任の委譲を行う
- 権限と責任の不一致をなくす
- 権限動詞の衝突を最小にする
- 権限の衝突解消レベルを最小にする
技術的負債
最初のコードを出荷することは，借金をしにいくのと同じである．
負債が生まれる．その時の利息によっては借金に頭を抱えることになる．
システム開発は「何かをできる機能を作る」ということと同時に，「何かができないところを作る」という作業であるという理解が必要不可欠．
イメージとしては，「ジェンガ」
以下の心情はありえない
「今は急いでいるから，早いけど将来困りそうなコードを書こう」
「今は時間があるから将来を見越したコードを書こう」
「見ることができない」という非対称性が，技術的負債が問題になる最大の理由
以下が技術的負債が生まれる２つの情報非対称性．これらを対処できないのがコミュニケーションそのものに原因がある．
- 追加機能の情報非対称性
- アーキテクチャが見えないという情報非対称性
技術的負債の可視化には「アーキテクチャの複雑性」と「将来要件の不確実性」に対処する必要がある．
アーキテクチャの複雑性には以下で対処する
- 循環複雑度の可視化
- 依存関係の分析
- コードチャーンの分析
将来要件の不確実性
- 非機能要件の具体化
- 仮説・戦略の透明化
- ユビキタス言語の作成
CHAPTER 5 技術組織の力学とアーキテクチャ
組織設計とアーキテクチャ
取引コストが高く情報処理能力が低い組織では「コンウェイの法則」から，技術的負債が生まれる 「逆コンウェイの法則」により，取引コストが低く情報処理能力が高い組織になる
マイクロサービスアーキテクチャ
マイクロサービスアーキテクチャにより，切り離した組織とシステムを作ることができるが，無理な導入にはデメリットもある．
マイクロサービスの特徴
- サービスによるコンポーネント化
- 分散ガバナンス
- スマートエンドポイント
- 分散データ管理
- プロジェクトではなくプロダクト
- インフラ自動化
- 進化的設計
- ビジネスケイバビリティによるチーム化
- 失敗のための設計
エンジニアリングカンパニー
構造上の問題は，誰かのせいでないのと同じぐらい，私たち自身を含んだ全員の責任でもある
解決すべき問題はその姿が見えてしまえば，「悩み」は「考える」に変わる
必要なのはシステムの「エンジニアリング」
所感
組織論について書籍で読んだことがなかったのと，4 月から新社会人になり組織について気になったのでジャケット買いした本です． 「不確実性」への対処がこの本で一貫したテーマなので，込み入った話をしていても頭の片隅に置いておくと読みやすいです．
新卒エンジニアでも，読んでいて学びの多い本なので読むタイミングは選ばない本だと思います．強いて言うなら働き方や将来像に対して「不安」を感じたときに読むのがベストかもしれません．
個人であっても，複数人であっても，チームや組織であっても，「不安」に駆り立てられないときはないと思います．
そこで，この本に書いてある通り，見えないものを見えるように行動することで，不安ではなくなり，悩みは考えるへと変化します．
それは，技術的なことでも，経営においても，アジャイルにおいても同様です．
見えないから不安であり，情報が非対称だから思い通りにならないことが一貫してかかれています．
この本の良いところは，個人から集団へとシフトして説明していくことだと思います．
そのおかげで，大体の立場において通じる考えを得ることができる本となっています．
不確実性を対処できることが，「エンジニアリング」ということを考えると全てのエンジニアが目指す像はこれなのかもしれない，と思いました．
