AIR Design for Marketing 事業部プロダクトマネージャー（以下、PMと表記します）の安永です。エンジニアなのですが今年からPMもやっています。
PMってやること多いですよね。巷ではミニCEOと言われることもあります。実際は組織やプロダクトの状態によってPMの定義は様々だと思いますが、未定義の場合は「プロダクトのために何でもやる人」という扱いを受けるのではないでしょうか。
当事業部でもPMという役割ができたばかりでまだ定義が曖昧なのですが、何でもできちゃうPMがいることもあってかPMは何でもやる雰囲気があります。
勿論何でもできることに越したことはないのですが、駆け出しPMの自分にとっては正直厳しく、タスクに溺れて本来PMがやるべき「プロダクトの方向性を決める」ための仕事ができなくなっていました。数ヶ月前の話です。
それからいろいろ試行錯誤を経て、今は少しは息継ぎできるくらいにはなってきました。
この記事では当時陥っていた問題と、試行錯誤の一部を紹介し、今どのように改善されたかを振り返ってみたいと思います。
プロダクトの方向性が決まらないうちに走り出すプロジェクト
私が担当することになったのは、社内の特定業務（といっても成熟した固定的なプロセスではなく、多様で変化し続けているプロセス）における課題を解決するためのプロダクトでした。
既にビジョンはあったものの、ビジョン実現のためにどんな課題を解決すればいいのか、どんな機能を作っていけばいいのかを示すプロダクトの方向性は決まっていない状態でした。
今思えばここでプロダクトの方向性を一時的にでも固めておくべきだったのですが、既にざっくりと機能の要求があったことと、「エンジニアのリソースを余らせるのはダメ」という指示があったこと、そして私のPM理解が浅かったためSTOPをかけれず、開発が始まりました。
（ちなみにこのときの機能の要求とは、「とあるツールで情報収集をしているが大変なので効率化してほしい」という要求でした。今なら「なぜそのツールで情報収集をしているのか？」「そのプロセスはどのくらいの頻度で発生するのか？」など開発の前に明らかにしなければならないことが思い浮かびますが、当時はそのまま受け入れてしまいました。）
タスクに溺れるPMと将来の見えないプロダクト
当時PMとしてやっていた仕事は、
- 要求をヒアリングして具体化、整理
- 機能の要求定義、仕様策定
- エンジニアのタスクを洗い出し、アサイン、進捗管理、レビュー
- 事業部マネージャーやターゲットユーザーが属するチームのマネージャーへの進捗報告、その資料作成
- ユーザーサポート、ユーザーインタビュー
という感じでした。（この他にエンジニアとしての業務が発生することもありました。）
開発はスクラムでやっていましたが、その状況は、
- チーム構成はPMとエンジニア
- スクラムマスターとプロダクトオーナーをPMが担当
- スプリントは1週間単位
- レトロスペクティブ（チームに対する振り返り）はなし
という感じでした。
結果、エンジニアに渡すタスクの準備が間に合わないという形で破綻しました。スプリントプランニングまでにタスクを準備できず、プランニング内でタスクについて議論することになり、プランニングが終わらない、という事態が発生するようになりました。
見積もりもできる状態ではなく「いつリリース？」に回答できません。（そもそもこの段階で機能リリースのスケジュールに注目されている時点で期待値調整に失敗しています。）
プロダクトの方向性を考える時間も取れないので「次何するの？」に回答できず、ステークホルダーの御用聞き状態。ビジョンに近づいてるのかわかりません。
いずれの仕事も「それがPMの仕事でしょ」という扱いだったので助けてもらうこともできません。自分が駆け出しPMだから、力不足だから、と塞ぎ込み。とはいえPMとして相談してもらいやすいように明るく振る舞う。
この頃はなかなかつらみが深く、心が折れかけていました。。
チームで機能を考えてわかった要求の曖昧さ
タスクの準備が間に合わない、となってまずはエンジニアのテックリードに相談しました。決まった仕様を実装するために必要なタスクを洗い出してもらい、一時的になんとかなりましたが、長くは続きませんでした。
要求を満たすためにどんな機能、どんな仕様にすればいいかをPM1人で考えていたので、結局そこがボトルネックになっていました。同時に、なぜ1人で考えているんだろうという違和感がありました。自分がエンジニアだった頃、問題解決するためにどんな機能にするかはエンジニアが考えていました。エンジニアはどのように問題解決するかまで含めて考える力があると思っています。そして今、自分が率いている開発チームにはエンジニアがいます。チームで考えた方が絶対いいアイデアが出るぞ、と。
そこで次の一手として、タスクの準備を開発チームでやってみることにしました。
具体的には、開発チーム全員で集まり、MindMeisterというマインドマップツールを用いてタスクを分解していく会議体を設定しました。
目的としては、
- 機能を実装するのに必要なタスク（チケット）をチームで作る。その過程でどんな機能・仕様にするかもチームで議論する。
- マインドマップで機能やタスクの関係を可視化＆なるべく細かくタスクを分解し、タスク内容を具体化する。これによりチームでの認識を揃え、タスクを受け取りやすく、見積もりをしやすくする。
を期待していました。
これはうまくいきませんでした。
それまではPM1人で機能を考えていたので気付きませんでしたが、要求定義に曖昧さがあったために、機能アイデアが発散してまとまりませんでした。プランニングで議論が終わらないという問題が、前倒しになっただけでした。
また、機能・仕様が決まらないと設計はできず、設計しないと実装タスクの洗い出しはできないので、結局ほとんどタスクの洗い出しは進みませんでした。
しかしながらわかったこともありました。
- 要求定義が曖昧だったということ
- 要求定義が具体的になれば、エンジニアが機能を考えることはできるということ
- 要求定義を具体化するための材料（ヒアリングや検証）が足りていないということ
です。
チームで意思決定して開発プロセスを改善していく
ここからさらに試行錯誤を重ね、さらに新メンバー（スクラムマスター資格持ち！）が加入したことによって、状況はだいぶよくなりました。この新メンバーはスクラムマスターとして加入したわけではありませんが、彼のアドバイスは試行錯誤に大きく影響を与えており、とても助けられました！
まず、PMは要求定義に責任を持ち、その要求を満たすために何をすべきかはエンジニアが責任を持つ、というルールをチームで作りました。これによりタスクの洗い出しやアサインをエンジニアに委譲することができました。要求定義は「誰の、何のための機能か」「どんな機能か」「受け入れ条件」とフォーマットに沿って書くようにし、チームにレビューしてもらい合意が取れてから着手するようになりました。機能アイデアのベースをPMが作っているところは変わっていませんが、「何のための機能か」「受け入れ条件」を明確にすることでエンジニアからフィードバックをもらいやすくなり、合意までがスムースになったと思います。
これ以外にも、チームのポリシーをドキュメントにするようにしました。タスクに影響するようなポリシーから、細かいところでSlackでメンションするときのポリシーまで、チームで議論になって方針が決まったものはポリシーとしてドキュメントにしました。あくまでポリシーなのでそれに縛られるものではなく、日々の仕事や議論の中で判断に迷ったときに参照するものとして使っています。これもタスクに関するチームの合意をスムースにしています。また、エンジニア側でも開発ルールなどをドキュメント化するようになり、チームの意思決定を形にして残す文化が醸成されつつあります。「形にして残す」ことは、議論や別のドキュメントを作る際に参照することができ、また、誰に聞かずともいつでも参照できるという点で重要だと思っています。
また、以前は基本的に実装に関するタスクだけを扱っていましたが、技術的な検証や、機能アイデアに本当に価値があるかを確かめるPoC的な検証もタスクとしてエンジニアにお願いできるようになりました。これによって実装する前に判断材料が増え、要求定義や優先度を見直せるようになりました。チームから意見できる材料にもなり、単なる御用聞きから一歩抜け出せたのではないかと思います。
地味に大きかったのがスプリント単位を1週間→2週間にしたことです。同時に進捗報告も2週間ごとにしたことで、会議やスクラムイベントの準備にかかっていた時間が大幅に削減されました。
レトロスペクティブ（チームに対する振り返り）も実施されるようになり、以降継続的に開発プロセスの改善がされるようになりました。以前は何か改善の取り組みを相談するのも心理的なハードルがありましたが、明示的に相談できる場が設けられたことによって、相談しやすくなったと思います。
まとめ：PMが今やるべきことを見極める
ここまで述べてきたような経験を経て、1人でできることの限界と、チームのありがたみを改めて感じました。
プロダクトのために何でもやるべきPMですが、現実問題として何でもはできません。なので、プロダクトのために限られたリソースで何をするかが重要になります。プロダクト開発の施策として「何をやるか」「どの順番でやるか」を考えるのは当たり前ですが、これは個人のタスクについても意識しておきたいです。
そして「今やるべきこと」が1人で難しいのであれば、チームに協力してもらうためにやるべきことが「今やるべきこと」になるでしょう。いずれにしても、自分が今やるべきことを見極めて実行していくことが、プロダクトのためでもあり、チームへの感謝・還元することになると信じて、これからもやっていきたいと思います。
