SAPプロジェクトで炎上の種になる「やってはいけないこと」

はじめに

SAP ERPに関するプロジェクトは、規模の大きさやミッションクリティカルな内容が多いことから、炎上に発展しやすいものです。

しかし、炎上が起こるからには何かしらの原因があるわけで、その原因さえ潰していけば炎上は回避できるとも言えます。

そこで今回は、「SAP プロジェクトで回避しておくべき炎上の種」をまとめて紹介していきます。

 

 

 

1.構成・変更管理が煩雑

まずひとつめの「種」は、構成・変更管理を雑にやってしまうことです。

SAPプロジェクトでの構成・変更管理は、ほぼ「移送の管理」です。

 

通常、プロジェクトでは移送毎に移送番号や内容を記録する台帳を作成します。

移送の度に台帳を更新するのは面倒かもしれませんが、怠るべきではありません。

移送の順序やタイミングに注意が必要な場合は、特に注意して記録しましょう。

この記録を怠ると、最悪の場合、本番環境での障害に繋がる可能性があります。

 

移送漏れや不適切な移送が発生すると、本番環境での障害がほぼ確実に発生します。

このような障害は、クライアントの信頼を失うだけでなく、現場の混乱をまねきます。

また、障害対応に追われることでプロジェクト全体が疲弊し、さらなる障害を引き起こす可能性もあるわけです。

 

また、設計書などのドキュメント管理も重要です。

ドキュメント管理を怠ると、クライアントとのトラブルに巻き込まれた際に、解決手段を失う可能性があります。

ドキュメントは通常、クライアントのレビューを受けているため、「これまでの承認」の証となります。

これがなくなると、論争の落としどころが作れずに、要件定義や設計のやり直しが頻発します。

そしてリソース不足に陥り、炎上に発展してしまうというのが典型例です。

 

 

 

2.開発ユーザーの使いまわし

2つ目の種は、開発ユーザーを過度に使いまわしてしまうこと。

これは、開発というよりもテストフェーズの問題かもしれません。

開発工程で最も効率化しにくく地味で手間がかかるのは「テスト」です。

このテストには、単体・結合テストはもちろんのこと、データ整備や動作確認のための作業も含まれます。

 

システムの動作確認では、実際の本番環境を再現するために、本番と同等のユーザーアカウントを使用することが重要です。

ベンダー側が使うシステムユーザーは通常、開発用ユーザーよりも強い権限を持っていることが多いため、これらのユーザーで動作確認を行うと、本番環境で発生するエラーを見落としてしまうことがあるわけです。

 

プログラムの動きだけを確認するのならばどのユーザーでも問題はないでしょう。

しかし、単体テストなどの場合を除き、動作確認は本番環境と同じ権限を持つユーザーで行うべきです。

さらに、データも可能な限り本番環境に近いものを使用することが望ましいです。

しかし、実際には開発用ユーザーで作成したデータをそのままテストに投入してしまったり、ひどい場合はUATもそのデータを使用してしまったりと、本番を想定しきれていないケースが散見されます。

これが後々の「予期せぬエラー」につながるわけです。

 

また、開発用ユーザーをそのまま保守運用や移行作業に使ってしまうという荒業も火種になります。

通常のベンダーであれば、保守運用用と移行作業用でユーザーを分けるでしょう。

特に移行作業用のユーザーは、作業効率を上げるために特殊なチェックを回避する設定になっている場合があり、保守運用とは区別して使用する必要があるわけです。

しかし、ごく稀に開発用ユーザーを流用して、まったく同じ権限設定を持つユーザーを作ってしまい、保守や移行に使用しているケースがあります。

まったく異なる作業を想定しているにもかからず、持っている権限が同一なのですから、結果に齟齬が生まれるのは当然です。絶対にやめるようにしましょう。

 

 

 

3.恒久対応の先延ばし

3つ目の種は、「恒久対応の先延ばし」です。

つまり、何らかの不具合や設計ミス、傷害などが発生した場合に、暫定対応のまま本番稼働まで持ち込んでしまうケースです。

暫定対応は、あくまでも「その場しのぎ」であって、システムのあるべき姿に沿ったものではありません。

このくらいのことはプロジェクトメンバー全員が理解していると思うのですが、なぜか恒久対応が行われずに放置され、カットオーバー間近になって大問題へと発展するケースを何度もみかけてきました。なぜ、こんな初歩的なミスが起こるのでしょうか。

 

理由はさまざまですが、よくあるものとしては「リソース不足」や「引継ぎミス」などが挙げられます。

SAPプロジェクトは、メンバーが頻繁に入れ替わることが多く、時にはリードクラスもその対象になります。

障害については「暫定対応済み」とされていれば「解決済み」として扱ってしまう人も多く、恒久対応が必要なことを後任者が知らないという事態に発展しがちなのです。

とても初歩的なコミュニケーションミスなのですが、これが本当に無くなりません。

 

また、SAP ERPは基幹業務に絡む重要なシステムだけに、再設計や改修にも企業上層部の承認が必要です。

時には、社内の政治的な理由からすぐに許可がおりないこともあります。

つまり、システム的な都合だけではなくクライアント企業の社内的な都合が絡むために、すぐは恒久対応が行われないことがあるわけです。

プロジェクトメンバーとしてできることは、「恒久対応と実施状況を可能な限り精密に残しておく」ことくらいでしょう。

 

 

 

4.コンセンサスを明示的に記録していない

4つ目の種は、「合意内容をしっかり記録していない」ことです。

これはSAP界隈に限らず、IT業界全体で問題視されている事柄ですね。

クライアントとの会議で何らかの合意に達した場合、その合意内容は議事録やメールを通じて明確に記録し、関係者に周知することが重要です。

合意した内容を適切に記録しておかないと、将来的に問題が発生した際に、その問題が複雑化するリスクがあります。

 

これは一般に「言った言わないの問題」として軽く扱われることがありますが、最悪の場合、訴訟に発展する可能性もあります。

合意内容が不明確な状態は、そもそも避けるべきです。

 

この件について、記憶に新しいところでは「大手証券会社」と「大手SIer」による訴訟があります。

大手証券会社側は概要設計フェーズから要件定義にない追加要件を連発し、設計・開発フェーズに入ってもそれが続いたことで、事実上、プロジェクトがとん挫してしまいました。

発注側に特定の業務を俗人的に支配していた有力者がおり、その力があまりにも強すぎて、誰もコントロールできなかったことが要因とされています。

しかし、その影には「合意内容を強く明示的に周知できなかったプロジェクト全体の風潮」もあるのではないかと推測されます。

 

合意内容は、プロジェクトに関係のない人でも理解できるほど明確かつ詳細に記録することが望ましいです。

これにより、どんな人が見ても合意の内容が明白となり、将来的な混乱や誤解を防ぐことができるからです。

 

 

 

まとめ

今回は、SAP関連プロジェクトで炎上を防ぐためにやってはいけないことを紹介しました。

いずれも初歩的な内容なのですが、シンプルであるがゆえに誰もが忘れやすく、なおざりにしがちなものばかりです。

一度でも炎上プロジェクトを経験していれば脳裏に焼き付くのですが、忙しくなればなるほど、その記憶も薄れていきます。

炎上プロジェクトの経験はSAP人材を大きく成長させることもある一方、ときには肉体や精神を蝕んでしまうこともある諸刃の剣です。

可能な限り自衛しながら、しっかりとキャリアを積み上げていきましょう。