クラウドサイン事業本部でエンジニアをしている比嘉（@teitei_tk）です。好きな AI はFate/EXTRA CCC の BB です。
現在、弁護士ドットコムでは AI の導入・検証を進めており、さまざまな AI を利用しています。
- フロントエンドエンジニアが Cursor を使ってバックエンド開発にキャッチアップしている話
- エンジニアは Deep Research をどう活かせるか
- 生成 AI と SaaS をつなぐ! Claude MCP 活用の実践
私はその一環で、ChatGPT Pro プランを利用しています。
IT 業界でエンジニアが生成 AI を使うとなったとき、真っ先に思い浮かぶのはコーディングへの活用でしょう。しかし、エンジニアの仕事はコーディングだけではありません。今回、私がエンジニアリーダーを務めているチームに新しいメンバーをお迎えすることになり、その受け入れ準備に AI を活用することを考えました。
この記事では ChatGPT Pro の o1 pro に支えてもらいつつ、メンバーをどのように受け入れたのかを振り返ります。
オンボーディング準備
会社で利用しているサービスのアカウント類はエンジニアリングマネージャーが準備を進めていたので、私の方はオンボーディングに集中できました。ここではオンボーディングのために何を準備したのかを書きます。
ドキュメントの用意
最初は o1 pro を使わず、過去にフリーランスとして活動していた際に何が欲しかったかを思い出しながらドキュメントを整備しました。その中で欲しかったのは迷ったとき・悩んだときに何を見たらいいかでした。それを踏まえて迷ったらこのドキュメントに戻ることで前に進めることを意識しています。
用語集
クラウドサインでは独自のユビキタス言語があります。それらすべてを網羅することは難しいですが、今後のプロジェクトで頻繁に出るであろうものをピックアップし、用語集としてまとめました。
Jira チケットの運用ルール
クラウドサインでは SOC2 に対応するためチケットの運用ルールが決まっています。これらは Google ドキュメントにまとめられていますが、チケットの変更ルールが複雑で一度に理解をするのが難しいです。それらを解決する手段として Figjam を利用して可視化しました。
スクラムイベント・ミーティング の運用ルール
クラウドサインではスクラムを採用しています。私のチームもスクラムで回しており複雑なことはありませんが、基本的な運用のルールを明文化しました。
例えばファシリテーター・議事録役はローテーションで回している。レトロスペクティヴはスプリントの終わりに行うなどです。
その他のミーティングのことについても記述しています。対して特別なことはありませんが、私のチームを含めた一部のチームでは 5 分前の終了を意識していること（30 分ミーティングであれば 25 分に終わる）を書いています。
環境構築資料
エンジニアのオンボーディング資料
新しく参画するエンジニアのオンボーディングとしてクラウドサインのローカル開発環境を構築し、実際に開発プロセスを体験する資料がすでにあるのでそちらを共有しました。
その上で、開発を進めるうえで躓きそうな点や、私のチームで利用している VSCode DevContainer のセットアップ手順もあわせて載せています。
簡単なアーキテクチャ図
サービス規模が非常に大きいためすべてを紹介することは難しいのですが、簡易的なアーキテクチャ図を作成しました。とはいえ、全体を網羅した資料は存在せず、たとえ作成しても覚えることも容易ではありません。そこで、最初の学習コストや認知負荷を下げるために、必要最小限の情報だけを FigJam を使ってまとめています。
オンボーディングの実施と工夫した点
入社して 1 ヶ月ほどは月・水・金で 1on1 を行う
参画当初はわからないことが多いだろうと考え、教育と立ち上がりのサポートを目的に、月・水・金の頻度で 1on1 を進めました。
1on1 の内容に関しては o1 pro に相談をしました。進捗・タスク状況の確認から技術的に詰まっていることがないかのヒアリングなど当たり前のことが多かったです。
一点、「参画当初は信頼関係ができておらず遠慮をする可能性があるから、こちらから困りごとや不足資料を尋ねると良い」 という提案があり、この視点は持ち合わせておらず感心させられました。
1 ヶ月ほど経つと理解できる部分が増え、質問も減少したため、徐々に 1on1 の頻度を下げました。
簡単なオンボーディングタスクを用意する
いきなりプロジェクトに参画し、コードを書いてもらう方法もありますが、まずはクラウドサインのコードベースに慣れてもらうことを優先し、いくつか簡単なタスクを用意しました。
直近の期待値を設定する
私がフリーランスとして活動していた際、困ったことの 1 つが「期待値がわからない」という状況でした。そこで「今週はここまで」「来週はここまで」と目標を細かく区切り、期待値をすり合わせることにしました。
プロジェクトやコードに関することだけでなく、メンバーの名前・顔・役割の一致や、開発に必要となるアカウントの準備、時間があれば読んでおいてほしいコードなどをタスクとして明文化しました。
具体的には、以下のような内容を期待値として設定しています。
今週
- 環境構築を完了させる
- オンボーディング資料を確認する
- クラウドサインのローカル環境を触ってみる
- 外部公開している API を利用して操作する
- クラウドサイン特有の用語を覚える
- メンバーの名前を覚える
- スクラム関連の基本を理解する
- ローカル・ステージング環境でアカウントを準備する
- （ざっくりで構わないので）アーキテクチャ図を把握する
- モブプロに参加してコードを書いてみる
- 時間があれば
- 後述するオンボーディングタスクに取り組む
- ソースコードを読む
来週
- （先週のタスクが終わっていなければ）それを完了させる
- オンボーディングタスクを完了させる
- （ざっくりで OK）AWS 構成図を把握する
- プロジェクトの DesignDoc を読む
- 時間があれば
- ソースコードを読む
生成系 AI の利用ルール
生成系 AI が当たり前に使われる時代ですが、社内で利用するにあたってはルールを設けています。 たとえば、業務上の機密情報を入力してはいけないことや、GitHub Copilot を個人アカウントで使うのは NG など、注意事項を明確に伝えています。
o1 pro に聞いて改善した点
上記のようにオンボーディング計画を立てましたが、何か改善点がないかを o1 pro に聞いてみました。以下が o1 pro のレスポンスを一部抜粋したものです。
1. 全体像の共有
アーキテクチャ概要・コンテキストの説明
まずは、バックエンド・フロントエンドがどのような役割を果たしているのか、どんなコンポーネントが存在するのか、といったシステム構成の全体像をざっくり説明すると良いです。
- 絵に描いた図（アーキテクチャ図やデータフロー図など）を見せながら口頭で補足する。
- 全体の役割分担や、利用技術（フレームワーク・インフラ構成など）についてひと通り話す。
- これまでの経緯や大事な観点の共有
- 「なぜこの設計方針になったのか」「どの部分が特に重要か」などのドキュメントには書かれない背景情報を先に伝えておくことで、コードを読む際の理解が深まります。
2. コードキャッチアップ施策
- 巨大なコードベースを俯瞰できるようガイドを用意
- 「どのディレクトリが何の役割か」「主要クラス・関数はどこにあるか」を示すドキュメントづくり。
- コードリーディングが得意とのことなので、閲覧すべき PR 履歴や実装例を整理
- レビュー時に注目すべきポイントをピックアップし、“どこを見れば理解が深まるか”を明示。
- 小さめのタスクやバグ修正をアサイン
- 実際にコードを触ってもらう → PR → レビューでフィードバック、の流れを回す。
3. 質問・相談しやすい環境づくり
- “小さなことでも質問 OK”という姿勢を繰り返し言葉と行動で示す
- 「そんなこともわからないのか」的な言い方は厳禁。
- 質問されたら「聞いてくれて助かる」などポジティブに返す。
- 質問の導線やフォーマットを明確化
- どのチャネルで聞けばいいか、最低限どんな情報を添えると回答しやすいかを伝えておく。
- 定期的な声掛けやモブプロで“相談しやすい雰囲気”を実体験させる
- 一度「相談 → 解決 → 感謝」の流れを体験すると、以後も質問が起きやすくなる
感想
o1 pro に支えてもらいつつ進めました。確かに「こういう視点もあるのか」と思わされる場面もありましたが、オンボーディング準備という点では少しオーバースペックに感じました。 試しに o1 にも同じ質問を投げてみましたが、大きな違いはなかったです。
ただ、o1 と相談しながら進められたのは非常に助かりました。一方 GPT-4o だと的外れな回答や、想定内の範囲にとどまる答えが多かったです。
弁護士ドットコムでは、AI を活用してやっていきたい人を募集しています。
