明日から本気出す

低空飛行する Web Developer

Developers Boost～U30エンジニアの登竜門～ 参加ノート

技術イベント

昨日行われた Developer Boost に参加してきました。

event.shoeisha.jp

Developers Summit（デブサミ）の、登壇者・参加者を30歳以下に絞ったイベントだと認識しています。

本記事では、参加したセッションについて、気になった箇所について自分なりのコメントを入れながら、まとめさせていただきます！ 見つけられたものについては、スライドのリンクもつけました。 参加できなかった方にも、セッションの概要やイベントの雰囲気をお伝えできればと思います。

「新規事業開発を支える技術」というタイトルで登壇しました

実は、今回は登壇者として参加させていただきました。こちらについては、後日、会社の方のブログで書かせて頂く予定です。
スライドはこちらになりますので、ぜひ目を通していただければと思います。

speakerdeck.com

参加したセッションについて

自分が登壇している以外の時間は、参加者として他のセッションを聞かせていただきました。
以降でまとめさせていただきます。

U30の皆さんに贈る最速キャリア戦略

合同会社DMM.com CTO 松本 勇気さん

20代にして DMM.com の CTO に就任されたということは、以下の記事で知っていました。

toyokeizai.net

とんでもない人がいるなあ、と思っていましたが、今回はその松本さんのセッションということで、楽しみにしていました。

DMM Tech Vision

今後の開発組織がどこへ向かっていくか、その方針、あり方についてまとめたもの

inside.dmm.com

標準化されたベストプラクティスの徹底によって支える

個人的に気になったワードです。最近では、技術ブログや、まさに Developers Boost などのイベントで、様々な知見が共有されています。 このことによって、業界の中でベストプラクティスが定まっていくという、とても良い循環が生まれていると思っています。

ベストプラクティスを参考にして取り入れていく、ということは自分も日頃から心がけていたりします。

発表の趣旨

最速で自分のやりたいことを実現するための考え方 について、CTO、キャリア戦略なども交えてのお話でした。

CTO のお仕事

CTO, VPoE という職種は、役割がわからなくなりがちだと思いますが、スライドでは松本さんがやられている仕事内容が一覧になっていて、わかりやすかったです！

市場で取り残されたら CTO としては負け という趣旨の言葉が個人的には刺さりました。技術的に市場で取り残されたら、という意味でお話されていたと思います。技術という部分において、そこを担保するのは CTO なんだという強い思いを感じました。

技術責任者、3つの役割と分立

CTO, VPoE, VPoP という3つの役割について、ベン図を用いてわかりやすく説明していただきました。
VPoP という役職は知らなかった・・・

役割分担が曖昧になりがちだと思いますが、このようにわかりやすく図式化してくださることで、徐々に業界としても定まっていくのかもしれません。

CTO の役割で意識している二点

  • 技術で経営を加速する、自社の市場を大きく変える技術に目を配る
  • 技術チームでできることの幅を広げることで、事業開発を加速する、技術リソースを確保する

CTOは、技術よりも経営を考える人

技術を考える人だと思っていました・・・

CTO としてコードを書き続けることが大事

「CTOは技術より経営を考える人」でありながら、もちろんコードを書き続ける必要はある、ということですね。

  • 色々な技術を理解しないといけない
  • CTO は技術を自社の武器にする職務
  • コードを書きながら理解していく
  • 技術を広く知るゼネラリスト
  • マネジメントになってもコードは書くべき

ということなどの話もありました。 コードを書きながら理解していく という言葉は印象的でした。

いかにコードを書く時間を確保するか。自分で何かを作ってみるのが一番強いですよね。最近社内の勉強会でディープラーニング本の読書会をしていますが、全然手を動かせていないので、反省です・・・。

エンジニアのキャリア

  • ゴールとして、CTO, VPoE, VPoP, フルタイムOSSコミッター, テックリード などのキャリアがある。
  • 自分が最終的に目指したい、成し遂げたいこと有りき。
  • 現実的な階段をのぼる
  • 取捨選択していくために、道標が必要

最速で駆け上がるために

必要なスキルは3つ。

  • テクニカルスキル
  • ヒューマンスキル
  • コンセプチュアルスキル

Tech に進もうがマネジメントは必須スキル。

  • Tech Lead = 技術で組織を牽引する人材
  • 職位が上がるほどに、影響を与えるべき組織の範囲が広がる
  • 人を集め、人を育て、人をモチベートする

=> これはマネジメント。

キャリアのステップを登るには、意思決定を行い、その結果を評価される事が重要。

  • 意見を正しくぶつけ、意思決定には従う
    • 理論的な正しさだけでは主張は通らない
    • 「自分がこうしたい」だけでは意見として扱われない
    • 課題解決に貢献する意見をするために、情報を解釈する

耳が痛いです・・・。数値が重要ともおっしゃっていて、自分に足りない部分だと思いました。

とはいえ、具体的にどうやっていけばよいのかイメージはわかず・・・何かノウハウみたいなものはあるのでしょうか・・・

  • 自分という人間を知ってもらう
    • 自分の能力・目標について思ったほど周囲はしらない
    • 1 on 1 や普段の雑談を大切に
    • 登壇などの発信で外側から内側への影響を作る

自分の能力・目標について思ったほど周囲はしらない というのは、その通りだなと思いました。そのために、 1 on 1 や普段の雑談を大切にされているということで、この辺りは地道にやっていくしかないんですね。

登壇などの発信で外側から内側への影響を作る については、引き続きやっていくぞ。影響を作れると良いな。

  • 意思決定者を理解する
    • 組織の構造を理解する
    • ボス猿を探す

誰に話すのが良いか、みたいなことは普段から意識していますが、まだまだ下手かも・・・。

  • 自分と組織を高次に組み合わせる
    • 組織の成果と自分の成長が両立する状態を作る
    • 自分と会社の目標が揃うような意思決定が増えていく

これができたら最高ですよね。

  • 意に沿わなくとも、組織の意思決定内容に貢献する
    • 意思決定の場、議論、その準備に全力を注ぐ
    • 意思決定が完了した後の反芻は組織の時間を巻き戻してしまう

大人だなあ、と思いました。すごい。ただ、意思決定の場にいることができないような場合、どう対処するのが良いのでしょうかね。特に20代だとそういうパターンも多そうです。決定事項に従うとしても、フラストレーションは溜まりそうですね。

感想

全体的に情報が整理されていて、言語化・図式化されていて、とてもわかりやすかったです。

「最速で駆け上がるために」のパートはとても印象的でした。組織での立ち振舞のお手本のような話で、自分自身の行動を見直す機会になりました。

スライドは今後、何度も見直すことになりそうです。ありがとうございました！

ZOZOのGlobal ECを支えるフロントエンド

speakerdeck.com

ZOZO Global EC

  • 72カ国
  • 急激なビジネス成長が期待される
  • 物流オペレーションのハードルが高い
  • 通常のECサイトより機能が多い
    • 海外ならではの機能
      • 多言語対応
      • 72カ国ごとの出し分け
    • ZOZOならではの機能
    • ZOZOSUIT での計測
    • 部位ごとのサイズ調整

かなり大変そうです・・・。最初から72カ国に対応する必要があったのかな？と思いました。スモールスタートするわけには行かなかったのだろうか・・・。

フロントエンド

  • Vux.js + Vue Router + Vuex + TypeScript
  • サーバーサイドは RESTful
  • SEO対策のため、SSR目的でNuxt.js に移行中

フロントエンド実装紹介

  • 計測3Dモデルは Three.js を使って WebGL で描画
  • 多言語化は vue-i18n
    • 翻訳テキストは json

フロントエンドの抱える課題

  • フロントエンド 6人
  • バックエンド 20 人、機能ごとにチーム分け
  • フロントエンドはすべて総括
  • ディレクターがいない
  • 夏以降に参入したメンバーで構成されている
  • 仕様策定の経緯などを把握しているメンバーが少ない
  • 特異領域も異なる

バックエンドは20人いて機能ごとにチーム分けされているが、フロントエンドは6人しかいなくて全てのドメイン知識も必要で辛い、という話。

ひたすら大変そう。こういうときに、マイクロフロントエンドという話が出てくるのでしょうか。フロントエンドもマイクロサービスにして機能ごとに提供しようという話。そうなると、サーバーサイドもフロントエンドも両方書く、というのが良さそうな気もします。

実装上の問題

  • 密に結合していて、変更に弱い
  • 程よい開発ルールの策定

HTML5 Conference で伺った話も合わせると、最初は少人数で厳しいスケジュール、かつ、フロントエンドに詳しい人もいない状態で構築された感じなのかもですね・・・。

コンポネント開発のルール

  • Atomic Design
  • Organisms は Vuex と結合しても OK
  • カタログページを作成
    • Atoms, Molecules は詳細に仕様を記載
    • Storybook に近いが、諸々の事情で自前のツールを使用。

Atomic Design 来てますね。Organisms は Vuex と結合しても OK というルールにしたのは意外でした。確かに、ページコンポーネントから子コンポーネントに流し続けていると、ひたすら props が増えていきますよね・・・。
これも一つの答えなのかもしれません。

この辺りで、自分の登壇に備えるために抜けさせていただきました。

事業をBoostさせるデータ基盤

speakerdeck.com

ユースケース

データ基盤のユースケースが多く、驚きました。

  • KPIモニタリング
    • 売上、DAU
  • ユーザー行動の可視化
    • 会員行動から離脱
  • レコメンド
  • 迷惑行為の自動検知
  • 問い合わせの傾向分析
  • 広告配信の最適化
  • ニュースレター
  • システムモニタリング
  • チームのキャパシティ

などなど。

なぜ基盤が必要になったか

  • 日時で S3 に CSV を出力
  • 各部署から依頼が増える
  • 各部署ごとにデータ疎通・加工
  • システム複雑化
  • 部署ごとに売上がずれた

どこの会社もこういう流れで、データ基盤が必要になるのかもですね。
改めてデータ基盤の必要性を確認できて、良かったです。

データの信頼性 => データ基盤の必要性

設計ポリシー

  • Model と View を分ける
    • Model : 蓄積/加工
    • View : 部署ごとに最適な View は異なる
      • Excel, Tableau, Re:dash, Jupyter
  • なるべく楽する
    • インフラ : BigQuery

Model と View を分ける、というのはアプリケーション開発にも通じるものがあり、なるほど！！と思いました。これは弊社でも取り入れたい！！

データフロー

  • 収集, 蓄積, 加工などの一連の流れをパイプライン管理
  • 小さく試しながらシステムを育てる

データウェアハウスを統一

  • ネームスペースで分ける
  • 3層構造で吸収

BigQuery に集約して、そこから Push, Pull でデータを活用しているということでした。すごい。

失敗から始まった

  • 1週間で使われなくなった
  • イテレーションを回すことが大事
  • チケット駆動開発
  • タスクの優先順位
  • 自動テストによる I/O の担保
  • ニーズ開拓の好循環
    • 小さな実績から信頼へ

もはや、社内のユーザーが顧客であり、そこに対してプロダクトを提供している感じですね。
丁寧なアプローチをされていて、良いなと思いました。

感想

ちょうど新規事業で KPI 基盤どうするか、と考えていたので、とても参考になりました。
アプリケーションエンジニアだけでは手に負えないとよくわかったので、社内のデータエンジニアの方に相談します・・・。

異なる組織文化の中で見えてきたもの

今日伝えたいこと

  • 組織文化と向き合い、どうやって良くしていくか
  • 異動して２ヶ月半
  • それぞれの良さとその文化の背景

そもそも、「文化」とは

  • 組織の活動を通して生まれた価値観や習慣

それぞれの文化

ATEAM

  • 職種を超えた連携の強さ
    • 様々な職種
    • 同期的コミュニケーション
    • 実際にユーザーと接する
  • どうしたらできるかを考える
    • 数値を分解して各チームで改善
    • 複雑なKPI

Increments

  • 知見の共有
    • ドキュメントを残す
    • PR も細かく記載する
    • 実装する前に PR を作り、コメントでディスカッション
  • 技術への向き合い方
    • 技術力が高い

異動後にやってきたこと

スクラムの推進

  • 進捗の見える化
    • 進捗がわからない、作業時間の妥当性がわからないという問題があった
  • タスクに対する責任感の向上

朝会小話の導入

  • 話がしやすくなる
  • 良い刺激になる

エイチームグループ全体で技術共有会を実施

  • 困ったときに誰に頼れば良いか分かる

これは大事ですね。困ったときに詳しい人に相談できると、強いです。

これからやっていくこと

良い文化を相互に活かす

  • 正しく現状を理解し、適切に文化を取り入れていく

感想

各社の良いところを相互に反映していて、とても良い話だなと思いました。
事業に強いエイチームさんと、技術に強い Increments さん。最強の組み合わせなのでは・・・！

ファッション分野における機械学習応用例

ZOZO研究所

  • ファッションを数値化する

主に3つの研究を行っている。

  • 採寸の研究
  • 似合うの研究
    • 型紙自動生成
    • ファクトリーオートメーションの実現
      • 服のレシピを入れる
    • コーディネート生成、推薦
  • 服作りの研究

ファクトリーオートメーションってすごいですね・・・。

画像認識の事例

  • 物体検出 + クロスドメイン画像検索
    • スナップ写真をインプットして、商品のリストを出力する
    • 商品検出の手間を省く
  • ボディスーツ無しで、画像一枚でサイズを測れないか
    • 3D => 2D
  • Visual Analitycs
    • 商品の特徴データからトレンドを予想したい
  • LIKE 数から、色の季節性が観測される
  • 2D Virtual Try-ON
    • 画像に対して服を着せ替える
    • 自分と、モデルの画像を入力する
  • AI がファッションをデザインする
  • 独創性を持たせることもできる
  • 相性の良いアイテムの組み合わせを知りたい

感想

実用レベルの事例がたくさんあって、驚きました。「ファッション x 機械学習」は注目すべき分野かもしれません。

「簡単でつかいやすい」を追求する開発の裏側 ～メディア解析基盤の話～

speakerdeck.com

メインテーマ : メディア解析基盤のリプレースと SageMaker

コンテンツ開発チーム

  • コンテンツ自動生成
  • 1秒動画、自動提案フォトブックなど
  • 簡単で使いやすくするための機能

Googleフォトでもコンテンツ自動生成されていると思いますが、そのようなイメージでしょうか。

  • メディア解析基盤
    • 全メディア（7000万件以上/月）を解析する
  • 旧システムの問題点
    • 一部インフラをアプリ向けAPIサーバと共有
      • 分析起因の高負荷で障害
    • 運用コストが大きい
  • 新基盤の要件
    • コンテナ化、マネージドサービス
    • k8s もあるが、3人チームなのでマネージドを使う
  • なぜ SageMaker か
    • マネージドである
    • S3 や RDS を扱いやすい
  • ビルド、テスト、デプロイは CodeBuild
  • SageMaker インスタンスのスケーリング
    • 公式ドキュメント「APIの実行回数でスケールすべし」とあるが、違う使い方をしている

感想

3人でここまでやっているのすごいと思います。

やはり、アプリケーションと機械学習や解析・分析系は基盤を分けるのが良さそうですね。
SageMaker の事例は初めて聞きましたが、マネージドかつスケーリングもしてくれるということで、参考になりました。

17:45【A-10】カベを壊せ！「機械学習」×「グラフデータベース」×「チャット」で繋ぐヒューマンリレーションシップ！！

  • グラフDB
    • CosmosDB
    • リレーションシップを作れる
  • Doc2Vec
    • 文書をベクトルとして扱う
  • Word2Vec
  • チャットの投稿を文章とする
    • あるキーワードを投稿したことがある人を検出できる
  • User2Vec
  • グラフDB
    • ユーザーとの距離を計算
  • ユーザー同士のコミュニケーションの量
    • ユーザー同士の関係スコア
  • Azure Machine Learning Service
    • リソース確保、最適なアルゴリズム、ハイパーパラメータの探索、デプロイの自動化
  • ありものを組み合わせるだけで大きな成果が出せる

感想

知識量が尋常じゃないし、一人でここまでやるのはすごすぎると思いました・・・。

ただ、マネージドサービスが増えて来ている中で、機械学習・ディープラーニング分野も個人である程度まで開発できる時代なのかもしれません。
何か作ってみるか・・・。

18:10【A-11】プロダクトを支えるSREの存在意義と役割

speakerdeck.com

SRE は、ソフトウェアエンジニアに運用チームの設計を依頼したときにできあがるもの

class SRE implements DevOps

  • DevOps を実装する

従来型の運用の問題

直接的なコスト

  • 人に手による問題解決に依存
    • デプロイ
    • configファイルの変更
      • 手動でサーバーに入って更新
    • 障害対応
  • 運用コストが線形増加

間接的なコスト

  • 利害関係の対立

SRE のアプローチ

直接的なコスト

  • ソフトウェアでの自動化・効率化
  • 運用コストの線形増加を防ぐ

間接的なコスト

  • 共通目標を定める

サービスレベル

  • SLI, SLA, SLO
  • 何を測ればよいか
    • 可用性、レイテンシ
  • 測定しやすいものから測ると良い
  • 可用性については、ダウンタイムを参考にすると、サービスレベル をイメージしやすい
  • リアルタイム計測基盤

OnCall

  • Run Book
    • オペレーションに関するマニュアル
    • 誰でもできるように、ドキュメントに起こしておく
  • 自動化されていない処理に関するドキュメント作成はマスト
  • Run Book にはテンプレがたくさんある
    • 何を書けばよいかわからない
  • アラート疲労を減らす
    • 重要なアラートの見落としが発生する
    • どんどん見なくなってしまう
    • 分類、ロジックが大切
  • モニタリングのアラート分類
  • ポストモーテム
    • 障害振り返りドキュメント

アラート疲労を減らす というのは、常に手を入れていくことが大切なのだと思いますが、そこまで手が回らなかったり・・・。

Webオペレーションは技芸であり科学ではない

感想

SRE はインフラエンジニアの進化系と思っていたところがありましたが、少し違いそうですね・・・。

サービス運用にとって、大切だけど後回しにされがちなことに、しっかりと向き合う職種だと思いました。現状がモダンな開発環境ではなかったとしても、必要な職種だと思いました。

最後に

最後息切れしている感があって申し訳ないですが、なんとか書きました・・・。スライドを見つけられなかったものについても、見つけ次第追記します。

登壇者も参加者も30歳以下ということで、セッションの内容や懇親会での会話も近い目線の話が多く、とても参考になりました。

運営スタッフのみなさま、登壇者のみなさま、参加者のみなさま、ありがとうございました！！