AI活用における「現場のベテラン」への期待

• 本項はAIを使ってタイポ補正していますが、原文には魂を込めてます。

はじめに

• 本稿は8分程度で読めると思います。
• エンタープライズのSI現場にて、AI活用にむけた「現場のベテラン」人材の活用に関する記事です。
  • 業務アプリのデリバリに責任をもち、他者をリード／指導の経験のある方をイメージしています。
• 「現場のベテラン」に技術好きな若手と一緒に、SI現場でのAI活用をしていって欲しいと考えて書きました。
• 注意：著者はclineを使う都合、cline活用に寄っているかもしれません。

「現場のベテラン」の言語能力はAIに活かせる

「現場のベテラン」で以下のような経験をされている方はいませんか？

• コミュニケーションツール黎明期にExcelのQA票を交換しながら開発をリード
• 拘りの強いメンバーへの諭し／説得（ただし感情論ではなくてロジカルに）
• 若手への教育・指導を「やってみせ」のレベル感で実施

(AIエージェントではなくて)
LLMを使い始めて私が思ったのは「今までのことが活かせる」でした。

見も蓋もないですが「AIエージェント」は「LLM」で駆動します。
「大規模言語モデル（＝LLM）」というだけのことはあり「言葉」で駆動します。
よって「言語化」が上手い人がLLMをより活用できると考えています。

• 出した指示が粗ければ、厳密にする／例を書く(→few-shot)
• 出した手順が粗ければブレイクダウンする(→CoT)

これまで真摯に「人間相手」にしてきた経験はLLM利用において武器になると思います。

「現場のベテラン」の「プロジェクトの歩き方」をAIエージェントに入れてほしい

「現場のベテラン」は新メンバーの受け入れを任されたことはないでしょうか？
新メンバーはドキュメントやナレッジがどこにあるか分からないので、以下のようなことを指導したと思います。

• オンボーディング資料(の目次)はこれです
• ここのフォルダにこれが入っているので、基礎知識として必ず見てほしい
• ⚫︎⚫︎をやるとき（担当する人は）これを見てほしい

このように「ユースケース別」「アクター別」で資料を案内したり、
資料同士のつながりがわかりやすいように工夫してきた経験が、
そのままAIエージェントにも活きます。
AIエージェントもルールとして「目次」を与えてやることで、探索能力があがります。

• 探索能力が高まり「壁打ち」の使い心地が向上する
• 「必殺のプロンプト」を用いて「一気に生成」だけでなく、「探索的な逐次生成」の精度も高まる

ドキュメントなどの「目次構成」は「いわゆる社内標準」でもいいかもしれません。
しかし、現場に個別最適化された「目次」の作成は「現場のベテラン」が適しています。
「開発ユースケース」を理解しているのは現場ですので。

「現場のベテラン」は「構成管理が大事」と気づくかもしれない

「目次」を整理する中で「現場のベテラン」は以下のことに気づくかもしれません。

• やはり構成管理が大事ではないか？
  • リポジトリ構成/フォルダ構成/文章体系/ブランチ戦略、等

共通部品のパッケージ(フォルダ構成)の例ですが

• 業務開発(Dev)チームが直接利用する部品
• 提供部品内で、内部的に使うInternalな部品。本来直接利用を想定しない
  上記の部品でパッケージが同じであるとします。

以下例
※ SPA のフォルダ構成にはさまざまな流派がありますが、本稿の趣旨ではないため雰囲気だけ掴んでいただければ大丈夫です。趣旨としては「設計書のフォルダ構成」にも言えることです。

悪い例（Dev と Internal が同じ階層）

components/
├─ Button/
│   ├─ Button.vue
│   ├─ Button.test.ts
│   └─ index.ts
├─ Formatter/
│   ├─ formatDate.ts        ← Dev が使う部品
│   ├─ formatCurrency.ts    ← Dev が使う部品
│   ├─ internalUtil.ts      ← 本来 Internal（直接使わせたくない）
│   └─ index.ts
└─ validator.ts              ← Dev は直接触らない想定

良い例（Internal を明確に分離）

components/
├─ public/                   ← Dev が使う公開 API / 部品
│   ├─ Formatter/
│   │   ├─ formatDate.ts
│   │   ├─ formatCurrency.ts
│   │   └─ index.ts
│   └─ Button/
│       ├─ Button.vue
│       ├─ Button.test.ts
│       └─ index.ts
└─ internal/                 ← AI にも Dev にも使わせたくない部品
    ├─ Formatter/
    │   ├─ internalUtil.ts
    │   └─ helperLogic.ts
    └─ validator.ts

AIエージェントは、フォルダ構成や命名から「どう使われる部品か」を推測します。
その構造が曖昧だと、意図と違う部品を選んでしまう可能性があります。
これは AI だけではなく「まだ行間が読めない新規参画者や開発者」でも同じです。
これを回避するためにはフォルダ構造の目次に部品ごとの補足説明が必要になります。

一方で、構成管理の筋が良いと、AIエージェントに任せられる部分が増え、
目次の準備や補足説明も軽くなります。

状況が許すなら、構成管理の見直しはおすすめです。

「現場のベテラン」は「基本が大事」と気づくかもしれない

AIエージェントの活用を考えると「構成管理以外」にも「システム開発の基本」が大事と気づきます。
「これまででやってよかったこと」「やっておけばよかったこと」が生きてくる場面が多くでてきます。

• 属人化を防ぐ工夫
• 地雷をよける工夫（経験）
• 複数の開発ソリューションを導入して整合性を取った工夫

こういう「地に足のついた経験／判断」が、AI時代でもなお現場を支える力だと感じています。

「現場のベテラン」にAIエージェントを使って欲しい理由

これは個人的な経験に基づく話ですが、
40代以降になると、身体的にも作業量は減ってきます。

• 長時間のコーディングが体力的に厳しくなる
• 集中力が持つ時間が減る
• 新規技術キャッチアップの速度が落ちる（特にこれが厳しい。これに使える時間が減る）

ただ、その一方で長く現場にいる分、

• 判断の基準
• 「なぜそうするのか」の背景
• 落とし穴の勘どころ

みたいな 「経験値から来る勘」のような部分は確実に積み上がっています。
是非「勘」で終わらせずに言語化してほしいです。

もちろん、その経験の中には「昔のままアップデートされていないプラクティス」が気づかないうちに混ざっていることもあります。

だからこそ、AIエージェントを使うことで、
技術好きの若手の視点や今どきのプラクティスと自分の知見を突き合わせる
という動きができると考えています。
なぜなら生成結果が全てなので。そこにベテランも若手もありません。

• ベテランが持っている仮説や判断基準をAIに渡す。
• 若手にもそれを見てもらって使ってもらう。
• その過程で、お互いの考え方がアップデートされる

そんな コラボレーションの道具としてのAIエージェント が使えると
ドキュメントなどの知財だけでなく、人にも残せると考えています。
私も体力のあるうちに若手と一緒に知財を作って、それを若手に残したいと考えています。

おわりに

本記事で伝えたかったのは次の4点です。

• ベテランはAIエージェントと相性が良い
• ベテランの“歩き方”を目次化してAIに渡すと効果が出やすい
• AI時代こそ「構成管理・言語化・基本の徹底」が重要
• 若手とベテランの知見をAIが橋渡ししてくれる

AIエージェントは、
「若手の新しいプラクティス」と
「ベテランの経験値」を
うまく混ぜ合わせてくれる道具だと思っています。

ベテランと若手はロールが違うかもしれませんが、
結局は同じ目標をもって現場開発をやっているので、
この記事がどこかで一つでも参考になれば嬉しいです。