第一部 一人から始める
カイゼン・ジャーニー
01 会社を出ていく前にやっておくべきこと
- 他者の実践の背景にどんな状況、制約があったのかを理解し、自分たちの状況、制約の元ではどのように実践すべきなのか捉え直さないといけない。
02 自分から始める
-
最初に何に取り組むか
状態の見える化から始めよう
タスクマネジメント
いきなり作業をはじめるのではなく。その仕事の背景や目的を理解することから取り組む。 -
タスクボードを使用する
朝会
ふりかえり
ほかの３つより、振り返りを一番大切にした方が良い。 -
許可を求めるな、謝罪せよ。
まずは小さく始めることが大切。許可がおりるまでまっていたら機会を逃してしまう。
03 1人ではじめるふりかえり
-
ふりかえりで仕事のやり方をみなおす
振り返りの基本
振り返りは「立ち止まって考える」ための機会といえる。
振り返りの二つの目的
プロセスのカイゼン
「不確実性の高い状況」でも前進するため、不確実な状況を明らかにしていく。 -
KPT
Keep
続けたいこと、やってみてよかったこと
Problem
問題点
もやもやしていること、気に掛かっていること
Try
試したいこと -
2回目のふりかえり
Tryをやってどうだったのかふりかえる。 -
ふりかえりをチームでやる意味は、自分では気付けないことを他者から教えてもらうため。
04 ひとりではじめるタスクの見える化
-
タスクを書き出し、見えるかする
「名詞＋動詞」での書き方が良い
タスクの完成の定義はすり合わせておく。 -
大きなタスクを大きなまま扱わない
大きなタスクを大きなまま扱っていると認識の違いが起きやすくなる -
分割して統治せよ
「分割統治法」
大きな話をまず細かく分けることから始める。
05 明日を味方につける
-
朝会
昨日やったこと
今日やること
困っていること -
1on1
聞くことに徹する
最低でも月1回30分の時間は作る（作れないようならリーダーはやってはいけない）
06 境目を行き来する
-
タスクボードでタスクを見えるかする
TODOには直近で必要なタスクのみ溜め込むのがよい
量が多くなると全体像が俯瞰できなくなる -
マルチタスクになったときのスイッチングコストの予防
wip:仕掛中のタスクを減らす
ルールできめてしまう
wipを１や２に制限し複数同時に着手してはいけないようにする
緊急のタスクは緊急の割り込みレーンを作成する
08 2人で越境する
-
取り組みをそのまま取り入れるのはやめる
小さく始めることが大事 -
世の中の事象も氷山と同じ
出来事（ここだけが見えている）
パターン
構造
メンタルモデル -
メンタルモデルを変えることは大変
対話を重ね、カイゼンを重ねること
第２部 チームで強くなる
09 1人からチームへ
-
プロダクトオーナー
プロダクトの価値の最大化に責任をおう -
開発チーム
自己組織化された専門家集団 -
スクラムマスター
チームが成果を上げるために支援・奉仕する -
プロダクトバックログ
実装するプロダクトの要求、要望、機能の一覧
詳細や見積もりを記載 -
スプリントバックログ
プロダクトバックログからスプリント期間内で作成すると決定したプロダクトバックログ -
インクリメント
動作するプロダクト
10 完成の基準をチームで合わせる
-
スプリントプランニング
１。何を作るべきか
２。どうやって顧客に届けるべきか -
完成の定義
スプリントには用意されておくべき
全員がどのような状態になったら完成か認識できるもの
11 チームの向かうべき先を見据える
-
インセプションデッキ
WHY
われわれはなぜここにいるのか？
プロジェクトのミッションは何か？
エレベーターピッチ
プロダクトのニーズ、顧客、差別化ポイントが何かそれぞれ答える。
パッケージデザイン
ユーザーから見たプロダクトの価値とは何か
やらないことリスト
スコープ、特にスコープに入らないことは何か
ご近所さんを探せ
チームを取り巻くステークホルダーは何か -
HOW
技術的な解決策
採用する技術やアーキテクチャは何が考えられるか
夜も眠れない問題
不安やリスクには何があるか
期間を見極める
必要な開発期間はどれくらいか
トレードオフスライダー
ローンチ期間、スコープ、予算、品質はどのような優先順位になるか
何がどれだけ必要か
期間、費用、チーム編成について答えよ -
チーム全員の頭で考えることが重要
プロジェクトは忙しい、それでも立ち止まって考えることが重要。 -
一つの項目に1時間以上かかることもある。
それがチームビルディングや自己組織化につながる。 -
時間がないチームは叩き台を利用しても良い、
-
下記４つを埋めるだけでもプロジェクトの推進は加速する。
ミッションや目的の共有のために「われわれはなぜここにいるのか」
リスクや不安のリストアップのために「夜も眠れない問題」
スコープの内と外の境界を明らかにするために「やらないことリスト」
判断基準を可視化し、その優先どの明確化のために「トレードオフスライダー」 -
インセプションデッキ作りに今更はない
12 僕たちの仕事の流儀
-
組織の成功循環モデル
-
Working Agreement
チームで決めたルールのこと -
決め方のコツ
スローガンのようなものは避ける
ルールは具体的で誰もが同じ見解で判断できるようなもの
もしくは状態や数値が記載されている内容
例えば
デイリースクラムは10時から15分いないでタスクボードの前で立って行う
疑問に思うことをすぐ聞くことは価値あることで、メンバーは賞賛Reaction を送る
13 お互いの期待を明らかにする
-
期待のギャップを埋めていくドラッカー風エクササイズ
互いの期待が合っているのがチーム
期待が合ったチームはお互いに動きやすくて、背中を預けられる感覚が持てる。 -
自分は何が得意なのか
自分はどうやって貢献するつもりか
自分が大切に思う価値観は何か
チームメンバーは自分にどんな成果を期待してると思うか -
その期待は合っているか？
完全にあっていない
あまりあっていない
ふつう
大体合ってる
完全に合ってる -
注意
人は得てして、勝手な自分の期待を押し付けがちだ。逆に、必要以上に自分を責めて勝手な期待を背負いすぎたりしてしまう。
そして、期待がミスマッチであるために、過度なストレスや不満が、お互いによって引き起こされてしまう。
14 問題はありませんとういう問題
ファイブフィンガーで危険な兆候を察知
危険なシグナルをキャッチする
デイリースクラムにはチームの１人1人が問題は必ず何かあるという前提にたってデイリースクラムに挑んでほしい。
「問題がない」が問題と言っても良いくらい
スプリントや仕事の今の状態を自分の考えで表明する。
スプリントや仕事の今の状態を自分の考えで表明する。
5.とってもうまくやれている
4.うまくやれている感触あり
3.可もなく不可もなく
2.不安は少しある
1.全然ダメで絶望的
まず、みんなに表明する前に自分自身への問いかけを心の中でする。
周りのメンバーの考えに左右されないように自分と向き合う。
その後は1番少ない本数を出したメンバーから話を聞いていく
本数の多いメンバーから聞いてしまうと
ネガティブなことを言いづらい雰囲気になってしまうから。
全員のフィンガーの表明によって問題を抱えている人をチームでサポートする姿勢ができる。
「このスプリントから始めたペアプログラミングはどうかな？効果あるかな？」
「ファイブフィンガーで」
「どん！」
みたいな感じでやる。
15 チームとプロダクトオーナーの境界
-
スプリントレビュー
完成の定義
以下のような状態ではだめ、１００パーセント完成して完了となる。
あと少し
80パーセント -
狩野モデル
魅力的品質
充足されれば満足を与えるが、不充足であっても仕方がない。
一元的品質
充足されれば満足、不充足であれば不満を引き起こす。
当たり前品質
充足されて当たり前、不充足であれば不満を引き起こす。
16 チームとリーダーの境界
-
むきなおり合宿
ふりかえりは、過去を顧みて現在を正す
むきなおりは、進むべき先を捉えて現在を正す -
向き直りの手順
ミッション、ビジョンを点検する
評価軸を洗い出し、現状を客観的に定める
評価軸ベースで「あるべき姿」と「現状の課題」を洗い出す
「課題解決」のために必要なステップを「バックログ」にする
「バックログ」の重要度と、一番効果の高いものを決める
時間軸を明らかにし、期限も明確に決める -
合宿のメリット
集中（時間・場所・目的）
合宿の狙いやタイムテーブル、アジェンダをしっかり準備することが大切。
リードタイム短縮（調整とアクションプラン）
高揚感 -
合宿のアンチパターン
いつもと同じ場所
目的・ゴールが曖昧
詰め込みアジェンダ
アクションプランを設定しない
必要な人がいない
まずい食事
17 チームと新しいメンバーの境界
-
星取表(スキルマップ)
プロジェクトで必要なエンジニアスキルと業務知識で項目を作成する。
インセプションデッキで作成したAチームの項目を参考にするとよい。
注意
人事評価には使用してはいけない、心理的安全性がなくなり本当のことが書けなくなってしまう。
「チームメンバーのスキルの見える化」以外の目的で使用してはいけない。 -
チームビルディング３種の神器
インセプションデッキ
プロジェクトやプロダクトの目的や方法論
ドラッカー風エクササイズ
チームメンバーの価値観
星取表
目的を達成するために必要なスキル -
星取表がないのならすぐに作成するべき。
必要だと気づいた時が自分やそのチームにとって最速のタイミング。 -
モブプロ
モブプロについての詳細も書いてあった
必要になった時に再度熟読する。
18 チームのやり方を変える
-
スクラムマスターは役割
チームにスクラムの理論、プラクティス、ルールを守ってもらうようにする
スクラムチームの外部の人たちに、プロダクトやチームについて理解してもらう
プロダクトオーナーや開発チームの活動を支援、コーチングする
プロダクトバックログの価値を最大化させるためのコミュニケーションの方法や、効果的なプロダクトバックログの管理方法を伝える
スクラムイベントをファシリテートする
チームを観察し、チームの自己組織化を後押しする
進捗を妨げるものを排除しながら、スクラムチームが作り出す価値を最大化する
チームを元気づける
奉仕や支援を通じて、メンバーが主体的に行動するよう促すサーバントリーダーシップを発揮する -
上記がやくわりとしてあるが
チームが成長するにつれて、スクラムマスターは不要となるように
チームが成長すべきである。
スクラムには1人のヒーローはいらない、ヒーローはチームである。 -
バリューストリームマッピング
プロダクトの価値がお客様の手に届くまでの仕事の流れを見える化するためのプラクティス（習慣的な取り組み。通例。習慣）。
19 チームの解散
-
ポストモーテム
プロジェクト後の事後検証
場の設定に関するポイント
時間厳守・タイムボックス厳守
全員参加
時間をさいてくれたことに感謝
集まった目的の共有
本日のゴールを明確化させる
最後に全員で写真を撮る（最後の姿を記念撮影） -
ルールに関するポイント
人事評価には関係ないということを宣言する
気軽で自由な発言の場にする
はじめに自分たちでグランドルールを3つくらい作る -
議論に関するポイント
抽象論の場合、具体的な内容を語るようにする
各自の見方箱となるので、事実を集め、解決すべき課題を見つける
事実なのか、意見・解釈なのかをわける
ポジティブな問題解決に導く
全員で決めたことに意義がある。リーダーのものでもファシリテーターのものでもない。
次のプロジェクトの糧にする。メンバーの各自のTry事項をつくる。 -
ファシリテーターとして気を付けるポイント
個人攻撃や誹謗中傷がでてきそうになったら、個人ではなく問題を対象に議論するように促す
考えを代弁せずにメンバーが発言のために思い出す時間を与える -
タイムラインふりかえり
-
感謝のアクティビティ
十分な時間を割く（1時間以上）
付箋紙ではなく、はがきよりふたまわりくらい小さいメッセージカードを使う
字がきれい汚いは個人差が出るが丁寧に書くことを心がける
感情面・抽象度のたかいことでもよしとする
具体的な出来事があればそれを書く -
タックマンモデル
チームの成長過程を知っておくことで、リーダーとしての振る舞い方を考えるきっかけになる概念
。
第３部 みんなを巻き込む
20
-
内側の期待
チームにおける期待（ドラッカー風エクササイズ）
外側の期待
プロジェクト関係者における期待（インセプションデッキ） -
リーダーズインテグレーション
新しいリーダーとの信頼関係の構築に役にたつ -
モダンアジャイルの基本原則
人々を最高に輝かせる
安全を必須条件にする
高速に実験＆学習する
継続的に価値を届ける
21 外から来たメンバーと、計画づくり
プランニングポーカーがうまくいく理由
参加者がそれぞれの知見を持ち寄って、活発な議論を行うから
全員で見積もることで知見の共有ができチームのレベルが上がっていく
楽しい雰囲気で行うことができる
-
当初の計画通りにいくプロジェクトは皆無でしょう
計画ではなく、計画づくりが大切
活動そのもの、過程そのものに価値がある。
CCPM
パーキンソンの法則でバッファはぎりぎりまで消費してしまう。
学生症候群でもギリギリまで消費してしまう。
なのでプロジェクト全体でのバッファを持つようにすれば上記の回避ができる -
上記を実践するには信頼関係が必要不可欠
プロジェクト全体でのバッファなので消費したことを伝え合う文化づくりが必要
残業で過小見積もりを回避したことも正直に報告する。
22 外部チームと、やり方をむきなおる
-
むきなおり
外部のチームとの向き直しの時以下のフレームワークを使うと良い -
スクラムオブスクラム
スクラムのスクラムマスターが集まって行うスクラム
他のチームに関係する作業の情報
チーム内だけでは解決できない障害
23 デザイナーと共通の目標に向かう
-
ユーザーストーリー
要求を三段階の自然な言葉であらわしたもの
who
what
why -
ギャレットの５階層
-
視座を変えて突破するための見方を得る
-
仮説キャンバス
25 広さと深さでプロダクトを見立てる
- ユーザーストーリーマッピング
顧客やビジネスの要求を全て受け入れているとプロダクトバックログも膨大なものになってしまう。それを避ける手段。
26 チームでともに超える
-
ユーザーインタビュー
気をつけないといけないことは、本当のことをはなしてないこともあること。
想像で話をすることがある。
なので行動と経緯を詳細に確認する必要がある。 -
SL理論
リーダーシップのスタイルはメンバー、成長によってかわっていく
S1 教示的リーダーシップ
トップダウンでリーダーが具体的かつ詳細に指示を出す
S２ 説得的リーダーシップ
リーダーがやり方をきめメンバーの疑問に答える
S3 参加的リーダーシップ
メンバーの自立的活動をベースにしリーダーは支援する
S4 委任的リーダーシップ
目的のみ共有し遂行はメンバーに委ねる
27 越境する開発
-
ハンガーフライト
自身の体験談を共有する場
共有することで他人の体験を自身のものとすることができる -
Afterword
越境を拒むものは、自分が本当に越境して良いのかの不安。 -
越境のサイクル
を回すためには成果とパッションが必要