ラクスに入社を決めた理由、背景等を教えてください。

前職はSIerのエンジニアとして、経費精算システムの導入案件を通じてこの領域の専門性を深めてきました。ただ、お客様の課題に対して「これが業界標準です」と自信を持って提示できる解決策を、自分自身では用意できないもどかしさがありました。

そうした中で出会ったのが楽楽精算でした。業界トップの導入社数を誇り、経費精算のデファクトスタンダードと呼べるサービスです。お客様の業務を効率化する「業界標準」そのものを提供していく企業の姿勢に共感し、入社を決めました。この想いは、3年が経った今も変わっていません。

実際に入社してから意外だったのは、マネージャーであっても技術力・技術理解が不可欠だということです。配下のメンバーは全員が開発エンジニアですから、その仕事を理解し育成していくには、自分自身にも技術力が求められます。私自身、ドメイン設計やアーキテクチャ、テストの考え方をイチから学び直しました。マネジメント職になってからも技術を学び続けられる環境だったことは、結果として良かったと感じています。

自組織の業務内容と役割を教えてください

楽楽精算の開発組織は現在6課体制で、開発2課は課長の私を含めて9名です。

開発2課の役割は、楽楽精算のコアドメインである伝票起票まわりの機能開発に加え、電子帳簿保存法などの法制度対応、そして楽楽請求や楽楽電子保存といった他商材との連携機能の開発を担うことです。単体の経費精算システムを超えて、「支払管理ソリューション」を構築していくための開発案件を主に担っています。

課の中は2つのチームに分かれており、各チームにはリーダーとしてプロジェクトマネージャーが立ち、管理職である私もPMとしてリードしています。構成はプロジェクトマネージャー1名、テックリード1名、シニアエンジニア2名、若手エンジニア4名。9名のうち4名が若手という育成比重の高い編成になっていますが、これは意図的にそうしています。

生成AIを取り入れることでコードベースに対する経験値の差が縮まってきたため、難易度の高い案件にシニアエンジニアと若手が共に取り組む形にし、早期のレベルアップすることを狙っています。

チームの日々の業務の流れを教えてください

メンバーの1日は、開発タスクの実行計画づくりから始まり、AIへの作業指示、生成結果のレビュー、そして他のメンバーの成果物のレビューが中心です。

以前は「コードを書く時間」が主でしたが、その前の準備と、出てきたものを評価するレビューへと時間配分が大きくシフトしました。作業もシリアルからパラレルへ変わってきており、メインの開発案件を進めながら、別のAIエージェントにリファクタリングを指示して並行で走らせるといった進め方もしています。

リリースサイクルは3ヶ月間隔の定期リリースに加えて、その間の月にもマイナーな機能リリースができるようになってきました。開発プロセスはウォーターフォールの比重が大きいですが、UX改善が中心となる案件ではスクラムも取り入れており、2週間スプリントでプランニングとレビューを回しています。

ミーティングは開発プロジェクトごとの朝会（DSM）が基本で、スクラムチームはスプリントのプランニング・レビュー、それ以外にチーム別の週次MTGと振り返り（レトロスペクティブ）を実施しています。

チームではAIをどのように活用していますか？開発や業務にどんな変化をもたらしていますか？

現在はClaude Codeを中心にAI駆動開発を行っています。

2025年から、若手メンバーがAIを活用して新規機能を実装し、シニアエンジニアがそれをレビューするという方式を本格採用しました。今ではエンジニアが直接コードを記述することはほぼなくなり、AIが生成したものをレビューして、その妥当性や技術的判断を下すやり方がメインになっています。

用途は実装だけではありません。

要件整理の段階で既存機能への影響範囲や考慮すべき点のドラフトを作らせたり、UX検討ではHTMLモックを出力させて叩き台にしています。テスト工程はPlaywright MCPを使った自動化も部分的に実現しました。レビューについても、誤字・誤植やコーディングルール違反といった従来人間が指摘していた内容はAIレビューでほぼゼロにでき、人間は要求事項の実現性やアーキテクチャの妥当性といった本質的な観点に集中できるようになっています。

ただし、ここに至るまでには壁もありました。最初にぶつかったのはコードレビューです。実装は若手メンバーが中心だったため、AIが生成したコードが妥当かどうか、特にどの層に機能を実装させるのが適切か、テストコードが十分で妥当かという判断に時間がかかりました。この課題は、テックリードをレビュアーとしてアサインし、若手の判断をテックリードがさらに評価してチェックする二段構えにすることで解決を図りました。若手が判断に窮して手が止まってしまう事態を防げただけでなく、テックリードの判断基準を若手へ継承していく効果も得られたと考えています。

こうした取り組みを経て、効果は明確に出ています。従来であれば6ヶ月かかっていたような大規模案件を、半分の3ヶ月で開発できる状況になりました。一方で品質については、正直に言えばまだ過渡期です。十分な品質を担保できるレベルまでコンテキストやルールが蓄積されているわけではなく、「テストによって品質を担保する」という段階を抜けられていません。ただ、テストの観点や暗黙知的な要素をコンテキストとして蓄積する取り組みも進めており、個人の経験値による気づきに頼るのではなく、仕組みによって品質を改善していけると考えています。

開発としての事業への関わり方を教えてください

開発2課の役割は、顧客課題の解決を「どう実現するか」を考えることです。仕様そのものを開発側から提案する機会は多くありませんが、だからこそ、顧客への価値提供は実装の判断そのものにかかっており、顧客業務への解像度が技術判断に直結します。

たとえば、電子帳簿保存法対応システムである楽楽電子保存との連携案件では、非同期のメッセージ連携方式を採用するというアーキテクチャの提案を開発から行いました。判断の根拠は2点です。1つは電子帳簿保存法の観点で、万が一保存した証憑がロストして楽楽電子保存に保存できなかった場合、それは法制度違反となりお客様の業務に大きく影響します。もう1つはユーザビリティの観点で、同期処理にしてリトライなどの保証を組み込むと申請処理のレスポンスタイムが伸び、ユーザー体験が劣化します。この両方を踏まえて非同期方式を選びました。お客様の業務と法制度への理解がなければ、技術選択そのものを誤ってしまう領域だと考えています。

チームの雰囲気を教えてください

若手とシニアの混成チームですが、関係性はとてもフラットです。

集中して作業に向かうタイプのエンジニアが多い一方で、解決すべき課題があれば対面という利点を活かしてその場で議論します。そうした場面で、若手エンジニアからも意見や考えが活発に出てくるのがこのチームの特徴です。経験年数ではなく、根拠を持って話せるかどうかで議論が進みます。

AI駆動開発への移行は、この雰囲気があったからこそ進んだ面があります。

AI活用の知見は課の週次MTGの枠内に共有セッションを設けており、「今週はこのような活用をしてこのような成果が得られた」という事例をメンバー自身が発表する形で回しています。誰かが決めたやり方を上から配るのではなく、うまくいったことを持ち寄って広げていくスタイルです。変化の速い領域なので、この共有の場がチームの学習速度をそのまま決めていると感じています。

チームでは、どんなやりがいを感じられますか？

開発2課が扱うのは楽楽精算のコアドメインに関わる機能開発で、お客様からのニーズ、営業からのニーズが特に高いものです。そのためリリース後に「実際に使いやすくなった」「機能が頻繁に改善されている」というフィードバックを、CSや営業を経由して聞くことができます。直接お客様と接点を持つ立場ではありませんが、自分たちの開発が確かに顧客価値になっていると実感できることが大きなやりがいです。スクラムで開発している案件では、スプリントレビューにCSや営業の代表に参加してもらったり、お客様にデモを見ていただくこともあり、そこで得られる反応もモチベーションになっています。

もう一つは成長機会です。

若手エンジニアであってもワンランク上の仕事を任せて成長の機会をつくることを大事にしています。従来、当課では「一定の経験を積むまでは上流工程を任せない」という考え方が根強くありましたが、私自身はもっと早いタイミングで任せられるはずだと感じていました。そこで育成のロードマップを引き直し、そのうえでチャレンジしてもらうようにしました。結果として、案件の難易度によりますが、いわゆる要件定義に該当する部分を従来より1年ほど早い段階で任せられるようになっています。難易度の高い案件にシニアと一緒に入り、自分の判断が形になっていく経験は、本人にとって大きな手応えになっているはずです。

マネジメントにおいて重視されていることはありますか？

一貫して重視しているのは、チームとして成果を出すこと、そのために考えていることを言葉にして伝えることです。そこに加えて、この1年はAI駆動開発という大きな変化をどう浸透させるかがマネジメントの最大のテーマでした。

AIを使った開発は今後の主流になるはずで、逆らうことはできないと考えていました。ただ、レガシーかつ膨大なコードベースを前に、AIで成果を上げられるイメージが湧きにくいという状況もありました。そこで、まず感度の高い若手エンジニアに実際にAIエージェントを使ってもらい、成功事例を作ることを意識しました。あえてシニアエンジニアより先に若手で実績を出すことで、「実際にやってみよう」という空気が組織の中に生まれ、浸透につながったと考えています。号令をかけるのではなく、事実で空気を変えるアプローチです。

同時に、任せて放置しない設計も必要でした。テックリードを二段目のレビュアーに据える仕組みは先述の通りですが、これは停滞を防ぐと同時に、テックリードの判断基準を若手へ継承する育成の仕組みでもあります。そして、AIが書いたコードを人間が正しく評価するには、判断根拠となる基礎の技術力が欠かせません。若手には書籍などを通じて基礎知識を身につけることの重要性を繰り返し伝えています。

活躍できる方の人物像を教えてください

AI駆動開発を取り入れたことで、エンジニアに求められる力は明確に変わりました。「どう実現するか」を突き詰めるための技術要件を上流から自ら整理する能力、そしてアーキテクチャや実装について判断を下す力です。機能開発を担う開発2課でもそれは同様です。

まず、エンジニアであっても顧客ドメインをしっかり理解しようとするスタンスが必要です。前述の連携方式の判断のように、お客様の業務と法制度への理解がなければ技術選択を誤ってしまう領域だからです。

もう一つは、AIが生成したコードが適切かどうかを根拠を持って判断できる技術力です。これはコーディングのスピードや手数ではなく、設計やテストの原則に立ち返って「なぜこれが妥当なのか」を説明できる力を指しています。AIツールの利用経験そのものが必須というわけではありません。むしろ、これまで積み上げてきた設計・実装の判断軸を持っている方であれば、AIを前提とした開発の中でその価値がより大きく発揮されます。

入社された方と取り組みたい課題、またチームで目指す組織像を教えてください

直近の最大のテーマはデリバリーの高速化です。これまでは開発組織をスケールさせる、つまり人数を増やし、増えていくメンバーを確実に成長させるというスタンスを取ってきました。ここからはAIを活用することで、むしろ小規模チームへ再編し、コミュニケーションコストも含めた生産性の向上を目指していきます。目標として掲げているのは、月に1回は機能リリースを実現し、お客様にタイムリーに価値を提供し続けられる組織です。先述のリリース体制を土台に、その先を狙う段階に来ています。

もう一つ、一緒に取り組んでいただきたい課題が品質です。先述の通り、AI駆動開発の品質はまだ過渡期にあります。テストの観点や暗黙知的な要素をコンテキストとして蓄積し、個人の経験による気づきに頼らず、仕組みによって品質を改善していくループを、巨大なコードベースの中で着実に広げていきたいと考えています。難易度は高いですが、業界のデファクトスタンダードを支えるシステムでこれに取り組める環境はそう多くないはずです。技術的な意思決定を一緒に担ってくださる方をお待ちしています。