皆さん、こんにちは。本投稿では、最近日本企業の中で盛り上がりを見せている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アプローチと、Waterfallアプローチにおけるプロジェクトのフェーズについて、そして初心者の方には特に大事にしていただきたいTestフェーズについて解説します。なお、実際のプロジェクトの中で皆様が経験されるものと一部異なる点がある可能性がございますが、本投稿で解説する内容は一般的なケースとしてご参考にして頂ければと思います。
Agenda
想定読者
- SAP導入プロジェクトに初めて参加することになった事業会社、SIer、コンサルティングファームの方
- SAP導入プロジェクトを担当するSIer、コンサルティングファームのポジションへの転職を考えている方
SAP初心者向けの投稿記事まとめはこちら
先にこちらのブログで取り扱っているSAP初心者向けの投稿記事のまとめをこちらでご紹介しておきます。もしご興味がある投稿がありましたら、ぜひ見て頂ければと思います。
SAP導入プロジェクトはWaterfall アプローチが基本
SAP導入に限らず、システム導入のプロジェクトにはアプローチというものが存在します。
アプローチとは、基本的な方針、考え方のことだと思って下さい。
SAP導入プロジェクトでは、基本的には前のフェーズが終わらない限りは次のフェーズに移らない、というWaterfallアプローチを採用します。
Waterfallとは滝のことを指しますが、まさに滝のようなイメージで、上から下に水が流れるように工程が流れていき、水が下から上に流れることが無いように、下から上の工程には戻らないことを意味します。
Waterfallアプローチでは、プロジェクトを複数のフェーズに区切り、前工程のフェーズが終わらない限りは後工程のフェーズに行かない、ということになります。
Waterfallアプローチの特徴はその保守性にあります。
前工程が完全に終わった状態で次の工程に移っていく、ということを基本思想とすることで、次のフェーズで実施しなくてはいけない活動の内容がきれいに整理され、どこからどこまでが作業範囲になるのか、という点を明確にして作業を始めることが可能となります。
また、Waterfallアプローチでは、スケジュールが立てやすい、工数が見積もりやすい、工数が算出しやすい、という点がメリットになります。
いつまでにシステム導入を終えるのか、関係する部署のメンバーの作業工数はどれくらいか、その導入に係る費用はどれくらいか、という点が明確になるという点は、保守的なアプローチを好む日本企業では非常に好まれる方法であり、最近はWaterfall以外のアプローチをとるシステム導入もありますが、いまだにWaterfallアプローチはSAP導入において基本思想となっています。
Waterfall以外のアプローチ：Agileアプローチ
Waterfallが基本であることはお伝えした通りですが、それ以外にもアプローチは存在します。
ここではAgile（アジャイル）アプローチを解説します。
Agileアプローチでは、プロジェクトを細かくSprint（スプリント）と呼ばれるものに区切ります。
そして、各Sprintにおいて、Planning、Design、Build、Testを行い、その結果を用いて次のSprintの計画を行います。
このSprintを複数回実施し、最終化に近づけていくという方針を取ります。
Waterfallでは、Designフェーズの完了時点でシステムに何を実装するのか、という部分について100点満点の答えを出すことが求められました。一方で、Agileアプローチで取り組む各Sprintでは必ずしも100点のモノを作ることを目指しません。
実際に作ってみて、動かしてみて、結果を確認してさらに改良するにはどうすればいいのか、という点をいわば走りながら考えていく、という考えになるわけです。
また、Agileアプローチでは、各種業務領域ごとにどんどんSprintのサイクルを次に進めてよいとする点がWaterfallとの違いとなります。
Waterfallでは、プロジェクトの中に含まれる業務領域やチームの作業がみんなひと段落したら、ようやく次のフェーズに進めるという考えでしたが、Agileアプローチでは、Planningの時点で定義した範囲に従って、「このSprintではここからここまでを実施する」というものが決まっていれば、それがひと段落すればどんどん次に進んでよい、という考えになります。
つまり、チームAとBがあって、AチームのSprintのサイクルが終わったら、Bチームの進捗に関係なく、Aチームは次のSprintのサイクルを初めてもOK、どんどん自分のチームが担当するシステムの領域を改善していってOK、ということを意味します。
Agileアプローチが採用されるのは、そもそもやりたいことが明確に決まっていないとき、ビジネスの状況が頻繁に変わるので実施したいと思っていることが高頻度で変わるとき、等となります。
SAP導入プロジェクトは、システム導入の対象が購買、販売、在庫管理、物流管理、財務会計や管理会計といった基幹業務となるため、企業として何を実施したいのか、という部分が非常にクリアになっているケースが多く、これが歴史的にもWaterfallアプローチが用いられてきた要因となっています。
例えば、CRM、データアナリティクス、BI導入、デジタルマーケティングツールの導入など、戦略的なIT導入になると、なんとなくやりたいことはイメージがあるものの具体化できていない、というケースが多いため、こうしたプロジェクトではAgile アプローチがよく使われます。
WaterfallアプローチにおけるSAP導入プロジェクトのフェーズ
それではここから、Waterfallアプローチを採用しているSAP導入プロジェクトというものがどういった流れで進んでいくのか、SAP導入プロジェクトのフェーズについて解説します。
プロジェクトに途中から入られた方は、今自分がいるのはどこなのか？という点を把握する様にして、そしてこれからどういった活動をしていくことになるのか、という点をイメージできるようになりましょう。
一般的な流れ：構想策定、要件定義/設計、開発、テスト、移行、保守
以下にSAP導入プロジェクトがとる一般的な流れを図解します。
プロジェクトは複数のフェーズと呼ばれる作業の集まりで構成されます。
SAP導入プロジェクトが対象とする業務領域、あるいは導入対象のモジュール（SAPの機能をまとめた単位）によってプロジェクトの長さ、期間は変わりますが、一般的に基幹業務と呼ばれる領域の全てを対象にした場合、合計で14カ月ほどの期間が必要となります。
SAP導入を担当するベンダー、コンサルティングファームの力量や事業会社の情報システム部門の力量によってこの期間は大きく変わりますが、SAP導入プロジェクトは概して1年以上はかかるケースが一般的です。
なお、海外の事例を見たりすると、半年でSAP導入プロジェクトは終えた！という例もありますが、そうしたものは多くの場合、本社が定めたテンプレートを子会社に導入するのみ、という状況になっていて、構想策定、要件定義、設計、開発といったフェーズにかける時間が相対的に少なくなっているケースが多く、これからSAP導入を行うという状況にある場合は少なくとも1年以上はかかることが大半です。
プロジェクトによっては日本語ではなく、英語で各フェーズのことを呼ぶケースも多いので、こうした言葉も覚えておくとよいでしょう。
各フェーズの作業内容概要
それでは、各フェーズにおいて実施する作業内容を大まかに以下にまとめます。
- 構想策定/Planning
- SAP導入プロジェクト全体の計画を作ります。SAPを導入する対象の業務領域、SAP製品の中で使用する機能モジュール、プロジェクトに関わるチームの体制や、各チームがいつ何を実施するのか、という点を明らかにしていきます。
- 要件定義・設計/Design
- SAPを導入する対象業務において、何が出来ることが必要なのか？という点を明らかにしていきます。「こういうことが出来るべき」という内容を要件と呼ぶため要件定義、または設計とも表現します。
- さらに、要件あるいは設計に従って、システム的にはどういったことを実現しないといけないのか、という点を明らかにします。
- 開発/Build
- 前のフェーズで定義した設計にしたがって、SAPのカスタマイズやプログラムの開発を行います。カスタマイズしたもの、開発したものについては簡単な機能のテストも行います。
- テスト/Test
- カスタマイズ、開発した機能がきちんと業務全体を実行できるものかをテストします。開発フェーズでは機能そのものの簡単なテストをしていましたが、ここでは様々な業務について一連の流れをテストします。これが終わることできちんとしたバグのない状況に至ったと判定されます。
- 移行/Migration
- SAP導入をするということは、それまでに使用していたシステムから新しいSAP製品に乗り換えるということになるので、マスターデータやトランザクションデータを旧システムから移すことになります。これを移行と呼びます。
- 保守/Hyper Care
- 移行後、実際に業務が問題なく新しいシステムで実施できるかを継続的に監視し、何か問題があった場合にはすぐに対処できるように保守活動を行います。
こちらでは大まかにプロジェクトの流れを解説させて頂きました。
SAP導入初心者はTestフェーズで勉強しましょう
皆さんがプロジェクトに入るフェーズは、企業ごとに事情がありますので選択することはできません。
ただし、SAP導入初心者の方はTestフェーズの期間を大事にして頂きたいと考えます。その理由は、TestフェーズではSAPという製品の機能、そして企業のオペレーションについて理解するための機会が非常に多く提供され、勉強するチャンスが多いからです。
TestフェーズはSAPを勉強できるチャンス
Testフェーズは、先ほどのセクションで簡単に説明した通り、以下のような作業を実施します。
- テスト/Test
- カスタマイズ、開発した機能がきちんと業務全体を実行できるものかをテストします。開発フェーズでは機能そのものの簡単なテストをしていましたが、ここでは様々な業務について一連の流れをテストします。これが終わることできちんとしたバグのない状況に至ったと判定されます。
Testフェーズでは、そのひとつ前のBuildフェーズで開発したプログラム、SAPに実施したカスタマイズ等が一連の業務を実行できるかをテストするため、実際にSAPに触り、日常の業務プロセスの遂行のために必要となる作業を確認していきます。
その際、どのプログラムを確認すべきなのか、どのカスタマイズを確認すべきなのか、またどのようにSAP上で操作を行えばそれらの確認ができるのか、という内容がTestスクリプト、あるいはTestステップとして整理された状態でTestフェーズは始まります。
Testステップを実行してみて、SAPを勉強する
SAP導入プロジェクト初心者の方は、ぜひこのTestステップを自分で実行してみましょう。
Testステップは誰が見ても、あとで同じことを実行すれば同じTestが実施できるように再現性を求めて作成されますので、これ以上ないほどの教科書的な存在になってくれます。
もちろん、皆さんが特定のチームに所属している場合は、Testフェーズでの作業としては所属チームが開発したプログラムや、実施したカスタマイズの確認のためのTestステップ実行が責任範囲とはなります。
しかしながら、TestフェーズではSAPの実機を触れることが可能で、だれでも、どんなデータでも作って良いチャンスになりますので、ぜひ自分の責任範囲外であってもTestステップを実行し、SAPを用いた業務オペレーションを勉強出来るチャンスととらえて下さい。
念のためですが、その際、他のチームの業務プロセスも把握しておきたいので、他のチームのTestステップを実行させて頂きたい、という点はチームのリーダーやマネージャーには伝えておくことは忘れないようにしてください。
終わりに
本投稿では、SAP導入プロジェクトの基本としてWaterfallアプローチ、そしてAgileアプローチの基本についてお伝えし、SAP導入プロジェクトではWaterfallアプローチが基本であることを解説し、個人的見解も含まれますがTestフェーズはぜひ初心者の方には勉強のチャンスととらえて頂きたいことをお伝えしてきました。 今後も、SAP導入プロジェクトの基本について少しずつ解説をしていきたいと思いますので、ご参考になれば幸いです。