要求仕様の美学

1990年代なかばから、企業の経営環境が大きく変化している。きっかけになったのは、インターネットの普及である。

インターネットが出現する以前、市場の変化は現在よりはるかに緩やかだった。企業は、市場の変化を見てから組織を変更し、対応するだけの余裕があった。この時期、ITはあくまでも組織を支援するための道具にすぎなかった。

Z言語をはじめとする要求仕様記述言語は、厳密さゆえに実用に適さないと言われる。何はともあれ、Z言語とはどんなものか。どのように厳密なのか。システム担当者なら、そのエッセンスを理解しておいたほうがよいだろう。

要求仕様に対するソフトウェア工学からのアプローチを解説する第2回である今回は、実際にUML図を作成する。自分だったらどう記述するか、考えながら読み進めてほしい。

ソフトウェア工学が誕生してから、40年が過ぎようとしている。今回からは、ソフトウェア工学が要求仕様にどのようにアプローチしてきたのかを、3回にわたって紹介していく。

前号では「発想力」について解説した。それに続いて今回は、発想力を引き出し、問題の解決策を導くための発想法を説明する。4つあるが、基本はどれもシンプル。適材適所で使い分けてほしい。

要求定義を正しく実施するには、業務上の問題を感知するだけでなく、その解決策を生み出せなければならない。今回は、解決策の創出に不可欠である「発想力」を解説する。

要求定義の前提になるのが、経営上や業務上の問題の発見と解決策である。ところが、その問題の定義が曖昧なことが多い。 そこで今回は「問題とは何か」を示し、適切な定義方法を説明する。

前回まで、ヒューマンエラーを引き起こす原因について人間工学と認知心理学の見地から解説した今回はそれらを踏まえ、要求仕様書作成時に発生するヒューマンエラーの具体例と解決策を解説する。

誰にとっても自明で誤解が生じない要求仕様を作成するにはどうすればいいのか。 そこには王道と呼べるものはなく、エラーが生じる原因をしっかり理解し、適切な対策を講じるしかない。 今回は前回に続き、ヒューマンエラーを引き起こす人間の特性を解説する。

ちょっとした言葉の行き違いや誤解、錯覚がもとで要求仕様の作成に失敗すると、ユーザーの本来の要求とはかけ離れたシステムを作ってしまうことになりかねない。人間はどのような条件下で間違いを犯しやすいかを知れば、要求仕様のミスや漏れをなくしてよいシステムを作れる。