自己紹介
真野隼記氏：「Goを使ってみてホントのところ」を、フューチャーの真野が発表したいと思います。私は社会人歴が10年くらいで、Goは5年くらい使っています。おまけですが、「フューチャー技術ブログ」という会社のブログも運営していて、自分でもいくつかGo関連の記事を寄稿したりしています。
golang.tokyoですが、実は2回前に行われた29回目にも出ています。その時は、今日とはぜんぜん違う、工場を制御するPLC（Programmable Logic Controller）ネタで登壇しました。今日は1年半ぶりくらいの登壇で、ちょっと懐かしい気持ちで出ています。
最初に会社の説明をさせてください。フューチャーですが、受託の会社で、2人のエンジニアが作ったITコンサルです。コンサルの戦略的なところからSIの実装までを全部やるのがポイントで、中立のポジションです。
会社のポリシーをフィロソフィのようなかたちでいろいろ書きましたが、「ないものはつくる」といったところは、僕も好きだなと思っています。
（スライドを示して）ITコンサルが何をしているのかというところで、最近のフューチャーの活動を簡単にプレスから引っ張ってきました。一番上は、新聞社の基幹システムを作った話で、2つ目はAI系のサービスを作ったこと。
3つ目は従業員の勤務地と業務の最適化で、私は内部はぜんぜん知らないのですが、ナーススケジューリングといった最適化的なエンジンも作っていると思います。下は地銀向けの次世代バンキングシステムです。金融系、フィンテック的なサービスを作っていて、いろいろ開発までやっている会社です。
登壇者の私と渋川が所属している、TIG（Technology Innovation Group）という技術組織があります。AIやIoTなどさまざまなことをやっているので、興味がある方がいれば最後にお声掛けいただければと思います。
（スライドを示して）Goネタでいくと、2021年7月26日から、ちょっと尖ったテーマとは思うのですが、GoのO/Rマッパーという、DBアクセス周りのテーマでブログ連載を開催しています。気になる方はぜひ見てもらえるとすごく嬉しいです。
私も1日目に登壇して、「go-rel」というちょっとマイナーなライブラリ（のテーマ）で投稿しました。微妙にはてブでホットエントリーに入って、すごく嬉しいです。喜んでいます。
フューチャーですが、最近技術ブログの投稿にもGoに関するものが増えています。Goのタグがついていたものだけで100記事を突破しているので、少しは日本のGo界隈に貢献できているのかなと思っています。競プロも開催しているので、Gopherの方も競プロerの方もぜひ触れていけたらいいなと思っています。
（スライドを示して）技術ブログ以外にも、Tech CastというPodcastや、未来報をnoteに書いたりしていますので、興味のある方はぜひ見てもらえるととても嬉しいです。
“リーダー”の定義
では本題に入っていきたいと思います。「Goを使ってホントのところ」で今日私が話したいのは、実際の開発者目線もだいぶ入っていますが、管理するというか、リーダーやマネジメントする視点でGoを使ってみて。Goで技術選定してみてどうだったかという話をメインでしていきたいと思います。
connpass上には、一応プロキシというエンタープライズ企業ならではのところも入れていて、そこも軽く触れながら、WebのAPIや実際のバッチ処理で使った注意点にも触れていきたいと思います。
1つ目、リーダー視点で語るGoでのアプリ開発です。リーダー視点といってもいろいろ捉え方があると思うので、最初にリーダーの定義を説明します。
（スライドを示して）今回でいうと、技術選定や処理方式について、メインで設計や判断をして、開発上の責任を持つマネージャーのような人。プロダクトオーナーやマネージャー、リードエンジニアみたいな人をリーダーと置いています。
今日はいろいろ話しますが、ここ5年くらいで5つくらいのプロジェクトの環境構築をしたり、システムを作ってきた経験での話なので、ちょっと偏った観測範囲かもしれませんが、なるべく汎用的な話題に絞って話していきたいと思っています。
Go言語を採用してよかったところ
まずサマリーで、Go言語を採用してよかったところを挙げていきたいと思っています。1つ目はキャッチアップが早いところです。私はJavaなどほかの言語もやっていますが、みなさんも知っているように、「A Tour of Go」という教育コンテンツやパッケージ管理も、言語に組み込まれているとなんやかんやすごく楽だなと思っています。
もう1つ、このあとでも触れますが、syntax sugarが少ない点です。「愚直である」とか「泥臭い」とかはGoでよく言われることですが、特に中途参画した方に、既存のコードが読みやすいとか、理解しやすいところは大きなポイントだと思っています。
あとは、Webのフレームワークの差異が少ないとか、コードの互換性です。ジェネリクスがくるとわかりませんが、後方互換性がかなり強く保たれているのは魅力的だと思っています。
あと、ちょっとネタなのですが（笑）。適度にスキがあると言うと変な話ですが、隙間産業的なツールを作りやすいところがあります。私も作るのですが、若手のメンバーもガンガン作っています。小さいツールを作りやすいので、成長実感につながったり、手を動かす行動につながりやすいところも、すごくいいポイントだと思っています。
新人が多い会社だからこそ感じるGoのメリット
最初に結論を言いましたが、私の会社の特殊なところでいくと、自社の新卒採用が特にすごくて、毎年100名くらいの方が入ってきます。これが全員ITコンサルタントなので、エンジニアでコードも書く人たちです。
全員プログラムがバリバリできるというより、新人研修は実はJava中心です。ポテンシャル採用なので、いわゆるプログラミングが未経験の人がどれくらいかはともかくとして、文系の学部出身の人も数多くいます。そういったところもあって、会社的にもローテーションがあり、人の流動性、入れ替わりもけっこうあります。
私がリーダーとして悩んでいるところでもあるのですが、戦力化までの期間をかなり短くしないと、教育投資効果がペイしにくいので、このあたりはかなり気をつけているところです。
そこでGoはどうかと聞いてみると、まず「A Tour of Go」がある。最初に「触ってみて」と投げられるのが非常にいいというのが1つです。
あと変な話ですが、「A Tour of Go」をやらなくても、先輩のコードをコピーするだけでも、ある程度業務的なコードが書きやすいところがあるかと思っています。一方で、例えばtry-catchでネストが深くなりやすいところもあると思っています。
一方で、Goが毎回エラーをリターンするところもトレードオフはあると思いますが、こことそこだけを切り取ってコピーするところがやりやすいのは、初心者にはいいという声がありました。
あとコード同士の関係を追いかけやすいところがけっこうあります。愚直だからかわかりませんが、一部の別の領域よりは追いかけやすかったという声もありました。コードジェネレートでコードを生成しているので、そこまでは追いやすいです。リフレクションで、動的にリンクも比較的少ないところが効いているのかなと思っています。
リーダーとして、最初にいい開発者体験を提供しやすいところは、本当に嬉しいポイントだと思っています。最初に成功体験をいち早く得て活躍してほしいのと、新人さん（として）は新しい環境に入って早く貢献したいのだけど、1週間コミットできなかったとなるとかなりストレスだと思うので、Goの泥臭くもあるけどわかりやすいところは相当強いと思っています。
ここ最近（のこと）ですが、Slackで初マージで調べてみると、初コミットまでだいたい1～2日くらいで、自分の環境のチームに関しては何かしらコードを書いてコミットしています。ハマっていても環境構築だし、Go自体は何かプログラム（言語）をやっていればすぐやれるというのは、相当いいと思っています。
リーダーというわけではありませんが、ほかのチームから移籍やローテーションで来る時に、事前に「やっておいたほうがいいことはあるか？」と聞かれます。最初にこれをシェアできるのは、「A Tour of Go」のいいところかなと思っています。
「なにもやらなくてもいいよ。来たら教えるから」と言われると不安になりますが、「これをやればいいんだ」というものが明確になっていると、ストレスも相当減ります。Goは意外とメンタル的にもいいんだと思っています。
実際に「全部やったの？」と聞くとやっている人は少ないです。ただ、ブラウザ上で手を動かせるコンテンツでは、初回の1、2個くらいの課題で手を動かしてみるので、そこはすごくいいと思っています。
ほかにも、コミュニティのみなさまのおかげで、初心者に優しいエコシステムが相当できているのではないかと個人的には思っています。
あと、（Goのいいところとしては）隙間産業的な記事の書きやすさという点です。これはいろいろ語弊がある気もしますが、（Goの）発展途上の面もあるかと思っています。どの言語もそうだとは思いますが、ジュニアクラスの方でも、ライブラリの利用で微妙にハマったネタが公開しやすいのかなと思っています。
これはリーダー目線から見てもけっこううれしい現象で、ネタを公開しやすいとか、チーム内でシェアできるというところでで、メンバーの成長実感につながりやすいです。
私もブログを運営しているので、外部露出によって採用などのプラスになります。そこも相当助かっているという点で、Goを選んでよかったと思っているポイントの1つです。
あとよくあるのが、例えば新規参画者の人、前に入った人が詰まったところがブログに出ていると、同じように自分もそれに助けられます。それが日本人の同じような人が書いていると、より正のサイクルが回るところで、とてもいい雰囲気作りにつながると思っています。
ライブラリ選定もフルスタック寄りの機能バリバリよりは、小さいものを組み合わせると、なんとなくネタを増やしやすいTipsがあると個人的に感じています。
Goの辛いところ
（Goで）辛いところは何かといろいろ考えたのですが、あまりありません。Go自体はわりとシャキシャキ動くので、どちらかと言うとDockerを組み合わせた時に詰まることが多いと思っています。
環境構築はどの言語でもそうですが、プログラミング初心者にとって鬼門です。最初にどれだけ環境構築ガイドを作れるかで初期生産性に大きな差が出るので、ここは気をつけたいポイントだと思っています。
（スライドを示して）バージョンの互換性が高いという話ですが、ほとんど文句がなくて非常によかったなと、5年くらいやってよかったなと思っています。たまに「GO111MODULE=onみたいな環境変数を設定してね」などの話がありますが、これは指定しても特にそこまで悪さをするものではないと思っています。今のところ、そこまで情報が陳腐化しないのもすごくいいポイントだと思っています。
プロキシ環境で困ること
一応プロキシというネタを最初に出したので、2ページだけ作ってきました。「Goを使って本当にプロキシってどうなんだ？」という話ですが、正直、慣れるとhttp_proxyを環境変数に置くと動くので、書いたわりにそれほど詰まっていなかったなと思っています。
これはGo自体というよりは、どちらかと言うとDocker上でGoをマルチステージビルドするとか、Dockerファイルの中でGoビルドコマンドを叩く時には、少しやっかいだと思っています。ホスト上で環境変数が残っていたとしてもDocker上でプロキシの設定があるわけではないので、build-argや引数で渡すところがけっこうハマりやすいポイントだったのかなと思っています。
たまにこういったものを書かずに、Dockerファイル上やdocker-compose.ymlにプロキシ設定の環境変数を寄せちゃう人がいます。毎回のプロキシ設定をしていないぶん、そういったハマりどころがあります。このコマンドは気をつければ大丈夫かなと思っています。
社内プロキシについていろいろ思うところもあったのですが、各種環境を作りきってさえしまえば、ぜんぜん問題はないのかなと思っています。もちろん社内のGitLabといった、プライベートリポジトリなどに噛み合わせる時はちょっとハマるかもしれないので、その時は急にキレキャラになるかもしれません（笑）。今のところは特に大きな問題は生じていないと思っています。
（次回に続く）
