フロントエンドをゼロから作り上げ、しくじってきた青春の思い出(ファンファーレ):スタートアップ開発しくじり先生(3)

Coral Capital出資先約80社からなるスタートアップコミュニティー「Coral Family」のうち、CTO・エンジニアが定期的に集まるCoral Developers。その中から生まれたイベント「スタートアップ開発しくじり先生LT」が5月に開催され、多くの参加者を集めました。

スタートアップの開発の失敗を赤裸々に語るライトニングトークには8社のCTOやエンジニア、プロダクトマネージャーが登壇。本記事では、ファンファーレ株式会社でソフトウェア・エンジニアを務める中山太雅氏による「フロントエンドをゼロから作り上げ、しくじってきた青春の思い出」と題したトークの内容をお伝えします。

ファンファーレは、産廃業界の省力化に取り組んでいます。最適な配車計画を短時間で自動生成するサービスを作っています。私はそこでフロントエンドを担当しています。

何をしくじったのか。アーキテクチャの設計をしくじり、データの更新がしづらくなりました。スライドには「問い合わせが増えてきた時期に開発2か月止めちゃったゴメンネ」と書いたのですが、思い返すと胸が痛みます。

フロントエンドの目線からアーキテクチャを設計した

問題の発端は、アーキテクチャを設計する必要があったことです。過去事例をリサーチして、「DDD(ドメイン駆動設計)をフロントエンドに組み入れるアプローチが、それなりにうまくいっている」と考えました。

エンティティ(一意性を持ち、状態の連続的な変化をトラックすべき対象)は、バックエンドが持っていますが、それをフロントエンドに返したとしてもトラックすべき対象であることは変わらないと考えました。そう捉えるとフロントエンドにおいてもエンティティはエンティティです。それに加えて、チームの構成上、フロントエンドの方が人的リソースが多い状態にありました。

そこで「多少フロントエンド側にロジックを持ってもいいんじゃないか?」と考え、エンティティを書き換えてサーバーに送り返すことを考えました。リポジトリ内にあるエンティティを書き換え、サーバーサイドに同期する作りにしました。この辺で「おや?」という顔をしている参加者の方もいますね。

結果、こういうアーキテクチャには問題があることが分かりました。サーバー側でしか分からない制約を扱いにくく、制約に引っかかった場合に状態を書き戻せなくなりました。例えば、数千のエンティティがあって「名前の重複を許さない」という制約がある場合、これをフロントエンド側でどう処理するのか。答えづらいものがあります。

失敗を認めて再設計

ほかのメンバーに負債を負債として認識してもらうことから始めました。リファクタリングのための時間を取り、アーキテクチャを再設計しています。外部のアドバイザーを含めて議論、レビューを繰り返し、今まさにリファクタリング中です。

教訓:技術的負債は負債として認め、自ら返済する

教訓ですが、フロントエンド側で状態を過剰にコントロールするのはやめましょう。

今回のしくじりのプラス面ですが、チャレンジ精神を持って挑戦し、負債を負債として認め、そこから理想像を組み立てて負債を返済する文化を創った側面があると考えています。「やー、自分が間違っていたな」と認めて、自分で負債を返済する文化です。

(執筆:星 暁雄)

New call-to-action


Coral Capital

Editorial Team / 編集部

Coral Insightsに登録しませんか?

Coral Insightsのメーリングリストにご登録いただくと、Coral Capitalメンバーによる国内外のスタートアップ業界の最新動向に関するブログや、特別イベントの情報等について、定期的にお送りさせていただきます。ぜひ、ご登録ください!
Load More