「フロントエンド刷新の価値」を検証しながら進んでいく、ツクリンクのリアーキテクチャ
建設業界向けマッチングサービス「ツクリンク」のフロントエンド・リアーキテクチャには、Gaji-Labo もプロジェクトの一員として参画しています。
このプロジェクトを担当しているツクリンク社の湯本さんと西村さんは、Rails アプリのフロントエンドをただ React へ置き換えるのではなく、品質や保守性を見極めながら、どのようにプロジェクトを進めるべきかを判断しながら丁寧に進めています。
このツクリンク社の丁寧なリアーキテクチャの考え方は、技術刷新を検討しているプロダクトチームにとって、示唆のある進め方といえるのではないでしょうか。
———フロントエンドを React にしようと考えた経緯を教えてください。
湯本さん:これまでの「ツクリンク」は Rails によるモノリシックな構成でした。
スタートアップなので、自分たちが「開発者体験が悪い」と感じるだけなら、事業成長を優先していいと思っているんですが、複雑な機能があるページでは、ユーザーや事業に影響するような品質低下が心配になってきたんですね。
そこで、このプロジェクトが立ち上がったという流れです。
ツクリンク株式会社プロダクト部エンジニアの西村さん(左手前)とエンジニアリングマネージャーの湯本さん(左奥)。Gaji-Labo のフロントエンドエンジニア下條(右奥)と吉澤(右手前)。
西村さん:ユーザーさんが見る画面を中心に、よりよく改善していこうというプロジェクトですね。
一言で言えば、フロントエンドのリアーキです。
Gaji-Labo 下條:当初はツクリンクさん社内で React 化を進めていて、Gaji-Labo が後から入った形です。一年くらい前からこのチームに入らせてもらっています。
最初の三ヶ月では、開発の進め方の整理をしたり、テスト環境の整備を行っていたのですが、それと並行して、今回のリアーキテクチャによって解決が期待できる成果や、評価するための指標の言語化も進めていました。
——— ツクリンクさんが社内で進めていたプロジェクトに後から Gaji-Labo が参画した形ですね。
湯本さん:社内だけで一年くらい進めていたんですが、フロントエンドの専門知識を持った人員が不足していることもあって Gaji-Labo に相談したんですよね。
Gaji-Labo 下條:先ほどお話したんですが、参画して最初のうちはリアーキテクチャでどのような恩恵が得られるかを可視化したレポートを作成・提案することから始めました。
西村さん:社内に「こんな効果があるから費用を出して本格的に進めましょう」という説得材料としてのレポートが出てくるのかなと思っていたんですけど、プロジェクト進行の判断軸となる整理をしてもらえたのは、とても良かったです。
例えば、テストのしやすさの向上が必要という話が初期段階で整理できたのが良かった。
Gaji-Labo 下條: そうですね。
テストのしやすさなどの保守性や、新しいメンバーが入ったときに開発しやすくするといった主軸となる考え方が整理されたのは良かったと思います。
Gaji-Labo 吉澤:ぼくは数ヶ月前からプロジェクトに参画したので関与は短いんですけど、単純に技術を置き換えるだけではなくて、良いところと悪いところをちゃんと理解したうえで進めたい、という空気があるチームだなと感じています。
———「いつまでに何ページ分を React 化する」といった進め方ではなく、リアーキテクチャを評価しながら進行するという方針があったんですか？
湯本さん:はい。Gaji-Labo に入ってもらう前から技術検証という側面を強く意識していました。
影響の少ない小さいページでまず動くものを確認して、次に複雑な状態や機能があるページで改めて評価する。そういう段階の切り方ですね。
湯本さん:今も、全ページを React にすればいいとは思っていなくて。React にする価値の低いページは Rails のままでもいいのかなと。
プロダクト価値を高めるために React にしておきたいページを重点的に移行していく、という考え方です。
Gaji-Labo 吉澤:丁寧に評価しながら進めたいという考え方に応えるためにも、技術をちゃんと使いこなしていくことが大切だと思っています。
例えば、React Router を使いこなせていない状態で「良くない」とチームが判断してしまうことがあってはいけないな、と。
西村さん:正直に言うと、自分は「React Router でいくことは決定している」という先入観を持って進めていました。
でも、「この進め方は本当に正しいのか」をちゃんと評価しながら進めるべきだ、という考え方になりました。
チームが自分たちで進め方を決めていくことで、一度始めてしまったら止められない進め方ではなく、後戻りも選択肢に入れられるんだなと。
Gaji-Labo 下條: Gaji-Labo にご相談いただいた時点で、評価しながら進めたいとお聞きしていたので、開発に入る前にレポートをまとめることを提案をしました。
このプロダクトの React 化を進めるにあたって、良いところと悪いところをちゃんとまとめて、意思決定に使えるようにと考えていました。
西村さん:この進め方についてはツクリンクが決めていたわけではなく、なにも言わずとも下條さんが進め方の提案をしてくれていたのがありがたかったです。
他にもこちらがお願いしてなくても先回りして動いてくれている感じがあって、心強いですね。
湯本さん:最初にレポートをまとめてくれたことで、「一緒のチームで進めていく」って感じになったのが良かったですね。
ただの現状の可視化ではなくて、この先どう進めていくのか明確になったと思います。
———丁寧なリアーキの進め方だと感じます。
Gaji-Labo 下條:レポートや前提をまとめるのに時間をかけてしまったなあと反省しています。
西村さん:そこは、人によって見え方が違うと思っていて、自分は時間かかったとは思ってないですね。
Gaji-Labo がフロントエンド開発に AI を活用する仕組みを入れてくれたり、コードを保守性が高い形にしてもらったりしているので、中長期で見たら早くなるようにしてくれていると思っています。
Gaji-Labo 下條:そう言ってもらえると、ありがたいです。
西村さん:むしろ、最近は下條さんから「手戻りを恐れず、一旦進めましょう」と背中を押してもらって、多くのユーザーが使う複雑なページの改修を一気に進めたりもしました。
必要な手順を踏みながら、ちゃんと前に進めてくれていると思います。
湯本さん:将来のデザインシステム整備とも足並みをそろえたりしているので、フロントエンドの刷新というよりも、プロダクトを一緒に作ってもらっている感覚です。
———フロントエンド開発の AI 活用についての話が出ましたが、どんなことをしているのでしょうか？
Gaji-Labo 吉澤:例えば、既存の Rails の実装を React プロジェクトのサブモジュールとして取り込んで、Claude がそれを参照できる仕組みがあるんですけど。
Claude が実装の参考にするだけではなく、移行漏れがないか検査したりできる仕組みが構築されています。
この仕組みをプロジェクトの開発ワークフローにさらに深く組み込んでいければ、精度も質も上がっていくと思うので、ワクワクしますね。
西村さん:PR (プルリクエスト) を作ったときに、Claude Code Actions でレビューが走るんですけど、これまでの ADR と矛盾がないかを AI レビューされるようにしていますね。
新しく入ったメンバーが過去の経緯を知ることもできるし、決定事項に矛盾するコードを書かないためのガードレールにもなっています。
Gaji-Labo 下條:意思決定のログをしっかり残す ADR を意識しました。
僕たちがプロジェクトから抜けることがあっても、持続可能であるために AI が活用してくれるようになっています。
Gaji-Labo 吉澤:Claude が実装する際に、ADR に従って修正案を出してくれることがあります。ドキュメントがあることで、人間だけじゃなく AI にとっても参照しやすい状態になっている。
湯本さん:「コードの方が正しい」ってことはないんですか？
西村さん: いまのところ、ないですよね？
Gaji-Labo 吉澤: うん、ないと思いますね。
Gaji-Labo 下條:いまは矛盾するほど ADR が溜まってないからだと思いますけど、もっと時間が経過して矛盾するような ADR が増えていったとしても、新しい日付が優先される形で活用されていくと思います。
湯本さん:以前はベンチャーらしく、機能開発が優先されるスタイルだったので保守性は後回しになりがちでした。
でも、このリアーキが始まってから、ドキュメントの重要性をあらためて認識して、積極的に残すようになっています。
西村さん: AI によってドキュメントを活用するコストが下がって、「ドキュメントなんてなんぼあっても良いですからね」って思うようになりましたね (笑)
いまもオンボーディング用の資料を整理していて、フロントエンドを触る人がどこから見ればいいかわかるように整えています。
リアーキって、作った瞬間よりも、そのあと扱い続けられるかのほうが大事なので。
———リアーキテクチャの手応えはありますか？
西村さん:あまり多くのユーザーは使っていないところはほぼ終わっていて、いまは本格的にユーザーに使われている主要機能に着手しているところです。
Gaji-Labo 下條:複雑性の高い主要機能でテストをしっかり書けているのは、大きいと思っています。
テストの書きやすさが確実に上がっていて、このリアーキテクチャがプロダクトの品質向上にはつながっているなという実感があります。
西村さん:一番違いを感じるのは、責務が分離されたことですね。
以前はひとつの場所に詰め込まれていたものが、ロジックや構造を追いやすくなった。人間にとっても AI にとっても、認知負荷は低くなっていて見通しが良いと思います。
西村さん:とはいえ、一度リリースしたけど、問題があってすぐ切り戻したってこともありました。
やってみて初めて見えるものもあったので、試行錯誤の連続ですね。
Gaji-Labo 下條:コンポーネント実装だけではなく、ロジックも API も含めて見ないといけない。なので、かなり丁寧に手探りで進めてきた感覚があります。
湯本さん:切り戻しが発生したときに、一緒にポストモーテムをやっていただいたのが印象に残ってます。
あれ、良かったですよね。
西村さん: あれは助かりました。
問題が起きたときって、心細いじゃないですか (笑)
原因究明から再発防止までディスカッションできたので、まさにチームとしてやってるなと感じました。
Gaji-Labo 下條: Gaji-Labo を実装を進める支援会社の人という扱いをせず、開発チームの一員として受け入れてくださっている感じがして、やりやすいです。
意思決定や進捗、設計の背景も含めて話し合えているのが良いですね。
西村さん:ただ置き換えるんじゃなく、React らしい設計・実装をしていかないと効果が出ないんだなって最近思うようになりましたね。
Gaji-Labo 吉澤:いまは僕たちリアーキのチームが触っていることが多いですけど、これは機能開発をしているチームに引き渡されていくもので、ドキュメントも実装も含めて、フロントエンドの専門家じゃなくても扱いやすいものにしていく必要があると思います。
まとめ: 技術が事業を支えるのだという意思を持った開発チーム
このリアーキテクチャプロジェクトから学べるのは、リアーキを進めることは前提にしつつも、本当に必要か、どこまでやるべきかを途中で問い直し続けていたことです。
小さく始めて、複雑な機能で再評価し、全面移行を目的化しない。技術が事業を支えるのだという意思を持った開発チームだと感じます。
レガシーなフロントエンドに向き合うとき、必要なのは一気に置き換える覚悟だけではありません。何を変えるべきで、何を変えなくていいのか。
どこで評価し、どう学びを残すのか。
範囲の大きなリアーキテクチャプロジェクトほど、その設計の丁寧さが結果を左右する。今回の取り組みは、そのことをよく示している事例でした。
お問い合わせ
私たちはスタートアップのプロダクト開発や新規事業チームの成長支援の会社です。フロントエンド開発やUIデザインなどの専門技術の提供を軸に、成長支援のためのチームワークの提供を一番大切にしています。