はじめに
こんにちは。タイミー プロダクトエンジニアの津守です。今年1月にタイミーに入社し、気づけば早3ヶ月が経ちました。
この記事では、入社して数ヶ月働いて感じた「AIツールがオンボーディングプロセスをどう変えたか」という体験をまとめます。技術的な深掘りというより、新しい環境に飛び込んだエンジニアの個人的な気づきとして読んでもらえると嬉しいです。
従来のオンボーディングプロセスのイメージ
新しい会社に入ったとき、多くのエンジニアは最初の数週間を
ドキュメントを読む。コードベースを読む。アーキテクチャを把握する。チームの開発スタイルを理解する。そして、ある程度理解できたと感じてから、ようやく手を動かし始める。
というような順序で過ごしてきたと思います。
言ってみれば「インプット先行」の学習スタイルです。この期間は"情報を受け取る期間"と暗黙的に認識されていることが多く、アウトプットは後回しになりがちでした。チームへの貢献よりも、まず「追いつくこと」が優先されるイメージです。
AI活用によって感じた変化
入社して最も強く感じたのは、この「順序」が変わったということです。
AIツールを使うことで、コードベースへの理解が浅い段階でも、まず動くものを作ることが現実的になりました。実際Cursor や Claude Code を主体に実装を進めると、知識のギャップをAIがある程度埋めてくれます。おかげで、入社初期からチームメンバーやステークホルダーのレビューやフィードバックを素早く受け取ることができました。
実際、チームメンバーやステークホルダーからのフィードバックやレビューには、基礎的な知識だけでなく、「タイミーではこうやってる」といった暗黙のコンテキストが含まれており、ドキュメントから得られる知識に加えて、より多くの背景情報を得られる場面があります。
開発アプローチとして広く受け入れられているアジャイルでは、「いかに早くステークホルダーがレビューできる状態を作るか」が重要な論点のひとつです。これは、個人が環境に適応するうえでも重要な要件だと思います。完璧な理解を待ってから動くのではなく、まず動くものを見せてフィードバックをもらう。そのサイクルを素早く回すことが、結果的に最も効率的な学習を生み出し、属する組織で求められる行動を起こせるようになるために重要と考えています。
適切に学習サイクルが回るための条件
ただ、このアウトプット先行の学習サイクルが機能するには、2つの環境が整っている必要があると感じました。どちらもAIツールの登場で新たに生まれた課題ではなく、組織の開発体験として元々重要だったものですが、AIツールの発達によってその重要性はさらに増しています。
1. AIが適切なアウトプットを出せる環境
AIが出すアウトプットの質は与えるコンテキストに大きく左右されます。学習サイクルの中でフィードバックを通じて暗黙のコンテキストを受け取れるとはいえ、そもそも明示的に言語化されているほうが望ましく、AIのアウトプットの精度も上がります。
実際、タイミーではバックエンド開発Handbookを通じて、開発プロセスを明示的に言語化する動きがあります。設計・実装・運用にまたがるガイドラインが体系的にまとめられており、さらにそれがAIエージェントのスキルとして提供されています（詳しくは新谷さんの記事「バックエンド開発Handbookを届けるために ― AI時代の知の高速道路を敷く」をご覧ください）。
Handbookが生まれた背景のひとつには、メンバーの増加やAIツールの進化により、バックエンド以外のエンジニアが越境してコードを書く機会が増えたという事情があります。ただ実際に使ってみて感じたのは、暗黙知をまだ何も持っていない入社直後のメンバーにこそ、そのインパクトが大きいということです。「そもそも何を知らないかもわからない」状態でも、AIがHandbookに沿ったアウトプットを出してくれることは、単なる品質担保以上の意味を持ちます。
自分がHandbookを意識していなくても、AIがガイドラインに沿った設計や実装を提案してくれる——「気づいたらタイミー流の書き方になっていた」という感覚は、入社して間もない時期にとても心強いものでした。
2. フィードバックをもらえる環境・体制
もうひとつの前提条件は、フィードバックの環境です。どんなに早くアウトプットを出しても、適切なフィードバックが返ってこなければ学習サイクルは止まります。
この3ヶ月間は、チームメンバーやステークホルダーから丁寧なフィードバックをもらえる環境にあり、そのおかげで学習が加速しました。特に、PRベースのコードレビューは厳密に行われており、そこでの指摘やディスカッションがとても多くの学びになりました。
ただ、3ヶ月を通じて感じたのは、現状ではフィードバックの質が運用や状況によってばらつきが出やすい状態にあるということです。体制として担保されているというよりは、チームメンバーの意識や余裕に左右される面があり、持続的に機能させるには仕組みとしての設計が必要だと感じています。
もうひとつ、AIがアウトプットを加速させることで生まれるトレードオフも見えてきました。学ぶ側が早く動けるようになった分、レビューする側が見るべきPRの量も増えます。学習サイクルが速くなった恩恵が、レビュワーの負荷という形で偏在してしまうわけです。
また、PRベースのレビューは厳密に行われている一方で、暗黙知やコンテキストを深く共有したうえでのフィードバックを、どう生み出すかという問いも残ります。これらに対してモブプログラミングやペアプログラミングのような形式は有効な解のひとつだと思っていて、後からまとめてレビューするコストを分散させながら、よりリッチなフィードバックを生みやすい構造だと感じています。
持続的に相互フィードバックが行われる開発体制をどう設計するか——これはまだ答えの出ていない問いですが、AIが学習サイクルを高速化させるほど、フィードバックを循環させる体制の重要性は増していくと感じています。
おわりに
3ヶ月を振り返ると、AIは入社直後の学習の「量」を変えたのではなく、「順序」を変えた、というのが一番しっくりくる表現です。
以前なら「理解してから作る」だったものが、「作りながら理解する」に変わりました。この変化は、入社直後という時期をより能動的に過ごす後押しをしてくれると感じています。
ただし、そのサイクルを本当に機能させるには、AIが適切なアウトプットを出せる環境と、フィードバックを届ける体制という、人間側の設計が不可欠だと感じました。Handbookをはじめとした環境を整えてくれたチームには、改めて感謝しています。
同じように新しい環境に飛び込んでいる方や、新しいメンバーを迎える立場の方に、少しでも参考になれば嬉しいです。
