【エンジニアリング組織論への招待】を10~15分で読めるように1万文字程度でまとめてみた

■ はじめに

エンジニアリング組織論への招待という本を読みました。

ジョブ理論 に続く名著でした。

• 理想に向けて、事業を最速かつ生産性高く成長させるには、「未来」と「他人」という2つの不確実性をマネジメントすることで、成し遂げられる
• ソフトウェア開発における不確実性のマネジメントには、不確実性に立ち向かえるチーム開発が何よりも重要である（ex. メンタリング、権限移譲、信頼関係、透明性）

の2点を中心に、事業成長×組織の幸せに必要なフレームワークを提供してもらえるものでした。

ソフトウェア関連の事業やプロダクトに関わっている人（特にマネジメントしている人）は職種限らず読むと、みんな幸せになれそうなので、1人でも多くの人がこの概念に触れられるように、私なりの視点で雑多にまとめました。

（ちなみに著者の 広木さん - hiroki_daichi には個別にご連絡し、要約した本記事の公開許可は(公開からしばらく時間は経ってしまいましたが）頂いております。広木さんありがとうございます。）

■ まとめ

以下まとめた内容です。
誤字脱字チェックはしていないので、悪しからず。

仕事と実現

• 仕事とは
  • 要求を実現するもの
• 実現とは
  • 曖昧な要求が具体的で明確な何かに変わっていく過程のこと
  • ※プロジェクトは初め不確実性の大きなものであり、徐々に不確実性が下がっていく（想定納期は実際の2倍〜1/4と大きな幅がある）

エンジニアリング

• とは
  • 「不確実性の高い状態から、低い状態に効率よく移すその過程で行う全て」のこと
  • ※重要な指標は「どうしたら効率よく不確実性を減らせるのか」
• 不確実性を減らす方法
  • 1. 自分がどのような本能に囚われているかを知ること（バイアスの理解）
  • 1. 仮説と検証を通じて、未来の不確実性を下げること（環境不確実性の排除）
  • 1. 同じ目的で働いているはずの人々との間にあるコミュニケーションの不確実性を減らすこと（通信不確実性の排除）
• つまり
  • 仕事の目的 = エンジニアリングの役割である

不確実性を減らす方法

• 1. 不確実性に向き合う時に知っておいた方がいい人間の不具合
  • 論理的思考力の盲点
    • 認知バイアスや偏見（詳細はリスト）
  • 全体論とシステム思考
    • 部分最適で考えずに、全体を俯瞰して見るということ
• 1. 環境不確実性の排除（未来への不安）
  • 課題
    • それがやってくるまでどうなるか分からない
  • 解決策
    • 経験主義
      • 考えても情報の整理しかされない、間違っていた、分からなかった、となっても次の打つ手が出ない
        • 行動した場合は間違っていても、分からなくても、それが情報となり次の打ち手に繋がる
      • 問題に直面したときに出来ること
        • コントロールできるものを操作し、観察できることを通じて、その結果を知識にすること
        • 人間は問題に出くわすとコントロールできないものを操作して、観察出来ないものを改善しだすが、それは間違っている
    • 仮説思考
      • 経験主義の生産性を上げる考え方
      • 少ない情報からっぽい答えを定義し、その正しさを検証する
• 1. 通信不確実性の排除（他人への不安）
  • 課題
    • 他者理解の不確実性
      • 人は他人や事象を完全には理解できない
    • 伝達の不確実性
      • コミュニケーションが到達するとは限らない
    • 成果の不確実性
      • 仮に理解されたとしても予想されたように行動するとは限らない
  • 結果生まれる問題
    • 情報の非対称性
      • 知ってる人、知らない人の分断
      • 無能で十分に説明のつくことを悪意のせいにするな
    • 限定合理性
      • 自分にとっても正解が全体にとっての正解にならない
  • 解決策
    • コミュニケーション
      • 1. 組織で求められるコミュニケーション能力とは、コミュニケーションの不完全性を減少させる能力
      • 1. 組織内で連鎖的に発生する不確実性のループを止めることが出来る能力
  • 補足（情報の透明性について）
    • 「出来る限りの情報を公開すること」ではない。伝達の不確実性をわずかに下げるのみ。
    • 「情報の透明性」とは意思決定と意思決定に関わる情報が、組織内に正しく整合性をもって伝達されるように継続して努力し、何か分からない決定があったとしても、それを隠そうとしたわけではなく、抜けてしまったのか、聞き逃したのだから、直接聞いてみようという関係性をつくること
    • 「透明性」とは継続したコミュニケーションや仕組みを通じて、コミュニケーションの不確実性を低く維持して、情報の非対称性が削減され、限定合理性の働きが弱められている状態

ソフトウェア開発と不確実性の削除の方法

アジャイルという概念

アジャイルとは

• 目的地のことで、環境に適応して、最も効率よく不確実性を減少させられている状態

アジャイルが良い理由

• 一般の人々が使うものになり、マーケットで受け入れられるかといった要素が強くなり、マーケットがプロジェクト期間中に大きく変化することも頻繁に発生
• 顧客のニーズに合うかどうかが最終工程にならないと分からないことが多発。顧客ニーズを捉えてなかったら開発投資が無駄に終わる

アジャイルなチーム（自己組織化）とは

• 目的地に向かう集団のことで、理想状態に向かって、前進しているチームの状態
  アジャイルな方法論とは
• 目的地に向かうための考え方のことで、理想状態にチームが向かうために、お互いにメンタリングし、不確実性に向き合い、減少させるためにはどうしたらよいかを考えるための組織学習の方法論や考え方

アジャイルな方法論

• 不安に向き合うために振り返りや学習という仕組みを取る（問題を隠すよりも共有したほうが良い、対人リスクを取りやすくなる）
• 少人数の対話を重視し、情報の非対称性を減らす
• 役割を分けて関係性を縛らずに、チーム全体の目的において、今自分は何をすべきかという問いを常に持つ。ある専門家がいても別の専門性のメンバーが手伝うことで新しいスキルの獲得と限定合理性の排除につながる
• 実験を行う前に実験結果について議論しても答えは出ない。まず実験を行って得られただけをチームにとっての重要な知識に転換する
• 意思決定の遅延で大惨事を避けるために、リアルオプション戦略（検証コストを小さくするオプションを作り、削減する不確実性の大きさを金銭的価値に変換する戦略）を取る

アジャイル型開発とは

• 目的地に向かう特定の移動手段のことで、アジャイルな方法論を取り込んだある具体的なチームで実行されている開発プロセスのこと

アジャイル開発手法とは

• 移動手段の手引書にかかれていることで、アジャイルな方法論を取り入れやすくするためのルールや、フレームワークとしてまとめられている手法

（アジャイルを実現させるための）スケジュールマネジメント

スケジュールマネジメントとは

• 出来る限り早く「いつリリースされるか」という時間の精度をあげること
• 早くプロジェクトを終わらせることではない。完了する納期にあわせて経営側は様々な意思決定をする（間に合わないなら追加投資、機能削減、計画修正などを行う）

ポイントは次の3つに注目して改善を行うこと

• 1. 制約スラック（作業同志の依存関係による無駄）を削減
  • リソース制約（この作業は◯◯にしか出来ない）
  • 依存制約（この作業は◯◯の作業の後にしか出来ない）
  • 調整コストや意思決定（多くの人を集めて行う会議で、それに作業内容が依存する場合）
• 1. 見積もりの予測可能性をあげる
  • 見積もりはあくまで予測で、それを「ノルマ」にしないこと
    • 予測が当たらないのであれば、予測精度に問題があって、仕事が達成できなかったことに問題があるんじゃない
  • プロジェクトバッファの引き方
    • 最悪値 - 理想値 = 偏差を作り、偏差の二乗の和の平方根がタスク全体の偏差になる。
    • そしてその2倍がプロジェクトバッファと設定（正規分布の95.4%）
  • そして不安量の大きいタスク順に問題解決をする
    • スムーズにスケジュールリスクを削減出来る
    • 不安の少ないタスクから取り組むプロジェクトが多いが、前には進むが見積もりの予見性は変わらず、経営の意思決定はしづらくなる
  • 不安量の大きいタスクの見積もり
    • ex. プランニングポーカー
• 1. プロジェクトバッファの消費を可視化し改善する
  • 小さいスプリントを繰り返し、1スプリントでの消化量の精度をあげる
  • ヴェロシティは目標値ではなく、チームの予測可能性を高めることと、チームの健康状態を測るために使うべき数値
    • ヴェロシティが上がっても、喜ばしいことではなく、それは見積もりの誤差があったことを示すだけ
    • ヴェロシティをあげることよりも、ヴェロシティが安定し、将来の予見可能性をあげることに投資をすべき
  • ヴェロシティと偏差を使った最高と最悪の着地点の見積もり

その他押さえるポイント

• ユーザーストーリーの作成
  • 1つの物語を階層的に分解することで得られる
    • 機能単位を物語として分解することで、なぜその機能が必要なのかという文脈が切断されることを防げる
  • 思い込みでその機能が必要と判断してしまうことを防げる
    • 顧客目線に立つための単位で、開発のための作業タスクではない
  • 開発作業を開始するのに丁度良いストーリーとは
    • Independent（独立している）
    • Negotiable（交渉可能である）
    • Valuable（価値がある）
    • Estimable（見積もり可能である）
    • Small（適切な大きさである）
    • Testable（テスト可能である）
• マーケット不安の削減への考え方
  • 仮説検証における仮説とは、直感的に少ない断片情報から「このようにしたらビジネスが成立する」というビジネスモデル全体のこと
    • 仮説の時点では何一つ確からしいものはない。最も不確実性が高い状態である
  • 新規ビジネスを考える際に何かのアイディアを捻り出してそれが「確実にうまくいくか」の視点で精査しがちだが、間違っている
    • 精査すべきは仮説として成立しているかであって、確実性ではない
  • 検証とは、仮説を構成する不確実性のうち、最も大きなものを安いコストで削減すること
    • 小さなコストで検証し、失敗をしたら別の仮説を構築することを繰り返して、ビジネスにおける仮説検証が成立する

（アジャイルを実現させるための）メンタリング

育成（指摘のコツ）

• 内心への指摘ではなく、行動の指摘をせよ
  • 怠け心や心構えに突っ込みを入れても、本人も分からなくて困っている
  • 変化を観測できないことを問題の対象にするのは愚かな行為。分からないから解決が出来ない
• SMART（メンターとメンティで次の行動を合意する時に押さえるべきポイント）
  • Specific（具体的な）
    • 抽象的ではない行動で、何をするのか解釈にブレの少ない言葉である必要がある
  • Measureable（測定可能な）
    • その行動が行われたことを、どのようにして計測するのかを合意する必要がある
  • Achievable（到達可能な）
    • 精神論的で、過剰な数の行動ではなく、達成が可能な行動として合意する必要がある
    • メンティに十分コントロール可能である
  • Related（関連した）
    • メンティの課題とどのようにこの行動が関連しているのか十分にメンティ自身が「説明できる」必要がある
  • Time-Bound（時間制限のある）
    • いつまでに行われるのか、いつまでに測定されるんおかということが具体的に決っている必要がある

信頼関係（アクノレッジメント）

• とは
  • 認めること。承認しているメッセージを発信し続けることが大事
• 相手に対して興味関心を持ち、変化にいち早く気付き、時間を費やして、言葉や行動を通して伝えることが基本
  • 存在承認
    • 相手が今ここにいてくれたありがたいというメッセージ
    • 例えば、挨拶をする。会ったときに笑顔である
    • 前に行っていたことを覚えている、頑張っている様子を見て肩をたたいて励ます
  • 行動承認
    • 「結論から話すようになった」や「前よりもよく調べている」「時間通りに来ている」など
    • ポジティブな行動をとった時に褒めるでもなく、その行動を言葉に出して伝える
    • この行動は承認されていると相手が感じることが出来る
  • 結果承認
    • 「〜はすごい成果だね」「〜はうまくできているね」「〜がよくて助かった」と出来上がったものに対して主観を込めて伝える

信頼関係（YOUメッセージとIメッセージ）

• 主語があなたになってるものをYOUメッセージ、主語がわたしになってるものをIメッセージ
• Iを主語にして伝えることで、自分のことを想ってくれているという気持ちが届きやすくなる

育成（目標の設定）

• 高くて、欲望に忠実な目標ほど、ブレずに良い成長を遂げることができる
• 会話を通して引き上げることが必要

（アジャイルを実現させるための）生産性向上のための組織開発

生産性とは

• 市場の不確実性を効率よく仮説検証する能力のこと（不確実性を削減する能力のこと）

生産性をあげるとは

• 生産性の向上 = 「個人の生産性の和 >> 組織の生産性」の解消
• 「個人の生産性の和 - 組織の生産性の解消」 = 「コミュニケーションコスト」
• 「理想的な情報処理能力 - 現実の情報処理能力」 = 「コミュニケーションコスト」

組織の生産性をあげる方法

• 権限委譲と期待値調整
  • 効果
    • コミュニケーションの必要性を減らす
    • コミュニケーションの失敗を防ぐ
  • 権限とは
    • 会社の資産やリソースに対して何をして良いかという自由度
    • 権限に見合う自由度を手に入れる代わりに、それに対応する説明責任が生じる（与えられた権限に対して、何を行い、どのような結果をもたらしたかという説明）
  • 権限委譲をする組織の設計ポイント
    • 明示的な権限と責任の移譲を行う
    • 権限と責任の不一致を無くす
    • 権限同志の衝突を最小にする
  • その他メリット
    • 組織の拡大には少ない指示や抽象的な指示から多くのことを判断して動いてくれる組織が必要
    • 社長や上司が個別具体的な指示をしないと回らない状況では、権限が移譲されず、組織が大きくなっても情報処理能力が上がらなくなる
• 適切な組織、コミュニケーション、外部リソースの調整
  • 効果
    • 取引コストを減らす
  • とは
    • 職能ではなく、責任やケイパビリティの単位で組織やコミュニケーションを設計
  • 取引コストとは（コミュニケーションコストの一部）
    • 探索コスト（取引相手を見つけるために支払うコスト）
      • クオリティの高い技術舞台を探すことは難しく、そのための関係構築のコストが必要
    • 交渉コスト（取引相手を交渉を行うために支払う発生するコスト）
      • 外周先とどのような契約条件で、契約を行うのかを決めるために必要なコスト
    • 監督コスト（取引相手が契約した取引を履行するように監督と矯正を行うコスト）
      • 作成されたプロダクトの品質を監督し、クオリティの維持がなされていることを検収したり、外注先をマネジメントするコスト
  • 取引コスト削減の方法1.（内製と外注リソースの使い分け）
    • 内製
      • 自社へのノウハウの蓄積が競争優位性を生むだろう領域や事業継続性に関わるデータを持つ領域は、企業のコアコンピタンスとして内製すべき
      • チームビルディングのコストや意識統一など、長期的なパフォーマンスの増加を狙うことで取引コストを削減しながら質の高い開発が出来る
      • 外注の時に発生する工数、納期、人月単価など取引コストを発生させるべきではない
    • 外注
      • 事業のコアコンピタンスにならない、一時的に必要な機能や周辺領域を拡大するために作られる機能開発は効率良い場合が多い
  • 取引コスト削減の方法2. （機能横断と機能別組織の使い分け）
    • バランスの保ち方
      • ビジネスが拡大し、業界構造を変える勝ち筋が見えてくると知の深化に傾斜しがちなことを知る（コンピテンシートラップ）
      • 短期的には合理的判断から生まれることを知る（スペックの向上と売上利益の向上の確実性が高いため）
    • 職能能段チーム
      • 能力を引き上げるコツ
        • 地理的に近い配置、十分な権限委譲、心理的安全性の高さ、目的の透明性
      • 選択すると良い場合
        • 不確実性が高い市場にチャレンジをするとき
      • メリット
        • 新しい知見が生まれやすくなり、ビジネス上の意思決定が早くなる
    • 職能別チーム
      • 選択すると良い場合
        • 業界標準となるビジネスモデルが固定的な場合で、ビジネス上の競合優位が、特定分野の知識に依存する場合に適している
      • メリット
        • 専門家集団が集まるので、特定の分野への深い知識を蓄えることができる
• 全体観のあるゴール設定と透明性の確保
  • ノルマを設けるな。自発的目標を設定せよ
    • ノルマは守らせるための細かな指示と監督監視を行う必要があるコストが高くなる。メンバーは低い目標を設定することにインセンティブが働く
    • 自発的目標は、細かな指示をせずとも従業員は目標に向かって熱心いに取り組む、結果メンバーの支援に時間を割ける
  • OKRの運用
    • 「従業員一人一人が組織全体を見渡して、自分が何のために仕事をしているのかを深く理解すること」がOKRの重要な役割
    • 企業全体で1つの木になるように設定する（会社目標のKeyResutは部署のObjectiveで部署のKeyResultはチームのObjectiveに…）
• 技術的負債の見える化
  • 技術的負債
    • 「現実のシステムへの追加工数 - 理想的なシステムへの追加工数」
  • 技術的負債との付き合い方のマインド
    • 最初のコードを出荷することは借金をしにいくのと同じ
      • 将来の時間を借りて対価（不確実性の削減）を得るもの
      • 返さずにいると、複利的に後の開発工数とバグのリスクとして乗っかってくる
    • プロダクト開発は、継続的に様々な市場の不確実性を考慮して要件が変わるもの
      • あらかじめそれを予見し、このコードは負債になるとか、ならないとか、その点を設計に盛り込むのは実質不可能
      • 予想外の機能追加や、ビジネス目的の方向転換、人員数の増加など、様々な外的要因によって、技術的負債は蓄積されやすくなる
  • すべきこと
    • YAGNI原則（you ain’t gonna need it）を守る
    • 「ここは変えることがないだろう」という部分を固定的に作り、「ここはよく変わるかもしれない」という部分を変動的につくる
    • システムを連続的にアップデートしながら作ると、新期開発しづらくなるほど複雑なシステムになる、そこで機能を変化させずに、中身の構造だけを将来像にあわせて再構築
    • 非機能要件の可視化（なぜ今技術的負債の返済が事業的に必要なのか）
    • 仮説と戦略の可視化（未来どんな可能性があるのか、どんな条件で機能の拡大や新期機能の開発が必要になるのか）

その他

• プロダクトマネジメントとプロジェクトマネジメント

  • まとめ

    • プロジェクトマネジメント
      • 目的は終わらせること
      • 方法不確実性に向き合い、スケジュール不安を減少させること
    • プロダクトマネジメント
      • 目的は終わらせなこと
      • 目的不確実性に向き合い、マーケット不安を減少させること

  • マネジメントとは

    • 対象となる◯◯の資源、資産、リスクを管理し、効果を最大化する方法

  • プロジェクトマネジメント

    • とは
      • 対象となるプロジェクトの資源、資産、リスクを管理し、効果を最大化する方法
      • 「はじめ」と「おわり」があり、それが効果をあげて、終了することが目的
    • プロジェクトにとって最大のリスク
      • 終了しないこと。納期を超過して完成の目処が立たなくなること
    • プロジェクトマネージャの役割
      • スケジュール不安を減少させるように物事に取り組む
    • 対処すべき不確実性
      • 方法不確実性（どのように作っていくか分からない不確実性）
    • プロジェクト型開発
      • 予算が開始時点で決まっている
      • 成功は、コスト・スケジュール・スコープが満たされるかどうかで計測される
      • 始まりと終わりがある
      • プロジェクトマネージャーによって指揮される

  • プロダクトマネジメント

    • とは
      • プロダクトが継続的に収益をあげて、損益分岐点を超えて発展することで、終了しないことが目的
    • プロダクトにとって最大のリスク
      • 終了してしまうこと
      • 顧客はマーケットに受け入れられず、採算が取れずに継続的にプロダクトの提供が出来なくなることが問題
    • プロダクトマネージャーの役割
      • マーケット不安を減少させるように物事に取り組む
    • 対処すべき不確実性
      • 目的不確実性（やってみないことには、何を作れば受け入れられるのか分からな不確実性）
    • プロダクト型開発
      • 予算は各ステージ毎に徐々に調達される
      • 成功は、その製品が最終的に得たマーケットシェアや収益に基いて計測される
      • 始まりはあるが、上手くいけば終わりはない
      • プロダクトマネージャーとテクニカルリードのペアで指揮される
• 組織設計とアーキテクチャとビジネスモデル
  • 逆コンウェイ作戦
    • 前提
      • ビジネスモデルと組織構造とアーキテクチャの三者が一致していれば組織の情報処理能力は拡大する
    • コンウェイの法則とは
      • 取引コストが高く、情報処理能力が低い組織からは、技術的負債が生まれやすい
    • 逆コンウェイ作戦とは
      • 取引コストが低く、情報処理能力が高い組織からは、良いアーキテクチャが生まれる
      • 積極的な組織設計やコミュニケーション設計をビジネス戦略に基いて行うことで、アーキテクチャ自身を良いものに変えようという考え方
• 不確実性の高いもの（ex. 新規事業の立ち上げ）への取り組み方
  • まとめ
    • エンジニアが最強なのは大きな投資をしなくても、不確実性は高いか可能性のあるビジネスに低リスクでチャレンジを行い、確実性を高めることが出来るからである
    • 不確実性の高いものには一気に投資すべきじゃない。不確実性を小さく出来る手段があるならそっちをすべき
  • リアルオプション戦略と遅延した意志決定
    • 遅延した意思決定
      • 「早期に大きな投資判断などの意思決定を行い大失敗をするよりも、小さく失敗をして成功しそうな時に大きな投資をする」のように、成功確率が上がるまで、巨額の投資判断を行わないという考え方
        • 新しいビジネスやシステム開発を行うとして、将来性はありそうだが不確か。不確実性が大きい段階で、大きな予算をつけて大きなプロジェクトを走らせると、失敗した場合にその投資の全てが無価値になる
        • これでは不確実なものをやるより、確実なものに挑戦した方がいい結論になるか、大失敗のリスクを受け入れるかを迫られることになる
    • リアルオプション戦略
      • プロジェクトが生み出す利益のボラティリティが分かれば、それを元にどの程度の費用までは仮説検証に使えるか計算可能
        • 不確実性が大きい、プロジェクトが生み出す利益のボラティリティが大きい場合は、その確からしさを安価に確認する方法を生み出すことが出来れば、プロジェクト全体をリスクに晒す必要がなくなる
        • 不確実性が高いプロジェクトは仮説が検証できるまで大きな投資をせずに、大きな意思決定を遅らせる
        • 最小限の仮説検証が可能な、MVP（実用最小限の製品）を作り、それを市場投入し、仮説が検証されれば追加で大きく投資
      • 仮説検証の仕方
        • ペーパープロトタイピングでもユーザーヒアリングでもテストマーケティングでも良い
        • 重要なのは意思決定を遅延させるための「権利」を獲得するアイディアをつくること
      • 補足
        • 将来の予測がつかない世の中だからこそ、率先して不確実性を味方につけなければ確実なものにしか投資できず、失敗しやすくなる
        • 期待値で割に合わないから、そのプロジェクトを進めるべきではないという考え方は合理的だが、そのとき、足りないものはむしろ、最小限の仮説検証というオプション