システム開発の手法により期間が異なる
開発期間の目安
開発期間は対象の基幹システムのスコープや仕様などによって大きく異なるため、具体的な目安を出すことは難しいというのが結論です。小規模なものであれば1～2カ月、大規模なものであれば数年かかることもあります。
開発手法による違い
開発期間は採用するシステム開発手法によって異なります。ウォーターフォールモデルでの開発は必須要件の機能を全て一度のサイクルで開発するため期間は長くなる傾向にありますが、アジャイル開発モデルは小さなサイクルを何度も繰り返す手法になるため、一つ一つの期間は短くなります。
ウォーターフォールモデル
システム開発の工程を、いくつかのフェーズに分けて管理する開発手法です。要件定義、設計、実装、テスト、運用保守、というフェーズに分けることが多く、基本的には各工程で計画されたタスクを全て完了させてから次のフェーズに進みます。
工程ごとの役割とタスクが理解しやすくなるため作業効率は高くなりますが、仕様変更が発生した場合、その対応が難しくなるというデメリットがあります。
アジャイル開発モデル
仕様変更が多発するシステム開発に効果的に対応できる開発手法です。一度に行う開発を短期間で実施できるように細かく分け、小さな開発を何度も繰り返していくことでシステムを完成させていきます。
少しずつシステムに機能の追加や修正を行っていくスタイルのため、途中で要件の追加や修正の要望があった場合も柔軟に対応できます。
期間を見積もるときにすべきこと
システム開発のプロジェクトでは不測の事態が発生することも多く、期間の見積は非常に難しいタスクです。しかし、ある程度精度の高い見積を行う方法はいくつか存在します。
トップダウン見積（類推見積）
過去の似たプロジェクトを参考に各タスクの期間の見積を行う方法です。簡単に実施できるということがメリットですが、正確な見積ができないということがデメリットになります。
複雑なものや大規模なものである場合は特にこの方法で見積を行うことは難しくなります。
また、過去に類似のプロジェクトが無い場合には使えません。精度の高い見積を行うことはできませんが、トップダウン見積は特にプロジェクトの初期段階でよく利用されます。
まず概算の見積をこの方法で行い、その後より詳細な見積が求められる段階で他のより詳細な見積方法に切り替えられます。
パラメトリック見積
過去のプロジェクトのデータを参考に、パラメーターを設けてそのタスクにどのくらい時間がかかるのかを計算する形で見積を行います。係数見積とも呼ばれています。
例えば、過去のプロジェクトで開発に1日かかった入力画面と似たような画面を今回のプロジェクトで10個作成することになった場合は、1日×10個で10日かかるという見積を行います。
過去のデータを利用するという意味でトップダウン見積と似た方法ですが、パラメトリックは過去のデータをもとに計算して見積を行うため、やや精度が高い具体的な見積を行える場合が多くなります。
工数積上（ボトムアップ）
プロジェクトで必要なタスクを細かく切り分けた後で、その一つ一つに対して作業時間を割り出し、その時間を積み上げることでプロジェクト全体の期間を算出する形で見積を行います。
通常はWBS（Work Breakdown Structure、作業工程を管理する手法）をもとに見積を行い、トップダウン見積、パラメトリック見積と比べて精度の高い見積を行うことができます。
また、場合によっては細かく分けたタスクを担当者に割り振った上で見積を行ってもらうことで、さらに見積の精度を上げていくことも可能です。また、必要なタスクの洗い出しを詳細に行うため、タスクの抜け漏れによる見積の精度の低下も防ぐことができます。逆にデメリットとしては、見積の作業に時間がかかるということが挙げられます。
基幹システム開発の流れ
基幹システム開発のプロジェクトはいくつかのフェーズに分かれています。
要件定義フェーズ
クライアントの要望やその背景などをまとめるフェーズです。通常は要求内容を正確に理解しドキュメント化をします。プロジェクトの背景と目的、用語の定義、業務の概要、現状の課題と改善方針、システムへの要件、などシステムを開発する上で必要となる事項をまとめます。
設計フェーズ
求められている要件をどのように実現するかを決めるフェーズです。どのような機能を作るか、機能が実行された時にシステムの内部ではどのような処理を行うか、ユーザーが操作する画面のデザインはどのようなものにするか、などシステムの仕様を決定していきます。複数のシステムを導入する場合は、その連携方法に関しても設計を行います。
実装フェーズ
システムを開発する（プログラミングなど）フェーズです。設計書に基づきプログラムを作成します。計算ロジック、API、画面、バッチなどシステムの機能に加え、必要であれば旧システムからのデータ移行用プログラムなども開発されます。
テストフェーズ
システムが想定通り動作するかどうかを検証するフェーズです。通常は、単体テスト（機能単位などで実施するシステム観点の検証）、結合テスト（モジュールなどの結合部分の検証）、総合テスト（開発者が行う業務観点の検証）、UAT（ユーザーが行う業務観点の検証）など、確認観点が異なるテストをいくつか実施することで、効率的に品質を高めていきます。不具合（想定通り動作しない箇所）が発見された場合、その修正と再テストを実施します。
導入フェーズ
システムを実際の業務で使用できる状態に持っていくフェーズです。本番用のインフラの構築、初期設定、マスタデータの投入、旧システムがある場合はデータの移行作業、などを実施します。また、ユーザーへのトレーニングなどを実施することもあります。
見積もった期間で間に合いそうにない場合には
プロジェクトを当初の計画通りの期間で完了させることは、難易度が高いものになるため、遅延の主な要因を知っておくことが重要です。遅延の要因となる可能性が高いものを理解しておくことで、影響を緩和することは可能です。
見積のミス
見積の精度が悪かったことが原因で発生する遅延は、特にプロジェクトの規模が大きい場合に発生頻度が高くなり、日数も大きくなります。そのため、規模が大きい場合は特に注意して正確な見積が必要になります。
他の担当者のレビューを入れる、経験が無いタスクの見積は専門の担当者に依頼する、タスクの担当者自身にも見積を行ってもらう、など見積の精度を上げる工夫を行うことが大切です。
アサインのミス
プロジェクトのメンバーにタスクを割り振る際に、知識や技術が不足している担当者をアサインしてしまうことも遅延につながります。どのような知識や経験が必要か正確に理解し、かつ担当者の技量をしっかり把握したうえで、アサインを決定していくことが重要になります。
進捗管理のミス
遅延が発生していることにできるだけ早く気付ける環境を作ることが大切になります。プロジェクトマネージャーが定期的、もしくは適切なタイミングで各担当者の進捗を確認し、遅延が発生している場合は担当者の交代など何らかの対策を検討し実行することが重要になります。
外注管理のミス
プロジェクトの中で外注する部分がある場合は注意が必要になります。手遅れになってから遅延を報告されないようにすることが重要です。定期的に進捗を報告してもらうことも対策の一つですが、社員とは異なりコミュニケーションがとりづらいこともあるので、実績のある業者に委託する、一緒に作業を行ってもらう、など、状況に合わせた適切な対応を取ることが効果的です。
まとめ
今回の記事では、基幹システムの開発期間について解説しました。コンサルティング案件などを探している方、事例を知りたい方は、ぜひfoRProまでご相談ください。