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

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

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

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

一方で、旧来から部門別で構築されてきた中小規模システム達は、いつのまにやら複雑に連携しあっており、相互に影響を与える中では、個別システムの都合だけでリリーススケジュールを決めることが困難になってます。
特に場当たり的に作って乱立してきた顧客フロント側サービスは、バラバラで不便すぎるのに、微妙な担当部門の業務都合によって統合が困難になってます。
そのうえ力のある部門が「うちの部門ではシステム化が競合他社より遅れてる」とか言おうものなら、さらに場当たり的な新規システムを構築することになります。
そういうシステムは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章を除く部分についてのサマリは福井のイベントで講演した資料をご覧ください。

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

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

ウォーターフォールとアジャイルを考える

初めて単独主催の勉強会をしました。ワークショップなので後半の1時間はディスカッションにしたのですが40人のわりには、それなりに面白い話ができた気がしています。資料とワークの結果、あとTogetterは以下から。

togetter.com

今回のプレゼンは純粋な「プロジェクトマネジメント論としてのウォーターフォールとアジャイルの違い」に絞った話をしたので、後半のワークが現実的な話になって面白かったです。話をしたのは以下のようなことです（資料の後半に細かいメモ書きがあります）。

• そもそもウォータフォールは必要なのか？
• とはいえ、ウォータフォールを採用しなくてはならない状況は？
• なぜ、アジャイルを採用できないのか？
• チームは重要だけど、どういうメンバーがいいのか？
• アジャイルとはいえPM的な人が必要になることってあるよね？
• アジャイルの立ち上げってどうするのがいいの？

偶然、牛尾さんの 私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログ とタイミングがあったので、この話もできてよかったです。で、この勉強会をした上で、記事へのコメントをしたいと思います。

まず、「ウォーターフォールは何のメリットも無い」は嘘です。何のメリットもないものが存在するわけないので。よって「現在のシステム開発においてウォーターフォールを採用するメリットはあるのか？」という問いだと思います。これは正しい問いかけです。

単純な議論としては「スコープが確定しているならウォーターフォールでいい」となりますが、ワークの中で「スコープを可能な限り確定するというのはプロジェクトマネジメントの基本だ」という意見はその通りだなと思いました。アジャイルでも可能な限り予測して確定することは大事ですね。ですので、確定できるだけは確定したうえで、プロジェクト進行中のリスクや変化をどの程度見込むのかに合わせてマネジメントスタイルを選択する、というのが基本的な考え方なのでしょう。

（そもそも、きちんと事前確定と変化が読めるチームであれば、何をしてもうまくいくだろうという身も蓋もない話もあるんですけど、それは置いておいて）

僕は現在のシステム開発においては「アジャイルをベースに、どこまでフェーズ切りやプロジェクトマネージャーという役割を導入すべきか」というような考え方が現実的だと思っています。

資料に書きましたが、僕はウォーターフォールとアジャイルの大きな違いは以下の2点だと思っています。

• チーム：PMという個人が中心、ではなく顧客も含めたチームでマネジメントを行う
• 定期的判断：フェーズが終わるまでやる、ではなく定期的に判断をする

 で、この2つが重要ではないプロジェクトはありません。その理由は明確です。

• これだけビジネスも技術も複雑化している中で全てを理解できる個人なんて存在しない。どうやってもビジネス側と開発側がチームとして力を合わせる必要がある
• もはや「顧客からの依頼でシステムを作るのが仕事」のではなく「顧客と一緒にITを使ってビジネスをするのが仕事」という時代なので「システムができるまで待ってくれ」ではなく「出来る限りビジネスをするにはどうするか」を考える必要があり、そのために定期的に時間で区切って判断するのは大事

1つ目については、あまり議論の余地はないと思います。ただ、これは「プロジェクトマネージャー（という役割）が不要」ということではないです。チームを活かすためにはファシリテーターやコーチやメンターやお世話係や叱ってくれる人が絶対に必要です。それをPOがやるのか、スクラムマスターがやるのか、あるいはPMがやるのかは「ロール名」の問題であって、誰でもいいです。ただ、どんなチームにも、そういう人が必要です。逆に「PMだから○○をやる」「POだから○○をやる」で思考停止するほうが問題です。

2つ目は難しい問題です。日本においては「SIerという外部企業に依頼する」や「稟議決裁というすり合わせ型の判断プロセス」が制約条件となります。ただ、これは「制約」であって「制限」ではありません。顧客と開発者の間に信頼感が醸成されれば「なんとかルールの範囲でやる」ということになります（経験的に）。

なので、最大の課題は「顧客と開発者の間に信頼感が醸成できるのか？」でしょう。これはお互いの努力が必要だと思います。顧客はITのことを学び、開発者は顧客のことを学ばないといけない。ITがこれだけ重要な世の中ですから、これができるようになった企業から成長の波に乗っていけば自然に淘汰が進むはずです（というか、進んでくれないと困ります）。

よって、ウォーターフォールかアジャイルかという議論は、マネジメント論としては「計画駆動か変化駆動かで使い分ければいい」というだけですし、ビジネスにおけるIT活用という側面であれば「アジャイル的な考え方（チームと定期的な判断）って重要」ということになるのでしょう。

僕個人は日本的な稟議決裁という事前すり合わせシステムがあるからビジネスが円滑に進む面もあると思っています。それはそれで日本の意思決定判断の良さ。もともとチーム主義って日本の得意技なはずなのですから（それが行き過ぎるとよくない、というのはありつつ）

今回、ウォーターフォールかアジャイルかという議論をしてみて「マネジメント論としては偏見を持たずウォーターフォールもアジャイルも勉強すべき」ということと「結局、マネジメントの本質は人だよね（方法論は適切なものを選べばいい）」ということに立ち返りました。

ワークショップは次を企画したいと思います。「このネタがいい！」というのがあればTwitterで教えてくださいませ。→ 鈴木雄介/Yusuke SUZUKI (@yusuke_arclamp) | Twitter

JJUG CCC 2016 Springで基調講演してきた

JJUG CCC 2016 Springで「JJUG運営の戦略と戦術」という内容で基調講演をしてきました。資料はこちら。

資料の訂正としては6ページ目にある参加者が「700名予定（申込：1,233名＋α）」は「810名（申込：1,267名）」で確定しました。昨年は670名ぐらいで安定していたので100名以上増えて最高記録を更新しました。なお、年代と参加回数の分布は実際の参加者を母数にしてもほぼ同じ割合いでした。

世の中に「標準的なコミュニティ」なんてないので、あくまでもJJUGの話として見てください。櫻庭さんが副会長を退任されて幹事会を離れるということもあったので、この2年間で櫻庭さんが果たした役割を紹介したかったのですが、ちょっと写真が怖すぎましたかね...。なにか間違ったことが伝わっていないか心配です。

（【追記】を参照ください。ご本人からは公認いただきました！）

JJUGの成長はひとえにコンテンツを作ってくれる皆さんやイベント運営をやり続けてくれるスタッフの頑張りのおかげです。僕はその成長を受け入れられる場所や、そのために「良いお金」を集めていることぐらいしかできません。日常的にはほとんどJavaを書いていない人が会長をやっている意味みたいなものに僕なりの答えを出せているのかな、と思います。裏番組を作った結果、聞いていただいた方は少なかったのですが、個人的には書いてて面白い資料でした。

今回はCCCに向けて改善をたくさんしました。個人的には休憩時間の増加やブースでのコーヒー配布とブースセションが良かったです。コーヒーは60リットルぐらい作ったそうですよ。あと20分枠でスピーカーデビューしてくれた人もいたのもうれしかった。
一方で運営の効率化というのは本当に重要な課題になってきています。「外部委託するとJJUGらしさが無くなるのでは？」という話もあったのですが、当日の運営ではなくて、事前にサイトを作ったりコーヒーメーカーやインカムの手配などの準備負担を減らせればと思っています。

とにもかくにも参加者、スピーカー、スタッフ、スポンサーの皆様お疲れ様でした！僕も楽しかったです！！また、秋に会いましょう。

【追記】

@yusuke_arclamp まぁ、確かにそういうこと言ってたからしかたない ^ ^;; まさかりは持ってなかったけどww

— Yuichi Sakuraba (@skrb) 2016年5月22日

マイクロソフトのネット配信に出てみた件

マイクロソフトの寺田さんと牛尾さんにお呼ばれして、Azure Minutesというネット配信番組に出演してきました。光栄なことに第1回ゲストです。

日本 Java ユーザーグループの会長を務め、IT アーキテクトとして著名な鈴木 雄介氏をお招きし、IT アーキテクトの視点からみたシステムの設計の考え方から、マイクロサービスや DevOps に対する取り組み方の本質、さらにはエンジニアとして重要に考えるべきこと、若いエンジニアに取り組んで欲しいことなど、 さまざまな事を聞いてみました。

ということですが、ちらりと内容を書いておきます。

■今のマイクロソフトってどうよ（2'15～）
元々、統合された技術としては非常に良くできていたが、それがオープン性を取り入れて頑張っている。応援したい

■ITアーキテクトの考え方で大事なことってなに？（4'35～）
最初に道具（技術）を決めてしまうと選択肢が少なくなってしまうので、顧客の問題をきちんと理解してから道具を選ぶようにしたい

■建築家の考えていることから何が学べるのか？（5'55～）
ビルを作るような建築家は、単に「どういうビルを建てるか」という以上に「ビルが完成してから、どう良く運営し続けるか」というような視点があるのが面白い。そういう視野の広さはITでは全然足りていない

■アーキテクト的な「予見する」とアジャイル的な「やって学ぶ」はどう切り分けているの？（8'30～）
結論は「バランスが大事」。50階のビルを建てるのに「とりあえず1階を作る」ことはできないが、ビルの外装ができた後に内装や設備を入居者に合わせて変えることはできる。そもそもアジャイルも「ベースをキチンと作って、その上で分からない事は学ぶ」という考えのはず

■マイクロサービスにはどうアプローチすべきなのか？（11'05～）
そもそも「マイクロサービスでやりたい」というのはダメ。継続的な改善を続けて結果的に良い形になったのがマイクロサービスだということ。まずは全社視点で最適なシステム配置を考えることから始めないと
日本ではSIerというビジネスモデルによって会社内でシステムが縦割りになっているのは大きな問題。それらをユーザー側の視点で全体最適できるアーキテクトが必要

■どうやって現場でアジャイルを浸透させていけるのか（16'00～）
地道な戦い。現場でウィーターフォール的にやるべきこととアジャイル的にやるべきことを1つ1つ一緒に考えていくしかない。半年とか1年をかけて変わっていってもらうしかない
「ある程度柔軟にやったウォーターフォール」と「計画をある程度ちゃんとやったアジャイル」は本来的に同じ事。いつの日か「柔軟なウォーターフォール」が主流になれば、それをアジャイルと呼び始めればいい

■Netflixは「自分たちに合う手法を適用しているだけ」と言っている（19'20～）
「アジャイルをやる」ことを目的にしてはいけない。そういう標準とかテンプレートのようなものを導入すると考えなくなってしまう。つねに「何が自分たちに必要か」を考え続けるのがエンジニアに求められていること

■若いエンジニアは何に取り組むべきか（23'00～）
エンジニア個人としてのオープン性が大事。自分が「何が分からないかが分かる」までは勉強しないといけないが、それ以降は色々な人と話をするほうがよい。JJUGやMSのイベントに遊びに行って話しかけてほしい

■5年後のビジョンは？（24'30～）
特に「こうなっていたい」というのはない。理想に向けて常に地道に努力をする、というだけ。振り返って「あー、こういう5年だったんだな」と思えればいい

JJUG CCC 2015 Fallご報告

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

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

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

恒例となった懇親会でのLT大会の様子

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

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

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

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

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

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

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

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

マイクロサービスアーキテクチャ - アーキテクチャ設計の歴史を背景に from yusuke suzuki