■

http://d.hatena.ne.jp/takahashim/20110607/p1 読んだ。

この開発側と発注側の差、開発側が「当初の想定通りのものを作る」ことが成功条件になっているのに対して、発注側は「ビジネスとして成功する」が成功条件になっている、という大きな違いこそが、失敗に陥りやすい根本的な要因になります。

”当初の想定通りのものを作る” の箇所がすこし、腑に落ちなかった。どの程度 ”当初の想定”を重視しているのかが、ここからは読めなかった。

発注側は「ビジネスとして成功する」が成功条件であるが、開発側が「発注側のビジネスとして成功する」が成功条件になっていないにズレがあるのは感じる。

「（発注者側の）ビジネスとして成功する」が、お金の話をしているのであれば、ビジネス成功報酬を契約に組み込む案があるだろうが、「（発注者側の）ビジネスの成功に向かって共に一喜一憂しながら試行錯誤を繰り返し、成功を分かち合う」ことを指しているのであれば、受託開発による、時間・空間・儲けの原理・文化・それ以外の何かの「場」の分離は、痛い。

その間を埋める案として、計画ゲーム、ユビキタス言語、Wiki, メール、Skype, twitter, 電話、テレビ会議、デモ、飲み会などなど、発注側と開発側とのかかわり合いを良くする案があるだろうが、色々と抜け落ちているのも確かだ。

最近みた、リーンスタートアップの仕組みの導入までが、将来の受託開発と呼ばれるものに変わっていくのであれば、”発注側は「ビジネスとして成功する」が成功条件であるが、開発側が「発注側のビジネスとして成功する」が成功条件になっていない件のズレがある”の課題に対して、少しは見通しが良くなるかもしれない。