要求の品質

　BABOKの最重要ポイントは、要求の品質にある。

　そもそも論をぶちあげて責任韜晦するなら、まだ賢いほう。ふつうの顧客は、「要求部門が違うと言うから」「書いてないことはこっちのフリーハンド」などと逆ネジを食い込ませてくる。要するに、仕様書には無いが無償（ただ）で対応しろ、という圧力だ。テストフェーズ後半か、シミュレータでもエミュレータでもなく「本当に使う人」「本当に接続するシステム」が使い出す頃に出てくる。いわゆる、宴もたけなわの頃だ。不備、誤読、漏れ抜け、ほころび、食い違いを、堂堂と「バグ」と読んではばからない。昔は殺意が湧いたが、これでかなり丸くなった[怒らないこと]（とはいえ、ここでは仏教ではなくBABOKからのアプローチを続ける）。

　しかしながら、反論が困難なことも事実。「仕様書に無い」「要件定義に書いてない」「そもそも要求すらない」という反論ができるほどトレーサビリティが無いのだ。もちろん要件定義書っぽいドキュメントは存在するが、網羅性も、完全性も、一貫性も、実現可能性も、具体性もないし、正確でもなく、修正もされておらず、検証もできない有様。どっかのコンサルティングファームが書きちらしたあるべき論が延々とコピペされた代物で、そいつをもう一段ブレークダウンした「要求」が無いのだ。

　どう"あるべき"かではなく、どう"したい"のか、こいつを明確化しないままプロジェクトをムリヤリ進めた連中は先月栄転してもういない。よくプロジェクトが廻ったね? 不完全な部分や曖昧で不正確なところはどうやって明確にしたの? 分からなくなる都度に訊いたの? あたり～、SEから、プログラマから、テスタから、（ひょっとすると）移行、運用、接続先システム担当者、マニュアル作成者から、「質問」が出るたびに、メールで問い合わせる。粒度もタイミングも範囲もバラバラで飛び交わされた膨大なメールこそが、「要求」になる。さもなきゃ会議室や電話で一方的に通告される「顧客の思いつき」が「要求」と化す（みんなの心の中にある仕様やね）。

　当然の結果、やたら詳細な要求（ユーザインタフェースまわりのチェックとかボタンのデザインとか）と、曖昧なままの部分（エラー系とか接続先システムのインタフェース、あとパフォーマンスｗ）と濃淡が出る。互いに矛盾する動作も、もとは膨大なメールのどこかにあるそれぞれの「要求」を現実化したもの。そのうち、SEも、プログラマも、テスタも、移行も運用もマニュアル作成者も（オペレータさえ！）、「いまある動きが正しい=プログラムが仕様です」と言いだす。矛盾した要求を検証しないまま実現しようとする「ひずみ」「ねじれ」をなんとかするためのバッチジョブ、プログラムの修正、手運用、虎の巻が生まれる。

　どうしてこうなった? これは、ドキュメントの品質でもプログラムの品質でもテストの品質でもない、要求の品質が貧弱、貧弱、貧弱ゥ～だからだ。

　じゃあどうする? BABOKの6.5「要求を検証する」では、要求の品質を提唱する。ここから先はおなじみだろう。品質特性の話になる。

1. 凝集性が高い（cohisive）
   
2. 完全である（complete）
   
3. 一貫性がある（consisitent）
   
4. 正確である（correct）
   
5. 実現可能性である（feasible）
   
6. 修正が容易である（modifiable）
   
7. 曖昧さがない（unambiguous）
   
8. テストが容易である（testable）

　ビジネスアナリストは、適切で充分な記述によって要求が仕様化されていることを検証する。この「検証」は要求アナリシスのプロセスを通してくり返し実行される。完全性や網羅性、一貫性をチェックリストやウォークスルーといったテクニックを用いて、見える化する。なんのことはない、レビューやペアプロでさんざやってきた成果物へのツッコミを「要求」にも適用するというわけ。

　だが、BABOKは先がある。「要求」の扱いだ。BABOKは「要求」と「表明された要求」と厳密に分ける。「表明された要求」とは、分析が行われてない要求のため、検証の対象にはならない。「メールで書いた」「会議で言った」だからやれ、というのはBABOKでは受け付けないのだ。プロジェクトで定義された「要求」の形にするために、「6.3　要求の仕様化とモデリングを行う」タスクを必要とする。すなわち、「要求」をまわす仕掛けがない限り、「要求」扱いされないのだ。顧客の思いつきで押し付けられる「要求」は、「要求」ではないのだ。

　「表明された要求」を「要求」にすることを意識するだけで、解決のアプローチが見えてくる。「表明された要求」に番号を振って、「6.3　要求の仕様化とモデリングを行う」のタスクを通し、「要求」化する仕掛けを作ればいい。これをExcelでやったのが、「要求を仕様化する技術」だ。Excelというインフラを援用すればここまで要求管理ができますよという好例だし、ソース管理ツールとかバージョン管理システムの発番体系に、「要求」をつなげる仕掛けなら、ちょっとしたカイゼンテクニックでやったことあるでしょ? こいつをもっとアタリマエ化して有無を言わさず見せ付ける。

　わたしが始めた方法は、メールの返信タイトルに要求管理番号をつけるという小技。顧客も最初は「何これ?」と言っていた。だが、自分の要求を「先先週のチェックのアレ」とか「明後日リリースのやつ」と言わなくて済むので、「番号」で伝えるようになってきた。だけどこの「番号」、チームでレビュー済みなんだよね。番号を払い出すためには、クリアすべき条件「仕様化、期限、確認手段」が必要なの。「期限が分からないので番号が出せません」と伝えたら、要求部門とネゴシエートしてくれた。

　もし、プロジェクトの最初から関われるのなら、「表明された要求」を精査して、番号を振るところから始める（トレースできるようにね）。ポイントは、「表明されていない（でも後から必要になる）要求」を先回りして、番号を予め振っておくこと（この辺は、「6.2　要求を体系化する」が詳しい）。

　「要求」と「思いつき」を厳格に分け、「要求の品質」をくり返しレビューする。これだけでも糞システムから糞がかなり取れる。だが実は、BABOKにはもっと先がある。ここでは、要求が品質を満たしているかを検証しているだけで、その要求は妥当かどうかは、別の問題になる。ビジネスの前提条件に合っているか、やることに意義（=便益）があるのか、機会費用とKPIとリスク分析を厳密に行う、「6.6　要求を妥当性確認する」が待っている。ホラ、あるでしょ、仕様も明確、一貫性も完全性もある要求だ。だけど、「ホントにそれ、今するの? オマエの意地とか意固地じゃないの?」というツッコミを入れる。そういう"仕掛け"を準備するのだ。