はじめに
- この記事は、Qiitaアカウントの整理のため、別のアカウントで投稿した過去の記事を移行してきたものです。全く同様の記事があるかもしれませんが、盗作等ではありませんのであしからずご容赦ください。
- 過去記事 投稿日：2019年04月16日
読んだ本
カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで
市谷聡啓 著
新井剛 著
感想
会社として、チームとして、うまくいかないもどかしさ、でも一人では何も変えることなどはできないと考えてしまう。。。
一人でもできること、何かを始めること、それをきっかけに少しずつ周りへの影響が広がり、徐々にチームとして機能していく、というフィクションの物語と、主にスクラムの手法による、カイゼンの理論とが交互に語られていて、物語とともに実践的な手法の理解もわかりやすく読み進められた。
始めの方に出てくる、「あなたは何をしている人なんですか？」の問いが非常に重い。
現状を憂い、愚痴を言うことはいくらでもできるが、自分もその現状を担う一部であることは忘れがちだと思う。
現状に対して何もできないと思い込むのではなく、「自分が何をしている人なのか」、を常に問い続けることが必要だと心にとどめたい。
内容とかポイントとか気になったところとか
一度読んだだけだとポイントとか忘れてしまうし、書きながら理解できることも多いので、実践のために意識するべきポイントとか気になったキーワードとかを抜粋してみます。
第1部 一人から始める
第1話 会社を出ていく前にやっておくべきこと
- 自分がいつもいる場所から外に出てみる
- 同じ場所だと考え方・やり方の傾向がそろいがち → 異なる考え、経験を持つ人たちとの接点：勉強会やイベント
- ただし、外から得た学びをそのまま自分たちの現場に適用しようとしてもたいていうまくいかない → 自分たちの状況に照らし合わせてみる必要
- 他者の実践の背景にどんな状況、制約があったのかを理解し、自分たちの状況、制約の下ではどのように実践すべきなのかを捉えなおさないといけない
- 同じ場所だと考え方・やり方の傾向がそろいがち → 異なる考え、経験を持つ人たちとの接点：勉強会やイベント
第2話 自分から始める
- 最初に：状態の見える化から始めよう
- タスクマネジメント
- 仕事の背景や目的を理解する → 目的を捉え違えると、間違ったものをいくら正しく進めてもムダになってしまう
- 目的を明らかにしておくことで、目的を達成するために「うまくいかない要素」を早めに見つけることができる
- タスクボード
- タスクの状態を見える化 → タスクが後どれくらいあるか、それぞれがどのような状況にあるか
- わかりやすさ=気づきやすさ → 問題の早期発見
- 朝会
- 昨日は何をやったのか
- 今日は何をするのか
- 今日することや計画を達成するうえで困っていることがあるか
- 上記を確認し、計画のズレを検出、再計画のきっかけ
- ふりかえり
- 仕事のやり方やその結果を棚卸して、次の計画づくりや日々の仕事に生かす
- タスクマネジメント
- 小さく試みる
- 「許可を求めるな謝罪せよ」：許可を待って機会を失うより、失敗したら謝る
- 不安があるのは当たりまえ、うまくいかなくても大けがしないように、まずはやってみる
第3話 一人で始めるふりかえり
- ふりかえりの基本：「立ち止まって考える」ための機会
- 目的１：「プロセスのカイゼン」
- 目的２：不確実性の高い状況（条件や制約がよくわからない、展開が予測しにくい）でも前進していくため
- 計画に過度に依存して進めるより、経験から得られたことを計画づくりに随時反映させていく
- Keep,Problem,Try（KPT：ケプト）
- Keep：よかったこと
- Problem：問題点、「モヤモヤしていること」「気にかかっていること」
- Try：次に試したいこと：緊急度や重要度を見定めて、順番をつけて取り組む
- 2回目のふりかえりで、Tryをやってみてどうだったのか？効果があった（Problemに変化があった）、つづけたほうがよさそうならばKeepに移動
- これを続けていくと、よい習慣としてのKeepが増えるはず
第4話 一人で始めるタスクの見える化
- タスクを書き出し、見える化する
- タスクマネジメントで気にしないといけないポイント
- タスクがどれくらいあるのか
- そのタスクのそれぞれのゴールは何か
- タスクのゴールにたどり着くために気を付けることはなにか
- 今の状況はどうなっているのか
- タスクマネジメントで気にしないといけないポイント
- 「どうなったらこのタスクは終わるのか」を言えるようになる
- タスクに関する情報
- 誰から依頼されたのか
- 次はだれに渡すのか
- 期日はいつか
- どれくらい作業時間がかかりそうか
- どうなったらこのタスクは終わるのか
- 人によってまちまちになりがちな完成の定義をそのままにすると、手戻りが発生して思っていたより時間がかかる
- タスクの目的と依頼者の期待を踏まえて、完成の定義を関係者ですり合わせておく
- タスクに関する情報
- 大きなタスクを大きなまま扱わない
- 大きなタスクを大きなまま扱っていると、認識の違いが起きやすくなる
- 目的によって、分割することを考える ： 分割統治法
- タスクを分けたら、それぞれのタスクがどこまで実現できなければいけないか、関係者とすり合わせ
- 1日以上かかるようなタスクは分割を考えたほうがよい
- 大きなタスクを大きなまま扱っていると、認識の違いが起きやすくなる
第5話 明日を味方につける
- 1日の最初に、1日の計画を立てる
- 昨日までにやったことを確認して、今日やることの計画を立てる
- スクラムでの日々確認すべきこと3つ
- 開発チームがスプリントゴールを達成するために、私が昨日やったことは何か？
- 開発チームがスプリントゴールを達成するために、私が今日やることは何か？
- 私や開発チームがスプリントゴールを達成するうえで、障害となるものを目撃したか？
- 今日のタスクマネジメントは、明日のタスクのマネジメントでもある
- 今日やるべきことは何かを理解することは、明日に回してもいいことは何かを判断することでもある
- スクラムでの日々確認すべきこと3つ
- 昨日までにやったことを確認して、今日やることの計画を立てる
- 一対一で対話する：1 on 1
- 上司やリーダーがメンバーの一人一人と向き合い、対話する時間を作る
- 上司が話すための時間ではなく、メンバーのための対話の時間とする：上司は聞き役に徹する
- 信頼関係とは、まず「自分を見てくれている、耳を向けてくれている」と認識できたところから始まる
- 上司やリーダーがメンバーの一人一人と向き合い、対話する時間を作る
第6話 境目を行き来する
- タスクボードで見える化する
- ”TODO","DOING","DONE"でタスクを管理
- 先々のタスク・気づいたことなどは”Icebox"や"Parking Lot"に優先順位をつけずにいったん預けておく
- ”TODO","DOING","DONE"でタスクを管理
第7話 二人ならもっと変えられる
- いつだって始めるのは自分からだ。でも、いつまでも一人ではない
- 「行動を始めるべきだと気づいたその時が、その人にとっての最速のタイミングだ」：遅すぎるなんてことはない
- 変化は一人から始められる。その変化を目の当たりにした二人目がきっと出てくる。二人になったら、もっとできることが増える
第8話 二人で越境する
- 一人で始めた見える化が周囲を巻き込む
- 外の世界から持ち込んだ話をそのまま自分の現場に持ち込むのはやめること
- それぞれの取り組みの背景にはそれぞれの状況や制約がある
- 新しいことを始めるには小さく試みることからスタートする
- リズムを崩さないように仕事を進めていこう、という意識がカイゼンの後押しになる
- 「ふりかえり」、「タスクマネジメント」、「朝会」、「タスクボード」などの実践で生まれたリズムを大切にする
- 一人で行っていた見える化が周囲への見える化へ → 二人目の目に触れて、仲間が増える
- 外の世界から持ち込んだ話をそのまま自分の現場に持ち込むのはやめること
第2部 チームで強くなる
第9話 一人からチームへ
- スクラムとは：カイゼンが組み込まれたフレームワーク
- スクラムのイベント
- スプリント：繰り返される開発期間のこと。通常は1か月以内で設定する
- スプリントプランニング：そのスプリントで何を実施するかの計画ミーティング
- デイリースクラム：スプリントのゴールを達成すべく、日々の進捗や優先順位、障害などを確認する。毎日同じ時間、場所で実施する15分以内のミーテイング。（朝会と同様の目的だが、必ずしも朝の実施でなくてもよい）
- スプリントレビュー：スプリントの終わりに作成物をレビューしてフィードバックをもらうミーテイング
- スプリントレトロスペクティブ：プロセスなどを検査し、カイゼンするためのミーテイング
- スクラムのチーム構成
- プロダクトオーナー：プロダクトの価値の最大化に責任を負う
- 開発チーム：自己組織化された専門家集団
- スクラムマスター：チームが成果を上げるために支援、奉仕する
- スクラムの成果物
- プロダクトバックログ：実装するプロダクトの要求、要望、機能の一覧。一覧の一つ一つをプロダクトバックログアイテムと呼び、詳細や見積などを記載
- スプリントバックログ：プロダクトバックログからスプリント期間内で作成すると決定したプロダクトバックログアイテムとその作業リストの一覧
- インクリメント：動作するプロダクト
- スクラムの理論と精神
- 透明性：スプリントの情報や状況を見える化し、共通認識を得ることを助ける
- 検査：チームやプロダクト、プロセスの状態を常に検査して、問題をいち早く検知する
- 適応：問題が発生したらカイゼン案を検討し、問題解決に向けて適応していく
- 持続的にカイゼンしていけるような仕掛け
- 経験主義
- スクラムのイベント
第10話 完成の基準をチームで合わせる
- スプリントプランニング：何を作るのかをスクラムチーム全員で共同で思案し、計画策定していく
- フェーズ1：プロダクトバックログアイテムについて、スプリントで達成すべきゴールを「スプリントゴール」として簡潔な言葉で明文化する
- フェーズ2：選んだプロダクトバックログアイテムを基に必要な作業を洗い出し、スプリントバックログを作成する
- スプリントバックログ：必要な作業タスクの一覧：分析や設計やテストなど、必要な作業すべて
- 完成（Done）の定義と受け入れ条件
- メンバー全員がプロダクトの「完成」に対して共通の理解を持つ
- 受け入れ条件（これらを満たしていれば、要求を確かに実現していると判断できるリスト）をプロダクトオーナーが規定し定義するべき
第11話 チームの向かうべき先を見据える
- インセプションデッキ：プロダクトのWhyとHowを明らかにする
- 目的や方向性を合わせる：プロジェクトの向かいたい先や制約を明らかにし、透明性をもって運営していくこと
- そのための道具がインセプションデッキ
- インセプションデッキの10の問い
- ＜Whyを明らかにする問い＞
- 我々はなぜここにいるのか：プロジェクトのミッションは何か
- エレベータピッチ：プロダクトのニーズ、顧客、差別化ポイントが何かそれぞれにこたえる
- パッケージデザイン：ユーザから見たプロダクトの価値とは何か
- やらないことリスト：スコープ。特にスコープに入らないことは何か
- 「ご近所さん」を探せ：チームを取り巻くステークホルダーは誰か
- ＜Howを明らかにする問い＞
- 技術的な解決策：採用する技術やアーキテクチャはなにが考えられるか
- 夜も眠れない問題：不安やリスクには何があるか
- 期間を見極める：必要な開発期間はどれくらいか
- トレードオフスライダー：ローンチ期間、スコープ、予算、品質はどのような優先順位になるか
- 何がどれだけ必要か：期間、費用、チーム編成について答えよ
- チームで作ることに意味がある：チーム全員の頭で考えなければ、チームに浸透する活きたデッキにはならない
- たたき台を基にみんなでちゃんと考えること
- ＜Whyを明らかにする問い＞
- 最低限のインセプションデッキ
- １．ミッションや目的の共有のために「我々はなぜここにいるのか」
- Start with why（目的から始めよ）
- ゴールデンサークル：内側からWhy→How→Whatの円
- What（何を）から考えるのがわかりやすいのでWhatから始めてしまうが、Why（なぜ）から始めてそれをHow（どうやって）実現するかを考える
- Whyは目的にあたり、理解が得られやすい。具体的な手段から説明をされても、最後に聞き返されるのは「それで、どうしてこれをやるんでしたっけ？」
- ２．リスクや不安のリストアップのために「夜も眠れない問題」
- ３．スコープの内と外の境界を明らかにするために「やらないことリスト」
- ４．判断基準を可視化し、その優先度の明確化のために「トレードオフスライダー」
- １．ミッションや目的の共有のために「我々はなぜここにいるのか」
- インセプションデッキの10の問い
第12話 僕たちの仕事の流儀
- 自分たちの働き方や開発ルールを自分たちで決める
- Working Agreementとは
- 価値観や行動規範がバラバラだとチームとして機能しづらい
- 些細なことでモチベーションを下げないためにも、チームで自分たちの振る舞いや約束事を決めておく
- 事細かく決める必要はない。メンバーの動きを縛るためではなく、チームの生産性をより高めるための取り決め
- チームメンバー自身で決めることが大切：リーダーやマネージャーのためのものではなく、他人が決めたルールはすぐに形骸化する
- スローガンのようなものは避け、具体的で、だれでも同じ県間で判断できるようなものが望ましい
- 例えば
- 欠席の時はデイリースクラムが始まる10時までに、Slackのチームチャンネルで全員に連絡する
- デイリースクラムは10時から15分以内でタスクボードの前に立って行う
- ミーテイングの際は議論を活発化させるために腕を組まない
- ユニットテストのないコードはコミットできない
- 疑問に思うことをすぐに聞くことは価値あることで、メンバーは賞賛Reactionを送る
- 成功循環モデル
- ＜バッドサイクル＞
- 結果の質：成果が上がらない
- →関係の質：対立が生じ、押し付けや命令が増える
- →思考の質：面白くなく受け身になる
- →行動の質：自発的・積極的な行動が起きない
- →結果の質：さらに結果が上がらない
- 結果を追求する重力が強いと、「結果の質」を向上させることから始めてしまう
- これを「関係の質」から問題がないか、点検する
- 結果は行動から、その行動は思考から、その思考はメンバーの関係性に大きく依存している
- ＜グッドサイクル＞
- 関係の質：お互いに尊重し一緒に考える
- →思考の質：気づきがあり面白い
- →行動の質：自分で考え、自発的に行動する
- →結果の質：成果が得られる
- →関係の質：信頼関係が高まる
- ＜バッドサイクル＞
第13話 お互いの期待を明らかにする
- 互いの期待があっているのがチーム
- 二つの期待マネジメント
- 内側の期待：チームにおける期待
- 外側の期待：プロジェクト関係者における期待
- 期待のギャップを埋めていくドラッカー風エクササイズ
- ドラッカー風エクササイズの4つの質問
- 自分は何が得意なのか？
- 自分はどうやって貢献するつもりか？
- 自分が大切に思う価値は何か？
- チームメンバーは自分にどんな成果を期待していると思うか？
- これらの質問について自分の表明を書き出し、ほかのメンバーと共有する。話し合いながら、お互いの相互理解を深めていく
- 話し合いが心理的に安全な場になっているかが最重要
- 頭ごなしに否定されたりしたら、腹を割って話を続けるなんてできない→腹の探り合いをしていたら期待をすり合わせるなんていつまでたってもできない
- その場が安全な場であることを公言する：他人を批判しない、否定しないといった前提の確認
- 話し合いが心理的に安全な場になっているかが最重要
- 5番めの質問：その期待はあっているか？
- 4つの質問はすべて自分に視点が向いている
- 「チームメンバーは自分にどんな成果を期待していると思うか？」に対して、ほかのチームメンバーに「その期待はあっているか？」を表明してもらう
- ドラッカー風エクササイズの4つの質問
第14話 問題はありませんという問題
- 危険なシグナルをキャッチせよ
- 「障害物」や「問題」の定義：本人が「頑張れば乗り越えられそうだから問題とまでは言えない」と思ってしまえば表明されない
- 受容力のあるメンバー程耐えてしまい、思っていることを直接的に伝えられない
- 評価が下がるのでは、レッテルを張られてしまうのでは、といった心理的不安
- 「あの人があんなに頑張っているのに・・・・自分も頑張らないと！」と問題を自分で抑え込んでしまう
- 「問題がない」が問題：みんなが問題に気づけていない、捉えられていない可能性があるということ
- ファイブフィンガーで危険な兆候を察知
- 個人個人が「スプリントや仕事の今の状態」を自分の考えで表明する
- 5本：とってもうまくやれている
- 4本：うまくやれている感触あり
- 3本：可もなく不可もなく
- 2本：不安は少しある
- 1本：全然だめで絶望的
- 一番少ない本数を出したメンバーから意見を聞く：本数の多いメンバーから聞いてしまうと、ネガティブなことを言いづらい雰囲気ができてしまう
- 全員が耳を傾ける。ここで意見を否定したら、だれも本音を言わなくなる。問題を検知したいのであって、人の意見をつるし上げることはしてはいけない
- 個人個人が「スプリントや仕事の今の状態」を自分の考えで表明する
第15話 チームとプロダクトオーナーの境界
- スプリントレビュー：スプリントの成果として、価値のあるものを届けられているかをプロダクトオーナー、開発チーム全員でプロダクトに向き合う
- デモシナリオを開発チームで組み、デモ事態を開発チームで行う。デモ結果をプロダクトオーナーが受け入れるかを判断する
- 「80パーセント完成しています」「あとちょっとで完成します」は完成といわない。受け入れ条件を満たしていなければ出来上がっていないと判断する＝「0-100ルール」
- スプリントレビューのゴールは、次のスプリントで作っていくプロダクトバックログの改訂版が出来上がっているかどうか
- １．シナリオに基づいたデモ
- ２．受け入れ条件を満たしているか
- ３．完成の定義通りか
- ４．新しいアイデアを検討、価値最大化の議論
- ５．プロダクトバックログ改訂版の完成
- デモシナリオを開発チームで組み、デモ事態を開発チームで行う。デモ結果をプロダクトオーナーが受け入れるかを判断する
- 狩野モデル
- 3つの品質を定義
- 魅力的品質：充足されれば満足を与えるが、不充足であっても仕方がない
- 一元的品質：充足されれば満足、不充足であれば不満を引き起こす
- 当たり前品質：充足されて当たり前、不充足であれば不満を引き起こす
- 3つの品質を定義
第16話 チームとリーダーの境界
- むきなおり
- ふりかえりは、過去を顧みて現在を正す
- 現在地点の状態を以上にする問題を解決して、正常に戻す発想
- むきなおりは、進むべき先を捉えて現在を正す
- 将来を見据えて逆算的にそこに至る道を探り、今は何をしておくべきかと思考する
- ふりかえりは、過去を顧みて現在を正す
- むきなおりの手順
- ミッション、ビジネスを点検する
- 「我々はなぜここにいるのか」
- 評価軸を洗い出し、現状を客観的に見定める
- トレードオフスライダーで確認したQCDSなど
- 評価軸ベースで「あるべき姿」と「現状の課題」を洗い出す
- 「あるべき姿」はミッション・ビジネスから描けるはず。それと「現状」との差が捉えるべきギャップ
- 「課題解決」のために必要なステップを「バックログ」にする
- 課題が多すぎるなら、「どの課題が原因となって、どの課題が起きているか」などの課題間の因果関係を整理する
- 「バックログ」の重要度と、一番効果の高いものを決める
- 一番の基準を決めると、それとの比較で順序付けできるようになる
- 時間軸を明らかにし、期限も明確に決める
- 重要度から優先順位と時間軸を明らかにし、バックログを並べなおす
- ミッション、ビジネスを点検する
第17話 チームと新しいメンバーの境界
- 星取表（スキルマップ）
- （誰）：誰がどんなスキルを持っているのか？
- （何）：何を誰にどれくらい任せることができるのか？
- （支援）：どの作業に誰の支援が必要なのか？
- （リスク）：チームとして足りない要素は何か？
- （成長）：チームとして手薄で強化したいスキルは何か？
- （育成）：個人として長期的に成長したいスキルは何か？
- チームビルディング三種の神器
- インセプションデッキ：プロジェクトやプロダクトの目的や方法論
- ドラッカー風エクササイズ：チームメンバーの価値観
- 星取表：目的を達成するために必要なスキル
- モブプログラミング：ペアプログラミングをチームでやること
- メリット
- プロセスフロー効率性：全員で一つの作業をするので作業分担が発生しない：同期、承認、手戻り、レビューが一切不要
- コミュニケーションカイゼン
- 対話がないとモブプログラミングは成立しないし仕事が進まない。
- しかも目線の先の中心は画面：「あなた vs わたし」ではなく、「問題 vs 私たち」の構図：チーム間の醸成
- 学習効果
- お互い持っている経験や情報は異なる：チームの活動とは、自分の知らないことを学べる機会の連続
- 異なる考え方や問いが発せられると、話して自身の最高が促される：こうした相互作用により新しい考えが生まれ続ける
- 達成感
- 全員で協力し、対話し、問題をどんどん片付けることで、生まれる達成感が桁違い
- メリット
- モブワーク：モブプログラミングはほかの仕事にも応用できる
- 新しいメンバーに仕事のやり方やハマりポイントを伝授するとき
- インフラの緊急トラブルで1秒でも早く復旧が必要なとき
- 時間的にひっ迫していてい一人で作業することにまだ慣れていない状況のとき
- TWI(Training Within Industry)の中のJI（Job Instruction：仕事の教え方）
- ＜JIの手順＞
- I.習う準備をさせる
- １．気楽にさせる
- ２．何の作業をやるかを話す
- ３．その作業について何を知っているかを確かめる
- ４．作業を覚えたい気持ちにさせる
- ５．正しい位置につかせる
- II.作業を説明する
- １．主なステップを一つずつ言って聞かせ、やって見せ、書いて見せる
- ２．もう一度やりながら、急所を強調する
- III.やらせてみる
- １．やらせてみて間違いを治す
- ２．もう一度やらせながら、一つずつ主なステップを言わせる
- ３．もう一度やらせながら、一つずつ急所を言わせる
- IV.教えた後を見る
- １．仕事に就かせる
- ２．わからぬ時に聞く人を決めておく
- ３．たびたび調べる
- ４．質問するように仕向ける
- ５．だんだん指導を減らしていく
第18話 チームのやり方を変える
- スクラムマスターは役職でも選任でもなく、単なる役割
- チームにスクラムの理論、プラクティス、ルールを守ってもらうようにする
- スクラムチームの外部の人たちに、プロダクトやチームについて理解してもらう
- プロダクトオーナーや開発チームの活動を支援、コーチングする
- プロダクトバックログの価値を最大化させるためのコミュニケーションの方法や、効果的なプロダクトバックログ管理法を伝える
- スクラムイベントをファシリテートする
- チームを観察し、チームの自己組織化を後押しする
- 進捗を妨げるものを排除しながら、スクラムチームが作り出す価値を最大化する
- チームを元気づける
- 奉仕や支援を通じて、メンバーが主体的に行動するよう促すサーバントリーダーシップを発揮する
- バリューストリームマッピング：プロダクトのプロセス毎のムダを発見してカイゼンするためのツール
- タスクボードからカンバンに
- 生まれてから締め切りまでの時間が極めて短い運用課題や機能改修など、小さいものがいくつもあり、かつ一つ一つの状態を管理する場合にはカンバンが有用
- たくさんの開発機能があるステージでつっかえて流れが滞っていたり、やり忘れや手戻りがあったら、何らかのボトルネックが起きているサイン
- スクラムのベロシティ同様、カンバンでも計測が重要
- カンバンで着手Readyとなったプロダクトバックログアイテムが完了するまでの期間を計測する
- 定期的に完成したプロダクトバックログアイテムの数を数える
第19話 チームの解散
- ポストモーテム：プロジェクトの終了後、プロジェクトを振り返って行う事後検証
- その検証結果から得られた学びをほかのプロジェクトに活用できるようにするのが目的
- 気軽に発言できないようでは、当り障りのないきれいごとで終わってしまう
- 全員参加
- 人事評価には関係ないことを宣言
- 気軽で自由な発言の場にする
- 具体的な内容を語るようにする
- 各自の見方は異なるので、事実を集め、解決すべき課題を見つける
- 事実なのか、意見・解釈なのかを分ける
- ポジティブな問題解決に導く
- 全員で決めたことに意義がある。リーダーのものでもファシリテーターのものでもない
- 次のプロジェクトの糧にする。メンバ各自のTry事項を作る
第3部 みんなを巻き込む
第20話 新しいリーダーと、期待マネジメント
- 期待マネジメントのアップデート
- 内側の期待：ドラッカー風エクササイズのアップデート
- 新しいメンバーがジョインした場合でも短時間でチームをリビルド
- 自分は何が得意なのか？
- 自分はどうやって貢献するつもりか？
- 自分が大切に思う価値は何か？
- チームメンバーは自分にどんな成果を期待していると思うか？
- その期待はあっているか？
- 新しいメンバーがジョインした場合でも短時間でチームをリビルド
- 外側の期待：インセプションデッキのアップデート
- 最低限の見直し項目
- 「我々はなぜここにいるのか？」：何も変わっていないのかを問い直す。ここが変わるとプロジェクトの根幹が変わる
- 「やらないことリスト」：スコープの増減を確認し、”後で決める”ことなども時間の経過とともに更新する
- 「『ご近所さん』を探せ」：プロダクトの方向性に多大な影響を与える発言権を持った新しいステークホルダーの出現など、状況をアップデート
- 「夜も眠れない問題」：時間の経過とともに、不確定要素が減り、ボトルネックが移る場合も。リスクにきちんと向き合いコントロールする
- 「トレードオフスライダー」：状況が変わり、優先順位が変わっていないか？ステークホルダーからの圧力などから実態に即していない場合も多くある。
- 最低限の見直し項目
- 内側の期待：ドラッカー風エクササイズのアップデート
- リーダーズインテグレーション
- ＜手順＞
- １．リーダー、メンバー、ファシリテーターが会議室に集まる
- ２．リーダーの自己紹介、抱負、価値観などを発表する（5分）
- ３．リーダーは会議室から退室する
- ４．メンバーだけで以下の項目を話しながら、付箋紙に自分の意見を書き出し、ホワイトボードに貼り出して共有する
- ４－１．リーダーについて「知っていること」（10分）
- ４－２．リーターについて「知りたいこと」（10分）
- ４－３．リーダーに「知っておいて欲しいこと」（10分）
- ４－４．リーダーのために「みんなができること」（10分）
- ５．メンバーが会議室から退室しリーダーが入室する
- ６．ファシリテーターが議論の流れや行間をリーダーに説明する（誰の発言かは伏せる）（10分）
- ７．リーダーは付箋紙の意見を見ながら回答を考える（10分）
- ８．メンバーが入室し、リーダーがメンバーに回答する（25分）
- ９．慰労会やフリートークでざっくばらんに雑談する
- ＜手順＞
- モダンアジャイル（心理的安全な場）
- 基本原則
- １．人々を最高に輝かせる
- ２．安全を必須条件にする
- ３．高速に実験＆学習する
- ４．継続的に価値を届ける
- ３の「安全を必須条件にする」とは？
- プロジェクトやチームの状態
- 人を非難しないメンバー間の関係性
- コードの修正をCIやテストで担保すること
- 「チームの状態が安全であること」も重要なファクター
- チームの中で反対の意見を言ったりミスをしてしまっても、そのことで非難されたり評価が下がったりしない場が重要
- お互いが尊敬しあい、信頼できているという確信が、より強いチームへと導き、結果として高い生産性が生まれる
- 基本原則
第21話 外からきたメンバーと、計画づくり
- アジャイルな見積、アジャイルな計画づくり
- ＜基本的な流れ＞
- １．規模の見積
- ２．見積もったストーリーポイントの合計
- ３．期間への変換
- ４．スケジューリング
- 規模と期間を分けることがポイント
- プランニングポーカー
- プランニングポーカーがうまくいく理由：参加者がそれぞれの知見を持ち寄って、活発な議論を行うから
- 結果がバラバラになるということはそれだけ異なる見方が存在するということ
- 出したカードの数字がお互い異なれば、その説明をする：説明の過程で懸念事項や過去の失敗談を共有できる
- チーム内でのタスクの難易度やスキルギャップが埋められていく
- プランニングポーカーがうまくいく理由：参加者がそれぞれの知見を持ち寄って、活発な議論を行うから
- リリースプランニング
- 計画ではなく計画づくりをしよう
- 計画とはその時点で分かっていることをベースとした単なるスナップショット
- 計画変更を後ろ向きなスタンスとして捉えるのは終わりにする
- 短いスパンで繰り返し、足りないタスクは計画的に追加し、誤った見積は修正していく
- 継続的な学びを知識とし、プロジェクトに適応させ続けることが重要
- 計画ではなく計画づくりをしよう
- ＜基本的な流れ＞
- CCPM（Critical Chain Project Management）
- 計画はたいてい上振れする
- パーキンソンの法則：仕事の量は完成のために与えられた時間を満たすまで膨張する
- CCPM：個別のバッファは持たず、全体としてのプロジェクトバッファをもって、個々のタスクが遅れた場合には全体バッファから消費していく
- 計画はたいてい上振れする
第22話 外部チームと、やり方をむきなおる
- 越境するむきなおり
- 別々のチーム間でのむきなおり
- 目の前のことだけに集中して衝突するのではなく、お互いの共通ミッションである「プロジェクトとして実現しなければならないこと」に立ち返る
- 一つ上の視座にお互いが立てたとき、それまで衝突していたことは小さくなる
- 別々のチーム間でのむきなおり
- YWTでのむきなおり
- 進むべき先を捉えながら、以下の3つの問いをする
- Y:やったこと
- W:わかったこと
- T:次にやること
- 定期的に行うことで次回のYWTでは前回のT(次にやること)がY（やったこと）に移動しているはず → その結果、W（わかったこと）がアップデートされる
- 進むべき先を捉えながら、以下の3つの問いをする
- アーキテクチャと組織の構造
- コンウェイの法則：「アーキテクチャは組織に従う。組織はアーキテクチャに従う。」
- アーキテクチャと組織の構造は表裏一体
- 組織階層や組織数、人数が増加していくと、プロジェクトとかプロダクトとかというチームの話ではなくなってくる
- つまり、問題解決の根底にある会社規模の組織変更を視野に入れなくてはならない
- アーキテクチャと組織の構造は表裏一体
- スクラム・オブ・スクラムが浸透すれば、旧来型の上意下達型のピラミッド構造の組織から、会社組織全体が自己組織化された集団への一歩となる
- コンウェイの法則：「アーキテクチャは組織に従う。組織はアーキテクチャに従う。」
第23話 デザイナーと、共通の目標に向かう
- ユーザーストーリー
- デザインチームと開発チームがそれぞれで動くために必要な「共通する理解」となりえるもの
- ユーザーストーリーの3段構成
- ＜ユーザー／顧客＞として：Who
- ＜XXXを達成＞をしたい：What
- なぜなら＜理由＞だからだ：Why
- ユーザーストーリーはあいまい・抽象的過ぎても、詳細を書きすぎてもよくない
- ：ユーザーストーリーを評価するために有用な条件
- I：Independent（独立して優先順位がつけられる）
- N：Negotiable（何を作るのかの案が調整可能である）
- V：Valuable（価値のある）
- E：Estimable（見積可能である）
- S：Small（チームで扱いやすい手ごろなサイズである）
- T：Testable（テストできる）
第24話 視座を変えて、突破するための見方を得る
- 仮説キャンバス
- ビジネスモデルキャンバス
- リーンキャンバス
第25話 広さと深さで、プロダクトを見立てる
- MVP：「ユーザーにとって価値があり、かつ最小限の機能性を持った製品」
- ユーザーストーリーマッピング
- 時間の流れに沿ってユーザーの行動を洗い出し、その変遷を可視化していくワーク
- ＜手順＞
- １．ざっくりと場面を話し、付箋紙に列挙する
- ２．時間軸に沿って並べ替える
- ３．人物像を描き、付箋紙に書き出す
- ４．場面ごとの行動を上げ、付箋紙に書き出す
- ５．各行動に対するストーリーを付箋紙に書き出す
- ６．行動やストーリーから抜け漏れを見つける
- ７．それぞれの行動軸に沿って、ストーリーの優先順位をつける
- ７－１．優先順位付けの1回目は、ユーザーにとって価値があるストーリーの順序を上にする
- ７－２．優先順位付けの2回目は、検証できていないストーリーや、作って確認したいストーリーの順序を上にする
- ８．特定の目標のために、最も優先順位の高い最小限のストーリー群をスライスして切り出す
- ９．切り出した最優先のスライスをMVPとして特定する
- １０．今後のリリースに向け、優先度の高いストーリー順ごとに、ストーリー軍をスライスして切り出していく。それぞれのスライスがリリースロードマップとなる。
第26話 チームで共に越える
- ユーザーインタビュー
- インタビューの技
- インタビューの際は、前置きは控えましょう。回答が誘導されてしまうのを防ぐため
- 中立でいましょう。インタビューアがどちらかのスタンスに立ってしまうと本音は出てこない
- 自分が確証バイアス（自分の関心事や都合のよい情報ばかりを集めてしまうこと）にとらわれている可能性を常に意識しましょう。自分の意見を強化したかったり、聞きたいことのみが記憶に残りやすいものです
- 誘導してはいけません。無意識のうちに誘導している場合もあります。自分の発言が相手にどんな影響を与えるのか、注意を払いましょう。
- インタビュー結果をすばやくチームでフィードバックしましょう。メンバーからの気づきも得ましょう
- インタビューが終了した時が重要です。帰り際に緊張感から解放されて本音が出ることもあります。エレベータホールや玄関までの見送りの時間も大切にしましょう
- とにかく相手と話しているこの時間を、楽しく演出しましょう。信頼関係と本音はリラックスした空間から生まれます。
- インタビューの技
第27話 越境する開発
- ハンガーフライト
- 飛行機乗りの世界での言葉。「ハンガー」は飛行機の格納庫のこと。天候が悪くて飛行機を飛ばせないとき、パイロットたちは格納庫の片隅で経験談などの雑談をしたことから。
- 自分一人で経験できることには限界がある。自分の経験を積極的に共有し、ほかの人の経験を自分のものとして体得する。
- 必ずしもすぐに役立つ知識ではないかもしれないが、経験や勘に基づく知識が蓄積され、成長する
- この現場の課題を、向こうの現場ですでに乗り越えているかもしれない。
- お互いの経験を共有し、経験と知恵をつなぐ機会を作る
- 飛行機乗りの世界での言葉。「ハンガー」は飛行機の格納庫のこと。天候が悪くて飛行機を飛ばせないとき、パイロットたちは格納庫の片隅で経験談などの雑談をしたことから。