概要

• エンジニアリング組織論への招待 - 広木大地 著

1章: 思考のリファクタリング

個人的な要約

• エンジニアリング（というより事業）は、不確実性を下げることを目的としている。
• 人間にとって不確実なものは2つで、「未来」と「他人」。未来は仮説検証、他人（特にチーム）はコミュニケーションで不確実性を下げる。
• 他人とのずれは、「情報の非対称性」と「限定合理性（全体的な視野や視座を持たず局所最適すること）」で発生する。
• また、個人単位でも人間の認知の歪みから、完璧に論理的に施行することは人間にとって難しい（全員が論理的に仕事をすることはチームとして仕事がしやすいという前提）
• 特に「怒り」という感情のハンドリング。怒りは「自分が大事にしているものが侵されている悲しみ」が先行している。
• マネジメント的観点では、マイクロマネジメントだとマネージャーの個人的能力・リソースが組織の限界となる。あいまいな目的を共有し、個人が動ける自律的な組織を目指す

自分の変化ポイント

• 情報の非対称性をなくしたい。
  • 情報のみならず自分の考えていること（プロダクトをどうしたいと考えているか、なんの技術に興味を持っているか、どんな組織を作りたいか）を咀嚼可能な分量で発信する仕組みを作る（timesチャンネルなど）。
  • そのチャンネルで経営目線やプロダクトオーナー目線での思考を発信することで、みなが広い視野・高い視座への理解を自然と持てるようにしたい。
• 「怒り」をメタ認知し、悲しみを探りたい
  • 自分にとって大切な何が失われているのか。できたら言語化し、それを悲しみとして認知する。（伝えるかはその時考える）

その他書かれていたこと

• 人間は「不安」が嫌い。不安からは「逃避」または「攻撃」したくなる。
• 不確実性の高い問題に先に対処する。小学校夏休みの宿題であれば自由研究に先に着手する。不確実なものほど見積が難しく、全体の質に影響を与えやすい。まずはそこに着手し感覚をつかむ。
• 他人の結果（その人の思考回路や価値観）は変更・観測不可能。手元の自分の行動（会話内容など）などコントロールできるものを変化させる。

2章: メンタリングの技術

個人的な要約

• メンタリングの究極のゴールは「自分で考えられる人を育てる」こと。
• [自己説得] メンティー自身が問題や答えを発見する自己説得が大切。高い納得感や応用力を持てる。それは、メンターが直接答えを教える他者説得に勝る。メンターはメンティーが自分で気づけるように、対話を通して促していく。
• [心理的安全性] その前提として、メンターとメンティーの関係性は重要。心理的安全性があることが重要。「どんなにダメなところを見せても、関係性が破綻することはない」とメンティーが感じられること。

自己説得を促すために

• とにかく相手が主語。相手への共感、相手の問題の可視化、リフレーミング。
• 感情が絡む問題は、まずは傾聴して感情への共感（≠同感）から。その後で問題の処理。
• 問題を解くときは、問題を書き出し、「問題 vs 私たち」の構図にする。

心理的安全性を高めるために

• 心理的安全性が高いと、「対人リスク」を伴う行動がとりやすくなる。問題点の指摘、自分の弱みの開示、失敗の報告等。
• お互いに弱みを見せられ、お互いに敬意を払い、お互いにメンティーへの成長期待を持っている。
• 相手を承認する。存在自体を認め、行動を事実として認知し言語化し、結果を評価する（褒める）。
• メンターも自己開示する（ストーリーテーリング）。そのストーリーの中での感情も共有する。自慢話ではない。

自分の変化ポイント

• 自分が答えを言うことが多かったので、問題があればその分析の思考過程から入る。解決策へとつながる思考に進む道筋を伝える
• 「信じる」これはふわっとしていることだけど、テクニックではなく心の底にあること。採用したからには同じ仲間としてその人へ期待し、その人にできる、輝くところがあると信じる。

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

• この章は、抽象的なアジャイルの思想・その思想が生まれた背景について解説されている。
• 読み物としては面白いが、要約としてまとめやすいコンテンツではないので、本に多くを譲る。

個人的な要約

• プロジェクトマネジメント
  • 平たく言うと「ちゃんと作れるか」。スケジュール・予算通り進めることに対しての不確実性（方法不確実性）を減らす。プロジェクトを「終わらせる」ことが目的
• プロダクトマネジメント
  • 平たく言うと「ニーズあるものを作れるか」。ユーザーから本当に求められているかということに対しての不確実性（目的不確実性）を減らす。プロダクトを「終わらせない」ことが目的。
• 変化が速いマーケットだからこそ、後者のニーズの部分を速い速度で検証しながら、プロダクト・プロジェクトともにマネジメントするのがアジャイル開発

後半

• 4章、5章は自分の今の状況よりも大きな会社の話も多かったため、要約は省略する。またしかるべきタイミングで読み込みまとめたい。