目次

ある日の電話

保守運用は属人化しやすい

保守運用を属人化させないためのドキュメント

できる保守運用担当者の思考プロセス

保守運用に必要な業務フローの要件

ある日の電話

5月の第３営業日、朝一の電話で「冨樫さん、月締めのジョブでトラブっています。至急対応をお願いします。」基幹システムの保守運用をしているとよくある春の風物詩です。初めてその連絡を受けた時は緊張が走ったものですが、毎年繰り返されるとだんだん慣れてきて、「ああ、そう言えば、そんな季節だな」と。そのお客様はSAPをご利用されていますが、SAPでは管理会計の伝票番号範囲の設定を会計年度毎に定義してやる必要がありました。お客様の情報システム部門にはそのことをお伝えしてあるのですが、なにせ年に一度のこと、稼働後のしばらくは担当者も気を張っているし、こちらも事前に念の為のご連絡をしているので忘れることはありませんでしたが、5年、10年と経過すると担当者も変わります、こちらも別の新たなお客様のプロジェクトで頭が一杯で、平気で「マスタメンテを忘れる」という事が起こります。「さて、しょうがない人達だなぁ、」と思いながらリモートからお客様のシステムにログインするのですが、今度はそのトランザクションコード(画面ID)がなんだったか思い出せません。若い頃はほとんどのトランザクションコードは覚えていたのに。この際に頼りになるのが、導入当時作成した業務フローです。トランザクションコードを調べるため、ということもありますが、業務フローを復習すると、今この段階までにお客様はどんな手順を踏んできており、この後どんな業務をいつまでに終わらせなければならないのか、トラブルが起きている”文脈”を理解することが出来ます。

 

保守運用は属人化しやすい

私自身が過去の経験で、業務フローがあって助かった、と思えたシーンを紹介させていただきました。保守運用は属人化しやすく、ブラックボックス化が深刻な問題となりやすい業務の一つです。その理由は次のとおりです。

　●お客様は保守を任せてきた担当者 (個人) を信頼している

　●担当者はそのことに誇りを感じており、期待に応えようとする

　●担当者は最短のリードタイムで問題解決することを優先する

　●そのためにドキュメントの更新や改善など、優先度が二次的な業務は常に後回しとなる

　●その担当者の頭の中にしかない暗黙知が増える

　●聞けば即答してくれるのでお客様はこの担当者をより一層信頼する

お客様企業から保守企業に対するお金の支払いがチケット制になっていて、正味対応時間に対する請求となるために、ドキュメント整備や更新に時間を割きにくい (そんなものは当初から整備済みの前提なので言い出せない) ということもありますが、そのようなネガティブな背景がなかったとしても上記に列挙したような現場のWin-Win関係の中で、保守運用はどんどんその担当者に属人化してゆきます。この構図は短期的には良いのですが、中長期的にはいつか破綻する運命にあり、保守担当企業の管理職はこの担当者の将来の配置変えに備え、お客様や自社の他の担当者とのノウハウの共有/移管を進めなくてはなりません。

 

保守運用を属人化させないためのドキュメント

それでは保守運用を属人化させないために整備しておくべきドキュメントとは、どのようなものが対象になるのでしょうか。まず挙げられるのは当該システムが開発された時に作成されたドキュメント類になるでしょう。次にそのお客様企業の規程やマニュアル類も重要です。お客様企業と保守運用担当企業のどちらがメンテナンス責任を負うかはアウトソーシング契約の範囲によるとは思いますが、いずれにせよこれらが最新化されていないと属人化は進んでいってしまいます。

●開発ドキュメント

　○ブループリント
　○インフラ設計書/仕様書
　○システム構成情報 (ハードウェア/OS/DB/ネットワーク情報)
　○アプリケーションメニュー/画面/機能/帳票/インターフェース/ジョブなどの一覧
　○ジョブフロー
　○プログラム設計書/仕様書
　○ER図/テーブル図
　○テスト仕様書/エビデンス類

● 規程/マニュアル
　○ISO/内部統制規程
　○組織図/職務分掌規程
　○業務規程/決裁権限規程/セキュリティ規程
　○業務フロー
　○システムの操作マニュアル/運用マニュアル

挙げればキリがありませんが、一般的に上記のようなドキュメント類は保守運用を引き継ごうとする際に求めれば出てくるものかと思います。これらのドキュメント類を最新に保ってゆくことには、それぞれに特有の苦労があることでしょう。本稿でその全てに触れることはできませんが、この中で最も事実とドキュメント間の整合性を取ることが難しいのが業務フローです。プロセスは目に見えませんので。本稿(連載シリーズ)ではこの業務フローを何のために、どうやって整備し、維持管理してゆけば良いかについて解説させて頂きたいと思います。

 

できる保守運用担当者の思考プロセス

まず保守運用担当者にとってお客様の業務を知っているとはどういうことかについてです。例えば販売管理周りをカバーするシステムにおいて、ユーザーから「売上計上時にエラーが発生した」という連絡を受けたとします。昨日までその事象は発生していませんでした。あなたならどんな順序で何を疑うでしょうか。基幹システムの保守運用に慣れた方であれば次のように考えると思います。

　●工事も設定変更もしていないし、他のトランザクションは動いているのでインフラは問題ない

　●プログラム改修のリリースもしていないので急に挙動が変わる訳がない

　●売上計上処理はこれまで○年間毎日動いており、今更バグが出るとも思えない

　●間違いなくユーザーの操作ミスまたはマスタ設定ミスがあったはずだ このような仮説のもとお客様のシステムに入り、当日のその他の売上データを確認します。

正常に計上されているので問題は連絡を受けたトランザクションに特有の事象だとわかります。次にエラーが起きた当該の売上処理の元になる受注データ、出荷データなどを確認します。それと同じ品目や得意先で過去に売上計上されているか? 操作したユーザーの所属組織に変わった点はないか? という事を調べます。原因は次のようなケースに分類されると思います。

　●新製品/新商品の初回の販売で品目マスタの設定にミスがあった

　●新規顧客への販売で得意先マスタの設定にミスがあった

　●価格改定があり価格マスタの設定にミスがあった

　●組織変更や異動があり売上を計上するための組織設定(利益センタや勘定設定)にミスがあった

　●受注承認/出荷処理/検収処理が正しく行われていなかった できる保守運用担当者は正解を一発で言い当てることが多いです。

その秘密は当該企業の大まかな変更イベント(組織変更、異動、新製品発売など)を把握しており、さらにはこの人はそんなミスをする訳がないとか、あの人ならあり得るといった勘も働くため、上記のような仮説から消去法で原因を特定できるからです。一つに特定できなかったとしても、お客様に対して簡潔に的を射た質問をして、すぐに答えにたどり着くことができます。だから気に入られる訳です。

 

保守運用に必要な業務フローの要件

業務フローを整備しその内容に精通しておくと、このような「できる保守運用担当者」に早く近づくことができます。売上計上のためには出荷処理が必要、その前に受注承認が必要といった「業務の順序性」が頭に入っている。但し、こんな場合には承認は不要、出荷処理はないなどといった「業務のシナリオ」が頭に入っている。これらに関連する形でアプリケーション上のトランザクションの流れや、マスタデータとの依存関係が理解できている。「できる保守運用担当者」は基本的にはこれらを記憶していますが、仮に忘れてしまった場合でも業務フローのどこを見れば良いという事をわかっているので困ることはないのです。意識の高い方はこのように業務フローを使いながら、曖昧な点や、時に役に立たなかった点を見つけると、フローを修正して次回以降に備えます。(こういうメンテナンスをしているからこそ、実際に見なくても記憶している訳ですが) 改めて、保守運用に使える業務フローの要件を挙げてみましょう ●業務の順序性を確認でき、アプリケーションのどの画面/機能がどこで使われるのかがわかる ●業務のシナリオ (事業/製品/商流/物流の違い) がわかりやすく整理されている ●業務の順序やシナリオに応じてアプリケーションのトランザクションの流れやマスタデータとの依存関係が表現されている (詳細は開発ドキュメント類にリンクされている) 次回はこのような業務フローをどのように整備するか、網羅性や粒度感の観点から解説したいと思います。