システム開発
要件定義
「何を作るか」ではなく「何が決まっていれば作れるか」を決める工程。
業務要件・機能要件・非機能要件を文書にする。重要なのは網羅性より、誰が決めたかが記録されていることである。後で揉めるのは仕様の中身ではなく、誰がいつ決めたかが分からない箇所だ。
非機能要件（性能・可用性・セキュリティ・運用）は忘れられやすいが、後から追加すると設計をやり直すことになる。
よくある誤解
「要件定義はベンダーがやるもの」と考えている発注側が多いが、業務をどう変えるかは発注側にしか決められない。ベンダーができるのは、決まったことを実装可能な形に翻訳することまでだ。決める人が会議に出てこないプロジェクトは、この工程で必ず止まる。
関連する用語
RFP
ベンダーに提案を求める文書。見積を比較できる形にするための道具。
受入テスト
発注側が「これで業務が回る」と確認する最後の工程。バグ探しの工程ではない。
基幹システム
止まると事業が止まる業務を担うシステム。販売・生産・在庫・会計など。