DX Criteria ver.201912を使ってVOYAGE GROUPとfluctを自己診断してみました。

どうも、ajitofm 準レギュラーの @makoga です。この記事は ajitofm ep.56 とのコラボ企画です。

ajitofm ep.56ではVOYAGE GROUPとfluctの自己診断結果などについて 広木 大地/ エンジニアリング組織論への招待 (@hiroki_daichi) | Twitter さんと楽しく語っていますので、ぜひ聴いてみてください。

この記事では、各社のCTOそれぞれが実施したDX Criteria ver.201912の診断結果を公開したいと思います。

DX Criteria ver.201912 とは

DX Criteria( DX基準 )は、日本CTO協会が監修・編纂している企業のデジタル化とソフトウェア活用のためのガイドラインです。 デジタル技術を企業が活用・コントロールするために必要な要素を多面的・具体的に言語化し、ソフトウェアエンジニアリング組織の健全な成長・経営目標の可視化・パートナーとのコミュニケーションなどに使っていただくことを目的に作成されています。

また、この基準は絶対的なものではありません。極めて現在的で具体的な項目で構成されているため、定期的に最新動向に併せてCTO協会の個人会員様と議論をおこないながら、適宜アップデートをしていくものです。

とのことです。

DX Criteriaの調査項目の構造は以下になります。

https://cto-a.github.io/dxcriteria/image/structure.png

320項目を記入するのはそれなりに時間が掛かりましたが、時間を掛ける価値はあったと思います。

DX Criteriaの詳細は下記を参照ください。

cto-a.github.io

VOYAGE GROUPの自己診断結果

全体感としてはちょっと甘めだったかなと思ってました。しかし、fluctの自己診断結果をみると現場感とそんなにずれがなく、妥当だったと思いました。

テーマ別でいうと、コーポレートが強く、デザイン思考が弱いという結果になりました。これは予想どおりでした。コーポレートは開発環境、評価制度、採用などに力をいれてきた結果だと思いますし、デザイン思考の強化は今後の課題と捉えています。

また、チェック項目でいうと、アンチパターンに強く、メトリクスの計測が弱いという結果になりました。これも予想どおりでした。私は致命傷に繋がることを排除し、挑戦しやすい環境を作ることに力をいれてきたので、アンチパターンが少ないことに繋がったと思います。メトリクスは設計に失敗すると負のフィードバックループに陥るので、無理に設定しないようにしてます。ただ、もうちょっと計測できるものもあるとあらためて思いました。これをきっかけに改善していきたいと思います。

f:id:voyagegroup_tech:20200205184823p:plain
team

f:id:voyagegroup_tech:20200205184925p:plain
system

f:id:voyagegroup_tech:20200205184947p:plain
data

f:id:voyagegroup_tech:20200205185007p:plain
design

f:id:voyagegroup_tech:20200205185033p:plain
corporate

fluctの自己診断結果

fluctはVOYAGE GROUPの100%子会社です。自己診断はfluct CTOのすずけんが行いました。

こちらはテーマ別でいうと、システムが非常に強く、デザイン思考が弱いという結果になっています。これはfluctエンジニア陣がシステムをより良い状態にすることにしっかり投資しているからだと思います。デザイン思考は今後の課題ですね。

以下、すずけんからのコメント

fluctについては広告配信事業として継続的に基盤への投資を進めてきました。データを効果的に使い、安定したシステムを動作させるために長く取り組んできた過程が反映されていると思います。

デザイン思考については現状課題として認識しており、今年1月から新たにエクスペリエンスデザインの部署を立ち上げました。fluctの会社全体としての顧客体験を向上をミッションとし、デザインとエンジニアリングのちからによってこれを解決するチームです。

実際にやってみると、DX Criteriaは組織間の相対評価ではなく、自身の組織に対する健康診断であるとやってみて感じました。例えばVOYAGE GROUP内の各事業においては、育成や評価の仕組みは全社での投資とされつつも、システム投資、チーム運営などは各事業部によって特色がでているはずです。なかなか包括的に自身の組織について振り返る機会というのはないので、DX Criteriaの各項目と会話しながら組織を点検するのは良いプラクティスになると感じました。

f:id:voyagegroup_tech:20200206133956p:plain
team

f:id:voyagegroup_tech:20200206134213p:plain
system

f:id:voyagegroup_tech:20200206134026p:plain
data

f:id:voyagegroup_tech:20200206134046p:plain
design

f:id:voyagegroup_tech:20200206134109p:plain
corporate

今後の展開

fluct以外のチームにも自己診断をしてもらい、チームごとに改善するところ、VOYAGE GROUP全体で改善するところの目線を合わせていきたいと考えています。今後も結果は公開していきたいと思ってます。

また、いろんな企業/チームがDX Criteriaで自己診断を行い、結果を公開していくと業界全体が良い方向に進むと思いました。

SRE NEXT 2020 参加レポート

はじめに

こんにちは。fluct でSREをしている村田です。

2020/1/25 (土) に豊洲フロントで開催された SRE NEXT 2020 に参加してきましたので、皆様にご報告していきたいと思います!

sre-next.dev

SRE NEXTは日本で初めてのSREをテーマとしたカンファレンスで、弊社もゴールドスポンサーとして参加させていただいており、当日はfluctのSREチームメンバー数名で参加させていただきました。 スポンサーセッションでは fluct SREチームのみっさんが 成長を続ける広告配信プラットフォームのモニタリングを改善してきた話 というタイトルで発表を行いました。

speakerdeck.com

印象深かったセッションなど

ここでは特に印象深かったセッション(など)についてまとめていきます。

早期来場者特典の特別ヨガプログラム

これはセッションではないのですが、会場に早く来た人向けのヨガプログラムがありました。 オープニング前の20分ほどの時間、インストラクターの saku_yoga さんのヨガレッスンを受けられるというもので、 座ったままの状態でできるリフレッシュ方法を沢山教えていただきました。 初めてのカンファレンスで緊張していましたが、ヨガのおかげでリフレッシュした状態でセッションに臨むことができました。 仕事柄やはりデスクワークが中心ですので、これからも活用させていただきます!

[A3] freee のエンジニアは障害から何を学び、どう改善しているのか?

freeeの@manabusakai さんによるセッションで、freeeのエンジニアがプロダクトの成長とともに障害とどう向き合ってきたかを解説していただきました。

freeeのプロダクトは人やお金に関する個人情報を扱うものが多く、障害に対して非常にシビアな対応が求められます。そんな中、起きてしまった事件(大きな障害)から何を学んだのか、そしてどのように改善していったかについて解説していただきました。

speakerdeck.com

良いと思ったプラクティス

セッションの中で紹介されていた取り組みの中で、特に印象に残ったのは次の2つです。

  • 自分たちに合った障害対応フローの作成
    • 障害対応フローをより明確に整理したドキュメントを用意
    • 初動対応や役割分担など、誰がどういう対応を取ったらいいかを明確にする
  • 障害対応のノウハウを共有する場を作る
    • 属人化しがちな対応ノウハウを組織に共有

fluct でも障害が起きた時の大まかな対応フローはあるのですが、ドキュメントなどを整備して、もっと誰でも対応しやすい状態にできると思いました。 加えて障害対応時のオペレーションについても、どのような対応を行ったのか、またその時何を考えていたのか共有するように改善していきたいと思いました。 障害対応時のノウハウを組織全体に共有することが、障害に対してより強い組織につながるのではないかと感じました。

[A7] サイト信頼性エンジニアリングの原則

Googleの@ymotongpoo さんによるセッションで、 SRE本に出てくる原則や手法を具体例をまじえながら解説してくださいました。 改めて、SREってなんだっけ?というのを振り返れる内容となっていて、SRE歴の浅い私としては特に聞けて良かった思ったセッションでした。

ymotongpoo.hatenablog.com

印象深かったトピック

紹介されていたトピックの中で個人的に印象深かったのは次の2つです。

  • SLOとエラーバジェット
    • SLOを設定するとエラーバジェットが決まる
    • SLOを必要以上に厳しくすると変更に対して鈍重になる
  • ポストモーテム
    • 人間にフォーカスしない。曖昧な表現はダメ
    • 事実と具体的な対策を書くことが大事

SLOに関する話題は他のセッションでも頻繁に取り上げられており、自分達のサービスの信頼性を担保していく中で各社が非常に重要視していることが伺えました。 その一方、自分達はというとSLO設定はまだできておらず、自分たちのサービスの信頼性を定量化できていない課題があることを再認識しました。

ポストモーテムでは、システムに何か問題があった場合には人間に着目するのではなくプロセスと技術に着目して振り返りを行い改善していくことが重要な考え方とされています。 fluct でも障害が起きた際は皆で振り返りを行いますが、この考え方は比較的実践できているように思いました。 失敗を学びに変える素晴らしい考え方なので、引き続き実践していきたいと思います。

[A8] Webサービスを1日10回デプロイするための取り組み

@fujiwara さんによる基調講演で、面白法人カヤックでデプロイの頻度を上げるために行ってきた取り組みについての解説をお聞きしました。

内容としては、Lobiというシステムの歴史とともにデプロイを誰でもかつ高頻度で行えるようにしていったというお話でした。 発表の中でfujiwaraさんが開発したstretcherというデプロイツールについての紹介があったのですが、 自分も実際に使ったことがあるため、開発者の話を生で聞くことができ感激しました。

speakerdeck.com

良いと思ったプラクティス

発表の中で紹介されていたプラクティスの中で特に良いなと思ったのは、

  • 休日前やピーク前はデプロイを避ける
    • Slack Bot が確認してくれる
    • どうしてもやるなら翌日の休日出勤申請をする

でした。fluct でも同様に休日前のデプロイは避けるという決まりがあるのですが、 Slack Bot での確認やどうしてもやる場合は休日対応できるように休日出勤申請をするなど仕組みで防止している点が素晴らしいと思います。

ブースについて

会場ではスポンサー企業によるブースが多数出展しており、スポンサー企業の方々と気軽にお話することができました。 ノベルティもたくさん用意されており、自分はNew RelicさんのブースでTシャツと靴下を頂きました!ありがとうございます!!

さらに CrowdWorksさんのブースでおみくじを引いたところ、大吉が出てなんと『実践Terraform』を頂きました! 以前から気になっていた本で、この機会に頂くことができて嬉しいです!ありがとうございます!!

おわりに

今回、SRE NEXT参加したことで、他の企業におけるSREの運用事例・プラクティスをたくさん知ることができ、非常に良い刺激を受けました。 実は自分はこういったカンファレンスに参加するのが初めてで、他の企業がどういう取り組みをしているのかを知る機会があまりなかったのですが、 今回、多くの知見が得られたとともに外と比較したときの自分達の課題についても認識することができました。 どの発表も素晴らしくとても刺激的なカンファレンスだったので、来年もぜひ参加したいです!

また、カンファレンス全体を通じて感じたことですが、運営してくださったスタッフの皆さんの対応が本当に素晴らしかったです。 初めてのカンファレンスで緊張していたため、スタッフの方の明るい挨拶には本当に心が救われました。 案内や進行もスムーズで、安心して参加することができました。 この場をお借りして全力で感謝の意をお伝えしたいです。

システムの複雑性と戦う方法

こんにちは。Zucksでエンジニアをやっています@karahiyo_nです。

先日社内向けに「Zucksで働き学んだ成果に繋がるプラクティス」という発表を行いました。今回はその一部を紹介したいと思います。

発表では6年間でシステム構成がどう変わってきたのかと実際にやってきたタスクを紹介しつつ

  • より妥当な意思決定をするために
  • より早く価値を提供できるように
  • システムの複雑性と戦う方法

などいくつかプラクティスを紹介しました。 今回はその中のひとつ「システムの複雑性と戦う方法」について書きたいと思います。

対象のシステム像

元の発表ではZucksのシステムを取り上げて解説したのですが、ここでは次のようなシステムをイメージしてください。

  • 非常に高いサービスレベルが求められるシステム(例えばAmazon Compute SLA相当)
  • 低レイテンシ、高トラフィック(で、さらに増加傾向)
  • 機能要望は尽きず毎時リリースされるシステム(同時にリリースが走っているのが日常)
  • 複数の外部サービス、クラウドベンダを使っておりリソースの数も多い(AWSやGCPなど。台数の上限緩和を3回くらいやった規模感)

生き物のように複雑かつすごい速度で変化し続けるシステムで、直接コントロールはできない外部環境によってその動きが変わるようなシステムです。

このようなシステムを開発、保守するには様々な万が一の問題、予期せぬ副作用の心配があります。 完璧だと思ったリリースでも思わぬバグがあったり、ユーザ数の増加などによって負荷に耐えられなくなったり、外部サービスやクラウドベンダ起因の問題などなど。

これら万が一の問題、予期せぬ副作用がある中で継続して開発を行いかつ安定して運用することがミッションです。

我々の仕事の難しさは、飛んでいる飛行機を飛ばしたまま改修するようなもの                              by さいないぷ

システムの複雑性と戦う方法

本番環境で安全にトライする

ローカル環境やステージング環境での動作確認だけでは改修内容の正しさを保証できない問題があります。 例えばロジックには問題なかったが本番環境の負荷に耐えられなかったり、権限不足で動かなかったり、結合テストでカバーしていない問題があったり、ライブラリのバージョンアップやデータベースのメンテナンスに伴う瞬断など影響範囲がわかりづらく広範囲に及ぶようなケースなどがあります。 このような事前のテストだけでは改修内容の正しさが保証できないような問題に対しては、本番環境で安全にトライすることを考えます。 完全なテスト・テスト環境を作るのはとても難しいので本番環境で確認するのが有効という考えです。

その際には安全に、サービスに影響しないようトライする方法を確認します。 サービスへの影響がありうるならなるべく影響を小さくしてトライすることを考えます。

サービスへの影響を小さくするために、例えばカナリアデプロイやブルーグリーンデプロイメントを行い全トラフィックの数%だけデプロイしたコードで処理します。 また影響の発生期間を短くするために、ロールバック方法を用意しロールバックにかかる時間を短くします。 とくに、穴となるのが"ロールバックが必要と判断するまでの時間"の長さです。サービスが意図通り動いてるのかどうかの監視とアラーティングも重要です。 もしも、やろうとしている変更がロールバックが難しいような場合は、そのデプロイ内容や方法自体から見直します。

サービスメトリクスを監視する

サービスが意図通り動いているのかどうかの監視とアラーティングが重要と書きましたが、それを実現するためにはどうすればいいか。 ひとつ効果的なのが、サービスメトリクスの監視です。

EC2インスタンスの起動失敗や、Lambdaの起動失敗、外部サービスとの通信に失敗などなど、これらは正常な動きではありませんが想定内の動きと考えます。その一つ一つの振る舞いの検知にのみ注力するのではなくサービスの状態、機能が動いた結果が正常なのかどうかを監視するべくサービスメトリクスの監視にも注力します。 EC2インスタンスの起動に失敗し続けていてサーバー負荷が上昇しその結果レスポンスが遅れていることを検知する、外部サービスとの通信に失敗し続けていてその結果、より最適なサービス提供ができていないことを検知する、なぜだかわからないが収益性が下がっていることを検知する、などなど。サービスに直結するものをみることで予期せぬ副作用や外部環境依存の何かしらの問題が発生していることに気づけるかもしれません。

難しい問題を簡単にする

ここでの難しい問題とは、人が十分に注意しなければいけないことが多い問題のことです。 人類には早すぎる問題に真っ正面から戦わずに、人間でも扱える程度の問題に落とし込めないかを考えます。

安全にトライするためには影響範囲を把握する必要があると先に書きましたが、もしその影響範囲の把握が難しいものになっているならば影響範囲を把握できるようにすることが最初の仕事かもしれません。例えば、誰がこのAPIサーバを使っているのかをロギングして確認する、SecurityGroupのallowルールを見直して実際に必要な最小限の権限にする、複数の機能が動いているサーバを機能ごとに別サーバで動かすよう分割するなどなど。

例外発生時に人が対応しなければいけないことを減らすよう自己復旧の仕組みを整える。データベースの瞬断時には自動で再接続をする、外部サービスへのリクエストの失敗は時間を置いて自動でリトライする。

正常に動くための条件がテストや何かしらの制約で守られておらず脆い。例えばcronスケジュールで繊細な依存解決をしている場合など。(〇〇までには15分も待てば十分でしょう、みたいな意思決定) テストや、コードで依存関係を明示的に書き正常に動くことを保証することを考えます。もしくはまずは監視の仕組みを用意してよくない状態の発生に気づけるようにすることを一手目として考えます。

再発防止する

残念ながら、万が一の問題や予期せぬ副作用が発生しないよう気をつけていても事は起きるときには起きます。 そのときにできることは起きた事から学び、次同じことが起きないように対策を打つことです。根本原因を理解し正しく機能する対策を打ちます。 チームで振り返り、障害内容の共有と今後の対応の確認を行います(ポストモーテム)。 弊チームではChaos Engineeringの一歩として避難訓練を行ったりしています。

まとめ

今回は先日社内向けに発表した「Zucksで働き学んだ成果に繋がるプラクティス」のひとつ"システムの複雑性と戦う方法"について書かせていただきました。 システムの複雑性とうまいこと戦って、毎日夜は安心して寝られることが一つ大切にしていることです。

Sunrise 振り返りを公開します! #voyage_intern

こんにちはこんにちは!fluct で広告配信のお手伝いをしている @jewel_x12 です。

この記事はSunrise Advent Calendar 2019の 6 日目の記事です。今年の 11 月初旬に Sunrise というインターンシップを実施したのですが、その参加者がアドベントカレンダーを自主的に作ってくれました。嬉しくて自分も参加です!(Treasureアドベントカレンダーもあるようです)

voyagegroup.com

今回の記事は Sunrise の振り返り と Sunrise に関連した内容になりますが、Sunrise Advent Calendar 2019 のネタはよろずで良いとの事なので、後続の方もフリーダムな記事待ってます!

Sunrise って?

Sunrise は VOYAGE GROUP のエンジニア向けインターンシップです。大規模リクエストを捌くシステムについて、安定した価値を出し続けるというテーマで 2011 年からやっています。

今年はリクエストに含まれるイベントデータを記録して、集計結果を見ることができるサービスをチューニングしてもらいました。増えていくリクエストを捌けるよう、どういった設計にするか?ということをやっていきます。

VOYAGE GROUP におけるインターンシップの振り返り

VOYAGE GROUP のインターンシップは Treasure をはじめいくつかありますが、関わったメンバーと人事による振り返りをしながら改善しています。参加してくださった皆さんからいただいたアンケートもここで参考にしています。

Sunrise も同様に 9 年間改善し続けていますが、他の VOYAGE GROUP のインターンシップと比較しても大きく変化している部類で、振り返りの結果や時流に応じて内容がどんどん変わっています。最初は架空のシステムの設計を机上でやるものでしたが、現在は我々が開発・運用しているシステムに近いものを触りながら設計するものになっています。

2018 年度 Sunrise の振り返りと今回やったこと

まず、振り返りの結果が実際にどうやって反映されているのか説明するために 2018 年度 Sunrise の振り返りについて書きます*1。ここからは 2018 年度 Sunrise のことを前回、2019 年 11 月に実施された Sunrise を今回と呼びます。

前回の振り返りでは Keep (継続したいこと)と Problem (見つかった課題)をリストアップしました。今回の Sunrise を準備する時には、このリストを参考にしてやる事を決定しました。前回と今回の対比を分かりやすくするため、今回はどのような Problem を参考にして、どう改善したのかを以下に記載します。

環境構築の自動化・開催日数を増やす

  • Problem
    • 初日の環境構築に時間がかかる
    • 残り時間を重視した優先度付けになってしまう

環境構築は自動化されていない部分があり、構築に時間がかかっていました。これを TerraformPacker, Makefile で自動化したり、README をパラメタライズしたりすることで、導入がスムーズになるよう運営メンバーの yowatari が調整してくれました。

環境構築部分を参加者と一緒にやっていくのも勉強になって面白いのですが、どのような設計にすれば良いかということや、やる価値のある施策に時間を使ってもらいたいところです。

環境構築の自動化以外では、2 日間開催だったところを 3 日間開催にしてみました。

情報共有のタイミングを増やし、仮説検証を理論立てて実行できるフォーマットを作る

  • Problem
    • 情報共有について
      • チーム内の情報共有がどこのチームも弱かった
      • チーム同士でもアイデアの共有が弱かった
    • 仮説検証の方法について
      • 状態の観察→仮説→検証みたいなサイクルになっていなかった
      • 1 施策 1 観測にしたい

近年の Sunrise は、参加者が触るシステムや課題設定も含めて、我々の業務に寄ったインターンシップになっています。我々が普段やっていることや、考えていることを伝えることで、他の場所では得られないものを持ち帰ってもらいたいという意図があります。

なので、我々の業務に近いインターンシップ設計にしたいところです。例えばチーム内で情報共有をしますし、部署間・会社間を超えてアイデアは共有しています。チューニングをする際も情報収集から仮説を立て、状況に応じて最も効果的である施策を選択し、実行していくことを心がけています。前回では実際の業務と Sunrise の実態にズレが生じました。

今回は各チーム間で情報共有するタイミングを増やし、共有するためのフォーマットを作りました。フォーマットでは集めた情報を書いたり、そこから得られる施策の想定インパクト、1 施策 1 観測といったことを促すものを作りました。

その結果、我々が業務でやっているような進め方を学べたという声をいただいたり、どのチームもある程度の水準までチューニングすることができていました。最近の Sunrise はスコアを競ったり順位を決定するものではないので、チーム内外で積極的に情報共有をして、お互いを高め合ってほしいです。

今回はどんな振り返りになった?

Keep と Problem の一部を抜粋します。

  • Keep
    • 業務で考えていることを伝えられた
    • Ajiting*2 率が高く、雑談ができた
    • 時間に余裕ができた
    • 用意していたリクエストのシナリオをクリアできるチームがいた
    • チーム間の共有があった
    • サポーターがチームにがっつり入って一緒に進められた
  • Problem
    • 用意したシナリオを全部クリアして、時間を持て余すチームも出てきた
    • アドテクノロジーについてあまり説明していない
    • インスタンス数の制限など、AWSアカウント毎の制限を事前開放しておくべきだった
    • 最後に VOYAGE GROUP エンジニアによる座談会をやったが、みんな疲れてそうだったので、ちゃんと聞いてもらえるタイミングでやりたい

次回はどうしたい?

時間ができたことによって見えてきた課題もあるので、ダウンタイムの SLO (Service Level Objective) を追加してみようかなとかムニャムニャ考えているところです。

まだ次回の Sunrise 予定は無いですが、来年もやる場合は更にパワーアップしているはずです!募集情報をぜひチェックしておいてください!そしてこれまで Sunrise に参加してくださった皆さん、ありがとうございました!皆さんが参加してくださることで、Sunrise は改善し続けることができています。

次回の Sunrise Advent Calendar 2019 記事はくぎさんの予定です〜。

*1:2018 年度の Sunrise は 2 回実施しており、その 2 回についての振り返りになります。

*2:社内バー Ajito でドリンクを飲みながらダベること。業務で詰まっているところをチームを越えて相談したり、どうでもいい話をしたりすることがある

さて、問題です。Treasureに直接関わった人の人数は?

トリックオアトリート!
VOYAGE GROUPでエンジニア新卒採用を担当しているナミ(@7naaaaami3)です。

渋谷はハロウィンで盛り上がる中、いまさら夏のインターンを振り返っちゃいます。

※この文章の元ネタは2019年10月に社内に公開したものです。

VOYAGE GROUPではこの夏、3つのインターンを開催していました。

  • 8月12日~30日 ものづくり実践プログラム「Treasure
  • 9月17日~19日 データドリブン開発プログラム「Adventure
  • 9月20日「Goで並行処理を学ぶ1dayインターン」

今年は新しいインターンも作る!という意気込みでやっていましたが、なかなかハードでした。

こんなにインターンシップを開催できているのも
ほんとーーーーーにたくさんのクルー*1のご協力をいただけているからこそです!!!

今回はクルーのみなさん、そして参加してくれた学生への愛をつづるのと、備忘録としてずっとやりたいとおもってたTreasureに関わってくれた人をかぞえます。
わたしの好きなハイライトとともに。

人数当たった人がいたらおかしあげます。トリックオアトリート。
長いので、人数だけ知りたい方は下へ飛んでくださいw
(名前を挙げさせていただいている方は、社内SlackのID or ニックネームで表記させていただいております)

インターンに向けての時間軸

- 2018年12月 キックオフ
- 2019年1月 講師陣検討
- 2019年3-5月 春の1dayインターン
- 2019年3-6月 各種インターンの選考
- 2019年3-6月 サポーターズ1on1イベント
- 2019年8月 Treasure
 - 前半:講義
 - 後半:グループワーク with サポーター
- 2019年9月 Adventure
- 2019年9月 Golang 1day
- 2019年11月  Sunrise

まずはTreasure運営陣

去年の12末に「来年どうするかねえ」とキックオフ。
小賀さん すずけんさん えいちさん さっさー
メイン講師が決まった瞬間はこちら。

メイン講師が決まった瞬間
メイン講師が決まった瞬間

やんうぇい プレッシャーの中、やんうぇいの想いがつまった素敵なTreasureでした。本当にありがとう!

これで計5名。

Treasure講師陣

Golangに ペイ、フロントエンドに ちゅーこ の新卒2年目を抜擢。
DBは昨年に引き続き こまさん ぷろ あっきー のポイントメディアの方が中心に。
セキュリティは安定の えびちゃんさん
インフラに みっさん ともかつ
アイディア講義に わーみー ガイアさん

講師を依頼してて一番のハイライトはこちら。

講師依頼の瞬間

鼻水出る勢いで引き受けてくれて本当にありがとう!! 本番は鼻水出てなくてよかった。

この時点で+10人。

3月~5月にかけての1dayインターン講師陣

「Goを使ってWebアプリケーションを作ろう」というテーマで。 せんちゃん あっきー ひむ しむ 6回にわたるインターンを開催してくれて、ありがとう! Treasure参加者の約半数が1day出身という快挙!!

学生からの素敵なコメントはこちら

手厚いサポートをしていただきありがとうございました! 普段SourceTreeに甘えていたので、改めてCUIの素早さ、vimmerのかっこよさに触れました。 分からないことがあっても聞きやすい環境を作って頂きありがたかったです。

ここまでで+3人。

3~6月にかけての面接官

たくさんいるので名前は割愛しますが...

今回初めて早期選考と通常選考で分けること、早期選考の学生へは面接のフィードバックをする試みもお願いしていました。

今年は例年より応募が1.5倍くらい増えたため、たくさん面接のお時間いただき本当にありがとうございました!!

この時点で+29名。 そろそろ数えるのが大変になってきたぞ、、、。

サポーターズ1on1

小賀さん、えいちさん、さっさー、ともかつ、ゆきみね、みっさん、ぺい、しまさん、ゆっけ、ガイアさん

3~6月にかけて計8回、1日に学生10~12名と1人あたり約25分間面談をして、ひたすらインターンを訴求するというイベント。 これ、脳みそと体力をフルで使うイベントでほんとに大変なのですが、一緒に参加していただいた方々のおかげで、Treasure参加者の8割がサポーターズ経由という結果でした!

ひたすら面談し続けるハードなイベントの中、結果も残しつつ楽しくできたのは一緒に参加していただいたみなさんのおかげです٩(๑❛ᴗ❛๑)۶ 本当にありがとうございました!!!

あと、なによりも学生を集めてイベントを運営していただいたサポーターズの方々、ありがとうございました!

ここで名前挙げたひとは全員重複してた。

そしてそしてサポーターのみなさん!

そして、約1週間半、ベタ付きでサポートをしていただいたみなさん!!!
じゅえる、こもりん、りょーきさん、さいないぷさん、さっさー、たがやす、こすさん、あっきー、いっきさん、ゆっけ、よっぴー、えいちさん、けんじさん、のざ、後藤さん、前田さん、さっくん

「Treasureが1番最高のインターンでした!」って終わってからも会うたびに何人もが言ってくれてます。涙でるほどうれしい。

そんなインターンにできたのも間違いなくみなさんのおかげです。

サポーター内Slackでの好きなやつ

今日のハイレゾ

+10人。

そしてそしてそして、内定者のみんな!!

TAとしてサポートしてくれて本当にありがとう。
みんながいなかったらインターンの成功はなかったと思います。
学生の質問に答える頼もしいみんなを見て、入社がますます楽しみになりました。

+9人。

正解は、、、、、66人!!!!

調べてみたら全社のエンジニアが100人強だったので人事や内定者抜いても半分。スゴイ。

とはいえ、これは直接関わっていただいた方の人数で、Treasureの講師やサポーターとしてクルーを送り出していただいた各チームの方々のおかげで、これだけの人数の方に協力していただくことができました!!

エモさはみんなの気持ちがあってこそ。

「VOYAGEのインターンはエモい」
と学生の間で噂になっているようですが
「エモさ」って人事だけでは絶対に作れなくて。
関わってくれたクルーが本気で向き合ってくれるからこそ
参加してくれた学生が本気で向き合ってくれるからこそ
みんなの気持ちがあるからエモさがでるんじゃないかなと思います。

参加してくれたTreasure生のみんな。
貴重な夏休みのインターンにTreasureを選んでくれてありがとう!
みんなが参加して本気で取り組んでくれたからこそ
素敵なインターンシップが作れたと思っています!

改めてこんなにたくさんの人に協力をいただいているのを実感して
VOYAGE GROUPの仲間やファンを全力で増やしに行くぞ!と気合がはいりました。書いてよかった(╹◡╹)

Adventureや1dayインターンもおなじく

初めて取り組んだデータドリブン開発プログラム「Adventure」も
メインとして西林さん、ほげひこさん 、そして当日は おうやん のおかげで無事に開催することができました!

優秀な学生があつまってくれて、たった3日だったけど、とても充実した素敵なインターンになったと思っています。

そして、またもや初の試み「Treasureに興味があるけど参加できなかった学生向けの1dayインターン」も ようこうさん監修の元 しゅう のサポートのおかげでいいかんじに終えることができました٩(‘ω’)و

どちらのインターンもわりと急のご相談だったにも関わらず、ご協力いただき本当にありがとうございました!! 今後、柱のインターンになるようにブラッシュアップしていきたい。

まだまだ続くよ仲間さがしの旅

気づけばSunriseが今週末に迫ってきました。ハヤイ。
じゅえる、わっさん、との、ぺい、その他関わってくれる方々 3日間、よろしくおねがいします!!

だいぶ長くなっちゃいましたが、すでに次の旅へ向けて走り出しています。 これからも引き続き、よろしくお願いします٩(๑❛ᴗ❛๑)۶

打ち上げ後に最高の笑顔!
打ち上げ後に最高の笑顔!

追記(インターンの内容はこちらから!)

Treasure生による感想ブログ

ひろき kirohi.com

でんでん denden-seven.hatenablog.com

やんやん shinya-ml.hatenablog.com

たじまん tjmschk.hatenablog.com

くぎ ramenjuniti.hatenablog.com

きっちん kitchen-py.hatenablog.com

うぉーりー wally-ngm.hatenablog.com

とむ tomu28.hatenablog.com

まえちゃん tako8ki.hatenablog.com

nasa nasaemon.hateblo.jp

Adventure講師、西林さんのブログ hagino3000.blogspot.com

*1:VOYAGE GROUPでは社員のことをクルーと呼びます

面接時に見ているポイント

こんにちは、CTO歴も丸9年以上になりました @makoga です。

Podcastや勉強会で話をしたときに好評だったので、今回は私が面接時に見ているポイントを書きます。

※この文章の元ネタは2016年1月に社内に公開したものです。

面接時に見ているポイント

3行まとめ

  • 事実と意見を分けて説明できるか
  • 実際の課題を解決しようとしているか
  • 技術をどう理解しているか

この文章の目的

30分から1時間の面接で一緒に働きたいかを判断するのは難しいことです。私も経験を積んで学んできました。 まだ経験が浅い面接官に私が実践していることを伝えることでVOYAGE GROUP全体の判断の精度を上げていくのが目的です。

事実と意見を分けて説明できるか

圧倒的にこれは重要。これができない人はかなり厳しい。

  • 関わったプロジェクトのなかで、自身が一番活躍できたと思うプロジェクトについて聞く
    • 学生の場合は1人で個人的に作ったものでもいい
  • まずは事実を聞く
    • 質問の例
      • 「そのプロジェクトの目的、体制、使っている技術、あなたの役割、結果について教えてください。まずは事実だけを説明お願いします。」
    • ここで事実と意見を混ぜて話す人が少なからずいた
    • 事実と意見が混ざっているときは「意見はのちほど聞きますので、まずは事実だけを説明ください」のように促す
      • 勘のいい人はすぐ気づくが、人によっては何を指摘されたか理解できない人も・・・
  • 事実を元に意見を聞く
    • 質問の例
      • 「そのプロジェクトでよかった点はどんなことですか?」
      • 「いまふりかえるとどんな課題があったと思いますか?」
      • 「次のプロジェクトで活かせることは何かありますか?」
      • ここで自分の意見が全然出てこない人も・・・

※事実と意見を分けて説明するのがうまい人が書いた障害報告書は読みやすい

実際の課題を解決しようとしているか

  • 現在関わっているプロジェクトの課題を聞く
    • 質問の例
      • 「どんな課題がありますか?」
      • 「その課題を解決しないと何が達成できないのでしょうか?」
      • 「その課題を解決しないと誰が困りますか?」
  • その課題を解決するために何をどのように進めているのかを聞く
    • いまやってることが実現されると本当に課題が解決されるのか
      • 質問の例
        • 「いまやっていることは課題解決と直結していますか?」
        • 「自分だけが嬉しいのではなく、プロジェクトの課題が解決されますか?」
    • 解決されるまでのステップをできるだけ小さくしようとしているか、いきなり大きな話だけしていないか
      • 質問の例
        • 「ですよねー、技術的負債を返済したいですよね。とはいえいきなり全部を返済できないと思うのですが、最初のステップはどう進めますか?その最初のステップが完了したときに得られる効果は?」
    • 他のプロジェクトでうまくやっているやり方をそのまま持ってこようとしていないか、現在の環境にフィットさせるような工夫をしているか
      • 質問の例
        • 「他のプロジェクトでやってるそのやり方はよさそうですね。とはいえそのまま持ってくるのって難しいですよね。いまのプロジェクトと他のプロジェクトの違いってどの辺りでしょうか?その違いを踏まえて持ってくる時に気をつけてることってありますか?」

技術をどう理解しているか

  • 関わったプロジェクトで使った技術を聞き、それらの理解のしかたを確認する
    • プログラミング言語、OS、DBMS、フレームワーク、ミドルウェア、etc
    • 質問の例
      • 「どの技術が好きですか? どんなところが好きですか?」
      • 「その技術を選定した理由を教えてください」
      • 「その技術はどんな要件に合ってると思いますか?」
  • 実際のプロジェクトで導入してみたい技術を聞く
    • 質問の例
      • 「なぜ導入したいのですか?」
      • 「導入前に影響の少ない環境で試してみましたか?」
      • 「試した結果どうでした?」

編集後記

社内に下書きを公開したところ『この公開によって「面接対策される」みたいな懸念ってありますか?』と聞かれたので、『対策してきて、しっかりした受け答えができる人が応募してくれるのはウェルカムです!』と返答しました。

PR

focus.voyagegroup.com

focus.voyagegroup.com

focus.voyagegroup.com

focus.voyagegroup.com

focus.voyagegroup.com

KDD 2019, AdKDD 参加レポート

こんにちは @hagino3000 です。去年に引き続き今年もデータマイニングの国際会議であるKDDに参加してきました。本稿は主にアドテク及びマーケティング関連の発表に焦点を当てたレポートです。

www.kdd.org

Index

なぜKDDに参加するのか

私は研究職では無くエンジニアですが、広告配信システムの開発業務で参考にする論文の多くはKDDに投稿されたものです。去年のKDDで見聞きした発表もいくつかは自社サービスのビジネス設定にあわせてプロダクトに適用しました。さらにインターネット広告に関するワークショップであるAdKDDが毎年開催されるため、広告配信システムに関る者として効率良くインプットと議論ができる事が挙げられます。

広告分野以外の発表についても、Applied Data Science Trackは問題をどう解決したかのソリューション設計が肝であるため分野を問わず学ぶところが多くあります。

Tutorial Day

KDD 2019 | Lecture-style Tutorials

初日はTutrorial Day。去年はガラガラだったA/B Testのセッションが2つもあり、かつ部屋から人が溢れる程の人気ぶりに驚きました。A/B Testはメトリクスの選定からオンライン多重検定におけるFDR(False Discovery Rate)の制御[1]まで様々な話題があり、知れば知るほどその奥の深さに気づかされます。

Challenges, Best Practices and Pitfalls in Evaluating Results of Online Controlled Experiments Fundamentals of large-scale sequential experimentation

AdKDD 2019

2日目はWorkshop Day、私は目当てのAdKDDに参加しました。

2019 Papers and Talks | AdKDD 2019

AdKDD Workshopはインターネット広告に関する招待講演と論文発表で構成されます。SSPからDSPまで様々なプレイヤーの持つ課題、例えばオークションメカニズムの設計・RTB入札ロジック・コンバージョン予測・広告クリエイティブ審査の自動化・広告効果の因果推論・オーディエンス属性推定とトピックは多岐にわたります。全ての発表の紹介は書ききれないので、いくつかピックアップします。

Tencent Ads: Interesting Problems and Unique Challenges

最も印象が強かったのは、Tencentの広告プラットフォームにおける取り組みをまとめた発表でした。広告クリエイティブの自動審査や人間の手によるターゲティング設定を自動化するといった地味な運用の話があったと思えば、動画の中に広告オブジェクトをレンダリングするVideoIn Adsの紹介が始まると会場の空気が一変します。

f:id:hagino_3000:20190815142953j:plain
Tencent Ads: Interesting Problems and Unique Challengesより

これには私も凄すぎて言葉を失いました。光源処理等で広告オブジェクトがシーンに馴染むようにしているとはいえ、現段階ではまだ違和感があります。しかし後から差しこまれた広告かどうか見分けが付かなくなるのも時間の問題だろうと感じました。トーク全体を通して現代のフルスペックな広告配信プラットフォームはこうなると、甚大な研究リソースが投入された結果であろうその姿に圧倒されました。

From the Clouds to the Trenches: Learning to Manage the Marketplace

因果推論ネタで新しかったのは Microsoft Advertising, AI & Research が広告配信のパフォーマンス結果(e.g. ROI)が広告主の行動にどの様な影響を与えるかの実験です。上手くいけば広告主の広告予算が増えるようなポリシーを広告主毎に見つけて適用できます。CPAが低く取れている時は予定よりも早く予算消化して増額提案した方が儲かるんじゃないか、みたいな反実仮想を考えるわけですね。

実験にはセンシティンブなサンプリングが必要で、反応が似ているペアを作ってTreatment群とControl群に割りふる必要があるとの事でした。負の副作用も起りうる、非常に挑戦的な実験で手に汗握りました。

f:id:hagino_3000:20190815143546j:plain
From the Clouds to the Trenches: Learning to Manage the Marketplaceより

In-app Purchase Prediction Using Bayesian Personalized DwellDay Ranking

大企業の発表が目立つ中で、京大鹿島研とサイバーエージェントの共同研究「未インストールユーザーのうちアプリ内課金をするユーザーを推定する」が地味ながらも「これはゲームアプリの広告を配信する時に欲しいと言われる奴だ……」と思いながら聴講。アプリ滞在時間を使ったBayesian Personalized Ranking。

アプリ内課金データは少なくLTV予測の難易度が高いため、課金しそうな人ランキングの問題に帰着している所が使いやすく見えました。現場のニーズっぽいネタが研究テーマになり成果として出てくる所がリスペクトポイントです。

本会議

3〜5日目は本会議。私はApplied Data Science Trackを中心に聴講しました、その中で印象に残った発表を紹介します。

マーケティングにおける逆強化学習・逆最適化

NECの TV Advertisement Scheduling by Learning Expert Intentions はTVCMのスケジューリングを行なうシステムを作った話です。配置の制約が複雑だったりフィードバックが得られない事から、配置職人の作業結果ログを元に組合せ最適化の目的関数を学習して最適化するのが面白かったです。有識者の行動を正とする所だったり、結果の説明性が高い階層クラスタリングを利用している点は伝統的な日本企業を相手にする時に役立ちそうです。

SMOILE: A Shopper Marketing Optimization and Inverse Learning Engine は小売業における実店舗内のプロモーション、デモやフライヤー配布や値引きといったマーケティング活動のプランニング最適化フレームワークです。プロモーション自体の効果(Lift)の推定値は得られるものの、プロモーション効果値と実際のプランニング(シーケンシャルな意思決定)を繋ぐ部分は複雑であるため、意思決定の部分は逆強化学習を用いて過去のプランナーの配置結果から学習するとあります。

人間の意思決定を模倣するパラメータを学習する方策は様々な応用が利きそうで注目しています。

マーケットデザイン

例えばある財を配布するのに「早い者勝ち」にするのか「抽選」にするのか「オークション」にするのか様々な手続きが考えられます。この様な手続きの中で効率が良く・生み出される価値が大きくなるものを追求する分野がマーケットデザインです。Two-Sided Fairness for Repeated Matchings in Two-Sided Markets: A Case Study of a Ride-Hailing Platform はライドシェアリングにおけるドライバーと乗客のマッチングアルゴリズムで公平性を考慮するものです。マッチングアルゴリズムは参加する人々に与えるインセンティブを変え、人々の行動を望ましい姿にする力があります。私は業務設計や値付けの際に役立つので好きな分野の1つです。

羅生門効果 (Rashomon effect)

講演を聞くまで知らなかったのですが、機械学習の分野で同じ予測を行えるモデルが複数存在する事をRashomon effectと呼ぶそうです。同じ予測性能が得られるのならばより単純なモデルを見つけて採用したい、これを行なうための方法論が最終日のKeynoteセッションに登場しました。

参考:A study in Rashomon curves and volumes: A new perspective on generalization and model simplicity in machine learning

PID制御でRTB入札最適化

DSPの広告配信システムで Bid Optimization by Multivariable Control in Display Advertising が制約にクリック1回あたりのコスト(CPC)を持つ入札金額最適化問題をシンプルなソリューションにしていました。クリック1回あたりのコストというのはオークションに入札して勝利して広告が表示された後さらにクリックが発生してようやくわかる値、遅れて得られる値です。行動(オークション入札)の後しばらくして充足しているか違反しているかわかる制約のためソルバーで静的に解ける問題ではありません。

f:id:hagino_3000:20190815144902p:plain
クリックあたりのコストと予算制約の元で獲得コンバージョン数を最大化する

これをPID制御で行なう事で非常にシンプルなソリューションになっています。オークションの入札最適化にはよく「いくらで入札したら何%で勝てるか」の勝率関数を利用します[2]。これを求めるタスクを入札ランドスケープ予測と言いますが、彼らのソリューションには登場しません (勝率無しでモデリングしている)。またこれだけで予算消化額の制御とCPCの制御が同時に出来る所が凄いなと思いました。

f:id:hagino_3000:20190815143424p:plain
Bid Optimization by Multivariable Control in Display Advertisingより

ランダムに出現しては消える蟹

四日目夜の懇親会では蟹が出ました。蟹が無くなると補充されるものの、補充された途端に人が集り蟹が消えてしまうので観測が非常に困難でした。

f:id:hagino_3000:20190807200206j:plain

全体の感想

強化学習の実用例が増えたなという印象です。Cost Per Clickの様な短期指標ではなく、広告主の長期的な指標に寄与する意思決定を行なうのに適しているとされます。自分のチームでもシミュレーターの開発からになりますが取り組みたいです。

あと開催地のアラスカは非常に涼しく、昼が長く22時を越えても明るかったので快適に滞在できました。


[1] サンプルサイズと有意水準を事前に固定して行なう古典的な仮説検定の設定とは異なるため

[2] 約定金額の分布を連続な確率分布で近似すると目的関数が扱いやすくなる。また約定金額の分布の累積関数は入札金額に対する勝率になる。