ポイント：システム再構築の留意事項、情報戦略の明確化、情報化企画書、既存システムの調査、システムの切替え

システム再構築の留意事項

　システムを再構築する場合のスケジュール表を作成する必要があり、その留意事項をまとめてみた。システム再構築プロジェクトは下記の1～９までの項目をスケジュール化して進める必要がある。しかし、それ以上に重要なのはシステム再構築を行える、組織風土つくりである。再構築プロジェクトのリーダーとなるべき人には、仕事ができるため、業務負荷が高くなるのが普通である。この部分を勘案し、リーダーとなるべき人の業務負荷軽減の実施と、全従業員への仕事の効率化の必要性を認識させられる経営者の存在が、システム再構築プロジェクトを成功させる最大の要因と考える。その前提のもとで1～９までの項目をあげてみる。

１．プロジェクトチームの発足

先に述べたことだが、プロジェクトリーダは非常に多忙になるため、極力、現状業務を減らす必要がある。それが出来ない場合は、サブリーダをおき、業務負荷の分散を行う。サブリーダの選定条件は「自主的に行動する人間である」ことである。もちろんリーダが自主的に動かない場合は、そのプロジェクトは最初から失敗であると考えたほうがよい。

プロジェクトチームには相談役をおき、相談役は、経営に携わる役員クラスの人間であることが望ましい。システム再構築は時にはトップダウンで決定すべきことが多々出てくる。この場合に相談役に調整を依頼する。　

システムの改革は、業務プロセスの変革を伴う。その場合に部門間での利害対立が起きる。よって各部署からのメンバーは自部署を代表して発言を行い、最終的にはリーダが決断を下す。

□メンバーの選任を行う。

□相談役をプロジェクトへ加える。

□各部署からプロジェクトへの参加を行うこと。

２．情報戦略の明確化

情報戦略の明確化が必要である。どんな経営課題を解決するためにシステム化をするのかを検討する必要がある。経営課題の解決の基準を定量化しておくとよい。

全体最適が理想であるが、実際の業務では早期構築が最優先の場合がある。その場合ＥＵＣであえて、部門効率化を行う場合もある。但し、この場合でも、情報戦略として、全社の情報化企画の方向性を合わせておく必要がある。情報化企画の方法性は「情報化企画書」に記述する。

□何のために旧システムを再構築システムに置き換えるのか明確にする。

□経営課題の解決基準の目標値を設定する。

□どのようなサブシステムを用意し、サブシステム間はどのように連携するか明確にする。

□システム再構築の業務領域（該当部署）を明確化する。

□今回のシステム再構築は、全社での全体最適を行うべきものか、部門の業務効率向上を目指すＥＵＣの位置づけかを明確にする。

□システム再構築のスケジュール（どの業務をいつシステム化するのか）を明確にする。

□パッケージソフトを活用するのか、オリジナルソフトを作成するか意思決定する。

□新しい業務プロセスの明確化を行う。

３．従業員の情報リテラシーの向上

システム再構築と平行して、該当する従業員の情報リテラシーの向上を行う。情報リテラシーとは広い意味では「情報活用の意識の向上」、情報リテラシーの向上まで到達していない場合はコンピュータリテラシー、つまり「コンピュータ活用能力の向上」を行う。

具体的には、メールでのコミュニケーションやWebでの情報収集といったわかりやすい部分から始め、コンピュータに慣れるようにするとよい。また、管理帳票や営業日報をExcelやWordで作成し、Windowsアプリケーションの操作性に慣れておくとよい。

□会社として、システム化の方向性の伝達を行う。

□会社としてシステム化することにより得られる効果を明確にする。

□従業員としてシステム化することにより得られる効果を明確にする。

□個人のコンピュータ操作に関するスキルアップの必要性を理解させる。

４．既存システムの調査

既存のシステムに関して、以下のことを明確にする。全く新しい業務プロセスにする場合でも、現状の問題点は明確にして、再構築システムの機能要件に反映すべきである。

□現行システムでの問題点の洗い出す。

□現行システムでの管理項目（データベース項目）を洗い出す。

□現行システムからデータが何らかの形で外部出力できるかの調査する。

□既存システムでの業務フローを明確にする。

５．システムの切替え方法の検討

現行システムから再構築システムへの切替え方法には２つの方法がある。“一括切替え”と“順次切替え”である。一括切替えは、現行システムの稼動終了と同時に再構築システムの稼動を開始する。一方の順次切替えは現行システムを稼動させたまま、再構築システムの稼動を開始する。

一括切替えの場合は運用がシンプルであるのでコストや担当者の負荷が少ない。しかし一旦問題が発生すると後戻りができず、相当のリスクを抱えているといえる。

逆に順次切替えは一定期間２つのシステムが同時に稼動することになるので運用が複雑で、コストや担当者の負荷が高くなる。しかし問題が発生しても現行システムに戻れるのでリスクは少ない。また、再構築システムと現行システムとの結果を比較し、システムの評価ができるメリットもある。

□システムの切替え手順を明確にしておく。

６．データ移行手段の検討

　システムを再構築する場合、現行システムのデータを引き継ぎながら再構築システムは稼動を始めるのが一般的である。現行システムから、外部データとしてファイルが出力できる場合はよいが、外部出力することが不可能である場合は、過去数ヶ月分のデータを手入力するか、売掛金、買掛金、在庫等のＢ／Ｓ項目の期首残高のみをマスタに手入力するか等のデータ移行の手順とルールを明確にしておく必要がある。

□現行システムのどのデータを再構築システムのどのデータへ入れるか明確にする。

□何か月分のデータ入力をする必要があるのか検討する。

□だれがデータ入力をするのか明確にしておく。

□いつまでにデータ入力をするのか明確にしておく。

□必要であればデータ移行ツールを作成する。

７．再構築システムの設計・開発

システムの再構築を行う場合はマスタの整備を行う必要がある。現行のシステムが長年も稼動しているため、もはや使用されていない不要なマスタが必ず存在するものである。不要なマスタはシステム再構築時に削除し、マスタをスリムにしておくと、システム全体の効率性のアップにつながる。

また、マスタコードの体系の見直しも必要となる。桁数が足りなくなっている場合の見直しはもちろんのこと、これまでのコード体系のルールが妥当であるか見直しを行うべきである。たとえばグルーピングしやすい、並び替えがしやすい等のコード体系が望ましい。

トランザクションデータの一部見直しを行う場合の留意点は、現在のデータベース構造に極力影響を与えないようにすることである。それには、主キーやインデックスの構造を変更するようなことは極力行わないようにする。（業務プロセスを完全に見直す場合は特に留意は不要である）

□マスタデータの見なおし（項目、コードなど）を行う。

□トランザクションデータ構造の見なおし（項目、コードなど）を行う。

□不足管理データの検討を行う。

□開発ツールの検討を行う。

□DBMS（データベースマネジメントシステム）の選定を行う。

８．総合テスト

実際の運用に近い形で運用評価を行う。この場合、「総合テスト仕様書」をあらかじめ用意して、それに従い、順に評価していく。

　総合テスト時には、特に順次切替え時には担当者に相当の負荷がかかるので、担当者は兼任ではなく、専任が望ましい。そして次の３つは総合テストが始まる前にしておくべきことである。

□総合テストスケジュールの明確化を行う。

□総合テスト仕様書の準備を行う。

□総合テストの分担（部署と担当者）を明確にする。

９．システム評価

　システムが動いたからといって、情報戦略、その上の経営課題がクリアできたとは限らない。情報化企画の部分で設定した、経営課題の解決基準の目標値をクリアできたか評価する。

□経営課題の解決基準の目標値をクリアできたか評価する。

□クリアできなかった場合の原因調査を行う。

□さらにシステムを使いやすくするには、どうするかを検討する。

　以上が、システム再構築時の注意事項である。すべてを実現するのは困難であるが、システム再構築プロジェクトを俯瞰的にとらえ、問題が発生した場合は迅速な対応が必要である。問題の発生に早く気づくことが、後戻りの工数を削減し、早期のシステム再構築の実現が可能となる。

2004年7月26日宿澤直正記

[事務所TOP] [コラム一覧へ]