サイバーエージェントでの6年間と、次にやること

前回の記事から2.5年くらい経過したので近況を書いてみます。

kurochan-note.hatenablog.jp

そろそろ何をやってきたのか忘れそうなので振り返っておくのと、今思っていることについて雑多に書き出しておきます。 今回はちょっと長めなので目次を作っておきました。

目次

  • サイバーエージェントでの6年間
  • 給料の話
  • 暇にさせてくれない上司と会社
  • 技術選定の自由という名の動物園
  • 採用には全力を尽くす
  • 挑戦した敗者にはセカンドチャンスを
  • 次は何をやるのか
  • さいごに

サイバーエージェントでの6年間

既に細かいことをわすてしまっているような気がするので印象的な出来事だけ列挙してみました。

2015年

  • 飛び交う言語が独特すぎてそれが面白かったのでメモを取り続けて公開したらちょっとバズった

kurochan-note.hatenablog.jp

  • 突然アメリカで約2ヶ月間働いたりしてた
  • 1メンバとして開発ができるようについていくのに必死

2016年

  • アドテクコンペというインターンを運営した
    • かなりうまくいったので改善しつつ、これを元にしたものが年2回くらいのペースで開催されるように
    • こんな感じのやつ

developers.cyberagent.co.jp

  • 他に何をしていたかあまり覚えていないかも…?
  • AWSのre:Inventに行かせてもらった

2017年

  • 広告の画像をユーザによって違うものを動的に生成し、さらにできるだけ低遅延で配信するというのをやっていた

Dynalystにおける動的な画像生成 - Speaker Deck

  • プロダクトのコードのビルドが遅いことにイライラしていたのでとにかく高速化したくてひたすらキャッシュしていた気がする

Scalaプロダクトのビルド高速化 - Speaker Deck

  • GoogleのMaglevの論文を読んでめっちゃすごいと思い、ネットワークに再び興味を持った

Maglev: A Fast and Reliable Software Network Load Balancer

2018年

2019年

  • 開発責任者というポジションになった
  • 「エンジニアブログを書こう月間」を企画してチームメンバ全員で1ヶ月間毎営業日ブログを書いた
  • Scala MatsuriのWi-Fiスポンサーを担当し、好き放題やったインフラ環境を構築した

2020年

  • 事業部に配属されてきた新卒向けの技術研修をがっつりやった
  • Slack Enterprise Gridを会社全体に導入した
  • GitHub Enterprise Cloudを会社全体に導入した
  • Snowflakeを使ったデータ基盤を構築した
  • Envoyを導入してモノリシックなサービスを分離できるようにした

2021年

  • AppleのATTどうするか問題
    • ラッキングまわりで嫌われがちな広告ですが、あくまでもユーザに対して誠実な商品を作った上で効果の出る商品づくりをしていこうという意思決定ができたのは良いことだった
  • 悩みが出てきた
  • 4月以降の話は最後に

給料の話

だいたいこういう系の記事は失敗談と給料の話がウケると相場が決まっていますね。

入社してから給料は上がっていますが、上がる時もあれば、あまり上がらない時もあったという感じです。頑張るタイミングと成果がでるタイミングというのは必ずしも一緒じゃないので、評価と自分の実感に悩むこともありました。

一生給料が上がり続けたらとんでもない額になるはずですが、さすがにそんなことはなく、給料を貰う側(=社員)である限りどこかで頭打ちになるのは分かっていて、今がそのタイミングかなぁという感覚もあります。

一緒に働くひとを採用する側になり、年収提示でオファーがくるサービスを試しに使ってみた時期もありましたが、お互いによく知らない状態で攻めたオファー金額を提示することは難しいということも分かりました。そういった体験もあり、転職しただけで爆上がりすることもないかなぁと思っています。年収をあげたいだけだったら副業したほうがいいかもしれないですね。

お金の話はpublicなところでは書きづらいですね。この会社に転職を考えていて、話を聞いてみたいという方がいらっしゃればご連絡ください。具体的な数字は触れませんが、主観的にみた雰囲気はお伝えできるかもしれません。

暇にさせてくれない上司と会社

一言も飽きたと言ったことはないのですが、飽きそうになるタイミングでだいたい突然何かが振ってきます。

入社当時はほぼ技術にしか興味がなく、広告系の部署を志望した理由も低レイテンシで高トラフィックなシステムを作る必要があるので、バックエンドエンジニア的に面白そう、当時はコンテナ技術(LXC, Docker)に興味を持っていて、これから入れていきたいという話を聞いていたのでここならやれそうだと思ったためでした。

実際配属されて働き始めると、チューニングだとか新しい技術の導入だとかをやる以前に、機能追加やビジネスロジックの実装といった部分の仕事がこなせないレベルでした。自分のプログラミング能力や、既存のコードを読み解いて方針を考える能力が低かったのもあるとは思いますが、どこかでkumagiさんのツイートのような事に気づいたような気がします。

プロダクト開発をしている限り、プロダクトの理解がなければ何を実装すべきかもわからないし、チューニングをしたところで嬉しいのかもわからない、どこでお金を作っているかも分からなければ優先度の判断もできないということがわかりました。これじゃあつまらないじゃないかと思ったこともありましたが、同時にビジネス課題を解決する形でエンジニアリングが生きてくる場所を見つけられれば誰にも文句を言われないし、やはり技術で勝負したいのでどこかで一発当ててやろうという気持ちになりました。

チームの開発スタイルにも慣れて、ある程度与えられたタスクをこなすことは出来るくらいにはなったかな?という時から上司からはビジネス面の観点も持ってほしいと常に言われていた気がします。 商品の機能のすりあわせや事業としてのチャンスを探るような場にも呼ばれ、当時の気分としてはビジネスの話よりコードを書いている方が楽しいんだけどなぁ。。という感じでしたが、こういう場での話をずっと聞いているうちに自分が頑張って作ったはずなのにたいして使われなかったり、インパクトがなかったり、逆にそんなに頑張ったつもりではないのにインパクトが出せたりという部分の感じ方がズレていたことが分かってくるようになりました。このあたりから自己満足ではなく意味のある開発がしたいと思うようになり、事業自体に自分がどう影響を与えられるのかという部分にも興味を持ち始めた気がします(遅い)。

一方でAWSGCPといったクラウドは事業を作るという点においてはスピード感が出せて最高ですが、技術的には自分たちで面倒を見る必要があるものが少ない分、つまらなくなってきたので趣味で物理サーバに手を出しはじめたりしました。

そして落ち着いてきたと思ったら開発責任者というポジションを任され、あまり考えてこなかったメンバの評価や育成、開発チーム自体をどうしていくかみたいな部分で頭をかかえはじめました。

2年くらい開発をやりつつ、マネジメント的な業務をやったあとはチーム内で役割分担するようになりました。

ちょっと余裕が出てきたな、と思ったときに面白そうな話に乗っかってしまい、会社全体向けにSlack Enterprise GridとGitHub Enterprise Cloudを導入する仕事をしました。 もともとは部署やチーム単位でバラバラにSlackやGitHubを契約していたのですが、部署をまたいだ連絡や情報の共有がしづらいという課題感を持った各部署の人たちが有志で集まるところからスタートし、Enterprise契約に集約してセキュリティ的な統制を担保しつつ情報共有のハードルをかなり下げることができるようになりました。他部署の方々と各所調整してまわったり、セキュリティチームに助けてもらったりした結果実現できたのですが、調整して組織全体を動かすみたいな仕事の仕方を学びました。

等々あった結果いい意味であまり暇になることはありませんでした。

採用には全力を尽くす

会社のミッションステートメントのうちの一つです。

これは本当にいい文化だと思っていて、特に新卒採用は文化として定着していると思います。 そういう環境で採用された人が多いので、育成もトレーナーが新卒に合わせてそれぞれで考えて動いているように思います。

自分もそうやって採用してもらって育ててもらったので今があります。 自分の所属管轄のボス(役員)の内藤さんの記事は毎年何かしらの形でシェアしています。

ameblo.jp

面接官もやっているのですが、採用方針や評価基準まわりで人事や他部署のエンジニアと話し合うことも多いように思います。部署によって微妙に欲しい人物像が違ったり、事業の変化も多いのでなかなか決まらなかったり擦り合わないこともありますが、(喧嘩しているわけではないのですが)納得が行くまで譲らない姿勢でみんな取り組んでいるように思います。

技術選定の自由という名の動物園

うちの会社はよく言えば技術選定は自由です。各自に裁量があります。

チーム内で合意さえ取れていればどんな技術だって取り入られれると思います。 プロダクトの経営方針についてはその上の経営層から指示がくることもあるとは思いますが、技術面の方針で上から指示がくることは見聞きしたことはありません。

会社紹介でベンチャーの集合体のような会社です、と表現されていることもあって、実際にそのようなイメージで間違いないと思います。 ただ、5000人を超える社員が所属していて、そのうちエンジニア職が1000〜1500人くらいいて、時価総額が1兆円を超えることがあるような会社が世の中で想像されるようなベンチャーそのものかというとちょっと違うんじゃないかなと思います。

www.nikkei.com

ベンチャー企業のような勢いとマインドを持ち続けるのは必要ですが、これだけ大きな会社なので必ずしもベンチャーと同じ戦い方をする必要はないのでは?と思っています。

新しいプロダクトやシステムを立ち上げるときに、ゼロから開発するのは非常に楽しくて、自身のスキルアップにも繋がるためモチベーションも高くなりますが、すこし引いた視点で見ると同じことを繰り返していたり、非効率に見えることもあるかと思います。

抽象的な言い方をすると、技術力だったり組織サイズが横並びでスケールすることはできるものの、技術力や開発した資産を積み上げることでの「高さ」を作るのには向いていないような気がしています。

それに対して何も動きがないということはなく、各部署で横断組織を作る動きはあったりしますが、うちの会社っぽい事例というのはまだ確立されていないように思います。 個人的にはここは大きなチャンスポイントだと思っていて、何かしら取り組んでいきたいと思っています。

他の人が言っているのを聞いたことはありませんが、こういった背景や、かといって誰の手にも負えないくらいバラバラということもなく、会社という体を維持できる程度には統制は取れているという意味を込めて個人的には裁量とか自由という言葉と合わせて「動物園」という比喩をよく使っています。

挑戦した敗者にはセカンドチャンスを

こちらも会社のミッションステートメントのうちの一つです。

「信頼残高」という社内でよく使われる言葉があり、役員の曽山さんは「期待を超えると残高が増え、下回ると残高が減る」というふうに解説しています。

ameblo.jp

信頼残高を使って大きな仕事をやったという実感はまだなくて、まだうまく立ち回ろうとして信頼残高を貯金しているような気がしています。

絶望するくらい派手に失敗してしまった人にしかこの言葉の意味はわからないんだろうなぁと想像していて、6年働いてもまだこの言葉の意味はピンときていないので、リスクを取った挑戦と言えるレベルのことはやっていかないといけないなと思っています。

6年間同じチームで働いていると考え方が硬くなってしまうというか、煮詰まりがちです。ドメイン知識も身についてきた分、リスクを判断したり、守りを固めることは強みになってきたかもしれません。 ただ、目指している方向性としてはあくまでも成長しつづけることなので、守っているだけではあまり貢献ができている実感が沸かなくなってきます。このあたりは最近の悩みでした。

挑戦やチャンスに対してスポットライトをあてて応援する文化がある一方で、失敗したときはその失敗についてしっかり反省, 共有をする必要もあると思っています。勢いがある感じだけ出してても必ず足元をすくわれて、無駄な失敗をするので必要な反省というのは引き続きやっていこうと思います。

次は何をやるのか

この記事が退職エントリーなのか在職エントリーなのかでいうと、今回も在職エントリーでした。 引き続き今の会社で働いていきます。

新しい取り組み(?)として、入社7年目にして初めて異動してみることにしました。

事業部は変わらないのですが、小売DXという部門で働きます。 小売というのは生産者(メーカーなど)や卸売業者から商品を仕入れ一般の消費者に販売する業種です。 スーパー、コンビニ、家電量販店、ドラッグストアなどを思い浮かべてもらうとよさそうです。

日本の小売業の販売額は145兆円(2019年)ほどあるようです。

www.meti.go.jp

日本の広告費は6兆円程度(2020年)のようなので、市場規模がかなり違いそうです。

www.dentsu.co.jp

インターネット広告市場でインターネット広告の商品そのものを作っていた時と違い、直接的に小売業をやるわけではないので、事業の収益化の方法も今までと変わってくるはずです。この市場を取りに行く、というよりはこの市場に対して新しい入り方をする、という解釈のほうがしっくりくるのかなという印象です。ターゲットにする市場が大きければ何か影響を与えたときのチャンスも大きそうですね。

これから小売DXという部門で色々立ち上げていきます、というフェーズなのであまりたくさん事例は出ていませんが、最近出たリリースだと

www.cyberagent.co.jp

こういうのがあるようです。インターネット広告が強みの会社なのでデジタル広告は絡んできていますが、それ以外のオンライン(EC, アプリなど)とオフライン(実店舗)を組み合わせたデータ基盤を作って様々なマーケティング活動ができる販促プラットフォームを作る、というのは新しい取り組みのように思います。

ほかにも既にデジタルサイネージを活用したプロダクトがあって社内でサイネージ端末と連携するシステムを作っているチームもありますが、エンジニア組織を持っていて企画に合わせた内製ができることや、インターネット広告をリアルタイムに取引するシステムを開発する上でのデータの扱いや大規模なデータ向けの分析基盤といった分野の知見は強みになるような気がします。 公式アプリのようなモバイルアプリの開発もやっていくようなので、メディア事業をやってきた企業としての強みも活かせるかもしれません。

出ている情報以外にも仕込み中の話がたくさんありますが、既存の大きな業界に対して単独で事業を立ち上げるわけではなく、様々な企業と提携するような形で事業を作っていくことが多くなりそうです。完全なゼロからの立ち上げでもなく、受託のように指示されたものを作るわけでもなく、自分たちの企画と実装力が肝になってきます。この取り組みがうまく行けば既存のWeb系企業とは違った新しい業態が作れると思うので面白いです。 エンジニア目線で言えば自分たちの強みだと思っているWebの技術がこの業界に対してどれだけ通用するのか、という部分で腕試しができるんじゃないかと思っています。意外とそんな簡単にはいかなさそうです。

こういう状態の部署に異動するので、まだ自分が具体的にどう動いていくのか決まっていません。 既に働いているメンバのやりとりを見たり、首を突っ込めそうな部分に突っ込んでみたりしたところ、まずは要件定義の部分に関わらせてもらって皆無なドメイン知識を補いつつ、インフラ〜バックエンドの開発をやり、最低限のセキュリティは死守する役割とかがいいのかなぁと思いました。

あと、どう考えても自分だけで手に追える規模の話ではないので、引き続き採用はやっていきます。一緒に働きましょう。 自分は他人があまりやらないようなところにチャンスを見出して成果を出すのが向いているんだろうなと思っているので、自分なりの動き方を見つけていく予定です。

さいごに

なんとなく思い立って勢いで書いてみました。数年後また振り返ってみようと思います。

ここまで読んでくれる方がどれくらい居るのかわかりませんが、最近採用サイトができたので、宣伝もしておきます。

www.cyberagent.co.jp

バックエンドエンジニア、フロントエンドエンジニア、インフラエンジニア(パブリッククラウド中心)、iOS, Androidの職種を募集しています。自分のつながりがある人はエンジニアが多いとは思いますが、ビジネス職も募集しています。

もし少しでも興味を持ってくれる方がいらっしゃったらDMをください。

ここで書かなかったようなことが話せるかもしれませんし、聞きたい話をしてくれそうな人を紹介することもできるかもしれません。

twitter.com

ということで、社会人7年目も元気にやっていこうと思います。

2020年書いた記事/発表まとめ

2019年はこんな記事を書いていたようです。 2019年書いた記事/発表まとめ - くろの雑記帳

今年は会社では所属しているチームの仕事に加えて、会社全体に対してSlack Enterprise GridやGithub Enterprise Cloudの導入をやったりして大きい組織に何かを導入する大変さなどを体験できて面白かったですね。来年はエンジニアリング方面でチャレンジしていきたいです。

2020年書いた記事/発表

2019年に社内の事業部向けに発表した内容を会社全体向けのエンジニアイベントで発表しました。 speakerdeck.com

2020年の2月はチームで毎日記事を書こうという企画をやっていました。色々なアウトプットができたんじゃないかと思います。 developers.cyberagent.co.jp developers.cyberagent.co.jp developers.cyberagent.co.jp

愛用しているMistelのキーボードの新作をレビューさせてもらう機会がありました。今でも仕事場のキーボードとして利用しています。 kurochan-note.hatenablog.jp

事業部に配属されてきたエンジニアの新卒入社社員向けに研修を行いました。 speakerdeck.com speakerdeck.com speakerdeck.com

Slackの表記をきっかけにふと時刻の表記について気になったので調べました。 kurochan-note.hatenablog.jp

仕事でAmazon Redshiftを利用している状況で、Snowflakeの導入を検討したことを発表しました。 最終的にはSnowflakeに移行することを決定し、年内には移行完了しました。社内だと一番大きな移行事例だったのではないかと思います。 speakerdeck.com speakerdeck.com developers.cyberagent.co.jp developers.cyberagent.co.jp

社内の事業部向けエンジニアカンファレンスで発表しました。 speakerdeck.com

社内でSlack Enterprise Gridを普及させる活動をしていて、会社としてのSlackの活用事例について発表しました。 speakerdeck.com

whywaitaアドベントカレンダーです。 kurochan-note.hatenablog.jp

来年もたくさんアウトプットしていきたいですね。 2021年もやっていきましょう〜

KDDI MUSEUMに行ってきた

この記事は whywaita Advent Calendar 2020 の16日目の記事です。 昨日 @whywaita と一緒にKDDI MUSEUMに行ってきたのでその記事です。

KDDI MUSEUMとは

KDDIが2020年12月1日にオープンした日本の国際通信の歴史に関する企業ミュージアムです。
平日しか空いていないので平日働いている身からすると少々ハードルがあります。
1回あたり15名程度?くらいの人数制限があるようです。

www.kddi.com

きっかけ

この記事を発見したので行ってみたくなりました。

japanese.engadget.com

誘ったものの、スルーされたので何度かリマインドした結果行くことになりました。

f:id:kuro_m88:20201216201800p:plain
slackの様子1
f:id:kuro_m88:20201216202315p:plain
Slackの様子2

無事有給が取れたようでよかったですね。

展示されているもの

  • 日本の国際通信
  • 通信市場参入と挑戦の軌跡
  • KDDIの挑戦
  • au 5G

の4つのコーナーに分かれていました。

f:id:kuro_m88:20201215140155j:plain
電話交換台

ペリーが江戸幕府にモールス電信機を献上した話から、長距離無線通信の時代、から戦後の国際通信までの流れが紹介されていたり、

f:id:kuro_m88:20201215141608j:plain
FASTERの中継器

FASTERの中継器が展示されていたのはテンション上がりましたね。FASTERというのは以下のやつです。

jp.techcrunch.com

f:id:kuro_m88:20201215142704j:plain
auの2000年以降のケータイたち

大学生まではドコモ派だったのでauは友達のケータイでしか見たことがなかったのであまり知っている端末はなかったのですが、そういえば「メガネケース」とかあったなーなどと盛り上がれてよかったです。

自由に見学できる形式ではなく、ツアーのような形式で案内を聞きながら回る形式だったので結構テンポが早く、一個一個しっかり見ることはできなかったので、 説明を聞きながら気になるものはじっくり見ておくのがよさそうでした。

バーチャルギャラリー

なんとバーチャルギャラリーとして全部3Dで公開されています。 わざわざ現地に足を運ぶのは大変という人はぜひ見てみてください〜

my.matterport.com

あわせて行きたい

NTTの技術資料館も行きたいですね。以前行った時は時間が足りなくて全部見きれなかったのでリベンジしたいです。

www.hct.ecl.ntt.co.jp

明日は kyontan の「KMNZ LIZは声が良くてちょろいオタクはすぐ負ける」です。

午前0時?午前12時?00:00 a.m.? 12:00 a.m.?

Slackで会話していて、ふと 12:21 AM という表記が気になりました。

f:id:kuro_m88:20200912130414p:plain
slackの会話内容

深夜に会話していたはずなので、24時間表記で言うところの00:21 です。午前は0時からはじまって12時に終わる物という認識だったので、これはSlackのバグなのかではないかと思って調べてみました。

結論

  • Slackのバグではない
  • 24時間表記で言うところの 00:00
    • 日本では 午前0時(午後12時)
    • アメリカでは 12 a.m.

日本での午前と午後の表記

NICT(情報通信研究機構)の記事がわかりやすかったです。

jjy.nict.go.jp

午前と午後を定義している法律は、明治五年に出された 太政官布告三百三十七号(資料1)以外に は見当たらない。また、この法律が改廃された記録も残っていないところから、 現在も生きているものと考える。したがって、午前12時と呼ぶのが正しいこ とになる。

やはり日本での解釈では、午前は0時(深夜)にはじまり、12時に終わる(お昼)。ただし、午前12時 = 午後0時ということになります。

小学校の算数の学習指導要領も検索してみました。

https://www.mext.go.jp/component/a_menu/education/micro_detail/__icsFiles/afieldfile/2019/03/18/1387017_004.pdf

124ページ目には午前と午後がそれぞれ12時間あるという記述はありましたが、何時から始まるのかについて言及はしていませんでした。しかし図が載っていたので転載します。

f:id:kuro_m88:20200912132044p:plain
午前と午後の範囲を示す図

この図を見る限り午前と午後はそれぞれ0時から始まり、12時に終わるように見えます。

アメリカでの午前と午後の表記

GPD(United States Government Publishing Office, 合衆国政府出版局)のスタイルマニュアルを参照してみました。

https://www.govinfo.gov/content/pkg/GPO-STYLEMANUAL-2016/pdf/GPO-STYLEMANUAL-2016.pdf

ここに Clock time という項目があり、その内容を抜粋します。

f:id:kuro_m88:20200912133829p:plain
GPDのClock Timeの記述

12 p.m. (12 noon) 12 a.m. (12 midnight)

ということで、お昼は 12 p.m.深夜は 12 a.m. ということになるようです。

Wikipediaにも明示的に書かれていました。 https://en.wikipedia.org/wiki/12-hour_clock

f:id:kuro_m88:20200912132324p:plain
アメリカでの24時間表記と12時間表記の差

アメリカだと12時からはじまり、1時、2時… 11時というふうに時間が進むようですね。

感想

まとめると

  • 24時間表記で言うところの 00:00
    • 日本では 午前0時(午後12時)
    • アメリカでは 12 a.m.

ということになりますが、12時から始まって、11時に終わるというのは納得がいかないですね…

Slackに関しては普段言語設定を英語にして生活しているのですが、日本語設定にすると24時間表記になりました。

前述のNICTの記事によると、

市販されているデジタル時計はほとんど“PM 12:00” と表示し、上記の表し方とは異なる。これは、アナログ式の文字盤には“0” の数字がなく、1~12までであり、これをそのままデジタル表示したためと 考えられる。

という説が書かれていますが、たぶんこれがそのままテキスト表記にも引き継がれているのでしょう…。

日本語の文脈に置いてa.m./p.m. 表記を使う時に 0 a.m. みたいな表記をするべきなのかどうか悩ましいですが、0 a.m. は複数の解釈の余地がないので誤って伝わることは起きないとは思います。