Product Developerの役割・仕事内容の実情は？面白いのは「エンジニアリングとビジネスを掛け算する感触」
グラファーでProduct Developerをしている山田です。「Graffer スマート申請」のプロダクト開発や、グラファーのプロダクトに使用されるマイクロサービスの開発を担当しています。前職ではフロントエンド、バックエンドを担当するエンジニアとして働いていました。
グラファーのビジネスモデルやProduct Developerという役割に興味をひかれて入社した私ですが、転職を検討する際はProduct Developerの役割をイメージできず、選考中にさまざまな質問を投げかけた記憶があります。
そこで、今回の記事ではProduct Developerの役割や、主だった仕事の1つであるPRD（Product Requirements Document）を作成した振り返りを書いてみることにしました。皆さんの中でProduct Developerの仕事の解像度が上がり、グラファーの業務内容がご自身のキャリアとマッチするかどうかの判断材料となれば幸いです。
Product Developerはどのような役割なのか？
Product Developerという呼称はあまり一般的ではないと思うので、はじめに職種の役割を説明します。
グラファーにおけるProduct Developerは、ビジネス部門と協業しながら、製品の開発を主導する役割を担っています。イメージとしては、フルサイクル開発者が近く、ソフトウェアライフサイクルでいう「開発」だけでなく、ライフサイクル全体に責任を持ちます。
仕事の内容としては、課題の設定・開発・テスト・運用を行います。例えば、私が関わっている「Graffer スマート申請」では、まずProduct Developerがビジネス部門と協同しながら、自治体・市民が認識していない本質的な課題の発見を行います。自治体・市民からいただく要望が発見のきっかけになる場合もありますし、利用者への直接のヒアリングや実際の現場業務を体験・見学させてもらうことがきっかけになることもあります。こうして得られた情報から課題の仮説を立て、解決方法に関する意思決定をし、決定した内容の開発・テスト・運用までを実施します。
ちなみに、Product Developerの役割やProduct Managerとの違いについては、カジュアル面談でご質問いただくことが多い話題の一つです。別記事にもまとめられていますので、よろしければチェックしてみてください。
「【エンジニア編】カジュアル面談でよく聞かれることにお答えします」
PRDとは、プロダクトの要件を整理した仕様書
次に、Product Developerの主な仕事の1つである、PRDの作成について紹介します。
PRDは「何を、誰のために、なぜ、どうやって作るのか？」を主軸に置いて、プロダクトの要件を整理した仕様書で、以下のような流れで作成します。
「解決したい課題」、「対象となるユーザー」、「必要な機能要求」の決定
考慮するべき法令、法的論点の有無を調査
状態遷移図やアーキテクチャ構成等を含んだ「詳細な仕様」の決定
セキュリティリスクの調査
テスト計画、リリーススケジュールの決定
PRDは、仕様書としてプロダクトの要件をまとめるだけでなく、仕様決定までの議論や検討プロセスを記録として残す目的もかねています。プロダクトの歴史が長くなるにつれて、組織の人間が入れ替わるといったことはどの会社でもあることだと思います。こういった入れ替わりのタイミングでよくあるのが、意志決定の際の背景や、考慮するべき点などが失われてしまうことです。しかしPRDがあることで、組織に後から加わる人が経緯をたどりやすくなります。プロダクトが変化してきた経緯や理由を知れば、自分自身がやるべきことや、プロダクトのあるべき姿を理解できるため、今後の開発を進める上での指針が得られる場面も出てくるはずです。
実際のPRDの例
PRDについてのイメージを深めていただくために、実際のPRDを例に挙げて、どのように要件を整理していくのかをご紹介します。
ここで例に挙げる実例は「画面上でGraffer アカウントから退会可能にする」という機能のPRDです。「Graffer アカウント」とはグラファーが提供するサービスの共有アカウントで、本人認証や利用履歴の閲覧機能を持っていますが、実はつい最近まで、ユーザーがアカウントを退会するためにはメールでの問い合わせが必要でした。
Grafferアカウントの維持に料金は発生しませんし、メールマガジンの配信もしてないので、退会をせずにアカウントをそのままにしているユーザーも数多くいます。そうなると、ユーザーにとっては「オンラインで退会できない」という課題は現時点で大きな問題ではないと判断できそうですが、ユーザー以外の視点で課題を捉え直すと結論が変わってきます。
ユーザーからの問い合わせに対応している人の視点から課題を捉えると、「問い合わせに対応するオペレーションの負荷」、「ヒューマンエラーのリスク」という課題が潜んでいるのです。問い合わせの件数は日に1〜2件なので、退会処理に忙殺されているわけではありません。ですが、その処理が人の手で実施されている以上、ヒューマンエラーのリスクはゼロにできません。今後Grafferアカウントの利用者が増えていけば、問い合わせの件数が増えると共に、オペレーションの負荷が増えることは想像に難くありません。
「オペレーションの負荷」の課題を解決する重要性が見えてきたことで、実際のオペレーションがどのように実施されているかを把握し、把握した内容を要件の検討材料としてPRDに盛り込む必要も出てきます。こうした検討の積み重ねによって、PRDの質を高めていきます。ですが、PRDの作成者があらゆる視点を網羅しきることは簡単ではありません。そこで活きてくるのが次にご紹介するレビューです。
PRD作成後にはレビューをもとに議論を重ねる
ここでも先ほどの実例に基づきながら、PRDを作成した後に行っている、Product Developerや、プロダクトを統括するProduct Managerのレビューについてご紹介します。
レビューの観点は「解決したい課題を掘り下げられているか」、「解決のアプローチとして妥当なのか」、「他の手段との比較検討は実施したか」、「影響範囲を考慮できているか」、「考慮するべき法令はあるのか」といった点です。また、「顧客への事前周知は必要か」、「社内の他チームとの連携は必要か」といったリリースに関する観点が必要になることもあります。
例に挙げた「Graffer アカウントの退会」の場合、当初課題として「ユーザーがオンラインで退会できなくて不便」という観点を挙げていましたが、これだけでは課題の掘り下げが不十分で、レビューを通じて議論することによって、より深い課題を明確にすることができました。
「解決のアプローチとして妥当なのか」という観点でもレビューが行われました。PRDの作成を始めた初期段階では、退会のタイミングで「Graffer スマート申請」の利用履歴も全て消す想定で要件を作っていましたが、ここに論点が隠れていました。「Graffer スマート申請」は行政手続きをオンラインで実施できるプロダクトです。日本の行政機関に提出した手続きは「行政文書」として扱われ、行政文書は区分ごとに最低保存期間が法律によって定められています。つまり、アカウントを退会したタイミングで過去の手続き情報を消す仕様は法律の観点で許容されないのです。
これまでの話を踏まえて解決のアプローチを見直すと、「退会のタイミングで消去するのはユーザーの個人情報のみとする」、「行政文書として扱われる利用履歴は保存期間が満了したら消去できる仕組みを別に用意する」の2つの要件が必要となります。このように「法務観点で大丈夫な仕様だろうか？」という観点もレビューでは重要になってきます。ちなみにこうした場合は、法務領域のメンバーにも議論に加わってもらいます。
新規事業の検討、技術的に難易度が高い要件の場合は別の論点が存在しますが、それらの説明は別記事に譲ります。
PRDの作成で求められる能力と、今の自分にまだ欠けているもの
Product Developerには、課題を深堀りするための視野の広さ、行政のドメイン知識に加えて、言語化能力が求められます。法務観点やデザインといった一人では解決できないことが後から出てくるケースも珍しくありません。
要件の検討からリリースまでを完遂する責務をもっているものの、全てを1人で完璧にこなせるわけではありません。自分だけでは解決できない課題に対しては、周りのメンバーを積極的に巻き込む、主体的な動きが求められる職種だと考えています。
今回例に挙げた案件を振り返ると、自分にとって特に課題なのは、言語化能力でした。PRDの作成過程は論文を書く過程と似ている面があり、結論としての要件と、結論に至るまでの経緯や検討事項を順序立てて説明する必要があります。つまり、説明する内容の確度を高めつつ言語化することになるわけですが、言語化能力は一朝一夕に身につかないので、日々の訓練が必要になってきます。
最後に：Product Developerの仕事の面白さ
前職までの働き方とグラファーでの働き方を比較すると、前職まではProduct Managerが要件を決めて、複数のエンジニアで1つの機能を開発するという進め方が当たり前でした。一方、グラファーでは1人のProduct Developerが要件の検討から実装・テスト・リリースまでを一貫して担当するため、向き合う仕事の幅は増えます。過去に働いてきた職場と比較して裁量も大きい分、要件を開発・運用する過程の難しさに対して、ポジティブに向き合う主体的な思考が必要になると考えています。
自分自身、「プロダクトをマネジメントする」経験を積めるチャンスを求めてグラファーに転職したわけですが、最近は「エンジニアリング」と「ビジネス」を掛け算する感触を少しずつつかめている感触があります。現時点では課題の深掘りや言語化の過程で苦労していますが、日々の積み重ねがProduct Managerに近づく道になっているはずだと感じています。
Product Developerに興味を持っていただいた方からのご応募をお待ちしています！
Product Developerの仕事は、主体性を求められる一方で個々の裁量が大きいので、自分から考えて動く人には合っている環境だと思います。興味を持っていただけた方は、ぜひお話ししましょう！
