今回は、SAP S/4HANA導入におけるアドオン開発の進め方と、設計や開発を進める上での品質管理についてまとめます。
昨今では、クリーンコア（Clean Core）戦略のもと、「アドオン開発は極力実施しない」「どうしても開発が必要な場合はERPの外部で実施する」という方法論でF2S（Fit to Standard）を推進する向きもありますが、導入や保守・運用の現場においては未だ重要なテーマだと考えています。

1.はじめに

SAP S/4HANAの導入に際し、アドオン開発は未だ重要なテーマだと記載しましたが、アドオンとは、導入企業の要件に沿って作成された機能を指します。その種類としては、帳票、外部システムとのインターフェース、伝票のチェック処理など、必要に応じて様々な手法で作成されたオブジェクトが存在し、業務改善につながるツールや機能として活躍しています。

アドオン機能を作る上で「不具合の無い開発成果物を作成すること」は最重要な事ですが、当社では、「レスポンスが良い」「操作が理解しやすい」「保守がしやすい」といった、お客様の視点を考慮した開発を行っています。

アドオン機能の開発をどのように進めていくのか、また、品質の担保はどのように行うのかという内容についてご説明します。

2.アドオン開発における各種定義書について

アドオン開発はウォーターフォールモデルに沿った開発手法で進める事が多く、大まかに「コンサルタントによる要件確認」「設計者による要件から処理へ落とし込む設計作業」「開発者によるコーディング作業（実装作業）」「テストの実施」という流れになります。

当然ながら、各立場の担当者が品質良く管理しやすい成果物（設計書、プログラムなどの開発オブジェクト）の作成を行うことが重要となります。
そのためには、ルールに沿って、且つ同じレベルの品質で作成していくためのガイドブックとなる定義書が必要となります。定義書とは、「設計ガイド」「開発規約」「テスト方針書」などと呼ばれるドキュメントです。

1つ目の「設計ガイド」は、設計作業を行うためのガイドブックであり、アドオン開発方針が決まった後で必ず用意すべき資料です。このガイドブックは、プロジェクトに従事するコンサルタント、設計者および開発者がそのプロジェクトにおけるアドオン設計思想を共有するための重要なドキュメントです。
設計ガイドには、「選択画面の画面構成の定義」や「帳票内容の基本構成の定義」、「インターフェース方針に対して、具体的な設計方針の定義」、必要に応じて、「使用するERPパッケージを用いた設計思想」や、「使用する共通部品・ツールを用いた設計ルール」、「特定のプロジェクトにおける特別な設計ルール」などが記されています。
設計ガイドをもとに設計書を作成することで、結果的には、「操作が理解しやすい」「保守がしやすい」とったことに結びつきます。

2つ目は「開発規約」です。「開発ガイド」同様、コーディング作業における、ガイドブックの位置づけです。「開発規約」では、「オブジェクトの命名規約（変数、定数などに対して、接頭辞または接尾辞で統一したIDの命名で管理）」「テキストコメントの記載ルール」「サブルーチン化した処理をコーディング方法の奨励」などが定義されています。
以前、開発規約を用意する目的について、一緒に開発作業に従事していた若手の開発者から、「開発規約に命名規約以外にも細かいことが定義されているのは何故か」と聞かれたことがあります。私は、「どの機能も同じルールのもとで作成でき、且つルールがあることで同じ品質で作成できるから」と考えています。
設計書や開発オブジェクトは本番稼働後には作成者の手を離れ、保守の担当者が管理していくことになります。その方々が管理しやすくするためにも、1つ目の設計ガイドの定義とともに、開発規約を基にした開発オブジェクトの作成も重要であり、規約に則って開発を行うことが「レスポンスが良い」ということにも結びつきます。

3つ目は「テスト方針書」です。テスト方針書とは、作成した開発オブジェクトが、不具合を引き起こさないようにするために実施するテストでの、決まりをまとめたドキュメントです。内容については、「テストパターンの洗い出し方」「テスト実施におけるテストデータの利用方法」などが定義されています。プロジェクトによっては、「テスト実施結果のエビデンスとしてのスクリーンショットの貼り方」など、細かい条件が定義された方針書もあります。
テスト方針書については、前述の２つの定義書同様にコンサルタント、設計者、開発者といったアドオン開発に関わる担当者が熟知している必要があります。テスト方針書の記述例をいくつか提示すると、単体テストであれば、「設計書をもとに、処理分岐におけるテストは全て行ってテストケースとして洗い出しておくこと」、「テストデータにおける確認は1件のみではなく、複数データによる確認を行うこと」、「実行した際の時間分析によるレスポンスの確認を行うこと」といった定義がされています。
テスト方針書通りに「テストケースの洗い出し」、「テストデータの作成」、「テストの実施」を進めることにより、不具合の検知および開発オブジェクトの品質担保ができることになります。
また、テスト方針書は導入先のお客様にも確認していただき、この内容を合意することによりお客様から安心感を得るものになります。

以上、3つの定義書について解説しましたが、設計作業、開発作業、テストを行う上では、定義書に対して各担当者がどの程度理解できているか、または、どの程度遵守できているかも確認する必要があります。

3.設計、開発を進める上で必要な品質管理について

「設計作業」、「開発作業」、「テスト」を行うにあたり、各定義書を用意する以外にも、対応するコンサルタント、設計者、開発者がそれらを理解して対応できているか、または確認漏れがないかを点検するプロセスや対策を用意しています。

インスペクションシートによる対策

インスペクションシートとは、各定義書をもとに作成した設計書や開発オブジェクトに対し、定義書を遵守した対応ができているかを確認するためのセルフチェックシートです。
セルフチェックシートを確認することは担当者に「気づき」を与え、作成した設計書や開発オブジェクトに対する点検を促すことになります。

ATC（ABAP Test Cockpit）チェックによる対策

ATCは、SAP社が提供する開発オブジェクトのチェックツールです。開発規約の命名規約に準じた開発がされているか、レスポンスを考慮した対応ができているかといった観点で、機械的なチェックを行うことが可能です。
当社では開発作業時にはインスペクションシートと併せて、ATCによる開発オブジェクトのチェックを行うようにしています。

レビュー実施と定量的な品質管理による対策

インスペクションシートによる自己の振り返り、ATCによる機械的なチェックを行う他に、第三者によるレビューも行っています。レビュアーと呼ばれる品質管理者をプロジェクトに参画させ、アドオン開発する機能毎に設計書、開発オブジェクト、テストケース、テスト実施結果を目検によりチェックします。レビューの実施結果はレビュアーから各担当者に提示され、その後修正などの対応を実施します。
尚、レビューが正しく行われているかについても確認を実施しています。レビュー結果から、レビュー実施時間（作業工数密度）やレビューで発覚した指摘事項の件数（欠陥密度）について、過去の同様の案件で対応した際の指標値をもとにゾーン分析を行い、レビューの実施結果の評価を行うという方法です。
これにより、レビュアーに対して実施状況の確認を行うだけでなく、設計者や開発者の品質遵守の状況を確認することができ、問題があればプロジェクトの管理者から注意喚起を行います。

以上の3つの対策により、アドオン機能を作る上で重要なポイントが守られているか、確認しています。

おわりに

SAP S/4HANA導入において、お客様の要件にどうしても標準機能では対応できない場合、アドオン開発が必要となります。
しかしながら、開発には様々な手間がかかるため、難しい面もあります。対策として、開発プロセスの明確化、各定義書の準備、品質管理を整えることが重要です。

当社では、前述のとおり、開発プロセス、各定義書の準備、品質管理についての知見や経験があります。SAPシステムの導入や運用保守でお困りの際は、ぜひご相談ください。