ゲームのルールを変える
「100年も前にわかっていてもいいはずなのにわからなかったことを教えてくれる人を、なんて呼ぶのかな。」
デッドライン
id:kurataniさんの日記ディフェンシブな開発を読んでの感想です。普段もやもやと考えていたことがすごく丁寧にまとまっています。
技術者として、お客さまの役に立つものが作りたい。たとえエライ人からじゃなくても(むしろそうでない人、実際にシステムを使う現場のユーザさんからとか)喜んでもらえるシステムが作りたいというのは多くの方が思うことではないでしょうか。
それを追求することが求められる、許容される状況こそがQoELの高い環境だと感じています。現実には「よいシステム」よりも「受注側が損をしないシステム」「受注側にとってのリスクの小さいシステム」を作ることに汲々とする場面も多いです。顧客のビジネスに有益な機能があることよりも、バグがないことを優先としてしまったりします*1。ですが、結局それで達成できる幸せって小さくないですか？
発注企業-受注企業というスキームでもSIer-従業員というスキームでも、お金のみをモチベーションとする関係はすごく危険です。自分がお金をもらう立場の場合、競争に対して自分を安売りするのが当座のごはんを食べる最適解となってしまいます。自分がお金を払う立場の場合、逆にいくらお金を払っても、優秀なパートナーを失うリスクを抱え続けます。いまのSIerを取り巻く環境を見る限り、そう言う危険なビジネスモデルのまま、みんなでチキンレースを続けている現実があります。
でも。それじゃつまらない。「よりよい世の中」は誰かが作ってくれるのを待つしかなくなってしまいます。そこから脱して、顧客満足度*2こそをモチベーションとする仕組みに変えていかなければ、自分が面白いものを提供する立場に立つことができないんですよね。
なんかすごくこっ恥ずかしいんですが、いまの職業(!=会社)を選んだのも、もともとそういう若かりし情熱がベースとしてあったからです。まだまだ混沌としているコンピュータやインターネットというものにはそれだけの可能性があると信じています。
気持ちだけでも若く、よりよいものを目指したいなぁ、と思ってRubyで遊んでみている今日このごろです。
