パターンを学べばどんな技術にも対応できる：マーチン・ファウラー特別ラウンドテーブル 現場レポート ［前編］（2/2 ページ）

[構成：吉田育代, 谷古宇浩司，アットマーク・アイティ編集局]

パターンとコードサンプルの関係

ダイクス　アーキテクチュアル・パターンがソフトウェア開発の作業に容易に適用されるべき、という意見には賛成で、マイクロソフトも、サン・マイクロシステムズも、その普及に貢献していると思います。ただし、両陣営とも、これがJ2EEの世界での適用法だ、これが.NETを使った構築法だと、いい合っているのが現状です。これはあまり好ましいとは思えません。確かに、選択したプラットフォームによる制限という問題なり制約はあると思いますが、それはパターンの世界では重要ではないと思います。重要なことは、さらに高いレベルでの情報パターンがどうであるか、ということであり、.NETかJavaかというプラットフォームレベルの差異はこの際、どうでもいいことのように思うのです。そもそも、パターンに関する昨今の盛り上がりは一時的な流行なのでしょうか。

ファウラー　わたしは特別な流行だとは思っていません。パターンについて、皆さんが必ず理解しておかなければならないことを教えましょう。パターンというのは、最良のコミュニケーションを図るために存在する、ということです。この点について解説するにはコードサンプルを取り上げるのが最適かもしれませんね。

　わたしは常に、コードからあらゆる情報を得ます。ある一定の範囲で疑問に答えてくれるのは常にコードです。文章や図版というのはあいまいな部分が生じますが、コードは常に正確です。コードは、あいまい性を許さないという意味で、数学のような存在だとわたしは考えています。しかし、コードは危険なものでもあります。パターンの実装というのは、数ある実装バリエーションの1種類にすぎないからです。コードは選択したプラットフォームに縛られます。この意味では、コードを全面的に信用することはできないということになります。コードはわたしのソフトウェア開発全体に対する理解を助けますが、そこには常にある緊張が伴うのです。

　わたしの書籍（『Patterns of Enterprise Application Architecture』Addison-Wesley）でも、この点には配慮しました。パターンごとにコードサンプルを示し、さまざまな文脈から意味を取る方法を示しましたが、1冊の書籍の中で、それぞれのパターンについて詳細かつ大量に説明するには限界がありました。ただし、わたしは書籍では常に万全を期したいと考えているものですから、今回も複数のプラットフォームのコードサンプルを載せるために、発行期日を.NET Framework Service Pack 2がリリースされるまで（2002年8月にリリース）遅らせたりしました。現在進行中の仕事でも、コードが両方（.NETとJ2EE）のプラットフォームで稼働することを常に検証しています。それでもまだ緊張は存在しますけどね。

　このように道のりは決して平たんではありません。しかし、大局的に考えればマイクロソフトやサン・マイクロシステムズはパターンの一般的な形と仕様の策定によく努力してきたと思います。

開発中に進化し続けるデザイン、アジャイルプロセスの真髄

萩原　次に、アジャイルプロセスを取り上げましょう。ここではアジャイルプロセスの中でどのようにアーキテクチュアル・パターンを適用するか議論したいと思います。ファウラーさん、この点について少しお話しいただけますか。

ファウラー　アジャイルプロセスという文脈からアーキテクチャを考えるうえで重要な要素は、いつ意思決定をするか、という点です。計画決定型の方法では意思決定に長い時間を割けません。アーキテクチャに関する意思決定は、コーディングや開発の実作業前に行わなくてはならないのです。しかし、アジャイルプロセスでは、本質的なデザインやアーキテクチャに関する意思決定をできるだけ遅らせることができます。デザイン工程がコーディング工程の中に交ざってくるのです。つまりこれは、プロジェクトが進行している間、デザインに関する意思決定を絶え間なく行っていくということです。複雑な意思決定はできるだけ遅らせるのです。

　なぜこうするか。開発の初期段階というのはあまり手元に情報がないものです。しかし、合理的な範囲で意思決定を遅らせることができれば、その後に得た、より良質の情報に基づいて判断することができます。

　アプリケーションをどうデザインをするかという問題において、われわれがアジャイルプロセスを導入して感じた明らかな変化は、<<デザインは常に進化し続ける>>ということなのです。継続デザインと呼ぶ人もいます。

　デザインが開発期間中に進化し続けるということ。これこそ、ソフトウェア開発に関する既成概念に衝突した最も大きな変化です。デザインに対する意思決定作業は、プログラミング作業の前に停止するのではなく、一緒に続いていくのです。計画決定型のアプローチでは、デザイン作業を始める前に、顧客の要求のすべてを知っておかなければなりませんが、アジャイルプロセスでは、進化的な変化を開発作業全体を通じて、継続的かつ段階的に取り込んでいくことができるのです。

仕様変更ごとに高額な追加費用を請求する

　かつて米国で、5年間に及ぶ金融関係のソフトウェア開発プロジェクトを手掛けたことがあります。この案件で一番ショックだったのは、開発作業の途中で顧客企業のビジネスプロセスが根本的に変わってしまったことでした。プロジェクトがスタートした1998〜1999年ごろにこの変化を予測することは不可能でした。ビジネスプロセスの変化は技術革新によってもたらされる場合のほか、新たな市場の創出によっても起こります。ビジネスプロセスとソフトウェア技術とは車の両輪なのです。両者がどのような変化をたどるかは、どんな人にも予知することはできません。しかし、アジャイルプロセスは、変化は起こるものであると覚悟を決めているため、変化と共生していくことができるというわけです。

平澤　進化デザインについてはよく理解できました。わたしがお伺いしたいのは、仕様変更の受け入れと契約についての関係です。ファウラーさんのお話ですと、アジャイルプロセスの場合は、変更を是として受け入れていくことになるので、もし一括請負契約で受けると、コストとの兼ね合いからそれをどうコントロールするかが問題になると思います。それについてはどうお考えですか？

ファウラー　基本的に、一括請負契約という考えは危険な幻想だと思っています。

平澤　それは開発者側の立場から？

ファウラー　開発者と発注者、両方の立場から。以前大きなコンサルティング・ファームに勤めていた友人の営業マンがいっていましたよ。彼がそのコンサルティング・ファームを辞めた理由の1つは、担当した開発案件で仕様変更を勝ち取るたびに報酬を受け取れる仕組みだったからです。その企業では一括請負契約を安い価格で受け、仕様変更で非常に高額な費用を請求していたのです。こうしたことは珍しいケースではありませんが、顧客企業にとっていいことではありません。一括請負契約は、開発を開始する前に相手の要求仕様が完全に理解できている場合にはいい考えですが、実際にはそんな状況にほとんど遭遇したことがありません。

一同　（笑）。

ファウラー　顧客企業が一括請負契約を選択すれば、そのリスクの付けが開発するアプリケーションに回ります。なぜなら簡単に仕様変更ができなくなるからです。もし、そうした状況が起こらなかったとしても、一括請負契約は顧客企業にとって大きなリスクとなるでしょう。なぜなら、開発側は要求どおりにしか作らないので、それが彼らにとって使えるものであるかどうかは尋ねません。それで結局終わってみると、コストを掛けたにもかかわらず、求めるソフトウェアは手に入らないということになっているのです。必要なのは、もっと協業的な、パートナー関係を基本にしたアプローチだと思います。一括請負契約はIT業界の恐ろしい特性です。訴訟により開発者の地位が脅かされる可能性もあります。一括請負契約は顧客企業にとって最悪の契約です。大きなコンサルティング・ファームの多くがこれで大もうけしていますよ。わたしたちも一括請負契約を受けるときがまったくないとはいいませんが、顧客企業と協業的な関係が築けるという確信が持てない状況ではそうしたリスクを冒さないようにしています。

（後編［2004年6月15日公開予定］に続く）