PMによる仕様書では補えない運用フェーズに強いドキュメント作り

メルペイでプロダクトマネージャをしてます、さとじゅんです。

メルペイでto B向けプロダクトの開発をしてます。なので、主にto B向けプロダクトについての話になります。

たまに思うこと

突然ですがPMは新しい機能を作る時は仕様書を書くことが多いですよね。
PRD（プロダクト要求仕様書）とかですね。

「Why」とか「What」とか「How」とか書きますよね。

それでリリースして運用していくと思うのですが、運用中にいろんな課題をこなしていくうちにひとつの事に気づきます。

「もう少しビジネスとシステムとオペレーションがひとつのつながりで理解できる資料が欲しいな」と。

to C向けのプロダクトに比べ、to B向けのプロダクトにはセールスやオペレーションのチームなど1つのプロダクトに関わる人が多くなる特徴があると思います。

PLGという考え方もあると思いますが、だいたいのto B向けプロダクトがto C向けプロダクトより人手はかかると思います。

そのためにもっとシステム単体のことだけでなく、それを通じた事業全体を理解しておきたいところです。

これ、運用していく中でとても重要な観点じゃないかなと思っているのでこの点について少し書いていきたいと思います。

😁 PRDの良いところ

まずはPRDの良いところについて書いていきます。

新しい機能を開発する時に最適

なんでそのシステムが必要なのか、どういう背景があるのか、なにを成し遂げたいのか、どんなKPIを狙うのか、どんな挙動になるのか、逆になにをしないのか、などなど、これから作る機能について必要な情報が理解できます。

特にプロダクト作りの北極星とも言える「Why」がしっかり書かれていることでチームメンバーの目線合わせができるのが良い点ではないでしょうか。

プロダクト作りに携わる人には最適なフォーマット

PMだけでなく、デザイナー、エンジニア、QAなどなど、機能を作ってリリースしていくまでの過程においては最適なフォーマットなのではないでしょうか。

場合によってはシステムのフェーズ切りまでを、記載するなどして、あるプロダクトをどうしていきたいのかまでが一目瞭然となるなどメリットがあると思います。

😢 PRDだと足りないなと思うところ

「点」はわかるが「線」でわからない

システムのことを理解できても、システムを推進していく時に全体としてどんなことが起きているのかが理解できません。

運用フェーズでは全体を俯瞰してのシューティングや、チューニングが必要になってくると思いますので、全体感を把握していることが重要になると思います。

またPMがそのシステムを通じて他の職種の人がどう動いているかがPRDだとわからないと思います。

運用に入った時に情報が足りない

ある特定のシステムに関しては、細かい背景含めよくわかります。

ただそのシステムをどのチームがいつどのタイミングでどう使っているのかを理解することは難しいと思います。

データの構成がどうなっていて、どのtableのデータを参照するとどんなデータが取れるかまではわかりません。

自分が作って喜ばれた資料

そんな課題があったので、わたしは自分の担当プロダクトでは下記の資料を作ってみました。

名付けて「ざっくりわかるシリーズ」

これは主にPM向けオンボーディング資料であり、他チームのPMに見てもらうことを想定としてたんですが、結果的にそのシステムに携わるエンジニアにもためになるinputにつながり、また、CS職の方やセールスの方など非エンジニアの人にも見てもらえる内容となりました。

どんな内容になっているのかみていきましょう。

資料の概要

大きく理解したいのは3点

1. ざっくりとしたシステムの概要

2. データ構造

3. 付随するオペレーション

目次

1/ なにをするシステムなのかをざっくり説明（What）
2/ システムの仕組みをざっくり説明（How）
3/ システムの全体アーキテクチャを説明（SystemArchitecture）
4/ 内部的にどんなデータ構成になっているか説明（DB）
5/ このシステムを使って運用観点ではどのようなことが行われているのか説明(Operation)
6/ 覚えておくべきイレギュラーケースに関して説明（EdgeCase）
7/ Appendix

1/ なにをするシステムなのかをざっくり説明（What）

ざっくりとそのシステムがなにをするものなのかを記載。
ここではPRDと違うのでざっくりとなるべく絵を使ってわかりやすく解説します。

2/ システムの仕組みをざっくり説明（How）

仕様書まではいかないものの、どんな挙動をする機能なのかざっくり解説します。

3/ システムの全体アーキテクチャを説明（SystemArchitecture）

特にmicroserviceを採用している場合は、どのmicroserviceをどういう順番でリレーしていくのかのアーキテクチャがあると全体の理解が深まります。

4/ 内部的にどんなデータ構成になっているか説明（DB）

運用していると必ずあるのが、ログやデータの調査系のタスク。
これを行ったり、仕様上重要なデータを認識するためにも、データベースのtable名、カラム名について重要なポイントだけでも抑えて列挙しておきます。
BigQueryなどの分析環境がすでにあって、非エンジニアなら誰でもたたけるような環境であれば、なおさら理解しておくと、自分でさまざまなデータ取得ができるようになるはずです。

5/ このシステムを使って運用観点ではどのようなことが行われているのか説明(Operation)

このシステムの前後では外部のステークホルダー、または社内の別チームがどんなオペレーションをしてどのようにこのシステムを利用しているのか説明します。
データがどう登録されて、どう使われていくかなど、ここでシステムを点ではなく「線」の情報として理解していきます。

6/ 覚えておくべきイレギュラーケースに関して説明（EdgeCase）

運用していくと必ず良く起こるイレギュラーケースにでくわします。
または運用上抑えておかないといけないイレギュラーケースが出てきます。
そのあたりの勘所をまとめておくと、関わる誰もが同じ目線でシステムに携わることができます。
多少システマチックな話でも書いていきましょう

7/ Appendix

このシステムを使うセールス職、CS職の方々が別途この資料にまつわる資料を作っているかもしれません。
そういったリンクをペタペタと貼っていきましょう。
例えばこんなものがリンクされているとよさそうな気がします。

経済条件、ビジネス要件、担当チーム、ステークホルダー、追うべきKPIなどの資料のURL

制作期間

この資料、1週間あれば作れます。

作ってみると、「それなら早く作っておけばよかった」と思うばかりです。

個人的にはどこかのQで自分のOKRに入れてしまって無理くりにでも作成する時間を作ってしまうのも手かなと思っています。

作ると良いタイミング

だいたいこの手の資料は、リリース前に運用を見越して作ろうとして作れないとかが多い気がします。

でもわたし的には運用が慣れてきたタイミングで作るのが良いと思います。

ある程度PDCAがまわってきて、関わる人からの質問もどういうのが多いかだいたいわかってきたタイミングで、みんなの悩みを解決できる資料としてまとめあげるととても良いです。

またこの資料を作ると作り手自身が事業とシステムのことを深く理解できます。

会社によってPMの役割が違ったりすると思いますが、システムだけでなく全体感が理解できるという点では良いのではないでしょうか。

さいごに

いかがでしたでしょうか？
PRDだけでは足りない情報はあると思うので、補う形でこのような網羅性があると、さらにシステムや事業の解像度があがるのではないでしょうか。

また、今日紹介してきたものは、PMの知識を民主化するためにも必要なドキュメントなんじゃないかと思います。

事業を推進できるのはえらいですが、だれでも同じことをできるようにするのはもっと偉いんじゃないかと思います

そのためにドキュメントを作って、ドキュメントを独り歩きさせることで、知識を民主化するというアプローチはおすすめです。

なにより人に感謝されます。

〜最後に告知〜

今回の内容もキラキラPMというよりは、泥臭い地味PMに必要なスキルだったのかもしれません。

ちなみにheyでPMやられているnagashimaさんと一緒に地味PM のmeet upをしようかと思ってます。

地味PMとして、地味だけど輝いている話をPM同士で語り合い、讃えあう会をしたいと思ってまして、そこで発表してくれる人を募集してます。

5分くらいで地味PMエピソードを募集してます。

われこそはという方、ぜひtwitterの #地味PMmeetup でコメントしてください！

私も地味PMのひとりとして、なにかお伝えできればと思っています。

最後までお読みいただきありがとうございました。
よかったらtwitterもフォローしてみてください。

さとじゅん
https://twitter.com/junsam22