「無事にシステムを稼働させることができれば良い」。こう考えているITベンダーが多いように思う。この考え自体は間違ってはいないが、システムを開発する段階から、運用・保守作業を円滑に進めるための準備を進めてほしい。
ITベンダーの多くが、システムの要件や機能についての仕様書を作成し、見える化に取り組んでいることは承知している。だが、まだ十分ではない面がある。
これからITベンダーにお願いしようと考えているのが、「Why」情報の整理整頓である。「なぜ、○○の機能を作ったのか」「△△機能を変更した理由は何か」「□□といった例外処理を追加した理由は」「なぜ、今回のシステム障害に××といった対応策を講じたのか」。こうした「なぜ」情報をドキュメントとしてまとめてもらいたい。
Why情報は、将来への備えになる。機能の追加・変更作業やシステム障害への対策などを、手際よく進めることができるだろう。
現状ではWhy情報が整備されていないことが原因で、苦労することがある。数年前に実施したERP（統合基幹業務システム）パッケージのバージョンアップ作業がそうだ。
当社は会計や人事・給与、購買などの業務にERPパッケージを適用している。このERPパッケージの標準機能だけでは、当社の業務を進められないという事情もあり、アドオン・ソフトも開発した。
このため、バージョンアップによるアドオン・ソフトへの影響度合いを調査する必要があったのだが、想像以上に手間取ってしまった。アドオン・ソフトについて「なぜ作ったのか」をまとめた文書が不完全だったためだ。
既に不要なのかどうか、ERPパッケージ新版の標準機能で置き換えても支障がないのかどうか、アドオン・ソフトを引き続き残すために修整が必要なのかどうか。こうした判断を下すのに時間がかかった。
この時は、システム構築を担当し、アドオン・ソフトについて詳しいITベンダーの技術者を呼び寄せ、なんとか事態を乗り切った。もし、この担当者が引退していたり、プロジェクトに参加できない状況だったりしたら、どうなっていただろうか。想像するだけでも、ぞっとする。
システムの仕事は属人化しやすい面がある。だからこそ、Why情報をはじめ、システムにかかわるさまざまな情報をできるだけ文書化しておくべきだ。
ITベンダーだけに頼るだけでは、当社の情報化推進力は高まらない。こう考えて、当社もこれまでドキュメントをまとめる作業に力を注いできた。
3年前に、製品選定や開発、運用・保守といった業務の手順を標準ガイドラインにまとめた。システムの種類ごとに、求められるレスポンスタイムや、バックアップ体制の取り方などについて定めている。
当社の標準は、システム担当者やシステム子会社の担当者が守るべき憲法のようなものだ。当社と付き合っているITベンダーの担当者にも理解してもらい、順守するよう呼びかけている。
苦労したが、ガイドラインを作ってよかった。標準に基づいて業務を進めるようにしたことで、開発や運用・保守といった業務の効率は確実に向上している。
いつも、ITベンダーの優秀な担当者に仕事を任せることができれば理想だが、事実上不可能だ。だからこそ、Why情報や標準を可視化することが重要なのだ。（談）
