Slide 1

Slide 1 text

©KAKEHASHI inc. やっぱり余白が大切だった話 2025年5月8日 松本 明紘 D-Plus トウキョウ1周年大感謝祭 続

Slide 2

Slide 2 text

©KAKEHASHI inc. 株式会社 カケハシ(2023年2月〜) ● AI在庫管理、医薬品のSCM関連の新規事業 ● バックエンドに軸足を置くテックリード もっち(X: @mottyzzz) 松本 明紘 2 自己紹介 https://speakerdeck.com/kakehashi

Slide 3

Slide 3 text

©KAKEHASHI inc. 前回のお話の 簡単なふりかえり

Slide 4

Slide 4 text

©KAKEHASHI inc. 4 前回のふりかえり

Slide 5

Slide 5 text

©KAKEHASHI inc. 5 個人の自主的な取り組みによって、 チーム全体の柔軟さや変化への強さを 向上させたい!

Slide 6

Slide 6 text

©KAKEHASHI inc. 6 2つの余白によるアプローチ 計画外の小さな余白を上手に使えるようにする 余白② 計画的なチームの余白を作る 余白①

Slide 7

Slide 7 text

©KAKEHASHI inc. 7 ①計画的にチームの余白を作る スプリントごとに、あとでカイゼンする余白を作る

Slide 8

Slide 8 text

©KAKEHASHI inc. 8 ①計画的にチームの余白を作る 下記のようなワーキングアグリーメントで実際に取り組んでいる ● 1週間スプリントの5日目はロードマップの開発は行わない ● プランニング時点で1週間の最初の3日で完了するくらいの 余裕をもった計画にする ● 想定より早くそのスプリントの開発が完了しとしても、 次の開発項目を始めない

Slide 9

Slide 9 text

©KAKEHASHI inc. 発表後にいただいた声

Slide 10

Slide 10 text

©KAKEHASHI inc. 忙しいと、余白を作ろうとしても 他のものをやってくれという フォースがあり難しい

Slide 11

Slide 11 text

©KAKEHASHI inc. 優秀なチームじゃないと 難しそう

Slide 12

Slide 12 text

©KAKEHASHI inc. 怖い (開発が遅延しそうで)

Slide 13

Slide 13 text

©KAKEHASHI inc. 木こりのジレンマ 13 ある日の朝、旅人は山の中を歩いていました。 奥深い森の中、汗を流しながら一生懸命に木を伐っているきこりを見かけました。 そして夕方、同じ道を戻ってみると・・・、朝と同じ場所で、玉の汗をかきながら一生懸 命木を伐り続けているきこりがいました。 でも、あんまり作業は進んでいないようでした。 旅人は足を止めてよくよく見ると、きこりが使っている斧の刃は、ボロボロでした。 そこで、きこりに声をかけました。 旅人:「きこりさん、精がでますなぁ。でもあんまり作業は進んでないみたいですね、一 旦手を止めて、斧の刃を研いだらどうですか?」 きこり:「旅人さんよ、なに言ってるんだよ、刃を研ぐ時間なんておいらには無いんだ よ、木を伐るのが忙しくてさ・・・。」 “ http://www.keieicoach.jp/news/418/ 引用: と 生産性向上には余白が必要 のジレンマ 忙しいので余白なんか取れない

Slide 14

Slide 14 text

©KAKEHASHI inc. 余白があったらいいよね ではなく 余白は必須

Slide 15

Slide 15 text

©KAKEHASHI inc. やっぱり余白が大切だった話 2025年5月8日 松本 明紘 D-Plus トウキョウ1周年大感謝祭 続

Slide 16

Slide 16 text

©KAKEHASHI inc. 余白があったらいいよねではなく、余白は必須 ● 事業やプロダクトの成長によりシステムが大きくなるにしたがって、 見えづらい活動が増えていく(既存仕様・コードの理解、運用、保守、障害対応) ● 不確実性の高い課題に対してスパイク(調査・検証タスク)を設けて、無理に開発 を進めず、理解にも十分に時間を使うことで手戻りや品質問題を防ぐ ● ソースコード改善や開発プロセスの改善、運用の自動化などに時間を確保できな いと、組織やチームとしての成長が止まってしまう 16 適切に設けられた余白は スクラムチームの安定と持続性と向上させる

Slide 17

Slide 17 text

©KAKEHASHI inc. ● 中規模以上の開発テーマは開発ロードマップ(全体マップ)を作成し、変化を前 提に開発ロードマップを使ってゆるいプロジェクトマネジメントを行う ● 開発ロードマップを使い、コミュニケーションを高頻度に、内容の確認や仮説含 めた提案を行う。その中で、ターゲット、見積もり、コミットメントを区別しなが ら優先度を決めて計画を立てる ● このときに、不確実性(事業的側面、技術的側面の両方を含む)が高いアイテム ほど優先度を上げる ● ターゲットの達成をゴールにしながら、開発者目線で必要なアイテムも並べて優 先度を決める。ターゲットの達成のために何が後回しになったかを明確にして おく ● スクラムイベントで開発ロードマップを見ながら状況や優先度の変化、進捗をそ の場で更新しながら認識合わせをすることでロールをまたがった情報対称性を 高める 本日話すこと 余白を上手にコントロールできるチームになるために実践していること 17

Slide 18

Slide 18 text

©KAKEHASHI inc. 木こりのジレンマ 18 ある日の朝、旅人は山の中を歩いていました。 奥深い森の中、汗を流しながら一生懸命に木を伐っているきこりを見かけました。 そして夕方、同じ道を戻ってみると・・・、朝と同じ場所で、玉の汗をかきながら一生懸 命木を伐り続けているきこりがいました。 でも、あんまり作業は進んでいないようでした。 旅人は足を止めてよくよく見ると、きこりが使っている斧の刃は、ボロボロでした。 そこで、きこりに声をかけました。 旅人:「きこりさん、精がでますなぁ。でもあんまり作業は進んでないみたいですね、一 旦手を止めて、斧の刃を研いだらどうですか?」 きこり:「旅人さんよ、なに言ってるんだよ、刃を研ぐ時間なんておいらには無いんだ よ、木を伐るのが忙しくてさ・・・。」 “ http://www.keieicoach.jp/news/418/ 引用: と 生産性向上には余白が必要 のジレンマ 忙しいので余白なんか取れない

Slide 19

Slide 19 text

©KAKEHASHI inc. プロジェクトマネジメントを 特定の誰かに押し付けていませんか?

Slide 20

Slide 20 text

©KAKEHASHI inc. こんなことありませんか?(1/4) 20 機能Zの開発、 どのくらいかかりそうか教えて ラフな見積もりですが 機能Zの開発には2週間くらいかかりそうです 了解、ありがとう!じゃあそのまま進めてください (ステークホルダーにも伝えとこう)

Slide 21

Slide 21 text

©KAKEHASHI inc. こんなことありませんか?(2/4) 21 そろそろ2週間だよね? リリースどうなってる? 今週で終わると思っていましたが、 もう少しかかりそうです そして2週間後… え、それなら、早めにできないって 言ってくれればよかったのに。 顧客にも約束しているので遅れるとまずいですよ。

Slide 22

Slide 22 text

©KAKEHASHI inc. こんなことありませんか?(3/4) 22 つぎの機能Yの開発、どのくらいでできそう? (2週間くらいでできると展示会に間に合って嬉しい んだけど) (実際には2週間くらいだと思うけど、 また怒られたくないから) ちょっと難しいところがあるので 1ヶ月くらいかかると思います。 分かりました、ありがとうございます (結構かかるな… この前の機能と似たような感じなのにな)

Slide 23

Slide 23 text

©KAKEHASHI inc. こんなことありませんか?(4/4) 23 (余裕ある感じするし、まずは軽くやっていくか) そして2週間後… (ずっと順調そうだったのに結局ギリギリまでかかった な。本当に1ヶ月必要だったのかな) (ちょうど半分くらいだし今のペースでちょうどだよな。 ちょっと仕様が曖昧なところあるけど、来週でいいか) さらに1週間後… (うわ、テストまだ残ってた。 まぁあと2日くらいで終わらせよう)

Slide 24

Slide 24 text

©KAKEHASHI inc. ターゲット、見積もり、 コミットメント、計画が 混在している状態での コミュニケーションになっている

Slide 25

Slide 25 text

©KAKEHASHI inc. ターゲット、見積もり、コミットメント、計画 25 本来の意味 よくある誤認 誤認による悪影響 見積もり ● 実装に必要な作業量や期 間の予測 ● 幅があることが多い ● 分析的・仮説的であるべき もの ● 勝手にコミットメントに される ● 勝手に計画にされる ● 正確なもの、精度が高い ほど良い ● 余裕がなくなる ● 遅れると「失敗」と見なされる不安 から過剰バッファを取るようにな る ターゲット ● 事業上の理由から達成し たい希望的な期日やス コープの目標 ● すでにコミットメントさ れた必達命令 ● 実現性があるもの ● 現実的な調整や健全な遅延が許さ れなくなる ● どうすればゴールに近づけるか? という工夫・調整がなくなり、事業 上の効果の最大化ができなくなる コミットメ ント ● チームが達成を約束した 期日やスコープ ● 納期 ● 絶対に調整が不可能な もの ● やらされ感やモチベーション低下、 心理的安全性の低下 計画 ● 見積もり、ターゲット、コ ミットメントから立てた現 実的に実行可能な道筋 ● 守るべき進行表 ● リスク対応ができない ● 柔軟な判断や学習が止まる ● 形骸化した「予定表」になる

Slide 26

Slide 26 text

©KAKEHASHI inc. こんなことありませんか?(1/4) 26 機能Zの開発、 どのくらいかかりそうか教えて ラフな見積もりですが 機能Zの開発には2週間くらいかかりそうです 了解、ありがとう!じゃあそのまま進めてください (ステークホルダーにも伝えとこう) 本当は計画 が知りたい 見積もり 計画だと認識、そ して勝手なコミッ トメント

Slide 27

Slide 27 text

©KAKEHASHI inc. こんなことありませんか?(2/4) 27 そろそろ2週間だよね? リリースどうなってる? 今週で終わると思っていましたが、 もう少しかかりそうです そして2週間後… え、それなら、早めにできないって 言ってくれればよかったのに。 顧客にも約束しているので遅れるとまずいですよ。 計画だと 思っている これも 見積もり ラフな見積もりのまま 開発スタートし、ゆるい 開発だと思っていたの で、不信感 計画だと思ってコ ミットメントまでし た、不信感

Slide 28

Slide 28 text

©KAKEHASHI inc. (実際には2週間くらいだと思うけど、 また怒られたくないから) ちょっと難しいところがあるので 1ヶ月くらいかかると思います。 分かりました、ありがとうございます (結構かかるな… この前の機能と似たような感じなのにな) こんなことありませんか?(3/4) 28 つぎの機能Yの開発、どのくらいでできそう? (2週間くらいでできると展示会に間に合って嬉しい んだけど) 今度は見積もりのつもり (暗黙的なターゲットの 存在) 不健全な 見積もり サボっているよう に感じて不信感 前回と同じこ とになるだろ う不信感

Slide 29

Slide 29 text

©KAKEHASHI inc. こんなことありませんか?(4/4) 29 (余裕ある感じするし、まずは軽くやっていくか) そして2週間後… (ずっと順調そうだったのに結局ギリギリまでかかった な。本当に1ヶ月必要だったのかな) (ちょうど半分くらいだし今のペースでちょうどだよな。 ちょっと仕様が曖昧なところあるけど、来週でいいか) さらに1週間後… (うわ、テストまだ残ってた。 まぁあと2日くらいで終わらせよう) 本来得られた事業 上の価値の最大 化のチャンスを逃 してしまう 余裕があると「まだ大 丈夫」と思い、緊張感 が失われてダラダラ 進む

Slide 30

Slide 30 text

©KAKEHASHI inc. プロジェクトマネジメントを 特定の誰かに押し付けていませんか?

Slide 31

Slide 31 text

©KAKEHASHI inc. 誰がやるべきとかではない 全員でやる ※AI在庫管理の開発チームではPjMロールはいない

Slide 32

Slide 32 text

©KAKEHASHI inc. 開発ロードマップ(全体マップ) 32 https://kakehashi-dev.hatenablog.com/entry/2024/09/09/110000 AI在庫管理のチームでは、中規模な開発テーマに対しては、 PdM、エンジニアなどチーム全員で開発ロードマップ(全体マップ)を作っている 全体マップ自体の説明はこちら: 機能1 機能2 機能3

Slide 33

Slide 33 text

©KAKEHASHI inc. 開発ロードマップを一緒に作りながらコミュニケーション(1/3) 33 このステークホルダーに対して 機能1、機能2、機能3を 段階的に12月までにリリースしたいです ちょっと全部を12月は難しそうですね… この順番でリリースしたい理由はありますか? 本当は機能3を先に出して効果検証したいんだけど、 機能1と機能2はその前提になる気がして 確かに前提になる部分ありそうですね。 ただ機能1と機能2の共通部分だけ先に開発して、 機能3だけミニマムで使える状態にはできそうな気 がします 本当のターゲッ トのスコープ 見積もりと ターゲットの確認 ターゲットの 説明

Slide 34

Slide 34 text

©KAKEHASHI inc. 開発ロードマップを一緒に作りながらコミュニケーション(2/3) 34 全部を100%スコープだと機能3のリリースが2 月くらいまでかかりそうですけど、機能3の効果 検証できるミニマムな範囲であれば10月くらい にはできる気がします その進め方で不確実性がありそうところはあります か? 機能1と機能2に想定外の事情の変化があった場 合、一気に100%スコープを開発するよりも、 トータルの時間がかかることになると思います。 機能3の結果によって、他の機能の優先度上げたくな る可能性もあるので、その方針で詳細の見積もりをお 願いします。 見積もり 見積もりの 幅の確認 見積もりの 幅 計画につな がる

Slide 35

Slide 35 text

©KAKEHASHI inc. 開発ロードマップを一緒に作りながらコミュニケーション(3/3) 35 設計した結果、パフォーマンス問題が発生する可 能性がありそうです。 10月にはできそうと話していましたが、性能検 証を先にしたいです。もともと12月という話も あったので多少の余裕はあるかなと思っていま すが大丈夫ですか? もちろん早めが嬉しいですが、重要なステークホル ダーなので、できるだけ事前に懸念も減らしましょう ありがとうございます。 現時点では10月目標で進めますが、何か問題を 発見した場合はまた相談させてください。 ターゲットを考 慮した計画変 更の提案 ターゲットの 追加情報 確率的な コミットメント

Slide 36

Slide 36 text

©KAKEHASHI inc. 事業的側面、技術的側面の両面から 最適な選択肢がとれる

Slide 37

Slide 37 text

©KAKEHASHI inc. 情報対称性が高まり 信頼関係の構築にもつながる

Slide 38

Slide 38 text

©KAKEHASHI inc. こういったコミュニケーションの結果 チームの最適な開発スタイル ができあがっていった

Slide 39

Slide 39 text

©KAKEHASHI inc. コミュニケーションの結果できた現在の余白のスタイル 39

Slide 40

Slide 40 text

©KAKEHASHI inc. 最初から全部はできない

Slide 41

Slide 41 text

©KAKEHASHI inc. やらないとできるようには ならない

Slide 42

Slide 42 text

©KAKEHASHI inc. チームの信頼と文化を作っていくために 練習しよう。訓練しよう。

Slide 43

Slide 43 text

©KAKEHASHI inc. やっぱり余白が大切だった話 2025年5月8日 松本 明紘 D-Plus トウキョウ1周年大感謝祭 続