この記事はクラウドワークス Advent Calendar 2021の８日目の記事です。

はじめに

初めまして、エンジニアの仁和です。普段はRailsを書いています。社会人1年目ながらこの1年で新規事業の立ち上げに携わらせて頂きました。その中で自分なりに得た気付きや学んだことを書いていきます！

新規事業に挑む上で心がけたい事

みなさんは新規事業に対してどのようなイメージをお持ちでしょうか？楽しそう？難しそう？全然検討もつかない？人それぞれだと思います。自分のイメージが持っているイメージは千変万化です。ビジネスモデルやユーザ層、チームメンバー、新規事業を取り巻くあらゆる事象が秒単位で変わっていくと言っても過言ではありません(いや、過言かもしれない)。そんなカオスの中で確実にリリースまで持っていくために何を意識したら良いのか自身の経験と照らし合わせながら分析しました！

QCDを決める

QCDとはQuality(質)・Cost(費)・Delivery(納期)の頭文字を取ったものです。作りたいサービスで一番求められることは何でしょうか？

圧倒的なUI/UX？
低コスト(人件費・インフラコスト)でリリースできること？
爆速でリリースまで持っていけること？

これは唯一解がある問いではなく、チームの構成や作りたいサービスの性質と相談しながら決めることです。どれを重視するかであらゆる意思決定が変わってきます。まず最初にメンバー全員で話し合って決めておくことをオススメします。

変数を減らす

事業の立ち上げフェーズの開発では決めることが多いです。そのため、自分の目の届く範囲内で開発に関する物事を決めておくと開発に集中できます。ではその開発に関する物事とはなんでしょうか？。自分なりに以下に列挙しましたのでそれぞれについて説明します。

技術選定

どの言語・フレームワーク・クラウドインフラで開発するかは大きな意思決定です。決める判断軸としては

社内に知見が溜まっているかどうか
- 言語のお作法
- バージョンのアップグレード作業の手順
使い慣れているか
- 自分が使い慣れているか
- 自分が使い慣れておらずとも他のメンバーが慣れていて、質問できる環境ならば一考の余地がある
新しい技術に対するモチベーション
- エンジニアは技術的好奇心が旺盛なので新しい技術を採用することによって開発のモチベーションが上がる
- 採用においてエンジニア組織のブランディングに繋がる
- 新しい技術は既存の何かしらの課題を解決するために生まれている
  - 正しく扱えば素早く作ることができる。

以上が挙げられるのかなと思います。ただ個人的な意見ですが、新規事業は明日も残っているかどうか分からないくらいの気持ちで臨むことが多いと思うので、初期の生産性に全振りした技術選定であればなんでも良いと思います。自分の手に馴染んだ技術スタックを採用すれば、まず大外れすることはないかと。もちろんチームメンバー全員のスキルセットを洗い出した上で妥当な落とし所を見つけるプロセスを踏んだ上での話ですが。例えば弊社のプロダクトのクラウドリンクスは

Kotlin + Spring Bootによるバックエンド開発
- モジュラモノリス + イベント駆動によるヘキサゴナルアーキテクチャの採用
- Firebaseで構築したPoC(Proof of Concept)から移行した
Nuxt.jsによるフロントエンド開発
Fargateによるコンテナ運用

で構築されており、全て弊社としては初採用でした。このように、チームメンバー・プロダクトの性質などを加味した上での技術選定であれば全てを新しい技術で構築しても問題ないという認識です。ちなみに自分の場合PoCを最速で作りたいという場合や対象のサービスの機能要件がそこまで複雑でない場合は

Railsで構築したAPIサーバをElastic Beanstalk(AWS)上にデプロイ
フロントエンドはNext.jsで構築してVercelにホスティング
- 余談ですが、自分はフロントは門外漢なのでcreate-react-appの代わりくらいの感覚でNext.jsを採用してます
- CSSはBEMわかんね〜って感じなのでTailwind CSSを使ってます
認証・認可は自力で作れないのでIDaaS(自分が好きなのはFirebase Auth)を使いたい
CI/CDはGitHub Actionsで完結させる
- Rails採用するとCI/CDの知見がネットに沢山あるので安心します

という構成をメインとしています。ビジネスサイドからヒアリングした上でここからカスタマイズしています(バックエンドをExpress + TypeScript, Spring Boot + Kotlin, Firebaseで検討するなど)。

アーキテクチャ

大規模Webアプリケーションにおける複雑性とアーキテクチャ設計に関する一考察

アーキテクチャに関しては弊社の過去のアドベントカレンダーで偉大な先人の方が素晴らしい記事を執筆してくださっています。ただ、新規事業は最初から大規模に展開するというよりかは小さく作って素早くリリースすることの方が多いと思います。牛刀で鶏を捌くではありませんが、初期からレイヤーを細かく切って設計すると新規事業の良さであるスピード感が失われかねないので、要はバランスですねという結論になってしまいます...。また、難易度の高いアーキテクチャを採用すると新規加入したメンバーのキャッチアップ・教育コストやドキュメントをどう運用するかなど諸々の課題が生じるのでその観点での吟味も必要かと思います。そこにあまりコストを払いたくない、ないし払える状況では無い場合はRailsのような重厚なフレームワークを採用するのも一つの手かもしれません。

技術的負債の積み方

今でこそ技術的負債とどう向き合うかのエントリが増えましたが、実際どう向き合うかは人それぞれです。自分が今でも参考にしているエントリはこちらの連載です。

CTOが考える、チームで向き合う技術的負債との付き合い方

負債はリボ払いみたいなもので、返すべきタイミングで返し切らないと雪だるま式に増え、返済計画がとんでもないことになります。もちろん、誰も意図的に負債を増やそうとして増やしているわけではありません。みんなわかりやすいソースコードの中で開発したいですし、良いコードを書こうと日々実装していらっしゃると思います。しかし

プロダクトそのものに対する理解やプロダクトのドメインに対する知識不足
使っているライブラリ・フレームワークの更新
サービスのピボットなどによる仕様の破壊的変更・追加

などによって意図せず技術的負債を生んでしまいますし、生まれてしまいます。これはもう避けられないと思っています。これに対する銀の弾丸は存在せず、上記の記事の通り、スプリントの中の何割かをリファクタリングやドキュメント整備に充てるという地道な作業によってのみ防げるのかなと思います。言うは易し行うは難しであることは重々承知していますが、一緒に頑張りましょう！

改善すべきだったこと

万事が上手く進んだわけではありません。この記事を書くにあたって再度振り返ってみて以下の部分が改善点として挙げられました。

開発対象のサービスの機能要件・非機能要件の複雑さによる実装・調査・検証コストの増大
- 複雑なデータ形式を扱う必要があったためデータの取得の部分でスロークエリが頻発することが事前に判明していた
- ブラウザ側で表示するデータも大量だったのでフロントエンドの基礎知識が必要だったが自分にはなかった
技術選定(DDD, イベント駆動, Vue.js, Express)に伴うコストの増加
- それぞれの技術をほぼ独学で1から学ぶ必要があったため学習コストが増加
- フレームワーク、ライブラリに対する知見が乏しいことによる実装コストが増加
新規メンバーのオンボーディングに伴う教育コストの増加
- 自分がオンボーディングを受けたことがないのでどうオンボーディングしたら良いのか分からなかった