Rustエンジニアの参画初月にやること｜現場で信頼される進め方

Rustエンジニアの参画初月は、ビルドと開発環境を手元で再現し、発注側がRustを選んだ理由とコードの決まりをつかみ、小さな変更をいくつか通したうえで、月末に「気づいた危うさと改善の見立て」を出すところまでを目標にします。最初の1か月で求められるのは大きな機能を作ることより、このチームの書き方で、安心してRustを任せられると発注側が判断できる材料を示すことです。

参画前の契約・環境の準備は参画が決まってから開始日までにやること、職種を問わない最初の1週間は参画初日から最初の1週間でやることで解説しています。この記事では、Rustならではの初月の動き方に絞ります。

初月のゴールを3つに分ける

この3つを、1週目、2週目、3〜4週目の順に重心を移しながら進めます。

1週目：ビルドを通し、コードの全体像をつかむ

開発環境とツールチェーンを確かめる

Rustの現場では、最初のつまずきの多くが環境です。まず次の点を確かめます。

• 使うRustの版：rustupの公式ドキュメントでは、rust-toolchain.tomlに使うツールチェーン、追加の部品、追加のターゲットを書き、リポジトリに含めて管理できると説明されています。このファイルがあるかどうか、何が書かれているかを最初に見ます
• 対応する最低の版：Cargoの公式ドキュメントでは、Cargo.tomlのrust-versionに対応する最低のRustの版を書くと、それより古い版でビルドしたときにエラーとして知らせると説明されています。設定されていれば、更新の方針を読み取る手がかりになります
• エディション：公式のエディションガイドでは、エディションはクレートごとにCargo.tomlで選ぶと説明されています。ワークスペースの中でエディションが混在していないかも見ておきます
• 自動の点検：Clippyやrustfmt、テストが自動の仕組みでどう回っているか、どの警告を失敗として扱うか

手元でビルドとテストが通るまでに手順書と違う点があれば、メモにして共有します。次に入る人の役に立ち、チームへの最初の貢献にもなります。

ワークスペースの構成を地図にする

クレートの分け方、依存の向き、外部との境界（データベース、他言語、ネットワーク）を一枚の図にします。読みながら、「ここはunsafeがある」「ここは他言語から呼ばれる」といった注意点を書き込んでおきます。この段階では良し悪しを判断せず、仮説としてためておきます。

2週目：決まりを確かめ、小さな変更を通す

コードの決まりを関係者に聞く

既存のコードから読み取れる決まりと、明文化された決まりを突き合わせます。聞いておきたいのは次の点です。

1. Rustを選んだ理由：速さ、メモリ安全性、配りやすさなど。理由によって、レビューで重く見られる点が変わる
2. エラー処理の方針：ライブラリと実行ファイルでエラーの型をどう分けているか、panicをどこで許すか
3. unsafeの決まり：使ってよい場所、レビューの手順、前提の残し方
4. 依存クレートの追加：誰の承認が要るか、ライセンスや保守の状況をどう確かめるか
5. 非同期処理の構成：使っているランタイムと、重い処理の扱い方

小さな変更を通す

テストの追加、Clippyの警告の解消、小さな不具合の修正など、範囲の狭い変更から通します。プルリクエストの説明には、何を変えたか、なぜその書き方にしたかを短く書きます。リモートの案件では、この文章がそのまま評価の材料になります。リモートでの進め方はRustエンジニアのリモートの記事でも触れています。

3〜4週目：担当の範囲を広げ、見立てを出す

担当の機能を一つ持つ

決まりに慣れてきたら、範囲のはっきりした機能や部品を一つ担当します。設計の段階で、データの持ち方やエラーの返し方を短く書いてレビューを受けてから実装に入ると、後の手戻りを減らせます。

危うさと改善の見立てをまとめる

1か月の間に気づいたことを、次の形でまとめます。

• ビルドや環境づくりで時間を取られている点
• unsafeや他言語との境界で、前提が残っていない箇所
• 依存クレートやツールチェーンの更新が止まっている箇所
• 計測されていない性能の前提

それぞれに、影響、取れる手、優先度の案を添えます。直すかどうか、いつ直すかを決めるのは発注側です。見立ては提案として出し、選んでもらう形にします。

案件の型によって初月の重心は変わる

C/C++からの置き換えの案件

既存のコードとビルドの仕組みを読むことに、初月の多くの時間を使います。境界の層で誰がメモリを確保・解放するか、エラーをどう伝えるかを、既存のチームと文書で確かめておくことが中心になります。

Webサービスのバックエンドの案件

本番の監視とログの見方、障害対応の手順を早めに確かめます。障害対応の待機に入るかどうかと、その扱いも初月のうちに窓口と確かめておきます。

組込みの案件

実機と検証の環境に慣れることが最優先です。機器の扱いの決まり、測定器を使う検証の場所と手順、no_stdの制約の中で使ってよいクレートを確かめます。

Rustを導入したばかりの案件

Rustに詳しい人がチームに少ない場合、レビューや方針づくりを期待されることがあります。その場合も、方針は案として出し、発注側に決めてもらう形を守ります。どこまでを自分の業務とするかは、早めに窓口と確かめてください。

初月に避けたい動き

範囲外の依頼が増えてきたときの扱いは作業範囲が広がったときの記事、Rustエンジニアがつまずきやすい場面はRustエンジニアのフリーランスがつまずきやすい点と対策で整理しています。

1か月の終わりに振り返ること

1か月が過ぎたら、次の点を自分で振り返ります。

• ビルド、テスト、点検の仕組みを、手順書なしで回せるようになったか
• Rustを選んだ理由と、コードの決まりを説明できるか
• 自分の変更が、大きな手戻りなくレビューを通るようになったか
• 危うさと改善の見立てを、発注側に伝えられたか
• 契約で決めた業務の範囲と、実際に担っている仕事がずれていないか
• 稼働時間の記録が残っているか

ずれている点があれば、2か月目の早い段階で窓口と話しておきます。

よくある質問

手順書どおりにやってもビルドが通りません。どうすればよいですか？

まずは、使っているRustの版と、rust-toolchain.tomlやrust-versionの設定を確かめます。それでも通らない場合は、試したことと出たエラーをまとめて、早めにチームに質問してください。手順書の抜けが見つかれば、直した内容を共有することでチームへの貢献にもなります。

既存のコードにunsafeが多く、危うく見えます。指摘してよいですか？

指摘してかまいませんが、初月は「ここに前提が残っていない」「ここはテストがない」のように事実と影響を示し、直すかどうかは発注側に選んでもらう形が安全です。理由があってそう書かれていることもあるため、まず経緯を尋ねることから始めてください。

初月から大きな機能を任されました。どう進めればよいですか？

設計の段階で、データの持ち方、エラーの返し方、他の部品との境界を短く書いてレビューを受けてから実装に入ると、チームの決まりとのずれを早めに直せます。分からない決まりは、推測で進めずに確かめてください。