チームの開発効率を上げたいと思っており、ちょうど周りで話題だったので「カイゼン・ジャーニー」を読みました。
「カイゼン・ジャーニー」は、チーム開発の効率化やマネジメントスキル向上を目指す方々にとって有益な書籍です。
物語形式で進行し、各章で紹介される手法やツールは、実際の現場での適用をイメージしやすくなっています。
概要
本書は物語形式で進み、登場人物による解説コーナーで詳細が語られます。
物語形式と聞くと表面的な内容かと思われるかもしれませんが、解説コーナーのボリュームが多く、内容は非常に充実しています。
紹介されているツールや手法は多岐にわたり、すべてを詳細に触れるときりがないため、以下ではストーリーには触れず、概要を要約しています。
第1部
1話
「もっと仕事のやり方を変えたい、よくしたい！」というときにWebで事例を拾い読みしても実行の支えにはなりづらく、
勉強会やイベントなど"外"にいって実際に他の現場の体験や工夫を見聞きすることで問題解決の可能性が広がる。
ただし、そのまま適用するのではなくその人と自分たちの"状況と制約"の差分を考慮し捉え直すこと。
2話、3話
最初は状態の見える化：タスクマネジメント、タスクボード、朝会、ふりかえり（KPTなど）から始めるのがよい。
「（事前に）許可を求めるな（後で）謝罪せよ」まずはプラクティスを小さく始める。
ふりかえりは一人でも（やらないより）よい。ただし、一人だとレビューがないのと同じことで他の人に気づかせてもらうということができないのでその点は注意。
4話、5話、6話
タスクの情報
- 誰から依頼された
- 次は誰に渡す
- 期日
- 予定作業工数
- どうなったらタスクが終わりか
1日以上かかるタスクは分割を考える。
多忙さの側面で働いていると勘違いしてはいけない。顧客に価値を届けることが本来の仕事。
緊急・重要のマトリクスで重要度が高いことの優先度を上げ、重要度が低いことの優先度を下げたりなくしたりする。
同程度の緊急・重要度なら簡単に実行できて効果が出やすい方を優先。
WIP制限：仕掛り作業を1か2に制限する
それにより価値を生んでいない滞留時間を削減する。
最優先の割り込み作業は緊急レーン。
緊急レーンは一人ではハードルが高いならメンバー全員が作業を中断してでもやる。
第2部
9話、10話
スクラムの基本
イベント
1. スプリント: 繰り返される1ヶ月以下の開発期間
2. スプリントプランニング: そのスプリントで何を実施するかの計画ミーティング
3. デイリースクラム: 日々の進捗や優先順位、障害の確認をする15分以内のミーティング
4. スプリントレビュー: スプリントの終わりに作成物をレビューしてフィードバックをもらうミーティング
5. スプリントレトロスペクティブ: プロセスを検査し改善するためのミーティング
スクラムチーム
1. プロダクトオーナー: プロダクトの価値の最大化に責任を負う
2. 開発チーム
3. スクラムマスター: チームが成果を上げるために支援する
下記3種の作成物をつくっていく
1. プロダクトバックログ: プロダクトの要求や機能の一覧
2. スプリントバックログ: スプリント期間内で作成すると決定したプロダクトバックログアイテムとその作業リストの一覧
3. インクリメント: 動作するプロダクト
11話
インセプションデッキ
- Whyを明らかにする
- プロジェクトのミッションはなにか
- エレベーターピッチ
- パッケージデザイン（ユーザーから見たプロダクトの価値）
- やらないことリスト（スコープ）
- ステークホルダーは誰か
- Howを明らかにする
- 技術的な解決策
- 不安やリスクはなにか
- 必要な開発期間はどのくらいか
- トレードオフスライダー（ローンチ時期、スコープ、予算、品質はどのような優先順位になるか）
- 何がどれだけ必要か（期間、費用、チーム編成）
12話、13話、14話
成功の循環モデル
関係の質->思考の質->行動の質->結果の質->関係の質->...
結果をよくするためにはまず関係の質を上げるところから始める。
ドラッカー風エクササイズ
- 自分は何が得意なのか
- 自分はどうやって貢献するつもりか
- 自分が大切に思う価値はなにか
- チームメンバーは自分にどんな成果を期待していると思うか
- ＋その期待は合っているか？（5段階）
トラックナンバー1
ファイブフィンガー
15話
狩野モデル
当たり前品質: 充足されて当たり前、不充足であれば不満を引き起こす
一元的品質: 充足されれば満足、不充足であれば不満を引き起こす
魅力的品質: 充足されれば満足を与えるが、不充足であっても仕方ない
今は魅力的品質を高めてユーザーのアテンションを集めるべき
当たり前品質を確保して基本的なところでユーザーの不満を減らそう
など
16話
インセプションデッキを振り返る
ユーザーや顧客、プロダクトオーナーやステークホルダーからの期待が変わっていくことがある
その結果、目的を調整する必要が出てきたりする
向き直り
1. ミッション、ビジョンを点検
2. 評価軸を洗い出し、現状を客観的に見定める
3. 評価軸ベースであるべき姿と現状の課題を洗い出す
4. 課題解決のために必要なステップをバックログにする
5. バックログの重要度と一番効果の高いものを決める
6. 時間軸を明らかにし、期限も明確に決める
17話
新人教育
星取表（スキルマップ）とモブプロ
ここのスキルマップは心理的安全性のため、評価には使わないこと。
TWI（Training Within Industry） / JI（Job Instruction）
18話
スクラムマスターの役割
バリューストリームマップ
リードタイムとプロセスタイム
無駄を発見して改善
- リードタイムを減らすポイント
- 待ち時間が長く（週や日）ボトルネックとなっているプロセス付近
- 手戻りが発生していてその割合が高い
- 最後にテストをして手戻りが発生するならTDDにするなど
- 不安な作業や心配しながらしている作業プロセス付近
- 精神的な負荷を減らす
ECRS
カンバン
19話
ポストモーテム
感謝のアクティビティ
タックマンモデル
第3部
20話
新しいメンバーが加入したとき、プロジェクトの状況が一変したときにはすぐにインセプションデッキとドラッカー風エクササイズをやり直す。
変化がなくとも3ヶ月〜6ヶ月に一度見直す。
リーダーズインテグレーション
リーダーが自己紹介して退出、リーダーについてメンバーが各項目について議論し退出、ファシリテーターが誰の発言かは伏せて共有、リーダーがメンバーに回答。
リーダーとの心理的距離を近づけ、認識を共有する。
モダンアジャイル
https://modernagile.org/
21話
プランニングポーカー
CCPM（CriticalChain Project Management）
個々ではない全体バッファを設ける。
五分五分で達成できる見積もりの合計値を出して、その半分をプロジェクトバッファとする。
※個々でバッファを積むと意味がないので、個々でバッファを積みたくならないよう、バッファを消費しても責められない環境は必須。
22話
SoE（Systems of Engagement）/ SoR（Systems of Record）
近くにある小さな問題は引き受ける。
YWT（やったこと わかったこと 次にやること）
スクラムオブスクラム
各チームのスクラムマスターや代表者が集まって共有する。
デイリーカクテルパーティ
ミーティングを3階層にし、下の階層から順に開催して集約する。
23話
デザインと開発の協業
ユーザーストーリー
INVEST (参考)
ギャレットの5段階
24話
仮説キャンバス
顧客がお金を払ってでも片付けたい用事は何か？ -> ジョブ理論
類似: ビジネスモデルキャンバス / リーンキャンバス
25話
"境界"を"越境"する
ユーザーストーリーマッピング
https://www.slideshare.net/slideshow/ss-41638116/41638116
MVP (Minimum Viable Product)
ユーザーにとって価値があり、かつ最小限の機能性をもった製品。
26話
ユーザーインタビュー
仮説を立て、インタビュースクリプトを用意し、検証する。
ペーシング / ミラーリング / ラポール空間
SL理論（Situational Leadership）
リーダーシップのスタイルは4段階で成長していく。
S1: 教示的 S2: 説得的 S3: 参加的 S4: 委任的
27話
ハンガーフライト
付録
5つの価値
越境 自分から始める フィードバック リフレーミング 巻き込み巻き込まれる
カテゴリー別27の原則
所感
会社や現状に不満がある人が拙いながらも行動を起こして改善していく内容なので、会社に不満や言いたいことがある人はとりあえず読んだら世界が変わるかもしれません。
2章からはスクラムが始まり、不慣れなところからうまく回すところまでいくので、特にスクラムをやろうと思っている場合は一度チーム全員で読んでおくと認識をあわせやすいと思われます。
それでいて大小様々な施策を行っていくのでスクラムをやらない場合でも参考になることはいっぱいあります。
全部をやる必要はありませんが、各ツールがどういう目的で使うかも触れられているので"これはやらない"の判断をするためにも参考になります。
最初の方にもありましたがその人と自分たちの"状況と制約"の差分を考慮し捉え直すようにしましょう。
心理的安全性やそれに近い話は各所で出てきます。
やはりチームの動きを改善するにはそれが必須という印象です。
ちなみに私個人としては、KPTはよいのですがリーダーの性質によってはKeepで満足されてしまうのでPTに焦点を当てたものから始めたことがあります。
いわゆる"JTC"的な考えのリーダーがいるときにKeepをやると、これから変えていきたいタイミングでいきなり変えられないことが決まってしまうのでつらいです。
タスクマネジメント
まずは付箋で、とあるがさすがに今どきは最初からRedmineでもBacklog、Trelloでもいいから最初からとりあえず課題管理系のツールを使うほうがよい
エンジニアでない上長向けに付箋で見える化したこともあったが、編集したり補足したりができないので時間が経つと「これなんだっけ？」というものが発生したり、色分けはしてるにせよ同じサイズの付箋なので長期タスクや短期タスクが混在して見づらかったりと管理ができていないことが露呈した。