マイクロサービス化設計入門 - AWS Dev Day Tokyo 2017
2017年月31日開催されたAWS Dev Day Tokyo 2017で「〜マイクロサービスを設計する全ての開発者に送る〜クラウド時代のマイクロサービス設計徹底解説！」という講演をしました。
諸般の事情でタイトルは煽り気味ですが、40分しかないのに徹底解説というのもあれなので僕としては「マイクロサービス化設計入門 」ぐらいの雰囲気です。マイクロサービス化にむけて設計をする場合に気にすべき点について整理をしています。資料はこちら。
巨大なシステムであってもマイクロサービス化によって柔軟な変更が可能になります。ただし、既存のモノリシックなシステムから品質方針の変更が必要になります。
モノリシック
- 単一システム内で不整合を発生させない
- 障害を発生させない
マイクロサービス
- 複数サービス間で不整合が発生する前提で頻度やリカバリ方式を検討する
- 障害が発生しても影響を一部に抑えてシステム全体をダウンさせない
講演後のQAでも、ここらへんの進め方について「ビジネス部門に不整合発生をどうやって納得してもらうか」という質問をいただきました。
回答としては「サービス分割自体は適切に検討した上で、サービス間の不整合の発生を前提として、その『発生回数を減らす』『リカバリを自動化する』といった方式についてコストを提示していくしかない」になります。サービスを分割する以上、技術的限界もあって完全に不整合を排除することはできません。この割り切りがうまくできるほどマイクロサービス化したメリットが高くなります。
何かを得れば、何かを失う。
そして何ものをも失わずに次のものを手に入れることはできない。
とは小説家 開高健の名言ですが、まさにその通りなのです。
ここら辺を掘り下げる話も、どこかでしてみたいですね。
2017/6/15追記。動画が公開されました。
JJUG CCC 2017 Springを開催しました #jjug_ccc
昨年の12月からブログを書いていませんでしたね。こんにちは、JJUG会長の鈴木雄介です。2017/5/20（土）に20回目となるJJUG CCC 2017 Springを開催しました。
まずは、参加者、講演者、スポンサー各社、ボランティアスタッフ、そして幹事のみなさま、参加ありがとうございました、そして、お疲れ様でした。
参加者は1034名（申込1874名）となり、過去最高を記録しました。20回目で1000人越えという大きな区切りを向かえることができました。
ともかく混雑してましたね。満席で部屋に入れない、部屋間の移動が大変、懇親会が満員電車などなど。我々としても、あの会場で1000人越えは厳しいな、と感じています。
結果「会場が狭い」「混雑しすぎ」という意見はメールやSNSを問わずにいただいています。はい、おっしゃるとおり。
そして、それに対して私も含めて感情的な反応が出てしまったことを申し訳なく思います。「事情も知らないのに文句を言うな」という感じで。この増田が分かりやすい指摘かと。
初めてJJUG CCCに参加した後輩が「聞きたいセッションがいっぱいで残念だった、もうちょっと広い会場でできればいいのに」と言っていたところに、「運営側の苦労も知らないで文句言うな」という意見が流れてきてむしゃくしゃして書いた。
Javaのイベントでは、会場の狭さに文句を言うことは許されない
運営側からすれば、色々な制約の中で選んだ会場であり、そう簡単に広くもできないという事情の中、参加者の一部からは好意的な言葉（「運営は頑張っている、狭いのは我慢すべき」）をもらっていると、どうしても文句に対して敏感になります。運営ハイの最中なので、なおさらです。
そんなわけで感情的な反応については心からお詫びをしたいと思いますが、一方で「幹事だって人間だもの」という広い心でお許しいただければ幸いです。
ところで増田に書かれている「コミュニティ慣れしていない人への対応」ですが、僕としてはコミュニティ初心者を歓迎したいです。コミュニティ文化を知らない人、あるいは「お客様気分」の人、そういう人がコミュニティに触れて、その混雑も含めて楽しさを見出し、もっと参加したい、次も来よう、いつかは登壇しようと思うきっかけになってもらいたいのです。そうでないとコミュニティは継続しません。
ですから、副作用的に文句が出ることも当然だと思っています。コミュニティの事情が良く分からないと「運営をどうにかしてくれ」と思うのは当然です。副作用は仕方ないのですが、それがネガティブな思い出になってコミュニティ初心者に伝わるのも避けなくてはいけません。
幹事にも言いましたし、いわゆる「常連」な皆様にもお願いですが、事情を知らない人にも優しくしてあげてください。ただ、甘やかす必要は無いので、（説教にならない程度で）コミュニティの事情や状況を話してください。1000人規模のボランティアイベントなんだ、参加者みんなで創り上げるもんなんだ、と。それを聞いても文句がある方は、次回から来なくなると思います。
僕としては「Javaとコミュニティ」みたいなセッションを毎回やったほうがいいんだろうな、と思いました。JUG（Java User Gourp/ジャグ）とは何か、Javaの仕様がどう決まるのか、標準JavaとOSSの違いはなにか、JJUGはどうやって運営されているのか、あたりでしょうか。
「そんなに真面目にやらなくても」という意見もあるかもしれませんが、社会人としてコミュニティのエコシステムを知ることは大事なことだと信じています。世の中を効率化するのに会社を超えたコミュニティは欠かせない存在です。
さて、「事情」は色々ありますが、私から話せるのはお金に関わることです。
今回のCCC実施にかかる費用は400万円ぐらいで、これをスポンサー費でまかなっています。今回は19社に協賛してもらいました。ちなみに日本オラクルさんは立場的にダイヤモンドスポンサーをお願いしていますが、大きなお金を出しているわけではありません。Javaコミュニティに賛同してくれている大事なスポンサーの1社です。
明細は以下の通りですが、ボランティアで運営しているため人件費はかかっていません。
- 合計：398万円
- 会場：290万円（ベルサール新宿グランドの料金表）
- 外注（通訳など）：6万円
- レンタル（無線機、延長ケーブル）：14万円
- 懇親会（フード、ドリンク）：50万円
- コーヒー：10万円
- 交通費（地方講演者支援分）：15万円
- 託児：13万円
たいていは費用が先支払いで、スポンサー収入が後になるため、一時費用は事務局企業に肩代わりをしてもらっています。つまり、毎回400万円の借金を背負いながら企画をしています。これまでスポンサーが足りない、開催できないといったことはないわけですが、常にリスクがある中で準備を進めています。ま、なんとかするしかないんですけど。
で、会場を拡げることは金額的な難しさと、物理的な難しさがあります。現在の会場は「会議室」であって「ホール」ではありません。これをホールにすると金額が数倍になります。JavaDayなんかは立派なホールですね。スポンサー費を数倍にすることも、スポンサー数を数倍にすることも現実的ではありません。そして、運営的にも広い会場には難しさがあります。音響や照明管理、誘導、椅子の移動など、スタッフに専門性と人数が必要になってしまうのです。
そんなわけで今の会場は程よい大きさと部屋数のバランスが気に入っています。もし、都内で10部屋以上で1000人以上収容できて、全部屋に1分以内でいけて、1日300-400万円のところがあれば、ぜひ教えてください。乗り換え検討しますので。他にも部屋別予約システム、全部屋無線LANなども検討していますが、いずれも数十万円単位で、かつ、完璧なものではありません。
そして人件費をゼロにするためには「幹事も含めてボランティアで回るぐらいの運営負荷にする」ということが大事です。CCCの運営は修業ではありませんし、儲けがあるわけでもないので、スタッフも苦労しつつも気持ちよくやれる、というレベルを維持する必要があります（打ち上げも割り勘です）。当日ボランティアスタッフは継続的に参加していただいている方もいて練度があがってきました。非常に感謝しています（参考：JJUG CCCボランティアスタッフのススメ - 我らねぶた馬鹿）。
また、本家のような有償化（数万円レベル）は考えていません。日本におけるJavaはエンプラを中心としつつ、OSSを含めれば非常に幅広いユーザー層が対象で、そこまで尖ったイベントをするのは難しいと思います。ただ、懇親会では「交流ではなくご飯だけが目的の人が増えてきた」という話もあるので、大きな負担にならない範囲で有償化を検討します。
もちろん、幹事も毎回のように改善を続けています。ただ、反省がなくなるわけではありません。次回は1000人超えをどうするのか、あるいは人数を絞るのか、幹事会で議論をしていきたいと思います（参考：JJUG CCC 2017 Spring 運営の人の話 – hotchpotch）。
結論として現時点では1000人を大きく超えるようなイベントをボランティアで回せる気がしていません。JAWS DAYを参考にすれば、とも言われたので、誰か中の人がいれば事情を教えてもらいたいです。五反田TOCメッセって、どうなんでしょう。
そんなわけでCCCは続けていきたいので、色々な試行錯誤をしきたいと思います。次回は11/18（土）を予定していますので、そこに向けたフィードバックはいくらでもお待ちしております。どうぞ、ごひいきに。
※年次定期総会資料
JJUG CCC 2016 Fallを開催しました #jjug_ccc
日本Javaユーザーグループの会長 鈴木です。2016年12月3日（土）にJJUG CCC 2016 Fallを開催しました。事前申し込み1525名、当日参加905名と記録更新です。
ベルサール新宿グランドにも慣れてきたのと、今回は貸し切りだったので大きな混乱はなかったかな、と思います。ただ、トイレ待ちでセッションに間に合わない、といった声もあるみたいなので、休憩時間の延長なども考えたいと思います。「キャパの限界」という意見も承知していますが、様々な事情からもうちょっと同じ会場で頑張ろうと思います（たぶん）。
また、参加アンケートもありがとうございます。次回に活かしたいと思います。まだ書いていないよ、という方はアンケートフォームからお願いします（ページが多くてごめんなさい）。
JJUGを支える数字の話
当日は部屋担当などでのんびり過ごしていたのですが、懇親会LTで枠が空きそうだったので、あわてて最新データを集計して発表してみました。
JJUG CCCはコアな技術者が多そうなイベントに思われがちですが、実際には初参加が5割弱、20代が4割弱です。技術的な勉強というだけではなく、コミュニティがどんなものかを知りたい人にも気軽に遊びに来てもらっていると感じます。
また、運用費が（人件費はボランティアベースで0円でも）400万円近くかかります。僕は「スタッフが当日に大変すぎると長続きしない」と思うので「地味に苦労するところはお金で解決」という方針にしています。たとえばコーヒー配布とかだって、機材を借りて自力でドリップしてもよいのですが、やはりスタッフに負担がかかってしまいます（Javaイベントだとコーヒーを配りたいし）。
こうしたことも考えつつ、この規模で開催できるのはスポンサー各社のおかげです。ありがとうございます。
スポンサーの問い合わせをいただくことも多くなってきました。JJUG CCCでは「お金も、コンテンツも出してください」とお願いしております。コンテンツは「エンジニアが魅力的に感じるJava（関連）の話」となります。ご相談は近くの幹事か僕にくださいませ。
CCCの運営方針について
エンジニアの成長に必要なのは内発的な熱量であり、それは、すごいエンジニアを知る、自分の悩みをカッコよく解決している話を聞く、先進的なオープンソースに触れてみる、みたいなことをキッカケに生まれるものです。
ただし、キッカケは千差万別なので、CCCのような場は、スピーカーやコンテンツの多様性を維持しながら、そんな出会いが1人でも2人でもいてくれればよいなと思います。それがJavaの未来のためにもなることなので。
基調講演で @cero_t が話していたように「発信する人のところに情報は集まる」のですが、その発信の仕方は色々あっていいです。ブログを書く、講演をする、スピーカーと話す、あるいはコミュニティ運営に携わる。どんなことでもいいですが、なんらかの発信をしないことにはフィードバックがありません。
なので、いつかは勇気を出して「話がしたいです！」と言わないことには進まないのですが、CCCは基本的には半年ごとに継続しているものなので「今回は話せなかった...」みたいな後悔があったなら、ぜひ、次の機会に挑戦してみてください。みんな優しいです（たぶん）。
コミュニティというのはメンバー相互の交流が目的です。なので、スタッフの立場からは場の提供に徹するべきだと思っています。コンテンツは基本的に公募ですし、方向性をコントロールするつもりもありません。総括する立場にもありません。ただ、技術的にも、その他の観点でも中立性や多様性を維持する努力はしていきます。意見があるよ！という人は、可能な限りオープンに発信いただけますでしょうか。真摯にコミュニケーションしていきたいと思います。
SIerが考えるプロダクトオーナーのありかた
2016/11/26（土）に行われたプロダクトオーナー祭り 2016で、プラチナスポンサーとして「プロダクトオーナーは育成できるのか？」という話をさせていただきました。資料は後段に。
なぜSIerがPOを語るのか
弊社は受託開発を中心とするシステム開発企業、いわゆるSIerです。資料も「SIerとして」という立場から書いています。なので、最初に「なぜSIerがプロダクトオーナーを語るのか」というのを説明したいと思います。
そもそも弊社は優先的に「大企業においてプロダクト開発的なプライム案件」を中心に獲得をしています。顧客企業はヘルスケア、通信、クレジットカード、データサービス、出版などの大手企業で、案件チームごとに10～15名ぐらいのメンバーが稼働し続けているような形態です。いわゆる保守というよりは、もっと新機能開発や改善を中心にしています。
弊社が、こうした案件にこだわる理由は、
- 継続前提の案件であれば、弊社の事業が安定する
- 顧客が継続的に投資するのは戦略的ITであり、やりがいがある
- 試行錯誤として新しいアイデアや技術へのチャレンジが認められやすい
というようなところでしょうか。よって、「大手企業におけるSoE（System of Engagement）」が最適となります。
こうなると顧客側の案件担当者との関係性が大切で、まさに「プロダクトオーナーとして振る舞っていただく」ことが重要になります。この「プロダクトオーナーとして」という言葉は、近年になってプロダクトオーナーという言葉が注目されたから使っているだけで、以前から「決定や判断が上手な担当者」であるかは案件の成果に大きく係わっていました。
ただし、大企業では「ベンチャー企業のプロダクトオーナー」とは異なり、経営者への調整や社内部門への調整が重要になってくるため「日本的なプロダクトオーナー」という言葉を使っています（参照：日本企業にアジャイルを導入して考えてこと #easg - arclamp）。
POは育成できるのか？
プロダクトオーナーという言葉に注目してみると、そこに溜まったノウハウというのは日本企業のIT担当者にとって有用なことに気付かされます。特に「企画部門」と言われている方々にとって重要なスキルになっているわけです。
そこで「日本的なプロダクトオーナー向けにプロダクトオーナースキルを身につけてもらう」というメニューがあれば、それなりに需要があるのではないか、と思いました。そこで社内で過去の経験からスキルモデルや育成コンテンツなどを作っています。まだ正式メニューというわけではないですが、話をすると興味を持ってくれる方も多く、少しづつトライアル導入を拡げています。
というわけで、興味がある方は連絡をいただければと思います。 →弊社の問合せページ
資料はこちらから。
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人規模のイベントもあります。毎月のナイトセミナーでもいいです。皆さんの参加を心からお待ちしています。
日本企業にアジャイルを導入して考えてこと #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ではあるものの、顧客との協業関係を築きながら段階的な拡張に対してビジネス的にも矛盾せずに対応できるようになっていますが、これはレアケースでしょう（←ステマ）。
せっかく拡張構造の集大成としてマイクロサービスアーキテクチャというものが定義され、かつ、オープンソースやクラウドサービスとして整備もされつつある状況です。なので、アーキテクトがすべきなのは、それを学んで自分のドメインへの適用方法やタイミングを考えるだけです。ただ、その「だけ」ですら、なかなかできていないのが現状でしょう。
日本のエンジニア（特にエンタープライズの）がアーキテクチャ設計のジレンマを乗り越えるべく、主体的に取り組んでくれることを心から願っています。
