はじめに
はじめまして。私は2017年のSAPジャパン入社以来、インフラ・Basis(テクニカル)領域にて、お客様へSAP S/4HANA製品を始めとするSAP製品の導入プロジェクトに参画し、導入を支援するコンサルティング・サービスを提供するポジションを担当しております。
今回はSAP入社以降に実際に自身が参画させて頂きましたプロジェクトの経験を踏まえ、プロジェクト期間の観点で自身が感じたことや気づきについて皆さんに共有できればと考えております。海外と比較して、日本におけるSAPの導入プロジェクトの期間は長いとよく言われますが、プロジェクト期間を短縮するにはどのような点を考慮すればよいのか、個人の経験則に基づく考えにはなりますが、これを読んで頂いた皆さんが今関わっている・もしくは今後関わるプロジェクトの期間短縮の一助となれば幸いです。
約6年 / 半年
この2つの数字ですが、何の数字か分かりますか？
これは私が入社以降に携わった、ある2つのお客様のそれぞれのプロジェクト期間を示しています。それぞれのプロジェクトにおける規模（利用ユーザ数やデータ量）や対象スコープ・モジュールも全く違うため、それぞれのプロジェクト期間が長い・短いと判断することは当然出来ません。ただ、圧倒的に導入に要した期間の違うプロジェクトを経験したからこそ、プロジェクト期間の長期化を防ぐためにどのような点に気をつけなければならないのか、私が感じた考慮ポイントを今回のブログポストにてご紹介したいと思います。
考慮ポイント
1. プロジェクト期間への意識付け
まず一つ目の考慮点としては「プロジェクト期間への意識付け」というポイントを挙げさせていただきました。通常、プロジェクト開始時点ではその前工程(提案時、もしくは構想策定など)で既にマスタスケジュールが計画されており、そのマスタスケジュールに従って、プロジェクトの担当チーム毎に、より細かなタスクスケジュールを計画していくことが多いかと思います。ただ、その際にプロジェクトの“期間”に対して、どのような理由・背景があって、このプロジェクトの“期間”が計画されているのか、その期間を守ることのモチベーションについて、プロジェクトに関わるメンバーと会話されることは、実はあまりやられていないのではないでしょうか？
先ほどご紹介した6か月のプロジェクト期間で導入されたプロジェクトでは、プロジェクト開始当初からお客様が主導する形で本番稼働までに短期間で実施することの理由付けや、それをプロジェクト全体に浸透させるための意識付けをプロジェクト全体（リーダー層のみではなく、メンバー含め）で終始一貫して徹底されていました。このことはとても重要なポイントだと思います。
例えば、プロジェクトが困難な局面に立った際にこのような意識付けが無ければ、Go Liveを延期してタスクを組み替えて・・・という判断をしてしまいがちになりそうですが、その意識付けが徹底されていたプロジェクトにおいては実際そのような話になることは無く、どうすれば現在計画しているプロジェクト期間でその問題を解決、もしくは回避できるのか、建設的な形で議論・検討が実際に出来ていたように思います。
また、次の2にも関連しますが、この意識付けの土台があってこそ、プロジェクト活動における“無駄”を排除し、そこに割かれるワークロードも削減することができたと思っています。
2. 徹底的な無駄の排除
先に記載の通り、6か月のプロジェクト期間で導入されたプロジェクトでは、プロジェクト期間を6か月で完遂することの優先順位を高く位置づけ、その目的のために“無駄”と判断したモノをプロジェクト内で認識を一致させ、徹底的にやらないこととしました。
以下に実際に“無駄”として定義したものの例を列挙します。
- コミュニケーション（Teamsの活用）
- メールによるコミュニケーションは基本的に排除。Teamsチャットを最大限利用し、コミュニケーションにかかる時間を短縮化。
- 議事録作成を排除。Teams録画を義務付け、録画を議事録として利用。
- テストエビデンスの最小化
- 最低限のエビデンスのみ作成。（エビデンス文書の体裁を整えるなどの無駄は排除）
- プロジェクト文書の最小化
- 議論・検討文書の体裁を整えることはしない。※議論・検討出来ればメモ書きでも可
- プロジェクト作成文書と定義する文書、及び定義された文書の内容もプロジェクト活動や、本番稼働後の運用観点で必要最低限な内容に絞って作成。
ワークロードという観点で一つ一つを見れば大した削減にはなりませんが、プロジェクトのあらゆる工程・タスクに関わるモノであるため、最終的には“チリツモ”でプロジェクトを振り返ってみるとプロジェクト期間の短縮への寄与という意味ではとても重要な要素であると考えています。
なお、特にプロジェクト文書の作成という観点で見たときに、プロジェクト期間が長期化するようなプロジェクトの傾向として、文書を作成・評価すること自体が目的となってしまっていることが往々にしてあるのではないかと思います。何のためにこの文書を作成するのか、といったそもそもの基本的な観点がプロジェクトを進める中で抜け落ちてしまい、体裁や「てにをは」のチェックに終始してしまうなどで、無駄な時間が割かれてしまい、それらが積もり積もってプロジェクトの長期化の一因に繋がってしまうということがあるのではないかと思います。
上記例で“無駄”として定義したものは、一つ一つを見れば“たかが・・・”と思われるものばかりですが、プロジェクトを短期間で完遂するために、本当に必要なモノなのか、それが無いとどんな問題があるのか、改めて考えてみる価値はあるのではないかと思います。
3. Fit to Standardの実践
最後にFit to Standardの実践です。
*Fit to Standardとは・・・業務をシステムに合わせることを目的とする導入手法。SAPのベストプラクティスのシナリオに沿って標準機能ベースで業務設計を行い、短期導入を目指す導入アプローチ。
冒頭に自己紹介したように私はインフラ・Basis(テクニカル)領域にてプロジェクト参画するため、直接的にFit to Standardを推進するポジションではないのですが、プロジェクト期間の短縮化という観点では、外せないポイントとなります。業務を標準機能ベースで合わせるアプローチとなりますので、アドオンの設計・開発・テストに要する期間が要らなくなるから、プロジェクト期間も短縮出来るんでしょ？と思った方、それも正しいと思いますが、それだけでは無いと考えています。
先に述べた6か月のプロジェクト期間で導入されたプロジェクトではFit to Standardの実践を徹底し、アドオン開発を“ゼロ”を実現しましたが、そのプロジェクトにおいてはテスト工程でパフォーマンスの問題が発生しませんでした。標準機能はもちろんSAPで開発、様々なテストにて検証されたうえでリリースされているため、パフォーマンスの観点の問題発生リスクはアドオン開発したものと比べ低いということが実証されたものと考えています。
(個人的な所感ですが) パフォーマンスの問題は調査・分析・チューニングの対応もそうですが、それらの調査・対応結果をアプリ・開発・ベーシスなどのチーム間で跨いでコミュニケーションして進める必要があり、プロジェクト全体として見たときでも、人・時間のリソースを多く割かねばならない問題だと感じており、この問題に割かれる時間が短縮出来るということは、プロジェクト期間の短縮に大きく寄与できるポイントになりうるのではないかと思います。
ベストプラクティスに沿った形で業務設計されているため、ベストプラクティスの業務シナリオを理解したメンバーであれば、すぐにシステム導入後の業務プロセスを理解することが可能です。プロジェクトにおいては、Fit to Standardを推進するチームとは別に、教育や運用関連のタスクを別チームで構成するケースも多いと思いますが、そのような場合でもベストプラクティスといういわば“共通言語”をベースに進めることが出来るということは、あらゆる場面で話がスムーズになるため、プロジェクト期間の短縮化に貢献できるポイントになると思います。
まとめ
以上、私が実際に参画し、経験したプロジェクトを通してプロジェクトの長期化を防ぐための考慮点について、お伝えしてきましたがいかがでしたでしょうか。皆さん既に認識されていることとは思いますが、プロジェクト期間が長くなることによるデメリットとしては以下のようなことが考えられます。
プロジェクトが長期化すればするほどと、追加のリソースやトレーニング、サポートなどのコストがかかりやすくなる傾向があります。これにより、プロジェクトの総コストが増加する可能性があります。
- ビジネスプロセスの変更への適応の遅れ、それに伴う競争力の低下
SAPの導入プロジェクトにおいては通常、ビジネスプロセスの変更を伴います。導入プロジェクトの長期化により、ビジネスが変更に適応するまでの期間が長くなり、競争力を維持する上での課題が生じる可能性があります。
プロジェクトが長引くと、プロジェクト開始時点では最新だったテクノロジーであっても、本番稼働時点では既にテクノロジーが進化し、新しい機能やセキュリティ対策がリリースされる可能性があります。これにより、プロジェクトが完了するまでに古いテクノロジーが使われ続け、最新の機能やセキュリティが利用できないという課題が生じる可能性があります。
これらのデメリットを最小限に抑えるためにも、今回挙げた“ヒント”が皆さんの今後のプロジェクト活動に少しでも生かされ、プロジェクト期間の短縮化に繋がれば幸いです。
