0→1 フェーズの技術選定の所感

taxio
·

ここ1年はシード期のスタートアップを手伝う機会が多かったので、特に Web Backend 周りの最初の技術選定をよく任されていた。

一度自分の考えをダンプしておく。

  • 言語

    • フルコミの人が開発の中心にいるのであれば何でも良い

      • 初期においてはメインの1人が爆速で開発できることが重要なので

    • ただし、あえて選択するなら以下の観点を設ける

      • 環境構築が簡単か

      • コンテナ技術と相性がいいか

      • ライブラリの開発が活発か

        • OSS や SaaS の公式 SDK が提供されやすいか

    • すると大抵は Go or Python になる

      • Next.js の API Routes で開発するという選択肢もある

    • 個人的には Go で開発することが多い

      • 型がある

      • 周辺ツールが整っている

      • CrossBuild 可能だし、1バイナリにできる

  • スキーマ駆動開発

    • サービスのドメインモデリングをして、合意を取ってから開発に入るというフローを徹底している

    • API の形態はチームのスキルセットによって変わる

      • OpenAPI

      • ProtocolBuffer

        • grpc-gateway 的なのを挟んで json でやりとりできるようにする

          • 最近だと connect を使う

      • GraphQL

    • Backend API 開発者的には GraphQL が楽。OpenAPI と Proto はどっちでもいいって感じ。

  • Database

    • どこかしらの RDB を使う

      • 個人的には PostgreSQL が好き

      • 費用感を見て、PlanetScale を使うのもアリ

    • NoSQL 系を使ってもいいが、サービスの初期開発においてはドメインモデルが変わることが多いので RDB レベルの自由度が欲しい

      • 特定のソリューションに特化したい場合はその限りではない

    • ORM, Query Builder はなるべく SQL に近いものを使う

      • おすすめは sqlc

      • Backend エンジニアならどうせ SQL 書けるし

    • スキーマ定義は冪等実行可能で、SQL に近いものを使う

      • おすすめは sqldef

      • Backend エンジニアなr...

  • Deploy 場所

    • 特別な事情がない限りオンプレではなく Cloud を使う

    • Cloud ベンダは特にこだわりはない。スタートアップ支援とかも含めて、一番安く済むところを選ぶ。

  • 認証

    • 今のところ Firebase Authentication

    • セキュリティ要件を後から追加していくことを考えたら Auth0 使いたいけど高いのよ...

  • 開発組織

    • ドメインの複雑性によるが、フルタイムで2,3人が理想

      • 初期の時点で副業を入れても、スピード感が合わない

    • 最初からいる必要はないが、開発後半までにはマネジメント専任のメンバーが確保できているとベスト

      • 大体終盤は開発メンバーがパツってきて、タスク管理が壊滅する

      • リリース後の開発サイクルを回すときには開発メンバーは疲弊しているので誰かがマネジメントを巻き取らないと開発速度が急に落ちる

      • 開発要件とスケジュールと品質のコントロールを俯瞰的に出来る人が絶対必要

      • ↑これらをするメンバーがいないと、開発メンバーの誰かがマネジメントも兼業してシンプルに2倍働くことになる