見出し画像

仕様書?PRD?要件定義書?Design Doc? プロダクト開発のドキュメントを作る前に、みんなで揃えたい考え方

カミナシPMのかこもえ(@kakomoe3)です🐙
このブログはプロダクトマネージャー Advent Calendar 2022の16日目の記事です。

💡このnoteはなに?
プロダクトに関するドキュメントの種類呼称別の整理と、どうしたら現在のチームにドキュメントに関する目線合わせのアイデアを書いたものです

💡誰のためのnote?
プロダクト開発に必要なドキュメントについて日々心を悩ませている人

ドキュメントの話に着地をつけたい


誰かが言い出すアレ

今までの経験上、どこに配属されても、プロダクトに関するドキュメントとして誰が何を書き、そして運用するのか、という議論が起きないことは1度もない。

プロダクトに関するドキュメントは、PRD・要件定義書・仕様書・Design Docなど、さまざまな呼称があり、会社や部門によってさまざまな使われ方をしている。
そしてそれぞれの言葉には単一の定義があるわけではない。
そもそもドキュメントなんていらんて!という主張に関しても、いや、ドキュメントは絶対必要やで!という主張に関しても、この中のどれか1つの自分自身の理解されている定義を前提として会話されていることが多そうだ。

実際ドキュメントの「呼称」そのものはあまり意味がない。
しかしながら呼称はわかりやすいため、議論に用いられることが多く、認識齟齬を起こす類のものだったりもする。

このnoteでは、そういう認識齟齬が起きうる議論をする前に、ここの認識を揃えておくとよさそうだということについて書きたいと思う。


プロダクト開発において、なぜドキュメントが必要なのか?

整理をする前に、なぜドキュメントが必要なのかについて触れておきたい。

アジャイルソフトウェア宣言には、「包括的なドキュメントよりも動くソフトウェアにより価値をおく」と書かれている。

ん?じゃあいらないの?という話になりがちだが、「左記(包括的なドキュメント)のことがらに価値があることを認めながらも、私たちは右記(動くソフトウェア)のことがらにより価値をおく」という記載があり、ドキュメントいらんぞ、と言っているわけではない。

ではドキュメントはなぜ必要なのか?
端的にいうと、チーム開発における非効率な間接業務のコストを下げられるから、と言えるかもしれない(あれ、カミナシもそんなプロダクトだったような...?🤔)


いいことだらけのドキュメント


1. 早く正確に伝えられる

スタートアップ初期はドキュメントがないケースが多いと思うが、スタートアップはより大きな価値を提供することを目指す組織だ。
組織が大きくなると、コミュニケーションパスが増える。
そうすると「話した方が早い」は嘘で、結果的にドキュメントを書く方が、早く正確に情報が伝わる。
そして往々にして、昔の生き字引のメンバーも、昔の意思決定の内容は忘れがちになる。そうすると、話すために調査をする、みたいな付随的なタスクが発生したりもする。

さらに昨今リモートワークや働き方に多様性が出てきたので、同期的なコミュニケーションをとるための間接的な調整コストも大きくなってきている。調整している間に書いた方が早い、ということすらある。

2-3人の少人数で永遠に開発を続けるチームなら、あるいは必要ないかもしれない。


2. 意思決定の質とスピードが上がる

特に継続して運用、改善をしていくプロダクトにおいては、過去の意思決定は未来の資産になる。

企画検討・修正判断時は、過去の意思決定の背景・前提を知ることで、車輪の再発明を防げたり、当時の前提と現在の前提、経緯を比較し適切な判断に早く辿り着くことができる。

運用時も、お客様から「これはバグです!」というお問い合わせがあった際に、意図した挙動でない(本当にバグな)のか、過去に何かしらの判断があって意思決定した仕様なのかがわかるだけでも、対応方針を素早く決めることができるだろう。
お客様から質問があった際も、ドキュメントがあることで素早くお客様に正しい情報を伝えることができるし、お客様自身で解決を促せるかもしれない。

これも、追加機能開発や改善を全くしません(自社での保守だけです〜)というプロダクトなら、ドキュメントは必要ないかもしれない。
保守運用を受託している会社だとすると、自社を守るためにドキュメントは必要になってくるだろう。


3. チーム開発の質とスピードが上がる

チーム開発においては、特に必要性をあえて言及するまでもなさそうだ。

大きな機能であるほど、認識齟齬や手戻りを最小限にし、抜け漏れに気づきやすくするためにもドキュメントは有効だ。
1.にも準ずるが、複数人で開発している場合はよりその効能が大きくなる。複数の目をいれることが、ドキュメントそのものの品質をあげることにも繋がる。
また、設計フェーズにおいてもなぜその意思決定をしたのかの背景情報を残しておくことで、レビューの品質も上がる。

逆にいうと1人だけで開発している場合はコミュニケーションパスもくそもないので、ドキュメントを書いてる暇があればコードを書け、となるよね💻
プロダクトがPMFする前の0→1フェーズ、ひたすらスクラップアンドビルドしているときとかも、仕様はすぐに陳腐化するのでドキュメントはむしろスピードを落とす結果にもなりうるとも思う。


チームやプロダクトの状況、フェーズによって必要なドキュメントは違う

ドキュメントはとても価値がある。価値があるが、チームの大きさやフェーズによってはドキュメントは不要だったり大層なものを書かなくてもよいことだってきっとあるはずだ。


プロダクト開発で、よくあるドキュメントの種類

プロダクト開発における、ドキュメントの種類はたくさんある。
仕様書・PRD・MRD・Design Doc・ADR・設計書・要件定義書・要求仕様書.....

そう、色々ある。

以下は、一般的なシステム開発のV字モデルの図だ。


そして、なんとなく、こんな感じのイメージがあったりなかったりするのではないだろうか。
※Design Docは、エンジニアリングの設計に関するドキュメント、PRDと似たドキュメントの2流派ありそうだったので2箇所記載している。異論は認める。


そこで考える。わたしたちは、雰囲気でドキュメントと言っていないだろうか、と。。
そして思う。ドキュメントのためにドキュメントを書くと、キリがないぞ、と。。


「なんで仕様書がないの?」と言い始める前にするとよいこと

さて、「ドキュメントなんでないのぷんぷん!過去の誰かがサボってたな〜!」と誰しも1度は思ったことがあるだろう。そして、誰しも1度は思われたことがあるだろう。

ちょっと待ってほしい。
なんで仕様書がないの?という前に立ち止まって確認しよう。
あなたの言う「仕様書」は、彼女の言う「仕様書」ではないかもしれない。
あなたの思う「Design Doc」は、彼の思う「Design Doc」と似ても似つかないかもしれない。

ぶっちゃけ名称はどうでもよいので、なんのために、どんなドキュメントが必要なのかの目線を合わせられるとよいのではないかと思う。


チームで目線を合わせるための項目

具体的にどういう項目を整理すれば目線が合うか。
シンプルに5W1Hでの整理が個人的な好みだ。

💡考えるおすすめ順番💡
Why👉Who👉When👉What👉Where👉How

まずは、目的および関係者、ユースケースに応じた記述すべき最低限の情報の目線を合わせる。


  • Why:ドキュメントの目的

  • Who1:書き手は誰か(複数になるケースもある。主体を決めておくとやりやすい)

    • When1:書くタイミングはいつか

  • Who2:読み手は誰か

    • When2:読むタイミング(ユースケース)はいつか

  • What1:何を書くか


これらが決まったら、次により詳細な情報を整理する。


  • What2:どういうものを対象に書くか

  • Where:どこに書くか

    • ストック情報かフロー情報か

    • バージョン管理が必要かどうか

    • 読み手がアクセスしやすい場所か

  • How1:どのように書くか

    • 図やイラスト、もしくは表など必要な要素はあるか

    • Whatの粒度や書き方、フォーマットはどうするか

  • How2:どのように運用するか

    • 完成の定義、完成までどのようにもっていくか(承認フローやチェックなど)

    • 最新化する運用が必要か、誰がどのタイミングで編集するか



自分達に必要なドキュメントを考えてみる

以下、整理したものの一部の例を紹介してみる。

これはいわゆる「要求定義」「PJT定義」といったフェーズのもので、戦略的に重要だったり大きな機能あれば重厚になるし、目的が誰からみても明示的だったり(たとえば不具合やUXの改善など)、小さな機能であれば省略したりこれ自体作らないこともある。

たくさん書きすぎるとそれ自体が負担になって続かなければ元も子もないので、自分たちのチーム状況やプロダクトフェーズなどを鑑みながらこの整理自体をアップデートしていくとよいと思う。


チームでドキュメントを運用する上でのコツ

最後にチームでドキュメントを書き、運用する上でのコツ(というか姿勢?)について書いてみる。


  • 書くと決めたら書く。でも中身は最初から完璧を目指さない(書くと決めたら、まずは不十分でも書くことが大事。書かないと振り返りもできない)

  • 全員で作り、育てる(誰か1人のドキュメントではなくチームのためのドキュメントなので、みんながオーナーシップをもつ)

  • たびたび見直して改善する(チーム状況もプロダクトフェーズも変化するものなので、過去のベストは今のベストではない)

  • ドキュメントの項目を埋めることを目的にしたら終わり(目的はなんだっけ...!)

  • 最初から完璧を目指さない。とにかく書く(大事なことなので2回言いました)



ということで、みなさまよいドキュメント生活をお過ごしください(^^)/~~~


最後まで読んでくれた人は、ぜひスキ❤️をポチっと押してください。
元気が出ます🐐心の栄養です🌳


🔈カミナシは全方位的に募集しています🔈
カミナシのPM組織はまだ立ち上がったばかりです。ほぼ0→1です!一緒に3,900万人の仕事を楽しくしませんか?

カミナシPMのEntrance Bookはこちら

YOUTRUSTの募集はこちら

カジュアルに話したい!という方は、Twitter DMなどで気軽にお声かけください🕊


この記事が参加している募集

PMの仕事

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