Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
続・やっぱり余白が大切だった話
Search
KAKEHASHI
PRO
May 08, 2025
Technology
4
730
続・やっぱり余白が大切だった話
D-Plus トウキョウ1周年大感謝祭
https://d-plus.connpass.com/event/352404/
での登壇資料です
KAKEHASHI
PRO
May 08, 2025
Tweet
Share
More Decks by KAKEHASHI
See All by KAKEHASHI
ユーザー課題を愛し抜く――AI時代のPdM価値
kakehashi
PRO
1
130
「AIと一緒にやる」が当たり前になるまでの奮闘記
kakehashi
PRO
3
170
みんなのSRE 〜チーム全員でのSRE活動にするための4つの取り組み〜
kakehashi
PRO
2
170
医療系のプロダクト開発における生産性向上と高信頼性を両立させる生成AI活用
kakehashi
PRO
1
110
完璧を目指さない小さく始める信頼性向上
kakehashi
PRO
0
210
ユーザー理解の爆速化とPdMの価値
kakehashi
PRO
1
170
スプリントゴール未達症候群に送る処方箋
kakehashi
PRO
2
740
安定した基盤システムのためのライブラリ選定
kakehashi
PRO
3
230
"SaaS is Dead" は本当か!? 生成AI時代の医療 Vertical SaaS のリアル
kakehashi
PRO
4
990
Other Decks in Technology
See All in Technology
夏休みWebアプリパフォーマンス相談室/web-app-performance-on-radio
hachi_eiji
0
260
【OptimizationNight】数理最適化のラストワンマイルとしてのUIUX
brainpadpr
2
540
Infrastructure as Prompt実装記 〜Bedrock AgentCoreで作る自然言語インフラエージェント〜
yusukeshimizu
1
160
Rethinking Incident Response: Context-Aware AI in Practice - Incident Buddy Edition -
rrreeeyyy
0
110
Lambda management with ecspresso and Terraform
ijin
2
170
九州の人に知ってもらいたいGISスポット / gis spot in kyushu 2025
sakaik
0
190
プロジェクトマネジメントは不確実性との対話だ
hisashiwatanabe
0
130
LLM 機能を支える Langfuse / ClickHouse のサーバレス化
yuu26
9
2.6k
「Roblox」の開発環境とその効率化 ~DAU9700万人超の巨大プラットフォームの開発 事始め~
keitatanji
0
140
MySQL HeatWave:サービス概要のご紹介
oracle4engineer
PRO
2
1.6k
Claude Codeから我々が学ぶべきこと
oikon48
10
2.8k
Intro to Software Startups: Spring 2025
arnabdotorg
0
270
Featured
See All Featured
Bash Introduction
62gerente
614
210k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.4k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
8
880
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
9
770
Fireside Chat
paigeccino
39
3.6k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Docker and Python
trallard
45
3.5k
Facilitating Awesome Meetings
lara
55
6.5k
Adopting Sorbet at Scale
ufuk
77
9.5k
A better future with KSS
kneath
239
17k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Fantastic passwords and where to find them - at NoRuKo
philnash
51
3.4k
Transcript
©KAKEHASHI inc. やっぱり余白が大切だった話 2025年5月8日 松本 明紘 D-Plus トウキョウ1周年大感謝祭 続
©KAKEHASHI inc. 株式会社 カケハシ(2023年2月〜) • AI在庫管理、医薬品のSCM関連の新規事業 • バックエンドに軸足を置くテックリード もっち(X: @mottyzzz)
松本 明紘 2 自己紹介 https://speakerdeck.com/kakehashi
©KAKEHASHI inc. 前回のお話の 簡単なふりかえり
©KAKEHASHI inc. 4 前回のふりかえり
©KAKEHASHI inc. 5 個人の自主的な取り組みによって、 チーム全体の柔軟さや変化への強さを 向上させたい!
©KAKEHASHI inc. 6 2つの余白によるアプローチ 計画外の小さな余白を上手に使えるようにする 余白② 計画的なチームの余白を作る 余白①
©KAKEHASHI inc. 7 ①計画的にチームの余白を作る スプリントごとに、あとでカイゼンする余白を作る
©KAKEHASHI inc. 8 ①計画的にチームの余白を作る 下記のようなワーキングアグリーメントで実際に取り組んでいる • 1週間スプリントの5日目はロードマップの開発は行わない • プランニング時点で1週間の最初の3日で完了するくらいの 余裕をもった計画にする
• 想定より早くそのスプリントの開発が完了しとしても、 次の開発項目を始めない
©KAKEHASHI inc. 発表後にいただいた声
©KAKEHASHI inc. 忙しいと、余白を作ろうとしても 他のものをやってくれという フォースがあり難しい
©KAKEHASHI inc. 優秀なチームじゃないと 難しそう
©KAKEHASHI inc. 怖い (開発が遅延しそうで)
©KAKEHASHI inc. 木こりのジレンマ 13 ある日の朝、旅人は山の中を歩いていました。 奥深い森の中、汗を流しながら一生懸命に木を伐っているきこりを見かけました。 そして夕方、同じ道を戻ってみると・・・、朝と同じ場所で、玉の汗をかきながら一生懸 命木を伐り続けているきこりがいました。 でも、あんまり作業は進んでいないようでした。 旅人は足を止めてよくよく見ると、きこりが使っている斧の刃は、ボロボロでした。
そこで、きこりに声をかけました。 旅人:「きこりさん、精がでますなぁ。でもあんまり作業は進んでないみたいですね、一 旦手を止めて、斧の刃を研いだらどうですか?」 きこり:「旅人さんよ、なに言ってるんだよ、刃を研ぐ時間なんておいらには無いんだ よ、木を伐るのが忙しくてさ・・・。」 “ http://www.keieicoach.jp/news/418/ 引用: と 生産性向上には余白が必要 のジレンマ 忙しいので余白なんか取れない
©KAKEHASHI inc. 余白があったらいいよね ではなく 余白は必須
©KAKEHASHI inc. やっぱり余白が大切だった話 2025年5月8日 松本 明紘 D-Plus トウキョウ1周年大感謝祭 続
©KAKEHASHI inc. 余白があったらいいよねではなく、余白は必須 • 事業やプロダクトの成長によりシステムが大きくなるにしたがって、 見えづらい活動が増えていく(既存仕様・コードの理解、運用、保守、障害対応) • 不確実性の高い課題に対してスパイク(調査・検証タスク)を設けて、無理に開発 を進めず、理解にも十分に時間を使うことで手戻りや品質問題を防ぐ •
ソースコード改善や開発プロセスの改善、運用の自動化などに時間を確保できな いと、組織やチームとしての成長が止まってしまう 16 適切に設けられた余白は スクラムチームの安定と持続性と向上させる
©KAKEHASHI inc. • 中規模以上の開発テーマは開発ロードマップ(全体マップ)を作成し、変化を前 提に開発ロードマップを使ってゆるいプロジェクトマネジメントを行う • 開発ロードマップを使い、コミュニケーションを高頻度に、内容の確認や仮説含 めた提案を行う。その中で、ターゲット、見積もり、コミットメントを区別しなが ら優先度を決めて計画を立てる •
このときに、不確実性(事業的側面、技術的側面の両方を含む)が高いアイテム ほど優先度を上げる • ターゲットの達成をゴールにしながら、開発者目線で必要なアイテムも並べて優 先度を決める。ターゲットの達成のために何が後回しになったかを明確にして おく • スクラムイベントで開発ロードマップを見ながら状況や優先度の変化、進捗をそ の場で更新しながら認識合わせをすることでロールをまたがった情報対称性を 高める 本日話すこと 余白を上手にコントロールできるチームになるために実践していること 17
©KAKEHASHI inc. 木こりのジレンマ 18 ある日の朝、旅人は山の中を歩いていました。 奥深い森の中、汗を流しながら一生懸命に木を伐っているきこりを見かけました。 そして夕方、同じ道を戻ってみると・・・、朝と同じ場所で、玉の汗をかきながら一生懸 命木を伐り続けているきこりがいました。 でも、あんまり作業は進んでいないようでした。 旅人は足を止めてよくよく見ると、きこりが使っている斧の刃は、ボロボロでした。
そこで、きこりに声をかけました。 旅人:「きこりさん、精がでますなぁ。でもあんまり作業は進んでないみたいですね、一 旦手を止めて、斧の刃を研いだらどうですか?」 きこり:「旅人さんよ、なに言ってるんだよ、刃を研ぐ時間なんておいらには無いんだ よ、木を伐るのが忙しくてさ・・・。」 “ http://www.keieicoach.jp/news/418/ 引用: と 生産性向上には余白が必要 のジレンマ 忙しいので余白なんか取れない
©KAKEHASHI inc. プロジェクトマネジメントを 特定の誰かに押し付けていませんか?
©KAKEHASHI inc. こんなことありませんか?(1/4) 20 機能Zの開発、 どのくらいかかりそうか教えて ラフな見積もりですが 機能Zの開発には2週間くらいかかりそうです 了解、ありがとう!じゃあそのまま進めてください (ステークホルダーにも伝えとこう)
©KAKEHASHI inc. こんなことありませんか?(2/4) 21 そろそろ2週間だよね? リリースどうなってる? 今週で終わると思っていましたが、 もう少しかかりそうです そして2週間後… え、それなら、早めにできないって
言ってくれればよかったのに。 顧客にも約束しているので遅れるとまずいですよ。
©KAKEHASHI inc. こんなことありませんか?(3/4) 22 つぎの機能Yの開発、どのくらいでできそう? (2週間くらいでできると展示会に間に合って嬉しい んだけど) (実際には2週間くらいだと思うけど、 また怒られたくないから) ちょっと難しいところがあるので
1ヶ月くらいかかると思います。 分かりました、ありがとうございます (結構かかるな… この前の機能と似たような感じなのにな)
©KAKEHASHI inc. こんなことありませんか?(4/4) 23 (余裕ある感じするし、まずは軽くやっていくか) そして2週間後… (ずっと順調そうだったのに結局ギリギリまでかかった な。本当に1ヶ月必要だったのかな) (ちょうど半分くらいだし今のペースでちょうどだよな。 ちょっと仕様が曖昧なところあるけど、来週でいいか)
さらに1週間後… (うわ、テストまだ残ってた。 まぁあと2日くらいで終わらせよう)
©KAKEHASHI inc. ターゲット、見積もり、 コミットメント、計画が 混在している状態での コミュニケーションになっている
©KAKEHASHI inc. ターゲット、見積もり、コミットメント、計画 25 本来の意味 よくある誤認 誤認による悪影響 見積もり • 実装に必要な作業量や期
間の予測 • 幅があることが多い • 分析的・仮説的であるべき もの • 勝手にコミットメントに される • 勝手に計画にされる • 正確なもの、精度が高い ほど良い • 余裕がなくなる • 遅れると「失敗」と見なされる不安 から過剰バッファを取るようにな る ターゲット • 事業上の理由から達成し たい希望的な期日やス コープの目標 • すでにコミットメントさ れた必達命令 • 実現性があるもの • 現実的な調整や健全な遅延が許さ れなくなる • どうすればゴールに近づけるか? という工夫・調整がなくなり、事業 上の効果の最大化ができなくなる コミットメ ント • チームが達成を約束した 期日やスコープ • 納期 • 絶対に調整が不可能な もの • やらされ感やモチベーション低下、 心理的安全性の低下 計画 • 見積もり、ターゲット、コ ミットメントから立てた現 実的に実行可能な道筋 • 守るべき進行表 • リスク対応ができない • 柔軟な判断や学習が止まる • 形骸化した「予定表」になる
©KAKEHASHI inc. こんなことありませんか?(1/4) 26 機能Zの開発、 どのくらいかかりそうか教えて ラフな見積もりですが 機能Zの開発には2週間くらいかかりそうです 了解、ありがとう!じゃあそのまま進めてください (ステークホルダーにも伝えとこう)
本当は計画 が知りたい 見積もり 計画だと認識、そ して勝手なコミッ トメント
©KAKEHASHI inc. こんなことありませんか?(2/4) 27 そろそろ2週間だよね? リリースどうなってる? 今週で終わると思っていましたが、 もう少しかかりそうです そして2週間後… え、それなら、早めにできないって
言ってくれればよかったのに。 顧客にも約束しているので遅れるとまずいですよ。 計画だと 思っている これも 見積もり ラフな見積もりのまま 開発スタートし、ゆるい 開発だと思っていたの で、不信感 計画だと思ってコ ミットメントまでし た、不信感
©KAKEHASHI inc. (実際には2週間くらいだと思うけど、 また怒られたくないから) ちょっと難しいところがあるので 1ヶ月くらいかかると思います。 分かりました、ありがとうございます (結構かかるな… この前の機能と似たような感じなのにな) こんなことありませんか?(3/4)
28 つぎの機能Yの開発、どのくらいでできそう? (2週間くらいでできると展示会に間に合って嬉しい んだけど) 今度は見積もりのつもり (暗黙的なターゲットの 存在) 不健全な 見積もり サボっているよう に感じて不信感 前回と同じこ とになるだろ う不信感
©KAKEHASHI inc. こんなことありませんか?(4/4) 29 (余裕ある感じするし、まずは軽くやっていくか) そして2週間後… (ずっと順調そうだったのに結局ギリギリまでかかった な。本当に1ヶ月必要だったのかな) (ちょうど半分くらいだし今のペースでちょうどだよな。 ちょっと仕様が曖昧なところあるけど、来週でいいか)
さらに1週間後… (うわ、テストまだ残ってた。 まぁあと2日くらいで終わらせよう) 本来得られた事業 上の価値の最大 化のチャンスを逃 してしまう 余裕があると「まだ大 丈夫」と思い、緊張感 が失われてダラダラ 進む
©KAKEHASHI inc. プロジェクトマネジメントを 特定の誰かに押し付けていませんか?
©KAKEHASHI inc. 誰がやるべきとかではない 全員でやる ※AI在庫管理の開発チームではPjMロールはいない
©KAKEHASHI inc. 開発ロードマップ(全体マップ) 32 https://kakehashi-dev.hatenablog.com/entry/2024/09/09/110000 AI在庫管理のチームでは、中規模な開発テーマに対しては、 PdM、エンジニアなどチーム全員で開発ロードマップ(全体マップ)を作っている 全体マップ自体の説明はこちら: 機能1 機能2
機能3
©KAKEHASHI inc. 開発ロードマップを一緒に作りながらコミュニケーション(1/3) 33 このステークホルダーに対して 機能1、機能2、機能3を 段階的に12月までにリリースしたいです ちょっと全部を12月は難しそうですね… この順番でリリースしたい理由はありますか? 本当は機能3を先に出して効果検証したいんだけど、
機能1と機能2はその前提になる気がして 確かに前提になる部分ありそうですね。 ただ機能1と機能2の共通部分だけ先に開発して、 機能3だけミニマムで使える状態にはできそうな気 がします 本当のターゲッ トのスコープ 見積もりと ターゲットの確認 ターゲットの 説明
©KAKEHASHI inc. 開発ロードマップを一緒に作りながらコミュニケーション(2/3) 34 全部を100%スコープだと機能3のリリースが2 月くらいまでかかりそうですけど、機能3の効果 検証できるミニマムな範囲であれば10月くらい にはできる気がします その進め方で不確実性がありそうところはあります か?
機能1と機能2に想定外の事情の変化があった場 合、一気に100%スコープを開発するよりも、 トータルの時間がかかることになると思います。 機能3の結果によって、他の機能の優先度上げたくな る可能性もあるので、その方針で詳細の見積もりをお 願いします。 見積もり 見積もりの 幅の確認 見積もりの 幅 計画につな がる
©KAKEHASHI inc. 開発ロードマップを一緒に作りながらコミュニケーション(3/3) 35 設計した結果、パフォーマンス問題が発生する可 能性がありそうです。 10月にはできそうと話していましたが、性能検 証を先にしたいです。もともと12月という話も あったので多少の余裕はあるかなと思っていま すが大丈夫ですか?
もちろん早めが嬉しいですが、重要なステークホル ダーなので、できるだけ事前に懸念も減らしましょう ありがとうございます。 現時点では10月目標で進めますが、何か問題を 発見した場合はまた相談させてください。 ターゲットを考 慮した計画変 更の提案 ターゲットの 追加情報 確率的な コミットメント
©KAKEHASHI inc. 事業的側面、技術的側面の両面から 最適な選択肢がとれる
©KAKEHASHI inc. 情報対称性が高まり 信頼関係の構築にもつながる
©KAKEHASHI inc. こういったコミュニケーションの結果 チームの最適な開発スタイル ができあがっていった
©KAKEHASHI inc. コミュニケーションの結果できた現在の余白のスタイル 39
©KAKEHASHI inc. 最初から全部はできない
©KAKEHASHI inc. やらないとできるようには ならない
©KAKEHASHI inc. チームの信頼と文化を作っていくために 練習しよう。訓練しよう。
©KAKEHASHI inc. やっぱり余白が大切だった話 2025年5月8日 松本 明紘 D-Plus トウキョウ1周年大感謝祭 続