目次
システムの遅延
システム開発の遅延理由として、
「システム化目的不適当」「RFP内容不適当」「要件仕様の決定遅れ」「要件分析作業の不十分」「開発規模の増大」の要求定義・要件定義に関連する5項目で遅延理由の半数を超えていることがソフトウェアメトリックスの調査で報告されています。システム開発の成功に要求定義・要件定義が重要であることがわかります。
要求定義
要求定義は実際に利用するユーザーの目線でゴールを達成するためにシステムがどのような振る舞いをしてほしいのかを定義づけていくことになります。
要求定義はどのようなことを記載するべきか4つの項目で考えていきます。
・システム開発のゴールと手段
どんなビジネス要件を達成したいのかというゴールと、達成するためにはどのような手段が必要なのか
・システムのリリース時期
┗要求定義では開発にかかる期間ではなく、ビジネス要件を達成すべき時期と考えた方が良い
・システムの開発体制
┗受注側は、上流工程担当チーム、プログラム実装開発チーム、ネットワーク担当のインフラチーム、テストチームなど様々
・リリース後の運用方法
┗誰がどのように運用すべきか業務担当が手動で管理・運用してくのはどの部分かツールはどうするのか認識を合わせる必要がある
要求仕様書は発注側の要望を受けて受注側が作成し、要件仕様書を作成する前には中側と受注側に認識の相違を確認する上で大切なものです。
要件定義
要求定義の合意が取れた段階で要件定義書を作成します。
要求に対して実現するためにどのような機能や性能が必要となるのかを整理していくことになります。
要求定義書には何を含めれば良いか、内容自体はシステムに重点を置いたものです。
・システム開発の全体方針
┗システムを導入することになった背景や、導入する目的、システム化の概要や範囲などについて明確にする
・ビジネス要件
・システムの機能要件
┗RFPや要求定義を元に、必要な機能をリスト化していくことから始める
・システムの非機能要件
・性能目標
・セキュリティ要件
・運用管理
作成した要件定義書を設計担当に引き渡す際には資料を渡すだけではなく説明する機会を持ちたいです。
読み合わせの中で、発注者と合意に至った経緯、発注側の温度感や印象を伝えておくことも重要です。
まとめ
開発が進んでいく中で、発注側のビジネス上の方針に変更が入った、あるいは予定していたシステムを変更せざるを得ない問題が発生したという状況は実際のシステム開発ではよくあるようです。
発注側のビジネス方針が変わったのであれば、変わったことでシステムのどこにどのような影響があるのか確認が必要です。
システム実装上の問題が出たのであれば、ビジネス上のどこにどのような影響が出てくるのかを確認していかなければなりません。
どちらの事象にも注視しながら制作を進めていく必要がありそうです。
