はじめに
はじめまして、2024 年の 2 月からカナリーでエンジニアとして長期インターンをしている小池雄大です！本記事では、インターンを通じて経験したことや感じたことを紹介します。長期インターンを探している学生さんやカナリーのエンジニア職に興味を持っている人の参考になれば幸いです！
ジョインしたきっかけ
カナリーに興味を持ったきっかけは以下の 3 つです。
- 10→100 フェーズのプロダクトに関わりたい
- 技術的にチャレンジングできる環境で開発したい
- ドメインへの関心
カナリーにジョインする前は、別のスタートアップ企業で初期フェーズのプロダクトを開発していました。まだ小さいプロダクトを日々改善し開発するのはとても面白かったですが、次のステップとして、より成熟したプロダクトの開発組織や技術構成、プロダクトの課題について知りたいと思うようになりました。その際、Wantedly でカナリーのエンジニア向けのエントランスブックを拝見し、カナリーに興味を持ちました。自分たちが目指している組織や課題に対する技術内容について、とても詳細に書かれており、学生ながら優秀なエンジニアが多く在籍していると考えました。また、不動産に近い領域で家業をしており、より身近な環境で開発してみたいというドメインへの関心からエントリーすることを決めました。
カナリーでの取り組み
ジョインしてから
入社後、CANARY を開発しているポータルチームに配属されました。主に Go を使ってバックエンド開発をしています。配属された当時、バックエンドのマイクロサービスへのリアーキテクチャが完了するタイミングでした。初めはマイクロサービスに対する理解が不足しており、設計思想やドメイン、トランザクションの管理などをキャッチアップするのにとても苦労しました（今でも苦労しています）。しかし、丁寧な 1on1 のおかげで日々の疑問を解消できました。
その他の技術構成についても、gRPC や Cloud Spanner など、個人開発では扱わないような技術が使われており、新たな学びがあってとても楽しく、貴重な経験をさせていただきました。
業務内容
いくつかタスクをこなしましたが、とくに印象深かったのは以下の 2 つです。
- CS チームからの依頼対応をスラックコマンド化し、トイルを改善
- 内部管理画面に課金設定を変更するための申請フローを確立
CS チームからの依頼対応をスラックコマンド化し、トイルを改善
CANARY がサービスとして規模を拡大する中で、エンジニアチームには先方や CS チームから多くの依頼が寄せられています。これらの依頼には、課金に関わるセンシティブな内容も含まれており、対応に多くの時間を要することがしばしばあります。このため、一部の依頼を Slack コマンドを用いて自動化することがタスク内容となります。とくに DevOps の領域では、トイル削減は重要な概念です。自動化によって手作業を減らし、時間の消費やミスを防ぐことは、チーム全体の生産性向上に寄与します。私が取り組んだトイル改善は、プロダクトの長期的な成長と安定を考えると、大きな成果をもたらしたと実感しています。また、Slack コマンドの導入により、CS チームやエンジニアチームから良いフィードバックをいただけたことが非常に嬉しかったです。
内部管理画面に課金設定を変更するための申請フローを確立
このタスクも業務改善の必要性から生まれました。送客依頼の 6〜7 割が課金に関する変更であり、大きな改善の余地がある業務でした。これらの変更は監査に関わるため、フローが複雑で、対応にはエンジニアだけでなく、CS チームの複数人による確認と承認が必要です。そこで、エンジニアが対応に多くのリソースを割くことが負担になっていたため、CS チームだけで対応を完結させる目的で、内部管理画面化を進めることにしました。この管理画面により、課金設定の変更に必要な承認プロセスを一貫して行うことができるようになりました。機能がひととおり完成したタイミングで、CS チームからフィードバックを得るためにデモ会を開催しました。デモ会では、ユーザー目線による貴重なフィードバックをいただき、自分の実装した機能が組織の役に立つことの実感を得られたのはとても貴重な経験でした。
カナリーでの学び
プロダクトやドメイン理解が重要
技術と同様にプロダクトやドメインの理解が不可欠であると学びました。プロダクトや組織の課題を解決するには、これらの知識が必要であり、課題の背景を把握するための近道となります。ドメイン知識が欠けていると、どこを改善すべきかを正しく特定できず、サービスの課題を見つけるのが難しいです。この理解を促進するための有効な手段として、社内用語辞典（ユビキタス言語一覧）が非常に役立ちました。これを活用することで、はじめて業務に携わる際にも、専門的な内容を迅速に把握できました。
以前のインターンシップでは、プロダクトの成長に伴い、ビジネス部門とエンジニアリング部門の間で用語の解釈に齟齬が生じることを経験しました。こうした問題を事前に解消することで、チーム内のコミュニケーションがスムーズになり、意図や目的が正確に伝わると感じました。
マイクロサービスは難しい
マイクロサービスの導入は多くの難しさがありました。マイクロサービスの効果を最大限に活かすためには、システムを適切なドメインで分割することが重要であり、そのためには業務や組織の深い理解が不可欠であることを学びました。また、トランザクション管理はモノリシックアーキテクチャのように単純ではなく、マイクロサービス間でのデータ整合性を保つための工夫が必要で、設計の難易度が非常に高かったです。
さらに、オブザーバビリティ（可観測性）も重要な概念であり、サービスの運用において課題を感じながら携われたことは非常に良い経験になりました。加えて、マイクロサービスを効果的に運用するためには、組織の最適化や強力な DevOps の体制が求められ、プラットフォームエンジニアリングがあってこその技術であると気付きました。
10→100 ならではの気づき
この成長過程で、運用面での課題が明確になってきました。とくに、トイルの改善やチームの生産性向上は重要なテーマとなり、組織全体を見渡し、生産性向上のための改善策を検討する視野が広がったことは大きな経験でした。また、コードの品質を保つためには、適切なコメントが非常に重要であることに気づきました。コメントは、新しく参画したエンジニアの認知負荷を下げるのに役立ち、私自身もインターンとして参画した際に多く助けられました。こうした細部への配慮は、コードの保守性を高めるうえで重要な役割を果たします。
さらに、toC プラットフォームにおける施策改善では、数値や仮説に基づいた検証が重要であることを学びました。何が効果的であるかを調査し、具体的な数値を見つけることで、データに基づいた意思決定が可能になります。カナリーでのミーティングに参加することで、このプロセスがチームでより効果的に機能を開発・改善するうえで欠かせないステップであると実感しました。
カナリーの良さ
カナリーの良さは、心理的安全性が高く、オープンで協力的な文化にあると思います。メンバーはお互いを尊重し、自由に意見を述べられる雰囲気があります。年次や立場に関係なく、誰もが積極的に意見を出し合い、それを適切に受け止め、フィードバックをもらえる環境が整っています。自分の考えや提案が受け入れられることで、インターン生も一人のエンジニアとして対等に議論に参加できました。
さらに、Slack のハドルや Gather といったツールを活用したオープンなコミュニケーション環境が整備されており、気軽に質問や意見交換、雑談ができます。このような環境から、いつでも誰かに相談できる安心感があり、非常に働きやすい職場です。
おわりに
カナリーのインターンは心からオススメできます。私自身、このインターンを通じてエンジニアとしての視座が大きく高まったと実感しています。カナリーでは、技術と目的を非常に大切にする文化が根付いており、各メンバーがオーナーシップを持ってプロジェクトに取り組む環境が整っています。技術と目的を重視し、責任感を持って働きたいと考える学生には、非常に適した場所だと思います。ぜひエントリーしていただきたいです。
Discussion