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