プロジェクト計画の範囲は、ITベンダーにより若干異なりますが、

基本設計からシステムリリースまでの計画を立案することをプロジェクト計画として説明します。

 

システム開発の工程

一般的に普及している、ウォーターフォールモデルのシステム開発工程は以下の工程から成ります。
・外部設計（基本設計）
・内部設計（詳細設計）
・製造（プログラミング）
・単体テスト
・結合テスト
・総合テスト（システムテスト）
・運用テスト（ユーザテスト）
・システム移行（システムリリース）
・運用/維持保守

上記の工程の中からシステムリリースを行うまでをプロジェクトとして定義し、
・スケジュール
・要員計画
・成果物
を立てていく事を、プロジェクト計画と言います。

他にも色々な計画を立てている会社はありますが、必須と考える計画の立て方について説明していきたいと思います。

 

プロジェクト計画は非常に重要で、「プロジェクトの成功はプロジェクト計画の内容で決まる」と言っても過言ではありません。

金融システムの開発は、税制改正などの対応があり、リリース日が変更できないプロジェクトも多くあります。
無理なスケジュールや要員計画を立てるとプロジェクトが途中で破綻する事になり、最悪の場合はリリース延期となり当該業務が行えなくなる事態になります。

また、開発計画やテスト計画を誤った場合、低品質なプログラムが作られ、テスト工程で大量の不具合が発生し、テストスケジュールに遅れが発生しますし、テスト計画が誤っていた場合は、リリース後のシステム品質の低下と言う事態に発展します。

 

スケジュール策定

ほとんどの場合はリリース時期が決まっていると思います。

法改正などの制度対応ならリリース日を動かすことは出来ませんし、システム更改や新機能の追加などでも利用者の希望日がシステムリリース日として設定されているので、プロジェクト計画を立てる際に工程毎のスケジュールを合わせた日をリリース日にすると言う事はほとんどありません。

従って、リリースから逆算してスケジュール化していく事になります。

基本的なスケジュールの割り振りとしては、全体の日数を１０としたら、
・外部設計：２
・内部設計：２
・製造：１
・単体テスト：１
・結合テスト：１．５
・総合テスト：２
・運用テスト：０．５
の比率をベースにスケジュール化します。

注意点としては、各工程の期間を重複させないようにスケジュールを引いていきます。

理由は、「各工程の期間が重複する　＝　スケジュール設定に無理がある」となるからです。

実際に開発が始まると、各工程の中で遅れが発生する事があります。
その際に「一部の機能の開発工程を重複させることでスケジュールを守る」と言う調整を行います。

例えばプロジェクト計画の時点で、外部設計の完了した機能から内部設計に入ると言う計画だと、
・機能単位のスケジュールを精緻に算出しなければならない
・機能間の設計調整を終える事が出来ているのか？
と言う見極めを行う必要があります。

細かい部分まで綿密に計画が立てられれば良いのですが、プロジェクト計画の段階ではプロジェクト要員の配置やスキルも粗い状態なので、プロジェクト計画段階であまり細かい部分まで計画を立てるのは意味がないと考えています。

開発期間が短く各工程を重複させなければスケジュールが成立しない場合、
・リリース時期の調整を行う
・要員の追加を行う
・実装機能を削る
などの調整を行った方が良いでしょう。

と言いつつも、スケジュールを立てる際は要員計画が立っていないので、まずはプロジェクトの希望としてのスケジュールを立てる事になります。

スケジュールを立てる際は、「外部設計、内部設計」と各工程の「大日程計画」スケジュールを引き、大日程計画から中日程計画、小日程計画と、小さな作業に落とし込んでいきます。

各工程の前後には、準備と評価の期間も忘れずに引きます。

準備期間は前工程と重複しても問題ありませんが、評価は後工程の前に終わらせるスケジュールを引いていきます。

小日程までスケジュールを引くと、プロジェクトスケジュールの完成です。

これをプロジェクトの「マスタースケジュール」としてプロジェクト全体に周知します。

この後作成する要員計画やテスト計画は、「マスタースケジュール」に基づいて作成します。

 

要員計画

マスタースケジュールが出来上がれば、要員計画を立てていきます。

要員計画は、システム規模と開発スケジュールが決まれば計算で作ることができます。

ほとんどの会社は、自社のシステム開発の生産性を把握していると思うので、

システム規模　÷　生産性　＝　必要な要員数

で割り出せます。

 

念のために生産性の説明をすると

システム開発を行う際、一人当たり1ヶ月で開発できる規模

になります。

もし、生産性を計算したことがないと言う場合は過去のプロジェクトの実績から以下の計算で出すことが出来ます。

全体の生産性　＝　システム全体の規模（step数）　÷　対応した人数　÷　開発期間（月数）

各工程の生産性　＝　システム全体の規模（step数）　÷　求めたい工程を対応した人数　÷　求めたい工程の期間（月数）

出来るだけ沢山のプロジェクトを計算し、その平均値を出すようにするのがポイントです。

要員数が決まれば、プロジェクトの性質を考慮し、人数の調整を行います。

基本的な考え方としては、
・新規開発：全体的な生産性は高くなるが、外部設計の生産性は低くなる。
・システム改修：全体的な生産性は低くなり、特にテスト工程の生産性は低い
と考えて要員計画の調整を行います。

多くの会社は、新規開発とシステム改修の生産性を分けて管理しています。
これから生産性を出す場合、新規と改修を分けて計算した方が良いでしょう。

また、要員をどのように確保するかも生産性に関わる部分になります。

常に一緒に仕事をしている人を多く集められるのなら問題ありませんが、新規要員を導入する場合は生産性の低下は避けられません。
新規要員が多いプロジェクトの場合は、要員数を1割程度割り増しして計画する方がよいでしょう。

 

成果物の定義

マスタースケジュールと要員計画を決めると共に、成果物の定義を行います。

外部設計からリリースまでの間に作成するドキュメントや計画書、テストのエビデンスで何を作成するのかを明確に定義します。

基本的には、今までの開発で作成した成果物を踏襲する事になりますが、プロジェクトとして納品する成果物を、ユーザと合意するためにも、成果物一覧として作成します。

成果物の種類だけではなく記載レベルも合意すべきでしょう。

過去に作成した成果物をサンプルとして出せるのであれば、ユーザに提示し、記載レベルの合意も得るようにします。

想定していない成果物を作成する場合、要員計画やスケジュールの調整も合わせて実施します。