顧客の問題を解く

プチ・パラダイムシフトせよ! - @IT
http://www.atmarkit.co.jp/fdotnet/nagilemind/nagilemind04/nagilemind04_04.html

結局システム開発の目的はこれに限る。システム開発だけではなく、ほとんどの仕事にあてはる事だと思う。
手法やツールは「顧客の問題を解く」為にあるものなので、こだわる事はあっても固執してはいけない。

デスマになる原因もこれ(「顧客の問題を解く」)が多いと思う。
1)仕様が決まらなくてスケジュール超過
2)顧客が検証する段階になって、「何これ?」って言われてやりなおし

1)の場合、顧客側が顧客の問題を理解していない場合に起こりやすい。
何が問題かわからないから何が欲しいかわからない。

※社内の政治的問題もあるとおもうけど、ここでは割愛
※システム化よりそういった政治問題がおこることを解決するべき

2)の場合は、開発者側が顧客の問題を理解していない
顧客の問題を理解しないまま設計したり、顧客に言われたそのままを作るとこうなりやすい。
顧客が「こんな風に作ってよ」って言ってきたら「なぜ」かを問わなくてはならない。
そこで初めて「問題」が現れるから。

毎回思うのですが仕事中に読んでると周りが気になる記事ですね(絵がね^^;)

TB先
Fujiwoの日記 – @IT ― 開発をもっと楽にするNAgileの基本思想 第4回
http://d.hatena.ne.jp/Fujiwo/20070116

コメントを残す

メールアドレスが公開されることはありません。