いまこそ「良い仕様書」がチームの生産性の鍵となる。ので、仕様書に含めたい 14 のポイントについてまとめました。
こんにちは、フリッツ です。今回はプロダクトマネージャーの日課とも言える「仕様書」について。自分にとっては PM 業の施策実行フェーズにおいて最も重要な仕事のひとつであり、最も心躍り、最も興奮する瞬間です。
PM になってかなりの時間が経ちましたが、「仕様書」への力の入れようは減るどころか、「もっと気合を入れなければ。」と感じる一方。在宅勤務が（たぶん） IT 業界のニュースタンダードとなっていくいま、なおさら「仕様書」の重要性を訴えたい今日この頃です。
ということで、今回は
・ 良い仕様書がもたらす 5 つの効果
・ 仕様書の重要性が増していく 2 つの理由
・ 仕様書に含めたい 14 の項目・実戦編
・ 仕様書作成時に心に留めたい 3 つのこと
・ 具体的な仕様書サンプル（後日追加公開予定）
などなどを復習してみました。超ニッチですが、仕様書のみについてここまでマニアックに考察した記事は無いはず……笑 だからこそ、どなたかのお役に立てる記事になっていると信じて。
01# 前置き：仕様書フォーマットに正解はない
仕様書の書き方に当然正解はなく、仕様書のテンプレートは、以下にあげたような変数（もっとあるけども……）によって全く違うモノとなります。
・ プロダクトに関わる人数は 5 人ですか？ 100 人ですか？
・ あなたは PdM 1 年目ですか？ 10 年目ですか？
・ プロダクトがリリースされてから何年経ちましたか？
・ 関わるチームメンバーは 1 人ですか？ 20 人ですか？
・ チームメンバーは百戦錬磨のベテランですか？ジュニアですか ？
・ そもそも、 PdM は何人いますか？1 人？ 20 人？
ある会社では「ざっくり書き、詳細は現場に任せた方が良い。」という場合が正解で、ある会社では「アニメーションの動きも文言もデータベースの設計も全部定義する。」というギチギチの仕様書が正解だったりします。どれも一長一短。置かれている状況によって、選ぶべき仕様書フォーマットは間違いなく異なるはず。
元 Google の方が「こうするといいよ。」とアドバイスする仕様書。所属する会社の社員がまだ 10 名程度しかいなかった頃に僕が書いていた仕様書。チームメンバーが 20 人の場合に書く仕様書。さらには、チームメンバー全員が会社に通勤できていたころと、誰もが在宅勤務を余儀なくされている今の仕様書。どれも、注力すべきポイントが異なるかと思います。
ただ、「One fits for all = 全ての場合に適用できる理想の仕様書」が存在しなかったとしても、「含めたほうが良いもの」の最大公約数はあるはず。それをまとめてみたのがこの記事です。
02# 良い仕様書がもたらす 5 つの効果
さて、仕様書ってなんでそんなに大事なの？適当な仕様書だとなんでダメなの？仕様書の良し悪しはどんなインパクトをもたらすの？こうしたいくつかの疑問について自問自答してみました。MECE じゃないけど許して…。
ひょっとしたら 04# の冒頭に添付した 14 項目の画像をざっと見ていただいてから読んでもらったほうがしっくりきやすいかも。
1. 良い仕様書は、コミュニケーション・サーチコストを削減する
PM <-> チームメンバーの無駄なコミュニケーションが減る
事前に確認できる可能な限りの「機能の振る舞い」を記載しておくことで、チームメンバーがいちいち PM に「ここはどうしますか？」と聞き、その回答を待つ、というコミュニケーションの無駄が削減できます。プロジェクト開始直後からそんな会話が始まっているようなら要注意かも。また、仕様書というオープンフォーマットで事前に内容が明記されていることで、質問が重複するといった無駄も防げるように。
関連ドキュメントを探す手間が省ける
プロジェクトにおいては、過去の仕様・発行されたチケット・デザインファイル・QAプラン・関連ドキュメントなどなど、多くの付随ドキュメントが発生します。「あのドキュメントどこだっけ？ごめん教えて～！」といった発言が頻発しているようなら要注意。これらすべてへのリンクを一か所にまとめるべき場所として、仕様書以上のものは本来ないはずです。これを周知することでチームメンバーそれぞれの無駄な工数を削減できます。
（頻繁な仕様変更が起きても）Slack の海に潜る必要がなくなる
予想しきれなかった仕様の抜け漏れや仕様変更の決定は Slack・口頭で決めることが多いかと思います。これ自体は仕方ないのですが、「良い仕様書」はこうした変更をすべてとらえていて然るべきです。結果、チームメンバーが最新の仕様を把握するために Slack のスレッドを探ったり、エンジニア/PM/QA 間での仕様伝達していたつもりだった/していない等の混乱が起きたりといった時間的ロスを防ぐことができます。また、仕様変更について周知できていなかったメンバーからの同じ質問、といった類似のロスも防ぐことができるようになるはず。
2. 良い仕様書は、開発がカオスに陥るのを防ぐ
追加で開発される機能が減り、終盤のカオスを防げる
エッジケースなど、後半になって発覚する仕様の抜け漏れはどうしてもありますが、事前にきちんと様々なケースを記述しつくしている仕様書はこういった追加開発を事前に削減する効果があり、特に開発終盤における追加機能ラッシュ・奔走状態、すなわちチーム全体への過剰なストレス・カオスをかなりの割合で軽減できる媒体になっているはずです。
自分が何を開発しているのかを誰もが把握している
度重なる仕様追加・仕様変更が仕様書においてきちんとアップデートされていない場合、終盤にはチームメンバーの誰もが何を開発しているか把握できなくなり、PM も場当たり的な反応が増え、QA も何が正しい振る舞いであるべきなのかを把握できなくなります。
その結果、本来ならばユーザーに提供されるエンドプロダクトがどのような UX を提供しているのか・本当に良いのか・悪いのかを把握しているべきである PM すら、仕様についてチームメンバーに聞かないといけなくなるハメに。良い仕様書は、常に更新され続け、チームメンバー全員にとっての「One True Source （ここに行けばすべての真実が書かれている）」をもたらすことができ、メンバー全員が「ユーザーに届く体験がどのようなものになるのか」をきちんと把握できている状態をもたらせるはずです。
3. 良い仕様書は、リリースまでの工期を劇的に短縮する
エンジニアの開発設計が正確になる
開発する機能についての詳細を可能な限り事前に記載しておくことで、エンジニアが機能の全体感を把握したうえで開発プランを設計することができるようになり、結果的に工数の削減につながることが多々あります。
おざなりな仕様＋追加開発が乱発された場合と、最初から開発内容が定義されている場合では、結果的に同じものが開発されていたとしても、その開発工数には天と地のような開きが生じます。
リリース直前の QA の工数が削減される
特に大規模機能の開発になると、どうしてもエッジケースの記載漏れや、エンジニアと口頭で決めてしまった（QAに周知されていない）機能などが出てきます。これが反映されていないと、終盤における QA のコストは平気で倍を超えるようになります。
しかし、良い仕様書はそういったケースをきちんと追加で記載しており、QA メンバーが「何が正しいふるまいなのか」を PM への質問・エンジニアへの質問等無しにストレスゼロで把握できるようになっているはずです。結果的に全体の QA 工数を削減することができ、リリースが当然早まることとなります。
4. 良い仕様書は、最終的な成果物の品質を向上させる
適当な機能の振る舞いが世にリリースされるのを防ぐ
良い仕様書は、細部まで機能の振る舞いを明確に定義しています。これをおざなりにしてしまうと、実際に発言されることはなくとも、
「仕様書に書いていなかったので、適当に決めました。」「仕様書に書いていなかったので、このバグは見逃しました。」「仕様書に書いていなかったので、ここは開発していません。」
等のケースが頻発し、結果的にリリース後、「こんなはずじゃなかった、こんな UIUX をユーザーに提供したい訳ではなかったんや…！」という PM のリードにより追加開発がパッチワークのように行われてしまいます。（ちなみにこれが何度も繰り返されると、チームメンバーからの信頼を損ない、故に追加開発もスムーズにいかず、というトリクルダウン的被害をもたらします。）
100% ではなくとも、良い仕様書はこういったケースをかなりの量削減することが可能なはずです。
5. 良い仕様書は、チームのモチベーションを増大させる
適当な仕様書は、チームを疲弊させモチベーションをさげる。良い仕様書は、チームの Why / What / How を定義しモチベーションをあげる。
おざなりな仕様書は
・なぜこのプロジェクトが発足したのかを伝えず ↓
・細かい機能の振る舞いを定義しておらず ↓
・PM の場当たり的な追加依頼が際限無く続き ↓
・開発工数を初期の 2-3 倍にまで肥大化させてしまい ↓
・それがいつ止まるかもわからない状態になり ↓
・出口が見えないチームを疲弊させ ↓
・チームのモチベーションをさげ ↓
・結果開発が遅延し、また機能の振る舞いが適当になり ↓
・最終的にエンドユーザーに届く UIUX を悪化させ ↓
・リリース後も追加開発が更に必要になり
といったデススパイラルを招きます。
これに対し、良い仕様書は
・この機能を開発することで期待されるインパクトを明記し、社外のユーザーのみならず社内にとってもそれがどれだけ期待されている（意味のある）プロジェクトであるかを伝え ↓
・プロジェクトのスコープを開発前から明確に定義することで不必要な仕様の膨らみを防いで区切りをチーム内外に明確にし（チームメンバーが PM に対して「それ、仕様書には無いので次にしましょう」と反論できるのが健全な体制ではないかと……） ↓
・細かい部分まで機能の振る舞いを定義することで開発中・後の大量の修正チケット（＝終わりが見えないトンネル）を防ぐことができ ↓
・余裕が生まれたチームメンバーから、仕様に記載されていない UIUX 追加修正案を受け取るまでになる
といったプラスのスパイラルを生み出すことができます。
最後の「チームメンバーから UIUX 改善アィデアを受け取る」というケースは結構稀ですが、非常にスムーズに行くプロジェクトにおいては、エンジニアや QA から「開発良いペースで進んでます。思ったんですが、余裕があるのでこの UX を追加しませんか？」と言った提案を受けとるまでに。個人的には、自分のプロジェクト進行中に起こる最も嬉しい出来事のひとつです。めちゃくちゃテンションあがります。
03# 仕様書の重要性が増していく 2 つの理由
さて、なぜ、今後「仕様書」の重要性が更に増していくのか？個人的に思っている 2 つの要因について短めに。ひとつは当然、いま全世界が影響を受けている COVID-19 による在宅勤務の加速。もうひとつは、今は前者の影に隠れてしまっているものの、グローバル開発・アウトソーシング開発の拡大が今後も加速し続けていく（して欲しい）ことに他なりません。
1. 在宅勤務において、コミュニケーションコストが増大している
在宅勤務が加速したことにより、エンジニア・デザイナー・QA陣は「PM の〇〇さん、ちょっと 5 分良いですか？」といった対面での仕様確認が（めんどうくさく）困難になりました。対話であればモックアップ等を同時に参照しながら 5 分で終わるものが、Slack による文字だけのコミュニケーションの場合、意思疎通がうまくいっていないと何十もの繰り返しの質問・回答が連なるスレッドとなってしまいます。
逆に、PM 側としても、「本当は 5 分の口頭確認で済む内容なんだよな…」と、ミーティングを設定するのも気が引けてしまうようになりましたよね。更には、オフィスでは気軽にエンジニアのところに行き「今の進捗を確認したい」といった気軽な確認も昔はできていましたが、現時点ではいちいちSlack での確認が必要となってしまう事態となりました。
2. 時差出勤があたりまえのグローバル開発が増えている（はず）
自分の PM 経験の 80% は 2 国間・3 国間にチームが分散していました。その際、チームの最も大きな拠り所となったのが「仕様書」でした。時差がある開発環境において、「仕様書の重要性」は 3-4 倍に膨れ上がるというのが個人的な感想です。
仕様書がおざなり＋時差が存在すると、寝ている間に質問が来て、朝起きて慌てて返事を返し、更に夜になるまでそのエンジニアからの返事を待ち～と、時差が無い場合に対して信じられないまでにスピードが鈍化します。
日本企業でも、主にアジア等にオフショア開発をしているところもあるかと思いますが、こうしたグローバル開発は、今後もどんどんと増えていくはず。「寝て起きたらプロジェクトがめっちゃ進行してた。」といった経験こそがグローバル開発の醍醐味・楽しさだとは思うのですが、仕様書の重要性はこうした環境において今後更に重要になってくるはずです。
04# 仕様書に含めたい 14 の項目・実践編
さて、良い仕様書のメリット、および仕様書が今後重要性を増してくる理由についてつらつら書いてきましたが、ようやく本題。個人的に定義している「良い仕様書」とは何か。どのような項目を仕様書に含めているか、についてガッッとまとめました。
画像にするとこんな感じに：
繰り返しになりますが、本項目はあくまで「僕が考える最大公約数の良い仕様書」です。僕が過去に働いていた会社・今働いている会社も割と違うフォーマット・項目を使用（存在しない場合もあるし）していますし、PdM の環境それぞれで良い仕様書の定義は異なるはず。
ただ、どれかひとつでも「あ、これ、入れた方が良さそう。明日からこれを含めた仕様書を書こう。」と思っていただければ筆者冥利につきます……一部 前記事 からの転載です。
1# プロジェクト発起に至った背景・解決したい問題を伝える
仕様書の先頭には、プロジェクト発起に至った背景・解決したいユーザーの問題を記述。実際の仕様レビューでも冒頭 5 分・締めの 2 分で「なぜこのプロジェクトが大事で、意義はどこにあるのか」をチームメンバー全員に可能な限り伝え、「会社の成長を左右する重大プロジェクトに参加している」と意識してもらえるようにします。
2# 検証したい仮説・達成したいことを簡単にまとめる
解決したい問題に対し、どのような仮説を以てこの機能を開発するに至ったのか？ユーザーがどのような状態になるのが理想なのか？を記載。特に仮説を証明するために実験的に開発するような機能の場合は後者をきっちりと。
3# プロジェクトの概略を 1-2 行でまとめる
仕様書そのものが何スクロールにもわたり、仕様レビュー会も 1 時間を超える……こんな場合は「全体像が最後になるまでわからなかった」という事例が起きえます。ほとんどの場合、全体を把握したのち→詳細を把握するという思考フローのほうが各人の理解力を向上させます。このため、自分の場合は、できるかぎり冒頭で「ざっくりいうとこのプロジェクトはこんなことをやるよ。」というのを仕様書および仕様レビュー会の冒頭でチームメンバーに伝えるようにしています。
また、これには以下のようなメリットも：
仕様書を読むのは開発に携わるチームメンバーのみでは当然なく、VPOP やエグゼクティブメンバー、PJM、自分が退社した後に関連仕様を探してあなたの仕様にたどり着いた別の PDM などなど、さまざまな人が訪れるはずです。なので、冒頭 1-2 行でプロジェクトの概略を書いておくと、こうした人が仕様書を全て読まずとも全体感を把握することができ、その先を読み進めるべきかどうかを判断できるようになります。
4# 計測する KPI と期待する動きをまとめる
開発機能をリリース後、どのような KPI をプロジェクトの成否のために検証するのかをまとめておきます。特に、(1) あがると期待している KPI (2) さがるかもしれない KPI の二項に分けて記載しておくと良いかと。
5# 実験用フラグ名・バリアント情報・振り分け% 等を記載する
実験用フラグ名などは、長大な仕様にちょろっと書いてあるような状態だと割とエンジニアに何度も聞かれてしまう項目となるので（体験談）、冒頭の目立つところにしっかりと記載しておきます。
6# すべてのリンクを仕様にまとめる
仕様書を見れば、全ての関連ドキュメントへのリンクが載っている状態を目指します。メンバーが「デザインファイルへのリンクはどこ？チケットどれだったっけ？あのドキュメントはどこ？」となってしまう無駄な時間・コミュニケーションの時間を極力削減。単純なように見えて、きちんと気をつけないとすぐにこの状態に陥ります。
・ 開発チケット（Epic/Story/Task 等）
・ デザインファイルリンク
・ QA プランへのリンク
・ 追加で来た質問に答えた内容
・ 関連ドキュメント
などなど、すべてをあますことなく仕様書ページの適切な部分に記載。（個人的には QA プラン / 追加質問等は仕様書の末尾へ。それ以外は先頭に記載しています。）
7# 「結果」欄：ローンチ後の検証結果を記載する
チームメンバーの多くは、リリース直後から「効果はあったのだろうか？」とやきもきするようになります。アクションに対するフィードバックは早いほうがモチベーションの維持にも良いとされています。したがって、仕様ページの前半に「検証結果」欄を空白で用意しておき、ダッシュボードの URL や BI からの検証結果があがり次第、追記。メンバーが気になった場合には、みずから途中結果を見に行けるような環境を形作っておきます。
プロジェクト終了後は、その検証結果を後日仕様ページの先頭に記載。これを行うことで、 1~2~3 年後に入った新しい社員が同実験の結果を容易に知りえることができ、「結果がどこにも残っていないから、もう一度やってみよう」といった無駄な工数を削減できます（個人的にはここ一番忘れがち……）
8# 現在の UIUX を軽くまとめる
開発する機能に関連する画面（リニューアルの場合はリニューアル前の画面など）のスクリーンショットと、ざっくりした振る舞いを記載。そこまで細かく書く必要に迫られたことは今のところないですが……（後人へ UIUX の変遷を伝える・ざっくりした現状の全体感をチームと共有しておく、くらい。そこまで大きなメリットはないかもしれない？）
9# 開発仕様：バックエンド側：を記載する
経験上、バックエンド側で必要な仕様を先に記載・ブリーフィングすることでプロジェクトの全体感・規模が伝わりやすくなり、後半のクライアント側仕様のレビューがスムーズに。また、中～大規模開発の場合はバックエンド側の開発規模・仕様がボトルネックとなることが多いため、仕様レビュー会の後半でどんでん返しが起きてしまうことがあります。が、前半にこれを持ってくるだけで結構その時間の無駄が防げるようになるはず。
10# 開発仕様：フロントエンド（クライアント）側：を記載する
完成したデザインのスクリーンショットを左に。右にその画面の振る舞いを可能な限り細部まで記載します。その画面でユーザーが取りえるアクションすべてに対するクライアントの振る舞いが理想。
大規模開発になってきた場合は、UIUX カラムそれぞれに対応するチケットへのリンクを掲載するとものすごく親切（めったにやらないけど…）
仕様が長大になっている場合は、絶対に見逃されたくない内容などがあった場合は太字・赤字等にしておきます。
11# 開発仕様：トラッキング：を記載する
開発機能に関連するトラッキング（イベント名・プロパティ名・発火条件）等を記載します。僕の場合は割と BI に助けて頂いています…… :-)
12# QA 関連ドキュメント・質問事項をまとめるスペースを作る
ここはほぼ QA メンバーの独壇場。QA プラン・工数等 QA メンバーが必要とするドキュメントを自由に記載してもらうスペースを用意。
また、QA との仕様確認が数十回にも渡るような大規模開発の場合（そして時差開発などの場合）は QA との質問・回答スペースを用意しておき、随時適当に更新していきます。
13# その他備考・関連部署への周知スケジュールなどをまとめる
その他特記事項・カスタマーサポートとの連携すべき事項・プロジェクトが成功した場合に次のフェーズでアップデートを行いたい内容・QA から質問が来てフェーズ 1 では見逃すことにしたエッジケースへの理想の対応方法・などなど、（多くはプロジェクト終了直前・直後に見直したくなる内容）項目を記載。
14# メンバーリストを追記する
PM・API・Client・Design・Mktg・Copy・QA 等々、関連メンバーの名前を仕様書の末尾に記載します。これを行うことで、プロジェクトメンバーの自覚はもとより、何よりも、1~2~3 年後に入った新しい社員が該当プロジェクトについて詳細を知りたい場合に問い合わせ先を簡単に把握でき、あなた（僕）が退職した後の無駄な摩擦を可能な限り削減できます。
……さて、読んでくださった諸姉諸兄諸氏のみなさまは、「意外と当たり前のことしか書いてないな」と思われたりしていないでしょうか？
ひとつひとつは大したことなく、革命的な項目など存在せず、割と当たり前のようなモノが延々と続いていたかと思います。
そうなんですよね。
ここまで書いておいてなんですが、自分が思うに、良い仕様書と悪い仕様書の違いは、こうした項目が、実際に必要とされた場合に備えてきちんと用意されているかどうかでしかありません。なので、良い仕様書を書けるかどうかは、「ちゃんとしっかり面倒臭がらずにやるかどうか」＋「定石の項目を抑えているかどうか」という、実は割と見も蓋も無いモノにしかかかっていない気がしています。
05# 仕様書フォーマットの実例
ということで、上記の項目をすべて含め、かつより実践に近い具体的な仕様書例を書いてみます。Google Drive で公開（予定）。なお、各項目はすべて自身が経験したこともない、 100% フェイクです。
（ちょっと力尽きたので笑、近日中に追加して Twitter でお知らせします）
06# 仕様書作成・ブリーフィングの際に気に留めておきたいこと 3 つ
最後に、自分が仕様書作成・ブリーフィングの際に気に留めていることをもう一度まとめてみます。項目、というよりも心構え。
1# 開発陣・QA陣の目線を意識した仕様を書こう
UX をゼロから考えた PM・デザイナーに対し、その仕様の全体図を文章・図のみから把握しなければいけない開発陣・QA陣には当然より大きな認知負荷がかかります。このため、可能な限りエンジニア・QAが読んでいるときの目線を意識して文章構成・段落構成を行います。
（これを行った場合、仕様書がこの note 記事さながらの非常に長大なものになる、というデメリットがありますが、（以下体験談）：何度か「もっと短くしたほうが良い？」とチームメンバーにフィードバックを求めたのですが、毎回「いまのスタイルを変えないで欲しい」と結構な勢いで猛反対をくらったので、たぶん総合的には良いはず…はず…です…）
2# 優先順位を意識してブリーフィングを行おう
悲しいかな、スペックレビュー後、多くの場合、ブリーフィングを行った際のフル仕様の 3 割から 5 割は初期リリースには含まれません。（そしてそのうちの 5 割は最後まで開発されず、日の目を見ない）このため、仕様内に含まれる諸機能は事前に分割しておき、それぞれに
・ P1 （必ず必要）
・ P2（ちょっと無理をしてでもできれば欲しい）
・ P3（余裕があれば開発しても良いかも）
と優先順位を割り振り、仕様書・仕様説明会でそれぞれの優先順位をコメントしながらブリーフィングを行います。こうすることで、仕様説明会後にはすでに削られる機能の 8 割が決まり、開発着手までの日数を軽減することができるようになるはずです。
3# 頻繁にアップデートを加えよう
仕様レビュー後には最低でも仕様ページの 10%、通常は 20~30%、大きな場合は 50% の書き直しを迫られることになります。更には、開発中盤～終盤になると、 QA から PM が想定できていなかったケースやエッジケースについて問い合わせが頻発。Slack で答えるだけでどうしても済ませがち（すみません）ですが、可能であればきちんと仕様書を最新の状態に保てるよう、頻繁にアップデートを繰り返しましょう。
07# 余談：仕様書を書き終えた？それは仕事の 50% が終わったに過ぎないのだよね……
仕様書を書き終わった後に最も心に留めて起きたいこと。それは、「仕様書は書き終わって、ようやく 50%。あとの 50% はいかにその中に含まれる情報の鮮度を保てるか。」というところ。直前項の繰り返しになるのですが、あまりにも重要すぎると思うのでもう一度。
基本的にはどの PM も「仕様書は常に更新し続けるべき」と意識しているかと思うのですが、これを 100% できている PM は少ないはず。というか、そもそもなぜ我々 PM は仕様書を書き終えても、「残り 50%」を重要視しないといけない状況に巻き込まれてしまうのでしょうか？
敵その 1 : 関連する機能と組み合わせた場合に必要となる追加対応
PM とチームが開発するひとつの機能は、多くの場合はそれのみでは動かず、関連する機能と組み合わせてはじめてユーザーがそれを使えるように＝完結した UX となります。
このため、開発している機能にとどまらず、既存の関連機能と組み合わさった場合の振る舞いを確認してからがリリースとなるのですが、これらの振る舞いを開発前にすべて把握することは不可能。必ず鉄壁の壁 QA の皆さまの力を借りる必要が出てきます。
その結果、開発中盤以降には、「この場合こうなってしまいますがどうしますか？」「今回の新機能の開発によって、別のここの画面で矛盾が起きることを見付けました」といった問題が次々と見つかり、これにチーム一丸で対抗していく必要があります。
こうした問題には数十の仕様修正・仕様追加がつきまとうのが常となりますが、これを仕様書に反映するのをサボっていると（以下略
敵その 2 : 誰も把握していなかった太古のレガシー仕様
以下は、特に中規模～大規模のサービスに関わっている方からは強い共感を得られるはずだと思っているのですが：
「既存の、とある機能の詳細について、責任者も開発者も退職しており、残っている仕様書は適当で、社内の誰ひとり現状を把握できていない。」
という恐ろしい阿修羅ケースがこの世には存在しており、そうした既存機能に立脚した新機能をリリースする場合、追加仕様・仕様変更はほぼ不可避となります。
そうした場合の追加仕様・仕様変更はもちろん仕方がないのですが、上述の通り、ここで必要となった変更もすべて仕様書にすべて反映していかなければ文字数が以下略。
敵その 3 : Slack / 口頭で変更を決定した仕様
ここまでお読みいただいた皆さまにはもう耳タコかもしれませんが、やはり Slack / 口頭で変更を決定した仕様は、どんなに注意していても割と仕様書に反映できていないのではないでしょうか？（僕はあまりできてない…）
こうした小さな変更が 1 つや 2 つなら良いのですが、複数のプロジェクトを抱えている場合は一日にこうした変更が 8~10 個、ピーク時には 10~20 と重なってきます。しまいには、一日の終わりに「さぁ仕様書を更新しよう。…あれ？あの仕様を決定した Slack スレッドどこだっけ…」という本末転倒・笑えない状態に。
ということで、「Slack / 口頭で仕様を変更したら、すぐに仕様書のページを開いて変更を反映し、その旨をまたチームチャンネルに投げる」くらいのルーティンを形作れるように最近は意識しています。
08# まとめ
以上、仕様書のフォーマットは状況それぞれであるという事を大前提としつつも、最大公約数をできるだけ取り入れた仕様書のテンプレートについて考察してみました。
できていないところ、自分もたくさんあります。ただ、個人的には本記事を書きながら「改めて本当の理想ってこうだよなぁ。これをできるだけ追えるようにがんばろう。」と思えたのが最大のアウトプットでした。
ご意見ご感想、ディスカッション大歓迎です。Twitter もやっているのでフォロー頂ければとても嬉しいです。励みになります。
09# 次回は PM の特性強化エリアについて
前回 はプロダクトマネージャーの職責全般について考察したマクロ視点の記事。本記事は「仕様書」という、ものすごくミクロなトピックにフォーカスしてみました。ので、次回はまたマクロ視点に立ち返り。
ということで、次記事は以下からどうぞ：
〇〇 強化型人間を目指そう：PM + プロダクトに関わる人の 20 の強化エリアとプチキャリア論
ここまでお読みいただき、ありがとうございました。本記事のどこか一部でもが参考になったとすれば、本当に嬉しいです。
それでは、また次回記事にて。
お断りとお願い
本稿および note の全記事は個人的な解釈に基づいたもので、所属していた/している会社の意向・見解とは一切関係ありませんので、その旨ご理解いただけますと幸いです。
いいなと思ったら応援しよう！
