エンタープライズ案件では、機能の複雑性に対処するだけでなく、安全性や拡張性などの様々な品質要件を満たすことが求められます。5年10年利用することが前提になるので保守性も重視されます。アーキテクトは、こういった様々な視点からの要求に対して、どのようなアーキテクチャが最適なのか頭を悩ますことになります。
その中でも、特に大きな課題がモジュラリティです。アーキテクチャとは、簡単に言えば「モジュールそのもの役割/機能」と「それらモジュールをどのように組み合わせるのか」ということを考えることと言えるでしょう。
では、なぜモジュール化をするのでしょうか？それは、1つ目が複雑さの軽減、2つ目が開発の分業と統合、3つ目が変化への対応です。
まず複雑さの軽減です。ご存じの通り人間というは理解力が高くありません。大規模システムで全てのことを一度に理解するのは不可能です。そこでモジュール化して粒度を上げることで理解を促進するのです。また、個別モジュールはその中に限定して理解を深めることができます。
次に開発の分業と統合です。数十人、数百人規模のプロジェクトではチームが細かく分離し、場合によっては物理的にも分断されます。こうしたチームの成果物を統合するのは「ビッグバン」と言われるぐらいに大きな課題です。こうした場合、モジュール化がされていれば各チームはモジュールに集中して作業することができ、かつ統合コストを下げることが出来ます。
最後に変化への対応です。モジュール化がされていれば個別モジュールに変更があった場合でも、他のモジュールへの影響が明確になり、また最小化することが可能になります。
では、どのようにモジュール化を行うべきでしょうか。これは簡単な答えはありません。ドメイン駆動設計のような設計手法は知られていますが、これとて銀の弾丸というわけにはいきません。そこで、こういったモジュール化について議論をしてみたいということで8/28（金）の日本Springユーザー会主催のSpring勉強会は、僕の発案で「アーキテクチャを考える」というのをテーマにしました。
モジュラリティを考えるのは、どういった視点が良いのか。いろいろ考えたのですが様々な設計手法を解説するよりも、もう少し概念レベルでの議論が重要と考えました。そもそも、我々がしているモジュラリティとは何か？モジュールを分ける意味とは？どうやってモジュールを見つけるのか？そして、モジュールを語る上で外せないパターンとは何か？
そこで、以前から交流があった（株）シーエーシーの熊澤公平さんをお招きしてセッションを行うことにしました。あまり知られていないかも知れませんが、日本で初めてJ2EEサーバを本格的な大型案件を動かしたのはリクルートさんです。現在も技術を中心として新しいビジネスの可能性を探り続けている部署がある珍しい企業と言えるでしょう。熊澤さんもその案件に関わった後、同社のメディアデザインセンターから（株）シーエーシーに転籍。現在でもネット広告に関するビジネス、システム面でのアーキテクト活動を行われています。また、その一方で、東京大学工学部と横浜国立大学工学部で非常勤講師も努めておられます。
熊澤さんが横浜国立大学で講義された内容を見せて頂いたのですが非常に面白いです。複雑系という視点からの考察も個人的にはど真ん中です。
というわけで、かっちり技術のお勉強というよりも、様々な視点からモジュラリティを見直す機会として興味を持たれた方は、ぜひご参加ください。また、一緒にSpring3.0の紹介などもありますので、そちらもオススメですよ。会場は日本オラクルさんの青山センターをお借りできたので席がない！なんてことはないはず。では、当日、お会いできることを楽しみにしています。
追記：
@kompiroに言われたこと。
@yusuke_arclamp モジュラリティは技術指向で、何がうれしいのか伝わりづらいのかなぁ、と。人間指向で語るとするなら、みんなが夢見ていた、機能を組み合わせるだけでソフトウェアが作れるよ、という感じですか?なんかいろいろ情報が落ちてる気がしてなりませんが。
そして、それ対する僕の答え。
@kompiro そそ。なので、そもそもモジュラリティって何だっけ？というのを工業も含めて振り返る。夢見るところに行くためには何をすべきかイメージングしないと。その上で、ソフトウェアでは「未来」どこまでいきたいか、「今」どこまでできるかとバックキャストしたい。夢を見ないと良い方向には行けないけど、現実を見ないと一歩が踏み出せない。そこのジレンマを受け入れて全体を思考する。今度のSpring勉強会が、そういう場になればいいなぁ。WS形式じゃないから、なかなか難しいけどね。
