Coral Capital出資先約80社からなるスタートアップコミュニティー「Coral Family」のうち、CTO・エンジニアが定期的に集まるCoral Developers。その中から生まれたイベント「スタートアップ開発しくじり先生LT」が5月に開催され、多くの参加者を集めました。
スタートアップの開発の失敗を赤裸々に語るライトニングトークには8社のCTOやエンジニア、プロダクトマネージャーが登壇。本記事では、ファンファーレ株式会社でソフトウェア・エンジニアを務める中山太雅氏による「フロントエンドをゼロから作り上げ、しくじってきた青春の思い出」と題したトークの内容をお伝えします。
ファンファーレは、産廃業界の省力化に取り組んでいます。最適な配車計画を短時間で自動生成するサービスを作っています。私はそこでフロントエンドを担当しています。
何をしくじったのか。アーキテクチャの設計をしくじり、データの更新がしづらくなりました。スライドには「問い合わせが増えてきた時期に開発2か月止めちゃったゴメンネ」と書いたのですが、思い返すと胸が痛みます。
フロントエンドの目線からアーキテクチャを設計した
問題の発端は、アーキテクチャを設計する必要があったことです。過去事例をリサーチして、「DDD（ドメイン駆動設計）をフロントエンドに組み入れるアプローチが、それなりにうまくいっている」と考えました。
エンティティ（一意性を持ち、状態の連続的な変化をトラックすべき対象）は、バックエンドが持っていますが、それをフロントエンドに返したとしてもトラックすべき対象であることは変わらないと考えました。そう捉えるとフロントエンドにおいてもエンティティはエンティティです。それに加えて、チームの構成上、フロントエンドの方が人的リソースが多い状態にありました。
そこで「多少フロントエンド側にロジックを持ってもいいんじゃないか？」と考え、エンティティを書き換えてサーバーに送り返すことを考えました。リポジトリ内にあるエンティティを書き換え、サーバーサイドに同期する作りにしました。この辺で「おや？」という顔をしている参加者の方もいますね。
結果、こういうアーキテクチャには問題があることが分かりました。サーバー側でしか分からない制約を扱いにくく、制約に引っかかった場合に状態を書き戻せなくなりました。例えば、数千のエンティティがあって「名前の重複を許さない」という制約がある場合、これをフロントエンド側でどう処理するのか。答えづらいものがあります。
失敗を認めて再設計
ほかのメンバーに負債を負債として認識してもらうことから始めました。リファクタリングのための時間を取り、アーキテクチャを再設計しています。外部のアドバイザーを含めて議論、レビューを繰り返し、今まさにリファクタリング中です。
教訓：技術的負債は負債として認め、自ら返済する
教訓ですが、フロントエンド側で状態を過剰にコントロールするのはやめましょう。
今回のしくじりのプラス面ですが、チャレンジ精神を持って挑戦し、負債を負債として認め、そこから理想像を組み立てて負債を返済する文化を創った側面があると考えています。「やー、自分が間違っていたな」と認めて、自分で負債を返済する文化です。
（執筆：星 暁雄）
【スタートアップ開発しくじり先生のトークまとめ、全記事一覧】
- 本番環境にホットフィックスをリリースして破壊した話（justInCase Technologies）
- 売れる！と確信して出した機能の利用社数が1社で膝から崩れ落ちた話（カミナシ）
- フロントエンドをゼロから作り上げ、しくじってきた青春の思い出（ファンファーレ）※本記事
- 組織で向き合う、しくじりと開発体制の歴史（hokan）
- WordPressが技術負債になった話（クレジットエンジン）
- ステージング環境でばっちり検証したけど、本番で沼った話（クレジットエンジン）
- 通知機能をマイクロサービス化していたらユーザ一斉通知でしくじった話（Seibii）
- 守りからはじめるカスタマーサクセス（空）
Editorial Team / 編集部
