新人プロダクトマネージャーに必要な3つのチェックリスト

こんにちは、freee株式会社でアソシエイトプロダクトマネージャーをやっている poe です。きょうは freee Developers Advent Calendar 2017 の8日目。新卒でアソシエイトプロダクトマネージャー（以下PM）になってから失敗したことを元に作成した、3つのチェックリストについて話したいと思います。

自分の略歴

社会人歴2年目の新人PMです。

2016年に新卒でfreeeに入社してセールスに入り、2017年1月からプロダクト戦略チームというチームに配属になりました。肩書はアソシエイトプロダクトマネージャー。いわゆる新人PMですが、やる気と行動力だけは負けない所存で修行中です。

悩み

仕様の手戻りが頻発していました。

4月からプロダクトの仕様を決めるようになったものの、右も左もわからない状態。先輩に見てもらいながら仕様を書き進めるも、あらゆるチェックポイントで、「この場合どうなる？」「この文言にしたのはなぜ？」というツッコミに対して明確な回答を出来ず、仕様の完成まで通常の4倍時間がかかる状態でした。

f:id:yushisawa2171:20171207112604p:plain

チェックリストを作るキッカケ

6月にジャーマネとの1on1の際に、手戻りを振り返ってみました。すると、手戻りの原因はほとんど基本的なことを徹底すれば回避可能なことが分かりました。ただし課題は「徹底できていない」ということでした。「意識する」では対策になっていません。具体的なアクションに落とし込む必要がありました。

そこでマネージャーから紹介してもらったのがこちら
「アナタはなぜチェックリストを使わないのか？【ミスを最大限に減らしベストの決断力を持つ！】」

アナタはなぜチェックリストを使わないのか？【ミスを最大限に減らしベストの決断力を持つ！】

作者: アトゥールガワンデ,吉田竜
出版社/メーカー: 晋遊舎
発売日: 2011/06/18
メディア: ハードカバー
購入: 24人クリック: 539回
この商品を含むブログ (46件) を見る

ハリケーン・カトリーナ、ハドソン川の奇跡……。
想定の枠を超えた大災害や大事故に直面した時に人はどう行動したか。
リーマン・ショックを乗り切った投資家の決断とは？
大切なことは人間の限界を認め、他者と協力し、「チェックリスト」には絶対に従うこと。
あなたが同じ失敗を何度も繰り返してしまうのはなぜなのか？
失敗が起きるのは、怠慢のせいでも努力が足りないせいでもない。
「チェックリスト」こそミスという名の病を治療する唯一の処方箋である。

タイトルだけ見た時、ぶっちゃけ興味はありませんでした。 チェックリストなんて平凡な解決手段に見えるし、使っているとまるで自分がなにも覚えられないかのように見えます。

しかし読了後、今すぐ取り入れてみようと思いました。執筆者は、失敗の大部分は基本的なステップを忘れる・軽んじることが原因であり、パイロットと医者を例に、チェックリストの有効性を訴えています。パイロットと医者、それぞれ同じくらい複雑な作業が要求される職種です。パイロットは離着陸やエンジン停止などのトラブル時の対応を、必ずチェックリストに従って解決してます。そのため航空業界では事故率が低く、最悪の事故も起きにくくなっています。一方で医者の場合、「手を洗う」「手術前に患者のアレルギーを確認する」「手術するチーム内で自己紹介を行う」など一見凡庸なステップを軽んじる・忘れることが、医療事故や手術失敗の原因の大部分を占めていると主張しています。人間の能力の限度を認めチェックリストを徹底している航空業界と、医療業界の対比が面白い。

プロダクトマネージャーの場合も、欠くと失敗につながる基本的（凡庸に見える）なステップがあるはずと思い、自分の過去の失敗を踏まえたチェックリストを作成しました。

作成したチェックリスト

ニーズは洗い出せているか？

誰がどういった背景で要望をあげたのか？

スコープは具体的か？

誰にとっての仕様変更か
なんのための仕様変更か
対象者が該当の機能を使う際の前提条件は具体的か
- ユーザーの知識
- 使うタイミング
課題は具体的か

正しいユーザー理解を担保できているか？

下記を対象に手を入れる機能のカバーするユーザー業務の説明を行ったか
- 業務に詳しい人
- 詳しくない人
上記を関係者と合意したか

解説

ニーズは洗い出せているか？

該当の機能に関するお客様からのご要望を、一つ一つ紐解いていき、背景を洗い出します。「◯◯の機能が欲しい」という同じご要望が複数あっても、必ず同じ背景を持っているとは限りません。誰がなぜその要望を出しているのか、という背景を洗い出していきます。

一見同じ要望であれば、一緒くたに対応してよいように見えますが、ご要望の背景によっては、「◯◯の機能が欲しい」という解決法がベストではない場合があります。したがって、背景を丁寧に洗い出して、なぜそのご要望が出てきたのか、ニーズを書き出していきます。

ここでは、該当する機能要望の背景すべてをクリアにしていくことがゴールになります。

【実際の失敗例】このステップを曖昧にこなした結果、ニーズを網羅できず対応すべきニーズに未対応な仕様を作ってしまったという経験があります。幸い大きな仕様変更ではなかったので、手戻りによって余計にかかった時間は1週間にとどまりました。

とはいえ、このステップを徹底できないと、どこまで書き進めても自分の仕様に自信をもつことができないので、精神衛生的のためにも徹底すべきステップです。

スコープは具体的か？

どんな仕様検討においても、要件を限定するために、仕様変更の目的を定めてスコープを絞ります。洗い出したニーズを調べて、どのニーズに対応するのか・なぜそのニーズに対応するのかを記載して、関係者の意識を揃えます。

この記載が無い、もしくは緩く条件しか記載されていないと、次のような問題が起きます。

①機能要件が広がり続け、本来対応が必要がない機能まで追加してしまう
②関係者それぞれが重要だと感じる、異なったニーズに基づいて仕様のアドバイスをくれるので、非生産的な議論に陥る

【実際の失敗例】私の場合、スコープを具体的に書かないために①が起きました。広がり続ける機能要件を前に、呆然とした覚えがあります（笑）すでに仕様を作りはじめてしまっていたので、仕様の作り直しに4週間かかってしまいました。

正しいユーザー理解を担保できているか？

freeeはtoBのサービスであり、課題の前提となるお客様がされている業務フローや状況を正しく理解して仕様を作る必要があります。本を読んだり、ユーザーインタビューを行うことで定性的な知識は手に入りますが、その理解が正しいか、品質を担保する必要があります。

一つの方法として、その業務を知らない人・とても精通している人に説明することが有効です。無邪気な質問からニッチな質問まで、その業務に精通していないと回答できない質問を受けて自分の理解度を確かめられます。

【実際の失敗例】私の場合、理解した気になって仕様を作ったものの、仕様の説明にあたってその前提を聞かれてもはっきりと答えられず、自分の知識不足が露呈したという経験がありました。間違った・足りない知識に基づいた仕様は間違う可能性も高く、ユーザー理解のために2週間手戻りしました。

どう活用しているか

上記はすべて当たり前に大切なことです。おそらく誰もが「当たり前」と思われることと思います。書いておいてなんですが、私もそう思います。しかし重要なのは、これらを漏らさず実行することです。

ここでチェックリストです。

仕様書を書くときは、最初にチェックリストをドキュメントにベタ張りにして、一つ一つのリストに回答するようにしています。そのドキュメントを関係者と共有することで、意識を揃えた上で、機能の具体的な仕様を書き始めます。関係者と共有する前提を具体的にすることで、より手戻りが少ない仕様書を作成できるようになるはずです。

(実際の仕様書) f:id:yushisawa2171:20171207113217p:plain

そして二番目に重要なのは、チェックリストを改善し続けることです。失敗した原因を突き詰めて、より分かりやすい・優先度の高いものに絞ったチェックリストに改善していくことで、肥大化したただのマニュアルになることを避けることができます。従って、私も今回紹介したチェックリストを更新し続けていく所存です。ちなみに冒頭であげた本によると、航空会社にはチェックリストを改善するためのチームが存在するそうです。

忘れちゃいけない、けど基本的なこと。ぜひ皆さんもチェックリストにしてみて下さい。きっと驚くほど、失敗が減るはずです。