[要求開発] うまくいかない要求定義をよむ

リコーITソリューションズ株式会社さまの技術情報ページ

要求開発超入門 を読んで要求開発は何なのかを探ってみる。

「我々は元気の出るプロジェクトを始めました」と書いてある。楽しみ。

volume 2 は、「うまくいかない要求定義」だそうだ


-----
以下内容の要約

なぜ、要求定義はうまくいかないのか？

契約的問題
ウォーターフォール開発では、ソフトウェア開発の最初の段階で(１ヶ月などの期間を切って、ユーザーにシステム要求を提示してもらい、開発会社がそれを元にシステム要求仕様を提示する。その時に受注金額が決まる。あらかじめ開発予算が決まっているときも多々あるので、発注側と受注側で要求を受ける・受けないという交渉が行われる。
このやり方には問題があり(図示)、ITシステムのビジネス上での活用方法がわからないのに、要求を出さないと損だとばかりに、無理やり要求を出してしまう。結果、半分も「使われない機能」ができあがってしまう。
ユーザーがしっかり要求を持っている訳ではない。ユーザーは業務をどのように行っているかは知っていても、ITを使ってどのように効率化するか？や新しい価値を生み出す方法はわからない。
システム開発側も、ユーザーの業務上の問題や課題が完全にわかる訳ではない。


要求の定義と要求の評価では見ているところが違う

[4コマ漫画が入る]
ユーザー：お魚を食べたい（収穫したい）
ユーザー：お金がかからない方法で、木と糸と針金を使って・・・
開発者：数日後に釣り竿を作って持ってくる
ユーザー：僕の要求とちがう〜！網がよかったのに〜

[別の図が入る]

要求を定義する段階では、「木と糸と針金をつかってお魚を穫る」だったのが、
要求を評価する段階では、「網でお魚を穫る」になっている。

これらからわかることは
本来ならば要求とは、手段が連鎖した全体的な系列を理解しなければならないということ。
ユーザーは、最初の段階では、網のイメージをはっきりと説明できなかった。
また、開発者も釣竿を考えたのだが、針金で針を作ってしまったり、浮きもない竿でどうやってつればいいかも分からないまま開発に着手した。
もっと最初から、結果イメージが予測できていればこういうことになりにくいはずである。


volume3につづく
-----


感想
そうですね。其のとおりですね。
次回どうなるのか〜