構想立案タスクの進め方の概要

今回は構想立案タスクの進め方の概要について共有します。

構想立案フェーズにおけるタスク（作業）は構想立案タスクのみになります。

コンセプトとスコープを定める

まずは新しいシステムのコンセプトを整理します。

新しいシステムを導入・再構築する場合、必ず何かしらの課題（経営課題、業務上の課題、IT部門が抱える課題 等）があり、それを解決する手段としてシステムを導入・再構築することになります。

コンセプトとは「新しいシステムの導入・再構築を通じて、どんな課題を解決したいか」をシンプルにまとめたものです。

簡単な例で言えば、

のような課題に対し、

というような感じです。

一方、スコープとは対応する範囲を表すもので、「何を対象とし、何は対象外とするか」を明らかにするものです。

システム化する対象が多くなればなるほど、検討が必要な量や作成するプログラムの量などが多くなり、その結果コストが増え、スケジュール（工期）が延びていきます。
スコープを明確にしないと対象範囲が明確にならないので、システム化にいくら掛かるか、いつリリースできるのか、という重要なポイントが定まらなくなりますので、重要なポイントです。

コンセプトとスコープが整理できてきたら、システム導入・再構築による効果（メリット）を想定します。

例えば、

というようなものです。

見積を行いコストとスケジュールの見通しを立てる

次に、システムの導入・再構築にいくら掛かるか（コスト）、どのぐらい期間がかかるか（スケジュール）を算出します。

これらの見通しを立てるためには、見積が必要です。

見積には精度に応じて三種類のレベルがある

見積には、

の大きく3種類あります。

超概算見積は事例などを基にした参考情報

超概算見積は、大雑把にどのくらい掛かるかを見積もる手法で、正式な見積に対して±50%程度の誤差の範囲内ぐらいの精度です。

構想立案フェーズの途中の段階では、システムに対する要件が詰まっていない状態です。
この状態では精度の高い見積は難しいので、今後スコープや要件を詰めていく際の参考にする位置付けです。

超概算見積の方法としては、参考事例による算出と、既存システムの規模から算出する方法があります。

参考事例については、コンセプトと近しい事例（社内事例や他社事例）を参考に、時間をかけずに情報を集めます。
他社事例は、実績のあるSIerや製品ベンダーに情報提供を依頼すると教えてくれます。
他社事例はあくまで他社事例であり、100%全く条件が同じでない限り同じコスト・スケジュールにはなりませんが、「何もベースになるものがないよりはマシ」というぐらいの気持ちで、この時点では全く大ハズレにならなさそうなら良しとして先に進んだ方が良いと思います。

既存のシステムの再構築の場合は、既存システムのプログラムのステップ数を数えて、それを基に算出するやり方もあります。

概算見積は精度を高めた見積情報

概算見積は、正式な見積もりに対して概ね±20%以内ぐらいの正確さで見積もる手法です。

概算見積は、構想立案フェーズにて稟議をあげる段階で算出します。
比較的大きなプロジェクト（目安：20人月以上）だったり要件がブレるリスクの高そうなプロジェクトでは、要件定義工程が終わった時点で再度見直しをすることが多いです。

概算見積では、積み上げ法、オブジェクト法、ファンクションポイント法などで見積をします。

これらの見積法で見積をするためには、システムが具備する機能（画面・帳票・バッチ・インターフェース）は何か（それぞれの難易度はどうか）、DBやファイルにどんなデータを持つか、どんなアーキテクチャー（プラットフォームやミドルウェア、プログラム言語など）を採用するか、が定まっていないと見積もりができません。

確定見積はファイナルアンサーの見積情報

確定見積は、正式な見積であり、最終的な見積になります。

確定見積は、積み上げ法、オブジェクト法、ファンクションポイント法などで見積をします。
概算見積と手法は同様ですが、ベースとなる情報の精度が上がり、見積の精度も上がります。

確定見積では、各機能（画面・帳票・バッチ・インターフェース）の仕様（どんなデータ項目があり、どんな処理をするかなど）まで明確になっている必要があります。

小さなプロジェクトだったら要件定義（基本設計含む）の完了時点で算出が可能なことが多いです。一方、比較的大きなプロジェクトの場合は、仕様のブレによる見積への影響が大きくなるため、各機能の基本設計が終わって仕様が確定した基本設計の完了時点で見積もりすることが多いです。

見積をするためには見積の前提となる情報を揃える必要がある

3つのいずれの見積でも共通なことは、情報の粒度の差はあれど、見積をするためにはまず必要な情報（＝見積の前提）を揃える必要があるという点です。

つまり、いきなり「見積をする」ということはできず、

というような流れが必要です。

構想立案タスクでは概算見積を算定する

構想立案タスクにおけるコスト・スケジュールは、概算見積を算出すべく見積の前提条件を明確にしていきます。

ここでいう見積の前提条件とは、「どんなシステムをどのように作るか」と同義であり、

のような情報になります。
システムに対しては想定ベースで概要レベルの要件定義や設計を先に実施することになります。

プロジェクトによっては超概算見積レベルで終わらせる場合もあります。
しかし、上記のようなものを概要レベルでも作成しておけば、次工程の要件定義ではその内容をベースに詳細化・具体化する進め方が取れますので、プロジェクトをより安全に進めることができます。

費用対効果を検証する

効果と見積の結果を比較して、システムに投資する金額以上のメリットがあるかを確認します。

例えば、

というようなものです。

稟議の承認をする人（例えば経営層や部長クラス）の立場になって、承認しやすいように、シンプルで分かりやすい費用対効果になるように検討しましょう。

プロジェクト全体計画と次工程の詳細計画を策定する

費用対効果があることが示せればプロジェクトのGoサインが出る一歩手前までの状態になりますが、実際にきちんと進められなければ残念ながら絵に描いた餅です。

新しいシステムの導入・再構築に向けて、きちんとした計画があり安心してきちんと進められる状態になっていないと、稟議の承認者の方の立場からすると「本当に実現できるのか？」と不安が拭えないでしょう。

よって、新しいシステムの導入・再構築をどうやって進めるのかの計画、つまりプロジェクトの全体計画を整理します。

プロジェクト計画は一般的にプロジェクト計画書というものにまとめます。プロジェクト計画書には、

のような観点で整理して記載します。

また、プロジェクトが承認されたらプロジェクトがすぐに始まりますので、プロジェクト開始直後の作業、つまり次工程について詳細計画を作成しておく必要もあります。

例えば、要件定義工程のスケジュール（中日程・WBS）や各種管理表の用意したり、新たなプロジェクト参画者のために必要なもの（パソコンや座席、各種利用ツールのユーザーアカウントなど）やルールを準備をします。

稟議（伺い）をあげてプロジェクトを承認してもらう

稟議書に必要事項をまとめ、添付資料としてプロジェクト計画書やベンダー（SIerや製品ベンダー）の提案書を添付して、承認ワークフローを回付します。

それに先立ち、承認者の方にはこまめに内容を説明して意見をいただき、承認者の方が気になっているところは明確な解決策や方針を提示して、安心いただけるようにしておきます。
また、プロジェクト外の関係者の方々にも同じように情報共有やお願いしたいことを説明し、了承を得ておきます。

無事に稟議が承認されたら、プロジェクトが開始できるように進めます。

プロジェクトを進めるにあたり関係者と認識を共有するため、キックオフミーティングを実施します。
そして、プロジェクトの予定開始日から、プロジェクトの関係者が一斉に自分の与えられた役割に集中して前に進めていける状態にします。

まとめ

構想立案タスクでは、

• コンセプトとスコープを決める
• 効果と見積を算出して費用対効果を検証する
• プロジェクトの全体計画を策定する
• 次工程の詳細計画を策定する
• 承認者や関係者にプロジェクトの説明を行い、稟議を回付して承認を得る
• 次工程を開始するための準備を行う

が必要です。

より詳しいことが知りたい方は、私のバイブルである以下の大場さんの書籍を御覧ください。

この書籍にはプロジェクトをお客様視点・SIer視点両方から記載されており、全体像や具体的な成果物サンプル、運営方法が載っています。

私がプロジェクトマネージャー、統括プロジェクトマネージャーになった時もこの本の内容がとても役に立ちました。

ゼッタイ失敗しない！驚異のプロジェクト実行術 準備編～始める前に押さえておこう（日経BP Next ICT選書） Kindle版