残業のない開発現場、ビジネスとITのリスク共有

TRICHORDの開発は、完全にアジャイル開発です。タイムボックスを区切ったマネジメントスタイルで、基本的に残業はなしです。っていうか、一日３コマのペア・プログラミングをやったら、へとへとで残業できません。ということを言ったら、記事になっていました。

残業ゼロの開発現場
http://itpro.nikkeibp.co.jp/article/OPINION/20070523/271904/

なぜ残業をなくせるかというと、それは（当たり前のことなんですが）開発のビジネスオーナーが自社だからです。受託型の開発だと、それはなかなか難しいのだと思います。つまり、ミッションとリスクをビジネスとITの間で分割してしまうと、そこでWin-Win関係と良好なコミュニケーションを確立することが難しくなってしまいます。

市場を「調査」し、仕様をまとめ、それを「発注」する。そして、それを開発し、「納品」し、市場へ「リリース」する。この１年のタイムスパンとウォーターフォールのような「計画遂行型」では、変化する環境についていけないのではないでしょうか。

ミッションとリスクを共有し、Win-Win関係と良好なコミュニケーションパスをビジネスとITの間で確立すること。そして、コミュニケーションをインナーループにし、それを１週間から４半期というペースでまわしていく。

ぼくの考えを、絵にしてみました。

この右側の形が、勝てるビジネスの形になっていくんじゃないかと思っています。これは、先日発表した、NaClさんと永和システムマネジメントのAgileとRubyを使った業務提携のテーマでもあります。（あ、Rubyのまつもとさんもブログに書かれていましたね。
http://www.rubyist.net/~matz/20070516.html）

それと、ぼくは、なんとか、ソフトウェア開発の現場を変えたいとおもっていて、エンジニア生活の時間の質（Qualitiy of Engineering Life)を向上させることを１うのテーマとしています。それには上記の右のような開発ができることが重要なんじゃないかな。そのために、エンジニアももっと顧客の悩みを感じる感性を持つ必要があるのではないかと思っています。リスクとミッションを共有する、共感力、が、仕様書では伝わらない、「よいもの」を作る秘訣なんじゃないかと思っています。

JUDEも 5.0　がリリースされました！
http://jude.change-vision.com/jude-web/index.html

JUDEの場合、内側から、「IT」はJUDEチーム、「ビジネス」がぼく、そして「市場」は使って下さっているみなさんと、これから使って頂けるみなさん。このループを回して、ニーズナレッジとシーズナレッジを融合させたい、という考え方なんです。JUDEのサポートチームに来る、不具合や励ましのメール、これが開発者の大きなモチベーションの原動力になっています。チェンジビジョンのみんなは、共感力を研ぎ澄ませ！