« システムの設計と施工を分離する | トップページ | けっきょくすべてが「SE本」 »

2006.02.25

システム要件を捉えるために必要な「疑り深さ」

システム設計者には詐欺師に対するときのような「疑り深さ」が必要だ。そのような姿勢によってしか探り当てられないタイプの要件が存在するからだ。その種の要件はしばしば重大で、捉えそこなうと痛い目に会う。

◆システム要件の分類学

 システム要件は、ユーザによって自発的に語られる場合と語られない場合とがある。ユーザが独自にまとめた要件定義書などは「語られた要件」の代表的なものだ。第三者がまとめたとしても、ユーザに一方的に語らせただけのものであればこれと似たものになる。しかし、そこに書かれたことを漏れなく取り入れるだけですべての要件をまっとうできると設計者が考えているとしたら、あまりに純朴過ぎる。

 システム要件には、「語られていないけれども無視できないもの」も「語られているけれども無視すべきもの」も存在する。つまり、システム要件には「語られたか、語られなかったか」と、これに直交する「無視すべきか、無視できないか」の分類軸がある。したがって、システム要件の探索者は少なくとも次の4象限を意識しなければいけない。

          無視すべき 無視できない

 語られた      A     B

 語られなかった  C     D

 BやCについては理解しやすい。Bは、問わず語りに語られる重要な要件なので扱いやすい。またCは、ユーザによって意図的に切り捨てられた要件なのでハナから問題にもならない。

 問題はAとDだ。なぜユーザは「無視すべき要件」をわざわざ語る(A)のか。なぜ「無視できない要件」をあえて語らない(D)のか。

 Aについてはそんなに難しい話ではない。古い実装技術の特性を前提とするシステムの仕様は、新しい技術にもとづいて刷新する際に「無視すべき要件」となり得る。「無視すべき」とは語弊があるかもしれないが、語られた内容を抽象化したものこそが「正しい要件」であって、字義どおりの内容としてはこだわる必要がないなんてことはよくある。また、事業環境の変化にともなって昔は有効だった要件が無意味になっても、ユーザが惰性でそれを語り続けるなんてこともある。

◆語られないが無視できない要件

 「語られないが無視できない要件(D)」はもう少し複雑だ。語られなかった理由によって「ユーザにとって当たり前すぎて、あえてコトアゲする必要を感じない要件(D1)」と「業務システムとして一般的な要件なので、設計者によって補足してもらえると期待された要件(D2)」とに分類できる。

 D1:当たり前すぎて語られなかった要件
 D2:設計者が補足できるので語られなかった要件

 D1の具体例を「CONCEPTWARE/財務管理」から示そう。「立替精算」に関するヒアリングにおいて、「長期出張などで多額の立替が必要になる場合には、事前に仮払を申請できる(1)」というルールを聞き取ったとする。このルールは「実際の費用が仮払額より少ない場合に、社員から差額の返還がなされる(2)」という要件を暗示している。会社から社員への支払がなされるだけだろうと考えて、支払専用のしくみとして設計した後で(2)に気づけば痛いことになる。しかし、(1)を語ったユーザが(2)を当たり前すぎて語る必要はないと考えてしまったり、語られなかった(2)について設計者が補えない可能性は小さくない。

 D2の具体例としては、「ユーザメニューは権限に応じた職種毎に用意されなければいけない」とか「一定以上に古いトランザクションデータをまとめてクリアするためのバッチ処理が用意されないといけない」などといった業務システムの設計上の常套パターンを挙げられる。これらをユーザがことさら語らないからといって無視してよいわけではない。頼まれはしなくても、とりあえずひととおり盛り込んだうえで、開発コストの問題についてはあらためて検討すべきだ。

◆想像力と疑心を用いる

 以上の分類を上記の4象限とともに整理すると次のようになる。

 システム要件
  ユーザに語られた要件
    A:無視すべき要件★
    B:無視できない要件
  ユーザに語られなかった要件
    C:無視すべき要件
    D:無視できない要件
       D1:当たり前すぎて語られなかった要件★
       D2:設計者が補足できるので語られなかった要件★

 けっきょくのところ、システム設計において意識的に探索されるべきなのは★で示したAとD1とD2である。そして、これらの扱いに手馴れることこそが、システム設計に熟練するということだ。語られたこと(AとB)だけを無批判に取り入れるだけでは何年たっても熟練したとは言えない。

 ただし、これらの中でもD2については比較的対処しやすい。それらの多くの部分は、業務システムの基本設計パターンとして熟練者の知見から形式化できる。筆者の「CONCEPTWARE」は、まさにそのような知的インフラを提供する試みである。

 ではAとD1についてはどう対処すべきか。適切な分析設計手法や支援ツールを使うことで対処しやすくはなるが、決め手にはならない。大事なものは設計者の姿勢である。「語られたわりに無視すべき」だの「語られないが無視できない」なんて、そんなやっかいな要件が個々の案件で暗躍している事実を想像し、徹底的に疑心暗鬼であり続けるしかない。

|

« システムの設計と施工を分離する | トップページ | けっきょくすべてが「SE本」 »

コメント

はじめまして。
ご両人のご意見どちらももっともだと
思います。
しかしどちらか一方を良しとできない場合が
多々あります。
開発後に「確かにこうおっしゃいました」と
資料を提示してユーザーに言ったとしても、
「そんなことはありえない、それを逆提案
するのがお前の仕事だろ」と言われれば
もうなにも言えません。
結局はユーザーにどこまで信頼され、
そういった場面になっても切り抜けられる
関係を築くことが、鍵にならざるを得ない
のかなと、心外ではありますが、思っています。

投稿: 樹里亜 | 2006.03.04 11:18

「逆提案するのが仕事」ですか。厳しいなあ(^^; 簡単じゃないんですが、後でそういうムチャな追求がされような信頼関係を築くことも必要ですね。

投稿: わたなべ | 2006.03.05 08:47

結局はユーザーの鶴の一声で、
物事は決まっていくものなんですよね。
あとあとやっぱりこうすればよかったと
思っても、そんなこと言ってない、の一言で
終わりですからね。

なんとかならないものですかね。

投稿: 樹里亜 | 2006.03.07 00:18

コメントを書く



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




トラックバック


この記事へのトラックバック一覧です: システム要件を捉えるために必要な「疑り深さ」:

» [ソフトウェア開発]内容を疑うことの限界 [酔狂人の異説]
システム要件を捉えるために疑り深さが必要であることは否定しない。記述されている内容を全て額面どおりに受け取るのは愚かである。だからといって、疑いさえすればいいというわけではない。「徹底的に疑心暗鬼であり続ける」ようにしたら、時間がいくらあっても、お金がいくらあっても足りない。 むしろ、記述されている内容を全て額面どおりに受け取って、「あなたが言っているのはこうです」と突きつけた方がいい。意図していることと言っていることとが違うということに気づかせるくらいの方がいい。 ... [続きを読む]

受信: 2006.02.26 21:23

« システムの設計と施工を分離する | トップページ | けっきょくすべてが「SE本」 »