システム導入/刷新に向けた現状分析の進め方と計画の立て方とは？
目次
この記事で理解できること
本記事では、新システムの導入や既存システムの刷新を担当することになった方がプロジェクトの立ち上げを完了し、新システムのあるべき姿を描いていくまでに、実施すべきことや意識すべきポイントを解説いたします。
新システムのあるべき姿といわれてもいきなり描けない、そのためにまずは現状の把握をしようにも、範囲が膨大すぎて具体的にどのような手順でなにを把握すればいいのかわからないという悩みを抱えている方は多いかと思います。
システム刷新は数年に一度のイベントであるため、やみくもに現状把握を行い、新システムのあるべき姿を描いても、知見不足から目的を達成するシステムを構築できない可能性が高いです。
そのため、体系的な手順・方法にのっとって実施していくことが重要です。まずは、プロジェクトをどのように進めていくのかの下準備について解説します。
システム発注プロセスの中での位置づけ
本記事では、システム発注プロセスにおいて、「②現状分析・要求検討、システム導入/刷新計画策定」を解説します。
前フェーズである、「①プロジェクトの立ち上げ」の実施内容やポイントを知りたい方は、こちらからご覧ください。
現状分析を行い新システムで実現したいことを考える
まず、「現状調査・要求検討」フェーズでは、以下のような流れで進めていきます。
それぞれ、各実施内容において、どのようなことを検討・協議するのか、どのような資料を作成するのか、詳しく解説していきます。
プロジェクトの進め方を具体化する
現状調査・分析に入る前に、まずはプロジェクトの進め方を具体化してメンバー間に共有しておく必要があります。
「プロジェクト実行計画書」の作成
今後プロジェクトを進めていくにあたっての基本的な枠組みを設定するため、プロジェクトを実行するための指針となる計画書を作成します。
計画書を作成しておくことで、プロジェクトメンバー間で共通認識を得ることができますし、方針に迷った際などに参照し、目的・目標に立ち返ることができます。また、予算やスケジュールなどの制約条件についても確認することができます。
具体的には以下のような項目を記載する必要があります。
プロジェクトの立ち上げで得た情報を記載することになりますので、詳細については「①プロジェクトの立ち上げ」の記事を参照してください。
- 背景
- 目的・目標
- 検討範囲
- 開発方式
- 要検討事項
- スケジュール
- 体制
- 予算
「プロジェクト管理資料・ルール」の整備
プロジェクトを円滑に進めるために、メンバーが利用する管理資料や従うべき管理ルールを整備し、プロジェクトメンバーに周知する必要があります。
具体的には以下のような項目の整備が必要です。
プロジェクト管理資料
- WBS・ガントチャート
この二つの資料は作業を漏れなく、遅延なく行うために作成・運用します。
「WBS」とは作業内容を細かく分解し構造化する手法のことです。プロジェクト完了までの全作業を漏れなく洗い出すことが目的です。タスクを分解してツリー構造に整理し作成します。
「ガントチャート」はWBSで分解した作業に担当者を振り分け、スケジュールを管理できるようにしたものです。
- 課題管理表
プロジェクトを進めていくうえで発生する課題・リスクを漏れなく管理するために作成・運用します。
- To-Do管理表
WBSで分解した作業より具体的なToDoを管理するために作成・運用します。
プロジェクト管理ルール
- プロジェクト管理資料の運用方法
プロジェクト管理資料の運用方法を定めます。誰が、どの程度の頻度で更新を行い、どのタイミングで報告を行うのかなどを定めておくことが重要です。
- コミュニケーション方法
情報の共有をどのように行うのかを定めます。連絡にはどのチャットツールを使うのか、定例会の出席メンバーには誰が必要なのか、頻度は週または月に何回なのかなど、コミュニケーションの前提を揃えておくことも円滑なプロジェクト進行を実現するために重要です。
プロジェクトの進め方の認識を合わせる
「プロジェクト実行計画」の認識合わせ（プロジェクトキックオフ）
プロジェクト目的や具体化したプロジェクトの進め方の認識を合わせるため、プロジェクトメンバー間でプロジェクトキックオフを実施します。
キックオフでは、前述のプロジェクト実行計画書やプロジェクト管理資料・ルールの認識合わせを行います。
キックオフ内での議論や認識合わせをした内容・結果を、プロジェクト実行計画書やプロジェクト管理資料・ルールに反映・更新します。
現状分析を行う
プロジェクトの目的や進め方についての共通認識を作ったら、現状の調査・分析に入ります。
システムに関する調査・分析だけではなく、より上流の事業戦略や事業課題に関する調査・分析も重要です。なぜなら、事業戦略の実現、事業課題の解決のためにシステムが存在するからです。
「事業戦略・事業課題」の確認
事業戦略について現状を整理するために、経営層に対して現状把握を行います。
システムを通して実現すべきことは、どのような事業戦略を実現し、どのような事業課題を解決するのかということに依存します。
そのため、経営層に対して、現状の事業戦略・事業課題をヒアリングし把握しておくことが必要です。
【作成する資料】
- 経営層へのヒアリングシート
「As-Is業務・業務課題」の確認・整理
As-Is業務（現状の業務のこと）の内容・業務課題について現状整理をするために、業務部門に対する現状把握を行います。
調査においては業務部門に、現状の業務の把握に役立つ資料がないか確認し、事前準備をしたうえで、ヒアリングを行うというのが一般的な方法です。
事前調査やヒアリング調査の結果をAs-Is業務フローに整理します。その後、現状調査の対象とした部署と認識合わせをしたうえで内容を更新します。
余裕がある場合は現状ヒアリングの際に、システム刷新後のあるべき業務についても業務部門に考えをぶつけておくとよいでしょう。（例：このような方法で業務を行うことは可能ですか？など）
そうすることで、あるべき姿を考えるときに指針が立てやすくなります。
【作成する資料】
- As-Is業務フロー
「As-Isシステム・システム課題」の確認・整理
現在既に利用しているシステムがある場合には、As-Isシステム（現行システム）の内容・システムの機能や運用での課題について現状整理をするために、情報システム部に対する現状把握を行います。
業務部門に対するヒアリングと同様、現状のシステムの把握に役立つ資料がないか確認し、事前準備をしてヒアリングを行うのが一般的な方法です。
調査結果は、以下の資料に整理し、情報システム部と認識合わせ行います。
【作成する資料】
- システム一覧
- システム全体構成
- IF一覧
- 機能一覧 など
「製品ロングリスト」の作成
パッケージでのシステム刷新を予定している場合は現状調査を行ったタイミングで、候補となりそうな製品のリストを作成しておきます。検討範囲に入りそうな候補製品を、インターネット上から得られる情報などをもとに洗い出します。
現段階では非常に多くの候補が記載されたリストとなるため、このタイミングで作成されたリストを、本記事では「製品ロングリスト」と呼びます。
【作成する資料】
- 製品ロングリスト
現状の課題からプロジェクトの目標を具体化する
現状調査・把握が終わったあとは、課題を整理して対応策の検討、そしてプロジェクト目標の具体化を行っていきます。
「現行課題」の整理・「対応策」の検討
調査をしたことで、事業・業務・システムの現状を把握したあとは、現行業務を分析し課題を可視化します。
可視化した課題の中で、根本的で対応すべき課題を見極めて、対応の優先度と対応策を検討します。業務・システムレイヤーの方がシステム的な解決策が思いつきやすいため、それらの対応策が思いつきやすいですが、事業戦略において何がボトルネックになっているのかという観点からも考えることが重要です。
【作成する資料】
- 現行機能一覧（全体と使用状況の整理）
- 現行システム全体構成図
- 現行課題一覧
- 課題のリスト（As-Is業務フローへのマッピング、現行システム全体構成図へのマッピング）
- 課題関連図
- 対応方針一覧 など
「プロジェクト目標」の具体化
根本的で対応すべき課題を見極めて、優先度と対応策が決定したら、その結果を踏まえ、プロジェクト目標の具体化または最終化を行います。
「製品ミドルリスト」の作成
パッケージでのシステム刷新を予定している場合は候補製品のノックアウトファクター（製品に求める前提条件の適否、主要課題への対応可否など 例：特定の機能がなければ候補としない）を検討し、製品ロングリストにて調査対象となった製品を絞り込みます。このタイミングで作成されたリストを、本記事では「製品ミドルリスト」と呼びます。
【作成する資料】
- 製品ミドルリスト
新システムと業務のあるべき姿を考える
現状の分析結果から最終的な目標が決まった後は、新システムと業務のあるべき姿を検討していきます。
「To-Be業務」の検討
新システム刷新後の新しい業務の流れ（To-Be業務）を検討します。
まず、As-Is業務からTo-Be業務への変更点を洗い出します。そのうえで、業務にかかわるドキュメント（ビジネスプロセス関連図、To-Be業務フロー、帳票など）を作成し変更点を可視化します。
あるべき姿を考える際は、現状の業務を知っているために、かえって、現状ありきで考えてしまいがちです。
現状の業務に引きずられてしまうのを防ぐためには、業務の目的に立ち返って発想することが肝要です。
目的を達成するためにこのプロセスは本当に必要なのか？という視点をもって考えると無駄を省いたあるべき業務を考えることができます。
【作成する資料】
- ビジネスプロセス関連図
- To-Be業務フロー
- 帳票 など
また、パッケージを導入する際は、パッケージ側が標準としている業務プロセスをTo-Be業務とすることがあります。パッケージは標準的な業務プロセスに基づいたシステム機能を備えているため、現在の業務をパッケージに合わせていくことで、業務の標準化を図ることができ、パッケージへの追加開発を避けることもできます。（業務をパッケージにあわせていくアプローチを、「Fit to Standard」と呼びます。）
「To-Beシステム全体概要」の検討
プロジェクトで導入/刷新するTo-Beシステムの全体概要を検討・可視化します。
具体的には以下の事項を検討・可視化する必要があります。
- その他の社内システムとの連携
- 共通基盤との連携
- サブシステムの構成 など
「機能要求概要」の検討
As-Isドキュメントや候補製品（パッケージ導入の場合）が提供する標準機能をもとに、機能要求を一覧に洗い出します。詳細な機能要求を作成する際の下ごしらえとなります。
【作成する資料】
- 機能要求概要
「非機能要求仕様」の検討
非機能要件とは、「機能以外の全ての要件」のことです。例えば、性能や可用性、セキュリティなどが上挙げられます。
ここでは、会社規模・利用者数・セキュリティポリシーなどをもとに、「製品の前提条件となる非機能要求」の検討を行います。
【作成する資料】
- 非機能要求概要
「製品ショートリスト」の作成
パッケージでのシステム刷新を予定している場合は製品ミドルリストに記載の候補会社と打ち合わせを実施し、整理したTo-Be業務・システム要求や、Web・カタログなどでは把握できない情報から候補製品を絞り込みます。このタイミングで作成されたリストを、本記事では「製品ショートリスト」と呼びます。
その後、必要に応じて製品ショートリスト上の候補会社へ、RFI対応を依頼する旨について事前予告を行います。
【作成する資料】
- 製品ショートリスト
システム導入/刷新計画を策定する
現状分析とあるべき姿の検討のあとは、システム導入計画、もしくはシステム刷新計画を策定していきます。
「システム導入/刷新計画策定」フェーズでは、以下のような流れで進めていきます。
開発会社から情報提供をしてもらう
新システムの要求概要が固まったら、発注先の候補となるシステム開発会社へ情報提供を依頼します。
このフェーズはより詳細な情報を得てシステムの導入/刷新計画を策定することが目的です。候補会社と連絡を取り情報提供を依頼しますが、システム開発会社の最終選定はまだ行いません。
「RFI」の作成
より詳細な情報を得てシステムの導入/刷新計画を策定するため、候補会社へ情報提供を依頼するためのRFIを作成します。
RFI（Request For Information）とは情報提供を依頼する書類です。具体的には、以下の内容を盛り込んで作成します。
RFIについて詳しく知りたい方はこちらをご覧ください。
- プロジェクト概要
プロジェクトの目的や検討範囲、予算などを提示します。プロジェクト実行計画書の内容を参照するとよいでしょう。
- 情報提供依頼事項
相手企業の基本情報や、相手製品の基本情報、製品の機能要求を満たしているのかといった事項です。
- 手続き要領
手続きの手順を示したものです。
- 回答様式
相手企業が回答すべき事項をまとめたものです。（費用、スケジュール、要求の対応可否など）
複数社の回答を同一フォーマットで比較しやすいといったメリットもあります。
併せて、発注先候補からのRFI回答に対する評価方法・評価観点についても検討を行っておきます。
【作成する資料】
- RFI
- RFIの評価方法・観点についての資料
RFI対応の正式依頼
製品ショートリストに記載の候補会社へ、RFIへの正式な回答依頼を行います。RFIで候補会社から提供していただく情報には、機密情報が含まれる場合は多いため、依頼を承諾した候補会社とはNDAを締結します。
「RFI」の発出
製品ショートリストに記載の候補会社へRFIを発出し、候補会社へRFI内容を打合せなどで説明し、認識合わせを行います。
「RFIに関する質疑」の対応
候補会社から受領したRFIの内容を確認し、不明点がないか確認します。
「RFI回答」の確認
候補会社から受領したRFIの内容を確認し、不明点があれば候補会社に問い合わせます。
デモンストレーションを実施する
パッケージ導入を検討している場合、現時点で把握している製品情報量をもとに、「概要デモ」での情報収集が必要となるタイミング（ショートリスト作成前/ショートリスト作成後/RFI回答受領後）を検討し、候補会社へデモの準備・実施を依頼します。デモを実施するためには候補会社側での準備が必要なため、デモを確認したい場合は前もって伝えておきます。
※概要デモ…製品の標準機能や操作感の確認をするためのデモンストレーション。
このタイミングでは候補会社が複数存在し、全候補会社とのデモにプロジェクトメンバー全員が参画するのは現実的ではないため、システム担当のメンバーがデモに参加して、製品の概要情報（要求・課題の実現イメージ、製品のユーザビリティなど）を確認します。
発注先を絞り込む
「RFI回答」のまとめ・評価
各社からのRFIへの回答と、評価結果を整理します。必要に応じて、このタイミングで候補会社を絞り込み、絞り込んだ後の候補会社をRFP発出先とします。RFPとは正式に提案を依頼する際に候補各社に送付する提案依頼書のことです。
新システムと業務のあるべき姿をまとめる
「システム導入/刷新計画書」「業務改善計画」の作成
候補会社とのやりとりやRFIで得られた情報をもとに、今回のシステム導入/刷新プロジェクトにおける「計画策定までの検討事項・検討結果」と「プロジェクト計画」を、「システム導入/刷新計画報告書」としてまとめます。
※必要に応じて、計画書と報告書に資料を分割します。
また、現状調査を踏まえ検討したTo-Be業務やRFIなどで得られた情報も踏まえて、システムの導入と同時に行う「業務改善計画」も作成します。
「システム導入/刷新計画報告書」と「業務改善計画」をもって、今後はプロジェクトを推進していきます。
プロジェクト着手の承認を得る
「計画着手」の承認
「システム導入/刷新計画報告書」の内容を、自社内の手続きに従って経営層に諮り、プロジェクト着手の経営承認を得ます。
「システム導入/刷新計画報告書」の承認後、RFP発出先の候補会社に対し、RFP提出の事前予告を行います。また、業務担当者のステークホルダーと「業務改善計画」の内容について認識を合わせた後、業務改善着手の承認を得ます。
刷新計画が決まったあとは
刷新計画が出来上がったあとは、より要求を詳細化した上で、候補会社へ提案依頼を実施します。
具体的な実施内容や、意識したいポイントについて、以下の記事で解説しています。ぜひ、続けてお読みください。
さいごに
IT調達ナビの運営会社である株式会社グローバル・パートナーズ・テクノロジー（GPTech）は、システム導入における、「システム発注側」の支援に特化したコンサルティングファームです。
システム導入・刷新に向けて、進め方や体制等でお困りの場合は、ぜひ一度弊社までご相談ください。
お問い合わせは下記からお願いいたします。
この記事の編集者
堀井 友貴
IT調達ナビの運営会社である、（株）グローバル・パートナーズ・テクノロジーに新卒入社。 同社のシステム発注側に立って支援するITコンサルティング業務で得られた経験から、システム発注に関わる人々の役に立つ記事を執筆する。
