※本記事は、2018年12月に公開された内容です。

2018年10月30日、Go言語の発展と推進を目的に、Goファンを対象として開催された「golang fan meetup」。Go言語の有識者を招き、パネルディスカッションを行いました。
Goを選定したきっかけに始まり、どのようにGoを組織に浸透させていったのか、Goの好きなところ、さらにはGoの未来まで、Goファンが気になる話題が目白押し。充実のイベント内容をレポートいたします。

＜パネラー＞

• 金子 慎太郎 氏
  株式会社エウレカ 取締役CTO
• 上田 拓也 氏
  株式会社メルカリ/メルペイ
• 松木 雅幸 氏
  株式会社はてな　チーフエンジニア兼Mackerelプロダクトマネージャー

＜ファシリテーター＞

• 大谷 祐司 氏
  株式会社サーキュレーション CTO

登壇者のご紹介

現在、各企業がおかれているGo言語活用のフェーズとは？

大谷：
福岡を拠点にサーキュレーションのCTOを務めている大谷と申します。本日はファシリテーターをさせていただきますので、どうぞよろしくお願いします。さっそくですが、登壇者の方は順に自己紹介をお願いします。

金子：
株式会社エウレカのCTO金子です。エウレカにはWebエンジニアとして入社し、iOSやAndroidアプリ、インフラ系に携わってきました。その後、デーティングサービスのPairsをPHPからGo言語へ書き直すことになり、実際にGo言語をプロダクション環境で使用した経験があります。

CTOとして事業戦略に関わる技術戦略の策定やエンジニア組織のマネジメント業務が主ではありますが、コーポレート部門のプロセスについてGoを活用して改善に取り組んでいる状況です。

Pairs自体はデーティングサービスで、実はかなり複雑なシステムです。ECサービスはヒトとモノのマッチングサービスですが、デーティングサービスはヒトとヒトとをマッチングさせるサービスで更新性が高く、技術的な挑戦があります。現在は日本と台湾、そして韓国に展開しています。ユーザーは全世界に800万人。先程触れた通り、2014年末にPHPからGoにフルスクラッチしました。決済システムや投稿監視システムはマイクロサービスとしてすべてGoで書かれています。複雑性の高いサービスに対して、Goのシンプルさがチーム開発やコードの読みやすさ、書きやすさに貢献してくれています。

上田：
株式会社メルカリの上田です。私はGoのコミュニティやGoビギナーズ、あとはGoogle Cloud PlatformのユーザーグループのGCPUGのスタッフもやっています。

メルペイのエキスパートチームに所属していて、稼働の50％以上を技術コミュニティへの貢献にあてています。活動内容としては、イベントへの登壇やカンファレンスへの参加ですね。あとはGopher道場というGoの初学者を集めた社外向けのイベントも主催していて、講義を行っています。

松木：
株式会社はてなの松木と申します。僕はアプリケーション側のチーフエンジニアということで、主に採用や技術ブランディングに関わっています。事業としてはMackerelというサーバー監視サービスのプロダクトマネージャーとしてプロダクトの仕様や方向性を決めたり、技術選定や技術戦略も行っていますね。Mackerelの中ではScalaやGoを活用しています。

個人的な活動としてはGoでいろんなツールを製作したり、『みんなのGo言語』という書籍の執筆にも関わるなどしました。あとはインフラ領域を含めたアプリケーション開発を得意としているので、ISUCONで何度か優勝した経験もあります。今日はGoに興味を持っている方、そして実際に使っている方がいらっしゃっているので、良いお話ができればと思います。よろしくお願いします。

大谷：
ありがとうございます。では早速、パネルディスカッションを開始したいと思います。

Goを選定した基準と導入の経緯

新たな技術的チャレンジングとして選ばれるGo言語

大谷：
今回のイベントの大テーマは「あなたの会社のGo言語」となっています。みなさんも各社でGo言語を使われていると思いますが、まずはどういった経緯でGo言語を選定するに至ったのかお聞かせいただければと思います。金子さん、いかがでしょうか。

金子：
エウレカがGo言語を使い始めたのは、先程も少しご説明した通り2014年末からです。PHPからGo言語に移行したわけですが、そもそものきっかけはデータベースのスキーマを書き換えるとコードベースがほぼ使えなくなってしまうので、それならフルスクラッチをしてコードベースも改善したほうが良いだろうという判断です。

PHPのナレッジが社内には蓄積されてたので、そのままPHPを使うか、あるいはRubyにするか、Scalaか、Goかという選択肢がありました。その中でチーム開発の観点からシンプルさやビルドの速さ、処理の速さを踏まえてGoを選択しました。

上田：
メルカリのサービス自体はPHPで書かれているのですが、最近はマイクロサービスに移行するにあたってGoを中心に採用していっています。

松木：
はてなの場合、あまり言語の統一はしていません。いろんな言語を使っていこうという方向にシフトしている最中です。その中でGoも使っていこう、という流れになっていますね。Goの採用にあたって他社さんと異なるのは、インフラ系のエンジニアから「Goっていいよね」という話題が盛り上がってきた部分です。DockerやConsulなど、筋の良いツールがみんなGoで書かれていたため、2013年頃からGoを評価する動きがはじまったのです。その中で社内のオペレーティングツールを作る際にGoが活用されてきた、という経緯があります。Perl、Python、Rubyなどのスクリプト言語と比べると、Goならサーバーにバイナリを置いてしまえば動作するという利点があり、徐々にGoの活用が浸透していきましたね。

Mackerelにおいてはmackerel-agentと呼ばれるユーザーさんのサーバーにインストールしてもらうプログラムをGoで書いたのですが、パフォーマンスが良くメモリーも食わず、とてもマッチする要件だったという実績もあります。そういった諸々の背景があり、現在はマイクロサービスの部分でもGoの活用が進んでいます。

Goへの切り替えはスムーズにできたか？

社内でGo言語をしっかり活用するため、丁寧な指導からスタートしていく

大谷：
各社、それぞれのサービス状況や新技術への挑戦として、もともと別の言語で製作を進めていたところからGo言語への切り替えを行っていることがわかりましたが、切り替えそのものはスムーズに進んだのでしょうか？

金子：
当時、弊社はインターンを経て入社した人が多く、静的型付け言語にそこまで経験がない人が多かったです。そのため、知見を社内で蓄積するのは苦労しました。毎週勉強会を開催し、初歩的な部分からPHPやC言語との違いを丁寧に教えていきました。

上田：
メルカリはPHPからGoへの移行している部分がありますが、メルカリでPHPをやっていた人も社内勉強会や実務を通じてGoを勉強していってます。PHPも書くしGoも書く、という人が増えている感じですね。

金子：
フルスクラッチを決めてから書き始めて少し経ってから、変更点がビルドできなくなっていたりと、困った話もありました。フルスクラッチ当初は複数のリポジトリで開発を進めていたため、発生した問題でした。

大谷：
なるほど。松木さんはどのように切り替えていったのでしょう？

松木：
はてなだと、Perlで書かれているはてなブックマークのコア部分をScalaに置き換えていくプロジェクトが現在走っているのですが、Go言語での大きな書き換えは実はあまりやったことがありません。書き換えというよりは、サービスの隙間を埋めるようなツールや新しい仕組みを作る際にGoを使ってみたいという現場の声があり、それに僕やCTOなど知見のあるメンバーが応えることで、「Goは使えるぞ」という空気を社内に醸成していった部分が大きいです。

Go言語をどのように組織に浸透させているのか

会社としてGoを盛り上げていく気持ちで、勉強会やイベントを積極的に実施

大谷：
みなさんなかなかご苦労されている状況ですね。そんなGo言語のエンジニアが少ない状況で、開発組織にどのようにGoを浸透させていったのでしょうか？

金子：
Goに限らずの話ではあるのですが、会社としてエンジニアリング組織を盛り上げるための勉強会は大切なので、iOSやAndroid、Webフロント、サーバーサイド、インフラ、デザインチームそれぞれで勉強会を開いています。Go言語に関しては先程もご説明したようにエンジニアチームで勉強会を行って僕が教えていますが、インターン入社の社員以外にもまだまだミドルレベル、新卒1年目レベルの社員もいるので、そういう人たちが最初の段階で躓かないように、僕が直接教えて勉強会でサポートしている形ですね。

それから、今回のようなイベントもそうですが、会社としてGoのコミュニテイに参加することもかなり重要だと思っています。個人ではなく会社としてGoを盛り上げていきたいので、こういった機会があれば積極的に参加したいです。

上田：
うちもさっき言ったような、週に1回の勉強会を100回以上開催していますが、なるべく止めないように、どんな小さなことでも共有して必ず開催する、というスタンスで続けています。

あとは私が社外向けに行っているGoの講義を社内向けにも開催したり、PHPやWeb、QAエンジニアに向けても講義しています。

松木：
うちはエウレカさんやメルカリさんと違って、あまり戦略的に浸透を狙ってはいません。個人の草の根活動で頑張っているところが大きいですね。イベントがあれば参加や登壇を後押しすることは頻繁にありますし、社内のslackやwikiに定期的に「こんなの作ったよ」とツールをあげています。本当は自社でイベントも開催できればと思っているのですが、なかなか手が回っていない状況です。

活用のノウハウ・工夫しているポイント

Go言語で活用できるポイントを指摘し合い、疑問点を議論する風土を作る

大谷：
勉強会の開催や丁寧な指導によってエンジニアを育てていくのがGo言語を浸透させるポイントですね。その他に、社内でGo言語を活用する上でのノウハウや、工夫しているポイントを教えていただけますでしょうか。

金子：
当たり前ですが、社内で「よりGo言語の利用を盛んにしていくこと」ですね。例えば、時々Pairsのプロダクションコードをレビューして、「Goではこういう風に記述するといいよ」といった話を懇切丁寧にします。そのときに「標準パッケージはこういうふうに書いてあるよ」などの参考事例とともに説明するのがポイントです。自分の考えではなく、どちらかというとGo言語の設計思想を伝えることを重視しています。

思想を伝えるという視点で言うと、Goはシンプルであることが大事なので、下手に手厚い機能を増やしてほしくないと考えています。それがなぜなのかを踏まえてレビューを書いたりすることもあります。

上田：
うちも金子さんがおっしゃった例と似ていますね。社内にGoに関する話題を話すSlackのチャンネルがあるのですが、最近は「テスティングフレームワークを使うかどうか」といった話題を議論したりしています。例えばGoはテスティングフレームワークを使わず、標準のtestingパッケージを使うことが多いですが、テスティングフレームワークを使うことの利点や問題点などを議論しています。他にも「スライスの要素はポインタにすべきか」など、誰かが議題をチャンネルに上げたらみんながそれに自分の考えを述べて議論していくといった流れが、私が入社した2016年頃から盛んに行われています。

松木：
僕はもうGitHubに「こういうの作ってみたけどどうかな」と上げてしまうことが一つの手かなと思っています。GoはGitHub等にパッケージを置くことを前提としている言語でもあるので、ある程度パッケージを切ってGitHub上にアップした方が議論や再利用もしやすいですし、「ここの部分はライブラリにできそう」という点があれば切り出してしまうこともありますね。

あと、Goの場合はきちんと使用上の決まりを作るのは大事ですね。mackerel-agentの場合はプラグイン機構があるのですが、「プラグインを書く際はこのインターフェースを実装してください」「このライブラリを使ってこういうふうに呼び出してください」といったことを決めています。使う人の規約を意識すると、上手くまわるのかなと思います。

金子：
スクリプト言語など、違う言語から入ってきた人は一つのパッケージにいろいろな責務を持たせているので、機能が多くなりすぎて「この人はこの機能を使って、別の人が違う機能を使って…」という状況になりがちです。しかし、その機能の違いや優位性は別のパッケージで実現できるんじゃないのか？という疑問が正直あります。本当に必要な責務だけをパッケージとして持たせて使っていってほしいです。

Go言語の未来について

現在のGoの立ち位置を踏まえた、慎重な機能拡張が望まれる

大谷：
ここからは非常に大きなテーマですが、Go言語の未来について「プロジェクトの活用」そして「Go2.0に向けて」という２つの視点からディスカッションしていきたいと思います。

金子：
プロジェクトの活用という観点だと、現状維持をしてほしいという思いが正直あります。Too muchに機能を追加されると開発サイドが困ってしまいますし、せっかくのGoのシンプルさが失われてしまいます。もちろんきちんとした良い機能であれば盛り込むべきではあるのですが、制限する術も用意してほしいですね。

エウレカもそうですが、さまざまな企業にGoが使われている中で、これから初めてGoに触れるという方も増えてくると思うので、正直ハードルが高いなと思うような機能は提供してほしくありません。

上田：
金子さんの言う通りそれなりの数の企業が現在Goを使っていますから、今後予想できるのはGoを活用できるエンジニアが足りなくなる未来です。それは弊社も危機感を持っているからこそ社外向けの勉強会を行っていますし、大学でも講義したりしているわけです。

それを踏まえて、エンジニアが最初に触れる言語としてGoが選ばれる未来が来るといいなと思っています。現在大学で最初に学ぶ言語はCやJavaですが、そこにGoが関わるには、大学の研究で使ってもらうなど大学で活用してもらわなければいけません。そのために、例えばPythonでやっているようなマシンラーニングの領域など、ある程度Goが得意なところは置き換えてもらうなどの方法が考えられます。Goを必須言語にするのはなかなか難しいとは思いますが、Goの得意分野が大学で活用されるといいなと思いますね。

Go2に向けては、先日行われた勉強会でで話す機会がありました。Go2で議論されている新しい機能は、もちろん使い勝手のよい魅力的なものでなければならないのですが、それを言語に加えることによってます複雑さをどうするのか、果たしてその機能に見合う複雑さなのか、という点をディスカッションしましたね。

金子：
エラーハンドリングの話でいくと、誰かしらが現状の「if err !=nil」を置き換えるツールを用意してくれるのではと少し思っていますが、あまりやってほしくないですね。かといってGoの標準に用意してほしいわけでもありません。オートメーションツールはあるとうれしいけれど、それをむやみに使われるとちょっと困る側面もあるんです。Goをプロダクションで使っている観点からすると、「なぜGoが生まれたのか」という思想背景をしっかり理解してほしいので、オートメーションツールの便利さを鵜呑みにして使ってほしくないなと思いますね。

松木：
Goはマクロが無いのが良いところなので、逆にそこを自動生成ツールで頑張りすぎるのは僕も良くないと思いますし、節度は持ってほしいですね。また、Goの良さは、現実の問題に直面している企業(=Google)がその解決のために作ったという点でもあるので、引き続きその立ち位置を保ち続けてもらいたいです。

Go2.0に向けて、Goの開発チームは基本的に言語機能をシームレスにエンハンスしていくという姿勢を目指していると思います。例えば、Perl6はもともとはPerl5の後継だったのですが、現在は違う言語としてメンテナンスするという決定をしましたし、Pythonも2と3で大きな修正が入ったので、みんながんばって移行をしなくてはならない状況が起きています。Goがそういったこれまで他の言語がうまくいかなかった点も踏まえつつ、どんな解決をもたらしてくれるのか、というのは楽しみにしている点です。

あとはGoの対抗馬がどう出てくるのかという部分も気になりますね。いろいろな良い言語はあると思うのですが、それぞれがそれぞれのドメインの問題を解決するために生まれてきていています。RustはMozillaが新しいブラウザを作るために作った言語ですし、Swiftはアプリを作るために表現力の高い言語を作ったという背景があります。Webの分散システムを作る上で適した言語という意味でGoはユニークなポジションではあると思いますが、似たような対抗馬となる言語が出てくると、Goに刺激を与えることができて面白くなるのではないかと思います。

Goのここが好き、ここが課題

何よりもシンプルであることが魅力。一方でとっつきにくさの緩和は必要

大谷：
Goの未来を通じて魅力や課題も見えてきた気がしますが、改めてGoのここが好き、またここが課題、というテーマでお話しいただければと思います。

金子：
やはりGoogleがインフラ組織に対して感じていた課題解決のために作られた言語であるというところが好きですね。それこそSwiftにはコーディングの表現力を豊かにして課題解決をすることができますが、Goは表現力を制限した上ではあっても、インフラレイヤーを低コストかつシンプルに開発できるというのが魅力です。

課題らしい課題は、書いていて楽しい部分が大きいのであまりありません。C言語をやっている観点からすると、数値解析をするにあたって、もう少し機械学習ライブラリを拡充してもらえるといいですね。それこそ大学生たちが最初に学ぶ言語にGoを選びやすくなるのかなと思います。

上田：
Goがシンプルだから好きだというのは、Goに触れている人にとっては共通の認識ですよね。2014年のGo Conferenceにロブ・パイク氏が来日した際に言っていたのが、Goを構成する要素が直交するような形で作られているという話です。シンプルに設計されていて、シンプルを維持するのはどういうことだろうかと考えると、Goの言語仕様はかなり面白い。どこをシンプルにするために何を削ったのか、Goの定数を見ていてもすごいと思う。そういった考え抜かれたシンプルさが好きな部分ですね。

課題はプログラミング初学者にたいする敷居の高さですかね。現在Goが広く使われている状況を見ると、基本から始められるようなチュートリアルの仕組みがあってもいいのではと思いますね。現在のチュートリアルは基本的にすでに他の言語をやってきた人向けなので。

松木：
僕が一番好きなのは、Webアプリケーションエンジニアのスキルセットや可能性が広がる言語だというところです。具体的には、ミドルウェアを書くという発想に至ることができる点ですね。そのためのツールも揃っています。

普段Webアプリケーションを作っていると、普通はリクエストを受けてデータベースにいってすぐさまレスポンスを返すという発想になりがちなのですが、Goはマイクロサービスを別で立てておいてそこで何か継続的な処理をさせる、といった、ちょっとした常駐デーモンがすごく書きやすい。そこが気に入っているポイントです。

課題として言語仕様に気になる部分がゼロではないですが、ほぼ無いと思っています。エラーも今のままでいいと思いますし、ジェネリクスも変な形で入ってほしくはないなと思います。nilableな値の扱いに感して言語機能なりベストプラクティスが欲しいというくらいでしょうか。あとは確かにとっつきづらさはあると思うので、これはコミュニティ内で努力して解消するところなのかもしれません。

採用基準、どうしてますか？

Go言語の習得よりも、大切なのは基礎知識と「一緒に働きたいかどうか」

大谷：
今回会場にはGoを扱っているエンジニアサイドの方が多く集まっていますが、各社ではどういう基準でGoのエンジニアを採用されているのか。あるいは、どうやってGoで開発するチームにつなげているのかをお伺いできればと思います。

金子：
Goをやっている人を採用したいという気持ちは本心としてありますが、現実問題としてとっつきにくさのハードルがあり、大体の人は「少し触ったことがあります」というレベルです。ですからGo言語自体を必須スキルとしては設定していません。それよりもWebの経験があるかどうか、その中でPHPやRailsなどの知見を積んできているかどうか、という点を採用基準にしています。

どういうことかと言うと、PHPのMVCがわかりやすいですね。MVCがあったときにファットコントローラが問題として挙げられることがよくありますが、採用時に「ファットコントローラになってしまったコードをあなたならどのように解消しますか？」と問いを投げます。回答によってどこまで知識をもっているかなど、いままでの経験を元にした設計を考えているのかがわかりますし、問題解決するための設計の発想は人それぞれですから、その部分を深く回答してくれる人はポジティブに検討します。

上田：
私個人としては、一緒に働くということがイメージできるということが大事なのではないかなと思っています。

松木：
はてなの場合はポリグロット志向でサービスの種類も多いので、この技術を習得していないと採用しない、ということはありません。HTTPプロトコルを理解しているかどうかなど基礎的な部分は問いますが、特定の言語分野に関する経験は全く問いませんね。現在社内で使う言語としてはGoやScalaやPerlが多いのですが、むしろ別の言語から来てもらいたい気持ちもあります。きちんとした技術力がある方であれば、入社までにこういう本を読んでおくといいですよとか、こういう資料を見ておいてくださいと伝えて、入社後もOJTで教えていけばしっかりこなしてくれますから。

あとはもちろん、僕たちがその人と働きたいと思えるか、その人も僕たちと働きたいと思ってもらえるかどうかを一番大事にしています。会社のミッションや僕が担当するMackerelのミッションに共感してもらえるか、面白いと感じてもらえるかが重要です。

エコシステムは今後どうなっていくのか

静的解析の拡充やコミュニティの多様化が焦点

大谷：
では最後にエコシステムについて。みなさんの視点から、今後どうなっていくのかをざっくりお伺いできればと思います。

金子：
個人的に使っているのがGo cycloという循環複雑度を測ってくれる静的解析パッケージなのですが、僕の場合何かしらMakefileでコマンドを連ねてからプッシュしているので、静的解析の部分をもっとGoのエコシステムとして拡充してくれるとうれしいですね。

上田：
静的解析の話でいくと、これまではパースから静的解析をするlint的な機能を1から10まで自分で書く必要があったのですが、最近はそれをモジュール化できるような仕組みが作られています。例えば静的解析のうちコントロールフローグラフを作るところまではこのモジュールがやってくれて、その結果をこのモジュールで検証するとか、モジュール化したものを組み合わせて作るといったものです。この仕組みが広まることで静的解析のエコシステムはもう少し良くなるのかなと思います。

松木：
別の話になりますが、コミュニティにもう少し多様性が出てきてもいいのかなとは思います。使い方について、僕自身も標準パッケージ原理主義のような部分はありますが、「実はこういう使い方をするともっといい」という主張を持つ対抗勢力が出てくると面白いですね。

Google-ismが強いのは良いところでもあるのですが、僕が一番困っているのは、モノレポジトリ問題です。いくつかのプロジェクトがあるときに、結局１つのリポジトリにした方が良いな、という気持ちになってくる。ただそれはGoogleがそういう運用をしているからそういう気持ちになるだけで、Gitを使っている我々からしてみるとそれでいいのかな？、とも思います。そこは良い感じの折衷案があればという気持ちが強いですね。

具体的に困っている点は、例えばGoのバージョンが上がった際にマイクロサービスをすべてビルドし直さなければならなくなるとかなり面倒なのですが、そういう状況が発生したときの解決方法を探っているところです。

質疑応答

Goはこれから先も学び続ける価値のある言語か？

質問者：
Go言語に触れて1年目です。Goは書きやすく個人的な相性も良いので続けていきたいのですが、この先の流行り廃りで劣勢になることはありそうでしょうか。あるとすれば、どんな点が弱点になりますか？

金子：
言語にはそれぞれ設計思想があり、Goの場合は「シンプルさの追求」ですから、重箱の隅をつつけば劣勢になる要素はいくらでもあります。ただ、単純に流行りに乗って手を出していくよりは、設計思想を理解して自分の中で芯を持って学んでいくことが大切だと思います。自分が信じたことを突き詰めて、Goを学ぶのであれば絶対にGoに深くコミットしていく、という気持ちでやってほしいです。

上田：
Go自体は非常に安定した言語なので、今学んだことがすぐに使えなくなるということは無いと思います。今日はGo2の話が出ましたが、1.xはまだまだこの先も生き残りますし、いろいろな企業がGoを使用している現状を見ると、速攻で消えて無駄になってしまう、ということは無いでしょう。

松木：
僕も、Goはそれなりに投資対効果の高い言語だと思います。自分の知識や技術の幅を広げていくには適しています。ただ、もちろん今知られている大体の技術は最終的に死んでしまいますから、そこはもう次、次、と乗り換えていく気持ちでやり続けることが大切です。しかし、なんであれ１つの言語に対する基本的な知識をきちんと深めた経験というのは、必ず今後のキャリアに生きていきます。

金子：
当たり障りなくいろいろな技術に触れていると、「結局、何がスキルとして身についたんだっけ？」という結果になりかねません。きちんと１つの言語を突き詰めて学ぶと、言語の話だけではなく、コンピュータサイエンスやデザインパターン、設計思想といったレベルにまできちんと習熟できますし、今後はそういったスキルを持った人が活躍できると思います。

大谷：
以上でディスカッションを終了したいと思います。本日はみなさんありがとうございました！

Coming up Event

2018年12月のCTO meet up

イベント告知12/4開催【CTO meetup】データドリブン×オープンイノベーション

ご登壇者

• 星川 隼一 氏
  THECOO株式会社 執行役員 Product Manager
• 高橋 道幸 氏
  株式会社Hacobu　執行役員
• 生内 洋平 氏 【モデレーター】
  株式会社マクアケ 執行役員 CTO
• 竹馬 力 氏
  株式会社リブセンス 不動産ユニット IESHILディベロップメントグループリーダー
• 本間 美香 氏
  弊社flexyご登録専門家

詳細ページを見る

イベント告知12/14開催【CTO meet up】CTOに求められる能力と限界

ご登壇者

• 岸田 崇志 氏
  株式会社 LITALICO /執行役員CTO
• 袖山 剛 氏
  BizteX株式会社 /取締役CTO
• 藤倉 成太 氏 【ファシリテーター】
  Sansan株式会社 /CTO
• 中筋 丈人 氏
  株式会社FABRIC TOKYO /執行役員CTO

イベント告知12/18開催「Container X mas Party」

※本イベントはMicrosoft社主催のイベントになります。 ※flexyにて本イベントのスポンサー及び、懇親会コンテンツの提供をさせていただいております。 詳細ページを見る

LINEでフリーランスの案件情報や最新Tipsを受け取る