Builderscon tokyo 2017に行ってきた

 · 9 min read

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

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

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

OSS 開発を仕事にする技術

（スライドが見つからない）

  • この分野への自分の経験値
    • Github に色々リポジトリ公開しているけど、大御所 OSS へのコミットはほんの数回
  • 前回の Builderscon で Kubernates の話してた人
  • 今回は Kubernates の話というより OSS の話
  • OSS プロジェクトの運営方法論の世界はかなり未開拓
  • 仕事にするとコミュニティ運営も発生するので、純粋な作業量は２倍になる
    • もし枯れてない 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 見たけどエンジニアの募集はなかったような

全体的に

  • いい刺激になった。色々やってみたい欲が湧いてきた
  • 去年よりも規模も幅も広くなった感じがした
  • 次回はトーク応募してみようと思った
Buildersconカンファレンス
© 2012-2022 Leko