軽快なマイクロソフトに倣え
マイクロソフトがアプリケーション開発ツールセットの最新版の開発に着手したとき、同社のデベロッパー部門のリーダーたちは、まず「借金」を精算することにした。
5000個のバグと戦った、MSが「Visual Studio 2008」RTM出荷 − ＠IT
なんでも、Visual Studio 2008を開発するにあたって、一つ前のバージョンであるVisual Studio 2005の開発で抱え込んだ"借金"・・・多数のバグ、テストコードの不足・・・の返済を優先したそうだ。
ソマセガー氏によると、マイクロソフトは「Whidbey」のコードネームで呼ばれたVisual Studio 2005の開発で多くの「借金」を抱え込んでしまい、その状態で「Orcas」のコードネームで呼ばれるVisual Studio 2008の開発サイクルに入ったという。このためソマセガー氏は2005年11月に、すべての開発作業の中断を命じ、開発チームに対してテスト作業の遅れを取り戻し、バグを洗い出すよう指示した。
5000個のバグと戦った、MSが「Visual Studio 2008」RTM出荷 − ＠IT
そうすべき理由は、ジョエル・テストの項目の一つ"新しいコードを書くまえにバグを修正しているか？"で語られている。
一般的に、時間が経てば経つほど、バグを直すのにかかるコスト（時間とお金）は増える。
ジョエル・テスト - The Joel on Software Translation Project
そういう理屈はわかっているが、一見スケジュールを遅らせるように見えてしまう施策であるし、「（納期を守るために）品質はどうでもいいから、とにかく動くものを作れ」などと言われた経験があるこちらとしては、たいへんな英断であるように思える。*1
俺が関心したのはMQやクオリティゲートといった施策そのものではない。あの大企業にあって、そうした判断が通ること、組織が方法の変更を受け入れる柔軟性を持ち続けている点がすごいと思うのである。
ITエンジニアの今後の行く末について、イノベーションやエキサイティングな革命とは無縁な生活を送ることがいかに不本意なものであるかを語るとき、そこに共感を覚える人はどれだけいたか？
http://japan.cnet.com/blog/0040/today/2007/11/19/entry_25001845/
（中略）
しかし、私が知る複数のソフトハウスや中堅SIerを見る限り、割合に差はあれど、同じように絶対的な多数派は変化を望まない・・・いや、変化することさえ思いつかない人々なのも確かそうです。
これが我々の現実だ。
開発プロジェクトの進め方に何かしらの変化をもたらそうとしても、現場と管理者の両方から猛烈な反発が返ってくる。「○○（旧来の手法）でもできるじゃん」とくる。そりゃできるけど、より良いやり方を求めようと思わないのだろうか？万事この調子であるから、バージョン管理システムを根付かせるのに、BTSひとつ導入するのに何年かかったことか。道具をちょっと増やすだけでこれである、開発プロセスの変更など至難の業だ。
規模が小さい分、スピードと柔軟性に優れているはずの中小ITベンダーでもこの有様だ。しかし、遙かに大きく鈍重に思えるマイクロソフトはそれを軽やかに実行する。なるほど、トップを走っていけるわけだ。
世のエンジニアの大半は、今のままダラダラと仕事を続けることを望む。茹でガエルになろうとしていることにまるで気づかない。しかし、マイクロソフトには自らを改革する文化がある。彼らに倣うことが出来ない限り、我々はいつまで経ってもあのような巨人になることはできないのだろう。
*1:もちろん、パッケージ開発は受託開発と違ってリリース時期を自ら決定できるからこそ通じるやり方ではある。
