arclamp

ITアーキテクト 鈴木雄介のブログ

JJUG CCC 2015 Fallご報告

2015/11/28(土)にJJUG CCC 2015 Fallベルサール新宿グランドにて開催しました。

セッション30個、ハンズオン2個、ブース4社、スポンサー11社という規模になり、参加677名(登録1129名)という結果でした。ご参加いただいた皆様、セッションをしていただいたスピーカーの皆様、セッションならびにブーススポンサーの皆様、それからボランティアも含めて運営スタッフの皆様、本当にありがとうごさいました。

今回のCCCは幹事会メンバーが増えてから3回目、いろんなトライをして、上手くいったり、いかなかったり、大変に学びの多い会となりました。ご迷惑をお掛けした点があれば大変申し訳なく思います。KPTもたくさん出ていますので、次回に活かしたいと思います。良い点にせよ、悪い点にせよ、フィードバックをしたい!という方はお近くの幹事メンバーなり@JJUGまでご連絡ください。JJUGの健全性を保つのはコミュニティの力です。

f:id:arclamp:20151128203148j:plain
恒例となった懇親会でのLT大会の様子

セッションの中でコミュニティディスカッションという時間があり、懇親会の準備をしていたので中途半端にしか参加できませんでしたが、コミュニティ運営に皆さんが悩んでいるんだな、ということを改めて感じることができました。

僕は何の因果か日本Javaユーザーグループ(JJUG)というJavaコミュニティの会長をしています。メンバーは4000人を超えたぐらいです(イベントの延べ参加者と思っていただければ)。JJUGは僕が立ち上げたわけでもありませんし、日ごろJavaをバリバリと書いているわけでもないですが、僕をエンジニアとして成長させてくれたJavaコミュニティへの恩返しが少しでもできればと思ってやっています。

会長として僕が唯一こだわっているのがお金のもらい方と使い方です。コミュニティは多くの善意によって支えられているので、基本的にお金の話にはなりません。ただ、どうしてもそれなりの規模のイベントをやるのであればお金がかかります。なので誰からお金をもらって、どこに使うのか、というのは大切なことだと思っています。そこで何を考えているのか、というのは、あえて字に書いて説明するものでもないですし、その結果が健全かどうかは、参加して感じてもらうものだと思っています。

お金とコミュニティのことを考えられるようになったのは、やっぱりデブサミを通じて岩切さんと知り合ったからだと思います。あれだけの規模のイベントを参加者無償でやれるというのは本当に素晴らしいことです。その裏側をほんの少しでも知れたことはとても特別な体験だと思っています。会場選びとか、スポンサー集めとか、勝手にすごく影響を受けています。

僕の希望はコミュニティというものが健全に社会や企業と関わり合い、持続していくことです。なんなら、JavaがなくなってもJJUGが続いてほしい。そこはエンジニアにとって楽しい場であるとともに、ユーザー企業にとっても有意義な場所であり、ベンダーにとっても大事にしたいと思える場であり、その他、関わる人々にとって素敵な場所でいてほしいと思います。

僕が「JJUGがどこに進むべきか」を示すことはこの先もないと思います。ただ、皆のJJUGがどうあってほしいのかをつなぎ、その健全性を(僕の価値観の中ですが)維持できればと思います。

というわけで、参加をお待ちしております。


PS 僕の講演資料はこちらです。Javaは関係ありません;-p

ソフトウェア開発におけるデザイン視点の変化

2015/11/14(土)に開催されたJavaOne2015報告会で話をしてきました。資料は以下。

この資料を作る中で気づいたというか、思ったことは、この20年でソフトウェア開発におけるデザインの視点が変化しているな、ということです。

ユニットテストDIコンテナが変えたもの

ユニットテストは衝撃的なものでした(はい、僕も@t_wadaの薫陶を受けたのです)。

ユニットテストを端的に説明するなら「自分で書いたコードを、自分のコードで確認する」ということですが、いわゆる「テスト」というよりは「実装技法」であると考えたほうがよいと思っています。

(それはTDDの事だとか、UATとしてのテストコードは別の意味があるとか、そういう話を含めたとしても、僕はユニットテストを実装技法だと理解しています。話がややこしいですが、「単体テスト」はテストでしょうね)

もちろん、DIコンテナも大きな変化でした。「依存性を注入する(Dependency Injection)」とは、ランタイムで依存するインスタンスを(APIは同じままで)切り替えることを意味します。DIコンテナは「アプリケーションがコードによって動作変更できるようにしておく」ことを保証するための強力なツールでした。


僕にとってユニットテストDIコンテナがもたらした変化は、ソフトウェアデザインの視点が「クラス」から「インスタンス」になったことです。

ユニットテストDIコンテナに慣れ始めた時期、UMLで詳細なクラス図を書くことに苦労したのを覚えています。なぜならユニットテストやインジェクションを書きやすくするためのクラス構造というのが、ビジネスロジックとして適するクラス分割の美しさとは別物だったからです。だから、ビジネスロジック観点の概要クラス図しか書く意味が無くなりました(実装差異が出る代表的な要素はインターフェースクラス、Privateスコープメソッド、設定の分離、フォルダ構成などでしょうか)。

つまり、ソフトウェアをデザインする上での美しさが「インスタンス化し動作された状態において、いかにシンプルさを保てるのか」に変化したということなのです。結果として静的な構造としての複雑さを招いたとしても、インスタンス化された構造を優先させるべきでした。

クラウド(プラットフォーム)が変えたもの

そして、現在においてはソフトウェアデザインの視点が「インスタンス(アプリケーション)」から「サービス」に変化しています。

「サービスがコードによって動作変更できるようにしておく」あるいは「サービス化し動作された状態において、いかにシンプルさを保てるのか」と書いてもよいでしょう。それはクラウドのことであり、SDx(Software-Defined anything)のことであり、CI/CDのことであり、DevOpsのことです。

資料で紹介しているカナリアリリースやダークカナリアリリース、あるいはChaos Monkeyのような仕組みはサービスがコーディング可能であることから生まれています。

現時点では「クラウドデザインパターン」と呼ばれていますが、プラットフォームの能力を最大限に引き出すようなデザインが重要になっています。マイクロサービスはアプリケーションを複雑に分割しますが、それがサービスとしてのシンプルさを維持するのです(かと言って、過度は複雑さは崩壊を招きますが...)。

僕にとって「サービス品質がコーディング可能である」というのは、ユニットテストDIコンテナの時に感じた「アプリケーション動作品質がコーディング可能である」という衝撃と似ています。

ソフトウェア開発におけるデザイン視点の変化

もう少し詳しく、下の絵を見てください。これはソフトウェア品質モデルを図示した物です。

f:id:arclamp:20151116192812p:plain

ソフトウェアの品質は右から「利用時の品質」「外部品質」「内部品質」「プロセス品質」に類別されると考えられます。これを「ITサービスの品質」「アプリケーション動作の品質」「クラス構造の品質」「プロセスの品質」と置き換えてみましょう。

その昔、エンジニアがコードで管理できるのが「クラス構造」だけであったものが、ユニットテストDIコンテナによって「アプリケーション動作」も管理可能になり、さらにクラウドの現在では「サービス」も管理可能になった。様々な技術や手法の発達が前後しながら、これを促進したのです。

何度か書いていますが、エンジニアの主戦場は「ソフトウェア開発(プログラミング)」から「サービス運営」に移ってきています。

とはいえ、まだまだ「サービスをコードで管理する」ことは未成熟な状況です。一部の先進的な企業やエンジニアの取組みを行い、その結果がOSSや事例紹介という形で広まりつつあります。なので、今が学ぶ良い機会でしょうね。興味を持たれた方は、ぜひ、触れてみてください。

たとえばJJUG CCC 2015 Fallとかでね(ステマ)!

エンタープライズにおけるDevOpsとマイクロサービス - JavaOne2015レポート

バズワード過ぎてタイトルにするのも憚られるのですが、JavaOne2015でキーワードになったことは間違いないので...。

JavaOne2015でもDevOpsやマイクロサービスについてのセッションが多く見られました。昨年はマイクロサービスというとWebアプリケーションフレームワークからの理想論的な話が多かったですが、今年はわりと事例に基づいた話が多かったように思います。ただ事例は事例で抽象的な話にならざるを得ないわけで、目新しい話があったわけではないように思います。

あと「JavaJVM)を使っているよ」というだけのことで、直接的に「Javaでどうすべき」という話は少ないです。これもDevOpsやマイクロサービスが特定の技術の依存しているわけではないから当然のことかと思います。


事例そのものはよく知られたWebサービス系の事例が中心となっていますので、Netflix、Gilt、TwitterFoursquareなどが色々な話をしていました。これらの事例は、まさにマイクロサービスとして数百のサービスを稼働させています。

よって、技術的なキーワードはランタイムの制御を行うことに力点が置かれていました。具体的には以下のようなものがあげられます。

  • デプロイ管理:Jenkins、spinaker
  • コンテナ:Docker
  • コンテナ管理:Kubernetes、Marathon+Mesos、spinaker
  • ルーター:Vamp、Zuul+Ribbon、ロードバランサ
  • サービスレポジトリ:ZooKeeper、Eureka
  • 分散ログ集約+視覚化:Elasticsearch+Kibana、Vector


これらの技術群はサービス全体をダウンさせることなしに継続的にサービスの変更を許容するための仕掛けです。代表的な概念が「カナリアリリース」でしょう。

カナリアリリースは現状バージョンのサービスがリリースされている状態で新バージョンのサービスを並列してリリースし、段階的にアクセス先を新バージョンに切り替えていきながら、何か問題が発生したら現バージョンにアクセスを切り戻す(ロールバックする)というものです。「A/Bテスト」や「ブルー・グリーン・デプロイメント」と呼ばれる手法とも近しいものですね。

f:id:arclamp:20151109220814j:plain
カナリアリリースの説明。新しいバージョンに5%を振ることでA/Bテストになる

カナリアは炭鉱で鳥かごにいれられて天井近くに吊るされており、有毒ガスが発生すると騒ぐため「問題の発生を先んじて発見する象徴」として使われています(カナリアにとっては迷惑な話でしょうが)。

Giltの事例では「ダークカナリアリリース」という言葉で「開発者だけがアクセスできるテストバージョンのサービスをリリースする」という話をしていました。マイクロサービス環境ではサービスをテストするのに周辺サービスをセットアップしないと稼働確認がしにくいわけですが、周辺サービスのセットアップは大変なので、そうであれば本番環境にテストバージョンのサービスをリリースしてしまい動作確認をしたほうが効率的というわけです。もちろん課金などの関わる本番に影響を与えるようなサービスについてはテスト環境を持っていると話していましたが、そうではないサービスは本番でテストしたほうが効率的なのでしょう。

f:id:arclamp:20151109215809j:plain
Giltのセッションでの1ページ。『我々は本番環境でのテストはいけてると考えている』

また、NetflixにはChaos Monkeyという「障害をランダムに発生させるツール」があるのですが、AWSインスタンスは毎週、アベイラビリティゾーンあるいはリージョン丸ごとは毎月障害を発生させているそうで、知ってはいたものの実際に聞いても信じられないという思いが先に来てしまいます。

f:id:arclamp:20151109221057j:plain
Netflixのセッションで紹介された動画。左上のリージョンがダウンし、アクセスが他のリージョンに移った後、リージョンが復旧して戻っていく様子


エンタープライズ業界にいるとダークカナリアもChaos Monkeyも「それは厳しい」という話かと思います。もちろん「テスト環境よりも本番環境でテストしたほうが良い」とか「本番で障害訓練をしていたほうが本当の障害に対応できるようになる」というのが合理的であることは間違いありません。しかし、その結果として「全体的にサービス品質を高めるためには部分的な品質劣化を許容する」というのは「部分の品質を積み上げることで全体の品質を担保する」というエンタープライズ的な考え方からすると理解しがたいものです。

Netflixの考え方は「運が悪いユーザーがいることを許容することで大規模なサービスダウンを未然に防ぐ」というものですが、講演者も「Netflixがダウンすることは悲しいけど、とはいえ、絶対にダウンしてはいけないサービスではないことが前提だ」と強調していました。「軍事、医療、金融といった分野で許される考え方だとは思わない」と。

よって、DevOpsというか、マイクロサービスというか、Web企業の先端的な取り組みについては「それはそれで効率的なことは理解する」ものの「すべてのサービスがそうなるべきかは別の話」ということでしょう。

また、マイクロサービスにしても「チーム個別の自治権を許容する」ということは、チームごとに品質のばらつきがあることを許容することと同じです。これもまた従来型の品質管理からすると受け入れがたいものですね。


もちろん、エンタープライズにおいてもカナリアリリース的発想は重要でしょうし、それが認められる分野も間違いなく存在します。システム連携が複雑になる中で「単体アプリケーションレベルでの完璧な品質」など意味がないのであれば、サービス全体の品質を判断基準にしていくのは当然のことでしょう。

ただ、現状で取り組もうとすると先ほど上げたような技術群は安定的とはいいがたく維持コストは相当なものとなるはずです。とはいえ、エンタープライズでもDockerがデファクトスタンダードになりつつあるわけで、コンテナ技術を前提としたプラットフォームマネジメントツールが一般的になってくるのは間違いないものでしょう。

たとえばAzureではセキュリティアップデートのために仮想マシンの自動的な再起動が起きるため、これを前提としたアーキテクチャ(異なるロール間の受け渡しにはキューを利用する)を採用する必要がありますが、こうした割り切りは今後も増えていくはずです。


クラウドを契機に品質の概念はずいぶんを変わったものになりつつあります。例えて言うなら「ガベージコレクションがメモリ管理を不要にした」のと同じように「プラットフォーム管理ツールインスタンス管理を不要にする」という未来が待っているのでしょう。

アジャイルウォーターフォールと同じように「既存の考え方を安易に否定する」のはダメですが、全体的な潮流を理解しながら技術の使いどころを俯瞰していくことは重要ですね。

JavaOne2015のサマリ

2015/10/25-29日で行われたJavaOne 2015に参加してきました。

来年のJavaSE 9および再来年のJavaEE 8に向けた端境期であったこともあり、近年まれに見る発表要素の少ないJavaOneでありました。

特に初日のキーノートでは、Java 20周年であったことから、スコット・マクニーリがやらかしたので最低限のお祭り気分は維持されたものの、昨年からのアップデートも少なく、特筆すべき話題はありません。

f:id:arclamp:20151025155406j:plain
キーノートで言いたい放題のスコット・マクニーリ

一方、最終日に行われたコミュニティキーノートはバック・トゥ・ザ・フューチャーを模した寸劇の連続で、2009年に遡れば「SUNがORACLEに買収されちゃった!どうしようJavaが有償になっちゃう!」とか「OSGiは古い、これからはJigsawだ。ORACLEなら2010年か2011年には仕様になるよ!」と言ってみたり、2004年に遡れば「Javaオープンソース化されてOpenJDKができるだって!なんてSUNは素晴らしいんだ。これでどっかに買収されるなんところはなくて未来は安泰だね!」などなどコミュニティメンバーが言いたい放題で大いに盛り上がりました。

f:id:arclamp:20151029135157j:plain
コミュニティキーノートの寸劇の最後は20年後の未来で暴れていたDukeを子供が救ったというハッピーエンドで(だから40周年おめでとう)。後はみんなで檀上に上がってケーキを食い尽くす

「さしたる発表もなかった。Javaは勢いがない」という意見もあるところですが、直前にORACLEがJavaエバンジェリストの解雇を発表したりと、Java全体としては明るい話題は少ない中でも「Javaの独立性は保たれている」という気概は現れていました。

以前も書いたようにORACLEの良さは淡々とスケジュール通りにリリースするであり、コミュニティとの関係をうまく保ちながら前に進んでいると思います。昔のような派手さがないことは寂しい一方で、イベントとしてはモスコーニから少し離れたHiltonとParc55を根城に好きにやらせてもらっているのだと思います。


少し技術側からの話題を。

IT業界全体としてはIoTブームではありますが「サーバサイドとしてのJava」「タブレットや組み込みとしてのJava(含Android)」は、もはや語る必要もないほど活用されていることでしょう。「IoT」というキーワードは出るもののORACLEとして製品が出るわけでもなく、普通に「使われているよ」というアナウンス程度だった気がします。

IoTについては「機械の稼働状況を広く収集し分析してメンテナンスに役立てる(広く言えばF1も含めて)」という定番はあるものの、そこから踏み越えた事例が出てきていません。ようは「これまでの技術の組み合わせ」であり「個別のニーズが多岐に渡りすぎる」ことからソリューション化がしくくく「ベンダーとしてIoTで儲けるのは困難」という結果として言葉の勢いが落ち着いてくると思われます。

むしろ、AWSやAzureをはじめとしたクラウドサービスとしては「収集と分析」という部分で強みを発揮しており、ここで乗り遅れているORACLEは存在感を発揮しきれていません。OOWではクラウドサービスの発表もあり、JavaOneでも「ORACLE CloudでJava」という内容は何度かは出てくるのですが「推してます!」というよりは「こういうものありますので…」程度のものでした。

JavaOneにおける僕の観測範囲では「DevOps」や「API」を基軸にした技術が注目だったのですが、そちらは別記事にて。

いずれにせよ、来年はJavaSE 9のリリースと合わせてJavaOneが開催されます。まだ、何が入るのかは議論の余地があるところですので続報を見ながら楽しみに待ちたいと思います!

f:id:arclamp:20151028200844j:plain
お約束のトレジャーアイランドでのパーティ

柔軟なウォーターフォールはアジャイルと見分けがつかない

2015年10月21日に行われたエンタープライズアジャイル勉強会2015年10月セミナーでの講演『エンタープライズアジャイル全体最適について ~アーキテクチャ設計とウォーターフォールの必要性~』のレポートです。資料は以下。

講演の後の懇親会で「計画的なアジャイルと、柔軟なウォーターフォールは見分けがつかない。ていうか、名前だけの問題だ」という話になりました。

資料でも書いているとおりエンタープライズ案件はリリース日について厳密なコントロールを求められます。一方で、多くのプロジェクトではリスク管理が重要であることは間違いなく、だからこそ、アジャイルでもウォーターフォールでも(まともなプロジェクトであれば)実質的なオペレーションは似通ったものになるというのです。

確かに、僕の経験から言っても、一度アジャイルを経験してしまうと「ウォーターフォールかどうか」というのは希薄になって「計画すべきはどこか、作って試すべきはどこか」という問いが重要になります。

最近の案件でも「アジャイル開発でやりたい」と言われたところで、結局、リリース日や必須機能が決まっていれば、アーキテクチャ設計を入念にやって、確度が上がったら長めなバックログを作って、中期のマイルストーンを決めて、他システムを巻き込むテスト計画を立てて、となってきて「あれ、これウォーターフォールじゃね?」ということがあります。ただ、もちろんのことながら、必要なだけのプロトタイミングやオンサイトやペアプロやオンライン情報共有や自動化や、様々ないわゆるアジャイルなプラクティスはやればいいだけです。

よって、「十分に柔軟なウォーターフォールアジャイルと見分けがつかない」というか「十分に計画的なアジャイルウォーターフォールと見分けがつかない」わけです。こうなってくると、たしかに呼び方だけの問題かもしれません。

喩え話的に「COBOLからJavaが主流になった瞬間、もはやCOBOLで作ろうなんて誰も思わないけど、実際にはCOBOL的なJavaはあったし」というのが引き合いに出たのですが、つまり「ソフトウェア開発といえばアジャイルプロセス」というのが「常識」となった瞬間に「ウォーターフォールアジャイルの亜種」になるのではないか、というのです。言語と開発プロセスを並べるのは簡単ではありませんが、言いたいことは良く分かります。

僕も「アジャイルを目的にした開発は嫌い」ということは言ってきたのですが、世の中の認識が「普通、アジャイルでしょ」となってきているのであれば「ウォーターフォール的な要素も残そうよ」という言い方にしていってもよいかもしれません。とはいえ、エンプラ系の講演で「もう普通はアジャイルですよね?」とかいうとぽかーんとされそうですが...。

なお、資料の方はプロセスとして「ウォータフォールとアジャイル」、アーキテクチャとして「SOAとMSA」と対比させ、現在は後者を主流としながらも、どちらも必要な要素であることをお話させていただきました。どちらも「トップダウンボトムアップ」の対比として考えることができますよね。

SOAとMSAの比較も盛り上がりましたが、それはまた別の機会にでも書きます)

アーキテクチャ設計の意味を問う - クリストファー・アレグザンダーの思考の軌跡

建築家クリストファー・アレグザンダーが「パターン」という概念を広め、それがウォード・カニンガムケント・ベックによってソフトウェア開発のデザイン・パターンに応用されたことをご存じの方も多いでしょう。

(ご存じでない方には、江渡さんの「パターン、Wiki、XP ~時を超えた創造の原則 (WEB+DB PRESS plusシリーズ)」をお勧めします)

クリストファー・アレグザンダーの思考の軌跡―デザイン行為の意味を問う」は、そのアレグザンダーがパターン・ランゲージに至った経緯、そしてパターン・ランゲージの限界を超えていった流れを追うことができる本です。

この本を読むと、アレグザンダーは一貫して”数学的”であり、客観的に証明可能な構造を求め続けたからこそ、近年では”神”の視座へと導かれていったのだと分かります。

パターン・ランゲージと設計プロセス

アレグザンダーはパターン・ランゲージによって、モノの”形”と、それに対する人の”価値”の美しい関係性を探求していました。

ある形をデザインする際の難しさは、複数の要求に対して全体的な整合性を取ることです。ソフトウェアのアーキテクチャ設計でも性能と保守性、コストとセキュリティなどの要件は「こちらを立たせれば、あちらが立たず」になりがちです。

そこで、パターン・ランゲージと呼ばれる複数の「部分的な形の基準(=パターン)」を用意しました。パターン・ランゲージを用いて要求を部分へと分解し、それらを再統合していく過程で、部分ごとに要求と形のギャップを解決していけば、美しい形を自動的に作り上げていけると考えたのです。

パターン・ランゲージが興味深いのは、単に「優れたパターンを用意しました」ということではなく、「パターンを基準として要求とのギャップを探索することで、段階的にデザインが進められる」という設計プロセス論であり、かつ、それは「誰が使っても同じ結果に至る」ことを前提にしていた点です。

機能の限界

しかし、こうした設計プロセスでは「形と価値への探求」が「形に与えるべき機能」と「機能がもたらす価値」という議論に分裂することが分かりました。そして、アレグザンダーは「機能」の議論を突き詰めていっても美しい形にはたどり着けないことに気づいたのです。

そもそも、人は「”形そのもの”に価値を感じる」のではなく、その「”形がもたらしうる機能”を通じて価値を解釈する」こと、言い換えると「形への意味づけ(≒機能)によって価値を考える」ことが脳の構造的に好きなのです。よって、価値と形を直接的には結びつけずに「価値から機能へ、機能から形へという変換」が発生していたのです。

この変換には、どうしてもデザイナーの志向性が反映されてしまうため「誰が使っても同じ結果に至る」ことができないのはもちろんのこと、美しいものとはなりませんでした。

なぜ通販番組で物が売れるのかと言えば、それは「触れて分かる形への直感的な価値を感じた」ではなく「機能への説明に対する概念的な価値を感じた」によるものなのでしょう。しかし、買った物を使い続けられるのかというと、それはまた別の話なのです。「美しいと感じる」ことと「機能が優れている(と納得した)」ことには乗り越えられない壁があるのです。

これは現代的に言われる「デザイン手法」に対する痛烈な皮肉とも捉えられます。つまり、「よく考えられたデザイン」であるほど、それは「機能と価値」という概念的な議論にすぎず、「形と価値」という具体的なモノ(存在)への探求ではないわけです。

中心的な価値基準の存在

この絶望は、アレグザンダーを次の段階へと進めます。

アレグザンダーは『(形に対する)諸価値基準の相違は、ある1つの中心的な価値基準に訴えることで解消できる。<中略>それをわれわれは一者(the One)や無(the void)や偉大なる自己(the great self)と呼んでもいいだろう』という、”いっちゃった”考えにたどり着きます。

とはいえ、論理は明快です。人は価値を機能によって考えがちではあるが、理由無く形に感動できるので、やはり、「形と価値はどこか深いレベルで直接的に関係している」としたのです。

そこで「価値は(形の)全体性からもたらされる」と考え、さらに「機能は全体性の動的側面に過ぎない」としました。

たとえば建物というのは、その形が独立して存在するものではなく、その周りにある庭や道路や隣家や、あるいは街や国のような存在から連続した全体性として存在します。そして、機能というのは「全体性の中で(構造が見いだされるときに)立ち現れてくるもの」だとしました。

こうなると機能を追い求めることは無意味となります。機能は全体性から生成されてくるものなので、機能そのものを直接定義することはできないのです。むしろ、優れた機能を提供し続けられる構造そのもの、つまり、形そのものを探求する必要があります。

よって、機能を部分的な静的構造と紐つけたパターン・ランゲージは否定され、価値ある機能を生み出し続けることができる構造を特徴づける幾何学的特徴を探求し、15個の幾何学的特徴を提示しています。

この15個は「自己と似ている形を探し続ける」という不思議な手法で見つけられています。アレグザンダーは形に対して感じる美しさ(≒価値)というのは「自己の中にある究極的な自己」と「全体性から現れる瞬間的な構造」が一体になることでもたらされるとしています。よって、「自己と似ているもの」を探すことが、美しいものを探すことになるのです。

この説明は形而上学的なので一見するとオカルト的ではありますが、形と自己に対する純粋な解釈によって成り立っています。この力強い精神は、納得感とは別として感銘を受けるものです。


戦い

2012年にアレグザンダーは"The Battle"を発表しています。これは日本の盈進学園東野高等学校で起きたことをまとめたものです。東野高校はアレグザンダーの成功例として知られていますが、これを作り上げるにあたり起きた様々な出来事をしるしています。

この部分はぜひ本で読んでいただければと思いますが、ソフトウェア開発の人にとっては「ウォーターフォールアジャイルのせめぎ合い」を感じることができると思います。

そして、そこで語られるアジャイル的思想の純粋さに恐ろしくなるはずです。開始時点では完成形は分からない、費用は予算によってのみ決まる、実物を触ることでしか設計しない、完成した物に対して常にフィードバックを行って修正する。これをウォーターフォールしか知らない人たちと共にやりきろうとする。これがアレグザンダーが経験した戦いなのです。

ソフトウェア開発におけるアーキテクチャ設計

さて、せっかくですから最後にソフトウェア開発におけるアーキテクチャ設計に寄せましょう。

アレグザンダーがパターン・ランゲージを諦めたからと言って、デザイン・パターンが無意味であったわけではないでしょう。ただ、やはり現代においては意味が弱くなったとは考えたほうが良いように思います。

おそらく、現代のソフトウェアは、アレグザンダーの言う全体性の議論を考慮しないといけないほど、部分では語れない連続的なものへと成長したと捉えるべきなのでしょう。静的(クラスの構造)なパターンは、ある閉じた系においては美しく存在できますが、開いた系では周辺からの圧力によって美しくはなれず、むしろ、美しさとは動的(インスタンスの動作)に現れるものなのです。

これがマイクロサービスアーキテクチャの議論に結びつきます。マイクロサービスアーキテクチャは、静的な構造としてだけではなく、各システム間の依存性や開発プロセスといった動的な要素を取り入れています。これがソフトウェアアーキテクチャ論の進化の方向性であることを感じさせてくれるのです。

最後に「優れた物から見つけられた秩序を他者が実践しても優れた物ができるとは限らない」ことを付記しておきます。「成功した人の手法を真似ても成功するとは限らない」という身も蓋もない話です。アレグザンダーが言うようにデザインとは「する」ものではなく「成る」ものなのです。


企業システムとマイクロサービス #DF15

Salesforce.comのグローバルイベントであるDreamforce 2015(2015/9/15-18)に初参加してきました。仕事ではAWSもAzureも使うのですが、今回は最近なにかと縁があるSalesforceの雰囲気を感じに。

現地では事例セッションを中心に聞いて回りました。ご存じの通りSalesforceエンタープライズ領域で使われるものなので、事例もエンタープライズ系が多くなります。エンタープライズということは「既存システムがある」ことが前提になるので、それらの既存システムとSalesforceをどのように統合するのか、というのがアーキテクチャ設計上の重要なポイントとなります。

(もちろん、スタートアップのベンチャーSalesforceを活用してビジネスローンチを早めた、なんて事例もありますが、この場合は既存システムが存在しません)

各セッションでは既存システムを「ドメインサービス(Domain Service)」と表現しており、それらとSalesforce(あるいはHeroku)はAPIを通じて統合されます。
ドメインサービス」というのはDDD用語ですが、特定のビジネスドメインにおけるサービスを指しています。企業システム全体の視点から見ているので、粒度は「棚卸システム」「商品カタログ」「支払」「顧客情報」なんで感じです。
ドメインサービスは、それがクラウドかオンプレかということは関係ありません。「企業内における特定ドメインのサービスである」ことが重要であって、サービスが提供できていれば実装方式はなんでもいいのです。
以下は百貨店Macy's(メイシーズ)の講演で使われていた資料です。

f:id:arclamp:20150915154315j:plain

連携に使われるAPIはバッチ系、オンライン系、画面連携系と類別され、それぞれの統合するデータ量やタイミング、あるいはビジネス上の結合度などで使い分けられます。IoTクラウドも発表されたので、今後はリアルタイムストリーム系という統合も可能になるのでしょうね。
以下は家電量販店Target(ターゲット)の講演で使われた資料。バッチ連携をData、オンライン連携をBusiness、画面連携をUIと表現しています。

f:id:arclamp:20150917103958j:plain

また、企業システム内の各サービスを総称して「マイクロサービス」と呼ぶのは一般的なようでした。「うちの企業にはXX個のマイクロサービスがあって、統合されている」という言い方です。
前回のSpringユーザー会の夏イベントでも話しましたが、マイクロサービスアーキテクチャは「マイクロ」という単語に惑わされず「サービスを複数のサービスから構成する」という関係性に注目して理解すべきです。


というわけで、各セッションは「当然そうだよね」という話ばかりだったので違和感もなく聞けました。やはり、エンタープライズの文脈からもマイクロサービスアーキテクチャ的な考え方は有効であり、クラウドも、その一部として配置すればいいだけです。

印象的だったのは上記のようなユーザー事例講演はユーザー企業内のアーキテクトが話をしている点です。やはり企業全体を理解したアーキテクトの存在というのは非常に大きいなと思います。
日本国内において、その役目を誰が担うべきかは簡単な議論ではありませんが、僕自身、そうした立ち位置での仕事も増えており、今後も大きなニーズがあるのだろうことは間違いないでしょう。

さて、来月はJavaOneですね。