システム導入の企画から導入完了までの主なプロセスを解説！

システム導入は業務上の課題を認識した後、企画から始まりベンダー選定や要件定義など様々なフェーズを経て完了します。
そして、フェーズごとに多くの成果物を作ることになりますが、それは開発会社だけでなく、発注者側も作らなければいけないものがあります。

当記事では、プロジェクトの起案から導入完了までのプロセスと作成される主な成果物について解説します。

企画・構想

企画・構想では大きく起案書の作成と経営層による承認に分けられます。

起案書の作成

システム導入は基本的に多くのお金がかかるため、経営層による承認が必要となります。経営層からの承認を得るためには、現状の業務がどういうもので、どのような課題があるかを明確にしていくことが重要です。
さらに課題を明確にしたうえで、あるべき姿を検討し費用対効果を算出します。費用対効果は作業時間の削減などといった定量的な側面と、作業ミスによるリスクや担当者の精神的負担の軽減などといった定性的な側面の両方があります。
現状業務、課題、あるべき姿を起案書としてまとめ、経営層からプロジェクト発足の承認を得られるよう準備します。

企画承認

起案書ができたら、経営層に向けてプレゼンテーションを行って、プロジェクトを発足させるための承認を得ます。
経営層による承認は、プロジェクトの規模によってフェーズが移り変わる毎に必要になる場合がありますが、最初の承認はどんなプロジェクトでも必要となります。
経営層に対して、現状の業務と課題、あるべき姿、システム導入によって得られる効果を説明し、プロジェクトを実施した方が将来的に得になると思わせることが重要です。

ベンダー選定

経営層からの承認を得られたら、課題を解決するためのソリューションおよびベンダーの選定を行います。

情報提供依頼書の作成

情報提供依頼書は一般的に「RFI（Request For Information）」と呼ばれます。RFIとは課題を解決するための製品やサービスを選定する際に、SIerなどにパッケージ製品や技術についての情報提示を求める際に提出する依頼書のことで、発注者側が作成するドキュメントです。
RFIは主に以下のような項目を記載してベンダーに提出します。

• 情報提供の背景・目的
• 対象の事業概要（会社概要やユーザ数、拠点など）
• プロジェクト概要（目的やスケジュール、業務課題、予算など）
• システム要求事項
• 情報提供依頼事項（製品情報、技術情報、導入実績、コストなど）
• 情報提供の手続き（問合せ窓口やスケジュール、プレゼン方法、指定フォーマットについてなど）

提案依頼書の作成

提案依頼書は一般的に「RFP（Request for Proposal）」と呼ばれます。RFPとは外部のベンダーに対して課題を解決するためのソリューションの提案を求める公式な依頼書のことで、発注者側が作成するドキュメントです。
RFPの作り方については、以下の記事で詳しく解説しています。

RFPに必要な6つの要素を解説！

RFP（Request for Proposal）は「提案依頼書」と呼ばれ、外部のベンダーに対してソリューションの提案を求める公式な文書のことで、発注者側が作成するべきドキュメントの１つです。ここでいう「提案」とは発注者側が企画構想フェーズ...

itbuild-map.com

2023.09.01

また、RFPと並行して評価シートも作成します。評価シートは以下のカテゴリーごとに評価項目を設けてベンダーごとに点数化し、定量的な測定を行って平等に評価できるよう準備しておきましょう。

• 提案理解・実現性
• 機能要件
• 非機能要件
• スケジュール
• 体制
• コスト
• 保守・運用

ベンダープレゼンテーション

RFP提出後しばらくするとベンダーから提案書が送られてくるため、内容を確認の上ベンダーによるプレゼンテーションを行います。プレゼンテーションはプロジェクト管理を行うPMに行ってもらうことが大切です。
また、プレゼンテーションの場で発注者側から質問をすることも非常に重要です。自分たちの課題を解決するために十分な検討がなされているかどうかは、提案の内容と質問に対する回答によって判断することができます。
プレゼンテーションが終わった後は、評価シートに従って点数化を行います。

契約締結

評価が完了した後は正式に発注を行うことになります。発注を行うに当たっては秘密保持契約や基本契約など様々な契約の締結を行う必要があるため、それなりの時間を要します。
また、ベンダーによっては受注するのにも社内決裁が必要となるため、プロジェクトに本格参加するには最低でも約１か月はかかると見込んでおいた方がよいでしょう。

システム開発

ここまで来てようやくシステム開発の各種タスクがスタートします。基本的にはベンダーの方でプロジェクト管理や成果物の作成を行いますが、発注者側も参画しなければならない場面が多数あります。

要件定義

要件定義とはユーザ（発注者）の現行業務や実現したい要望などをヒアリングし、あるべき姿を実現するためにどのような機能を持ったシステムを構築していくかを検討していくフェーズです。
ウォーターフォール型のシステム開発において、最も重要となるフェーズになります。ここで発生した抜け漏れを後続のフェーズで回収することは非常に難しいため、可能な限り時間をかけて慎重に実施していきましょう。
また、要件定義が完了すると追加開発のボリュームが出てきます。追加開発は高額になることが多いため、できるだけ標準機能だけでおさまるように業務を見直していくことが大切です。
ただし、その業務が企業の競争の源泉になっている場合は、業務の変更は行わず、追加開発を選択することも必要になります。

※要件定義フェーズはベンダーと発注者が協力し合い、各種成果物を作成していくため、以下はそれぞれ同じものが記載されています。

基本・詳細設計

要件定義で取り決めた内容をシステムに反映させるために設計書を作成していきます。設計書は一般的に基本設計書と詳細設計書に分けられます。
作成するのはどちらも主にベンダーが行いますが、画面や帳票に表示させたい項目の確認などは、発注者側も参画しレビューを行うことが重要です。

開発・単体テスト

要件定義書や設計書の作成まで完了してようやくシステムの開発作業がスタートします。開発や単体テストは基本的にベンダー側で行いますが、発注者側はすべてを丸投げするのはやめましょう。
少なくとも週次くらいのペースで進捗や課題の状況を確認し、開発が滞りなく進んでいるかをチェックすることが必要です。

結合・システムテスト

開発が一通り完了すると、テストフェーズに入ります。テストの種類は様々ありますが、基本的には結合テスト、システムテスト、パフォーマンステスト、ユーザテストを行います。
結合テストとは単体テストで問題ないことを確認したそれぞれのモジュールを組み合わせて、意図した通りの挙動になっているかを確認するテストです。
システムテストは総合テストとも呼ばれますが、すべてのシステムが要件定義の内容通りに動作するかを確認するテストです。
パフォーマンステストはシステムが要求される性能基準を達成し、ユーザーが期待する応答時間や処理能力を得られることを確認するテストです。
ここまでは基本的にベンダー側で行われるテストになりますが、開発フェーズと同様に週次くらいのペースで進捗と課題の確認は行うようにしましょう。

ユーザーテスト

ユーザーテストとはエンドユーザーにとって使いやすく、期待通りの機能を提供しているかどうかを確認するためのテストです。また、実際の業務で使用する環境で動かすことで、環境に起因する障害がないかも確認します。
ユーザーテストは実際の業務に限りなく近づけることが重要になるため、実際の担当者、データ、テストシナリオを用意して行います。ユーザーテストで問題がないことを確認したら、本番移行に進みます。

データ移行・業務移行・システム移行

新しいシステムを導入する時には必ず「データ移行」と「業務移行」と「システム移行」を行います。
それぞれの概要は以下の通りです。
・データ移行：新しいシステムにデータを移行する作業
・業務移行：これまでの業務から脱却し新業務で運用するための作業
・システム移行：現行基盤から新基盤にシステムを移す作業
これらの対応はベンダー側で行うことも可能ですが、その分費用が増加することになるため、可能であれば発注者側が主体となり、ベンダーと協力しながら進めていくようにしましょう。

システム検収

ここまでのフェーズを終えることでシステムの検収を行うことができます。
検収とは開発されたシステムが要件仕様に準拠し、利用者や関係者が期待する通りに機能していることを最終確認・承認することです。
ベンダー側としては検収をもってシステム改修の責任から解放されることになるため、発注者側は慎重に検収を行う必要があります。
※本番稼働後にベンダー側の瑕疵による障害が発生した場合は、システム改修を行う必要があります。

本番移行・検収

検収をするためにはこれまで作ったシステムをユーザーのもとに届ける必要があります。この届けるという作業を本番移行といいます。
本番移行では予め取り決めた実施期間の中で、前述した「データ移行」「業務移行」「システム移行」を行います。
プロジェクトの規模にもよりますが、基本的に本番移行は業務やサービスを停止して行うため、作業ミスだけでなく、時間がかかりすぎてしまうのもNGです。
非常に緊張感のある作業になるため、手順書の精緻化やバックアップ体制の確保等、事前の準備がとても重要になります。

運用・保守

本番移行が完了したら運用・保守のフェーズに入ります。新しいシステムを導入した直後は問い合わせや障害が多くなるため、速やかに保守体制を構築し対応にあたります。
また、システム導入において最も避けたいのは「使われない」という状態です。
この状態を避けるためにも、日々トランザクションデータをチェックしてシステムがきちんと稼働しているかをモニタリングします。
モニタリングの結果、使われていない事が分かった場合は、その理由を調査して対策を検討する必要が出てきます。

まとめ

ここまでシステム導入の企画から導入完了までの主なプロセスと作成物について解説してきましたが、重要なのは発注者側とベンダー側がそれぞれどこまでの成果物を担当とするかを明確にすることです。
ベンダー側に依頼することになれば、その分工数がかかるため、導入費用が増えることになります。
一方で、発注者側は通常業務もあるため、実際に手を動かすことは難しい場合があります。
メリットデメリットを考えたうえで、それぞれの役割を明確にし、プロジェクトを進めていくことが大切です。