この連載では、「Forkwell Jobs」の開発にも関わるフリーランスエンジニアの後藤大輔(@idesaku)が、さまざまな企業で働くエンジニアとリレー形式で対談を行っていきます。

前回の伊藤友気氏からご指名のあった第6回のゲストは、fluctの鈴木健太氏(suzuken)です。 大学院生時代にCTOとして「トリッピース」の立ち上げに関わった経歴を持つ鈴木氏は、現在、VOYAGE GROUPでSSPを提供する株式会社fluctにおいて、主にデータ分析基盤の開発に携わっておられます。また「若手Webエンジニア交流会」や、Go言語の勉強会「Shibuya.go」などを通じて、鈴木氏をご存じだという方も多いのではないでしょうか。今回は、鈴木氏がエンジニアになろうと思ったきっかけから、現在気に入っているという「Go」のこと、職業エンジニアとしての関心事、将来の展望など、幅広くお話しを伺いました。

鈴木さんご指名のリレー相手は、インタビューの最後でご紹介します！

さらに今回は鈴木さんが登壇するイベントのお知らせもありますよ！

伊藤氏との出会いは「VOYAGE GROUPの社内勉強会」

後藤

東京大学大学院、伊藤さんからの紹介で、今回はfluctの鈴木健太さんにお話しを伺います。「suzukenさん」とお呼びしていいでしょうか？

鈴木

いいですよ。よろしくお願いします。

後藤

ちなみに、suzukenさんは前回の伊藤さんのインタビューはご覧になりましたか？ 伊藤さんいわく「鈴木さんは、ギークっぽさがなく、ニュートラル」ということだったんですが……。

鈴木

いやー、そんなふうに紹介されたのは初めてです。

後藤

ですよね（笑）。そもそもsuzukenさんと伊藤さんは、同じところで仕事をされていたんでしょうか。

鈴木

前回のインタビューでも触れられていましたが、もともとヒザくん（伊藤氏のこと）が、VOYAGE GROUPでfluctに関わっていたときに、同じフロアで作業をしていたころに知り合いました。当時、彼はSSP（Supply Side Platform）系をやっていて、僕はデータの分析系、基盤系をやっていました。ある時、社内勉強会のようなものがあったんですが、そこで、前回も名前が出た@ajiyoshiさんが共通のメンターになって一緒に勉強していたという縁がありました。

後藤

伊藤さんは、最近もsuzukenさんと一緒に飲んだと言っていました。今も仲がいいんですね。

鈴木

ええ、この間も、彼が夜にふらっと会社にやってきて「Ajiting」（VOYAGE GROUP内にあるバースペース「Bar AJITO」で飲むこと。夜になるとアルコール類も無料）しましたよ。

バイト先で書いたVBAプログラムが職業エンジニアとしての原点

後藤

suzukenさんは、学生時代にスタートアップでCTOをやっていたという話も伺っているのですが、そもそも、どういう経緯でテクノロジー方面にかかわるようになったんでしょう。

鈴木

プログラムを最初に書いたのは大学1年のときでした。数学の問題を解くプログラムをRubyでというものでしたね。もっとも、その時には、それを仕事にするつもりはなかったんです。直接のきっかけになるような出来事は、その後にいくつかありました。

1つは、先輩の紹介で行った、特許関連の手続きを行う法律事務所での事務のアルバイトです。そこは、多数のExcelファイルと使い勝手がいまいちな社内システムを相手に、人海戦術でタスクをなぎ倒していくような環境でした。

そこで仕事をしていくうちに、いろんな作業がプログラミングで自動化できるんじゃないかと気がつきました。VBAでプログラムを書いて、それを使った社内の他の人に「便利になった」と喜んでもらったりして。この時、初めて「プログラミングで人の役に立つことができるんだ」という感覚を得ました。

後藤

「自分のため」はもちろん、「人のため」にプログラムを書けることを意識されたんですね。ちなみに、大学の専攻は何だったんでしょうか。

鈴木

慶應大学理工学部の管理工学科です。経営工学的なことを学ぶ学科で、工場のラインでの生産性の上げ方についてとか、管理会計などについてもやるのですが、その中のひとつに情報工学があり、それを選んだという感じですね。ストレートな情報系とは、ちょっと毛色が違います。

後藤

今は、そういうところでもRubyを教えているんですか。面白いですね。そのバイトしていた法律事務所での経験が、その後のコース選びに何らかの影響を与えたということなんでしょうか。

鈴木

そうだと思います。4年のときに人工知能系の研究室に所属したのですが、そこでは、Webまわりの技術とAIの技術を組み合わせて何かをやるということに取り組みました。3年の時にも、その先生の授業があって、Web関連の技術を用いたプログラミングを初めて体験しました。JavaScriptで双六みたいなゲームを作るといった簡単なことでしたが、それがすごく楽しかったというのも、その後の進路選びに影響していますね。当時は、mixiのようなSNSが非常に注目されていた時期で、インターネットやWebへの興味が出てきたというのもあります。

後藤

大学時代に関わったスタートアップというのは、その流れですか。

鈴木

いえ、そちらのきっかけはまた別です。修士1年のときに、VOYAGE GROUPのインターンにきていたんですが、同じころ、技術系以外のインターンとして同じくVOYAGE GROUPにきていた石田言行（いあん）という人物に突然「話したい」と声をかけられたんです。

AJITOで飲みながら、「トリッピースというサービスを立ち上げたいと思っているんだけれど、エンジニアがいない。鈴木くんはプログラムが書けると聞いたので、よかったら一緒にやらないか」という感じで誘われました。それが2011年のはじめごろです。

ちょうどそのころ就活中だったんですが、具体的に何をやりたいかというイメージも固まっていませんでした。そんな状況で「ちょっとやってみるか」といった感じで参加することにしたのがきっかけです。結局それから、修士2年の終わりまで、研究と並行してトリッピースのエンジニアリングに関わっていました。

後藤

トリッピースは旅行に関するソーシャルサービスですよね。研究されていた「WebとAIの組み合わせ」というテーマと、どこかで接点はあったのでしょうか。

鈴木

僕が研究でやっていたのは、「セマンティックWeb」に近い領域でした。会計に関わるようなデータを、よりセマンティックWeb的に扱うためにはどうすればいいかといった視点で、データモデリングをしたりWeb APIを作ったりといった感じです。

トリッピースは旅行のWebサービスで、ビジネス寄りではありましたが、とはいえやはりWebサービスということで、共通点はあったといえるかもしれませんね。

後藤

修士の間はトリッピースに関わられて、修了後にfluctに就職されたわけですね。

鈴木

実は就職活動をしていた段階では、キャリアとして何をやっていくかについて、明確な考えがなかったんですよ。でも、トリッピースに関わる中で、エンジニアリングのスキルを使って、ものやサービスを作り出すことに面白さを感じるようになりました。それが、仕事としてエンジニアをやっていこうと思った、直接のきっかけだったと思います。

関わる技術範囲が広い「データ分析基盤」の道へ

後藤

就職後は、データ分析基盤に関するお仕事に関われているんですよね。suzukenさんは、今年の「AWS Summit Tokyo」で行われたパネルディスカッションにパネリストとして参加されたり（動画）、「サーバ／インフラエンジニア養成読本 ログ収集～可視化編」（技術評論社刊）というムックに寄稿されていたりと、どちらかというと「インフラエンジニア」寄りの印象があったのですが、現在の指向はそちらにあるんですか。

鈴木

うーん。自分では、一貫してソフトウェア、アプリケーション側の立場だと思っているんですよ。僕の場合は、ミドルウェアやアプリケーションを動かすために、自分で必要なインフラを整えたりすることはありますが、そこまでです。「インフラエンジニア」には、より深いハードウェアやネットワークの知識が必要ですよね。自分の関心は、そちらにはないんです。

「サーバ／インフラエンジニア養成読本」に寄稿したのは、Fluentd、Elasticsearch、Kibanaといったツールを使って、ログデータの収集／解析と可視化を行い、データを組織の中で生かして行く方法を俯瞰的に紹介するものでした。

とはいえ、その中には「ログ収集基盤がなぜ必要なのか」や、そのためのインフラをどう用意するかといった話も含まれてきますので、インフラとアプリケーションの中間ぐらいの領域でしょうか。表現が難しいので、最近はざっくり「ソフトウェアエンジニア」と自称するようになりました（笑）。

後藤

うーん。なるほど。私の中でも、「データ分析基盤」というもののイメージが、まだなんとなくモヤモヤしています。端的に、suzukenさんがfluctで関わっているお仕事を説明するとしたら、どう言えば良いのでしょうか。

鈴木

そうですね…。まず「データ分析基盤」については、簡単に言ってしまうと「行動ログをはじめとする多様なデータが、いろんなデータソースから1カ所に集められていて、必要に応じて分析に使える状態になっている」環境全体のことを指します。クエリ発行の部分に限れば、GoogleのBigQueryだとか、AmazonのRedshiftだとか、個別の環境があるわけですが、コアとなるその部分に、どうデータを流し込むかまでを含めた、全体の仕組みを「データ分析基盤」と呼んでいます。

後藤

そこには、データモデリングをどうするかとか、どのように格納しておくかといったあたりの設計も含めて、「データアナリストが解析しやすいデータ環境」を作り出すという作業が入ってくるわけですね。

鈴木 そうなります。クエリを発行可能になるまでの段階をひたすらがんばるのがメインの仕事になります。データ分析における前処理の専門家なので「マエショリスト」などとも呼ばれていますね（笑）。

後藤

ハンドリングするデータのサイズとしては、テラバイト級を毎回一気にといった感じですよね。

鈴木

はい、そういう部分も含めてやっています。入社してすぐのころは、Amazon Elastic MapReduceでHadoopの基盤を作って、そこにネットユーザーの行動ログを流し込み、分析結果をもとにして、「セグメント」とよばれるいくつかのカテゴリに割り当てるような、広告のターゲティングの仕組みを作っていました。「DMP（Data Management Platform）」と呼ばれる、ログデータの分析結果からユーザーのアクションを促して最適化するような仕掛けを作り出す分野です。

後藤

fluctは、アドテク分野でも特に「SSP」を提供してらっしゃるんですよね。その中で、DMPはどういう役回りになるんでしょう。

鈴木

アドテクは「媒体と広告主をつなげるための仕組み」なのですが、僕らのやっているSSPは、媒体のほうに近いプラットフォームです。逆に、広告主側に近いものは「DSP（Demand-Side-Platform）」と呼ばれます。DSPは、広告主側で予算や訴求プランに応じた広告配信を管理する仕組みになります。

SSPであるfluctの役割は、僕らの仕組みを使って広告を掲出している1万ほどのサイト、つまり媒体に、「よりイイカンジで広告を出す」ことになります。媒体を見ているユーザーの行動ログから、どのように広告を配信すれば、より効果的にアクションへつながるかを分析して、実行するのがDMPの役割になります。

後藤

なるほど。いかに「イイカンジで広告を出せる」ようにするかが、SSPにおけるデータ分析基盤の使いどころというわけですね。実際の配信は、SSPとDMPが連動して、完全に自動化されているわけですか。

鈴木

もちろん人的な判断が加わることもあります。例えば、広告マッチングにおいて、特定のキャンペーン広告を打つ際に、よりクリックレートが上がりそうな媒体があれば重点的に配信してみたり、逆に、メディア側から特定のジャンルの広告を出さないようにしてほしいという要望があれば、それに個別に対応したりといったことをしています。

fluctの強みは、SSPのシステムをすべて自社内で作って運営している点だと思います。エンジニアだけでなく、オペレーターもシステムの内部をよく知っているので、突発的なユーザー行動の変化や季節変動、お客様である媒体側の要望にも、かなりフレキシブルに対応できるんです。

後藤

「自動化」と「人力」のいいとこ取りでやっているんですね。

「Go」から「ソフトウェア」の本質を学ぶ

後藤

ところで、このところ「Go」を書かれているとか。私自身も、Dockerに興味を持って調べていくなかでGoにも若干興味があるのですが、suzukenさんは仕事で使っていらっしゃるんですよね。

鈴木

はい。社内で使っているクローラーや、文書を分類するような仕組みのフロントエンドなどは、Goで書いています。

後藤

Goは一般的に使われている他の言語と比べれば、リリースされてから7年前後と比較的新しいですよね。どういうところがいいのでしょう。

鈴木

Goは、使い始めるにあたって、最初に覚えなければならないことが少ないんですね。言語仕様がコンパクトで、標準ライブラリの機能なども最小限に絞られていながら、できることは多い。そういうところが気に入っています。

後藤

逆に、Go以外だとどんな言語を使われているんですか。

鈴木

個人的には、Web系をやってきているので、PHPやJS系ですね。あと、RubyやPythonも少し。でも、そのあたりでやっていたようなことについては、だんだんGoでやるようになってきています。後は、必要に応じてJavaやScalaも使いますが、あまり多くはないですね。

後藤

Goは、コードをコンパイルしてバイナリを作るというスタイルも含めて、C++で辛い思いをした人に向いた言語のようなイメージがあります。ただ、今のお話しからは、RubyやPythonよりも使いやすい何かがあると評価されているようにも感じたのですが、それはどういったところでしょう。

鈴木

いくつか理由があるのですが、まず運用の観点で言えば、デプロイが楽ですね。RubyやPythonだとデプロイする先の環境に依存モジュールをすべて置いておく必要がありますが、Goではビルド時にそれらをすべて含めてしまうことができます。マルチプラットフォーム向けに簡単にビルドできることもあって、最終的にできあがったバイナリを展開先に置くだけで済みます。

あと、Goは静的型付けのチェックが非常に強力な言語で、そのメリットをJavaほど長くコードを書かなくても得られるというのも大きいです。

後藤

型推論があるということですか。

鈴木

型推論ではないんですが、インターフェースの機能が強力です。Javaだと、あるクラスがインターフェースを実装していることをimplementsで明示しなければいけません。でも、Goでは実装の有無を自動的に判別してくれるので、指定したインターフェースを備えているものに対して何かする、というような処理をより簡単に書けます。

後藤

ビルド時に依存するライブラリをすべて含めてしまうということは、Goではダイナミックリンクのような仕組みはあまり使わないんですかね。

鈴木

僕はあまり使いませんが、たとえば外にあるCのライブラリを呼び出したいときに使える「cgo」のような仕組みはありますね。

後藤

プログラム本体のファイルサイズは膨らむかもしれないけれど、今のコンピューティング環境を考えれば、そのデメリットは微々たるものですしね。それよりも、プラットフォーム間の差異を気にすること無く「できたものをただ置けば動く」というシンプルさから得られるメリットのほうが大きいですね。

鈴木

あと、Goを使っていて感じる大きなメリットとしては、使える周辺ツールが充実しているというのもあります。フォーマッターにlinter、パッケージ管理ツールなど一通りそろっていますので、特にチームで何かを作るようなときには作業が進めやすいのではないかと思います。

後藤

今年に入って「Shibuya.go」という、Goの勉強会も何度か主催されていますよね。

鈴木

そもそも、僕がソフトウェアエンジニアになろうと思ったきっかけのひとつが、同じジャンルの仕事をしている人たちが、勤めている企業に関係なく、勉強会などを通じて気軽に会える雰囲気がある業種だと感じたことなんです。そこで実際に技術が身につくかどうかは別にして、いろんな人と会って話ができる場があるというのが好きですね。Shibuya.go以外にも、就職した年から「若手Webエンジニア交流会」というのを立ち上げて、継続的にやっています。

後藤

このリレーインタビューに登場してくれた方の中にも、その交流会に参加されている人が何名かいらっしゃいますよね。

鈴木

ええ。Webでの発言をよく知っている人でも、実際に会ってみると印象が違ったりして、そういうのも楽しいですね。

後藤

Shibuya.goのほうは、今年からスタートして3月に2回目が開催されたところで、かなりのハイペースですよね。

鈴木

「Shibuya.go」については、そろそろ3回目をやりたいと思っています。実は今、共著でGoの本も書いているんですよ（「みんなのGo言語【現場で使える実践テクニック】」技術評論社刊、9月9日発売！）。

後藤

Goプログラミングの入門書的なものですか。

鈴木

どちらかというと、Goプログラマー向けのTips集のようなものになる予定ですが、もちろん入門的な内容も含まれてきます。僕はその中でテストについて書くことになっています。

VOYAGE GROUPって、全体的にテストを極めて重視する文化があるんですよ。エンジニアが互いに評価し合う仕組みがあって、その結果がある程度、給与などにも影響するのですが、その中でもテストを含めたソフトウェアの品質管理や、長期的な目線でプロダクトを作れているかといったことが評価の重要な基準になってきます。

後藤

分析系のシステムをテストするのは大変そうですね。

鈴木

分析結果や機械学習の結果に対してテストしようとすると、たしかに大変で、それは今後の課題ですね。むしろ、それより手前の段階、つまり分析基盤を成り立たせるために必要なソフトウェアをクリーンに作っていくという意味でのテストは、いわゆるユニットテストや結合テストのような形でしっかりやっていけると思っています。

後藤

あと、suzukenさんは、GoでSchemeインタプリタを実装するようなこともやっておられましたよね。あれは純粋にGoの勉強のためにされたのですか。

鈴木

あれは「SICP（計算機プログラムの構造と解釈）」という本に触発されたところが大きいですね。社内にも、あれを読んでいるエンジニアが結構います。計算機科学の本なので、最初のほうはプログラミング言語の動きに関する話があるものの、徐々にインタプリタやコンパイラを作る話に入っていくんですね。「言語」を作れる人というのは、エンジニアの中でも「魔法使い」のような特別な存在じゃないですか。僕は、自分では作れないものを作れる人を、ものすごく尊敬するし、憧れるんですよ。で、この本を読んで、自分が言語を書けるとしたらどんな感覚になるのかに興味が出てきて、試してみたんです。

後藤

たしかに、普通のアプリケーションを書くのとはまったく別の感覚でしょうね。

鈴木

ソフトウェアエンジニアを続けていきたいと思っている人は、何らかの形で小さな言語や小さなOSを自ら実装するということをやっておいたほうがいいだろうと思います。言語もOSもソフトウェアのひとつの形ですから、その設計から学べることは多いと思うんです。

実は、今、Goを使っているのには、そうした理由もあります。今のGoは、標準ライブラリもすべてGoで書かれているんですけど、それらが非常にクリーンで読みやすいです。その点で、一番「Goらしさ」を持っているのが、Go自体の標準ライブラリだと思います。Goでプログラムを書きつつ、Goという言語そのものから、ソフトウェアについて学ばせてもらっている感覚がありますね。

見つけ出した「課題」をエンジニアリングの力で「解決」することが面白い

後藤

少しずつ、将来のことを伺わせていただきたいと思っています。現在はデータ分析基盤を作っていくというお仕事をされているわけですが、将来的にも、この方向を突き詰めていきたいと考えていらっしゃるんでしょうか。

鈴木

うーん、直近はともかくとして、今のところ、例えば「10年後にこういうことをやっていたい」というような強い思いはないんですよ。これまでも、常にその場で知識とスキルを足し算しながら積み重ねている状況なので、当面はそんな感じで続けていくんじゃないでしょうか。ただ、ベースとして「ソフトウェア」と「インターネット」が好きだという部分は変わらないと思いますので、その領域でものを作ることは続けていきたいと思っています。

後藤

今日はGoやデータ分析基盤に関するお話しを多く伺ったのですが、それ以外に、今後面白そうだと感じている技術分野はありますか。

鈴木

僕は長く職業エンジニアをやっているので、どちらかというと「課題の発見」や「その課題をどう解決するか」に意識が向いていて、あくまでも技術はその手段なんですね。なので、技術領域に興味を絞るのは苦手です。

トリッピースに関わったときも、最初はWebサイト上に細かい機能を追加するようなことをやっていたんですが、次第に「サイトのビジネスとしての成長を見ていくためには、データ分析が必要だ」と思うようになり、Google Analyticsのようなものを自分で作りたいと考えました。

トリッピースは、ユーザーが交流しながら旅行をプランニングし、実際に旅行に行ってかけがえのない体験を共有してもらうことを目指したサイトで、運営側は、そうした交流を促進していくためにどうすればいいかをひたすら考えて作り続けていました。動ける人数が限られた中で、必要な情報を集め、改善点を見出していくために、エンジニアとしてできることは何だろう、と考えていった先にデータ分析という分野があったわけです。

ニーズが先にあって、その解決のために技術を探し求めるという順番なので、むしろ関心のある分野は「業務」や「ビジネス」のほうになりますね。

後藤

トリッピースではCTOという立場で、経営にも関与されていたんですよね。

鈴木

はい。ビジネスの課題や目標に対して、技術面からどう手を打つかについて考える立場でした。会社という組織の行動を決めるのは経営判断ですよね。であれば、そこに属するエンジニアがコードを書くことも経営判断の一部です。企業としてやるべきこと、サイト上で実現すべき機能がたくさんあるものの、どこから着手すべきかは誰も見当が付いていない中、それを考えながらものを作っていくのは、とても面白い経験でした。

後藤

問題解決のためのソフトウェア作りが興味の中心にあるわけですね。将来的には、また経営を行う立場になりたいという考えがあるのでしょうか。

鈴木

実はfluctでも、一時マネージャーをやったのですが、1年くらいやってみて降りたんですよ。マネジメントに興味がないわけではないのですが、仕事への割り込みの増加にうまく対処できなくて。そうした現状で、限られた時間をできるだけ有効に使ってより多くのアウトプットを得ようと考えると、現時点ではいちエンジニアとして働いた方がよいと判断しました。

ただ、企業がソフトウェアを作っていくにあたっては、エンジニアにも経営的な視点が必要になるフェーズが絶対にあるというのが僕の考えです。fluctでは、明確にパートナーや競合が存在する中で、競争に勝つための機能を作っていくことが求められます。その中で、例えば自社の複数のサービスで共通して使える汎用的な機能を優先して作れば、そこから得られる経営上の効果は「かけ算」で大きくなります。

その機能が何なのか、どれを優先すればいいのかといった明確な指示は、トップダウンでは出てきません。現場ベースで考えを取りまとめ、必要性を説明し、段取りを決めて実装する。そういう開発の進め方がとても重要だと思いますし、僕としてはそれを実践しているつもりです。

後藤

一度CTOの立場で仕事に向き合われた経験からだと思いますが、ソフトウェア開発を非常に広い視野で捉えていらっしゃると感じます。

鈴木

どんな企業であっても「必要なことを全部知っている人」というのは、いないと思うんですよ。競合の状況に詳しい人でも、社内のことは案外知らなかったりする。システムのことを良く知っているエンジニアも、常に外に出ている営業さんのニーズは分かっていなかったりする。そうした断片を拾い集めて、その中から「何が重要か」を見つけ出せる人というのは、絶対に必要です。だれも正解を分かっていない中で、それを考えだす作業も「仕事」の一つだと思うんです。

次回のゲストは「サッカー好き」で「バランス感覚が良い」インフラエンジニア

後藤

お話しを伺って、伊藤さんが、鈴木さんのことを「不思議な人」と評された理由が分かる気がしました。コードも書くし、インフラも触るし、コミュニティ活動にも携わるし、経営的な感覚も持っている。本来、エンジニアが1人で持つのは大変な、複数の視点を持っていて、そのすべての立場で積極的に活動しておられるのが「不思議」で「ニュートラル」な雰囲気の根底にあるような気がします。

鈴木

もうちょっと「ギーク感」を出した方が良かったですかね。（笑）

後藤

GoでSchemeインタプリタを実装するというのは、十分にギークがやることだと思いますよ（笑）。ただ、活動の総量が多いせいで、「ギーク」な印象が薄まって感じられるのかもしれないですね。

では、最後に次回のインタビュー相手をご紹介いただけますでしょうか。

鈴木

若手Webエンジニア交流会などでもつながりのある、坂本卓巳（@takus）さんを指名させてください。現在は「スマートニュース」のエンジニアです。

後藤

鈴木さんから見て、坂本さんはどんな印象の方ですか。

鈴木

僕と同年代の社会人で、サッカーがすごく好きです。あと、彼も「ギーク感」がないと思います。（笑）

普段は温厚だけれど、システムのアーキテクチャなどを作るときには、非常にカッチリと、ソリッドに考えをまとめる印象がありますね。仕事も早いです。あと、ベースはインフラエンジニアですが、サービス寄りの考え方もできる、バランス感覚の良い人というイメージがあります。

後藤

特に聞いてみたいテーマはありますか。

鈴木

えーと…「スマートニュース、面白い？」とかどうでしょう。

後藤

わかりました。ぜひ聞いてみたいと思います（笑）。本日はどうもありがとうございました。

執筆：高橋美津

ここで運営からの宣伝です！

今回の鈴木さんへのインタビューをきっかけに、VOYAGE GROUP と Forkwell で合同イベントを開催することになりました！

テーマは「日本最大級のアドプラットフォームを支える技術とチームとは」

• 技術スタックとしてどういうものを基盤としてつかっているか
• fluct, DR, zgok, GSM, M0mentum全部いれて、横断的にどういう姿勢でやってるか
• 現場ではどんなエンジニアが求められていて、評価されているか

詳細は下記のリンクをご覧ください！

http://forkwell.connpass.com/