はじめに
こんにちは！mentoでエンジニアをしているよしけんです
この記事では、シリーズBの資金調達を得たスタートアップが、どのように迅速かつ納得感のある技術選定を行ったのかについて、実体験に基づくプロセスを紹介します！
対象読者は、スタートアップで新規事業や技術選定に関わるエンジニアの方々です。もちろんそれ以外の方も「こんな進め方があるんだ」と気軽に読んでいただけたら嬉しいです。
「コーチング・プラットフォーム」から「プロダクトカンパニー」へ
初めてmentoを知る方向けに、簡単にご紹介します。
mentoは、企業のマネージャーに対して1on1のコーチングを通じて成長を支援するコーチングプラットフォームです。エンタープライズ企業を中心に、多くの管理職の「行動変容」を後押ししています。
そんな私たちが、次の成長フェーズとして掲げたのは 「プロダクトカンパニーへの転換」 です。
これは、コーチングという強みを活かしつつ、より多くのユーザーに価値を届けるために、プロダクト×コーチ×AIで課題解決を図っていくという意思でもあります。
スタートアップにおいて最も重要なのは、サービスを市場に早く出し、素早くフィードバックを得ることです。「迷っている時間」は最大のコストです。
しかし今回は
- 既存のコーチングという ビジネス資産や、アプリケーションコードやデータなどの資産があり
- ステークホルダーやチームも拡大し
- リリースは急ぎたい
という制約があり、白紙から自由に決めるわけにはいきませんでした。では、どうやって リリースの速さとチームの納得を両立させたのかを、私たちが実施して得られた知見を共有できればと思います。
今回の技術選定に関わったのは
- CTO
- 正社員エンジニア2名（うち1名はリード）
- 業務委託3名：（うち1名は入社予定）
の計6名のチームです。
このほかプロダクトチームとしてPdMやデザイナーといったメンバーもいますが、今回の意思決定には関与していません。
「全部テーブルに広げる」 ことから始める
新サービスの技術選定を進める上で、まず大事なのは「何を決める必要があるか」を明確にすることです。そのためにまず 「何が決まっていて、何を決めなければいけないのか」 をテーブルに並べることから始めました。
以下のような形で「観点→アクション→意思決定」という型で整理すると、合意形成もしやすくなります。
| 項目 | 観点（例） | アクション（例） | 意思決定（例） |
|---|---|---|---|
| セキュリティ観点 | - DBの論理分離は必要か - メールアドレス以外のログイン方法は検討すべきか |
- データ分離をどのように実現できるか、実施コストの把握 - 既存のIDaaSで新たに求められるログイン機構を実現できるか、他サービスを利用する必要があるかの調査 |
- 今回はデータ分離を行わないが、分離方法を調査しDocsにまとめる - 既存サービスではカバーしきれない要件があり、Auth0の導入を検討 |
| リリース期限 | - 1stスコープの定義の目安 - ビジネス観点でβ版リリースの希望時期 |
- サービスの1stスコープがFIXするまでに、何を実装しておく必要があるかの検討（短期視点） - リリース期限をX月としたときに、基盤をどこまで作り込むかのすり合わせ（中期視点） |
- サービスの1stスコープ定義前に基盤づくりにフォーカス - 1stスコープの機能要件はあらかじめ検証しておく |
| 人員計画 | - リリースまでの期間中の採用方針・採用計画 - 業務委託での採用も可能か、その際はどのくらいの金額を使えるか |
- スケジュールのアップデート - 採用まではどのような動き方をすべきか検討 |
- 採用人数を増やすために採用に一定リソースを振り分ける - ドキュメントの整備を行いオンボーディングコストを抑える - フロントエンド、バックエンドでチームを分けられるようにスキーマ駆動開発を導入検討 |
| 既存アセットの活用 | - コーチングというアセットは新サービスにどの程度関連するか（データ連携だけなのか、体験にも関わってくるのか） | - 既存プロダクトとの統合パターン（データ連携のみ／体験の一部統合／全面的なUX統合）を洗い出し、それぞれの技術的・組織的コストを試算 | - モジュラモノリス or マイクロサービス的に依存を切り分けたアーキテクチャを採用する - 既存サービスのアセットをフルに使えることを重視して意思決定する |
特にmentoでは、既存のコーチング機能を新サービスにどう組み込むかが大きな論点でした。それによって、既存のプロダクトをそのまま使うのか、あるいは移行して使うのか、はたまた作り直すのかなどのアクションが変わってきてしまいます。
また、誰が何を決めるのかを事前に決めておいたことで、迷ったときにも時間をかけずに進められました。基本はCTOが意思決定しますが、明確に知見があるテーマはその人に委ねる方針にしました。例外として、セキュリティなど一発アウトの領域はCTOまたは責任者が判断するようにしています。
“One‑Way Door” と “Two‑Way Door”な意思決定
意思決定には2種類あります：
- One-Way Door（OWD）：やり直しが難しい決定
- Two-Way Door（TWD）：後戻り可能な決定
技術選定フェーズにおいて、様々な意思決定を求められます。それらをすべて同じグラデーションで意思決定するには、時間があまりにも足りません。
私たちは、TWDな決定は即断し、OWDな決定には時間をかける。もしくはTWDにできないかを考える、という進め方を取りました。
Next.js を「採用しない」と決めたわけ
例えば、私たちの意思決定の中にNext.jsを採用しないという意思決定を行いました。
理由は、私たちが提供する業務SaaSにおいてSSRやISRが不要だったため。ページ速度やSEOが差別化にならず、Next.jsに伴うバージョンアップ対応やエコシステムの揺れ戻し（Page RouterからのApp Router推奨が変わったときのような）も懸念でした。
また、コミュニティの反応としてもピーク時と比べてポジティブな反応が低くなっていることも気になりました。
最終的にReact + Viteを採用し、必要に応じてNext.jsも組み込めるよう、pnpmによるモジュラモノリス構成とし、依存を局所化しました。これにより、TWDに近い構成を実現しました。
OWDには慎重に、TWDは走りながら。これが、全ての判断に時間をかけすぎないためのコツでした。
「誰と何を決めるのか」の設計
チームで合意形成するトピックを意識的に少なくすることで、スピード感を持った意思決定を行うことも大切です。
つまり、意思決定を早めるためには、時として意思決定する人数を狭めるのも一つの方法です。
mentoはコーチングを提供する会社だけあって、日々のプロジェクト進行においても対話を通して物事を進めることが多いです。
個人の意見が尊重されるため議論になりやすく、発言者も心理的安全性が高い状態で発言できるため、個人的には良い文化だと思っています。
一方で、チームの規模が大きくなればその分だけ意思決定速度が遅くなってしまうというデメリットもあります。
当初は全てに関してチームメンバーに意見を求めるような座組でキックオフを企画していましたが、チーム人数が倍に増えたこともあり、チームで全てのトピックを議論するのではなく、あえて範囲を絞って議論することにしました。
対象は、技術スタックの根幹である言語とフレームワーク選定（既存はPython/Flask）にしぼり、ここだけはチーム全員で議論し、それ以外（IDaaSの選定やReactのフレームワークなど）は共有のみにとどめました。
すべてをトップダウンで決めることも可能でしたが、あえて意思決定に参加してもらうことで、当事者意識を醸成したかったという意図もあります。
結果的に：
- 論点が明確化され、議論が深まりやすい
- ビジネス的としてなぜやるかの抽象度の高い背景共有に時間を使え、納得感が高まる
という凝縮された会にすることができました。
また、オフライン開催だったため、空気感や微妙な反応も見ながら進められたのも良かったです。
専門家の力を借りて、自分たちで判断する
社内で不足している知見は、外部の専門家の力をお借りしています。
例えば、フロントエンドの技術選定は、技術顧問の古川さんに、認証基盤やGraphQLの導入などは外部顧問に参画してもらい、「穴」だけ指摘してもらう 形式で進行しています。
その際、背景共有を丁寧に行うことでmentoメンバーと同じ視座でディスカッションできるようにしています。また、このタイミングで過去の判断はADR（Architectural Decision Records）として残すようにしているので、あとから参画したメンバーにも意思決定の文脈を伝えやすくなりました。
一方で、実装や最終判断はあくまでも自分たちで行い、主体性と学習効率を両立を意識しました。
シード期とは違い、資金がある今だからこそ、判断に必要なプロセスをショートカットできるようになったのは大きな変化です。
おわりに
ここまでお読みいただきありがとうございます。
スタートアップにおいて、技術選定はスピードと納得感の両立が求められる難所です。シリーズBを迎えた私たちが意識したのは、 「どの意思決定に時間をかけ、どれは素早く進めるか」 のメリハリでした。
改めてまとめると
- まずテーブルに載せて、 「何を決めなければいけないかを決める。」 その際に、既存のアセット（プロダクト、ビジネス、コード）をどう活かすかを早めに整理する
- One-Way Doorな意思決定は慎重に、Two-Way Doorな意思決定は大胆に行いメリハリをつける
- ステークホルダーが増えても、意思決定のスピードを下げないために 「チームで決めるべきことと、誰かが意思を持って決めるべきことのメリハリを付ける」
- 「チームにない知見は外部の専門家にサポートしてもらう」 ことで、学習時間をショートカットする
このような方針で判断軸を整えることで、チーム全体のスピードを保ちつつ、納得感ある意思決定が可能になりました。
私たち自身、まだ模索の途中ではありますが、皆さんのチームのヒントになれば幸いです。
We’re Hiring！
mentoは全職種で絶賛採用強化中です！
もし記事を読んで少しでも気になったらお気軽にご連絡ください〜
また、各種イベントを開催予定ですのでそちらもぜひ〜！
▼ 採用イベントを開催予定です。ぜひこの機会にお話させてください！
▼ 広木さんとこれからの時代のマネジメントについてのイベントも開催します！！
▼ カジュアル面談もお気軽に！(各種SNSでもDMいただければすぐ反応します！)
Discussion