実業務に使えるシステムか？ 運用試験と実用準備：企業システム戦略の基礎知識（11）（2/2 ページ）

[青島 弘幸，＠IT]

業務マニュアルを整備する意味

　前ページで述べたように、運用試験とは開発したシステムが実際の業務に使えるかどうかを確認することが目的である。システムは、機械系と人間系が有機的に連動してこそ相乗効果が得られる。人間系の部分に関して必要になるのが業務マニュアルである。運用試験はこの業務マニュアルに対する試験でもあり、利用者に対する実践的な教育の場でもある。

　業務マニュアルなしで運用試験を開始してもシステムの基本的な使い方が分からずに手間取ったり、誤った使い方をしてそれをシステムの不具合だと勘違いしたりと混乱のもととなる。また、業務マニュアルなしでの運用試験は人間系の業務を省いた、単に機械系の機能確認になってしまうケースも少なくない。そしていざ実用開始してから、業務上の不備やマニュアルの不備、あるいはシステムの不備が発見される。システムの実用開始直後に、そのような混乱が発生すると収拾がつかなくなる。不具合をなんとか機械系であるコンピュータ・プログラムを改修することで対応しようとするとどんどん例外処理が膨らみ、システムはあっという間に継ぎはぎだらけになってしまう。業務マニュアルは単なるシステムの操作説明書ではない。人間系（入力）→機械系（処理）→（出力）人間系というように、システムに対する入力業務から出力に対するアクションまで一貫した業務プロセスを、システムを利用してどのように遂行すれば良いのかが理解できなければならない。実際の利用者がこのことを理解してシステムを有効活用しなければ、せっかくの投資も確実な成果に結び付かない。

システム活用は十分な教育から

　システムを構築するに当たり、予算とスケジュールを守ることに精魂尽き果ててしまい、実用開始前の教育にまで手が回らないことが多い。しかしシステムは構築するのが目的ではなく、それを活用してこそ目的が達成されるものである。そのことを忘れずに、運用試験の段階で実際の利用者に十分教育を実施しておく必要がある。そもそものシステム構築の目的に始まり、各機能の目的や実際の業務に対してどのように利用するのが最も効果的であるのか、など本質的な部分からの理解がないと意図したとおりにシステムが利用されず、目的の成果が得られない。

　また想定外の事態が発生したときに、どのように対処すればよいのかを業務マニュアルで明確化しておき、その対策が有効に機能するかどうかを確認しておけば、実用開始後に多少のトラブルに見舞われても人間系でなんとか乗り切ることができる。そのため、利用者には入出力の意味、システム内部の業務処理について理解を与えておかなければならない。特にエラーリストや警告リストのたぐいはその意味を教えずに放置するとデータ精度が悪化し、次第に使われないシステムとなったり、ある日突然、問題が発覚したりして大騒ぎになる。

　この教育に対する負担はシステム構築全体の中で過小評価しているケースが少なくないが、結構大変な作業である。時間に追われて業務マニュルの整備が遅れ、利用者に操作マニュアルだけ渡して「後はよろしく」では、システムの有効利用はおぼつかない。

目指せ、ワンタッチ段取り

　運用試験の最後には、システムの本番移行作業が待ち受けている。まったくの新規システムであればさほど問題もないかもしれないが、既存のシステムからデータを移行するような場合には、リスクを抑える周到な準備が必要である。

　そこで参考になるのが、トヨタ生産方式の段取り時間短縮の考え方だ。改善の結果、10分以内にまで短縮したものを「シングル段取り」といい、さらに極限まで短縮したのを「ワンタッチ段取り」という。システムの移行も、理想はワンタッチ段取りである。考え方は、まず段取り作業を外段取りと内段取りに分ける。外段取りとは、機械を止めなくても実施できる事前準備作業である。内段取りとは、機械を止めて行わなければならない作業である。段取り作業を分析し、できるだけ外段取り作業の比率を増やし、機械を止めて行う内段取りの時間を極限まで短縮する。例えば、メニュー以外の画面は事前にすべて移行を完了して検証しておき、本番の直前にメニュー画面だけを切り替えたり、データベースも事前に移行して差分更新で同期させておき、本番の直前に新旧データベースを切り替えたりといったやり方が考えられるだろう。

　リスク管理の観点からすれば、こうした移行にかかわるリスクと準備作業についての検討は、移行間際ではなく上流工程で行うべきである。例えば新データベースを設計するときに、既存のデータをどのように移行するかを考えて設計しなければならない。特にデータの識別子が変更されるような場合、新データベースに合わせて既存データを分解・集約しなければならない。データを分解・集約するということは、管理精度が変わるということであり、これが実際の業務では大問題となることがある。本番間際に窮地に追い込まれないよう移行要件が十分検討されているか、ぜひ要件定義段階でのレビュー項目に追加していただきたい。これも外段取り化だ。

　次回は、実用展開について説明していこう。

著者紹介

▼著者名　青島 弘幸（あおしま ひろゆき）

「企業システム戦略家」（企業システム戦略研究会代表）

日本システムアナリスト協会正会員、経済産業省認定　高度情報処理技術者（システムアナリスト、プロジェクトマネージャ、システム監査技術者）

大手製造業のシステム部門にて、20年以上、生産管理システムを中心に多数のシステム開発・保守を手掛けるとともに、システム開発標準策定、ファンクションポイント法による見積もり基準の策定、汎用ソフトウェア部品の開発など「最小の投資で最大の効果を得、会社を強くする」システム戦略の研究・実践に一貫して取り組んでいる。趣味は、乗馬、空手道、速読。

「システム構築駆け込み寺」を運営している。

メールアドレス：[e-mail]