はじめに
2026年上期を振り返ると、AIを使用してできるようになったことは増えました。
ただ、できるようになった先に、それぞれ別の難しさが現れています。本記事では、5つの場面について「できるようになったこと」と「まだ難しいこと」を対にして整理します。
| 場面 | できるようになったこと | まだ難しいこと |
|---|---|---|
| Agent Skill | 単独で動作するSkillを作る | リポジトリに適合するAgentに整備する |
| イシュー起票 | AIでGitLabにイシューを切る | 良いサイズと区切りで分解する |
| 優先度とMVP | 価値を高めるイシューを切り、優先度を定める | 開発体力を見ながら適切なMVPに切り出す |
| 開発フロー | イシュー駆動のフローを整備する | 従来フローからの移行を終える |
| ハンドオフ | 指示書を精度高く作る | 担当者に依頼し、任せ切る |
1. Agent Skill：書く力と読む力
単独で動作するSkillは作れるようになりました。しかし、それを特定のリポジトリに適合するAgentとして整備するのは難しいと感じています。
Skillを作るときに必要なのは書く力ですが、リポジトリに合わせるときに必要なのは読む力です。
そのリポジトリがなぜ今の構成や規約になっているのか、積み重なった判断を理解しなければ、Skillは動いても馴染みません。
2. イシュー分解：単位は単独のイシューでは決まらない
AIを使ってGitLabにイシューを切ることはできるようになりました。しかし、良いサイズと区切りで分解するのは難しいままです。
難しい理由は、分解の単位や制約条件が、単独のイシューの中では決まらないことだと捉えています。次のような複数の変数によって、適切な切り方が変わります。
- チームの開発力
- アサインできる状態にあるか
- 他のイシューとのコンフリクト
- 同時に進めると効率の良いものがあるか
つまり、同じ要求でも、チームと周辺の状況が変われば正しい分解は変わります。イシュー分解は、対象を切り分ける作業というより、その時点のチームの状態に合わせて解を求め直す作業です。
3. 優先度とMVP：MVPはユーザー目線だけでは決まらない
プロダクトの価値を高めるイシューを切り、優先度を定めることはできるようになりました。しかし、開発体力を見ながら適切なMVPに切り出すことは難しいです。
難しい理由は、イシュー分解と同じです。ユーザー目線でのMVPを定義できたとしても、次の変数によってMVPの単位が変わります。
- チームの開発力
- アサインできる状態にあるか
たとえば、開発リソースを他に回したい場合は、機能開発を行わず、FAQの整備のみをMVPと判断することもあります。
つまり、MVPはユーザーにとっての最小価値だけで決まるものではなく、その時点でチームが割けるリソースとの掛け合わせで決まります。
4. 開発フロー：作ることと手放してもらうこと
イシュー駆動の開発フローは整備できました。しかし、従来フローからの移行を終えることが難しいです。
新しいフローを作ることと、人が古いフローを手放すことは別の問題です。
従来フローが担当者に与えている安心や慣れを理解しないままでは、移行は終わりません。
5. ハンドオフ：伝えることと手放すこと
Agent Skillの指示書は精度高く作れるようになりました。しかし、それで担当者に依頼し、ハンドオフし切るのは難しいです。
指示書の精度は私自身の理解の深さであり、相手の理解ではありません。
任せ切るとは、相手が私とは違うやり方で進めることを許容することです。難しいのは伝えることよりも、手放すことでした。
5つに共通すること
こうして並べると、5つには共通点があります。
できるようになったことは、どれも自分の理解を外に出す能力です。難しいと感じていることは、どれも自分以外の文脈を理解する能力です。
具体的には、次のものがいずれも私の外側にあります。
- リポジトリの経緯
- チームの開発力とアサイン状況
- 他のイシューとの関係
- チームの実際の速度
- 従来フローに留まる人の事情
- 担当者の理解度
AIは前者を大きく伸ばしてくれましたが、後者はまだ伸ばせていません。今のところ後者は、予測して外すという経験から身につけるしかないと感じています。
後者を伸ばすAIの使い方があれば、ぜひ皆さんから教えを乞いたいです。
これから
イシューを切るとき、任せるときに、どこで詰まるかを先に予測し、結果と照らし合わせることを続けていきます。
作る力の次に磨くべきは、相手の文脈を見積もる力だと考えています。