自己紹介
前川裕一氏：前川裕一です。アルプのロードマップ変遷について話します。資料はTwitterにも公開しているので、そちらからも見てもらえます。今日の参加者はPMやソフトウェアエンジニアのバックグラウンドの方が多いと思いますが、僕もそうで、2021年までずっとエンジニアをやっていました。
「Scalebase」はサブスクリプションビジネスなどを管理するビジネスインフラとしてのSaaSです。このサービス自体を他の外部のサービスとつないでいくような、システム間統合をメインで見るプロダクトマネージャーを、2022年からやっています。製品の内容に興味のある方はぜひ見てください。
今日は、創業期から今までのフェーズごとで、どのようにロードマップと関わったかについて、他社の一例というイメージで見てください。これまでのアルプと、これからのアルプがどう変わるかを紹介します。
ロードマップというものが存在しなかった黎明期
これまでのアルプは、ロードマップと言いつつ、開発手法のほうが重要でした。
なぜなら開発の黎明期は、ロードマップというものが存在しなかったからです。プロダクトオーナーもいないし、そもそも何を作るかを模索していたので、概念図を設計するなど、とにかく自分たちの作るものをモデリングしていました。
創業期からずっとNotionを使ってドキュメント管理をしています。アルプでは最近は使っていませんが、モデリングにはCacooを使っていました。
スライドの右の図のように、「僕たちはこういう概念を取り扱って、それに関わる概念はこういうものだ」というレベルの開発をしていたので、この段階ではそもそもロードマップは必要なかったというのがあります。
PdMの役割がゆるくできてきたユースケース期
僕はそこから先をユースケース期と呼んでいますが、ユーザーストーリーマッピングを作って開発の優先度を決められるようになってきました。そこではビジネス、デザイン、フロントエンド、バックエンドといった領域に分かれていましたが、ビジネスのメンバーにはほとんど社員がいなかったので、プロダクトオーナー兼プロダクトマネージャー、プロジェクトマネージャー兼CSみたいなぐちゃぐちゃな状態でした。
その人が基本的な要件を決めて、それを概念図に落とし込んでタスクやユースケースのレイヤーまで決める。そこからどういう実装をしようかと考えていました。このタイミングではまだロードマップはありませんが、バックログの管理はできたので、その優先度決めや「ユースケースを達成するのにはこれがいい」とか、「ユーザーストーリーを達成するにはこうするのがいい」という議論をしていました。
そういう初期からDDD（Domain-Driven Design）を実践していて、お客さんの説明する言葉と、開発で使う言葉がすべて一致するようなユビキタス言語で実装していました。PdMの役割も、このあたりでゆるくできあがっていたと思います。当時はCacooではなく、Miroをホワイトボードとして使ったり、概念図をアップデートしたりしていました。
フロー効率がリソース効率になってしまっていたスクラム開発期
そこから、開発チームの規模も大きくなってきたので、スクラムの開発をするようになりました。社内の開発チームを小さな2つの開発チームに分けて回してみると、タスクの差し戻しやデザイン相談がどんどん増えて、混乱に陥りました。
そんな中でもなんとかベータ版のリリースを行い、何を作るべきかがある程度見えてきました。ただし、いろいろ並列で作業をしていると、「手が空いているのでこっちのタスクもやります」とか、「本来やっていたはずの作業が終わったので次に何をしたらいいですか」とか、「できる限りやります」みたいな感じで、フロー効率からリソース効率になってしまう問題がありました。
この頃から、要件を定義している人と実装している人の距離が少し離れてきたので、その理由を明確化するためにPRD（Product Requirements Document）などを書き始めていました。このときもNotionやMiroを使いつつスクラムをやっていたので、プランニングポーカーにHatjitsuというツールを使ったりもしていました。
プロジェクトマネージャーが板挟み構造になっていたカンバン開発期
スクラムをやったのはいいのですが、けっこう混乱もあり、タスクの要件定義に時間がかかってしまうので、カンバンに移行しようと考えました。導入社数も増えて、運用やサポートも開始されたので、機能開発＋改善も行わなければいけない。それに合わせて、カンバンにしようと思いました。
このタイミングでプロダクトバックログも複数になり、プロダクトオーナーはとにかくレビューが大変な状況になりました。また、デリバリーという言い方はあまり好きではありませんが、誰が何をやるかリソースマネジメントをする役割としてプロジェクトマネージャーが生まれましたが、プロダクトオーナーと開発チームの間に、板挟み構造になっていました。
この頃からデザインツールはFigmaになり、Figjamは今もホワイトボードとして使っています。タスク管理もかなり複雑になり、バックログが複数になったあたりから、JIRAなどを使うようになりました。
「作ってみないとわからない」なら、ロードマップは不要？
今までの発表を聞いて、「ぜんぜんロードマップの話が出てこないじゃん」と思ったかもしれませんが、ざっくり半年ごとの目標はありました。「このお客さんに対して、何月までにこういう導入が必要なので差分開発をしましょう、早く完成させましょう」という目標はありました。
顧客のニーズは都度変わるので、存在はしているけど、みんなそんなに見ていない。それをメンテナンスするだけの人も特にいなかったので、スケールしない。エンジニアも気にしていない状況になっていました。
この状況を、何だろうと思って調べていました。『正しいものを正しくつくる』という本にもありましたが、僕らが最初に作っていたプロダクトは仮説検証している、つまりMVPを探している状態なので、そこにロードマップがあっても、結局ドラスティックに変わってしまう。
僕はスライドの左側のタイミングでは、ロードマップは不要なのではと思いました。諸説あると思いますが、僕の考えはそうです。
根本的に変わってしまうと、ロードマップを立てたところであまり意味がない。作ること自体大変なのに、変わってしまうので、必要ないかもと思っています。特にアルプは開発者が多いので、「ロードマップがないと困ります」とは誰も言わない。なぜなら、作ってみないとわからないから。まだ、今作っているものが本当にいいのかがわからないので、むしろなぜそれを作るのかを知りたがっていました。
これからのアルプは「ビジョン駆動開発」に
これまでのアルプは、ロードマップより開発手法、「どうやって正しいものを作るか」にフォーカスしていましたが、これからのアルプは少し変わります。「ビジョン駆動開発」と勝手に名前をつけていますが、ある程度作った存在が見えてくると、僕らが作っているものは何なのか、どういう価値があって、どういうものを提供しているのかが見えてきます。
それがわかってくると、じゃあどこを目指すのか、これを使ってどういう世界にしたいのかが知りたくなってくる。さらに、どんどん新しいメンバーも増えるので、それをどうやって伝えていけばいいのかという根本的な問題が出てくる。
そこでプロダクトビジョンを策定します。弊社の坂口がブログを書いているので、ぜひ読んでください。Scalebaseのプロダクトビジョンを「意思決定と実現を繋ぎ、経営をScaleさせる」としました。
これに対してロードマップをどう作ればいいのかを調べていました。（スライドを指して）海外の記事に戦略の階層（ピンクの点線の部分）として紹介されています。
このプロダクトのビジョンに対して、それを構成するオブジェクティブが存在して、それぞれテーマがある。そこをくくったものがプロダクトのロードマップです。その一つひとつのビジョンに対してどんなオブジェクトがあって、どんなテーマがあればいいかはプロダクトの戦略。それ以降の機能や、どういうものを作るかがリリースプランになるという紹介ですが、これは確かにわかりやすくて、僕らもこういうものにしていけたらいいなと考えました。
一方、先ほど言ったとおり、チームは要件を決めている人と実装している人の間にプロジェクトマネージャーが挟まって、納期ベースでコミュニケーションしてしまっていた。ここに齟齬が発生しがちで、そうなると、みんな役目を果たしているけどなんとなくうまくいかない状況に陥ったので、それをどうにか変えたかった。この件に関しても弊社の竹尾がブログを書いているので見てください。
併せて、先ほどのプロダクトビジョンからオブジェクティブを導き出して、それに対するオブジェクティブを設定して、それぞれのチームを作るようにしていきました。資料を見てもらえれば、このあたりの細かい内容がわかります。
各開発チームにプロダクトマネージャーが入ったほうがいいので、そのように分割しつつ、プロダクトマネージャーを配置しました。プロダクトオーナーが1人と、プロダクトマネージャーが3人いるプロダクトチームができました。
その中で「僕自身が考えるScalebaseはこう」「あの人が考えるScalebaseはこう」といったいいプロダクトがどんどん出てきますが、それをビジョンから逆算して方向性を揃えていくためにもで、ロードマップを作りました。このタイミングで、NotionとJIRAは同じですが、ProductBoardを使ってニーズを拾い集めるところから要求分析までやっています。
注意点として、Work In Progressなので、開発手法と一緒に今も改善中です。組織間での共通認識としてロードマップをデザインして公開するようにしています。これは常にアップデートされるものなので、検討中としています。
ProductBoardの中身も同じように、タスクやどういうものを開発していくかを紐づけて、オブジェクティブと一致させてみました。
大事なのはハイインテグリティーコミットメント
ロードマップを考えるのも大事ですが、一番大事なのは、ハイインテグリティーコミットメントだと思っています。開発チームへの禁断ワードは「いつ出るの？」です。プロダクトマネージャーは「いつ出るの？」を毎日聞くような役割ですが、エンジニアは最速で作ろうとしているに決まっている、みんな良い方向に開発しようとしているに決まっていることを正しく伝えたい。
きちんと「いつできます」と伝えたいのに、ロードマップというものが存在することによって「いつ出ます」と聞かれるのが早いという問題があります。とにかく早い。
ビジネスとして、成果が期待できるかはわからないし、作れるのかもわからないし、「プロトタイプはできたんですか」と言われてもできていないし、もはや品質に問題あるかについてはもっとあとの世界でのこと。本当にリリースしたあとに顧客を満足させられるのかも出してみないとわかりません。
それなのに「いつ出るの？」と、とても早い段階で求めてしまうのはよくない。ロードマップは納期を決めるものではありません。僕はプロダクトマネージャーとして、コミットメント自体はなくせないけど少なくすることはできるので、開発チームの開発者も、僕自身も納得できるタイミングのコミットメントをしていきましょうというのが今日のまとめです。
ありがとうございました。
