【無料お試し版】「エンジニアのチームを整える技術」はこちらから： 前半52ページを無料で試し読みすることができます。(本編は全118ページ) https://karamage.booth.pm/items/1559204 技術書典7 サークル詳細ページはこちらから： 【き31D】からまげ＠うまうまだよもん https://techbookfest.org/event/tbf07/circle/5728090902757376 2019年9月22日(日)に池袋サンシャインシティで開催される技術書典7で書籍版の「エンジニアのチームを整える技術」を頒布します。 このページでは、PDF版の「エンジニアのチームを整える技術」の販売を行っています。 PDF版の購入を何卒お願いいたします。 ―――――――――――――――――――――――― 【整えるシリーズ第二弾】 「エンジニアのチームを整える技術」 本書には、チーム開発を成功に導くためのマインドセットについて書きました。 チームの本と書くと、「なんだ、マネージャ向けの本か」と思われるかもしれませんが違います。 リーダやマネージャだけでなく、「チーム開発」に関わる全てのメンバーに読んでほしいです。 ――そう、あなたです。 あなたに読んでほしいんです。 「チームを整える」とは、チームのマインドセットを整えることを意味します。 チームのマインドセットが整った結果、「変化し続けるチーム開発」が可能となります。 世の中は目まぐるしく変化――それどころか激変につぐ激変を繰り返しています。 一時的にもてはやされたビジネスモデルや知識は、すぐに陳腐化し、役に立たなくなります。 個人でもチームでも、努力すべき方向が見えず、不明瞭な時代になっています。 ここで大事なのは、正解がわからないけれども、「わかっていないことはわかっている」ことを自覚することです。 この状態になって初めて問題の本質に近づくことができます。 チーム開発でほんとうに大事なことは、わからないものに囲まれたときに、答えがないままそれにどう対処するかの智慧といえます。 本書でもっとも言いたいことは、変化し続けることの重要性、これだけです。 そこで、「変化し続けるチーム開発」の現場を、より楽しく、体系的にまとめたものを、 「エンジニアのチームを整える技術」 としてあなたにお届けいたします。 【本書のロードマップ】 1 章にて、「チーム開発における 3 つの課題」における「プロダクト型チーム開発」が、なぜ今必要なのかということを説明しています。 2 章には、「変化し続けるチーム」の重要性について、「変化しないチーム」の問題点を挙げて比較しています。 3 章には、「変化しないチーム」について、筆者の体験談を元に、チーム開発のアンチパターンとして、ストーリ仕立てで記述しています。 4, 5 章には、チームのメンタルセットを整えるための技術を体系的にまとめています。 最後の章では、未来のチーム開発について、筆者の未来予想図を書いています。 【本書で得られること】 • プロダクト型チーム開発 のマインドセット • チームのメンタルの整え方やリフレーミングについて • プロジェクト型チーム開発 が時代遅れになってきている理由 【目次】 まえがき 　- キャッチャー・イン・ザ・ライ 　　 - ぼくは、耳と目を閉じ、口をつぐんだ人間になろうと考えた 　- 変化し続けることができるチームが求められている 　- この本の概要 第 1 章 プロダクトをつくるためのチーム 　1.1 チーム開発における 3 つの課題 　　- 「人」と「プロダクト」を大切にしたい 　1.2 プロダクト型開発に移行せよ 　　- プロジェクトという形態からプロダクト開発へ 　　- アジャイルはジャズ 第 2 章 変化し続けるチーム開発 　2.1 チームは何のために仕事するのか 　　- You know what I’d like to be? 　　- あなたは何をする人ですか? 　　- 壁と境界と越境 　　- 納期を守るためのチームという悪夢 　　- プロダクトに意味付けできるチームが強い 　　- アジャイルとウォータフォールの違いは不確実性との向き合い方 　2.2 なぜ日本ではアジャイルが普及しないのか 　　- わからないことを、「わからない」という勇気 　　- エンジニアリングとはアジャイルである 　　- ウォーターフォールからアジャイルへ移行できていない企業 　　- SIer は近い将来淘汰される 　2.3 プロジェクト型開発からプロダクト型開発へ 　　- プロジェクト型は終わらせるのが目的 　　- プロダクト型は継続するのが目的 　2.4 ユーザ企業の内製化にはアジャイルチームが必要 　　- アジャイルだと 3 倍の成功率、1/3 の失敗率 　　- 大規模開発でもアジャイルが有効 　　- アジャイル型人材の必要性が高まっている 　2.5 認知フレームの問題 　　- 過去のウォータフォールでの成功体験が邪魔している 　2.6 リフレーミングでチームの働き方を変える 　　- 会社や組織は変えにくいが、チームのメンタルセットは変えやすい 　2.7 変化し続けるチーム vs 硬直するチーム 第 3 章 Solid State Team には近づくな 　3.1 登場人物 　3.2 曖昧性と不確実性との戦いが、いま、はじまる 　　- ハイブリッド・アジャイルという名の悪魔合体 　　- 何を作るのか決まっていないのに見積もりを強要する 　　- 破裂しそうに膨らむ要求仕様いう名の爆弾 　　- どんぶり勘定のステップ数見積もり 　3.3 マイクロマネジメントを強要する上司 　　- 頻繁な作業報告 　3.4 Solid State Society - 個体状社会 　　- 遅れる進捗と怒れる人々 　　- 客先常駐という刑務所 　　- 監視体制と臨戦態勢 　3.5 分断するチーム 　　- 作業員としてコードを書く日々 　　- デザイナーとの分業 　3.6 ドメイン知識の不在 　3.7 硬直するチームの憂鬱 　　- UI/UX を考えるのは誰? 　　- プログラマはコードだけ書いていればよい 　　- マネージしないマネージャーは、ただのャーだ 　　- 説教されるだけの 1on1 　　- いつからアジャイルだと錯覚していた? 　3.8 唐突な開発打ち切り宣言 　　- プロダクトオーナの消失、そして誰もいなくなった 　3.9 憂国への帰還 ENDLESS ∞ GIG 　　- ぼくらはみんな生きている 第 4 章 チームを整える技術 　4.1 個人よりチーム 　　- 一人から始める 　　- 最初のチームメンバーは自分 　　- チームは個人の拡張 　4.2 複数人チームで働くということ 　　- 個人の能力よりチームワークが重要な理由 　4.3 タックマンモデル 　　- チームの成⻑の「4段階」 　　- チームビルディング 　4.4 対話がすべて 　　- 対話することでチームを変える 　4.5 コミュニケーションの不確実性 　　- 私はあなたではないという単純な問題 　　- 意見の対立 　　- 個人で働くことの限界 　　- HRT 　　- コードレビュー 　　- 有害な人と付き合う方法 　4.6 学習するチーム 　　- メタ認知で学ぶチカラを鍛える 　　- コンフォートゾーンを出てラーニングゾーンへ 　　- コンフォートゾーンに戻ろうとするホメオスタシス (恒常性) 　　- 対人リスクを取って前に踏み出す勇気 　　- 斧を研ぐ時間 　　- 価値があると認識しながら学習する 　4.7 強いチームとは 　　- 「これやる意味あるんすか?」と言えるチームが強い 第 5 章 チームをリフレーミングする技術 　5.1 リフレーミングの定理 　　- リフレーミングとは? 　　- ネガティブなことの中に、ポジティブな力を見つける 　　- 仕事の意義をリフレーミングする 　5.2 再生と再認 アンラーニング 　　- 成功体験が「負債」になる 　　- 学習棄却 (アンラーニング) の方法 　　- ウォータフォールからアジャイルに移行する方法 第 6 章 自己組織化を超えた先に 　6.1 今後、どういうスタイルでエンジニアは開発するのか 　　- チームから、「個」の集合体へ 　6.2 スタンドプレーから生じるチームワークとは 　6.3 チームという概念の消失。溶けて消える 　　- 人の心が自由になる働き方とは 　6.4 STAND ALONE COMPLEX あとがき 　- 著者紹介