仕様書の参考例と、こんな内容を仕様書に最低書くといいというお話
よく、仕様書を書いていなくて、書いてみたいけど、具体的な仕様書がネット上に落ちてなくってこまってるって相談を受けるので 「仕様書の記載内容のイメージ」を作りました！
※前提として「現在仕様書を書いていない、自社開発のMVP検証前後のフェーズのスタートアップ向け」に書いています。PMが仕様書、エンジニアがDesign Docを書く分担です。
ついでに、システム開発の基礎である「システム開発のV字モデルをベースにした設計書の紹介」も含めてまとめてみましたー！
大規模開発に使われたり、古くからあるフレームワークなので、スタートアップの方だと、システム開発のV字モデルの概念やそれにあわせた成果物を知らない人が多いけど、「要件定義書」と「設計書」を全てドキュメント化するとどうなるかを理解した上で、「仕様書」として情報を削る方が、考慮漏れ防止やエンジニアがやっている設計内容の理解につながるので、全体を知っててもいいのかなぁと思っています。
結論から！
仕様書のイメージ
仕様書
notionはこちら➡︎https://fallacious-packet-325.notion.site/ffe775e764bb4ac4810c83aeeb1972a5
全体の画像をとりあえずみたい方はこちら⬇︎
使える方は参考にしてもらえればと思いまーす！もし、こうしたほうがいいよ！っていうところあったら、ぜひ教えてくださーい！
一般的な仕様書とは
一般的に製品やサービスなどが満たすべき条件や内容を明確化し、まとめた書類のことを「仕様書」と呼びます。それを実現するものを設計書と呼ぶのが概念です。一方で、仕様書の具体的な定義は曖昧なことが多く、プロダクト開発において関係者間での認識齟齬や仕様のもれを防ぐためのドキュメントを一般的にさしていることが多い印象です。
具体的に仕様書の対象となる内容
システム開発のV字モデルにおける要件定義書と基本設計書の一部であることが多いと思います。
大きく分類すると、要件定義ではサービス概要、機能や性能概要 を定義し、基本設計では外部設計、詳細設計では内部設計をおこないます。
外部設計は、目に見える機能についての仕様、内部設計はバッチ処理やデーターベース構成などユーザーの目に見えないものの定義をおこないます。
基本設計の具体的な成果物の一例です。
詳細設計の具体的な一例です。
最低限必要な仕様書の主な項目について
仕様書によく書かれる主な項目は以下の通りです。
要件定義の一部と基本設計の一部を書いているものが多いです。
以前、大規模システム開発をしていた時は、基本設計と詳細設計の成果物をすべてつくっていました。一方、現在の新規の自社開発の場合は、ドキュメントを最小限にして、PMFの検証をはやく回すところが多いので、最低限この程度記載があるといいのかなと思います。
仕様書の内容について
改めて書き出すとこんな感じ。
Notionも再度掲載
https://fallacious-packet-325.notion.site/ffe775e764bb4ac4810c83aeeb1972a5
仕様書の項目
仕様書のステータス、担当者、各種リンク
目的
KPI
概要
機能一覧(複数機能ある場合)
画面遷移(複数画面ある場合)
画面イメージ+機能の仕様
分析ログ
ポイント
ドキュメントのステータスとFigmaやチケットへのリンクの作成
KPIとログがリンクするように記載
画面が複数ある時は画面遷移を添付
仕様記載について
画面名やセクション名は認識ずれを起こさないために明記
ボタンは画像なのか、テキスト表示なのかを記載。具体的な表示方法(右寄せや縦横固定、透過など)はFigmaにコメントで書く場合も多い
テキスト情報の表示の場合は、上限文字数や上限を超えた時の処理の記載
動的に表示するか静的に表示するかの確認
例) ランキング表示について、バッチで1日1回更新なのか、読み込みのたびに表示なのか
ユーザー入力がある場合
分岐、入力情報の上限文字数や文字の種類、バリデーションチェックを記載
タップ時の注意
タップエリアの明記
エラーチェックを記載
AndroidとiOSでページ遷移の種類がことなるので明記
トライアル機能なのか継続的に使う機能なのかの意識合わせをする
例) 決済機能などは継続的に使うが、新しいキャンペーンなど一度トライアルでやるものなのか、継続的なのかによってどこまで作り込むかが異なるため
なぜ仕様書を書くか
これは、いろんな意見があると思います。
わたしは、費用対効果(効果=最終的なチームの生産性)が高いと思っているので、どのような状況でも仕様は書きます。書きおこすと漏れを気づく場合も多いので、、、
一方、超初期の開発だとFigmaにメモ書きのみの場合なども多いのが実態です。
仕様がもれない ※リリース後の障害や拡張性検討も含め
QA項目をつくるときに困らない
仕様の確認のための無駄なコミュニケーションが少ない。また認識齟齬や漏れがおきていない
見積もり精度が高く、リスケがおきていない
のようなクオリティ高い開発ができるチームであれば、PMFするまではなくてもいいかもしれません。
若手のPMであればあるほど、仕様書を書く時間がないと思っている状況でも、仕様書を書いてエンジニアなどもはじめチームメンバーに仕様をレビューしてもらうことで、結果、スムーズな開発ができる場合が多いので書いた方がいいと思います。
この仕様書の例は、フォーマットを作るのも含めて1時間くらいで書いています。慣れていなくても、2時間くらいで仕様書を書けるのであれば、チーム全体の生産性を考えたときにあがるシーンが多いと思うし、慣れると早く書けるようになると思います！
一方で、「仕様書を書く」ということを目的にしないようにし、その組織に応じた仕様書にブラッシュアップしていけることが大事なのかなと思います！
少しでも参考になったらうれしいです🐰
---------------
以下宣伝です📣
こちらの内容をベースにUdemyで若手PMや開発以外の部署の方向けに講座を作ってみました！。はじめの20分程度は全員無料でご覧いただけます！
以下のURLまたは、クーポンコードを入力していただくと、定価2400円ですが、20%オフの1920円でご購入いただけまーす！期限切れていたら教えてください💦
クーポンコード： PM_CUPON
対象URL：https://bit.ly/3nF3kCf