2年目エンジニアが新卒に贈る成長のコツ

こんにちは、VOYAGE MARKETING新卒2年目エンジニアのかいくんです。
去年、ビジネス視点を持ったエンジニアになるためにVOYAGE GROUPに入社しました。入社後は新設されたアプリチームに配属してもらい、アプリ開発未経験ながら気合でアプリを開発してきました!

今回は僕が入社後に学んだ成長のコツを紹介していきます。

目次

仕事内容

僕が開発しているアプリはECナビアンケートです。
アンケートに回答するとポイントが貯まって、現金やAmazonギフト券などに交換できるサービスです。

ECナビアンケート

ECナビアンケート

  • EC Navi Apps
  • ライフスタイル
  • 無料
apps.apple.com

このアプリはディレクター2人、エンジニア3人、デザイナー1人の計6人で開発しています。

仕事はミーティングから始まります。ミーティングではチーム全員で何に取り組むかについて話し合います。 エンジニアやデザイナーであっても売上やユーザー動向を把握して、機能や案件の提案を行っています。 取り組む内容が決まったら仮説を立てて検証を行います。 そして検証結果を元にまたミーティングを行うという流れで進めています。

f:id:Kai-kun:20200428172125p:plain:w400

2年目エンジニアが新卒に贈る成長のコツ

事業を理解しよう

提案や方針に対して意見を言うには、事業の理解が必要です。

僕は新卒エンジニアであっても提案や方針に対して意見が言える環境にいました。 そのため「バンバン意見を言って活躍するぞ!」と気合を入れてミーティングに参加していました。 しかし、ミーティングで意見を言うのは簡単ではありませんでした。

それはチームが置かれている状況、業界やユーザーの動向など事業についての理解がなかったからです。 例えば、売上増加を目標としたミーティングでは何をすれば売上が伸びるのかわからず、全く意見が言えませんでした。

そんな僕が事業を理解するために行った2つの取り組みを紹介します。

1. 表・グラフ・ログを確認する

サービスの開発や運用に携わっている方は業界やユーザーの動向を知るために、日々何かの表やグラフ、またはログを確認しています。これらを確認すれば事業の理解を深められます。

例えば僕のチームのディレクターは、スプレッドシートに売上項目を分類して、項目ごとにユーザー1人当たりの売上の目標と実績をまとめています。 このスプレッドシートを確認すると、影響が大きい売上項目や、目標と実績が乖離している売上項目がわかります。

このような売上に関する情報があれば、売上増加を目標としたミーティングで、より売上に影響のある提案ができたり、目標と実績の乖離について質問して議論を活発化することができたと思います。

表・グラフ・ログを確認して事業の理解を深めましょう。

2. 目標と指標が選ばれた背景を知る

仕事には目標があります。そして目標が達せられたか判断するために指標を定めています。 目標と指標が選ばれた背景を知れば、事業の理解を深められます。

例えば僕のチームでは、ユーザー1人当たりの売上増加を目標としています。そしてアプリリリース後の最初の指標は「長期にわたってアプリでポイントを獲得しているユーザー数の増加」でした。

最初の指標を「長期にわたってアプリでポイントを獲得しているユーザー数の増加」としていたのは、アンケート回答による売上は少ないため、長い間サービスを利用してくれなければユーザーを獲得するためにかかった費用が回収できないからです。 このような背景を知っていれば、売上増加を目標としたミーティングで、直接売上を伸ばすための提案だけでなく、ユーザーを獲得するためにかかっている費用を下げるといった違った視点で意見が言えたかもしれません。

目標と指標が選ばれた背景から事業の理解を深めましょう。

優先度を決めて取り組もう

やりたいことがたくさんあるのに対して、やれることはとても少ないのです。 何が必要なのかを判断して優先度を決めて取り組みましょう。

優先度を決める時は、指標やサービス価値に対する影響の大きさを考えると良いと思います。 指標を達成するためには影響の大きい課題から取り組みます。 またサービスでエラーが起きた場合は、サービス価値に及ぼす影響の大きさで取り組む優先度を判断します。

入社したての頃の僕は「すごい新卒だと思われたい」「良いサービスを作りたい」「コードを綺麗にしたい」という気持ちに溢れていました。 そのため「コードが微妙だから新しい書き方にリファクタリングしたい」「放置されているエラーを直したい」といった感じで、目についたものに片っ端から取り組もうとしていました。

しかし片っ端から仕事に取り組むのはよくありませんでした。 取り組める仕事は限りなくあり、終わらないからです。 また無駄な仕事に時間を使って、必要な仕事ができないのは本末転倒です。 先輩にはよく「それは今やらなくて良いよ」と注意されていました。

特に優先度を決める必要を感じたのはアプリのリリース前です。 アプリをリリース予定日までに使えるようにするため、サービス価値に影響の大きい機能を優先的に実装しました。 例えば、会員登録機能やアンケート回答機能です。 デイリーコンテンツや広告といったサービス価値への影響が比較的小さいものは、初回リリース時の実装から省きました。

影響の大きさから何が必要か判断して、優先度を決めて取り組みましょう。

コードレビューで質問しよう

コードレビューで成長するコツは、なぜそのようにコードを書いたのか質問することです。

できるエンジニアの設計には意図があります。 それは責務の分け方、状態や依存の管理の仕方、将来の拡張や運用を反映した設計など様々です。
コードレビューをする際は、そのコードが問題なく動くかを確認するだけではなく、なぜそのように書いたのか?と疑問を持ち、開発したエンジニアと議論を交わすことで成長できると思います。

取り組む課題が大きい、開発期間が短いといった時に、新卒の自分にできる仕事がないこともありました。
「できる仕事がなくて悔しい!でも成長しなければできないまま。」
「やることがなくて、どうしたら良いのかわからない。」
そんな辛い時期もあります。
そういう時は先輩のコードレビューを通じて成長できました。

例えば、どれだけコードを作り込むかはその時々で判断するべきだと学びました。 すぐに削除されるコードであれば、無駄にクラスを分ける必要はないでしょう。if文を追加するだけの最低限の実装とテストで良いかもしれません。またコードが今後どのように改修されるかわかっていない場合は、理解しやすいようにシンプルに実装した方が良いと思います。間違って抽象化されたコードは分かりづらく改修しにくくなってしまうからです。

このようにコードレビューから様々な設計を知り、新たなコードの書き方を身に付けられます。

まとめ

今回は僕が入社後に学んだ成長のコツを3つ紹介しました。

  • 提案や方針に対して意見を言うには事業を理解している必要があります。事業に関する数値や、目標と指標の背景から事業の理解を深めましょう
  • やりたいことがたくさんあるのに対して、やれることはとても少ないです。影響の大きさから優先度を決めて仕事に取り組みましょう。
  • できるエンジニアの設計には意図があります。コードレビューの時はなぜそのように実装したか質問して吸収しましょう。

入社からの1年はあっという間でした。 様々な経験をさせてもらい、たくさんの学びがありました。 そして経験や学びの分だけ、成長や挑戦の機会がありました。

答えのない課題に対して、チームで考え、行動していくのは非常に面白いです。 失敗を恐れず、引き続き頑張っていこうと思います。

ニッチすぎる!?知られざる広告JavaScriptの世界

こんにちは。雨宮(@rail44)です。
普段はヨーヨーやポケモンに興じるかたわら、株式会社fluctで広告配信システムの開発を担当しています。

fluctは広告業界ではSSP(Supply-Side Platform)と呼ばれる立ち位置で、インターネットメディアの収益の最大化にフォーカスした事業を行っています。
私たちのシステムを使うと、広告によるマネタイズが面倒な運用無しに出来る。といったイメージです。

この記事では、自分が直近で担当をしている広告の配信スクリプトと、普段注目されづらいその裏側について書いていきたいと思います!

広告タグの構造

さて、webページに広告を表示したい場合、アプリケーションはHTMLで記述されているため、広告もHTMLタグの形でお渡しすることになります。
(※fluctではモバイルアプリや動画プレイヤーへの広告配信も行っており、それらの場合はHTMLではない納品形態になっています)

シンプルな物で一例を示すと以下のようなHTMLタグになっています。

<!-- A: 表示領域 -->
<div class="hoge"></div>

<!-- B: 広告配信スクリプト -->
<script type="text/javascript" src="https://pdn.adingo.jp/p.js" async></script>

<!-- C: 広告表示コマンド -->
<script type="text/javascript">
  var fluctAdScript = fluctAdScript || {};
  fluctAdScript.cmd = fluctAdScript.cmd || [];
  fluctAdScript.cmd.push(function (cmd) {
    cmd.loadByGroup("hoge-group")
    cmd.display(".hoge", "hoge-unit");
  });
</script>

タグの構造をざっくり分類すると、
A: 表示領域となるdiv要素
B: 外部のJavaScriptを読み込むためのscript要素
C: IDを用いて広告の読み込みや表示を指示するscript要素
といった作りになっています。

ここで、途中で読み込んでいる、B が広告配信スクリプトと呼んでいるJavaScriptとなります。
サーバーへの広告リクエストの発行、広告のレンダリングやスタイリング、各種イベントのトラッキングなどが責務となっています。

さて、このJavaScriptをガシガシ開発していくわけなんですが、広告以外ではなかなか遭遇しないような制約が数多くあるので紹介していこうと思います。

広告ならではの制約

動作するブラウザが限定できない

一般的なwebサービスではターゲットとなるユーザーから、動作環境を想定した上で開発が行われます。
たとえば、スマホユーザーが主体であればiOSのSafariとAndroidのChromeをサポート範囲とすれば大部分をカバーすることができます。

しかし広告システムとなると、様々なwebメディアへと導入されることになるので、広告配信スクリプトはサポート範囲として最大公約数を目指すことになります。

実際、現在のfluctでは、数バージョン前のInternet ExplorerやSafari、つまりPromiseやArray.prototype.forEachが無い世界でも動作するような作りになっています。

Polyfillは(素直には)使えない

動作するブラウザを広くするためには、Polyfillを用いて未実装な機能を補完するという解決策が多く用いられます。
今日ではbabelからcore-jsを使う方法が一般的でしょうか。 [参考]

ところが、これも広告配信スクリプトでは工夫をして導入する必要があります。
なぜなら、広告を表示したいwebアプリケーションへ既にPolyfillが導入されていた場合に、衝突してしまう危険性があるためです。

エラー処理を緻密に行いたい

Polyfillが使えないのと同じような理由で、ランタイムエラーの検知をするのにwindow.onerrorのような手法は使えません。
自分達のシステムとは関連しない、メディア側や導入されている別の広告プロダクトのエラーも検知してしまうためです。

そのために、エラーが発生してもそれをthrowするのではなく、ScalaでいうEitherやRustでいうResultのような構造を用いることが優先されます。
また、想定外のランタイムエラーを検出するためにスクリプトの全体をtry-catch句でラップすることになりますが、window.setTimeoutのような、一旦ブラウザのランタイムへコンテキストが戻ってからコールバックされるような物はcatchができないことに注意する必要があります。

try {
    window.setTimeout(() => {
        throw new Error("hoge"); // Unable to catch!!
    }, 0);
} catch (e) {
    console.log(e);
}

ですが、すでに述べた動作させたいブラウザやPolyfillの制約によりPromiseは使えません!

広告の表示は出来るだけ速くしたい

速くしたい、というのは通常のアプリケーションでもあたり前な話なのですが、広告についてはより顕著です。
多くの広告がインプレッション(表示回数)やクリックされた回数を元に利益の計算がなされるため、表示が遅くユーザーの目に留らないようでは無意味となってしまいます。

メディアの動作とは互いに影響し合わないようにしたい

広告の表示が遅れてしまっても、メディア自体の表示が遅れないように。もしランタイムエラーを起こしてもメディアが動作しなくなることは避けなければなりません。
また、メディア側で用いているフレームワークによって広告表示が出来なかったり、といった事を避ける必要があります。
しかも、ここでもフレームワークの種類やバージョンに始まり、メディアの作りは千差万別です。

以上から、スクリプトの全体的な動作を非同期的に行う必要があります。
先ほどの広告タグの作りにも、その一端が現れているのが分かるでしょうか。

とはいえ、書き味はモダンにしたい

var Ad = function (hoge) {
    this.hoge = hoge;
};

Ad.prototype.load = function () {
    ...
};

なんて2020年に書きたくないんじゃ!!(突然の発狂)
言語オタクとしてはプロトタイプベースの言語はとても可愛いゲがあって良いんですが、チームでメンテナンスをしていくことを考えると辛すぎます。

非同期エラー処理をするにしても、

function setTimeoutWithCatch(cb, errCb, msec) {
    window.setTimeout(function () {
        try {
            cb(e);
        } catch (e) {
            errCb(e);
        }
    }, msec);
}

とか作りたくないんじゃ!

どう戦うか

これまでの制約をまとめると、広告配信スクリプトの要件はこんな感じになってしまいます。

Promiseが無く、Polyfillも使えない環境下で非同期に動作する、読み込み/実行が高速なJavaScript
(日々の開発の負担は減らしたい)

:sob:

この要件への立ち向い方は色々ありそうですが、現在のところ、

  • 最低限のPromise風のsyntaxが使えるオブジェクトを手製
  • そのPromiseLikeなオブジェクトを使ったモジュールローダーを手製
  • 手製のモジュールローダーを使うようなJavaScriptの成果物となるよう、バンドラであるRollupを使ったビルドシステムを整える

などといった取り組みを行っています。

Promise風のオブジェクト

今回のケースでPromiseが使えるようになると何が嬉しいかというと、コールバック関数をラップする、といった辛さのあるエラーハンドリングの回避が出来る点が最も顕著でした。
そこで、それなりの大きさがあるfull-featuredな代替実装を使うのではなく、素朴な .then/.catchを実現できることのみにフォーカスした、小さなPromise風オブジェクトを実装しPonyfill的に運用しています。

Ponyfill

import { PromiseLike } from "./promise"

function delay(msec: number): PromiseLike<void> {
  return new PromiseLike((resolve) => {
    setTimeout(() => resolve(), msec);
  });
}

のように、Promise風オブジェクトを使う部分で明示的にimport文を書くことで、モジュール内のスコープでのみその恩恵を受けることができるようになります。
また、このPromiseLikeには .catch がなされていない例外のスローが起きた時のハンドリングを実装しているので、想定外のランタイムエラーをログ収集基盤で検知することも実現できました。

(なお、TypeScript自体に PromiseLike<T> 型が存在していて、import無しだとそちらと見做されてしまう問題には後から気付き、対応予定というのはあります……)

モジュールローダー

AMD形式のモジュールを動的に読み込むモジュールローダーも自前で実装しています。
モジュールローダーへ求められる要件としては

  • Internet Explorerで動作する
  • 用いるPromiseの実装を上記の物に切り替えることのできる
  • グローバルではなく名前空間を持たせてモジュールの定義や展開ができる
    • これもPolyfillと同様、Webメディアのモジュールローダーとの衝突を避けるため

といった物で、このようなモジュールローダーは自分で書かなければ存在しませんでした。
AMDの仕様へ準拠しつつ、広告商材の配信頻度からimportする可能性の高いモジュールはエントリポイントとなる単一のJavaScriptへバンドルし、そうでない物は外部モジュールとしてビルドする、といった私たちのビジネスの構造に特化した実装をしています。

ビルドシステム

ここまで見てきた通り、広告スクリプトは通常のWebアプリケーションの構成とは大きく異なっています。様々なWebページからロードされ、その機能が利用されるといった特徴から、アプリケーションというよりライブラリに近い特性を持っていると言えます。
そこで、Webアプリケーションのバンドラとしてデファクトスタンダードと言えるWebpackではなく、npmモジュールのビルドでよく用いられているRollupを採用しています。

また、モジュールの分割の制御や独自のモジュールローダーの採用の必要から、RollupのCLIを直接使うのではなく、Rollupをライブラリとして利用するビルドスクリプトを記述してビルドを行っています。
言及が遅れましたが、TypeScript、ESLint、Terserといったモダンなツールチェインが使えるような環境も実現できました。

まとめ

ニッチな話題が続きましたがいかがでしたでしょうか。

class構文、const/let、Promise、async/awaitなど近年のJavaScriptの進化は目覚ましく、類を見ない先進的な構文を持った言語になりつつあります。
その書き味や開発のしやすさを維持しつつ、上記のような制約を満たすためのビルドシステムやモジュールシステムを作り込むのは、大変ですがエンジニアとして非常に魅力的な課題です。
また、Web上のトラフィックで少なくない割合を占める、広告の表示で高速化や省サイズを実現することはインターネットそのものに寄与することのできる取り組みでもあります。

今回の記事では割愛していますが、CIとLambda@Edgeを組み合わせた検証環境などのトピックもあるので、別の機会があればまだまだ話が出来そうです!

株式会社fluctでは、こんなニッチなJavaScriptで広告をよりよくする仲間を募集しています!

株式会社fluct SSP開発本部 ソフトウェアエンジニア | 株式会社VOYAGE GROUP
株式会社fluct SSP開発本部 シニアソフトウェアエンジニア | 株式会社VOYAGE GROUP
株式会社fluct SSP開発本部 ソフトウェアエンジニア(沖縄勤務) | 株式会社VOYAGE GROUP
株式会社fluct SSP開発本部 クライアントサイドエンジニア | 株式会社VOYAGE GROUP

CTOが聞く Vol.1 「アドプラットフォームと屋外広告、新レポート基盤」

VOYAGE GROUPのエンジニアにCTOが「最近は何やってるの?」と聞いていく連載の第1弾です。今回はブランド広告主向けアドプラットフォーム「PORTO」などを開発しているせんちゃんに話を聞いてみました。

f:id:voyagegroup_tech:20200408175118p:plain
Google Meetでのインタビュー風景

目次

渋谷のデジタルサイネージにテスト用の広告を配信した

(CTO) 最近は何やってるの?

(せんちゃん) 1月から2月あたりはDOOH(Digital Out of Home:デジタル屋外広告)の対応やってました。

(CTO) ああ、PORTOのやつね。 voyagegroup.com

もう配信してるんだっけ?

(せんちゃん) テスト用の広告は配信しました。実際に渋谷の某所にあるデジタルサイネージに表示されたときは嬉しかったですね。

(CTO) DOOHでRTB(Real Time Bidding)するときって、ブラウザとかアプリに広告配信するときとの違いってあるの?

(せんちゃん) 広告配信を個人に行うか、大衆に行うか、が大きな違いですね。従来のデバイスにおけるRTBでは、それを利用している個人に対して最適な広告を配信していました。一方、DOOHだと同時に見ている人がたくさんいるので、異なった配信ロジックが必要となります。技術的には、1回のBid Request(入札リクエスト)に対してN人の扱いをするようになったのが大きな違いです。またDOOH特化のパラメータとしてトータル人数、世代などが渡って来るので、新しいターゲティングも可能となりますね。

(CTO) なるほど、今後が楽しみだね。

(せんちゃん) はい。DOOHにとどまらず、ConnectedTV(インターネットにつながったTV)など、スマホ・PC以外の広告媒体への配信が国外では盛り上がってきています。僕達も様々な媒体を通じて広告を届けられるようになっていきたいですね。

最初はRDBでもよかったけど、データレイクが必要になってきた

(CTO) その他にはどんなことをやってるの?

(せんちゃん) アドプラットフォームだと、速報系のレポートや月次で締めたレポートなど複数のレポートがあります。今は毎分集計したデータをAmazon Auroraに格納して、そこから1時間ごとの集計データを生成してそれをAmazon Auroraに格納してとやってるものがあります。最初はデータ量が少なくこれでも問題なかったのですが、最近は集計・クエリともに時間がかかるようになってきました。

また、レポートとして必要となるデータはビジネスの拡大とともに変化していきます。レポート軸の追加は大変な作業ですし、そもそも集計済みのデータに関しては異なる軸で集計し直す事はできません。

これらの経験を生かして、レポートのデータ構造がサービスの発展を阻害しないような仕組みにしていきたいと考えています。ログとレポートを疎結合にするために、データレイクのアプローチが取れるのではないかと技術調査を進めているところです。クラウドベンダーが提供するソリューションの進化はめざましく、インプット量は多くなりますが「こんなことも可能なのか」とワクワクさせられますね。

(CTO) 10年前は大規模データを分析するために高価なDWHアプライアンスを買ったんだけど、今はクラウドサービスからいろいろ提供されてるよねー。なんて良い時代だ。

データを多角的に見れるようにする

(CTO) あとは、最近やっていきたいと思ってることはある?

(せんちゃん) データをもっと扱いやすくしたいです。たとえばうちのチームはGoogle BigQueryを使っているのですが、これはもともとデータ分析チームが分析用に構築したものでした。

これが大変便利で、広告配信サービスプロダクトでも少しずつ利用するようになっていったんですね。その結果、分析基盤への修正影響範囲が広い状態になってしまいました。ここは改めて、用途に合わせて切り分けていく必要があると感じています。

生ログはS3にためておき、レポート集計用途にRedshiftを据える、アドホックな調査にAWS glue + Athenaを用いる、速報系に Kinesis Data Analytics + QuickSightを用いる、など。同じ「データを見る」という行動でも、コンテキストに合わせて多角的に切り込むことができる基盤を作っていきたいですね。

まとめ

(CTO) スマホ・PC以外への広告配信や、圧縮しても数テラバイトになるデータが毎日増えていくデータ基盤の整備など、いい話が聞けました。

さて、次回は誰に聞こうかなー

[PR]

せんちゃんのチームでは一緒にプロダクトを成長させていく仲間を募集してます。

hrmos.co

話して気づいた最上位エンジニアズの共通点

こんにちは、VOYAGE MARKETING新卒2年目エンジニアのayakaです。

VOYAGE GROUPの人事評価制度では、事業貢献・能力・クリードによりグレードが決まるのですが、先日最上位グレードであるE4エンジニアの方々と一緒にお話をする機会をいただきました。今回は、その場で自分が思っていたこと、気づいたことをしたためたいと思います。

目次

この記事の用語集

この文章の元ネタは、2020年2月に社内に公開したものになります。社内用語が多いため本題の前に用語と登場人物を解説します。こちらを見ながら読み進めてください。

グレード・E4

グレード制を採用しており、事業貢献・技術力評価会の内容を加味した能力・VOYAGE GROUPとして大切にしたい行動指針のクリードの観点からグレードが決まります。グレードは下記の4段階で最上位がE4になります。

f:id:satomin35y:20200407101037j:plain 詳細はこちら:5分でわかる技術力評価会 / understanding voyagegroup's technology assessment in 5 minites - Speaker Deck

VOYAGE MARKETING

利用者数日本最大級のポイントサイト『ECナビ』やポイント交換サービス『Pex』などを運用するVOYAGE GROUPのグループ会社。筆者ayakaはVOYAGE MARKETINGの新卒2年目社員。

株式会社VOYAGE MARKETING | 貴社サービスの顧客エンゲージメントを支援します

fluct

日本最大級のSSP「fluct」をはじめ、メディアのマネタイズを支援するグループ会社。 記事に登場するもっちーさんはfluct CEO、E4エンジニアとしてとみーるさん・あじよしさん・ようこうさん・すずけんさん・西郡さんが登場。

株式会社fluct ‐ 日本最大級SSP「fluct」を運営

きっかけ

E4エンジニアズとのんだきっかけは、去年のVOYAGE MARKETINGの忘年会の2次会にfluctCEOのもっちーさんが来てくださったとき。 エンジニアの話になった際、VOYAGE MARKETINGには現在E4がいないので、そのレベル感が全然わからないと話をしました。

VOYAGE GROUPで働いていると「E4の人たちってすごい!」というような話は至るところで耳にします。ですが、自分の見解としては、何がすごいのか純粋にわからない、がありのままの意見でした。

ここで注釈しておきたいのは、一緒に働いたこともなければちゃんとお話したこともない、仕事内容も知る機会がない、=何がすごいのかわからないという意味です。決して挑戦的な意味ではないので言葉のインパクトの強さはご容赦ください。

みんなが口を揃えて絶賛するその凄さに自分も触れてみたいと思ったし、VOYAGE GROUPのトップエンジニアとされている人たちが普段どういう思考で、どういう目線で働いてるのか純粋に興味がありました。

その話をしたところ、それなら直接話しちゃえよ!呼んだから! とおもむろに予定が作成されE4エンジニアズとののみに至ります。

学んだこと

  • とみーるさん(@tomita)は忍者大会で14位だった

   2年連続で優勝した人は心眼の使い手で、意味不明の領域だったそう(わかる)

  • あじよしさん(@ajiyoshi)は生まれたときからE4説

  • ようこうさん(@beaconsco)はディスプレイの文字が小さいらしい

  • すずけんさん(@suzu_v)は唯一の新卒E4

  • 西郡さん(@_nishigori)はSREイベントでfailover

え?学んだことってそれ?と思われる(でしょう)ほど、上記だけで伝わったと思うんですが、ほんわかした会をさせていただきました。もちろん、お仕事の話とか、プログラミングの話とか、歴史の話とか、色々させていただいたんですけど、割愛します。

そして、E4の人たちってここが共通してるかも?と思ったことがあります。これは書くか迷ったんですが、以下の理由で書いておきます。

言語化するのが難しいことなので、選んだ言葉がフィットしてる感じは今もありません。そもそも人を言葉で語るのは無理ゲーですし、そういったことを文字として起こすとそれとして意見が固定されてしまうので苦手です。なのでこれが全てと思わず、雰囲気として伝われ!の気持ちを込めて記します。

  • 好奇心がすごい

  • 良い意味でこだわりが強い

  • 理解力が高い

  • 話にストーリーがあり論理的でわかりやすい

  • 話のキャッチアップの速度&範囲が広い

  • 話してる最中でも常にアンテナが張られている

  • 凄いと思っていないナチュラルさ

  • 周りを見る力

  • 察する力

これ一つひとつにどの時にそう思ったか、なぜそう思ったか、はちゃんと浮かぶのですが、書ききれないのでこの場では一言で終わらさせてください。

話せば話すほど、何者だ?????????? って感じになり、そりゃそうなんですが数時間話しただけではまだまだ足りないし語れません。

ただ、話をしているとき、相手が今の話を理解できてないなと気付いたり、それに気付いたとき体系的に話をしてくれ、その説明がめちゃくちゃわかりやすかったり(現に細かいことを知らなくてもなんとなくわかった)、 1つの話をするとそれに関していろいろな可能性が浮かんできてそこからの話の広がり方が凄かったり、 話が広がったときにこれは違う話だったけどこうだね、と軌道修正しまとめる力が凄かったり、、

この些細な気遣いだったり、察する力だったりが全員感度高くて驚きました。

結論

もっといっぱい話したくなりました。

最初は緊張で冷や汗がダラダラでした。何を話したいか、何を聞きたいかも真っ白でした。しかし、実際はすごく話しやすいし、面白くて興味深い話を沢山聞かせてもらえるので、どんどん吸収していきたいし、純粋にもっと話したいです。

語彙力が足りず思ったことが伝わってるか不安ですが、感謝の気持が伝われば幸いです。この場をお借りしてお礼申し上げます!ありがとうございます!

自分の希望としては、今回に限らずまたお話できたらと思います!

以上、fluctのE4の方々とお話してきたレポでした。

▼VOYAGE GROUPの技術評価についてはこちら

speakerdeck.com

なぜオンライン移行に爆速対応できたのか?決まり手はkintone×Zoomにあった! サポーターズ、フルオンライン1on1面談イベントの裏側に迫る

TL; DR

  • オンライン移行 爆速対応の決まり手はkintone×Zoomにあった!

  • サポーターズの強みはツールの威力を活用するだけではなく"捨て続ける改善力"にある

  • 急変する市場変化に追従するために必要なものは「挑戦し続ける」こと

目次

フルオンラインで就活ができる時代が訪れている!!

新卒4年目(17卒)のエンジニア @ShuzoN です。
2019年2月から1年間サポーターズに所属しています。

僕が所属するサポーターズは新卒のエンジニア/ビジネス職の就活支援を行う企業です。

サポーターズ、延べ3,000人参加の全就活イベントをオンライン化し、学生と企業のマッチングを支援~セミナーや1on1面談など、3月実施の18イベント、参加社数200社をオンラインでマッチング~

今回はこのフルオンライン1on1面談イベントについて、設計および実装に現役エンジニアとしては1人で関与していた僕が裏側を紹介していきます。

ビジネス要件も含みながら、実際にどのようなシステムが動いているのかについてお話ししていきます。

サポーターズと新型コロナウイルス感染症(COVID-19) の関係

これまで、サポーターズでは学生と企業が1on1で面談を行うマッチングイベントやセミナーイベントなど、 実際に人を集めたイベント を開き就職活動のサポートを行ってきました。

ところが...

厚生労働省 新型コロナウイルス感染症について

2019年12月中旬から流行しているCOVID-19の影響を受け、国内のカンファレンスやイベントが相次いで中止。

クライアント企業が軒並み在宅勤務 となりました。 弊社VOYAGE GROUPも在宅勤務に移行。

当然、就活イベントもリアルイベントは行えません。

このため、今後のイベントを全てオンライン上で行う と意思決定。

僕がjoinした2019年2月からちょうど1年。

サポーターズが蓄積した オンライン上でイベントを行うノウハウ がここでフルに生かされることになりました。

そもそもサポーターズ1on1面談イベントとは

オンラインイベントの裏側に入る前に、まずは サポーターズ1on1面談イベントに関して概要を説明します。

f:id:namu_r21:20200331192956p:plain:w600

サポーターズでは学生と企業を1対1でつなげる「1on1面談イベント」を行っています。

おおざっぱに説明すると、1日で企業説明〜面談を一気にやっちゃう就活イベントです。

もう少し正確に言うと、イベントに参加する学生と企業が実際にサポーターズに来て1対1で面談する形式のマッチングイベント です。

大まかな流れは図に示した通りで、シンプルな流れです。

オンライン移行 爆速対応の決まり手はkintone×Zoomにあった!

この急速な時流変化に追従する 秘訣はkintone x Zoom の組み合わせ にありました。

kintone は、サイボウズ株式会社が開発するDBと協調するフォーム、ページ表示、メール送信までをクリックのみで作ることができるWebサービス です。

さながらGoogleスプレッドシートの強化版とでもいいましょうか。

Zoom は、Zoom Video Communicationsが開発する オンライン上でセミナーやミーティングを行うためのビデオチャットシステム です。

サポーターズでは 「kintone x Zoom」を組み合わせることで完全オンラインイベント を行っています。

Zoomでオンラインミーティングを用意し、kintoneでそのURLを学生と企業に共有します。

今回は「面談を実現するための仕組み」に限定して解説していきます。

大まかな流れは以下です。

f:id:namu_r21:20200402114250p:plain:w600

1. サポーターズがZoomのミーティング部屋を作る  
2. サポーターズがZoomで作成した面談URLをkintoneに登録する  
3. 学生と企業がkintone上で面談URLを参照  
4. この面談URLをもとにZoom上でオンライン面談を行う  

こうすることで データ共有から通話開始までオンラインで完結する仕組み が実現できます。

ミーティング部屋はZoom APIを利用し半自動的にスクリプトで作成しています。

f:id:namu_r21:20200327134314p:plain:w600

ZoomはAPIが非常にオープンで、UIで触れるものはほぼ全てAPI越しに設定可能です。

Zoomには 「同ホストが作成した複数の部屋で同時に通話できない」 という仕様があります。

同時刻に複数の通話が行われる際はホストとなるアカウントを分散して部屋作成を行う必要があります。

無邪気に1ホストアカウントで時間が重なる部屋を複数作ると通話が失敗します(事実、失敗しました)。

その仕様を反映したコア部分のコードはこちらです。実際に使われているRubyスクリプトの一部です。

  
  def fetch_Zoom_url(company, datetime, talent)  
  
    # 面談時間が重複し、ホストアカウントを使い切った場合はエラー  
    if datetime_duplicated?(datetime) && user_depleted?(datetime)  
      raise "日程が人と被ってる. この人のは自分でURL作ってな:#{datetime}:#{talent}:#{company}"  
    end  
  
    # 時間が重複しないホストアカウントの取得  
    user_id = room_host_user(datetime)   
  
    # Zoom apiを叩いて部屋の作成  
    response = make_room(user_id, datetime, company, talent)  
  
    # 200以外の何かしらがあったらエラーを返す  
    if response.code.to_i > 300  
      raise "code: #{response.code} | ZoomURLの発行(fetch)に失敗したよ: #{company}:#{talent}:#{datetime}"  
    end  
          
    # ミーティング時間の記録  
    store_mtg_datetime(datetime)  
  
    json = JSON.parse(response.body)  
    json["join_url"]  
  end  

このように簡単なスクリプトを書き、Zoomとkintoneでは実現できない溝を埋めてあげることで威力を最大限まで引き出すことができます。

※Zoomの利用規約内で利用しています。Zoom公式サポートに問い合わせしたところこの方法しかないとのことでした。

サポーターズの強みはツールの威力を活用するだけではなく"捨て続ける改善力"にある

サポーターズの強みはkintone x Zoomによるツールの活用力だけではありません。

強みは 良いものを求め捨て続ける改善力 にあります。

kintoneの良さは 「非エンジニアが作成できる & 成果物を捨てやすい」 ことです。

とはいえ、kintoneの正体はUIで簡単に作成できるリレーショナルデータベース です。

つまり テーブルの正規化を含むRDB設計力とビジネスに合わせた改善力の両方 を必要とされます。

2019年2月からの1年間で、現役エンジニアの僕と元エンジニアのビジネスマネージャを主軸に「改善体制」作りを行ってきました。

1年間に行われたスクラップ&ビルドは3回。

元々スプレッドシート運用だったものをkintoneで完全に置き換えツールもkintone関連ツールにまとめました。

改善内容について

1年間の改善、挑戦の中で生まれたものは以下です。

  • 1on1面談イベントをほぼkintoneアプリだけで完遂 (現在version3)

  • Google App Script(GAS)で動く面談組み合わせ作成スクリプトを開発

  • オンラインで行う企業セミナーの実施

  • オンラインで行う1on1面談の実施

  • 1on1面談を行うZoomミーティング作成スクリプトの開発

段階的に オンラインでの面談イベントノウハウ を蓄積してきました。

上記で僕はスクリプトの開発とkintone アプリの設計、作成まで直接的に関わっていました。

細かな設計に関しては割愛しますが、この1年でイベント運用にスプレッドシートをほぼ使わなくなるドラスティックな改善 を行いました。

改善前(2019年2月時点)

僕がサポーターズにjoinした直後の状況です。

f:id:namu_r21:20200401120728p:plain:w600

イベント運用中に見るべきスプレッドシートが多く(3-4枚)、使用するツールも複数にまたがっていました。

改善後(2019年4月時点)

f:id:namu_r21:20200327134401p:plain:w600

改善後はほとんどのスプレッドシートがkintoneに置きかわります。

上記のように 面談表作成以外は ほぼワンストップで kintoneを利用するオペレーションに変化 しました。

イベント中にサポーターズスタッフが見るべきシートは2枚まで減ります。(kintoneアプリ + 面談作成シート)

こちらに加えて、GAS上で動作する 面談組み合わせ作成ツールを開発し面談表作成を高速化。

Excelソルバーを使う方法 から GASで新たに実装する ことで面談作成時間を 7分から4秒にしました。

kintoneによるワンストップのオペレーションで学生、企業の回答データ取り込みも早くなり

改善前は20分以上かかっていた面談表作成の運用を2分まで短縮 しました。

新商材 オンライン上で行う企業セミナーの発明(2019年7月時点)

f:id:namu_r21:20200327134430p:plain:w600

改善だけではありません。オンラインを用いた新商材の開拓もこの時期から始まりました。

新商材の開発を兼ねて、 オンラインで行う企業セミナーの実施 を行なっていました。

Zoom上でセミナーを行うことができる Zoomビデオウェビナー を利用し、クライアント企業のセミナーをオンライン上で行いました。

この取り組みは評判が良く、現在はビジネス職のセミナーイベントとして主軸商材に。

ここで 「オンライン上で企業プレゼンを行うノウハウ」が蓄積しました。

オンライン上で行う1on1面談の実施

f:id:namu_r21:20200327134830p:plain:w600

セミナーだけでなく オンライン上での1on1面談もこの時期に試作 しています。

Zoom上でビデオチャットができる Zoom ミーティング を利用し、オンライン上で面談を行います。

同時期に Zoomでオンラインミーティングルームを作成する前述のスクリプトも開発。

ここで「オンライン上で1on1面談を行うノウハウ」が蓄積しました。

実は、この取り組みは人事さんにあまり受け入れられず、お蔵入りしていました。

新商材 フルオンライン1on1面談イベントの発明(2020年2月時点)

7月以降は 半年ごとにkintone資産を捨て運用をマイナーチェンジしてきました(現在version3)。

2020年2月になりCOVID-19の影響により、イベントがオンライン移行しました。

それに伴って 1on1面談イベントもフルオンラインに変貌。

f:id:namu_r21:20200327134851p:plain:w600

実は オンラインになってやるべきことは通常のイベント運用に Zoom運用 を足すこと でした。

本質的には 過去資産を組み合わせたことによる相乗効果が生んだ成果 だと思っています。

1年で積み立ててきたオンラインイベントのノウハウが結果的に全てが繋がって 「フルオンライン1on1面談イベントの実施」 ができています。

平時のイベント運用改善 + オンラインイベントへの挑戦を日常業務の中で取り組んできた からこそ成し得た「圧倒的スピード対応」だと思います。

急変する市場変化に追従するために必要なものは「挑戦し続ける」こと

急変する市場変化に追従するために必要なことは「挑戦し続けること」  

この1年間、サポーターズの面談イベントを支えるツールに携わった僕が肌に感じたことです。

この相乗効果を生むために必要なフローを3行にまとめました。

- 段階的に既存の仕組みを捨てて、新しい取り組みに挑戦する  
- 挑戦の中で評判が良かったもの、運用しやすかったものを取捨選択する  
- そこで得たノウハウを1つずつ組み合わせていくと、急激な変化にも耐えうる強い仕組みが生まれる  

大切なことはビジネスを止めない程度に 小さく失敗し続ける ことであり、それがそのまま 未来への準備につながります。

現状維持ではなく 準備 = 挑戦し続けること が 急変する市場変化に追従するために必要なものだと思います。

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 までお声がけください。