[読書] エンジニアリング組織論への招待 ～不確実性に向き合う思考と組織のリファクタリング～ 読んで自分の理解をまとめてみた

ゲームソリューション部の新屋です。 長い間積み本だった「エンジニアリング組織論への招待」を読了しましたので、私なりのまとめ・感想を述べていきます。

まとめ

エンジニアリングで不安と立ち向かう！
その心構えと不安の正体と分析、そして立ち向かう方法について教えてくれる本でした。

感想

• 上司が「視座を高く・視野を広く持て」とよく言われますが、大志を抱け、くらいのエールみたいなものだろうとずっと考えていました。本書を読むとその意図がちょっとわかった気がします。
• 自分はPMという立場ではありませんが、本書で紹介されているマネジメント手法は積極的に使っていけると思います（エンジニアから提案するシーンは多いですし）
• 本書では、開発現場で起きる数多くの問題たちが紹介されています。もっと早く読んでいれば、過去の悲しい事件たちを救えていたのかも知れません。

注意

ここから先はチャプターごとのメモ書き兼まとめです。 ひとりで輪読会するイメージでアウトプットをしてみました。長文ですので気になる方だけお進みください。 最後の方はまとめることに心が折れたので、輪読会はやはり他の誰かといっしょに開催する方がいいと思いました。

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

要約

• エンジニアリングとは「実現」の科学
  • 実現=不確実な状態から確実な状態に変化すること
  • 不確実なもの
    • 他人・未来
    • コントロールできないもの・観測できないもの
  • 不確実性に向き合うと人間は不安になる⇒攻撃or逃避
  • はやいうちに不確実性に向き合うことで確実性が高まり安心できる
    • 夏休みの宿題
  • 組織（企業）は不確実⇒確実に変化させる装置
    • 仕事をしているとさまざまな問題「らしきもの」に直面する
• 論理的思考
  • 問題を解くために必要 学校のテストで鍛えられる
  • 正しく認知し正しく演繹（えんえき）する
  • しかし認知が歪まない人間はいない
    • どこで認知が歪むか知っておく
      • ベーコンの4つのイドラ・スプリッティング・一般化のしすぎ⇒レッテル貼り・すべき思考・選択的注目・結論の飛躍・感情の理由づけ・認知的不協和・怒り
  • 問題解決よりも問題認知のほうが難しい
• 経験主義・仮説思考
  • 経験主義: コントロールできるものを操作し、観測できるものの結果を見ることでしか、前に進むことは出来ない
  • 仮説思考: わずかな痕跡からそれを説明可能とする大胆な思考展開・モデル化⇒検証するための行動へ繋げる
  • 仮説を立てる⇒検証することで、問題を明晰にしていく（認知）
• システム思考
  • 要素還元的思考: 物事を要素に分解して考え、それらは線形的な関係で繋がっている
  • 全体論的思考: 物事を全体で捉え、要素同士の関係に注目する
  • システム思考とは、要素同士の関係性に注目して、物事の構造を解き明かす考え方
• 部分だけしかみないことで対立が起こる
  • 対立は局所最適解同士の衝突
  • 認知範囲（視野・視座・視点）とシステム思考で対立に向き合う
  • 対立は個人の問題でなく関係性の問題と捉える
• ビジネス全体のフィードバックサイクルを見つける
  • 組織が目指している結果がスケールしていく、拡張フィードバックサイクルは対立を解消する
• 不確実性
  • 未来=環境不確実性⇒経験主義・仮説思考で向き合う
  • 他人=通信不確実性⇒コミュニケーションで向き合う
    • さらに他者理解の不確実性・伝達の不確実性・成果の不確実性が発生する
    • 通信不確実性により生まれるもの⇒情報の非対称性・限定合理性
• 情報の非対称性とは、一方が知っていてもう一方が知らない状態のこと
• 限定合理性とは、自分が認識する範囲内でしか合理的行動が取れない状態のこと
  • 人間の認知能力には限界があるので仕方ない
• そして、組織が求めるコミュニケーション能力とは
  • 組織の通信不確実性を減少させること
  • 組織内に連鎖的に発生する不確実性のループを止めることが出来ること
• 情報の透明性とは、意思決定と意思決定に関わる情報が組織内に正しく整合性をもって伝達されるように継続して努力し、もし抜けていれば気兼ねなく情報のPullまたは再Pushができる関係をつくること
• 不確実性を削減し、組織の秩序をつくる

気づき

• PDCAサイクルを仮説を定めず実施していたかも知れない
  • 仮説推論は痕跡を見つけることが前提なので現状分析が事前に必要
• ビッグデータによって演繹的・帰納的、あるいは決定的に答え（意思決定）が導き出されると勘違いしていた
  • 常にデータは不完全なのでビッグデータは仮説の検証しかできない
  • 検証結果からまた仮説を推論しデータを集めて検証を繰り返す
• 経営者が口うるさく言う「視座を高く持つ」ことの意味がわかってなかった（理想を高く、くらいの理解だった）
  • 限定合理性による対立を防ぐため

疑問

• P/Lを微分するとビジネスモデルになるとはどういうことか

Chapter2 メンタリングの技術

要約

• メンタリングは相手の思考のリファクタリング
  • メンター: 相手にとってのロールモデル
  • ピアメンター: 数年上の先輩、距離が比較的近い
• 形だけのメンタリング制度は危険、特別な技能ではないがテクニックを意識する必要がある
• 他者説得より自己説得の方が相手にとって高い納得感と自己効力感を得られる
  • 自ら考える人材をつくることが目的
• 悩むと考えるは違う
  • 堂々巡りと次に取るべき行動がわかっている（列挙されていたり）
• 3つのテクニック 傾聴・可視化・リフレーミング
  • 傾聴⇒問題構造の可視化
    • 共感: 相手の不安を取り除き、感情支配から脱出させる
    • 問題の可視化・明晰化: 問題を比較可能にする ホワイトボードの書き出すなど
    • 事実と意見を分ける: 事実に注目するが、感情を蔑ろにしない
  • リフレーミングで課題の本質に気づかせる
    • 前提の確認と（もし間違っていれば）前提の取り外し
    • 情報の非対称性の解消
    • 課題の分離
• 心理的安全性
  • アットホームで仲が良いことが心理的安全性では無い
  • ある人が対人リスクがある行動をとってもその人の地位や人間性が脅かされない
  • メンター⇒メンティは、承認と自己開示、そしてフィードバックをもって接する
    • 自己開示では自分語りで気持ちよくなってはダメ
• 内心でなく行動に注目し、変化を促す
  • 直接コントロールできない、相手の問題をあげつらうことで享楽に身をやつすな
  • SMARTの原則
• ゴール認識レベルを高めて次の一手を生み出す行動が取れるようになる
  • メンタリングによってメンティ自身が高いゴール設定をする
  • ゴールを具体的にイメージできており、行動と習慣が伴うようになっていればOK

気づき

• なし

疑問

• 自立型人材に関して問題を感じているからと言って行動に移せるわけじゃないと思う。問題に対して疑念を持つが自信が無く動かない人を多くみてきた。ここにはもうひとつ壁があるように思う。

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

要約

• アジャイルがなぜ必要とされているか
  • スケジュール不安⇒プロジェクト型開発（計画駆動）
  • マーケット不安⇒プロダクト方開発（マーケット駆動）
  • どちらにも対応したい！
• Be agile
  • 情報の非対称性が小さい
  • 認知の歪みが少ない
  • チームより小さい限定合理性が働かない
  • 課題・不安に向き合い不確実性削減が効率よくできる
  • 対人リスクがとれて心理的安全性が高い
• アジャイルとウォータフォールは対立しない
• アジャイルの歴史を紐解くと面白い
  • 戦後日本の製造業は急速に発展した
    • デミングサイクル⇒PDCA⇒トヨタ生産方式/カンバン方式/多能工
    • アメリカは出遅れて研究に入る⇒リーン生産方式
      • 製造業からソフトウェア開発へ伝播
  • 失敗から学ぶ、SECIモデルとダブルループ学習
    • 組織のルールにもとづいて何かを経験し感じる（形式知-内面化）
    • 組織で仲間と共通の経験を積み重ねる（暗黙知-共同化）
    • それら体感（問題の対策方法など）を明文化する（暗黙知-表出化）
    • 形式知を既存のもの周囲のものと組み合わせて再構築する（形式知-連結化）
  • 戦中日本軍は、身体化された暗黙知には強かったが、形式知を再構築する能力に欠けていた（著: 失敗の本質）
  • 逆にアメリカでは身体化された暗黙知は新鮮だった
    • 長期化するベトナム戦争⇒反体制運動とカウンターカルチャー
    • 人間性の解放⇒ヒッピー文化と東洋思想（個人の中に宿る神性）
      • そしてPCの普及（個人の拡張）⇒ハッカー文化へ
    • 次第に「東洋的」「西洋的」がアメリカ目線で融和していく
  • そうして生まれたのが「XP」「スクラム」「リーンソフトウェア開発」
  • 日米合作とも言えるアジャイル開発だが、日本は出遅れてしまった
• アジャイルソフトウェア開発宣言
  • 個人と対話、動くソフトウェア、顧客との協調、変化への対応
  • プリンシパルエージェント問題への対策
• アジャイルの方法論
  • 「アジャイルへ至るために、私たちは何をすべきか」と問い続けることがアジャイルの起点
    • 不安と向き合う
    • 少人数の対話
    • 役割をわけない
    • 経験のみを知識にかえる
    • 意思決定を遅延する
    • 価値の流れを最適化する
      • 深化と探索⇒レスポンスタイムとスループットを理解している
  • 脱構築
    • 自分たちを再構築していくこと
    • 他のチームがある瞬間において上手くいったからといって真似しても上手くいかない

気づき

• なし

疑問

• なし

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

要約

• 不確実性マネジメント
  • 方法不確実性: スケジュールと見積もり
  • 目的不確実性: 要求と仮説、仮説検証
  • 通信不確実性: 振り返り、コミュニケーション
• スケジュールマネジメント
  • 理想工期: 工数人月/人数
  • 制約スラック: クリティカルパス・属人化作業による遅延、意思決定タイミング、調整期間
  • プロジェクトバッファ
• 見積もりは不安によってブレるものだが向き合っていく
  • CCPMアプローチ: サバ取り⇒バッファ消費率の観測
  • 多点見積もり: プロジェクトバッファを算出⇒不安の大きい順に作業
  • 不安の大きいタスクを分解
  • 相対見積もり
  • 小さいスプリントを繰り返し、ヴェロシティから見積もりをする
    • 不確実性コーンを利用してゲタを履かせる
• 要求の詳細化もマネジメントし、具体的なタスクになるまで落とし込む
• リリースポイントを短くつくりプロダクトオーナーがプロダクトに触れることで目的不確実性は小さくなる
• ユーザーストーリーはINVESTの原則でつくる
• 投資ラウンド
  • シード⇒シリーズA,B,C
  • 仮説検証⇒ユーザー調査⇒プロトタイプ検証⇒MVP⇒小規模マーケ⇒大規模マーケ
  • 先に進むほど不確実性は小さくなるが、投資リターンも小さくなる
• マーケット不安は解消されない
  • 仮説⇒仮説検証の繰り返し
  • 仮説は、リーンキャンバスなどでつくる
• 不安と向き合うためには
  • スクラム: スケジュール不安とマーケット不安のマネジメントを組み合わせて、不安への向き合い方をチームが学習するための方法論。
    • ゴール設定（ゴールレベルを認識すること）が大事⇒インセプションデッキなど

気づき

• スクラムをやっていると段々と上手く行かなくなって、それはスクラムのやり方が間違っていたからだ、とか、プロダクトではなくプロジェクト型の案件だったからだ、とか自分たち以外のものに理由をつけていたが、それは誤りだと気づいた。
  • むしろ、なぜうまく行かなかったんだろうと毎回振り返っていたその行為自体はスクラムをやれていた。ただ、お作法だからと思考停止したり、お通夜のような雰囲気になっていたのはゴール設定が上手くいっていなかったからか？

疑問

• なし

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

要約

• 組織の情報処理能力の高さ=生産性
  • ガルブレイスの情報処理モデル
    • 目的不確実性⇒情報処理必要量
    • 方法不確実性⇒組織の情報処理能力
    • 通信不確実性⇒組織の情報処理能力
• 個人の総和が組織の能力にはならない
  • コミュニケーションコストより情報処理能力は劣化していく
• コンウェイの法則
  • 組織がシステム開発を行う際、その組織のコミュニケーション構造と同じ構造の設計を行ってしまう
  • 例えば、コミュニケーションコストが高い組織はバグの混入率も高くなる傾向がある
• 権限委譲
  • 権限を移譲すると説明責任が発生する
    • 対になっていないと情報の非対称性が発生する
  • 明示的に許可していない権限は許可していないのと同じ
  • 「従業員が経営者意識をもって動いてくれない」は、権限委譲（と対になっている説明責任）が失敗している
• 権限移譲には7段階のレベルがある
  • 自由にやっていいよ、だと完全に委任されたのか、報告の責任があるのか明確にならない。権限移譲のレベル確認でお互いの期待値がズレないようにする
• 権限移譲が排他的であるとは限らず、衝突が発生することがある
  • 解消には上位権限にエスカレーションする必要があるが、少ないほうが情報処理能力が高い組織だと言える
• 権限移譲の設計は
  • 明示的な権限と責任の移譲を行う
  • 権限と責任の不一致をなくす
  • 権限同士の衝突を最小にする
  • 権限の衝突解消レベルを最小にする
    • 同一組織化を意識する（低いほど）
      • 第1段階: 相互依存の同一化
      • 第2段階: 事業とプロセスの同一化
      • 第3段階: 戦略の同一化
• 技術的負債
  • とりあえずクイック＆ダーティは神話
  • 技術的負債は見ることが出来ないので解消のコストをかける判断ができない
    • なら可視化してしまえ
• 技術的負債の可視化
  • アーキテクチャの複雑性に対して（エンジニア⇒経営者へ説明）
    • 循環的複雑度
    • コード依存関係の分析
    • コードチャーン分析
  • 将来要件の不確実性（経営者⇒エンジニアへ説明）
    • 非機能要件の具体化
    • 仮説・戦略の透明化
    • ユビキタス言語の作成
• 取引コスト
  • 外注するときはホールドアップしないように頑張ろう！！！！
• 知の探索と知の深化のバランスが大事
  • 知の探索⇒新しいイノベーション⇒機能横断的組織⇒内製したほうがいいかも
  • 知の深化⇒効率化⇒機能別組織⇒外注したほうがいいかも
• 目標管理の目的⇒ノルマじゃない
  • 主体性向上
  • モチベーションアップ
  • 問題解決力の向上
• マイクロサービスアーキテクチャ
  • 技術組織でサービスを分割することで情報処理能力をあげる、組織論で考えることもできる
  • ただしこの分割を正しく行うには、ビジネスモデルとアーキテクチャへの深い理解が必要
    • さもなくば組織レベルの技術的負債ができあがる
  • 優先度の高いサービスから段階的に移行するのがオススメ
    • 腐敗防止層というリアルオプション選択⇒ファサードパターンとも言う

気づき

• なし

疑問

• なし

これまとめるのになかなか時間掛かりました🙂