創業～シード期のプロダクトマネジメントの変遷について

こんにちは。東京ファクトリー代表兼、今はProceedクラウドのPdMも担当している池です。
最近PdM/PMといった職種が人気になっているようでSNSでもPdMのキャリアについてなど見かける機会が増えてきましたね。
米国ではMBA卒業生にとってもPdM/PMが人気の職種になっているそうですが、日本ではまだなじみも薄く、創業期からPdMがメンバーに入っているチームは少ないのではないでしょうか？
かくいう弊社も創業~今までPdMロールは私が担っており、色々と苦労をしてきました。
特に、私の場合はキャリアが重工業エンジニア⇒戦略コンサルとWebとは比較的遠いところにいたこともあり今も試行錯誤しながら開発を進めています。
本noteは私と同じく非web系のバックグラウンドの起業家やスタートアップでのPdM/PMや開発に関心のある方の参考になればと思い、事業の各フェーズで感じた課題と解消方法について書いてみました。
※アジャイル開発に関する用語の説明は割愛しています。

読んでいただいた方の中で”もっとこうしたほうが良い"という意見があればご連絡いただけると嬉しいです。
DMはコチラ

創業前後の状態：初めはウォーターフォール(WF)で

東京ファクトリーの提供しているProceedクラウド(製造業の現場向けSaaS)のPdMは開発開始から2021年末現在まで私が担当しています。私自身はBCG在籍時に数カ月間アジャイル開発の案件にビジネスサイドで従事したこともあり、アジャイルの基礎知識は持っているものの、PdMは全くの未経験でした。
なお、創業時は私+副業エンジニア3名(稼働は10h~80h/月程度)+副業デザイナー1名という開発体制でスタートしました。

最初は私が会社設立前から作成していた要件定義書とラフなデザインを基にまず人に触ってもらえるものを作るということをゴールとして開発を開始しました。
仕様書通りにまずは動くものを作るというところからスタートしているので、アジャイルではなくウォーターフォール(WF)に近い手法でした。
メンバーも少ない中で、アジャイルを運用するのも大変なので、まずはWFで開始してお客様からの声が聞けるようになったタイミングでアジャイルに移行するというアプローチで問題無かったかと思います。

週次の進捗が読めない!?⇒アジャイル開発向けタスク管理ツールの導入

当初MVPの開発は3カ月ほどで完成する予定だったのですが、完成まで5カ月ほどを要しました。
この時は週次の開発会議を開催するものの特に進捗の無い週もあるなど、進捗管理が最大の課題でした。まずはお願いしている副業の人にタイムラインを意識していただくために、エクセルで詳細なタスクレベルの工程表を作り管理していくという手法を取りました。
暫くこの方法で運用していたのですが、副業のエンジニアの方も5名を超えてきたころのタイミングで本格的にアジャイルを導入すべくタスク管理ツールの導入の検討を開始しました。
タスク管理ツールに関しても知識がほとんどなかったので、5つくらいのツールを横並びにして比較するなど、結構時間をかけて検討してしまったのですが、カンバン方式でのタスク管理ができること、ストーリーポイントの見積りができる、カスタマイズなどの運用の手間がかからない、費用がかからない、などの条件から最もスタンダードであると思われるJiraに落ち着きました。(Jiraはユーザー10名を超えるまでほとんどの機能を無料で使うことができるので非常にオススメです)
Jiraを導入してからは各人のタスク(チケット)のストーリーポイントを見積り、各人に割り振っているすププリントごとの業務量が適切かを判断した上で、スプリント計画会議にてタスクを伝達できるようになりました。このようにすることで、各人が1スプリントでこなせるタスクの量が見える化でき、開発進捗の計画が立てやすくなりました。

本番環境でバグが発生!?⇒スプリントのサイクルの見直し

2020年末頃からは複数のユーザー企業でのPoCも決まり、いよいよユーザーがプロダクトを使うようになりました。プロダクトを使い始めていただくと、ポジティブなフィードバックと共に、UIの面での指摘や改善要望、追加機能開発要望をいただけるようになりました。
この頃の一番大きな問題としては、いただいた要望に対して、迅速に開発を進めて本番にリリースした結果、ユーザーに使ってもらうタイミングで初めてバグが見つかるということでした。
この時の開発の進め方としては、1スプリントは1週間単位で行っており、スプリント開始/完了が毎週火曜日で、スプリントが完了した翌日水曜にはバグ出しを行い、木曜夜にはリリースをするという状況でした。また、スプリントに乗せたい新規の開発要望などはスプリント開始前日に入るといったこともありました。
そのため、①開発したい仕様検討が曖昧なまま開発に着手してしまう②バグ出しから本番リリースまで期間が身近過ぎるため社内で洗い出し切れなかったバグが本番に残ってしまう、ということが課題の大きな原因であったと考えられます。

この課題を解決するために、以下図のように開発サイクルの見直しを行いました。

ポイントとしては、
① 仕様検討の会議をスプリント開始前の週の週末に実施することで、仕様をより精緻にする
② スプリント終了後のバグ出しから本番リリースまで約10日間の期間を設け、本番リリース前にもFIX確認を行うことで、しっかりとバグ修正を社内で行う
という点です。

スプリントサイクルの見直しに伴い、開発要望検討~本番リリースは最短で1カ月ほどかかるようになったのですが、じっくりと開発に取り組むことで本番環境でのバグ発生は大幅に削減されました。

ユーザーからの要望増加!?⇒要望をプロダクトの方向性に合わせて優先度をつけていく

現在は多くのお客様に活用いただいたり、商談を進めて行く中で様々なご意見を頂戴することがあります。
SaaSというビジネスモデルの特徴上、このような多くのお客様の声を基にプロダクトを改善していくことで、既存のユーザーにもさらに使いやすいプロダクトを提供できる、ということがユーザーにとっての大きな一つのメリットなのですが、では様々な声に優先順位をつけてどのタイミングで開発に反映していくかという部分は非常に重要で難しい問題です。
場当たり的に1社の声を聞いて機能追加をおこなったところ、他のユーザーにとっては必要の無い機能であったということがリリース後に判明し、貴重な開発リソースを無駄にしてしまう、ということも起こり得ます。
ここで重要になってくるのは、顧客の声を聞いてすぐに開発に着手するのではなく、プロダクトの方向性(＝解決したい顧客の課題に対するプロダクトの課題解決アプローチ)に照らし合わせて、大筋の中でその声がどこに位置するのかを鑑みて開発タイミングを検討していくということかと考えています。
東京ファクトリーの開発しているProceedクラウドも解決したい課題が「技術継承」「業務効率化」「サプライチェーンの見える化」など、複数に分かれているのですが、大筋の中での開発タスクの位置づけを意識するために、プロダクトロードマップを引く際に、開発したい機能の横にその機能が搭載されることにより解決する課題を記載するようにしております。

今後やりたい事

今後は以下に取り組んでいきたいと考えています。
① 顧客環境でのバグ発生の可能性を下げたい
② リリースに伴う顧客の負荷を下げたい
③ 1年単位のプロダクトロードマップ検討~開発までのブレーク

① 顧客環境でのバグ発生の可能性を下げたい
業務アプリケーションを提供するにあたって不具合を顧客環境に出さないということは当たり前ですが、非常に重要なので、(機能リリースの速度も大切ですが)速度が多少犠牲にしてでも不具合を出さないということを強く意識して今後も開発を進めて行きたいと思います。
また、弊社は技術的負債がたまりにくい技術スタックにはなっていますが、MVPをクイックに作っていく中で一部負債になっているものも存在しています。技術的負債については、予期せぬ不具合を招くだけでなく、今後のエンジニア採用力などもに影響を及ぼす可能性があるので時には機能開発より優先して取り組んでいきます。
加えて、現在はUIテストを手動で行っているのですが、プロダクトの機能が増えていく中で、手動では見切れない範囲が多くなっています。そのためAutifyなどのE2Eのテスト自働化ツールの導入を現在検討進めています。

② リリースに伴う顧客の負荷を下げたい
東京ファクトリーでは現在2週間に1回本番環境でリリースを行っているのですが、ユーザーにとって頻繁にUIが変わることは負担になっているかと感じています。
将来的には新規機能リリースのサイクルを2か月や四半期などの単位に切り替えたいと考えているのですが、それに伴い、現在ローカル-Dev-本番となっている環境のなかでDev-本番の間に顧客ヒアリングに使えるデモ環境を設けて、本番リリース前に既存ユーザーに新規機能を確認いただけるようにしていきたいと考えています。

③ 1年単位のプロダクトロードマップ検討~開発までのブレーク
現在はプロダクトロードマップは3~5カ月くらいの感覚でアップデートしています。
まだプロダクトの市場性の仮説検証の要素も多分にある時期なのですが、今後より市場性が固まってきた段階で「中長期のプロダクトロードマップ」 ー「 中期のロードマップ」 ー 「短期的な開発計画」 ー 「スプリント」が上手く連動するような仕組みを構築していきたいと考えています。

上記①～③を実現していくためにも東京ファクトリーではまだまだ人手が不足しているので、ご関心のある方は是非カジュアルにお話をさせてください。

Meety作りました⇒コチラ