[読書メモ] エンジニアリング組織論への招待

TL;DR

広木 大地氏の名著、 エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリングに関する読書メモです

概要.

プログラムのバグは自然発生するのではなく、人間が生む
問題解決のためには、コードだけでなく、人々の思考・組織・ビジネスの構造のリファクタリングが必要
分からないことに向き合い、不確実性をリファクタリングし、問題解決方法を本質的に捉える

思考のリファクタリング

人間が本来理解できないものは、「他人」と「未来」

情報を生むことで不確実性を下げる

• 「他人」；通信不確実性
  • 私はあなたではない
  • いくつもの不確実性
    • 他者理解；人は他人や事象を完全には理解できない
    • 伝達；コミュニケーションが到達するとは限らない
    • 成果；仮に理解されたとしても、予想された行動を取るとは限らない
  • その結果生まれるもの
    • 情報の非対称性；知っている人・知らない人の分断
    • 限定合理性；自分にとっての正解が全体の正解にならない
• 「未来」；環境不確実性
  • 仮説検証のサイクルを回すことで、情報の正しさを検証する
  • リアルオプション戦略・遅延した意思決定
    • 不確実性が大きい段階で大きなプロジェクトを走らせると、失敗した場合に予算全てが無駄になるかもしれない
    • 仮説を立てて少ない予算で仮説を検証し、検証が完了するまで大きな投資をせず大きな意思決定を意図的に遅延させる手法
• 論理的思考の盲点
  • 演繹的：スタートから順に組み立てる
  • 帰納的：ゴールから逆算する
  • 自分や他人が非論理的になる瞬間を知る
    • 怒りが発生しているときこそ「自分が何を大切にしているのか」を知ることが出来る
      • 怒りっぽい人はアイデンティティの幅が広く、なかなか怒らない人は自分自身の範囲が狭く、攻撃的な言葉も攻撃と感じない。ある意味で関心の幅が狭い。
    • 怒りを感じたときは、悲しみとして相手に伝える
      • 「それは自分にとって大切なことなので、その発言は大事なものをぞんざいに扱われたようで悲しいです」
  • 事実と認知は別
    • ベーコンの４つのイドラ
      • 種族のイドラ
        • 人間が本来持つ性質から生じる錯覚・偏見
        • 「遠くに有るものが小さく見える」「暗い場所では物がはっきり見えない」
      • 洞窟のイドラ
        • 個々の環境起因で外の世界を知らずに決めつけてしまうこと
      • 市場のイドラ
        • 言葉の不適切な使用から生じる誤解や偏見
        • ありえない噂話を信じてしまう
      • 劇場のイドラ
        • 伝統や権威を無批判に受け入れて、誤った考えでも信じてしまうこと
    • 認知の歪み
      • 一般化のしすぎ；主語が大きい
        • レッテル貼り
      • ゼロイチ思考；二者択一
      • すべき思考；ルールの背景を本質的に理解せず批判するなど
      • 選択的注目；人は見たいものだけ見る
      • 結論の飛躍；既読スルーされているから嫌われている
      • 感情の理由付け；「あの人が嫌い」→「あの人は無価値」
  • 自分の知性に対する絶え間ない疑いと、自分自身への洞察力
• 経験主義・仮説思考
  • 経験主義
    • 分からないことは行動で突き止める
    • 何が分かれば理解したことになるのかを定義し、それを確かめる
  • 仮説思考
    • 観測できないものは制御できない
    • 僅かな痕跡から行動に移す、跳躍した判断が大事
    • データから意思決定するのではなく、データからそれを確かめる行動を取る
• システム思考
  • 時間と資源の制約の中でより正解に近づく手を打ち続けること
  • 何が正解かを自分で設定する
  • より広い視野で問題の本質を捉える
  • 物事をツリー構造ではなくネットワーク構造として捉えて、それぞれは非線形的な関係性を持つ
  • どんな基準で判断すべきかを決める。一番のビジョンを明確にする。
  • 立場が違う人達が集まる議論は、それぞれの役割によって全体像を見失うことがある。全員が少しずつ正しく、少しずつ間違っている。
  • 視野、視座、視点
    • 視野；同時に把握できる領域の広さ
    • 視座；どこから眺めるか
      • 高すぎるとミクロな解決案を提示できない。
    • 視点；鋭さ、凡庸さ
      • 問題の構造すれば、問題のトライ方によっては問題がシンプルになることもある

メンタリングの技術

• メンタリングの目的

  • 対話重視
  • 「思考のリファクタリング」を応用し、相手の認知の歪みを補正し、次へのアクションを促す
  • エンジニアリングの本質は「不確実性の削減」であるとすると、他者の心理的課題のリファクタリングもエンジニアリング
  • 色んな場面で実践できる
    • コードレビュー
      • 自分のコードにアイデンティティを広げている可能性もある
      • そのためコードへの指摘を人格への指摘と受け取ることもある
      • 口頭のほうが、迅速でディスコニュニケーションが少ない、ということもある
    • ペアプロ
    • 障害時ハンドリング
    • チームマネジメント

• 自ら考える人材を育てるテクニック

  • 自立型人材
    • 自ら問題を発見し、解決できる
    • 問題について自分ごと化して捉える
      • 物事の原因を自分に求める
  • 学習性無気力；「何を提案しても無駄だ」と自立的に考えなくなってしまう状態
  • 自立的に動くことは楽しいと感じるように導く

• 傾聴とただ聞くこと

  • ただ聞くだけだと・・
    • 自分の意見を言う
    • 自分の興味のある質問をする
  • 傾聴では・・・
    • 相手の感情への共感を表す
      • うなずき、横に座る、ミラーリング
      • 相手のペース
    • 相手の話の内容を可視化する
      • 「あなたの問題↔私の解答」という構図から、「問題↔私達」という構図に変える
      • 図解することで第三者目線に立ち返ることが出来る
      • 感情的に固執している要素を引き剥がす
        • 「全てがいや」という状態から、１つ１つ課題を羅列することで、ポイントで議論できるようになる
        • 課題を簡素化する
        • 事実と意見（感情）を分ける
    • 相手の思考の盲点を探索しながら質問をする
  • 同感と共感は違う
    • 同感：「「あの人は許せない！」」同じ感情になること
    • 共感；「だからあの人を許せないんですね」相手を理解すること

• 心理的安全性の作り方

  • 素直に話すようになる；相手がどう思うかを考慮しすぎて話せない、ということがない
  • 考えが明晰になる；認知の歪みがない、議論する際に認識齟齬によってこじれることがない
  • 意義のある対決が後押しされる；関係が悪化するだけの対立ではなく本質的な議論ができる対立が生まれることに懸念がない
  • お互いに自己開示することで、その間柄での対人リスクは軽減される
  • 失敗が緩和される；失敗を報告しやすくなる
  • イノベーションが促進される；今までの前提が取り外されて創造的な意見が生まれる
  • 組織の障害でなく目標に集中できるようになる；組織の理不尽に力を掛ける必要がない
  • 責任感が向上する

• 思考ではなく行動に着目する、行動を計測する

• 自分はそんなつもりはないけど相手がそう解釈したら心象が悪くなる、という場合は事前に「自分はそんなつもりはないけど、そういうふうに見えたら教えて」と伝える

• 「自分の経験だとこうだ」「私とあなたの事情は違う」で終わるのは失格

• 前提の確認と取り外し

  • 「これってそもそも何が問題なんでしたっけ？」
  • 「一旦この前提がなかったとしたらどうなりますか？」

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

• アジャイルのメリット
  • 早めに出してマーケットを獲得する
  • 変化に強い
  • 経験主義的
• ウォーターフォールはプロジェクトマネジメント、アジャイルはプロダクトマネジメント
• エンジニアリングはケアしなければならない範囲が広い
  • 目的不確実性；「何を作るか」
    • 要求と仮説検証
  • 方法不確実性；「どの様に作るか」
    • スケジュール予測と見積もりの手法
  • 通信不確実性
    • 振り返りの手法
• リーンソフトウェア開発における、７つの贅肉の落とし方
  • 全体を最適化
  • 無駄をなくす
  • チームに権限移譲；意思決定権を与え、開発スピードを上げる
  • 学習を強化；失敗を恐れず経験を積む
  • 早く提供；早期に連続的に出すことで、目的の不確実性削減
  • 品質を作り込む
  • 決定を遅らせる；必要なものを必要なタイミングで作る

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

• 見積もりに間に合うことを管理するのではなく、見積もり予測が収束するかどうかを管理する

• プロダクト開発のバリューストリーム

  1. 顧客の課題を特定し、仮説検証戦略を作る
  2. 開発要求を固める
  3. 実装
  4. テスト
  5. リリース
  6. 効果検証

• スコープバッファ

  • どの程度まで作るかのバッファ
  • MVP；最低限ここまでつくったらリリースできる、という機能のライン
  • 機能（ストーリー）ごとにレイヤ横断的に作ったほうが良い

• ユーザーストーリー

  • どのような人が
  • 何が出来る
  • そのことでどんな感情になる

  ユーザーストーリーがあることで、開発者の思い込みが排除されやすくなる

• 仮説県境プロセス

  1. 仮説構築
  2. ユーザー調査
  3. プロトタイプ検証
  4. MVPリリース
  5. 小規模マーケティング
  6. 大規模マーケティング

• 最も不確実なものは何かを洗い出し、それを最も安く検証する方法を考える

• スクラムサイクル

  • スプリント計画
    • プロダクトバックログを実現可能なスプリントバックログに分解する会議
    • タスクの分解、実現方法の検討、課題の洗い出し、一段詳細な見積もりなどを行う
  • デイリースクラム
    • 毎朝全員が出席して、その日やること、前日までの課題を完結の話す会議
  • スプリントレビュー
    • プロダクトオーナーが、インクリメントレビューをする
    • しゅうせが必要であればバックログに追加
    • スプリントごとにリリースポイントになるように開発をすすめる
  • レトロスペクティブ
    • 振り返り会議
    • 良かった点、悪かった点、次へのアクションを決める

• ゴール設定

  • インセプションデッキ
    • プロジェクトの全体像(目的、背景、優先順位、方向性等)を端的に伝えるためのドキュメント
    • アジャイルサムライの著者 Jonathan Rasmusson氏 によって広く認知されるようになった
    1. 我われはなぜここにいるのか(Why1)
    2. エレベーターピッチを作る(Why2)
    3. パッケージデザインを作る(Why3)
    4. やらないことリストを作る(Why4)
    5. 「ご近所さん」を探せ(Why5)
    6. 解決案を描く(How1)
    7. 夜も眠れなくなるような問題は何だろう(How2)
    8. 期間を見極める(How3)
    9. 何を諦めるのかをはっきりさせる(How4)
    10. 何がどれだけ必要なのか(How5)

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

• 組織の情報処理能力を上げることで、効率的に不確実性を排除できる
• コミュニケーションは発信・到達だけではなく、受信の確認と、行動変容による「正しく受信されたか」の確認が必要
• 権限・責任から見る組織設計
  • 明示的な権限と責任の委譲を行う
  • 権限と責任の不一致をなくす
  • 権限同士の衝突を最少にする
  • 権限の衝突レベルを最少にする
• 技術的負債が大きくなると開発がしづらくなるのは、積み上げたジェンガで遊び続けるようなもの
• 技術的負債は見えない
  • 見える価値：新機能
  • 見えない価値：アーキテクチャ
  • 見えるマイナス価値：バグ
  • 見えないマイナス価値：技術負債
• 技術的負債の可視化
  • 技術的負債＝ある機能の実際に掛かる工数ー理想的な環境だったときの工数
  • エンジニア→経営者へのコミュニケーション
    • アーキテクチャの複雑性
      • 循環的複雑度の可視化
      • 依存関係の分析

      • コードチャーンの分析

        • 誰がいつどこをどの様に触ったか→バージョン管理
        • 色んな人がいろんな意図で触るファイルは、バグが混入しやすい
  • 経営者→エンジニアへのコミュニケーション
    • 将来要件の不確実性
      • 非機能要件の具体化
      • 仮説・戦略の透明化
        • 「上手く行ったら続ける」というような曖昧な将来設計は、意思決定木で確率を明記し、お互いの認識を揃える
      • ユビキタス言語の作成
• コードチャーンの可視化