最初のお問い合わせは2023年の9月です。その後、2024年の1月から「無料相談」として4回のミーティングを行いました。この段階で、すでにお客さまの中で作りたい機能の構想は整理されていた状態です。

僕らで作るとしたら技術スタックをRuby on Railsにするか、Firebaseなどを使ってサーバーレスで構築するかだったんですけど、今回はターゲットが製造業や金融、官公庁など、数万人規模の大手企業になることが想定されていたので、セキュリティ面での要求水準の高さや、業務フローの複雑性などを考慮して、堅牢かつ柔軟にビジネスロジックを構築できるRailsを採用することに決めました。

無料相談の4回のミーティングの中で「じゃあ何から作りますか？」という要件を詰め、データベースの基本的な設計まで行いました。その後2024年の2月に、実際に開発がスタートするタイミングで長野がジョインしたという流れです。

実装面で一番頭を悩ませたのは、「トピック管理」の共通化と「テナント管理の簡素化」ですね。

トピック管理というのは、似て非なる入力画面やメニューが40種類ぐらい存在する機能のことです。これを忠実に40個のデータベーステーブルを作り、MVC（モデル・ビュー・コントローラー）のセットを40個用意して……と力技でやっていけば、動くものはすぐにできます。でもそれでは後から「全体に共通する項目を1つ足したい」というような場合に修正箇所が膨大な量になり、保守が破綻してしまうんです。

そこで、いかにシステムを抽象化し、「同じソースコードは1回しか書かない（DRY原則）」状態を保つかというアーキテクチャの設計には非常に苦労しましたね。具体的には、画面ごとの差分をハードコードするのではなく「メタデータ」として設定値に切り出し、コアとなるエンジン部分は共通のロジックで動くような設計基盤を作り上げました。

もう一つのテナント管理の簡素化については、実装そのものよりも「どういう要件で作るか」をお客さまと一緒に固めていくプロセスが難しかったです。

当初はインフラ環境を個別に用意して、データを完全に分けた別々の「RACUUUN」環境をお客さまごとに立てる構成で始まっていました。しかしこれだと今後お客さまが増えていった時の運用負荷を考えると、それぞれを保守していくのが現実的ではなくなってしまいます。

そこで運用を楽にするために、テナント管理を簡素化する方針に途中から切り替えました。大企業の大切な運用データを預かるシステムにおいて、企業間の「データ漏洩（他社のデータが見えてしまうバグ）」は致命傷ですが、アプリケーションのフレームワークレベルでスコープ（参照範囲）を厳格に切り分けて、絶対に他とデータが混ざらないような堅牢なデータ分離の仕組みを設計しました。インフラをまとめることでアプリ側の難易度は跳ね上がりましたが、将来の事業スケールを考えたら、我々プログラマが複雑性を引き受ける方がいいと思って、決断しました。

あのエピソードだけ聞くと、魔法を使ったり、めちゃくちゃな力技でハックしたように聞こえるかもしれませんが、そうではありません（笑）
あれができたのは、それまでに長野と一緒に作ってきた「UIコンポーネント」や「内部のAPI設計」が綺麗に整理・独立させられていたからです。

ブロックが揃っていたからこそ、それらを組み替えて「サイドバーに全てを集約する」という新しい画面を即座に組み上げることができました。ホワイトボードで抽象的な議論を続けるより、実際に動くソフトウェアをお客さまの目の前でお見せした方が、要件定義は圧倒的に速く進むんです。

ソニックガーデンの開発では、常にデプロイ（リリース）可能な状態を保つためのCI/CDパイプラインや、自動テストの環境が初日から整備されています。だからこそ、その場で出たアイデアを即座に形にし、「もし既存の機能を壊してしまったらどうしよう」という恐怖を抱くことなく、攻めの姿勢でプロトタイピングができるんです。圧倒的なスピードの裏には、それを支える強固な技術的基盤があります。

『納品のない受託開発』は「作って納品して終わり」ではありません。ずっと続くサービスだからこそ、今日書いたコードのメンテナンスをするのは、1年後、2年後の自分たち自身です。なので、開発中は常に「2年後の自分に恨まれないコードを書くこと」を絶対条件にしています。

スピードを優先して汚いコード（技術的負債）を放置すれば、いつか必ず自分たちの首を絞めることになります。なので、もし実装を進める中で「ここの設計はまずい」と気づいた箇所があれば、お客さまに「将来の保守性を担保するために、リファクタリング（内部構造の整理）の時間をください」と交渉します。

ありがたいことにK-modelさまは「技術的負債を抱えるくらいならリリースを延ばす」と言ってくださる、エンジニアにとって非常に理想的なお客さまです。

長く使われるシステムを健全に育てるには、テストコードの充実と日々のリファクタリングが欠かせません。「ただ動けばいい」という一時的なコードではなく、ビジネスの要件変更に柔軟に対応できるアーキテクチャを維持し続けること。それが我々ソフトウェア開発者としてのプロの責任であり、お客さまの事業に対する真の価値提供だと考えています。

開発者目線で言うと、長く同じプロダクトに関わることで、システム全体の知識と、K-modelさまのビジネスが深く結びつくようになりました。新しい要望が来た時も「あの業務フローなら、この設計パターンを応用すれば作れるな」とすぐに引き出しを開けられるようになり、よりスピーディに価値を出せるようになっています。お客さまの事業成長と、自分自身のシステム理解がシンクロしていく感覚は非常に面白いです。

僕は前職で大企業にいた経験があるので、巨大なシステムにおける「運用管理」がいかに煩雑で、ルールにがんじがらめになっているか、実体験として想像がつくんです。だからこそ、K-modelさまが掲げる「不毛な運用管理をなくしたい」というビジョンには深く共感しています。

大企業で働く大勢の人たちが、無駄な作業から解放されて本質的な仕事に向き合えるような画期的なシステムを、我々が裏側で作っている。ただ言われたものを作るのではなく、システム開発を通じて社会を良くするための一端を担えていることに、大きなやりがいを感じています。そうした「技術を使った課題解決」に面白みを感じられるプログラマにとっては、最高のプロジェクトだと思いますね。