見出し画像

要求仕様書とはなにか

※この記事は hey アドベントカレンダー2020 9日目の記事です。

STORES でプロダクトマネージャーとして働いている西岡(@nishiokadaiki1)と申します。


プロダクトマネージャーの重要な仕事である要求仕様書についてnoteをかきます。過去何度も要求仕様書らしいものは書いてきたのですが、最近の開発プロジェクトの中で書く意味や内容が、ようやく腹落ちした感覚があったので、hey アドベントカレンダーという良い機会にアウトプットしてみます。

要求仕様書とは

最初に、要求仕様書とは何かを簡単に説明します。
要求仕様書とは、開発をする前にプロダクトマネージャーが、機能を実施する背景や内容、目的をまとめたものです。開発チームで実際につくる機能を議論していく土台となります。必要となる情報が欠けていたり、論理構造が破綻していると、議論が中々前に進まず、開発スピードが落ちてしまう原因になります。

書く目的

要求仕様書の目的は大きく2点あります。

1. みんなで良い解決方法を模索するため
プロダクトマネージャーだけでベストな解決方法は生み出せません。プロダクトマネージャーの役割は、持っている前提知識や考えを共有し、プロダクトのあるべき姿と現状のギャップ(課題)を浮き彫りにする事だと考えています。そのギャップを埋める解決方法は、開発メンバーとともに議論し決定していくことが多いです。

2. 施策へのモチベーションを高めるため
開発する前にみんながワクワクできるような絵を描きたいと思っています。この機能を開発すると事業が前に進むことを事前に想像できるかどうかは、開発チームのモチベーションにも影響し、最終的なアウトプットの質も大きく変わると考えています。

何を書くか

要求仕様書には下記の内容を書くようにしています。もちろん、開発する内容により、若干の修正をしていきます。
他の要求仕様書にはあまり出てこない項目として、「プロダクト戦略上の位置づけ」があります。この機能は長期的なプロダクトの方向性とどのようにリンクしているのか、なぜ今この機能を開発する必要があるのかを説明する項目になります。これはロードマップの優先順位を問われる内容になっており、プロダクトマネージャーに説明責任があると考えています。

・ 概要
・ プロダクト戦略上の位置づけ
・ ターゲットユーザー
・ ユースケースと解決したい課題
・ 機能仕様(仮のスコープ)
・ 定性的 / 定量的な見立て(成功状態の定義)
・ 競合状況
・ スケジュール
・ リスク

開発プロジェクトでのドキュメント役割

ここで開発中にでてくる他のドキュメントと比較して、要求仕様書の立ち位置を確認してみます。
STORES の直近の開発では、要求仕様書の他に、機能仕様、技術仕様というドキュメントが作成され、開発中に決まったことを適時更新していくスタイルになっています。

3つのドキュメントはそれぞれ下記のような役割として認識しています。
要求仕様書は、誰に何をつくるのかを定義したもの。それを受けて、開発チームで何をどうやって作るのかが議論されていき、機能仕様と技術仕様のドキュメントが作成されていきます。

要求仕様書

ドキュメントをテンプレート化する価値

最近では、開発中に作成頻度が高い要求仕様書などのドキュメントをテンプレート化する動きがありました。

開発プロジェクトに応じて、どのテンプレートを利用するかは各開発チームに一任されています。必ずしも全てのテンプレートを盲目的に使うのではなく、必要に応じて最低限のテンプレートを活用していく事が重要です。

こういったドキュメント整備は地味な作業になりますが、長期的に運用されていく事でチーム内に共通の資産を育んでいく良い試みになると信じています。

画像2


デメリットはないか

要求仕様書を作成する事のデメリットはないか考えてみます。
要求仕様書はその作成になんといっても労力がかかります。必要な情報を収拾し、前提情報や仮説検証したいことを丁寧に文言に落とす作業は、「これ絶対成功するからやりたい!」という単純なコミュニケーションより、多くの時間がかかります。プロダクトや会社のフェーズによっては、要求仕様書がない方が良い場合もあるかもしれません。

ただ、今後5年10年と STORES プロダクトが続くことを前提にすると、意思決定の過程をドキュメントにしていつでも参照できる(意思決定の資産化)状態にしておく事は長期的に開発効率を高めるのではないかという思いがあります。

最後に

今回は個人的な要求仕様書の書き方、またそれをテンプレート化して社内の共通資産にしていく動きについて記載しました。関わっているプロダクトやチーム状況により各々特徴があると思うので、気軽にフィードバック頂けると嬉しいです。要求仕様書の書き方や必要性について悩んでいる方の参考になれば幸いです。

hey アドベントカレンダー 2020は他にも多種多様なコンテンツになりそうですので、今後の更新を楽しみにお待ち下さい!
明日は@morihirokさんの「標準化と形骸化」になります!



この記事が気に入ったらサポートをしてみませんか?