立ち上げ期はロードマップ不要？ いつからいる？ 12.5億円調達、アルプのロードマップ変遷

※2022年2月8日に開催された【開発PM勉強会〜SaaSの開発ロードマップ、マイルストーンどう決める？〜】 より、アルプ株式会社の前川裕一さんによる【アルプのロードマップ変遷】を書き起こし形式でお届けします。

＞＞＞「開発PM勉強会」の記事一覧はこちら

アルプのロードマップ変遷

「アルプのロードマップ変遷」というタイトルで始めさせていただきます。前川裕一と申します。よろしくお願いします。

Twitterは（@_kaelaela）でやっていて、僕もソフトウェアエンジニアがバックグラウンドで、昨年までずっとエンジニアをやっていました。今年から「Scalebase」のプロダクトマネージャーをやっています。

「Scalebase」は、サブスクリプションビジネスなどを管理するビジネスインフラとしてのSaaSです。僕自身は、このサービスを他の外部サービスとつないでいく、「インテグレーションエクスペリエンス」と言われるようなシステム間の統合をメインで見ています。製品内容は、ちょっと説明する時間がないので、興味のある方はぜひ見てください。

今日の話ですが、創業から今までのフェーズでどのようにロードマップと関わったか。こんな一例もあるんだな、くらいの感じで見ていただけると助かります。

「これまでのアルプ」から「これからのアルプ」に、どう変わってきたか、ご紹介します。

開発黎明期

これまでのアルプはロードマップとは言いつつ、開発手法の方が重要でした。一番最初の開発の黎明期は、ロードマップなんて存在しませんでした。プロダクトオーナーもいないし、そもそも何を作るか模索していたので概念図を設計するなど、とにかく作るものをモデリングしまくっていました。

創業期からずっとNotionを使ってドキュメント管理していたのですが、Cacooとかも使っていました。

右の図のような感じで、こういう概念を取り扱い、それに関わる概念はこういうものだよね、というレベルの開発をしていました。ここの段階でそもそもロードマップが必要にならなかったというのがあります。

ユースケース期

そこからユースケース期と僕は言ってるんですけど、ユーザーストーリーマッピングを作り、開発の優先度が決められるようになってきました。

ここでは、ビジネスデザイン、フロントエンド、バックエンド…と領域が分かれていますが、社員もほぼいなかったので、ビジネスプロダクトオーナー兼プロジェクトマネージャー兼セールスとCSみたいな。ぐちゃぐちゃの状態で、その人たちが基本的な要件を決めて概念図に落とし込み、タスクやユースケースのレイヤーまで落とし、どう実装しようかといった感じで考えていました。

このタイミングでもロードマップはないのですが、バックログの管理ができました。なので、優先度決めなど「ユースケースを達成するのにはこれが良いよね」「ユーザーストーリーを達成するのに、こういう風にして行くのがいいよね」といった議論をしていました。

創業初期からDDD（ドメイン ドリブン デザイン）を実践していて。お客様に説明する言葉と、開発で使う言葉が一致するようなユビキタス言語を使いつつ、実装もそういう状態にしていました。

スクラム期

で、このあたりでゆるくPdMの役割も出来上がってきたと思います。当時はCacooではなく、Miroを使っていました。ホワイトボードとして使ったり、概念図もアップデートしていったり。

開発チームも規模も大きくなってきたので、スクラム開発をするようになりました。社内の開発チームの中を小さな開発チームを2つに分けて回してみました。そうなってくると、どんどんタスクの差し戻し、デザイン相談が増えて混乱に陥りました。

そういった中でもなんとかβ版のリリースを行い、何を作らなきゃいけないか、ある程度見えてきた時期。

ただし、わちゃわちゃとやっているうちに・・・

「自分の手が空いているのでこっちのタスクをやります」「本来やっていたはずの作業が終わったので、次何したらいいですかね？」「できる限りやって行きます」みたいな感じでフロー効率が、リソース効率になってしまう問題がありました。

この時点ぐらいから「要件を定義している人」と「実装している人」の距離がちょっと離れてきました。なので「なぜ」を明確化するためにPRDなどを書き始めました。この頃もNotionとMiroを使いつつ、スクラムをやっているのでプランニングポーカーとかhatjitsuというツールを使ったりしていました。

カンバン開発期

スクラムもいいのですが、結構混乱も。タスクの要件定義をする部分が、スクラムだと時間かかってしまうので、カンバンに移行してみようとなりました。

導入社数も増えたし、運用やサポートも開始されてきたので、機能開発プラス、改善も行わなきゃいけなくなってきて。そこをちゃんと合わせてカンバンにしていこうとなりました。

このタイミングからバックログも複数に。プロダクトオーナーはとにかくレビューが大変な状況になりました。そこでプロダクトオーナーと、チームの間に、誰が何をやっているのか、メインで見る人としてプロジェクトマネージャーを立てて。ただ、板挟み構造になっていました。

この頃は要件を書く上でNotionを使ってみました。この頃からデザインツールはfigmaになって。figjamを使い、ホワイトボードとして今も使っています。タスク管理もかなり厳しくなってきたので、JIRAを使うようになってきました。

…今日のテーマを聞いてて「あれ？全然ロードマップが出て来ないじゃん」と思ったかもしれませんが、ざっくり半年ごとぐらいの目標はありました。何月までに、このお客さんに対し、こういう導入が必要なので、その差分を開発していきましょう。完遂しましょうといった目標がありました。

ただ、その顧客のニーズが変わるので、存在はしているけど、あまりみんな見てないし、それをメンテナンスする人も別にいないのでスケールしない。エンジニアも気にしていない、みたいな状況になっていました。

これ、なんなんだろう？と思って。「正しいものを正しくつくる」という本にもありましたが、僕らの最初に作ったプロジェクトは、仮説検証し、MVPを探している状態なので、そこにロードマップがあっても、結局ドラスティックに変わってしまう。なので、諸説あると思うんですけど、この左側のタイミングではロードマップ不要なのでは？というのが、僕の考えです。

根本的に変わってしまうと、ロードマップを立てたところであまり意味がない。作ること自体が大変なのに、変わってしまう。なので、必要ないかもな…と思っていて。特に開発者が多いのですが、「ロードマップがないと困ります」とは誰も言っていない。なぜかというと、作ってみないとわかんない。これが本当にいけるのか、わからなかったので、むしろ「なぜそれを作るのか」を知りたがっていました。

ビジョン駆動開発へ

これまでのアルプは、ロードマップより開発手法。どう正しいものを作るかっていうことにフォーカスしていました。

ただ、「これからのアルプ」はちょっと変わってきました。ビジョン駆動開発と勝手に名前を付けています。

作ってくると、ある程度、その存在が見えてきます。僕らが作っているものは何なのか。どういう価値があり、どういうものを提供しているのか。それがわかってくると「じゃあ、どこを目指すんだろうか？」「これを使ってどういう世界にしたいのか」が知りたくなってきます。

且つ、どんどん新しいメンバーも増えてくる。なので、それをどう伝えていけばいいんだろう？という部分に困ってきます。

そこでプロダクトビジョンを策定していきました。Scalebaseのプロダクトビジョンは「意思決定と実現をつなぎ、経営をScaleさせる」です。弊社の坂口さんがブログを書いているので、そちらもぜひ読んでもらえたらと思います。

（参考）ビジネスとプロダクトの意思決定の共通基盤、プロダクトビジョンを設定した話
https://note.com/sakaguchithealp/n/n77486a9e7e1b

この時に「ロードマップってどうつくったらいいんだろう」と結構調べたのですが、海外の記事で戦略の階層みたいなもので紹介されていました。

中央付近、ピンクの点線のところにプロダクトのビジョンがあり、それを構成するオブジェクティブが存在していて。それぞれに各テーマがある。さらにそこを括ったものがプロダクトのロードマップですと。

一個一個のビジョンに対し、どういうオブジェクトがあり、どういうテーマがあると良いか。どこがプロダクトの戦略で、それ以降の機能をどうするか。どういうものを作るか、ここがリリースプランになる、という紹介の図です。確かにわかりやすいと思っていて。僕らもこういうものにした方がいいなと考えました。

一方でチームは先ほど言った通り、「要件を決めている人」と「実装している人」の間に、プロジェクトマネージャーが挟まり、納期ベースでコミュニケーションしてしまっていました。ここで結構齟齬が発生しがちでした。なので「みんな、自分の役目を果たしているが、なんとなくうまくいかない」という状況も出てきて。それをどうにか変えたかったのです。この話に関しても弊社の竹尾さんがブログを書いているので、見てもらえると助かります。

（参考）「超」 自律性を追求してプロダクトチームを分割した話
https://note.com/showmant/n/nc74e7a119352

それに合わせて、先ほどのプロダクトビジョンからオブジェクティブを導き出して、それごとのチームを作るようにしていきました。

資料を見てもらえると細かい内容がわかりますが、そうなった時に各開発チームにプロダクトマネージャーが入ったほうがいいので、分割しつつ、プロダクトマネージャーを配置するようにしました。

プロダクトオーナー1人、PdM3名のプロダクトチームみたいなものが出来てきて。その中で僕自身が考える「Scalebaseってこうだよね」とか「あの人が考えるScalebaseってこうだよね」とか、どんどん出てくるのですが、そこをビジョンから逆算し、方向性を揃えていく。そういった目的でロードマップを作りました。

このタイミングでNotionとJIRAは同じですけど、ProductBoardを使ってニーズを拾い集めるところから要求分析するところまでやっています。

ちょっと要注意なんですけど、work in progressなので、開発手法と一緒に業務改善中でもあります。組織間での共通認識としてロードマップをデザインし、みんなに公開するようにしています。常にこれはアップデートされるもので「検討中」みたいな感じにはなっていて、こういう感じで用意しています。

合わせてProductBoardの中身も同じようにタスクとかどういうものを開発して行くかっていうのを紐付けてオブジェクトと一緒に一致させています。

ハイインテグリティーコミットメント

いろいろと言ってきましたが、ロードマップを考えるのも大事ですが、本当に大切なことはハイインテグリティーコミットメントだと思っています。

開発チームに対し、禁断ワードって「で、いつ出るの？」ですよね。一方でプロジェクトマネージャーは「いつ出るの？」を毎日聞かなければいけない役割でもあって。エンジニアとしては、最速で作ろう、みんなでいい方向に開発しようとしているに決まっています。それを「いつまでにできます」と正しく伝えたいのに、ロードマップみたいなものが存在することで「いつ出るの？」と聞かれるのがとにかく早い。これは、問題だと思います。

たとえば、（立ち上げフェーズにある）ビジネスとして「それは成果が期待できるか」は分かっていないし「作れるか」も分かっていない。「プロトタイプはできたんですか？」もできてない。「品質に問題はないか」に関しては、もっともっと後の世界です。

「顧客を満足させられるか」は出してからじゃないとわからないです。そういう問題がたくさんあるのに「いつ出るの？」という話をとっても早いタイミングにしてしまうのは、あまりよくありません。プロダクトマネージャーとして、僕はそのコミットメントは無くせないけど、どんどん小さくすることはできます。なので、開発チームも、開発者も、僕自身も、納得できるコミットメントをしていきましょうというのが今日のまとめです。ありがとうございました！

＞＞＞「開発PM勉強会」の記事一覧はこちら

編集 ＝ CAREER HACK