モジュール化によるコラボレーション

先日翻訳した、Jeff氏のインタビューの中では、モジュール化によるコラボレーションについて軽く触れられています。広い意味でとらえれば、SOAなど、分散システムも大きなモジュールと言うこともできるでしょう。しかし、OSGiのように、一つの環境の中に閉じたモジュール化は、コラボレーションを加速できると言えそうです。
Eclipseはモジュール化によってコラボレーションが産まれた例として最も成功したプラットフォームと言っても過言ではないでしょう。最初はJavaの開発環境のみでしたが、JavaEE開発用の環境が提供されていますし、UMLを用いた開発用の環境もあります。また、RCPのような方向性を打ち出したことで、開発ツール以外の分野でも広く利用されるようになりました。最近ではDSLを用いた開発用の環境も公式に提供されるようになっています。
ここで「公式に」と書きましたが、「非公式」な環境もたくさんあります。こういった環境はどうやって産まれたか、考えてみると、プラグインシステムによるモジュール化の影響が大きいように見えます。ほとんどツールシステムの根幹からプラグインとして組み入れる事のできる環境となっていたため、既に存在するツールキットの上に新しく自分たちが欲しいツールを実装していくことで新たな環境が次々と生まれてきています。利用しているツールキットに、足らない機能があれば、拡張したものをフィードバックすることもできます。(Eclipse.orgが提供するソースはEPLなので、足らない機能を拡張するなど、修正した場合は公開する必要があります。)そのため、既存の環境も機能向上を果たすことが出来てきました。
Eclipseを見ていると、モジュール化によるコラボレーションをうまく果たすためには、既存の環境自身が高い魅力を持つことと、フィードバックをうまく受け取るシステムが重要に思えます。しかし実際のところそれを実現することは難しいと考える事が多いのではないでしょうか？特に「高い魅力を持つこと」と言う部分です。
しかし、実際にソフトウェアシステムの開発では、いくつかの組織がコラボレーションして一つのシステムを組み上げる事もあるでしょう。そういうときに、組織単位で異なるモジュールに分離しておくと、開発は確実に楽になります。なぜなら担当範囲が明確なので、その責任範囲も明確だからです。僕は開発範囲がモジュール毎に分割された環境で仕事をした事があります。そういう環境では組織間の取り決めが一番重要になる事は間違いありませんが、モジュールに分離されているアーキテクチャにより、かなり開発を助けられました。リリースの日付さえ歩調を合わせることができるならば、各々の組織においての開発プロセスはどんなプロセスでも大丈夫でした。言い換えれば、納期が同じであれば、ですね。
また、モジュールが分離されていることで、ソースコードの公開範囲を限定できます。コードの共同所有は個々の組織内のチームでは行うべきことですが、組織をまたげば、そううまくはいかない事もあるでしょう。モジュールに分離しておくことで、必要な部分はバイナリで提供しやすくできます。共有領域においてはコードを公開する方が望ましい事は言うまでもありません。しかし、組織をまたいでコードを共有する必要なく、開発を進められるのも、モジュール化の利点です。
モジュール化のコラボレーションについて、簡単にまとめてみました。