要求の品質BABOKの最重要ポイントは、要求の品質にある。そもそも論をぶちあげて責任韜晦するなら、まだ賢いほう。ふつうの顧客は、「要求部門が違うと言うから」「書いてないことはこっちのフリーハンド」などと逆ネジを食い込ませてくる。要するに、仕様書には無いが無償(ただ)で対応しろ、という圧力だ。テストフェーズ後半か、シミュレータでもエミュレータでもなく「本当に使う人」「本当に接続するシステム」が使い出す頃に出てくる。いわゆる、宴もたけなわの頃だ。不備、誤読、漏れ抜け、ほころび、食い違いを、堂堂と「バグ」と読んではばからない。昔は殺意が湧いたが、これでかなり丸くなった[怒らないこと](とはいえ、ここでは仏教ではなくBABOKからのアプローチを続ける)。反論が困難なことも事実。「仕様書に無い」「要件定義に書いてない」「そもそも要求すらない」という反論ができるほどトレーサビリティが無いのだ。要件定義書っぽいドキュメントは存在するが、網羅性も、完全性も、一貫性も、実現可能性も、具体性もないし、正確でもなく、修正もされておらず、検証もできない有様。どっかのコンサルティングファームが書きちらしたあるべき論が延々とコピペされた代物で、そいつをもう一段ブレークダウンした「要求」が無いのだ。"あるべき"かではなく、どう"したい"のか、こいつを明確化しないままプロジェクトをムリヤリ進めた連中は先月栄転してもういない。システム担当者、マニュアル作成者から、「質問」が出るたびに、メールで問い合わせる。粒度もタイミングも範囲もバラバラで飛び交わされた膨大なメールこそが、「要求」になる。なきゃ会議室や電話で一方的に通告される「顧客の思いつき」が「要求」と化す(みんなの心の中にある仕様やね)。当然の結果、やたら詳細な要求(ユーザインタフェースまわりのチェックとかボタンのデザインとか)と、曖昧なままの部分(エラー系とか接続先システムのインタフェース、あとパフォーマンスw)と濃淡が出る。互いに矛盾する動作も、もとは膨大なメールのどこかにあるそれぞれの「要求」を現実化したもの。そのうち、SEも、プログラマも、テスタも、移行も運用もマニュアル作成者も(オペレータさえ!)、「いまある動きが正しい=プログラムが仕様です」と言いだす。矛盾した要求を検証しないまま実現しようとする「ひずみ」「ねじれ」をなんとかするためのバッチジョブ、プログラムの修正、手運用、虎の巻が生まれる。これは、ドキュメントの品質でもプログラムの品質でもテストの品質でもない、要求の品質が貧弱、貧弱、貧弱ゥ~だからだ。BABOKの6.5「要求を検証する」では、要求の品質を提唱する。ここから先はおなじみだろう。凝集性が高い(cohisive)完全である(complete)一貫性がある(consisitent)正確である(correct)実現可能性である(feasible)修正が容易である(modifiable)曖昧さがない(unambiguous)テストが容易である(testable)ビジネスアナリストは、適切で充分な記述によって要求が仕様化されていることを検証する。この「検証」は要求アナリシスのプロセスを通してくり返し実行される。完全性や網羅性、一貫性をチェックリストやウォークスルーといったテクニックを用いて、見える化する。なんのことはない、レビューやペアプロでさんざやってきた成果物へのツッコミを「要求」にも適用するというわけ。BABOKは先がある。BABOKは「要求」と「表明された要求」と厳密に分ける。「表明された要求」とは、分析が行われてない要求のため、検証の対象にはならない。「メールで書いた」「会議で言った」だからやれ、というのはBABOKでは受け付けないのだ。要求の仕様化とモデリングを行う」タスクを必要とする。「要求」をまわす仕掛けがない限り、「要求」扱いされないのだ。顧客の思いつきで押し付けられる「要求」は、「要求」ではないのだ。「表明された要求」を「要求」にすることを意識するだけで、解決のアプローチが見えてくる。要求の仕様化とモデリングを行う」のタスクを通し、「要求」化する仕掛けを作ればいい。これをExcelでやったのが、「要求を仕様化する技術」だ。こいつをもっとアタリマエ化して有無を言わさず見せ付ける。わたしが始めた方法は、メールの返信タイトルに要求管理番号をつけるという小技。顧客も最初は「何これ?」と言っていた。自分の要求を「先先週のチェックのアレ」とか「明後日リリースのやつ」と言わなくて済むので、「番号」で伝えるようになってきた。この「番号」、チームでレビュー済みなんだよね。「期限が分からないので番号が出せません」と伝えたら、要求部門とネゴシエートしてくれた。プロジェクトの最初から関われるのなら、「表明された要求」を精査して、番号を振るところから始める(トレースできるようにね)。要求を体系化する」が詳しい)。「要求」と「思いつき」を厳格に分け、「要求の品質」をくり返しレビューする。これだけでも糞システムから糞がかなり取れる。実は、BABOKにはもっと先がある。ここでは、要求が品質を満たしているかを検証しているだけで、その要求は妥当かどうかは、別の問題になる。要求を妥当性確認する」が待っている。ホラ、あるでしょ、仕様も明確、一貫性も完全性もある要求だ。オマエの意地とか意固地じゃないの?」というツッコミを入れる。いう"仕掛け"を準備するのだ。»コメント「要求を仕様化する技術・表現する技術」、リンク先のは絶版ですが、改訂第2版が出てます。11:13>>通りすがりさんありがとうございます!リンク先を変えておきました。答えが見つからないときは、問題を変えてみよう。(哲学はなぜ間違うのか)本は読まなくても書評を書くことはできる。