« 分析設計手法のスタイルとオフショアの脅威 | トップページ | システムの論理設計を構造化するための視点 »

2005.12.17

要件を要件として深追いしてはいけない

ユーザ要件は海に浮かぶ氷山のようなものだ。言語化可能な部分は海上に出たごく一部で、大部分は水没していて言語化どころか意識にのぼることさえない。このような要素をシステム設計においてどのように扱うかによって、上流工程のスタイルはまったく違ってくる。

◆スクラッチ案件での要件の位置づけ

 前回のエントリーで説明した「スクラッチ案件」において、要件はとくに重要視される。新システムを構想するためのレファレンスとなる現行システムが存在しないか、あっても貧弱すぎてアテにならないからだ。

 そのような案件向けであっても、要件の扱い方は2つの流儀に分かれる。ひとつは要件全体を正面から定式化するやり方。もうひとつは言語化が困難であるような要件については深追いせずに搦め手(からめて)を用いるやり方。便宜上、前者を「A方式」、後者を「B方式」と呼んで検討しよう。

◆要件をじっくりモデル化するA方式

 上流工程手法の多くは「A方式」に分類される。この方式では、高度な図法を用いて要件を手間ひまかけて「見える化」したうえで、これを起点としてシステムの仕様を構想する。最初に「要件」をモデリングしてから「仕様」をモデリングする点が特徴的だ。

 「要件をモデリングする」よりは「問題そのものをモデリングする」と表現したほうがわかりやすい。つまりA方式は「問題の様相を明らかにすれば答えもおのずから明らかになる」という信念にもとづく流儀といえる。

 「信念」と呼んだのは、その前提が常に有効とは限らないからだ。数学の問題のように本質的にトートロジーの形をとっていたりごく明解な構造を持つ問題に対しては有効だが、そういう問題はどちらかというと特殊だ。システム設計を含めて世にある問題の多くは、どんなに対象を分析しようが加工しようがまともな答えが浮かび上がるアテがないほどにとっ散らかっている。そういう問題をそのままモデリングしてもムダが多すぎる、というのが筆者の意見だ。

◆振り返ればそれは「スカスカ」

 では「B方式」において要件はどのように扱われるのだろう。筆者のやり方に沿って説明すると、要件定義のフェーズでは表計算ソフトを使ってチャカチャカっとまとめるくらいのことしかしない。意味上のまとまり毎に見栄え良くツリー形式に整形したり重要度で分類したりもするが、それでも「気の利いた箇条書き」以上のものではない。

 なぜ要件をまとめることに対してそのようにイーカゲンな態度をとるようになったかというと、システムが完成した後で、かつて苦労してまとめた要件定義を見直すと「スカスカ」であることを何度も経験したからだ。最終的に考慮された要件の束と比較すると、まとめたのが無意味だったとしか思えないほどに内容が薄い。顧客が事前に強調していた要件でさえ、システムが完成した時点では変形されて仕様化されていたりもする。まともに原型をとどめているのは「非機能要件」に分類されるものくらい。そんな経験を何度もすれば、設計の参考にするために要件をじっくりまとめることがばかばかしくなる。

 そのような経験を通して筆者は、ユーザ要件の大部分はとらえどころのない存在だと考えるようになった。位置と速度とを同時に測定できない素粒子のように実体があやふやなので、観察のために深追いしてわかった気になっていれば痛い目にあう。

◆仕様の光を当てて要件を捉えるB方式

 しかし、あきらめることはない。要件を要件として掬(すく)い上げるのではなく、「仕様」という光を照射して浮かび上がらせる手があるからだ。すなわち、要件に対して間違いであるなら間違いであることがアカラサマとなるような形で仕様をユーザに示せばよい。ユーザから「ちょ、ちょっと待ってください。それではいかにもマズイです」とあわてて拒否される可能性があるほどに具体的な仕様を押し付ける。拒否されたならその場で修正してまた返す。その繰り返しに徹することで、ユーザさえ意識していなかった要件が言語化されると同時に仕様化されてゆく。要件に対する自分の洞察力の無さに絶望した末にたどりついた現実的なスタイルだ。

 A方式でもムダがあるように、B方式でも「試行錯誤」にともなうムダはある。しかし前者は「困ったムダ」だし、後者は「有用なムダ」だ。ムダ弾が通り抜けた場所には「急所」はないのだから、飽きずにめげずに場所を替えて弾を撃ち続ければ急所を絞り込めるからだ。遅かれ早かれ氷山の隠れた部分は、明確な言葉を発しながら海上に浮かび上がる。

 そんなわけで、B方式においてモデリングされるのは九割方が「仕様」である。その様子は「業務システムのための上流工程入門」の「ビデオレンタル店のモデリング事例」で端的に示されている。そこでモデリングされているのは「ビデオレンタル業の問題領域」などではなく、最初から「ビデオレンタル管理システムの仕様」であることに注意してほしい。A方式、すなわち「正面突破の要求モデリング」に真面目に取り組んで途方にくれてしまった読者なら、その流儀は参考になるだろう。

|

« 分析設計手法のスタイルとオフショアの脅威 | トップページ | システムの論理設計を構造化するための視点 »

コメント

コメントを書く



(ウェブ上には掲載しません)




トラックバック


この記事へのトラックバック一覧です: 要件を要件として深追いしてはいけない:

» Re: 設計者の発言: 要件を要件として深追いしてはいけない [atsushifxの七転八倒]
◆仕様の光を当てて要件を捉えるB方式  しかし、あきらめることはない。要件を要件として掬(すく)い上げるのではなく、「仕様」という光を照射して浮かび上がらせる手があるからだ。すなわち、要件に対して間違いであるなら間違いであることがアカラサマとなるよう�... [続きを読む]

受信: 2005.12.21 23:48

« 分析設計手法のスタイルとオフショアの脅威 | トップページ | システムの論理設計を構造化するための視点 »