U30に限定したエンジニアカンファレンス『Battle Conference U30』に参加してきましたレポート

WRITER: hori_ryota
このエントリーをはてなブックマークに追加

FRESH! でサーバサイドエンジニアをしております @hori_ryota です。

Battle Conference U30 というイベントが弊社運営で開催されるということで、一般参加者として行ってきましたレポです。

イベント概要

「Battle Conference U30」は、Under30 エンジニアによる Under30 エンジニアのための技術カンファレンスです。 Talk Battle やAtCoder社によるProgramming Battle (プロコン) といった企画を予定し、若手エンジニアが所属を超え、これまで様々な領域で培ってきた技術的知見の共有や参加者同士のコミュニケーションを促進するとともに、Under30エンジニア達が自身の技術、事業、キャリアにおける挑戦を発表する場と、技術力をより一層向上すべく互いに刺激を受け合うことができる場を提供いたします。また基調講演では、株式会社Gunosy新規事業開発室 執行役員 松本勇気氏に登壇いただくことが決定いたしました。 20代のエンジニアのみなさまぜひご参加くださいませ。

Battle Conference U30

ということで、若手（30歳未満）エンジニアに絞ったカンファレンスだそうです。

なお、当日のセッションの様子は FRESH! にて公開されておりますので、ぜひご覧ください！

会場

港区の TABLOID が会場でした。企業ブースが設置され、コーヒーも飲み放題でした。

トークバトル（セッション）の会場のお洒落感がすごかったです。

セッション

会場はA-1とA-2に分かれそれぞれ行われたので、拝見したものだけとなってしまいますが登壇内容を簡単にご紹介させていただきます。（私がサーバサイドのため、サーバサイド成分が高めです）

紹介と合わせて、手元で取ったメモも併記させていただきます。意訳になっているところが多いため、なにか誤りや補足したほうがよさそうな点がございましたらご連絡いただけますと幸いです。

開場挨拶

  • 株式会社サイバーエージェント 代表取締役社長 藤田 晋さん

開催経緯などについて。

基調講演「U30な僕らの生存戦略」

20代を代表するエンジニアである Gunosy の松本さんによる “エモい” お話でした。

Gunosy 立ち上げに携わった経験から、当時の思いや考えなどについて。

  • メインテーマ：自分の目的に合致した努力と成果、評価を
  • これまでにやってきたこと
    • エンジニア経験のない状態でいきなりCTO
      • 技術力がない状態で様々なプロダクトを作りながら全レイヤの技術に触れた
    • Gunosy にて
      • 立ち上げ当初は機械学習のエンジニアがほとんどだったので、機械学習以外のことをまるっと担当
      • 執行役員就任前後から社内の技術的な牽引を担うように
      • 現在は新規事業担当をやりつつ、必要なものを全て触るスタイル
      • いつの間にか全領域で牽引できる技術力になった
  • 目的地に対して最短のスタートラインから始める
    • エンジニアリングは常に車輪を生み続ける
      • 5年前のスタートラインはいまのスタートラインにならない
        • 昔なら低レイヤーから組まなければいけない（難しかった）ものがクラウドなどで初めから提供されている
        • 今は常に新しい車輪が生み出され続けているいい環境
        • 使えるなら使っちゃえ
        • おっさんの「コレも知らないの？」とか気にしない
        • 達成に近づいてから後で戻ればいい
    • どこを目指すのか意識する（長期の課題設定）
      • 自分が目指すものを長期なり短期なり明確化
      • 最終的にはどこで誰に評価されたいのかを自分の中で正しく持つ
      • 目的と評価軸の明確化
      • “課題は設定できた時点で7割解決している”
    • 考え方の例（技術Xのスペシャリストになりたい！）
      • （ スライドにて具体例が紹介されているため、 FRESH! もしくはスライドをご覧ください ）
  • “目的に対して最短距離を走り続け望む方向で評価されていこう”

具体的な考え方の指針、松本さんの場合の具体例をご紹介頂きましたので、ぜひ登壇資料をご覧いただければと思います。

Elastic searchを用いたPicmarryのフリーワード検索

Elasticsearchの基礎的な概念から、Picmarryにて採用した理由、工夫したポイントなどについてお話いただきました。

 

  • 3人で開発している
  • 女性ってふわっとサーチ（あいまい検索）が好きだよね！というところからフリーワード検索が必要に
  • 関連度が出せ、表記ゆれに対応できるようにElasticsearchを採用
  • 12月末に出したい！という要望で12月頭に勉強からスタート。無事リリース
  • 解析に関する問題、改善（カナ問題）
    • チンザンソウだとホテルチンザンソウがヒットしない
    • N-gram で改善
  • フィルターに関する問題、改善（県問題）
    • “県” が登録されてしまい、 “大分県” で検索すると別の県が出てくる
    • 品詞でフィルタリング
  • 所感
    • 解析、フィルターがカスタマイズしやすく便利
    • ラッパーも合って開発しやすい
    • 運用3ヶ月で大きな問題はなし

「開発支援という仕事」

 

  • 大事なことに集中してもらう
    • ユーザーに価値を届けるために本質的なことだけに集中する
    • ビルド時間の短縮
      • 高速なマシンを用意することでテスト、コンパイル時間が 1/3 に
      • お金で解決できるなら解決しよう（たかだか20万程度）
    • お金でテスターさんを集めて手作業でテストしてもらう
      • 切羽詰まるとやりがち
      • 精度に不安な面
      • 機械的にできるテストは自動化しよう
      • テスターさんには人間にしか再現できない複雑なテストに集中してもらおう
      • OpenSTFの導入でリモートからオフィスの検証端末に繋げられるように
    • その他、ディレクターやマーケティング担当者などのシャローワークを削減していく
      • 恐るべき人力スクレイピングの事例
        • Scrapyによるお手軽スクレイピングで解決
      • 会議室予約の事例
        • 全社標準の会議室予約システムがつらい
          • 会議室システムをスクレイピングしてアプリ化、Slack連携で解決
  • 変えられないものはあるけど、できる範囲で自分たちで工夫していこう
  • コストと時間はちりつも式に増えてリリース速度を加速していく
  • “ごみあるところに金はある”

様々な事例を紹介していただいて、特に人力スクレイピングについてはあるある！と思わず共感してしまいました。

AbemaTVでネイティブエンジニアからサーバーエンジニアに挑戦した話

元々 FRESH! で iOS エンジニアをしていたギアくんの登壇でした。

iOS エンジニアからサーバサイドエンジニアへと転向し、初めてのタスクをどう進めていったかの話。

 

  • 知識を広くしたくてサーバサイドに挑戦
  • 初めてのタスクはAbemaTVサーバのモニタリングを作成
  • AbemaTVのサーバリポジトリは35もあった（ネイティブの文化だと1リポジトリだよね）
  • プライベートでGCPなどAbemaTVで使用しているツール群を触るところから始めた
  • アーキテクチャ図の紹介
  • 収集データが多岐にわたる

転向した経験、という初々しい話が聞けるかと思いきやいきなりDBや技術の選定理由の具体的な話に入り、ギアくんのハイレベルさを改めて見せつけられて個人的にはとても楽しかったです。

サーバサイドを続けている人間として悔しさが募り、お尻に火がつく素敵な発表でした。

登壇資料にもありましたが、具体的な導入の話はブログにも書かれているのでぜひご覧ください。

障害に捨てるところなし

障害から学べることってたくさんあるよね、というお話。

一般的には失敗とされる障害をいかに糧にして上手く付き合っていくか、というお話で、技術だけでなく文化の問題も大事というところは強く共感いたしました。

Sukiyaki Project 〜高可用な自宅サーバを目指して〜

どうやって技術的挑戦していますか？という話

 

  • sukiyaki project
    • sukiyaki project
    • 学生時代のノリで「自分のやりたいことを」を好き勝手やる場を作った
    • 若手エンジニア4人
    • みんなの自宅NOCをつなげて日々インフラエンジニアとして成長している
  • やったこと
    • （ 技術的な詳細は登壇資料をご覧ください ）

圧倒的飯テロ。ガチ勢感が溢れる発表で、いい意味で置いてけぼりを喰らいました。いかにモチベーション高く挑戦していくかという暑さを感じ、とても刺激になりました。

最良の砂場を目指して-プライベート開発を支える技術-

プライベート開発を続けるための “エモい” お話

 

  • コツ
    • より良いプライベート開発はより良いミドルウェアから
      • どれだけ長期間やっても大規模な集団で開発しているコア機能には勝てない
    • 最初長く続けることを目標に、あとあと高品質なものを短時間で作るのを目標に
      • 短期間でガッとつくると燃焼しきってしまう
      • 考える時間もちゃんとつくる
    • タスク管理を業務レベルで行う
      • 見積りやタスク管理の経験になる
      • 整理することでスピードアップ、集中につながる
    • 他人も持っている課題にアプローチする
      • スターが付くとモチベーションにもなる
    • それなりに大きい会で発表することを前提に
      • 甘さを捨てる
      • 承認欲求を刺激
    • ネット上では多くの人の目に触れるように
      • 「他者から観測可能な自分の価値を高める」
      • 海外を視野に
  • 自分はどうトライしてどういう結果が出せたか
    • 自分用のニュースサイト
      • Rails, React
      • ミドルウェアやクローラーサーバはGoで実装
      • etc.
    • 中規模以上の環境（業務レベル）を想定したクオリティで開発環境を用意
    • コアな機能は保守的に、周辺機能は前衛的に
    • その他の周辺物
  • プライベート開発で出会う危険な場面
    • 最初から大規模の設計をしようとする
      • 必要になったタイミングで修正にしない限り、無駄な設計のせいで書き直しコストがかさむ
    • メインのフレームワークで個性を出そうとする
    • 個性を出そうとして車輪の再発明をしがちだが、後でむなしくなる
      • コアは堅実に、周辺は前衛的に
    • なんでも新規
      • ほどほどに
  • プライベート開発で得られたもの
    • 職
    • Issueを通じた意見やエラー報告
    • 設計への関心、学習機会
    • 新規性のある技術を採用する場面の見極め方
    • 規模に比例して徐々に現場レベルの知見が得られる
  • 現在やっていること
    • Goでクローラーサーバをつくるなど

内容が盛り沢山だったのでメモを取り切れていないです。ぜひ登壇資料をご覧ください。

疎かになってしまいがちなプライベート開発の話で耳が痛かったですが、モチベーションを刺激される発表でした。「他者から観測可能な自分の価値を高める」というフレーズにはTwitter上でも多くの共感を得ている様子が見られました。

車輪の再発明をやってみた

虚無感と絶望との戦い

 

“お昼を食べて戻ってきたら会議室に呼ばれて、「3日後に新規サービスリリースするからサーバ用意して」と言われた。” に象徴される絶望や虚無感との戦いアレコレとどう戦ってきたかというお話でした。

なかなかのトンデモな戦いで会場も笑いに溢れ、非常に面白かったです。具体的なお話が多いので、内容についてはぜひ登壇資料をご覧ください。

オープンソースの最大の長所とは

rm -rf / なTシャツが印象的でした。

 

  • OSSと私
    • OSSの印象
      • GitHubのイメージが強い
      • 優秀なデベロッパーが担当
      • ユーザだけでなく、何か貢献したい
      • 最近はenterpriseでもOSSをよく活用
    • 最初の壁
      • 壁
        • バカな質問をしたら恥ずかしい
        • 技術力不足の痛感
      • 乗り越えた方法
        • 無理矢理にでも自分を参加させていくのが大事
      • その後
        • 気持ちよく手伝えるようになった
        • StackOverflowやGitterで質問に応えられる
        • ドキュメントへの貢献
        • バグ報告など
    • 学べたこと
      • 実用的なベストプラクティス
      • Solution-drivenではなく、issue-driven
  • “Community is a feature” コミュニティは機能のうち

まずは飛び込んで見る、関わってみることが大事、ということで、勝手に高くなりがちな最初のハードルに対して後押しをしてくれる発表でした。

つたない英語でもプルリクしてみると意外と何とかなったりした経験は私にもあるので、とても共感しました。

自分の足を撃たない技術

バグを再発させないためにLintをみんなで整えていこう、というお話でした。

 

  • 私が普段挑戦していることと皆さんにも挑戦していただきたいこと
    • 自分の足を撃たない技術
      • 特に自分の足を2度撃たない技術
      • バグの再発防止
    • ありがちな解決策
      • テストを書く
        • 保証されるのはテスト箇所だけ
      • 記事を書く
        • 広く知らせることができるのはメリット
        • しかし、忘れて再発させてしまいがち
    • Lintしましょう
      • テストと違い、全てのコードに適用可能
      • ブログを書くのと違って人間が忘れても機械が検査してくれる
    • Lintを作りましょう
    • Ruby以外の言語でもLintの選択肢はたくさんある

「Rubocopでは私が日本一だと思います」「Twitterで私に聞けばなんでも答えます」「っていうか私が書いているんですけど」など、エンジニアの鏡とも言える発言にしびれました。

新規バグを踏むのは意味のある失敗になりますが、二度踏みはもったいないので積極的に自動チェック化していきたいですね。

大量ログを扱うElasticsearchクラスタの最適構成を求めて

巨大なElasticsearchの貴重な運用知見をお話いただきました。

 

  • 何が悪かったか
    • ノード同士が密結合
      • 各ノードですべてのタスクをやろうとすると1台の負荷が他に波及してしまう
      • ノード1台についき1タスクのみを担当するよう構成を変更
    • 監視システムが貧弱
      • メモリ使用率すら取れない、SSHしないとログが見れない、参考にならない大量のアラート
      • Stackdriverを導入
      • 「監視』の前に「観察」
        • 何が大事かを見極める
  • 上記2つはチューニングの前段階。これらができてやっとちゃんとしたチューニングに取り掛かれる。
    • 実際のチューニング例
      • （ 登壇資料をご覧ください ）
  • インフラのコード管理
    • Terraform管理にした

感想

たくさんの失敗事例、失敗から学んだ事例が赤裸々に語られていてとても楽しく拝聴することができました。

登壇した皆さんは技術的バックグラウンドは異なりますがそれぞれ大きな経験を積んでいるだけでなく、自ら積極的に経験をつもうと工夫している姿勢が印象的でした。

懇親会ではマグロ一本分のお寿司や軽食が振る舞われ、同世代のエンジニア同士で共通の話題も多かったのか、大きな盛り上がりを見せました。

個人的にもSNSやブログ上だけで追っていた同世代で活躍しているエンジニアと交流することができ、楽しかったとともに非常に刺激を受けることができたかと思っています。

参加前には単純に年代で区切って集まるのってどうなの？と思っている部分もあったのですが、結果としては参加して良かったと言えるイベントだったと思います。競う対象を同世代に絞って視野が狭くなるのは良くない傾向ではありますが、刺激を受ける機会としてはとても素晴らしいイベントでした。

登壇された皆様、運営してくださった皆様、協賛してくださった各企業の皆様、本当にありがとうございました。

hori_ryota
入社してからプログラミングを覚えた4年目エンジニアです。最近はGoと動画周りを触っております。
https://hori-ryota.com/
外れ値検出のアルゴリズム、Google Apps Scriptの話他「LT Thursday」Vol.15
次の記事
AWS×PHPでの 高信頼かつハイパフォーマンスなシステム
前の記事