システム化計画プロジェクトのポイント！！（その10） 〜つまらないIT仕事をワクワクさせる
「システム化計画プロジェクトのポイント」シリーズの第10回目では、前回に引き続き「新システム構築計画の策定」の進め方について説明していきましょう。
- システム化の目的の定義
- 新業務/システムの概要設計
- 新システム構築計画の策定
「新システム構築計画の策定」の中では以下のようなタスクがあります。
- 開発工程の定義
- 実行プロジェクトの定義
- 開発工数の見積もり
- 開発計画（スケジュール）の策定
- 推進体制の定義
- 課題に対するアクションアイテムの整理
今回は上記「開発工数の見積もり」と「開発計画（スケジュール）の策定」の２つのタスクを説明します。
３．開発工数の見積もり
開発工程、実行プロジェクトの定義に引き続いて次に、全体の開発規模、開発工数などを見積もっていきます。要は、標準化された開発工程で、実行プロジェクトが推進されていく際に「どのくらいの人数」「どのくらいの期間」の計画にすればよいかを、ここで見積もるわけです。
開発工数の見積もりには以下のカテゴリーがあります。各カテゴリー毎に見積もるアプローチが異なります。
- アプリケーション開発工数
- インフラ基盤導入構築工数
- 業務対応工数
- プロジェクトマネジメント工数
まずアプリケーション開発工数です。システムの規模を見積もる方法はいくつかあります。例えば、現行システムのステップ数から推定、他の類似システムの事例から推定、機能数から今までの開発経験値で求める方法、ファンクションポイント法により算出するなどです。
後に行くにしたがって精緻で時間がかかる方法となります。どの開発規模算出方法もそれなりにSI経験があるプロフェッショナルが行うべき作業となります。
また特にFP（ファンクションポイント法）などは機能、データ、インターフェース、I/O数などがある程度「新業務/システムの概要設計」で分析されている場合は、合理的な算出法となります。
ここではFP法の詳細については説明しませんが、もしご興味があれば、FP法についての書籍等も出ていますのでその算出ロジックを勉強してみてください。
システムの開発規模（通常、ステップ数またはFP数など）が出されたらここからそのシステムを開発できるシステムエンジニアの数を算出します。
ここで使う数字としては、SEの生産性という数字が必要となります。今までの開発案件についての実績があれば、過去の生産性に基づいて行えますが、ない場合には、業界一般的な数字を使いましょう。
このように自ら規模を見積もるのと同時に、この段階で専門のSIベンダーに見積もりを取らせる方法もあります。
その場合は、「新業務/システムの概要設計」のアウトプットを使ってRFI(Request for Information)またはRFP(Request for Proposal)を作成して、SIベンダーに提示することが必要となります。ただ、このSIベンダーによる見積もりの場合は、以下のようなメリット、デメリットがありますので、上手く行いましょう。
＜メリット＞
- 類似開発事例も多いSIベンダーであれば信頼がおける
- SIベンダーからの見積もりはそのまま、構築の契約交渉につなげることができる。
- RFI,RFPにより、見積もり以外の参考となる情報やアイデアが得られる。
＜デメリット＞
- 基本的にSIベンダーのマージンやリスク率が上乗せされているため高価となる。
- または全く逆に、あるSIベンダーの戦略的思惑がある場合には実際の開発コストよりも低い（戦略的な）価格が提示される
- SIベンダーの見積もり根拠は明かされないかあいまいにされることが多い。
４．開発計画（スケジュール）の策定
全体の開発工数（人月）が計算されたら、それを現実的なチーム編成、人数をで割って作業期間をだしましょう。その期間を工程ごとに横に並べたものが開発計画（スケジュール）のドラフトとなります。
具体的にはここまでに定義した以下の単位毎の作業期間をだしていきます。
実行プロジェクト×開発工程
例えば「Aアプリケーションシステム構築プロジェクト」の「基本設計」にどれくらいの体制×期間を置くのかを決めていきます。
複数アプリケーションがある場合はどのような順番で行うか、またはいっそ並行して行い、テストのタイミングを一緒にするかなどを決めていきます。
以上のように、いろいろと考えるべき要素があるので、まずはドラフトの開発計画（スケジュール）を早めに作成して、それを関係者でレビューしてチューニングしていくような作業にすると良いと思います。
最後にスケジュール上、以下のような理由で時間がかかりそうな箇所に遅延した場合にリカバリーするためのバッファ期間を置いて行きましょう。
- 社内のコンセンサスをとるタイミング
- リスクや難易度が高い業務
- ユーザーレビュー（ユーザーは時間がとれないことが多いため）
- システム開発発注にともなうベンダーセレクション、ベンダー契約手続き
これで出来上がりです。ここまでいくと、新しいシステムの開発のイメージが湧いてワクワクしてきますね。
とにかくビジュアルに線引きすることが大事です。皆がイメージを共有するためにも、開発計画（マスタースケジュール）を早めにつくりましょう。