仕様変更対策

  • 仕様書は契約書のようなもの。詳細に記述し、委託者と受託者が十分な時間を取って確認する。
  • 要件確認リストを使い、可能な限り要件漏れを無くす。
  • 要件定義書をユーザと共にレビューする。
  • 早期の段階でプロトタイプを作り、イメージを確認する。
  • 変更が見込まれる機能は可変化する。
  • 現場を見学し、現場の声を聞く。出来れば業務を体験させてもらう。
  • 事前に技術検証をしておく。
  • 不明点はユーザに必ず確認を取る。その際、解決策をいくつか用意しておく。
  • 全体の整合性はレビューで防ぐ。
  • 余裕があれば、仕様説明を兼ねて、レビュー会にプログラマーを参加させる。

プロジェクトチェックリスト

  • 顧客信用情報
  • 契約書(基本・個別)
  • 見積書
  • 注文書・注文請書
  • RFP
  • プロジェクト名
  • 背景・目的
  • 概要
  • 業務フロー
  • システム構成
  • 規模(期間・費用・工数等)
  • 納期
  • 納品物
  • マスタースケジュール
  • 体制
  • 機能要件
  • 性能要件
  • 品質要件
  • ハードウェア
  • ソフトウェア
  • ネットワーク
  • 開発言語
  • リスク

平時と有事

平時は役割分担に従い、担当の職責を全うする事が優先されるべきであるが、問題発生時は垣根を越えて、関係者を巻き込み、組織的なに対応を行うべきである。問題を個人に押し付け、見殺しにするような事があってはならない。