【初心者向けざっくり解説】SAP導入プロジェクトの基本 - 設計/要件定義フェーズの作業内容、成果物【カスタマイズ、開発スケジュール】

皆さん、こんにちは。本投稿では、最近日本企業の中で盛り上がりを見せているSAP導入プロジェクトの基本について解説します。

SAPとは、言わずと知れた基幹業務システムのシェアNo.1のERPパッケージシステムのことで、多くの日本企業においても既に導入されています。

SAPのERPパッケージの最新バージョンはSAP S/4 HANAとなるのですが、ひとつ前のモデルであるSAP ECCは2025年にサポート対応が終了するため、2022年現在、多くの日本企業がすでに導入済みのSAP ECCをS/4 HANAへ移行しようとプロジェクトを企画しています。

SAP導入プロジェクトの必要性が高まっている一方で、過去にSAP ECCを自社企業に導入した人材はすでに定年退職済みというケースも多く、SAPに関する知見を持つ人材が相対的に少ない状況であり、この問題をSAP業界では2025年問題と呼ばれています。

そうした状況下において、事業会社、SIer、コンサルティングファームなどではSAPの知見を持つ方を広く募集しており、SAPの知見を持つ人にとっては高い市場価値を発揮するチャンスとなっています。さらに、現時点ではSAPの知見がなかったとしても業界としては深刻な人材不足であるため、勇気をもってこの領域でキャリア形成を図ろうとする方は大歓迎される状況です。

私の周りでも多くのSAP導入未経験の元エンジニアの方がコンサルティングファームに転職され、SAP導入プロジェクトに関与するようになってきています。

本投稿では、そうしたSAP導入プロジェクトにこれから関わっていくという方向けに、SAP導入プロジェクトの基本知識を提供したいと思います。

今回は、SAP導入プロジェクトの基本アプローチであるWaterfallアプローチおける開発、Buildフェーズにおける作業内容について解説します。開発、Buildフェーズには多くの作業が発生するのですが、本投稿ではカスタマイズ、開発作業スケジュールの作成までを取り扱います。

なお、実際のプロジェクトの中で皆様が経験されるものと一部異なる点がある可能性がございますが、本投稿で解説する内容は一般的なケースとしてご参考にして頂ければと思います。

Agenda

想定読者

SAP導入プロジェクトに初めて参加することになった事業会社、SIer、コンサルティングファームの方
SAP導入プロジェクトを担当するSIer、コンサルティングファームのポジションへの転職を考えている方

SAP初心者向けの投稿記事まとめはこちら

先にこちらのブログで取り扱っているSAP初心者向けの投稿記事のまとめをこちらでご紹介しておきます。もしご興味がある投稿がありましたら、ぜひ見て頂ければと思います。

: 【初心者向けざっくり解説】SAP導入プロジェクトの基本 - 投稿記事まとめ【基本知識、各フェーズの作業内容・成果物、勉強方法】

開発/Buildフェーズの作業内容、成果物

SAP導入プロジェクトの設計/Designフェーズが終わったら、開発/Buildフェーズが始まります。

ここでは、設計/Designフェーズの最後に実施した、開発に対する承認取得において、承認が得られた開発オブジェクトを実際に開発していきます。

想定読者である皆様はプロセス/Processチームに所属しているわけですが、この開発/Buildフェーズでは開発者のチームと協力しながら業務要件を実装するプログラムを作り込んでいきます。

SAP標準機能で対応が出来る業務要件については開発者に作業をしてもらうことにはならず、皆様ご自身の手でSAPに対してカスタマイズを行い、標準機能を業務要件に合わせていくことになります。

開発/Buildフェーズで実施する作業と、このフェーズで作成する成果物は以下の通りとなります。

実施する作業

カスタマイズ、開発作業スケジュールの作成
カスタマイズ設計（CSの作成）
カスタマイズの実施
カスタマイズテストの実施（CuTの作成）
承認済み開発オブジェクトに対する機能設計（FSの作成）
開発チームとの機能設計図書の内容確認
開発チームによる詳細設計（TSの作成）
開発実施、単体テストの実施（TuT、FuTの作成）
結合、統合テストケースの作成

成果物

カスタマイズ一覧
カスタマイズ設計書図書（CS：Configuration Specification）
単体カスタマイズテスト結果（CuT：Configuration Unit Test）
機能設計図書（FS：Functional Specification）
詳細設計図書（TS：Technical Specification）
単体詳細テスト結果（TuT：Technical Unit Test）
単体機能テスト結果（FuT：Functional Unit Test）
WRICEFリスト（更新）
結合テストケース、統合テストケース

馴染みのない用語がいくつか出てきたと思いますが、あとでしっかり解説していきます。

本投稿では、以下を対象に解説していきます。

カスタマイズ、開発作業スケジュールの作成

カスタマイズ、プログラム開発とV字モデル開発

まずBuildフェーズの作業の内容をそれぞれ開設する前に、Designフェーズで作成した要件一覧が、どのようにBuildフェーズで対処されていくのかをご紹介します。

要件一覧に記載されている要件は、大きく2つの対処法を取ります。一つは標準機能で対処するもの、すなわちFit＆Gapを実施した結果、Fitと判定されているもので、もう一つはGapと判定され、開発を行うということになりWRICEF一覧が作成されているものです。

標準機能で対処することになっている要件は、BuildフェーズではSAP標準機能をカスタマイズすることで要件を実装します。後述しますが、このときにCS、CuTというドキュメントを作成します。

一方で、プログラム開発を行う対象であるWRICEF一覧については、当然ながらプログラム開発を行うことで対処し、このときにFS、TS、TuT、FuTというドキュメントを作成します。

次に、V字モデルというものをご紹介します。カスタマイズを行う場合のモデルと、プログラム開発を行う場合のモデルがありますが、基本的な見た目は同じだということがお分かりになるかと思います。

V字モデルというのは、システム開発プロジェクトにおいて、開発作業の出発点である要件定義から最終的に行われる受入テストまでの流れを図としてまとめたものです。

V字モデルに含まれる要素を簡単に解説すると、以下のようになります。

要件定義
- システム導入を通じて実現したいこと（＝要件）を定義します

カスタマイズ設計
- 要件を実装するためにどのようにカスタマイズを行うかを文書にまとめます。このときに作成する文書をカスタマイズ設計図書（CS：Configuration Specification）と呼びます
- カスタマイズ設計図書に、カスタマイズが完了したらどういったテストを行うかといった内容も記述しておきます

カスタマイズ
- カスタマイズ設計図書を基に、SAPに対してカスタマイズを実施します

カスタマイズテスト
- カスタマイズした内容をテストして、カスタマイズ設計図書で記述した通りに動くかを確認します。このとき、テストの結果をまとめたものをカスタマイズテスト結果（CuT：Configuration Unit Test）と呼びます

機能設計
- 要件をどのようにシステムとして実装するかを文書にまとめます。このときに作成する文書を機能設計図書（FS：Functional Specification）と呼びます
- 機能設計図書に、開発が完了したらどういったテストを行うかといった内容も記述しておきます

詳細設計
- 機能設計図書を基に、より詳細にプログラムとしてはどういった実装を行うかを文書にまとめます。このときに作成する文書を詳細設計図書（TS：Technical Specification）と呼びます
- 詳細設計図書に、開発が完了したらどういったテストを行うかといった内容も記述しておきます

開発
- 詳細設計図書を基にプログラムを開発します

詳細設計テスト（単体詳細テスト）
- 出来上がったプログラムをテストして、詳細設計図書で記述した内容通りに動作するかを検証します。プログラム単体のテストであるため、単体詳細テストとも呼ばれます。このとき、テストの結果を文書にまとめたものを単体詳細テスト結果（TuT：Technical Unit Test）と呼びます

機能設計テスト（単体機能テスト）
- 出来上がったプログラムをテストして、機能設計図書で記述した内容通りに動作するかを検証します。プログラム単体のテストであるため、単体機能テストとも呼ばれます。このとき、テストの結果を文書にまとめたものを単体機能テスト結果（FuT：Functional Unit Test）と呼びます

結合、統合、受入テスト
- プログラムが複数出来上がったら、今度はプログラム単体ではなく、一連の業務プロセスが動くかどうかをテストし、もともと定義していた要件が実装されているかを確認します

これらが要件定義から一連の業務プロセスのテストまでの流れなのですが、その中で要件定義した内容は結合、統合、受入テストで検証され、機能設計の内容は機能設計テストで検証され、そして詳細設計の内容は詳細設計テストで検証をされていくということがお分かりになると思います。

このように、単純に1つの方向に作業を進めていくのではなく、カスタマイズテスト、詳細設計テスト、機能設計テスト、結合、統合、受入テストがそれぞれテスト実施前に整理されたカスタマイズ設計、詳細設計、機能設計、そして要件を検証するという意味を持つ、ということを図としてあらわしたのがＶ字モデルというわけです。

企業やプロジェクトによっては、Ｖ字モデルに含まれる内容に差異があるケースもありますので、こちらはあくまで一例とお考え下さい。

カスタマイズ、開発作業スケジュールの作成

Ｖ字モデルについて解説が終わったところで、Buildフェーズの最初の作業である、カスタマイズ、開発作業スケジュールの作成について解説します。

まずはカスタマイズのスケジュールからです。

Designフェーズで作成した要件一覧のなかで、Fit＆Gapを実施した結果、Fitとされているものは標準機能をカスタマイズして対処するものになるので、これらに対してカスタマイズのスケジュールを作成していきます。

最初に、要件一覧から情報を抜き出す形でカスタマイズ一覧を作ります。このとき、要件と基本的には1対1でカスタマイズを一覧にしていくのですが、一つのカスタマイズであるように見えても、SAP側では複数の箇所に対してカスタマイズを行う必要があるもの、というものがよくあります。

カスタマイズ一覧では、抜け漏れを防ぐために一覧にしたカスタマイズ情報に対して、具体的にはSAPのどの部分をカスタマイズするのか、という内容も記述する様にしましょう。ちょっとイメージがわきにくいかと思いますので、追加補足します。

この例では、要件はたった一つ、「物品の購入とサービスの購入を分けて管理できるようにしたい」というものです。これをSAPに対するカスタマイズで実現しようとすると、4つほどカスタマイズを行う必要があるのです。（実際にはもっとあるかもしれませんがいったん4つとさせて頂きます。）

まずは物品の購入とサービスの購入に使用される発注伝票に対して、異なる伝票タイプを作ろう、ということで「Define Document Type」、そして次に購買活動を行う拠点（Plant、購買組織：Purchasing Organization）で使用できるようにするための「Assign Document Type」、そしてそれぞれの伝票が異なる伝票番号を持つようにするために「Define Number Range」で異なる番号範囲設定を行い、最後に「Assign Number Range」で新規作成した番号範囲を、つい先ほど作成した伝票タイプに割り当てる、という流れになります。

これはSAP導入の経験がないと整理が難しい部分もありますが、まずはここまで整理しておくと後で抜け漏れがなくなるので便利、という風に考えておいてください。

次は開発スケジュールの作成です。

Designフェーズの最後に、WRICEF一覧という成果物を作成しました。このリストには、開発を行う対象が一覧化されています。このリスト上にさらに日付を追加するようなイメー時で、各オブジェクトに対する作業スケジュールを決めます。

ここまででカスタマイズスケジュール、開発スケジュールの作り方の概要を説明してきました。

作業スケジュールを組むときに考える必要がある作業とは、V字モデルの部分でBuildフェーズの作業として説明している内容が基本的な内容となるのですが、文書を作成したら、それに対するレビューが発生するという点に注意しましょう。

すなわち、とある担当者がカスタマイズ設計図書や機能設計図書を作成完了したからと言って、そのまま次のステップとしてカスタマイズ実施や詳細設計図書の作成といった後続の作業をスタートすることは出来ません、ということです。

きちんと、作成したドキュメントは要件を定義した方が責任をもってレビューをすることになります。カスタマイズ、開発スケジュールを作成する際は、文書の作成完了日に加えて、レビュー完了日も決めるようにしましょう。

このとき、あらかじめプロジェクトの方針として1つの文書に対するレビューは5営業日で終える、というようなことが決まっているのであれば、そうした数字をスケジュール作成の際に活用しましょう。

また、開発スケジュールを作成する際には、開発難易度の考慮も必要です。WRICEF一覧を作成する際に、あらかじめ難易度を整理しておいて、それを使用して機能設計、詳細設計、開発作業にどの程度の時間を要するのか、という点を見積もります。

こちらも、あらかじめ開発難易度：Highのものはこれくらい時間がかかる、という情報を整理していれば、それを活用しましょう。

他機能、検討事項との関連性の考慮について

開発作業スケジュールを作成する際は、WRICEF一覧上の開発対象オブジェクトについてスケジュールを作成していくわけですが、その時に考慮したいのが他機能、検討事項との関連性です。

すなわち、何を先に開発したほうがいいのか、という点を考えることです。

例えば、とあるプログラムが別のプログラムによって処理された情報を用いるといった関係性がある場合は、前工程のプログラムの仕様が決まってから、後続のプログラムの仕様を設計したほうが手戻りは少なくなりますよね。

プログラム間の関係性まではまだ見えていないという場合であっても、基本的には業務の流れというものに沿って、前工程に関係するプログラムやカスタマイズから先に実施していくということが基本の考えとなります。カスタマイズに関していうと、業務の流れの前に、そもそもどういった拠点、組織があるのか、という点が整理される必要があるので、最初に取り掛かるカスタマイズは組織構造（Enterprise Structure）となることが一般的です。