2016年現在のJavaについて

Sun MicrosystemsがOracleに買収されたのが2009年ですから、あれから7年が経ちました。

2013年、Javaは大人になったはずだった

僕は2013年に「イマドキのJavaとORACLEについて - arclamp」という記事をアップし、次のように書きました。

そんなわけで「ORACLEはJavaにコミットしているのか？」という質問が無意味なぐらい、ORACLEはJava技術だけではなく、Javaユーザーの方を向いているのです。

もちろん、ORACLEは（SUNに比べて）イノベーションが足りないとかスピード感がないとか批判もできるのですが、これだけエンタープライズのユーザーが増えた中では、Javaの後方互換性を保ちつつ、着実に進化していく、つまりは引き続き安心してJavaを使うことができるというのは大きな価値でしょう。

そう、Javaは本当の意味でオトナになったのかもしれません。

2009年の買収に前後して混乱していたJavaの動きは、2013年ごろには確かに前を向いて動いていました。

2015年、Oracleの推進力が落ちてきた

しかし、2015年頃から「オラクルがJavaエヴァンジェリストを削減」ということや、重要人物がJava担当から外されたという情報が相次ぎました。

さらに2016年になるとJava EE Guardiansが設立されました。Java EE Guardiansは、Java EEの仕様策定においてOracleの推進力が弱まっていることを懸念し、この改善を目指すコミュニティ活動です。そして、Oracleへの改善要求を行い、Java EEを推進力がある企業に任せるべきだ、という提案を行っています（参照： Java EE Guardiansへの支援表明と活動紹介 ）。

こうした動きの裏には、Oracleがクラウド戦略を加速するために社内の優先順位を変えているからだと言われています。今年のOracle Open Worldでは「OracleのエリソンCTO、IaaS注力でAWSに“宣戦布告”」という発表をしています。

2016年、Javaはどうなっているのか

では、このままJavaの勢いは落ちてしまうのでしょうか？僕が今年のJavaOneは感じたのは、そんなことは気にしないコミュニティの勢いです。このことを伝えたくてJavaOne 2016 報告会 @ 東京でも「JavaOne2016総括」という発表をさせてもらいました。

標準Javaの歩みが遅くなっても誰かが追い越していくだけ

JavaOne 2016におけるOracleの発表はたいしたものではありませんでした。それよりもIBMによるOpenJ9の発表は拍手が起きる内容でした。OpenJ9はIBMの商用JVMであるIBM J9をオープンソース化するもので、OpenJDKに含める形でも公開されます。しかも、OpenJ9は既にオープンソース化されているEclipse OMRをコアにしています。

Eclipse OMRというのは「言語の実行環境を作るためのツールキット」です。スレッド制御、GC、JITコンパイラなどの言語に非依存な実行環境の機能を提供し、各言語向けに実行環境を作るためにはグルー（糊）部分だけを開発すればよいようになっています。
昨年のRubyKaigiではRuby版（プレビュー）を公開しています（講演：It's dangerous to GC alone. Take this! - RubyKaigi 2015）。なお、Python版も公開予定があるようです。

現在のOpenJDKはSun時代から引き継がれているHotSpotがコアとなっていますが、Java9以降はHotSpotベースのOpenJDKとOpenJ9ベースのOpenJDKが存在することになります。IBM J9は起動の高速化とフットプリントの低減が実現されています。おそらく、この特性はOpenJ9にも受け継がれるでしょう。当然、OpenJDK9に向けてHotSpotの改善も予定されているので、その比較は興味深いです。

参照：J9: Under the hood of the next open source JVM

IBMはオープンソースを活用して実質的な標準を奪取することに長けています（参考：Google対OracleのJava API訴訟。歴史的経緯とIT業界への影響を考える。JJUGナイトセミナー）。

一方でマイクロソフトもCoreCLR（共通言語ランタイム）をオープンソース化しており、LinuxやMac上でも.Netを動かそうとしているので、言語ランタイム基盤の争いが始まっているのかもしれません（参考：CoreCLR がオープン ソースに）。

Oracleが主導する標準Javaと関係なく世の中は動いています。標準Javaの歩みが遅くなっても誰かが追い越していくだけなのです。

JavaOneはコミュニティの交流の場

では、標準Javaの歩みが遅くなる中でJavaOneというのは、どういう存在だったのでしょうか。正直に言ってOracleによるキーノートでは目新しい発表はありませんでした。Java EEはロードマップが示されたものの、その実現性には疑問を持たざるをえません。

元気だったのはコミュニティが主催するコミュニティ キーノートです。今年は「STAR WARS: THE FORCE AWAKENS（フォースの覚醒）」をパクった「STAR WARS: THE CODER AWAKENS（コーダーの覚醒）」という題目。『ダースコーダーとデュークトルーパーが銀河中の開発者からモジュールを盗んでコードがコンパイルできないようにしてしまったのです』という設定のもと盗まれたモジュールを追いかけて様々な星を巡ります。

役者（？）は世界中のJUGリーダーやOracleのJava関係者であり、最強の敵ダースコーダーにはジェームズ・ゴスリンが配役されるなど、言ってしまえば学芸会です。興味がある方は、ぜひ公式サイトの動画公開で見てみてください。Javaネタ満載のぐだぐだ演劇です。

ゴスリンが正体を明かして「I'm Duke's farther.」（私はDukeの父だぞ）というシーン。もちろん、「Lukeの父」にかかってます。ちなみに左手に持っているのは台本で、彼だけ台本片手に演じ続けていました。

僕はJavaOneが「ベンダーの話を聞きに行くところ」ではなくて「コミュニティが交流するところ」に変わったのだと感じています。このコミュニティキーノートは1年に1回世界中からJava関連のエンジニアが集まったときにやる出し物です。これは昼のイベントですが、夜には様々な交流パーティーが開催されています。

Javaの特性はエンタープライズとオープン性にあると思います。Javaの標準化プロセスと成熟したオープンソースというのは特定ベンダーへのロックインを回避するという目的では大きな意味を持ちます。そのことから、今でもエンタープライズ業界ではJavaは非常に有効な技術です。JavaOneに来ると政府や金融をはじめとした多くのエンタープライズ業界なエンジニアがTシャツとジーパンで参加しています。

僕はサーバーサイドの講演を中心に聞いて回りましたが、世界中のエンタープライズ業界で何が起きているのかが良く分かりました。

• AgileやCloudは当たり前で議論すらない（全員が導入しているわけではなくて「導入できないプロジェクトもあるよね」という状態）
• DevOpsはCI/CDから1周回って、複雑化したパイプラインの管理がテーマ
• Microservicesは「なぜ導入するのか？」という議論ではなく「導入のデメリットをいかに減らすか（リジリエントやテスト戦略など）」の議論。あとはマイクロサービス用プラットフォームの興隆
• Reacitveは議論の段階ではあるものの、マイクロサービスが増加していったときのサービス間通信のオーバーヘッドを減らすために重要であると合意されつつある

Javaを取り巻くコミュニティは非常に元気です。ただ、それはOracleが主導しているわけではありません。もちろん、標準プロセスはJavaの重要なポイントですから、Oracleを無視するわけではありません。この絶妙な関係性が垣間見えることがJavaOneの面白さでしょう。

というわけで「いまのJavaOneって行く意味あるんですか？」と聞かれたら大きな声で「ある」と答えたいと思います。ベンター側の大本営発表以外に、これほどオープンで実務的な事例やノウハウを共有できる場は多くはないでしょう。

誰がJavaを再び偉大にするのか？

IBMがキーノートに「MAKE JAVA GREAT AGAIN」（Javaを再び偉大にしよう）というキャップをかぶってきたことが話題になりました。では、誰がJavaを再び偉大にするのでしょうか？

その答えは「コミュニティ」です。

Javaという技術を使い、成長させ、将来にわたって継続してほしいと願う人がたくさんいる限りJavaは無くなりません。

たくさんいる、しかもアクティブであるというのが大切です。Java技術に価値があることを証明するのはユーザー規模なのです。なので、ぜひコミュニティに参加してください。そこにたくさんの人がいて、熱くJavaを語っている姿があること、それこそがJavaを再び偉大にするために大切なのです。

で、日本にも日本Javaユーザーグループという大きなJavaコミュニティがあります。来月の12月3日（土）には1000人規模のイベントもあります。毎月のナイトセミナーでもいいです。皆さんの参加を心からお待ちしています。

JJUG CCC 2016 Fall特設サイト

日本企業にアジャイルを導入して考えてこと #easg

2016年11月18日に行われたエンタープライズアジャイル勉強会11月セミナーにて「ユーザー企業へのアジャイル導入四苦八苦」という講演をさせてもらいました。資料は後段に。

エンタープライズアジャイルとは

「エンタープライズアジャイル」の定義は曖昧です。いわゆるエンタープライズ業界でもアジャイルをやっていこう、という方向性を合意しつつ、そのディテールは現場ごとに異なります。
弊社はSIerなので、別顧客で3つの事例を紹介しています。もちろん内容は異なりますが、いずれも以下のような条件になります。

• 顧客は日本企業で社歴が数十年以上
• システムはいわゆるSoE領域（間接的にでも売上に寄与する）
• 10人ぐらいのチームが継続的に維持される規模

こうした案件を通じた学びはフィードバックサイクル、プロダクトオーナー、アーキテクチャの三点です。

フィードバックサイクル

企業システムではリリースサイクルを「3ヶ月定期」にするのがいいと考えています。3ヶ月という期間は、

• 現場と話し合って成果を作り出すための最短期間
• 経営層として成果を評価できる最短期間
• 上記をやりながらシステムを開発するための最短期間

というような意味を持っています。つまり、日本企業の中で現場や経営層と合意形成しながらシステム開発する最短期間が3ヶ月なのです。ざっくりしたスケジュールとしては設計1ヶ月、実装1ヶ月、受入1ヶ月となります。

3ヶ月といっても顧客にとっては慌ただしく過ぎていきます。前半は企画して見積もりして部署間調整。中盤になって開発に入り始めたら説明資料を作り営業に説明に行きながら機能詳細を詰めていく。終盤は受入しながら経営層向けの説明資料を作り、リリース向けの広報作業、さらには前のリリースの評判をヒヤリングして次の企画の優先順位を考え始めなくてはいけません。そして、いざリリースされると次のサイクルが始まっている中で現場からのQA対応もしなくてはなりません。これは、なかなかタフなのです。

上記のような3ヶ月定期的リリースをしてみて感じたメリットは以下の通りです。

• スケジュールが決まっているから締め切り駆動で物事が進められる
• 「次のリリース」が決まっているから要件の押し込みが発生しにくくなる
• リリース時に経営層のレビューをするから「成果に結びつく機能は何か」という優先度判定になる
• 他の部門や経営層から確実なフィードバックが得られる

この3ヶ月間はプロセスは手続き的に進んでいくのでウォーターフォール風な側面も持ちます。中間成果物もドキュメントだったりするので動くソフトウェアというわけではありません。ただ、3ヶ月間の日程とリソースが先に決まっています。なので、僕としては3ヶ月イテレーションという言い方が適切に感じています。

プロダクトオーナー

こうした案件ではプロダクトオーナー、つまり、他部門にまたがる要件を取りまとめ優先順位付けをする役割が非常に重要です。

一般的な定義のプロダクトオーナーはシステムの受益者であるユーザーと開発チームの仲立ちであり、その両者にアプローチすることが求められます。
しかし、日本のエンタープライズでは特に

• 会社組織の意思決定プロセスの促進
• 社内の現場部門との調整

といったことが強く求められます。

つまり、日本企業では「POとしての判断」というのがPO個人ではなく「組織的に行われるもの」であり、POはその判断を促進するファシリテーターのような機能が必要になります。つまりPOには強力な組織内調整能力が求められるのです。

ところが「ビジネスも理解し、開発の言うことも分かり、経営層にもパスを持ち、現場に対する交渉力も持つ」なんていうスーパーPOはなかなかいません。
なので、実体としては「リードPO」のような人がいて、あとはそれぞれの役割を数名の人が集まって実現する形になることが多いように思います。

リードPOにもっとも必要なのは「想い」です。このプロダクトをこうしたい、これが会社として目指すべきものだ、という熱い想い。それがあると周りが協力してPOとして機能します。例えば上司が経営層とのパスを調整してくれたり、別部署の同期が相談に乗りながら調整方法を考えくれたりといったことです。
こうした活動をする中で成果と機能のバランスや、社内で何が求められているのかを理解していくことで成長していくことができるわけです。

ちなみに「そういう日本企業の組織的判断ってやつが無駄なんだ」というのは、半分は理解しつつも、それを言い訳にしてアジャイルを諦めたくはありません。そういう企業こそ、僕らの生活には欠かせないわけで、少しずつでも改善してもらわないと困るのです。

アーキテクチャ

最後はアーキテクチャです。健全にプロセスが機能するためには、それを保証するアーキテクチャが必要です。簡単に言うと他の機能から独立してリリースできる、ということです。
情報分析系システムなどはデータの終着点なので、そもそも他システムに対して疎結合になります。しかし、オンラインシステムでは簡単にいかない場合もあります。

弊社の事例では、そういった際にアプリ分割を行なって既存機能との疎結合化を図りました。社内では心臓外科手術なんて言ってましたが、モノリシックなシステムの一部を切り取り、まっさらな別のモジュールにした上で認証機構は共有できるようにしましたです。術後に小さな障害はあったものの経過は順調で、想定通り、その部分だけは独自にリリースが可能になりました。

技術的な側面としてはCI/CDや自動テストなども段階的に導入されています。ただ、それは導入が目的というよりも、リリースを頻繁にする際にデプロイ手順の自動化や面倒で複雑なテストケースの自動化をやってないと「やってられん」というチーム内の素直な動機です。方法論さえ事前に理解しているなら「困ってから対応する」というほうがチームの導入モチベーションも上がるので悪くないことだ思っています。

なお、これがマイクロサービスアーキテクチャに繋がっているのは言うまでもないでしょう。アジャイルといっても、個別の機能によって適切なリリースサイクルは異なります。よって機能感を疎結合にし、それぞれが独自のサイクルでリリースを可能にすることはとても大切なのです。

まとめ

エンタープライズアジャイルが何であるかはよく分かりません。ただ、僕としてはアジャイルの原則に従い、顧客と対話しながら、適切なフィードバックが得られるようにしているだけです。その結果が以下のようなことです。

• フィードバックは3ヶ月定期リリースにするこで経営層や現場から得られるようにする
• プロダクトオーナーは顧客や開発だけでなく、経営層や現場ともやり取りをして判断を促進する
• アーキテクチャは適切にプロセスが回るように疎結合を実現する

こう書くと当たり前のことですよね。でも、それでいいんだと思います。

僕はどの案件でも「アジャイルを導入しましょう」と言ったことはありません。むしろ、言いたくない。

案件の背景と顧客の要望に応えるための手法がアジャイルであるかはどうでもいい。ただ、結果的にアジャイルな要素を含んでいる、というだけです。手法は道具です。それぞれの現場に必要な道具を適用して、当たり前なことをひとつひとつ積み重ねていくのが大事だと思っています。

資料は以下から。

アーキテクチャ設計のジレンマと拡張構造としてのマイクロサービスアーキテクチャ

2016年10月24日のQCon Tokyo 2016にて「今どきのアーキテクチャ設計戦略」という講演をさせていただきました。

アーキテクチャ設計のジレンマ

伝統的に、アーキテクチャ設計というのは設計や実装に先立って事前的に行われる必要がある、とされています。設計や実装は定義されたアーキテクチャを参照しながら進めなくてはならないからです。なので、アーキテクチャ設計にあたっては「システムの振る舞いに対する要求」という「話」を理解して進めていくことになります。そのため、その要求が正確であればあるほど適切な構造を定義できることになります。これは当たり前のことですね。

一方で、現在的なシステム開発というのはアジャイルに代表される「フィードバックと改善によって段階的に機能を拡張する」という前提にあります。これも当たり前のことで「誰も事前に正しい要求を定義できるわけがない」から「動くソフトウェアを見てフィードバックをすることで正しい要求に近づいていく」のです。

というわけで、ここに「アーキテクチャ設計のジレンマ」が生じます。

• 構造を決めるには正しい要求が必要
• 正しい要求は「フィードバックと改善」で導かれる
• そのためには動くソフトウェアが必要
• 動くソフトウェアを作るためには構造が必要

このジレンマは長らく「アジャイルとアーキテクチャの対立」として表現されてきたものです。ところが、ここに来てようやくマイクロサービスアーキテクチャが、この対立構造を解消しつつあります。

拡張構造の採用

アーキテクチャ設計のジレンマというのは避けられないものなので、アーキテクト側としては何らかの設計戦略によって、これを回避することを考えます。

1つ目のアプローチは予測型アーキテクチャ設計です。将来に発生する機能拡張を予測し、それをも含んだ最適なアーキテクチャを設計すればよい、と考えるわけです。しかし、この予測型こそがアジャイルが最も嫌うアプローチであり、実際には破たんすることになります。良くあるのは予測増改築型アーキテクチャ設計（別名：温泉旅館型）への進化であり、悲しくも不思議な館を作ったり、増築した経験がある人も多いでしょう。

そこで2つ目のアプローチとして言われているのが犠牲型アーキテクチャ設計です。これは現時点で分かっている機能に対して必要十分なアーキテクチャ設計を行い、それで耐えられるまでやって、ダメになったら作り変えればいい、という考え方です。XPのYGNIの法則（You ain't gonna need it/機能は実際に必要となるまでは追加しないのがよい）といってもよいでしょう。このアプローチは非常に有効ですが、アーキテクチャの改変には大きなコスト（お金的にも時間的にも）が発生するというデメリットがあります。よって、「技術的負債」という言い方をして、段階的に負債を返しながら再構築にならないアプローチを取ります。

そんな中で常に求められるのが拡張構造型アーキテクチャ設計です。これは現時点でわかっている機能に対して最適な構造を用意しつつ、将来に必要なった機能について段階的に構造を拡張できる、といういいとこどりのアプローチです。

※拡張構造における基本構造はプラットフォームと称されることが多い

ところが、拡張構造型には大きな問題があります。それは「※天才に限る」ということです。というわけで、私のような凡人アーキテクトはコミュニティの英知であるところのオープンソースを採用したり、クラウドサービスを利用することになります。

拡張構造としてのMSA

この拡張可能な構造にするための努力について、現時点での集大成がマイクロサービスアーキテクチャだと思っています。ただ。拡張性を確保するために相当に複雑な構造になっています。

資料内に構造として色々とあげたものをリストとして記載しておきます。もうすこし詳しい内容は後段の資料を確認してみてください。ただ、あっさりしか書いていないので個別のテーマは検索してください。1つ1つのテーマで講演ができちゃうぐらい深いです。

• 疎結合を維持する戦略
  • データ分離：共有データ、ビュー、トリガー/ストアド、ETL、イベントソーシング
  • テスト戦略：Test Doubles、Dark Canaries、Consumer-Driven Contract testing
  • 不整合の許容：Amazonのクーポン
• リジリエンスを確保する戦略
  • サービスの集中管理：設定の集中管理、知的なルーター、非同期メッセージング
  • 階層型障害への対応：サーキットブレーカー、分散トレース、障害注入テスト
• ツール群
  • CI/CDツール群：チケット管理、ソースコード管理、CI/CDツール、ドキュメント管理、チャットツール
  • インフラツール群：インフラ構成管理、コンテナ
  • 分析ツール群：メトリクスツール

MSAの採用に向けて

とはいえ、「プラットフォームとして拡張構造型のマイクロサービスアーキテクチャを採用しよう」といってもなかなか簡単なことではありません。マイクロサービスの拡張構造を習熟し、チームが機能するようになるのは長い時間がかかります。

マイクロサービスのアーキテクチャは設計コンセプトから実際のフレームワーク、さらにツール群などを含めて相当複雑な構成になっています。これはアジャイルから始める長い歴史の積み上げがあるわけです。このストーリーはCloud First Architecture設計ガイドに書いていますし、デブサミ関西でも「アジャイルから現在までの15年間の歴史で自分がどこにいるかは意識すべき」（参照：デブサミ関西2016「クラウドの発展とデベロッパーの役割について」）という話をしました。

僕は「マイクロサービスで全体一括再構築はうまくいかない」と思っています。なので、僕が考えるアプローチは「マイクロサービスアーキテクチャには明日からでも取り組もう」です。

マイクロサービスというと、どうしても「マイクロ」が気になることですが、その本質は「サービス同士を疎結合にして個別変更を許容する」ということです。だから、サービスの大きさや、そのサービスの変更リズムというのはドメインに合わせていけばいいと思います。たとえば10人ぐらいのチームで抱えるような規模で、大きなリリースは数か月おき、とかでもよいと思います。

ともかく、今の仕組みを大きく変えるのではなく、段階的に導入していかなくてはなりません。できることから取り入れていけばいい。実際、多くのウェブサービス企業でも、そういった段階的な取り組みをしています。

ただ、内製化の進んでいないエンタープライズ分野では、こうした考え方は非常に厳しいものがあることも分かります。情シスの担当者もベンダーの担当者も、どうしても一括再構築という選択肢しか取れないのです。弊社はSIerではあるものの、顧客との協業関係を築きながら段階的な拡張に対してビジネス的にも矛盾せずに対応できるようになっていますが、これはレアケースでしょう（←ステマ）。

せっかく拡張構造の集大成としてマイクロサービスアーキテクチャというものが定義され、かつ、オープンソースやクラウドサービスとして整備もされつつある状況です。なので、アーキテクトがすべきなのは、それを学んで自分のドメインへの適用方法やタイミングを考えるだけです。ただ、その「だけ」ですら、なかなかできていないのが現状でしょう。

日本のエンジニア（特にエンタープライズの）がアーキテクチャ設計のジレンマを乗り越えるべく、主体的に取り組んでくれることを心から願っています。

講演資料

Cloud First Architecture 設計ガイド

デブサミ関西2016「クラウドの発展とデベロッパーの役割について」

JavaOneに来ていますが、満席で入れなかったのでデブサミ関西2016の話を。

「デブサミへの帰還。」というエモいエントリが上がっていますが、たしかにデブサミ育ちとしては、デブサミに呼んでもらえる、それも基調講演というのは非常にありがたい話です。そのあたりの経緯と雑感を。資料はこちら。

基調講演という形式ですが、本家の東京デブサミは基調講演というぶち抜き枠を置きません。広い会場で全員に同じ話を聞かせるというのはイベント全体を総括する内容でなくてはなりません。一方で多様なエンジニアのお祭りであるデブサミでは、総括も難しく、基調講演という形式が合わないということだと思っています（勝手に）。だから「デブサミの基調講演」というのは、かなりレア枠なのです。

そんな中、デブサミ関西2016のテーマは「変化」ということで「技術が成熟していくなかでエンジニアの役割が変わっていっているのではないか。改めて、これからのエンジニアにとって大事なことを考えたい」というものです（全文は開催概要を）。基調講演ですから、これを総括する話をしないといけません。

そこで、偶然にもCloud First Architecture 設計ガイドを刊行しようとしていたので、書籍の内容のサマリ＋αということで話をさせてもらいました。出版社が違うのに、快く受け入れていただきありがとうございます。

タイミングとしては、本が先だったわけでもなく、講演依頼が先だったわけでもなく「あ、ちょうど、それ書いてたんです」というタイミングだったのは素直にうれしいです。この本がタイムリーであったということですよね。

「変化」を語るうえで重要なのは経緯の理解です。変化というのは、ある時点とある時点の比較によって成り立ちます。よって、今起きていることを理解するには、歴史を遡って過去との比較をすることが必要です。そして、その比較を深く理解するには、その時点間の経緯をストーリーとして語る必要があります。

この本は2001年のアジャイルソフトウェア開発宣言以降の技術やブームの流れを追ったものです。会場で話した中で一番イジワルな質問は、このページでしょう。

「あなたは、この年表のどこにいますか？」

先に言っておくと僕自身も2014年時点にいるわけではありません。なので、体験的にマイクロサービスアーキテクチャ（MSA）を語れません。でも、仮にやるべき時がくれば、何をすればいいかは分かっているつもりです。

MSAはアジャイルから10年以上経って広まりました。この10年間には意味があります。クラウドが生まれ、DevOpsが生まれ、様々な試行錯誤の上でMSAというものにたどり着きました。

仮にMSAに取り組むのならば、10年という時間が生んだ巨人の肩に乗らなくてはなりません。そのときに大事なのは巨人の姿をちゃんと理解しておかないとうまく肩に乗れない、ということです。

僕が言いたいのは「MSAはすごい」ではなく「よりよいITを求めた試行錯誤において現時点ではMSAという形になっている」ということです。MSAは「よりよりITを求める過程における1つの結果」に過ぎません。MSAは目的ではなく手段です。MSAにしたらよくなる、ではなく、よいものを追い求めたらMSAになったのです。

そして、よりよいITを求めるには、まだまだやるべきことがたくさんあります。そこに多くのエンジニアが取り組んでくれたらと思います。エンジニアが活躍できる場がすごく拡がっているのですから。

ところで、本にも少しづつ本の反応をいただけてます。一番多いのが「興味を持って深堀したいときに参考図書の紹介が少なすぎる」というもので、これは、そのうち対応したいと思います。

エンタープライズにおけるマイクロサービスアーキテクチャについて

エンタープライズ業界でもマイクロサービスアーキテクチャの議論が盛り上がりはじめてて、それは良いのですが、やはり本質的ではない技術論にばかり夢中になっている気がしています。

エンタープライズシステムの現状

モノリシックな巨大システムでは一部分の改修であっても、システム全体対する影響調査やリグレッションテストによる工数増加が発生し、共通機能をいじるとなれば関連機能も含めた改修が発生するなど、スピード感は落ちる一方です。
つまり、従来型のコンポーネント集約のような手法で巨大システムを作ると、開発効率が上がったとしても、保守における変化効率が極端に下げることが分かっているわけです。

一方で、旧来から部門別で構築されてきた中小規模システム達は、いつのまにやら複雑に連携しあっており、相互に影響を与える中では、個別システムの都合だけでリリーススケジュールを決めることが困難になってます。
特に場当たり的に作って乱立してきた顧客フロント側サービスは、バラバラで不便すぎるのに、微妙な担当部門の業務都合によって統合が困難になってます。
そのうえ力のある部門が「うちの部門ではシステム化が競合他社より遅れてる」とか言おうものなら、さらに場当たり的な新規システムを構築することになります。
そういうシステムはSaaSやパッケージだから既存システムとの連携が難しくて「とりあえず手動」で始めた業務が定期バッチになり、そこを担当する事務部門は人件費が下がりません。

そんな乱立は裏方である顧客サポート部門も不幸にします。顧客のシステム横断ビューどころか、シングルサインオンもままならず、問い合わせ対応には数個のシステムと膨大な暗黙知をもって対応し続けている。ミスが起きればクレームになり、そこの品質を上げようにもコストセンターにシステム投資はまかりならんし、だいたいシステム構築経験者が少なすぎて提案すらできない。

さらに今や偉くなった役員から「弊社のシステムは分散していて使いにくいという声が上がってる。全体最適化の視点がない！」とかしたり顔で言われても「おめーが担当の時にゴリ押しで導入したからだろうが」とは言えずに統合連携基盤なる検討を始めるしかないわけです。
ところが、いざSOAだと連携基盤を持ち込んでも、えらい複雑なワークフローを組んで破綻するか、データフォーマットを標準化したら最小公倍数状態で各システム側で変換ロジックをゴリゴリと書くことになり「なにが楽になったの？てか、障害が起きてもどこが原因か分かりにくすぎて対応コストが上がったよ」と現場は大ブーイングになります。

まぁ、システム部門も「それぞれの担当システムが平穏無事であればよい」という姿勢なのが問題なわけです。分かる、分かりますよ、新規システム構築に際して既存システム側の改修見積りしたら、そっちのコストのほうが高くなっちゃって文句を言われ、工夫を凝らして既存流用したら、逆に保守性が下がっちゃったりするわけです。なんで他シスのせいで怒られなきゃいかんのかと。

じゃあ、システム部門主導で全体最適だと。よかろう標準化だと。具体的には標準フレームワークや標準データモデルだと。それらに意味がないまでは言わないまでも、ユーザーが多様化し、ビジネスニーズも多様化する中で果たして標準的な技術やデータで何ができるのでしょうか。フロントシステムとバックエンドのシステムは非機能特性が違うので、同じ技術は適しません。ツーシーターのスポーツカーと業務用のバンが同じ構造でいいのかってことですよ。

そんなわけで目の前には山頂が雲に隠れ、裾野も霧の向こうという巨大基幹システムと、周辺には複雑な地下水脈でつながり合う部門システムがまとわりついており、次の再構築ってどうするのよと、業務が止まるような再構築できないよ、という状況なわけです。

安心してください。みんな悩んでますから。たいていの企業で多かれ少なかれ似たようなことが起きています。

昔は1つのシステムをどうするのか考えれば良かったのです。ところが、お互いがシステム連携を始めてしまい、それが重要になってくると、個別システムを効率的に開発・管理する視点よりも、企業システム全体を効率的に開発・管理する視点が大事になってきています。でも、そういう全体視点でシステム配置を最適化するための考え方で良さそうなものがなかった。

MSAはシステム全体視点の戦略

そこでMSAですよ、というのが話の流れ。

例えばAmazonだって社歴は20年を超え、その巨大な売上を支えるシステムは当然そこらの大規模システムと引けを取らない。そういう彼らが言うMSAというのは、オンラインサービスを主軸にしながらもバックエンドの物流や会計までもが緩やかに繋がる「企業システム」なわけです。それらをどう管理したらいいんだろう、かつ、フロントシステムの改修速度は落としたくない。その答えがMSAだったわけです。

MSAのメリットは「巨大なシステム（群）をチームで見れる程度のサービスに分割していくことで、それらのサービスごとに個別ライフサイクルを実現し、システム全体としての変化スピードを上げる」ということです。
サービス同士が疎結合である、つまり、機能改修の変更が他のサービスに及ばない、かつ、リリースに伴う停止や切替が他サービスから隠蔽されるということが出来ていれば、個別のサービスは、そのサービスに求められる変化スピードを実現することができます。早ければいいって話ではないです。そのシステムに求められるスピードが他者に干渉されないことが大事。
そのための技術としてクラウドによる仮想化やDevOpsによる自動化というのは大きな役割を果たします。

エンタープライズにおけるMSAというのは、技術論の前に、全体システムをいかに最適化するのか、という概念として考えればよいと思います。単体システムや単体アプリの視点ではなく、企業内部の全システムを見る視点。「木」をどうこうではなく、「森」をどう管理するか。
木は、その木に思い入れのあるチームに任せたほうが良い。大事に育ててくれよと。ただ、森の土壌や治水といった、森全体を健全に管理するのは、また別な視点で別な人が責任を持って取り組まないといけない。
エンタープライズでMSAに取り組むなら、こういうことを考えてもらいたいなと思うのです。

「MSAに再構築する」のはNG

では、MSAにどうやって取組みべきでしょうか？
僕個人としては「巨大なシステムを分割しながら段階的にMSAに移行していく」という取組みそのものがMSA的な姿勢であると思います。「MSAなシステムを作るために大規模再構築をする（リリースは3年後）」というのはMSA的ではありません。
来週、来月にでも最初の一歩は踏み出せるはずです。巨大なシステムに対して、部分的にでも、ほんの少しでもアジャイルやクラウドや自動化や、なんらかモダンな技術を導入していく。そして時間を掛けて全体システムを最適化していく。その営みがMSA的なのです。

アジャイルが、具体的にはプロセス論（do Agile）であるながらも、その本質が「アジャイルにするという姿勢（be Agile）」であるように、MSAも、具体的には個別の技術論（do MSA）ではありますが、その本質は「MSAにしていくという姿勢（be MSA）」であると思っています。

宣伝1.僕の部署では、こういうお悩み解決のために全体システムの分析やら再構築の方針策定やらの手伝いもしてますよ。ご興味がある方は連絡ください → グロースエクスパートナーズ株式会社

宣伝2.もう少し詳しくMSAに至る流れを知りたい、という方は以下の本を。2016/8/25発売です！

Cloud First Architecture 設計ガイド

ウィトルーウィウス 建築書

ウィトルーウィウス建築書 (東海選書)は建築家ウィトルーウィウスによって紀元前30年頃に書かれた書籍で、最も古い建築書として知られてます。松岡正剛による書評（778夜『建築書』ウィトルーウィウス|松岡正剛の千夜千冊）が素晴らしいので加えることもないのですが、とはいえ、僕自身の備忘としてブログにしておきます。

この本は「建築書」といっても家の建て方だけが書いてあるわけではありません。城壁の作り方、都市の配置と方向、神殿における柱と配置と形、劇場の形と音の響き、都市と田舎の個人邸の違い、土地が持つ地質や水質の見分け方と飲み水の確保方法、さらには各惑星の動きと星座の見方、日時計の作り方、そして、荷揚げや石材運搬の器械、水車やポンプの器械、あるいは、軽弩砲や重弩砲といったものの説明が書かれています。

大変興味深いことは、それぞれについて単なる実践のための手順書ではなく、歴史の中で蓄積された理論がしめされ、さらに、実践と理論が結びつくことの重要性が書かれていることです。

星学者と音楽家の間に四角形と三角形における星の協和と四度および五度の音の協和に関して共通の論議があり、また幾何学者にギリシア語でロゴス-オプティコスと呼ばれる視覚に関する議論がある。その他あらゆる学問においても多くのこと、むしろ総てのこと、が議論の対象として正に共通である。ところが、手とその操作によって完全なものに仕上げられる作品に手を付けることは特別に一つの技術において制作へと教育された人々のやることである。

「理論は多くの学問において共通」ではあるものの、「実践として作り上げることには専門の教育が必要」であるのです。

しかし、その理論というのも実践の積み重ねの中から形作られてきました。

「（その昔）人類は野獣のように一生を送っていた」「（火を発見すると）人間の集まりでは、偶然に単語が定まり、習慣の中でお互いの間に会話が生まれた」「一つの場所に集まるようになると、ある者は屋根を葺きはじめ、ある者は洞窟を掘りはじめ、日々改良された形式の家を造り上げた」「人間は本性において模倣的である学習的であるから、競争によって技能を鍛錬した」「今日でも他の国々ではその通りの状態で家が建てられている」「（これを証拠として）古代の建築法の発明についてこれがそのやり方であると判断する」

その上で、

「家造りに対する腕がいよいよ熟達し、職人を名乗ってもよいほどになった」「それからまた、彼らは己の知力をみがき、技術の多様性から生まれた広い考え方で前途を望み、次いで研究を尊重してシュムメトリアの理論にまで到達した」

シュムメトリアは「シンメトリー」の語源ですが、単なる「対称性」という意味にはとどまりません。

シュムメトリアとは、建築の肢体そのものより生ずる具合よき一致であり、個々の部分から全体の姿にいたるまでが一定の部分に照応することである。

部分を単位として全体が割り切れる、あるいは比例するといったことであり、建築を成り立たせる一つの要素として考えられています。

もちろん、理論は単に完成された姿だけに限る物ではありません。

建物を造り上げるに適する材料について、それらがどんな自然法則でつくられていると考えるのか、元素の集合はどんな混合割合いで適切に調合されているか、を読者に曖昧でなく明瞭であるように論述しよう。実に、材料のどんな種類も、人体も物質でも、元素の集合なくては生ずることも知覚されることもできず、またこれらの物に内在する因がどのいうふうにまたどうしてこうであるかを細密な理論によって証明するのでなければ、自然界は自然学者の教えによる真の説明をうることができない。

時は古代ローマがローマ帝国となる頃、ローマ支配下の各地を回りながら、多数の都市国家をまとめていったのは、建物に限らない圧倒的な「もの作りの強さ」であり、その裏側には大量の理論があったということを想像させます。

そして、建築家自身にもこれを継承し、発展させるための「理論」と「実践」についての高い能力を要求しました。

建築家の知識は多くの学問と種々の教養によって具備され、この知識の判断によって他の技術によって造られた作品もすべて吟味される。それは制作と理論から成立つ。制作とは絶えず錬磨して実技を考究することであり、それは造形の意図に適うあらゆる材料を用いて手によって達成される。一方、理論とは巧みにつくられた作品を比例の理によって証明し説明しうるものである。

特に次の文章はもの作りの総てを説明した文章と言えます。

実に、すべてのものには、特に建築には、この二つすなわち「意味が与えられるもの」と「意味が与えるもの」が含まれている。意味が与えるものとは、それについて語られるよう提示されている事物をいい、意味を与えるものとは、学問の理に従って展開された解明をいう。

僕なりの解釈はこうです。あらゆる「もの」というのは、そのものが「何かとして機能する」ことによって、その何かの機能を意味する言葉が割り当てられます。「人とが住まうことができるもの」は「家」と呼ばれます。

一方で「何かの機能を果たしうる」ものを適切に造るには、その機能を定義し、そのものとして構成するための理論が必要となります。「家」というのは屋根や壁や入り口があり、さらには目的に応じた部屋割りが必要であり、そこには部材の強度や部屋の広さについての論理があります。

実践を積み重ねて「有用なものを造る」ことは確かに重要です。ですが、それは「『それ』ができた」というだけに過ぎません。そこからそれを磨き上げ、作り上げる能力を鍛錬し、その経験を理論として体系化する。そして、その理論を意識的に適用することによって、改めて『もの』を適切に作れるようになったと言えるのです。

もの作りというと実践的な知識ばかりが重視されがちです。もちろん、実践は重要です。しかし、時には理論を学び、その起源を知ることによって、より深く実践と向き合うことができるようになります。そして、実践を突き詰める中で生まれてきたものに名を付け、理論としてまとめることで、世の中の発展に寄与することができるようになると思うのです。

僕自身、まだまだ学ぶことも、やるべきこともたくさんあるのだなと、そして、少なくとも僕が学んだことは次の世代に伝えていかなくてはいけないなと感じた次第です。

ウィトルーウィウス建築書 (東海選書)

Cloud First Architecture設計ガイドが発売（8/25）されます #cfadg

本を書きました。2016/8/25に発売されます。ハッシュタグは #cfadg (Cloud First Architecture Design Guide)でお願いします。

Cloud First Architecture 設計ガイド

「Cloud First Architecture設計ガイド」ですから、クラウドファーストなアーキテクチャをどうやって設計するのか？という本です。とはいえ、（僕らしく）回りくどい道のりでクラウドファーストについて解説しています。

クラウドファーストは「クラウド技術群を前提にシステムを構築する」ということですが、これを体現したのがマイクロサービスアーキテクチャでしょう。しかし、マイクロサービスアーキテクチャは技術論ではありません。
マイクロサービスアーキテクチャはムーブメントであり、テクノロジーであり、マネジメントであるという多面的な姿を持っています。「サービス同士を連携させる」といった一言では済ませられないのです。

おそらく多くのITサービスが、マイクロサービスアーキテクチャという巨人の肩に乗るはずです。様々なクラウドサービスを利用すること、様々な企業が公開しているオープンソースソフトウェアを利用すること、様々なメソッドやプロセスを実践すること。

しかし、この巨人がいかに立ち上がったのかという物語を知らないと、巨人の膝小僧やくるぶしを肩と誤認しかねません。よって、マイクロサービスアーキテクチャに至るまで、どういった背景と経緯があったのかを知ることで、巨人の大きさや姿を明確に理解することができると考えました。

本書は6章でなりたっていますが、1章から3章までは「マイクロサービスアーキテクチャへの道のりを解説すること」にあてられています。アジャイルを源流にDevOpsというムーブメントが生まれ、仮想化やクラウドをうまく利用しながらマイクロサービスアーキテクチャというものが形作られてきた15年間です。

続く4章では、こうしたクラウドファーストというものとエンタープライズシステム開発の関わりについて整理しています。象徴的なアジャイルとウォーターフォール、ITILとDevOps、マイクロサービスアーキテクチャーとSOAの比較をしています。また、エンタープライズでクラウドファーストを導入する際の阻害要因について考えています。

第5章は現代的なアーキテクチャ設計の進め方について僕なりの考え方を整理しました。
アーキテクチャ設計というのは事前的な作業であり、そこ構造を定めることで実装が始まります。旧来のアーキテクチャ設計というのは、ソフトウェア開発の初期段階でソフトウェアに対する要求を的確に理解し、それに基づいて最適な構造を導く、とされてきました。しかし、現在のソフトウェアでは全ての要求を最初に描くことはできません。むしろ、作りながら要求を導くことが正しいとされています。
よって、クラウドファーストなアーキテクチャー設計では「要求が定まらなければ構造が決まらない」「要求を定めるためには作らなければならない」「作るためには構造が決まっていないといけない」というジレンマに陥ります。このジレンマを受け入れ、いかにアーキテクチャ設計を戦略的に進めるのかが重要です。

最後の第6章では、こうした現状においてエンジニアがどういったスキルを身につけるべきかを考えてみました。マイクロサービスアーキテクチャを支える技術は、テクノロジーだけでもクライアント、サーバー、インフラと多方面に拡がります。CI/CDといった要素も重要です、一方で、UXやリーンといった手法や、当然、アジャイルようなプロセス論も必要です。こうした多方面に拡がっている要素を全て理解することは不可能です。では、自分自身がどういった方向性でサバイブしていくべきなのでしょうか？もちろん、僕自身も答えを見つけられてはいないのですが、その方向性だけでも共有したいと思っています。

5章を除く部分についてのサマリは福井のイベントで講演した資料をご覧ください。

出版される前から弱気なのは、もうこの瞬間にも本の一部が時代遅れになっているだろうということです。その筋の専門家が読めば「ださっ」と言われかねないだろうとも思っています。ただ、そういった最新技術をピックアップすることよりも、これまでの道のりを整理することが必要だと感じた次第です。

この本が皆さんにとって少しでも助力になれば幸いです。少ししたらイベントも企画します。