見出し画像

作り込まれたドキュメントよりも大事なこと

お久しぶりです。別所 (@gb_pdm)です。

この記事はプロダクトマネージャー AdventCalendar 2024の17日目のエントリーになります。

最後に公開したnoteの記事がプロダクトマネージャー AdventCalendar 2022となっており2年ぶりの投稿となります。


What's This?

ここ最近PRDやPBI、ロードマップなどのドキュメントを作り込む時間がなく反省する時期が続いていた自分が、同期コミュニケーションを中心に仕事をしていく中で大事なことに気づき始めた話です。

いかに自分が未熟で周りに助けられているかという話でもあります。

結論、今の自分が作り込まれたドキュメントよりも大事だと思っていることはこの2つです。
・ユーザーと課題の解像度を上げること
・課題の解決に向けて背中を預けられる仲間がいること

今でもドキュメントは絶対にあったほうが良いと思っていますし、わかりやすいドキュメントがあることに越したことはないと思っています。

ただ背中を預けられる仲間がいて課題と向き合う時間がとれているのであればドキュメントの完成度に固執する必要はないのではないかと思うようになりました。

ドキュメントよりも大事なことに気づいたきっかけ

雑なPBIでも文句を言わず任せてくださいと言ってくれたスクラムマスターの存在

素晴らしいPBIテンプレートを用意してくれたにも関わらず自分が書き込む時間がなくチケット名のみ起票してリファインメントに臨むことも多かったです。(今でも…)

本当はもっと細かく仕様や受け入れ条件を書き込んでもらいたいはずです。

そんな中でも文句を言わず
・「技術負債のようなPBIは自分たちで仕様や受け入れ条件の記載もできるのでこちらで埋めていきますね」
・「技術的な話や具体的な作業内容は開発チームでも進められるのでニーズや目的のところだけ簡単に埋めてもらって後は口頭で補足説明してもらえれば大丈夫です」
と言ってくれ、なるべく自分がユーザーと向き合う時間を捻出できるようにサポートしてくれています。

### Background / 背景
<!-- 当該ユーザーストーリーが求められる背景や概略 -->

### User Story / ユーザーストーリー
<!-- ユーザーが特定の目的を達成するためのニーズや期待を簡潔に表現する -->

#### Persona / ペルソナ
<!-- 誰がそれを求めているのか -->

#### Goal / ニーズ
<!-- ペルソナは何を求めているのか -->

#### Reason / 目的
<!-- それが実現されるとどんな目的を果たせるのか -->

### Feature or Work / 機能(作業)
<!-- ユーザーストーリーを叶えるために我々が何を行うのか -->

### Acceptance Criteria / 受入基準
<!-- この機能(作業)がユーザーストーリーを満たすための基準 -->
- [ ] 

### Definition of Done / 完了の定義
<!-- このPBIが完了となるための条件 -->
- [ ] 受入基準を全て満たしていること
- [ ] 当該機能がリリースされていること
- [ ] ステークホルダーへのリリース報告が完了していること

同じ目線を持った爆速デザイナーの存在

今の自分のチームにはエンジニアの他にデザイナーが1名います。
これまでユーザーインタビューやユーザビリティテストもずっと2人3脚でやってきました。

リサーチ業務から情報設計、UIデザインまで何でもやってくれます。

流石にプロダクトマネージャーとしてワイヤーフレームや画面遷移図くらいは自分で作成するよとデザイナーに提案したのですが、

デ「私、作業早いんで大丈夫です。私は今みたいに思っていることをその場でばーーっと話してもらってその場でデザインに起こすやり方が待ちも少ないので良いと思っています。」

私「た、たのもしすぎるーーー!」

というわけでデザインプロセスにおける成果物もかなりお任せしてしまっています(汗)

これらの経験を経て気付いたもの

これらの経験を経てふと自問自答したことがあります。

「僕は誰のために洗練されたドキュメントを作ろうと思っているのか?」

自問自答した結果、「自分がプロダクトマネージャーとして優秀であることを示したい」「プロダクトマネージャーとしての成果物をわかりやすく残したい」「チームの役に立っている感を出したい」といった気持ちが背景にあることに気づきました。

このことに気づいた時に、こんな気持ちのためにドキュメントを作り込むのであればその時間をユーザーのために使うべきだと感じました。

そして今自分は仲間に支えられながら、以前よりも多くの時間をプロダクトの未来や解くべき課題の発見に向き合う時間として使えるようになってきています。

同期コミュニケーションで気をつけている事

ドキュメントが雑になり口頭でのコミュニケーションが増えているので、同期コミュニケーションにおいて意識している点を最後に紹介します。

①議論の上決まったことは雑でもよいからその背景とセットでテキストに残す

デイリーやリファインメントの場での議論を重要視していて、そこで決まった方針や仕様については後で見返せるようにチケットに忘れず追記しています。

その際にどういった理由でその仕様になったのかも明記するようにしています。

②認識のズレに細心の注意を払う

下記のようなプラクティスを活用しながらドキュメントに頼らず認識ズレが起きづらい工夫をしています

・プラニングポーカーでPBIに対する「不確実性」「作業量」「複雑性」の認識ズレが無いかを確認する
・デイリーで5fingerを行いスプリントゴール達成の進捗に対しての認識ズレが無いかを確認する
・デイリーでこまめにデモを実施してもらい非言語部分の認識連れが無いかを確認する
・会話の中で「誰が」「どういう条件で」「どういう操作をしたときに」「どういう挙動になるか」のいずれも省略せずに伝えるようにし、相手が話す際にも省略されている場合には省略された内容の確認をする

③この状況を当たり前だと思わない

仲間のサポートがあってこの状況が作られていることに常に感謝すること

さいごに

いかがだったでしょうか。

今回紹介した出来事に加え、プロダクトマネージャーのしごとの『第9章 : ドキュメントは無限に時間を浪費する』に書かれている内容や組織を変える5つの対話の2冊の書籍も自分の考え方を変えるきっかけをくれたとても素晴らしい本でした。

もし興味がある方は是非読んでみてください。

というわけで今回は以上となります。
最後まで読んでいただきありがとうございました!

参考


いいなと思ったら応援しよう!