🪴 Quartz 4.0

Search

SearchSearch

エンジニアリング組織論への招待

Dec 01, 2023, 9 min read

image

  • エンジニアリング組織論への招待

    • 不確実性に向き合う思考と組織のリファクタリング
    • #技術的負債

  • Amazon

  • タイトルが面白そうだったのでとりあえずメモ(6/12)

  • 良い本だという噂は聞いていたがあんまり読む気が起きてなかったのはおそらく「組織論」に対する関心が薄かったから。冒頭の章でメンタリングに役立つことが書いてあったと聞いて興味がわいてきた。

    • メンター業務も組織論なのだなぁ。
    • 上司部下の関係ではない関係性でつながれた組織

  • 1-1　すべてのバグは，思考の中にある

  • 1-2　不確実性とエンジニアリング

    • エンジニアリングの意味
    • はじめとおわりを考える
    • プロジェクトにおける不確実性コーン
    • 組織構造と不確実性の流れ
    • 不確実性と情報の関係
    • 不確実性の発生源
    • 情報を生み出すこと

  • 1-3　情報を生み出す考え方

    • 仕事と学力テストの3つの違い
    • 仕事の問題を学力テストの問題に変換する
    • 3つの思考とソフトウェア開発

  • 1-4　論理的思考の盲点

    • 論理的思考と2つの前提
    • 人間が正しく論理的に思考するためには
    • 非論理的に考えない＝論理的に考える
    • 人は正しく事実を認知できない
    • ベーコンの4つのイドラ
    • 認知の歪み
    • 認知的不協和
    • 扁桃体をコントロールする
    • 自分のアイデンティティの範囲を知る
    • 「怒り」を「悲しみ」として伝える
    • 問題解決より問題認知のほうが難しい

  • 1-5　経験主義と仮説思考

    • わからないことは調べるしかない＜＜経験主義＞＞
    • 不確実性と夏休みの宿題
    • プロフェッショナルの仕事
    • コントロールできるもの／できないもの
    • 観測できるもの／できないもの
    • あなたができること
    • 少ない情報で大胆に考える＜＜仮説思考＞＞
    • PDCAサイクル
    • データ駆動な意思決定の誤解
    • リアルオプション戦略と遅延した意思決定
    • 問題の解決よりも問題の明晰化のほうが難しい

  • 1-6　全体論とシステム思考

    • システムとは全体の関係性を捉えること
    • 部分だけしか見ないことで対立が起こる
    • 認知範囲とシステム思考
    • 問題解決より問題発見のほうが難しい

  • 1-7　人間の不完全さを受け入れる

    • コミュニケーションの不確実性
    • カレー作りの寓話
    • 不確実性を削減し，秩序を作る
    • Chapter 2　メンタリングの技術

  • 2-1　メンタリングで相手の思考をリファクタリング

    • メンタリングの歴史
    • メンタリングとエンジニアリングの関係
    • 「自ら考える人材を作る」ためのテクニック
    • 効果的なメンター／メンティの関係性
    • 「他者説得」から「自己説得」に
    • 「悩む」と「考える」の違い

  • 2-2　傾聴・可視化・リフレーミング

    • 解けないパズルを変換する
    • 空っぽのコップにしか水は入らない
    • 「傾聴」と「ただ話を聞くこと」の違い
    • 共感をして話を聞き出す「信号」
    • 問題の「可視化」と「明晰化」
    • 認知フレームとリフレーミング

  • 2-3　心理的安全性の作り方

  • 2-4　内心でなく行動に注目する

    • 内心は見ることができないが，行動は見ることができる
    • SMARTな行動#smart_criteria
    • 「わかった？」は意味のない言葉
    • 能力は習慣の積分，習慣は行動の積分
    • なぜ行動を起こせないのか？
    • ゴールへのタイムマシンに乗る
    • Chapter 3　アジャイルなチームの原理

  • 3-1　アジャイルはチームをメンタリングする技術

    • 日本と世界のアジャイル開発普及率
    • 日本国内ではアジャイル実践者の数が圧倒的に少ない
    • アジャイル開発が必要とされた2つの理由
    • アジャイル開発は3倍の成功率，1/3の失敗率
    • プロジェクトマネジメントとプロダクトマネジメント
    • アジャイルをするな，アジャイルになれ
    • ウォーターフォールかアジャイルか

  • 3-2　アジャイルの歴史

    • アジャイル開発は経営学
    • デミング博士とPDCA
    • トヨタ生産方式とリーン生産方式
    • 生産方式から知識経営へ
    • 生命科学の発展と社会科学への流入
    • ハッカーカルチャーと東洋思想への憧れ
    • 軽量ソフトウェア開発プロセス
    • アジャイルソフトウェア開発宣言
    • アジャイルの歴史に見る3つのポイント

  • 3-3　アジャイルをめぐる誤解

    • アジャイルに関する5つの誤解
    • アジャイルはなぜ誤解されるのか

  • 3-4　アジャイルの格率

    • 「アジャイル」は理想状態
    • アジャイルな方法論
    • アジャイル開発は「脱構築」される

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

  • 4-1　いかにして不確実性を管理するか

    • 不確実性マネジメント

  • 4-2　スケジュール予測と不確実性

    • スケジュールマネジメントの基本
    • 制約スラックとクリティカルパス
    • 悲観的見積りと楽観的見積り
    • スケジュール不安の「見える化」
    • 計画でなく実績から予測する
    • 要求粒度と不確実性
    • スケジュール不安はコントロールできる

  • 4-3　要求の作り方とマーケット不安

  • 4-4　スクラムと不安に向き合う振り返り

    • 不安に向き合うフレームワークとしてのスクラム
    • どこに向かって，どのように振り返るか
    • 不安を知りチームマスタリーを得る

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

  • 5-1　何が技術組織の“生産性”を下げるのか

    • 生産性という言葉の難しさ
    • 組織の情報処理能力
    • 組織とシステムの関係性
    • エンジニア組織の情報処理能力を向上させるには？

  • 5-2　権限委譲とアカウンタビリティ

  • 5-3　技術的負債の正体

    • 技術的負債をめぐる議論
    • コミュニケーションのための分類
    • クイック＆ダーティの神話
    • 技術的負債は「見ることができない」
    • 理想システムの追加工数との差による表現
    • 見えてしまえば「技術的負債」ではない
    • 技術的負債に光を当てる

  • 5-4　取引コストと技術組織

    • 取引コスト理論
    • ホールドアップ問題
    • アーキテクチャと外注管理
    • 社内における取引コスト
    • 機能横断チームの重要性

  • 5-5　目標管理と透明性

    • 誤解された目標管理
    • 抜け落ちたセルフコントロール
    • OKRによる目標の透明化
    • 透明性と情報公開

  • 5-6　組織設計とアーキテクチャ

    • 取引コストとアーキテクチャ
    • 逆コンウェイ作戦
    • マイクロサービスアーキテクチャ
    • マイクロサービス化を行う時期の難しさ
    • エンジニアリング・カンパニー

Graph View

Backlinks

  • No backlinks found