アンチパターン1:ドメイン、タスク、リソースの関係性を把握できていない
AIプロジェクトには、コンピューティングリソースや人的リソースが大量に必要になることがある。そのためデータのドメイン、対応するタスクの種類、そして必要なリソースの関係性を正確に把握しておくことが肝要だ。
データには、エクセルのような構造化データや画像のような非構造データが存在し、これらのデータタイプはプロジェクトによって異なるリソースを要求する。またAIが解決すべきタスクは多岐にわたり、分類や回帰といった基本的なタスクから、専門的な知識を必要とするより複雑なタスクまで多様である。
構造化データを扱う場合は比較的少ないコンピューティングリソースで済むが、非構造化データ、特に3次元データなどを扱う場合は、小規模なAIモデルであっても膨大なリソースが必要となることがある。
人的リソースに関しても、基本的なタスクではそれほど多くのリソースが必要ではないが、複雑なタスクになると相応のリソースが必要になる。したがって、プロジェクトを受注する前に、見積もりを慎重に行い、プロジェクトの規模や要求に対して適切なリソースを確保できるかを確認することが重要である。
アンチパターン2: 契約形態を準委任契約ではなく、請負契約にしてしまう
これは、特に起業したばかりのAIベンダーや、大手企業とベンチャー企業との間に力の差がある場合に見られる。
PoCは通常の開発と異なり、可能な限り性能を高めようと努力するものの、データ不足や期待値の調整が上手くいかず、性能目標を達成できないことがある。このような状況であっても契約上の性能達成は求められるため、AIベンダーは開発工数を削減されるリスクに直面する。
PoCの後の開発フェーズにおいては請負契約が適切な場合もあるが、PoCの段階では要注意である。請負型で契約を結ぶ必要がある場合は、リスクを受け入れる覚悟で案件に臨むべきだ。
アンチパターン3：過度なリップサービスによる失敗
このケースは、コミュニケーション能力が高いPMやリーダーがAIベンダーにいる場合によく見られる。小規模なPoCであっても、相手に良く思われたいという気持ちから、依頼側の要求に応える形で新機能を加えてしまい、開発の後半で困難に直面することになる。
要件定義の段階や新機能を加える余地がある時期には、特に注意が必要である。PoCが工数を要するものになりそうであれば、新たな見積もりを行い、追加発注を依頼することが望ましい。
アンチパターン4: PMが不在である
特に最近起業した学生ベンチャーなどで見られる。失敗の主な理由は、全体の進捗管理やデリバリー能力の不足にある。プログラミングができても、スケジュールを立てて開発を進めることができないのだ。受託開発はクライアントへの説明資料の作成なども必要とされる。実際のモデル作成やプログラミング作業は全体の一部に過ぎないのだ。
この問題を避けるためには、コンサルティング経験があるメンバーやPM経験があるメンバーを、外部からでも早期にチームに加えることが重要である。このメンバーにプログラミングスキルは必ずしも求められない。
アンチパターン:5解決方法を不必要に複雑にする
この問題は、技術力に自信があるテック企業に特に多い。複雑な技術の組み合わせにより、運用工数が増大し、結果的にAIの性能向上が困難になるケースである。具体的には、複数のAIモデルを組み合わせることで性能向上が期待できるものの、再現性が低下するリ スクがある。
PoCの初期段階では、多少の複雑性が許容されるかもしれないが、時間が経つにつれて、作成者でさえも再現が困難になるほどの複雑度になることがある。AIモデルの作成者は、運用時の管理工数や再現性を考慮に入れ、できるだけシンプルなモデルで性能改善を目指すべきである。
成功への道は、失敗をしないことが基本条件であり、成功を定義する条件によって異なる。生成AIが中心となる時代でも、ここで紹介したアンチパターンは存在し続けるであろう。
上記のようなアンチパターンを避けることが、成功に向けての第一歩になる。
「LLMが変えたPoC。今や企業は容易に実現可能性を図ることができるようになった」も読む
