Amazon Web Services ブログ

スペックファースト: SAP ABAP のスペック駆動開発

AI コーディングエージェントは数分で ABAP を生成できますが、スペック（仕様）がなければ、次の開発者にはなぜそのようにコードが作られたのかという記録が残りません。現在、多くの ABAP チームは SAP ABAP コードの作成やモダナイゼーションにバイブコーディングを用いています。結果は早く得られますが、コードの背後にある開発上の判断は失われ、要件が変わったときの修正が難しくなります。

SAP ERP Central Component (ECC) を今も運用しているお客様の SAP ABAP チームは、RISE with SAP へのアップグレードに先立ち、カスタムコードをレビューしてモダナイゼーションするようますます強く求められています。ABAP コードは、それを書いた開発者が別の役割に移った後も長く残り続け、ドキュメントは存在しないか古くなっています。ABAP のモダナイゼーションに同じバイブコーディングのアプローチを取ると、何をなぜ変更したのかの記録がないまま、ドキュメント化されていないコードがさらに増えていきます。

本記事では、ABAP におけるスペック駆動開発 (SDD) の仕組み、良い ABAP スペックに含めるべき内容、そしてトランスポートのリリース後もスペックが役立ち続ける方法を紹介します。例では AWS Coding Plugin for SAP ABAP を使用します。これは、AWS のエージェント型開発環境である Kiro のコマンドラインインターフェース Kiro CLI 上で動作します。プラグインの機能とインストール方法については、AWS Coding Plugin for SAP ABAP, powered by Kiro のご紹介 を参照してください。

バイブコーディングの問題点

バイブコーディングを使えば素早く開発できますが、複雑な要件や大規模な ABAP コードベースでは、コンテキストが失われ、判断がドキュメント化されないまま残るため、開発チームは苦労します。コンテキストウィンドウには上限があり、50 メッセージ前に AI コーディングエージェントに伝えたビジネスルールが、気付かないうちに対象外になってしまうことがあります。会話が長くなるにつれ、エージェントは当初の意図を解釈し直し始め、やり取りのたびに方向がずれていきます。コードはコンパイルされ有効化もされますが、意図したとおりには動作しません。

その結果、正しく見えても実際の業務シナリオでは失敗するコードが生まれます。そして次の開発者がそのプログラムを引き継いだとき、スペックも設計上の根拠もなく、あるのはコードとトランスポートの説明だけです。開発者はまた、コンテキストを理解するためにプログラムを 1 行ずつ読み解くことになります。

スペック駆動開発とは

スペック駆動開発は、ワークフローの中心に仕様を据えます。ABAP コードを生成する前に、要件、システム設計、実装上の判断を定義します。主要な判断が明示的に記録されるため、複雑な要件にも少ない反復で取り組みやすくなり、何をなぜ作ったのかという明確な記録が残ります。要件が変わったときは、スペックを更新して ABAP コードを再生成します。

Understanding Spec-Driven-Development: Kiro, spec-kit, and Tessl の中で、Birgitta Böckeler は SDD の 3 つのレベルを説明しています。

  • Spec-first（スペックファースト）: コードを生成する前にスペックを書きます。ABAP 開発者にとっては機能仕様書として馴染みのあるステップです。
  • Spec-anchored（スペックアンカー）: 作業完了後もスペックを保持し、以降の変更に利用します。
  • Spec-as-source（スペック・アズ・ソース）: スペックのみを編集し、生成されたコードには一切手を加えません。

SDD が ABAP 開発に適しているのは、スペックがすべてのセッションの開始時に読み込まれ、コンテキスト内に保持され続けるためです。スペックは平易な言葉で書かれるため、AI コーディングエージェントが 1 行のコードを書く前に、機能コンサルタントや新しい開発者がレビューできます。エージェントは双方が合意したタスク定義に基づいて作業し、その定義は会話全体を通じて維持されます。

AWS Coding Plugin for SAP ABAP は、要件・設計・タスクを記録する 3 つの Markdown (.md) ファイルによって、ABAP にスペック駆動開発をもたらします。

ABAP スペックに含めるべき内容

良い ABAP スペックは、シニア開発者が作業を始める前に確認する質問に答えるものです。レポート、クラス、汎用モジュール、Business Add-In (BAdI) 実装といったオブジェクトタイプを明記します。入力と出力、ビジネスルールを列挙し、データが欠落している場合や呼び出しが失敗した場合に何が起こるかを記述します。

スペックには、エージェントがビジネス要件から推測できない SAP 上の判断を明記します。これらを未定義のままにすると、エージェントはコンパイルは通るものの要件に合わないものを選んでしまいます。スペックでは、BAdI、ユーザーエグジット、新規プログラムのいずれであるかといった拡張手法を明記すべきです。

スペックには、そのタスク固有の事項を記録します。命名規則、承認済みライブラリ、再利用可能なスキルといったチーム全体の標準は、エージェントが自動的に読み込むステアリングファイルに置きます。

次の例は、ABAP レポートの例における要件ファイルの一部です。

Requirements:

Program type:
Report (executable program)

User story:
As a sales back-office clerk, I want to see open sales orders that are past their requested delivery date, grouped by age, so that I can follow up with the customers.

Input:
Sales organization (required), customer (optional), order date range (optional)

Output:
ALV list using CL_SALV_TABLE (no REUSE_ALV function modules or classic lists), grouped by overdue aging buckets (30 days or less, 31 to 90 days, more than 90 days)

Acceptance criteria:
1. The selection screen requires a sales organization and accepts an optional customer and order date range.
2. The report runs an AUTHORITY-CHECK for the sales organization before it reads any data.
3. Orders are grouped as 30 days or less, 31 to 90 days, and more than 90 days overdue.
4. If no orders match, the report shows an information message and doesn’t display an empty list.
5. Database access uses Open SQL with host variables escaped by @. No SELECT *.
6. After each successful BAPI call, commit with BAPI_TRANSACTION_COMMIT.
7. Exceptions use CX_ROOT subclasses. No MESSAGE statements in methods.
8. ABAP Unit tests cover the grouping logic and use test doubles for database access.

スペックからトランスポートのリリースまで

ABAP の観点で見たスペックからトランスポートのリリースまでの道のりは、AI-Driven Development Lifecycle (AI-DLC) に沿って進みます。AI-DLC は、次の図に示すように、AI ネイティブな開発を Inception（開始）、Construction（構築）、Operations（運用）の 3 つのフェーズに構造化する方法論です。

3 つのフェーズを示すワークフロー図。Inception では開発者とエージェントが要件・設計・タスクを起案して承認し、Construction ではエージェントがコードを生成・有効化し、ATC と ABAP Unit を実行して合格するまで繰り返し、Operations では開発者がトランスポートを本番環境にインポートしてスペックを Git にコミットする。

AWS Coding Plugin for SAP ABAP では、各フェーズは次のように進みます。

  1. Inception（開始）: エージェントはセッション開始時にステアリングファイルを読み込み、スペックを起案する前にチームの標準、ベストプラクティス、承認済みライブラリを適用します。開発者とエージェントが協力して要件を定義し、設計について合意します。エージェントは重複を避け確立されたパターンに従うため、ABAP リポジトリから関連オブジェクトを検索します。そのうえで、考慮すべきエッジケースを提案します。開発者はその結果を検証し、ビジネス上のコンテキストを提供します。エージェントがスペックを起案し、開発者がそれを修正・承認します。承認前にコードが書かれることはありません。
  2. Construction（構築）: エージェントは ABAP コードを書いて有効化し、ベースラインに対して ABAP Test Cockpit (ATC) チェックを実行します。また、新規および既存の ABAP Unit テストの両方を実行します。すべてのチェックに合格するまでこのループを繰り返します。その後、オブジェクト間の問題を検出するためにトランスポート全体を一括で有効化し、トランスポートの長いテキストを作成します。エージェントは、SAP 開発システム上で開発者の SAP ユーザーの権限で動作します。開発者はコードをレビューし、結果がスペックと一致していることを確認します。「すべてのチェックに合格」はレビューの終わりではなく、始まりとして捉えてください。
  3. Operations（運用）: トランスポートを本番環境にインポートします。スペックを Git リポジトリにコミットすることもでき、各変更の背後にある意図を保存できます。要件が変わったり不具合が見つかったりすると、サイクルは Inception に戻ります。各イテレーションは既存のスペックから始まります。

このワークフローで生成されたコードに問題がある場合は、失敗の種類に注目してください。構文エラー、有効化エラー、テストの失敗は、Construction フェーズでエージェントが修正すべきものです。コードが有効化されすべてのテストに合格しているのに誤った結果を出す場合、問題はスペックにある可能性が高いでしょう。
修正するには、スペックで期待する結果をより具体的にする、テストケースを追加する、またはシステム内ですでに正しく動作している類似コードをエージェントに示します。エージェントが誤った BAPI やクラスを選ぶ場合は、正しいものをスペックに明記します。
エージェントが何度も間違える BAPI のように、このタスク以外にも当てはまる修正をスペックに加えた場合は、それをステアリングファイルに移します。次のスペックは、その教訓をあらかじめ組み込んだ状態から始まります。

新規コードと既存コード

新規開発の場合、進め方はシンプルです。スペックを書き、コードを生成し、検証してテストします。

ABAP の作業では、SAP S/4HANA に向けたコードのモダナイゼーション、SAP クリーンコア原則への準拠、新しいビジネス要件への対応など、既存コードの変更が伴うことがよくあります。
こうした変更では、まずエージェントにプログラムの現在の処理内容を要約させ、その要約をスペックの土台にします。次に、変更しない部分も含めて、目指す最終状態の全体像を記述します。差分だけを扱うスペックでは、それ以外のすべてについてエージェントが推測することになります。ビルド後は、既存機能が引き続き期待どおりに動作することを確認します。

このアプローチに従うと、ドキュメント化されていなかったプログラムが、変更を重ねるごとに徐々にスペックを獲得していきます。変更のたびにスペックが追記され、数回のイテレーションを経ると、以前は存在しなかった最新のドキュメントがプログラムに備わります。

ステアリング: すべてのスペックの背後にある標準

どのチームにも、ABAP オブジェクトの命名規則、出力パターン、トランスポートの説明など、ABAP 開発全体に適用される標準があります。これらの標準は、エージェントがすべてのセッションの開始時に読み込む Markdown ファイルであるステアリングファイルに含めるべきです。AWS Coding Plugin for SAP ABAP は、接続された SAP システムごとにステアリングファイルを作成します。一般的なステアリングファイルには、次のような標準が含まれます。

ABAP development standards

- Report naming conventions: Z<module>_<description>, for example, ZFI_, ZSD_, ZMM_
- ALV output: CL_SALV_TABLE only, no classic list output
- Exceptions: CX_ROOT or a subclass, errors logged to the application log (SLG1)
- Database access: Open SQL only, host variables escaped with @, no SELECT *
- Testing: 80% coverage for business logic, test doubles for database access
- Transport description: [TICKET-ID] Brief description

スペックはタスク固有の事項に使い、ステアリングでは従うべき標準をエージェントに示すようにしてください。

組織で多数の ABAP プロジェクトを運用している場合、ステアリングファイルとスペックテンプレートは再利用可能な資産になります。あるプロジェクト向けに作成したクリーンコアのステアリングファイルが、次のプロジェクトの出発点になります。

早速始めましょう

AWS Coding Plugin for SAP ABAP のインストールについては、開発者ドキュメントを参照してください。セットアップが完了したら、小さなタスクでスペック駆動開発を試してみましょう。

  1. Eclipse ADT 環境からサンドボックスの SAP システムに接続します。
  2. 期待される結果がすでに分かっている、単純なレポートを選びます。
  3. エージェントと一緒にスペックを書き、コードが生成される前に承認します。
  4. 完成したスペックを Git にコミットします。そのレポートに次の変更要求が来たら、スペックから始めます。

SAP S/4HANA 上の完全な ABAP アプリケーションに AI-DLC を適用したステップバイステップの例については、AI-DLC（AI 駆動開発ライフサイクル）による SAP ABAP アプリケーション開発 を参照してください。

まとめ

本記事では、スペック駆動開発によって AI が生成した ABAP コードの背後にある根拠をどのように保持できるかを紹介しました。エージェントがコードを生成する前に、要件・設計・タスクを書きます。共通の標準はステアリングファイルに保持し、スペックはチャットセッション終了後も残るため、何をなぜ作ったのかという明確な記録になります。次の変更要求で、AWS Coding Plugin for SAP ABAP を使ってぜひ試してみてください。スペック駆動の ABAP 開発についてのご経験を、ぜひコメントでお聞かせください。

AWS Coding Plugin for SAP ABAP は無料でご利用いただけます。Kiro CLI のサブスクリプションが必要で、無料枠（50 クレジット）から始められます。より大きな容量が必要な場合の有料プランは、月額 20 ドルの Pro から月額 200 ドルの Power まであります。詳細は Kiro の料金を参照してください。

著者について

Stephan Kremer は AWS のシニア SAP スペシャリストソリューションアーキテクトです。SAP のお客様とともに ABAP のモダナイゼーションやクラウド移行に取り組んでいます。

Adren D Souza は AWS のシニア SAP パートナーソリューションアーキテクトです。グローバルシステムインテグレーター (GSI) とともに、AWS 上での SAP の移行とモダナイゼーションに取り組んでいます。

本ブログの翻訳は Amazon Quick による自動翻訳を行い、パートナー SA 松本がレビューしました。原文はこちらです。