[toc]
はじめに
はじめまして。CADDiの学生インターンとしてバックエンドエンジニアをしている渡邊です。
このたび、3ヶ月間のインターンを7月末に終えるにあたり、その成果発表として記事を書きたいと思います。
この記事では、私がインターンを始めるまでの経緯、インターンで行った実際の業務内容、そしてインターンを通しての感想、の3項目について書いていきます。
インターンまでの経緯
CADDiのインターンには、2022年3月のイベント「Rust完全に理解した(嘘)」を通じて、カジュアル面談・技術試験・面接を経て参加させていただくことになりました。
インターンでやってみたいこととしては以下の2つがありました。
- 「業務システムの開発」
今までは、個人での開発、地元企業でのアルゴリズム開発、といった小規模な開発に携わっていたため、より大規模なシステムに携わってみたかった。 - 「仕事でRustを書く」
過去の業務（アルゴリズム開発）ではC++を使っていたが、言語の使い勝手に不満があった。そこで、日頃から愛用しているRustを業務で使うことでどのような開発体験が得られるのかを知りたかった。
インターンの内容
仕事の概要
生産管理プロダクトチーム傘下のKlein-2022開発チームに配属され、社員の方々と一緒に開発を行いました。
インターンの最初数日で環境構築やプロダクトの説明を受け、その後は他のチームメンバーと同等の扱いでタスクに割り振られて開発に取り組みました。
勤務形態としては、フルリモートで週3日、各8時間（10:00~19:00）の勤務でした。
Klein-2022 とは
社内で稼働している受発注オペレーション管理システム「Klein」の置き換えを目指すプロダクトです。
「お客様に対して見積・受注を行い、サプライパートナー（SP）様へ製造を発注し、製造された製品を検査した上でお客様へ出荷する」という一連の受発注オペレーションを管理します。
単独で動くわけではなく、社内の他システム（SP様との見積・発注のやりとりを行う「SPP」、倉庫拠点オペレーションを管理する「Polaris」など）とデータを連携することもあります。
Klein-2022の構造
Klein-2022は以下の図のような構造になっています。
Klein-2022はフロントエンド（Next.js）、BFF（NestJS）、バックエンド（Rust）という3つのモジュールからなります。モジュール間の通信は、フロントエンド↔︎BFFはGraphQL、BFF↔︎バックエンドはgRPCを使用しています。
なお、バックエンドはモノリシックではなく、受発注オペレーションの段階に合わせて分割されたマイクロサービスとなっています。 現時点では以下の6個のサービスで構成されています。
- アカウント: お客様、SP様、案件担当者などの情報を管理
- BOM: 製造する製品の情報を管理
- 見積: 見積を管理
- 販売: お客様からの受注、およびお客様への製品の出荷を管理
- 調達: SP様への発注、および製造された製品の入荷を管理
- SC: 拠点検査（CADDi拠点における製品の検査）の情報を管理する
Klein-2022のより詳しい設計やその背景を知りたい方は、Klein-2022開発チームのメンバーである松田氏の発表資料をご覧ください。
Rust製の業務WebアプリケーションをRustでリプレイス
典型的な開発フロー
新機能を追加する際の典型的なタスクの流れは以下の図のようになっています。
図の内容を説明します。
まず、Design Docを記述します。
Design Docには、その機能がなぜ必要なのか、ユーザ目線でどのような動作が提供されるのか、実装の設計と理由、などを記載します。
記述自体の時間に加えてチームでのレビューも行うためそれなりの時間を要しますが、これを書くことでチーム内で機能に対するイメージがはっきりし、結果的に開発効率がよくなります。
次に、gRPCインタフェースを定義します。
前節のアーキテクチャ図にあるように、Klein-2022ではバックエンド↔︎BFF間の通信をgRPCで行なっています。
従って、gRPCのインタフェースを先に定義しておくことで、この先のタスクを並行して行うことができます。
gRPCが定義できたら、並行して以下の2つのフローでタスクを行います。
- Rust: データベースマイグレーション → バックエンド実装 → 統合テスト実装
- TypeScript: BFF実装 → フロントエンド実装
※「統合テスト」は、バックエンドのgRPCを実際に呼び出して、データベース・バックエンド・gRPCが意図通りに動作するかを確認するテストです。
自分はReactやTypeScriptにはあまり明るくなかったので、gRPCの定義をやった後に、TypeScriptのタスクは他メンバーにお任せしてRustのタスクをやることが多かったです。
上のタスクが全て終わったら、最後に他の方に動作確認をお願いします。
問題なく動作すれば、機能開発は完了です。
チーム開発の進め方
前節でタスクの分解方法を説明したので、分解されたタスクの進め方も含めて、チーム開発がどう動いていたかを説明します。
CADDiではスクラム開発を採用しており、スプリント期間は2週間です。
スプリント開始は水曜日で、この日にはスプリントゴールや扱うユーザーストーリーを決めるスプリントプランニングを行います。
スプリントプランニングでは、各ストーリーのDoD（完了の定義）やストーリーポイント（ストーリーの規模を数値化したもの）についてチームで議論します。
議論してみると、当初自分が想定していたよりも実装する内容が多かったり波及範囲が大きかったりすることが他メンバーの指摘によってわかることがあります。
こういったことが開発中に判明すると大変なので、ここで先んじて議論しておくことは開発効率の向上につながります。
スプリントプランニングの中で、ストーリーは前節で説明したようなタスクに分解されます。
タスクの割り当ては、スプリントゴール達成のために必要な優先順位をチームで議論しながら、優先順位やメンバーごとの得意分野を踏まえてタスクを取っていく形で行われます。また、手が空いたら随時未割り当てのタスクを取ることになります。
私はバックエンド側のタスクを取ることが多かったですが、インターン終盤ではBFFのタスクや簡単なUIの修正（文言の修正、GraphQLの修正などReactがあまり絡まないもの）も取るようになりました。
タスク（特にDesign Doc）を進めていくと、ストーリーの必要性や実現したいことがエンジニアにとって明確でないことがあり、その場合はユーザーやPdM（プロダクトマネージャー）に質問することになります。
Klein-2022は社内で使用される製品なのでユーザは社員です。そのため、ユーザ・PdMどちらに対しても質問は社内Slack・Discordで行うことができます。
インターン中に私からPdMに質問をする機会が何度かありました。質問をするには当然ながら機能の深い理解と機能にからむドメインの知識が必要となるので、働く期間の短いインターンにとっては難しい部類の仕事だと思います。ただ、チームメンバーに相談することで理解・知識は補えるので無理な仕事ではなく、また質問のために勉強することで機能やドメインへの理解が深まることになります。
自分のタスクを処理する他に、自分以外のチームメンバーが出すプルリクエスト（PR）のレビューをすることも日常的に行いました。
PRを作成する際には、チームメンバーのランダムな3人（GitHubの機能で選ばれる）にレビューを依頼することになっています。
幸いなことに私はある程度Rustの経験があったので、レビューを通してRustの経験が比較的浅いチームメンバーの手助けをするという貢献ができました。
以上に述べたチームの動き方はインターンだからといって特別ということはなく、一般のチームメンバーと同じものです。
インターンの感想
初めて大規模な業務コードに携わることとなりましたが、コードの構成が整っているおかげで、数万行規模のコードを触るのも苦になりませんでした。また、バックエンドが日頃から愛好しているRustで書かれていることもあり、事前の想定通り楽しんで開発を行うことができました。
インターン用の特別なタスクというものはなく、普通のチームメンバーと同じタスクを扱いました。ドメイン知識が必要で手ごわいタスクもありましたが、チーム内でDiscordを使って気軽に相談・質問できる体制があり、非常に助かりました。
日頃から技術に関しては色々勉強をしていたとはいえチーム開発の経験はなく、自分の能力でチームに貢献できるか不安がありました。しかし業務に関わっていくうちにチームメンバーから「積極的にタスクを取っていく姿勢がよい」「インターンの枠に収まらず戦力として役に立っている」などといった評価をいただくことができ、自分の能力に自信が持てるようになりました。
最後に
暖かいチームと整理されたコードに迎えられ、実りあるインターンをさせていただくことができました。
Klein-2022チームの皆様、CADDiの皆様、3ヶ月間ありがとうございました！
ここまでお読みいただきありがとうございました。キャディにご興味のある方は、お気軽に求人ページからカジュアル面談をお申し込みください。また、各種エンジニア向けイベントも随時開催しています。こちらもぜひご覧ください。
