こんにちは、ばいおです。
今回はSAP導入プロジェクトのタブーについて記事にしました。
今回の記事は特にSAP初学者の方に読んでいただきたい内容です。
SAP導入プロジェクトでこれをやったらマズいことになる可能性が高い、という３点をまとめたので、是非読んでいってください。
願わくば、本番障害を引き起こしてしまい不幸になる方が、この記事を読むことで少しでも減れば幸いです。
SAP導入プロジェクトのタブー３選
構成管理を怠る
タブー１つ目は「構成管理を怠る」です。
SAP導入プロジェクトにおいて、構成管理はとても大切です。特に移送関連。
どのプロジェクトにも、移送を取得する度に移送番号・移送内容を記載する台帳は必ずあるかと思います。
移送を取得したら都度台帳をメンテナンスしていくのはかなり面倒ですが、横着せず必ず実施しましょう。移送順序や移送時期など特別に考慮しなくてはならない点がある場合は、必ず記載するようにしましょう。
これを怠ると最悪の場合、本番障害に直結します。
前提移送が抜けてて移送に失敗した、なんてパターンはかなりラッキーです。本番障害になる前にミスを検知できたのですから。（勿論ミスはよろしくないですが）
一番残念なのは、誰も検知できずに移送漏れした場合や、移送してはいけないものが移送されてしまった場合です。
これが起こると、ほぼ確実に本番障害です。
本番障害は怖いです。
クライアントからの信頼を失い、上司からは詰められ、障害対応のため泣きながら睡眠時間を削らなくてはいけないのですから。
皆様はこんな経験したくないですよね？私は嫌です。好きな人がいたらごめんなさい。
ちゃんと台帳に書いておくだけで防げるはずの障害を、書くのを横着してしまったばかりに起こしてしまうなんて、とても勿体ないです。
また、設計書等のドキュメント管理も疎かにしてしまいがちですが、しっかりやりましょう。
クライアントと揉めた時、設計書の更新履歴があなたを救うカギとなるかもしれません。
成果物であるドキュメント類は必ずクライアントのレビューをもらっているはずです。
レビューをもらっているということは、「ここまでは承認をもらっている」という証拠です。
ドキュメント類の構成管理を適切に行っていれば、もしクライアントから「そんなの知らん！」と言われても、「でもレビューもらってますけど。。。」と切り返すことができます。
こまめな構成管理は、他でもない自分を守るために実施するものなのです。
然るべきユーザを使用しない
タブー２つ目は「然るべきユーザを使用しない」です。
これは、動作確認の場合と本番作業の場合とで話が分かれます。
まず動作確認の場合。
動作確認では、可能な限り本番に即したユーザを使用するようにしましょう。
多くの場合ベンダーが使用するシステムユーザには、クライアントが実際に使用するユーザよりも自由な権限を持つユーザがあてがわれているかと思います。
ここで、うっかり便利な自分のシステムユーザを使用してテストしてしまったばっかりに、クライアントのユーザならエラーとなるチェックをすり抜けてしまった、というケースが偶に起こります。
動作確認するなら、可能な限り本番相当の権限を持つユーザを使用して実施しましょう。
（もちろん、単体テストなど、プログラムの動きを確認するという目的のテストならば別です。）
尚、本番相当という意味では、動作確認に用意するデータも本番相当のものを用意するのが望ましいです。障害というヤツは、いつも予想外のところから顔を出すので。。
次に、本番作業の場合。
本番作業の場合、ベンダー側が使用するユーザは大きく２つに分かれるかと思います。
１つは保守運用で使用するユーザ、もう１つは移行作業で使用するユーザですね。
この２つのユーザを、「どっちも本番環境にアクセスできるから、どっち使ってもいいでしょ！」とゴチャ混ぜにして使用すると、惨劇が起こるリスクがあります。
というのも、移行作業で使用するユーザは、「移行のときにしか使用しない」というその特性上、そのユーザ独特のチェック突破ロジックや代入ロジックが組まれている可能性があります。
移行作業で使用するユーザが、保守運用で使用するユーザと区分されているのにはちゃんと意味がありますので、間違っても移行作業以外で移行ユーザを使用しないようにしましょう。予期せぬ代入がされてしまうこともあります。
特に気をつけたいのが、移行作業をするついでに本番障害対応をするケース。
横着して、「移行ユーザで障害対応もしちゃえ！」としてしまったら、さらなる障害を引き起こしてしまうかもしれないですよ。。。
もっとも、大抵の場合は、本番作業手順書・移行作業手順書があって、かつ本番環境にアクセスするときには監視者がいて、悪いことはできないような体制になっているはずなんですけどね。
何故かありえないことが起きるのがプロジェクトです。
合意した内容を残さない
タブー３つ目は「合意した内容を残さない」です。
これはSAP導入プロジェクトに限った話ではないと思いますが、大切な話なので記載しました。
クライアントとの会議で、何かを合意したのであれば、その内容を議事録なりメールなりで必ず残し、周知するようにしましょう。
合意事項を明確に残さないと、その合意事項にまつわるところで問題が発生した場合、泥沼化する恐れがあります。
俗に言う、「言った言わない問題」ですね。
最悪の場合、下記のような訴訟になってしまうことも、、
あなたが書いたその議事録が、会社を救う神の一手になるかもしれません。
そもそも合意内容が曖昧なのは論外です。
合意内容は、誰の目から見ても明らかになるような形に落とし込みましょう。
（プロジェクトに全く関係ない人でも理解できるレベルで、というのはよく言われることですね）
おわりに
今回はSAP導入プロジェクトのタブー３選について、記載しました。
「何をアタリマエのことを！」と思われた方もいるかも知れません。
私もその通りだと思います。今回記載したことはどれも当たり前のことだし、平時には普通にできることです。平時には。
これが忙しくなってきたり、メンタルが平静を保っていない状態だったりすると、忘れてしまったりついつい手を抜いてしまいがちになってしまうのです。
作業担当者は今回挙げたようなタブーをうっかり犯さないこと、上司は確認ポイントとして、タブーが犯されていないかを確認することが、本番障害を少しでも減らすカギになることでしょう。
ここまで読んでいただきありがとうございました。
