社内AIツール開発を依頼する前に決めること — SaaSで足りない業務を小さく作る方法

社内AIツール開発を依頼する前に決めることは、まず「SaaSで足りない部分」を1つに絞ることである

社内AIツールや業務アプリの開発を依頼する前に決めるべきことは、要件を全部洗い出すことではない。まず「今使っているSaaSやスプレッドシートで、具体的に何ができていないか」を1つだけ言語化することである。forCreatorsでは自社の業務改善でスプレッドシート管理からポータル化を進めた際、最初に決めたのは全体設計ではなく「どの承認フローが毎回止まっているか」という1点だった。範囲を絞らずに発注すると、要件定義だけで数週間が過ぎ、開発が始まる前に予算と気力が尽きる。SaaSで足りない業務は複数あるはずだが、最初の1本は必ず1業務に絞る。それが、依頼前に決めるべき最も重要な事項である。

発注前に決めるべきことは4つある

社内AIツール開発を外部に依頼する前に、担当者が自分の言葉で答えられるべき項目は次の4つである。

1. 対象業務：どの業務の、どの工程を対象にするか（例：受注データの入力ではなく、入力後の承認待ち状態の可視化）
2. 現在のデータの置き場所：スプレッドシート、SaaSのDB、紙、メールのどれに情報があるか
3. 使う人：現場担当者だけか、管理職の承認も含むか
4. 「うまくいった」と言える状態：数字ではなく、誰が何をしなくてよくなるか

この4つが曖昧なまま発注すると、開発会社側も要件を推測で埋めるしかなくなる。逆にこの4つさえ決まっていれば、見積もりも試作の方向性も具体的に議論できる。forCreatorsが社内ポータルを自作した際も、最初に固めたのはデザインではなくこの4項目だった（スプレッドシート管理をやめて、社内ポータルを自作するまで）。

要件定義は「困っている業務」から逆算するべきである

要件定義は、理想の機能一覧から始めるのではなく、今困っている業務から逆算して作るべきである。理由は単純で、理想から作ると機能が膨らみ続け、開発期間も予算も際限なく伸びるからである。forCreatorsの社内ポータルも、最初から全部門の情報を集約する設計にはしなかった。まず「今週の制作進行が誰にも見えていない」という1つの困りごとに対して、進行状況だけを表示する画面を作った。困りごとから逆算すると、必要な機能は自然と3〜5個程度に収まる。これより多い場合は、対象業務の範囲がまだ広すぎる可能性が高い。

小さく作って育てる進め方が失敗を減らす

社内AIツールは、最初から完成形を目指すより、小さく作って現場で使いながら育てる方が失敗しにくい。理由は、実際に使ってみないと「本当に必要な機能」と「あると思っていたが使わない機能」の区別がつかないからである。forCreatorsでは社内ポータルを一度に作り切るのではなく、最初のバージョンは限られた業務だけを対象にし、現場からのフィードバックを受けて機能を追加する形で運用してきた（SaaSに頼らず、社内ポータルを自作した話）。最初の設計に使わない機能が含まれていたことも実際にあり、その部分は早い段階で削った。小さく作ることは、開発コストを抑えるためだけでなく、無駄な機能を作らないための手段でもある。

SaaSと内製、どちらを選ぶかは業務の「個別性」で判断する

SaaSを使うか内製で作るかは、対象業務が自社特有の運用ルールに強く依存しているかどうかで判断するべきである。

判断軸	SaaS導入が向く	内製・社内ツールが向く
業務の型	業界標準の業務フローに近い	自社独自のルールや承認フローがある
変更頻度	運用ルールがあまり変わらない	現場の運用に合わせて頻繁に変える
データの分散	1つのSaaS内で完結する	複数のツール・スプレッドシートに分散している
求める柔軟性	標準機能で十分	表示や権限を細かく調整したい

この表で右側に当てはまる業務ほど、SaaSでは「惜しいがそのままでは使えない」状態になりやすい。その隙間を埋めるのが、小さく作る社内AIツールの役割である。

依頼前の準備が整えば、次は小さな試作から相談できる

社内AIツールの開発を依頼する前に、対象業務・データの所在・使う人・成功の状態の4つを自分の言葉で説明できるようにしておくことが、発注後の手戻りを防ぐ最も確実な方法である。forCreatorsでは、こうした要件整理から小さな試作、実際の運用に乗せるところまでを一緒に進める相談を受けている。まずは自社のどの業務がSaaSで足りていないのか、話しながら整理したい場合は「社内AIツールの作り方を相談する」から連絡してほしい。