February 14, 2004

分散開発

ちょうどいいときに分散開発ネタが出たので少し本題から外して反応してみる。 さて、先日のFowler氏の論文にもあるように、オフショア開発のような国境、時差を越えて分散しなくても、例えば同じ社内でも拠点の違う部署どうしのコラボレーションや、事業部等組織の壁を越えたプロジェクトや、協力会社との共同開発もそうであるが、つまるところ、コミュニケーション、情報共有が重要である、という結論には反論できない。Fowler氏の論文では、Wikiの可能性や、ThoughtWorks社で利用しているらしい、CruiseControlの有効性に触れられている。 また、モジュール間どうしの結合でうまくリンクできないというリスクを低減させる方法として、「継続的インテグレーション」、つまり、結合を実施する機会を可能な限り増やすこと、リファクタリングにより、常にソースコードの品質を高めることで対処せよ、とのこと。 つまり、情報共有を効率よく高めるために、(共有の開発支援ツールも含めての)コミュニケーションツールが重要だ、ということだ。 これらのツールに求められる機能としては、いろいろあるだろうが、ひとつ挙げるとするならば、情報の一元管理だと思う。分散開発において一番困るのは、情報伝達のタイムラグが発生すること、伝わった情報、伝わらなかった情報にムラができることだ。後者は、古き良き時代のおじさん方の中には、意図的に利用することもあると思うが、ソフトウェアプロジェクトにおいては、これは致命的だろう。そこで、「常にマスター情報にアクセスできるようにするための仕組み」である、Webの利用は誰もが思いつく。分散開発の典型例、オープンソースソフトウェアプロジェクトを支えているのも、ソースコードのバージョン管理、リポジトリを一元化する、CVSとそれへのWebインタフェースがあればこそだ。だが、実際の業務で、これがなかなか敷居が高い。なぜか? 内部のプロジェクト情報を外部のNWに流すのはもってのほか。社内のOA用NWとも切り離して、孤立したNW内での開発を強要するプロジェクトリーダ、協力会社とのそうした風通しのよい状況を作ることに抵抗する中間管理職等の存在だ。 まぁ、CNETのこの記事にも、Fowler氏の論文にも、「一番の問題は、カルチャーだ」と言ってるし、結局、道具じゃなくて、どういうマインドを持つ構成員によってプロジェクトが構成されるか、ってことに行き着いてしまう。 おっと終電だ。続きは、別の機会に。
Posted by money at February 14, 2004 1:03 AM | TrackBack
Similarly Feeds
Comments
Post a comment









Remember personal info?






Powerd by FC2.com
since 2/Feb/2004