スタメンでCTOしております、 @tnir ( X: @takuya_stmn , note: @takuya_stmn ) です。 2023年9月、スタメン技術ブログで次の記事を公開しました。 ドメイン駆動設計は何を解決する手法なのか 記事では、TUNAG の技術的負債解消に向けてドメイン駆動設計（DDD）の導入を検討している、と書きました。その後の対外的な印象として、「スタメンは DDD を積極導入している」と読まれる場面がありました。 本記事の目的は二つです。 当時の検討表明と、いまの実装実態のあいだにある差分を正確に共有すること その後に行った小規模な試験導入（PoC）から得た、Rails 文脈での技術的・組織的な学びを共有すること 結論を先に述べます。私たちの設計の軸は ActiveRecord で、DDD はバックエンドのごく小さな範囲で試しました。その結果、ActiveRecord を軸にする方針を選んでいます。ただしこれは DDD全般の評価ではなく、私たちの文脈での記録です。小さく試し、合うものを残し、合わないものを手放すプロセス自体は、今でも有効なエンジニアリング判断だと考えています。 2023年の記事が書いていたこと 当時の記事の冒頭は、次のとおりです。 株式会社スタメンでは、企業エンゲージメント構築サービス TUNAG（ツナグ）の技術的負債解消と今後の持続的成長のため、ドメイン駆動設計(DDD)の導入を検討しています。 記事は実装報告ではなく、コアドメインを軸に「DDD が何を解決する手法なのか」を整理する解説でした。実装詳細は扱わない、とも明記しています。締めは、将来に向けた表明です。 つまり本文の事実は「導入を検討している」までであり、「すでに積極導入している」ではありません。ただし、解説の熱量や「邁進していきます」という結びが重なると、読後印象としては積極導入企業のように残りやすい面もありました。このギャップを、いま実装と検証結果に基づいて補正します。 当時の課題提起がなければ、机上の議論で終わっていた可能性もあります。検討を公開し、その後に実コードで検証まで進めたからこそ、本記事で共有するトレードオフが見えました。 何を、どこまで試したか 私たちのプロダクトは、大きくバックエンド（API）とフロントエンドに分かれます。 領域 DDD との関係 フロントエンド 導入なし バックエンド全体 教科書的な全面適用はなし。LoC ベースで全体の 1% を大きく下回る範囲で、部分的・実践的な試験のみ 試験の主例 社内教育・テスト（ナレッジテスト）領域の新規 API 見送り後の比較例 タスク依頼・ToDo 領域の新規 API 本記事では前者を 業務DXサービスA API 、後者を 業務DXサービスB API と呼びます。どちらも TUNAG 本体から独立した形で実装されたグリーンフィールドサービスのバックエンドです。 業務DXサービスA API は、MVC でくくると Model がおおよそ 2,000 LoC 前後、View + Controller がおおよそ数百 LoC 規模でした。期間は 2023年12月からの約3ヶ月です。ここでの DDD は、Evans 流の戦術パターンを全面適用したものではなく、不変条件が重要な箇所に限定した実用主義的な導入（DDD-lite としても呼ばれることがある）でした。設問・選択肢・合格判定・受験セッションなど、「壊れると困るルール」が比較的はっきりしている領域だったため、試験対象として適していました。 実コードでは、たとえば次が確認できます。 ドメイン層を ActiveRecord から分離した pure Ruby のオブジェクトがある 選択肢数・重複・合格ラインなどの不変条件を、生成時や操作時に検証する実装がある 一部の更新経路では、リポジトリ経由で集約を再構成してから永続化する 一方で、次の限界もありました。 単純更新・複製・一部セッション更新は ActiveRecord 直叩きのまま残り、層を迂回した 一部のドメインオブジェクトは、振る舞いに乏しいデータホルダーに近い ドメインイベントや、依存逆転を徹底した古典的構成までは採っていない つまり「DDD を名乗るに足る部分実装はあった」が、「プロダクト全体の標準アーキテクチャになった」わけではありません。 時系列は次のとおりです。 時期 内容 2023年9月 技術ブログで導入検討を表明 2023年12月〜約3ヶ月 業務DXサービスA API で部分的・実践的な DDD を試験導入 2024年3〜4月 PoC 振り返り。本格採用を見送り、業務DXサービスB API では採用しない方針を合意 2024年5月〜約3ヶ月 業務DXサービスB API を、DDD 非採用前提で初期開発 現在 フロント未導入。バックエンドでも局所試験の知見にとどまり、標準は ActiveRecord を軸にした設計 業務DXサービスB API は「DDD 導入の第2弾」ではありません。振り返りの結果、採らないと決めたあとの開発です。境界の分離や外部モデルの漏洩防止など、マイクロサービスとして当然の設計はありますが、それを DDD の戦術導入とは数えません。 なぜ本格採用を見送ったか — 技術的・組織的な理由 ここが本記事の本題です。「やらなければよかった」ではなく、「何が効き、何が合わなかったか」を残します。 1. 本来の課題と手法がずれた 2023年の検討の出発点は、TUNAG の技術的負債解消でした。ところが検証が進むにつれ、 手法の導入そのものが目的化しやすい 局面がありました。 負債解消で本当に解きたかったのは、たとえば次のようなことだと考えています。 変更影響の見通しを良くすること ドメイン知識をコード上で追跡しやすくすること チームが安全に改修できる速度を保つこと 一方で、層分け・用語・パターンの整備が進むと、「DDD らしく書けているか」が評価軸になりやすい。すると、負債解消や変更容易性への寄与より、導入の完成度が議論の中心になります。業務DXサービスA API での試験は、この目的化を本体から切り離して観測するためにも有用でした。振り返りの結論は明確で、 その時点のスタメンの文脈では、DDD の本格導入は TUNAG の技術的負債解消に適していない 、でした。 2. Rails / ActiveRecord との摩擦コストが高かった 業務DXサービスA API は Rails API です。ActiveRecord は永続化だけでなく、クエリ・バリデーション・ライフサイクル・関連の中心でもあります。ここに戦術的 DDD（集約の再構成、リポジトリ、pure ドメインモデル）を部分導入すると、少なくとも次のコストが発生しました。 二重モデル化 : DB 行としての AR と、ドメイン上のオブジェクトを往復させる変換が必要になる 経路の分岐 : 不変条件が強い操作だけドメイン経由、単純 CRUD は AR 直叩き、という二系統が同居する 認知負荷 : 「この変更はどの層に書くべきか」の判断自体が、機能追加のたびに発生する 複雑な採点や、正式版の訂正ルールのように、壊れ方が高い箇所では、pure なドメインオブジェクトに寄せる利点はありました。逆に、大半の更新が CRUD に近い画面・API では、変換と層分けのコストが、得られる安全性を上回りやすかった、というのが率直な感触です。 Rails way（責務を散らさない Model、明確な UseCase、必要なら concern）を主軸にした方が、少人数チームでの変更速度と学習コストのバランスが良かった、というのが本格採用見送りの技術的な中核です。 3. 効く範囲が、プロダクト全体のボトルネックと一致しなかった DDD が相対的に効きやすいのは、ルールが複雑で、不変条件の破壊がそのまま障害になる領域です。業務DXサービスA API でも、設問制約や採点のようにその種の箇所には部分適用の合理性がありました。 しかし TUNAG 本体を含むプロダクト全体の負債の主因が、「集約境界が無いこと」だけだったわけではありません。認証委譲、サービス分割、スキーマ契約、運用、データ整合、画面を含む変更伝播など、別種の複雑性の方が大きい局面も多い。戦術 DDD を局所に厚くしても、プロダクト全体の変更容易性が線形に改善するとは限らない、というのが PoC 後の整理です。 4. 小さく試せたから、大きく間違わずに済んだ 見送り自体を失敗とは捉えていません。新規の小さい API で約3ヶ月試し、振り返り、次の新規 API では使わないと決めた。この切れ方の方が、本体へ先に全面適用するより健全でした。 組織として得られた整理は、次です。 DDD は銀の弾丸ではない 導入を目的化すると、負債解消から離れる Rails 中心のプロダクトでは、戦術 DDD の全面適用より、ActiveRecord を軸に複雑箇所だけ設計を厚くする方が現実的なことが多い 手法の採否は、流行や完成度ではなく、事業成長と開発生産性（保守性・変更容易性を含む）で見る いまの設計方針 PoC 後の標準は、ActiveRecord を軸に置いています。UseCase（アプリケーションサービス）でユースケースの流れとトランザクション境界を担保しつつ、永続化モデル側は ActiveRecord 本来の表現力を活かす。そのうえで、モデルを無秩序に太らせないために、関心事ごとに concern へ閉じる、という形です。 これは「Fat Model に戻した」という意味ではありません。ドメイン層と AR を二重に持つコストを下げつつ、ユースケースのオーケストレーションは UseCase に残し、モデルに散らばりがちな関心事だけを concern で分割する、という選択です。Concern の濫用が神オブジェクトの隠蔽になりうることは認識したうえで、DDD-lite の二重モデルより、この分割の方がチームの認知負荷と変更速度に合う、と判断しています。 対外的な事実関係は、次で足ります。 2023年の記事は導入検討の表明であり、全面採用の報告ではない フロントエンドでは DDD を導入していない バックエンドでも、LoC ベースで全体の 1% を大きく下回る範囲での部分的・実践的な試験にとどまる 主例は業務DXサービスA API（2023年12月〜約3ヶ月） 2024年3〜4月の振り返りで本格採用を見送り、業務DXサービスB API（2024年5月〜約3ヶ月）では非採用前提で開発した 現在のスタメンを「DDD積極導入企業」と呼ぶのは実態に合わない 小さく検証し、合わなければ採用しない、という判断は今後も取りうる 手法の是非を好みで決めず、小さく試し、事業成長と変更容易性を含む生産性、および本来の課題（技術的負債解消）への寄与で採否を決める。業務DXサービスA API での試験と、業務DXサービスB API での見送りは、その一例です。 おわりに この記事は、過去のチャレンジ計画ブログ記事を消すためのものではありません。当時の検討や、その後の試験を否定するものでもありません。むしろ、2023年の記事が課題を言語化し、仮説を外に出したからこそ、机上の空論で終わらせず実コードでトレードオフを検証できました。話題の手法をスローガンで終わらせず、小さなプロダクトに落として確かめ、本格採用を見送った記録です。 エンジニアリングにおいて重要なのは、流行を追うことでも、一度選んだ手法に固執することでもありません。自社のプロダクト特性、フレームワークの前提、チームの認知負荷に照らして、効く設計を残し、効かない設計を手放せることです。今回の PoC は、その判断をコードと振り返りで一度通した事例だと考えています。 設計の話をするときも、採用の話をするときも、「スタメンは DDD を積極導入している」ではなく、「小さく試し、Rails / ActiveRecord を軸に UseCase と concern で整理する設計を主軸として選び直した」と読んでいただけると、実態に近いです。 今現在、主に採用しているシンプルな Rails Way に準じたアーキテクチャに関しては別の記事でコメントできればと思います。

はじめに こんにちは！エニグモの採用広報担当です。 本記事では、現在のプロダクト開発チームの体制や組織を横断した意思決定の仕組み、そしてAI駆動開発をはじめとする現在のエニグモの開発環境について紹介します。 エニグモが前回、開発組織の変更発表を行ったのは3年前の2023年のことです。 当時は『チームトポロジー』の考え方を取り入れつつ、Domain・Squad・Chapterをベースとした体制へと大きく転換しました。 それから約3年、生成AIをはじめとするテクノロジーの劇的な進化に伴い、開発スタイルや組織に求められる役割も目まぐるしく変化してきました。 今年2026年4月には、サービスエンジニアリング本部 部長の木村より、今後目指していくエンジニア組織のビジョンを発表しています。 （参考： AI駆動開発とベンチャー回帰で創る次世代エンジニア組織 ） 今回は、前回の記事を3年ぶりにアップデートし、掲げられた「AI駆動開発」や「フルスタック・フルサイクルな開発」を、現在の組織・開発体制の中でどのように実現しているのか、その具体像をお伝えします！ はじめに エンジニアが所属する組織について プロダクト開発体制 ■Domain（ドメイン） ■ Squad（スクワッド） ■ Chapter（チャプター）　 プロダクト開発を支えるチーム エンジニア組織の意思決定 ■ Committee ■ Squad Weekly エニグモならではの開発環境の魅力 ■ 大規模なグローバルCtoCサービスを開発できる ■ AI駆動開発を前提に、フルスタック・フルサイクルへ ■ チームや事業を越えて、経験の幅を広げる まとめ エンジニアが所属する組織について サービスエンジニアリング本部（以下、SE本部）は、エンジニアが所属する部署で、大きく以下の3つのグループで構成されています。 アプリケーション開発グループ ：主力事業である「BUYMA」をはじめとしたプロダクトの機能開発を担当 AIテクノロジーグループ ：AI・データ基盤・機械学習・検索などの専門領域を担当 インフラグループ ：インフラ・セキュリティ領域を中心にプロダクト開発を支援 ここからは、実際の開発体制について詳しく紹介します。 エンジニアはいずれかのグループに所属していますが、日々の開発業務をグループ単位の縦割りで行っているわけではありません。実際のプロダクト開発では、所属グループの枠を越え、事業ミッションや専門性に応じてチームを組みながら活動しています。 プロダクト開発体制 BUYMAのプロダクト開発体制は、事業やユーザーへの提供価値を軸とした「Domain（ドメイン）」「Squad（スクワッド）」と、技術領域を軸とした「Chapter（チャプター）」という3つのチーム単位を設けています。 これらを独立した組織として分けるのではなく、エンジニアはDomain／Squadで事業課題に向き合いながらプロダクト開発を進め、同時にChapterを通じてチームを越えた技術的な取り組みも行う、マトリクス型の体制をとっています。 （※AIテクノロジーやインフラなど専門領域のメンバーは、このDomain/Squadでの開発を横断的に支援するチームとして機能しています。詳しくは後述します。） 　 それでは、マトリクス型の開発体制を構成するDomain／Squad／Chapterについて、それぞれ詳しく見ていきましょう。 ■Domain（ドメイン） Domainは、BUYMAにおける事業・ユーザーへの提供価値を軸に設定された開発領域です。 各Domainには、エンジニアだけでなく、ディレクター、データアナリスト、デザイナー、ビジネスサイドなど、さまざまな職種のメンバーが所属しています。共通のミッションや事業KPIを持ち、職種を越えて事業課題に向き合いながらプロダクト開発を進めています。 現在は、すべてのDomainがユーザーに直接価値を届ける「ビジネスミッション」を持つ体制への転換を進めています。 そのためエンジニアも、担当する機能を開発するだけではなく、事業KPIやユーザーへの提供価値を意識しながら、プロダクトや事業成果により深く関わることができます。技術だけでなく、事業視点を持ってプロダクト開発に携われることも、Domain体制の特徴です。 BUYMAには現在、以下の3つのDomainがあります。 BUY Domain ミッション：購入者を強力に吸い上げ、集客とCVRを最大化する。 主なカバー範囲：会員登録、商品詳細、購入リスト、レコメンド、クーポン、広告、特集ページ、カート、商品レビューなど。 SELL Domain ミッション：世界中から商品を力強く吸い上げ、品揃えを最大化する。 主なカバー範囲：出品ページ、出品リスト、受注リスト、商品画像、お問い合わせ、タイムセール、ショップ連携など。 SERVICE INFRA (SI) Domain ミッション：決済や安心補償などの機能を提供し、ユーザーへの提供付加価値を最大化する。 主なカバー範囲：決済連携、物流（配送・倉庫連携）、入金関連、セキュリティ関連など。 ※大型キャンペーン対応、商品画像施策など、複数Domain横断のプロジェクトもあります。 ■ Squad（スクワッド） 各Domainは、事業ミッション達成に向けて複数のSquadで構成されています。 Squadは、具体的な事業課題やプロジェクトを軸に組成され、その達成に必要なシステム開発にオーナーシップを持つチームです。 例えば、BUY Domainには「集客・流入Squad」「CVR Squad」、SI Domainには「配送Squad」などがあり、それぞれのテーマに沿って開発を進めています。　　 各Squadにはチームをリードする「Squad Lead」が存在し、要件の設計やタスクへの落とし込み、プロジェクトマネジメントなどを担います。 また、Squadでは設計・開発・テスト・リリースから運用・不具合対応まで、開発ライフサイクルを一貫して担当します。実装して終わりではなく、リリース後のユーザーの反応やデータを見ながら継続的に改善し、プロダクトを育てていけることも、Squadで開発する面白さのひとつです。 ■ Chapter（チャプター）　 Chapterは、特定の専門領域を担当するメンバーが、Domain／Squadを横断して活動するチームです。 メンバーはそれぞれのSquadでプロダクト開発を行いながら、Chapter活動として技術的な改善や基盤整備にも取り組んでいます。 Frontend Chapter ：フロントエンド領域を横断し、プロダクトの品質向上、パフォーマンス改善、計画的なバージョンアップやリファクタリングなどを担当 モバイルアプリ Chapter ：iOS・Androidアプリ開発を担当。各Domainの企画段階から参加し、アプリ領域の開発を横断的にリード QA Chapter ：サービス品質の維持・改善をミッションに、上流工程からプロジェクトに参加。自動テストの導入や本番不具合の分析・対策など、横断的な品質向上を推進 事業やプロダクトに向き合うDomain／Squadでの活動と並行して、専門領域を軸とした技術改善にも取り組めることが、Chapterを設けている特徴です。 プロダクト開発を支えるチーム Domain／Squadでのプロダクト開発を、技術や開発環境の面から横断的に支えるチームもあります。 Application Platform、AI Technology、Infra、DX、DevRelの5つのチームが、それぞれの専門性を活かしながら、ソフトウェア基盤の改善や開発環境の整備、組織づくりなどに取り組んでいます。 Application Platform 各Squadに共通する技術的な課題や、Squad単独では対応しづらい課題を横断的に解決し、開発全体の生産性を高めることをミッションとしています。 具体的には、言語・ライブラリ・フレームワークのバージョンアップ、AWS化に向けたアプリケーション修正、疎結合化・モジュラー化・マイクロサービス化などのアーキテクチャのモダナイズ、サービスの信頼性強化（SRE活動）などに取り組んでいます。 複数のSquadに関わる中長期的な技術課題やアーキテクチャ改善に取り組めることも、このチームの特徴です。 AI Technology AI・データ基盤・機械学習・検索など、データ領域の専門知識が必要となるシステムについて、設計・開発から運用までを担当しています。 データサイエンティスト、検索・MLOpsエンジニア、データエンジニアなどのスペシャリストが所属し、開発初期の設計・開発フェーズからSquadと密接に連携してプロジェクトを進めています。 専門性を活かしながら、AI・データ技術を実際のプロダクト開発につなげていけることも、このチームの特徴です。 Infra インフラ・セキュリティ領域の専門知識が必要となるシステムについて、設計・構築から運用・監視までを担当しています。 BUYMAのオンプレミス環境からAWSへの移行後の運用や、Kubernetesクラスタの構築・運用および開発支援、サービスのセキュリティ強化などに取り組んでいます。 ※以下2つのチームは、専任メンバーでのチーム組成ではなく、他チームのエンジニアが開発業務を兼任して活動しています。プロダクト開発だけでなく、自分たちの手で「開発者体験」や「エンジニア組織の文化」を作っていけるのがエニグモの特徴です。 DX Developer Experience（開発者体験）の略で、開発者体験の維持・向上をミッションとしています。 主にBUYMAのローカル開発環境やCI/CDツールの整備などに取り組んでいます。 DevRel Developer Relationsの略で、社内エンジニアの技術力向上や知識共有、交流促進を目的として、社内LT・勉強会を企画・運営しています。 また、テックブログや対外イベント、カンファレンス協賛などを通じた技術広報にも取り組んでいます。 エンジニア組織の意思決定 ここまで、プロダクト開発を担うチームと、それを支えるチームについて紹介してきました。 複数のチームが連携してプロダクト開発を進めるSE本部では、すべての意思決定を一か所に集約するのではなく、チームを横断して情報共有や組織課題について議論する場を設けています。 ■ Committee SE本部における組織運営や意思決定を担っています。 すべての意思決定を部長一人に集約するのではなく、内容に応じて部長が判断するもの、マネージャーを含めて議論・判断するものを分けながら意思決定を行っています。 また、特定のテーマについては分科会を設け、その領域を担当するエンジニアも議論に参加しています。 役職者だけで組織や技術に関する議論を完結させるのではなく、テーマに応じて現場のエンジニアも意思決定に関われることが、SE本部の組織運営の特徴です。 ■ Squad Weekly 各SquadやChapterの状況共有や、チームを横断するアジェンダについて相談するSE本部の定例ミーティングです。 部内での情報共有や、各チームから上がってきた課題について相談・解決することを目的としています。 必要に応じて、本定例で扱われた内容を部長から役員や他部門長へ共有しています。 チーム単独では解決しづらい課題も、組織全体で素早くフォローアップできる透明性の高い環境を作っています。 エニグモならではの開発環境の魅力 ここまで、SE本部の組織・開発体制について紹介してきました。 エニグモではAIを活用した開発を進めるとともに、特定の技術領域や所属チームにとらわれず、一人ひとりのエンジニアがカバーする領域を広げていくことを目指しています。 ここでは、エニグモが目指すエンジニア像と、実際にどのような挑戦の機会があるのかをご紹介します。 ■ 大規模なグローバルCtoCサービスを開発できる BUYMAは20年以上にわたり運営を続け、1200万超えのユーザーを抱える、グローバル×CtoCの大規模プラットフォームサービスです。 多くのユーザーが利用するサービスだからこそ、安定したサービス運営を続けながら、新たな機能開発や改善を進めていく必要があります。 また、ユーザー数が多いため、施策の効果が数値として現れやすいことも特徴です。 新機能のリリース後には、A/Bテストやデータ分析を通じて成果を検証し、次の改善につなげています。 トラフィック量や扱うデータも大きく、スケーラビリティやパフォーマンスなど、大規模サービスならではの技術課題にも向き合いながら開発を進めています。 長く続くサービスを安定して運営しながら、ユーザーの反応やデータをもとにプロダクトを改善し続ける。こうした開発に携われることも、エンジニアとしての醍醐味です。 ■ AI駆動開発を前提に、フルスタック・フルサイクルへ SE本部では、AIを開発プロセスに取り入れ、AIを活用することを前提とした開発を進めています。 AIの支援によって技術領域を越えて知識を得たり、これまで専門外だった領域の開発に取り組んだりしやすくなったことで、エンジニア一人ひとりがカバーする領域を広げる「知識のフルスタック化」を目指しています。 実際に、バックエンドを主な専門領域としてきたエンジニアがフロントエンドの開発を担当するなど、これまでの専門領域に閉じずに開発を進めるケースも生まれています。 今後は技術領域だけでなく、企画から設計、開発、運用まで、個人やチームがより広い範囲でプロダクトに関わるフルスタック・フルサイクルな開発を進めていきます。 目指しているのは、AIを活用しながら自身の専門性を広げ、単独でもユーザーへの価値提供を進められる「PM兼アーキテクト」として振る舞えるエンジニアを増やしていくことです。 ▼AI駆動開発については、以下の記事で詳しく紹介しています。 「 AI駆動開発とベンチャー回帰で創る次世代エンジニア組織 」 ■ チームや事業を越えて、経験の幅を広げる SE本部では、所属するDomainやチームを固定的なものとはしていません。 組織の状況や本人の希望などに応じて、別のDomainやチームへ異動するケースもあります。 例えば、AI Technologyからアプリケーション開発に関わるチームへ異動したり、アプリケーション開発からApplication Platformへ活動の幅を広げたりするなど、これまでの経験を活かしながら新たな領域に挑戦する機会があります。 また、通常の開発業務と並行して、DXやDevRelの活動を兼務することもできます。 プロダクト開発だけでなく、開発者体験の向上、社内の技術力向上・知識共有、社外への技術発信など、自身の関心に応じてエンジニア組織づくりにも関わることができます。 さらに、BUYMAだけでなく、新規事業やグループ会社のサービス開発にプロジェクトベースで携わるケースもあります。 BUYMA TRAVELをはじめとするグループ会社のサービスや、新規事業のサービス開発・基盤構築を担当するなど、BUYMAにとどまらず、エニグモグループのさまざまなサービス・技術領域に関わる機会があります。 まとめ 今回は、2026年現在のエニグモのエンジニア組織・開発体制についてご紹介しました。 Domain／Squadを中心としたプロダクト開発、専門領域を横断するChapter、そして開発を支える各チームが、それぞれの役割を持ちながら連携して開発を進めています。 また、AI駆動開発を前提に、これまでの専門領域にとらわれずフルスタック・フルサイクルにカバー範囲を広げたり、チームを越えた兼務や異動、新規事業・グループ会社のプロジェクトに携わったりと、エンジニアとしてさまざまな領域に挑戦できる環境があります。 エニグモでは、一人ひとりのエンジニアが自身の専門性を活かしながら、新しい技術や領域にも挑戦し、プロダクトや事業への価値提供の幅を広げていくことを目指しています。 そんなエニグモの開発組織に少しでも興味を持っていただけた方は、ぜひ私たちと一緒に、これからのプロダクトや開発組織をつくっていきませんか？

本ブログでは、 ローンチブログ で紹介した各ユースケースをさらに詳しく掘り下げます。パートナーやお客様が SAP モダナイゼーションプロジェクトにおいて Kiro ベースのサンプルエージェントを使って達成した成果の一部もご紹介します。これらのサンプルエージェントは こちら からダウンロードできます。ローンチブログで取り上げた主なユースケースを振り返ります。 SAP S/4HANA 準拠に向けた ABAP コードのアップグレード クリーンコアに向けた ABAP のリファクタリング SAP PI/PO から SAP BTP へのモダナイゼーション SAP Business Warehouse（BW）から Business Data Cloud（BDC）の SAP Datasphere へのモダナイゼーション 機能仕様書と技術仕様書の生成 単体テストの自動化 本ドキュメントに記載するベンチマークは、すべて AWS の社内開発環境で実施したものです。ベンチマークで使用した Kiro クレジットは、 Kiro Pro サブスクリプションの範囲内に十分収まっています。 1. SAP S/4HANA 準拠に向けた ABAP コードのアップグレード 最初のユースケースは、レガシーなカスタム SAP ECC ABAP コードを SAP S/4HANA に準拠した標準コードに変換することです。数千（あるいは数万）のカスタム ABAP プログラムを持つエンタープライズにとって、このエージェントは最も労働集約的な改修作業を自動化します。コードを変換する前に、エージェントは機能仕様書、技術設計書、単体テストクラスを作成します。変換中には、定義されたエンタープライズ標準に準拠するようコードを改善します。これを実現するため、パフォーマンス標準、コーディング標準、セキュリティ標準、ドキュメント標準、コードの重複回避をカバーする、80を超えるサンプルルールとベストプラクティスを完全に構成可能なセットとして提供しています。変換後、エージェントは単体テストを実行してビジネスロジックの整合性を確認します。 ベンチマーク： AWS の社内ベンチマークでは、88オブジェクト（5,854行のコード）からなる SAP ECC パッケージ全体を4.5時間で完全に SAP S/4HANA 準拠のコードに変換し、生成されたすべての単体テストに合格して、工数を87%削減しました。このベンチマークで使用した Kiro クレジットは377でした。 NTT Data Global Solutions（GSL）は、お客様の SAP S/4HANA への移行を加速するために ABAP エージェントを活用しています。GSL の新しい移行サービス Neo i-KOU! は、ABAP の改修フェーズを最大95%短縮します。製品テストでは、従来は変換に4人月以上を要していた ABAP コードを、わずか0.21人月の工数で変換しました。 2. クリーンコアに向けた ABAP のリファクタリング このユースケースでは、Clean Core Extensibility Model への準拠に向けてカスタム ABAP コードを評価・改修します。このモデルでは、各カスタマイズが SAP S/4HANA のコアシステムの外側にどれだけクリーンに配置されているかに基づき、A から D の等級で評価します。カスタマイズを最高レベルの A と B に保つことで、お客様はカスタムコードを壊すことなく迅速にアップグレードして SAP の新しいコア機能を採用できるため、より速くモダナイズしてコストを削減できます。AWS は、既存の ABAP カスタマイズをこれらの基準に照らして評価し、基準に満たないコードを改修することで、お客様がそこに到達できるよう支援します。 ベンチマーク： 社内ベンチマークでは、エージェントが143オブジェクト（10,200行のコード）にわたって116件の「Extensibility Level D」の ABAP 指摘事項を特定しました。55分の実行時間で、Level D の指摘事項を100%改修しました。エージェントは、非標準のコードを適切な SAP リリース済みオブジェクトに置き換えるか、クリーンコアの原則に従ってそれらを拡張しました。重要な点として、クリーンコアの自動改修は、SAP が標準オブジェクトをリリースしているオブジェクトに限定されます。ほとんどのお客様では、リリース済みオブジェクトが利用できないカスタムコードが一定の割合で存在すると想定しておくべきです。それらのオブジェクトについては、手作業でのレビューと、クリーンコアの選択肢（サイドバイサイドへの変換、現状維持、Fit-to-Standard の採用など）に関する判断が必要です。ベストプラクティスとして、まずエージェントを使ってすべてのカスタムコードを分析し、ABAP オブジェクトごとの現在の Extensibility Level（A、B、C、D）を示すレポートを作成して、自動改修の対象となるものを特定することをお勧めします。 3. SAP PI/PO から SAP BTP Integration Suite への移行 このユースケースでは、SAP PI/PO のインターフェースを SAP Business Technology Platform Integration Suite（BTP IS）に変換することに焦点を当てます。SAP のミドルウェアプラットフォームである SAP PI/PO は、2027年12月に標準メンテナンスの終了を迎えます。お客様は数十から数百のインターフェースを BTP IS に移行する必要があり、単一のインターフェースを手作業で変換するには、その複雑さに応じて数日から数週間かかることがあります。この課題に対処するため、私たちはモダナイゼーションエージェントを開発しました。単一のプロンプトで、エージェントは既存の PI/PO 構成を調査し、機能仕様書と技術設計書を作成し、PI/PO のアーティファクトを BTP 対応の形式に変換し、その結果を BTP IS にデプロイすることで、大幅な時間とコストの削減を実現します。SAP PI/PO の移行に加えて、エージェントは要件定義書から直接、新規の BTP IS インターフェースを開発することもできます。 ベンチマーク： 社内ベンチマークでは、エージェントが22の SAP PI/PO インターフェースを約2時間で SAP BTP Integration Suite に変換しました。これらのインターフェースには25のメッセージマッピングが含まれており、IDOC、SOAP、REST、同期・非同期など、さまざまなインターフェースタイプにまたがっていました。エージェントは、ソースの通信チャネル、アグリーメント、共有関数ライブラリを読み取り、各ターゲットアダプターを決定してマッピングロジックを再現しました。その後、SAP BTP IS のインターフェースを作成し、稼働中のテナントにデプロイし、ソースのルールに照らして単体レベルのデータで各マッピングをテストしました。エージェントは、ルーティング、ファンアウト、マルチキャスト、値マッピング、IDOC セグメントマップ、ステートフルなオーケストレーション（ccBPM）といった複雑な要件にも対応しました。セキュリティ上の理由から、パスワードや証明書などの認証情報は移行しないため、エンドツーエンドのテストの前に手作業のステップが必要です。このベンチマークで使用した Kiro クレジットは約220でした。 4. SAP BW から Datasphere へのモダナイゼーションエージェント このユースケースは、SAP BW のモダナイゼーションを加速し、作業をエンドツーエンドで自動化するものです。エージェントはまず既存のすべての SAP BW のデータパイプラインとデータモデルを読み取り、それぞれについて機能仕様書と技術仕様書を作成し、クラウドネイティブな SAP Datasphere の同等物に変換します。SAP BW Private Cloud Edition（PCE）の道を選ぶお客様は、エージェントを Data Product Generator や Query Template Generator などの SAP ツールと組み合わせて使用できます。 これは、同じ期限を迎えるもう1つのワークロードに対処するものです。数千の企業が利用するエンタープライズデータウェアハウスプラットフォームである SAP BW も、2027年12月に標準メンテナンスの終了を迎えます。SAP はお客様に SAP Datasphere への移行を推奨しており、そこに至る道は2つあります。SAP Datasphere に直接移行するか、まず暫定的なプラットフォームである SAP BW Private Cloud Edition（PCE）に移行するかです。後者の場合、2027年以降も SAP BW を稼働させ続け、自社のペースで Datasphere を採用できます。 SAP BW 向けのエージェントは Kiro Specs 上に構築されたガイド付きワークフローであり、アーキテクトや開発者があらゆるステップで主導権を保てます。データフローを発見し、それらを SAP BDC の Data Products にマッピングし、設計書を作成し、変換済みの Datasphere オブジェクトを生成・デプロイします。その過程で、組織独自のベストプラクティスとデータ戦略が適用されます。 ベンチマーク： 社内ベンチマークでは、このエージェントが販売管理（Sales and Distribution）のコンテンツを含むレガシーな SAP BW 環境を2.2時間で SAP Datasphere に変換しました。SAP BW 環境は Layered Scalable Architecture（LSA++）アーキテクチャに基づいており、32の Data Store Object、13の Transformation、6つの Composite Provider、1,273のフィールドで構成されていました。最終的な SAP Datasphere 環境には、32の Local Table、13の Data Flow、6つの Analytic Model が含まれていました。このベンチマークで使用した Kiro クレジットは856でした。 AWS パートナーである DXC と Kyndryl は、お客様の SAP BDC へのジャーニーを加速するために SAP BW エージェントを活用しています。DXC は、Kiro と Modernization Agents を「DXC Fast BDC」と組み合わせることで、複雑なアセスメントを自動化し、AI を活用したビジネスインサイトを実現し、最短10週間でビジネス価値を提供するデジタルトランスフォーメーションを加速しています。Kyndryl の SAP US Data Lead である Poshan Ponnamreddy 氏は次のように述べています。「 AWS の Modernization Agents、Kiro、そして Kyndryl の Agentic AI Framework の組み合わせは、お客様の SAP モダナイゼーションの期間短縮に貢献しています。AI を活用した変換機能がコードの分析と変換を自動化し、品質を向上させながら手作業の工数を最大80%削減します。これらのイノベーションが一体となって移行の成果を加速し、価値実現までの時間を大幅に短縮します。 」 5. 機能仕様書と技術仕様書の生成 「何十年も前に」書かれたコードにドキュメントがなく、業務の専門家もとうの昔に組織を去ってしまった、という話をよく耳にします。AI を使ってコードを分析しドキュメントを生成することは、SAP ABAP、PI/PO、BW など幅広い SAP プラットフォームで効果が実証されたユースケースです。多くの SAP プロジェクトの最初のステップは、レガシーコードを分析・文書化して、現状（As-Is）の機能仕様と技術仕様を理解することから始まります。 Kiro のサンプルコードを使って構築したモダナイゼーションエージェントは、希望する形式で、かつ自社のドキュメント標準に従ってドキュメントを生成するための機能を提供できます。また、未使用のコードを特定することもでき、不要なコードのモダナイゼーション作業を回避できます。 Toyota Chile は SAP ECC から SAP S/4HANA への移行を進めていますが、数百のレガシー SAP ABAP オブジェクトについてドキュメントや理解が不足していました。シニアソフトウェアエンジニアの Rolando Sabatino 氏は、次のように体験を語っています。「 Kiro と AWS の Modernization Agents for SAP on AWS により、プロジェクトの工数を簡素化・削減できています。Kiro を使って未使用のコードや陳腐化したテーブルを特定し、移行範囲から除外しました。また、ビジネスユーザー向けの機能ドキュメントと開発者向けの技術仕様書も生成しました。ドキュメントは数時間で生成され、数か月分の手作業を回避できました。 」 6. 単体テストの自動化 単体テストは、あまり知られてはいないものの機能を確認するうえで効果の大きいアプローチであり、AI によるコード変換を高精度で信頼性の高いものにしている要因です。コードのモダナイゼーション中の AI のハルシネーションを大幅に最小化するため、結果が信頼できるものになります。ベストプラクティスとして、AWS はモダナイズの前にレガシーコードの単体テストを生成することを推奨しています。これにより、AI エージェントは変換後のコードを検証するための明確な成功基準を得られます。 これがなぜそれほど重要なのか、もう少し詳しく説明します。Kiro や Claude Code などの AI コーディングツールは、よりエージェント的な機能を備えるよう成熟するにつれて、人間の作業方法を模倣するかたちで自律的に反復しながら問題を解決するようになりました。人間がコードを書いてバグを見つけると、バグが解決されるまで分析・編集・再テストのサイクルを続けます。エージェント型ツールはこれと同じループを実行し、問題が修正されたことを確認するために単体テストを使用します。言い換えれば、単体テストは成功がどのようなものかをエージェントに伝え、エラーがなくなるまで分析・編集・再テストを繰り返せるようにします。自動単体テストを組み込んでいることは、私たちのモダナイゼーションエージェントが前述の高品質なベンチマークを達成できた主な理由の1つです。 正確で高品質なコードのためのセーフガード 業界でよく聞かれる正当な懸念の1つが、AI が生成するコードの正確性と品質です。お客様からは「 エンタープライズは、SAP のような最も重要なワークロードにどうすれば自信を持って AI を適用できるのか？ 」と頻繁に質問されます。ABAP ではコードが他の ABAP オブジェクトに格納されたロジックやライブラリを頻繁に参照するため、正確性と品質のリスクが増幅されます。ほとんどの AI コーディングアシスタントは、そうした外部の依存コードを取得できず、それがしばしばハルシネーションの原因となります。AWS は正確性と品質を重視しており、これらのサンプルエージェントに独自のセーフガードを組み込んでいます。 第一に、これらのサンプルエージェントを活用して構築したエージェントは、依存するすべてのコードとライブラリを取り込み、Kiro が完全なコンテキストを持てるようにします。これは、変換時に正確なコードを生成しビジネスロジックを維持するうえで不可欠です。第二に、カスタマイズ可能なステアリングファイルにより、独自のコーディング・パフォーマンス・セキュリティ・ドキュメントの標準を定義できます。サンプルエージェントには、すぐに始められるよう80以上のルールを含むサンプルのステアリングファイルが付属しています。第三に、単体テストに対する独自のアプローチにより、変換前にコードを作成してテストし、変換後にまったく同じビジネスロジックを再テストすることで、品質を大幅に向上させ、時間を節約します。 監査可能性も重要なセーフガードの1つです。これらの Kiro ベースのサンプルエージェントを使って構築したモダナイゼーションエージェントは、会話履歴を保存し意思決定をログに記録できるため、デバッグや微調整に役立ちます。特筆すべきことに、2社のお客様が自社の AI 自動化のアプローチを内部統制チームおよび監査チームとともにレビューしました。予想に反して、監査担当者は意思決定ログの透明性を好みました。それが、ほとんどの従業員が手作業で維持しているドキュメントを上回っていたためです。 これらのエージェントはソフトウェア開発ライフサイクルの多くの部分を自動化しますが、本番環境に移行する前に、お客様が引き続きエンドツーエンドの徹底したテストとビジネス検証を実施することが重要です。 まとめ SAP のモダナイゼーションは、エンタープライズ IT において今なお最も複雑でリソース集約的な取り組みの1つです。サンプルエージェントを共有することで、私たちはお客様とパートナーに、より速く、より手頃なモダナイゼーションへの道を提供することを目指しています。これらのサンプルエージェントは こちら からダウンロードでき、詳細は こちら でご覧いただけます。 本ブログの翻訳は Amazon Quick による自動翻訳を行い、パートナー SA 松本がレビューしました。原文は こちら です。