orangeitems’s diary

クラウドではたらくエンジニアの日々の感想です。

相変わらず混乱しているJavaの新しいリリースモデル

f:id:orangeitems:20180521104049j:plain

 

改めてJava

日経 xTECHから、Javaのリリースモデルの記事が本日出稿され、改めて話題となっているようですね。

 

tech.nikkeibp.co.jp

 

ご存知の通り、OracleによるJavaのサポートモデル変更はまだ落ち着いていません。この記事の大きなポイントは、ここです。

懸念点があるとすれば、OpenJDKではLTSの提供をまだ公式に表明していない点だろう。ただ、LTS提供の意向は示しており、「おそらく提供されるだろう」というのが大方の見方だ。LTSが提供されることがはっきりすれば、企業の情報システムで利用するJava SEも無償のOpenJDKで構わない可能性が高い。

 可能性が高い、と言う言葉で、企業のシステム計画を立案するわけにいかないというのが混乱のもとです。

Java 8のサポートは2019年1月に切れます。これ以降はOracleに有償サポートを申し込まない限り脆弱性のパッチは手に入れられないことになります。ただ、Redhat Enterprise LinuxにインクルードされているOpenJDKについては、Redhat社が独自に2020年10月までサポートすることが分かっています。

2018年5月現在のJavaサポート状況をまとめる - orangeitems’s diary

 

今後は?

一方で、Oracleは、OpenJDK 11のLTSサポートを推進する方向であるとOracle Blogで表明しています。

OpenJDK11のLTS(長期サポート)実現をOracleが支援する方向で調整 - orangeitems’s diary

OracleもJavaのエコシステムを壊し、ユーザーを減らすことは望んではいないと思いますので、「おそらく提供される」と思います。ただ、やはり明確にはなっていません。

Oracle Java SE 11がリリースされてから、つまり2018年9月になって初めて、OpenJDKにおいて動きがあると思います。また、Redhat社もおそらく、OpenJDK11をRedhat Enterprise Linux 8でサポートし長期リリースに加えてくるのではと私はにらんでいます(憶測)。RHEL7ではさすがに今更やらないだろうと・・(わかりませんが)。

企業とすれば、OpenJDK11がLTSになるか、RedHat社が長期サポートを決定してからJava8 -> 11化のプロジェクトを立ち上げたいところですよね・・。

 

まとめ

Oracleとすればあいまいにしたままのほうが、問い合わせも増え商談も増えると思いますのでこのまま状況は推移すると思われます。

もしOracle Java SEをこのまま使い続けたいということであれば、Oracle社に問い合わせを行いどう安定的にJavaを利用するかはっきりさせたほうがよろしいかと思います。そのうえで有償サポートに切り替えるか、OpenJDKに切り替えるか、もしくはJavaを捨てるかを考える必要があると思います。

OpenJDK + Redhat Enterprize Linuxにしているのであれば、RedHatのOSサポートに合わせて考えていけば良いかと思います。ここはRedhat社と話しながら進めたほうが無難です。

また進捗があれば記事にします。基本的にここ数カ月間状況は何も変わってないなあと思います。

ごもっとも→経団連が情報経済社会省(デジタル省)創設を提言

f:id:orangeitems:20180520211044j:plain

 

デジタル省創設を提言

経団連が何か提言すると条件反射的に反発が広がるようですが、これは正しいと思いますよ。

 

www3.nhk.or.jp

経団連は、ビッグデータの活用を国を挙げて強力に推し進める必要があるとして、政府に「デジタル省」の創設を求める提言をまとめました。

提言では、ビッグデータの活用は経済成長のカギを握ると指摘したうえで、アップルやグーグルなど海外のIT企業はスマートフォンなどから得られる膨大なデータを活用して新しいビジネスを生みだし、急成長を遂げていると分析しています。

 

本当にばらばら

民間から見ると、経済産業省と、総務省と、内閣府がばらばらにやっているように見えますし実際、似たような予算が分割されています。下記の記事で予算を調べたことがあって思い出しました。セキュリティー一つとってもばらばらにやっているのです。

 

www.orangeitems.com

 

そもそも、情報技術分野において、ITとICTという言葉が日本で混在しているところからしてバカバカしい経済産業省と総務省の陣地争いから始まっています。

 

tech.nikkeibp.co.jp

 

有料記事ですが、冒頭だけでも内容は理解できると思います。

総務省に一杯仕事をもらっている企業は、ITじゃなくてICTって言ってますよ。特に通信界隈は総務省管轄なので、NTTは絶対ITって言いません。ICTって言います。

経済産業省においては、IPAが主導して民間に情報提供をしていますが、IPAのページではITという言葉になっています。

放送法撤廃の件もそうですが、特にIT分野について、制度が古すぎて生産性が非常に悪くなっています。その一方で欧米はデジタルを政治の中心においていますから、どんどんグローバルスタンダードは欧米に決められていき、日本にローカライズする中で同じことを複数の組織に分かれて解釈しようとするものですから、もはや日本はデジタル的には世界を追従するしかない立場になっていると思います。

 

行政はデジタルに最適化せよ

この前の財務省文書改ざんの事件でもそうですが、20世紀のような話がこの現在にも発生する時点でレベルの低さが露呈しています。

マイクロソフトに、揶揄されていましたよね。

logmi.jp

まさに、古いしきたりばかりを優先し何も新しいことに取り組まない日本は、何か新しい刺激でもないと根本から変革できないように思えて仕方ありません。

目に見えて、デジタル後進国となってしまった日本が、世界に追いつくためにはトップである行政の大幅な改革が必要です。デジタル省大いにごもっともです。

図らずもTorの匿名性が証明されてしまった年金流出事件の時効

f:id:orangeitems:20180520122109j:plain

 

年金情報流出事件が時効

3年ほど前に大きな話題となった年金情報流出事件ですが、時効が成立し終了となってしまいました。

mainichi.jp

日本年金機構が2015年5月にサイバー攻撃を受け、約125万件(約101万人分)の個人情報が流出した事件は、20日午前0時に不正指令電磁的記録供用容疑の公訴時効(3年)が成立した。警視庁公安部は犯人の特定に向けて同容疑で捜査を進めたが、通信先を匿名化する通信ソフト「Tor(トーア)」などが壁となった。公安部は21日に容疑者不詳のまま同事件を書類送検し、捜査を終結する。

 

事件に「直接」Torは関係ない

この件は、標的型攻撃の恐ろしさが世間に知れ渡ったことで有名です。

cybersecurity-jp.com

2015年5月、日本年金機構に対し外部から「標的型攻撃メール」が送られ、その結果年金管理システムに保管されていた125万人分の個人情報が漏洩しました。

組織の前身である社会保険庁の時代から「情報管理」において不祥事を多発していた日本年金機構。甚大な被害を出してしまった2015年の個人情報漏洩事件から1年が経った今、彼らはどの様に生まれ変わり、国民の年金情報管理を担っているのでしょうか。

今回は日本年金機構で起こった情報漏洩事件について、事件の経緯や原因、その後の対策、現在行われている情報管理方法まで調べてみました。

 

その後、ウイルスは「Emdivi」であることがわかっています。

japan.zdnet.com

 

しかし結局のところ、事件の終始においてTorが登場した経緯はありません。毎日新聞の記事によると標的型攻撃によるデータ流出の際の送信先のIPアドレスが、Torで使われるもののようでそうなると、Torの中のことはすべて匿名化される前提でありかつ世界に分散しているため困難を極めたという文脈のようです。

ただTorというのはクライアント~サーバー通信です。Tor通信が成り立つためには、年金機構側の端末にTorクライアントをどうにかして導入しないとTor通信が成り立ちません。もし送信先のIPアドレスが犯人のものであるのら、そこを解明すれば良いだけです。しかし今回はそれが不可能だったということになります。

標的型攻撃によって配布されインストールされたプログラムに、Torクライアントが導入されていたとすれば理解できます。

インターネットの日本語の情報を見ると、まるで「Tor Browser Bundle」というWEBブラウザーを使うことが唯一のTorの使い方のように見られる記事も散見されるのですが、これは誤解です。Tor自体はオープンソースであり下記サイトにすべての情報があります。

www.torproject.org

 

このサイトの中に、PythonでTorクライアントを作るためのライブラリがあります。Stemです。

f:id:orangeitems:20180520120005p:plain

Pythonの実行環境とStemライブラリとプログラムをインストーラーにして忍ばせればユーザーに知られることなくTor通信を成り立たせることが可能のように思えます。Python自身はサイレントインストールできますしね。

また、Stemのページを見ればわかりますが、HelloWorldからサンプルプログラムまで、実装まで書いてあるのでプログラマーであればそこまで難しくない内容に見えます。

EmdiviがStemを取り込みTor経由でファイルを送信していたとすれば何となく操作が難航するフレームワークが見えてきますがこれは私個人の憶測にすぎません。

 

一連の感想

時効ということであれば、調査内容は今後のセキュリティー業界のためにオープンにしてほしいところです。少なくとも何がTor絡みであると判断したかについては情報が明らかにされることを望みます。

システムエンジニアは自宅にもワークスペースを持つべき

f:id:orangeitems:20180519174957j:plain

 

自宅にワークスペースを作ってみた

VR絡みでデスクトップパソコンを買ったので、これを機に自宅に会社と同じレベルのデスクと椅子を用意してみました。

といっても、高価なオフィス家具ではなくIKEAのデスク。

 

f:id:orangeitems:20180519173745p:plain

デスクプランナー

これ、なんと3,999円です。天板が2,999円で、足が1つ250円。それぞれ色もカスタマイズできます。私は車でIKEAまで行って持って帰りました。通販でも手に入りそうですが。

で、初めてオフィスなみの広い机を手に入れブログを書いていますが、いいですよ。快適です。集中できます。家ですからね。こんなに安くできるなら早くやっておけばよかったと思いました。

 

なぜワークスペースを持つべきか

会社と同じ作業空間を持つことにより、会社も自宅も同じ品質の作業ができるからです。なので、会社で思っていたいろんなやりたいことをそのままシームレスに自宅に持ち込めます。長時間作業できる机と椅子に身を置き、十分な性能のパソコンと向かい合ってるといろいろ想像力がわいてきます。

MacBookをソファーの上で開いていた時に、何か実行したいと思ってもなかなか実行まで行けなかった理由が、実は自分の体を置く物理的スペースの性能が低かったということを思い知らされました。

何せ、机は4000円で手に入る時代ですから、もし自宅で、ソファーの上でノートパソコンで作業している人がいたら、ぜひ机と椅子を手に入れて作業してみてほしいです。かなりクリエイティブな環境になること間違いなしです。

・・ということで、まったくITの話題ではないのですが、結局人間が操作している以上は人間の環境(机、椅子、部屋、温度、音)が重要なのだなと痛感したので記事にしておきます。自宅だからといって手を抜いたらイケナイ。

もしかしたら人生が変わるかもしれないぐらいの差です。

パーシステントメモリーの登場でデータセンターは激変する

f:id:orangeitems:20180519165247j:plain

 

業界のルールが変わる

新しいメモリーが世界を変えます。しかも2020年。2年後の話です。

メモリーは外部記憶装置と比べると爆速なので、最近はインメモリーデータベースという、データをすべてメモリーに置きバックアップを外部記憶装置に置き実行するタイプのデータベースが流行しています。最近はどの商用データベースを選んでもインメモリーデータベースのサポートをしています。それぐらいメモリーは高速に計算するうえでは重要な部品です。

ただし、基本的にメモリーは、電気を通し続けないと記憶した情報が失われてしまいますよね。ですのでハードディスクやSSDなどの外部記憶装置に書き込んで電源を停止してもデータが保管するようにしています。

パーシステントメモリーという単語をご存知でしょうか。

パーシステントとは、持続的という意味ですが、なんと電気を通し続けなくてもデータが失われないという夢のメモリーです。この「夢さ」がまだ日本には伝わってないと思います。電源を停止してもメモリー情報が残るというのは、実際ITのインフラに携わっている人間にとってかなりのルールチェンジです。パーシステントメモリーが一般的なものとなり、最近のDIMMと呼ばれるメモリが無くなったらどうなるかを、よりエンドユーザー目線で想像したいと思います。

 

電源が消失しても、再度電源をつければ継続できる

例えばパソコンの「スリープ」という機能はメモリーだけ通電させ続けることで復帰できます。「休止状態」は外部記憶装置に書き出して電源を停止します。VMwareを利用の方はご存知かと思いますが「サスペンド」という状態はこれと同じです。何しろ外部記憶装置に書き出さないとダメで、電気が継続していないとスリープ機能は実装できないのが常識でした。

スマホのスリープも結局は電池が微弱な電力を通電させ続けてくれるので、実装できています。最近は省電力化がどんどん進んで、スリープ時の電源の減りも穏やかになりました。昔のAndroidはほっとくとすぐ電池が無くなっていました。

さて、このパーシステントメモリーの登場。電気が無くなってもスリープ機能が可能になるのです。

何らかの理由で電源が停止しても、データが破損する確率がぐっと低くなります。これまでデータが壊れる最大の理由は、メモリが外部記憶装置に書き出しを行っている途中の電源喪失でした。書き出しが中途半端なためファイルシステムと整合性があわなくなるのです。この仕組みを回避するため、サーバー機器では、RAIDカードを介在して外部記憶装置と接続し、RAIDカードに電池を入れて停電しても書き込みキャッシュを保持するという仕組みでこれまで回避してきました。この装置も不要になります。電源が復旧したら途中の書き込みが再開されるためこの問題が解決するのです。

 

コンピュータの再発明

パーシステントメモリーの登場は、コンピューターの常識を大きく変えることになります。

 

アイドル時の消費電力がゼロに

メモリーを保持するのに電気がいらなくなるので、この世のオンラインのコンピューターの消費電力がぐっと下がります。CPUがアイドル状態でディスプレイの表示をオフにしたらほぼ電力消費がゼロになります。

データセンターを例にとってみれば、プログラムはいつでも動作してしているのではないし、サーバー側はディスプレイがありませんので、データセンターの電力消費量が相当に下がると思います。物理サーバーはだいたいOS起動時に600Wぐらいを使い、アイドル状態が100Wぐらいだったと記憶しています。この100Wが0に近づいていくという目安を持っておけばいいと思います。

 

システム保守が楽に

かつ、電源断などの障害が起きたとしても、電源が回復すればそのままプログラムが継続します。したがって、保守が相当に楽になります。部品の種類を変えなければ電源を停止し交換後起動すると、なんとプログラムはそのまま動き続けるのです。

システムの停止→OS停止→電源停止→部品の交換→電源起動→OS起動→システム起動、という一連の手順書が、かなりの運用保守の世界で作成され利用されていると思いますが、これがかなり省力化されます。電源停止→部品の交換→電源起動、で十分です。もちろん異常時はシステムやOSの再起動が必要とはなりますが理論的には不要となります。

 

すでに実用化が近い。メモリーの問題ではなく業界がひっくりかえる。

・・・と、ここまでは緩やかな変化な話ですが。もっと刺激的な話があります。

持続的メモリーとは、結局はストレージと何ら変わらないわけで、これを大容量化していくとストレージは不要になります。最終的にはストレージサーバーはすべてなくなり大きなメモリーが残ることになります。

実はここまで見越して2014年から米ヒューレット・パッカード・エンタープライズ(HPE)にて、1つのプロジェクトが進行しています。「The Machine」です。

www.atmarkit.co.jp

japan.zdnet.com

ascii.jp

これらの記事を読むとわかるように、これまでのコンピュータは1960年代のいわゆるノイマン型アーキテクチャーから進んでおらずこのままでは進化が頭打ちになる。これを根本から覆すためのカギがパーシステントメモリーであることが読み取れると思います。

世の中は量子コンピューターのほうが話題になっていますが、実用化を考えるとこちらのほうが先です。

パーシステントメモリは、現在サンプル出荷が行なわれており、2018年中に一般提供開始予定であることが明かされた。対応プラットフォームは、コードネーム“Cascade Lake”こと次期Xeonスケーラブルプロセッサとなり、そちらと同時に展開されるという。

 同氏は、MicrosoftやSAP、VMWare、Linuxといったパートナーからのサポートも受けており、本番システムで利用するためのエコシステムを提供し、簡単に導入できると述べた。

まさに、部品レベルでは今年実用化される分野であり、来年までに相当な変化が起こると想像しています。例えば、この技術を用いて新しいクラウドサービスが出現したら、これまでのインフラは一気に古いものになってしまうぐらいの爆発力をもった技術だと思っています。もしくは、オンプレでもこれだけパワフルで電力もいらず、障害にも強いのであればクラウドサービス不要論も議論されうると思います。

 

まとめ

新しいメモリーが出るのねというレベルの話ではないのに、まだそう誤解している業界関係者も非常に多い分野です。1960年代から続くコンピューターの仕組みは情報処理技術者試験にも登場するくらい基本的なことで、業界経験が長ければ長いほどその呪縛からは逃れられないと思います。

飛行機がない状態から飛行機が発明されるぐらいのことが、今まさに起きようとしているわけで、頭を柔らかくしてのぞまないと、「老害」扱いされてしまいます。

ついに一般提供開始まで来てしまったので、あとはその衝撃を受け止め新しいビジネスを作れたらいいなと思う次第です。

 

iQOSは究極のIoT案件だった件

f:id:orangeitems:20180517105102j:plain

 

iQOSを知る

最近、飲み屋で周りを見ていると、たばこはiQOS(アイコス)で吸う人を見かけます。私は一本も吸ったことがないしこれからも吸うつもりはないのですが、たばこ独特の間接喫煙の煙がないしにおいもないし、結構画期的なんじゃないの?と思った次第です。

まずは、仕組みを勉強しましょう。なぜかというとiQOSを使っている人を目の前にしてどう振る前ばいいかわからないからです。ちなみに普通のたばこであれば息止めてます笑。

chimanta.net

要約

・アイコスとはフィリップモリスが長年開発を続けてきた害の少ないタバコです。
・アイコスの特徴はなんといっても煙が出ないことです。
・アイコスならその有害な物質の9割が削減できます。
・アイコスはチャージャー本体とホルダー、そして専用のタバコ(ヒートスティック)を使用します。
・正直最初は抵抗がありました。やはりタバコとは違います。(中略)最初は微妙かな〜と思っていましたが、3日も経つと普通においしく感じてきましたよ。
・臭いが少ない
・煙が出ないから周りの人に迷惑をかけない

ということで、何やら普通のたばこよりはよっぽどいいものであることがわかりました。

 

なんとチャージャーにはBluetooth機能が内蔵

これだけなら、画期的な新しいタバコというので終わりなのですが、なんとBluetooth機能が内蔵されているとのこと。

chimanta.net

このページくわしいなあ・・。まだ日本ではbluetooth機能が解除されていないのですが今年中には解除されアプリが出てくるのではないかということです。

bluetoothでスマホとつないで、アプリを連動させればサーバー(クラウド)にデータを送信できますね・・ってこれってIoTだ。ユーザー数から言っても究極の端末数になるかもしれません。

“2018年前半に加熱式たばこ「アイコス」でブルートゥースとの連動を始める。使用状況などの情報をリアルタイムで利用者に届ける体制を整備する。
18年前半に必要なアプリを開発して連動できる環境を整える。
アイコスは3月に発売した新機種がブルートゥースの機能を搭載する。
初期のサービスではアプリを通じて利用本数や充電の残り時間などをリアルタイムで発信。
サービスやアプリの種類は順次増やす考えだ。”

 

通信機能をネガティブに見る記事

喫煙者の行動がインターネットに吸いあがり利用される、この事実にネガティブな評価をしている記事を読みました。

toyokeizai.net

加熱式たばこiQOSという新商品に対し規制当局から承認を得るため、フィリップモリスインターナショナル(PMI)<PM.N>は、従来のたばこより健康被害を起こす可能性が低いと主張している。しかし、iQOSにはもう1つの、喫煙者にはそれほど恩恵をもたらさない機能がある。
それは、ユーザーの喫煙習慣に関するデータの収集だ。
PMIは、すでにiQOSユーザーの登録情報をデータベース化して蓄積している。そして、それをさらに一歩進めるアプリソフトを開発した。
これが規制当局に承認されれば、ユーザーの喫煙習慣に関する情報をデバイスから収集し、マーケティングに利用することができる――。フィリップモリスの元プロジェクトマネジャーで、日本でこのソフトをテストした正岡資郎氏は、ロイターに語った。

 

IoTにしろAIにしろ、EVIL(邪悪)でないことが大事だということが最近クローズアップされてきたように思います。先進的であろうとするあまり、モラルハザードを助長するような仕組みを作ってはいけないということです。先進技術に触れていると、便利は法を超越するという感覚を持ちがちになってしまうのかもしれません。

技術自体には善悪はなく、それを使う人や企業が大事ということになろうと思います。行きつくところはコーポレートガバナンス(企業統治)まで及びます。極論、社長が知らないことを社員が始める会社は、どこかで大きなリスクを負うということになります。

iQOSがIoT案件である以上は、そのデータをどのように使うのか、どう社会に正しく還元するのかが明確でないと、FaceBookのように大きな事件にもなりかねないということでしょう。データを集めて何が始まるのか、注視していきたいと思います。

 

未来のパソコンはMicrosoftが作る Surface Hub 2の発表を見て

f:id:orangeitems:20180516175050j:plainMicrosoft Surface Hub | Connect, Collaborate & Share All-In-One Device

 

ずっと変わっていないパソコンの世界

パソコンと言えば、大半の人がデスクトップパソコンとノートパソコンを思い出すと思います。実はその形はこの20年間変わっていないのです。デスクトップパソコンであれば、液晶ディスプレイと箱とマウスとキーボード。ノートパソコンであればいわゆるクラムシェル型と言われるふたを開けるとディスプレイとキーボードが現れる形。

 

f:id:orangeitems:20180516170319j:plain

Windows95 ノートPC あります:ファーストポイント 日本橋店情報

 

上記は、Windows 95が動いていたノートパソコンですが、実際今のパソコンと変わらないのではないでしょうか。1995年から全くイノベーションが起こっていないというのは驚きではありませんか。

 

f:id:orangeitems:20180516171004g:plain

http://www.hitachi.co.jp/New/cnews/9607/0702.html

 

こちらは日立のパソコンですが、これも結局ブラウン管ディスプレイが液晶に変わっただけであり、今もってこんなパソコンと付き合っているということになります。

 

誰もデザインをイノベーションしないまま、性能だけ上がって2018年を迎えてしまったというわけです。日本のパソコンを作っていたベンダーも、結局どこも似たような形のものになってしまい、いわゆるコモディティー化が発生しどんどん中国に吸収されつつある状況、もしくは撤退の道を選んでいます。NEC、富士通はすでに合弁会社にて生産しています。差別化できないなら安くなるしかないという製品になってしまいました。

 

パソコンハードウェアに参入したMicrosoft

ほとんどのパソコンが中国や台湾メーカーという中で、Microsoftがパソコンを作っているのは大分認知されてきたのではないでしょうか。

ascii.jp

この記事の通り、2012年から参入し、今ではAppleのパソコン売り場(いわゆるApple Store)の横に、Surfaceのコーナーもできているのを目にした方もいらっしゃるでしょう。パソコンが陳列されているコーナーとは別枠でプレゼンテーションしています。

 

この一連の動きはMicrosoftがパソコンを作っている、のではなくWindowsが動くハードウェアを再発明するということだと最近理解しました。最近、Suface Laptopを手に入れたのですがその肌触りが、一般的なノートパソコンとは違います。

解像度はMacBookのRetina並みもしくはそれ以上ですし、タッチパネルですし、電池も優秀です。デザインも他のノートパソコンと比べると先進的です。

ぜひ、店頭で見かけたら触れてみていただければと思います。

 

Microsoftの姿勢がはっきりわかる今日のニュース記事

さて、Surfaceだけを見ていたら、Microsoftの考え方がわかりません。今日の下記の記事を見てください。

 

www.itmedia.co.jp

米Microsoftは5月15日(現地時間)、Windows 10を搭載する大画面端末「Surface Hub 2」を2019年に発売すると発表した。50.5インチの4Kディスプレイ(アスペクト比は3:2)を備え、ビデオ会議端末やホワイトボードとして使える。価格などは明かしていない。

 

こちらが、その動画になります。


もうパソコンの形をしていませんよね。Microsoftはパソコンと言う呪縛から逃れて新しいWindowsを表現したいのです。デスクトップである限り、ノートである限り、イノベーションは限定されWindowsも進化できないということです。

 

基本的にはパソコン業界は、Microsoftにパソコンベンダーが集う形で、共存共栄、最近の言葉で言えばエコシステムを作ってきました。しかし、Microsoft自身がハードウェアを出すということはもはやこのエコシステムは賞味期限切れだということをパートナーに突き付けたということになります。

Microsoft自身が尖った製品を先に出すことで、他のパートナーの見本になるということも言えると思います。むしろ非パソコンであれば、linuxやAndroidで動かすシーンも増えているぐらいです。パソコンという呪縛と心中していられないということだと思います。

 

まとめ

実は、下記のエントリで、Surface Laptopと、富士通のテンキー付きパソコンの2台を購入したのですが、

www.orangeitems.com

 

前者はパソコンのイノベーションとしての進化を、後者は家電製品(コモディティー)としてのパソコンの進化を、両方感じ取ってしまったので、このような記事を書かせていただきました。

今後のMicrosoftの製品に期待大です。

 

ユーザー側からの視点で考える「一見、理解されがたい仕事のスキルの所有者たちが、正当に評価され、報われますように」

f:id:orangeitems:20180514135405j:plain

 

運用保守の世界にあるもやもやについて

労働者から見た景色とユーザーから見た景色が違うと、どちらも不満が生まれるという例です。

 

blog.tinect.jp

一見理解されがたい仕事のスキルの所有者たちが、正当に評価され、報われますように。

そう願うばかりです。

 

ユーザー側からの視点で原因を考える 

この記事は完全に労働者側(運用・保守を行うエンジニア)からの観点です。その間に担当営業が噛んでお客様と折衝していそうですね。もしくはアカウントSEをつけているようなケースもあります。そしてその先にユーザーがいるとします。ユーザーはなぜ運用保守料を削るか、想像力を働かせる必要があります。

 

1)バリューが伝わっていない

この記事にもありましたね。安定運用のためにいろいろな運用保守業務を裏方で実施しているのにユーザーに伝わっていない場合です。そのため「何もしていない」になってしまい減額されるというロジックです。監視していたり予防保守作業を行なったりといろいろやっているのに、先方には伝わっていないと。

このケースがなぜ発生するかということを考えて見ます。往々にして設計・構築時の運用設計にて、何を運用保守が実施するかをお客様に理解していただいていないことが原因になる場合があります。ITの知識のないユーザーだと、説明を聞いてくれない場合もあるのですが、何しろ会議室に拉致して数時間、運用保守サービスの内容を事細かに説明した方がいいです。「ほう、こんなことまでやってくれているんだね」という言葉が引き出せたら勝ちです。ですので、運用保守フェーズでお客様にサービス内容を理解してもらおうとしてももはや手遅れである場合がほとんどです。

次に、どんなに開始時に運用保守内容を理解してもらっても、相手の担当者が変わってしまう場合があります。もちろん、交代時に引き継ぎが行われるので、設計・構築時の信頼関係は大事なのですが、もちろん情報は抜けが発生します。したがって、運用保守サービスについては、毎月ごとにレポートを作成し、お客様に最低でも送付することが重要です。これを意外とお客様は見ています。細かくレポーティングすればするほど、バリューが継続的に伝わります。その中に、地味な作業も含めて記載しておくと評価いただけることもあります。

また、定例会など直接お会いして会話することも重要です。顔を見えない時間が長くなればなるほど、取替え可能であるという認識に近づいていきます。これはクラウドでもオンプレでも同じです。人が大事、というのであればお会いに言って不満の一つでも聞いてくれば、バリューとなります。

というふうに、「一生懸命にやってるから分かりにくくても価値を認めてもらいたい」という欲求に対して、ユーザーへバリューを伝える努力がどれだけできたかがポイントになります。安定運用こそ結果だ、と心の中で誇っていても、伝わらないものはバリューにならないのです。

特に、多重請負などが発生している現場の場合は、末端の作業者のバリューなど絶対伝わりません。下記の記事でもこれは書きました。

www.orangeitems.com

 

2)ビジネスがうまくいっていない

どんなにどんなに安定運用しても、そのシステムが稼いでくれない場合があります。たとえばEコマースであれば、製品が売れないとか。もしくは競合が現れてしまったとか。天候不順とか。会社自体の経営に問題があったとか。ビジネスですのでいろいろありますので、1億しか稼げないシステムに1億の運用保守費用はかけられないのです。システム構築時には5年後のビジネス拡大まで目論んで運用設計するのが普通ですので、これを下回るようなビジネス状況の場合、「うるさい、値引け」という状況になるのは普通に起こります。

せっかく設計・構築フェーズを乗り越え、安定運用に入っているのにどうして。そうは言ってもユーザー側のビジネス理由には逆らえません。エンジニアはその辺りの情報まで降りてこないこともザラですので、割り切って別の仕事に情熱を傾けた方が平和だと思います。

 

まとめ

ということで、始めが肝心。そして継続的にアウトプットすること。そして、それでもどうしようもないビジネス上の理屈は素直に諦めること。これが基本にあると思います。運用保守かいわいのみなさま、お仕事がんばりましょう。

 

Google Duplexへの批判、AIがAIと見分けがつかなくなったときに起こること

f:id:orangeitems:20180511222001j:plain

 

AIは敵か味方か

コンピューターが劇的に進化し始めた時、人間の仕事が無くなると揶揄されたものですが、逆にコンピューター絡みの仕事が増えているこの世の中です。

さて、最近は人口知能の進化、もしくは進化させようという運動が盛んになってきたように思います。そのための基礎技術が進み、これを使った応用的なソフトウェアも一般化してきました。例えばAlexaやGoogle Echoのようなスマートスピーカー。Aiboのようなクラウドとつながるデジタルペット。Webサービスでもりんなのようなチャットポッドも有名です。Googleは自動広告にAIの技術を使っていますし、今の所人間に対して何か不都合を与えていることは何一つないと思います。

今週はGoogle I/Oという、Googleのイベントがあったのですが、そこで物議をかました発表があったのをご存知でしょうか。

www.itmedia.co.jp

 米GoogleがGoogle I/O 2018で披露した、AIアシスタント「Googleアシスタント」がユーザーに代わって電話し、先方の人間と会話して予約などを実行する機能が物議を醸している。

 この機能は、同社の新しいAIシステム「Google Duplex」によるもので、まだ開発段階だとして紹介された。基調講演では、美容院の予約とレストランの予約の2つのデモが披露されたが、いずれも人間と区別のつかない自然な会話になっており、会場からは驚きの声が上がった。

 これについて、ノースカロライナ大学准教授でIT企業に批判的なツイートで知られるゼイネプ・ツーフェクシ氏は、Googleアシスタントは人間のふりをして電話をしただけでなく、相手をだますために「ふーむ」とか「ああ」とまで言ったとして「シリコンバレーの倫理は失われ、制御不能だ」とツイートした。

ついに、来る時が来たのかもしれないという予感がしました。

 

AIがAIと見分けがつかなくなったときに起こること

私もWebにて、あるサービスのサポートをチャットで受けた時に、大きな違和感を得たことがあります。話しているうちに、もしかしたらこれは機械か?、と疑わしくなってきたのです。もし機械(AI)なのであれば、私が投げかけた言葉に乗せたエモーション(感情)ってばかばかしくなりませんか?。ロボットに向けて一生懸命しゃべっている私って、マヌケに思えませんか?。人だと思って一生懸命話したのは、信頼関係を築くためでもあるのです。実は機械でした、これを後から言われたら、かなりムッとするのだなあという気づきがありました。

最近は電話調査でも、機械応答のケースがあります。はいもしもし、と出て見ると、「こちらは・・・です。自動抽出により世論調査をしております・・」みたいなことをしゃべりだすんですけど、「もしもし返せ!」って思います。何しろ、機械相手に喋らされるのって、屈辱的な何かが生まれます。

まだ、相手が機械とわかっていて、「へい、しり!」「おっけーぐーぐる!」とかって、まるで上司や飼い主のように呼びかけることから始める関係だから、まだ気持ちが穏やかなんだと思います。勝手にiPhoneが、「ねえ、◯◯!、メール来てるんだけど見ないの?」なんてしゃべり出したら、イラっとしますよね。主導権とるんじゃないと。

さてさて、このGoogle Duplexです。勝手に電話かけてレストランや診察の予約をAIがしてくれるそうですが。これ取り次いだ人は、機械だと気がついたらイラっとするし、気がつかないなら気がつかないで、イラっとしますよ。

このように、「AIがAIと見分けがつかなくなったとき」に大問題が起こると私は予想しています。これはシンギュラリティのような次元が高い話とは違います。今、VRが進化していてどんどん仮想現実が人間の現実に近づいていますよね。でもゴーグルをかぶらされているし音もヘッドフォンだし、人間は騙せない状況です。でも声ならば、先にたどり着いてしまうのではないでしょうか。AIなのか人なのか電話で相手がわからない状況です。そして遅れてVRがそこまで進化していくのでしょう。

何が大問題なのか。これまで、少し感情的な表現で「ムッとする」「屈辱的」「イラっとする」と表現してきましたが、人間の尊厳を傷つけるのです。犬や猫に真顔で相談できますか?。人間だからこそ、人は話をするのです。人間じゃないことで尊厳が傷つけられるのは理屈じゃなく感情です。

この大問題に向かって、人間が突き進んでいます。もちろん、良い使い方を事前に取り決めていれば悪い道具にはなりません。でも、例えば電話でオレオレ詐欺をする人は電話を悪いことに使っています。仮想通貨を熟知して盗み出す人もいました。テクノロジーに良いも悪いもなく、使う人がそれを決めるのです。そして、使う人次第で大きく悪い方向にぶれるとしたら、これは大問題です。

Google I/Oで、Google Duplexを披露したことで、問題が顕在化してしまったということになります。それはすごい技術かもしれませんが、これを使って人間にとって悪い未来も想起できてしまったということです。

 

どこかでモラルを作らなければいけない

原子力の例がわかりやすいです。テロリストが手に入れたら大変なことになる。わかりますよね。平和利用すれば原子力発電に活用できます。それぐらいAI自体よりAIが作り出すいろいろな道具が、モラルハザードが起こった瞬間に悪意を持って暴れ出します。人にAIと悟らせないAIを使って、人は何を起こせるのでしょう。善のイノベーションと、悪のイノベーションが同時に起こります。この悪の方を制御しないととんでもないことが起こると思います。

例えばどんな悪いことができるのか・・。っていろんなアイデアを思いついている人はもういるのではないでしょうか。むしろ洗い出して先回りしないといけません。AIの進化と同じくらい、モラルを作っていくことは大切なことだと思います。

クラウドエンジニアが誤解されている限りビジネスがはかどる

f:id:orangeitems:20180510115333j:plain

 

オシャレなクラウドエンジニアと、ITベンダーの温度差

外から見るとクラウドエンジニアってそう見えてるのね・・という記事を読みました。

tech.nikkeibp.co.jp

パブリッククラウドの導入が一段と進んでいる――。こう感じた出来事があった。クラウド導入を専業とするITベンダーに取材に行った際に、「スーツ姿で勤務することが増えている」という話を聞いたことだ。

 

結構本質は捉えているとは思います。クラウド専業と言っているのは、おそらくAWSを得意とするベンチャー企業を意味していて、下記のような特徴を持つと思います。

・私服でオシャレ
・リモートワークなど充実
・カフェのようなオフィス
・若い人が多い
・業務外で良く集まる
・会社の外の関係があり、飲み会が多い

はてなを見ていると、社内の記事がアップされ上記のような様子が表現されていることがありますね。

今日もこんな記事を見つけました。

docs.esa.io

私のイメージにぴったりです。

これをいいとか悪いとか言っているわけではなく、ユーザー側である日本企業にとってこれまでのITベンダーの在り方とは真逆だというのが日経 xTECHの記事ということになります。

 

考察

シリコンバレーのスタートアップが醸し出す文化が、日本のITベンチャーに伝染し、そして彼らがAWSをはじめとするパブリッククラウドを基盤として用いた。そんな流れで「クラウドエンジニアは何か苦手」というユーザー企業が多いのだと思います。

ベンチャーのマインドだととりあえずサービスをリリースすることが最優先で、そこからはPDCAを回し続けてどんどんバージョンアップさせるということが大事になります。ですので、Kubernetesなどのコンテナ技術でどんどんリリースすることもチャレンジしていますし、ダメなら元に戻せばいいじゃん、というノリです。

一方で、ユーザー企業は中期経営計画に基づいた投資計画を前提として、5年計画を基本とした予算を作成し、稟議書として経営に提案して初めて認められるのがITです。したがって、「とりあえずやってみればいいのに」とはならないのは当たり前と言えば当たりまえです。そもそも、内部統制自体がそのような仕組みでもあり、経営のガバナンスがないのに予算が柔軟に使われるようには決してなっていません。

内部統制の仕組みが、もっとアジャイルな柔軟なものになっていかなければいけないとは思いますが、日本のユーザー企業の場合はITに精通した人が経営につくことは少なくて、稟議持ってこいや!5年分の予算計画立てろや!となるのは致し方ないと思うところではあります。柔軟であるというのはすなわち、変化に応じて決断を早くしていくことになるのですが、これこそITに対して精通しているというのが最も重要です。アメリカではIT自体が基幹産業となっていることもあり経営がITをわかっているケースが多いので、このあたりは国の違いということで理解するべきだと思います。

だって、地球人すべてがITやってたら、ごはん食べていけないですからね。非ITだって立派な産業ですし、ガバナンスの方法は違ってしかるべきです。

ですから、クラウドエンジニアがシリコンバレーに触発されて、ユーザー企業から疎遠にされればされるほど、どうなるかというと、これまでのSIerで伝統的なIT、つまり記事中のスーツ姿で仕事してきた人がクラウドをやりだせば、ユーザー企業はこれまでどおりSIerのクラウドエンジニアを普通に採用すると思います。日本流のガバナンスにおいては、スーツとネクタイのドレスコードは組み込まれていて、所詮クールビズと言ってもネクタイを外すくらいです。そして、これまでのITの仕事文化の通り、お客様にクラウドを1つのツールとして最適化して提案すれば、それは単なる普通の仕事です。

記事のように、クラウドエンジニアは私服で~、という誤解が世間に出回っているうちは、スーツでお客様にお邪魔するだけでポイントになるので、楽な話だと思います。だって、スーツ着て落ち着いた対応をするってのは、ITの知識全然関係ありませんからね。

ちなみに、オンプレだと99.999%の可用性、パブリッククラウドだと99.99%だという記載が記事中にあるのですが、実態はそんなことありません。オンプレでもいろいろ起きますよ・・。むしろオンプレこそ問題を抱えている場合が多いです。パブリッククラウドは少なくとも大規模なインフラを構えている時点で、いろいろな悩みが解決している点も多いです。一方、パブリッククラウドが健全であることが前提ですが、ちゃんと設計すればクラウドでもきっちり動きます。逆にオンプレでも、ダメダメ設計すれば99.999%なんて夢の数字です。このあたりはユーザー企業でも理解が進んでいるところだと思います。

また、障害時の対応だって、クラウドによってはクラウドベンダーも巻き込んで全力対応します。一言でクラウドと言っても結局はデータセンターで物理サーバーの上で動いているわけであって、パブリッククラウドだからユーザーと対話しないというのも、5年前くらいの認識かなと思います。特に企業向けのクラウド基盤においてはユーザー企業との会話が密接に行われています。AWSもエンタープライズサポートに入ればかなり綿密にサポートしてくれます。またAWSを担いだパートナーも、同じように全力対応するでしょう。

ということで、多分に「ユーザー企業が苦手とするクラウドを専業とするベンチャー」はどんどんSIerが買収していくと思います。で知らないうちにスーツを着る部門が中にできると思いますよ。日本ってそういう国ですから。ユーザー企業が歩み寄るんじゃなくて、SIerが会社を買ってユーザー企業に合わせて作り替えると思います。もういろいろなクラウド専業ベンダーがSIerにいくつも買収されているではありませんか。

ということで、クラウドエンジニアの現場から個人的な感想でした。

 

SHOWROOMと石原さとみと。ニコニコ生放送とオワコンと。

f:id:orangeitems:20180508174915j:plain

 

対照的な2つのニュース

一日のうちにこの2つのニュースを並べられるとは皮肉としか言えません。

 

bunshun.jp

女優の石原さとみ(31)が、IT企業「SHOWROOM」の代表取締役社長・前田裕二氏(30)とゴールデンウィーク直前に2人で沖縄県を旅行していたことがわかった。

 

diamond.jp

かつては日本のライブ配信サービス業界を席巻した「ニコニコ生放送」。しかし、近年は衰退の一途をたどっている。人気放送主(生主)たちは、他社サービスへ続々と流出し、業界は戦国時代を迎えているのだ。

 

SHOWROOMとは?

このSHOWROOMというサービスは今日まで全く知らなかったのですが、事前にニコニコ生放送が衰退しているという記事があって予備知識がありました。

形勢不利なニコ生に対して、ライブ配信業界は、「YouTube Live」「ツイキャス」「LINE LIVE」「FRESH!」「ふわっち」「SHOWROOM」「OPENREC.tv」などが勢いを増しており、

しっかり、ニコ生の競合として書かれていましたね。

で、せっかくなのでSHOWROOMのことを調べてみました。

 

ホームページ

showroom.co.jp

 

会社概要

社名:
SHOWROOM株式会社

所在地:
〒150-0001 東京都渋谷区神宮前6-19-20 第15荒井ビル2F

設立年月日:
2015年8月3日

従業員:
88名(2018年4月末時点)

事業内容:
ライブ動画ストリーミングプラットフォーム「SHOWROOM」の運営、番組制作等

 

沿革

以下、Wikipediaより転載します。

2013年11月25日 - 株式会社ディー・エヌ・エーの事業としてPC(ブラウザ)版サービス開始
2013年12月20日 - Android版アプリ サービス開始
2014年1月14日 - iOS版アプリ サービス開始
2014年6月10日 - 番組視聴ボーナスとして無料ギフトアイテム獲得機能の追加
2014年9月13日 - 無料会員登録した全てのユーザーが配信可能となる
2014年10月1日 - アマチュア専用ギフトアイテムと有料ギフトの1ユーザー10分で10万ゴールドまでの利用制限追加
2015年1月9日 - 専用の公式配信ソフト『SHOWROOM Producer』無料リリース
2015年2月9日 - 動画上部に表示される最大25文字のテロップ機能追加
2015年4月1日 - iOS用公式配信ソフト『SHOWROOM Producer』の公開・サポートを終了
2015年5月18日 - 無料ギフトアイテムの獲得数制限追加
2015年5月 - 一部公式コンテンツ(横浜DeNAベイスターズ公式戦 生中継など)の視聴有料化(予定)
2015年8月3日 - 株式会社ディー・エヌ・エーの会社分割によりSHOWROOM株式会社を設立し、当日から当サービスの運営を承継[6]

なるほど、DeNAから分割した会社だったんですね。

 

サービス内容

WEB版は以下です。また、アプリ(iOS/Android)も出ています。

www.showroom-live.com

芸能人の生放送がたくさんありますし、投げ銭の機能もあったり、ユーザーも生放送できたりと、かなり充実してますね。

今回のニュースで相当PVが伸びるのではないでしょうか。

 

ニコ生は厳しいね

私は、今日の今日までSHOWROOM知らなかったわけですが、こりゃあ勝てないですね。今一つ三上洋さんのコメントがピンと来なかったのですが、サービスとしての出来が一目瞭然です。

ニコ生は進化を遂げないと先行きが厳しいとありますが、というよりは、一から作り直したほうが早いような気がします。必要な機能を実装することより、不要な機能・無駄な機能と整合性を取る方がよっぽど大変なように見えます。

一方は社長が石原さとみさんと沖縄旅行、一方はオワコン記事と、かなり明暗が分かれることとなったわけですが、ニコニコ動画古参としては巻き返してほしいものだと思っています(とはいえSHOWROOMはちょっと研究してみよう、コンテンツがすごい)。

まだまだ知らないことたくさんあるなと思った次第です。

どこかのIT業界のような話「テスラの多重下請解消」

f:id:orangeitems:20180508151416j:plain

 

あのテスラで多重請負??

IT業界の偽装請負による多重請負構造は散々問題にされてきました。日本独自の問題なのかな?と思っていたら、なんとアメリカ、しかも最先端のテック企業であるテスラで問題になっているというニュースがありました。

 

gigazine.net

「生産ラインで作業を担当しているスタッフの中に下請け業者が非常に多く含まれ、さらに下請けから孫請け、という複雑な契約によって派遣されているスタッフが存在しているという事実を知って失望した」という旨が記されていました。

マスク氏は、何層にもおよぶ下請け業者の構造を「ロシアのマトリョーシカのよう」と表現しており、いくつもの業者による手数料の「中抜き」が行われることでコストが跳ね上がっていることを問題視。さらに、それらの業者の多くが事前に決められた契約額ではなく、実動時間ベースの支払いを受けていることも問題点として挙げています。

 

過去、対策は各社で行われた

私も、多重請負が当然だった企業を離れて数年経つので2018年現在どうなっているのかは正確にわかりませんが、度々SES契約を隠れ蓑に多重請負が横行しているのをインターネットで目にします。

大手SIerなどは、2009年あたりに大規模な対策をした記事があります。

tech.nikkeibp.co.jp

コンピュータメーカーや大手SIerなどによる、再々委託禁止の動きはごく当たり前のものになってきた。

この記事でも「2次まで」はOKで、3次請けは禁止のところが多くなってきたという記事です。全く認めないということでも無さそうですしそこまでやると人が集めにくいということもあるのでしょう。また、実態に基づいて請負やSESではなくきちんと派遣で受け入れ、多重は一切禁止するというのが王道だとあります。確かにその通りだと思います。

ただ業界は大手SIerばかりではないので、未だにルールが無かったり形骸化していたりする現場も残っていると思います。特にデスマーチ状態で、とにかく人を入れないとという現場はモラルハザードしがちです。

 

テスラの実態

さて、ロシアのマトリョーシカ、とはよく言ったものですね。記事には、多重請負のデメリットがとても生々しくかかれています。

・いくつもの業者による手数料の「中抜き」が行われることでコストが跳ね上がっている
・業者の多くが事前に決められた契約額ではなく、実動時間ベースの支払いを受けている
・下請け業者の数はもはやコントロールできない
・契約労働者のパフォーマンスは、非常に優れた労働者から酔っぱらいよりもひどい者まで幅がある

ユーザーには75万で売られているのに多重請負で自分の手取りは20万いかない、なんていう「中抜き」問題ってよく語られていますよね。しかも契約には上限/下限労働時間が設けられていて、上回った/下回った場合は時間精算することになっていることが多いです。したがって、「実働時間ベース」の支払いになり生産性が低くて労働時間が長い場合に単金が上がってしまいます。ひどい会社だと実働時間で精算し、自社の勤務表は定時で上がったようにして、ちょろまかす会社もあるかもしれません。そして、多重下請を許すといろんな会社の人が現場にいることになりコントロールできない状態となります。日本の場合は一次下請けが子請け孫請けをコントロールすることになってますが、うまいこと行かない現場も存在するでしょう。そして、大規模な現場であれば統制が取れなくなり、現場に来たものの全く成果の出せない未経験者に近い人までいる始末です。

・・と、私の記憶にある現場も似たような場所があったので、アメリカのテスラなんていう世界でも有名な企業でもそんなことが起こってるのかと軽くショックを覚えた次第です。

 

あと、この記事の最後の部分とか特に目も当てられない・・。

・下請け業者の状況を統制する人物が不在であるために、無秩序な状況に陥っている
・派遣される労働者は「fleas(ノミ)」と呼ばれている
・雇われた電気技師は工業的または工場オートメーションに関する経験を持っていない
・設備の稼働プランや労働者への作業指示がまったく示されない

ああー、もはやIT業界あるある。一次請けの社員が打ち合わせばっかりで、仕事の指示がないとか。外注のことを害虫と言う冗談があるとか。未経験者なのに有識者としてアサインされるとか。席はあるけど仕事がないとか・・。

 

まとめ

うーん。結局、多重請負構造にて起こる悪影響は、日本や業界に限ったものではなく万国共通だということになりますね。こういった悪い商習慣に巻き込まれないよう、労働者側もきちんと勉強することが必要だと思います。自分がどのような契約で働きどのようなお金の流れで給料を頂いているか関心を持つことが重要だと思います。

 

 

OpenJDK11のLTS(長期サポート)実現をOracleが支援する方向で調整

f:id:orangeitems:20180506193901p:plain

 

概要

Oracle社のJavaプラットフォーム部門による製品管理ブログにて、「Java SEリリース間隔の修正とFAQ」という文書を、2018/5/3に製品管理シニアディレクター、ドナルド・スミスさんがアップしました。

Update and FAQ on the Java SE Release Cadence | Oracle Java Platform Group, Product Management Blog

Javaのサポートポリシー変更については、日本のみならず世界において大変話題になっており、ある程度の火消しを狙った文書と思われます。特に、OpenJDKのLTS(Long Term Support、長期サポート)についての記述がありますので強調して紹介しておきます。結論から言うと、OpenJDK11のLTS化に大きな望みをつなぐ記載となっています。

 

日本語翻訳(原文:Update and FAQ on the Java SE Release Cadence)

※本文は個人的に翻訳したものです。正確な情報は原文をご確認ください。誤訳部分があれば随時更新します。

 

2018年5月3日(木曜日)
Java SEリリースケイデンス(間隔)に関するアップデートとよくある質問
投稿者:Donald Smith | Sr.製品管理ディレクター

Java SE 9の作業が2017年の早い段階で終了したため、一部のOpenJDKコミュニティの貢献者は、新しい機能をよりタイムリーに反映させるために、Java SEプラットフォームとJDKをより早いペースで進化させる方法の検討を始めました。 JCPワーキンググループが設立され、Java Community Processが変化に対応する方法を検討しました。主な貢献者の間でのさらなる議論の後、計画が提案され、並行して、Oracleは商用Java SE製品の計画を発表しました [1]。

その後、OpenJDKコミュニティは、Oracleのリーダーシップのもとに、Java SE 9、Java SE 10、Java SE 11のアーリーアクセスビルド、また、調整されスケジュールされた複数のセキュリティアップデートを提供しています。OpenJDK 脆弱性グループが結成されました。 Java SE 10で小さな新しい言語機能が追加されたことは、新しいリリースケイデンス(間隔)が、実装だけでなくJCPの仕様作業でも機能することを示しています。

言い換えれば、新しいケイデンス(間隔)は、私たちが長年にわたって慣れ親しんできた用語やプロセスに新しい語彙や意味を導入します。簡単に理解できる新機能の予測できるリリーススケジュールのメリットは、明確に、エコシステムの中の最も大きいプロジェクトのいくつかへの努力と同じ価値を持ちます。この傾向は、Java SEエコシステムの他の部分でも発生しています。たとえば、Eclipseは、年次「リリーストレイン」があり、Wildflyは四半期ごとのリリースモデルに移行しています。

このブログのエントリーは、この数ヶ月間に尋ねられた共通の質問のいくつかに対処します。

 

Q1:確実に誰もが6ヶ月ごとのメジャーリリースを採用するとは想像できませんよね?

それ以上の「メジャーリリース」はありません。それは今やレガシーな言葉です。代わりに、「機能リリース」の安定した流れがあります。これは、バージョン管理上の新しい取り組みを除いて過去にいくつのリリースが行われたことと一致しています。例えば、Java 8は2014年3月にリリースされました。機能リリースである8u20は、ほぼ半年後の8月にリリースされました。 次の機能リリースである8u40はその6ヶ月後にリリースされました。

したがって、以前と同様に、6か月ごとに「機能リリース」の取り込みを期待しています。

Java 9→10→11は8→8u20→8u40の方が、7→8→9よりも近いのです。はじめのうちは3年ごとのメジャーリリースに慣れているため、その大きな変化がもたらす巨大な影響を精神的に持つことで、恐怖感が生まれるでしょう。6ヶ月のリズムはそうではありません。FAQの後半で、これについてのより具体的な証拠を提供します。

 

Q2:新しいリリースが基本的に6ヶ月の寿命である場合、毎回メジャーリリース番号をカウントアップするのはなぜですか?なぜそれを9u20、9u40などと呼んでいないのですか?

いくつかのJCPプロセスを合理化することで、「メジャーリリース」のために何年も待たずに、新しいクラスライブラリ、JVM、ローカル変数型推論などの言語機能をわずか6ヶ月で導入することが可能になりました。 2年ごとに仕様が大きく変更されるため、導入の準備が整い次第、より実用的に安定した流れで導入することができます。

 

Q3:仕様の変更は危険に思えます。更新によりツールのエコシステムが阻害されるのではないでしょうか。

いくつかのツールは8→9に移行するのに苦労していますが、その移行を行った人がほぼ一晩で9→10になることができます。

Java 10がリリースされたとき、主要な IDE はすべて、数日で新しいローカル変数型推論機能を含むJava 10をサポートしていました。GradleやLuceneのような人気のあるプロジェクトは、すぐに正式なサポートを追加しました。UbuntuやSUSE Linux Enterprise Serverなどの有名なLinuxディストリビューションでは、最新のOpenJDKをプラットフォーム上のデフォルトのJRE / JDKにするために積極的に調整されています。 Elasticsearchは、新機能の恩恵を受けるために、できるだけ早くLTSリリースと非LTSリリースの両方と互換性があることを計画しています。これらは、他のプロジェクトや製品が6ヶ月のリズムに追いついている例のほんの一部です。

この新しいケイデンス(間隔)は、ツールベンダーにとってより管理しやすく、予測可能にします。さらに、将来の開発者は、OpenJDK Project Valhallaの最小値型や、OpenJDK Project ZGCのZ Garbage Collectorなどの新しい機能を、使い慣れたオープンソースライセンスで利用可能なアーリーアクセスビルドを使って研究することができます。

 

Q4:新しいバージョン「X + 1」がわずか6ヶ月間先にあるのに、バージョンXにアップデートする目的は何ですか?

最新のOracle JDKビルドとOracleのOpenJDKビルドは、開発者によって毎月何百万回もダウンロードされます。Java 9の最新リリースは、Java 7およびJava 8よりもはるかに高速にダウンロードされています。たとえば、この文書の時点でのJDK 10のダウンロード数は、JDK 8の更新版数を5倍上回ります。

新しいリリースケイデンスの強力な理解は印象的です。一般的なIDEや他のツールベンダーがJava 10のサポートを迅速に採用して利用できるようになることは非常に奨励されています。

 

Q5:私はまだ確信できていません。Java 9を採用するのはチャレンジです。そのため、10や11もそうなると思います。

多くのJava SE開発者とユーザーは、新しい「メジャーバージョン」を採用する前にいくつかのアップデートを歴史的に待っていました。これは、「メジャー」リリースに数多くの主要な仕様変更機能が含まれていても、このケースは6ヶ月のリリースで進行しています。これは、Java SE 9以降のケースではありません。

たとえば、Java SE 9のリリースでは、Java SE 8の上に約19,000のソースコードの変更が組み込まれていました.Java 9とJava 10の間では2,700通りの変更しかありませんでした。Java 8とJava 8u40の変更とほぼ同じです。したがって、Java SE 9はJava SE 8と比較して「メジャー」なアップグレードですが、Java SE 10はJava SE 9のシンプルな機能更新版です。

 

Q6:X + 1リリースの移行がスムーズになることを、どのように確信できますか?どのくらいの時間がかかるのですか?

アーリーアクセスビルドは、Oracle独自のOpenJDKビルドを含めて、以前よりダウンロードして試すことは簡単です。OracleのOpenJDK アーリーアクセスビルドをビルド・テスト・システムで使用することを開発者に推奨します。そのため、問題が早期に発見される可能性があります。

機能リリースの最終更新と次の機能リリースのセキュリティ更新プログラムの間には3ヶ月があります。この間に移行することを強くお勧めします。新機能リリースと次回の予定されているセキュリティ更新では約1ヶ月が経過しています。たとえば、Java 9.0.4は2018年1月に、Java 10.0.0は2018年3月に、10.0.1は2018年4月にリリースされました。Java 10.0.1リリース以降、Java 9.0.4またはJava 10.0.0の使用はお勧めしません。ただし、JDK 10のアーリーアクセスビルドは、10.0.1アップデートリリースの6ヶ月以上前、2017年11月から定期的に公開されています。

これは、フィーチャーリリースとそれに続くセキュリティーアップデートの間に4〜6週間あった過去のリリースと一致しています。たとえば、2015年3月初旬に8u40がリリースされました。予定されていたセキュリティアップデート8u45が2015年4月14日にリリースされました。(注:原文では2014とありますが2015の誤りだと思います。)。

 

Q7:わかりましたが、私は新しい機能を望んでいません。私は本番環境のシステムを持っており、安定性、パフォーマンス、およびセキュリティの更新のみを望んでいます。私は何をしますか?

Oracleでは、2018年9月のJava SE 11以降の「長期サポート」(LTS)リリースとして、3年ごとにリリースを指定する予定です。Java SE 9 のリリースはJava 10のリリースで終了しました。 Java 10はJava 11のリリースで同様に動作しますが、Java 11は少なくとも8年間はOracleの商用サポートを受ける予定です。

Java 6とJava 7(そして2019年にはJava 8と思われる)でほぼ10年の間に起こったように、OracleがOpenJDKの特定のリリースシリーズにソースコードの変更を寄付しなくなった後は、顧客のニーズに集中することができます。OpenJDKコミュニティの他の有資格者は、リリースシリーズの継続的なメンテナンスを進める可能性があります。彼らはOpenJDKコミュニティ標準に従って、選択した限り、Oracleやその他の人々がまだ維持している後のリリースから関連する変更をバックポート(修正)します。例えば、JDK 6の場合、Sunは2008年にプロジェクトを確立し、Oracleは2013年までこれを維持し続けました。その後、他のメンテナナンス担当は、後のリリースからの更新をバックポートすることでプロジェクトの作業を続けました。

Oracleは、JDKアップデート・プロジェクト内で確立されたプロセスを提供するとともに、新しいメンテナンス担当が新しい役割を果たし、少なくとも脆弱性グループであることを保証するために、OpenJDKコミュニティの移行をサポートしています。(注:この文が最も重要です。)

 

Q8:Java SE 8では何が起こっていますか?

Java SE 8は、従来のバージョン管理とリリースのケイデンス(間隔)モデルの終わりです。Java 9は新しい始まりでした。

Oracle JDKの場合、Java 8はJava 7およびJava 6とまったく同じ移行プロセスを実行していますが、例外はあります。まず、新しいリリース・モデルに慣れるために、Oracle JDKのパブリック・アップデートを2019年に商用生産用に、少なくとも2020年末にデスクトップ用に拡張しました。2つ目は、Java 6 - > 7およびJava 7 - 8の場合と同様に、Oracle JDKをOracleのOpenJDKビルドと互換性を持たせるための取り組みを発表しました。あなたがまだそれをしていないならば、我々は10に移動し、新しいリリーストレインに乗ることを提案するでしょう。最後に、Javaクライアント(アプレットとWeb Startを含む)のロードマップに関する詳細情報を掲載しました。

OpenJDKのフロントでは、Oracle は 2019年1月までJDK 8 Updatesプロジェクトを継続してリードし、貢献する予定です。その前に、新しいメンテナの要請が行われます(詳細は前のQを参照してください) 。

 

Q9:私はOracleの顧客ですが、どのように影響を受けますか?

Java SEの依存関係を持つOracle製品内でJava SEを使用する場合は、対象となります。このMy Oracle Supportノートで詳細を確認してください。

2018年5月4日編集 質問に番号を追加し、Q8のJavaアプレットとWeb Startのロードマップへの参照を追加しました。

 

脚注:

[1] - ; Oracleがバイナリとビルドのために発表した計画のためのtldr - (a)Oracle JDKの以前にクローズされたすべてのソース・ビットをOpenJDKに移動する(b)GPLv2 + CPEの下でOpenJDKバイナリを公開する、(c) Oracle JDKとOpenJDKのバイナリが交換可能なようなスムーズな移行

 

補足

Oracle自身が、Q7において、OpenJDKは、Oracle JDKのバックポートつまり修正点の修正を移行しサポートし続けるように支援することを明言しているように読めます。

確実にOpenJDKのコミュニティーが正式に発表したわけではないので速報ベースとはなりますが、Oracleの公式ブログの中でこの発言があったことは、Java関係者としてもまずは安心できるニュースではないでしょうか。

 

Kubernetesに対するインフラエンジニアの付き合い方

f:id:orangeitems:20180506094356j:plain

 

ニュースの絶えないKubernetes

Kubernetesが日本でどういうふうに読まれるかが定まっていないのに、どんどん市場は成長していっていると思います。関連のニュースは絶えませんし、だからと言って、まだ会社の現場で使われる状況にはなっていません。例えばVMwareに関してはたくさんの会社のサーバーで使われていますし、LinuxはCentOSやRedhat Linuxとして当たり前のように本番サーバーで動いています。今後、Kubernetesをどのように本番に迎え入れるか議論が深まっていくと思います。それこそインフラエンジニアの出番です。

一方で、AWSやAzure、Google Cloudなど、メジャーなクラウドプラットフォームでは利用可能になっていっています。やもすれば、Kubernetesはパブリッククラウドで利用するソフトウェアとの誤解が広まってしまいそうです。これまでは手元(オンプレミス)でテストしてからパブリッククラウドへと利用が広まっていくのが常道でしたが、今回は順番が逆のように思われます。

 

今のKubernetesを評価する

私は今のKubernetesを「車のエンジン」と捉えています。

車のエンジンだけでは動きません。シャーシにエンジンを搭載し、タイヤとホイールとドライブシャフトとハンドルと椅子と・・いろいろくっ付けて車になります。今のKubernetesは動かすためにはいろいろ作業が必要です。つまり、車を利用するためには、車を組み立てる技術が必要です。また、車ができた後もどのように車が動くかをちゃんと理解しないと、使いこなせないレベルです。

これでは使いにくいため、組み立てたもの、つまり「車」を売っているベンダーもいます。IBMはIBM Cloud privateというパッケージを出しています。RedhatはOpen Shiftというパッケージを。VMwareは子会社のPivotalからPivotal Container Servicesというパッケージをリリースしています。

一方で、そもそもレンタカーのようにサービスとして車を利用する形式が進んでいます。AWSだとAmazon EKS、AzureだとAzure ACS、GoogleではKubernetes Engineなど。これはもう車は貸出を受ければ誰でも使えるようになっています。

皆がレンタカーとしてしか車を使わないかというと、そんなことは絶対なくて、やはり所有して使いたいという欲求は無くならないので、どこかでKubernetes構築はインフラエンジニアの必修業務になると思います。もちろん、この業務ならレンタカーだねということもあるでしょう。このあたりの適材適所を考えていくのはインフラエンジニアの未来も変わらないミッションです。

 

Kubernetesの今の問題

今のKubernetesの問題は車の操作が難しいことです。知識が無くても何と無く車が使えるようになれば、もっと普及していくでしょう。今までの数々のテクノロジーも、「車のエンジン」レベルまで急激に成長し、しかし車になれずだんだんしぼんでいったケースもたくさんあります。私をはじめ数々の「本物になれなかったテクノロジー」を見てきているベテラン勢はKubernetesがその領域を超えるか注視している最中にあると思います。

具体的な例としては、OpenStackやCloud Foundaryが挙げられます。一冊ぐらいは本を読んだものですが、利用はかなり限定的になっています。もちろん一部のパブリッククラウドで使われているのは知っていますが、企業の現場においてVMwareやLinuxほどは使われていないのが現状です。MySQLやPostgreSQL、apache HTTP Serverや、Zabbixなどもよく触りますが、これらも本物です。本物に関しては仕事にどんどん入ってきますので勉強が必要です。来ないものは見極めて「勉強しない」というのも一つの生産性の上げ方です。

Linuxは「本物」になったわけですが、本物になる過程は非常に時間がかかりました。当初Linuxは単なるカーネルソフトウェアでした。まだ「車のエンジン」です。これに様々なソフトウェアを組み合わせて様々なディストリビューションが作成されました。これが「車」です。今や、RedhatにしてもCentOSにしても、Suseにしても、基礎的な知識だけで簡単にインストールし使い始められるようになりました。これは初めからそうだったわけでは決してありません。初めのうちのLinuxは、ドライバの組み込み一つにしても知識がないとできませんでした。

 

今、どうするべきか

Kubernetesに対する各ベンダーの投資はかなりもので、どんどん成長しているのは間違いありません。ただこの先にいけるかどうかは誰も読めません。いつもここまでは来るのですが。例えばHadoopも限定的な利用に止まっているようですし。

今のところKubernetesについては「先進的なものを使っていることで、ブランド価値を上げる」くらいの位置であり、「車がないと生きていけないよね」までは来ていません。そんな時代が来てから勉強しても決して遅くはないです。ただ第一人者にはなれないのでピンと来た人は研究を始めた方がいいと思います。

この業界に20年いるとわかるのですが、新しい技術の大部分が出て来ては消えて生き、その中の一部のソフトウェアが本物になります。本物になったソフトウェアは相当に使いやすく、最後はワンクリックでインストールが完了します。GUIも用意され、もはやマニュアルが無くても一通り使える代物になります。実はそこから勉強するのが最も楽です。ただ、本物になる前から研究していて動作原理を語ることができる人が、業界のリーダーとなります。業界関係者が全員リーダーになる必要はないですし、いろいろな本物を楽に(生産性高く)身につけてディストリビューターに徹するのはこれはこれで賢いやり方だと思います。どちらがいいということもなく、バランス良く振る舞えるかどうかが評価されるインフラエンジニアの要です。

Kubernetesが結局クーベルネティスなのかクーバーネイティスなのかクーベルネイティスなのかよくわからないんですが、Linuxだってリナックスに固まったのも時間がかかりました。固まり始めたら本物になる予兆かもしれませんね。

 

ツイッターのインフラ基盤がGoogle Cloudに移行、距離が近づく両社を考える

f:id:orangeitems:20180505012410j:plain

 

ツイッターのインフラ基盤がGoogle Cloudに移行

昨日の全ユーザーへのパスワード変更依頼の記事を見て以来、パラグ・アグラワル(Parag Agrawal)最高技術責任者(CTO)のブログは注目していましたが、また大きな話が発表されました。

Twitterのインフラ基盤をGoogle Cloudに移行するというニュースです。

blog.twitter.com

 

Google Cloudとの新しいコラボレーション

パラグ アグラワル

2018年5月3日(木曜日)

毎日、人々はTwitterに来て、世界で何が起きているのかを知り、話します。毎日数億個のツイートが送信されているため、インフラストラクチャとデータプラットフォームを拡張することが不可欠です。

私たちが過去述べたように、Hadoopのコンピュート・システムは、当社のデータプラットフォームの中核であり、そしてTwitterは世界最大の複数の大型Hadoopクラスタを実行しています。実際には、Hadoopファイルシステムは数万台のサーバーに300PB以上のデータを格納しています。ここ数年、私たちは、サービスのニーズの高まりに対応するために、プラットフォームとインフラストラクチャのニーズを評価しています。

今日、私たちはGoogle Cloudと協力して、コールドデータストレージとフレキシブルに実行中のHadoopクラスタをGoogle Cloud Platformに移行することを発表しました。これにより、データプラットフォームを使用しているエンジニアリングチームの経験と生産性を向上させることができます。

 

「Twitterのエンジニアリング戦略と、Google Cloudが世界規模で提供するプラットフォームとサービスの要求を満たすための強力な連携があります。Google Cloud Platformのデータソリューションと信頼できるインフラストラクチャは、プラットフォームに必要な技術的な柔軟性と一貫性をTwitterに提供し、チームとの継続的な技術協力を期待しています。」

ブライアンスティーブンス
Google Cloud CTO


この移行が完了すると、より高速な容量のプロビジョニングが可能になります。

・柔軟性の向上。
・ツールとサービスの広範なエコシステムへのアクセス。
・セキュリティの改善。
・ディザスタリカバリ機能の強化

また、アーキテクチャ上、このクラスのHadoopワークロードのコンピューティングとストレージを分離することができます。これには、長期的なスケーリングと運用上のメリットが多数あります。

Google Cloudとの新しいコラボレーションは、エンジニアリングチームだけでなく、Twitterの全員にとって何を意味するのだろうか、非常に興奮しています。

 

徐々に近づいている両社

Googleではツイッター検索はできませんよね。Yahoo!のリアルタイム検索で私はいつも検索しています。ところが、英語圏ではすでに2015年からGoogleで検索できるようになっているのはご存知でしょうか。

www.advertimes.com

グーグルとツイッターは(2016年5月)19日、Google検索でリアルタイムにTwitter投稿(ツイート)を表示させると発表した。スマートフォンなど携帯端末の、Googleアプリやブラウザで検索できるようになる。当面の対象言語は英語で、地域は米国に限る。両社は2009年~2011年にかけ、Google検索でツイートのリアルタイム検索を提供していたが、提携を解消していた。

 

過去、Googleがツイッターを買収するという話は本当にあったのです。

www.afpbb.com

米経済専門局CNBC(CNBC)は23日、米ツイッター(Twitter)が、米グーグル(Google)の親会社アルファベット(Alphabet)や米顧客情報管理(CRM)大手セールスフォース・ドットコム(Salesforce.com)などへの売却に向け動いていると報じた。

 

ところが買収話は立ち消えとなりました。これで窮地に陥ったかと思いきや、ツイッター社は黒字化をついに昨年果たし現在は経営状況が好転しています。

www.nikkei.com

米ツイッターが8日発表した2017年10~12月期決算は、最終利益が9107万ドル(約100億円)で上場後初の黒字となった。開発の先行投資で赤字が続いてきたが、コスト削減で利益が出る体質になった。実質的な収益性の目安である、売上高に対する償却前利益の比率は過去最高を更新した。

 

考察

そして、今回のインフラ基盤のGoogle Cloud化のニュース。黒字化といい基盤のGoogle化といい、今後、益々協力関係を深めていきそうな両社です。そもそも、2社は互いのビジネスにとって互恵的な関係を組みやすいです。最終的には買収の選択肢も再燃しそうです。

憶測とはなりますが、今後、Yahoo! Japanが提供しているツイッターのリアルタイム検索にしても、Googleが同様のサービスを始める可能性もあると思います。Yahoo! Japanとしてはそうなっては痛手でしょうね。人気のYahoo!のサービスの一つであるリアルタイム検索が、Googleでもできるようになるとそっちで済ませちゃうのかなと。上記記事にもありますが、2009年〜2011年ごろはGoogleでもツイッター検索できていたんですよねそういえば。

クラウドではたらくエンジニア、としてはなかなか大きいニュースでした。