「AIかWebで社内の手作業を減らしたい。でも、どの開発会社に、何を基準に頼めばいいのか分からない」。中小企業の経営者や、情シス・業務改善を任された担当者から、よく聞く言葉です。検索すれば開発会社は無数に出てきて、どこも「できます」「実績多数」と書いてあります。だから会社名や実績数を並べても、絞り込めません。
先に結論を言います。数ある開発会社を見分けるコツは、「何を作るかを一緒に決められる相手か」と「作った後、自分たちで回し続けられる形にしてくれるか」の2点で見ることです。この2つを軸にすると、同じように見える会社が、意外とはっきり分かれます。この記事では、開発会社の3タイプ、頼む前に自社で決めておくこと、ブラックボックス化を避けるチェック項目、そして起こりがちな失敗の構造までを、依頼を受ける側ではなく「選ぶ側」の目線で整理します。
AI・Web開発会社は、大きく3タイプに分かれる
同じ「開発会社」でも、得意な関わり方は会社ごとにかなり違います。おおまかに3つに分けて、それぞれ向くケースと向かないケースを併記します。優劣ではなく、自社の状況との相性の話です。
受託請負型 ── 仕様を固めて渡すと、そのとおりに作って納品するタイプです。要件がはっきりしていて、作るものが決まっている案件に向きます。逆に、「何を作れば効果が出るか」がまだ曖昧な段階だと、仕様の詰めをこちらが全部負うことになり、ずれたものが出来上がりやすくなります。
SaaS導入代行型 ── 既存のツールやサービスを選定し、自社の業務に合わせて設定・連携してくれるタイプです。世の中にある製品で足りる業務なら、早く安く始められます。一方、自社特有の業務フローに合わせにくい、月額費用が積み上がる、ツールの仕様変更に振り回される、といった点は見ておく必要があります。
伴走・内製化型 ── 何を作るかの整理から一緒に入り、小さく作って試しながら、運用や改修を自社側でも回せる形を目指すタイプです。業務がまだ言語化しきれていない、作った後も自分たちで育てたい、という場合に向きます。逆に、丸ごと任せて完成品だけ受け取りたい、社内で手を動かす人を一切割けない、という場合には噛み合いにくいところがあります。
業務自動化を頼む前に、自社で決めておく3つのこと
どのタイプに頼むにしても、頼む前に自社で決めておくと、見積もりも成果もぶれにくくなります。逆にここが空白のまま相談に行くと、相手の提案に流されがちです。全部きれいに埋まっている必要はありませんが、少なくとも次の3つは意識しておきます。
- どの業務を自動化するか ── 「なんとなく全部効率化したい」ではなく、時間を食っている具体的な作業を1つか2つに絞ります。どの作業が重いかの見極めは、業務の棚卸しから始めると見えてきます(業務の棚卸しの進め方で手順を整理しています)。
- 誰が使うか ── 作ったものを日々操作するのは誰か。詳しい担当者一人だけが使う想定か、現場の全員が触るのか。使い手が変われば、必要な作りやすさも変わります。
- 成果をどう測るか ── 「楽になった気がする」で終わらせず、月何時間の作業が減ったか、ミスが減ったか、といった見える目安を先に決めておきます。ここが決まっていないと、作った後に「効果があったのか分からない」状態になります。
この3つは、開発会社に相談する前に社内で話しておくだけで、見積もりの精度も、出来上がりの納得感も変わってきます。
開発会社選びで見落としがちなチェック項目
会社の実績やデザインの見栄えは目に入りやすい一方、後から効いてくるのに見落とされがちな点があります。相談や見積もりの段階で、次を確認しておくと安心です。
- 見積もりの粒度 ── 「業務自動化システム一式」のような大きな括りではなく、何にいくらかかるのかが分解されているか。粒度が粗い見積もりは、後から追加費用が乗りやすい傾向があります。
- ブラックボックス化しないか ── 作ったものの中身や設定を、自社側でも把握できる形か。仕組みが完全に相手の頭の中だけにあると、その会社に頼み続けるしかなくなります。
- 改修のしやすさ ── 業務は変わります。小さな変更を、どのくらいの手間と費用で直せるのか。改修のたびに大きな見積もりが必要な作りは、運用段階でつらくなります。
- 保守費の中身 ── 月々の保守費に何が含まれるのか。障害対応だけなのか、軽微な変更まで含むのか。「保守費」の一言で片づけず、内訳を確認します。
これらは、相手の技術力そのものより「頼んだ後の付き合いやすさ」を左右します。作る段階より、作った後のほうが長いからです。
よくある失敗 ── 「丸投げして直せず放置」になる構造
業務自動化でつまずく典型は、技術的な失敗というより、進め方の構造から生まれます。
要件を詰めきらないまま「いい感じにお願いします」と丸投げする。開発会社は言われたとおりに一式を作って納品する。最初は動く。ところが数ヶ月して業務が少し変わると、自社では中身が分からないので直せない。相手に頼むと、そのたびに見積もりと待ち時間が発生する。だんだん面倒になり、結局そのシステムは使われなくなり、手作業に戻る ── これが「作ったのに放置」に至るよくある流れです。
原因は、作り手の腕以前に、「自社の業務を自社が一番よく分かっているのに、その知見をシステムに残す設計になっていなかった」ことにあります。丸投げは楽ですが、丸投げできる範囲は「変わらないもの」に限られます。業務のように動き続けるものは、育て続けられる形にしておかないと、いずれ現実とずれます(開発でつまずきやすい点はAI開発でよくある落とし穴にもまとめています)。
小さく始めて、社内に残す ── という選び方
ここまでを踏まえると、選び方の軸が見えてきます。いきなり大きなシステムを一式で発注するのではなく、時間を食っている作業を1つ選び、小さく作って効果を確かめる。そのうえで、うまくいったら広げる。そして、作った仕組みの中身と運用の知見が、少しずつ自社側にも残っていく。この進め方に付き合ってくれる相手かどうかを、選ぶ基準にするやり方です。
小さく始めれば、失敗しても傷が浅く、方向転換もしやすい。社内に知見が残れば、次の自動化は前より速く進みます。特定のツールや特定の会社に縛られにくくなるのも利点です。ZELKが法人向けの業務自動化・システム開発の相談で大事にしているのも、この「小さく試して、社内に残す」考え方です。どのタイプに頼むか迷う段階なら、一度、作れる立場の人に業務を見てもらうと当たりがつきやすくなります。開発を丸ごと任せたいのか、社内に伴走者を置きたいのかで、AI顧問という関わり方が合う場合もあります。
もちろん、この「伴走・内製化型」が全ての会社に最適というわけではありません。すでに仕様が固まっていて作るだけなら受託請負型が速いですし、既製ツールで足りるならそれを設定してもらうのが早い。自社がいまどの段階にいるかで、合う相手は変わります。
相談前に整理しておくとよいこと
最後に、開発会社に相談する前に手元でまとめておくと、話が早く進む点をチェックリストにします。全部埋まっていなくても問題ありません。埋まらない部分こそ、相手と一緒に整理する材料になります。
- 自動化したい業務の候補(時間を食っている作業を1〜2つ)
- その作業を日々やっている人・使う人は誰か
- 成果の目安(月何時間減らしたい、ミスを減らしたい など)
- 予算の目安と、いつまでに始めたいか
- 既存のツールやデータ(スプレッドシート、既存システムなど)
- どこまで任せ、どこは社内で持ちたいか(丸投げか、伴走か)
- 作った後の改修・保守を、誰がどう回すか
- 自社のデータや機密の扱いをどう確認するか
このリストは、そのまま相談時の質問にも使えます。見積もりの粒度、ブラックボックス化しない作りか、改修のしやすさ、保守費の内訳。これらに具体的に答えられる相手かどうかで、頼んだ後の付き合いやすさがかなり見えてきます。業務自動化は、大きく構えるより、小さく試して確かめながら広げるほうがつまずきにくい領域です。何を頼むか決めきれない段階でも、業務の棚卸しと優先順位づけから始められます。相談してから実際に業務改善へ進める流れは開発会社に依頼して業務改善する進め方も参考にしてください。
