IT業界には「パターン」と呼ばれる形式でノウハウがまとめられることがある。汎用化したノウハウと解決すべき課題とをセットにして紹介するものだ。分析時に利用する「アナリシスパターン」、設計時に利用する「デザインパターン」などが有名である。

　日経SYSTEMSの2012年7月号の特集で、クラウドを利用したシステムを構築する際のパターンを独自に作成して紹介した。このコラムでは今回の特集をなぜ企画したかと、どのように作っていったかを説明しようと思う。

サービス非依存なパターンがなかった

　この特集の企画は当初、「クラウドを活用したシステムのアーキテクチャー設計」というテーマで走り始めた。取材を進めると、初めてクラウドを利用した開発現場は「オンプレミスでの構築と違い、クラウドは勝手がよくわからない」といった悩みを抱えていた。そこで、よく起こる課題とノウハウとがセットになったパターンを示すことができれば、きっと役に立つ読者が多いはずだと考えた。ちなみにここでのクラウドとは、パブリッククラウドのIaaS（Infrastructure as a Service）やPaaS（Platform as a Service）を想定している。

　実は、米Amazon Web Services（AWS）のクラウドサービス向けのパターンは存在する。「AWSクラウドデザインパターン」がそれだ。しかし、特定のクラウドサービスを前提としない、サービス非依存なパターンが、今の開発現場には必要だと筆者は思っていた。

　サービス非依存なパターンを作ることについて、取材先の複数のITエンジニアに意見を聞いてみた。すると、否定的な意見を言われることが多かった。複数のITエンジニアからの証言をまとめると、こういうことだ。「クラウドサービスを利用する際は、まずどの事業者のクラウドサービスにするかを選ぶ。クラウドサービスによって特性が異なるためだ。構築ノウハウが必要になるのはその後。つまり、サービスに依存したノウハウは存在するが、サービス非依存なノウハウはない」。

　話を聞いたのは一線級のエンジニアの方々である。そんな人たちに否定されて心が折れそうになったが「世間の人が意識していないからこそ、まとめる意味がある」と自分を奮い立たせた。そして、一線級のITエンジニアが否定したパターンを作るという、半ば無謀な挑戦が始まったのである。

複数の専門家の助言を仰ぎ確証を得る

　パターンの作り方はこうだ。まず、クラウドを活用したシステム構築事例を取材する。その事例の中から、ほかの開発現場でも通用しそうなノウハウを抽出する。そのノウハウを汎用化してパターンにする。

　このパターン化の作業を進めていく上での最大の問題は、筆者がITエンジニアではなく、パターンを導くのに必要な開発経験がないということだ。個別の事例から役立ちそうなノウハウを抽出することはできても、「その事例で使われているクラウドサービス特有のノウハウ」なのか「他のサービスでも応用可能なノウハウ」なのか、確信を持って判別することはできなかった。また、「パターンとしてまとめるには、あまりに当たり前すぎる」「もっと効率の良い実現方法がほかにある」といったことは避けたかった。

　そこで、前述のITエンジニアの方々を含め、多くの方から助言を頂くことにした。具体的には、汎用化できそうなノウハウについて「こういうことはよくある話ですか？」「他のサービスでも通用しますか？」「妥当な設計だと思いますか？」と聞いて回ったのだ。対面取材やメールで、一つの事象に対し複数の意見を集めた。正直、通常の特集より手間がかかっている。それらの回答を総合し、筆者が“いける”と確信したものをパターンとした。パターンは「パターン名」「解決される課題」「概要」の形式でまとめた。

　こうして6ジャンル12個のパターンをまとめた。6ジャンルとは「性能を高めるパターン」「クラウドとのシステム連携パターン」「信頼性を高めるパターン」「セキュリティを確保するパターン」「運用性を高めるパターン」「コストを低減するパターン」である。

　12個にまとめる過程で落選したものある。選りすぐった分、役に立つパターン集になったと思う。実際に役に立つものかどうかは、本誌を読んでご判断いただきたい。もちろんご批判も歓迎である。この特集を機に、クラウド開発のノウハウをパターン化するということに弾みがつけば良いと思う。最後に、パターンの作成に協力いただいたITエンジニアの方々に、この場を借りてお礼を申し上げたい。