システム構築の流れは基本的に下図のような流れになります。
導入するシステムの規模などによって、各フェーズの期間が異なったり、フェーズを省略、あるいは統合する場合はありますが、基本的な流れは変わりません。
このシステム構築の流れはウォーターフォール型のシステム開発の手順であり、アジャイル型のシステム開発の手順はまた別となりますが、多くのシステム導入の場合は、ウォーターフォール型のシステム開発をする場合が多いです。
準備フェーズ
システム導入のためのプロジェクトの準備段階です。
準備フェーズに実施する内容としては、プロジェクト体制の構築、システム、ベンダーの選定、プロジェクト全体の概算見積もりなどプロジェクト全体に影響する様々な内容があります。
この段階の成果がこの後のプロジェクト全体の成否を決めると言っても過言ではありません。
特に会社で始めてシステムを導入する場合などは、準備段階で何をしたら良いかが分からずに、時間ばかり経過し、進まないなどの状態に入りかねません。
準備段階でやることを整理し、計画的に進めることが必要です。
■実施内容
•プロジェクト体制の構築（プロジェクト憲章の作成、プロジェクト体制の構築など）
•世の中の情報の収集
•現状調査、将来像の明確化（As-Is、To-Be）
•課題の明確化
•システム選定
•ベンダ選定 プロジェクト全体の見積もり
提案フェーズ
準備段階でまとめた提案資料を持って、会社上層部へ提案を行い、システム導入の承認を得ます。
規模が大きなシステムの場合は、会社上層部に対し、準備段階から経過報告などをして、前持って情報のインプットが必要です。
提案フェーズで大事なのは、提案が通るだけではなく、その結果を会社方針に展開してもらい、上層部から関係する各部署に対して、指示してもらうことに意味があります。
システムを使った業務改革を実施するためには、関係各部署の協力が必要です。
会社上層部から社員に対し、会社が一丸となって業務改革を行う意思を表明してもらいましょう。
また、提案が承認された場合は、プロジェクトに参加する人の確保、社内外の人が集まる場所の準備なども必要になってきます。
■実施内容
•会社上層部への提案
•会社方針への展開
•ベンダ、外注との契約
•システム開発用機材（サーバーなど）の準備
•プロジェクトルームの設置 プロジェクトのキックオフ
要求定義フェーズ
要求定義フェーズは、システムを構築する上で一番大事なフェーズと言っても過言ではありません。
要求の粒度に関しては様々ですが、基本的には考えられる要求事項を全て書き出し、書き出した内容から必要な要求内容を精査して要求仕様書を完成させます。
要求はどうしても現場業務をベースに「これがないと仕事が回らない」になったり、「せっかくシステムを導入するならあれもやりたい、これもやりたい」などになってしまい、まとまらないケースが多くあります。
また、曖昧な要求は後の工程に対して大きな影響を与えます。
必要な要求を正確にまとめる気持ちでリーダーが強力に推進する必要がります。
それでも、要求は膨れ上がり、何度も見直しが入る可能性がありますが、粘り強く頑張りましょう。
■実施内容
•新業務フロー図の作成
•ベンダーによるシステムのデモ
•要求の洗い出し、精査
•要求の合意 システム開発の概算見積もり
要件定義フェーズ
要求の内容を基に、具体的にシステムで実現する機能を明確化するフェーズです。
ベンダーが要求定義書をベースに要件定義を行います。
新しい業務の中で、システムで実施する部分とシステムの外で人が実施する部分を明確にします。
要件が固まるとベンダーは、これ以降のシステム開発（設計、プログラミング、テスト）にかかる工数の見積をします。
ユーザーはベンダーから要件定義書と見積もりをもらい、システムの機能とシステム開発にかかる費用の確認します。
このフェーズで導入するシステムの全体像が決まるので、ユーザーはベンダから出された資料を入念にチェックする必要があります。
■実施内容
•ベンダーへの要求説明とベンダーからの質問に対する回答
•ベンダーによる要件定義書の説明
•ベンダーによるシステム開発（設計、プログラミング、テスト）の見積もり説明
•要件の合意
設計/プログラミングフェーズ
ベンダーがシステム開発をするフェーズです。
最近のシステム開発はアドオンをしない方向で進んでいますが、その分システム側には設定項目が多くあり、規模の大きなシステムでは、何万、何十万と言う設定項目があります。
プログラムによるシステム設計ではなく、設定によるシステム開発になってきています。
ユーザーはベンダの設計にどこまで入るかですが、これはユーザー側に専任のIT部門がある場合と無い場合で大きく違ってきます。
専任のIT部門がある場合はある程度ベンダーの開発状況を把握できますが、無い場合はベンダーに任せる形になります。
しかし、専任のIT部門が無い場合でも、ベンダーの開発日程の管理などは重要です。
このフェーズの遅れがプロジェクト後半の日程に大きな影響を及ぼす可能性があるからです。
また、この期間ユーザーは何もしないわけではありません。
導入へ向けた教育資料の作成、受入テストの準備など、導入へ向けた準備をする段階です。
■実施内容
•ベンダーの日程管理 設計書の確認
•設計書の確認
テストフェーズ
単体テスト、結合テスト、システムテスト、インストールテスト、受入テストなどシステムの規模や開発するベンダーによって、様々なテストがあります。
テストフェーズは、開発したシステムの「品質の確認」をする重要なフェーズです。
ここでのテストの抜け漏れによって本番運用後の不具合やクレームの数が大幅に変わってきます。
最低やらなければならないテストは以下の３つです。
•プログラム単体のテスト：ベンダがプログラム単体のテストを確実に実施したかの確認
•機能確認のテスト：要件定義で決めたシステムで実現する機能の全件確認
•業務フローに基づいたテスト：実ユーザによる業務フローに基づいた本番運用に近いテスト
また、テストは「不具合なし」は失敗テストです。
開発してすぐのシステムに不具合が全く無いは有りません。
導入前に１件でも多くの不具合を見つける覚悟でのぞみましょう。
■実施内容
•テストシナリオ、テストデータ、テスト環境の準備
•テスト実施
•変更管理 テスト報告書の作成
システム移行フェーズ
システムを稼働させ、ユーザに対しシステムの利用を許可します。
システム移行には全く新しいシステムを運用開始する場合と、旧システムから新システムへ切り替える場合があります。
旧システムから新システムへ切り替える場合は、旧システムのデータを新システムへ移行したり、周辺システムの新システムへの切り替えなど様々な作業が発生します。
また、ユーザが利用開始すると開始後１ヶ月程度は、障害やユーザからのクレーム多く発生するので、その対応が必要となります。
移行前にはユーザー教育も必要です。
■実施内容
•システム移行手順書の作成
•システム移行テスト
•システム、データ移行
•導入直後のサポート体制の構築 ユーザ教育
運用/保守フェーズ
システムを導入し、新しい業務の運用を開始した後、その業務が止まること無く安定して継続できるようにします。
運用体制を構築し、ユーザーからのシステムに対する問い合わせに対応したり、新業務の導入の経過を観察し、課題を見つけ改善します。
保守体制は、ベンダーと保守契約を結び、システムに異常が発生しないように定期的なメンテナンスを実施します。
最近では、様々なセキュリティー対策や、定期的なシステムのバージョンアップなどがあるので、それらを対応する必要があります。
また、移行後の半年程度はシステムの不具合が発生する可能性があります。
迅速に対応し、業務が停止しないように十分に注意する必要があります。
■実施内容
•運用/保守体制の構築
•運用/保守マニュアルの作成
•運営委員会のようなユーザーの声を聞く定期的な打ち合わせ
•新規ユーザの教育 ユーザ管理（棚卸しなど）
まとめ
システム構築の流れを簡単にまとめました。
全体感は掴めていただけたでしょうか？
システム構築の流れは、いろいろな本やネットで紹介されています。
ネットの多くはシステムを導入するベンダーさんによって書かれているため、それぞれ違いますが、大まかな流れは同じだと思います。
システムを立ち上げる際は、まずは全体感をつかむこと。
まずは、このシステム構築の流れを理解し、次に書くフェーズで実際にどのようなことをするのか、見ていきましょう。