🤖

新メンバーの私がCLAUDE.md/AGENTS.mdの整備を担当してよかった3つの理由

に公開

新メンバーの私がCLAUDE.md/AGENTS.mdの整備を担当してよかった3つの理由

はじめに

新しい会社にジョインして、最初にちょっと圧倒されました。

私がいま働いているのは、コスメの口コミアプリ「LIPS」を運営する会社です。LIPSは月間数百万人規模のユーザーに使われており、コスメのレビュー投稿、レビューや商品の検索、ランキング、レコメンド、AI診断など、ユーザーのコスメ選びに関するあらゆる体験を設計しています。

9年間運用されてきたメインのRailsリポジトリでは、DBのテーブルが900個。フロントエンドのNextもモリモリで別リポジトリ。そして、iOSとAndroidのネイティブアプリ。大きくて複雑なプロジェクトに、即戦力として期待されている。

「どうすれば早く貢献できるだろう?」

いままでだったら、夜な夜なコードリーディングをしてこっそりキャッチアップして、オンボーディングタスクを爆速でこなすというやり方もあったかもしれません。

ですが、いまはAIがあるので、AIを使って効率よくドメイン知識を高めていき、中期的なスパンでの技術の向上と組織として再現性がある方法でオンボーディング期間を過ごそうと考えました。

ありがたいことに業務時間の1-2割の時間を使ってAIを使った開発環境の整備をすることにOKをもらえたので、やってみることにしました。

この記事では、既存メンバーではなく、新メンバーがClaudeやCursorなどのAIエージェントの整備、特にCLAUDE.md、AGENTS.md、Project Rulesなどシステムプロンプトの整備を担当することのメリットについて書いていきます。

やってよかった3つの理由

1. フレッシュな視点を活かせる

プロジェクトでの経験が長くなってくるとAIエージェントへのプロンプト作成も上手になってきて、タスクに応じて「この実装は〇〇を参考にして」などと無意識のうちにAIエージェントにコンテキストを与えることができるようになってきます。

しかし、プロジェクトに入ったばかりでドメイン知識がまったくない状態ではそれが難しいため、AIエージェントも不十分なコードを生成しがちです。

そこで、新メンバーだからこそのゼロからの視線で、CLAUDE.md、AGENTS.md、Project Rulesなどにプロジェクト固有の実装ルールを記載していくと、全体の開発効率も上がっていきます。

「じゃあ具体的に何を書けばいいの?」という疑問には、シンプルな答えがあります。

AIが一発で生成できなかったプロジェクト固有の理由によるコードを書けばいいと考えています。

具体的には、以下の3つです。

  1. プロジェクト独自のルール
  2. 同じような修正指示を繰り返してやっと書いてくれた実装
  3. AIが気付かなかった関連箇所で揃えるべき実装

詳しくは以下の記事をご覧ください。

https://zenn.dev/appbrew/articles/e2f38677f6a0ce

https://zenn.dev/appbrew/articles/7eb12fff5738f4

暗黙知やあいまいなことを明文化することは既存メンバーにもよろこばれるので、自分の行動が価値を生んでいるという手応えが得られます。

2. チームのルール作りに関われる

AIエージェントを使った開発では、出力するコードの量よりも、どの実装方針がいいの迷いが多ければ多いほど時間がかかるように感じています。

開発しながら「このパターンとあのパターン、どっちがいいんだろう?」と疑問に思ったら、それをCLAUDE.md/AGENTS.md/Project Rulesに推奨パターン、非推奨パターンとして書いていきます。

ちゃんと明文化することで、「いま複数の実装があるのですが、こっちのやり方を推奨にしませんか?」と、チーム全員に対して提案しやすくなります。

ちなみに、ここではチームで合意が取れる範囲で、自分がよいと思う開発スタイルを「推奨パターン」として提案できるのもメリットです😊

いい提案ができたときに、「非推奨のパターンはこの際書き換えましょう!」ってベテランメンバーに言われたときは、共通理解を作ることができた気がしてうれしかったです。

3. AI駆動開発が得意と評価される

そこまですごいことをやってなくても、AIを使った開発を積極的に実践している人としてまわりから評価されるようになります。

AIエージェント関連の整備は成果がドキュメントとして残り、他のメンバーがすぐに恩恵を受けられるため、貢献が可視化されやすいです。

いきなり「AIが得意な人」というポジションを確立できるのは、新メンバーにとって自信につながります。

とても大切な前提

ただし、新メンバーにAIエージェント関連ドキュメントの整備をお願いする側には、とても大切な前提があります。

それは、AIを使った開発環境の整備を「雑用」として扱わず、コードの実装以上の価値のある貢献として評価する。そうした文化がなければ、新メンバーは「意味あるのかな...」と感じてしまいます。

また、「AIがここのコードを〇〇さんの記述通りに一発で出してきたよ!」のような、ポジティブなフィードバックをもらえたりするとうれしいです。

まとめ

もし新しいチームで「まず何から貢献しよう?」と迷っているなら、AIエージェントの整備は小さく始められて効果が大きいと思います。今後の技術的な成長の投資にも、自分の居場所づくりにも役立つはずです。

AppBrew

Discussion