エンジニアからPMに異動して1ヶ月でわかったfreeeの基盤PMの働き方
freeeの基盤チームのプロダクトマネージャーは何を何故やっているのか？ということを書いていく記事です。
私は7月からfreeeの基盤におけるプロダクトマネージャー（以下PM）になりました。もともとソフトウェアエンジニアをやっておりました。
エンジニアからPMになり、ガラッと時間の使い方が変わりました。でも、最近は少し慣れてきて、freeeの基盤PMとしての動き方、その理由も明確になってきました。
なぜ何をしているかの事例を書くのか？
PMが普段の業務でやることは不明確です。その証拠にPMが何をするのか？という議論は様々な場所で巻き起こっています。
また参考になる事例も少ないです。そのため、自分の行っている業務はPMとして良いのかを判断する材料が少ないと感じています。
だから、何をやっているかを書くことでPMの日常業務の参考事例を増やしたいと思いました。
参考事例が増えれば、自分の業務をより効率的に振り返ることができるようになると思っています。
実際PMの普段の業務はなんですか？という一般的な答えはありません。
私もPMになった当初は『実際には何をするんだろう？』と思いました。
もちろん、PMの仕事の目的は『プロダクトの価値を継続的に届ける』ことです。これを端的に答えることができる人は多いし、それが至上命題であることは明らかかなと思います。
でも、『プロダクトの価値を継続的に届ける』ために、普段何をやるのか？というHowのアプローチには様々あります。
これは『PMの仕事とは？』と検索して、すぐ出てくる図がそれを端的に表していると思います。
Product Management Skills NO ONE talks about ;) | HackerNoon より引用
これを見ると『つまり、いろいろなアプローチがあるということですね？』という気持ちになります。
最終的にはそのプロジェクトの状況次第。結局そういうことかなと思います。
PMは時としてユーザーインタビューもするし、プロジェクトマネジメントもやるし、Whyの言語化もします。
状況によってはプロジェクトマネジメントに集中したほうが成果が出やすくなることもあります。また、その他の打ち手に関しても同様です。
じゃあ、このときに参考にする事例は？
プロジェクトの状況と、その状況で何をしたのか？が記載されている事例はパッとは出てこないです。
実際にプロジェクトのビジネス的な背景、UX、エンジニアのチーム状況がわかるほど解像度の高い情報というのはあまり出てない印象です。
だから、自分たちの状況と比較して、自分のやることを判断するのは難しいし、抽象的な概念から自分たちの仕事に落とし込むことが必要な状況かなと思います。
そんなわけでエンジニアからPMに異動してきてやる仕事もだんだんと固定されてきたこのタイミングでやっている普段の業務とその理由を共有することにも意味があるかなと思っています。
そのため、この記事では可能な限り普段の業務の言語化とその業務をPMがやる理由を言語化していきたいと思います。
基盤チームのPMの仕事
私は基盤（認証認可）チームのPMとして、Whyの言語化とロードマップ作成を主な仕事としています。
これは基盤チームが関わるステークホルダーが多く、PMとして言語化の重要度が高いこと、そして他の仕事はチームの人に任せることが可能な状況によってこの仕事内容が選択できています。
この仕事内容を知って貰う前にまずはチームの概要、チーム状況をご説明しておこうかと思います。
基盤（認証認可）チームとは
freeeにはfreee会計、freee人事労務といったプロダクト以外にプロダクト共通の機能を提供するチームがあります。これが基盤チームです。
私はこの基盤チームに所属しており、中でも認証認可にまつわる機能開発のPMをやっています。
認証認可チームが提供している代表的な機能
認証認可と聞いてログイン画面が一般には想起されます。他にも様々な機能を提供しています。具体的なキーワードをいくつかあげます。
サインアップ
ログイン
パスワードの再設定
メール認証
アカウント管理プロダクトへのメンバー招待
チームを取り巻く状況
基盤チームに入ってわかったことは判断に必要な知識は多いが、ソリューションの実現は他の人に任せられる状況にあり、かつ言語化の重要度が高いということでした。
判断に必要な前提知識が多い
基盤チームは関わるチーム、技術領域が多岐にわたります。そのため、最終的に優先度判断するために必要な知識が多くなります。
ソリューション実現は他の人に任せられる
背景が理解できればソリューション実現は任せられる頼もしいチームメンバーがいます。典型例としてプロジェクトマネジメントはノンタッチで問題ありません。
言語化の重要度が高い
プロダクトの方向性を示すことはPMが他人に任せることができない業務です。また、チームの規模が大きいほど重要度が増してきます。freeeの基盤はステークホルダーが多いこともあり、この重要度が高いように思います。
詳しく説明していきます。
判断に必要な前提知識が多い
基盤だけ有って、ステークホルダーや技術が広いです。また、それに加えて認証認可周りは意外と新サービスが出てくる速度が早いです。
ステークホルダーや技術の幅が広い理由は全プロダクトに関係があることと認証認可周りの技術領域が深いためです。
全プロダクトに関連がある
決算説明資料でも分かる通り、freeeは12個のプロダクトを展開しています。この全プロダクトに基盤は関連しています。
結果として関係者も全プロダクトとなり、多くの調整が発生します。調整ごとの具体例としては、重複しそうな機能分担や、各プロダクトのも含めた体験に必要なピースはなにか？などを調整します。
これらは様々なプロダクトを使う全てのユーザ価値を考えながら基盤プロダクトを開発しているということです。
自然とインプットも多くなります。
認証認可周りの技術が深い
認証認可周りは古くから非常に多くの企業で開発されています。そのため、古典的な手法やデファクトスタンダードとなるような技術が多いです。また、それらも日々進化を続けているため、背景理解のための技術トレンドは抑えておく必要があります。
例えばOpenID Connectもその一つです。
OpenID ConnectはOAuth2.0という仕様の上に存在する認証プロトコルの仕様です。オープンな仕様でさえ、他の仕様を補うように進化を続ける一例です。また、この仕様を様々なコミュニティがこれを実装しています。
意外と新サービスが出てくる速度が早い
昨今、認証認可を簡単に実現するSaaSが次々と出てきています。GoogleやAWSなどのPaasはもちろん認証認可を提供するサービスを提供しています。また、アカウント管理のOkta、OneLoginなんかは認証認可にものすごく関わりのある企業群です。また他にも知られていない多くの認証認可のサービスを提供している企業がたくさんあります。
ソリューション実現は他の人に任せられる
ソリューション実現自体は他の人に任せられる状況です。チームのエンジニア・UXチームの実行力が頼もしいです。
そのため、背景と課題感が整理されている状態であれば、それを実現するために必要なアクションを自然と取ってくれるなと思えます。
UXチーム
課題感や解決したい方向性を提示すればUIを作ってくれるのはもちろん。込み入った業務を考えるときは、ユーザの行動観察から一緒に伴走してくれます。
込み入った業務を考えるときはユーザー課題を解きほぐし、一緒に解決したい課題を言語化するために、課題整理まで手伝ってくれます。
彼らはユーザーリサーチからユーザーストーリーマッピング、UI作成まで広くカバーしてくれる存在です。
『〇〇困っている人いるみたいなんだけど、なんかいい感じの体験ってどんなのだと思う？』と言ったコミニュケーションが多いように思います。
エンジニアチーム
実現可能なソリューション案を実現（リリース）までこぎつけてくれます。
また、ロードマップの順番へのアドバイスや、実現するに当たってのリスク提示、当初想定していた方法以外の解決方法の提案なども行ってくれます。プロジェクトマネジメントも彼らが責任を持って実行してくれます。
また、彼らはfreeeとして他のプロダクトも含めて開発速度を加速するという角度から、プロダクトのあるべき姿を提案してくれます。
『〇〇って言う困りごとを解決したいと思うんだけど、リスクとか実現方法とかってどんなのあると思う？』と言ったコミニュケーションが多いように思います。
言語化の重要度が高い
そもそも課題特定や方向性のアウトプットはPM独特の業務です。
ステークホルダーや前提知識が多くなってくるとこの重要度が上がってきます。
freeeの会社としての規模感や、基盤チームの状況から課題特定や方向性のアウトプットが本当に重要になってきていると感じています。
課題特定アクション
ステークホルダーが多くなると、インプットコストが高くなること、フラット判断することの重要度が増してきます。
必要な知識の幅が広くなると、課題の特定アクションに必要なインプットが多くなります。これにはヒアリングや、調査、分析などが含まれます。チーム全員が知識をインプットするとコストが嵩むようになります。そのため、わかりやすく言語化することがチームをスケールさせるために重要だと感じます。
また、ステークホルダーが多いとそれぞれの熱量も分散してきます。そのため意識しないと、意図せず偏った判断になることもあります。そのため、PMという機能に課題感をためることでフラットに判断する重要度が増すと感じています。
結果として、インプットを言語化することを通じて、大枠で課題特定をしておくことはPMとして重要度が高いと感じています。
将来の方向性アウトプット・直近のオプションの意思決定
関連するプロダクトやステークホルダーが多くなるとやりたいことは数限りなく出てきます。また、関係者が多くなるため、これらを調整しながら意思決定することが大変になってきます。
この意思決定はアクションを実行することとは別種の作業で、並行で行うのは難しいです。作業のコンテキストスイッチが大きいようなイメージです。
そのため、大枠で将来の方向性をロードマップとして提供することでスコープを絞り、実際のアウトプットの総量を増やすことにつながると感じています。
普段の業務
これらの前提を踏まえて私は主にこの3つの仕事をしています。
概要
課題の発見
誰がどのくらい困っているのかをヒアリングや調査によって見つけます。課題の重要度判定を行うためのインプットすることも業務に含まれます。
課題の言語化
課題をビジネスメンバー、UX、エンジニア、QAがわかるような言葉で言語化します。また課題が解決された状態も同時に言語化しておきます。
優先順位付け
上記で言語化した課題の対応の優先順位付けを行います。小さな優先順位付けは企画でやる仕様の意思決定になりますし、大きな優先順位付けはロードマップの策定になります。
いわゆるWhyの言語化とロードマップの作成です。これらを行うことでチームのゴールを作るイメージです。
一般的なPMの仕事と語られるもののうち、『特にビジョンづくりが求められるのがfreeeのPMの特徴だね』と社内で話していたりします。
以下では更に私の業務を詳しく書いていきます。
課題の発見
課題感の収集と課題感を理解するためのインプットに時間を使っています。
課題感の収集
認証認可周りはfreeeの様々なプロダクトや部署に関係します。そのため社内の様々な部署に課題感をヒアリングします。
このときのヒアリング対象は各プロダクトチームのみならず、マーケティング、法務、カスタマーサポートなどです。会議で実際にお伺いすることもあれば、チャットや社内SNSで収集することもあります。
またサポート履歴などからユーザーの課題感を抽出したりもします。課題感を広く集めるフェーズなので考慮するケースを取り残さないように注意するイメージで仕事をします。
技術情報収集や新しいサービスの状況調査
認証認可周りの技術や出てくるサービスを調査します。
マーケット状況は日々変わっており、これらをインプットすることが正確な理解に繋がります。2019年の資料 を見ても最近の認証認可周りの議論はグローバルでかなり進行していることがわかります。
また、Okta、OneLoginを始めとするiDaaSの台頭などに代表されるように認証認可周りのマーケット状況も刻々と変わっていっています。これらのサービスを調査しています。
課題の言語化
課題感が収集できたら、これらをドキュメントに言語化します。
担当部署やユーザーが困っていること
freee社内の人やfreeeのプロダクトを使っている人たちが困っていることを言語化します。『誰が何に困っている。何故ならば～』というフォーマットに則り、言語化していく。
背景
背景となる法令、担当部署やユーザーが普段やっている業務、プロダクトの開発状況を書いておきます。
これによって課題がどこにあるのかという理解の補足ができるようになります。また、UIや機能要件・非機能要件を決定するインプットになります。
課題感を解決できた状態を言語化
課題感が解決された状態を言語化しておきます。この言語化はプロダクトの機能にならない粒度感でまとめておきます。
ソリューションは考えてくれるチームがいるので『困っている人がどうなる』という粒度でまとめていきます。
やることの優先順位付け
課題感が解決された状態が言語化されたら、今回のスコープでやることを決定します。
MVP（やること）の決定
今回のプロジェクトで実現したい最も最小のスコープを決定します。開発コストはソリューション案を検討してくれるチームで行ってくれるため、コストのことは忘れます。
課題が解決された最小の状態を定義することに集中します。
このときに『これをやるとどうなるのか？』、『これをやらないとどうなるのか？』、『マジ価値なんだっけ？』などの問いを投げかけて、スコープを絞っていきます。
やらないことの決定
プロジェクトのテーマに関連して上がってきた課題感の中で今回やらないと決めたことを決定します。
やることは決定しているので、あえてやらないことを言語化しておくのがまずは重要です。
その上でもしやるとしたらという想定で、着手する課題案を順に並べておきます。価値の大きさ、ミッションの関連性、複雑性などを考慮します。
問いを投げかけていく中で、並んでいる順番とその理由を明確にするイメージで仕事をしていきます。
まとめ
改めて私の普段の業務とその業務をやっている理由をまとめてみます。
freeeの基盤（認証認可）チームはステークホルダーや前提知識を整理し、優先度を判断する重要度がましてきたチーム・会社の規模になってきている。
そのため、普段の業務として課題感を発見して、やることや方向性を決める。また、これに加えてチームメンバーが理解しやすくまとめる。
改めてですが、PMがなんの仕事をするのかというのは状況次第。
各人の置かれていた状況で『プロダクトの価値を最も最大化するためになにか大事か？』に依ります。だから、同じPMでも人によって業務が全く異なるのだと思います。
現在、freeeの基盤（認証認可）のPMは言語化タスクが多いです。
一方でfreeeの社内でもPMの仕事は一律でないところもあります。
プロジェクトマネジメント業務に片足突っ込んでいるPMも少なくないと思います。
同じPMでも最初期のスタートアップのような状況ならば、freeeのCEOがコードを書いたように、そのほうが早くユーザに価値を届けることができると判断になることもあるかもしれません。
でも、自分のチームにおけるPMの仕事の優先順位をスッキリと言語化できて、自分のやるべきことに集中できると自信が持てる気がします。
成果を出すために何が重要なのか？それを行うために何を行うのか？を言語する際に参考になる例が提示できていると嬉しいです。
この記事を読んでfreeeのPM面白そうだなと思ったら、ぜひご応募ください。
freeeはプロダクトのポートフォリオを増やしていくため、基盤、プロダクトともに成長フェーズです。きっと面白いチームが見つけられると思います。カジュアルにお申し込みください。
また、もっとカジュアルにという方向けにMeetyも受け付けています。気になりましたら、チャットだけでもご連絡ください。