PO（プロダクトオーナー）がエンジニアの意見を取り入れロードマップを改善。不確実性の高い開発を周囲に見える化したらどうなったか？
プロダクトに組み込まれていた5つの機能をそれぞれ独立させ、マルチプロダクト化したFULL KAITEN。それぞれの機能の価値がよりクリアになり、新たなニーズも掴めるなど、さらに事業として成長していきそうでワクワクしています！
このような進化に伴い、現在2名が在席するPOが増員を計画しています！本日は弊社でPO（プロダクトオーナー）歴が最も長い島田に、POの業務の流れ、責任、仕事でのエピソードについて聞いてみました！
募集の背景は、マルチプロダクト化
島田：2022年秋まで、FULL KAITENというサービスの中に色んな機能を詰め込み、シングルプロダクトとして提供していました。昨年、提供価値が異なる各機能を分割し、それぞれを一つのBtoB SaaSとして「マルチプロダクト化」するという大きな変化がありました。
シングルプロダクトに色んな機能が全部盛りだった以前のFULL KAITENでは、お客様の要望に広く応えようとするあまり開発もセールスも総花的になっていました。リソースがない中で幅広い知見が必要な開発は大変でした。
このマルチプロダクト化は開発にとっても大きなメリットがあります。
1つ1つの機能に集中して開発できるため、お客様に価値を届けるための戦略を立てて考え抜くことができる
エンジニアのリソースが限られている中、どの機能に対してリソースを割くのかという優先付けがしやすくなる
プロダクト毎に何を優先するかという優先度を決めやすくなった
いつまでにMRRを…などボードメンバーが決めた事業戦略に合わせやすくなった
機能別に担当者がいれば専門的になっていくので、お客様の課題の深いところまで理解し寄り添った開発ができる
この利点を活かし、POは説得力のあるロードマップを作成していかなくてはなりません。今回はこの「マルチプロダクト化」に伴い、プロダクトの価値提供をさらに加速すべく、新たにPOメンバーを募集するに至りました！
PO業務の流れ
島田：POは、「プロダクトの提供価値を最大化する責任者」だと定義しています。 重要な役回りとなるため、組織体制としては、ビジネスサイド、エンジニアサイドどちらでもない、「社長直下」となっています。
プロダクトの開発は以下のようなステップで進めています。
1．お客様の要望やCSの要望がPOに届く
2．課題の本質・解決法・そもそも実現可能なのか？を検討する
3．SEと協議。エンジニアリソースの面で無理はないか？技術的に実現可能か？
4．SEにフィードバックをもらいながら、プロダクトの方針や実現したいことをサービス仕様に落とし込む
5．SEは、サービス仕様を受けて、システム要件を定義し、プロダクト仕様に落とし込む
「どのお客様の、どんな課題を、どういう手段で、どのように解決したいか？優先度は？」
を考え抜き、最終的にサービス仕様で実現したい提供価値を定義するという大変重要な役割を任されています。
上記の流れの中では何度もCSやSE、エンジニアとミーティングを繰り返します。他部署と接する機会が多いのもPOの特徴で、コミュニケーション能力も必要になってきます。
エンジニアの意見を取り入れ、ロードマップ作成方法を改善した話
筆者：最近PO業務で印象に残った出来事はありましたか？
島田：在庫配分の機能のロードマップ作成時にエンジニアの意見も聞いてみたところ、良い変化がありました！
SIや受託開発出身のエンジニアと話していて「前職では、使われもしないんだろうなっていう機能を言われるままの期日に合わせて必死で作ってきた。作った後どうなったのか、成果を知るような機会もなかった。それで転職を考えるようになった」と数名から同じようなことを聞きました。
自社開発出身のエンジニアでも、作った後で聞くのは不具合の報告や要望ばかりだったと。
確かに、彼らがこれまでやってきた開発は、上から言われたものを言われた通り、指定された期限内に必死で作り、リリースして終わり。自分達が作ったシステムがどう使われているのか、役に立っているのか、そもそも使われているのかという手触り感がない。
これでは面白味もやりがいもないなと感じたのです。それまで、CS出身の私には「上流工程から関わりたい」というエンジニアの気持ちがなんとなくしか理解できていなかったのですが、実際に話してみてとても納得しました。
筆者：FULL KAITENは、エンジニアが上流工程から関わることはもはや当たり前、リリース後にもレビューミーティングやslackの専用チャンネルにて顧客の感謝の言葉、ポジティブ・ネガティブな反応や活用事例を聞く機会は多く作ってますよね。
島田：そうなんです。そこで今回、ロードマップ作成時のスケジューリングの段階からエンジニアの意見を取り入れたいと思ったのです。
というのは、過去に開発のリリースのスケジュールが立て続けにズレて、ウェビナー企画や広報・セールス計画などに影響が出てしまい社内に混乱を招いたことが何度かあったからです。原因をよくよく考えてみて発見したのは、ロードマップの見方が人それぞれに違い、意識にズレが生じていたということ。
ボードメンバーなど上位レイヤーや他部署のメンバーから見ればいつまでに開発が終わり、その日に確実にリリース可能だと判断して見ていた。それに対してエンジニアにとってはあくまで「工程表」であり、開発に取り掛かってみないと何が起こるかなんて分からない。不確定要素ありきで見ているんですよね。
今回の在庫配分のロードマップ作成時には、お客様が必要とする機能が洗い出された状態で、CSとSEとエンジニアリーダーと共に、1日かけて要件を決めました。
以前と変えたのは、開発には確実なものと不確実性の高いものがあるという前提を組み込んで、それぞれ表記を変えて周りに伝わるようにしたことです。特に不確実性の高いものについて、「この開発の期限は約束できない」と分かるように。
紫：着手してるがリリース日はまだ対外的には言わない
青：確定
グレー：まだ構想段階（仕様決めなど）
オレンジ：仕様は固まったけど着手していない
という具合です。
筆者：開発には確実なものと不確実性が高いものと2種類が存在するんですね。ちなみに不確実性の高い開発というの例えばどんなものがあるんですか？
島田：FULL KAITENは重厚長大なシステムであり、ビッグデータを扱ってるので、どうしても開発が重くなります。やってみたら重くて動かなかった、やってみたら予想外に費用が掛かると分かった、など色んなケースがあります。
筆者：なるほど。このように進捗状況の共有方法を変えたことで、どのような変化がありましたか？
島田：ビジネスサイド、エンジニアサイドの目線を揃えることができました。
結果、ビジネスサイドとしてはお客様とのコミュニケーションが取りやすくなり、期待値のコントロールがしやすくなったり、計画的なコンテンツ作成が行えるようになっています。
一方でエンジニアサイドとしては、どの開発項目が不確実性が高いのかをビジネスサイドに理解してもらえることで、安心して実装に取りかかれるようになりました。
開発の遅れの理由が分かりやすくなったり、各開発タスクの進捗も細かく見れるようになったので、私としても助かっています。
島田が感じるPOの魅力
島田：FULL KAITENのようなSaaSにとって、プロダクトとは事業にもお客様にも一番重要なものですよね。そこに深く関われる、任されていると感じられるところではないでしょうか。
お客様に本当に喜んで使って頂けるため、どの機能を優先して提供するかを決断するポジションはやりがいがありますね。常に、どうしたらお客様がFULL KAITENに価値を感じてくださるのだろうと考えてワクワクしています。
また、その決断を社内に展開して説明するのもやりがい・面白さを感じる業務の1つです。
ボードメンバーはもちろん、CSやエンジニアにも納得してもらえるようにエビデンスを持って社内に説明できないといけない。それにはお客様のことをちゃんと分かってないとできないんですよね。
色々試行錯誤しましたが、FULL KAITEN導入から1年が経過し、契約更新（FULL KAITENは1年契約）してくれるお客様が増えてきました。
プロダクトが理由での解約というのがだいぶ減ってきたと実感できていることも嬉しいですね。これからもお客様の課題の本質を見極めて、喜ばれる機能をどんどん実現し、FULL KAITENの価値提供を最大化していきたいと思います！
POの仕事が分かる記事はこちらもおすすめ↓
フルカイテンでは事業拡大と上場準備に伴い、PO・SEなど全方位で採用強化中！
今すぐの転職ではなくても少しでもご興味ある方は、筆者のXにお気軽にDM、または下記採用ページからカジュアル面談をお申し込みください！
採用ページはこちら
会社が分かるYouTubeはこちら
この記事が気に入ったらサポートをしてみませんか？