Suyama氏の自己紹介
Daiki Suyama氏：もともとあったタイトルと若干異なるのですが、今回は「事業とプロダクト間のインターフェース作り」というところでお話しできればと思います。
軽く自己紹介をすると、2022年4月に現在の株式会社クライドに入社して、フルサイクルエンジニアとして働いていました。2022年11月にそこに加えてDevOpsの部分やイベントの企画、新卒採用など、いろいろな業務に携わり始め、2023年4月からPdM兼PO兼テックリードのようなかたちで働いています。
Suyama氏がPdMに就任した背景と、当時起きていた問題
さっそく内容に移れればと思います。まず自分が就任した当時の背景と状況について、それぞれ説明したいと思います。
PdMに就任した背景としては、エンジニアとしての取り組みの部分で、DevOpsエンジニアとして開発生産性の向上をして、そこから「事業で改善できる部分があるんじゃないか」というような提案をして。そこの取り組みの評価があったり。あとは事業のフェーズが変化して、プロダクト開発にテコ入れする必要があったという背景があります。た。
（スライドを示して）状況として、（当時）起こっていた問題が1つあります。（その問題として）大きいのは、事業戦略がプロダクト戦略になっているという状態です。
これが起きると何があるかというと、2点だけ挙げたのですが、（まず）事業としてあるべき姿が描けても、プロダクトとしてあるべき姿が描けない。あとは、事業戦略＝プロダクト戦略になると、ユーザーの解像度を上げるという部分がおざなりになるというような問題が発生します。
PdMとPOの役割分割
自分がPdMに就任したタイミングで、体制変更がありました。就任前はもともとPOが1人いて、チームごとにリーダー1人プラスメンバー数人という体制でやっていました。
就任後はPOだった人がPMMになって、自分がPdMのポジションに入り、加えてフロントエンドとバックエンドのチームにPOを1人ずつ（立て）、自分が（PdMとPOを）兼任するかたちになりました。それ以外に、弊社ではスクラム開発を採用しているので、スクラムマスターやテックリードがいます。
ここでのPMMとPdMの役割の違いとしては、どちらかというとPMMは事業の部分、PdMはプロダクトの部分に責任を持つような役割になっています。
（スライドを示して）今、PdMとPOを兼任すると話したのですが、PdMとPOでは厳密にいうと役割が違うかなと自分は思っていて。現状、こういった役割の違いを置いています。
自分1人（が両方の役割を持っている状態）なので難しいのですが、PdMは何の機能を作るか、POはどうやって機能を作るかにフォーカスして役割を分割しています。PdMは事業開発とプロダクト開発のインターフェースとして、POはエンジニアチームとプロダクト開発とのインターフェースとして機能するようなかたちになっています。
ただ、この部分はまだ手探りで進めているところなので、これからもっとブラッシュアップしていければと思っています。こういった分離があります。
プロダクトバックログの分離をどのように行ったのか
今日話すメインテーマは、プロダクトバックログの部分ですね。この部分をどうやって分離したかというところ。プロダクトバックログの部分について、自分がここまでの経緯を踏まえて意識してきたことを話します。
プロダクトバックログについてはみなさん知っていると思うんですが、開発項目を一覧化したようなリストのことです。一覧化されているので、エンジニアチームでもビジネスサイドでも、それを見にいくことでどんな機能が開発されているかわかるようになります。
ただ、自分の就任前にはエンジニアチームと自分の就任前にいたPOが把握しているバックログがそもそも異なっていたり、その異なっている部分の調整のためにコミュニケーションコストが増大したり、エンジニアからの情報もPOからの情報が適切に伝わらないというような問題がありました。
ここで何をしたかというと、先ほど自分がPOとPdMという2つの役割を兼任しているという話をしたのですが、それぞれが管理するバックログを分離してみました。これによって、エンジニアチームとPOの把握しているバックログの同期を取れるようにするのが目的です。これによって就任前の状態（で起きていた問題）は、現状解消していると思っています。
「PdMのプロダクトバックログ」と「POのプロダクトバックログ」の構成
では、具体的にPdMのプロダクトバックログとPOのプロダクトバックログをどういった構成にしているかが、次の2枚のスライドになります。
（スライドを示して）1枚目がPdMの管理するプロダクトバックログです。こういった感じでいろいろ、行ごとにやる機能だったりバグ修正だったり（が置かれている）というものになっています。
PdMのほうには4つのカラムを用意しています。Status、Project、Category、Idea fromと書いてあります。これらはスライドに書いてあるとおりの定義です。 StatusとProjectに関しては一般的かなと思うのですが、CategoryとIdea fromと書いてあるところについては、ビジネスサイドが把握したいものとして適切かなと思って自分が付けています。
Categoryについては、今これをパッと見るとバグ修正だったりImprovement（改善）だったりが多いのですが、このFeatureの割合を増やしたいということで、それを可視化するために付けています。
Idea fromについては、PMの仕事としていろいろなステークホルダーが絡んでくるので、適切に要望が分散されているかを確認するために付けています。
まだブラッシュアップできていないところはあるのですが、こういったかたちで、プロダクト開発と事業開発の間のインターフェースになるようにバックログを設計しています。
（スライドを示して）逆にこちらはPOが管理するところで、プロダクト開発と開発チームの間のバックログになります。StatusとProjectは先ほどのプロダクトバックログと同じですが、Epic、PRDというところが異なります。
先ほどのスライドではCategory、Idea fromと書いたのですが、これに関してはエンジニアチームが把握しなくてもいい（部分）というか。Categoryに関してはJiraのチケットでフィールドとして用意しているのでいらないかなと。あと、Idea fromというところは完全にPMのタスクになるので割愛しています。
（その代わりに）追加したのがEpic、PRDというところです。自分たちは、機能開発する時にまずEpicを作って、そこから設計をして分割していきます。さらに先ほどのProjectというところが微妙に異なっていて、PdMについてはいろいろなステークホルダーからの要望の単位になっていますが、こちらは開発のタスク単位となっています。
先ほどの要望の単位だと、例えば数ヶ月かかるようなものもあって。これだとEpicを作るのは適切ではないというところで、開発のタスクの単位、スプリントの単位ぐらいに切っていて。このプロダクトバックログは1週間から2週間単位ぐらいに分かれています。
こういったかたちでPOとPdMと2つのプロダクトバックログを用意して自分が管理するようにしています。
今日の発表の3つの重要なポイント
自分の発表は以上です。最後にまとめとしてどんなことを意識すべきかというと、事業開発とプロダクト開発が適切に分離できているか、インターフェース作りという部分と、役割や業務分担が明確か、最後にプロダクトバックログで何を管理しているのか。この3つが今回の自分の発表で重要かなと思います。
最後に宣伝というか、自分はTwitterをしているので、フォローしてもらえると幸いです。今日の内容は別途記事にまとめて公開する予定です。
ご清聴ありがとうございました。
