はじめに
こんにちは、グループ経営ソリューション事業部の永井です。
私は、2017年から aiuola（あいうぉーら） と Ci*X（さいくろす） という自社プロダクトの開発を担当しています。
aiuola および Ci*X のファーストリリースは 2018年 10月。それ以降は、エンハンスバージョンアップを重ね、製品の機能を強化してきました。
エンハンス開発の要件定義～設計フェーズでは、 Google の Design Docs を参考にした独自のドキュメントを用いて設計をしています。
この記事では、その具体的な内容と運用方法についてご紹介します。
※ 本記事は 電通総研 Advent Calendar 2025 14日目 の記事です。
aiuola 、 Ci*X の開発スタイル
まず、 aiuola 、 Ci*X チームのエンハンス開発の流れを簡単に説明します。
aiuola 、 Ci*X は、半年ごとに新しいバージョンをリリースしています。開発期間 6ヶ月は、大まかに、
- 要件定義～設計：1～2ヶ月
- 実装：2～2.5ヶ月
- テスト：1～1.5ヶ月
- 出荷準備：0.5～1ヶ月
とフェーズが分かれています。
全体としてはウォータフォール型のように見えますが、アジャイルの手法を取り入れ、2週間ごとのスプリントを回しながら開発を進めています。
（詳しくは、以前の記事もご覧ください！ → エンタープライズアプリケーションプラットフォーム「aiuola」におけるアジャイル開発 ）
エンハンス開発で対応する案件には、お客様からの要望や、社内で企画した新機能、不具合の修正などが含まれます。
それらの案件は、開発チームのバックログに登録されます。そして優先度付けを行ったうえで、 6ヶ月 の開発期間に収まるよう対応案件を決定します。
Design Docs とは
Design Docs は、直訳すると「設計書」ですが、ソフトウェア開発界隈では、 Google の Design Docs を指すことが多いでしょう。詳細はリンク先のブログ投稿を参照していただきたいのですが、ここではその内容を簡単に説明します。
Design Docs の目的は、ソフトウェアの目的（どのような課題を解決するか）を明確にし、その実現方法とトレードオフについて議論することで、チーム内での認識の統一を図ることです。また、あとから、「なぜこのような意思決定をしたのだろう？」と疑問に思ったとき、過去の Design Docs を参照することでその経緯をたどることも可能となります。
Design Docs には決まったフォーマットはありませんが、一般的に以下のような項目が含まれます。
- コンテキスト：このドキュメントを読むにあたり必要となる知識
- 目標とやらないこと：ソフトウェアや機能が何を目的としたものか、どんな課題を解決するか。逆に、対象外とする課題は何か
- 設計：システムアーキテクチャやデータモデル、API設計、制約など
- 代替案：検討した他の設計案と、評価（採用しなかった理由、トレードオフなど）
- その他の関心ごと：開発の進め方やテストの手法、セキュリティ対策、パフォーマンス最適化、運用・保守など
作成したドキュメントは、レビュープロセスを経て実装フェーズに進みますが、実装中に設計の見直しが必要になった場合は、ドキュメントを修正し、軌道修正をしながら開発を進めていくことができます。
aiuola 、 Ci*X の Design Docs
ここでは、私たちが使っている Design Docs のフォーマットや作り方、レビュープロセスについて、ご紹介します。
（ちなみに、チーム内では「Design Docs」ではなく、「検討資料」と呼んでいます。なぜ「検討資料」にしたのかは忘れてしまいました 笑）
Design Docs のフォーマット
aiuola 、 Ci*X では、エンハンス開発を行う際、案件ごとに Design Docs を作成することとしています。
Design Docs のフォーマットは、試行錯誤の結果、以下の項目を含めることになっています。項目とその書き方を以下にまとめました。
（実物とは少し異なりますが、大まかな構成は同じです）
- 概要
- 要望の背景・解決したい課題
- このエンハンス案件によって、どのような課題を解決するかを明らかにします。お客様のご要望はいったん受け止めますが、 aiuola 、 Ci*X はパッケージ製品なので、製品としてどのような対応をするのがベストかを慎重に検討する必要があります。
- 要件
- このエンハンス案件の要件を定義します。必須な要件（Must）、可能なら実現したい要件（Want）をまとめるとともに、実現しないことも（あれば）記載します。
- 要望の背景・解決したい課題
- 仕様検討
- 前提知識
- このドキュメントを読む人が知っておくべき用語や、既存機能の簡単な説明を記載します。
- 他社製品の調査
- 市場に既に存在する製品に、今回の要件を満たせる類似機能が存在する場合、どのような方法で実現しているのか、公開情報を調査します。先行している製品を参考に、よりよい仕様を実装することで、競争力を高めます。
- 法律・制度の調査
- エンタープライズアプリケーションは、法律や制度によって仕様が自ずと決まってしまう場合があります。法律や制度を正確に理解し、それを遵守した実装を行うことが求められます。
- 業務の検討
- エンタープライズアプリケーションの場合、業務プロセス内にシステムが登場することを想定した設計を行う必要があります。
- 仕様案
- アプリケーションの仕様案をまとめます。ここでは、いわゆる外部設計に相当する内容を記載します。複数の仕様案がある場合、それらを比較し、このエンハンスバージョンで最適な案を選定します。
- 制約
- 例えば、エンハンスバージョンアップ後に後方互換がなくなる箇所など、ユーザーに影響のある制約事項があれば、まとめておきます（なるべく、そういった制約が生まれないような仕様案を模索します）。
- 前提知識
- 技術調査
- 新しい要素技術を導入するなど、実装に入る前に調査・検証が必要となる場合は、その内容と結果を記載します。
- 設計
- その他
- 外部サービスとの連携で必要な調整など
- 社外のサービスと連携するような案件の場合、先方との調整が発生することもあるため、そういった情報はまとめておきます。
- 他チームとの連携で必要な調整など
- 例えば、インフラ構成の変更が必要な案件など、社内の他のチームにも作業を依頼しなければならない場合、その内容をまとめておきます。
- リリース時・リリース後の注意事項
- 本番環境へのリリース作業中、特別に実施する必要がある作業があれば、その内容を記載しておきます。また、リリース後に利用者側で必ずやらなければならない作業がある場合も、その内容を記載しておきます。
- 外部サービスとの連携で必要な調整など
- 仕様相談やレビューの記録
私たちは、 Confluence というツールで Design Docs を管理しており、小規模な案件であれば1ページで書ききってしまうのですが、大規模な案件の場合、項目ごとにページを分割したり、階層化したりして、読みやすいドキュメントになるよう工夫しています。
また、上記項目はすべて必須というわけではなく、案件内容によって必要な箇所のみ記載することにしています。
Design Docs のレビュー
Design Docs を作成したら、ドメインエキスパートやテックリードによるレビューを実施します。
案件の規模や内容によっては、すべてを書き終えてレビューを依頼するのではなく、少人数での仕様相談会や途中段階でのレビューを実施することもあります。
仕様相談会やレビュー時のやり取りは、意思決定の根拠として重要であるため、 Design Docs の 仕様相談やレビューの記録 の項に記録しておきます。
実装中にも修正を加えていく
レビュープロセスを通過し、いよいよ実装、となりますが、まだ Design Docs の役目は終わりません。
実装中に、設計の見直しが行われたり、新たな影響範囲が見つかったりすることはよくあります。
その場合、 Design Docs を修正し、新たな方針のもと実装を進めていくこととします。
テストと Design Docs
テスト担当者は、開発者の作成した Design Docs を参照し、テスト仕様書を作成します。
Design Docs に、影響機能が網羅的に記載されていることで、テスト範囲が明確になります。
なお、実装中も Design Docs の修正は続いているため、実装完了後、テスト実施に入る前に、必ずテスト仕様書にも Design Docs 最終版の内容を反映させることとしています。
Design Docs と仕様ドキュメント
Design Docs は、エンハンス案件の開発時に利用するもので、作り捨てのドキュメントです。
完成したアプリケーションの仕様は、 別途バージョン管理している、仕様ドキュメント（画面定義書、バッチ仕様書、API仕様書 など）への反映を行います。
過去の Design Docs の管理
ここまで来てようやく Design Docs はその役目を終えることとなります。
過去の Design Docs は、 当該エンハンスバージョンの Design Docs 置き場に格納されます。
おわりに
今回は、私たち aiuola 、 Ci*X チームで利用している Design Docs についてご紹介しました。
元の Google の考え方を参考にしつつ、チームにフィットするようカスタマイズした結果、現時点ではこのような形になっていますが、チームの状況によってこれからもどんどん改善されてよりよいものになっていくと思います。
本記事が、皆様の設計ライフの一助となれば幸いです。
私たちは一緒に働いてくれる仲間を募集しています！
電通総研 キャリア採用サイト執筆：@nagai.satoshi
レビュー：@miyazawa.hibiki
（Shodoで執筆されました）
