⤴️
Fusic Tech Live 〜プロダクト開発を支える技術〜 レポート
2025 年 2 月 12 日、Fusic が主催する「Fusic Tech Live 〜プロダクト開発を支える技術〜」がオンラインで開催されました。今回のテーマは、自社で開発・提供している「360（さんろくまる）」と「sigfy」という 2 つのプロダクトに焦点を当て、どのような技術や組織運営でサービス価値を高めてきたかが語られました。登壇したエンジニア・プロダクトマネージャーのリアルな知見が満載の、熱量あふれるセッションを振り返ります。
オープニング
進行を担当した砂本氏から、イベントの概要や注意点が案内されました。Fusic Tech Live は、Fusic のエンジニアやプロダクトチームが実践を通じて得た知見を共有するイベントです。今回は、「プロダクト開発を支える技術」と題し、受賞歴のある 2 つの自社プロダクトがどのように成長し、どのような技術的工夫によって開発を進めているかが紹介されました。 以下では、3 名の発表と Q&A の内容を中心にまとめます。
発表 1：岡本 泰明「360 リプレースの記録 〜 Laravel & React への移行で得た知見 〜」
360 リプレースの背景と概要
最初に登壇した岡本氏は、新卒入社後に競技プログラミングの経験を活かし、数理最適化や Web 開発などに取り組んできたエンジニアです。今回のテーマは「360 リプレース」。360（さんろくまる）は、360 度フィードバックを Web 上で実施できるサービスで、既存のケーク PHP ＋ jQuery 構成から Laravel ＋ React への大規模リプレースを敢行したそうです。
ケーク PHP から Laravel へ 新人研修でも Laravel を採用するほど社内で Laravel の経験が増えたことや、開発メンバーを確保しやすいメリットが理由とのこと。
jQuery から React & TypeScript へ 複雑化していたフロントエンドを SPA 化し、型定義を活用して開発体験を向上させる狙いがあったとのこと。
大変だったポイント
ビジネスロジックとテストケース対応 8 年にわたる運用の中で蓄積した業務ロジックが複雑化。既存仕様を正しく把握するために、過去のドキュメントや当時の担当者に聞き込みを行い、テストケースを流用するなど慎重に進めた。
jQuery の依存関係 同一ページで複数ファイルにまたがって jQuery コードが書かれており、解体作業が難航。ビューと JavaScript の相互依存を取り除くのに苦労した。
DB 移行とクエリ検証 ケーク PHP の ORM から Laravel の Eloquent への移行は書き方が大きく異なるうえに、集計ロジックの精度が 360 において非常に重要だったため、丁寧にテストを実施した。
こだわったポイント
開発体験（DX）の向上
型定義の自動生成 ララベルタイプジェンという OSS を活用し、Laravel のモデル定義から TypeScript の型を自動生成。フロントエンドでの型安全と開発効率を向上させた。
Excel のインポート/エクスポート最適化 Laravel-Excel を導入し、大規模なデータのインポート/エクスポートをシンプルに実装。運用現場での Excel 利用が多い 360 には不可欠な改善だった。
CI での自動チェック PHPUnit テストや ESLint などの静的解析、型チェック、翻訳ファイルのキー重複チェックなどを CI 上で実行。開発者が本質的な実装に集中できるようにし、品質担保にもつなげた。
E2E テストの導入 Laravel Dusk による E2E テストを用い、画面上の動きを再現。スクリーンショット比較テストも導入したが、細かい差分をどう扱うかなどで苦労したそう。
Q&A ダイジェスト
Q: 「フロントとバックを完全に切り離さず、Laravel + Inertia.js を選んだ理由は？」 A:（岡本氏） 「単純に SPA を試してみたかったのが 1 つ。あとは、ララベル側で型定義を用意し、それをフロントに自動生成するというワークフローが取りやすかったことが大きいです」
Q: 「E2E テストが大変とのことですが、具体的には？」 A:（岡本氏） 「スクリーンショット差分を扱う部分です。ピクセル単位で差分検出されると誤検知が多かったり、テスト結果を安定化させるために乱数シードの固定や差分閾値の設定などを試行錯誤しました」
発表 2：イ ドヒョン「サービス安定化の大切さと、DB サーバー負荷を減らした話」
サービス成長に伴う安定化の課題
続いて登壇したイ・ドヒョン氏は、2015 年に Fusic へ新卒入社後、「sigfy」プロダクトの立ち上げから 7 年間携わってきたエンジニアです。初期設計からインフラ、バックエンド、フロントエンド、さらにモバイル開発まで幅広く手掛けてきました。
sigfy は学校と保護者をつなぐ連絡サービスで、ユーザ数が増えるとともに負荷が急増。トラブル対応が続き、運用スケジュールがたびたび崩れてしまうなど、安定化が最重要課題となりました。
DB サーバー負荷削減の取り組み
背景 Web サーバーの負荷対策はクラウドのオートスケーリングや ELB などを用いていたが、DB サーバーはリードレプリカやバージョンアップでしのいでいたため、根本的な負荷増への対処が追いつかない状況に。
原因調査と検証
スロークエリロギング 長時間かかるクエリを記録し、頻繁に実行されるクエリを洗い出す。
パフォーマンスインサイト RDS のメトリクスをチェックし、負荷が急増するタイミングを特定。セッション状況やスパイク発生時のクエリ数を可視化し、真のボトルネックを明確化した。
本番同等の検証環境 プロダクションと同じスペックの RDS インスタンスを用意し、ローカス等で実際のユーザアクセスに近い負荷シナリオを再現。クエリ最適化の効果を数値で検証した。
解決策と効果
マテリアライズドビューの活用 頻繁に参照される巨大テーブルに対し、マテリアライズドビューを導入。更新タイミングを管理しつつ、クエリ負荷を大幅に削減することに成功。
テーブル分割・再設計 更新頻度の高いフラグ系カラムを別テーブルで管理するなど、スキーマ設計を見直し、クエリの実行時間を短縮。
導入後の本番実績 CPU 使用率が劇的に低下し、AAS 値（高いと負荷の要因）が大きく下がった。これにより、これまで繰り返し発生していたスパイク時のパフォーマンス懸念が大幅に緩和された。
Q&A ダイジェスト
Q: 「本番と同等の環境で検証するのは大変では？」 A:（ドヒョン氏） 「確かに手間はかかりますが、やらないと根拠のある判断ができません。負荷状況を確実に再現し、解決策が本当に効くかを確かめるためには必要なプロセスでした」
Q: 「まさに SRE っぽいですね。普段からどんなふうに運用を？」 A:（ドヒョン氏） 「大規模な負荷対応が必要な時は、本番データ規模と同じ環境を作り、原因分析から検証まで一気通貫で行うフローを整えています。必要に応じてスケールアップで凌ぎつつ、根本対処を継続していますね」
発表 3：船越 将一「チームの想いを大切にしたプロダクトマネジメント」
住宅開発と自社プロダクト開発の違い
最後に登壇した船越氏は、Fusic のプロダクト部門長として「sigfy」「360」両方の価値を探求するプロダクトマネージャーです。長年のディレクターやプロジェクトマネージャー経験、そして人事領域への関与から、チームづくりとプロダクトづくりを併せて考えるアプローチが印象的でした。
自社プロダクトの難しさ 受託開発と違い、自ら仕様を決めて意思決定を行うため、答えがない状態で手探りになることが多い。大きな意思決定を 1 人で担うには限界があるため、チームの集合知を活かすことが重要だという。
プロダクトの軸とチームの思い
軸（ミッション・ビジョン・大切にしていること）を作る 答えがない中でも「何のためにやるのか」「どんな価値を届けるのか」を明確化するのが、プロダクトに“芯”を与える。
全メンバーが納得感を持てる状態 チーム全体でワークショップや雑談会を重ね、現状の課題や将来像を共有する。メンバーの思いを乗せることで、熱量と連帯感が生まれ、最終的に「尖ったプロダクト」へと繋がる。
大事にしているコミュニケーション文化
雑談会でオープンな人間関係を築く 雑談だけでなく、「モヤモヤ」「悩み」「ワクワク」を率直に話し合える場を定期的に設けている。
ゴールや合言葉の共有 チームの合言葉を決め、「もっとできる」精神を全員で意識。360 などの仕組みを活用しながらお互いにフィードバックし合い、目指す姿をブラさず進める。
Q&A ダイジェスト
Q: 「少人数で開発しながら営業面もこなすコツは？」 A:（船越氏） 「営業専門の担当を厚くできない中、パートナー企業の活用が鍵だと感じています。結局『このプロダクト良い』と自信を持って推してもらうために、サービス品質や“軸”が大事になるんだと思います」
Q: 「人事的視点をどのように PM に取り入れているのか？」 A:（船越氏） 「チームが“小さい組織”なので、メンバー全員の成長や人間関係づくりは PM の重要業務になっています。技術面だけでなく、各メンバーの想いを尊重し、意欲を発揮できる体制づくりを意識していますね」
全体を踏まえた感想 〜想いが生むプロダクトの力〜
3 名の発表から浮かび上がったのは、以下のようなポイントです。
技術的アプローチを「仕組み」で支える
Laravel + React 移行に伴う型定義や CI 自動チェックなど、継続的な開発を進めやすくする工夫が、リプレース後の開発速度と品質向上につながる。
DB 負荷対策では一時的なスケールアップだけに頼らず、マテリアライズドビューやテーブル分割など、原因を徹底分析し根本的な最適化を図る。
軸づくりとチームコミュニケーション
「何のために作るか」「どんな価値を生みたいか」のプロダクト軸を共有し、全員が自分ごと化することで、機能追加や運用の優先順位がブレにくくなる。
雑談会やフィードバックの場でメンバー同士が互いの思いや意見をオープンに共有し、共通の合言葉や目標を持つことで熱量が高まる。
メンバーの“想い”がプロダクトを強くする
余白ある開発スケジュールやアイデア出しの場を用意することで、技術的・ビジネス的に新しい取り組みが生まれる土壌を整える。
突発的なアイデアやモチベーションを殺さずに実装できる体制が、付加価値の高い機能や差別化につながっていく。
サービスの魅力や強みを育むには、コードやインフラだけでなく「チームがどんな思いを持ち、どんなコミュニケーション文化を築くか」が大きく影響する ── そんなメッセージが印象に残るイベントでした。今後も Fusic が手掛ける 2 つのプロダクトがどのように成長し、どんな技術やチーム運営の工夫を見せていくのか、ますます注目していきたいところです。
Yardでは、テック領域に特化したスポット相談サービスを提供しています。
興味がある方は、初回の無料スポット相談をお申し込みください。
また、資料請求やお問い合わせもお待ちしております。テック領域の知見を獲得し、事業成長を一緒に実現していきましょう。
Read next
Loading recommendations...