要件定義が難しい理由として「要件は変化する」とよく言われますよね。「変化の激しい現代の経営環境においては」といった枕詞をつけて。しかし本当に要件はそんなに変化するのでしょうか。
僕は、要件は確かに変化するけれども、かといって、１年や２年でそれほど大きく変化するものでもないとも思っています。
もし根幹の要件がそんなにすぐに変化するのであれば、作ったシステムはすぐに使えなくなるはずではないでしょうか。現実はそうではなく、うまく作られたシステムは、改修は行いながらも何年も使い続けられるのです。
確かに例外はあります。プロジェクトの実施途上で外部環境が大きく変化したとか、トップが交代して方針が変わったというようなケースです。しかしこういった場合はプロジェクトをいったん仕切り直すべきであって、またその理由付けも可能です。
一般に「要件が変化して大変」というのはそういうケースではなく、要件は一応定義した積りなのに、プロジェクトの後工程に入ってから仕様変更要求の嵐に見舞われるといった状況を指しています。
ほとんどの場合、これは、プロジェクトの開始後に何か業務上の変化があって要件が変わったのではなく、
- 要件を単に見落としていた。
- 不十分な調査や誤解に基づいて要件を定義した。
- 要件は形だけはまとめられていたが関係者の合意形成ができていなかった。
ですから、要件変更の嵐に見舞われないようにするには、アジャイル派が言う「変化ヲ抱擁スル」だけでは不足だと思うのです（「変化ヲ抱擁スル」こと自体は良い考えだと思いますが）。抱擁しようとしたら相撲取りが出てきて押しつぶされたなんて笑えない冗談です。
やはり「変化ヲ封殺スル」アプローチも必要ではないでしょうか。
封殺スルといってもユーザに対して居丈高に「仕様変更凍結」と宣言することがすべてではありません。第一、関係者の多くが「要件は固まった」と認識していない段階で仕様変更凍結を宣言しても、結局、骨抜きにされてプロジェクト管理チームが威信を失うだけです。
だからその前に、
- プロジェクトで考えた新しい仕事の仕組みやEDPシステム仕様の合理性を、実際の取引のパターンに基づいて検証する。
- 新しい仕組みのもとで各部門の業務がどう変化するか、各部門に対して具体的に説明する。
- 各部門からフィードバックを受け止め、きちんと対応する。
これは手間も時間もかかる仕事ですからそれなりの人的資源と期間を覚悟する必要があります。実際問題としては、完全に要件が落ち着く前に見切り発車で開発に着手せざるを得ない場合もあるでしょう。その場合でも、上述したような検証・説明作業がある程度進んでいれば、どんでん返しを食らうリスクはぐっと減るものです。
また、先ほどアジャイル派のアプローチを批判しましたが、プロジェクトを小さなステップに区切るというアジャイル派の提案は真剣に受け止めるべきです。プロジェクト規模が２倍になると複雑さはたぶん３倍か４倍になります。そうすると（開発作業の大変さはさておいても）上述したような検証・合意形成プロセスに時間がかかりすぎることになりかもしれません。
いずれにしても業務要件やシステム要件が決められたということのみをもって要件定義の完了と見なすのではなく、「いったん決めた要件の検証と合意形成」をプロジェクトの重要作業ステップと捉えて取り組まないと（すなわち人的資源と期間を割り当てないと）、いつまでも「要件がコロコロ変わるんだよね」と言い続けることになるわけです。こうした要件の「変化」に対して、「凍結凍結」と声高に叫ぶだけなのも、逆に変化への追随能力の高さだけで勝負するのも、何かアプローチがズレている感じがしませんか？
