SyntaxHighlighter

2015年12月31日木曜日

2015年の振り返り

2015年の振り返り。

今年は、ここ数年取り組んできたFWや、自動化(ソース、テスト)関連の取り組みの整備、発展、またstash(bitbucket)を使った開発フローを導入、普及するということが多かった一年でした。
反面、新しい技術に取り組む機会が少なかったのが残念ではあり、導入検証レベルでdockerにトライしている程度。

そういった意味では、よい効果が出たものを各方面に普及しつつ、また自身は新しいものを吸収していくということはやり方に工夫がいるなということを感じた一年でした。
ただ、チャレンジの年、普及の年と1、2年ごとに入れ替えがあるのはいいことかもしれません。(毎年チャレンジだけしてそれを普及しないというのも仕事としてはどうかなと思うので)

また、今年はそこそこの規模での案件の平行開発が活発で、gitのブランチ運用がかなりノウハウがたまった気がします。
それにともない、CIのジョブもうまくそれぞれの環境でテストできるように工夫が必要だったりで、難しい反面、ひとたび構築出来ると安定感が増すので、このあたりは文書化して残しておくのは重要かなと思いました。

反面、忙しさが増してしまい、勉強会の参加はうまく取り組めなかったと思います。

去年にも引き続き、大きめの勉強会は時間を確保したが、コミュニティ系の小規模なものはあまりいける余力がなかった。
また、大きめのものはブログに感想を書くようにしているが、小さめのものはtwitterでつぶやいて終わりという、振り返りがきちんとできていないものがいくつあった。

勉強会、行ってブログにまとめるまでが勉強会ということもあり、アウトプットをまとめることをしていかないといけないなと思います。


来年(2016年)

来年は、環境がいろいろ変わりそうなので、また少しチャレンジをしようと思っています。
今までやってきたものを下地にして、自分の地力が試されそうなので、一歩ずつ取り組んでいこうと思います。

2015年11月17日火曜日

JavaOne 2015 報告会に行ってきました。

JavaOne 2015 報告会に行ってきました。


JavaOne 2015 報告会 @ 東京
togetter JavaOne 2015 報告会 @ 東京 #j1jp

自分が聞いたセッション(リンクは公開された資料)

全体の話

JavaOne 2015に行った方々のJavaOneの雰囲気 + Javaの最新動向の話し。
最近の大きめのカンファレンスは、あまりコードの部分に触れることも少なくなり、少し寂しかったのですが、今回は、Javaの未来の話しということもあり、新しい機能と共にコード例がたくさんあり、わかりやすいものも多く、非常によかった。

報告会では来年JavaOne行ってみたい人アンケートがちょっと出て、手をあげなかったけど、後日、この報告会の話しを知り合いに話したら来年一緒に行ってもいいかもと言われてたので、気になるイベントに。
(もし行けても、個人で行くことになりそうなので、もう少しチケットがお手頃ならいいのになぁ。)

個々のセッションの話

Impressions of JavaOne & Java trends


JavaOne全体の雰囲気を伝えるセッション

気になったキーワードあたりは下記

  • 今回のJavaOneは大きなアップデートなし
    • ORACLEは予定通りに作業を進める会社
    • 成熟し、大人になったものと思えば良い
  • OracleはJavaとJavaコミュニティを重視している
    • EE8はコミュニティの声をきいて、どれを入れるかを決めている
    • (ベンダー主導でない)
  • JJUG CCC 2015が、11/28(土)にあるので来てね


技術トレンド

  • DevOps & Microservices
    • Javaそのものは重要視ではない(Javaは基盤)
  • そもそも「ソフトウェア開発」が重要ではない
    • プログラミングができるのが重要だった時代から、サービスを提供する時代になってきている
  • ITサービス運用が重要
  • カナリアリリース
    • ブルーグリーンデプロイメント
    • ルーター側で古いバージョン、新しいバージョンを平行稼働して新しい方に振り分けていく
    • 問題があったら古い方に戻す
  • ダークカナリアリリース
    • 開発者にしかみえないリリースを本番環境でテスト
    • マイクロサービスにすると、周辺サービスに依存するものが多くなるので、本番環境でやったほうがテストが効率的
    • (クックパッドも本番環境でユーザには見えない機能が使えるとかあったかも)
  • Chaos Monkey
    • ランダムサーバを落とすOSS
  • サービス品質の確保
    • 全体的なサービス品質を確保するために、部分的な品質劣化を許容
    • 不運なユーザは存在しうるが、サービスがダウンするような事態にはならない
    • エンタープライズ発想とは逆
    • Netfilixがいうレベルのダウンタイムなら許容できるエンタープライズもあるのではないか
このあたりは、鈴木さんのブログをみたほうがよいかも。

エンタープライズにおけるDevOpsとマイクロサービス - JavaOne2015レポート

(感想)
SeasarCon2015でもFault Injection Testingの話しがあったように、Netflixは障害が起こるのは当たり前の前提での設計、テストをしているのだと感じた。

また、ソフトウェアデザインについて、重要なポイントが変化してきているというのは確かに思っていたことではある。

  • 内部品質 -> デザインパターンとかで綺麗に作るか
  • 外部品質 -> JUnitなどの単体テストしやすさで作るか(DIなども)
  • 利用時品質 -> サービス継続を確保するためにどう作るか

という感じでデザイン(プログラムの設計)の仕方が変わってきている。
というか、あまりプログラムの細部が語られなくなってきたように思う。

語られない = 必要でないというのは違うと思っていて、

  • それを必要とする人間とそうでない人間・会社の棲み分けがより広がってるのではないか
  • スピーカーが大人になった(一部分をみるのではなく、全体を見る立場の人が多くなった)

のではないかと思っている。

Java SE Update


  • JDK9は、2016/09/22、来年のJavaOneに合わせてリリース予定
  • JDK9 = Project Jigsaw + それ以外


それ以外

  • jshell -> コンソール上でコードをかけるようになる
  • Java.Doc.Next -> javadoc周りのがいろいろ便利に
  • Cross compiling and the javac -release -> source,targetオプションを集約したもの
  • Milling Project Coin -> "_"の命名禁止(既存でかいてると影響がある)、内部的な変更
  • Deprecation and imports
  • Re-engineering javac -> ダイアモンドネストが多いとコンパイル時間が増えてたのが改善
  • 非互換がいくつかあるので注意(詳しくはスライド参照)


JAR Hellの課題

  • 紛失したライブラリはどれか
  • コンフリクトはどこで発生したか
  • 内部APIを安全に変更できるか

-> JARの抽象化機構が必要 -> Moduleが必要

Module

  • モジュールの依存関係を定義する仕組み
  • 公開したくないパッケージをexports指定で公開しないようにできる
  • publicの範囲も指定可能に
  • API開発をしている人にはメリットがある
    • 意図しない内部的なクラスを使われなくなる

jlink

  • jlinkでオリジナルjavaイメージを作れる感じ
  • (java_20151113、java_new、java_bakとかできそうな。。)


(感想)
Moduleの公開したくないパッケージを指定できるというのは、FWなりAPIを作っている人からすると、嬉しいと思う。

Moduleはいろいろ記述が柔軟になりそうな反面、複雑なものが出てきそうで、JAR HellからModule Hellとかならないのだろうかとは懸念する。

また、今は実質、GradleやMavenなどのビルドツールを使っていると思うが、それらを置き換えてまで使いたいかというのを仕組みを理解している人に聞いてみたい気もする。

Gradleなどが、Module形式でかけたり、Moduleが定義されていると、そこらへんを読み取って依存を追加してくれたりするなど、Moduleとうまく共存できれば広がるんだろうけど、そのあたりはどうなんだろうか。

Java SE 講演から


Eclipse Collectionsの話し。

  • GS Collectionsから、Eclipse Collectionsへの移行途中
  • Spring ReactorにもGS Collectionsの依存が入っている
  • GS Collectionsでは社内的な事情でGitHubに公開していたものの、PRは受け取れなかった
    • コミュニティのコントリビュートを受けれるようにしたかった
  • Eclipse Collectionsへ。(パッケージもcom.gs -> org.eclipseへ変わる)

その後は、GS Collectionsでもあったようなお話。

(感想)
今回はまだスライド公開されていないようですが、下記あたりのものがJavaOne用にブラッシュアップされた感じ。

GS Collections and Java 8 Lambdas
GS CollectionsとJava 8 実用的で流暢なAPIで楽しい開発を!

Eclipse Collectionsになったはいいけど、GitHubでプルリクとか受ける形になるのかな?
(聞き逃したので不明ですが、Eclipse Foundation傘下なので、GitHubでやるのではないっぽい?)

GS Collectionsは、Java Day Tokyoで知っていたけど、追加の情報もあって勉強になった。

特に、throwingというラッパーメソッドのようなものを利用することで、lambda内のtry-catchがすっきり書けるのはとてもいいと思った。

Java ME & IoT


  • SE embedded -> なくなった(セッションがひとつもなかった)
    • Open JDKにモバイル相当のプロジェクトができた。(さくらばさん情報)
  • jigsawでやってくれということか変更点がほとんどない

他にJavaOneのマイナー?な点にスポットをあてたネタがいろいろなセッション。

Java EE Update(前半)


Servlet4.0
  • HTTP/2対応
  • HTTP/2 サーバプッシュ
    • htmlの要求がきたら、関連するjs,png,cssなどをプッシュする
    • 1リクエスト、1レスポンスの原則が崩れる
    • PushBuilderというものが検討されている
JAX-RS2.1

  • 非同期クライアントAPIの改善
    • Jerseyには既に実装がある
    • RxJava、Java8のCompletableFuture対応
      • 今は書き方が複雑
      • FinalResult、PartialResultアノテーションで順序制御(提案中)
  • ノンブロッキングI/O
    • 本当に必要かも含めて、まだまだ検討中
JMS2.1

  • JMS2.0の微妙な部分の改善
  • MessageListenerの実装が不要に
    • Messageインターフェースのキャスト不要(TextMessageなど)
  • キュー指定がJNDIで指定可能に


JPA2.2

  • Java SE8対応
  • Date and Time API
  • Repeatableアノテーション
  • スクロール機能の標準化。(hibernateであったもの)


WildFly Swarm

  • Spring Boot風のJavaEE(まだ実験的)
  • Spring Bootとの背景の違い
    • Spring Boot -> Springを利用するときにpom.xmlが複雑化していたのを整理
    • WildFly Swarm -> Java EEをフルセットで使うのではなく、利用する機能だけ一式jarにまとめて軽量化
  • ・・・とあるが、WildFly Swarmで実行可能なjarができるが、今はちょっとした依存の組み合わせでも、100MB近いjarになる
    • 不要な依存がまだ入っているのではないか
  • 機能の追加はpom.xmlに追加したい機能を依存に追加する(Spring Bootと同じような感じ)
  • デフォルト設定(Spring BootだとAuto Configuration)もある
    • 何が設定できるかは xxxFraction.javaのソースを読む(しかない?)

SwarmによるJava EEの分解を見て
  • Java EEもマイナーアップデートが欲しい
  • Springは着実に進化、JavaEEは標準化に時間がかかる
  • 仕様確定後、実装サーバが1年越しにようやく出てくる


(感想)
JAX-RSの非同期部分はあまり知らなかったので、コード実例がありながらだったので、とても参考になった。

最後にも言われていたが、EE全体は、どうしてもSpringに比べてスピード感が遅い印象で、洗練された新しい機能を早く使いたい場合は、(対応されていれば)Springの方がいいと思う。

とはいえ、標準化がされないと独自仕様が乱立するだけなので、Java EEとSpringでいい仕様をフィードバックしあって成長していって欲しい。(Springで実質デファクトとなったものを整備してEE側にも取り込まれて、Spring側がそれらの標準仕様に対応していくという流れはいくつもあるので)

Java EE Update(後半)


MVC1.0

  • JSF(component)ではなく、なぜMVC(action)か
    • 見通しのよさ、簡便さ
    • RESTとの親和性
  • フロントエンドの流行廃り
    • WONTA(Write Once, Never Touch Again)
    • どうせそのうち書き直すのだから、保守性は考慮にいれないの意味
    • 定着したサーバサイド技術として、MVCへのニーズ
  • ValidationはBeanValidationベース
  • ビュー(JSPなど)は仕様レベルではJSP、Facelet
    • 参照実装(Ozark)にはextensionとしていくつかある
    • (自分がよく使っているThymeleafもあるよう)
  • スコープ
    • デフォルトスコープは、request
    • リダイレクトスコープ(RedirectScoped)も可能
  • FWでなく、API
  • 「ポストStruts」ではない
  • Validationとそれに関連する画面遷移の周りのをもうちょっと使い込まないと実用にはつらい

(他に紹介されてた、JSON-P 1.1、JSON-Bはあまり使うことはなさそうなので省略)

JavaOneの感想

  • すでに日本のブログや勉強会で紹介されてたネタもちょくちょくあった
  • 世界とレベル差はあんまりない


(感想)
MVC1.0はSpring MVCっぽいものがEEとして出るというような感じで、Spring MVC自体はかなり気に入っているので、そういったものが標準として出てくるのはよいと思った。
また、(参照実装ではあるが)Thymeleafも対応されそうな気配があるので、ウオッチしたいなと思う。

JSONは、Jascksonがデファクトなような気がするので、今更感が強いような。
(加えて、JSON以外のデータフォーマットが数年後に出るかもしれないのに、低レベルAPI部分に凝り過ぎなような気もする)

Speaker Panel: How to be a speaker at JavaOne?

パネルセッション

スピーカ

  • 谷本さん(アクロクエストテクノロジー)
  • 伊藤さん(ゴールドマン・サックス)
  • てらださん(Microsoft)


Q1. JavaOneで講演してどう?

  • 谷本さん
    • スピーカーで言っても飛行機代出ない
    • コミュニティに貢献できるのはうれしい
    • うかるテーマで出したので、話したいものではないのでモチベーションが上げにくかった
    • 他の人がやらないようなもの、事例系がうかりやすい
  • 伊藤さん
    • JavaOne初めて行ったので、テンションあがった
    • Call for Paper(CfP)と別経路で話すことになったので、講演が決まったのは9月入ってからで急だった
    • Eclipse Foundationで話す枠があったので、提供してもらった
  • てらださん
    • Oracleをやめたけど、JavaOneに行きたかった
    • 自腹でいこうと思っていたが、JavaOneのチケットは15万くらいする
    • Oracle時代に世界中のコミュニティの人と知り合いだったので、受かった人にお願いした
    • 人のセッションに乗っかって、話させてもらった(2、3人スピーカー登録できるので)
    • 当初は、話すまでは予定になかったが、発表の10分前に話すことに決まった
    • 日本用の動画の画面、文字でプレゼンで、英語でしゃべって説明した
    • 意外と日本語の画面でもわかってくれる人もいた
    • (今回でなく)1回目の発表はめちゃくちゃ緊張した
      • JavaOneはセッションがおもしろくないと人がどんどん抜けていくのを知ってたから
    • 今年は、10分前に決まったものもあって、気楽にやれた
    • 日本でイベントでしゃべってるような感じできた
  • 谷本さん
    • (今回でなく)1回目、自分の英語が伝わってるか不安だった
    • 多少、文法が間違ってても準備してたら話しをきいてくれる
    • 今回は準備不足で結構、途中退席されてしまった
  • てらださん
    • 日本とちょっとプレゼンの仕方が違う
    • 日本では最初つまらなくても、後半でおもしろかったら印象に残る
    • アメリカはおもしろくなかったら退席されるので、最初にこういうポイントは聞いてほしいということを伝えておくのがよいと思う


Q2. 今後、どんな人にJavaOneで講演してもらいたいか

  • 谷本さん
    • JJUGなどで話している人がいい
    • GC、JVMなどのコアな部分ではそうではないが、それ以外だと日本人の発表が勝っている人もいる
    • 世界で活躍すると、コミュニティも盛り上がる
    • コミュニティに参加しているような人は積極的に参加してほしい
    • 子供がプレゼンというのもおもしろい(子供がやってみた系)
    • (話あいまい)子供でもプレゼンの訓練をしている私立とかあって、そこの子供はとてもうまいそう
  • てらださん
    • 今日ここにきている人は、JJUGでまず発表してみることをチャレンジしてほしい
    • うかりやすいのは、事例系
  • 伊藤さん
    • ツイート数は日本が一番多かったように思う
    • JJUGのコミュニティを紹介する系もよいかもしれない


Q3. JavaOneのスピーカーになるための極意

  • 谷本さん
    • 会社としてでる
    • 事例公開、lambda、jigsawといった単品のものは本家本元がいるので、ノウハウ、パフォーマンスチューニングとかのほうが通りやすいのではないかと思う
  • 伊藤さん
    • 英語については、テクノロジー系だと、用語が英語から来てるので、会話よりはプレゼンのほうが楽(準備もできるので)
  • てらださん
    • JavaOneは文化としてセッション中でも質問くるので、そこは大変
  • 谷本さん
    • プレゼンである程度書いていたら、乗り切れるかも
    • 質問はtwitterでと書いておいて。手を挙げても見ないふりをしたこともあった
  • 伊藤さん
    • チャンスがあったら手が伸ばせる人
    • 臆せず、やってみる人
  • 谷本さん
    • 今自分がやっている仕事が頑張ってれば、おもしろければ、それを話せば良い
    • 事例で、実際に使った痛みがないと相手に伝わらない
    • 大きい会社の事例と、小さい会社の事例だとちょっと違うので、表現の仕方は考える。なんかの箔をつけないといけない、大企業のお客様の事例として話すなど
  • てらださん
    • コンテンツを選んでる側は、コミュニティ参加、講演経験なども考慮されている
  • さくらばさん(場外から)
    • CfPは、締め切りから審査されるわけではなく、随時審査されるので締め切り間際に出すと、落ちる確率が高くなるかも
  • 谷本さん
    • アブストラクトは英語、過去資料、発表動画とかは日本語で出してもOKだった
    • 動画は発表している雰囲気を見ているのではないか
  • てらださん
    • CfPはいくつも出せる、(サムライズムの)ゆうすけさんは4本出していた


Q4. スピーカーになるとこんなメリットがあるか?

  • 伊藤さん
    • スピーカータグをもらえる
  • 谷本さん
    • チケットがタダ
    • 転職しやすくなるかも(会社の顔になるのでなかなか辞めれないが)
  • てらださん
    • スピーカー用の部屋が使える


Q5. 来年JavaOneのスピーカーになりたいと思っている人へ

  • 谷本さん
    • 日本の人はすごい人がいる
    • コミュニティを盛り上げていくことが重要
    • 自分がやることをきっちりやっていれば、世界という舞台もレベルも、実はそんなに遠くない
    • 仕事頑張れ、エンジニアが一番成長するのは普段の仕事であり、その延長線上でアウトプットすることでよりよい形になっていくと思う
    • 周りのも発展させていくし、自分も成長するのでよいと思う
    • Javaも若い人がまた入ってきて平均年齢さがってきてるので、また盛り上げていきたい


(感想)
それぞれ思い思いに話されていたが、3人とも共通するのは、伊藤さんがいっていた、チャンスがあったら手が伸ばせる人、臆せず、やってみる人というスタンスの人だなと思った。
手を伸ばさないと、変わらない、けど今やってる自分の仕事、自分がやることをきっちりやっているという積み重ねも大事。

その行動力、(結果を伴う)信頼性で周りの人ともフィードバックループをつなげていくということかな、自分も少しでも見習っていこう。


2015年9月30日水曜日

Seasar Conference 2015に行ってきました。

Seasar Conference 2015に行ってきました。


Seasar Conference 2015 公式サイト
compass

自分が聞いたセッション
  • 【S405】基調講演(当日急遽テーマ変更)
  • 【S401】SIの終焉3
  • 【S405】俺は守りに入らない、これが今の俺だ(当日急遽時間変更)
  • 【S405】Seasarからクラウドへ、振り返って知る技術的に重要だった観点のある個人的観測について
  • 【S405】SmartNewsとBacklogの作り方
  • 【S405】SIは本当に終わったのか?

なお、今回は、聞いたセッションの資料は公開されてないよう。
(半分はパネルディスカッション形式だったから。他の方のは公開されているセッションもある。)

全体の話


ひがさんのセッションで、いきなりのテーマ変更としてSeasar2関連の裏話へ。

Seasar2は、1年後(2016/09/26)へサポート打ち切りへ。
運営側や、他の発表者も知らない感じが見受けられ、本当にサプライズだったのかも。

実際のメンテナやMLでのサポートでずっと貢献されていた、小林さんへの感謝の拍手があったのが感慨深い。

今後については、ひがさんのブログで発表されている通りですが、
  • GitHub自体は残すのか(ソースは公開されたままなのか)
  • mavenリポジトリはどうなるのか?(mavenのセントラルリポジトリにはない)
  • 公式サイト自体(レファレンスは日本語が多いので伝えやすい)
といったあたりが気になるところです。

Seasar2から卒業しよう
続Seasar2から卒業しよう

また、セッションまたいだ印象としては、今回は選んだセッションの都合なのかそうでないのか、Seasar Conferenceと銘打っているのに、Seasar2のコードは一つもみなかった。(その他関係がないプログラムコードは、1セッションでしか結局見なかった)

発表者の現在の仕事の立ち位置、ロールなどもあるのでしょうが、
個々のプログラムやFWを紹介というよりも、プロダクトやビジネスをどう推進していくかのような立ち位置、内容の印象を多く受けました。

個々のセッションの話


【S405】基調講演(当日急遽テーマ変更)


事前公開とはテーマが変わって、ひがさんのSeasar2裏話

Not 同窓会 But 卒業式。
  • Seasar2は、1年後(2016/09/26)へサポート打ち切りへ
  • Seasar2をずっとやってると新しい技術(分野?)を追えない
  • 環境に慣れた、満足感が出てきたら次のフェーズに向かったほうがいい

ひがさんの仕事の関連もあるので、一部オフレコの話もあったり、裏話は聞けてよかった。
他、公開可能なものは、ほぼブログで話されているようなので、割愛。

聞いてて考えたことは、Seasar2しかり、某FWなり、10年以上企業(がバックにあるプロダクト)がちゃんとサポートしてくれるFWってのはないと思っていかないとなと感じた。
ただ、もう機能追加がないので、自分なり、自社のメンバーがある程度ソースを理解して、拡張できるレベルのメンバーがいれば自分たちのプロダクトの開発においては問題ないかなと思います。
セキュリティ面で何か合った場合は、自分たちでパッチをあてるなどはしていかなければなりませんが。

そういった意味では、Springは今でも活発に開発が続けられているので、すばらしいなと思います。

【S401】SIの終焉3


栗原さんの仕事の軌跡を振り返りつつ、SIの話。

後でSIの終焉、SIの終焉2の記事を見ると、おおむね一緒のことを話されていたのかなと思います。

後半、時間切れで本題にあまり入れなかったようで、もうちょっと聞きたかったな思いました。
最近、プラットフォームを押さえにいくのがトレンドなのか、Uber、Airbnbといったものだけでなく、アメリカで過ごした身近なところでのインフラの寡占化の例を照会してもらったのは興味深かったです。

SIの終焉
SIの終焉2

SIの終焉という記事を記載したとき

  • Google Appsをセールスしていたのでクラウド推しの背景もあった
  • (クラウド推しについては)今振り返ってみても、時代が進んでもあまり変わっていない
  • 当時は、金融の案件がストップ、違約金もらってまで止まったケースがある -> SIをやってると翌月からいきなり仕事があるわけではない
  • 変遷
    • 2010 -> フルスクラッチ
    • 2011 - 2013 -> SIレス(パッケージ)
    • 2014 - マネージドサービスにアウトソーシング(Google Apps etc)
  • SIは、SES、SaaSにわかれて移行してきている


SIの終焉2のとき

  • 1をふりかえって、予想はあたったけど、うまくできなかったことがある
  • Google Apps -> 低収益性でもうからない
  • ドルで仕入れて、円で売る。為替、当時80円、今は120円でお客さんのコストもアップしてしまう
  • クラウドリセールするのは軒のみあまりいいことはない。ちまいSIしかなかった(ライセンスをうるためのオプションのようなもの)
  • 人のものを売っていてももうからない -> 自分たちのものを作ったほうがいい
  • Google Appsのまわりのアドオンのようなものを売っていた
  • SIは期間がぶれる可能性がある
  • サービスだと、前払い(年額)なので収益予測がしやすい、雇用に対する計画がしやすい
  • SoftBank、Googleと組んでiPhone + Google Appsで寡占的な法人市場を形成できてたが、具体的にアプリが何もなかった
  • アプリを作る話を提案したら、Glabioという会社を作ることになった。


SIの終焉3(本題)

  • アメリカ 地獄編
  • シリコンバレーの紹介
    • 舞浜の先に埼玉が来た感じ、田舎。
    • それなのに家賃が超高い。年収は日本円に直すと、新卒1000万。もらってる人は5000万?
    • 各家庭共働きが当たり前
  • インフラの画一化
    • 民間企業がゴミを回収している、サービスを選べない
    • 犯罪、車上荒らしにあったが、警察は現場に来ない、日常茶飯事なので、emailを聞かれ、被害届サイトがあって自分で入力し、それをもって保険請求などをする
    • これらは民間企業がやっている、被害届けはCoplogicという会社(SaaS)
  • アメリカでは、インフラを徹底的に効率化している
    • インターネット化
    • クレジットで払うのは当たり前で、日本と逆に現金で払えないお店がある
  • それらの民間企業はどういったビジネスをしているのか
    • Coplogic -> へぼい(見た目の話)CSSなんてないようなもの
    • UBER(配車サービス)、日本はタクシー免許持ってる人?だが、普通の車とおじさんが来る
    • Airbnb(ワードが出ただけ)
  • 日本になく、アメリカにあるもの
    • 積極さ
  • なんとかなりそうなものが出たら爆走。下手したら一塁に出てないのに、二塁に行こうとするくらいの勢い

企業内の構造について

  • 世の中の会社、役員は、社員を使い、評価、教育を行う
  • トップでなく、リーダーでないとダメ、信頼してもらわないとダメ
  • 活かすコミュニケーションとは、自分はやりたがらないこと、できないこと、思いつかないことを担当する(やりたがらないことをやって信頼を獲得する)

このあたりでセッションの時間切れ。
(LTに持ち越したようですが、都合によりLTは参加しなかったので聞けず)

【S405】俺は守りに入らない、これが今の俺だ


ガチDJになるようです。
次のセッションにも関連しますが、おかしいくらい熱中という意味では、冗談ではなく真剣なんだろうなと思います。

個人としては、Seasar2全盛期のように、プログラマー、エンジニア全体を活性化するような活動をしてもらえると励みになりますが、今は目指す方向が変わったということかな。

  • ひがさん学校に通ってて、ガチのDJになろうとしている
  • sxsw(サウスバイサウスウェスト)に向けて動いている
  • プログラミングをやめるつもりはない。どちらかというと得意な方と思っている
  • 今は、プロジェクトにとって一番いい関わり形でやっていきたい。(のでプログラミングは関わっていない)
  • 今日は映像などはないが、自分にとって完成した思ったら公開はする、2ヶ月以内
  • (その他専門的な話 & オフレコ寄りの話)

【S405】Seasarからクラウドへ、振り返って知る技術的に重要だった観点のある個人的観測について


DIxAOPというSeasar2に関係のある話しをうまく、クラウドのプロダクトに絡めて、興味深く聞けた。
特に、Fault Injection Testingの考え方は非常に面白いなと思ったし、考え方+ライブラリレベルで実現しようとしている企業もあるということで、参考になった。

前段
  • 今は某A社のプリセールスのアーキテクト
  • (Seasar2と関連して話しているのか)DIxAOP考え方の重要性は増している
  • Webの受け口はシンプルにしてクライアント側の事情と切り離す、これらに関連している

前の会社からの転職について
  • 2011 -> クラウドの世界へ踏み出す
  • なぜ入ったか -> 必要なのは非連続的な成長と考えた
  • 前の会社では、ある程度自由にできる部分はあったが、階段でしか上がれない会社であった
  • 今の会社では、いろいろな会社、システムがみれた
    • スタートアップ、メディア、アダルトといった多岐に渡る、お客さんを見ている
    • 帯域、ストレージの使い方
    • 小売からみたITと、ITのそもそもの考え方の違い、そういったものを学びたかった
    • 全体を滞りなくまわすやりかた。そういったものが知れる会社

クラウドについて
  • 扱っている粒度が変わってきた -> FW、ライブラリからサービスへ
  • クラウドで重要な点
    • 大事なのは、IaaSより、Programmable Infrastructureかどうか
    • ダイナミックなインフラ
    • コンピュートとストレージの明確な分離
  • インフラのコモディティ化
  • 使える技術要素がよりスケールに主眼
    • 非同期、ノンブロッキング、スケールアウト、リアクティブプログラミング、一貫性の考慮
  • クラウド -> ユートピアは来ない。全然違うプラットフォームとして考えたほうがいい。
  • 運用面 -> 落ちても即座に復旧するシステム
    • 一元的に集中管理、絶えず、改善、デプロイメントからロールバックまで
    • システムが桁違いに大規模、細かいところはアプリ側で工夫したほうがよい
  • 全体最適が中心、個別最適ではない

DIxAOP
  • 大きなサービスを作る場合は重要
  • 疎結合にしないとスケールしない
  • クラウド、モダンソフトウェアにみる、DIxAOPの例
    • Presto
      • Facebookが開発している、Hadoop上でSQLを利用するエンジン
    • s3mper
      • Netflixが開発している、AWS S3上のデータ整合性ライブラリ
  • Fault Injection Testing
    • 障害を意図的に混入させテストする手法
    • クラウドのリソースはクラウドにあるので、テストがしにくい
    • 外部から状況をエミュレートしたり再現できたりする余地があることがシステムとっては大事
    • こういった箇所でもDIの考え方が利用されている

マイクロサービス
  • マイクロサービスは、サービスをパイプでつなぐみたいなもの
  • 依存関係をアーキテクチャのレベルでできるだけ解決
  • うまくやるには難しい、DevOps的な運用スタイルじゃないとそもそも無理
  • 考慮すべきこと
    • 認証と認可
    • スロットリング
    • サーキットブレイカー(まずいときに遮断)

最後のオンプレミス
  • クラウドは、新しいプラットフォームであり、最後のオンプレミス
  • 仮想化ベース -> EC2
  • コンテナベース -> Docker,ECS
  • イベントベース -> Lambda
  • The No Stack Startup

これからのクラウドに向けての考察
  • ダイナミックでプログラミング可能なインフラを使うには?
  • クラウドネイティブな開発手法・設計手法、徹底的に活用するものがない
    • クラウドネイティブアプリケーション
    • クラウドを活用するための言語・開発ツール
    • ローカルで開発じゃなくなりそうでは?
  • 運用方法、もっと手がぬけないのか
  • 自動化も作り込むまでが大変、全員ハンドメイド感

【S405】SmartNewsとBacklogの作り方


SmartNewsの浜本さん、ヌーラボの橋本さん、ひがさんのパネルディスカッション。
注釈がない限りは各プロダクトの方が話されていた内容。

浜本さんと橋本さんのアプローチの仕方が違っていているのに、根本にある考え方は意外と似通っていて、おもしろいなと思った。
バイアス(思い込み)、確かによくハマるので、自分の感覚だけを信じすぎるのではなく、客観的なもので判断というのは重要。

SmartNewsのパーソナライズの話し、パーソナライズをやめてみんなが興味があるものシフトしたのはなぜか?(浜本さん)

  • パーソナライズをやめたわけ
    • 当初は、TwitterのAPIを使っていて、ソーシャルグラフを取得して解析、個人の好みにあうものが表示される、というのをやっていた
    • パーソナライズの段階を0 - 10で判断できるようにしていたが、0でも以外と面白いものがあることに気付いた
    • パラメータチューニングするのが好き
    • 初期では、インテリジェントなものができないのでいろいろパラメータを試していた
    • 完全にオンにしていたものをオフにするということはなかなかやっていなかった
    • パーソナライズにやろうとしていろいろためしていたが、逆にパーソナライズしないほうが面白いこともあるとわかった
  • UIをわかりやすくするというのがあるが、余分な機能というのはどうやって削ぎ落としたか
    • 当時は朝刊、昼刊、夕刊などを選べるようにしていた
    • ユーザテストをやったときに、ユーザにみせると昼刊が夕方に表示されていて、なんで?と言われた
    • ユーザからみると、昼から、夕方に差し掛かるときにひるのニュースみても仕方がない
    • プッシュ通知としては残したが、ユーザから目に見える機能としては消した


Backlogについて(橋本さん)

プロダクトがうまれた背景

  • 東京の仕事を受注して、やりとりするさいに、メールでやりとりするのが大変だったので作った
  • 当時も他のツールはあったが、業務用すぎたので自分たちで明るいものを作ろうということになった
  • 自分たちにとっていい感じのものを作った

Backlogの転換点

  • 自社サービスとして出したのは大きな転換点
  • 業務チックでないものに整えてだした
  • そのころはクラウドというのもなく、小さい会社だったので、スラッシュドット?から叩かれた
  • 浜本さん:SmartNewsもリリース時に叩かれた
  • 浜本さん:ITメディアの人がジョインして、メディアの人とコミュニケーションを取ってくれてうまいこと鎮静化され
  • Backlogの炎上は、放置した
  • 結果的に(いいプロダクトだからか)ユーザは増えていった
  • ものが当たるときは賛成、反対派がぽんとわかれるのかなと思っている
  • ASP型ですぐにつかえるのがいいと評価されたものもある
  • ひがさん:ユーザテストについては?
  • あまりやってない、社内でけっこう使って実績があった
  • 機能などは社内にものをいう人が多い
  • 見た目はデザイナさんが、開発に参加してくれた
  • ひがさん:ISIDでもBacklogを使っている
  • ひがさん:Iデザイナーで開発者でない人ばかりのプロジェクトでも使ったりしていたが、そういうときに気軽に使えるのはよい

Backlogのコンセプト

  • とにかくすぐに始められることというのが、当時はアイデアを練ってかんがえてたのはあった
  • なので、ダウンロードはありえないよねというのはあったと思う
  • ひがさん:そういったプロダクトのコンセプトとしては当初からあったのか。
  • そう。プロダクトの作りにも関わってくる。
  • (マルチテナントな構成で提供できる作りになっているかということだと思われる)
  • ひがさん:方向性を変えるときでも、根本的な部分は変えてないというのはSmartNews、Backlogともに変わってないのかなと思った

SmartNewsのコンセプト

  • SmartNewsは、Smartモードというオフラインでも読めるNewsを提供している
  • 今は、Facebook、Appleなども提供している
  • ひがさん:機能を削るという話はでなかったのか
  • そこは削らなかった、当時は、地下鉄は電波が入らなかった
  • そういう環境でも快適にニュースを提供したいという信念を持っていて、そこは譲らなかった

SmartNewsのユーザテスト

  • 日本でも英会話カフェで外国人捕まえてやった
  • アメリカでもクレイグスリストで募集をかけるとユーザが集まってくれる

Backlogのユーザテスト

  • 最初にソフトウェアファーストでやったので厳密に狙ってたわけではない
  • 少しは目論見があったので、英語版も出していた
  • シンガポール、ニューヨーク、など現地スタッフがいる
  • ひがさん:細かいチューニングとかはやってるのか?
  • スタッフとして採用はしているので、そこでフィードバックはもらっているのはあるかもしれないが、やってますよとまでは言えない
  • 狙ってやってるかというわけではない

起業、新しいサービスをするためのアドバイス

浜本さん

  • 作ってる側の目と何の思い入れのないひとが見る目が全然違っていて、後から自分はなんでこんな思い込みをしているのかということがあった、今でもある
  • 確実にバイアスがかかっていて、それを解かないといけない
  • ユーザテスト、他のプロダクトとの比較などやっている
  • 街にいる人のスマホとかの使い方の観察など、なるべく自分の感覚でないものを取り入れる目を持つというのを心がけるのがいいと思う
  • SmartNewsとしてはプロダクト思考をめざしている
  • ユーザに届ける部分の届き方が少し違うだけで、大きく変わるが、そこをきちんと伝えられるエンジニアは貴重
(プロダクト = 触ることができるもの(自分たちで意思決定、開発者している部分?)という意味か)

橋本さん

  • おかしいくらいに夢中になっていること
    • 浜本さんのように、いきなりアプリを直接見せて感想を聞かせてもらうように熱中しているような人
  • 冷静な分析
  • すばやい判断

【S405】SIは本当に終わったのか?


こちらもパネルディスカッションで、某A社の大谷さんと、ヌーラボの橋本さん、ひがさんの話し。

失敗パターンは特に参考になりました、確かに思い当たる点がいくつかある。。
SI vs スタートアップは、どちらがいいという結論は(当然)出ず。

SIの前提が、今のSIの延長線上でどういう体制、進め方で開発していくかという感じで、SIがどう変化していくかという話しではなかったのは、話し手のロールゆえになのかなというのが気になった。

栗原さんのSIの終焉3でもSIの向かう先が少し提示されていたけど、見るレイヤーが違う感じで、あちらは、SIはSES 、SaaSに分かれていく話で、SIのビジネスのやり方自体の話しをされていたが、こちらはもう少し狭いスコープの話しだった。

プロダクトの失敗パターン

  • ひがさん:誰かからアイデアを持ちかけられたもの(他人事になりやすい)
    • 人から言われたことをいかにうまくいくようにするかに考えちゃうから
    • サービスが世の中に受け入れられるかどうかをスキップしているから
    • 他人事になっちゃいけない
    • 橋本さん:受託もそう、お客さんから言われた仕様をそのままうけると失敗する
  • 大谷さん:オーナーシップを持てないもの
    • スタートアップでも同じ、自分でオーナーシップを持てるかどうか
  • ひがさん:焼き直し(ガラケー->スマホ等)
  • 橋本さん:オリジナリティがないもの(社内用Twitter)
  • ひがさん:広めるための施策がないもの(ユーザの増やし方)


企画だけで当たるかどうかは絶対にわからない。
なので、ユーザテストなどで検証が必要。

SI or スタートアップ

  • ひがさん:大谷さんは、SI or スタートアップ?
  • 大谷さん:スタートアップとSIの違いは、技術というよりは、スパンが違う
    • 技術はコロコロ変えるものではないし、負債もそれなりに抱えてる
    • サイクル的に変えるチャンスはあるかもしれない
    • スタートアップでも古い技術ちょこちょこ置き換えながらやっているところもある
  • 橋本さん:受託は、おもしろかったものもある
  • ひがさん:受託やっていいなと思ったのは、ユーザのニーズが理解できるというのはよかったなと思う
    • 金融機関のローンシステムの裏など(どういう審査がされているかとかがわかる)
  • 橋本さん:受託のときは仕様書が降りてくるようなものは受けてなく、こっちが気持ちを持って作れるかというのがあった
    • ワガママなお客さんも好きでなく、お互いが会話できる関係性でないと断っていた
  • 大谷さん:(前の会社のとき)主体的に動ける人と一緒にできるかというのは大事だった
    • 保険のシステムのときも保険のおばちゃんと発注している人の意識差が違ったりしてた
  • ひがさん:SIとスタートアップの違い、結構違うというわけではなく、エンドユーザがどう使っているか、どう思っているかを見ながら開発できるのかというのが大事
  • 橋本さん:全体を見るのが大事
    • エンジニアとして注目してみると、受託だと事業計画を見せてもらわないエンジニアもいる
    • それをお互いでブラッシュアップしてから仕事をうけるというのもあった
    • お客さんもシステムをしょっちゅう作るわけではない、素人なので
    • が、受託では踏み込ませてくれないときもある
    • スタートアップだと事業計画はみやすいかも?
  • 大谷さん:スタートアップというわけでもなく、企業の企画の方も該当しそう
    • ITの中だけに閉じたとしても、できることが少ない
    • AWSに行って、外の人といろいろ話すようになったかなり変わったと思う
  • ひがさん:言われたものを言われたまま作るってのはうまくいかない
    • 顧客といい関係を築きながら進めるのがいいけど、それが難しい
  • 大谷さん:スタートアップだからというのはない
    • チーム、企業の規模が大きいほど、難しい
    • ユーザとダイレクトにインタラクションを持ちにくくなる
    • 実際に使う人と企画する人が分離しないように、チームの作り方を工夫するのが大事かなと思った
    • ダイレクトに使う人でない人が関わったら難しい
    • スタートアップでは小さい人数で回しているのがあるから、ダイレクトに接しやすいかなというのがある
  • 橋本さん:SEは、あまり仕事を頑張らないほうがいいと思う
    • 頑張っちゃってるせいで、体調を崩している人が多いように見受けられる
    • ハートフルな自分がでてくる
      • (お客さんの背景なども考慮するようになってくる?)
  • 橋本さん:スタートアップは広告戦略もあるので、それをそのまま信じるのは危険かなというものある
    • 失敗したときのスタートアップは影響がでかい
    • 受託は(契約によっては)受託金額という限度がある
  • ひがさん:どっちもいいところ、悪いところがある