■ 1. インタビュー対象者の概要
- パーソルキャリアに2022年7月入社、エンジニア歴は約8年
- 入社後は機能追加チームを経て、自ら希望してdodaリビルドプロジェクトに参画
- 現在はシステムアーキテクトとして、求人領域のチームリーダーを務めマイクロサービス化を推進
■ 2. dodaシステムが抱えていた課題
- システムは15年以上稼働する大規模な構成
- 技術的負債と開発効率の課題:
- フロントエンドとバックエンドのソースが混在し、軽微な改修でも影響範囲が広く開発速度が低下
- フロントエンドにJakarta Pages（JSP）を採用していたため、バックエンドとの密結合が発生
- 外部ベンダーへの開発委託期間（6〜7年前まで）により、保守性を考慮しない設計になっていた
- ユーザー体験の課題:
- Webサイトの描画速度が遅く、サイト内パーツの動作も緩慢
- Googleの「Core Web Vitals」の数値が競合他社と比較して低水準
- 以上の背景から2020年以降、内製化の方向性に転換
■ 3. dodaリビルドプロジェクト
- 目的: フロントエンドとバックエンドを分離し、JSPからReactへ置き換え
- チーム体制の改善:
- 当初はフロントエンドとバックエンドでチームが分離しており、APIインタフェースの不整合による手戻りが頻発
- 担当者の提案により画面ごとに両領域のメンバーを混在させたチーム編成を導入
- 再編成によりコミュニケーションロスと手戻りが改善
- ドキュメント不足への対応:
- 設計書ではなくソースコードを「正」として、リバースエンジニアリングで仕様を起こした
- プルリクエストによるレビューでダブルチェック体制を整備
- 完璧を目指さず90%を目標とし、問題発生時に旧アーキテクチャへ即時ロールバックできる体制を構築
- 改善結果:
- Core Web Vitalsの3指標すべてで網羅率80%超を達成（目標水準は70%以上）
- モダンなアーキテクチャへの移行によりリリース頻度が増加し、開発効率が向上
- バックエンドにクリーンアーキテクチャを採用し、外部依存を排除することで保守性を向上
■ 4. dodaマイクロサービス化プロジェクト
- 背景と課題:
- doda周辺システムがすべて同一の巨大な共有データベースを参照しており、変更時の影響範囲が広い
- 影響範囲の調査だけで時間を要し、開発速度の低下を招いていた
- プロジェクトの方針:
- 各アプリケーション専用のデータベースを切り出し、アプリケーション単体でリリース可能な構成に変更
- リビルドプロジェクトでフロントエンドの密結合を解消した後、共有データベースの密結合解消を目指す流れ
- マイクロサービスを選択した理由:
- 規模の小さなアプリケーションではモノリス回帰の事例が増えているが、dodaほどの規模では各アプリケーションをスリム化する方が保守性と生産性の向上に有効と判断
■ 5. AI活用の取り組み
- 社内でClaude Codeを導入し、仕様調査・テスト・実装の各フェーズで活用
- 運用上の課題と対策:
- 社内では1日のトークン使用量に上限があり、マイクロサービス化されていないコード量の多い部分では制限に達しやすい
- CLAUDE.mdに情報を記述することでAIに方針を与え、迷走を防ぐ仕組みを導入
- OSSのガードレールフレームワークを活用し、安全な生成AI利用を実現
- マイクロサービス化とAI活用の関係:
- 細かいリリースを可能にするマイクロサービス化はAI活用の推進にも有効
- AIを活用することで、仕様の要望を即座に動くものとして提示できるスピード感が実現可能になる見込み
- 将来構想:
- AIエージェントを求人検索に活用し、ユーザーがチャットで話しかけるだけで個人の志向や将来像に合わせた求人を提案できるシステムを目指す
■ 6. 組織文化とリーダーシップ
- パーソルキャリアの組織風土:
- 挑戦したいことに自ら手を挙げることで参画できる環境
- 技術選定をボトムアップで進められる裁量の大きさがある
- リーダーシップのスタイル:
- サーバントリーダーシップを意識し、メンバーが主体的に動ける環境づくりを優先
- チーム内の心理的安全性の確保と情報共有の仕組み化を重視
- 優秀なメンバーにはマイクロマネジメントよりも自律的に動ける環境が生産性向上につながると考える
- 今後のキャリア目標:
- 傾聴スキルやサーバントリーダーシップに関する知識を習得し、マネジャーへのキャリアアップを目指す
- 自らの組織像を描き、実現に向けたロードマップを引けるマネジャーを目指す
- 生成AIを活用した開発手法の導入による生産性向上に継続して取り組む