日経SYSTEMS 7月号のコラムは「システム設計に進む前に「要件整理」を」です。
要件定義をきちんと行ったはずなのに，テスト・フェーズになって，ユーザーから「これでは要件を満たせていない」と指摘されたことはないだろうか。
みたいなところですが、ありがちなのは要件整理が出来ていない場合です。
ユーザーが話す要件は，システムの機能を定義しているのではなく，ある状況でその機能に何を求めるかを説明しているにすぎない。そうした要件は，例えるなら，建物をいろいろな角度から描いた絵のようなものである。一見すると，それぞれの絵に描かれていることは正しい。しかし，それらを集めてきて整理していくと，建物のある部分が描かれていなかったり，構造的な矛盾があったりする。
こうした個別の情報を集め，不足していることをつかみ，矛盾の除去を行うことが必要である。これが「要件整理」である。
というわけで、要件整理をしましょう！という話です。基本は論理的に組み当てていくだけなので、ロジカルシンキングのツールなどを使いながら、きっちりと進める以外に方法はありません。ただ、経験がないうちは簡単ではありません。主成功シナリオに絞るなど、なるべく散漫にならずに進める問いでしょう。
さて、まとめ。
本来，要件整理をしなければ「システムの全体像」を描けないものである。だが，システム構築経験があると，ユーザーから聞いた要件だけでシステムの断片（ここでは画面設計や遷移図を指す）を描き，それを基にシステム設計へと進めることが可能である。ただし，可能というだけで，こうしたやり方では要件の矛盾や不足がある状態でシステムを作ることになる。若手のエンジニアは要件整理に時間をかけず，システム設計に走ってしまいがちだ。要件を構造的にとらえて整理したうえで，システムの全体像を描くことが大切である。
なんか、このコラムを書きながら、自分もなんだかんだと10年以上もシステム開発をしてきたんだなぁと思ってしまいました。2-3年目の若いメンバーに設計をまかせると、どうしても甘い整理になりがちですが、まぁ、当時の自分も同じだったんだろうなと。
あと、個人的にびっくりしたのが、そう言う状況でもなんとなく画面設計を行ってしまえること。若いなりい実装経験もあるだろうし、そもそもシステムを触ることにも馴れているでしょうから、それなりに作れてしまうんですね。
ただ、これは経験がある人でも同じで、いつも似た設計を盲目的にしている場合があります。効率化のためには大事なことですが、やはり、きちんとした要件整理はしないといけません。
要件整理をして、どんなアーキテクチャが望ましいかを考える。基本的ですが、実直にやるべきステップです。
