「企画構想フェーズ」はプロジェクトの超上流工程に当たり、現行業務の分析やあるべき姿を構想していきます。
システム導入における企画構想フェーズは、現行業務をどのように変えていきたいかを定義する「業務要求定義」と、その要求を実現するための「ソリューション・ベンダー選定」の工程に分けられます。
当記事では、システム導入プロジェクトの方向性を決める重要なフェーズである企画構想フェーズの「業務要求定義」の工程について解説していきます。
プロジェクト開始準備
企画構想フェーズを進めていくにあたって1番最初にやるべきは、プロジェクトを発足させる背景や目的を明確にすることです。
プロジェクトを発足させるということは必ず何かしらの課題があり、その課題を解決したいという思いがあるはずです。その課題は経営者や管理者が決める場合もありますが、業務担当者から上がってくる課題もあります。
その課題をできるだけ具体的に落とし込んで、プロジェクト発足の背景と目的として設定します。
プロジェクト発足の背景と目的の明確化・具体化ができたら、次に行うべきは企画構想フェーズの計画策定とプロジェクト管理ルールの策定です。
具体的には以下のような項目を計画書として作成していきます。
- プロジェクト発足の背景・目的
- スコープ
- 体制・役割
- スケジュール
- 主要タスクの詳細と想定される成果物
- 企画構想フェーズの終了条件
これらの項目の策定が完了したら、プロジェクト関係者を集めてキックオフミーティングを行いましょう
※キックオフミーティング：プロジェクトを開始する前にメンバーの足並みを揃えるための会議
プロジェクト発足の背景・目的
明確化・具体化したプロジェクト発足の背景と目的を文書にして残していきます。
こうすることで、プロジェクトを進めていく中で判断に迷う場面に差し当たったとき、計画書に記載される目的に立ち返ることで、その判断をサポートしてくれます。
また、プロジェクトに新規メンバーが参画したときに、初動から足並みを揃えることができます。
スコープ
プロジェクトを進めていくために、スコープを決めることは必須です。
このプロジェクトではどの部分の課題を解決したいのか、必ず対象範囲があるはずです。
計画書にはこのスコープについて、誰が見てもどこまでが対象範囲か分かるように、業務の視点とシステムの視点でスコープを定義し図示していきましょう。
体制・役割
続いて企画構想フェーズを進めていく体制と役割を決めてきます。企画構想フェーズでは、現行業務の分析やあるべき姿にするための業務設計などを実施していきます。
それらをこなしていけるメンバーの決定と、そのメンバー1人1人の役割を計画書に明記します。
ポイントとしては、プロジェクトを推進していくメンバーだけでなく、業務側の人たちも体制図に入れるようにしましょう。そうすることで、プロジェクトをより進めやすくなります。
システムを使うのは実際に業務を行う方たちです。より良いシステムを構築するには、業務を行う人の参加は不可欠になるため、業務側のキーマンとなる人を体制図に組み込むようにしましょう。
スケジュール
どんなプロジェクトのどのフェーズにも納期があるため、それぞれのタスクについて対応期日を決めていきます。
ポイントはいきなりスケジュールを考えるのではなく、企画構想の終了条件を達成するためにはどのような工程を辿っていけばいいかを最初に検討することです。
一番上の図は企画構想フェーズの一般的な工程を大工程・中工程・小工程に分けて表しています。もちろんプロジェクトの特性によって工程は変わってきますが、参考にしていただければと思います。
スケジュールが策定できたら上位層含む関係者全員で認識合わせを行います。実現性のあるスケジュールとなっているのか、予算は足りるのかなどをあらゆる方面からチェックしてもらい、精度の高いスケジュールを立案しましょう。
主要タスクの詳細と想定される成果物
これまでの内容を計画書に記載しても、プロジェクトのメンバーは具体的に何をすればいいのか分からないため、主要なタスクの詳細と想定される成果物を明記していきます。
イメージとしては、1番上の小工程をさらに細分化し、成果物の単位まで落としていきます。
例えば「ASIS整理・分析」の工程で行うタスクや想定される成果物は以下の通りです。
| タスク名 | 想定される成果物 |
| 現行業務の調査 | ・ヒアリングシート |
| 現行業務の可視化 | ・業務フロー図 |
「ASIS整理・分析」の工程では、業務担当者の暗黙知を紐解いて形式知にしていきます。上記のようなタスクを行うことで、現行業務がどうなっているかを明らかにすることができます。
このようにある工程を成果物の単位まで落とし込むことで、プロジェクトのメンバーは何をすればいいかがハッキリします。
計画の段階で書けることには限りがありますが、できるだけ詳細を明示するようにしましょう。
企画構想フェーズの終了条件
最後に企画構想フェーズの終了条件です。何をもって企画構想のフェーズが完了となるのかを計画の段階で明確にし、関係者と合意をとっておきます。
具体的には以下のような項目です。
- 想定されるすべての成果物の作成とレビューが完了している
- 次フェーズの計画策定が完了し、関係者からの承認を得ている
- ベンダーの選定と要員確保が滞りなく完了している
ここではあまり細かいことを書く必要はありません。要は計画で定めた各種タスクが滞りなく完了しているかを最後にチェックし、承認を得るための項目とお考え下さい。
ASIS分析・TOBE設計
計画策定とキックオフミーティングが完了したら、ようやくプロジェクトが本格的に稼働します。
ASIS整理・分析
ASIS整理・分析は業務担当者の暗黙知を紐解いて形式知にしていく工程です。すでに業務フロー図がある場合はそれを読み解いて事実確認を行い、必要に応じて最新化していきます。ない場合は、業務担当者にヒアリングを行い1から業務フロー図を作成していきます。
また、システムの費用対効果を測定するためにも、以下のような定量的な情報も集めておくとよいでしょう。
- 作業人数
- 作業時間
- 作業者の1時間当たりの単価
これらの情報を収集しておくことで、ソリューションを選定する際に費用対効果を想定することができ、より効果的なシステムを導入することができます。
TOBE設計・効果測定
現行業務を明らかにした後は、その業務のあるべき姿を設計していきます。余計な業務や時間がかかっている業務がないか、紙を減らすことができないか等あらゆる視点から現行業務を評価し、新たな業務を設計していきます。
業務を設計するうえで、いくつか有効的なフレームワークがあります。代表的なものはECRSです。
- Eliminate（排除：取り除く）：余計な業務は排除する
- Combine（結合：つなげる）：一緒にできる業務は1つにする
- Rearrange（交換：組み替える）：組み換えにより効率が上がる業務があれば交換する
- Simplify（簡素化：単純にする）：紙で1つずつ目検していたデータをIT化により簡素化する
他にも、業務設計を手助けするフレームワークはたくさんありますので、うまく利用しながらこれ以上ない業務設計にしていきましょう。
設計がある程度固まってきたら、効果測定を行うようにしましょう。
ASIS分析の際に収集した定量情報と新たな業務の定量情報を比較し、どれだけ効果が出るのかを測定します。
この測定結果はソリューション・ベンダー選定を行う際に、費用対効果を明らかにするのに必要な情報となります。
GAP分析・課題抽出
ASISとTOBEが明らかになったら、両者の間には必ずGAPがあるはずです。GAP分析を行いどのようなGAPがあるのかをリストアップしていきましょう。
システム導入プロジェクトでは、このGAPを埋める手段がシステムになるため、非常に重要な分析となります。分析の結果、システムを導入せず、業務を変えるだけでTOBEを実現できるとなる場合もあります。
また、このGAPはのち工程で作成するRFP（提案依頼書）にも盛り込まれ、ベンダー候補に配布されます。ベンダーの候補者はこのGAPの内容を確認し、自分たちのソリューションなら解決できそうと判断されれば、提案書を提示してくるわけです。
企画構想フェーズにおいて、非常に重要な分析になりますので、丁寧に遂行していくようにしましょう。
ソリューション・ベンダー候補検討
ソリューション・ベンダー選定はASIS分析を行っている段階で、ある程度の目星をつけていきましょう。
ベンダーの候補はロングリスト・ミドルリスト・ショートリストといった形で、段階を踏みながら最終候補まで絞り込んでいきます。
最終的にGAP分析までを行った結果、このベンダーなら良いソリューションを提案してくれそうという候補者にRFPを配布していきます。
まとめ
企画構想フェーズの業務要求定義の工程では、現行の業務分析を行い、あるべき業務の仕方を設計し、要求事項を整理していく工程です。
要求した事項すべてが実現されるかは導入するソリューション次第ですが、システム導入プロジェクトの方向性を決めていく重要な工程となりますので、課題を出し切り要求事項を整理していきましょう。
