システム導入、システム開発、ＷＥＢ構築のコンサルティングを納得の価格・期間でサポートいたします。

今回は、システム導入がどのように流れていくかについて、大まかな全体像とポイントを、お話させていただきます。

１．システムの企画

システムを何故導入し、最終的にどうしたいのか、目的と手段を明確にします。
検討には、対費用効果だけでなく、現状分析や市場調査、同業他社の動向も考慮に入れます。
また、開発体制、運用体制なども含め、トップが積極的に関与して決定します。
アウトプットとして、「システム導入企画書」をまとめておくと良いです。

２．要件定義

「システム導入企画書」をブレイクダウンした形で、要件をまとめます。
トップやシステム部門だけでなく、現場へのヒアリングも重要になりますが、現場の意見を聞きすぎて目的から外れないように注意する必要があります。
より戦略的なシステムを新たに導入する場合は、外部のコンサルタントに依頼することも検討します。
アウトプットとして、「要件定義書」を作成します。

３．基本設計（外部設計）

どのような機能があり、どのようなインタフェースになるのか、システムの全体的なイメージを定義します。
このフェーズからは、システム開発の担当者が加わりますので、外部に委託するときは、このフェーズの前に選定しておく必要があります。
基本設計で定義されていない機能を後から追加すると、機能追加として別途料金を請求されますので、機能の抜けが無いようにチェックをします。
アウトプットとして、「基本設計書」があり、内訳として、業務フローやシステム構成図、ER図、テーブル定義書、機能一覧などがあります。

４．詳細設計（内部設計）

基本設計を元に、プログラマがプログラミングするための詳細な設計書（仕様書）を作成します。
当然の事ながら、プログラマが理解できるように記述されていないと、憶測でプログラミングされてしまいますので、品質に大きく関わります。
アウトプットとして、「詳細設計書」があり、内訳として、項目説明書やモジュール設計書などがありますが、選択した開発手法によって種類が変わります。

５．開発・単体試験

詳細設計書を元にして、プログラマがプログラムを作成します。
単体試験はプログラムのロジックに基づき、プログラマが各モジュールの妥当性をテスト（ホワイトボックステスト）します。

６．結合試験

開発されたプログラムが正しい順番で流れ、正しい結果を返すかどうかをテストします。
基本設計書を元に、試験計画、試験項目を作成しておきます。
単体試験を抜けてきた不具合を見つけるフェーズですから、単体試験を行った者は原則的に関与してはいけません。
ほとんどの場合、設計者が行います。
小規模の場合、省略されるケースもあります。

７．総合試験

テスト用に作成したデータを用いて、実際にシステムを運用できるかを試験します。
プログラムだけでなく、バックアップが正しく動作するか等、運用までを視野に入れた総合的な試験を行います。
導入するシステム部門の担当者を交え、その妥当性を厳しくチェックします。

８．運用試験

実データを用いて、実際に運用してみます。
システム移行のときは、旧システムと新システムを並行稼動させるなどして、トラブルが発生しても業務に影響が無いように考慮します。
システムの規模により、行わないケースや、総合試験として行う場合などがあります。

９．運用

システムを本稼動します。
事前に運用マニュアルを作成し、不測に事態に備えるだけでなく、人材育成を行い、サポート体制を明確にし、担当者に告知します。
発生したトラブルは、操作ミスなどの軽微なものも含めて記録しておき、今後の改善に役立てるようにします。

１０．導入効果の確認

システムを導入したことにより、最初に設定した目標が達成できたのか確認します。
また、運用記録をチェックし、体制の見直しや教育で不十分だった点をまとめ、改善していきます。

このような全体的な流れを意識し、常に現在位置とゴールを認識するようにしましょう。
フェーズ毎に目標が達成できたかをチェックし、問題点は次のフェーズに絶対に持ち込まないようにします。
長丁場ですが、丁寧に積み重ねていけば、大きなトラブルは起きないものです。