急成長モビリティSaaSの開発組織の変遷と組織デザインで大事にしていること
はじめに
こんにちは。ニーリーCTOの三宅です。
弊社の開発組織のことを知ってもらいたくて開発メンバーや組織のカルチャーを紹介するnoteを多く書いてきました。弊社の開発組織をより知っていただけるよう、まずは私から開発組織の全体像とデザインしていくうえで大事にしていることを書こうと思います。その後、各チームリーダーからチーム紹介をしていく予定です。
ただ紹介しても面白くないので、開発組織がどのように変遷してきたかという歴史や、その中でどのような課題や苦悩があったか、それを解決するために何を考えてきたのかを時系列で紹介します。
今までの開発組織の変遷
Park Directがサービスをローンチしてちょうど4年が経ちました。
もう4年も経ったのかとあっという間に感じますが、ここに至るまでに開発組織も大きく変わったので、４つのフェーズに分けて紹介します。
フェーズ１：初期開発期
初期はオフショアメインで開発をしました。プロダクトの初期開発をオフショアで対応するスタートアップは珍しいかもしれません。弊社ではPark Direct事業を立ち上げる前から、インキュベーション事業というお客様の新規事業の立ち上げをワンストップで支援する事業を展開していました。その関係で、フリーランスやパートナー企業の方々とプロジェクトを組む機会が多かったのですが、今回お願いしたベトナムの企業も過去に一緒にプロダクトを作ったことがある企業だったので、オフショアに対する不安や抵抗はありませんでした。
なぜオフショア開発を選択したのかというと、開発リソースとスピード、そしてコストが大きな理由です。Park DirectはtoC、toB両方にWebアプリケーションを提供する必要があり、機能も駐車場の検索や契約だけではなく、決済など主要な機能が最初から必要だったので、初期からそれなりに作り込みをする必要がありました。開発だけでなく、事業戦略や営業、カスタマーサクセス、マーケティングなど他にもやるべきことが沢山あるなかでリソースもコストも有限でした。なによりCTOの自分は（当時はそもそもCTOと名乗っていませんでしたが）、インキュベーション事業の方でPark Direct事業の軍資金をせっせと稼いでいたので、コードを書く時間を捻出できていませんでした。そのため、実績のあるベトナムの企業と一緒に開発をすることを選択しました。オフショア開発を選択したことで、当時もですし今も苦労していることはありますが、リーズナブルかつスピーディーに開発ができたからこそ今があるので、オフショア開発を選択したことは良かったなと思っています。
当然、自分で書きたい作りたいという思いはありましたが、もしその選択を当時していたら、自分が様々な作業のボトルネックになってしまい開発期間は伸びていたと思いますし、インキュベーション事業の売上も減り資金調達が必要になるなど、事業に集中する時間がよりとれなかったんじゃないかなと思います。なので、世の中のスタートアップで初期プロダクトを自分たちで作るのが大変だと思ってる方がいらっしゃったら、こういうやり方もあるんだよと少しでも参考になれば幸いです。
フェーズ２：サービスローンチ後
サービスローンチ前にそれなりに作り込んだものの、まだまだ機能は足りない状況でした。また、実際に営業をしていくと想像以上に個社要望があり、それを柔軟に吸収するための機能開発をしないといけなかったりと、機能追加に追われる終わりのない旅が始まりました。
必要な機能が沢山あったので、リリースサイクルを上げていく必要があったのですが、当時の社内体制だとオフショア開発でスピードをあげていくことが難しく、日本での開発チームを立ち上げて完全にオフショア開発から卒業しました。
よくあるのは、事業や開発組織が大きくなってからオフショア開発を取り入れたグローバル開発体制へのシフトだと思いますが、弊社は逆の流れで、しかもローンチ後に早々にシフトをしました。今振り返ると大きな判断の１つだったのかもしれませんが、当時は迷いなく判断ができました。なぜかというと、これは今もずっと大事にしていることですが、「いいモノをいかに早く世の中にデリバリーできるか」、これをシンプルに追求していたら自然とそういう判断になりました。
オフショアでスピードが課題になるというと、コミュニケーションコストが想像しやすいと思います。確かにお互いが母国語ではない英語でコミュニケーションをするので多少は苦労があります。ただ一番苦労したポイントはドメイン知識の共有でした。Park DirectはVertical SaaSで、決済機能も提供していることもあり、かなり複雑なビジネスロジックを有しています。オフショアの方も優秀なエンジニアではあるのですが、ドメイン知識については日本や業界特有のものが多くキャッチアップが大変でしたし、こちら側も共有やレビューの負荷が高くなっていました。なのでオフショア開発から卒業して日本内製にシフトする判断をしました。
実際に日本内製にシフトしてみると、ドメイン知識の共有やレビュー負荷、コミュニケーションコストが軽減され、だいたい2週間間隔で新機能をリリースできるようになりました。スプリントチームを日本とベトナムの２つにわけ、リリースサイクルを合わせて、QAのタイミングで日本側に合流させてリリースコントロールするやり方で少しずつ内製に寄せる方法をとりました。特に困ったこともなくスムーズにシフトできましたし、開発スピードはしっかりと上がりました。
決してオフショア開発が悪いというわけではありません。ただ、業界知識や複雑な業務ロジックなどが必要とされるプロダクトを文化も言語も異なるグローバル体制で開発していくには、それなりに準備や体制・仕組みが必要だと思っています。今すぐという話ではないですが、将来開発スピードをあげるために、再びグローバル開発にチャレンジしたいと思っています。
フェーズ３：２グループ制に移行
順調に事業が伸び始めて、どんどん開発が追いつかない状況になっていきました。システムが大きくなってきたため、機能追加だけではなく、品質に対するへのケアもより必要になったり、パフォーマンス向上など非機能面の開発も必要になっていき、少しずつリリースサイクルが落ちていってしまいました。また、開発リソースは限られているので優先順位を付けざるを得ないが、一方でどれも重要な開発なので優先順位を付けるのが難しい、など開発案件のコントロールも難しくなっていました。
さらに、実は当時はCTOだけではなくサービスローンチ後からカスタマーサクセスの責任者も私が兼任しており（むしろそっちのほうが主だったかもしれません）、コードを書く時間どころかプロダクト開発に対して割ける時間がどんどんと減ってしまっていました。
そこで、開発組織を異なるミッションを持った２つの組織にわけて、代表の佐藤と私がそれぞれをマネジメントする体制に移行しました。私がtoB向けの価値提供のための開発と開発者生産性向上のためのトイル撲滅などの開発、佐藤がtoC向けの価値提供のための開発を担当するようにしました。２人で見るようになって、開発組織が拡大できたのもありますが、ミッションをわけてそれぞれに注力できるようになったことも開発スピードの回復には大きな影響があったと感じています。
スピードを追求する上で自分が常に意識していることの１つに、担当範囲を広くとりつつ独立性・自走性を維持するというのがあります。要は、企画からデリバリーまで一人でやれるのが最強だよねと思っていて、でもそんなスーパーマンはそうそういないので、それをいかに組織・チームで再現するかを考えています。
弊社の開発組織は「事業へ染み出す」カルチャーを大切にしていますが、それにはこのカスタマーサクセス（CS）での経験が背景にあります。CTOがCS責任者を兼任したことで、ユーザー理解や業務解像度がめちゃめちゃ上がるので課題の発見や優先順位の判断がしやすいことと、デリバリー含めて自分の責任範囲で実行できるのでスピードが非常に高かったというメリットがありました。ただ、1人が幅広い工程を全て見るデメリットも当然あって、特に当時は完全に自分がボトルネックになってしまい組織の自律性が向上しづらい状況があり、その改善が更なるスピード向上には必要不可欠でした。採用には時間がかかります。事業の成長スピードに対してCTOがボトルネックにならないためには先を見据えて先手先手を打って組織拡大や権限委譲の推進をしていくことの重要性を痛感しました。
フェーズ４：現在
現在の体制はこんな感じになっています。
まずは今の組織について説明します。
今の開発組織は大きく３つのグループに分かれています。
プラットフォーム開発グループは、Park Directのサービスを安全に、安定して使っていただく、そして今後の急成長をしっかりと支えるために活動するグループです。
「QAチーム」は品質とアジリティの両立、「SREチーム」は信頼性とアジリティの両立、「ARCH（アーキテクチャ）チーム」は開発者の体験や生産性の維持・向上と0→1の創造、「Analyticsチーム」は経営や事業判断を支えるためのデータ分析結果の創出をミッションにしています。
プロダクト開発グループは、ユーザーの課題解決や価値提供を通じて、事業数値をあげていくための機能開発をするグループです。Park DirectはBtoBtoCのサービスのため、toCの借主様、toBの不動産管理会社様向けに機能開発をしていく必要があります。また、これは変わった考え方かもしれませんが、自社のCSメンバーもPark Directの立派なユーザーだと私達は考えています。そこで、３方向のそれぞれのユーザーおよびKPIに向き合った開発体制にしています。
最後はマーケティンググループです。
なんでマーケティンググループが開発組織の中に？と皆さん思われたのではないでしょうか。もともとは別の組織として存在していたのですが、去年の9月からこの体制になりました。これは弊社の開発組織の特徴を大きく表しています。なぜこのような組織デザインにしたのかというと、シンプルにこうしたほうがいいモノを早く提供できると考えたからです。
この体制に変更した当時のマーケティング活動においてメインの活動領域はデジタルマーケティングでした。そして、デジタルマーケティングにおいては、例えば、SEOやCVR改善では開発が必須になりますし、広告運用で行うデータ分析は開発メンバーが得意な領域と言えます。そのため、マーケティングメンバーが開発メンバーと距離感近く一緒にやったほうが、いいモノを早く提供できると考えました。変わった組織デザインなので、色々と議論を呼びそうだと予想しつつ経営合宿で提案したのですが、意外にも賛同を得られてすんなりと決まったことは今も覚えています。トライした結果は劇的にCPAを改善できたり、マーケ施策のスピードが早くなったりと良い効果が生まれたのでやってよかったと思っています。
マーケティンググループが開発組織の中に入ったり、2グループが再構築されてチーム体制を作れたことも大きな変化点ですが、一番の変化点は各チームのリーダーに権限委譲ができたことです。前のフェーズで2グループ制にすることで確かにスピードは回復して速くなりました。しかし、私と佐藤がそれぞれトップダウンで対応する構造だったため、組織が拡大するにつれて、それぞれがボトルネックになりはじめてしまい、スピードが上がらなくなっていました。それがリーダー陣に権限委譲することで、ボトルネックが解消されるだけではなく、意思決定するメンバーが増えたことで対応する量も増え、スピードがさらに上がりました。開発組織は今後も拡大していくので、今度はリーダー陣がボトルネックにならないように各メンバーがより自走して対応できるように自己組織化を進めていきたいと思っています。
開発組織をデザインする上で大事にしていること
ご紹介した通り、事業成長とともに開発組織は大きく変わってきましたが、開発組織をデザインする上で大事にしていることが大きく２つあります。
１つは、フェーズ3でも述べた「開発組織が事業に染み出す」カルチャーが発揮できる組織構造になっているか、です。弊社ではエンジニアが事業創造や事業グロースに対して積極的に関与していくことを推奨していますし、そういうことをやりたいメンバーが多く集まっています。このカルチャーは何よりも大事にしていて、弊社の開発組織の特徴でもあり魅力だと思っています。なぜそこまで大事にしているかというと、エンジニアが事業側に染み出すことで、世の中に価値を提供するスピードが上がるからです。
いいモノを作るためにはエンジニアが一次情報に触れられるかは非常に大事で、積極的にクライアントとの商談やMTGに同席するようにしています。私自身も定期的に全国飛び回り、その度に学びを得ています。来年はより多くのエンジニアが一次情報に触れられるような仕組みを作っていきたいです。
対応スピードをあげるためにはフェーズ3のエピソードでも書きましたが、いかに担当範囲における独立性・自走性をあげるかが大事です。意思決定におけるコミュニケーションコストを下げることが重要だからです。そのために、弊社の開発組織では担当領域を限定するのではなく隣接領域に染み出すことを推奨して一人で判断できる範囲を広げています。結果、フルサイクルなエンジニアが多く集まり活躍してくれています。今後はさらに自走性を高めていくために、意思決定がしやすいデータ分析基盤の構築やプロダクトガイドラインの制定などの仕組みづくりや開発チームの自己組織化をしていきたいです。
もう１つは、「組織は戦略に従う」です。世の中の組織デザインの事例は非常に参考になりますが、他社で成功した組織が必ずしも自社で成功するとは限りません。特にスタートアップの場合、様々な要因で事業を取り巻く環境や戦略も急に大きく変わります。その時その時の事業戦略から開発戦略へと落とし込み、実行するために最適な組織を常に実現することが大事だと考えています。
最適な組織を常に実現するためにIssueドリブンであることを大事にしています。世の中のベストプラクティスを安易に導入するのではなく、なぜそれを導入するのか？導入した結果、課題は解決するのか？何が得られるのか？という問いかけを常に心がけています。
さらに、組織コンディションを定性だけではなく定量的にモニタリングすることも大事にしています。そのため、開発生産性のモニタリングには力をいれています。今はFour Keysを中心に見ていますが、開発組織のアウトプットだけではなくアウトカムまでを意識したモニタリングができるように今後もアップデートしていきます。
これからの開発組織について
これは、フェーズ毎の人数推移です。
現在、全体の開発人数は増えてきていて、フリーランス・パートナー企業の業務委託の方や副業の方に支えていただきつつ開発しています。去年と比較して社員数も約5倍になっていますが、まだまだ圧倒的に足りていません。さらに、既に2つ目の事業であるPark Direct for Businessも立ち上がり、今後もPark Directをベースに複数の事業を立ち上げていく予定なので、開発組織を拡大しつつマルチプロダクト開発体制へシフトしていく必要があります。
また、組織拡大だけではなく、権限委譲の加速も重要なテーマです。今年の上期にQAチームやARCHチーム、サクセスエンジニアリングチーム、Analyticsチームと複数のチームを立ち上げており権限委譲も進めていますが、まだまだ足りていません。組織拡大と共に権限委譲と自己組織化を進めて、開発組織全員で事業グロースを加速していけるような組織を作っていきたいと考えています。
さいごに
会社自体やPark Direct事業はまだまだこれからですが、開発の規模はそれなりに大きくなってきました。しかし、開発組織は事業規模に対して人数が少なく本当にまだまだこれからの組織です。また、エンジニアが活躍できる魅力的な課題が山程あります。例えばバックエンドのリアーキテクチャやモビリティプラットフォームを見据えたマイページの開発、マルチプロダクト開発体制への移行など、技術観点でもプロダクト観点でも組織観点でもチャレンジングなテーマが盛りだくさんです。
急成長中の開発組織でガッツリ開発したい方、開発組織のこれからを作っていきたい方、チャレンジングな課題に挑戦したい方など、とにかく少しでも弊社に興味をもっていただけたら、気軽にお声がけいただけると嬉しいです！
ニーリーでは、事業拡大に伴う組織強化のため、多様な職種で⼈材を募集しております。
詳しくは、採用特設サイトをご覧ください。
採用特設サイト：https://jobs.nealle.com/
また、少しでもご興味を持っていただいけたら、オープンポジションのカジュアル面談も実施中です！
https://herp.careers/v1/nealle/HT6slw2HulGr
■開発メンバーとのカジュアル面談はこちら
・三宅 克英（取締役CTO）
モビリティSaaSのプロダクトグロースについてお話しましょう
・菊地 弘晃
Mobility SaaSを一緒に開発しませんか？