こんにちは。SHIFTのDAAE（ダーエ）戦略部で新規事業のプロダクトマネージャーを担当しているyokoです。

時短勤務のため、チームメンバーにフォローいただきながら、プロダクト作りに毎日奮闘しております。

この記事では、プロダクト開発の初期段階に行われる、要求定義→要件定義→基本設計のDAAE流DesignDocの書き方をお伝えします。

こんな方にオススメ

• プロダクトマネージャーになりたての方

• プロダクト開発の上流工程を勉強したい方

• 設計書のドキュメント化に困っている方

はじめに

プロダクト開発において各ステークホルダー間の認識齟齬を無くす上で、ドキュメント化はとても大切です。しかし、毎度丁寧に全てをドキュメントに落としていく時間がなかなか取れないのが現状です。

DAAE（ダーエ）戦略部では、様々なプロダクトを開発しており、成長ステージやプロダクト規模も様々で、部内のプロダクトマネージャーと会話すると、それぞれやり方も違っていて面白いのが特徴。

今回は私のチームで実践している、DesignDocの書き方をお伝えします。

DesignDocとは？

プロダクトに新規機能を追加するにあたり、ビジネス企画側との合意や、開発者へのインプット及び認識合わせを行う上で、DesignDocを活用しています。

1. 目的
DesignDoc書く上での目的は下記3つです。

• 明確化：何をいつ、どのスコープまで実施するかをハッキリさせます

• 合意形成：プロダクトに関わる人の共通認識合わせに使います

• 記録：組織メンバの入れ替わりを考慮し、どのような経緯で設計しているのかを残します

2. 誰が書くか
プロダクトに関わる人、全員で書いていきます。

設計検討時などのコミュニケーションツールとしても使っていきますので、検討メモ等も残していきます。

3. DesignDocの基本構成
DesignDocの基本構成は、大きくは以下の要素で成り立っています。

（1）概要
　　・どのようなサービス、機能であるのか

（2）背景と目的
　　・なぜやるのか、機能実装によってどのような効果を期待するか

（3）やること、やらないこと
　　・提供内容をフェーズ分けして提供する場合のスコープ
　　・スケジュールの兼ね合いで落とす機能
　　・最低限必要な機能も合わせて記載

（4）スケジュール
　　・具体的なリリースタイミング

（5）要件定義
　　・ユーザーストーリ
　　・DB設計や処理のチェック条件
　　・開発タスクに落とせる粒度に分解して設計

（6）設計詳細
　・大規模開発時等、機能が入り組んでいる場合は記載

（7）非機能要件
　・セキュリティ要件や、ログ等として保持すべき事項

（8）リスクと課題
　・既存機能への影響度や、セキュリティリスク等
　・ペンディング事項等を明確化

要求定義＆要件定義時のポイント

DAAE(ダーエ)では、開発プロセスの初期段階でプロトタイプを用いたテスト「施策フェーズ」を追加しており、スピーディーに機能をユーザーへ提供し、その機能が与える価値を見極めながら、改善を加えて本格実装を行っております。

そのため、設計段階で各ステークホルダーとの期待値合わせをしていく事がとても大事になってきます。

1. ビジネス企画側との目線合わせ
コミュニケーションが足りないと、「出来上がりが思っていたモノと違う」というケースが発生してしまいます。そうならないためにも、初期段階での下記目線合わせはとても大事です。

• 背景や目的
  なぜその機能を実装するのか、なぜ今実施するのか、これを提供することで、どのような価値をユーザーが受け取れるのか
  

• ゴールやKPI
  その機能を実装することで、何を達成したいか、KPIとして何を設定するか

積み上げられたバックログの提供順番等を合意していく上で、とても大事になってきます。

2. システム開発側との目線合わせ
開発者として、開発機能の目的やゴールが見えないと、設計時に汎用的な作りにできなかったり、ユーザー視点の足りないエラーハンドリング等が起こったりします。

• 背景や目的
  こちらは、ビジネス側と同じですね。
  

• ユーザーストーリー
  誰が、どのようにその機能を使うのか。それにより、どのような結果を求めているか

より開発者が業務理解をした上での実装ができることで、実装時の細かい考慮が可能となります。

DesignDocをどう書けばよい？

1.要求定義
DesignDocを書き始める前の準備として、私のチームではこのテンプレートに沿って要求事項を整理しています。

「埋められない事項＝要求が定まっていない」ということですので、ヒアリングをしながら要求事項を固めていきます。

また、スケジュールや同時期に開発している機能の規模感や進捗とのバランスを取っていく上で、「制約事項」や「依存関係」はしっかりと合意していきます。

申し送り事項となっている内容については、きちんとバックログに残し管理していきます。

2.要件定義
まずは、機能を大きな要素に分解します。分解した機能に対して、ユーザーストーリーを作っていきます。 同時にストーリーチケットを発行し、後続の基本設計内容を紐づけていきます。

ドキュメントと実際の開発管理が紐づけされ、管理がしやすくなるので、オススメです。

3.基本設計

ストーリー設計
ユーザーストーリーをシーケンス図などを用いて記載していきます。 各ユーザーストーリーで、どのような処理が行われるかが可視化されてイメージ合わせがしやすいです。

UI設計
開発対象機能を実装する上で、まずデザインと画面仕様書を作成します。
デザインデータと一緒に、画面の各項目における細かい処理内容を記載していきます。

DB設計
上記ストーリーを構築する上で、どのようなデータをシステムとして保持するべきかを整理していきます。 DB構成の概要を記載し、開発者と正規化を行っていきます。

実行仕様設計
各実行仕様の詳細を記載していきます。
処理内で条件分岐等があれば、チェックロジック等も記載していきます。

※チェック仕様のイメージ

非機能要件
処理速度や、セキュリティでの考慮事項等を記載していきます。

4.調整事項や課題事項
最後に、ペンディングとして残っている内容や、今後の拡張性を考慮して設計して欲しい事項をリスト化していきます。

リリース前に、このリストを見ながら積み残し事項がないかを確認し、管理しております。

最後に

「DesignDocの書き方」で調べると、色々出てくると思います。
しかし、開発プロダクトの規模やステージによって、記載レベルもまちまちです。

今回挙げた内容は、1~2ヶ月で実装していく規模感のリリースをする際の、設計ドキュメントとなります。

もっと小さい規模の機能を作る際は、シーケンス図や画面仕様書だけのケースもありまし、微修正レベルでしたら書かないケースもあります。

各ステークホルダーの目線合わせ、後日振り返る時に利用していくためのドキュメントですので、是非チームにあったやり方で色々試してもらえたらと思います。

今回の紹介内容が、読んでいただいた方にとって何かしらのヒントになれば幸いです。

DAAEマガジン

お問合せはお気軽に

＼もっと身近にもっとリアルに！DAAE 公式 X／

SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/

SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/

SHIFTの導入事例
https://service.shiftinc.jp/case/

お役立ち資料はこちら
https://service.shiftinc.jp/resources/

SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/

PHOTO：UnsplashのKelly Sikkema