生成AI時代の到来に合わせ、社内向け管理サイトの開発をローコードツールからコードベースへと切り替えました
こんにちは、HQ でソフトウェアエンジニアをしている @rintaromasuda です。今回は HQ における社内向けサービス「スタッフ画面」の開発方針を切り替えた話について書きたいと思います。 よろしくお願い致します。
HQ「スタッフ画面」とは
言わずもがなではありますが、SaaS をお客様に提供する際、そのサービスを管理するため、サービス提供側の為のサイトも開発・運用するのが一般的だと思います。HQ でもエンジニア、プロダクトマネージャー、 クライアントサクセスをはじめとしてHQ の様々なスタッフが利用する管理用のサイトがあり、その役割から「スタッフ画面」と呼ばれて親しまれています。
スタッフ画面開発方針の転換
HQ にスタッフ画面が誕生した際は、お客様に提供しているサービスと同様 Next.js 上でコードベースによる実装を行っていました。これをある時点でローコードツールによる実装に切り替えたのですが、数ヶ月 前より生成 AI 時代の本格到来に合わせ、これを再びコードベースによる実装に切り替えることにしました。この決断の背景には生成 AI 時代の本格到来も含め以下のような理由がありました。
- HQ の会社としてのステージが変わり、スタッフ画面に求められる複雑性が増した
- フロントエンドの統合の恩恵により、フロントエンド開発・運営コストが大きく下がった
- 生成 AI 時代が本格到来し、その恩恵をフルに受けられる開発環境が必要になった
以下でそれぞれを詳細に説明したいと思います。
HQ の会社としてのステージが変わり、スタッフ画面に求められる複雑性が増した
まずは誤解のないように述べておきたいのですが、導入当時の HQ の状況を鑑みるとローコードツールの導入は成功でした。ローコードツールの導入によりスピード感を持って必要な機能を実装や変更を行うこと ができ、変化の大きい黎明期のサービスの根幹を支えました。また、運用上の都合でイレギュラーなデータソースを扱いたい場合などにも各種コネクターのおかげで柔軟に対応できたり、スキルの高いプロダクトマネージャー により機能追加がなされたりなど、ローコードツールの導入により大きな恩恵を受けてきました。
一方で会社のステージが進むにつれ、当初は「リモートHQ」ひとつだけだったサービスも複数個に増え、スタッフ画面に求められる機能の複雑性も増していきました。結果として、ローコードツールを使っている にも関わらず内部では相当量のコードが記述されるなどのケースも散見されるようになってきました。ローコードツールはその名の通りコードが少なく済むときには非常に便利で心強い存在ですが、いざコードをたくさん 書く段に入ると、むしろ非効率になる場合も多く、これがコードベースの開発に戻る理由のひとつとなりました。
フロントエンドの統合の恩恵により、フロントエンド開発・運営コストが大きく下がった
このブログでも何度か説明させて頂いている通り、HQ ではサービスのフロントエンドの統合を行っています(参考: 複数ホストで動作する Web サーバーをプルリクエスト単位でプレビューする)。この統合により、スタッフ画面を 含めた各サービスの開発、運用にかかるオーバヘッドがなくなり、かつサービス間でのコンポーネントの共有化も進み、更には全てが同じコードベースであることによるエンジニアのスキル向上の効率化が進みました。 簡潔に言えばフロントエンド開発にまつわるコストがとても低下したという背景も理由のひとつになっています。
またこれは少し余談になるかもしれませんが、単純に HQ 開発チームのエンジニアリングリソースも積極的な採用により増したことも大きな理由のひとつです1。フロントエンドも含めてエンジニアリングに従事できる人財が 増えたことも決断の背景にはあります。
生成 AI 時代が本格到来し、その恩恵をフルに受けられる開発環境が必要になった
最後に本題の生成 AI についてです。と言っても近年の生成 AI の進化の勢いについて今更私が述べることはありませんが、最早生成 AI の恩恵なしにソフトウェアの開発することは想像できない という意見に反対の方はいないのではないかと思います。そしてその恩恵を最大限に受けようとすると、やはり然るべき環境でコードを書いてソフトウェアを開発することが前提となるのではないでしょうか。 逆に言うと、ローコードツールによる開発ではなかなか生成 AI の恩恵は受けづらいという側面がありました。
このブログで CTO の髙橋が紹介している例2にもありますように、HQ では開発に生成 AI をフル活用しています。そしてスタッフ画面の開発にも AI をフル活用しはじめたことにより、ローコードツール導入当初 に目的としていたことのひとつであった非ソフトウェアエンジニア以外による機能の開発や修正といった事例もどんどん生まれています。更に言うなら、生成 AI による開発の恩恵を最も受けやすい もののひとつがスタッフ画面のような社内向け管理サイトの開発ではないかと思っています。
管理サイトには上述のような複雑な案件もある一方、定型的なデータの CRUD 操作のようなものも多くあります。HQ ではこのような CRUD 操作は生成 AI 向けに型化されており、新しいデータに対するCRUD 操作 の雛形はほぼ自動で作成されています。またスタッフ画面は当社内スタッフ用のサービスなので、新しい開発手法を先んじて大胆に導入しやすいといった背景もあります。生成 AI による開発を大胆に適用した結果、 少し前までなら信じられないようなスピードでスタッフ画面の開発を進めていくことが可能になりました。
生成 AI による開発手法の導入、これが間違いなくスタッフ画面実装方針の変更を行った最大の理由です。
まとめ
HQ におけるサービス管理用サイトである「スタッフ画面」の開発方針をなぜコードベースによる開発に戻したのか、その背景についてお話しさせて頂きました。HQ では更なる生成 AI 活用を進めており、それを一緒に 推し進めてくれる仲間をまだまだ募集中です。もしご興味がありましたら、ぜひ以下より採用情報をご覧になってください。
Footnotes
-
HQ の採用活動については VP of HR 古田の note 記事 をぜひご覧になってください。 ↩
-
活用の一例となりますが、よろしければ devcontainer 内の Coding Agent で Playwright MCP を使う をご覧ください。 ↩