9/22(日)に池袋サンシャインシティにて開催される「技術書典7」へ向けて、執筆作業を続けていました。
周囲の人にレビューしてもらいながら、何度もリライトしました。

そして、ようやく入稿作業が終わったー。
後は当日が楽しみであります。

「エンジニアのチームを整える技術」について

技術書典7 「き31D」にて「エンジニアのチームを整える技術」という本を頒布します。

【無料お試し版】はこちら
前半52ページを無料で試し読みすることができます。(本編は全118ページ)
https://karamage.booth.pm/items/1559204

サークル紹介ページはこちら
https://techbookfest.org/event/tbf07/circle/5728090902757376

本書には、チーム開発を成功に導くためのマインドセットについて書きました。
 チームの本と書くと、「なんだ、マネージャ向けの本か」と思われるかもしれませんが違います。 リーダやマネージャだけでなく、「チーム開発」に関わる全てのメンバーに読んでほしいです。

【本書で得られること】 

• プロダクト型チーム開発 のマインドセット
• チームのメンタルの整え方やリフレーミングについて
• プロジェクト型チーム開発 が時代遅れになってきている理由

本書のロードマップ 

・1 章にて、「チーム開発における 3 つの課題」における「プロダクト型チーム開発」が、なぜ今必要なのかということを説明しています。
・2 章には、「変化し続けるチーム」の重要性について、「変化しないチーム」の問題点を挙げて比較しています。
・3 章には、「変化しないチーム」について、筆者の体験談を元に、チーム開発のアンチパターンとして、ストーリ仕立てで記述しています。
・4, 5 章には、チームのメンタルセットを整えるための技術を体系的にまとめています。
・最後の章では、未来のチーム開発について、筆者の未来予想図を書いています。

書籍頒布物紹介

「エンジニアのチームを整える技術」 116ページ   1000円

【目次】

まえがき
　- キャッチャー・イン・ザ・ライ
　　 - ぼくは、耳と目を閉じ、口をつぐんだ人間になろうと考えた
　- 変化し続けることができるチームが求められている
　- この本の概要

第 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

あとがき
　- 著者紹介

技術書典7とは

新しい技術に出会えるお祭りです。
技術書典は、いろんな技術の普及を手伝いたいとの想いではじまりました。
技術書を中心として出展者はノウハウを詰め込み、来場者はこの場にしかないおもしろい技術書をさがし求める、技術に関わる人のための場として『技術書典』を開催します。

日時 2019/09/22 (日) 11:00〜17:00
場所 池袋サンシャインシティ2F 展示ホールC/D（文化会館ビル2F/3F）
主催 TechBooster/達人出版会

https://techbookfest.org/event/tbf07

それでは、当日は現地でお会いできることを楽しみにしています!