要件を決めるとき、機能で決めていくと、同床異夢になりやすい。で、どうするか

　昨日のブログで、システムの要素を決めるとき、「機能より、出力内容から決めたほうがいい（なぜかは、別のときに書きます）」と書いた件について。

　いいかえると、要求仕様の要件は、機能より、入出力項目（内容）で決めたほうが、間違いが少ない。
　理由や、それに関するソフトウエアの歴史を述べる前に、その事例を示します。

---

日経システム構築　２００５年２月号　５２ページ（問題解決の軌跡　東亜建設）から引用

　用語と機能に対する認識の相違、ならびに業務分析の不足は、要件定義工程でカスタマイズの増加となって噴出した。
　一例を挙げると、「手形管理一覧」という言葉に対して、東急建設側は、旧システムでの「支店別に小計を出力する形」を想定していた。一方のＮＥＣは、パッケージ標準の「小計を出力しない」手形管理一覧を想定していた。
　支店別に小計を計算できなければ、東急建設にとっては使えない。「（パッケージ導入なので）帳票の体裁が変わるのは当然だと思うが、業務で利用できなければ意味が無い」

（ここまで引用）

---

　上記の例、「手形管理一覧」という機能名（たぶん、おおまかな内容も）は一緒だけど、入出力でみると違うと言うケース、結構起こります。
　営業サイドは、売りたいので、似た機能があると、「それできます！」といってしまう。
　開発は、現在の開発は、オブジェクト指向が進んでいるため、クラスが切れれば、あと細かいことを意識しなくても、話が進められてしまう。とくにＵＭＬを使う場合、アクティビティ図から書くけど、アクティビティは、機能（業務内容）さえ決まれば、書けてしまう。
　そこで、まったく予想していない出力項目が入っていても、その項目を意識しなくても、問題なく、仕事がすすめられてしまうことがある。

　でも、実際には、必要な出力項目がないと、意味ないし、出力項目を導くには、入力データを受け取ってないと、処理できないです。

　なので、要件を出すとき、
（１）機能から抽出すると、たしかにやりやすいけど（動詞を探せばいいから）
（２）その機能は、入出力項目で定義しないと（売上代金、担当コードを入力とし、担当コードごとに売上を集計、出力する機能とか）、誤解が生じやすい（同床異夢になりやすい）

---

　あと、機能できめると、もうひとつ問題がある。

　これは、１９９０年ころの、システム開発のトレンド、ＤＯＡについて、思い出してもらうと分かる。ＤＯＡが出てきた背景は、機能は、変わりやすいが、データ構造は変わりにくいということから、でてきた。

　実際そうなの？っていうことはあるんだけど、でもでも、機能は、変わりやすい。

　立場や、見方によっても、機能は変わってみえる。

　それに対して、データで定義すると、実物の、事実に基づいて定義できるから、結構、変わりにくいし、同じ見方になりやすい。

---

　まあ、ここらへんの詳しい議論は、要求定義のお話のときにします。
　とりあえず、昨日、保留にしていたことの、回答。
　あと、昨日、保留にしていた、作業内容が、見積もりの「期間で、できそうかっていうことを考えて、リスクがあればヘッジする」過程については、また別にあらためて。