要件定義の怪物、ビジネスルールをいかにして仕様化するか？

要件定義の中で最も難しいのはビジネスルール（お客様の業務における固有のルール）の仕様化ではないでしょうか。要求やその理由が明確になれば仕様を導出できます。しかし、その仕様化する上で、ビジネスルールを検証可能な仕様に落とし込めないと、後々になって大きな問題となります。

例

ある監視対象装置には制御イベントAと制御イベントBがあり、システムとして操作できる必要がある、という要求があります。
制御イベントAには関連パラーメタ（a1, a2, a3・・・）があり、制御イベントBにも関連パラメータ（b1, b2, b3・・・）があり、各制御イベントは関連パラメータの各値によって動作する仕様が異なります。

各制御イベントに対するそれぞれの仕様は明確にしたとして、要求にはさらりと「制御イベントAと制御イベントBは同時実行を可能とする」と記述があります。さらにこの同時実行に関する備考または箇条書きで「a1とb1の値が等しく、装置のxxxパラメータが〜な場合は・・・」といくつかの動作仕様の補足があったりすると、それはもう「怪しい匂い」です。

これを箇条書きの文章レベルでそのまま仕様とすると、一見仕様としては明記しているように感じますが、暗黙的な仕様が明確にならないままになってしまいます。結果として、明記したパターンだけは動作するものの、想定していないパターンが発生した時に問題が発生します。

仕様として書いたパターンは試験もしているので動作しますが、テストパターンを抽出する段階で想定していないパターンについて検討できていなければ、顧客の受入試験で問題が発覚します（テストパターンを抽出する段階で気づいて設計に反映させたとしても、後戻り工数は大きなロスとなります）。「それは仕様として明記していません」という理由は顧客の運用を踏まえると許容されることはなく、受入試験の段階で設計の見直しが発生し、膨大な工数を消費することになってしまいます。

さらに、受入試験段階では時間もないことから、その対応が問題となったパターンだけを通すような対応になりがちであり、結果としてモグラ叩き的に問題が発生していくという、非常に苦しい状況に陥ります。

ではどうすれば良いか？

結論は要件定義の段階で、この暗黙的な仕様も含めて検討し、仕様化する必要があります。そのためには検証可能なマトリクスによる整理が必要になります。入力条件と出力パターンの組み合わせで整理できるのであればデシジョンテーブルを、状態を考慮した整理が必要であれば状態遷移表と状態遷移図を使います。マトリクスで整理できなければ実現不可能という強い意志で、要件定義での仕様化が必要不可欠です。

お客様も最初から全てを整理できていない

システムを使うお客様は業務についてのプロであり、システムを開発する側よりも当然業務について熟知しています。しかし、普段よく行う業務については知っていても、たまにしか行わない業務、限られた人しか行わない業務、通常は考えられないイレギュラーなパターンについては、熟慮すれば分かるかもしれませんが、常に整理して理解できているとは限りません。このため、要求にも想定されるパターンしか文章化されません（多くは「〜なパターンは考慮すべき」という箇条書きとして現れます）。しかし、システムはあらゆるパターンについて対応できる必要があります。予期しないヒューマエラーや悪意ある操作など、お客様も想定していなかったパターンにも対応できる必要があります。

だからマトリクスによって一緒に検討すべき

マトリクスを開発する側で作成して整理を行い、お客様にも一緒に検討、検証して頂くことで、ビジネスルールを仕様化することができます。またこの検討を一緒に行うことの効果として、お客様の業務が想像以上に難しいことが双方で共有され、機能の実現性の難易度をお客様にも理解して頂くことができるため、結果としてスケジュールや見積りの交渉も、適切に行うことができます。

私はこんな取り組みをしています！というご意見を募集します。

このビジネスルールの仕様化を要件定義段階で正しくできれば、日本のシステム開発はもっと成功すると思います。そうなればお客様、システム開発者、双方にとって幸せなことではないでしょうか？上記のように書いてみましたが、これだけが正解ということはありません。ぜひ「私はこんな取り組みをしています！」というご意見があれば教えてください。