RAKSULグループについて

藤門：今日は「AI時代の開発生産性戦略：エンジニアは何を武器にすべきか？」というタイトルでお話しさせていただきます。

まず、ラクスルについて紹介します。皆さんの中にも、会社や個人でラクスルを利用された方がいらっしゃるかもしれません。特に印刷のラクスルとして、名刺やチラシなどでご利用いただいたケースが多いと思います。

印刷事業は確かにRAKSULグループの大きな柱ですが、実際には印刷以外にも多様なサービスを展開しています。これには明確な理由があります。私たちは印刷事業だけでなく、企業、特に中小企業の皆様が起業から成長に至るまでのライフサイクル全体において、End-to-Endで経営課題を解決するプラットフォームを目指しているからです。



具体的なサービス展開について説明します。まず起業・開業時には登記でハンコが必要になるため、ハンコヤドットコムをグループに迎え入れています。事業開始段階では店舗運営にユニフォームなどのアパレルが必要になり、配送業務ではダンボールや梱包材が必要です。これらに対応するためダンボールワンというプラットフォームを展開し、梱包材から配送まで一貫したサービスを提供しています。

そして中小企業が最も課題とする資金調達の分野では、今年の冬を目標にラクスルバンクというファイナンス事業の立ち上げを予定しています。

これらのサービス展開には重要な技術的課題があります。ハンコヤドットコム、ダンボールワン、ペライチ（ホームページ作成サービス）など、様々な企業との連携によってサービスを提供していますが、それぞれが独自のIDシステムや決済基盤を持っています。

その結果、ユーザーが複数のサービスを利用する際には、各サービスでそれぞれ異なるIDでログインし、サービスごとに支払い情報を登録する必要があります。これによってシームレスな利用体験を提供できない状況が発生しています。

そこで私たちRAKSULグループでは、IDや決済を横断的に一気通貫で統合するプロセスに注力しています。この取り組みについて、今日詳しくお話ししていきます。

AI時代のエンジニアは何を武器にすべきか

今日のプレゼンテーションの核心となる問いは、「AIがソフトウェアの70%を書く時代、エンジニアは何を武器にするか？」です。

実は、今回のタイトルはすごく後悔しています。ちょうど5月ぐらいにこんなタイトルで話そうかという話をしていたのですが、この2か月間でAIの進歩がとてつもなく加速したからです。なので、「武器！」とか言ってしまいましたが、「これからClaudeに全てを任せる」といった話をするとすごく滑りそうなので、今日はそうならないようにここでしかお伝えできない話ができればと思います。

AI時代のエンジニアは何を武器にすべきか、この問いに対する答えを見つけるため、今日は先ほど少しお伝えしたプロダクトのPMI（Post Merger Integration）の事例を軸にしてお話ししたいと思います。

ラクスルのPMI事例

今回お話しするのは、ラクスル初の大規模プロダクトPMIの事例です。具体的には、ダンボールワンとラクスルのID基盤と決済基盤の統合プロジェクトについて説明します。



これは実際のモバイル版サイトの画面です。今回やろうとしたことは、ダンボールワンとラクスルのID基盤や決済基盤を統合することでした。従来は各サービスで別々にID登録が必要でしたが、ラクスルIDに統合すれば、どちらのサイトでも同じ体験で商品購入や支払いができるようになります。

なぜこのプロジェクトを実施したかというと、2つの重要な目的がありました。

1つ目は、ID基盤と決済基盤をシームレスにつなぐことで、2つのプロダクトを一気通貫で使えるようにすること。

2つ目は、将来のPMIのためのベストプレイブック作成です。End-to-Endで中小企業をご支援するには、まだ我々のサービスでは足りません。今後もグループを拡大する必要がある中で、次回以降のPMIが効果的、効率的に行えるような再現性の高い手法を確立したかったからです。

実際どうだったかというと、非常に多くの課題が出ました。主要な8つの課題をご紹介します。



まず担当者異動による役割分担の不明確化が起きました。このプロジェクトは約2年間に渡るもので、人事異動により担当者が変わってしまい、「これ誰がやるんだっけ？」という状況になりプロジェクトが停滞しました。

次に相互チェック不足による仕様漏れです。複数チーム間でのコミュニケーション不足により、重要な仕様が漏れてしまうケースが発生しました。

技術面ではDB間のスキーマ不一致に苦しみました。これは歴史のあるプロダクト同士を統合する際の典型的な課題です。

特に深刻だったのが影響範囲・リスクの過小評価でした。「ここを少し直したらこういう機能ができる」と思って影響範囲を見定めても、実はある機能の開発が根っこの方まで伝わっていて、全然違うところに大きな問題を起こすことがありました。

その他にも開発リソース不足で人員確保に苦慮したり、2つの会社でのやり取りにおける関係者間の情報連携・共有不足、データ計測準備不足で状況把握に遅延が生じたり、ユーザーへの説明不足により混乱を招くといった課題も発生しました。

このままだと絶対に物事が進まないわけですが、我々RAKSULグループはなんとか乗り越え多くの課題に解決策を出して対処していきました。

特に重要だった3つの取り組みをハイライトします。



まずプロジェクトの体制再構築です。人が異動してプロジェクトが停滞した時、経営層も介入しプロジェクト体制を再構築しました。「なんでこのPMIやってるんだっけ？」「それぞれのチーム・部門がどんな役割を担っているんだっけ？」ということを明確化しました。

次に全員参加の進捗管理を実施しました。ダンボールワンとラクスル2つの会社があり、さらにはプロダクトマネージャー、エンジニア、デザイナー、カスタマーサポートなど、いろんな職種のメンバーがいて、それぞれ持っている視点が全然違います。そこで全員参加の進捗管理を何度もやり、毎日のように起きる不確実性やリスクを全員で探して早期発見・対処をしました。

最後に、システムだけでなく一部をオペレーション対応することも辞さない柔軟性を持ちました。私たちラクスルは「仕組みを変えれば、世界はもっと良くなる」というビジョンでやっているので、どうしても仕組みで解決したくなります。ですが、最後はシステムだけでは解決できない部分を手作業でも対応することも受け入れる柔軟性が成功につながりました。

これらの取り組みを抽象度を上げて整理すると、乗り越えられた成功要因は3つに集約されると私は思っています。



まず1つ目が「リアリティ」です。私たちRAKSULグループは、印刷のラクスルでは皆さんが普段使っているプリンターとは全然違う大きな印刷機を扱い、ダンボールワンでは物理的な梱包材を扱っています。こういうドメイン知識が必要な領域で、15年以上やってきた経験の上でプロダクトを作っていく実行力を大事にしています。

2つ目が「オーナーシップ」です。プロジェクトの体制が変更になった時に、誰がどこに責任を持つか、特に自分自身がどこに責任を持って課題を解決するかのオーナーシップをクリアにしています。

3つ目が「スタンス」です。PMIでは同じことが二度起きません。不確実な中で2つの判断を迫られた時に、「私はこう思う」「私だったら、こうする」というスタンスを必ず取るのが、RAKSULグループの大事な文化になっています。

RAKSULグループのユニークなところは、ウェブの世界で完結しないビジネスモデルです。サプライチェーンと密接に連携する産業領域では、ドメインの理解と実行力の両立が欠かせません。我々の一番の強みは、このドメイン理解と実行力だと思っています。

PMIに必要なケイパビリティとは

この経験を踏まえて、PMIに必要なケイパビリティを3つの「設計力」として整理しました。

1つ目が「構造を設計する力」です。PMIの初期段階で、プロダクト・組織・技術の「あるべき姿」と、達成度を測る「計測の仕組み」を具体的に設計する能力です。長期にわたるプロジェクトにおいて、あるべき姿を定義し、そこに本当に近づいているかの達成度を測る仕組みを設計し、ロードマップをしっかり作る力が極めて大事です。

2つ目が「協働を設計する力」です。複雑なプロジェクトでは、「誰がどう決めるか」というルール、「いつどこで話すか」という場、「誰が隙間を埋めるか」という役割を意図的に設計する能力が必要です。2つの会社で複数の職種が関わるプロジェクトでは、揉めた時の決定ルールや話し合いの場を設計し、知識や理解のギャップを誰が埋めるかの役割を意図的に設計することが重要です。

3つ目が「判断を設計する力」です。常に発生するトレードオフに対して、「何を優先し、何を犠牲にするか」という判断の軸を事前に設計し、関係者間で合意を形成する能力です。例えば、IDをつないで決済の仕組みを変更する時、ユーザー体験が変わってコンバージョンレートが下がる可能性があります。この時にKPIを取るのか、売り上げを取るのか、プロジェクトの進捗を取るのかという判断が必要になります。事前に判断軸をしっかり作り、関係者間で合意した上で、実際にトレードオフを取る瞬間が来た時に判断できることが重要です。

これを一旦表にまとめると、設計する力は3つあります。構造を設計する力は、What（何を・どのような状態を目指すか）を設計する力として、統合後のプロダクト、チーム、技術基盤が「あるべき姿（To-Be）」を定義し、そこに至るまでのロードマップを描く能力です。



協働を設計する力は、How（どのように）を設計する力として、異なるチームが1つのチームとして効果的に協働するための「プロセス」や「文化」をデザインする能力です。

判断を設計する力は、Why/When（なぜ・いつ）を設計する力として、不確実性が高く、情報が不完全な中で、前に進むための「意思決定の軸」を設計し、トレードオフを乗り越える能力です。

最後にこのプロジェクトの成果についてお知らせします。こちらは直近の決算でお伝えした数値ですが、オレンジで囲ったところでラクスルIDが増えています。ダンボールワンのユーザーの皆さんが、無事にラクスルIDを使っていただいて、IDの統合が完了しました。



顧客の再登録は不要でスムーズな利用ができるようになり、決済情報も共有できることで購買体験が向上しました。顧客データを統合的に管理できることで、2つのプロダクトを両方とも使っていただけるような提案ができることを期待しています。

先ほどの表を頭に覚えていただいた上で、本題のAIの話をしたいと思います。

ソフトウェア開発におけるAIの影響

ソフトウェア開発において、AIの影響とは何なのかという点について説明します。

まず残念なお知らせをします。ソフトウェア開発は、ほとんどAIで置き換わると思った方がいいです。

「AIが70%を書く」という根拠として、アメリカのベンチャーキャピタルが2024年に実施した調査結果があります。この調査では、アメリカのスタートアップやメガベンチャー、ビッグテックのCTOやCIOに対して、現在AIをどの程度活用しているかをヒアリングしています。



濃い黒色の棒グラフが2024年段階で既に使用している割合、青色の部分が2025年に使用予定の割合を示しています。例えばソフトウェアのコード記述（Writing code）については、82%が既に使用中、9%が来年使用予定で、合計91%がAIを活用することになります。

全体を平均すると約70%になります。これは体感値ではなく、既にアメリカで実際に起きている現実です。このAIによる代替の流れは基本的に不可逆的です。

一方で、AIにはまだできないことも多数存在します。人間の強みが活きる領域として、要件定義・ビジネス要求の翻訳、倫理的判断、文脈の深い理解、優先順位付け、ステークホルダーとの協調作業、独自性のある創造的思考、曖昧さへの対応、プロジェクト全体の見通し、大規模システムの統合などがあるといわれていれます。

例えば、文脈を深く理解してものを作ることや、先ほどのPMIのように「あるところを修正すると別の箇所に影響する」といった全体的な影響範囲の把握は、プロジェクト全体やソフトウェア全体を見渡せる能力が必要です。複数のステークホルダーとの協調作業も、AIが自動的に行うことは困難です。



これらの分析は、ChatGPT、Gemini、Claudeの3つのAIに「自分たちの苦手分野は何か」を議論させた結果から導出しました。興味深いことに、大規模システムの統合については、我々が実施したようなプロダクトの統合でさえAIは対応できないと回答しています。

実際に、今日皆さんにお見せしているスライドも、AIで約90%自動作成しています。ハイライト部分が全てオレンジ色になっていますが、これには興味深い背景があります。

ラクスルのロゴは本来、シアン、マゼンタ、イエローといったインクの色を使用しています。しかし、私のXアカウントに「みかん（mikan）」という文字が含まれているため、AIが「あなたのアカウントにみかんが入っているので、ハイライトはオレンジにしておきますね」と勝手に判断しました。

これは私が意図した文脈とは異なる判断であり、AIの文脈理解不足を示す典型的な例です。

さらに興味深いことに、先ほど私がお伝えしたPMIで直面した課題とAIが苦手とする領域には多くの共通点があります。

例えば、AIの「ステークホルダーとの協調作業が苦手」という特性は、PMIでの「関係者間の情報連携・共有不足」と対応しています。「システム全体を見渡せない」という限界は、PMIでの「影響範囲・リスクの過小評価」と同様の問題です。

つまり、AIが不得意だと言っているところは、プロダクトを統合しようとするところで苦しむところと、ほぼ一緒ということが、私の気づきです。

この類似性の根本的な理由は、その構造にあると考えています。。現在の生成AIは「ある言葉の次に来る言葉の確率」に基づいて動作するため、同じプロンプトから同じ結果が出るとは限りません。出力には常に不確実性が含まれています。

我々が体験したようなPMIも基本的に同じパターンが少なく、不確実性が多く含まれています。この構造上の課題が同じなので、PMIで経験する困難とAIで今後我々が体感する困難は、基本的に一緒になるというのが私の気づきです。

先ほどの表に戻り、PMIに必要な3つの軸をAIに当てはめると、以下のような対応関係になります。



構造を設計する力について、AIでソフトウェアを作る際に、「何のためにこれを作るのか」「どのような条件で機能が発動するのか」「どのような形でメンテナンスし続けるのか」などのソフトウェアの構造を言語化してプロンプトに投げ込む必要があります。協働を設計する力について、「ここはAIに任せよう」「ここは人間が判断しなければならない」という分担を決める基準の設計力が必要になります。

判断を設計する力について、AIが作るコードやドキュメントには必ず不確実性が含まれるため、それがアクセプトされるかリジェクトされるかを人間が判断基準で決める必要があります。例えばテストコードなど、この意思決定の基準をAIに組み込まないと活用できません。

先ほどお伝えした3つの力は、AI時代でも全く同じように重要になります。

ソフトウェア開発に本当に必要なもの

皆さんはAIエージェントコーディングを活用されていますか？私も積極的に使っており、最近のGitHubのアクティビティがその変化を表しています。



転職直後の2か月間はほとんど開発活動ができませんでしたが、5月頃からCursorを使い始め、Claude Codeが登場した瞬間に草の色が劇的に濃くなりました。開発アクティビティが大幅に増加したのです。

今日が7月4日で、ちょうど1か月前にClaude Codeが自由に使えるようになったアナウンスが出された日です。たった1か月でこれほど大きく変わり、AIによって私の開発スタイルが急進的に変化しました。

しかし、AIの進化は実際には漸進的です。急激に変化したのではなく、長い時間をかけてステップバイステップで進化してきました。

現在の生成AIは、2006年の深層学習から始まっています。途中でTransformerという重要な論文が発表され、そこから生成AIが毎年着実にステップアップしてきました。計算機能力の向上やビッグデータの普及も進化を支えており、昨日今日で急に性能が上がったわけではありません。

私が現在このような速度で開発できているのは、AIエージェントコーディングが開発のベストプラクティスの基盤の上に成り立っているからです。



AIが作るコードの正しさはテストによって保証され、AIへの学習は既存ドキュメントを使用し、学んだことを再度ドキュメント化することで複雑性を管理します。AI自身がソースコードを書いて検証するためには標準化されたインフラ環境が必要で、これら全ての要素が揃うことで開発が一直線に進みます。

まとめると、AIエージェントコーディングは急に登場したものではなく、ソフトウェア開発のベストプラクティスの上に成り立っている開発手法です。

私たちが長い間「テストは重要」「ドキュメンテーションは重要」と言い続け、試行錯誤を積み重ねてきた蓄積の上にAIが乗っているからこそ機能します。

これまで「事業が優先」「プロダクトの成功（PMF）の方が先」といった議論をしてきましたが、もうその議論は終了したのだと理解しています。スピードを重視してベストプラクティスを後回しにすればするほど、AIによるレバレッジを受けられず、その会社は必ず淘汰されるという構造の変化が既に起きているからです。

AIによってソースコードは書けるようになりました。私たちに求められるのは、単なる実装者ではなく、ソフトウェア開発の構造を理解し、自分たちならどのような構造にすればもっとプロダクトを早く作れるか、生産性高く作れるか、ユーザーのために価値を作れるかという構造を設計し、整えるエンジニアになることです。

私自身も単なる実装者ではなく、ビジネス価値を最大化する構造を作れるようなエンジニアでいたいと思っています。

最後にもう一回、PMIの話に戻すと、今ラクスルで何をしているかというと、今回のPMIのプロセスを踏まえて、全員で振り返りを実施しています。振り返りをした結果、現在別で走らせているプロダクトのPMIがあって、ここで学んだことを次のPMIに全部活かしています。リファクタリングをしています。加えて、重厚なプレイブックを作るためにドキュメントを強化しています。

私たちのプロダクト開発もそうですが、このPMIも全て同じように構造からデザインすることで、うまくいくのではないかと思います。私自身も、そうした視点を持ったエンジニアになりたいと思っていますし、日本の伝統的な構造や慣習にとらわれず、新しい価値を生み出し、より良い日本と社会を築いていける会社でありたいと考えています。皆さんと一緒に、その未来をつくる仕事ができれば嬉しいです。

アーカイブ動画も公開しております。こちらも併せてご覧ください。
※ご視聴には登録が必要です