Zoomでオンラインイベントをテレビ番組っぽく配信するためにやったこと(機材編)

 こんにちは。社内でWebアプリケーションエンジニアをしつつ、社内の音響サポートしている @brtriver です。

 VOYAGE GROUPのAJITOでZoomを使ったオンラインイベントを何度か開催しましたが、その中の1つの日本CTO協会( https://cto-a.org/ )が主催する会員限定のイベントで実際に配信で利用した機材、設定で工夫した内容についてせっかくなのでまとめてみたいと思います。*1

cto-a.org

 このオンラインイベントでは全員が個別にZoomに参加するのではなく、発表者はオフライン会場であるAJITOに集まりその様子をZoomを通して配信する形式で開催しました。

f:id:brtRiver:20200329155557p:plain
オフラインの会場の様子

4行でまとめると

  • Zoomは他のプラットフォームに比べても音質が良い。ただし癖も有り
  • できるだけソフトウェアではなくハードウェアに頼る。ATEM mini はコスパ最強
  • スライドはカメラ越しではなく直接取り込み文字を鮮明に読みやすく
  • できるだけ継続可能なためにシンプルな機材構成を目指そう

*1:本記事は機材やソフトウェアについての説明にフォーカスしていますが、実際はイベントの運営方法にも工夫が必要だと実際にやってわかりました。この運営方法の課題や工夫についてはまた別の記事で話ができればと思います。

続きを読む

技術力評価会の社外評価者とふりかえりを実施しました #voyage_tech

こんにちは。 最近技術広報ぽいことに関わり始めた @tan2 です。

さて、VOYAGE GROUPでは「技術力評価会」というチームを横断したエンジニアの能力評価を2011年から継続的に実施しています。合わせて、都度ふりかえりも行い改善も繰り返しています。

speakerdeck.com

技術力評価会の取り組みのひとつとして、2017年からは通常の社内評価者2名に加え、社外の強いエンジニアを招聘し評価に加わっていただくというやり方に挑戦しています。 評価者を社外からも招聘する狙いとしては、以下のようなものがあります。

  • 社内で人数が少ない技術領域では、評価者/被評価者の組み合わせのパターンが少ない。社外から識者を招聘することで、新しい視点や気づきが得られる機会を増やしたい。

  • 技術力評価会を数年実施することで、社内での価値観が擦り合ってきた。それ自体は良いことだが、タコツボ化していくリスクもある。社外の目を入れることで、自分たちでは気づけないバイアスを知りたい。

今回は外部評価者のみなさまを交えて、技術力評価会のふりかえり & 打ち上げを実施したので、その様子をレポートします。

今回招聘した社外評価者のみなさま

  • 中山 心太さん/tokoroten (株式会社NextInt代表) Twitter GitHub Medium
  • 小林 篤さん/nekokak (株式会社ディー・エヌ・エー 常務執行役員 CTO) Twitter GitHub
  • 星 北斗さん/kani_b (クックパッド株式会社) Twitter
  • 松館 大輝さん/d_date (株式会社カンカク) Twitter
  • 佐藤 鉄平さん/teppeis (サイボウズ株式会社) Twitter GitHub
  • 小林 徹さん/koba04 (サイボウズ株式会社, 株式会社SmartHR) Twitter GitHub
  • 新原 雅司さん/shin1x1 (1×1株式会社 代表取締役) Twitter GitHub

社外評価者とのふりかえりで出たKeep/Problemの一部

  • Keep
    • 事前資料や GitHub リポジトリなど情報が事前に公開されていて、最終成果だけでなく、その過程を見ることができたのは良かったです。
    • 対象者以外の評価会にも参加出来たのはよかったです。人によって違うなぁという印象も受けたので
  • Problem
    • 外国人の方の評価は、日本語の問題なのか、アウトプット能力の問題なのかが分からなかった。
    • 遠方からの参加だとホテルの手配などがあるので、早めにスケジュールが分かると嬉しかったです!
    • 評価会のテンプレートがデータ分析者にはイマイチ感。試行錯誤の過程、意思決定のながれが表現できるテンプレートを用意したほうがよさそう
    • 同じ技術横断で最新の技術や問題を共有できる場があるとよさそう
    • プレゼンテーションの技術力がダイレクトに響くのは本質的ではなさそう
  • Memo/雑感
    • 外国人の方の評価は、外資企業で働く日本人or外国人を評価者に当てたほうがいいんじゃないのか?ネイティブじゃない企業で働くとはどういうことか、というのを語れる人を連れてきてほしい
    • 棚上げ力大事。被評価者にとって良いなと思うことは伝えるようにしました。
    • 32. 技術力評価会の現場(brtriver) | PHPの現場@brtriver さんと技術力評価会について話しました(宣伝)
Problemに対して今後どうしていくか

出たProblemに対して、早速こんなお話がされていました。

  • テンプレートは最近新しく増やしたものの方が適切だったので、今後はそちらの利用を促していくことに。
  • これをきっかけに、技術横断の取り組みとして、iOSの最新技術に関するSlackチャネルが作られ、勉強会が開催されるようになりました。
  • プレゼンテーションのスキルについてはCTO @makoga過去にnoteに書いていました。このように考え、今後も改善していきます。

ふりかえりの様子

f:id:tan2jpn:20200221182126j:plainf:id:tan2jpn:20200221182238j:plain
会場は社内BARのAJITO
f:id:tan2jpn:20200221182704j:plainf:id:tan2jpn:20200221182725j:plain
そのまま打ち上げへ

社外評価者の方と Podcast: ajito.fm でも語っています。興味のある方は是非聞いてみてください。

次に向けて

引き続き社外から評価者を招聘したいと考えています。我こそはという方は、是非 VOYAGE GROUP CTOの @makoga までお声がけください。

デブサミ2020登壇資料を公開しました。

また技術力評価会ネタかよ!と言われそうですが、デブサミ2020で登壇しました、 @makoga です。

デブサミのテーマが「ともにつくる」だったので、一般的な企業では1人で実施していることが多いけど、VOYAGE GROUPでは「ともにつくる」ようなことって何があるかなと考えました。まっさきに思い浮かんだのが技術力評価会でしたが、もう何回かプレゼンし、資料も公開してるしなーと思いました。ただ、これまでは始めたきっかけや仕組みの説明が中心だったので、評価者がペアであることにフォーカスすれば今までとは違った切り口になるかなと考え、セッションに応募し、めでたく当選しました。

speakerdeck.com

この資料の流れとしては、まず最初にエンジニアの技術力が難しい原因を4つ説明してます。

f:id:voyagegroup_tech:20200227145137p:plain
エンジニアの技術力評価が難しい原因

その後、3つのPartで考え方、仕組み、効果などについて説明してます。

f:id:voyagegroup_tech:20200227145243p:plain
Agenda

Part1では、評価制度と人事制度ということで、等級制度(グレード制度)、評価制度、報酬制度、それぞれの説明と関係性を説明してます。

f:id:voyagegroup_tech:20200227150304p:plain
評価と人事制度

Part2では、技術力評価会の概要を説明してます。ここは今までに公開した資料を読んだことがある人はざっと目を通しておさらいするくらいでいいかと思います。

f:id:voyagegroup_tech:20200227150333p:plain
2年間で8人から評価される

Part3では、評価者がペアであることの効果、ペアの組み合わせが変わることによる効果について説明してます。事前に技術力評価会の評価者を経験した人にアンケートをとったので、その結果も記載してます。

f:id:voyagegroup_tech:20200227150407p:plain
ペアで評価することで、バイアスは減ったと思いますか?

登壇後のAsk the speakerには7人も来てくれました。各社それぞれの悩みがあり、それを聞ける場があるのは嬉しいですね。

まだ技術力評価会ネタにニーズがあると感じたので、機会があればまた違った角度からの情報を公開していきたいと思います。

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 でドリンクを飲みながらダベること。業務で詰まっているところをチームを越えて相談したり、どうでもいい話をしたりすることがある