AI Nativeがもたらす開発の再設計。ラクスルが挑む「開発生産性の最前線」と未来のエンジニア像

AI Nativeがもたらす開発の再設計。ラクスルが挑む「開発生産性の最前線」と未来のエンジニア像

ラクスルはこれまで、印刷事業から始まり、広告、金融など、複数の事業を多角的に展開してきました。それぞれ異なるドメインやプロダクトを持つ中で、コードベースや開発プロセスは複雑さを増し続けています。レガシーなシステムと新規のシステムが混在し、ドメインが複雑化していくのは、サービスが成長し続ける企業が必ず直面する宿命とも言えます。

そんな環境において、2025年5月、ラクスルは「AI Nativeで開発する」という強力な方針を全社的に打ち出しました。この方針によって、開発のあり方は一気に変化することになります。

AIの導入により、コードの実装スピードは劇的に向上しました。しかし、現場ではこれまでとは異なる「詰まり」が生まれ始めています。開発スピードが上がったことで、ボトルネックは、設計・実装から、要求・要件定義やコードレビュー、品質担保へと移っていきました。開発生産性の本質とは何か。AIがコードを書く時代において、エンジニアやプロダクトマネージャー（PdM）の役割はどう再定義されていくのか。

今回は、システム統括部を率いる箱崎さんに、この目まぐるしい変化の中で見えてきたリアルな課題と、そこから再設計されていく開発組織の姿、長年培われてきたカルチャー、そして今この環境で働く面白さについて、じっくりとお話を伺いました。

開発組織の危機からV字回復へ。

── 箱崎さんは2024年4月に入社されました。「組織の立て直し」が最初のミッションだったと伺っていますが、2年前にラクスルに入社された当時、どのような課題があったのでしょうか。

箱崎：当時の開発組織は「思っていた以上に傷んでいるな」というのが正直なところでしたね。
離職していく方も多かったですし、ミドル層のエンジニアの誰かが抜けてしまったら開発業務が停止するという、属人的なリスクを抱えていた状態でした。マネジメントを担うTechダイレクターもほとんどおらず、ラクスル事業CTOの岸野さんが4つも5つもダイレクターを兼任しているような状況でした。

── いつ破綻してもおかしくない状況だったのですね。そこからどのようにして組織を立て直していったのでしょうか？

箱崎：開発のスタンスや手法を小手先で変える前に、まずは「出血コントロール」と「輸血」、つまり離職の抑止と必要な人材の採用に全力を注ぎました。このような状態においては、やるべきことは極めてシンプルで、「現場のエンジニアの課題意識を確認しつつ、とにかく人を入れること」です。一人で幾つものチームをマネジメントして救うことは現実的ではないため、メンバーに必ず層を厚くします！と宣言した上で採用にリソースを集中させました。
その上で、二度とこのような不安定な状況に陥らせないために、組織の構造的な課題やチーム構成の整備に着手しました。ラクスルの根底にあるカルチャーを尊重しつつ、評価の基準やディクショナリー（共通言語）そのものは変えずに、より「ロングスパン」で人とチームをしっかりと見て、育成・評価していく流れを作りました。
そこから2年が経ち、油断は禁物ですが、組織として見違えるほど立ち直りました。今では事業上の様々な投資や、それに伴う開発をしっかりと安定して踏める、強固な土台ができたと実感しています。

既存の巨大コードベースに挑む。ラクスルが実現した「AIコード生成率8割超」の裏側

── 組織の土台が整ったタイミングで、全社的な「AI Native」の方針が打ち出されたわけですね。この方針がスタートしてから、実際の開発現場にはどのような影響があったのでしょうか。

箱崎：これはかなり影響がありました。世の中にAI Native開発に取り組んでいる企業はたくさんあると思うのですが、やはり企業活動である以上、どんなに現場がコミュニティ活動などで「頑張りましょう」と言っていても、経営陣によるトップダウンの強力なコミットメントに勝るものはありません。
ラクスルでは、ボード（経営陣）が強い危機感を持って「AI Nativeを進める」と宣言し、期中であるにもかかわらず臨時予算を配分して、この取り組みを強烈にプッシュしてくれました。このトップの決断が降りてくれたことが、何よりも大きかったと思います。

── 経営陣の強い意志があったのですね。現場のエンジニアたちの反応はどうだったのでしょうか？

箱崎：ラクスルのすごく良いところは、元々の採用基準がしっかりしていることもあってメンバーがおしなべて優秀である点です。エンジニア一人ひとりが、強いオーナーシップを持って開発に取り組んでますし、何より新しい技術に対する好奇心が強い。そのため、方針が決定される前から、「AIをもっと開発に活用したい」という機運が現場のエンジニアの間で高まっていました。ただ、それまでは予算がなかったり、社内のレギュレーションが整備されてないという壁に阻まれていたんです。
そこにトップダウンで号令がかかったことで、生産性を上げることへのプレッシャーはありつつも、一気に全員が同じ方向を目指して取り組めるようになりました。ラクスルが潜在的に持っていたボトムアップのエンジニアリングカルチャーと、予算の確保や制約の緩和というトップダウンの施策が見事に噛み合い、綺麗な「挟み撃ち」の形になったことで、あとは淡々と実行フェーズに移すことができました。

── この1年で、具体的な開発のやり方や成果はどのように変わりましたか？

箱崎：元々はGitHubCopilotによるコード補完などを個人レベルで使っている状態でしたが、全体としての足並みは揃っていませんでした。当時は世の中の先行事例に対して、ラクスルは組織として少し出遅れている感覚すらありました。しかし、この1年を通じて完全にキャッチアップし、今ではむしろ私たちが「先行ケース」として他社にノウハウを示せる部分もあるというレベルにまで状況が整ってきたと考えています。
分かりやすい指標を1つ挙げると、「AIが生成したコードの割合」が、新規開発だけでなく、長年運用している既存リポジトリへの追加・変更コードも含めて、8割に達しています。

── 新規だけでなく、既存のコード改修分も含めて8割というのは驚異的ですね。他社でもあまり聞かない数字なのでは？

箱崎：純粋な新規プロダクトの開発だけに限定すれば、9割や10割と言うことも可能で、そうした事例はよく聞きます。しかしラクスルが挑戦しているのはそこだけではありません。私たちが取り組んでいるのは、15年もの歴史の中で肥大化し、ドメインも複雑で、ソースコードの煩雑性も高い「既存の巨大なコードベースや技術負債」に対して、いかにAIを使って切り込めるかという、非常に泥臭くて難しい領域です。現在のラクスルは、そうした既存機能の改修や整備までもが、ほぼAIベースでの開発に移行しています。ここは大きなアドバンテージだと自負しています。

── 何もない場所に新しいコードを書くよりも、歴史のある複雑なシステムを止めずにAIと共に改修していく方が、遥かに難易度が高いですね。それを実現できた要因はどこにあるのでしょうか？

箱崎：既存の複雑な領域にどこまで切り込めるかというスタンスを最初から崩さなかったこと、そして現場の優秀なエンジニアたちがAIに対するコンテキストの与え方のテクニックやノウハウを愚直に蓄積し、トライし続けてくれた結果です。
AI Native開発を進める上で一番重要なのは、一部の得意な人だけが突っ走るのではなく、「組織全体のAI活用度の平均値を引き上げること」です。そのため、社内イベントや日々の業務の中で、「こういう型や指示の出し方をするとうまくいく」といった知見をチームを超えて密に共有し、全体の底上げを図っています。
また、組織が一定の規模になったからこそ、最低限の「規律」や技術ガバナンスも敷いています。例えば、ラクスル事業の開発で使うAIツールは、開発においては『Cursor』に統一し（モデルは一定の範囲内で自由に選べる）、PdMでの活用や補佐的な部分ではClaude Codeを活用する、といった一定のルールを設けています。その一方で、それ以外の様々なツールやモデルを試すこと自体は禁止していません。性能やコスト効率的に優れたものがあれば乗り換えられるようにしつつ、同じツールを使うことで、全体としてのノウハウ共有や活用推進がうまいくようにしており、この辺の塩梅が開発組織としての生産性向上を支えるポイントだと思っています。

AI時代にエンジニアの役割はどう変わるか？求められる「二極化」への対応と上流設計

── AIの進化のスピードは凄まじいですが、箱崎さん自身のこれまでのキャリアを振り返って、このAI Native時代において「変わらずに活かせているシステム開発の本質」と、「新しく変えなければならなかった価値観」は何でしょうか？

箱崎：非常に本質的な問いですね。まず「変えなくていい部分」は、システム開発における原理原則そのものです。例えば、マイクロサービスアーキテクチャのように関心を分離してサービスを小さく区切る設計思想や、適切なドキュメンテーションをきっちり残すこと。これらは大昔から言われていることで、一見AIとは無関係に思えます。
しかし、システムが綺麗にマイクロサービス化されて関心ごとが区切られていれば、AIにとっても「理解すべき境界線」が明確になります。結果として、複雑なモノシリック（一枚岩）のソースコードを渡すよりも、遥かにAIは精度が良くて質の高い生成コードを返してくれるようになります。つまり、「人間にとって良い設計や綺麗なアーキテクチャは、AIにとっても理解しやすい」ということです。ベースとなる設計力やデータモデリングの知識の重要性は、AI時代になっても全く変わりません。
逆に「変えなければならなかった部分」で言うと、AIのアウトプットに対する人間の認知レベルの切り替えです。初期の生成AIを知っている人ほど「AIのコードは信用できない、人間が付きっきりでレビューしないとダメだ」と思いがちですが、その認知のままだと、これからの圧倒的な開発スピードや並列度にはついていけなくなります。

── その認知の変化は、これからのエンジニアやPdMに求められるスキル、あるいは採用基準にも影響を与えているのでしょうか？

箱崎：明確に影響しています。ラクスルとしての根本的な採用基準は変わりませんが、今の時代においては「AIをどこまで使いこなそうとしているか」という興味や、アグレッシブな姿勢を非常に重視するようになりました。また、これからの時代は「ハードスキル（純粋なコーディング力）」以上に、コミュニケーションや調整能力といった「ソフトスキル」をより重視する採用にシフトしています。
今後、エンジニアの役割は二極化していくと考えています。1つは、新しいAIのモデルを組み合わせたり、情報や指示の与え方を工夫したりして、AI活用の限界値を押し上げていく「AIパワード層・ビルドアップ層」。もう1つは、実装自体はAIが爆速でやってくれるようになるため、より上流でビジネスモデルを定義し、プロダクトの価値を創出していく「プロダクトドリブンな開発ができる層」です。
後者においては、これまで以上にプロダクトマネジメントへの比重が高まっていくはずです。実装スピードが上がれば、1名のPdMに対して必要なエンジニアの比率はどんどん下がっていきます。これからは、純粋にコードを書くだけの「中間層」の業務は間違いなくAIに代替されていきます。だからこそ、仕様を論理レベルで綺麗に切り分けたり、サービスの分割単位を決めたり、経営的なデータモデリングを考えたりする「人間にしかできない設計力やドメイン知識、ユーザーを理解する力」を持った人材が、より求められるようになると確信しています。
エンジニアも単に技術だけを追うのではなく、業界のドメインをより深く知り、ユーザーの顔を理解して、AIと壁打ちしながらプロダクトを作り込めるような存在へと、役割をアップデートしていく必要があります。

最高の「実験場」へ。プラットフォーム構想の最前線で進化し続けるおもしろさ

── AIによって実装が爆速になったことで、システム統括部としての開発生産性の「捉え方」や「評価指標」にも変化があったのでしょうか？

箱崎：はい、そこも大きく再設計しました。最初は、TechBlogなどでも出していた「Maeged Pull Request（1人あたり、および一定期間あたりの本番コード適用回数）」を指標にしていました。これはこれで分かりやすいのですが、よく考えてみたら「プルリクの数が上がったからといって、事業として何が達成されたの？」という問いが必ず付きまといます。
そのため、現在は「PRD（要件定義書）の作成数」「そのローンチ数」「そしてそこにかかったリードタイム」を全体指標として置いています。もっと分かりやすい言葉で言えば、人を増やさずに「どれだけの施策を、どれだけ短い期間で、どれだけ多く打てたか」という、事業価値に直結する打ち手の数を評価しているんです。

── なるほど。指標をそこへ変えたことで、見えてきた課題はありますか？

箱崎：AI Native開発によって、実装スピードは以前と比べて60%以上は向上しました。しかし、実装が爆速になって並列度が上がった結果、今度は人間が担当している「コードレビュー」のフェーズが詰まったり、PdMが要件定義書（PRD）を作るスピードが追いつかなくなったりするという現象が発生しました。当たり前のことですが、ボトルネックは消えるのではなく、次へと遷移していくんです。今はまさに、その新しく現れたボトルネックの打ち返しを行っているフェーズです。
これに関しては、PdM組織の拡張による上流の根詰まりの解消や、要件ごとのAIへのINPUT情報の整理や、確認観点のスリム化などにより品質を保ったままレビューやテストにメリハリをつけたことで、直近ではPRD単位に対する機能リリースというより大きな単位でもすでに40%以上の生産性（月あたりリリース数）の向上にたどり着いています。
もちろん、ここで終わりにはなりません。現在は例えば、人間が伴走する形から一歩進んで、タスクを完全にAIエージェントに任せ、動作確認から本番環境へのデプロイ（ライブアップ）までを自動で行うような「依頼型・エージェント型」の仕組みを検証し始めています。全体としても短期は鈍化する可能性の高い施策自体のスループットだけではなく、システム開発に関わる問い合わせや運用保守作業自体の自動化や、施策の硬度を上げるために必要な（商品の品揃えや価格に関するものなどの）情報や、オペレーション（入稿プロセスなど）を磨き上げる方向にもAI活用の幅を広げ、引き続き生産性向上カーブを上げ続けるような活動を設計し、開始しています。

── 次々と新しいボトルネックをAIと共に突破していくのですね。現在のシステム統括部を率いるツートップの体制についても教えてください。箱崎さんと岸野さん、お二人の役割分担はどのようになっているのでしょうか？

箱崎：基本的には、お互いの強みを活かして明確に管掌を分けています。私は他社でのマネジメントや経営のバックグラウンドを活かして、開発プロセス、チーミング、組織組成、そして人系の予算やリソース管理など「大人な対応」や泥臭い調整をメインに担っています。一方で岸野さんは、新卒からラクスル事業部CTOを務めるに至ったという強烈な惹きつけを活かして、アーキテクチャの選定やテクノロジーのリーダーシップ、技術負債の解消、そして現場をエンカレッジしてAI Nativeを実際に推進する役割を担っています。このバランスが非常に良く機能していると感じますね。

── 最後に、この記事を読んでいるエンジニアやPdM候補者の皆さんに向けて、今このタイミングでラクスルに参画するおもしろさやメッセージをお願いします！

箱崎：ラクスルは今、MBO（経営陣による買収）を経て非公開化し、「中小企業をEnd-to-Endで支援するプラットフォーム」へと大きく舵を切っています。安定した印刷事業という強固な収益基盤がある中で、新規事業やM&Aを次々と仕掛け、複数のプロダクトを横断した巨大なプラットフォームのシナジーを設計していく、極めてエキサイティングなフェーズです。PdMや事業を創りたいエンジニアにとって、非常に魅力的な環境だと言えます。
そしてエンジニアリングの視点で見れば、ラクスルはすでに「AI活用が当たり前に普及し、既存の複雑なシステムへの適用ノウハウも溜まっている組織」です。数名規模のシードベンチャーでAIを使って新規開発をやるのは簡単ですが、これだけの事業規模と歴史的なコードベースを持つ多国籍なチームで、本気でAI Nativeを推進し、次の「エージェント型自動化」に差し掛かっている組織は、世の中にそう多くありません。
ラクスルは今、本当に面白いステージです。ここで得られるAI Native開発の泥臭い経験値やノウハウは、これからの時代を生き抜くエンジニアにとって、圧倒的な武器になるはずです。「何事もチャレンジしたい」という強いスタンスを持った方には我々も機会を提供しますので、ぜひ一緒に、新しい時代の開発のあり方を再設計していきましょう！

【編集後記】 技術の本質と向き合い続ける、ラクスルの強さ

AIがコードを書く時代になり、開発のあり方は激変しています。しかし、ラクスルのシステム統括部が向き合っていたのは、「人間にとって良い設計は、AIにとっても良い設計である」という、いつの時代も変わらないシステム開発の本質でした。

実装が高速化した先で、次々と現れる新たなボトルネックに組織一丸となって立ち向かい、開発生産性を着実に事業価値へと変換し続ける。非公開化を経てさらなる大勝負に出るラクスルには、自らの役割をアップデートし、圧倒的な先行優位性を築けるエキサイティングなステージが広がっています。

❤️‍🔥 技術の変革期を、ただ消費する側ではなく、自ら仕掛ける側として楽しみたい。そんな熱意を持つエンジニアやPdMの皆さんを、お待ちしています！