SyntaxHighlighter

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は、あまり仕事を頑張らないほうがいいと思う
    • 頑張っちゃってるせいで、体調を崩している人が多いように見受けられる
    • ハートフルな自分がでてくる
      • (お客さんの背景なども考慮するようになってくる?)
  • 橋本さん:スタートアップは広告戦略もあるので、それをそのまま信じるのは危険かなというものある
    • 失敗したときのスタートアップは影響がでかい
    • 受託は(契約によっては)受託金額という限度がある
  • ひがさん:どっちもいいところ、悪いところがある