要約(5)：ソフトウエア企業の競争戦略

http://d.hatena.ne.jp/hidekoji/20050508

先日の続きです。第4章のBest Practices in Software Development:ソフトウェア開発のベスト・プラクティスについての要約。先日は、デザインや発想は、実装(開発工程)よりも(ビジネスで成功するという観点からは)重要であるというお話でしたが、今日は開発工程に関する要約です。先日は実装はデザインと比較すると重要度は低くなるとまとめましたが、とはいってもある程度規模が大きく、複雑なソフトウェアを開発するには、それなりの開発/実装方法というものが必要になってきます。常に変化する要件やニーズに対応させつつ、かつ安定したソフトウェアをいったいどうやって開発するのかという問いに対して、本書では"Synch-and-Stabilize"(同期させ安定させる)というテクニックを紹介しています。

本書ではSynch-and-Stabilizeについて以下のような説明がせれています。

The core idea is to encourage programmers to innovate and experiment but frequently synchronize their designs with other team members by creating "builds" (working versions) of the product as often as possible, and then periodically stabilize (debug and integrate) their code before proceeding to the next set of development tasks

小職による超訳

Synch-and-Stabilizeの中心となる考え方は次のようなものです。プログラマーに新しいことに挑戦させ、実験的なことをやらせつつ、その一方で、できるだけ頻繁に製品のbuild(現行作業バージョン)を作ることで、デザインを他のチーム・メンバーのものと同期させ、そして、次の開発タスクに進む前に定期的にコードを安定化(デバッグやインテグレーション)させるのです。

Synch-and-Stabilizeでの開発を体験してみて

小職が、知っている(やったことがある)開発は、まさにこのSynch-and-Stabilizeです。小職が参加したビジネスアプリケーションの開発では、大体1ヶ月おき1週間おきにbuildが自動的に作成され、他のコンポーネントとのインテグレーションの確認や、不具合のチェックが行われていました。buildテスト中に自分の担当した部分で不具合がでると、P1(最優先対応)のBugが登録されてしまうので、テスト期間中に治すため、それこそ死に物狂い*1での対応となります。(5/12日追記：正確にはBuild自体はWeeklyで行われ、さらにそれとは別に開発Phaseが大体一ヶ月単位で決められていて、そのPhaseレベルで新機能の実装を完成させるというフローでした。)

このSynch-and-Stabilizeがいいのは、ウォーターフォール型と違って、すばやく、新しい機能を追加していける点です。小職が参加した開発でも、途中で自分が参加しなかったbuildがあったりすると、次のbuildで大幅に機能が追加されていたりUIが変わっていたりして、たった1ヶ月でものすごい進化を遂げていたことを実感しました。これぐらいのスピード感で開発していけないと、グローバルな市場で勝ち残っていくのは難しいのです。

*1:基本的には24時間対応