「エンジニアリング組織論への招待」読後メモ（自分用）

#読んだ本
エンジニアリング組織論への招待　～不確実性に向き合う思考と組織のリファクタリング
広木 大地 (著)

#感想
冒頭の『はじめに』にあるとおり、様々な「不確実性」についてを紐解き、不確実性にどう向き合い、力に変えていくかが体系的に示された一冊です。

タイトルに「組織論」とありますが、

• 1章では組織の中の個人の在り方みたいなもの
• 2,3,4章では個人対個人とか、比較的少人数のチームについての理論や方法論
• 5章で会社組織としての構成の在り方

のような順を追った流れになっています。

組織論とか、組織変革みたいな話だと大きすぎて途方に暮れてしまいますが、1章の「思考のリファクタリング」では個人の思考をどうやって変えていけば、効率的に不確実性の削減を行えるか、といった内容が様々な理論を基に提示されており、まずは1章の内容を個人的に取り組む、みたいなことはできそうだと思いました。
2章以降のチーム・会社組織についての話も、組織の中の個人として行動する上でのベースとなりえる知識であり、なるほど、と思う箇所も多かったです。

内容とかポイントとか気になったところとか

一度読んだだけだとポイントとか忘れてしまうし、書きながら理解できることも多いので、実践のために意識するべきポイントとか気になったキーワードとかを抜粋してみます。

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

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

• ソフトウェア開発の現場には多くの理不尽や感情の対立が発生　＝　人間の思考にバグが含まれているような状態
• 「思考のリファクタリング」：考え方を少しだけ変える
  • 「不確実性に向き合う」考え方とも言える：学校教育の中で「わからないもの」にどう立ち向かったらよいかを教わることはなかった

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

• エンジニアリングの意味
  • エンジニアリングとは「何か役に立つものを」「実現していく」こと
• はじめとおわりを考える
• 「実現」の「はじめ」と「おわり」
  • 「はじめ」：「お腹がすいた」「何か食べたいな」　＝　何を食べたいのか、曖昧
  • 「おわり」：目の前に「料理」がある　＝　具体的な料理が確定して出来上がっている
• 「曖昧さ」を減らし、「具体性・明確さ」を増やす行為がエンジニアリング
• プロジェクトにおける不確実性コーン
  • 「曖昧さ」とはまだ決まっていない、確実でないこと＝「不確実性」
  • 「不確実性コーン」：時間が経つにつれて不確実性が徐々に下がっていく様を表した図
    • ものを実現するというのは、不確実から確実な状態に推移させていく過程
    • エンジニアリングで重要なのは「どうしたら効率よく不確実性を減らしていけるか」の考え方
• 組織構造と不確実性の流れ
  • 企業における「実現」の流れ
    • 「抽象で曖昧な指示」と「具体的で明確な行動」の関係
      • 上位に行けば行くほど、抽象的で曖昧な状態で指示していく必要がある
      • 逆に現場に行くほど、指示や行動が具体的になる
    • 企業という組織は、組織全体を通じて、何かを実現するためにより曖昧な状態から具体的な状態に変化させる「処理装置」
    • 「具体的で細かい指示」が必要な組織：指示する側の知的能力がそのまま組織の知的な能力＝組織のメンバーは小さな「不確実性」の削減しかすることができない状態
      • 「マイクロマネジメント型」の組織という
    • 「抽象的で自由度のある指示」でも動ける組織：少ない指示で物事を実現できるので、より大きな「不確実性」の削減が可能
      • 「自己組織化された」組織という
• 不確実性と情報の関係
  • 「不確実性を減少させる知識」＝「情報」
  • 「情報」によって選択肢を絞り込めたり、絞り込む場合の材料が手に入る⇒「不確実性」の量を削減
• 不確実性の発生源
  • 「不確実性」＝「わからないこと」
    • 人間にとって本質的に「わからないこと」はたった２つ：「未来」と「他人」
  • 「未来」：「環境不確実性」
    • それがやってくるまでどうなるかわからない
      • 実際に行動し、実験して観察することで少しずつ確実になる
  • 「他人」：「通信不確実性」（「コミュニケーション不確実性」）
    • 私たちは別の自意識を持っていて、すべての情報を一致させることは不可能
    • 会話や書き残したものもすべて正しく伝わるとは限らない
    • 正しく伝わっても、他人が思ったように行動するとも限らない
    • コミュニケーションを通じて不確実性を削減するしかない
  • 「不確実性」を減らす行動を阻むもの＝「不安」
    • 「わからないもの」を無意識に避ける習性があり、本能的に「攻撃」か「逃避」を選択してしまう
    • 「わかっている」物事を優先して実行してしまう
    • 不確実なものが減らない限り、「不安」は減らない
      • 「不安」を減らすには不確実性に向き合う必要がある　←→　「不確実性に向き合うこと」それ自体が「不安」を生み出す
• 情報を生み出すこと
  • 「エンジニアリング」は技術的な面だけではない
    • 「エンジニアリング」は何かを「実現」すること　→　「不確実性を下げること」
    • 「不確実性を下げること」＝「情報を生み出すこと」
  • 「エンジニアリング」の本質は「不確実性の削減」
    • ソフトウェアを書くこと以外でも不確実性の削減手段であればエンジニアリングの一部

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

• 仕事と学力テストの3つの違い

  • 学校では「情報を生み出す」「不確実性を下げる」という基準で物事を学んではいない

  • 社会人になると問題がはっきりと与えられることはない

  • 学力テストと仕事の違いとは？

    	学力テスト	仕事
    人数	1人	複数人
    情報	問題に書いてある	必ずしもあるわけではない
    答え	決まっている	決まっていない（問題を設定することから始まる）

  • 論理的思考の盲点

    • 学力テストは論理的な思考を用いて行う
      • 人は論理的な思考を常に正しく運用できるわけではない：とりわけ他人が介在すると感情的にならざるを得ない
      • 仕事は通常複数人で行う：共同作業の中で意識的・無意識的に感情的になることがままある
      • 問題解決に必要な論理的思考力は、コミュニケーションの失敗によって制限されてしまう＝論理的思考の盲点
      • どんな時に自分は論理的でなくなる可能性があり、人が論理的でなくなる可能性があるのかを知ったうえで問題解決に臨むことが必要

  • 経験主義と仮説思考

    • 問題を明晰化するために、行動し必要な情報を得る
      • 経験主義：情報を入手するために、行動を起こして、その結果を観察し、そこから問題解決を行う
      • 仮設思考：限定された情報であっても、その情報から全体像を想定し、それを確かめることで少ない情報から問題解決に向かう思考様式

  • システム思考

    • 1つではない正解に対して、より正解に近づく一手を打ち続けることが重要
    • 正解が常に用意されているわけではない：正解を自ら設定することが重要
      • 全体像を見極めて、広い視野で問題を捉え、正解を設定するためにシステム思考が必要
• 仕事の問題を学力テストの問題に変換する
  • 仕事上の問題や悩みが解けないのは問題が複雑になってしまっている？
  • 「仕事の問題」を「学力テストの問題」に置き換えられるのであれば、簡単に解決できるはず
    • 「問題が解けない」のであれば、「問題が正しく明晰に記述できていない」と考えると何をすべきかが見えてくる
  • 「思考のリファクタリング」とは複雑な問題を簡単な問題に変換していくこと
• 3つの思考とソフトウェア開発
  • 3つの思考：「論理的思考の盲点」「経験主義と仮説思考」「システム思考」
    • 論理的思考の盲点：心理学、認知科学、経済学、組織行動学などの形で、マネジメントを行う上での基礎的な考え方になっている
    • 経験主義と仮説思考：ニュートン以来の科学哲学の根底と同時に、アジャイルやリーンなどの現代的なソフトウェア開発プロセスの基礎的な価値観
    • システム思考：ライフサイエンスやエコロジー、経営学、ソフトウェア開発など広い分野で参照されている

1-4　論理的思考の盲点

• 論理的思考と2つの前提
  • 論理的思考とは「演繹的思考」：前提であるルールと事象から結論を導く思考方法
    • ルール：人間はみな死ぬ
    • 事象：私は人間である
    • 結論：私は死ぬ
  • 論理的思考の重要な前提2つ
    • ルールと事象（考えの基になる事実）を正しく認知できること
    • 正しく演繹できること
• 人間が正しく論理的に思考するためには
  • 事実を正しく認知できる
    • 人の認知は必ず事実からは変化してしまうもの：どんな人間であれ、ありのままの事実を完全に正しく認知することはできない
      • できる限り正しく事実を認知するには、自分の認知が、いつ、どのように歪むのかを知る必要がある
  • 感情にとらわれずに判断できる
    • 人はすばやく結論へと思考を進めてしまう
      • 感情による短絡を排除して演繹しなければ正しく問題を解決できない
• 非論理的に考えない＝論理的に考える
  • 論理的に考えるには「非論理的に考えてしまう」瞬間を知ることが重要
    • 「自分や人はいつ非論理的になるのか」を知らないと、そのような環境に陥った時に論理的思考力が著しく限定される
  • 論理的思考能力とは、「感情的になる瞬間を知り、その影響を少なくできる」能力でもある
• 人は正しく事実を認知できない
  • 「雨が降った」という事実と雨が降った時に感じた認知とは隔たりがある：正しく事実を認知することは不可能
    • ただ、自分の認知がどのように歪むのか、歪みうるのかを知っておくことで、それが事実ではないかもしれないという可能性を留保できるようになる
  • 事実を認知できないという前提に立って、事実らしきものを客観視できるようにする：論理的思考を制限されないように気を付ける
• ベーコンの4つのイドラ
  • 「イドラ」：人間の錯覚や認識の間違い
    • 種族のイドラ：人間が本来持っている性質から生じる錯覚や偏見
      • 「遠くにあるものが小さく見える」「暗いところではものがはっきりと見えない」など
    • 洞窟のイドラ：外の世界を知らずに一般的なものだと決めつけて理解することから生じる偏見
      • 「自分がそうだから、ほかのひともそうだ」「自分の家では目玉焼きにマヨネーズだからみんなそうだ」など
    • 市場のイドラ：言葉の不適切な使用から生じる誤解や偏見
      • 「噂話やデマを信じてしまう」ことなど
    • 劇場のイドラ：伝統や権威を無批判に受け入れて、誤った考えでも信じてしまうことから生じる偏見
      • 「偉い人の言っていることは正しい」など
• 認知の歪み
  • 「認知の歪み」からネガティブな感情や不安が発生する：それを正すことでネガティブな感情を取り除くことができる
  • ゼロイチ思考：白か黒か、敵か味方かなどの２分法で捉えてしまう認知の歪み
    • 「常に」「全部」「決して」などのフレーズ：「あの人はいつもそうだから、これがだめなら全部ご破算だ」
  • 一般化のし過ぎ：「主語が大きい」：ある1つ2つの事例から、全体をそうだと決めつけたり、早計な判断をすること
    • 「今日、彼は挨拶しなかったから、きっと自分のことが嫌いだ」
    • AさんとBさんの個人的な諍いから、「営業」と「エンジニア」の関係が悪いと捉えてしまい、解決が難しくなる
  • すべき思考：他人に対し、「すべきである」「しなければならない」と期待し、それを強制する思考パターン
    • ルールをその人の事情関係なしに押し付けようとする思考
    • 自分にも向かう：「私は社会人として就職しなければならない」「ちゃんとした大人として結婚しなければならない」「仕事なのだから理不尽も受け入れなければならない」
      • 自分自身を閉じ込めることで自信を追い詰めるような考え方による認知の歪みが、問題解決を困難にする
  • 選択的注目：「心のフィルター」：人は見たいものしかみない
    • 景気が悪いというニュースを見る→町を見渡すと景気が悪そうな事象ばかりが目につく
    • 一度ネガティブなイメージを持ってしまった人の言動の端々にネガティブな印象を持ってしまう
  • レッテル貼り：「一般化のし過ぎ」がさらに加速：ある人の特定の属性のみ注目して、それを原因だと判断するような思考の歪み
    • 「あの人は○○人だから、このように考えるに違いない」「あの人は男（女）だから」「あの人はエンジニア（営業）だから」
  • 結論の飛躍：「先回りのしすぎ」「心の読みすぎ」
    • 「既読スルーしているのは怒っているからだ」
    • 相手の感情を先回りして読み取るのは有利に働くこともあるが、短絡的に結論に飛びつくのはよくない
  • 感情の理由付け：感情のみを根拠に、自分の考えが正しいと判断するような認知の歪み
    • 「何か不安を感じるので、この計画は失敗するに違いない」「あの人のことが嫌いだから、あの人は価値のない人間だ」など
    • 実際には感情的なことを理由に考えていることを意識的・無意識的に「正当な理由がある」かのように伝える人が多い
  • 認知の歪みが重なると、単純な問題が知らず知らずの間に大きな問題に
    • 「営業は、みんな外回りに行って、いつもサボってばかりいる。会社の士気に影響があるから、監視をしたほうがよい」
      • 営業は、全員がそうであるというのは事実か
      • 外回りで頻繁にサボっているのは事実か
      • 会社の士気に影響があるというのは事実か
      • 監視をしたほうがよいという対策が有効というのは事実か
• 認知的不協和
  • 自分の感情や行動の矛盾（不協和）を解決するために認知自体を歪めることを認知的不協和の理論という
  • 「タバコが体に悪いことを知っていながらタバコを吸う」：知識と行動の整合性が取れない状態→タバコを吸うことを正当化できる情報を選択的に取り入れ、不整合を避けようとする
  • 「勉強しようと思っていたのに、言われたからする気がなくなった」
    • よくない状態であるのをわかっているところに押し付けるように伝えるのは善意であれ、行動を起こせない理由づくりに加担することになる
• 扁桃体をコントロールする
  • 偏桃体：怒り、恐怖や危機をつかさどる脳の器官
    • 危機を察知し、生命を脅かされることから逃れるため
    • 自分自身を守るために怒りを発生させ、相手に対する攻撃と防御を無意識に起こそうとする
    • 「怒り」が発生しているときは「自分」「自分が大切にしているもの」に被害が及びそうだと感じている
      • 怒りを感じたときは「何が大事なのか」「自分自身の延長線上にあるもの」「自分自身を構成するもの」を知るときでもある
• 自分のアイデンティティの範囲を知る
  • アイデンティティ：「自分自身を構成すると思っていること」
    • アイデンティティの範囲が広い：怒りを感じる射程範囲が広く、怒りっぽく感じられることも
    • アイデンティティの範囲が狭い：怒りを感じにくい：関心がないのかも
• 「怒り」を「悲しみ」として伝える
  • 「怒り」：相手に「恐怖」を与え、「怒り」のトリガーを引く→怒りの感情が連鎖的に広がり、手がつかないようなパニックやトラブルにも
  • 相手の大事にしている部分だと気づかずにぞんざいに扱ってしまうケースがほとんど
    • 「自分にとって大事なことで、ぞんざいに扱われたようで悲しい」ことを伝える
    • 怒りを感じたときに、「何がどのように傷つけられたのか」を深く捉える＝思いがけない自分自身を知ること
• 問題解決より問題認知のほうが難しい
  • 感情のない、認知が歪まない人間はいない：自分は論理的であると思い込むことこそ、非論理的な思考を生み出す
  • 複雑に入り組んだ問題に見えたことが、他人・自分の認知の歪みを取り除くと実はシンプルな問題に過ぎないこともしばしば
  • 人は自分が間違っているかもしれないことを無意識に避け、正しく認知できない
    • 「自分は間違っているかもしれないが、それに早く気付くほうがよい」と思考のパターンを変える必要がある

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

• わからないことは調べるしかない＜＜経験主義＞＞
  • 経験主義の対義語は「理性主義」あるいは「合理主義」
    • 聖書やアリストテレスといった「前提」から世の中を説明する：新しい知識は人間の「理性」の中にあるとする考え方
  • 経験主義は知識の源泉を「経験」に求める：実験を行ったり、行動を行うことでしか「知識」は得られない
  • ウォーターフォールをはじめとする「設計主義的プロセス」：実際の経験に基づかず、理性によって設計主義的にソフトウェアをくみ上げる
  • スクラムなどの「経験主義的プロセス」：スクラムガイドでも経験主義に関する言及
  • わからないことを行動で突き止める
    • 理性主義的な発想では、「わからなかった」という事実から次の行動へ移せない：「わからなかったのは頭が悪かったからだ」
    • 経験主義的な発想では、「わからなかった」「正解ではなかった」ことが重大なヒントとなり、次の行動へ移せる
      • すべての情報がそろっていないのだから、より問題をはっきりさせるための「次の一手」は何かを考えられる
• 不確実性と夏休みの宿題
  • 「自由研究」や「苦手な教科の宿題」などのどのくらい時間がかかるのかわからない宿題が残ってしまうと、夏休み中ずっと憂鬱
    • 「自由研究」などの不確実性の高い宿題は、実際に「やってみる」ことでどのくらいで終わるか見えてくる＝実際に行動をとることで不確実性が減り、スケジュールの予測精度が上がる
  • 不確実性の高いタスクこそ優先的に取り組むことができれば、時間の予測も正確になる
    • 不確実性の高いタスクに取り組むことは難易度が高い：不確実なものに直面することはとても不安なこと
• プロフェッショナルの仕事
  • プロの仕事：短い時間で一定のクオリティまで上げて、残りの時間でクオリティを作りこむ
  • アマチュアの仕事：残り時間が短くなってから、急速に出来上がる
  • 不確実性の高いものを最初期に仕上げていくと、全体像が早い段階で見える：プロフェッショナルほど、不確実性を最初期に下げることを心掛けている
• コントロールできるもの／できないもの
  • 経験主義では「行動できることは何か」と「行動の結果起きたことを観察できるか」を重視
    • コントロールできないものをコントロールしようとしても、いつまでたっても解決に向かわない
      • 雨が降っているときに、「雨が降っていなければなあ」と思っても仕方がない→濡れないように傘をさす
    • 「上司が自分の仕事を評価してくれない」ケース
      • コントロールできないもの
        • 上司の自分に対する内心での評価
        • 上司の評価基準
      • コントロールできるもの
        • 上司の評価基準を詳しく聞くという行動
        • 上司の評価基準に合わせた自身の行動の変化
        • 上司を変えるための異動などの行動
        • 自分の仕事を上司に詳しく説明するという行動
        • 自分自身の想いを上司に知ってもらうための行動
    • 「新入社員が『ゆとり』で全然仕事ができない」ケース
      • コントロールできないもの
        • 新入社員の能力
        • 新入社員の内心
      • コントロールできるもの
        • 新入社員への指示の出し方
        • 新入社員の行動へのフィードバック
  • 残念ながら私たちが操作できるのは、自分の行動や考え方だけ
• 観測できるもの／できないもの
  • 「新入社員の能力」はコントロールできないものだが、影響を与えるための行動をとることは可能
    • コントロールできないものを変化させようと試みるとき、その対象が「観察できる」必要がある
      • 「観測できないものは制御できない」
    • 「新入社員の能力」「新入社員の内心」は観察すらできない
  • 直接コントロールできないが「観察」できるものとは？→「新入社員の行動」
• あなたができること
  • 「コントロールできるもの」を操作し、「観測できること」を通じてその結果を知識とすること
  • 「コントロールできないもの」を操作して「観測できないもの」を改善するというのは不可能な問題設定
• 少ない情報で大胆に考える＜＜仮説思考＞＞
  • 推論能力の方法
    • 演繹法：ルールと事象から結論を導く三段論法
      • ルール：人間はみな死ぬ
      • 事象：ソクラテスは人間である
      • →結論：ソクラテスは死ぬ
    • 帰納法：観察・実験を通して集めた個々の経験的事実から、共通する普遍的な法則を求める
      • 事象：このカラスは黒い
      • 事象：あのカラスも黒い
      • →結論：すべてのカラスは黒い
    • 仮説法：「わずかな痕跡」から、それを説明可能とする大胆な思考展開、モデル化を行い、それを検証するための行動につなげる
      • 事象：2つの大陸の海岸線は似ている
      • 仮説：大陸は移動したのではないか
      • →結論：2つの海岸線が1つである証拠を探そう
  • 仮説法では「痕跡がわずかであっても」「確かめる行動につながる」ことが重要
    • 「十分な証拠がそろっていないから、仮説が作れない」「今までの前提から導けないからこの仮説は間違っている」など、演繹法・帰納法で捉えてしまうと次の行動につながらない
    • 仮説は演繹的、帰納的に導けるものではなく、人間的な直感やひらめきによって「大胆な飛躍」をもたらすもの：合議による凡庸なアイデアは仮説にはなりえない
• PDCAサイクル
  • 「仮説」の定義がないまま、計画が立てられ、何を検証するのかが明らかでないような状況が多くみられる
    • その結果、仮説は検証されず、何を確かめるためだったのかわからないため、改善もできない悪循環
  • 仮説検証のサイクルでは「何が仮説なのか」を明らかにし、どのようにしたら「検証できるのか」のアイデアを持つことが重要
• データ駆動な意思決定の誤解
  • 「大量のデータが存在すれば、次にとるべき正しい行動がわかる」とする誤解
    • 実際は、常にデータは不完全であり、そこから意思決定は導けない
  • 「データ駆動な意思決定」
    • 「仮説」を推論するために、持っているデータの可視化をする
    • 「仮説」がただしかったのか、統計的に検証する
  • データから演繹的、帰納的に決定論的に答えが導けるわけではない
• リアルオプション戦略と遅延した意思決定
  • 「遅延した意思決定」：最初から大きな意思決定を行い大失敗するよりも、小さく失敗をして、成功の確率が上がるまでは大きな意思決定を行わない考え方
  • 「リアルオプション戦略」：大きな意思決定を行う前に、より少ない費用で仮説検証を行えるような手立てを「オプション」として用意することで、不確実性を金銭的な価値に変換・可視化する
• 問題の解決よりも問題の明晰化のほうが難しい
  • 「問題は何なのか」という問いを明晰にしていく：直ちに解くことができない問題であれば、まだ問題が明晰ではない

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

• システムとは全体の関係性を捉えること
  • 要素還元的思考：要素がツリー構造になっている：要素の総和として全体の性質がわかる
  • 全体論的思考（システム思考）：要素がネットワーク構造になっている：要素の総和では全体の性質はわからない
  • 要素還元的に、直接的な関係性のある部分に分解して考えても、全体像を把握できずに思いもよらない結果を生むことがある
  • 要素の性質よりむしろ、要素同士の関係性に注目して問題の構造を解き明かす考え方が「システム思考」
• 部分だけしか見ないことで対立が起こる
  • 対立は、それぞれがそれぞれにとっての「部分」しか認識していないために発生することが多い：三次元の「U」
  • ビジネス全体のフィードバックサイクルをもったシステムの観点で見なければ、合理的に見える決断が、局所最適解に陥る可能性がある
  • 全体の関係性が見えれば対立は解消する
• 認知範囲とシステム思考
  • 「良い」プログラマとは？：問題解決のための眼があること
    • 「視野」：あるポイントから問題を眺めた時に、同時に把握できる領域の広さ
    • 「視座」：どこから眺めるか（高い／低い）：社長が現場感覚を理解するとか、平社員が部長の立場から見るとか
    • 「視点」：どの角度から見るか（鋭さ／凡庸さ）：普段は見えない角度から本質をえぐりだすのが「視点」の力
• 問題解決より問題発見のほうが難しい
  • 合理的に見える解決策が別の問題を引き起こしたり、想定しない悪化をもたらす可能性がある
    • 害獣を駆除するという解決策が、益獣までも根絶してしまう可能性

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

• コミュニケーションの不確実性
  • 他者理解の不確実性：人は他人や事象を完全には理解できない
  • 伝達の不確実性：コミュニケーションが到達するとは限らない
  • 成果の不確実性：仮に理解されたとしても予想されたように行動するとは限らない
  • 「情報の非対称性」：情報の偏り、ある情報を片方の人が知っていて、もう片方の人は知らないという状態
    • 「無能で十分に説明のつくことを悪意のせいにするな」：お互いの情報伝達が不完全なゆえに引き起こされた問題であっても、何か害意や悪意を見出してしまう
  • 「限定合理性」：自分と他人の利害が異なる場合に、それぞれがぞれぞれにとって合理的な行動をとっても全体として不合理な行動となること
• カレー作りの寓話
  • 情報の非対称性
    • ボブはパーティの客の求めているものを知っており、カレーの作り方は知らない
    • エバはカレーの作り方は知っているけれど、パーティの客の求めているものは知らない
  • 限定合理性
    • 効率を考えて「役割」を分けたことで、それぞれにとっての限定合理性が生まれる
  • 最初はお互いパーティの客をもてなしたいという思いで一致していたのに、コミュニケーションの不確実性を解消できないまま進んでしまった
    • コミュニケーションの不確実性は、未来の不確実性の増加として転嫁されてしまう
  • 真に組織に求められるコミュニケーション能力とは、コミュニケーションの不確実性を減少させる能力
    • 組織内で連鎖的に発生する不確実性のループを止め、集団に発生する「情報の非対称性」と「限定合理性」を低減させる
  • 「情報の透明性」：情報を公開するだけでは足りない
    • 正しく整合性をもって伝達されるよう努力すること
    • 何かわからない決定があったとしても、「隠そうとしたわけではないのだから直接聞いてみよう」という関係性を作ること
• 不確実性を削減し、秩序を作る
  • 自分自身がどのように本能にとらわれているかを知り、仮説と検証を通じて未来の不確実性を下げていきながら同じ目的で働いているはずの人々との間にあるコミュニケーションの不確実性も減らしていく必要がある

Chapter 2　メンタリングの技術

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

• メンタリングとは：対話を通じて、思考の幅を広げていくことで、その人の歪んだ認知を補正し、次の行動を促し、成長させていく手法
• メンタリングとエンジニアリングの関係
  • ソフトウェア開発の中でメンタリングのテクニックが必要となる場面
    • コードレビュー：よりよい考え方に気が付き、成長を促すもの
      • 「なぜ、そのようにしたのか」を問いながら、ポイントに気づいてもらう
    • ペアプログラミング：相互に対話的に問題解決を行う
      • 相互の信頼関係、一定のプライバシーへの配慮などが必要
    • 障害時ハンドリング：情報を整理し、事実と意見を分け、チームを支援する
    • チームマネジメント：スクラムマスター：1:1のメンタリングテクニックがなければ1:nのチームマネジメントは難しい
• 「自ら考える人材を作る」ためのテクニック
  • 依存型人材：問題を与えられてから考える、問題と解決策を渡されてから動ける
    • 物事の原因を他人に求め、善悪で判断を行う
  • 自立型人材：自ら問題を発見し解決することができる、問題について自分事としてとらえている
    • 物事の原因を自分に求め、善悪の二元論ではなく、今より良い状態にするために自分がどうしたらよいか？という問いを常に抱えている
  • 依存型と自立型の境界線を分ける要素：上司と部下の関係における期待値
    • 上司が「ここまでは自立的に考えてほしい」の期待値と部下の「ここまでは自立的に考えるのが自分の仕事だ」の期待値が一致しないままだと、お互い不満が募るばかり
  • 「コンフォートゾーン」：人は与えられた役割に対して、心地よくいられる思考や行動の範囲に閉じてしまう
    • コンフォートゾーンを変えるのは難しい：閉じた世界の中での「限定合理性」の中で考えるのは「心地よい」ものであるため
  • 「自己効力感」：自ら考えて動いた結果、ポジティブな結果を手に入れると、自立的な思考を行うことの快感（自己効力感）につながる
  • 依存的な思考を行う快感＝コンフォートゾーンより、自己効力感が上回るように導くことが必要
• 効果的なメンター／メンティの関係性
  • 効果的な関係性の条件（HRT：ハート）
    • 謙虚：お互いに弱さを見せられる（Humility)
    • 敬意：お互いに敬意を持っている(Respect)
    • 信頼：お互いにメンティ（自身）の成長期待を持っている(Trust)
  • メンターは「何か課題を指摘する」ための存在ではない
    • 課題に一緒に向き合い成長を支援する
    • それがメンティに伝わらなければ、メンター自体が成長を阻害する可能性
    • メンターのネガティブな特性がメンターに感染したり、「学習性無気力」を引き起こす危険性
  • 階段を上る手助け
    • 階段を認識させる
      • 上ばかり見て階段に気が付かないことも
      • 「階段があるよ」よりも「足元は大丈夫？」：見えていない課題に自分から気づかせることを重視
    • 壁にはしごをかける
      • 階段を上ったという実感が少ないと正のフィードバックループが途切れがちになる
      • はしごを一歩一歩上っている実感を提供
    • 階段を上りたくさせる
      • 階段を上ることが面白くなければ誰も上らない
      • ゴールの認識を合わせ、こうなりたいと思う状態をリアルに想像、そのために何をするかを考えさせる
• 「他者説得」から「自己説得」に
  • 他者説得
    • 他人が答えを伝える
    • 体感を伴わない
    • 理解を確認できない
    • 論理的には理解できて、反論はないけれど、いざ自分がやろうと思うと何をすればよいのかよくわからない
    • 伝えたほうはその人が納得しているのだろうと思い、結局それができないことを責めてしまう
  • 自己説得
    • 他人が質問で促す
    • 体感を伴う
    • 行動の変化が発生しやすい
    • 「上司ともっと話し合うべき」では響かないが、「上司はなぜそうしているのか？」「その人の考えていることがわからないのならどうする？」と解決策を自ら発見するよう促す
    • 答えではなく、質問を通じて思考回路の盲点となっている部分を外していき、自ら解決策に導く
• 「悩む」と「考える」の違い
  • 「悩んでいる」：頭の中に様々なことが去来し、ぐるぐると思考が巡り続け、もやもやが取れない状態
    • 苦しく、生産的でないため、結果が伴わない＝この状態ではサポートが必要で、共に考え戦略を立てていく必要がある
  • 「考えている」：課題を書き出したり、調査したり、何かと行動をとっていて、答えが出ていなくても手が止まるということはない
    • 次にとるべき行動がはっきりすれば、「考えること」はあっても「悩むこと」は少ない
  • 「考える」は行動で、「悩む」は状態

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

• 解けないパズルを変換する
  • 「ひとりでは解けない愛のパズルを抱いて」
    • 「愛のパズル」なので、（感情的に固執していて）解けない
      • 感情的に固執していて解けないので「傾聴」をする
    • 「パズルを抱いて」いるので、（客観視できずに）解けない
      • 客観視できずに解けないので「可視化」をする
    • 「解けないパズル」なので、（前提を変えないと）解けない
      • そもそも解けない問題なので前提を変える「リフレーミング」をする
• 空っぽのコップにしか水は入らない
  • 悩みや不安でいっぱいだと伝わらない：思考停止状態
  • 「傾聴」によりコップを空っぽにしてあげる
• 「傾聴」と「ただ話を聞くこと」の違い
  • 「傾聴」では相手を中心とし、「相手の思考が整理され、前向きに考えられるよう支援」することを意識
    • 「相手の」感情への共感を言動で表す
    • 「相手の」話の内容を「可視化」する
    • 「相手の」思考の「盲点」を探索しながら質問をする
• 共感をして話を聞き出す「信号」
  • 「相手の側に立って話を聞いている」という「信号」
    • しぐさ、うなずき、座り方
    • 表情
    • 相槌
    • 気が付かない信号を指摘してもらう
      • 自分はそういうつもりではないが、そんな風に感じることがあったら教えて
    • 共感と同感
      • 共感：個人的な感情に対して事情や価値観を理解し、相手の感情を理解すること
      • 同感：まったく同じ感情を持つこと
      • 傾聴に必要なのは「共感」であり「同感」ではない
• 問題の「可視化」と「明晰化」
  • 「可視化」：ホワイトボードやノートに書くこと、グラスなどのものを並べる
    • 物理的に目線を変えて、「問題と私たち」という構図にする
  • 「明晰化」：感情的な癒着をはがし、問題を簡単な問題に変換する
  • 事実と意見を分ける
  • フォーカスポイントを作る
    • 掛け算の「筆算」にあたることを手伝う：何桁の問題であっても、1桁の掛け算と足し算に問題を分解
      • 「今やっている仕事のゴールがわからない」
        • 「今やっている仕事」とは何ですか？
        • 「ゴール」とは例えば、どういうものですか？
        • 「わからない」というのはどういう意味ですか？
  • 「悩んでいる」＝「いくつかの選択肢を比べることができない」
    • 「選択肢」が不明確
    • 「比較軸」が不明確
    • 「評価方法」が不明確
• 認知フレームとリフレーミング

  • 認知フレーム：自分の持つ「認知する枠組み」の中でしか情報を処理することができない：認知フレームの外側は「心理的な盲点」

    • 人はありのままに物事を見られない：不安や焦り、優先順位といったことで枠組みは変化する

  • 「リフレーミング」：認知フレームを変更するテクニック

    • 囚われている認知フレームを変えていくことで、「解けない問題」を「解ける問題」に変えていく

  • 認知フレームを発見するキーワード

    統計	表現例	隠れた認知フレーム
    こちら系	「この会社」「この人は」「この部署は」「ここでは」	同じ側にいるように思われているが、自分は同じではないと感じているときに使われる。一体感を持っていない
    あちら系	「あの部署は」「あの人は」「あそこは」「あいつは」「彼らは」	自分たちと大きく同じくくりにいるはずなのに、自分たちとは明確に違う目的で動いている。線引きの向こう側の存在として考えている
    極端系	「いつも」「すべて」「絶対に」「無駄／無意味」	ゼロかイチで、グラデーションがない状態で物事を認知している
    すべき系	「常識的に」「普通」「～すべき」「～しないと」	「～すべき」という思考の枠組みがあって、その中に限定して考えようとしている
    決めつけ系	「どうせ」「～に違いない」	感情的に決めつけて、事実を確認せずに推論している

  • 前提の確認と取り外し

    • 「前提を問う」：「そもそもなぜ問題なんでしたっけ？」「具体的に何が困るんでしたっけ？」「どうなったら解決でしたっけ？」「良い解決策の条件はなんでしたっけ？」
    • 「いったん、この前提がなかったらどうなりますか？」＝外して考えることでリフレーミングを促す
    • 「一番重要だと思うものは何ですか？」＝前提の優先順位を問うことでリフレーミングを促す

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

• 「アットホームな会社」は心理的安全性が高いか

  • 高い生産性につながるような「心理的安全性」と、緊張感のないぬるま湯的な「心理的安全性」は何が違うのか？
  • 心理的安全性を高めることによる影響
    • 率直に話すようになる
    • 考えが明晰になる
    • 意義ある対立が後押しされる
    • 失敗が緩和される
    • イノベーションが促される
    • 組織内の障害でなく目標に集中できるようになる
    • 責任感が向上する
  • 「心理的安全性が高い」＝「対人リスクを伴う行動が増えること」
    • 「対人リスク」：個々人の関係性が損なわれる可能性がある行動
      • 相手との関係性は決して崩れることはないだろうという確信が持てる状態
  • 「意見が対立すること」を「仲が悪い」と考えてしまうような風土があると、嫌われないように意見を殺してしまう
    • お互いに過度に心を読みあって、指摘すべき点もできない「うわべ」の関係：高い生産性にはつながらない
  • メンタリングにおける心理的安全性
    • メンティの弱さ、メンティの失敗を開示してもらう
    • 自分の弱さ、自分の失敗を開示する

• アクノレッジメントとストーリーテリング

  • アクノレッジメント：「承認」
    • 存在承認
    • 行動承認
    • 結果承認
  • 傾聴や声がけ、感謝を伝えることもアクノレッジメント
  • 相談してフィードバックを求めることもアクノレッジメント
  • 当たり前のことを意識してやること
    • ちゃんと挨拶する
    • 無視しないで話を聞く
    • 相手に感謝を伝える
    • 気にかけて話しかける
    • 自分本位でなく相手本位で話をする

• ストーリーテリングの重要性

  • 自分の経験を物語として相手に追体験させ、理解を深めてもらう
    • 自己開示
    • 感情の共有
    • 価値観の共有
    • 返報性の原理

• ジョハリの窓と心理的安全性

  • 自分がわかっている／わかっていない、他人がわかっている／わかっていない
  • 自分も他人もわかっている「解放の窓」を自己開示とフィードバックによって広げることで、「未知の窓」が開かれる＝成長を引き起こす

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

• 内心は見ることができないが，行動は見ることができる
  • 「手が止まっている時間が長い」とか「リリース前の確認を怠った」などの具体的な行動を「仕事に対する甘さ」という抽象的で捉えどころのない問題に変換してしまう＝解決しない
  • 具体的な行動について、変に脚色せずに伝え、どうしてなのかを問いかける→具体的な行動を提案する
• SMARTな行動
  • 次の行動への合意の時にはSMARTを意識する
    • Specific：具体的な
    • Measureable：測定可能な
    • Achievable：到達可能な
    • Related：関連した
    • Time-Bound：時間制限のある
• 「わかった？」は意味のない言葉
  • 何かを説明して「わかった？」：「自分にとってのわかった」と「他人にとってのわかった」は違う
    • 観測可能で具体的な行動を通じて、理解を確認する必要がある：「わかる」の定義を「具体的行動を行うことができる」に変換
      • 「試しに1人でこれをやってみて」、「代わりに自分の言葉で説明してみて」
• 能力は習慣の積分，習慣は行動の積分
  • 成長のサイクルは「行動」・「習慣」・「能力」・「成果」のループ
    • 「能力」や「成果」に直接的に干渉はできないが、「行動」や「習慣」は成長を促すことができる
• なぜ行動を起こせないのか？
  • 行動を起こせないとき：行動を「促進する力」より「阻害する力」のほうが大きい
    • 行動を促進する力を増やしたり、阻害する要因を減らす：「リインフォース（再強化）」
• ゴールへのタイムマシンに乗る
  • 自立的な人材
    • 自分の気が付かなかった問題に気が付くようになる
    • 認知の歪みによる感情と問題の癒着を切り離せる
    • 答えではなく、次の一手を生み出す行動がとれるようになる
  • ゴール認識
    • 0：願望：「お金持ちだったらなあ」
    • 1：義務：「お金持ちにならないといけない」
    • 2：欲求：「お金持ちになりたい」
    • 3：意思：「お金持ちになるぞ」
    • 4：必然：「お金持ちになっている」
  • ゴール認識が高いレベル4の確信を持っている状態になることで、自分の今の状態を将来の自分から見てメンタリングできる

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

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

• 日本と世界のアジャイル開発普及率
  • 日本は30～40%、世界的には60～95%
• 日本国内ではアジャイル実践者の数が圧倒的に少ない
• アジャイル開発が必要とされた2つの理由
  • ソフトウェアが大規模化、複雑化したこと
  • マーケットの不確実性に対応する必要性が出てきたこと
• アジャイル開発は3倍の成功率，1/3の失敗率
  • アジャイル開発への誤解：大規模開発には不向き
    • 大規模開発でこそより効果的という統計
    • 「管理をしない」「エンジニアの合議で決める」「設計を全くしない」などのありがちな誤解
• プロジェクトマネジメントとプロダクトマネジメント
  • プロジェクト
    • 目的：終了すること
    • 抱えている不安：スケジュール不安
    • 対処すべき不確実性：方法不確実性
  • プロダクト
    • 目的：終了しないこと
    • 抱えている不安：マーケット不安
    • 対処すべき不確実性：目的不確実性
  • 目まぐるしく変化する市場環境や顧客ニーズにこたえていく必要性が出てきたことで、プロジェクト型開発からプロダクト型開発へ
• アジャイルをするな，アジャイルになれ
  • アジャイルな状態とは
    • 情報の非対称性が小さい
    • 認知の歪みが少ない
    • チームより小さい限定合理性が働かない
    • 対人リスクをとれていて心理的安全性が高い
    • 課題・不安に向き合い不確実性の削減が効率よくできている
    • チーム全体のゴール認識レベルが高い
• ウォーターフォールかアジャイルか
  • ウォーターフォールのスコープ：プロジェクトマネジメント
    • 「方法不確実性」とそれに伴う「スケジュール不安」
  • アジャイルのスコープ：プロダクトマネジメント
    • 「方法不確実性」に加えて、「目的不確実性」と「マーケット不安」、「通信不確実性」と「継続するチームマネジメント」
  • ウォーターフォールとアジャイルは異質な前提に立ったものであり、比較対象ではない
  • アジャイルな方法論は、組織間の「限定合理性」と「情報非対称性」の解消を試みるアプローチ

3-2　アジャイルの歴史

• アジャイル開発は経営学
• デミング博士とPDCA
• トヨタ生産方式とリーン生産方式
• 生産方式から知識経営へ
  • SECIモデルとダブル・ループ学習
    • SECIモデル：暗黙知が形式知に変わる→その形式知が組織全体に広がり暗黙知として根付く→それを土台に新たな暗黙知が生まれるようなループをモデル化したもの
    • ダブルループ学習：「行動」と「結果」のシングルループ学習に、環境の不確実性を取り込んで「前提」を変えていく学習ループ
      • 前提を変えていくとは「リフレーミング」
• 生命科学の発展と社会科学への流入
• ハッカーカルチャーと東洋思想への憧れ
• 軽量ソフトウェア開発プロセス
• アジャイルソフトウェア開発宣言
  • 「従来重視されてきたもの」「これから重視していくべきもの」の対比による宣言
    • プロセスやツールよりも、個人と対話を
    • 包括的なドキュメントよりも、動くソフトウェアを
    • 契約交渉よりも、顧客との協調を
    • 計画に従うことよりも、変化への適応を
  • 「前項の事柄に価値があることを認めながらも」：まったく不要ではない：対立ではなく対比
• アジャイルの歴史に見る3つのポイント
  • 日本は米国に、米国は日本に学んだ
  • 組織学習をプロセスに取り込んだ
  • 複数の軽量プロセスの総称

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

• アジャイルに関する5つの誤解
  • 誤解１：アジャイル開発は決まったプロセスである
    • アジャイル開発は、アジャイルなチームを作るための方法論で、複数の軽量開発プロセスの総称：ルールは少なく、自由度は高い
    • アジャイルなチームを作るという目的を達成しながら、ウォーターフォールで意識されるスケジュール不安中心に対応するプロセスも可能
  • 誤解２：アジャイル開発では設計をしない
    • 顧客に価値を届けることが最大の目標であり、中間成果物を「価値」とはみなさない
      • 設計工程だけでは進捗とみなさないだけで、必要ならばドキュメントを書いてもよいし、ナレッジの形式知化は重要な組織学習の要素
      • 旧来の設計文書より情報の伝達効率の良い方法があればそちらを利用する
  • 誤解３：アジャイル開発は優秀なメンバーでないとできない
    • アジャイルができないほどのメンバーであれば、ほかのプロセスを採用してもうまくいかない
    • アジャイル開発はメンバーに自立性が求められ、チームは常に課題と直面する
      • そこで生まれる問題は成長を促すことにつながる
  • 誤解４：アジャイル開発では中長期計画がない
    • 計画を立てることはいつでもできるし、計画が変化したとしても柔軟に動く
      • 不確実性が大きいケースでは中長期計画を立ててもさほど意味がない、ということはあり得る
  • 誤解５：アジャイル開発は開発者に決定権がある方法だ
    • アジャイルなチームは、開発しているプロダクトの顧客ニーズやビジネス価値について、深く理解するようになっていく
    • そのため、優れたアジャイルチームになるほどに権限が徐々に委譲されていく
      • 本来であればそのことがさらに生産性を向上させていくが、開発とビジネスの間に情報の非対称性や限定合理性が発生している場合は最悪な結果を導く
• アジャイルはなぜ誤解されるのか
  • 経験主義が理解されていない
  • メタファーがわかりにくい
  • 対立の図式で流通した
  • すでにあるビジネスと開発の対立を促進してしまった
  • 従来の手法を重視する人のアイデンティティに触れた
  • クールエイドを飲むな
    • アジャイルという言葉、考えに対して安直に無批判に受け入れてしまう人々が現れた＝教条主義的に「こうでなくてはだめだ」が誤解を増大させた

3-4　アジャイルの格率

• 「アジャイル」は理想状態
  • 自己組織化：「チームが環境に適応して、不確実性を最も効率よく削減できている状態」
• アジャイルな方法論
  • 「どうしたらもっと不確実性を減らせるのか」
    • 不安に向き合うこと
      • チームの力を借りて不安に向き合う
      • 問題を隠してしまうよりも、チームで共有したほうがよい＝対人リスクをとりやすくすることで促す
      • 認知フレームを取り外し、解決策を模索することで、不安が通信不確実性に転嫁されることを防ぐ
    • 少人数の対話を重視する
      • 情報の非対称性を減らす
      • 心理的安全性が十分に高く、相手にリスペクトを持っていれば、破滅的なコミュニケーション断絶は起きない
    • 役割を分けない
      • 「カレーの寓話」：役割を分けたことで異なる目的意識が発生し、「限定合理性」を生み出す
      • 「役割を遂行するにはどうしたらよいか」ではなく、チーム全体の目的において「いま自分は何をすべきか」
    • 経験のみを知識に変える
      • 実験を行う前にいくら実験結果を議論しても答えは出ない：まず実験してみる
    • 意思決定を遅延する
      • 「仮説思考」「リアルオプション戦略」
    • 価値の流れを最適化する
      • システムのパフォーマンスの最適化
        • レスポンスタイム
        • スループット
      • 「価値」とは？－開発チームとプロダクトオーナーの意思が統一されていることが重要
• アジャイル開発は「脱構築」される
  • 必要なことは、外でうまくいっている何かを探すことではなく、しっかりと自分たちを取り巻く状況を観察すること
  • 流行りのカッコよさを教条的に取り入れるのではなく、今なにをすべきかをしっかりと周囲と対話していくこと

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

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

• 不確実性マネジメント
  • 方法不確実性：スケジュール予測と見積の手法
  • 目的不確実性：要求と仮説検証の手法
  • 通信不確実性：振り返りの手法

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

• スケジュールマネジメントの基本
  • 理想工期：総作業時間／人数
  • 制約スラック：作業同士の依存関係による無駄
  • スケジュールマネジメントの3つの観点
    • 制約スラックを削減する
    • 見積の予測精度を上げる
    • プロジェクトバッファの消費を可視化し改善する
• 制約スラックとクリティカルパス
  • リソース制約
  • 依存制約
• 悲観的見積りと楽観的見積り
  • プリンシパル・エージェント理論
    • エージェンシースラック：依頼者からみて、代理人に「嘘をついたほうが得になる」と思わせてしまうことで高くついてしまう差額
    • コントロールコスト：依頼者の利益が代理人の利益になるようにするためのコスト
    • シグナリングコスト：代理人である「情報を持つ側」が情報を開示するためのコスト
  • あくまで予測である見積を「ノルマ」として扱った場合、それを達成するための過負荷がかかる可能性がある＝エンジニアは悲観的な見積もりを行うようになる
• スケジュール不安の「見える化」
  • CCPMアプローチ：不安量を集めて管理する
    • 個別のタスクのバッファをいったん取り除き、プロジェクト全体としてのバッファとして再設定する
    • プロジェクトの進捗率とバッファの消費率を経過観察＝バッファの消費率という形での「見える化」
  • 多点見積
• 計画でなく実績から予測する
  • 小さいスプリントを繰り返す
  • ヴェロシティと生産性
  • ヴェロシティを用いたスケジュールマネジメント
• 要求粒度と不確実性
  • 作る工程そのものよりも「何を作るのか」が決まっていく過程の方が実際には多くの不確実性を持っていてブレ幅が大きい
    • 要求が詳細化していく過程そのものもマネジメントする必要がある
  • ボトルネックを探してスループットを上げる
    • プロダクトの開発におけるバリューストリーム
      1. 顧客の課題を特定し仮説検証戦略を作る
      2. 開発要求を固める
      3. 実際の開発を行う
      4. テストをする
      5. リリースする
      6. 効果検証を行う
• スケジュール不安はコントロールできる
  • スケジュール不安の大きい開発者と経営者という関係性がある場合には、まずその「情報非対称性」を取り除くことが重要
    • スケジュール以外にも重要なことがあることをお互いに気が付く必要がある

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

• スケジュール不安とマーケット不安の対称性
  • 時間境界型プロジェクトと機能境界型プロジェクト
• マーケット不安はいつ削減できるか

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

• 不安に向き合うフレームワークとしてのスクラム
  • スクラムにおける役割
    • プロダクトオーナー
    • 開発チーム
    • スクラムマスター
  • スクラムにおけるイベント：スプリントの最中と周辺にいくつかのイベント
    • スプリント計画：プロダクトバックログを実現可能なスプリントバックログに変換する会議
      • タスクの分解
      • 実現方法の検討
      • 課題点の洗い出し
      • 詳細見積　など
    • デイリースクラム：毎朝、チームの全員で、1分程度でその日やることや前日までの課題を簡潔に話す会議
    • スプリントレビュー：プロダクトオーナーがインクリメントをレビューする
    • レトロスペクティブ：振り返り会議
  • これらのイベントにより、チームの学習を促す
    • 目的不確実性に伴うマーケット不安に向き合う
    • 方法不確実性に伴うスケジュール不安に向き合う
    • 通信不確実性に伴う「情報の非対称性」を減らす
• どこに向かって、どのように振り返るか

  • インセプションデッキ：ゴール設定のフレームワーク

    • どこに向かって、なぜ走っていくのかを明確にして、「ゴール」を設定することで、「どこに向かって」振り返るのかがはっきりする
      1. 我々はなぜここにいるのか(Why1)
      2. エレベーターピッチを作る(Why2)
      3. パッケージデザインを作る(Why3)
      4. やらないことリストを作る(Why4)
      5. 「ご近所さん」を探せ(Why5)
      6. 解決案を描く(How1)
      7. 夜も眠れなくなるような問題は何だろう(How2)
      8. 期間を見極める(How3)
      9. 何を諦めるのかをはっきりさせる(How4)
      10. 何がどれだけ必要なのか(How5)

  • 振り返りの流れ

    • ０．ゴール再認識
    • １．テーマ設定
    • ２．現状整理
    • ３．よかった探し
    • ４．問題の洗い出し
    • ５．問題の深堀
    • ６．対策の決定
• 不安を知りチームマスタリーを得る
  • 本当の不安は無意識のうちに閉じ込められている：「不安は何か？」と聞いても出てくるものではない
    • 「ゴール認識のレベル」が高くなってくると、自然と不安の正体が明らかになる
      • ただ単に「わからない」ところから出発し、チームが自分たちが今わからないものを「どのようにしたらわかるようになるのか」「わかったものからどのようにしたら改善するのか」を意識できるようになると、チームは自分たち自身の手によって広い視野での問題解決を進められるようになる＝自己組織化、チームマスタリーを得ている状態

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

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

• 生産性という言葉の難しさ
  • 労働生産性の定義：労働生産性＝付加価値額／従業員数
    • 企業における付加価値額とは、企業全体をシステムとして、投入した労働人数に対してどれだけの付加価値が得られているか
      • 営業や技術といった個別の部署で測定できるものではない
  • 生産性を向上させるのであれば、技術組織という企業システムのほんの1要素ではなく、企業全体の構造に注目する必要がある
  • 「生産性」という言葉は、日常語として曖昧な意味のまま使われ続けているが、組織の効率性としての指標にはあまり向いていない
• 組織の情報処理能力
  • 企業の成長につながる能力とは、市場に存在する不確実性を効率よく仮説検証する能力
  • 「不確実性の削減」＝「情報を生み出す」こと：情報処理の低い企業組織では、市場の不確実性にうまく対応できない
  • ガルブレイスによる組織の情報処理モデル
    • 保有するシステムを含む組織形態から、企業の「情報処理能力」が決定する
    • 対象となる市場の不確実性から、必要となる情報処理量が決定する
      • 市場の不確実性が高いほど「情報処理の必要量」が多くなる
      • それに対して組織の持つ「情報処理能力」が上回れば、「組織成果」につながる
  • 組織の情報処理能力を決めるもの
    • エンジニアリングの不確実性
      • 環境不確実性
        • 目的不確実性
          • 戦略　＝　ガルブレイスモデルの「情報処理必要量」
        • 方法不確実性
          • 戦術　＝　ガルブレイスモデルの「情報処理能力（組織形態）」
      • 通信不確実性
        • 兵站　＝　ガルブレイスモデルの「情報処理能力（組織形態）」
    • ガルブレイスモデルの「情報処理能力」は「生産性」のイメージに近いもの
  • 個人の総和が組織の能力にならない
    • 完璧な情報伝達はできないし、それぞれに思惑を持っている
    • 人数が増えるほどコミュニケーションの失敗が発生し、情報処理能力が減衰する
    • コミュニケーションコストを減らすことが組織のケイパビリティ向上につながる
    • コミュニケーションは「発信」と「到達」に加え、「受信」と「正しく受信されたか」が不可欠
    • 「情報の非対称性」が組織の情報処理能力を減少させる
      • 誰が、どのような人と、どれだけ、どんなコミュニケーションをするのかという設計が必要
• 組織とシステムの関係性
  • 分割された組織では、事業全体の情報は見えにくくなり、自部門の情報は見えやすくなる
  • エンジニア組織は、組織の下流工程に位置しやすい
    • 市場の不確実性を判断する経営層、戦略を練るビジネス部門から最も遠い部門
  • 階層的に組織が分断されることで情報伝達の制度は下がる
  • 対等な関係性を持った部門とされていても、組織の情報処理の構造が「誰かが誰かに依頼する」関係になっていると、エージェンシースラックが生まれる
  • 「システムそのもの」に、組織の不合理が蓄積される
    • コンウェイの法則：「システムを設計する組織は、その構造をそっくりまねた構造の設計を生み出してしまう」
    • コミュニケーションコストが多くかかるであろう環境ほど、バグが多くなる
    • 組織構造は「コミュニケーションコストの構造」
    • 例えば、別の3つのチームとの協議、上長からの4つの稟議書が必要な機能開発があった場合、コミュニケーションを回避して実装できるような機能を開発したほうがよい、と判断するようになる
      • コミュニケーションコストが低い構造でシステムを作ることが最も効率的になってしまう＝コンウェイの法則
• エンジニア組織の情報処理能力を向上させるには？
  • 「ソフトウェア開発上の問題の多くは、技術的というより社会学的なものである」（トム・デマルコ『ピープルウェア』）
  • 組織のコミュニケーション構造のリファクタリング
    • 権限委譲と期待値調整
      • コミュニケーションの必要性を減らし、失敗を防ぐためには適切な権限委譲とそれに伴う期待値の調整が必要
    • 適切な組織・コミュニケーション・外部リソース調達の設計
      • 職能ではなく、責任やケイパビリティの単位で組織やコミュニケーションを設計していくことで、コミュニケーションコストを減らし、システムに反映される
    • 全体感のあるゴール設定と透明性の確保
      • 組織の各要素の間で生まれる情報の非対称性を減らすため、透明性の確保と全体感のあるゴール設定を持つことで、限定合理性の発生する余地を減らしていく
    • 技術的負債の見える化
      • 組織的な問題の発露である「技術的負債」現象の見える化を通じて、対応可能な課題に変えていく

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

• 組織と権限
  • 企業活動は権限を従業員の一人一人に分割しないと成立しない
    • 権限を委譲された側は、権限に見合う会社のリソースを取り扱うことができ、権限に見合う自由を手にする
    • 権限には、それに対応する責任（説明責任）が伴う
  • 責任と権限の不一致
    • 権限と責任は整合性を持たなければならない
    • 権限がないのに責任がある、責任がないのに権限がある＝組織に悪い結果をもたらす
    • 従業員にとって明示的でない権限は、最も不自由な状態
      • 上司の胸先三寸で権限について差配できることを意味する＝実質、すべての権限が上司にある状態
    • 上司と部下の間で認識している権限とそれに伴う責任の不一致＝上司と部下の期待値が異なる状態
• 権限と不確実性
  • 組織の人数が増え、その情報処理能力を活用するためには権限の明確な委譲が不可欠
    • 「従業員が経営者意識をもって動かない」という愚痴
      • 「権限委譲のコミュニケーションが失敗しているか、委譲ができないような組織しか作れていない」という自身の問題
    • 「自分に権限がないので問題点を改善できない」という愚痴
      • 「自身が必要な権限を獲得できるだけの信頼を得られていない」という自身の問題
• 権限委譲のレベルとデリゲーションポーカー
  • 権限委譲のレベル
    • レベル1：命令する：上司がすべてを決定して命令する＝すべての権限は上司
    • レベル2：説得する：上司が部下に対して「なぜそうするのか／どうしてやるのか」を説明・説得＝部下は説明をよく理解し趣旨に合うように実施
    • レベル3：相談する：上司が行う提案を部下に対して相談する＝最終決定の前に、部下に意見を求める
    • レベル4：合意する：上司と部下が合意をして初めて遂行する＝上司と部下の権限は同じレベル
    • レベル5：助言する：部下が提案を行い、上司は気になる点などを指摘する＝助言であって命令でないので、部下はすべて聞き入れる必要はない
    • レベル6：尋ねる：部下に決定権が委譲されている＝上司が報告を求めたときには説明する責任がある
    • レベル7：委任する：部下が上司の確認なしに実施をしてよい＝上司がそのことについて尋ねたときのみ回答する
  • 上司はより高いレベルで部下に権限を委譲できるように育成する必要がある
  • 部下は自分の権限を拡大できるよう、自分の問題認識レベルのどこが足りないのかを真摯に向き合い、成長する必要がある
  • 権限委譲のレベルについて、上司と部下で合意点を作ることは非常に重要
    • デリゲーションポーカー
    • 権限の可視化とコンセンサスボード
• 権限の衝突
  • ある目的のための責任と権限を持った複数の組織は、組織の目的遂行や組織の維持のために大なり小なりの衝突が発生する
  • 権限の衝突はそれぞれの組織の上位組織によって解決が促される
• 権限と組織設計
  • 権限と責任という観点から見る組織設計のポイント
    • 明示的な権限と責任の委譲を行う
    • 権限と責任の不一致をなくす
    • 権限同士の衝突を最小にする
    • 権限の衝突解消レベルを最小にする

5-3　技術的負債の正体

• 技術的負債：一般的には、「早さ」を求めて構築されたシステムの構造的な課題が徐々に蓄積し、債務であるように徐々に開発速度そのものを遅くしていく現象
• 技術的負債をめぐる議論
  • 「最初のコードを出荷することは、借金をしに行くのと同じである。小さな負債は、代価を得て即座に書き直す機会を得るまでの開発を加速する。危険なのは、借金が返済されなかった場合である。品質の良くないコードを使い続けることは、借金の利息としてとらえることができる。技術部門は、欠陥のある実装や、不完全なオブジェクト指向などによる借金を目の前にして、立ち尽くす羽目になる。」
  • 「負債」の解釈
    • 非経営者：「放っておいてはいけない」「定期的に返済すべきもの」＝「借金」
    • 経営者：資本の意味合いもある、利子が低ければ経営上有利＝借金よりポジティブな意味合い
  • 曖昧な「技術的負債」の定義
    • 「不可解な開発速度の低下」
      • 開発初期は単純な機能であることが多く、新機能の実装も比較的簡単
      • しばらく開発を続けると、同じような要求をしているつもりでも「時間がかかる」ようになる
        • 開発者以外は理解しにくい現象
      • 「ジェンガ」のようなもの
• コミュニケーションのための分類

  • 「何が負債であるか」の議論よりも、「技術的負債になりえる要素がどのように生み出されるのか」

    • 技術的負債の4象限：「無鉄砲な／慎重な」「意図的な／無意識の」

      	無鉄砲な	慎重な
      意図的な	どうせ設計する時間は取れないから、こんな風に作ってしまえ	リスクはあるけど、リリースの方を優先仕様
      無意識の	オブジェクト指向や設計の方法なんかよくわからないし	よし俺的にはこれで大丈夫だ！

  • 以下の考え方は本当だろうか？

    • 慎重かつ意図的に作られた負債であれば、問題なく返せるだろう
    • 無知や無鉄砲さから生まれた負債は予想しない利息を支払うこととなるため避けるべきである
    • 「後の負債になることを意識して慎重に行えば開発を早くすることができる」
    • 「後の負債になることを避けようと思えば、開発時間を長くすることで回避することができる」
• クイック＆ダーティの神話
  • コードを書く上で「綺麗さ」と「早さ」はトレードオフの関係とされる
    • 実際には「ソースが汚くて遅い人」も「綺麗で早い人」もいる
  • プロダクトは市場の不確実性を考慮して要件が変わっていく
    • 変化を予見してコードが負債になるかならないかを盛り込むのは不可能
  • 負債として理解していれば汚いコードを書いていいわけではない
  • その時できる限り良いコードを書く重要さ
    • YAGNI原則に代表される、「今ある機能をシンプルに作る」
• 技術的負債は「見ることができない」
  • ソースコードをしかるべき人が見れば読み解くことができるが、システムの表面的な機能だけでは知りうることができない
  • エンジニアと非エンジニアの視点は、CTスキャンされた図像で人体を見ているか、肉眼で表面的に見ているかくらい違う
    • エンジニアと非エンジニアの「技術的負債」に関する情報の非対称性が、「技術的負債」が問題になる最大の理由
• 理想システムの追加工数との差による表現
  • 現状のシステムでかかる工数と「理想的なシステム」でかかる工数の差で技術的負債は表現できるという考え方
    • ある機能を追加するときに50人日かかるシステムが、「理想的なシステム」では20人日で済む場合、差の30日という逸失コストが技術的負債
  • 「技術的負債」：経営者とエンジニアのコミュニケーションのために生まれた言葉
    • システム内部に起こる「複雑性の増加」によってコストが増えることを経営者は理解しにくく、数値化もしにくい
    • 「負債」というメタファーを当てて、合理的判断がしづらいというコミュニケーション上の問題を解消しようとした
  • 「技術的負債」で問うべきはエンジニアチームと経営者の間に存在する認識の差であり、システムの複雑性の増加そのものではない
  • 「技術的負債」の「隠れた原因」
    • 追加機能の情報非対称性：経営者の頭の中にある「これから追加していきたい機能」と同じものをエンジニアがイメージできているわけではない
    • アーキテクチャが見えないという情報非対称性：エンジニアはシステム内部を「CTスキャンの目」で見ているが、多くの経営者はそうではない
• 見えてしまえば「技術的負債」ではない
  • テクニカルな問題だと思われる「技術的負債」は、実はコミュニケーション上の問題
  • 見えていて、管理できてしまえばあとは実行していけばよい
    • ところが、「技術的負債の解消」に関するタスクは見えづらい
      • なんだかよく見えないときは化け物のように恐ろしいが、見えてしまうとタスクの積み重ね
  • 一般には非機能要件：表面の機能には影響がないが、性能や拡張性、運用性に関するもの
    • 1つ一つが見えてしまえば、まだ満たされていない「非機能要件」のリストとして管理可能
• 技術的負債に光を当てる
  • 技術的負債に光を当てるために必要なこと：2つの情報非対称性の解消
    • 「エンジニアは知っていて、経営者が知らないこと」：アーキテクチャの複雑性
      • コード複雑度（循環的複雑度）の可視化
      • コード依存関係の分析
      • コードチャーンの分析
        • 「誰が」「いつ」「どこを」「どのように」コードを修正したのかというリスト
    • 「経営者は知っていて、エンジニアが知らないこと」：将来要件の不確実性
      • ユビキタス言語の作成：ビジネスドメインを知る人々とプログラマーなど、ステークホルダー間で共有する単語とその定義
        • サービスを取り巻く諸概念を、日常語とは違う形で厳密に定義し用いることで、システムの関係性のブレをなくしていく
      • 非機能要件の可視化
        • 保守性などの非機能要件であっても、投資規模を決め、優先順位の高いものから処理していくなどの「見える化」が必要
      • 仮説と戦略の透明化
        • 仮説段階だとしても戦略や意思決定を透明に議論する

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

• 取引コスト理論
  • 探索のコスト：取引相手を見つけるために支払うコスト
  • 交渉のコスト：取引相手と交渉を行うために発生するコスト
  • 監督のコスト：取引相手が契約した取引を履行するように監督と矯正を行うコスト
  • 取引コストによって、何を内製し、何を外注するかが決まる
  • 取引コストはお互いの利害関係が一致しないための限定合理性から生まれる
• ホールドアップ問題
  • コアコンピタンスを外注に依存するなど、企業内にあるべき事業上のケイパビリティが外部にあると、大きな取引コストが発生
• アーキテクチャと外注管理
  • APIによる取引コストの削減
  • 外注とプラットフォーム戦略
    • 例：AppleのApp Store
• 社内における取引コスト
  • 同一企業内でも、それぞれの組織の限定合理性により、取引コストを支払ってしまう
  • 全体最適はどこにあるか
• 機能横断チームの重要性
  • 機能横断チーム：職能・職種を横断してチームを組成し、意思決定者と能力を持つ人員の取引コストをできる限り下げたチーム
  • 意思決定のスピードと高いコミット意識を持つ状態を維持・育成
  • 機能横断チームの能力を引き上げるキーワード例
    • 地理的に近い配置
    • 十分な権限委譲
    • 心理的安全性の高さ
    • 目的の透明性

5-5　目標管理と透明性

• 誤解された目標管理
  • 経営学の出発点：工場における生産力の向上
    • ノルマによる生産量コントロール→機械のように扱う手法の限界→目標による管理
• 抜け落ちたセルフコントロール
  • 目標による管理：MBO(Management By Objective)：Self Control
    • 目標による管理およびセルフコントロール
      • 「不可能ではないが挑戦的な目標」を「従業員自ら設定」し「従業員が納得して達成に臨む」よう支援する
  • 「目標」と「ノルマ」が同一視されて運用：「セルフコントロール」が抜け落ちたため生まれた誤解
• OKRによる目標の透明化
  • OKR(Objective and Key Results)
    • Objective：目標
    • Key Results：主な結果：どのような変化がある程度定量的に判断されるのかを明示
  • 目標を達成できたのか判断しやすい
  • 目標と結果の不一致がある場合に早期に発見しやすい
• 透明性と情報公開
  • OKRの先進的なポイント
    • 「目標による管理」をしっかりやり直す
    • 「透明性」を重視する
      • 目標設定を通じて、従業員一人一人が組織全体を見渡して、自分が何のために仕事をしているのかを深く理解する

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

• 取引コストとアーキテクチャ
  • 動きやすい仕事と動きにくい仕事
    • システム開発において動きやすさを決めるのはアーキテクチャ
    • 企業活動で言うと組織構造
• 逆コンウェイ作戦
  • コンウェイの法則を逆手にとって、積極的な組織設計やコミュニケーション設計をビジネス戦略に基づいて行うことで、アーキテクチャ自信をより良いものに変えていこうという考え方
• マイクロサービスアーキテクチャ
  • ビジネスの各要件ごとにチーム編成し、チームの中だけでUI、AP、DBなどの技術レイヤを担当できるようにする＝取引コストの小さい組織
  • マイクロサービスの特徴
    • サービスによるコンポーネント化：独立的で交換可能なサービスとして、コンポーネントに分ける。個別にアップグレード可能な設計にする
    • 分散ガバナンス：言語選定やDB選定などをチームに権限を与えて、最適な選択肢を選べるようにする
    • スマートエンドポイント：HTTPによるAPIや軽量メッセージングシステムによるエンドポイントの提供
    • 分散データ管理：ドメイン駆動設計におけるコンテキスト境界となるようにデータの管理を分解する
    • プロジェクトではなくプロダクト：プロジェクトのように終わりのある開発ではなく、継続的に改善するプロダクトとして提供する
    • インフラ自動化：自動テストや自動デプロイ、サービスモニタリングといったインフラの自動化を組み込んでいること
    • 進化的設計：サービスの追加、変更、廃止が他のサービスに影響がないようにそれぞれ設計されること
    • ビジネスケイパビリティによるチーム化：ビジネス上の能力とそれを実現できる機能横断チームの単位にサービスを分解すること
    • 失敗のための設計：1つのサービスが落ちても、それに応じた設計がなされ、非同期呼び出しなどによって遅延が全体に影響を与えないこと
• マイクロサービス化を行う時期の難しさ
  • マイクロサービス化への第一の条件：プロダクトを支えるビジネスの戦略が固まっていて、ある程度の仮説検証が終了している状況
    • ビジネスがまだ立ち上がり切っていないときに、大きな作り直しや方向転換を図る可能性があるから
  • 遅すぎるのも問題：多くの人員で同じシステムをメンテナンスし続けることで、技術的負債や調整などのコミュニケーションコストの増大が発生
    • 身動きが取れなくなり、移行が難しくなっていく
  • 腐敗防止層というリアルオプション
    • 巨大になったプロダクトのすべてを再設計するのは大変
    • 腐敗防止層の設置：アーキテクチャの再設計を遅延させるためのオプションの一つ
      • 古くなったアーキテクチャを新しいアーキテクチャ設計の文脈で使えるようにAPIへと変換を行うレイヤを設ける
      • 見せかけだけ「あたかも新しいアーキテクチャ」であるように変換する：デザインパターンの用語では「ファサードパターン」
• エンジニアリング・カンパニー
  • 企業活動は、市場に存在する不確実性と、複数人の組織のコミュニケーションの不確実性とを相手にした「エンジニアリング」
  • 構造が与える力は見えづらく、個人の問題として隠してしまいがち
  • 構造上の問題は、誰かのせいでないのと同じくらい、私たち自身を含んだ全員の責任でもある
  • 根本的な問題が「構造上の問題」にあると気が付けば、対立は消滅する