【初心者向けざっくり解説】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アプローチおける構想策定、Planningフェーズにおける作業内容について解説します。Planningフェーズには多くの作業が発生するのですが、本投稿ではプロジェクトにおける進捗管理、成果物管理、そして変更管理の方針決定までを取り扱います。

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

想定読者

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

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

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

進捗管理、成果物管理、変更管理の方法を決める

プロジェクトの進捗、成果物、そして変更内容をどのように管理するのか、という方針を整理します。

進捗管理

まずは進捗管理から見ていきましょう。

進捗管理の方法としては、WBS(Work Breakdown Structure)を作成し、各作業の状況を可視化することが一般的です。

WBSでは、プロジェクト内の作業を一覧にして、作業開始予定日、作業完了予定日をあらかじめ定めます。そして、作業の担当チームから進捗状況を週次などのペースで確認することで、プロジェクト内のあらかじめ決めておいた作業予定に遅れが出ているかいないか、または予定よりも先に進んでいるところがあるならばそれはどこか、という点を明らかにします。

このような進捗管理ですが、どのようなサイクルで回していくのか、という点も基本となるルールを整理します。

以下にサンプルを記載しますが、例えば毎週PMOがプロジェクト全体の進捗状況を確認し、報告会を行い、関係者全員で認識合わせを行うという方法をとっているとしましょう。

この場合、いつまでに各チームが進捗状況を更新して、PMOに報告するのか、という点を整理します。

サンプルの図の例では、木曜日までは日々の活動を実施し、一週間作業進捗をチーム内のメンバーと報告書としてとりまとめ、作業の進捗状況をWBSにアップデートし、内容について合意します。

「この内容で報告します」という合意が得られたら、金曜日にPMOへ報告書、更新したWBSを提出します。

金曜日にPMOが各チームから報告書と更新されたWBSを受け取ったら、PMOは翌週月曜日の全体進捗報告会議に向けて準備を進めます。PMOは事前に各チームの報告書を確認しておき、プロジェクトの進行の観点でリスクになるようなことや、大きな進捗の遅れに対して状況を確認し、対応策を検討します。

なお、全体進捗会議で個別の課題を詳細に議論すると時間が足りなくなってしまうので、状況の把握にとどめ、何かしらの問題が発見された場合や報告が行われた場合は、そうした問題への対応策検討のための会議設定などの行うことにする、という具合にアクションを整理するにとどめておくのが一般的です。

プロジェクト計画書の中では、こうしたWBSを用いて進捗状況を管理する、そして週次の進捗報告を行うこととする、といったルールを記述しておきます。

実際にWBSを作成するのは以降の各フェーズの最初の段階で、構想策定/Planningフェーズの時点でプロジェクトの開始から終了まで詳細に作業を分割したタスクを一覧にしているWBSを作るわけではありませんのでご安心ください。

成果物管理

次に成果物管理です。

成果物とは、後段のセクションでどういったものなのか具体例を交えて解説していますが、SAP導入プロジェクトにおいてはシステムの設計内容や、業務の流れなどをまとめた資料のことを指します。

SAP導入プロジェクトではWaterfallのアプローチが基本になりますので、とある成果物が後続の作業の前提になります。

つまり、とある成果物は後続の作業や他の成果物の作成のために必要なインプットになります。

したがって、作業を進めていくために必要な前提事項になってくる成果物が既に作成されているのか、そして内容はしかるべき責任者によってレビューされ、承認がされているのかどうか、という管理が必要になります。

これが成果物管理です。

プロジェクトの規模が大きくなると、成果物の作成の担当者が別々に存在する、フェーズの途中で新たに参画してくる、といったメンバーも増えてきます。

したがって、どの成果物がいつ誰に作られるのか、承認はいつまでにされるのか、既にされているか、またデータとしてどこにあるのか、といったことを決めるのが成果物管理となります。

スケジュールを管理するときは表形式で整理すると見やすくなるので、こちらのイメージのようにExcelでまとめておくことが一般的です。

フェーズごとに成果物を整理し、どのチームが作るのか、誰が承認をするのか、いつ作成がスタートして、作成完了はいつなのか、そしてレビューの開始はいつで、承認完了はいつなのか、という点を管理します。

Planningフェーズの間はBuildフェーズなどの先のフェーズの成果物については承認者、予定開始日、予定完了日などは大まかに決めておくことになりますが、各フェーズに入る前に担当者や日付などを詳細化していくことになります。

プロジェクト計画書の中では、成果物をどういった形式で作成し、レビューし、承認していく、というルールを記述し、この時点で成果物のレビュー予定までを作るわけではありません。

成果物のレビュー、承認には時間がかかるものなので、予定完了日の2週間前には作成を終えてレビューの依頼を出すことにする、といった時間に関するルールや、レビューをするときには資料をメールで送って見ておいてもらうという方法ではなく、打ち合わせを設けて作成者がレビューをする人に説明をすることを基本方針とする、などのレビューの方法に関するルールも記載します。

こうしたレビューの方法ですが、SAP導入プロジェクトでよく使われる表現がありますのでご紹介しておきます。

レビューの方法

• Walkthrough（ウォークスルー）
  • 成果物の作成者とレビュー担当者の間で打ち合わせを設定し、成果物の作成者がレビュー担当者に対して詳細に説明を行う
  • 重要な成果物、内容が複雑な成果物についての第一回目のレビューで実施することが多い
• Off-line Review（オフラインレビュー）
  • 成果物の作成者がレビュー担当者に成果物を送付し、レビューをして頂くように依頼する
    （打ち合わせ形式で詳細の説明を行わない）
  • 重要性の低い成果物、見れば内容を理解できる程度のシンプルな成果物、既にWalkthroughを実施しており内容を大方把握している状況の成果物に対する修正部分に関するレビューで実施することが多い

よくある方法は、重要な成果物や複雑な成果物に対する第一回目のレビューはWalkthroughで実施し、二回目以降や修正部分の確認はOff-line Reviewで行うというものです。

新規に作成した成果物であり、まだ誰もレビューをしていないものであれば第一回目のレビューはWalkthrough形式で行い、その時点でレビュー担当者が出来る限りのコメントを行い、修正のポイントを作成者に伝達します。

その後、作成者が指摘を受けた修正ポイントに沿って成果物の更新を行ったら、そのあとの確認作業はWalkthrough形式ではなくOff-line Reviewで行う、というものになります。

変更管理

それでは次に変更管理です。

変更管理とは、既に承認された成果物への変更、承認されている基本的な計画などの変更に対する管理を指します。

成果物管理の部分でも触れましたが、成果物は後続の成果物のインプットになるので、仮に既に承認されている成果物があとから更新されるとなると、後続の成果物として作成したものも調整をしなくてはいけない、という事態になります。

よって、個人が好き勝手に成果物の内容を書き変えることはプロジェクトとして望ましくないので、なにかしらの変更を承認済みの成果物に対して実施する場合はきちんと定義したルールにのっとって実施する必要があり、このルールをプロジェクト計画書の中では記述します。

以下に成果物の変更の場合のサンプルを記載します。

こちらの例では、変更を成果物に対して行う場合は変更の理由、ビジネスへの影響、変更が棄却された場合（承認されなかった時）の対処、作業への影響とコストを整理することをルールとして定めています。

とくに作業の影響やコストは、自分のチームの変更が他のチームの作業にも影響することもありますので、プロジェクト全体を考えて見積もることになります。

そして、これらの情報をまとめてPMOや業務ユーザーなどの意思決定者に変更を実施するか否かについて判断をして頂く、という流れになります。

プロジェクト計画書には、このような形式でどんな情報をあらかじめ整理するのか、誰に対して変更に関する判断をしてもらうのか、といったルールを記述します。また、変更管理のための会議はどのくらいの頻度で実施するのか、等も定めます。 ここまでは成果物の変更に関するお話をしてきましたが、プロジェクト全体の計画や、スケジュールなどの方針の変更も変更管理の対象となります。プロジェクト計画書に記載する内容としては同じで、意思決定をする前にどんなことを事前に整理した状態にすべきなのか、という点をルールとして定めます。

終わりに

本投稿では、SAP導入プロジェクトの基本としてWaterfallアプローチにおけるPlanningフェーズの作業内容と成果物について解説してきました。 今後も、SAP導入プロジェクトの基本について少しずつ解説をしていきたいと思いますので、ご参考になれば幸いです。