正しい仕様書のサボり方
（本記事は、2022年6月13日に下記Noteへ投稿した内容を転載しています）
こんにちは、カウシェのプロダクトチームの@konchanです。
みなさんの中で「仕様書を書くのが面倒・・・」「やり方がわからない」という理由で開発がカオスになったり、品質が落ちたりしたことはありませんか？
スタートアップの限られたリソースで「良い仕様書」を作るために「効率的にサボること」も大切。
そんな課題に対して本記事では、SIer・大手ベンチャー・スタートアップなど、幅広い業界を経験してきたカウシェのプロダクトマネージャーが、良い感じにサボりつつ仕様書を書く方法を紹介していきたいと思います。
近藤 優輝 / @konchan
NTT DATAグループを経て2016年DeNAへ入社。各種ヘルスケアサービスの開発リード、新規サービスのローンチを牽引。
副業を経て2021年3月フルタイムとしてカウシェにジョイン。2021年9月からPdMとして方針策定、企画、開発をリード。趣味はスプラトゥーン、筋トレ、釣り。
仕様書を書くPros・Cons
仕様書というと腰が重いイメージがありますが、それをアウトプットすることでのPros・Consがあります。
Pros
- 具体仕様を検討しておくことで考慮漏れが減る → 開発の手戻りが少なくなる。品質が良くなる
- 開発時の認識合わせの不要なコミュニケーションコストが減る → 開発工数が低くなる
- 複数人で開発する際に共通認識を持つことができる
- より良いUXがないか事前に検討できるのでUI/UXが向上する
- 事前に仕様を明確にすることで開発工数を見積もることができ、スコープ調整できる
etc…
こんなに良いことがある仕様書ですが、なぜ疎かになりがちなんでしょうか？それはConsの部分が影響していると考えています。
Cons
- 仕様書を書く工数が必要になる
- 仕様書に何を書いて良いのか分からない
仕様書を書くことは、工数を使います。そのため書かない方が早く開発を進められるという意見もあると思います。
これに対して自分の考えとしては、開発開始時点でサボった仕様検討、確認にかかる工数は後工程の実装時に発生するので、工数としては同じ。
むしろそこで問題があった時に手戻りが発生するので、前工程で検討しておかないと工数が増大する原因になります。特にチーム開発ではこのコストがボディブローのように効いてきて、炎上につながります。
再現性高く安定した品質とコストで開発するには、前工程で仕様を固めておくことが重要です。
ただ 何を書いて良いか分からない という課題があるのではないでしょうか。。
プロジェクトのフェイズや事業領域、チームのスキルセットによって記載する内容は異なりますし、調べてもSIerの厳格な仕様書例ばかり出てきてWebサービス、アプリにおける仕様書のフォーマットみたいなものがなかったりします。今回はこの課題にフォーカスしていこうと思います。
仕様書に必要なこと
仕様書に記載されているべきことは
「何を作りたいか？」
があれば良いと考えています。
そのため、どのように作るかについてはあまり記載されていなくても良いです。これはSIerの仕様書でいうと詳細設計成果物が該当しますが、それはコードを見れば良いので自社サービス開発においては不要だと思います。
※ 納品物が必要なプロダクト開発形態などであれば必要な場合もあります。
何を作りたいかを運用可能なレベルで記載するにはどうすれば良いでしょうか？
「良い感じ」の仕様に必要な要素
「運用可能な仕様書 → 良い感じ」であるためには最低限
- 必要な情報が記載されていること
- シンプルであること
- 情報が集約されていること
を満たしている必要があると思います。
逆に仕様書の正規化や完全性はトレードオフで犠牲にして良いと考えています。これはやりすぎると運用工数がかかりすぎてメンテナンス性に欠けるためです。
完璧なものを求めすぎず良い塩梅で仕様を書くことが重要です。
仕様書を書く方法
カウシェでは開発バージョンの仕様書はFigmaに集約することにしています。Figmaだけを見ればその開発バージョンでやりたいことがわかるようになっています。
これは1つのドキュメントだけを見れば良いのでエンジニアが開発に集中できる状態を作ることを目的にそういった運用にしています。迷ったり情報を探すコストが下がるので開発効率が上がります。
ただ開発バージョンの仕様（差分仕様）を把握することには適していますが、最新の仕様（全量仕様）を把握したいという要望は満たせないので、最新のリリース仕様についてはNotionで管理するようにしています。
仕様書フォーマット
現在カウシェで採用している仕様書のフォーマットでは次の項目を記載します。
画面名
仕様を記載する画面の名称です。命名規則はプロジェクトによって異なって良いですが、ドメインとCRUDを意識して {ドメイン名}_{CRUD} などとすると命名しやすいです。
e.g. Userドメインの画面名
- ユーザー_一覧
- ユーザー_作成
- ユーザー_詳細
- ユーザー_編集
- ユーザー_削除
項目名
画面に表示している項目の名称です。項目のまとまりに着目して命名すると付けやすいです。また一定のまとまりがある部分はセクションという命名にしてしまっても良いと思います。
e.g. 商品に関する項目名の付け方
- 商品_画像
- 商品_タイトル
- 商品_シェア買い価格
- 商品_参考価格
- 商品_割引率
項目制御
項目ごとの表示ロジックやバリデーションについて記述します。
e.g. リストの項目制御
- 初期取得: 10件
- ソート: 作成日時降順
- pull to refresh あり
イベント制御
ユーザーアクションなど特定のイベントを起因として行われる処理について記述します。
e.g. リストのイベント制御
- スクロール
- 項目を10件ずつ読み込む
仕様書記載例
より具体的にイメージしてもらうためにカウシェで実際に書いている画面仕様書の一部を例に説明したいと思います。
仕様を書く際には下記のようなカードを用意して記載しています。
実際にカウシェのお気に入り一覧画面の仕様です。お気に入り一覧のリストアイテムとして表示される商品については別で仕様書のカードを用意して記載しています。タイトルなどFigmaを見ればわかるようなものについて、テキストでお気に入りを設定するなどの冗長な記載はしないです。
項目ごとに項目番号を振るというのもあると思います。命名規則がしっかりしていればそこはある程度認識できるので余程混み合っている画面以外は工数がかかりますし、不要かなと考えています。
このように仕様を書いておくことで完全ではないですが、大部分の仕様については理解できるので、確認コミュニケーションのコストがかなり下がります。それによって、スピードを維持しつつ品質の高いプロダクト開発を行うことができます。
まとめ
本記事では一例としてカウシェで実践している仕様の管理について述べました。まだまだ試行錯誤中ですが、今のところ「良い感じ」に仕様は管理できていると思います。自分のところはこうしている、といったものがあればシェアしていただけると、とても嬉しいです。
仕様を管理することでより良いUI/UXや開発スピードアップ、低下防止につながるので、引き続き試行錯誤してアップデートしていきます。
また、開発機能の仕様書の書き方については述べましたが、仕様書の開発バージョンごとのドキュメント管理については、Notion × GitHub Flowを採用していたりするのでそれは別で述べていきたいと思います。
これからも試行錯誤しつつ限られた開発リソースを最大限活かすために仕様を書いて、シェア買いビッグバン（プロダクトグロース）していきたいと思います！
