DMM Sprint Goに行ってきました〜!!
みなさんお久しぶりです。YAMAです。
DMMさんのインターン「DMM Sprint Go」に行ってきたので、そこで何をしてきたのか、何を感じたのかを書いていこうと思います。
そもそもDMM Sprint Goって何?
ざっくり言うと、Goを5日間みっちりやるインターンです。
最初の1日目から3日目まではリモートで、Zoomを使いながら講師の方が解説してくれるって感じでした!
その後の4日目・5日目は会社の方に行って、実際に会って話しながらやるみたいな感じでした。
流れとしてはこんな感じです。
| 日程 | 形式 | やったこと |
|---|---|---|
| Day1 | リモート | Goの基礎・標準ライブラリの演習 |
| Day2 | リモート | 1日目の解説・アプリケーション開発(API実装・DB作成) |
| Day3 | リモート | アプリケーション開発・講師のライブコーディング |
| Day4 | 出社 | 社内ツアー・アプリケーション開発 |
| Day5 | 出社 | アプリケーション開発・ビアバッシュ |
1日の流れとしては、11:00に朝会でスタートして、18:00に終了という感じでした。
朝が早すぎないのが地味にありがたかったです。
まずは、チームを組んで、10〜15分くらいアイスブレイクをして、チームの人と仲良くなってから演習に入っていきました。
チームの人は結構話しやすく、交流もできて、楽しかったです。
Goの演習
タイトルにも書いてある通りなんですけど、Goのインターンに行ってましたね。
ここからは各日の演習の内容を書いていきます。
Day1:Goの基礎・標準ライブラリ
まず、最初はきほんのライブラリ(例えば、io、net/http、contextなど)を学ぶ簡単な演習などをしました。
その後、それらを使った、テストの作成などをしていきました。
一日目は講義を集中的にやって、Goの基礎を学ぶ的な感じでした。
実際に、Goの基礎を学ぶことができたので、Goを触ったことがない人でも安心して参加できると思います。
しかし、プログラミングの基礎がない人には結構難しいかもしれないです。
という感じで、1日目は終わりました。
講師の方の話がわかりやすすぎる
当たり前なのですが、Goを業務でずっと使っていて、理解がとてもある人しかいないので、丁寧にかつわかりやすく解説をしてもらうことができました!
質問しても的確に答えてくれるので、みんなわからないところがあればすぐに質問をしていました。
Day2:アプリケーション開発(API・DB・アーキテクチャ)
2日目は、朝会のあと、まず1日目の演習の解説を講師の方がしてくれました。
お昼をはさんだあとは、いよいよアプリケーション開発です。
いきなり書き始めるのではなく、まず2時間半くらいかけて導入の解説があって、そこから実際に手を動かすという流れでした。
APIの実装、DBの作成をしていきました。
まーこれが結構大変で、最初は全然わからなくて、アーキテクチャの理解ができていなかったので、APIの実装やDBの作成などをするのに時間がかかってしまいました。
ちなみにこの日のスケジュールのスライドに「ガンガン質問していこう!まじでどのタイミングでもOK!!」って書いてあって、実際その通りの空気でした。
詰まったら聞いていいんだと最初にはっきり言ってもらえるのは、めちゃくちゃ助かりましたね。
そして最後に1日の振り返りをして、2日目は終わりました。
Day3:アプリケーション開発・ライブコーディング
3日目は、朝会が10分だけで、あとはほぼ丸一日ずっと演習でした。
昼休憩も「各自のタイミングで1時間取ってください」という形だったので、キリのいいところまで進めてから休憩する、みたいな進め方ができたのが良かったです。
そして夕方の16:00から1時間、講師の方のライブコーディングがありました。
それを見たあと、もう一度演習の時間があったので、見て学んだことをその場ですぐ自分のコードに反映できるという流れになっていて、これがかなり効きました。
このライブコーディングがめちゃくちゃ勉強になったので、次の章でまとめて書きます。
講師のライブコーディングを見て感じたこと
Day1のところでも講師の方の解説がわかりやすいって書きましたが、Day3のライブコーディングは特に印象に残ったので、ここでまとめて書きたいと思います。
講師の方は、コードを書きながら解説をしてくれるのですが、考え方がまるっきりインターン生の人たちと一線を画していて、非常に論理的で整理されていました。
「コードを真似する」のではなく「必要な情報だけ参照して組み立てる」
自分はほかのコードを見ながら実装をしていたのですが、業務でGoを使っている人は、実装しようとしている部分に必要な定義や関数の使い方だけを別のファイルから参照して、あとは自分でコードを書いていました。
コード全体を見て真似するのではなく、必要な部分だけをピンポイントで参照して、それ以外は見なくても実装できるというのが本当にすごいと思いました。
自分は「似たコードを探して、それを参考にしながら書く」という感覚だったので、必要な情報だけを取り出して自分で実装できるところに、経験の差を感じました。
Onion Architecture
まず、アプリケーションのアーキテクチャは、Onion Architectureを採用していました。
そもそもOnion Architectureとは、アプリケーションの層構造を「ドメイン層」「ユースケース層」「インフラ層」「プレゼンテーション層」に分けて、依存関係を内側の層に向けることで、疎結合な設計を実現するアーキテクチャです。
自分はMVCアーキテクチャを使ったことがあったのですが、Onion Architectureは初めてだったので、最初は理解するのに時間がかかりました。
Onion Architectureを理解できたあと、実装が楽になったのは、依存関係が整理されているので、どの層で何をすればいいのかが明確になったことです。
たとえば、ドメイン層ではビジネスロジックを実装し、ユースケース層ではアプリケーションの振る舞いを定義し、インフラ層ではデータベースや外部サービスとのやり取りを実装するというように、各層の責務が明確になったので、実装がスムーズに進められました。
実装の考え方
最初はほかのコードをみてどういう風に実装されているのかを見て、まねていくように実装していきました。
Goでは、エラーハンドリングが非常に重要で、エラーが発生した場合の処理をしっかりと実装する必要があります。
しかもエラーなどは自分で定義して、エラーが発生した場合の処理を実装する必要があるので、エラーハンドリングの考え方を学ぶことができました。
実際に出社してきた
東京へ
4日目と5日目は、実際に会社に行って、集まってアプリケーションの開発をしていきました。
私は大阪から東京に行くので、朝の新幹線で東京に向かいました。

あ、ちなみに朝食はこれです。

めっちゃ美味しかったです。
チーム開発
その後、昨日の続きで、アプリケーションの開発をしていきました。
昨日と違い、Zoomではなく、実際にチームメイトと話しながら開発をしていきました。
結構これが新鮮で、自分は元々OSSなどをGitHub上でやり取りして開発をしていたので、実際に会って話しながら開発するのは新鮮でした。
あ、ちなみに、自分がコントリビューターとして参加しているOSSはblogに書いてあるので、興味がある人は見てみてください。→ OSSの話
Day4〜5:出社してからのアプリ開発
あまり詳しくは書けないのですが、チームでアプリケーションを作っていきました。
一人で開発自体はやるのですが、その途中で、チームメイトと相談しながら開発をしていきました。
ほかにも講師の方がずっといてくれて、わからないことがあればすぐに質問できる環境だったので、非常に開発がしやすかったです。
実際どこまでアプリを作れたか
目標とappendixに書いてある機能を実装することができました。
それと課題以外にも、別の機能を実装することができました。
ほかの人を見ていると結構まばらで、完成している人がいれば、まだ完成していない人もいました。
GitHub
チームで開発して感じたこと
さっきも書いた通り、今回は1つのリポジトリをチームで触るというよりは、各自で実装を進めて、詰まったらチームメイトに相談するという形でした。
なので、コンフリクトで大変みたいなことはなかったのですが、逆に「人に聞ける環境」のありがたさをめちゃくちゃ感じました。
一番違うなと思ったのは、聞いてから答えが返ってくるまでの速さです。
自分は元々OSSでの開発がメインで、GitHub上でやり取りしながら進めていたので、1回聞いたら返事が返ってくるのは数時間後とか、下手したら翌日ということもよくありました。
それが出社していると、その場で画面を見せながら「ここどうやった?」と聞けて、すぐに答えが返ってくるんですよね。
Day2でアーキテクチャが理解できなくて詰まっていた話を書きましたが、あれも隣で聞ける状態だったらもっと早く抜けられたんだろうなと思います。
しかも講師の方がずっといてくれるので、詰まっている時間そのものが短くて、1日で進む量が全然違うなと感じました。
あと、まわりの進捗が見えるというのも、一人で開発しているときとは全然違う感覚でした。
さっき書いたとおり、完成している人もいればまだ完成していない人もいるという感じだったので、自分がまだ詰まっているのに隣の人はもう次の機能に進んでいる、みたいなことが普通に起きます。
正直これはちょっとプレッシャーでもあったのですが、悪いことばかりでもなくて、「あの人がもう終わってるってことは、この方針で合ってるんだな」という安心材料にもなりました。
何より、単純に「自分ももうちょっとやろう」と思える刺激になったのが大きかったです。
一人で開発しているとこの感覚がまったくないので、ここは出社してよかったなと思う部分でした。
ビアバッシュ
最終日の夜は、ビアバッシュがありました。
そもそもビアバッシュって何?って感じだと思うので、簡単に説明すると、ビールを飲みながらLT会をして社員さんと交流する会です。
みんなでビールを飲むのですが、そのビールサーバがなんと、自作のビールサーバで、社員さんが作ったそうです。
すごいですね。
学生がすごかった
まじで、他の参加学生がすごかったです。
自分は、JavaやPythonをメインで扱っているのですが、ほかの学生さんは、JSやTSをメインで扱っている人が多く、フロントエンドの知識が豊富な人が多かったです。
あと、Goを使ったことがある人もいて、Goのclean architectureを知っている人もいました。
自分はDay2の時点でOnion Architectureに苦戦していたので、「もう知ってるんかい」となりました。
ただ、そういう人が近くにいると聞けることも多いので、そこはめちゃくちゃありがたかったです。
社員さんが優しかった・話がおもしろかった
ビアバッシュでは、社員さんとも話す機会がありました。
これがめちゃくちゃおもしろくて、技術の話をふっても普通に返ってくるし、こっちが知らないことは丁寧に教えてくれるという感じで、話していて全然疲れませんでした。
そもそも、さっき書いたビールサーバを自作しちゃうあたりで大体察してもらえると思うのですが、みなさん普通に手を動かすのが好きな人たちなんですよね。
演習中の講師の方もそうで、質問をすると的確に答えが返ってくるし、社内ツアーのときも「この植物は本物で職人さんが手入れをしている」みたいな話まで教えてくれました。
5日間ずっとこの空気だったので、いい意味で緊張せずに過ごせたなと思います。
DMMの社内について
DMMさんのオフィスは六本木にあります。


カフェ
カフェは、めっちゃ安くて、コーヒーや紅茶などが飲めます。
画像がないのが惜しいですが、アクセスが良くていつでも買いに行けるので、めっちゃ便利でした。
ご飯
出社していたので、お昼ご飯は会社の近くのご飯屋さんに行きました。

めっちゃ美味しかったです。
社内ツアー
4日目は、朝から会社に行って、社内ツアーをしてもらいました。
一部お見せできる部分だけですが、こんな感じでした。



という感じで、まじきれいでした。
あと、この植物は本物で、職人の人が手入れをしているそうです。(すげー)
まとめ
Goの知識
このインターンに参加する前は、Goをほとんど触ったことがなかったので、名前と雰囲気を知っているくらいの状態でした。
しかし、インターンに参加して、Goの基礎的な文法だけでなく、ioやnet/httpといった標準ライブラリの使い方、テストの書き方、そしてGoらしいエラーハンドリングの考え方まで学ぶことができました。
5日間で「Goで1本アプリを書ききった」という状態まで持っていけたのは、かなり大きかったです。
今後はいろいろなGoのライブラリを使って、自分でもアプリケーションを作っていきたいと思います。
開発の考え方
正直、Goの文法よりもこっちのほうが学びが大きかったかもしれません。
1つは、Onion Architectureです。
MVCしか知らなかった自分にとって、「層を分けて、依存の向きを内側に揃える」という考え方は最初かなり難しかったのですが、理解できたあとは「この処理はどの層に書くべきか」で迷わなくなりました。
設計を理解しているかどうかで、実装スピードがここまで変わるのかというのが素直な驚きでした。
もう1つは、コードの読み方です。
今までの自分は「似たコードを探して、それを参考にしながら書く」という進め方だったのですが、講師の方は必要な定義や関数の使い方だけをピンポイントで見て、あとは自分で書いていました。
真似をやめて、必要な情報だけ取りに行って組み立てる。
これは今すぐ全部できるようになるものではないですが、意識するだけでもだいぶ違うなと感じているので、これからの開発で少しずつ寄せていきたいです。
チーム開発
一人で黙々と書くのと、まわりに人がいる状態で書くのとでは、進む量が全然違いました。
詰まったときにその場で聞ける、まわりの進み具合が見える、というだけで、こんなに変わるのかという感じです。
自分は元々OSSでの開発がメインで、非同期でやり取りするスタイルに慣れていました。
それはそれで良さがあるのですが、今回みたいに短期間で一気に作るなら、同じ場所で顔を突き合わせて進めるほうが圧倒的に速いなと実感しました。
どっちが優れているという話ではなく、場面によって使い分けるものなんだなというのが今回の学びです。
「DMMで働きたい」と思った理由
ここまでGoの話やチーム開発の話を書いてきましたが、5日間終わって一番強く残ったのは、正直「ここで働きたいな」という気持ちでした。
なんとなくで終わらせるのももったいないので、なんでそう思ったのかを自分なりに整理してみます。
1つ目は、人です。
記事の中で何回も書いてしまったのですが、社員さんも講師の方も、本当に感じが良かったです。
質問をすれば的確に答えが返ってくるし、ビアバッシュで技術の話をふっても普通に会話が続く。
そして何より、「わからないことを聞きづらい」という空気が5日間で一度もなかったんですよね。
チーム開発のところでも書きましたが、詰まったときにすぐ聞ける環境かどうかで、進む量って本当に変わります。
それが会社の雰囲気として当たり前になっているのは、働く場所を選ぶうえで自分にとってかなり大きいポイントだなと感じました。
2つ目は、技術との距離の近さです。
ビールサーバを自作しちゃう社員さんがいる時点で大体察してもらえると思うのですが、「業務でやっているから技術をやる」という感じではなくて、単純に手を動かすのが好きな人が多いという印象でした。
自分は元々、技術寄りの話や開発環境の話をするのが好きなので、そういう話が普通に通じる環境はめちゃくちゃ居心地が良かったです。
あと、演習でOnion Architectureをやったこともそうですが、設計の話をちゃんとやるんだなというのも印象に残っています。
講師の方のライブコーディングを見ていても、「動けばOK」ではなく、なぜその構造にするのかを説明できる状態で書いているのが伝わってきました。
自分もそういうコードが書けるようになりたいと思ったし、そう書くのが当たり前の場所で働きたいと思いました。
3つ目は、集まってくる人のレベルです。
これは会社そのものというより、まわりの学生を見て感じたことです。
Goのclean architectureを知っている人がいたり、フロントエンドをがっつりやっている人がいたりで、とにかくレベルが高かったです。
こういう人たちが「行きたい」と思って集まってくる会社なんだな、というのが素直にうらやましかったし、自分もこの中に入りたいと思いました。
……と、ここまで真面目に書きましたが、オフィスがきれいでカフェが安いのも普通に効いています。
ここに通うのかと想像すると、テンションが上がってしまいました。
5日間という短い期間でしたが、技術・人・環境のどれを取っても、自分が働きたいと思える会社でした。
また機会があれば、ぜひ挑戦したいと思います。
おまけ
シーシャバー
初めて、シーシャバーに行きました。
たばこと違い、煙が甘い香りで、ほかに、肺に溜めずに吐き出すので、たばこよりも健康的だそうです。(あんまりわかんないけど)
あとは、アイスをつけると、煙が冷たくなって、より吸いやすくなるそうです。

東京で食べたものなど
せっかく東京まで来たので、ご飯もいろいろ食べてきました。
まずはもんじゃ焼き。

小さいヘラで削りながら食べるやつ、初めてやりましたがめっちゃ楽しかったです。
そして焼肉。

見てのとおりです。うまい。

先輩に連れて行ってもらった定食屋さんです。 刺身の定食を頼んだのですが、めっちゃ美味しかったです。
ここまで読んでいただきありがとうございました!
これからも、いろいろなことに挑戦していきたいと思います。以上、YAMAでした。