続・やっぱり余白が大切だった話

D-Plus トウキョウ1周年大感謝祭
https://d-plus.connpass.com/event/352404/
での登壇資料です

Transcript

1. ©KAKEHASHI inc. やっぱり余白が大切だった話 2025年5月8日 松本 明紘 D-Plus トウキョウ1周年大感謝祭 続
2. ©KAKEHASHI inc. 株式会社 カケハシ(2023年2月〜) • AI在庫管理、医薬品のSCM関連の新規事業 • バックエンドに軸足を置くテックリード もっち(X: @mottyzzz) 松本 明紘 2 自己紹介 https://speakerdeck.com/kakehashi
3. ©KAKEHASHI inc. 前回のお話の 簡単なふりかえり
4. ©KAKEHASHI inc. 4 前回のふりかえり
5. ©KAKEHASHI inc. 5 個人の自主的な取り組みによって、 チーム全体の柔軟さや変化への強さを 向上させたい！
6. ©KAKEHASHI inc. 6 2つの余白によるアプローチ 計画外の小さな余白を上手に使えるようにする 余白② 計画的なチームの余白を作る 余白①
7. ©KAKEHASHI inc. 7 ①計画的にチームの余白を作る スプリントごとに、あとでカイゼンする余白を作る
8. ©KAKEHASHI inc. 8 ①計画的にチームの余白を作る 下記のようなワーキングアグリーメントで実際に取り組んでいる • 1週間スプリントの5日目はロードマップの開発は行わない • プランニング時点で１週間の最初の3日で完了するくらいの 余裕をもった計画にする • 想定より早くそのスプリントの開発が完了しとしても、 次の開発項目を始めない
9. ©KAKEHASHI inc. 発表後にいただいた声
10. ©KAKEHASHI inc. 忙しいと、余白を作ろうとしても 他のものをやってくれという フォースがあり難しい
11. ©KAKEHASHI inc. 優秀なチームじゃないと 難しそう
12. ©KAKEHASHI inc. 怖い (開発が遅延しそうで)
13. ©KAKEHASHI inc. 木こりのジレンマ 13 ある日の朝、旅人は山の中を歩いていました。 奥深い森の中、汗を流しながら一生懸命に木を伐っているきこりを見かけました。 そして夕方、同じ道を戻ってみると・・・、朝と同じ場所で、玉の汗をかきながら一生懸 命木を伐り続けているきこりがいました。 でも、あんまり作業は進んでいないようでした。 旅人は足を止めてよくよく見ると、きこりが使っている斧の刃は、ボロボロでした。 そこで、きこりに声をかけました。 旅人：「きこりさん、精がでますなぁ。でもあんまり作業は進んでないみたいですね、一 旦手を止めて、斧の刃を研いだらどうですか？」 きこり：「旅人さんよ、なに言ってるんだよ、刃を研ぐ時間なんておいらには無いんだ よ、木を伐るのが忙しくてさ・・・。」 “ http://www.keieicoach.jp/news/418/ 引用： と 生産性向上には余白が必要 のジレンマ 忙しいので余白なんか取れない
14. ©KAKEHASHI inc. 余白があったらいいよね ではなく 余白は必須
15. ©KAKEHASHI inc. やっぱり余白が大切だった話 2025年5月8日 松本 明紘 D-Plus トウキョウ1周年大感謝祭 続
16. ©KAKEHASHI inc. 余白があったらいいよねではなく、余白は必須 • 事業やプロダクトの成長によりシステムが大きくなるにしたがって、 見えづらい活動が増えていく(既存仕様・コードの理解、運用、保守、障害対応) • 不確実性の高い課題に対してスパイク(調査・検証タスク)を設けて、無理に開発 を進めず、理解にも十分に時間を使うことで手戻りや品質問題を防ぐ • ソースコード改善や開発プロセスの改善、運用の自動化などに時間を確保できな いと、組織やチームとしての成長が止まってしまう 16 適切に設けられた余白は スクラムチームの安定と持続性と向上させる
17. ©KAKEHASHI inc. • 中規模以上の開発テーマは開発ロードマップ(全体マップ)を作成し、変化を前 提に開発ロードマップを使ってゆるいプロジェクトマネジメントを行う • 開発ロードマップを使い、コミュニケーションを高頻度に、内容の確認や仮説含 めた提案を行う。その中で、ターゲット、見積もり、コミットメントを区別しなが ら優先度を決めて計画を立てる • このときに、不確実性（事業的側面、技術的側面の両方を含む）が高いアイテム ほど優先度を上げる • ターゲットの達成をゴールにしながら、開発者目線で必要なアイテムも並べて優 先度を決める。ターゲットの達成のために何が後回しになったかを明確にして おく • スクラムイベントで開発ロードマップを見ながら状況や優先度の変化、進捗をそ の場で更新しながら認識合わせをすることでロールをまたがった情報対称性を 高める 本日話すこと 余白を上手にコントロールできるチームになるために実践していること 17
18. ©KAKEHASHI inc. 木こりのジレンマ 18 ある日の朝、旅人は山の中を歩いていました。 奥深い森の中、汗を流しながら一生懸命に木を伐っているきこりを見かけました。 そして夕方、同じ道を戻ってみると・・・、朝と同じ場所で、玉の汗をかきながら一生懸 命木を伐り続けているきこりがいました。 でも、あんまり作業は進んでいないようでした。 旅人は足を止めてよくよく見ると、きこりが使っている斧の刃は、ボロボロでした。 そこで、きこりに声をかけました。 旅人：「きこりさん、精がでますなぁ。でもあんまり作業は進んでないみたいですね、一 旦手を止めて、斧の刃を研いだらどうですか？」 きこり：「旅人さんよ、なに言ってるんだよ、刃を研ぐ時間なんておいらには無いんだ よ、木を伐るのが忙しくてさ・・・。」 “ http://www.keieicoach.jp/news/418/ 引用： と 生産性向上には余白が必要 のジレンマ 忙しいので余白なんか取れない
19. ©KAKEHASHI inc. プロジェクトマネジメントを 特定の誰かに押し付けていませんか？
20. ©KAKEHASHI inc. こんなことありませんか？(1/4) 20 機能Zの開発、 どのくらいかかりそうか教えて ラフな見積もりですが 機能Zの開発には2週間くらいかかりそうです 了解、ありがとう！じゃあそのまま進めてください (ステークホルダーにも伝えとこう)
21. ©KAKEHASHI inc. こんなことありませんか？(2/4) 21 そろそろ2週間だよね？ リリースどうなってる？ 今週で終わると思っていましたが、 もう少しかかりそうです そして2週間後… え、それなら、早めにできないって 言ってくれればよかったのに。 顧客にも約束しているので遅れるとまずいですよ。
22. ©KAKEHASHI inc. こんなことありませんか？(3/4) 22 つぎの機能Yの開発、どのくらいでできそう？ (2週間くらいでできると展示会に間に合って嬉しい んだけど) (実際には2週間くらいだと思うけど、 また怒られたくないから) ちょっと難しいところがあるので 1ヶ月くらいかかると思います。 分かりました、ありがとうございます (結構かかるな… この前の機能と似たような感じなのにな)
23. ©KAKEHASHI inc. こんなことありませんか？(4/4) 23 (余裕ある感じするし、まずは軽くやっていくか) そして2週間後… (ずっと順調そうだったのに結局ギリギリまでかかった な。本当に1ヶ月必要だったのかな) (ちょうど半分くらいだし今のペースでちょうどだよな。 ちょっと仕様が曖昧なところあるけど、来週でいいか) さらに1週間後… (うわ、テストまだ残ってた。 まぁあと2日くらいで終わらせよう)
24. ©KAKEHASHI inc. ターゲット、見積もり、 コミットメント、計画が 混在している状態での コミュニケーションになっている
25. ©KAKEHASHI inc. ターゲット、見積もり、コミットメント、計画 25 本来の意味 よくある誤認 誤認による悪影響 見積もり • 実装に必要な作業量や期 間の予測 • 幅があることが多い • 分析的・仮説的であるべき もの • 勝手にコミットメントに される • 勝手に計画にされる • 正確なもの、精度が高い ほど良い • 余裕がなくなる • 遅れると「失敗」と見なされる不安 から過剰バッファを取るようにな る ターゲット • 事業上の理由から達成し たい希望的な期日やス コープの目標 • すでにコミットメントさ れた必達命令 • 実現性があるもの • 現実的な調整や健全な遅延が許さ れなくなる • どうすればゴールに近づけるか？ という工夫・調整がなくなり、事業 上の効果の最大化ができなくなる コミットメ ント • チームが達成を約束した 期日やスコープ • 納期 • 絶対に調整が不可能な もの • やらされ感やモチベーション低下、 心理的安全性の低下 計画 • 見積もり、ターゲット、コ ミットメントから立てた現 実的に実行可能な道筋 • 守るべき進行表 • リスク対応ができない • 柔軟な判断や学習が止まる • 形骸化した「予定表」になる
26. ©KAKEHASHI inc. こんなことありませんか？(1/4) 26 機能Zの開発、 どのくらいかかりそうか教えて ラフな見積もりですが 機能Zの開発には2週間くらいかかりそうです 了解、ありがとう！じゃあそのまま進めてください (ステークホルダーにも伝えとこう) 本当は計画 が知りたい 見積もり 計画だと認識、そ して勝手なコミッ トメント
27. ©KAKEHASHI inc. こんなことありませんか？(2/4) 27 そろそろ2週間だよね？ リリースどうなってる？ 今週で終わると思っていましたが、 もう少しかかりそうです そして2週間後… え、それなら、早めにできないって 言ってくれればよかったのに。 顧客にも約束しているので遅れるとまずいですよ。 計画だと 思っている これも 見積もり ラフな見積もりのまま 開発スタートし、ゆるい 開発だと思っていたの で、不信感 計画だと思ってコ ミットメントまでし た、不信感
28. ©KAKEHASHI inc. (実際には2週間くらいだと思うけど、 また怒られたくないから) ちょっと難しいところがあるので 1ヶ月くらいかかると思います。 分かりました、ありがとうございます (結構かかるな… この前の機能と似たような感じなのにな) こんなことありませんか？(3/4) 28 つぎの機能Yの開発、どのくらいでできそう？ (2週間くらいでできると展示会に間に合って嬉しい んだけど) 今度は見積もりのつもり (暗黙的なターゲットの 存在) 不健全な 見積もり サボっているよう に感じて不信感 前回と同じこ とになるだろ う不信感
29. ©KAKEHASHI inc. こんなことありませんか？(4/4) 29 (余裕ある感じするし、まずは軽くやっていくか) そして2週間後… (ずっと順調そうだったのに結局ギリギリまでかかった な。本当に1ヶ月必要だったのかな) (ちょうど半分くらいだし今のペースでちょうどだよな。 ちょっと仕様が曖昧なところあるけど、来週でいいか) さらに1週間後… (うわ、テストまだ残ってた。 まぁあと2日くらいで終わらせよう) 本来得られた事業 上の価値の最大 化のチャンスを逃 してしまう 余裕があると「まだ大 丈夫」と思い、緊張感 が失われてダラダラ 進む
30. ©KAKEHASHI inc. プロジェクトマネジメントを 特定の誰かに押し付けていませんか？
31. ©KAKEHASHI inc. 誰がやるべきとかではない 全員でやる ※AI在庫管理の開発チームではPjMロールはいない
32. ©KAKEHASHI inc. 開発ロードマップ(全体マップ) 32 https://kakehashi-dev.hatenablog.com/entry/2024/09/09/110000 AI在庫管理のチームでは、中規模な開発テーマに対しては、 PdM、エンジニアなどチーム全員で開発ロードマップ(全体マップ)を作っている 全体マップ自体の説明はこちら： 機能1 機能2 機能3
33. ©KAKEHASHI inc. 開発ロードマップを一緒に作りながらコミュニケーション(1/3) 33 このステークホルダーに対して 機能1、機能2、機能3を 段階的に12月までにリリースしたいです ちょっと全部を12月は難しそうですね… この順番でリリースしたい理由はありますか？ 本当は機能３を先に出して効果検証したいんだけど、 機能1と機能2はその前提になる気がして 確かに前提になる部分ありそうですね。 ただ機能1と機能2の共通部分だけ先に開発して、 機能3だけミニマムで使える状態にはできそうな気 がします 本当のターゲッ トのスコープ 見積もりと ターゲットの確認 ターゲットの 説明
34. ©KAKEHASHI inc. 開発ロードマップを一緒に作りながらコミュニケーション(2/3) 34 全部を100%スコープだと機能3のリリースが2 月くらいまでかかりそうですけど、機能3の効果 検証できるミニマムな範囲であれば10月くらい にはできる気がします その進め方で不確実性がありそうところはあります か？ 機能１と機能2に想定外の事情の変化があった場 合、一気に100%スコープを開発するよりも、 トータルの時間がかかることになると思います。 機能3の結果によって、他の機能の優先度上げたくな る可能性もあるので、その方針で詳細の見積もりをお 願いします。 見積もり 見積もりの 幅の確認 見積もりの 幅 計画につな がる
35. ©KAKEHASHI inc. 開発ロードマップを一緒に作りながらコミュニケーション(3/3) 35 設計した結果、パフォーマンス問題が発生する可 能性がありそうです。 10月にはできそうと話していましたが、性能検 証を先にしたいです。もともと12月という話も あったので多少の余裕はあるかなと思っていま すが大丈夫ですか？ もちろん早めが嬉しいですが、重要なステークホル ダーなので、できるだけ事前に懸念も減らしましょう ありがとうございます。 現時点では１０月目標で進めますが、何か問題を 発見した場合はまた相談させてください。 ターゲットを考 慮した計画変 更の提案 ターゲットの 追加情報 確率的な コミットメント
36. ©KAKEHASHI inc. 事業的側面、技術的側面の両面から 最適な選択肢がとれる
37. ©KAKEHASHI inc. 情報対称性が高まり 信頼関係の構築にもつながる
38. ©KAKEHASHI inc. こういったコミュニケーションの結果 チームの最適な開発スタイル ができあがっていった
39. ©KAKEHASHI inc. コミュニケーションの結果できた現在の余白のスタイル 39
40. ©KAKEHASHI inc. 最初から全部はできない
41. ©KAKEHASHI inc. やらないとできるようには ならない
42. ©KAKEHASHI inc. チームの信頼と文化を作っていくために 練習しよう。訓練しよう。
43. ©KAKEHASHI inc. やっぱり余白が大切だった話 2025年5月8日 松本 明紘 D-Plus トウキョウ1周年大感謝祭 続