契約前に確認する項目:好意的な提案ほど急いで条件を返さない
相手が好意的な提案をしてきた段階で条件を積んで返すと、うまくいっている関係の温度を落とすことがある。自社の共同開発案件を材料に、契約前に確認すべき項目とその聞き方を整理する。
6 / 75 ページ
相手が好意的な提案をしてきた段階で条件を積んで返すと、うまくいっている関係の温度を落とすことがある。自社の共同開発案件を材料に、契約前に確認すべき項目とその聞き方を整理する。
見積書の「進行管理」欄が小さいからといって、PM工数がかかっていないとは限らない。自社の受託経験と公開参考価格をもとに、見積の読み方と発注側が聞くべき質問を整理する。
AI開発の支援会社を選ぶとき、提案書の体裁や実績件数だけでは分からないことがある。実装物を触れるか、実測を標本数つきで出しているかという2つの確認軸を、自社の開示例をもとに整理する。
AI導入後の運用は、動かし続けることより「壊れたことに気づく」ことに工数がかかる。実行時にAIを呼ばない構成であっても、気づく仕組みは別に用意しなければならない。
最初に見えた良い数字ほど疑ってよい。自社の検証記録では、事前に条件を登録したうえで新しい標本で追試したところ、当初+11.0ptだった改善がlift 0.0まで消えた。この設計が採用の誤りを防いだ。
AIツールが使われなくなる原因は性能ではないことが多い。価値が成立した瞬間に壁を置いていないか、利用データだけで人を判断していないか。自社が判断として採っている2つの線引きを書く。
既存の紙・帳票・データベースにAIをつなぐとき、時間がかかるのは読み取りそのものではない。書式の違いを吸収し、項目の定義を確かめる工程が本体になる。
AIが変えるのは業務のうち一部の工程だけである。導入前にその工程の時間を測っておかないと、導入後に「速くなった気がする」以上のことが言えなくなる。
PoCが終わらず延長され続ける経路と、健全に「作らない」と結論して終える経路がある。自社がゲーム開発向けの検証で下した判断の中身と、その根拠を整理する。
自社が新規プロダクトの技術選定で作り直しになった実例と、複数プロダクトを同時に進めて止まった実例から、内製を選ぶ判断が成立する条件を整理する。