「誰でも作れる」が売り文句になるとき
「AIを使えば誰でも作れます」。この言い方が売り文句になると、動くものと業務で使えるものの差が、宣伝と見積もりの段階で消えます。
「誰でも作れるようになった」という主張には、正しい部分があります。試作までの速度は実際に変わりました。問題は、速くなった区間と変わっていない区間が区別されずに語られることです。
型1 ― モードの違いを無視した「なんでも作れる」
支援AIの使い方は3つのモードに分かれ、モードによって必要なレビュー体制がまったく違います(表の第11章)。この区別が説明から落ちると、次の問題が生じます。
| 説明 | 省かれている前提 | 確認する質問 |
|---|---|---|
| 「開発期間が半分になります」 | どのモードで、何を任せた場合の話か | 入力補完・対話・エージェントのどれを想定していますか |
| 「レビューの負荷も下がります」 | エージェントモードではレビュー負荷は上がる | 変更の差分は誰がどう確認しますか |
| 「非エンジニアでも開発できます」 | 出力の妥当性を判断する知識は必要 | 出力が正しいかは誰が判断しますか |
| 「テストも自動生成されます」 | 意味のある条件を検証しているかは別問題 | 生成されたテストは何を検証していますか |
3行目が最も重要です。表の第11章で述べたとおり、AIは知っている人の作業を速くする道具であり、知らない人が知らないままで完成させられる道具ではありません。この点を踏まえない見積もりは、後半で必ず崩れます。
型2 ― プロンプトだけで完結するという誤解を利用した安価受注
「指示を書くだけで作れる」という前提に立つと、見積もりは小さくなります。この見積もりが通ると、次の順序で進みます。
- 短期間で動くものが完成する(この段階までは想定どおり)
- 既存システムとの接続、例外処理、権限の扱いで止まる
- 追加の情報提供と作業が必要になる
- 期間と費用が当初の想定を超える
- 範囲を狭めるか、品質を落とす選択になる
この経過は受注側の能力不足が原因とは限りません。見積もりの前提に、指示しなかった観点は出力に現れないという性質が織り込まれていないことが原因です。
見積もりを検証する質問
- 「異常系の処理、認証と権限、ログ、費用上限は見積もりに含まれていますか」 ― 表の第11章の8項目のうち、動作確認では現れない項目。
- 「当社の既存システムとの接続について、仕様書は必要ですか」 ― 必要と答える提案は、実態を把握しています。
- 「自前ロジック型とサービス連携型を分けて見積もっていますか」 ― 後者は相手側の仕様に依存するため時間がかかります。
2問目が有効です。「不要です」という回答は、既存システムの仕様を推測で扱う前提を意味します。もっともらしい間違いが混ざる領域です(表の第11章)。
型3 ― セキュリティと保守性の説明を省いた納品
動作確認では現れない品質は、納品の時点でも現れません。したがって受け入れ条件に明記されていなければ、実装されていなくても検収は通ります。
省かれやすい項目を、受け入れ条件のひな型として並べます。
| 項目 | 確認方法 | 入っていないと |
|---|---|---|
| 異常系の動作 | 通信断・想定外入力・二重実行を実際に起こして確認 | 本番で業務が止まる |
| 認証と権限 | 権限のない利用者で操作を試す | 公開できない状態で完成する |
| 設定の外部化 | 接続先や閾値をコード外から変更できるか | 変更ごとに開発が必要になる |
| ログの記録項目 | 入力・出力・モデル・費用・処理時間が残るか | 稼働後に原因を追えない |
| 設計資料と運用手順書 | 納品物として受け取る | 以後の変更を自社で行えない |
| 検証セットと回帰テスト | 納品物として受け取る | モデル更新ごとにベンダーに依頼 |
| 保守の範囲と費用 | 発注時に見積もる | 稼働直後に追加契約の交渉が始まる |
受け入れ条件が「正常に動作すること」と書かれている契約は、AI案件では判定に使えません。出力が毎回変わる前提では、単発の動作確認が合否の判断になりません。実データの件数と許容できる誤りの件数で定義してください。「実データ100件を処理し、人の修正が必要な件数が10件以下」であれば、双方が同じ基準で判定できます。加えて、検証に使う実データは発注側が用意します。ベンダーが用意したデータでの結果は受け入れ判定には使えません(表の網羅版 第14章「テスト・品質保証」)。
型4 ― 生産性の指標を都合よく選ぶ
AI支援の効果を示す指標の選び方で、結論が大きく変わります。表の第11章の対比を、確認の観点として並べ直します。
- コードの行数・機能数 ― 効果が過大に見えます。冗長なコードや使われない機能でも数値は上がります。
- 着手から動作までの時間 ― 速くなった区間だけを測っています。本番品質までの工程が含まれません。
- AI利用率 ― 手段の使用量であり、成果ではありません。
確認すべき指標は1つです。「稼働後に発生した障害件数と、修正にかかった時間」。この数値を出せない場合、生産性の主張は着手から動作までの区間だけを測っています。
型5 ― レガシー連携の難易度を伏せる
既存の古いシステムとの連携では、AI支援の効きが落ちます。理由は明確で、そのシステムの情報が公開されていないためです(表の第11章)。
この点が伏せられると、次のことが起きます。
- 一般的な構成を前提にしたコードが出てくる
- 動作確認の段階で不整合が判明する
- 仕様確認と疎通試験の工数が後から追加される
- 既存システム側の改修が必要になり、別部署との調整が発生する
確認は「連携先の仕様確認と疎通試験の工数は、どれだけ見込んでいますか」です。この工数を0または極小で見積もっている提案は、連携の実態を把握していません。
二年目の十二月、朝凪精機は受注入力の刷新について「工期は従来の半分」という提案を受けました。情報システム課の森が、伏字にした受注メール30通で開発支援AIを使って同じものを小さく試作すると、2日で画面が動き、得意先名・品番・数量・納期が埋まりました。ところが営業部業務課の課長に見せると、販売管理システムへの登録には得意先コードと出荷倉庫の区分が必要で、メールには書かれていないことが判明します。担当者の記憶と自作の早見表で埋めてきた項目でした。提案の見積もりには、連携部分の仕様確認と疎通試験の工数がどこにもありませんでした。発注の前に「連携先の仕様確認と疎通試験の工数」を問い、連携を別の範囲として見積もり直してもらうことにしたので、計画に含められる作業になりました。
この場面は網羅物語之巻 第9章「動くものと、使えるもの」に出てきます。
自社が発注側として先に決めること
この章の型の多くは、発注側の準備で防げます。所要は半日程度です。
- 受け入れ条件を件数で定義する ― 「実データ○件で修正必要が○件以下」。検証用の実データは自社で用意します。
- 動作確認では現れない7項目を受け入れ条件に入れる ― 前掲の表をひな型として使います。
- 納品物に設計資料・運用手順書・検証セットを含める ― 以後の変更と品質監視を自社で継続できます。
- 連携先の仕様書を先に用意する ― 提案の精度が上がり、見積もりの前提が揃います。
- 追加要望の窓口・判断者・費用の扱いを決める ― 変更管理として処理できるようになります。
- 保守の範囲と費用を発注時に見積もる ― 稼働後の交渉を避けます。
1番目と3番目が最も効きます。受け入れ条件が件数で定義され、検証セットが納品物に含まれていれば、稼働後の品質劣化も自社で検知できます(第14章)。