アジリティの高いプロダクト開発を実現する、フルサイクルな組織と開発フロー ー後編ー
株式会社oveflow VPoEの佐藤歩さん(@ahomu)による、弊社エンジニアの岡本健さんのインタビュー。
後編では、改めて現在の開発フローについてお話を伺いつつ、今後の展望やResilireが求める人材像についてもお話を伺っていきます。
※前編はこちらからお読みいただけます。ぜひご覧ください。
現在の開発フロー
佐藤：前編では主にエンジニアの中の開発フローやスプリントの話などを伺ったのですが、改めて開発全体の流れを教えていただいてもいいですか。
岡本：はい。リアーキテクチャについて言うと機能の一覧があって、それに対してデザインとかユースケース、機能要件等を、プロダクトオーナーとプロダクトマネージャー、テックリードと僕の4人で決めて、そこからすぐ開発に進んでいくというのが現状です。そこにも一定の課題があると思っていて、機能要件としてのフィックスのタイミングがわかりづらい。決める人はプロダクトオーナーと決めたのですが、結局開発やデザインに落としてみると意外とうまくいかなかったり、細かいレベルで課題が出てくることが多くて、現在はそこの開発フローを整理し直してる状況になっています。
佐藤：トップダウンでフィックスしたと思っても、結局逆流というか、やってみたらあれやこれやと違うのが出てくるから、そこら辺の可逆性をどう担保するかみたいなところですよね。
岡本：そうですね。プロジェクトの開発フロー全体でいうと、開発そのものの前後にも様々な工程があって、プロダクトの要求仕様や見積りのための最低限の機能仕様書を固めるであったりとか、Lo-fi UIは言われてるものをちゃんと作るであったりとか、プロダクトの品質であったりとかを大体定めたうえでデザインとか開発に入っていくという流れを、改めてちゃんと言語化して再定義しているっていうのが現状ですね。
佐藤：仕様策定から開発の流れになっていくという、かっちりした開発フローという感じがしますけれども、これはもう今後ずっとやっていく感じですかね。
岡本：そうですね。
少ないリソースでアジリティを損ねず回していく
佐藤：ここら辺のプロダクトの作り方って一つの理想形かなと思うのですが、これを実現するにはどれぐらいの時間軸でという計画は、すでにあるのでしょうか。
岡本：これはすぐ実現したいと思っています。ただ一つ一つの成果物の精度を高いものにしようとするとハードルが高いので、決めなきゃいけないことを理解しておきながら、今の開発を止めずにアジリティを高めていくところが、まず足元目指すところです。現状開発に対しては20人ぐらい、デザインも3、4人いるのですが、この手前のところのリソースという意味だと、先ほどお伝えした4人で回しているというのが現状です。だからこそ個々の役割を明確にしたうえで、そこでもしリソースが不足しているのであればPdMの採用を進めていく、等の方針も定まってくると思うので、まずは回してみるっていうところに軸を持ってます。
佐藤：この辺りが短期的にやっていきたいところですかね。
岡本：そうですね。
Resilireのミッションを達成するための、フルサイクルエンジニアリングとマルチプロダクト戦略
佐藤：ありがとうございます。じゃあそろそろもう少し中長期的なところで、改めて開発チームを構築していくにあたって大切にしていることを聞かせてください。
岡本：そうですね。プロダクトを開発するにあたって「フルサイクルエンジニアリングでありたい」というところですね。僕らのミッションは「データでサプライチェーンをアップデートする」ことで、そのためには膨大な量のデータが必要になる。それだけのデータを蓄積するためには、複数の異なるセグメントに対して、それぞれ違う切り口のプロダクトが必要になると思っています。つまり将来的にマルチプロダクトの戦略を取る必要性があって、さらに各セグメントに対してなるべく深いデータを収集できるようなプロダクトでなければいけません。
佐藤：スタートアップ初期からマルチプロダクト戦略を取られるのは、開発チームとしての難易度もぐっと上がりそうですね。
岡本：そうですね。マルチプロダクト戦略を取る上で特に気をつけるべきは、プロダクト単位でのアジリティを如何に高い状態で保つかだと考えています。マルチプロダクトでもアジリティを高い状態に保つには、組織の課題と開発の課題の分離など複雑性はあるものの、マルチプロダクトでも開発スピードを高められるアジリティの高いプロダクト開発を実現するには、組織のサイジングが重要です。各組織のサイズとしては、一つのプロダクトが着実にアウトプットを出せて、かつコミュニケーションコストの増大を防ぐサイズに最適化されるべきだと思っています。大体学校の1クラス分ぐらいよりちょっと少ないぐらいが、目指すべきサイジングですね。それを踏まえると、一人のエンジニアの守備範囲というのはどうしても広くなります。要は人数ではなく一人一人の質でカバーすることになるし、気にする範囲というのは広くなるはず。だからこそ「フルサイクルエンジニアリング」を提唱しているという背景になります。
佐藤：いわゆるコンパウンドスタートアップと言われるような戦略で解釈して良いですかね。
岡本：良いと思います。とりあえずプロダクトをたくさん作ればいいというわけではなくて、データを中心にして、そのデータの質を上げるために、いくつかプロダクトが生まれてくるような想定です。
佐藤：データ軸で面を取りに行くというところですね。あとさっきの人数規模の話ですけど、チーム構成としてはどのようなものを想定されていますか。
岡本：個人的にイメージしているプロダクトのチームって、セールスもCSも含む形をイメージしていて、そこも含めて、1クラスよりもちょっと少ないぐらいという感覚ですね。チーム構成に関しては、フェーズによるのですが、例えば初期フェーズだったら売れないことには始まらないので、セールスの声をちゃんと聞いた方がいいし、分母として増えてきたらCSの影響度合いが大きくなってくるはずなので、CSの声をよく聞いたうえで機能開発の優先順位を決めていきたい。なのでプロダクトとしてのチームは、やっぱりセールスまで含んでるのが理想的な状態かなと思いますね。
佐藤：開発の意思決定に影響する部分も含めて、広義の開発フローと言えるかなと思うのですが、今おっしゃっていたようなセールスとかCSとの連携に関して、今後の開発体制の展望はいかがでしょうか。
岡本：まだそこの連携は弱いのですが、エンジニアとしてはそこまでアンテナを張ってほしいというところがあって、それも含めての「フルサイクルエンジニア」だと思っています。現状の取り組みとしては、NotionにCSから上がっているVoice of CustomerのBacklogがちゃんと積んであったり、そのあたりはちゃんとやっていますね。また、プロダクトはResilireのミッションを達成することも目的であるので、Resilireのミッションにフィットしたものとお客様の声と合致したものの優先順位をあげてプロダクトを作っていく形になっています。
佐藤：プロダクトとかResilireとしてのそもそものミッションの芯があって、その芯の中に作る予定っていうのがたくさんあって、その中のその優先順位が顧客の声とかで、入れ繰りされるみたいな。
岡本：そのシーンを決めるっていう意味だと、もうそこは多分職能は関係なくて、こうあるべきだよねというような話がフラットにできたらいいなと。今現時点でそうできているので、これが継続できたらいいなという話はしています。
佐藤：そうなるとそのプロダクトに対して、自分から頭を使ってアイデアや意見を発信してくれる人が入ってくれる方がいい。
岡本：そうですね。 そのような人が入ってくれることで、フルサイクルエンジニアリングかつ最小限のチーム構成でマルチプロダクト戦略を前に推し進めることができ、アジリティの高い開発チームを構築していけると思います。
Resilireが求める人材像
佐藤：プラスアルファで求める人材像みたいなのはありますか。 岡本さん自身が大切にしているのは、どういったところでしょうか。
岡本：気持ちの切り替えがちゃんとできる人。「考えること」と「決めること」、「それを実行すること」、その三つを分離して考えられる人がいいと思っています。Resilireが思い描いてるゴールが正しいかどうかなんて誰も評価ができないと思っていて、会社が大きくなることで証明するしか、多分ない。そうしたときにそもそもそのゴールって合ってるんだっけ、っていうような発想ができることが、第一段階として大事だと思っています。一方で、自分が出したアイデアにならなかったとしても、組織として決めたならそれに向かって動いていく。そういう気持ちの切り替えができるようにするには、さっきの「考えること」と「決めること」、「それを実行すること」が、それぞれ別物だとちゃんと理解している人。難しいけど大切なことなんじゃないかなと思っています。
佐藤：各段階でちゃんと参加の姿勢は見せつつ、決まったことにはフォロワーシップを発揮し、各ステップの狭い視点で変に執着しないみたいな。
岡本：そうです。
フラットな組織 Resilireの、今後の課題
佐藤：前提条件のところのフルサイクルエンジニア、マルチプロダクトの話がありましたけど、今後の開発フローにおいて、より具体的にこうしたいとかはありますか。
岡本： 今進めている短期的な施策で理想的なところを目指しつつ、それ以上のフローをブラッシュアップしていく。経験を積んでいくしかないのかなと思ってます。
佐藤：細かい改善はありつつも、徐々にその理想の形に向かっていくということですね。そこをどういうプロセスで進めていきたいか、イメージってお持ちですか。
岡本： そうですね。トップダウンでなんでも決めていくというよりも、個々が納得感とモチベーションを維持しながら進めていくことがベースかなと思います。これはResilireの良いところでもあり悪いところでもあるのですが、組織がフラットなので、トップダウンで言うにしても、トップって誰ですかという話になるんですよね。津田さんしかいないので。結局それで行こうって言っても、反対意見が出てしまうと詰まっちゃう。だとするとちゃんと課題を言語化して認識を共有して、頭からちゃんと理解して、お互いの理解レベルを合わせて着実にプロダクトとして積み上げて前進していく形になる。 5月にリアーキテクチャのプロジェクトが稼働し始めてから、4、5か月の時間をかけているという背景にも、こういった組織のフラットさ、お互いの納得感を確かめ合いながら進めていくといった風土がありますね。
佐藤：中心人物になる方がおられるかなとは思いつつも、コミュニケーションとしては対等に進めているっていうところが一つポイントになりそうですね。
岡本：それは僕はすごくいいところだと思うのですが、こういったときは時間がかかりますね（笑）
佐藤：ここら辺の開発フローも、問題意識を持った人が自発的にやるなかで、その課題感をちゃんと共有しながら浸透させていくところであり、個々があくまで対等な関係としてやってるから時間がかかると。
岡本：そうです。フラットって聞こえはいいじゃないですか、でも逆にこの状態をよしとできる人っていうのは、採用の一要件としてあるのかもしれないです。
佐藤：そうですよね。ちょっと気になったところとして、マルチプロダクトでマルチチームになったときに、各チームを育てるのに数ヶ月単位でかかっていくってなってくると、逆にスピード感がスポイルされちゃう部分もあるような気がするので、その辺りはどうするのかなと、率直に思ったところはありました。
岡本：まさにそうですね。横串で統一されていて、例えばそれこそコンパウンドスタートアップの定義通りだと思うのですが、データ中心で、その周辺のデザインとか思想自体は共有しましょうというところ。その思想を共有するための象徴が、将来的にマルチプロダクト化してきたときに必要になってくると思っています。それがCEOなのかCxOなのか、あるいはルールベースで全て言語化するという選択肢もあると思いますけど、そのあたりは必ず今後の課題になってくると思っています。
最後に
Resilireでは、エンジニアを積極的に採用しています！
弊社の事業やプロダクト、開発について、もう少し詳しく知りたいという方は、エンジニア採用ページ、採用デックをご覧ください。
社会課題の大きい領域のプロダクトづくり、シード期スタートアップといった裁量が大きく、スピード感のある開発に少しでも興味を持った方は、ぜひカジュアルにお話しさせてください！
岡本健のカジュアル面談はこちら
この記事が気に入ったらサポートをしてみませんか？