そーだいなるVOYAGE GROUPの裏側 #VM 編 レガシーシステムといい感じに付き合うスキル

 今日も@soudai1025 こと id:Soudai がお届けします。

 そーだいなるVOYAGE GROUPの裏側は #voyagebook のイベントとして、各事業部のエンジニアにパネルディスカッション形式で話をしていく企画です。 第三回の今回は「レガシーシステムといい感じに付き合うスキル」と題してVOYAGE MARKETING(以下 VM)のみんなとディスカッションしてきました!

f:id:tan2jpn:20201017175212p:plain

当日の紹介資料

 資料の中にVMの紹介やパネラーの自己紹介もあります。 どんな会社なのか気になる!って人もぜひ資料を見てみてください。 オススメポイントは人気声優と同姓同名の下りです!*1

speakerdeck.com

 質疑応答の内容に合わせたツイートなどのまとめはこちら。 togetter.com

 実際のパネルディスカッションの様子は上記の動画をどうぞ。 3回目ともなるとこなれてきて、いい感じに雑談から入り、配信もできました。 パネルディスカッションも大盛りあがりだったのでぜひ見てください!

 今回は牧場のfluct、サバンナのZucks、に対して農耕と評される、VMの話でした。 チームで問題に取り組み、チームで問題を解決するという文化が終始出ていましたね。

 特にレガシー改善は古いコードのメンテナンスをさせられているという印象が強いですが、そんなことはなくてどんどん新しい仕組みを取り入れたり、置き換えたりしながら前に進んでいて、多くの人に勇気を与える回でした。  

感想

 今回は自分の中では大きく以下の3つのテーマがありました。

  • 歴史あるサービスをメンテナンスするということの楽しさと学び
  • レガシーコードを腕力*2ではなく、組織で取り組む
  • 改善の道に王道なし、プロダクトの成長に近道なし!

 この3つがVMの特徴だと思っていて、皆様にその片鱗をお伝えすることができたのでは無いでしょうか。 特にこのツイートがVMの文化を表してるなぁと感じます。

 VMの文化はチームにフォーカスしているものの、前述の2社と変わらず、事業の成長にエンジニアが向き合ってきた形です。 お互いにサポートしながら 一つのミッションをチームで解決する というミッションベースの文化は多くの企業でも取り入れる要素なのではないでしょうか。

 今回の回も名言が連発なのでぜひTwitterのまとめも御覧ください。

次回予告

 次回のそーだいなるVOYAGE GROUPの裏側は VLS*3 です! ここまで1を100にする、100を10000にするような事業の話がメインでしたが次回は0を1にする話です。 今までは腕力あり、文化ありですが次回はそこにまさに 技術あり! といった内容になる予定です。

 最小限で最大の効果を発揮する、技術で問題を的確に解決していくVLSの姿に乞うご期待ください。 本の中で語られなかったより深い技術の話を引き出せると思うとオラ、ワクラクしてきたぞ!

voyagegroup.connpass.com

 VMに変わってお仕置きよ! 次回のVLS回もよろしくおねがいします!

techlog.voyagegroup.com

*1:当日誰も触れなかったのでここで触れます

*2:腕力についてはfluct回を参照

*3:VOYAGE Lighthouse Studio

新卒とOJTに配属からの様子を聞いてみた【VOYAGE MARKETING編】

こんにちは!新卒エンジニア採用担当のさとみんです。

VOYAGE GROUPにはこの春9名の新卒エンジニアが入社し、4月末の配属からもうすぐ半年が経とうとしています! 今回は、VOYAGE MARKETINGに配属されたぐりと、ぐりのOJTであるよっぴーのインタビューをお届けします!

※OJTとは?…OJTは、業務を通じて仕事に必要な知識・スキル・マインドなどを新入社員に継続的に指導する存在です。VOYAGE GROUPでは業務の中で1人ひとりのスキルや個性に合わせて学んでいけるよう、OJT制度を取り入れています。

▼3行まとめ

  • やりたいと手を挙げると任せてもらえ、想像以上に働く自由度が高かった
  • わからないことに対して、チームを超えてみんなが教えてくれる
  • 「設計の選択肢を増やす」ことが今後の目標

f:id:satomin35y:20200924184938p:plain

登場人物

ぐり(左):2020年入社の新卒1年目。VOYAGE MARKETINGに配属され、ECナビの技術的負債の返済などを担当。

よっぴー(右):2016年入社の5年目。VOYAGE MARKETING(以降VM)でECナビの技術的負債の返済などを担当し、ぐりのOJTも担当。

ーまずは、入社から配属までを教えて下さい!

ぐり:今年は入社式・研修・配属とすべてオンラインだったのが印象深いですね。配属希望を出すまでは約2週間で、研修ではVOYAGE GROUPや事業の説明、各事業部の方々との交流の時間があり、部署の雰囲気や現場のクルーを知ることができました。

よっぴー:VMでは、ランチ時間に新卒へ向けてエンジニアが普段行っている「昼会」を公開しました。進捗共有の様子や今後の方針について話し合う姿をそのまま見てもらうのが、1番部署の雰囲気が伝わるのかなと思ったので。

ぐり:正直話している内容は全然理解できなかったのですが(笑)、部署の雰囲気や毎日集まる機会があることを知れて部署選びの参考になりました。VM以外だと、ランチをしながら質問する場を設けてくれる部署が多く、各部署への自分のイメージと、実際はどうなのかの差分を埋めるのに役立ちました。

※VOYAGE GROUPでの配属先の決定について…本人の志向性をもとに人事や現場クルー、CTOとの面談を重ね、最も活躍できる部署へ配属が決定します。

ーどんな基準で部署を選んだの?

ぐり:ユーザーに近いところで開発できるかを重視していて、ECナビサポーターズを中心に話を聞きに行きました。「実際開発していてどう感じるか?」などを質問し、自分がやりたいことが本当にできるかを実際に相談したりもしました。色々な部署の話を聞けば聞くほど「どの部署に行っても楽しそうだな」という気持ちで着地したので、配属式ではいい意味でドキドキ感がありました。

ー晴れてVM配属になったその後は?

ぐり:配属翌日、最初は上長の福田さんとVM開発本部のどのチームに入るかを面談で話し合いました。ユーザーに近い部分のアプリケーションを触りたいと相談し、VMの各チームの状況を聞く上で最終的にリノベGというチームを福田さんに薦めていただきました。

よっぴー:リノベGは僕の所属するチームで、20年近く続くサービスであるECナビ

ecnavi.jp

技術的負債の返済が僕らの役割です。サービスも長年続くと、開発面ではシステムが複雑になっていて、誰も仕様を知らなかったり、使われているか分からない、似たような機能が乱立していたりと課題も蓄積されていき、例えば、「新しく機能を追加・変更するぞ!」という場合でも開発工数とは別に仕組みや影響の調査といった工数が増えてしまうケースがありますね。なので、開発の課題部分をきれいにする技術的負債の返済をしていき、ユーザーにより早く価値提供できるようにしていくのが僕らのチームの役割です。

ただ、いきなり「技術的負債の返済をしろ!」と言われてもさすがに難しいので、最初はECナビに慣れてもらうために、内部向けの管理画面の改修など小さめのタスクから任せていて、一通り触った7月頃からリノベGのタスクに着手してもらってます。

ー1番最初の仕事は?

ぐり:「ここが変だよECナビ」という提案企画をまず最初に任されました。ECナビを使って違和感のある箇所を事業部のメンバーに向けてプレゼンする企画で、配属された同期たちと相談しながら提案をまとめました。実際に自分が提案した中からだと、「ナビックの新着情報」のデザイン変更案と、ユーザーのお知らせ欄の見やすさ改善が採用されました。

▼実際のぐりの提案資料一部

f:id:satomin35y:20200924190023p:plain f:id:satomin35y:20200924191513p:plain f:id:satomin35y:20200924191523p:plain

よっぴー:提案が採用されたのすごいよね!

ぐり:この企画を通して、気になったところは自分でどんどん提案できる環境だとわかりました。最近では、「このコードをきれいに直したいな」と思ったところはGitHubのIssueにメモしておいて、タスクが空いた時に直して自分からプルリクエストを出したりもしています。

ー開発周りでの初仕事は?

ぐり:管理画面の開発です。ECナビはポイントサイトで、一定期間を超えたユーザーのポイントは失効していくのですが、失効作業の一部でエンジニアが本番DBを触る作業が残っていて、より安全に作業が進むよう、これを無くすための機能開発を担当しました。その際、今まで学校の課題くらいでしか触れていなかったPHPに本格的に挑戦しました。

よっぴー:管理画面に着手してもらった狙いとしては、まずは小さいタスクから取り組んでもらい、ECナビのプロダクトのコードへ慣れてもらう意図がありました。初めて触るPHPについても、ぐりは周りのクルーにSlackで勉強の仕方などを質問していたよね。

ぐり:はい。実際、おすすめされた『はじめてのPHP』という本で勉強しました。プログラミング自体は他の言語でやっていたので、「PHPだとどう書くのか」という部分を書籍などで補完しました。他にも聞きたいこと・わからないことがあればSlackで質問をすると、全然違うチームの人も含めてみんなが集まって教えてくれるのでありがたいです(笑)

よっぴー:テキストベースで解決が難しいものは、在宅勤務でも適宜通話をつないだり、オンラインで画面共有をして一緒にコードを見ながら進めていきました。リモートながら、ぐりがドライバーで自分がナビゲータとしてペアプロをしながら進めていきました。

ーー最近取り組んでいる仕事は?

ぐり:最近だと、ECナビでの広告掲載の一部を自動化しました。ECナビ上に掲載する案件は、内部向けの管理画面から、運用担当の方がどの広告枠に何を掲載するかを手作業で登録しているのですが、一部の広告枠でこの運用を自動化しました。あとは、運用ミスが起きやすい管理画面の改善や、すでに利用されていない機能を見つけて削除、などもしています。

ーー実装を進める中で大変だったことは?

ぐり:要件の実装においていくつか選択肢があり、適切な選択肢を選んでいくのが難しかったです。メリット・デメリットをそれぞれ自分で出し、チームメンバーに壁打ちをしながらまずは自分主体で進めていきました。

よっぴー:ぐりは質問の際にすぐに答えを求めるのではなく、「こう考えているんですがどうですか?」という聞き方をしてくれたのがいいですね。タスクをこなすにつれて、ぐり自身の考えがブラッシュアップされていて成長を感じています。

ーー配属前と配属後でギャップはあった?

ぐり:配属前は仕事の進め方に関して、チームでやることが決まっていてそれに向けてやっていくイメージだったのですが、実際はやりたいと手を挙げると任せてもらえ、自由度がかなり高い印象を受けました。また、在宅勤務中も毎日昼会でリモートながら顔を合わせていたので、チームに打ち解けるのもそれほど時間がかかりませんでした。

ーーでは最後に、これからやっていきたいことは?

ぐり:リノベチームが技術的負債を頑張って返済していくチームなので、 やはりその部分でチームに貢献できるように頑張っていきたいです。また、ECナビのように長く使われているサービスでは、その歴史とともにうまくいっている設計・うまくいかなくなった設計を身をもって学ぶことができます。それらを学んで、『設計の選択肢を増やす』というのが個人的な目標です。自分の選択肢を増やしてそのタイミングごとにベストな選択が取れるようになりたいです!

よっぴー:自分の手持ちを増やして、リノベGやそれ以外の範囲でももっと幅を広げて動いていけるように一緒に頑張っていこう!

お知らせ

VOYAGE GROUPでは、2022年4月入社のエンジニア新卒採用選考を開始しています! ミチを切り拓く、未来の仲間を募集中。詳細はこちらから!

voyagegroup.com

そーだいなるVOYAGE GROUPの裏側 #Zucks 編 フルサイクル開発者の文化

 今日も@soudai1025 こと id:Soudai がお届けします。

 そーだいなるVOYAGE GROUPの裏側は #voyagebook のイベントとして、各事業部のエンジニアにパネルディスカッション形式で話をしていく企画です。 第二回の今回は「フルサイクル開発者の文化」と題してZucksのみんなとディスカッションしてきました!

f:id:Soudai:20201009173640p:plain

当日の紹介資料

 資料の中にZucksの紹介やパネラーの自己紹介もあります。 どんな会社なのか気になる!って人もぜひ資料を見てみてください。

speakerdeck.com

 質疑応答の内容に合わせたツイートなどのまとめはこちら。 togetter.com

 実際のパネルディスカッションの様子は上記の動画をどうぞ。 今回はYou Tube Liveがこちらの問題で配信できなかったため、zoomの録画から生成されました。 You Tube Live勢が見れてない、イベント史上最高と評判高い前説もぜひ見てください!

 今回はサバンナと評される、Zucks文化がにじみ出るディスカッションでしたね。 諸事情でリモート参加の人もいましたが、違和感なくディスカッションできたのは技術力の勝利と言ったところでしょうか。 Zucksの章にも出てきた @brtriver さんのCSO*1*2 のおかげです!

 

感想

 今回は本には登場しない三人に来てもらいました。 Zucksの文化は独特と言われることも多いですが、どちらかといえば「大切なことを正面から向き合って解決していった結果」でしたね。 結果的にフルサイクル、ドキュメントが必要にないくらいにissueをはじめ、しっかりとコミュニケーションを取ることは多くのエンジニア、企業にとっても学ぶことが多いのでは無いでしょうか。

 また監査対応に「特別対応を用意しない」というのは本当に大切だなと思いました。 常に本質を見抜き、最善な解決をしていく姿勢に 技術力で問題を解決する ということはこういう姿だと強く感じました。

 要所要所の名言はTwitterのまとめにも出てくるのでぜひ、そちらも見てみてください。

次回予告

 次回のそーだいなるVOYAGE GROUPの裏側は VM*3 です! 牧場のfluct、サバンナのZucksに対して、農耕と呼ばれるのVMです*4

 腕力だけがレガシーの改善方法じゃない、毎日の積み重ねの先に健全なプロダクションがある。そんなVMの取り組みは「自分は凡庸だ」と感じている人にこそ、聞いて欲しい話です。

 正しいことの繰り返しの中に四季がある、そんなVMの話は私も今からめちゃめちゃ楽しみです。

voyagegroup.connpass.com

 翔べ!voyage!! 次回のVM回もよろしくおねがいします!

techlog.voyagegroup.com

*1:チーフサウンドオフィサ

*2:非公式

*3:VOYAGE MARKETING

*4:そーだい調べ

日々変化するゆるふわフォーマットをBigQueryでおいしく料理する方法。Athenaユーザも必見だよ!

3行まとめ

  • BigQueryはいいぞ
  • 外部テーブルはすごいぞ
  • Scheduled Queryも便利だぞ

こんにちは。ひむ(@himu)です。
株式会社fluctでエンジニアとして働いていたり、ボルダリングしたりガチャを回したり健康で文化的な生活をしています。

fluctはインターネット広告プラットフォームのサービスなどを提供しており、毎日億単位の大量のイベントログが発生しています。
イベントログには、売上の計算に必要なデータから、アプリケーションを改善する上で必要なデータなど、様々なデータが入り混じっており、情報が追加されることも度々あります。
今回は、そんな日々変化するログを分析基盤に取り込み、活用しやすくするためにやってきたことを紹介します。

背景

今回扱うサービスは社内では比較的新しいもので、Athenaでログをクエリするしくみが早い段階から作られていました。

アプリケーションはAWSのEC2インスタンス上で動いており、ログファイルに吐き出したデータをkinesis agentがストリームに取り込み、Kinesis Firehoseを使ってS3に保管するという流れです。
当初は取引量も少なく、S3に置いたログをAthenaでクエリするので十分データを活用できていました。

しかし取引量が増えるにつれてログの量やフィールドが増えたことで、1日あたり10億レコード、1TB近くと、単純にデータサイズが大きくなってきました。
Athenaで分析しようとしても、クエリごとに数分、あるいはそれ以上かかるようになり、データ活用の大きな障害になってしまいました。Athenaのパーティション自動生成のしくみがわかりづらかったことも頭を悩ませる原因になっていました。

そこで、もともとチームの分析基盤としてBigQueryを使っていたこともあり、そちらに取り込もうと考えました。

データの流れ

f:id:himuk:20201002185620j:plain

そのままコピーするだけのLambda

S3からGCSへのコピーでは、今回パスも含めてそのままコピーするLambdaを用意しました。

import io
import json
from urllib.parse import unquote_plus

import boto3
from google.cloud import storage
from google.oauth2 import service_account

s3_client = boto3.client('s3')
sm_client = boto3.client('secretsmanager')


def init_gcs():
    cred_json = sm_client.get_secret_value(SecretId='gcp_serviceaccount_json')['SecretString']
    cred = json.loads(cred_json)
    return storage.Client(
        credentials=service_account.Credentials.from_service_account_info(cred),
        project='project_name',
    )

def handler(event, context):
    gcs_client = init_gcs()

    for record in event['Records']:
        stream = io.BytesIO()

        s3_bucket = record['s3']['bucket']['name']
        key = unquote_plus(record['s3']['object']['key'])
        s3_client.download_fileobj(s3_bucket, key, stream)

        gcs_bucket = gcs_client.bucket('bucket_name')
        blob = gcs_bucket.blob(key)
        blob.upload_from_string(stream.getvalue())

外部テーブルを使おう

ログはJSON Lines(BigQueryでいうところのNEWLINE_DELIMITED_JSON)で、配列データがあったり、デバッグ用のフィールドがomitemptyされたりしています。
また、スキーマの変更もあり得るため、そのたびにテーブルスキーマ定義も変更しないと取り込みエラーになる可能性があります。
いわゆる「ゆるふわフォーマット」というやつですね(たぶん)。

Athenaはそういったデータをクエリするのに便利なツールで、データの実体はクラウドストレージにあり、テーブルはビューのような感覚で使えるようになっています。

GCPにも似た機能があり、それがBigQueryの「外部テーブル(External Table)」です。

まさにGCP版Athenaとも言える機能で、GCSやGoogle Driveに置いたファイルをBigQueryから直接クエリすることができます。
Athenaと同様にhive partitionを扱えて、BigQueryのパーサをそのまま使えるので対応フォーマットも多いです。 少し前にGoogle SheetでBigQueryが使えるようになったりしていて、BigQueryの多機能ぶりには頭が上がらないですね。

クエリ速度ですが、Athenaと比較するのが馬鹿らしくなるくらい速いです。
Athenaで10分以上かかっていたクエリが数秒で返ってきたときは感動しました。
今回はGCSのNearline Storageに置いたので、ストレージクラスが違ったりGoogle Driveなどにクエリすると遅くなるのかもしれません。

ゆるふわをゆるふわのまま扱う

外部テーブルを使えばBigQueryで扱うことができるようになりますが、ゆるふわフォーマットをゆるふわたらしめているのはスキーマで、外部テーブルも例外なくスキーマ定義をしなければなりません(auto detectは使えます)。

正直これが一番面倒な作業です。ログに出しているデータすべてを定義しなくてはならないし、変更にも都度対応しなければなりません。
日々活用しているのは一部のフィールドだけだったりしていて、深くネストされたフィールドなどはデバッグでたまに見るくらいだったりします。

であれば、一部だけクエリできるようにして、あとはJSON文字列のままのほうがクエリしやすくもなるのでは?
必要なフィールドだけパースするようにすれば、エラーの可能性も低くできるのでは?

そこで、「JSONはJSON文字列のまま取り込んで、そのあと必要なフィールドだけ抽出する」ようにしました。
外部テーブルではJSON Linesをそのまま1カラムのレコードとして取り込み、その後BigQueryの関数を使ってパースしたテーブルを定期的に作ります。

こうすれば、外部テーブルは一度作ってしまえばずっと使えるし、パースするクエリを変更したタイミングから新しいスキーマでテーブルが作られるようにできます。

これを実現するために、

  • JSON Linesを1カラムのレコードとして取り込む
  • 定期的に外部テーブルにクエリして結果を保存する

といったことをやっていきます。

JSON Linesを1カラムのレコードとして取り込む

BigQueryでJSONフォーマットを指定すると、すべてのフィールドをパースしようとします。「ここまでパースして!これより深いネストはパースしないで!」というワガママは聞いてくれないのです。

というわけで、「これはJSONフォーマットではありません」という風に教えてあげます。

具体的にどうするかというと、同じ1行1レコードであるCSVを指定します。
BigQueryのCSVフォーマットにはデリミタを指定することができるため、データに入り得ない文字を指定すれば1行1カラムとしてパースされます。

外部テーブルは、通常のテーブルと同様にGCPコンソールやコマンドラインツールから作成することができます。

bq mk --external_table_definition=tabledef.json dataset.table
{
    "csvOptions": {
        "allowJaggedRows": false,
        "allowQuotedNewlines": false,
        "encoding": "UTF-8",
        "fieldDelimiter": "",
        "quote": "",
        "skipLeadingRows": 0
    },
    "schema": {
        "fields": [
            {
                "name": "fields",
                "type": "STRING"
            }
        ]
    },
    "sourceFormat": "CSV",
    "sourceUris": [
        "gs://bucket/*.gz"
    ],
    "hivePartitioningOptions": {
        "mode": "STRINGS",
        "sourceUriPrefix": "gs://bucket/",
        "requirePartitionFilter": true
    }
}

デリミタには制御文字を指定しています。
JSONは制御文字をエスケープしなければならないため、エスケープされていない制御文字をデリミタに指定すれば1カラムのテーブルができます。

……そう、JSONは制御文字をエスケープしなければなりません。
しかし、外部テーブル定義ファイルはJSONです。つまり上の外部テーブル定義はJSONとして読み込めないのです。

File ".../bq/third_party/yaml/lib2/reader.py", line 144, in check_printable
    'unicode', "special characters are not allowed")
ReaderError: unacceptable character #x0001: special characters are not allowed
  in "tabledef.json", position 174

当時のわたしは「一度きりだし、今だけ動けばいいや」とエラーを出しているライブラリを書き換えてコマンドを実行してテーブルを作成しました。
今考えると、BigQueryクライアントライブラリを使えば問題なく作れますね(一度使うためだけに書くのが面倒ではありますが)。試してませんが、ブラウザで制御文字を入力してもできるかもしれません。

定期的に外部テーブルにクエリして結果を保存する

ここまでで、JSONログをBigQueryでクエリすることができるようになりました。
あとは、JSONをパースして必要なフィールドを抽出したテーブルをつくるだけです。

今回は1時間毎にhive partitionがつくられるようになっているため、1時間毎に外部テーブルをクエリして、結果をテーブルに出力するようにしました。

この定期的にクエリを実行するのにはBigQueryの機能である「スケジュールされたクエリ(Scheduled queries)」を使います。

文字通り定期的に指定したクエリを実行してくれる機能で、1日ごと1時間ごとなどの指定はもちろん、特殊な文法ではあるものの任意の間隔でクエリを実行することができます。
これにBigQueryの機能である「Destination Table」を合わせて使うことで、定期的にクエリを実行し、結果をテーブルに書き込むことができます。

クエリには、実行時間をTIMESTAMP型の変数 @run_time として使うことができます。

SELECT
  PARSE_TIMESTAMP('%Y-%m-%dT%H:%M:%E3S%z', JSON_EXTRACT_SCALAR(fields, '$.timestamp')) AS `timestamp`,
  JSON_EXTRACT_SCALAR(fields, '$.message') AS `message`,
  STRUCT<
    `id` STRING,
    `type` STRING
  >(
    JSON_EXTRACT_SCALAR(fields, '$.req.id'),
    JSON_EXTRACT_SCALAR(fields, '$.req.type')
  ) AS `req`,
  JSON_EXTRACT(fields, '$.buyers') AS `buyers`,
  STRUCT<
    `creative_id` STRING,
    `price` FLOAT64
  >(
    JSON_EXTRACT_SCALAR(fields, '$.res.creative_id'),
    CAST(JSON_EXTRACT_SCALAR(fields, '$.res.price') AS FLOAT64)
  ) AS `res`,
  STRUCT<
    `req` STRING,
    `res` STRING
  >(
    JSON_EXTRACT(fields, '$.debug.req'),
    JSON_EXTRACT(fields, '$.debug.res')
  ) AS `debug`
FROM `project.dataset.external_table`
WHERE ts = FORMAT_TIMESTAMP('%Y%m%d%H', TIMESTAMP_ADD(@run_time, INTERVAL -1 HOUR))

Destination Tableのテーブル名にも変数を使うことができます。
UTCからJSTは+9時間ですが、1時間前のデータなので+8hとしています(今回は日別にテーブルを作って append するようにしています)。

table_{run_time+8h|"%Y%m%d"}

まとめ

S3に置いたログファイルを、ゆるふわなままBigQueryで扱うまでの流れを紹介しました。参考になれば幸いです。

BigQueryは細かい調整をせずとも、大抵の問題をお金とパワーで解決できてしまいますが、スキーマなどどうしても融通がきかないこともあります。
そんなときでも、ちょっとした工夫をしてあげれば便利に使えますし、そういった工夫をしやすくするための機能も豊富で、とても魅力的なサービスだと思います。

fluctでは、そんなゆるふわデータを扱ったり、ゆるふわにならないようしっかりスキーマを定義したりして、一緒に事業を作っていく仲間を募集しています。

株式会社fluct SSP開発本部 ソフトウェアエンジニア | 株式会社VOYAGE GROUP
株式会社fluct エクスペリエンスデザインセンター フロントエンドエンジニア | 株式会社VOYAGE GROUP

そーだいなるVOYAGE GROUPの裏側 #fluct 編 広告配信の舞台裏の技術者たち

f:id:Soudai:20201002183831p:plain

 今日は@soudai1025 こと id:Soudai がお届けします。

 そーだいなるイベントが遂にはじまりました。#voyagebook のイベントとして、各事業部のエンジニアにパネルディスカッション形式で話をしていく企画です。 第一回の今回は「広告配信の舞台裏の技術者たち」と題してfluctのみんなとディスカッションしてきました!

voyagegroup.connpass.com

f:id:Soudai:20201002184005p:plain

当日の紹介資料

 資料の中にfluctの紹介やパネラーの自己紹介もあります。 どんな会社なのか気になる!って人もぜひ資料を見てみてください。

speakerdeck.com

 実際のパネルディスカッションの様子は上記の動画をどうぞ。 和気藹々としながらも噂に違わぬ、fluctの豪腕ぶりには驚嘆しました。

 質疑応答の内容に合わせたツイートなどのまとめはこちら。

togetter.com

感想

 本の中では id:suzu_v さんがフォーカスされてましたが、 id:nishigori-dao さんと id:tomi-ru さんの豪腕っぷりもすごかったですね。 オンプレからECSもすごいし、一人で海外向けの事業を立ち上げ、開発、そして粗利がガンガン出しているのは、まさに今話題の 事業がわかるエンジニア ですね。

 fluctは牧場とか技術選定は無いみたいなパワーワードから、技術的な筋力は普段の業務で伸ばすとかゴールのメリットが見えていれば返済も頑張れるなど金言も沢山ありましたね。 見てない人はぜひYouTubeのアーカイブを見ていただければと思います。

次回予告

 次回のそーだいなるVOYAGE GROUPの裏側は Zucks です! ドキュメントを作らない、フルサイクルエンジニア、本番環境で検証する、など独特な文化と圧倒的なアウトプット力が特徴のチームです。 Zucks回を見た時、「自分がなりたかった理想のエンジニア像はこれだ!」と思う人も多いのではないでしょうか。

 なんと id:Soudai も普段はZucksの中のアフェリエイトチームのお手伝いをしています。 アジャイルだけどスクラムではない、型にハマらないサバンナのようなZucksの話も間違いなく面白いのでぜひ皆さんご参加ください。

voyagegroup.connpass.com

 次回のこの時間もサービスサービス♫ 次回のZucks回もよろしくおねがいします!

techlog.voyagegroup.com

#技育祭 「400人以上の...若手エンジニアが成長するコツ」の動画が公開されたので、口頭で回答したことのいくつかをこちらにも記載しておきます

2020年7月4日、5日の2日間で開催された技育祭 2020では3つのセッションに登壇した @makoga です。

CTOパネルディスカッション

初日のオープニングセッションとなるCTOパネルディスカッションでは、『エンジニアリング組織論への招待』の著者であり株式会社レクター 取締役 広木さん、ビジョナル株式会社 取締役CTO 竹内さん、 合同会社DMM.com CTO 松本さんの3人をパネラーに迎え、私はモデレータとして参加しました。

www.youtube.com

このパネラーで面白くならなかったらモデレータの責任だなと思っていたので、たくさんの人が視聴してくれてホッとしました。

Goライブコーディング

午後には、すずけんのライブコーディングの解説役として参加しました。

※動画が公開されたらここに追記します。

こちらも多くの人が視聴してくれました。ライブコーディングはみんな真剣にみるのでイベント中はすごい静かだけどアンケートの結果をみるといつも満足度が高いイベントなんですよね。

400人以上の...若手エンジニアが成長するコツ

2日目には、『400人以上のインターン生を受け入れ成長させてきたCTOが考える若手エンジニアが成長するコツ』という長いタイトルの単独セッションに登壇しました。

www.youtube.com

このセッションは200人以上の学生が視聴してくれたようです。とても嬉しい。

初日に2つ登壇し、他のセッションを視聴したところ、技育祭に参加する学生はたくさん質問してくれることが分かりました。そこで、最後の質疑応答だけではなく、区切りのいいところで質問ピックアップの時間を2回とりました。

f:id:voyagegroup_tech:20200912104628p:plain
アジェンダ - 若手エンジニアが成長するコツ

これは成功だったと思います。たくさん質問をもらえましたし、視聴者の理解も深まったと思います。

このプレゼンで使った資料は公開していますので、若手エンジニアが成長するコツに興味がある人はぜひ読んでみてください。

speakerdeck.com

このエントリでは、当日にもらった質問やコメントに対して、口頭で回答したことのいくつかを記載しておきます。

当日にもらった質問やコメントと回答

  • 学生:ダニングクルーガー曲線の完全に理解したまでいくのが最初のハードル
    • 回答:自分だけで学べるところまでいくのは簡単ではない。勇気を出して周囲のできる人に支援を求めよう。
  • 学生:筋トレみたい
    • 回答:そうですね。コンフォートゾーンの少し外側で負荷を掛けながら力をつけていくのは似てますね。
  • 学生:研究だけに頼らずいろんなものに手を出すべきか?
    • 回答:好奇心を持って脇目をふらず集中できることがあるならそれでいい。壁にぶち当たっていたり、伸び悩んでいるのであれば、周囲に目を向けることも悪くない。
  • 学生:目標に到達し、次の目標を出す方法は?
    • 回答:一歩引いて視野を広げ目標を探索する目標を立てる。もしくは、到達したものにつながる周辺のことに目を向けてみる。
  • 学生:自分の上位互換みない人がたくさんいる中で競争しなければならない場合、どんなことを意識するといいか?
    • 回答:いきなり同じようになれないし、個性が違うのでなる必要もない。上位互換の人の良いところを1つ選び、それを身に着けるようにする。いろんな人の1つをいくつか身に着けると自分の個性につながる。
  • 学生:目標設定が難しい
    • 回答:繰り返しになるが、他の人が持っているもので自分も身につけたいというものがあればそれを目標にしてみるといい。
  • 学生:分からないことを1人で無限に調べてしまう癖がある
    • 回答:調べることは悪いことではないが、時間的な制約があるなら信頼できる人にすぐ聞くのがいい。その場合、答えを教えてほしいではなく、ここで詰まっているので次の1手を教えてほしいという聞き方がおすすめ。
  • 学生:ただ作るだけなら速いが、凝り性なので時間が掛かる
    • 回答:早い段階で、他の人に見せることを意識するのがおすすめ。
  • 学生:質問の仕方に悩む
    • 回答:分からないことを質問するのもスキルである。ファクトを伝えることを意識しよう。やりたいこと、やったこと、結果を区別して伝えよう。
  • 学生:何か作りたいけど、作りたいものがない
    • 回答:普段使っているツールを模倣したものを作ってみるのがおすすめ。そうすれば仕様を考える時間を最小限にし、技術的なチャレンジに集中できる。
  • 学生:これほど育成に力を入れているのはなぜですか?
    • 回答:ソフトウェア開発力、プロダクト開発力がビジネスの競争力の源泉だと思っているから。

まとめ

技育祭はとても盛り上がりましたし、面白いセッションがたくさんあったと思います。

次の機会があれば #voyagebook 『Engineers in VOYAGE 事業をエンジニアリングする技術者たち』をベースに「事業をエンジニアリングするコツ」の話をしようかなと思っています。

[イベントのお知らせ]

voyagegroup.connpass.com

#voyagebook の書評で頻出する3つのテーマ

こんにちは。技術広報の丹野です。 2020年8月7日に発売された『Engineers in VOYAGE 事業をエンジニアリングする技術者たち』(ハッシュタグ #voyagebook)ですが、その後多くの方々から素敵な感想/書評をいただきました。とてもありがたいですね。今回は本書の書評の中で取り上げていただく機会が多かったテーマについてまとめたいと思います。

f:id:tan2jpn:20200911165048j:plain

頻出する3つのテーマとその書評

生々しい、ここまで公開していいのか

blogやTwitter、Facebookなどでの反響で特に目立つのは、「ここまで赤裸々に公開して大丈夫?」という趣旨のものです。 いずれもVOYAGE GROUPの現役のサービスに関する話題なので、過去に直面した課題のことが話されていても、現時点では解決しているか、解決に向かって進んでいます。そういう観点では安心してお読みください。

​ 将来の状況の変化に伴う課題をあらかじめすべて想定して事業を始めることは、現実的には困難です。 そのなかで、開発者もまた事業の当事者として、システムの技術的な課題だけでなく事業の要請から生まれる課題にも取り組んできた結果が「生々しさ」につながっているのだと思います。 その生々しさがリアリティとして伝わったならうれしいです。 ​

いくつか印象に残った書評を下記に引用させていただきました。

珠玉のエンジニアリング冒険譚 〜 書評「Engineers in VOYAGE 事業をエンジニアリングする技術者たち」 : 小野和俊のブログ

そしてこれらの課題に対して、それぞれのプロジェクトでどんな風に考え、どんな文化を大切にし、どんな苦労に直面しながら、これらを乗り越えてきたのかが記されている。その内容は「企業の名前を入れた本で、ここまで書いていいのか」と思えるほどに赤裸々だ。興味深いのは、テーマの重さと対照的に、課題を乗り越えるためのアイデアはほとんどすべてがしなやかさや遊び心を感じさせる軽やかなものだということだ。

Engineers in VOYAGEを読んだ - Diary over Finite Fields

生々しさゆえ、読んでいても爽快感を覚えることはない。しかし、事業に向きあう開発者を美化せずに描いているし、そして課題解決の過程がとてつもなく面白い。

技術的負債との向き合い方:カッとなってやる短期決戦と腹を括ってやる長期戦

「技術的負債」というキーワードへの反応もたくさん頂戴しています。 インタビュワーの和田さん自身、本書の制作過程であらためてウォード・カニンガム氏による「技術的負債」のもともとの含意を手繰り寄せられたことからも、「技術的負債にどう取り組んでいくか」は本書の大きなテーマのひとつだったと言えるかもしれません。 ​

特に、第3章のVOYAGE MARKETINGや、第5章のサポーターズのエピソードは、数多くの歴戦のWeb開発者の方々の心に響いたようです。 また、第1章のfluctでの「腕力」をめぐる和田さんの話に共感いただいたという声もいくつか拝見しました。 技術的負債との対峙という観点で印象に残った反響を下記に引用させていただきます。

#voyage-book.md · GitHub

fluct の事例では、”技術的負債の返却には腕力が必要” という言葉が登場するのですが、これは非常によくわかるなぁと感じました。こういった過去の辛さを改善していく作業は、ついカッとなってやれる人がいると進んでいくことってあるなぁと振り返ってみても感じます。

一方、ECナビの事例では戦略的に改善していく事例が紹介されていて、これをコツコツやれるのはすごいと感じました。その中で複雑すぎるテーブルの関連性をツールを使って可視化したけど複雑すぎることがわかっただけで有効活用されなかったという話はあるあるで好きでした。複雑なシステムをツールなどを使って可視化してみたけど、どうすればいいのかわからずそこで満足して終わってしまうことはよくありますが、そこから別のアプローチで進めていったのはとてもいい事例だなと感じました。

事業会社の現場 - 「Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち」 - Shin x Blog

3 章は、それ以外にも、データベースのテーブル数を 1200 から 450 まで減らしたり、システムをスリム化していく流れでコード、機能、事業の削減(葬り)に分けて実施していくという骨太の内容でした。これを 5 年かけて通常業務と並行しながら除々に実施したというのは、大変ではありますが、粘り強く少しづつでも進めることで技術的負債を返却できるという一つの指針を見ることができました。

Engineers in VOYAGE - 事業をエンジニアリングする技術者たち - を読んだ

単に技術的な機能面だけはなく、事業ごと葬る、といったようにビジネスサイドとも合意を得て力強く進められていることがわかる。 このような経験・スキルは中で体験しているエンジニアでないと獲得しがたいものである。もちろん、書籍から得られる知見は表面上に限るかもしれないが、その内容について少しでも触れることができるという意味で、大変貴重な書籍である。

事業を作る人達の物語が最高だった #voyagebook - そーだいなるらくがき帳

要所でそれぞれの事業部がそれぞれの技術的負債に対して、どのように解決してきたかが書いてある。 そのアプローチは事業のフェーズ、規模によっても当然違ってくるが、それが各事業毎に違ったアプローチで書かれているのだが、それがとても参考になる。 リプレースなのか、リアーキテクチャなのか、リファクタリングなのか、それぞれ全く違うアプローチを1冊でそれぞれ見れる貴重な本だ。 今まさに技術的負債に立ち向かおうとしているのであれば一度は読んだ上で、アプローチの参考にしてほしい。

本:Engineers in VOYAGE - 事業をエンジニアリングする技術者たち|hidenorigoto|note

本書を読んで私が思うのは、VOYAGE GROUPは、負債の上手い乗りこなし方を身に付けているということです。事業開発という目的のためには、避けて通れない技術的負債の問題に対して、組織としての対応能力を磨いているように思います。

事業をエンジニアリングする

本書のサブタイトルにもある「事業をエンジニアリングする」という観点への反響もたくさん頂いています。 当初は『事業をエンジニアリングする技術者たち』のほうが本書のメインタイトルだと思われてしまう誤算もありましたが、 これはカバーの印象だけからくる勘違いではなく、やはり本書を実際に読んで感じて頂いたものが「事業をエンジニアリングする」というフレーズにとても合致していたからこそだと思います。 ​

頂いた反響のなかにも、下記に引用させていただいたもののように、このフレーズに込めたメッセージを的確に読み取っていただけたと感じられるものがたくさんありました。

珠玉のエンジニアリング冒険譚 〜 書評「Engineers in VOYAGE 事業をエンジニアリングする技術者たち」 : 小野和俊のブログ

正論だけではまかりとおらない、事業という複雑で壮大な冒険をVOYAGEのエンジニアたちはどんな風にして生き抜いてきたのか。 本書のサブタイトルは「事業をエンジニアリングする技術者たち」。 そう。ここで登場するエンジニアたちは、ソフトウェアだけでなく、事業そのものをエンジニアリングしているのだ。

「Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち」を読んだ #voyagebook | by Yuki Fujisaki / tnj | Aug, 2020 | Medium

この本の中では、事業方針や組織体制と、開発して生まれるソフトウェアの設計は切っても切り離せない、コンウェイの法則的な話が何度か登場します。また、出てくるチームは大きさもバラバラで、文化もそれぞれ異なりっているのですが、事業としてのエンジニアリングを全員が認識しているのが自分の中では印象的で、フルスタックエンジニアではなくフルサイクルエンジニアの考え方を軸に置いているのが組織文化に繋がっているように感じました。

事業を作る人達の物語が最高だった #voyagebook - そーだいなるらくがき帳

5年、10年、15年モノの事業との付き合い方や0から始める新規事業との付き合い方、そしてそれぞれのフェーズで新しいことにチャレンジしていくために如何にビジネスを犠牲にせずに立ち向かっていくか。 そんな物語の中に哲学がある。

「事業をエンジニアリングする技術者たち Engineers in VOYAGE」を読みました

エンジニアが勝手に考えた「キレイなシステム」とか「最強のシステム」ではなく、ビジネスと照らし合わせた上で解決すべき課題を定義して改善するという進め方が全体としてあるように感じました。

#voyage-book.md · GitHub

エンジニアリングは事業のために行われるものであり、本書では様々なシステムや様々な状況の話が出てくるのですが、事業のためにという点が全ての共通点としてブレてない点に企業としての強さを感じました。この点については技術力評価会に参加している中でも感じたことだったので、本書を読んだ改めて納得した部分です。

事業会社の現場 - 「Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち」 - Shin x Blog

インタビュイーである開発現場のエンジニアの方々が圧倒的な当事者意識を持って仕事に取り組まれているということです。これはシステムに対してだけでなく、事業に対しても同様です。事業会社で働くなら当たり前のことかもしれませんが、システム、さらにその目的である事業をいかに自分のこととして捉えられるかによって考え方も起こすアクションも変わってきます。

事業会社の現場 - 「Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち」 - Shin x Blog

こうした当事者意識は本人の心持ちだけではなく、それを後押しする環境、文化にも影響を受けます。もし、自分がこうした意識を持とうとしても、すぐにボールを取り上げられる環境や事業サイドの下請けのような立場になっている環境ではそれを継続することは難しくなります。本書で登場する 5 社では現場のエンジニアが当事者意識を持てるような、後押しするような環境になっているのだろうということを感じました。

本:Engineers in VOYAGE - 事業をエンジニアリングする技術者たち|hidenorigoto|note

ソフトウェアエンジニアのモチベーションの源泉というのは人によって様々ですが、「事業に貢献する」ことに強くモチベートされる方が、偶然私の周りには多くいます。「Engineers in VOYAGE - 事業をエンジニアリングする技術者たち」は、そういう種類のソフトウェアエンジニアが読むと、この会社で仕事したら楽しいだろうな!と思わせてくれる本だと思います。

書籍『Engineers in VOYAGE 事業をエンジニアリングする技術者たち』とは

本ブログによる発売エントリ

書籍「Engineers in VOYAGE 事業をエンジニアリングする技術者たち」が発売 #voyagebook - VOYAGE

  • 本書内の「はじめに」を全文掲載しています。

本書の編者:和田さん (@t_wada)のブログエントリ

『Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち』ができるまで #voyagebook

  • 「はじめに」のはじめに、本書のきっかけ、インタビュー準備と本番、各章の読みどころ、本書へのさまざまな方からの感想などをまとめていただいています。

本書の編集者:鹿野さん (@golden_lucky) のブログエントリ

2010年代に日本のインターネットでいろんな事業をいい感じにやってきた会社から2020年代へのヒントをもらえる本を作った

  • なぜ VOYAGE GROUP?なぜ t_wada?なぜ宇宙船?で、結局のところどういう本なの?など、鹿野さんの視点から本書を振り返っていただいたアツいブログエントリ。

本書の購入について

最後に

VOYAGE GROUPのエンジニアたちやエンジニアリングの文化に興味を持っていただけた方は、本書のインタビュイーたちともカジュアルに質問や情報交換などができる機会を設定したいと思いますので、以下のリンクからご応募いただけると幸いです。

「Ask the Engineers in VOYAGE」