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

デブサミ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で自己診断を行い、結果を公開していくと業界全体が良い方向に進むと思いました。