この記事は、AIエージェント時代のSES・受託開発について書いた記事を、自分なりの流れで並べたインデックスです。
AIを使うこと自体を否定したいわけではありません。
むしろ、AIはかなり使えると思っています。
ただ、SESや受託開発、多重下請けの現場では、AIだけでは解けない問題もあるように見えています。
前提情報、判断権限、仕事の出し方、分担の仕方によって、AIの効き方が大きく変わるのではないか、という話を整理しています。
はじめに
AIエージェントを使うと、実装そのものはかなり速くなります。
コードを書いてもらう。
エラーを直してもらう。
テストを追加してもらう。
変更内容を整理してもらう。
そういう作業は、かなり任せやすくなってきました。
ただ、SESや受託開発の現場で考えると、話は少し複雑になります。
コードを書く前の前提がそろっていない。
誰が判断するのか分からない。
背景が伝わっていない。
機能ごとに人が分かれていて、全体の流れを見にくい。
現場担当者に責任はあるのに、変える権限はない。
こういう状態だと、AIを入れても、思ったほど開発がうまくならないことがあるのではないかと感じています。
この記事は、そのあたりを考えた記事をまとめたページです。
単なるリンク集というより、AIエージェントをSES・受託開発の現場で使うときに、どこが詰まりやすいのか を整理するためのインデックスとして書いています。
目次
この連載では、AIエージェント時代のSES・受託開発を、だいたい次の流れで見ています。
| 回 | テーマ | 含めている話 |
|---|---|---|
| 第1回 | AIだけでは開発はうまくならない | SES・多重下請けで前提情報が分断される問題 |
| 第2回 | ヒアリングミスはどこまで救えるのか | 聞けていないことはAIにも分からないという話 |
| 第3回 | 共通ルールだけでは足りない | プロンプトやAIへの頼み方をそろえる難しさ |
| 第4回 | 機能ごとの分担とAIの相性 | 局所最適や前提のコンフリクトが起きやすい話 |
| 第5回 | 仕事を出す側が背景を渡せるか | 作るものだけでなく、判断基準も渡すという話 |
| 第6回 | 判断権限のない現場 | AIの提案を活かすには、誰が決めるのかが効いてくる話 |
| 第7回 | AIを使う前にそろえたい前提 | 業務フロー、用語、データ、変更範囲を残す話 |
| 第8回 | AIを入れても改善しにくい現場 | AI利用が逆に現場の弱さを見えやすくする話 |
最初は、AIエージェントを現場に入れれば、実装はかなり楽になると思っていました。
それ自体は間違っていないと思います。
ただ、考えていくうちに、SESや受託開発では「AIをどう使うか」だけではなく、AIに何を渡せる状態になっているか の方が効いてくるように見えてきました。
AIエージェント時代のSES・受託開発を考える
第1回：SESや多重下請けの現場では、AIだけでは開発はうまくならない
AIエージェントを使えば、自社プロダクトのように前提情報を集めやすい環境では、かなり開発を進めやすくなります。
一方で、SESや多重下請けの現場では、前提情報が分断されやすくなります。
仕様の背景、業務の流れ、判断基準、顧客との合意、変更してよい範囲。
こういう情報が現場の開発者まで届いていないと、AIに聞いても、AIは正しい判断をしにくくなります。
この連載の出発点として、AIだけではなく、現場構造そのものを見る必要があるのではないか、という話です。
第2回：AIはヒアリングミスをどこまで救えるのか
AIは、情報を整理したり、抜けていそうな観点を出したりするのが得意です。
ただし、そもそも聞けていないことは、AIにも分かりません。
間違った前提を渡せば、AIはその前提の上で、それらしい答えを出してしまいます。
ヒアリングミスは、実装ミスよりも見つけにくいことがあります。
この記事では、AIが助けられる範囲と、AIだけでは埋めにくい前提のズレについて整理しています。
第3回：共通ルールだけじゃだめなんだ...
AIをチームで使うなら、共通ルールやプロンプトを用意すれば揃うように見えます。
ただ、同じルールを見ていても、人によってAIへの頼み方は変わります。
何を省略するのか。
どこまで任せるのか。
どこで止めるのか。
どういう出力を良いと見るのか。
そこには、その人の仕事の進め方や感覚が出ます。
この記事では、共通ルールだけでAIの出力を揃える難しさと、揃えるなら話し方よりも境界や責任範囲を見た方がよいのではないか、という話をしています。
第4回：機能ごとに人を割り振ると、AIの強みが消えるのではないか
機能ごとに人を割り振るやり方は、管理しやすく見えます。
ただ、AIエージェントは、本来もう少し横断的に考えられます。
業務フロー、データの流れ、画面間のつながり、状態遷移、影響範囲。
こういうものを見ながら実装できるのが、AIの強みのひとつだと思っています。
それを細かい機能単位で分断すると、各担当者のAIが局所最適で動いてしまい、あとから前提のコンフリクトが表に出ることがあります。
この記事では、AI時代の分担は、機能単位だけでなく業務フローやインターフェース単位で考えた方がよいのではないか、という話をしています。
第5回：仕事を出す側が背景を渡せないと、AIも判断できない
AIに任せるなら、作るものだけではなく、背景も渡した方がよさそうです。
なぜその機能が必要なのか。
誰が使うのか。
どこまで変えてよいのか。
何が未決なのか。
どの判断基準を優先するのか。
こういう情報がないと、AIは推測で進めることになります。
この記事では、仕事を出す側が「作ってほしいもの」だけでなく、「判断に使う背景」も渡せる状態にしておくことが、AI時代にはより大事になるのではないか、という話をしています。
第6回：判断権限のない現場で、AIの提案はどこまで活かせるのか
AIは、ときどき良い改善案を出してくれます。
でも、現場担当者がその案を採用できるとは限りません。
責任はある。
でも、変更する権限はない。
SESや受託開発の現場では、こういう状態が起きやすいと感じています。
この記事では、AIの提案を「案」として扱うこと、判断者を明確にすること、権限がないなら変更範囲を狭めることなど、AIの提案を現場でどう扱うかを考えています。
第7回：SES現場でAIを使う前に揃えたい前提
AIに渡す前提が、AIの出力をかなり左右します。
業務フロー。
用語定義。
データの正。
状態遷移。
変更してよい範囲。
変更してはいけない範囲。
未決事項。
確認者。
こういうものが残っていると、AIはかなり使いやすくなります。
この記事では、SES現場でAIを使う前に、最低限そろえておきたい前提を整理しています。
第8回：AIを入れても改善しにくい現場の特徴
AIを入れても、改善しにくい現場はあります。
質問できない。
判断者が分からない。
背景が出てこない。
権限がない。
人だけ増える。
レビューできる人がいない。
AI利用が「早く作れ」の圧力になる。
こういう状態では、AIが便利であるほど、現場の弱い部分が見えやすくなることがあります。
この記事では、AIを入れる前に見ておきたい現場の特徴を整理しています。
おわりに
AIエージェントは、SESや受託開発でもかなり使えると思っています。
ただ、AIを入れれば自動的に現場がよくなる、というほど単純でもない気がしています。
AIが力を出すには、前提が必要です。
何を作るのか。
なぜ作るのか。
誰が決めるのか。
どこまで変えてよいのか。
どこから先は確認が必要なのか。
そういう情報が渡せないままだと、AIはそれらしく進めてしまいます。
だから、AI時代のSES・受託開発では、AIの使い方だけではなく、仕事の渡し方、判断の残し方、権限の置き方も一緒に見ていく必要があるのだと思います。
まだ整理中ですが、今の自分にはそんなふうに見えています。