Builderscon tokyo 2017に行ってきた

こんにちは。
先日Builderscon 2017に参加してきたので、レポートを残します。

オンプレ、クラウドを組み合わせて作るビックデータ基盤 -データ基盤の選び方-

  • この分野への自分の経験値
    • TreasureData, BigQuery, AthenaなどのDWHや、re;dashやKibanaなどのBIツールをかじったことある程度
  • Mercari KAURUの中の人
    • 公式サイトの画像に"恋は雨上がりのように"が入ってて少しテンション上がった
  • クエリがテストできる環境の必要性を感じた
    • 重い分析クエリ投げて本番が固まるなんて事件が起きたことが過去にあった
  • (引用)DWHの検討軸の例
    • 容量、料金、コスパ
    • 事業計画に沿ってスケールできるか
    • データパイプラインが作りやすいか
    • 分析の用途にマッチするか
    • 運用がつらくないか
  • そもそも、データ分析に投資できるくらいの体力(利益)すらない小さな企業だと予算どりが辛そう

OSS開発を仕事にする技術

(スライドが見つからない)

  • この分野への自分の経験値
    • Githubに色々リポジトリ公開しているけど、大御所OSSへのコミットはほんの数回
  • 前回のBuildersconでKubernatesの話してた人
  • 今回はKubernatesの話というよりOSSの話
  • OSSプロジェクトの運営方法論の世界はかなり未開拓
  • 仕事にするとコミュニティ運営も発生するので、純粋な作業量は2倍になる
    • もし枯れてないOSSにドッグフーディングする時があれば工数は多めに見積もっておこう
    • だけど一人では実現できない練度のプロダクトになる
  • やろうと思ったこと
    • OSS使っててエンバグしたらすぐフィードバック(Issue)
    • 自分がよく使うOSSって何か考えてみる
    • Node.js
    • babel系統
    • webpack系統
    • fetch(github/fetch, bitinn/node-fetch)
    • React系統
    • React Native系統
    • commander
    • debug
    • mocha
    • lodash
    • sinon
    • etc
    • 洗い出してみると意外とありそう。バグに出くわしたこともあった。貢献できそう

マイクロチームでの高速な新規開発を支える開発・分析基盤

  • Gunosy LUCRAの中の人
    • このプロダクト知らなかった
  • 3ヶ月で3人でプロダクトをローンチさせた
    • ゴリ押しではなく、きちんと定時で帰って心身ともに健全に完遂
    • さらに施策を打つための分析基盤の構築まで行った
  • 無意識に発生している待ち時間はとことん削る
    • アプリのビルドやCIのビルド待ちの時間は削ろう
  • やる/やらの判断をしっかりする
    • プロダクトのコンセプトを検証する上で必要か?
    • 初期においてはAndroid対応は切った
    • お気に入り・フォローなども切った
  • ログはとにかくたくさんとる
    • タブのクリック、スワイプレベルのログまで取る
    • 通信頻度減らすためにログをbuffer/flushする仕組みが必要そう
  • 非エンジニアもSQL打って自分の欲しいデータを料理できる
    • 現職も全員とは言わずとも適正ありそうな人お呼びしてできる現職勉強会してみようかな
    • まず可視化できる環境の整備が先
  • 施策の効果計測をするのではなく、そもそもその施策をするべきか否かA/Bで数字が出るか否かでフィルタする
    • 出してから考えるのではなく、だす前にきっちり考える
    • その上で出したものはプロダクトにとってマイナスがない限り捨てない
  • 「データありきで考える」というマインドは面白そう
    • かなり組織毎の合う/合わないは別れるし、現職では難しそうと思う
    • 完全に染まりきれずとも定量的・定性的なデータをもとに判断軸を形成することは大事だと思う
  • 集まったメンツのおかげなのだろうか? そうではないと感じた
    • もちろん実力による要因は大きいとは思うけど、方法論の話だと感じた
  • 組織・ツールが成熟していることが必要だと感じた
    • まずはそういった分析ができるだけのログ収集、データ(ユーザ)量、可視化ツールを整えないと話にならない

静的解析とUIの自動生成を駆使してモバイルアプリの運用コストを大幅に下げた話

  • ソウゾウの中の人
  • 社内用バナー管理コンソールの話
  • プロダクト毎に分けるのではなく、マルチテナント型にしてプロダクト毎にGAEのnamespaceを切る
  • 非エンジニアだけで運用できる体制づくりだいじだと思う

Ionic 3+ではじめる次世代アプリ開発(HTMLでiPhoneアプリをつくろう!)

  • Ionic2→3の新機能とか開発環境周りの話とかを期待していたけど、ちょっと違った
  • Ionic触ったことなさそうな人らの反応はTwitter見てる限り良かったので、ポテンシャルはありそうなのかなと思った
  • 現状React Native触ってるけど、わざわざ乗り換えるだけの強みはないかな、と思った

polyglot になろう !!

  • 複数の言語のノウハウを集積して他の言語に活かせるエンジニアになろう! な話
  • C++のNVIイディオム知らなかった
    • けどこういう実装はしたことあるので言わんとしてることはわかった
  • もうちょいポンポンと例が出てきたら良かったと感じた

Factory Class

(スライドが見つからない)

  • キーボード作った人の話

The Evolution of PHP at Slack HQ

(スライドが見つからない)

  • Slackを支えるPHPの話
  • SlackがPHPなのはもともと知ってた
  • PHPはサーバが立ち上がりっぱな形式ではないので、メモリ管理はかなり雑でいいというのは同意
    • そこに精神すり減らすのはスタートアップがやるべきことではないという点にも激しく同意
    • その時いたメンツがPHP得意だったからSlackはPHPを選んだという背景もあるそう
  • 多言語へのスクラッチではなく、HHVMを選んだ
    • 素のPHPからでも段階的に始められるので事業リスクが少ない
    • やや事業サイドな感じはしたが、好きな温度感だし、そうじゃないとあれだけの事業にはなってないと感じる
    • あらためてリプレースなんてただの博打で、ポーカーで持ち札全部捨てるのと同じですわと感じた
  • 昔Slackの日本法人のHR見たけどエンジニアの募集はなかったような。

全体的に

  • いい刺激になった。色々やってみたい欲が湧いてきた
  • 去年よりも規模も幅も広くなった感じがした
  • 次回はトーク応募してみようと思った