memorandums

日々の生活で問題解決したこと、知ってよかったことなどを自分が思い出すために記録しています。

ぶらんこ作って?

以下の図、よくみますね。

f:id:ke_takahashi:20171206131003j:plain

引用 Project Cartoon: Japanese

要求定義の困難さを説明する図としてよく使われるように思います。ちょっと真面目に見てみたんですね。。。図の解説文がないかと探してみたのですがない。。。がんばって考えてみたのですが少し違和感を感じました。

例えば、左上の「顧客が説明した要件」と右下の「顧客が本当に必要だった物」の差が大きいという点です。顧客自身が説明したはずなのに、顧客が欲しい物が全く違うというのは、この文字だけを読むと感覚的におかしいと感じます。

その他も、持ち場立場によって、同じ言葉でも解釈が様々になるという例であることはわかるけど、その立場の人が考えたという理由を探すのが難しい図もあります。そこまで考えなくても。。。と思うかもしれませんが。

で、さらにぐぐってみると、原典として以下のような情報があります。

f:id:ke_takahashi:20171206145541j:plain

引用 University of London Computer Center Newsletter, No.53, March 1973 | Tree Swing Cartoon Parodies | Know Your Meme

この図であれば、想像は難しくない気がします。

左上の図はプロジェクトの「スポンサー」が提案したものとのことですが、実際の顧客が欲しいものとは違って当然ですね。これであれば上記の疑問は解消できます。

右上の図も面白く、スポンサーが「3つの座面が必要」と言ったものを「3本のロープが必要」と誤解するのは想像できます。

さらに、左中央ではシステム分析者がブランコにならないものを想像し、プログラマ(右中央)がそんなダメダメ分析をなんとかブランコと解釈しようとして実装するものの、ブランコとしては機能しない。。。というのも想像できまし笑えます。

そして、それでも何とか実働したソフトウェアは座面がブランコのようにスイングするけど。。。人が乗れない。。。要は使い物にならない。。。という結果がうかがえます。それでも何とか動かすように枝を添え木をしているところがリアルで笑えます。

早期にプロダクトをリリースするアジャイル開発プロセスの導入により、このような要求定義誤りは少なくなっていくのでしょうか。。。この辺は実務をしている人のみぞ知るというところだと思いますが。。。人がソフトウェアを作っているうちはこの問題はなくならないのか。。。なくすために何ができるのか?というところかと思います。