目次
■エンジニアの軌跡
2016.08.23 2024.03.28 約7分
さまざまな企業で働くエンジニアとリレー形式で対談を行うDevRelay。vol.6は大学院生時代に CTO として「トリッピース」の立ち上げに関わった経歴を持つ鈴木氏の登場です。現在はVOYAGE GROUP で SSP を提供する株式会社fluct で主にデータ分析基盤の開発に携わっています。「若手Webエンジニア交流会」や、Go言語の勉強会「Shibuya.go」も開催する鈴木氏。本記事では鈴木氏がエンジニアになろうと思ったきっかけからGo言語のこと、エンジニアに必要な「経営的視点」を伺いました。
idesaku：東京大学大学院、伊藤さんからの紹介で、今回は fluct の鈴木健太さんにお話を伺います。「suzukenさん」とお呼びしていいでしょうか？
鈴木：いいですよ。よろしくお願いします。
idesaku：ちなみに、suzukenさんは前回の伊藤さんのインタビューはご覧になりましたか？ 伊藤さんいわく「鈴木さんは、ギークっぽさがなく、ニュートラル」ということだったんですが……。
鈴木：いやー、そんなふうに紹介されたのは初めてです。
idesaku：ですよね（笑）。そもそも suzukenさんと伊藤さんは、同じところで仕事をされていたんでしょうか。
鈴木：前回のインタビューでも触れられていましたが、もともとヒザくん（伊藤氏のこと）が、VOYAGE GROUP で fluct に関わっていたときに、同じフロアで作業をしていたころに知り合いました。当時、彼は SSP（Supply Side Platform）系をやっていて、僕はデータの分析系、基盤系をやっていました。ある時、社内勉強会のようなものがあったんですが、そこで、前回も名前が出たajiyoshiさんが共通のメンターになって一緒に勉強していたという縁がありました。
idesaku：伊藤さんは、最近も suzukenさんと一緒に飲んだと言っていました。今も仲がいいんですね。
鈴木：ええ、この間も、彼が夜にふらっと会社にやってきて Ajiting（VOYAGE GROUP 内にあるバースペース「Bar AJITO」で飲むこと。夜になるとアルコール類も無料）しましたよ。
idesaku：suzukenさんは、学生時代にスタートアップで CTO をやっていたという話も伺っているのですが、そもそも、どういう経緯でテクノロジー方面にかかわるようになったんでしょう。
鈴木：プログラムを最初に書いたのは大学1年のときでした。数学の問題を解くプログラムを Ruby でというものでしたね。もっとも、その時には、それを仕事にするつもりはなかったんです。直接のきっかけになるような出来事は、その後にいくつかありました。
1つは、先輩の紹介で行った、特許関連の手続きを行う法律事務所での事務のアルバイトです。そこは、多数の Excelファイルと使い勝手がいまいちな社内システムを相手に、人海戦術でタスクをなぎ倒していくような環境でした。
そこで仕事をしていくうちに、いろんな作業がプログラミングで自動化できるんじゃないかと気がつきました。VBA でプログラムを書いて、それを使った社内の他の人に「便利になった」と喜んでもらったりして。この時、初めて「プログラミングで人の役に立つことができるんだ」という感覚を得ました。
idesaku：「自分のため」はもちろん、「人のため」にプログラムを書けることを意識されたんですね。ちなみに、大学の専攻は何だったんでしょうか。
鈴木：慶應大学理工学部の管理工学科です。経営工学的なことを学ぶ学科で、工場のラインでの生産性の上げ方についてとか、管理会計などについてもやるのですが、その中のひとつに情報工学があり、それを選んだという感じですね。ストレートな情報系とは、ちょっと毛色が違います。
idesaku：今は、そういうところでも Ruby を教えているんですか。面白いですね。そのバイトしていた法律事務所での経験が、その後のコース選びに何らかの影響を与えたということなんでしょうか。
鈴木：そうだと思います。4年のときに人工知能系の研究室に所属したのですが、そこでは、Webまわりの技術と AI の技術を組み合わせて何かをやるということに取り組みました。3年の時にも、その先生の授業があって、Web関連の技術を用いたプログラミングを初めて体験しました。JavaScript で双六みたいなゲームを作るといった簡単なことでしたが、それがすごく楽しかったというのも、その後の進路選びに影響していますね。
idesaku：大学時代に関わったスタートアップというのは、その流れですか。
鈴木：いえ、そちらのきっかけはまた別です。修士1年のときに、VOYAGE GROUP のインターンにきていたんですが、同じころ、技術系以外のインターンとして同じく VOYAGE GROUP にきていた石田言行（いあん）という人物に突然「話したい」と声をかけられたんです。
AJITO で飲みながら、「トリッピースというサービスを立ち上げたいと思っているんだけれど、エンジニアがいない。鈴木くんはプログラムが書けると聞いたので、よかったら一緒にやらないか」という感じで誘われました。それが2011年のはじめごろです。
ちょうど就活中だったんですが、具体的に何をやりたいかというイメージも固まっていませんでした。そんな状況で「ちょっとやってみるか」といった感じで参加することにしたのがきっかけです。結局それから、修士2年の終わりまで、研究と並行してトリッピースのエンジニアリングに関わっていました。
idesaku：トリッピースは旅行に関するソーシャルサービスですよね。研究されていた「Web と AI の組み合わせ」というテーマと、どこかで接点はあったのでしょうか。
鈴木：僕が研究でやっていたのは、「セマンティックWeb」に近い領域でした。会計に関わるようなデータを、よりセマンティックWeb 的に扱うためにはどうすればいいかといった視点で、データモデリングをしたり Web API を作ったりといった感じです。
トリッピースは旅行の Webサービスで、ビジネス寄りではありましたが、とはいえやはり Webサービスということで、共通点はあったといえるかもしれませんね。
idesaku：修士の間はトリッピースに関わられて、修了後に fluct に就職されたわけですね。
鈴木：実は就職活動をしていた段階では、キャリアとして何をやっていくかについて、明確な考えがなかったんですよ。でも、トリッピースに関わる中で、エンジニアリングのスキルを使って、ものやサービスを作り出すことに面白さを感じるようになりました。それが、仕事としてエンジニアをやっていこうと思った、直接のきっかけだったと思います。
idesaku：どちらかというと「インフラエンジニア」寄りの印象があったのですが、現在の指向はそちらにあるんですか。
鈴木：うーん。自分では、一貫してソフトウェア、アプリケーション側の立場だと思っているんですよ。僕の場合は、ミドルウェアやアプリケーションを動かすために、自分で必要なインフラを整えたりすることはありますが、そこまでです。「インフラエンジニア」には、より深いハードウェアやネットワークの知識が必要ですよね。自分の関心は、そちらにはないんです。
「サーバ／インフラエンジニア養成読本」に寄稿したのは、Fluentd、Elasticsearch、Kibana といったツールを使って、ログデータの収集／解析と可視化を行い、データを組織の中で生かして行く方法を俯瞰的に紹介するものでした。
とはいえ、その中には「ログ収集基盤がなぜ必要なのか」や、そのためのインフラをどう用意するかといった話も含まれてきますので、インフラとアプリケーションの中間ぐらいの領域でしょうか。表現が難しいので、最近はざっくり「ソフトウェアエンジニア」と自称するようになりました（笑）。
idesaku：うーん。なるほど。私の中でも、「データ分析基盤」というもののイメージが、まだなんとなくモヤモヤしています。端的に、suzukenさんがfluctで関わっているお仕事を説明するとしたら、どう言えば良いのでしょうか。
鈴木：そうですね…。まず「データ分析基盤」については、簡単に言ってしまうと「行動ログをはじめとする多様なデータが、いろんなデータソースから1カ所に集められていて、必要に応じて分析に使える状態になっている」環境全体のことを指します。クエリ発行の部分に限れば、Google の BigQuery や Amazon の Redshift など個別の環境があるわけですが、コアとなるその部分にどうデータを流し込むかまでを含めた、全体の仕組みを「データ分析基盤」と呼んでいます。
idesaku：そこには、データモデリングをどうするかとか、どのように格納しておくかといったあたりの設計も含めて、「データアナリストが解析しやすいデータ環境」を作り出すという作業が入ってくるわけですね。
鈴木：そうなります。クエリを発行可能になるまでの段階をひたすらがんばるのがメインの仕事になります。データ分析における前処理の専門家なので「マエショリスト」などとも呼ばれていますね（笑）。
idesaku：ハンドリングするデータのサイズとしては、テラバイト級を毎回一気にといった感じですよね。
鈴木：はい、そういう部分も含めてやっています。入社してすぐのころは、Amazon Elastic MapReduce で Hadoop の基盤を作って、そこにネットユーザーの行動ログを流し込み、分析結果をもとにして、「セグメント」とよばれるいくつかのカテゴリに割り当てるような、広告のターゲティングの仕組みを作っていました。「DMP（Data Management Platform）」と呼ばれる、ログデータの分析結果からユーザーのアクションを促して最適化するような仕掛けを作り出す分野です。
idesaku：fluct は、アドテク分野でも特に「SSP」を提供してらっしゃるんですよね。その中で、DMP はどういう役回りになるんでしょう。
鈴木：アドテクは「媒体と広告主をつなげるための仕組み」なのですが、僕らのやっている SSP は、媒体のほうに近いプラットフォームです。逆に、広告主側に近いものは「DSP（Demand-Side-Platform）」と呼ばれます。DSP は、広告主側で予算や訴求プランに応じた広告配信を管理する仕組みになります。
SSP である fluct の役割は、僕らの仕組みを使って広告を掲出している1万ほどのサイト、つまり媒体に、「よりイイカンジで広告を出す」ことになります。媒体を見ているユーザーの行動ログから、どのように広告を配信すれば、より効果的にアクションへつながるかを分析して、実行するのが DMP の役割になります。
idesaku：なるほど。いかに「イイカンジで広告を出せる」ようにするかが、SSP におけるデータ分析基盤の使いどころというわけですね。実際の配信は、SSP と DMP が連動して、完全に自動化されているわけですか。
鈴木：もちろん人的な判断が加わることもあります。例えば、広告マッチングにおいて、特定のキャンペーン広告を打つ際に、よりクリックレートが上がりそうな媒体があれば重点的に配信してみたり、逆に、メディア側から特定のジャンルの広告を出さないようにしてほしいという要望があれば、それに個別に対応したりといったことをしています。
fluct の強みは、SSP のシステムをすべて自社内で作って運営している点だと思います。エンジニアだけでなく、オペレーターもシステムの内部をよく知っているので、突発的なユーザー行動の変化や季節変動、お客様である媒体側の要望にも、かなりフレキシブルに対応できるんです。
idesaku：ところで、このところ「Go」を書かれているとか。どういうところがいいのでしょう。
鈴木：Go は、最初に覚えなければならないことが少ないんですね。言語仕様がコンパクトで、標準ライブラリの機能なども最小限に絞られていながら、できることは多い。そういうところが気に入っています。
idesaku：逆に、Go以外だとどんな言語を使われているんですか。
鈴木：PHP や JS系ですね。あと、Ruby や Python も。でも、そのあたりでやっていたようなことについては、だんだん Go でやるようになってきています。必要に応じて Java や Scala も使いますが、あまり多くないです。
idesaku：Go は、コードをコンパイルしてバイナリを作るというスタイルも含めて、C++ で辛い思いをした人に向いた言語のようなイメージがあります。ただ、今のお話しからは、Ruby や Python よりも使いやすいと評価されているようにも感じたのですが、それはどういったところでしょう。
鈴木：まず運用の観点で言えば、デプロイが楽ですね。Ruby や Python だとデプロイする先の環境に依存モジュールをすべて置いておく必要がありますが、Go ではビルド時にそれらをすべて含めてしまうことができます。マルチプラットフォーム向けに簡単にビルドできることもあって、最終的にできあがったバイナリを展開先に置くだけで済みます。
あと、Go は静的型付けのチェックが非常に強力な言語で、そのメリットを Java ほど長くコードを書かなくても得られるというのも大きいです。
idesaku：型推論があるということですか。
鈴木：型推論ではないんですが、インターフェースの機能が強力です。 Java だと、あるクラスがインターフェースを実装していることを implements で明示しなければいけません。でも、Go では実装の有無を自動的に判別してくれるので、指定したインターフェースを備えているものに対して何かする、というような処理をより簡単に書けます。
idesaku：ビルド時に依存するライブラリをすべて含めてしまうということは、Go ではダイナミックリンクのような仕組みはあまり使わないんですかね。
鈴木：僕はあまり使いませんが、たとえば外にある C のライブラリを呼び出したいときに使える「cgo」のような仕組みはありますね。
idesaku：プログラム本体のファイルサイズは膨らむかもしれないけれど、今のコンピューティング環境を考えれば、そのデメリットは微々たるものですしね。それよりも、プラットフォーム間の差異を気にすること無く「できたものをただ置けば動く」というシンプルさから得られるメリットのほうが大きいですね。
鈴木：あと、Go を使っていて感じる大きなメリットとしては、使える周辺ツールが充実しているというのもあります。フォーマッターに linter、パッケージ管理ツールなど一通りそろっていますので、特にチームで何かを作るようなときには作業が進めやすいのではないかと思います。
idesaku：今年に入って「Shibuya.go」という、Goの勉強会も何度か主催されていますよね。
鈴木：そもそも、僕がソフトウェアエンジニアになろうと思ったきっかけのひとつが、同じジャンルの仕事をしている人たちが、勤めている企業に関係なく、勉強会などを通じて気軽に会える雰囲気がある業種だと感じたことなんです。そこで実際に技術が身につくかどうかは別にして、いろんな人と会って話ができる場があるというのが好きですね。Shibuya.go 以外にも、就職した年から「若手Webエンジニア交流会」というのを立ち上げて、継続的にやっています。
idesaku：Shibuya.go のほうは、今年からスタートして3月に2回目が開催されたところで、かなりのハイペースですよね。
鈴木：「Shibuya.go」については、そろそろ3回目をやりたいと思っています。
鈴木：実は今、共著で Go の本も書いているんですよ（「みんなのGo言語【現場で使える実践テクニック】」技術評論社刊、9月9日発売！）。
idesaku：Goプログラミングの入門書的なものですか。
鈴木：どちらかというと、Goプログラマー向けの Tips集のようなものになる予定ですが、もちろん入門的な内容も含まれてきます。僕はその中でテストについて書くことになっています。
VOYAGE GROUP って、全体的にテストを極めて重視する文化があるんですよ。エンジニアが互いに評価し合う仕組みがあって、その結果がある程度、給与などにも影響するのですが、その中でもテストを含めたソフトウェアの品質管理や、長期的な目線でプロダクトを作れているかといったことが評価の重要な基準になってきます。
idesaku：分析系のシステムをテストするのは大変そうですね。
鈴木：分析結果や機械学習の結果に対してテストしようとすると、たしかに大変で、それは今後の課題ですね。むしろ、それより手前の段階、つまり分析基盤を成り立たせるために必要なソフトウェアをクリーンに作っていくという意味でのテストは、いわゆるユニットテストや結合テストのような形でしっかりやっていけると思っています。
idesaku：あと、suzukenさんは、GoでSchemeインタプリタを実装するようなこともやっておられましたよね。あれは純粋に Go の勉強のためにされたのですか。
鈴木：あれは「SICP（計算機プログラムの構造と解釈）」という本に触発されたところが大きいですね。社内にも、あれを読んでいるエンジニアが結構います。計算機科学の本なので、最初のほうはプログラミング言語の動きに関する話があるものの、徐々にインタプリタやコンパイラを作る話に入っていくんですね。「言語」を作れる人というのは、エンジニアの中でも「魔法使い」のような特別な存在じゃないですか。僕は、自分では作れないものを作れる人を、ものすごく尊敬するし、憧れるんですよ。で、この本を読んで、自分が言語を書けるとしたらどんな感覚になるのかに興味が出てきて、試してみたんです。
idesaku：たしかに、普通のアプリケーションを書くのとはまったく別の感覚でしょうね。
鈴木：ソフトウェアエンジニアを続けていきたいと思っている人は、何らかの形で小さな言語や小さな OS を自ら実装するということをやっておいたほうがいいだろうと思います。言語も OS もソフトウェアのひとつの形ですから、その設計から学べることは多いと思うんです。
実は、今、Go を使っているのには、そうした理由もあります。今の Go は、標準ライブラリもすべて Go で書かれているんですけど、それらが非常にクリーンで読みやすいです。その点で、一番「Goらしさ」を持っているのが、Go 自体の標準ライブラリだと思います。Go でプログラムを書きつつ、Go という言語そのものから、ソフトウェアについて学ばせてもらっている感覚がありますね。
idesaku：現在はデータ分析基盤を作っていくというお仕事をされているわけですが、将来的にも、この方向を突き詰めていきたいと考えていらっしゃるんでしょうか。
鈴木：直近はともかくとして、今のところ「10年後にこういうことをやっていたい」というような強い思いはないんですよ。これまでも、常にその場で知識とスキルを足し算しながら積み重ねている状況なので、当面はそんな感じで続けていくんじゃないでしょうか。ただ、ベースとして「ソフトウェア」と「インターネット」が好きだという部分は変わらないので、その領域でものを作ることは続けていきたいと思っています。
idesaku：今日は Go やデータ分析基盤に関するお話しを多く伺ったのですが、それ以外に、今後面白そうだと感じている技術分野はありますか。
鈴木：僕は長く職業エンジニアをやっているので、どちらかというと「課題の発見」や「その課題をどう解決するか」に意識が向いていて、あくまでも技術はその手段なんですね。なので、技術領域に興味を絞るのは苦手です。
トリッピースに関わったときも、最初は Webサイト上に細かい機能を追加するようなことをやっていたんですが、次第に「サイトのビジネスとしての成長を見ていくためには、データ分析が必要だ」と思うようになり、Google Analytics のようなものを自分で作りたいと考えました。
トリッピースは、ユーザーが交流しながら旅行をプランニングし、実際に旅行に行ってかけがえのない体験を共有してもらうことを目指したサイトで、運営側は、そうした交流を促進していくためにどうすればいいかをひたすら考えて作り続けていました。動ける人数が限られた中で、必要な情報を集め、改善点を見出していくために、エンジニアとしてできることは何だろう、と考えていった先にデータ分析という分野があったわけです。
ニーズが先にあって、その解決のために技術を探し求めるという順番なので、むしろ関心のある分野は「業務」や「ビジネス」のほうになりますね。
idesaku：トリッピースでは CTO という立場で、経営にも関与されていたんですよね。
鈴木：はい。ビジネスの課題や目標に対して、技術面からどう手を打つかについて考える立場でした。会社という組織の行動を決めるのは経営判断ですよね。であれば、そこに属するエンジニアがコードを書くことも経営判断の一部です。企業としてやるべきこと、サイト上で実現すべき機能がたくさんあるものの、どこから着手すべきかは誰も見当が付いていない中、それを考えながらものを作っていくのは、とても面白い経験でした。
idesaku：問題解決のためのソフトウェア作りが興味の中心にあるわけですね。将来的には、また経営を行う立場になりたいという考えがあるのでしょうか。
鈴木：実は fluct でも、一時マネージャーをやったのですが、1年くらいやってみて降りたんですよ。マネジメントに興味がないわけではないのですが、仕事への割り込みの増加にうまく対処できなくて。そうした現状で、限られた時間をできるだけ有効に使ってより多くのアウトプットを得ようと考えると、現時点ではいちエンジニアとして働いた方がよいと判断しました。
ただ、企業がソフトウェアを作っていくにあたっては、エンジニアにも経営的な視点が必要になるフェーズが絶対にあるというのが僕の考えです。fluct では、明確にパートナーや競合が存在する中で、競争に勝つための機能を作っていくことが求められます。その中で、例えば自社の複数のサービスで共通して使える汎用的な機能を優先して作れば、そこから得られる経営上の効果は「かけ算」で大きくなります。
その機能が何なのか、どれを優先すればいいのかといった明確な指示は、トップダウンでは出てきません。現場ベースで考えを取りまとめ、必要性を説明し、段取りを決めて実装する。そういう開発の進め方がとても重要だと思いますし、僕としてはそれを実践しているつもりです。
idesaku：一度 CTO の立場で仕事に向き合われた経験からだと思いますが、ソフトウェア開発を非常に広い視野で捉えていらっしゃると感じます。
鈴木：どんな企業であっても「必要なことを全部知っている人」というのは、いないと思うんですよ。競合の状況に詳しい人でも、社内のことは案外知らなかったりする。システムのことを良く知っているエンジニアも、常に外に出ている営業さんのニーズは分かっていなかったりする。そうした断片を拾い集めて、その中から「何が重要か」を見つけ出せる人というのは、絶対に必要です。だれも正解を分かっていない中で、それを考えだす作業も「仕事」の一つだと思うんです。
idesaku：お話しを伺って、伊藤さんが、鈴木さんのことを「不思議な人」と評された理由が分かる気がしました。コードも書くし、インフラも触るし、コミュニティ活動にも携わるし、経営的な感覚も持っている。本来、エンジニアが1人で持つのは大変な、複数の視点を持っていて、そのすべての立場で積極的に活動しておられるのが「不思議」で「ニュートラル」な雰囲気の根底にあるような気がします。
鈴木：もうちょっと「ギーク感」を出した方が良かったですかね。（笑）
idesaku：Go で Schemeインタプリタを実装するというのは、十分にギークがやることだと思いますよ（笑）。ただ、活動の総量が多いせいで、「ギーク」な印象が薄まって感じられるのかもしれないですね。
では、最後に次回のインタビュー相手をご紹介いただけますでしょうか。
鈴木：若手Webエンジニア交流会などでもつながりのある、坂本卓巳（@takus）さんを指名させてください。現在は「スマートニュース」のエンジニアです。
idesaku：鈴木さんから見て、坂本さんはどんな印象の方ですか。
鈴木：僕と同年代の社会人で、サッカーがすごく好きです。あと、彼も「ギーク感」がないと思います（笑）。
普段は温厚だけれど、システムのアーキテクチャなどを作るときには、非常にカッチリと、ソリッドに考えをまとめる印象がありますね。仕事も早いです。あと、ベースはインフラエンジニアですが、サービス寄りの考え方もできる、バランス感覚の良い人というイメージがあります。
idesaku：特に聞いてみたいテーマはありますか。
鈴木：えーと…「スマートニュース、面白い？」とかどうでしょう。
idesaku：わかりました。ぜひ聞いてみたいと思います（笑）。本日はどうもありがとうございました。
※本記事の内容は掲載当時の情報であり、現在の情報とは異なる可能性がございます。
