ウォーターフォールとアジャイルを考える
初めて単独主催の勉強会をしました。ワークショップなので後半の1時間はディスカッションにしたのですが40人のわりには、それなりに面白い話ができた気がしています。資料とワークの結果、あとTogetterは以下から。
今回のプレゼンは純粋な「プロジェクトマネジメント論としてのウォーターフォールとアジャイルの違い」に絞った話をしたので、後半のワークが現実的な話になって面白かったです。話をしたのは以下のようなことです（資料の後半に細かいメモ書きがあります）。
- そもそもウォータフォールは必要なのか？
- とはいえ、ウォータフォールを採用しなくてはならない状況は？
- なぜ、アジャイルを採用できないのか？
- チームは重要だけど、どういうメンバーがいいのか？
- アジャイルとはいえ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
ソフトウェア開発におけるデザイン視点の変化
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コンテナの時に感じた「アプリケーション動作品質がコーディング可能である」という衝撃と似ています。
ソフトウェア開発におけるデザイン視点の変化
もう少し詳しく、下の絵を見てください。これはソフトウェア品質モデルを図示した物です。
ソフトウェアの品質は右から「利用時の品質」「外部品質」「内部品質」「プロセス品質」に類別されると考えられます。これを「ITサービスの品質」「アプリケーション動作の品質」「クラス構造の品質」「プロセスの品質」と置き換えてみましょう。
その昔、エンジニアがコードで管理できるのが「クラス構造」だけであったものが、ユニットテストやDIコンテナによって「アプリケーション動作」も管理可能になり、さらにクラウドの現在では「サービス」も管理可能になった。様々な技術や手法の発達が前後しながら、これを促進したのです。
何度か書いていますが、エンジニアの主戦場は「ソフトウェア開発（プログラミング）」から「サービス運営」に移ってきています。
とはいえ、まだまだ「サービスをコードで管理する」ことは未成熟な状況です。一部の先進的な企業やエンジニアの取組みを行い、その結果がOSSや事例紹介という形で広まりつつあります。なので、今が学ぶ良い機会でしょうね。興味を持たれた方は、ぜひ、触れてみてください。
たとえばJJUG CCC 2015 Fallとかでね（ステマ）！
エンタープライズにおけるDevOpsとマイクロサービス - JavaOne2015レポート
バズワード過ぎてタイトルにするのも憚られるのですが、JavaOne2015でキーワードになったことは間違いないので...。
JavaOne2015でもDevOpsやマイクロサービスについてのセッションが多く見られました。昨年はマイクロサービスというとWebアプリケーションフレームワークからの理想論的な話が多かったですが、今年はわりと事例に基づいた話が多かったように思います。ただ事例は事例で抽象的な話にならざるを得ないわけで、目新しい話があったわけではないように思います。
あと「Java（JVM）を使っているよ」というだけのことで、直接的に「Javaでどうすべき」という話は少ないです。これもDevOpsやマイクロサービスが特定の技術の依存しているわけではないから当然のことかと思います。
事例そのものはよく知られたWebサービス系の事例が中心となっていますので、Netflix、Gilt、Twitter、Foursquareなどが色々な話をしていました。これらの事例は、まさにマイクロサービスとして数百のサービスを稼働させています。
よって、技術的なキーワードはランタイムの制御を行うことに力点が置かれていました。具体的には以下のようなものがあげられます。
- デプロイ管理：Jenkins、spinaker
- コンテナ：Docker
- コンテナ管理：Kubernetes、Marathon+Mesos、spinaker
- ルーター：Vamp、Zuul+Ribbon、ロードバランサ
- サービスレポジトリ：ZooKeeper、Eureka
- 分散ログ集約＋視覚化：Elasticsearch+Kibana、Vector
これらの技術群はサービス全体をダウンさせることなしに継続的にサービスの変更を許容するための仕掛けです。代表的な概念が「カナリアリリース」でしょう。
カナリアリリースは現状バージョンのサービスがリリースされている状態で新バージョンのサービスを並列してリリースし、段階的にアクセス先を新バージョンに切り替えていきながら、何か問題が発生したら現バージョンにアクセスを切り戻す（ロールバックする）というものです。「A/Bテスト」や「ブルー・グリーン・デプロイメント」と呼ばれる手法とも近しいものですね。
カナリアリリースの説明。新しいバージョンに5%を振ることでA/Bテストになる
カナリアは炭鉱で鳥かごにいれられて天井近くに吊るされており、有毒ガスが発生すると騒ぐため「問題の発生を先んじて発見する象徴」として使われています（カナリアにとっては迷惑な話でしょうが）。
Giltの事例では「ダークカナリアリリース」という言葉で「開発者だけがアクセスできるテストバージョンのサービスをリリースする」という話をしていました。マイクロサービス環境ではサービスをテストするのに周辺サービスをセットアップしないと稼働確認がしにくいわけですが、周辺サービスのセットアップは大変なので、そうであれば本番環境にテストバージョンのサービスをリリースしてしまい動作確認をしたほうが効率的というわけです。もちろん課金などの関わる本番に影響を与えるようなサービスについてはテスト環境を持っていると話していましたが、そうではないサービスは本番でテストしたほうが効率的なのでしょう。
Giltのセッションでの1ページ。『我々は本番環境でのテストはいけてると考えている』
また、NetflixにはChaos Monkeyという「障害をランダムに発生させるツール」があるのですが、AWSのインスタンスは毎週、アベイラビリティゾーンあるいはリージョン丸ごとは毎月障害を発生させているそうで、知ってはいたものの実際に聞いても信じられないという思いが先に来てしまいます。
Netflixのセッションで紹介された動画。左上のリージョンがダウンし、アクセスが他のリージョンに移った後、リージョンが復旧して戻っていく様子
エンタープライズ業界にいるとダークカナリアもChaos Monkeyも「それは厳しい」という話かと思います。もちろん「テスト環境よりも本番環境でテストしたほうが良い」とか「本番で障害訓練をしていたほうが本当の障害に対応できるようになる」というのが合理的であることは間違いありません。しかし、その結果として「全体的にサービス品質を高めるためには部分的な品質劣化を許容する」というのは「部分の品質を積み上げることで全体の品質を担保する」というエンタープライズ的な考え方からすると理解しがたいものです。
Netflixの考え方は「運が悪いユーザーがいることを許容することで大規模なサービスダウンを未然に防ぐ」というものですが、講演者も「Netflixがダウンすることは悲しいけど、とはいえ、絶対にダウンしてはいけないサービスではないことが前提だ」と強調していました。「軍事、医療、金融といった分野で許される考え方だとは思わない」と。
よって、DevOpsというか、マイクロサービスというか、Web企業の先端的な取り組みについては「それはそれで効率的なことは理解する」ものの「すべてのサービスがそうなるべきかは別の話」ということでしょう。
また、マイクロサービスにしても「チーム個別の自治権を許容する」ということは、チームごとに品質のばらつきがあることを許容することと同じです。これもまた従来型の品質管理からすると受け入れがたいものですね。
もちろん、エンタープライズにおいてもカナリアリリース的発想は重要でしょうし、それが認められる分野も間違いなく存在します。システム連携が複雑になる中で「単体アプリケーションレベルでの完璧な品質」など意味がないのであれば、サービス全体の品質を判断基準にしていくのは当然のことでしょう。
ただ、現状で取り組もうとすると先ほど上げたような技術群は安定的とはいいがたく維持コストは相当なものとなるはずです。とはいえ、エンタープライズでもDockerがデファクトスタンダードになりつつあるわけで、コンテナ技術を前提としたプラットフォームマネジメントツールが一般的になってくるのは間違いないものでしょう。
たとえばAzureではセキュリティアップデートのために仮想マシンの自動的な再起動が起きるため、これを前提としたアーキテクチャ（異なるロール間の受け渡しにはキューを利用する）を採用する必要がありますが、こうした割り切りは今後も増えていくはずです。
クラウドを契機に品質の概念はずいぶんを変わったものになりつつあります。例えて言うなら「ガベージコレクションがメモリ管理を不要にした」のと同じように「プラットフォーム管理ツールがインスタンス管理を不要にする」という未来が待っているのでしょう。
アジャイルとウォーターフォールと同じように「既存の考え方を安易に否定する」のはダメですが、全体的な潮流を理解しながら技術の使いどころを俯瞰していくことは重要ですね。
JavaOne2015のサマリ
2015/10/25-29日で行われたJavaOne 2015に参加してきました。
来年のJavaSE 9および再来年のJavaEE 8に向けた端境期であったこともあり、近年まれに見る発表要素の少ないJavaOneでありました。
特に初日のキーノートでは、Java 20周年であったことから、スコット・マクニーリがやらかしたので最低限のお祭り気分は維持されたものの、昨年からのアップデートも少なく、特筆すべき話題はありません。
キーノートで言いたい放題のスコット・マクニーリ
一方、最終日に行われたコミュニティキーノートはバック・トゥ・ザ・フューチャーを模した寸劇の連続で、2009年に遡れば「SUNがORACLEに買収されちゃった！どうしようJavaが有償になっちゃう！」とか「OSGiは古い、これからはJigsawだ。ORACLEなら2010年か2011年には仕様になるよ！」と言ってみたり、2004年に遡れば「Javaがオープンソース化されてOpenJDKができるだって！なんてSUNは素晴らしいんだ。これでどっかに買収されるなんところはなくて未来は安泰だね！」などなどコミュニティメンバーが言いたい放題で大いに盛り上がりました。
コミュニティキーノートの寸劇の最後は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が開催されます。まだ、何が入るのかは議論の余地があるところですので続報を見ながら楽しみに待ちたいと思います！
お約束のトレジャーアイランドでのパーティ
