AI時代の開発パートナー選び：見るべきは「技術力」より“設計する力”

生成AIの普及で、実装そのものの速度は確実に上がりました。要件が固まっていて、作るものが明確なら、コードを書く時間はどんどん短くなる。これは歓迎すべき変化です。

一方で、受託開発の現場を長く見てきた立場（※受託／開発会社を25年以上経営してきた社長という想定）として、はっきり言えることがあります。

実装が速くなるほど、失敗の原因は「技術力不足」ではなく“設計不足”に収束していく——ということです。
• 何を作らないか（作らない機能・後回しにする機能を決められるか）
• どこで検証するか（早い段階で間違いに気づく仕組みがあるか）
• 変更に耐える構造にするか（変化が前提の現実に合わせた設計か）

この3つが弱いと、AIで実装が速くなった分だけ「間違ったもの」を高速で積み上げ、後半で大爆発します。
逆にここが強いパートナーは、技術スタックが多少違っても、結果としてコストも納期も品質も安定します。

この記事では、開発会社を選ぶときに“技術スタックより先に見るべき”、設計の粒度をチェックリスト化し、面談で聞くべき質問例まで落とし込みます。

なぜ今、「技術力」だけでは差がつきにくいのか

AI時代、実装力の価値が下がった――と言うと語弊があります。正確にはこうです。
• 「書ける／作れる」ことが差別化になりにくくなった
• 「正しいものを選び、正しい順序で、正しく確かめる」ことが差別化になる

受託開発の失敗は昔から、だいたい次のどれかでした。\

1. 要件が曖昧なまま走る\
2. 途中で前提が変わる（変わるのが普通）\
3. 仕様変更で構造が破綻する\
4. 品質が後追いになり、手戻りが爆増する
   
   生成AIは(4)の「単純な実装」を加速しますが、(1)(2)(3)はむしろ悪化し得ます。
   なぜなら、作るスピードが上がるほど“意思決定の誤り”が大きな損失になるからです。

AI時代に価値が跳ねる「設計する力」とは

ここで言う“設計”は、画面やDBやクラス設計だけを指しません。もっと上流から下流までの「粒度」を行き来する能力です。

私はこれを、ざっくり3つに分けて見ています。

1) 要件の翻訳力（ビジネス言語 → 開発言語）

• 「売上を上げたい」「工数を減らしたい」を
ユーザー行動・業務フロー・データに落とす力
• 曖昧な希望を、検証可能な仮説に変換する力

2) 意思決定の型（決め方が再現可能か）

• 「誰が」「何を根拠に」「いつ」決めるか
• 決めないことを決める（保留の扱い、前提の管理）

3) リスクの見立て（危ないところから潰す）

• 技術リスクだけではなく、運用・法務・セキュリティ・組織まで含めた見立て
• “検証ポイントの設計”＝どこで失敗を小さくするか

この3つが揃うと、結果として「変更に耐える構造」も自然に整っていきます。

開発パートナー選び：技術スタックより先に見るチェックリスト

以下は、発注側が「面談」「提案書」「初期ワーク（PoC/要件定義/設計）」で確認できるように、観察可能な形にしたチェック項目です。
（チェックが多いほど良い、ではなく“自社に必要な項目が満たされているか”を見てください）

A. 要件の翻訳力チェック（曖昧さを扱えるか）

• ビジネス目的を「ユーザーの行動」まで落として説明できる
• 「機能」ではなく「成果（アウトカム）」を先に確認する質問が出る
• “用語の定義”を揃える動きがある（言葉のズレを放置しない）
• 仕様の前に、現状業務・制約（規程、権限、例外）を聞いてくる
• 「要件＝全部実装」ではなく、優先順位を付ける会話ができる

提出物・アウトプットで見抜く
• ユーザーストーリー / 業務フロー図 / 画面遷移（粗くていい）
• 用語集（グロッサリー）
• 仮説と検証項目の一覧（何を確かめるかが書かれているか）

B. 意思決定の型チェック（決め方が強い会社はブレない）

• 重要な判断に「判断軸（コスト/リスク/将来変更/運用）」が明示される
• 「前提」「未決事項」「決定事項」を分けて管理する提案がある
• 仕様変更の扱い（変更管理）が最初から設計されている
• “決める会議”と“共有する会議”が混ざっていない
• 迷ったときのエスカレーション（誰に、いつ、何を持って）が定義される

見抜きポイント
• 「大丈夫です、できます」よりも、選択肢とトレードオフが出るか
• 「決めないと進まない点」を、先にリストアップしてくるか

C. リスクの見立てチェック（危ない順に潰せるか）

• 早期に「失敗しそうなポイント」を挙げる（耳が痛いことを言える）
• 技術以外（運用・監査・法務・個人情報・権限）に触れる
• リスクに対する「検証計画」がある（やる/やらないではなく、どう確かめるか）
• “最初の一発”を大きくせず、小さく検証→拡張の提案がある
• 外部連携・データ移行・権限設計などの地雷を先に質問してくる

典型的な地雷例
• 権限が複雑（部署、役職、担当、代理…）
• データの正が複数（Excel、基幹、SaaS）
• 運用の担当が不在（作って終わりになりやすい）
• 既存業務が例外だらけ（現場ヒアリングなしで破綻）

D. 「どこで検証するか」チェック（後半で爆発しない会社）

• 最初に“検証ポイント”を置く（プロトタイプ、ユーザーテスト、データ検証など）
• PoCの目的が「作ること」ではなく「意思決定すること」になっている
• 仮説→検証→学び→次の意思決定、のループが設計されている
• 受け入れ基準（Doneの定義）が明確
• テスト戦略（自動/手動、どこを厚くするか）が説明できる

E. 変更に耐える構造チェック（“未来の変更”を前提にしているか）

• 変更が起きそうな箇所を先に特定している（価格体系、権限、連携先など）
• データ設計に「将来の拡張余地」がある（固定化しすぎない）
• 依存関係を減らす方針（疎結合、モジュール分割、境界）が語れる
• 運用・監視・ログ・障害対応を“後で考える”にしない
• 「作りやすさ」より「直しやすさ」を優先する場面がある

ここが強い会社は、言い換えると
"リリース後の現実（変更と運用）を知っている会社”です。

面談で聞くべき質問例（質問で「設計の粒度」が露出する）

以下は、面談でそのまま使える質問です。
ポイントは、答えの内容より「考え方の構造」が返ってくるかです。

1) 要件の翻訳力を測る質問

Q.「このプロジェクトの成功を、どう定義しますか？」
• 良い兆候：KPI/利用シーン/業務の変化に落とす質問が返る
• 危険信号：機能一覧や画面数の話から始まる

Q.「“作らない候補”を最初に挙げるなら何ですか？」
• 良い兆候：MVP設計、段階導入、優先順位の型が出る
• 危険信号：全部必要です、全部できます、から入る

Q.「要件が曖昧な状態で始める場合、最初の2週間で何をしますか？」
• 良い兆候：ヒアリング→仮説→検証→意思決定の順がある
• 危険信号：とりあえず画面を作ります、の一点張り

2) 意思決定の型を測る質問

Q.「仕様変更が入った時、どう扱いますか？」
• 良い兆候：影響範囲、優先順位、コスト/納期、意思決定者の整理
• 危険信号：柔軟に対応します（＝ルールがない）

Q.「重要な設計判断は、何を根拠に残しますか？」
• 良い兆候：ADR（意思決定記録）や議事録、前提管理
• 危険信号：担当が覚えてます、口頭で共有します

3) リスクの見立てを測る質問

Q.「今回の案件で“最初に潰すべきリスク”は何だと思いますか？」
• 良い兆候：複数のリスクを優先順で挙げ、検証方法まで言う
• 危険信号：特にありません／やってみないと分からない

Q.「失敗したプロジェクトの典型パターンと、予防策を教えてください」
• 良い兆候：痛い話を具体的に語れ、仕組みに落としている
• 危険信号：失敗はありません／うちは優秀なので

4) 検証設計を測る質問

Q.「どのタイミングで、誰が、何を見て“進める/やめる”を判断しますか？」
• 良い兆候：ゲート設計（Go/No-Go）と必要材料が明確
• 危険信号：最後まで走って完成させます、だけ

Q.「受け入れテスト（UAT）の設計は誰がどうやりますか？」
• 良い兆候：発注側の役割も含めて設計する
• 危険信号：納品したらあとはお願いします（丸投げ）

“小さな初期ワーク”で見抜く：おすすめの見極め方

面談だけで判断しきれない場合、私は発注側にこう提案します。

2〜5営業日程度の有償ワーク（設計スプリント）を実施する

見るべき成果物は、完成した画面ではありません。むしろ次のようなものです。
• 目的・前提・制約の整理（1枚でいい）
• 作る／作らないの境界線（MVP案）
• 主要な業務フロー or ユーザージャーニー
• リスク一覧と、検証計画
• おおまかなアーキテクチャ方針（詳細不要、境界が分かる程度）

ここで“設計の粒度”が見えます。
粒度が合う会社は、短い期間でも「判断が進む」感覚があります。

生成AIの使い方も確認する（スピードとガバナンスの両立）

AI活用は今や前提ですが、発注側が見るべきは「使ってるか」ではなく「統制できてるか」です。

面談での確認例：
• 「生成AIは、どの工程で使いますか？（要件/設計/実装/テスト/ドキュメント）」
• 「機密情報・個人情報の取り扱いは？入力しないルールは？」
• 「AIが出したコードのレビュー方針は？責任の所在は？」
• 「プロンプトや設計判断は、再現可能な形で残しますか？」

“速く作る”は手段で、“安全に運用できる”が目的です。
ここを取り違えると、リリース後に事故が起きます。

最後に：AI時代のパートナーは「設計で未来のコストを減らす」

発注側が本当に買っているのは、コードではありません。
意思決定の質と、手戻りを減らす設計です。
• 技術スタックは後から変えられる
• でも、意思決定の型と設計の粒度は、途中で矯正しづらい
• そしてAI時代は、実装が速い分だけ「間違い」も速い

だからこそ、開発会社選びで見るべきは「技術力」よりも、“設計する力”。
具体的には、要件の翻訳力／意思決定の型／リスクの見立てです。

この記事のチェックリストと質問例を、ぜひ次の面談でそのまま使ってみてください。
返ってくる答えの中に、あなたのプロジェクトを守る“設計の粒度”が確実に現れます。