スケジュールはリスクを考慮した実現性だけではなく完成までの時間が重要
プロジェクト計画書策定の最後はスケジュールの策定となる。ベンダーには、一括リリースと分割リリースの両方で検討してもらった。共通して次のような回答があった。
- 一括のメリットは、ベンダー側の作業効率が良いので、投資を抑えられるとのことだった。
- 分割のメリットは、一括に比べてテスト工程が割高になるが、リスクを抑えられるとのことだった。
ベンダーからの提案とは別に、D社小林から、3つの助言があった。
- S社の場合は、一括と分割の良いところを活かした形式が良い。目玉となるシステムとデータ構造として中心としたアーキテクチャの部分を先に実施する。分割型である。アーキテクチャを最初に決めることで、分割のデメリットを極力抑えることができる。また、アーキテクチャは本番運用後の優位性を維持するための重要なものでもあるので、最初に決める必要がある。
- 時間軸も考慮する。要件は時間の経過とともに変化（陳腐化）する。IT投資は使うことで意味が出る。
- 要件定義は長めに取る。何をIT化するのか、どのような要件とするのか、業務は流れるのか？等々、確認する。スケジュールに追われると妥協した要件となり、開発することが目的になってしまう。
アドバイスを考慮して検討した。最初は顧客情報の統合による顧客サービス向上とアーキテクチャを対象とした。次は物流にすることとした。
また、既存システムの凍結時期を要件定義終了の1ヶ月前とした。理由は、既存システムではあるが、リニューアルするシステムが運用開始するまでは利用するため、既存システムの凍結までに必要な要件の中には、リニューアルするシステムの要件に必要なことがあるためである。
【連載】スケジュール
体制のポイントはスキル不足を外部から補う
体制は、山田マネジャー、佐々木マネジャー、部門から選ばれたプロジェクトメンバー、情報システム部門、D社小林を中心メンバーとした。
しかしながら、プロジェクトメンバーは、通常業務をしながらであるため、出来るだけ部門に関係するタスクのみ配慮した。
同様に情報システム部門も、既存システムの保守があるため、100%集中することは期待できない。また、S社の社員として経験値があるため、業務を知っている反面、発想が既存業務から離れることが難しい。つまり、要件が今と変わらない懸念がある。このため、人員不足解消も含めて、ITコンサルタントに情報システム部門としてプロジェクトメンバーとして参画してもらうこととした。
これがとても重要なことだが、COO渡辺から、経営会議でプロジェクトメンバーは、現行業務で忙しいのはわかる。一時的に派遣を採用しても良いので、プロジェクトメンバーのプロジェクトの対する時間を確保すること、責任を持って要件を決め、当事者意識を持って行動するように指示をした。
また、プロジェクトメンバーには、プロジェクト業務を評価対象とするように付け加えた。
コメント