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

by SHIFT EVOLVE

Embed

Start on current slide

Slide 1

Slide 1 text

Slide 2

Slide 2 text

自己紹介髙橋直規 / 幡ヶ谷亭直吉 x:@asagayanaoki 出身：神奈川 / 居住：東京エンジニア歴：18年8か月役割：PjM、PdE 好きな言語：Java 好きな主義：経験主義好きな思考：プロダクト思考／好きな指向：オブジェクト指向趣味：アナログレコード土日の過ごし方：6歳の娘ととにかく遊ぶ

Slide 3

Slide 3 text

本日お話すること https://sessionize.com/s/zhi-gui-gao-qiao/shi-yang-hashu-kuyoriyu-ru-fen-duan-wochao-etachim/144660

Slide 4

Slide 4 text

本日お話すること • ドキュメント主導の分業体制がもたらした限界 • 体制の見直しによるチームの設計・仕様検討の課題 • 「語る」ことによる設計文化の醸成と学び

Slide 5

Slide 5 text

アジェンダ • STEP0：導入 • STEP1：チーム分断と仕様の属人化 • STEP2：仕様検討を移管しても残る属人性 • STEP3：チームで仕様を育てる文化への転換 • まとめ

Slide 6

Slide 6 text

STEP0：導入

Slide 7

Slide 7 text

2023.8 2024.10 2025.4 現在 0→1: 初回リリース 1→継続開発フェーズウォーターフォール（工程ごとにスクラム適用）適応型開発（スクラム）受託側PjM/POアシスタント/スクラムマスター受託側PjM/Dev • プロダクト • プロセス • 私の役割この話はどんな開発現場の話か新しく集まったメンバーでフルリモートのなか始まってプロダクト開発。暗黙知が共有されにくい環境からのスタート。 STEP0：導入受託側PjM/QA支援

Slide 8

Slide 8 text

STEP1：チーム分断と仕様の属人化

Slide 9

Slide 9 text

新規プロダクトの立ち上げ、すべてが“はじめて”だった・新規プロダクト開発プロジェクト・ほぼ全員が初対面でのフルリモート開発 2023.8 2024.10 0→1: 初回リリース 1→継続開発フェーズ 2025.4 現在ウォーターフォール（工程ごとにスクラム適用）適応型開発（スクラム）受託側PjM/POアシスタント/スクラムマスター受託側PjM/QA支援受託側PjM/Dev • プロダクト • プロセス • 私の役割 STEP1：チーム分断と仕様の属人化

Slide 10

Slide 10 text

要件定義基本設計詳細設計実装・UT 結合テスト総合テスト UAT 設計1週間スプリント実装～結合2週間スプリント STEP1：チーム分断と仕様の属人化工程ごとにスクラムが適用されたウォーターフォール開発

Slide 11

Slide 11 text

プロジェクトが進む中、要件変更やメンバーの経験不足などによって設計工程が遅延。実装メンバーの参画時期も決まっていたため、次の工程を進めることが求められていた。 STEP1：チーム分断と仕様の属人化基本設計詳細設計実装・UT 結合テスト

Slide 12

Slide 12 text

基本設計詳細設計実装・UT 結合テストファストトラッキング（※）で進めましょう STEP1：チーム分断と仕様の属人化 ※工程を並行して進めて、納期を早める手法実装メンバーの参画タイミングは変えられないため、設計チームと開発チームを分離することで、設計チームが残る設計を引き続き担当し、出来上がっている設計書をもとに開発チームが実装を先行開始。

Slide 13

Slide 13 text

設計がある程度片付いた段階で設計メンバーは開発チームに合流。仕様変更などは開発チームで実施想定だったが、機能実装に追われる開発チームに仕様検討をプロセスに含める余裕がなく、結局は終盤まで仕様検討が属人化する状態に。基本設計詳細設計 STEP1：チーム分断と仕様の属人化実装・UT 結合テスト

Slide 14

Slide 14 text

STEP1：チーム分断と仕様の属人化 ■チームの分断により仕様検討は属人化したチームの分断は、機能をはやく作りあげていくという要求もあり、無意識に「考える人、作業する人」の関係を生んでいた。つくる人たちに考えるためのプロセスが共有されず、結果的にものを作り続けるサイクルのなかで、仕様検討という考えるためのプロセスを含めることができなかった。

Slide 15

Slide 15 text

■仕様検討の属人化がもたらした問題仕様を記載したドキュメントは短期的な成果や納品物としての役割は果たせた。ただし、チームの仕様に対する学習には役立たなかった。なにより、開発者が実装を進める上での仕様書としても不十分だった。 STEP1：チーム分断と仕様の属人化実は設計書読んでもよくわかんないんですよね～ API設計書検索対象：〇〇テーブル検索条件：〇〇.xxカラム = APIのパラメータ ※実装者は物理名を気にする

Slide 16

Slide 16 text

STEP1まとめチーム分割で短期成果は出た受け渡しのドキュメントでは仕様は伝わりきらないチームで”考える場”が要る STEP1：チーム分断と仕様の属人化

Slide 17

Slide 17 text

STEP2：仕様検討を移管しても残る属人性

Slide 18

Slide 18 text

STEP2：仕様検討を移管しても残る属人性 2023.8 2024.10 0→1: 初回リリース 1→継続開発フェーズ 2025.4 現在ウォーターフォール（工程ごとにスクラム適用）適応型開発（スクラム）受託側PjM/POアシスタント/スクラムマスター受託側PjM/Dev プロダクトプロセス私の役割初回リリース後、開発の進め方を抜本的に見直す必要があった。・プロダクト成長を持続可能にするために役割でのチーム制を廃止・開発チームをすべての工程を扱うチームに受託側PjM/QA支援

Slide 19

Slide 19 text

STEP2：仕様検討を移管しても残る属人性チームを分断することでの依存性を無くすために、開発チームで設計を行うことになった。基本、スクラムでは1スプリント内で価値ある成果を届けることを目指す。ただ、それまで開発チームでは実装中心にプロセスを進めていたため、要件定義や設計をどうプロセスに取り入れるかが安定しなかった。要件定義～リリース

Slide 20

Slide 20 text

STEP2：仕様検討を移管しても残る属人性複雑な要求事項に対しては、 1スプリント内で設計からリリースまで完結させることが難しかった。そのため、そうした複雑な要求に対しては前スプリントで仕様検討を行い、次スプリントで開発に着手するプロセスを採用した。開発～リリース要件定義～設計

Slide 21

Slide 21 text

STEP2：仕様検討を移管しても残る属人性 ■仕様検討を特別なタスクとすることでまたしても属人化が生まれた仕様検討をする人間は固定しない想定だったが、得意な人間に偏っていった。結局はチームとして仕様を考えることができない状況を生んだ。

Slide 22

Slide 22 text

STEP2：仕様検討を移管しても残る属人性 ■仕様検討の属人化がもたらした問題複数機能が連携するシステム仕様の整合性について、考えた人しか妥当性が分からない状態に。仕様の精度や責任の所在をチームで扱えず、仕様を考えた人しか理解していない状態が続いた。ここの仕様はあの人に聞けばわかるはず設計書 A機能：〇〇〇〇〇〇〇〇 B機能： △△△△△△△△ C機能： □□□□□□□□ ※実装者は実装機能を気にする

Slide 23

Slide 23 text

STEP2まとめチーム体制の見直しだけでは属人性は解けなかった役割を設ければ仕様の属人性は形を変えて残るだからチームで仕様を“語る場”が要る STEP2：仕様検討を移管しても残る属人性

Slide 24

Slide 24 text

STEP3：チームで仕様を育てる文化への転換

Slide 25

Slide 25 text

チームで仕様を検討できる状態にするための試行錯誤が進んだ。 2023.8 2024.8 0→1: 初回リリース 1→継続開発フェーズ 2025.4 現在ウォーターフォール（工程ごとにスクラム適用）適応型開発（スクラム）受託側PjM/POアシスタント/スクラムマスター • プロダクト • プロセス • 私の役割 STEP3：チームで仕様を育てる文化への転換受託側PjM/QA支援受託側PjM/Dev

Slide 26

Slide 26 text

4つの施策をもとにチームで仕様を育てる文化への転換を実現。 2024.8 STEP3：チームで仕様を育てる文化への転換 2025.2 2025.5 機能開発直後の仕様共有会の開催事前設計ディスカッションと同期作業リリース前にプロダクトをさわる会の開催現在リファインメントとプランニングの活用

Slide 27

Slide 27 text

STEP3：チームで仕様を育てる文化への転換 2024.8 2025.2 2025.5 機能開発直後の仕様共有会の開催事前設計ディスカッションと同期作業リリース前にプロダクトをさわる会の開催現在リファインメントとプランニングの活用リリース前にプロダクトをさわる会の開催プロダクトの品質向上のため、役割を問わずチームメンバーが集合して、指定時間内に意図的に不具合を見つけ出すバグバッシュを開催。

Slide 28

Slide 28 text

STEP3：チームで仕様を育てる文化への転換 ■目的 ✓リリースに向けて不具合を洗いきるためのイベント ■やり方 ✓スプリントレビューの際に、全員がリリース対象となる機能をコミュニケーションを取りながらアドホックに触っていく ■得られた価値 ✓役割に捉われないコミュニケーションにより仕様のズレや考慮漏れが可視化 ✓全員にプロダクトの品質に対する当事者意識が醸成 ■残った課題 ✓実施タイミングがリリース直前のため何か問題があった場合に対処が遅れる

Slide 29

Slide 29 text

リファインメントとプランニングの活用仕様検討の属人性を無くすことと、機能実現に当たる考慮漏れを無くすためにリファインメントとプランニングを意識的に活用。 2024.8 STEP3：チームで仕様を育てる文化への転換 2025.2 2025.5 機能開発直後の仕様共有会の開催事前設計ディスカッションと同期作業リファインメントとプランニングの活用現在リリース前にプロダクトをさわる会の開催

Slide 30

Slide 30 text

STEP3：チームで仕様を育てる文化への転換 ■目的 ✓チームで仕様検討ができる状態の実現（STEP2の状態への対策） ✓機能実現前に仕様考慮漏れを無くす ■やり方 ✓リファインメントでは、POも含め“何を作るか”をチームで語って合意 ✓プランニングでは、開発メンバーで“どう作るか”を語って合意 ■得られた価値 ✓誰かに属人化せずチームで機能仕様を検討できる状態に ■残った課題 ✓基本設計レベルまではチームで考えることができる状態を作れたが、スプリント内で検討する詳細設計～実装レベルでは属人性が残った。

Slide 31

Slide 31 text

機能開発直後の仕様共有会の開催各メンバーが担当機能の開発を終えた段階で、その機能の仕様や実装内容を共有するミーティングを開催。 2024.8 STEP3：チームで仕様を育てる文化への転換 2025.2 2025.5 機能開発直後の仕様共有会の開催事前設計ディスカッションと同期作業現在リリース前にプロダクトをさわる会の開催リファインメントとプランニングの活用

Slide 32

Slide 32 text

STEP3：チームで仕様を育てる文化への転換 ■目的 ✓機能仕様だけでなく実装をチームで共有しコードレベルでの共通理解を醸成 ■やり方 ✓開発完了翌日に機能のデモやコードレベルでの仕組みを説明する会を開催 ✓メンバー間での質疑応答も実施 ■得られた価値 ✓実装時の判断の背景が可視化され、コードレベルの知識がチームに伝播 ✓「説明する仕組み」により、機能仕様への当事者意識と責任が全員に拡張 ■残った課題 ✓複雑な機能では細部の解釈のズレは発生し得るため、リアルタイムでの解消の仕組みが必要

Slide 33

Slide 33 text

事前設計ディスカッションと同期作業プランニングで決めきれなかった細かい仕様は、実装開始前にチームで議論。複雑な機能は複数人であたり、随時仕様を検討・調整できる状態に。 2024.8 STEP3：チームで仕様を育てる文化への転換 2025.2 2025.5 機能開発直後の仕様共有会の開催事前設計ディスカッションと同期作業リファインメントとプランニングの活用リリース前にプロダクトをさわる会の開催現在

Slide 34

Slide 34 text

STEP3：チームで仕様を育てる文化への転換 ■目的 ✓プランニングで決め切れない細かい仕様をチームで検討する ✓実装中の仕様すり合わせをリアルタイムに行う ■やり方 ✓プランニング時に対応が必要な機能についてチームで合意し、議論 ✓スプリント中はハドルなどで随時会話できる状態を実現して開発 ■得られた価値 ✓細かな実装方針も属人化せず、チームで検討・合意できる状態を実現 ✓解釈ズレの即時解消により手戻りが減少 ■残った課題 ✓後続で紹介

Slide 35

Slide 35 text

Slide 36

Slide 36 text

STEP3：チームで仕様を育てる文化への転換スプリント内で4つの施策を実施できる状態を作り、チームで仕様を考える文化が根づいた。仕様を語ることで、チームの意識とプロダクト理解を育てた。リファインメントとプランニングの活用事前設計ディスカッションと同期作業機能開発後の仕様共有会の開催リリース前にプロダクトをさわる会の開催

Slide 37

Slide 37 text

STEP3：チームで仕様を育てる文化への転換 ■残る課題語ることが重要であっても、ドキュメント自体の価値が無いわけではない。将来のメンバーや第三者にも理解できるように、どのように仕様の記録を残していくかの検討が必要。 ■今後今の課題はチームで仕様を考えられるようになったからこそ、見えるようになった課題。これからもチームの成長を通じてそれらを解決し、プロダクトの持続的な成長へつなげていく。

Slide 38

Slide 38 text

STEP3まとめチームの対話がプロダクトを育てる属人性は「チームで考える」仕組みで解ける「語る」ことでプロダクト開発は協働行為になる STEP3：チームで仕様を育てる文化への転換

Slide 39

Slide 39 text

まとめ

Slide 40

Slide 40 text

まとめチーム分割は、チームの仕様検討力を阻害していた。（STEP1）役割が固定化されると、理解は属人化する。（STEP2）チームで語り、合意を育てる文化が自己組織化を支える。（STEP3）設計を「書く」から「語る」へ。プロダクトの成長をチームで考え、実現し続けられる状態を作ることが、長期的なプロダクト開発にとって大切なことだった。

Slide 41

Slide 41 text

No content