「ベンダーを変えたのに、同じ問題が起きた」
受注側として15年間、日本企業の開発案件を回してきました。その中で何度も繰り返し聞いてきた話があります。
「ベンダーを変えてみたんだけど、なぜか同じところで止まるんだよね」
前のチームが使えなかったから変えた。でも結果は変わらない。「オフショアは使いづらい」という結論になりかけている——そういうパターンです。
正直に言うと、これを受注側から見ると、かなりの場合「ベンダーの問題ではない」んですよね。
批判じゃないんです。受注側にいるからこそ見える角度があって、その角度から見たときに「あ、ここが詰まっているな」と見えるものが、発注側の体制の中にあることが多い。
今日は、その話をしようと思います。
AIは「整った環境」でしか速く走れない
AI-nativeな開発チームが入ると何が変わるか——これは以前の記事で書きました。「AIが競合になった時代に、オフショアの価値はどこにあるか」という話です。
今回は逆側の話です。優れたAI-nativeなチームが入ったとして、それでも成果が出にくい状況がある。その原因が、受注側ではなく発注側の体制にあることが、思った以上に多いんですよね。
AIは「整った環境が好き」なんです。曖昧な仕様、バラバラなデータ、遅い意思決定——こういう状態だと、どれだけ優秀なAI-nativeチームも、その力を半分も引き出せない。結局、人間の判断と職人技に頼る部分が増えていく。
あるとき、全社でこういう言い方をしました。
「プロジェクトでヒーローが必要な状態になっているということは、仕組みがまだ十分に強くないということだ」
発注側の体制が整っていない状態だと、受注側も「ヒーロー頼み」になるしかない。仕組みで動けない環境に置かれているから。
AI投資もマーケティングも同じで、基盤が整っていない状態で「使う側だけ」を変えても、結果は変わりにくい。順番があるんですよね。
発注側の「AI-ready」を見分ける5つの問い
ここからが本題です。
受注側から見て「この発注体制ならAIが最大限に動く」と感じる状態と、「これだと難しい」と感じる状態。その差を5つの問いにまとめました。自社の体制確認にも、発注先を選ぶときの基準にも使えると思います。
5つ全部に「◯」が付く発注側は、正直ほぼいません。1〜2個でも明確に◯があれば上出来で、全部△の状態でAI活用を始める案件も珍しくない。それ自体がダメというわけじゃなくて、「今どこにいるか」を把握してから始めるかどうかの差が、3ヶ月後に大きく効いてくるんですよね。
問い1：仕様を「言語化」できるか
曖昧な仕様は、人間のエンジニア相手でもプロジェクトを壊します。AIが入ると、その問題がより顕著になる。
人間のエンジニアは経験と文脈から「たぶんこういうことだろう」と補完できます。AIはその補完の精度が低く、特に日本語の曖昧な指示（「いい感じに」「前回と同じように」「Aさんに確認して」）で誤りやすい。
確認のポイント：
- 「誰が、どういう場面で、何をしたいか」が1文で書けるか
- 「これができたらOK」という受入条件が定義されているか
- 仕様書や指示の中に「いい感じに」「前回と同じ感じで」が出てくるか（出てくるなら要注意）
完璧な仕様書を最初から書けというわけじゃないんです。ただ、「渡す前に一度だけ言語化してみる」という習慣があるかどうかで、AIの動きやすさが変わります。
問い2：データが「AIが触れる状態」にあるか
「データはあります」と「AIが使える状態にある」は、全く別の話なんですよね。
Excelが何十個もあって、それぞれ形式が違う。紙でしか残っていない情報がある。「あの担当者の頭の中にある」データがある。こういう状態だと、AIが素材として使える情報がそもそもない。
確認のポイント：
- AI活用に使うデータが一か所にあるか、あるいはアクセスできる状態か
- 日付・単位・名前の表記など、形式が統一されているか
- 「あとで整理する予定」のデータが案件の核心部分にないか
完璧に整える必要はなくて、「AI活用を始める前に、使うデータだけでも整理する」一工程を入れるかどうかの話です。
問い3：意思決定が「AIのペース」に合えるか
AIで作業が速くなっても、意思決定が遅ければ全体のスピードは変わりません。
例えば、AIを使えばプロトタイプを1日で出せるようになったとします。でも「確認してOKをもらうまで次に進めない」フローがあれば、「確認待ち2週間」はそのまま残る。むしろ、高速で出せるようになったプロトタイプが積み上がっていく状態になります。
確認のポイント：
- レビューの承認者と期限が最初から決まっているか
- 「確認してみます」のまま止まりやすいフローになっていないか
- 小さい判断を現場に委ねられているか（全部上に上がると遅くなる）
意思決定のスピードそのものを変えるのは難しいです。ただ「誰が、いつまでに、どんな判断をするか」が最初から決まっているかどうかは、仕組みで変えられる。
問い4：アウトプットに対する責任が「誰かに帰属している」か
これが一番見落とされやすいと感じています。
AIが出したコードは誰がレビューするか。AIが提案した設計は誰が確認するか。何か問題が起きたとき、誰がどう判断するか。
ツール導入より先に責任構造と判断基準を設計しなければ、どんなツールも3ヶ月で形骸化する——というのが、何十件もプロジェクトを見てきた実感です。
確認のポイント：
- AIのアウトプットを確認・承認できる担当者がいるか
- AIが間違えたとき（必ず間違えます）の対処法が決まっているか
- 「AIがやったから」が免責になる文化になっていないか
受注側がどれだけしっかりしていても、発注側の責任構造が曖昧だと「誰も確認していなかった」という問題が必ず出ます。これは受注側には防ぎようがない。
問い5：失敗を「次につなげる仕組み」があるか
AI活用で最も残念なパターンが、「試して、うまくいかなくて、終わる」です。
AIはまだ発展途上で、最初からうまくいくことのほうが少ない。重要なのは、失敗をデータとして扱えるかどうかです。「なぜうまくいかなかったか」が記録されて、次の判断に使われる状態になっているか。
確認のポイント：
- うまくいかなかったことを「担当者の問題」にしない文化があるか
- 失敗の原因が記録されて、次のプロジェクトで参照できるか
- 「次はこうする」が組織として共有されているか
AI時代に強い組織は、失敗が速くて安い組織だと思うんですよね。小さく試して、早く学んで、次に活かす。その循環を仕組みとして持てているかどうかです。
グレーが残ったら、一緒に見ます
5つの問いを見て、全部クリアだという発注側はほぼいないと思います。
1〜2個は明確に◯があるけど残りはグレー、という状態が現実的には一番多い。それで問題ないんですよね。ただ、「今どこにいるか」を把握せずに動くのと、把握してから動くのとでは、3ヶ月後の着地が変わります。
僕は15年間、受注側から発注側の体制を見てきました。「どこが整っていて、どこが足を引っ張っているか」は、一度話すだけでだいたい見えます。
グレーが残っている部分があれば、15分の壁打ちで一緒に確認しませんか。売り込みではなく、現状の整理として使ってください。
原田 祥吾Shogo Harada
代表取締役 · 株式会社リノエッジ
東京とベトナムの二拠点で、ITオフショア開発・海外進出支援事業を展開。「気合いより仕組み」を信条に、不透明になりがちな越境ビジネスを構造化する経営者。「個人のスキル」ではなく「再現性のある品質」を組織と顧客へ提供することにコミットしています。
よくある質問
AI開発を外注するとき、発注側が最初に準備すべきことは？
この記事の5つの問いを順番に確認することをお勧めします。特に「問い1（仕様の言語化）」と「問い4（責任の帰属）」は、多くの案件で最初のボトルネックになります。完璧に整えてから始める必要はなく、今どこにいるかを把握してから動くことが大切です。
AIを使う開発会社を選ぶとき、何を見ればいいですか？
受注側の能力と同じくらい、「自社の体制と合っているか」を見ることをお勧めします。どれだけ優れたAI-nativeチームも、発注側の意思決定が遅かったりデータが整っていなかったりすると力を発揮しにくい。AI-native開発チームに何ができるかを知った上で、5つの問いで自社の状態を確認するのが、ベンダー選びの前にやるべきことだと思います。
5つの問いのどこから手をつければいいですか？
どれか一つだけ選ぶなら「問い4（責任の帰属）」です。責任が曖昧な状態だと、他の4つがどれだけ整っていても成果に繋がりにくい。「AIが出したアウトプットを誰がどう確認するか」を最初に決めるだけで、プロジェクトの動き方が変わります。それが決まったら、他の問いに順番に取り組んでいくのが現実的です。気になる点があれば、15分の壁打ちで一緒に整理しましょう。