2025年11月25日、日本最大級のJavaコミュニティイベント「JJUG CCC 2025 Fall」が開催され、SHIFTからは、製造ソリューションサービス部 プロジェクトマネージャーの髙橋 直規が登壇しました。
「仕様は“書く”より“語る”‐分断を超えたチーム開発の実践」というタイトルで、自身が受託側プロジェクトマネージャーを務める案件で経験した「分断」と「属人化」の実態、そしてそれを乗り越えたプロセスについて話しました。
髙橋が育てた、「チームで語り、合意を育てる文化」のステップ、自己組織化までの道のりを追いかけます。
-
製造ソリューションサービス部 髙橋 直規
エンジニアやPM、サービスマネージャー（※）として、さまざまなシステム開発案件などに携わった後、アジャイルを専門的に扱うために、3社目として2023年3月SHIFTに入社。現在は、SHIFTの「アジャイル」にまつわるさまざまな案件に入り、プロジェクトマネジメントから実務となるエンジニアリングまで、幅広い領域でアジャイルサービスの浸透／普及に従事している。
（※）業務ごとにシステムを管理し、滞りなくサービス提供ができるよう責任を担う立場。
目次
ドキュメント主導開発が生んだ分断と属人化
ドキュメントに仕様は書かれているのに、意図が伝わらない。ドキュメントは正しいのに、チームは正しく動かない。そんな経験をしたことはないでしょうか。
私が、仕様を“書く”文化から“語る”文化へ移行する必要性を痛感したのは、ある新規プロダクトの開発プロジェクトに参画したときのことです。
そのプロジェクトは、ほぼ初対面のメンバーでフルリモート環境という、暗黙知の共有が極めてむずかしい状況からのスタートでした。
2023年8月から開発を開始し、2024年10月の初回リリースを目指すというスケジュールで、この期間、私はプロジェクトマネージャー（PM）、プロダクトオーナー（PO）のアシスタント、スクラムマスターなど幅広い役割を担いました。
開発手法は、「工程ごとにスクラムを適用したウォーターフォール型」。具体的には、基本設計は1週間ごとのスプリント、詳細設計から結合テストは2週間ごとのスプリントといった形でした。
ところが、プロジェクトが進むにつれて、度重なる要件変更やメンバーの経験不足が影響し、設計工程は遅延しはじめます。
しかし、実装メンバーの参画時期はすでに決まっており、プロジェクトを止めることはできません。
私たちは苦肉の策として、設計チームと開発チームを完全に分離しました。設計チームが残りの設計を進める傍らで、開発チームは完成した設計書から実装を先行開始する。
これは「ファストトラッキング」と呼ばれる、納期を短縮するための手法です。
チームの分離は、無意識のうちに「仕様を考える人（設計チーム）」と「コードを書く作業をする人（開発チーム）」という役割の分断を生み出しました。
設計チームから開発チームへは、ドキュメントという形で仕様が一方通行で受け渡されるだけ。そこには、開発チームによる仕様検討というプロセスが抜け落ちていました。
このドキュメントはリリースするための納品物としての役割は果たしていましたが、チームが仕様を理解するうえでは不十分なものだったと思います。
実際に、ある開発メンバーにAPI設計書を渡したところ、「設計書を読んでも、よくわからない」という言葉が返ってきました。
それもそのはず。設計書にはデータベースの論理名で仕様が記述されていましたが、開発者にとってコードを書く際に必要なのは物理名です。
「考える人」と「つくる人」が分断されたことで、ドキュメントが実装の役に立たなくなってしまった現実を浮き彫りにしました。
後になって、私たちはこの状況が『チームトポロジー』という書籍に登場する「コンウェイの法則」に当てはまることに気づきました。
同書は、「システムを設計する組織は、その構造をそっくり真似た構造の設計を生み出してしまう。コミュニケーションの必要性に応じた設計活動を行うべき」と説いています。
私たちは「設計」と「開発」という分断された組織構造を選択した結果、意図や背景が伝わらないドキュメントを生み出してしまいました。
短期的な成果は得られても、このままではプロダクトの持続的な成長は望めません。私たちは、チームのあり方を根本から見直す必要に迫られました。
チーム体制の見直しで生まれた、新たな属人性
初回リリースを終え、私たちはチーム体制の抜本的な見直しに着手。チーム制を廃止して、要件定義から設計、実装、テストまでの全工程を1つの開発チームが担う体制へと移行しました。
仕様検討のプロセスも開発チームが担うことで、チーム全員が仕様に責任をもち、プロダクト全体を理解できるようになると思われました。
しかし、これまで実装を中心に担ってきた開発チームにとって、「どのようにつくるか」を考える設計プロセスを自分たちのサイクルに組み込むことは困難でした。
特に複雑な機能については、1スプリント（開発サイクル）内で設計からリリースまでを完結させることがむずかしく、実装前のスプリントで仕様検討を先行させるプロセスを採用しました。
ところが、「仕様検討」が、新たな属人化を生んでしまったのです。仕様検討は、チームの誰もが担当するものと想定していましたが、実際には「得意な人」や「やりたい人」に作業が偏ってしまいました。
複数の機能が連携する複雑な仕様について、その整合性や妥当性を理解しているのは、それを考えた本人だけ。ほかのメンバーは、自分の担当機能のことはわかっても、システム全体の動きを把握できません。
いつしかチーム内では、「ここの仕様は、あの人に聞けばわかるはず」という会話が当たり前になっていました。
『The DevOps ハンドブック』には、「作業を受け渡しすると必然的に失われる情報があります」と書かれています。私には、この言葉が刺さりました。
私たちは、チームを一つにしても、メンバー間で役割が固定化されれば、そこに見えない情報の受け渡しが発生し、コンテキストが失われる。
必要なのは、チーム全員で仕様を語り合い、ともに考えるための「仕組み」と「文化」を意図的につくることだったのです。
「語る」文化へ転換。チームで仕様を育てる4つの施策
「考えるチームを育成する」とは具体的にどういうことか。私たちは試行錯誤を重ね、日々の開発サイクルのなかに「対話」を生み出す4つの施策を組み込んでいきました。
1つ目に取り組んだのは、スプリントの最終日にチーム全員でリリース対象の機能を実際にさわり、不具合を意図的に見つけ出す「バグバッシュ」です。
目的や具体的なやり方は以下です。
これによって役割の垣根を越えた対話が生まれ、お互いの認識のズレや考慮漏れが可視化されました。
何より、「自分たちのプロダクトの品質は全員で守る」という当事者意識がチームに芽生えたことが最大の収穫でした。
ただし、リリース直前に問題が見つかるため「気づくのが遅い」という課題も残りました。
そこで取り組んだ2つ目の施策は、リファインメントとプランニングの活用です。
この施策によって、これまで特定の人物が担っていた仕様検討が、チーム全員の活動になりました。
しかし、この段階ではまだ詳細設計や実装レベルでの判断は個々の担当者に委ねられており、そこでの属人性は残っていました。
そこで行った3つ目の施策は、機能開発直後の仕様共有会です。これは、各メンバーが担当機能の開発を終えた直後に、その仕様や実装内容をチームに共有する会です。
その結果、「なぜこのような実装にしたのか」というコンテキストが可視化され、コードレベルの知識がチーム全体に伝播しました。
また、説明責任を全員が負うことで、機能仕様への当事者意識がさらに強まりました。
ただ、複雑な機能に関しては仕様の解釈にズレが生じるリスクがあるため、よりリアルタイムにズレを解消する仕組みが必要でした。
そこで4つ目。事前設計ディスカッションと同期作業といった施策をとりました。
これによって、細かな実装方針についてもチームで合意形成ができるようになり、手戻りが大幅に削減されました。
これら4つの施策は、スプリントの開始から終了までの流れのなかに組み込まれました。
このサイクルをスプリント内で繰り返すことで、「仕様について語り合う」ことが特別なイベントではなく、チームの日常となり、文化として定着していったのです。
仕様を「書く」から「語る」へ。対話がもたらしたチームの成長と今後の展望
この経験を通じて、私たちはプロダクト開発の本質を再認識しました。
『ユーザーストーリーマッピング』という書籍には、「書かれたものを投げ合うことよりも、会話をかわすことが重要なのです」という一節があります。
まさしく、私たちの学びはここに集約されます。チーム全員が対話を重ね、共通の理解を築き上げていく行為によって、自己組織化されたチームは開発され、プロダクトが育つのです。
もちろん、これですべてが解決したわけではありません。「語ること」が中心になったいま、新たな課題も見えてきました。それは、「未来のための記録をどう残すか」ということです。
対話で生まれた合意や仕様の背景を、将来のメンバーや第三者にも理解できるようにするには、ドキュメントが不要なわけではありません。
しかし、それはもはや一方的な「指示書」ではなく、対話の結果を補完する「記録」であるべきです。
仕様を「語る」文化を前提としたうえで、どのようなドキュメントがもっとも価値をもつのか。この問いに取り組めるようになったこと自体が、チーム開発が成功した証だと考えています。
私の経験が、みなさんの自己組織化されたチームの育成・開発に役立てば幸いです。
（※本記事の内容および取材対象者の所属は、イベント開催当時のものです）
