ごきげんよう🙋♀️あっきー(@kuronekopunk)です。
2023年に書いた技術課題に関する記事から約2年が経過し、当時からいくつかの課題は解決し、新たな技術的挑戦が見えてきました。
サービスリリースからは約12年が経ち、ユーザー数も機能も着実に増加し続ける中で、技術課題と向き合いながらプロダクト開発を続けています。
この記事では、この2年間でのAWS移行やSREチーム発足といった取り組みに加え、生成AIとの協調を前提とした「AIフレンドリーなアーキテクチャ」への挑戦など、新たに見えてきた技術的な課題と未来への展望についてまとめます。
これまでの取り組み
時系列に関係なく目立ったトピックをまとめていきます。
生成AI活用
Cursor, Devin, Claude Codeなど生成AIの技術をプロダクト開発に積極的に取り入れ、開発組織全体の生産性と品質向上を目指しています。
生成AI活用の関連記事
好みに応じたコーディング支援ツールの利用
ローカルの開発環境はエンジニアの好みに応じ、GitHub Copilot, Cursor, Cline, Claude Codeを選んで利用しています。
現在はCursorとClaude Codeが多数派となっています。
Devin活用
Devinも利用できるようになっており、非同期で作業を依頼するなどユースケースに応じて使い分けています。Devin内でブラウザ操作なども可能なため実際に動かしてテストさせるなどは有用に感じています。
Claude CodeによるPRレビュー
GitHub Actions経由でClaude Codeが自動でPRレビューを行っています。レビュー依頼のプロンプトやワークフローはまだ簡素なものなので開発ルールや環境の整備と共にブラッシュアップしていければと考えています。
SREチーム組成と信頼性への取り組み
SREチームが発足し、サービスの信頼性向上に取り組んでいます。
Dependabotアラートが生成された際には、素早くアップデートできる体制を整備しています。
今後はより高度なチューニングや多角的な監視観点を増やすことで、信頼性の極限追求に取り組んでいきます。
AWS移行
2023年当時課題として挙げていたHerokuからAWSへのインフラ移行は完了しました。移行と同時にインフラ構成をコードで管理するIaC化も実現しています。これによりブルーグリーン・デプロイメントの実現や、PostgreSQL、Elasticsearch、Redisの細かな設定変更が可能になり、より柔軟で安定したインフラ基盤を構築できました。
またインフラ構成がコード化されたことで、AIによる構成の分析や変更提案も容易になり、AIの普及にも対応しやすくなっています。
監視体制の強化
SRE主導でCloudWatch Syntheticsを活用したユーザー視点での定点監視を導入しました。 これにより、実際のユーザー体験により近い形でのサービス監視が可能になっています。
パフォーマンス改善
スロークエリ対策については、主要な問題は解消できました。しかし、Bot等による高頻度なアクセスでスパイクが発生することがあるため、WAF等での制御を随時対応しています。
データ量の増加に伴う新たなボトルネックの発見と改善は、あまり手を付けられておらず負荷検証などは課題として残っています。
QA・テスト戦略
テストを書く文化も根付いており、テストカバレッジは80%を維持しています。
CIにおけるRspecの自動テストは定期的に最適化を行い、現在はユニットテストとE2Eテストが各6分ほどで完了するようになっています。
Flakyテストが一部存在し、開発生産性への影響は少なからず存在しています。
Flutterによるモバイルアプリリニューアル
WebViewベースからの脱却を果たし、一部画面でFlutterによるネイティブ機能の提供を開始しました。WebViewと比べ、より滑らかで快適なモバイル体験を提供できています。
今後はUX向上のため、Flutter実装範囲を継続的に拡充していく予定です。WebViewとネイティブ実装の使い分けを戦略的に進めながら、ユーザー体験の最適化を図ります。
Webフロントエンドの段階的分離
React Routerを活用し一部ページの分離を行いました。これにより、フロントエンドとバックエンドの責務分離が部分的に進んでいます。
まだフロントエンドではテストコードが書けていない状態で、今後拡充予定です。
将来的には、UX向上と責務分離の実現はもちろん、AIが参照しやすい疎結合なコードベース実現への一歩としても重要な取り組みと位置づけています。
デザインシステムの設計
デザイナー主導でMUIをベースとしたデザインシステムの構築が進んでいます。
分離したフロントエンドの中で、デザインシステム用のコンポーネント設計などを行っていく想定です。
モジュラモノリスの試験的導入
モジュラモノリス化については、一部モジュールの分離を試行しました。しかし、依存関係の整理に課題が残り、単純な分離では効果が薄いという貴重な学びを得ました。この経験が、現在のアーキテクチャ全体を見直すきっかけとなっています。
メール・プッシュ通知基盤の改善
2年前の記事にあったメール・プッシュ通知基盤については、現状大きな問題が出ていないこともあり、他の優先度の高い課題に注力するため手を出せていません。安定稼働している間に、将来的な改善計画を検討していく予定です。
認証系についても同様に、現状維持の状態が続いています。今後のモバイルアプリ強化やAPI設計の進展に合わせて、改善の必要性を再評価していきます。
組織、その他活動
職能横断型「Growthチーム」による価値提供
以前はエンジニアのみでスクラムのフレームワークを回していましたが、現在は「Growthチーム」という名前でPdMやデザイナーも含めた職能横断型のFeatureチームで開発をしています。
これにより、エンジニアが「なぜ作るのか」から関わり、プロダクトに直接向き合いやすい環境ができています。単に実装するだけでなく、ビジネス価値の創出により深く関与できる体制は、エンジニアのモチベーション向上にも大きく寄与しています。
社外への情報発信
『つくてくトーク』という外部の方も招いたLT会を毎月開催しています。社外との技術交流により、新しい知見の獲得と自社技術の発信を両立しています。
また、有志メンバーによる隔週でのテックブログ投稿を始めました。
多様な社内学習機会
自由なテーマで話し合う「華金勉強会」や「スクラムガイドを読む会」などが有志メンバーによって開催され、多様な学習機会が増えています。
これから
2025/07以降に取り組みたい課題と方向性をまとめます。
関心の分離、疎結合なアーキテクチャの推進
人間ももちろんですが、AIフレンドリーなコードになるようコンテクストマネジメントの観点から依存関係を小さく保った設計が大切になっていくと考えています。そこで適切に関心を分離し、依存関係を整理することで、コンテクストを小さく保ち、メンテナンス性の高いコードベースを目指しています。フロントエンド分離やモジュラモノリス化も、この文脈で重要な意味を持ちます。
フロントエンド分離
現状、RailsのView上でjQueryを利用している部分が多くあります。テストがしづらく、変更容易性も低い状況です。この課題を解消するためReact Routerを利用したフロントエンド分離を推進しています。現在は検証として4ページの移行が完了しています。
Webフロントエンドを分離することでフロントエンド単体のテストの実施や、デプロイ容易性を上げていき、より開発生産性を上げていければと考えています。
また、並行してデザイナー主導でMUIをベースにしたデザインシステムの整備を行っています。フロントエンドのデザインシステムのコンポーネント設計やStorybookを活用した開発までは手が回っていないため今後推進していく予定です。
モジュラモノリス
過去の試行で得た学びを踏まえ、今後は付け焼き刃な分割ではなく、モデリングから再検討します。モジュラモノリスが最適なのか、あるいはマイクロサービスなど別のアプローチが良いのかを含めて、根本的な設計から再評価する必要があります。これも、前述した「AIが参照しやすい疎結合なコードベース」を実現するための重要な取り組みです。
生成AI活用の強化
現在の取り組みとして、AIによるコードレビュー一次対応など、開発速度向上への貢献を実現しています。今後、開発フロー内での生成AI活用をより充実させていき、開発生産性の向上を図ります。
また、ここから更に発展して、非エンジニアが書いたIssueからAIが自律的に開発・テスト・デプロイまでを完結させることができる開発フローを実現するため、AIが参照しやすいドキュメントやアーキテクチャの整備が不可欠だと考えています。
プロダクト開発のワークフローとドキュメントの整備
AIが仕様や設計思想を理解するため、ADR（Architecture Decision Records）をリポジトリ内に配置するなど、ドキュメントのルール作りや整備を進めています。適切な設計と文書化は今後重要なポイントになっていきます。
PRD（Product Requirements Document）を書いてリポジトリに入れ自動化を考えるなどプロダクト開発のワークフロー全体の最適化を考えていければと思います。
CI/CD, テストコードの継続的改善
テストの実施待ち時間はAIの開発生産性のボトルネックになります。開発のガードレールとしても品質の高いテストをより早く実行できるテスト戦略・設計を見直しより良いCI環境を作っていければと思います。
また生成AIによりPR作成数が爆発的に増えCI費用が上がるため、コスト観点でも重要なポイントです。
組織としての成長
これまでに挙げた技術課題をエンジニア組織全体で向き合い技術力を上げていきます。
去年から始めたFeatureチームでは、エンジニアが「なぜ作るのか」から関わり、プロダクトに直接向き合っていける環境づくりやチーミングを強化していきます。
成長支援という観点では目標設定について別の記事で紹介しています。
採用
こういった技術課題の解消や技術的な判断をリードし、チーム全体の技術力向上を牽引してくれる人材を積極的に探しています。
テックリード候補やSRE、フロントエンドエンジニアなど幅広く募集していますので興味があればご連絡ください。
おわりに
2023年から2年間を振り返ると、多くの課題を解決できた一方で、新たな技術的挑戦も見えてきました。特に、AI活用に向けたドキュメント整備や疎結合アーキテクチャの推進は、これまでとは異なる視点での技術的取り組みです。
技術的負債は悪ではなく、サービスの成長と共に生まれる自然な現象です。大切なのは、それらと向き合い、優先順位をつけて着実に改善していくことだと考えています。
AI時代における開発組織のあり方、エンジニアがプロダクト価値創出により深く関わる体制作り、そして継続的な学習文化の醸成。こうした取り組みを通じて、技術的負債の解消だけでなく、より良いプロダクト開発ができる組織へと進化し続けています。
この記事を読んで少しでも興味を持っていただけた方がいらっしゃいましたら、Twitter（@kuronekopunk）のDMでお声がけください。技術的な課題について雑談したり、カジュアルに話せればと思います。
同じような課題を抱えている方、AI活用やモジュラモノリス、フロントエンド分離などについて具体的に話してみたい方も、ぜひ気軽に連絡ください！
Discussion