Come On!! Go Fan!!(後編)~Go言語の未来はどうなる?「シンプルさ」という魅力を輝かせ続けるために~

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

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

<ファシリテーター>
●株式会社サーキュレーション CTO 大谷 祐司 氏

Go言語の未来について

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

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

金子:プロジェクトの活用という観点だと、現状維持をしてほしいという思いが正直あります。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の未来を通じて魅力や課題も見えてきた気がしますが、改めてGoのここが好き、またここが課題、というテーマでお話しいただければと思います。

金子:やはりGoogleがインフラ組織に対して感じていた課題解決のために作られた言語であるというところが好きですね。それこそSwiftにはコーディングの表現力を豊かにして課題解決をすることができますが、Goは表現力を制限した上ではあっても、インフラレイヤーを低コストかつシンプルに開発できるというのが魅力です。
課題らしい課題は、書いていて楽しい部分が大きいのであまりありません。C言語をやっている観点からすると、数値解析をするにあたって、もう少し機械学習ライブラリを拡充してもらえるといいですね。それこそ大学生たちが最初に学ぶ言語にGoを選びやすくなるのかなと思います。

上田:Goがシンプルだから好きだというのは、Goに触れている人にとっては共通の認識ですよね。2014年のGo Conferenceにロブ・パイク氏が来日した際に言っていたのが、Goを構成する要素が直交するような形で作られているという話です。シンプルに設計されていて、シンプルを維持するのはどういうことだろうかと考えると、Goの言語仕様はかなり面白い。どこをシンプルにするために何を削ったのか、Goの定数を見ていてもすごいと思う。そういった考え抜かれたシンプルさが好きな部分ですね。
課題はプログラミング初学者にたいする敷居の高さですかね。現在Goが広く使われている状況を見ると、基本から始められるようなチュートリアルの仕組みがあってもいいのではと思いますね。現在のチュートリアルは基本的にすでに他の言語をやってきた人向けなので。

松木:僕が一番好きなのは、Webアプリケーションエンジニアのスキルセットや可能性が広がる言語だというところです。具体的には、ミドルウェアを書くという発想に至ることができる点ですね。そのためのツールも揃っています。
普段Webアプリケーションを作っていると、普通はリクエストを受けてデータベースにいってすぐさまレスポンスを返すという発想になりがちなのですが、Goはマイクロサービスを別で立てておいてそこで何か継続的な処理をさせる、といった、ちょっとした常駐デーモンがすごく書きやすい。そこが気に入っているポイントです。 課題として言語仕様に気になる部分がゼロではないですが、ほぼ無いと思っています。エラーも今のままでいいと思いますし、ジェネリクスも変な形で入ってほしくはないなと思います。nilableな値の扱いに感して言語機能なりベストプラクティスが欲しいというくらいでしょうか。あとは確かにとっつきづらさはあると思うので、これはコミュニティ内で努力して解消するところなのかもしれません。

goevent

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

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

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

金子:Goをやっている人を採用したいという気持ちは本心としてありますが、現実問題としてとっつきにくさのハードルがあり、大体の人は「少し触ったことがあります」というレベルです。ですからGo言語自体を必須スキルとしては設定していません。それよりもWebの経験があるかどうか、その中でPHPやRailsなどの知見を積んできているかどうか、という点を採用基準にしています。
どういうことかと言うと、PHPのMVCがわかりやすいですね。MVCがあったときにファットコントローラが問題として挙げられることがよくありますが、採用時に「ファットコントローラになってしまったコードをあなたならどのように解消しますか?」と問いを投げます。回答によってどこまで知識をもっているかなど、いままでの経験を元にした設計を考えているのかがわかりますし、問題解決するための設計の発想は人それぞれですから、その部分を深く回答してくれる人はポジティブに検討します。

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

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

event

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

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

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

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

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

松木:別の話になりますが、コミュニティにもう少し多様性が出てきてもいいのかなとは思います。使い方について、僕自身も標準パッケージ原理主義のような部分はありますが、「実はこういう使い方をするともっといい」という主張を持つ対抗勢力が出てくると面白いですね。
Google-ismが強いのは良いところでもあるのですが、僕が一番困っているのは、モノレポジトリ問題です。いくつかのプロジェクトがあるときに、結局1つのリポジトリにした方が良いな、という気持ちになってくる。ただそれはGoogleがそういう運用をしているからそういう気持ちになるだけで、Gitを使っている我々からしてみるとそれでいいのかな?、とも思います。そこは良い感じの折衷案があればという気持ちが強いですね。
具体的に困っている点は、例えばGoのバージョンが上がった際にマイクロサービスをすべてビルドし直さなければならなくなるとかなり面倒なのですが、そういう状況が発生したときの解決方法を探っているところです。

質疑応答

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

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

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

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

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

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

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

goevent イベント The Go gopher was designed by Renée French.
GO fan meet up限定のじゃがりこもご用意しました!

Coming up Event

2018年12月のCTO meet up

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

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

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

12月開催イベント
ご登壇者
●株式会社 LITALICO /執行役員CTO 岸田 崇志 氏
●BizteX株式会社 /取締役CTO 袖山 剛 氏
●Sansan株式会社 /CTO 藤倉 成太 氏 【ファシリテーター】
●株式会社FABRIC TOKYO /執行役員CTO 中筋 丈人 氏
詳細ページを見る

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

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


この記事を書いた人
flexy編集部
flexy編集部
ハイスキルIT人材への案件紹介サービス
サーキュレーションが運営するフリーランスのエンジニアを中心としたIT人材の案件紹介サービスflexy。エンジニアに役立つコンテンツも提供しています。【flexyのサービス詳細】★求人を募集している法人様向けお仕事をしたいご登録希望の個人様向け

週1日~/リモートの案件に興味はありませんか?

週1日~/リモートの関わり方で、「開発案件」や「企業のIT化や設計のアドバザリーなどの技術顧問案件」を受けてみませんか?副業をしたい、独立して個人で仕事を受けたエンジニア・デザイナー・PM・技術顧問の皆様のお仕事探し支援サービスがあります。

flexyでご案内できる業務委託案件

React

テーマ クラウド入居者管理システムのフロントエンド開発(リモート可)
勤務日数 2-3日/週
報酬 4万円/日
必要スキル React
勤務地 東京
リモート

外部CTO、技術顧問

テーマ 技術アドバイザリーとして知見と経験を生かす
勤務日数 1日/週
報酬 10万円/日
必要スキル エンジニア組織立ち上げや統括のご経験、コードレビュー経験、技術的なアドバイスが出来る方
勤務地 東京
リモート 相談可

Go

テーマ 家族型ロボットのサーバサイド開発
勤務日数 3-4日/週
報酬 5万円/日
必要スキル Go GCP
勤務地 東京
リモート 相談可

AI

テーマ AIを活用した新規事業立ち上げの技術顧問
勤務日数 週1日〜
報酬 5万/日
必要スキル Python、AIの知見、新規事業立ち上げの経験
勤務地 東京
リモート リモートと常駐のMIX

PMポジション

テーマ 複数のプロダクトごとにPMを必要としているため急募
勤務日数 2-3日/週
報酬 5万円/日
必要スキル PMとしての経験、PHP、JavaScript
勤務地 東京
リモート リモートと常駐のMIX
個人登録

お仕事をお探しの方(無料登録)
法人の方(IT課題の相談)