Chatworkのオンラインサマーインターンシップ2020に参加してきたよ
こんにちは。
8月中旬～9月頭の3週間でChatwork株式会社のオンラインインターンシップに参加してきたので記録を残そうと思いますー
オンラインでの開催は初の試みらしく、僕もオンラインのインターンシップは初めてだったので、不安な部分はありました。
しかし、めちゃめちゃ楽しかった＆勉強になりました。
インターンの流れ
参加するまで
LabBaseというサイトに登録していたら、スカウトをいただきました。
chatwork自体は知っていたし、scalaを使ってるとのことで触れてみたいと思いました。それと、1週間の講義＆2週間の実務というめちゃ充実の内容だったので、そんなにしっかりやってくれるところは中々ないだろうなと思って応募してみました。
研究のことや開発経験のことをプロフィールに書いておけば結構スカウトをもらえるので、院生とかにはLabbaseはおすすめです。(魔法のスプレッドシートなるものを見ておきさえすればいいという噂も)
面接は人事の方とエンジニアの方が同席し、2対1で行いました。
確か時間は1時間弱くらいで、最初に人事の方からいわゆる人事面接的な質問をされ、その後にエンジニアの方から技術的な質問をされました。
内容はあんまり覚えていません（笑）けどそんなに変わった質問はされた覚えもなく、めちゃゆるい雰囲気で喋りやすかったです。
どこの面接でもそうだと思うんですが、院で研究してたり個人で開発されてる方はなんでそれをしてるのか？を自分なりに考えていれば大丈夫な気がします（テキトー）
技術的なことに関しては、長期インターンでやってることを中心に開発経験を聞かれました。使用してる言語やFW、どんな機能作ったかとかです。おそらくすでに業務で開発したことがあるというところは評価していただけたのかなとは思います。
面接は一回だけで決まり、コーディングテストとかもありませんでした。面接した次の日にぜひ来てくださいというメールが届き、ほんとにいいのかな？とかちょっと思いました笑
参加決定後
インターンではバックエンドはScalaを使用するので、事前学習として「実践Scala入門」が配送されてきて、これを一通り読んできてとのことでした。入門といいつつなかなかのボリュームで、だいぶしんどかったです。
全然scalaを知らなかったので、match文ってなに？case classってなに？なんですぐOptionで包むん？みたいな感じでした。正直未だにふわっとしてる。
あと16インチのMacが届き、テンションがあがります。
1週目
そしていよいよインターンが始まります。
インターン中は基本ずっとGoogle meetをつないで行いました。
講義を受けるときはコメントで色々茶々入れながら聞けるのがいいですね。やっぱりオフラインの講義でその場で手を上げて質問するって中々抵抗あって、疑問に思ったタイミングでその都度コメントしたほうが聞きやすいです。話す側も非同期的にコメが溜まっていくので、その場で話を止めなくていいですし。
1周目は講義パートですが、講義といってもすごい実践的。
ソフトウェア開発の基礎、チーム開発のことを教わったり、実際に手を動かしながら(僕はバックエンドコースだったので)scalaを学んだりで盛りだくさんです。
特に最後の講義の、ドメイン駆動設計のお話が一番聞けてよかったです。後の実務パートで活きてきます。
運用のお話などもあり、chatworkがないと仕事が出来ない会社も多くあると聞きました。そのためちょっとでも障害が出て止まったりするとYahooニュースに載っちゃうみたいですね…
ただそれくらい社会インフラの一部になっているサービスを開発できるのは、相当やりがいがありそうです。
2週目
2週目からはいよいよ業務パートです。
2チームに分かれましたが、僕のチームバックエンド3人フロントエンド2人でした。
社員の方がスクラムマスター兼プロダクトオーナーになって、最初に1週間でやるタスクを決めて、開発して、週の最後に振り返るという感じです。
今回は既存の掲示板アプリが用意されており、そこに「お気に入り機能」を設計して実装するというのが主な目標でした。
最初は設計なのですが、今まではいざ設計しようとなると、画面こんな感じかなーって考えて、それに合わせてテーブル定義して、みたいな感じでした。が、チーム開発ではそういうわけにはいきません。
これでは、後に変更や機能追加を行う際にどんどんカオスになっていきます。チームで開発するとなるとなおさら、個人間で解釈が違ってしまうことが多発します。
それを防ぐために、ドメイン駆動設計の考え方を導入し、ドメインモデルの定義をしました。（ドメインモデリングというやつ）
ドメインモデルとは何か？というのが捉え方が難しいのですが、個人的には
「ある問題を解決するために必要な登場人物」
「組織内でその登場人物の名前や振る舞いの共通認識を決定すること」
になるのかなあと。
ドメインモデリングをすることで、エンジニア間だけでなく、組織全体で共通認識や共通言語（ユビキタス言語という）が決まり、そのドメインを使ってどのように問題を解決していくかを共有することが出来ます。
詳しいことはここらへんの本読むと良いみたいです。
あとかとじゅんさんの資料なども参考に（めちゃ重めです）
- ユーザー
- スレッド
- メンバー
- メッセージ
- お気に入り
があたり、振る舞いとしては
- スレッドはメンバーを持つ
- メッセージはスレッドに投稿される
などなど…
元々用意してあるアプリには、お気に入り機能以外はすでに実装されていたので、お気に入り機能のドメインモデルをチーム内で話し合いました。
まあけど、チームメンバーはみんなドメイン駆動設計なんてしたことなく、初めてのことばかりでした。
そもそも、ドメイン駆動設計で出てくる単語が多すぎる（笑）。エンティティ、リポジトリ、値オブジェクト、集約、境界など‥
しかしメンターさんや社員のサポートもあり、なんとかやってみました。miroという、オンラインで付箋を貼れるサービスを利用して、みんなで色々書きまくりました。
オンラインだとやりにくいところはあるんですが、こういうサービスがあるとすごく進めやすくていいですね
そしてある程度全員で認識を揃えたらいよいよ開発。
僕らのチームのバックエンド担当３人はscala経験者がいなかったので、基本画面共有しながらモブプロって感じでした。
そして一週間の最後にスプリントレビューを行います。最初に計画したタスクをどのくらい達成できたか、このスプリントで何が良くて何がビミョーで次はどうしたいのか、などをきっちり振り返ります。
確か一週目は、計画した半分も終わらなかった気がします （笑）
3週目
３週目は2週目と同じ感じです。一週経験すると、タスクの見積もりも少し精度があがり、ちょっと慣れてきます。
ただ開発してるとどんどん「この設計じゃまずくない？」なことが起こり、その都度話し合って修正して、とやってるとすぐ時間が溶けていきました。
ドメインモデルの関係を意識しすぎて、フロントがクソ使いにくいAPIレスポンスを作っちゃったりして、ごめんなさいになりました。（リードモデルとドメインモデルは区別する必要があった）
結局全部終わらせることは出来なかったですが、なんとか動くとこまではもっていけました。（というか、そうさせてもらった）
masterブランチにpushされるとcircleCIが走ってデプロイされるんですが、最後だけ無理やり違うブランチを社員の方にデプロイしてもらいました。yu_shu_no_bi（有終の美）ブランチとかいうふざけた名前のブランチを動かしてもらって、ちゃんと動作してめちゃ盛り上がりました（笑）
感想
ドメイン駆動設計わからん
DDDを実践してみたものの、まだまだわからないことだらけです。
ただ、DDDの第一人者的な人であるかとじゅんさん（@j5ik2o）をはじめ社員の方々は、完璧な正解や教科書が存在するわけではないので、やりながら学んでいくしかないとのこと。それもそのはず、DDDはあくまで設計なので、解決したい問題によってチームで議論してアプローチを決定していく必要があります。
特に集約の決め方がむずいです。今回で言うと、「お気に入り」というドメインはどこに属するのか。ユーザの集約に持たせるのか、メッセージの集約に持たせるのか、というところで詰まりました。
一般的な集約の基準としては、「集約元が更新されるときには同じタイミングでそれも更新されてほしい」かどうかというところらしいですが、多分どちらも間違いというわけではないんですよね〜
いろんなエンジニアの方から聞きますが、アーキテクチャや設計は「正しさ」よりも「決めること」の方が大事なようです。スピード感を持って決めてしまって、変更の必要があるときになったら変える。Done is better than perfectってやつですねー
あとドメインの振る舞いを考えるときは、受動態で考えると良いと教えていただき、なるほどなあってなりました。
無生物主語が日本語だと違和感があるので、「AがBをCする」を考えると大体「A=ユーザー」になっちゃうんですよね。そのため、「BがAによってCされる」と考えるとBがドメインとなり、振る舞いをコードに落とし込みやすくなります。
これぞオブジェクト指向。すげえー
オンラインでモブプロむずい
モブプロもオンラインだと難しいですね。オフラインなら一個のPCをかわりばんこで使えばいいですが、「こここう書いたほうがいいんじゃない？」的なことがオンラインだと非常にしにくかったです。
ただその分、自分の考えていることややりたいことを的確に伝える訓練にはなったと思います。 しかもモブプログラミングの心得の一つに、「ドライバーが勝手に進めてはいけない」というのがあって、全員の認識を揃えながらすすめるにはオンラインの方が効果があるなあとも思いました。
モブプログラミングはみんなで考えながらコードを書いていく分、モブプロ中の開発効率は確実に犠牲になります。全員の理解を揃えるところに狙いがあるので、その犠牲を払っていることを全員が十分に理解しないとですね。
チーム開発楽しい
なによりこれです。他のサマーインターンでも思ったことですが、みんなで「こういうもの作ろう！」と決めて、全員でわいわい開発していくのは本当に楽しいです。 チームのメンバーがめちゃめちゃ優秀な人ばかりでだいぶ頼っちゃいましたが、その分刺激も得られて超楽しかったです。
インターンはオフラインがいい
正直、オフラインで出来たなら絶対そっちのほうが良かったです（笑）
短期のインターンに行く意味って、一番は体験が得られるからだと思うんですね。なのでその体験を余すことなく享受するには、実際のオフィスに行って、チームで一緒のディスプレイ見ながら開発して、というような物理的な体験が必要な気がしました。
あとやっぱりきれいなオフィスいくとテンションあがりますしね（笑）
あとあと、去年のインターンに参加された方がメンターとしてついてくれたのですが、全員「オフィス近くのご飯がめちゃうまかった」と言っていたので、食べたかったなあーー
まとめ
3週間めちゃめちゃ良い時間過ごせました。知らない人とチームになって短期間だけで開発するというのは、後にも先にも中々できない経験だと思うし超楽しいです。楽しい上にすごい量の知識をインプットし、実践できる機会なんてホントに貴重です。
あと、オンラインだと中々物理的な会社の雰囲気はわかりにくかったですが、社員の方々の雰囲気が優しくて気さくな方ばかりでした。「働くをもっと楽しく、創造的に」というミッションを掲げている会社だけあって、それを体現している人が集まっているんだろうなあという印象です。今度オフィスツアーに行けるらしいので楽しみです。
他の会社のインターンなども行きましたが、やっぱりエンジニアは楽しそうです。楽しいだけじゃないと思うけど、きつくてもやっていたい仕事だなと思います。
どこで働くことになるのでしょ〜
追記
一緒に参加した人のブログ
オフィスツアー行ってきた
11月にオフィスツアー行ってきて、インターン生と社員の方々とオフ会をしました（笑）。
3週間顔を合わせていたものの、あくまでmeetの画面上だったので、「ほんとに存在するんだ、、」と口々に言ってました。
そしてオフィスがキレイでした。めっちゃ広いってわけじゃないですが、バーカウンターとかあって働いたら楽しそう。
あとエンジニアの業務スペースを見てみると、めっちゃ高そうな椅子とか作業環境が充実してて羨ましいっす。
オフィスは東京タワーの目の前にありました。
オフィス出て道路を挟んだ向かい側に東京タワーの入り口があります笑
東京タワーを見ながら美味しいご飯とお酒をいただいてきました😉
