書籍概要

エンジニアリング組織論への招待
～不確実性に向き合う思考と組織のリファクタリング

著者
発売日
更新日

概要

「コミュニケーションにおける不確実性を減らすには？」「技術的負債を解消する方法とは？」「経営陣とエンジニア間の認識のずれを解消するには？」
エンジニアリングにおける課題を解決する思考の整理方法やメンタリング手法を，さまざまな企業の技術組織アドバイザリーを務めている著者が解説。
若手を戦力として育て上げ，成長する組織を設計・運営するためにおすすめの1冊です。

こんな方におすすめ

  • 開発チームの生産性を上げたいエンジニア
  • 社内組織を改善したい経営者

著者から一言

若手の頃，Webエンジニアとしての仕事は「コードを書くことだ」と単純にそう思っていた気がします。良いコードを書きたい，悪いコードをリファクタリングしていきたいし，何よりそれによってより良い社会になっていくことを目指していました。

より良いアーキテクチャで品質の高いコードを書くにはどうしたらよいのだろうか。そう考えていくうちに，人々の思考の癖や人間関係，ビジネス環境の中で生まれてくる不合理が，形を変えてコードの中に漏れ出ているように思えてきました。

そして，問題解決のためには，コードだけでなく，人々の思考・組織・ビジネスの「構造」こそリファクタリングしなければいけないと考えるようになりました。それこそがエンジニアリングの本質なのだと気がついたのです。

エンジニアを取り巻く環境には，様々な問題があります。

なぜ，いつまでも堂々巡りの議論をしてしまうのか
なぜ，上司と部下のコミュニケーションは失敗するのか
なぜ，イケてるはずのアジャイルやリーンがうまくいかないのか
なぜ，プロジェクトは炎上し，スケジュール通りに終わらないのか
なぜ，技術的負債が問題となるのか，その正体はなんなのか
なぜ，経営者とエンジニアの認識が食い違うのか

これらの根源は，「わからない」ことに対する不安です。未来や他人の考えていることは絶対にわかりません。ですから，問題なのはちょっとしたきっかけから作られた「構造」であって，誰かが悪いわけではないのです。しかし，長らく続いた不況のためか，日本社会は「わからないもの」に向き合う力が弱くなっているように思います。

けれど，先が見えないという「不確実性」をどう扱うかを知ることができれば，「不安」は「競争力」に変わります。エンジニアリングに必要な思考は，まさにこの不確実性を力に変えるという点なのです。

本書は，「不確実性に向き合う」というたった1つの原則から，エンジニアリング問題の解決方法を体系的に捉える組織論です。わからないものを避けるという本能を，どのように理解し，克服し，導くのか。テクノロジーを力に変えたい経営者やエンジニアリーダー，そして，今，かつての私と同じように悩んでいる人のチャレンジへのきっかけとなればうれしいです。

目次

Chapter 1　思考のリファクタリング

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な行動
  • 「わかった？」は意味のない言葉
  • 能力は習慣の積分，習慣は行動の積分
  • なぜ行動を起こせないのか？
  • ゴールへのタイムマシンに乗る

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　組織設計とアーキテクチャ

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

サポート

正誤表

本書の以下の部分に誤りがありました。ここに訂正するとともに，ご迷惑をおかけしたことを深くお詫び申し上げます。

（2018年4月4日最終更新）

P.25　「ベーコンの4つのイドラ」の1行目（第2刷以降，修正済み）

誤 16世紀のイギリスの哲学者、フランシス・ベーコンは、人間には後述する経験主義の祖でもあり、人間の認識には様々な錯覚や誤謬が含まれることを説いた人です。
正 16世紀のイギリスの哲学者、フランシス・ベーコンは、後述する経験主義の祖でもあり、人間の認識には様々な錯覚や誤謬が含まれることを説いた人です。

P.49　13行目（第2刷以降，修正済み）

誤 MVP（Minimum Valuable Product）
正 MVP（Minimum Viable Product）

P.234　小見出し（第2刷以降，修正済み）

誤 エンジニア組織は、組織の下流肯定に位置しやすい
正 エンジニア組織は、組織の下流工程に位置しやすい

P.244　表のレベル6（第2刷以降，修正済み）

誤 上司が行う提案を部下に対して相談する。最終決定の前に、部下に意見を求めるという権限のレベル
正 部下に決定権が委譲されている。しかし、上司が報告を求めたときには説明する責任がある

P.246　1，2行目

誤 権限が明示的で、双方が合意している状態になると、お互いの「期待のずれ」が発生しにくくなります。
正 権限が明示的でなく、双方が合意していない状態では、お互いの「期待のずれ」が発生しやすくなります。

P.257　「理想システムの追加工数との差による表現」の数式の出典

誤 （P. Kruchten, R. Nord, and I. Ozkaya(2012). Technical debt: From metaphor to theory and practice. IEEE Software, 29(6):18?21,November/December)
正 （K. Schmid. Technical debt -- from metaphor to engineering guidance: A novel approach based on cost estimation. Technical Report 1/2013, SSE 1/13/E, University of Hildesheim, SSE, 2013.）

P.265　小見出し（第2刷以降，修正済み）

誤 コード複雑度の可視化
正 循環的複雑度の可視化

P.290　「OKRによる目標の透明化」の下から2行目（第2刷以降，修正済み）

誤 それよりも高い目標を掲げるという目安が与えれれています。
正 それよりも高い目標を掲げるという目安が与えられています。

商品一覧