2．導入スケジュールの検討

開発規模（機能数、画面数、難易度など）に応じて、開発～導入～運用開始までのだいたいのスケジュールを出す。
内部的には、体制も決める。

スケジュールを顧客と調整する。必要に応じて、システムの内容を調整する。

この作業の前段階として以下の作業を行い、また、作業に必要な情報として以下のものや情報等を用意しておく。

この前の作業	事前情報、他
・企画案の検討・必要なハード／ソフトの検討・必要な運用・保守項目の検討	・企画案（概要～詳細）・（先方の）業務計画

開発スケジュールの検討手順

開発側として欲しい構築期間を算出し、「いつ以降なら稼働可能か」を判断する。

開発範囲と開発工程全体に対して、「何を作るか」「どんな作業が発生するか」をできるだけ細かく洗い出す。
（各工程毎／各機能毎／各画面毎など）
それぞれの作業に必要な時間数／日数を想定する。
それぞれの作業に対する時間数／日数を積み上げ、全体の必要日数（月数）を計算する。
構築を担当するメンバーの人数・スキルを判断する。
以上を考え合わせ、トータルで「○人体制で○日（○ヶ月）程度」という構築期間を算出し、開発スケジュールを決定する。
- 総工数30人月の開発プロジェクト：
  3人体制で10ヶ月、5人体制で6ヶ月、最初の2ヶ月は4人体制で後半は5人体制で4ヶ月半、．．．
スケジュールをドキュメント化する。（Excelなど）

見積書と同様にスケジュールも、いきなり正式書類として出す必要はない。  
まずは「大まかな流れ」として、メモ程度の資料を出して反応を見る。  
調整後ほぼOKとなった段階でマスタスケジュールとする。  

スケジュールの折り合いがつかない場合の調整手段

ユーザとして「○日までに本番運用させたい」という経営的・業務的事情がある。
それと、開発側から出したスケジュールが合わないことがある（というか、最初の段階ではまず合わない）。
ユーザの要望を聞きながら、随時調整していく必要がある。

必要な機能を絞り込み、今回開発分を縮小する。
段階的な開発を検討し、「１次分はここまで、２次分はここまで」などとする。
ユーザの要求を聞き、過去の開発資産を流用するなどして開発効率を極力上げる。
（ただしこれは調整の有無にかかわらず、プロジェクトとして常にやらないといけないこと。）
体制を増やす。
とにかくがんばる。

この作業で以下の成果物を出す。または完成イメージの状態にする。それをこの後の作業につなげる。

成果物、完成イメージ、他	この後の作業
・システム企画に対応する導入スケジュール	・提案

新システム導入のタイミングは、ユーザ側の業務上／経営戦略上の都合により、期日を動かせない場合もある。

納期（導入日）は契約書にも明記されるものであり、遵守しなければならない。

スケジュール表に挙げた作業項目は、それぞれ「何をどこまでする作業か」を具体的に説明できるようにしておく。

プロジェクトの進行状況や、ユーザ側の業務上・経営上の事情によっては、プロジェクト途中での調整や見直しもあり得る。

システムのある機能について「それを完成させるためには、どんな細かい作業が発生するか」という洗い出しは、  
知識や経験がないと、なかなか難しい。  
また、システム開発のある作業について「その作業には、何時間／何日くらいかかるか」という想定も、同様。

見積は本来、営業、プロジェクトマネージャー、上級ＳＥレベルの仕事。  
新人がすぐにこういった作業にたずさわることは、ほとんどない。  
ただし、仕事を取るため、プロジェクトを運営するためには、こういった作業が必要になることを意識しておく。

（プロジェクト全体ではなくても）個人レベルの作業時間数の想定などは、すぐにでも必要になる感覚。
これは「自己管理」の一部なので、「自分が、どんな作業を、どの程度でできるか」を常に意識すること。

results matching ""