Upgrade to PRO for Only $50/Year—Limited-Time Offer! 🔥
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
そのプロダクトは誰のもの?
Search
おぎ
October 04, 2025
1
43
そのプロダクトは誰のもの?
スクラム祭り2025 島根トラックでの発表に使った資料を加筆修正したものです。
※一部表現や内容はコンテキストを共有できていない人に誤解されることを防ぐため変更してあります
おぎ
October 04, 2025
Tweet
Share
More Decks by おぎ
See All by おぎ
「10分以内に機能を消せる状態」 の実現のためにやっていること
togishima
1
630
インターフェース設計のコツとツボ
togishima
2
1.1k
100行で書けるPSR-11
togishima
0
660
ITなんもわからん素人がアジャイルと出会うまで
togishima
1
100
とあるWebエンジニアの生成AI活用事例
togishima
0
140
設計、Interface
togishima
0
96
実践、Interface
togishima
1
2.1k
PHPerを続ける理由
togishima
0
110
闇のPHPからの防衛術
togishima
0
310
Featured
See All Featured
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
141
34k
Conquering PDFs: document understanding beyond plain text
inesmontani
PRO
4
2.1k
Bootstrapping a Software Product
garrettdimon
PRO
307
120k
Organizational Design Perspectives: An Ontology of Organizational Design Elements
kimpetersen
PRO
0
42
The Illustrated Children's Guide to Kubernetes
chrisshort
51
51k
Paper Plane
katiecoart
PRO
0
44k
Marketing to machines
jonoalderson
1
4.3k
Mind Mapping
helmedeiros
PRO
0
38
The SEO identity crisis: Don't let AI make you average
varn
0
35
Accessibility Awareness
sabderemane
0
23
GitHub's CSS Performance
jonrohan
1032
470k
Site-Speed That Sticks
csswizardry
13
1k
Transcript
そのプロダクトは誰のもの? 〜 停滞していた開発チームがオーナーシップを取り戻し、爆速 で価値提供を実現するまでの軌跡 〜
自己紹介 名前:荻島 貴(Ogishima Takashi) 職業:開発者(PHPer) 特技:スノーボード 好きなこと:内省とカイゼン スクラム系カンファレンス初登壇
あるプロジェクト参画時に感じた「違和感」
何かがおかしそうな気配は感じるけど 言語化ができない…
まずは2スプリントほど観察してみることに
チームは機能不全を起こしていた • スキップされるスプリントレビュー • 形だけで具体的なアクションを伴わないふりかえり • リリース日以外のマイルストーンの存在しないスケジュール • 遅れていることは認知しつつ、何も言わないチームメンバー •
具体的な対策を打ち出せないリーダー
テコ入れするぞ
約1ヶ月で試したこと • 隔週→1週間スプリントに移行、試行回数を増やす • TDD導入と週次での勉強会主催 • モブ・ペア作業の機会を増やす • 相対見積もりの導入 •
アクティビティをダッシュボード化し、リードタイム計測 • チームのふりかえりを通してケイパビリティの検査
結果: 1ヶ月では解決に至らず...
直線思考の限界 “私たちは「目に見えるできごと」だけに注 目し、「問題の原因と結果はすぐ近くにある と無意識のうちに思い込み、問題の近くに 解決策を探そうとする」傾向があります”
分かった2つの事実
①『現状のペースだと想定の2.5倍かかる』 ②『チーム内に必要な能力が足りない』
希望とマネジメント “どれだけうまくいっていないか をで きるだけ早く知ることだ。 できるだけ早く知りたいのはそうす れば状況をマネジメントできる から だ。” 〜Robert C.
Martin〜
「うまくいかないこと」がわかった
検査はできたので 適応していきましょう
プロジェクトの立て直しへ • マネージャーへエスカレーション ◦ 能力が不足していることを通知、支援を要請 • プロジェクト体制変更 ◦ PO追加 ◦
追加人員(エース級の投入) ◦ 臨時でリード交代
しかし状況は芳しくなかった • スコープは当初の想定よりも大幅に大きいことが判明 • チームを支援していたテックリードが不在に • 増員メンバーが揃った時点でPJ期間の半分以上経過 • 当初のデッドラインを守るのは現実的に不可能 •
しかし想定の2.5倍という期間は事業上許容できない
それでもやることは変わらない
検査と適応
脱サバイバルモードへ ①時間を作る - 現実的な計画の再構築 - 「デリバリー速度」への最適化 ②学習する - UI/UXレベルからの再設計 -
希望ではなく現実ベースでの判断
チーム主体での意思決定へ • 業務要求を整理し、要件を再定義 • デザインを情報設計レベルからやり直し • 途中まで作ったUIを全削除 • 再定義した要件を元に再見積もり •
見積もりを元にスケジュール引き直し、スコープ調整
「誰かが考えた仕様」ではなく 「自分たちで決めた仕様」で作る
結果としてスクラムになっていた • 現状の進みを元に週次で計画の見直し (≒スプリントプランニング) • 週次で動くプロダクトを囲んで確認 (≒スプリントレビュー) • 現状を把握した上で次週までにどう改善するか話す (≒スプリントレトロスペクティブ)
• タスクを日次レベルに分解し、毎日の朝会で確認 (≒デイリースクラム)
透明性が確保され、サイクルが回り始めた • 「動くもの」があることで進捗が可視化され、課題が明確に • 月次→隔週→週次で動くものを出せるように • ベロシティから相対的に考えることで現実的な見通しが立った チームに主体性が戻ってきた!
〜再出発から数ケ月〜
🎉 無事リリース 🎉
リリースした結果 想定以上の反響があった! ≒ ユーザーに価値が届いたということでは?
チームを妨げていたものは何だったのか?
欠けていたのは一人一人の「オーナーシップ」 • 仕様を決めてくれない? → チームで決める • 設計通りに作ればいい? → 変更はある前提 •
見通しが立てられない? → 現状から相対的に見積もる • 開発者なら関係ない? → チームの遅れはチームの責任 • 能力が足りない? → 必要なものは獲得しに行く
Q.自分たちがやっていいのか?
A. 自分たちにしかできない
今回特に大事だと感じた価値観...
勇気!
スクラムとXP スクラム:価値基準 • 確約 • 集中 • 公開 • 尊敬
• 勇気 XP:5つの価値 • コミュニケーション • シンプル • フィードバック • 勇気 • 尊敬
あなたが一歩を踏み出せば 何かが変わるかも…?
ご清聴ありがとうございました👏