仕様は“書く”より“語る” - 分断を超えたチーム開発の実践 / 20251115 Naoki Takahashi

2025/11/15 JJUG CCC 2025 Fall
https://sessionize.com/jjug-ccc-2025-fall/

株式会社SHIFT
製造ソリューションサービス部
髙橋 直規

Transcript

1. 仕様は“書く”より“語る” - 分断を超えたチーム開発の実践 #jjug_ccc 髙橋直規 株式会社SHIFT 2025.11.15 JJUG CCC 2025 Fall Copyright SHIFT Inc, All Rights Reserved.
2. 自己紹介 髙橋直規 / 幡ヶ谷亭直吉 x:@asagayanaoki 出身：神奈川 / 居住：東京 エンジニア歴：18年8か月 役割：PjM、PdE 好きな言語：Java 好きな主義：経験主義 好きな思考：プロダクト思考／好きな指向：オブジェクト指向 趣味：アナログレコード 土日の過ごし方：6歳の娘ととにかく遊ぶ
3. 本日お話すること https://sessionize.com/s/zhi-gui-gao-qiao/shi-yang-hashu-kuyoriyu-ru-fen-duan-wochao-etachim/144660
4. 本日お話すること • ドキュメント主導の分業体制がもたらした限界 • 体制の見直しによるチームの設計・仕様検討の課題 • 「語る」ことによる設計文化の醸成と学び
5. アジェンダ • STEP0：導入 • STEP1：チーム分断と仕様の属人化 • STEP2：仕様検討を移管しても残る属人性 • STEP3：チームで仕様を育てる文化への転換 • まとめ
6. STEP0：導入
7. 2023.8 2024.10 2025.4 現在 0→1: 初回リリース 1→継続開発フェーズ ウォーターフォール（工程ごとにスクラム適用） 適応型開発（スクラム） 受託側PjM/POアシスタント/スクラムマスター 受託側PjM/Dev • プロダクト • プロセス • 私の役割 この話はどんな開発現場の話か 新しく集まったメンバーでフルリモートのなか始まってプロダクト開発。 暗黙知が共有されにくい環境からのスタート。 STEP0：導入 受託側PjM/QA支援
8. STEP1： チーム分断と仕様の属人化
9. 新規プロダクトの立ち上げ、すべてが“はじめて”だった ・新規プロダクト開発プロジェクト ・ほぼ全員が初対面でのフルリモート開発 2023.8 2024.10 0→1: 初回リリース 1→継続開発フェーズ 2025.4 現在 ウォーターフォール（工程ごとにスクラム適用） 適応型開発（スクラム） 受託側PjM/POアシスタント/スクラムマスター 受託側PjM/QA支援 受託側PjM/Dev • プロダクト • プロセス • 私の役割 STEP1：チーム分断と仕様の属人化
10. 要件定義 基本設計 詳細設計 実装・UT 結合テスト 総合テスト UAT 設計1週間スプリント 実装～結合2週間スプリント STEP1：チーム分断と仕様の属人化 工程ごとにスクラムが適用されたウォーターフォール開発
11. プロジェクトが進む中、 要件変更やメンバーの経験不足などによって設計工程が遅延。 実装メンバーの参画時期も決まっていたため、 次の工程を進めることが求められていた。 STEP1：チーム分断と仕様の属人化 基本設計 詳細設計 実装・UT 結合テスト
12. 基本設計 詳細設計 実装・UT 結合テスト ファストトラッキング （※）で進めましょう STEP1：チーム分断と仕様の属人化 ※工程を並行して進めて、納期を早める手法 実装メンバーの参画タイミングは変えられないため、 設計チームと開発チームを分離することで、 設計チームが残る設計を引き続き担当し、 出来上がっている設計書をもとに開発チームが実装を先行開始。
13. 設計がある程度片付いた段階で設計メンバーは開発チームに合流。 仕様変更などは開発チームで実施想定だったが、 機能実装に追われる開発チームに仕様検討をプロセスに含める余裕がなく、 結局は終盤まで仕様検討が属人化する状態に。 基本設計 詳細設計 STEP1：チーム分断と仕様の属人化 実装・UT 結合テスト
14. STEP1：チーム分断と仕様の属人化 ▪チームの分断により仕様検討は属人化した チームの分断は、機能をはやく作りあげていくという要求もあり、 無意識に「考える人、作業する人」の関係を生んでいた。 つくる人たちに考えるためのプロセスが共有されず、 結果的にものを作り続けるサイクルのなかで、 仕様検討という考えるためのプロセスを含めることができなかった。
15. ▪仕様検討の属人化がもたらした問題 仕様を記載したドキュメントは短期的な成果や納品物としての役割は果たせた。 ただし、チームの仕様に対する学習には役立たなかった。 なにより、開発者が実装を進める上での仕様書としても不十分だった。 STEP1：チーム分断と仕様の属人化 実は設計書読んでも よくわかんないんですよね～ API設計書 検索対象： 〇〇テーブル 検索条件： 〇〇.xxカラム = APIのパラメータ ※実装者は物理名を気にする
16. STEP1まとめ チーム分割で短期成果は出た 受け渡しのドキュメントでは仕様は伝わりきらない チームで”考える場”が要る STEP1：チーム分断と仕様の属人化
17. STEP2： 仕様検討を移管しても残る属人性
18. STEP2：仕様検討を移管しても残る属人性 2023.8 2024.10 0→1: 初回リリース 1→継続開発フェーズ 2025.4 現在 ウォーターフォール（工程ごとにスクラム適用） 適応型開発（スクラム） 受託側PjM/POアシスタント/スクラムマスター 受託側PjM/Dev プロダクト プロセス 私の役割 初回リリース後、開発の進め方を抜本的に見直す必要があった。 ・プロダクト成長を持続可能にするために役割でのチーム制を廃止 ・開発チームをすべての工程を扱うチームに 受託側PjM/QA支援
19. STEP2：仕様検討を移管しても残る属人性 チームを分断することでの依存性を無くすために、 開発チームで設計を行うことになった。 基本、スクラムでは1スプリント内で価値ある成果を届けることを目指す。 ただ、それまで開発チームでは実装中心にプロセスを進めていたため、 要件定義や設計をどうプロセスに取り入れるかが安定しなかった。 要件定義～リリース
20. STEP2：仕様検討を移管しても残る属人性 複雑な要求事項に対しては、 1スプリント内で設計からリリースまで完結させることが難しかった。 そのため、そうした複雑な要求に対しては前スプリントで仕様検討を行い、 次スプリントで開発に着手するプロセスを採用した。 開発～リリース 要件定義～設計
21. STEP2：仕様検討を移管しても残る属人性 ▪仕様検討を特別なタスクとすることでまたしても属人化が生まれた 仕様検討をする人間は固定しない想定だったが、得意な人間に偏っていった。 結局はチームとして仕様を考えることができない状況を生んだ。
22. STEP2：仕様検討を移管しても残る属人性 ▪仕様検討の属人化がもたらした問題 複数機能が連携するシステム仕様の整合性について、 考えた人しか妥当性が分からない状態に。 仕様の精度や責任の所在をチームで扱えず、 仕様を考えた人しか理解していない状態が続いた。 ここの仕様は あの人に聞けばわかるはず 設計書 A機能： 〇〇〇〇〇〇〇〇 B機能： △△△△△△△△ C機能： □□□□□□□□ ※実装者は実装機能を気にする
23. STEP2まとめ チーム体制の見直しだけでは属人性は解けなかった 役割を設ければ仕様の属人性は形を変えて残る だからチームで仕様を“語る場”が要る STEP2：仕様検討を移管しても残る属人性
24. STEP3： チームで仕様を育てる文化 への転換
25. チームで仕様を検討できる状態にするための試行錯誤が進んだ。 2023.8 2024.8 0→1: 初回リリース 1→継続開発フェーズ 2025.4 現在 ウォーターフォール（工程ごとにスクラム適用） 適応型開発（スクラム） 受託側PjM/POアシスタント/スクラムマスター • プロダクト • プロセス • 私の役割 STEP3：チームで仕様を育てる文化への転換 受託側PjM/QA支援 受託側PjM/Dev
26. 4つの施策をもとにチームで仕様を育てる文化への転換を実現。 2024.8 STEP3：チームで仕様を育てる文化への転換 2025.2 2025.5 機能開発直後の仕様共有会の開催 事前設計ディスカッションと同期作業 リリース前にプロダクトをさわる会の開催 現在 リファインメントとプランニングの活用
27. STEP3：チームで仕様を育てる文化への転換 2024.8 2025.2 2025.5 機能開発直後の仕様共有会の開催 事前設計ディスカッションと同期作業 リリース前にプロダクトをさわる会の開催 現在 リファインメントとプランニングの活用 リリース前にプロダクトをさわる会の開催 プロダクトの品質向上のため、役割を問わずチームメンバーが集合して、 指定時間内に意図的に不具合を見つけ出すバグバッシュを開催。
28. STEP3：チームで仕様を育てる文化への転換 ▪目的 ✓リリースに向けて不具合を洗いきるためのイベント ▪やり方 ✓スプリントレビューの際に、全員がリリース対象となる機能を コミュニケーションを取りながらアドホックに触っていく ▪得られた価値 ✓役割に捉われないコミュニケーションにより仕様のズレや考慮漏れが可視化 ✓全員にプロダクトの品質に対する当事者意識が醸成 ▪残った課題 ✓実施タイミングがリリース直前のため何か問題があった場合に対処が遅れる
29. リファインメントとプランニングの活用 仕様検討の属人性を無くすことと、機能実現に当たる考慮漏れを無くすために リファインメントとプランニングを意識的に活用。 2024.8 STEP3：チームで仕様を育てる文化への転換 2025.2 2025.5 機能開発直後の仕様共有会の開催 事前設計ディスカッションと同期作業 リファインメントとプランニングの活用 現在 リリース前にプロダクトをさわる会の開催
30. STEP3：チームで仕様を育てる文化への転換 ▪目的 ✓チームで仕様検討ができる状態の実現（STEP2の状態への対策） ✓機能実現前に仕様考慮漏れを無くす ▪やり方 ✓リファインメントでは、POも含め“何を作るか”をチームで語って合意 ✓プランニングでは、開発メンバーで“どう作るか”を語って合意 ▪得られた価値 ✓誰かに属人化せずチームで機能仕様を検討できる状態に ▪残った課題 ✓基本設計レベルまではチームで考えることができる状態を作れたが、 スプリント内で検討する詳細設計～実装レベルでは属人性が残った。
31. 機能開発直後の仕様共有会の開催 各メンバーが担当機能の開発を終えた段階で、 その機能の仕様や実装内容を共有するミーティングを開催。 2024.8 STEP3：チームで仕様を育てる文化への転換 2025.2 2025.5 機能開発直後の仕様共有会の開催 事前設計ディスカッションと同期作業 現在 リリース前にプロダクトをさわる会の開催 リファインメントとプランニングの活用
32. STEP3：チームで仕様を育てる文化への転換 ▪目的 ✓機能仕様だけでなく実装をチームで共有しコードレベルでの共通理解を醸成 ▪やり方 ✓開発完了翌日に機能のデモやコードレベルでの仕組みを説明する会を開催 ✓メンバー間での質疑応答も実施 ▪得られた価値 ✓実装時の判断の背景が可視化され、コードレベルの知識がチームに伝播 ✓「説明する仕組み」により、機能仕様への当事者意識と責任が全員に拡張 ▪残った課題 ✓複雑な機能では細部の解釈のズレは発生し得るため、 リアルタイムでの解消の仕組みが必要
33. 事前設計ディスカッションと同期作業 プランニングで決めきれなかった細かい仕様は、実装開始前にチームで議論。 複雑な機能は複数人であたり、随時仕様を検討・調整できる状態に。 2024.8 STEP3：チームで仕様を育てる文化への転換 2025.2 2025.5 機能開発直後の仕様共有会の開催 事前設計ディスカッションと同期作業 リファインメントとプランニングの活用 リリース前にプロダクトをさわる会の開催 現在
34. STEP3：チームで仕様を育てる文化への転換 ▪目的 ✓プランニングで決め切れない細かい仕様をチームで検討する ✓実装中の仕様すり合わせをリアルタイムに行う ▪やり方 ✓プランニング時に対応が必要な機能についてチームで合意し、議論 ✓スプリント中はハドルなどで随時会話できる状態を実現して開発 ▪得られた価値 ✓細かな実装方針も属人化せず、チームで検討・合意できる状態を実現 ✓解釈ズレの即時解消により手戻りが減少 ▪残った課題 ✓後続で紹介
35. 4つの施策をもとにチームで仕様を育てる文化への転換を実現。 2024.8 STEP3：チームで仕様を育てる文化への転換 2025.2 2025.5 機能開発直後の仕様共有会の開催 事前設計ディスカッションと同期作業 リリース前にプロダクトをさわる会の開催 現在 リファインメントとプランニングの活用
36. STEP3：チームで仕様を育てる文化への転換 スプリント内で4つの施策を実施できる状態を作り、 チームで仕様を考える文化が根づいた。 仕様を語ることで、チームの意識とプロダクト理解を育てた。 リファインメントと プランニングの活用 事前設計ディスカッションと 同期作業 機能開発後の 仕様共有会の開催 リリース前に プロダクトをさわる会の開催
37. STEP3：チームで仕様を育てる文化への転換 ▪残る課題 語ることが重要であっても、ドキュメント自体の価値が無いわけではない。 将来のメンバーや第三者にも理解できるように、 どのように仕様の記録を残していくかの検討が必要。 ▪今後 今の課題はチームで仕様を考えられるようになったからこそ、 見えるようになった課題。 これからもチームの成長を通じてそれらを解決し、 プロダクトの持続的な成長へつなげていく。
38. STEP3まとめ チームの対話がプロダクトを育てる 属人性は「チームで考える」仕組みで解ける 「語る」ことでプロダクト開発は協働行為になる STEP3：チームで仕様を育てる文化への転換
39. まとめ
40. まとめ チーム分割は、チームの仕様検討力を阻害していた。（STEP1） 役割が固定化されると、理解は属人化する。（STEP2） チームで語り、合意を育てる文化が自己組織化を支える。（STEP3） 設計を「書く」から「語る」へ。 プロダクトの成長をチームで考え、実現し続けられる状態を作ることが、 長期的なプロダクト開発にとって大切なことだった。