ソフトウェア診断室：つくる前に、まず課題を見極める

AI や業務システムを入れたい。けれど、どの業務から始めるべきか、外部ベンダーに何を依頼すべきか、稟議でどう説明すべきかが曖昧なまま止まっている。日本の企業でよく起きるのは、技術そのものよりも、その前段の整理不足です。

まず必要なのは、開発を急ぐことではありません。現場の業務、承認の流れ、データの所在、保守の責任を見極めたうえで、つくるべきか、買うべきか、まだ始めない方がよいかを決めることです。

日本企業で起きやすい失敗：要件が曖昧なまま外注が始まる

DX や AI 導入の話になると、まずツール選定やベンダー探しから始まりがちです。稟議を通すために概算見積もりを取り、外部に相談し、PoC を始める。しかし実際には、現場で誰が使うのか、どのデータを使うのか、例外処理を誰が見るのかが決まっていないまま進んでしまうことがあります。

この状態で開発を始めると、できあがったものは「仕様通り」でも、現場では使いにくいものになりがちです。さらに、担当者の異動やベンダー交代が起きると、なぜその仕様になったのかも引き継げなくなります。

ソフトウェア診断とは：開発可否を決める前の整理

ソフトウェア診断は、開発を始める前に課題を整理するための短いプロセスです。いきなり見積もりを出すのではなく、まず次の点を確認します。

• 本当にソフトウェアで解くべき課題か。 業務手順の見直しや既存ツールで足りる場合は、無理に開発しない方がよいこともあります。
• 最初に解くべき業務はどこか。 全社システムを一度につくるのではなく、稟議で説明しやすく、現場効果が見えやすい範囲を見極めます。
• 現場と管理側の責任分担は明確か。 入力、確認、承認、例外対応、保守の担当が曖昧なままでは、本番運用に乗りません。
• データとセキュリティの境界はどこか。 AI を使う場合ほど、社外に出せない情報、ログ、権限、確認できる記録の扱いを先に決める必要があります。
• 外部ベンダーに渡せる設計になっているか。 要件、判断理由、受け入れ条件が残っていなければ、ベンダー交代や追加開発のたびに同じ説明を繰り返すことになります。

先に診断する方が、稟議にも説明しやすい

診断を挟むと、稟議で説明する内容が変わります。「AI を入れたい」ではなく、「この業務のこの部分を改善し、まずこの範囲で効果を確認する」という形にできます。

費用も、いきなり大きな開発費ではなく、調査・設計・小さな実装という段階に分けられます。社内で慎重に進めたい企業ほど、この分け方が重要です。

始める前に確認したい 3 つのこと

1. どの業務が、誰にとって詰まっているのか。 「効率化したい」だけでは不十分です。毎日時間がかかる作業、ミスが多い作業、特定の担当者に依存している作業を具体化します。
2. 今はどのように処理しているのか。 Excel、メール、チャット、紙、基幹システム、外部ベンダーへの依頼がどうつながっているかを整理します。
3. 半年後に誰が運用し、誰が直すのか。 開発後の保守、変更、問い合わせ対応を考えないまま本番化すると、使われないシステムになりやすいです。

よくある詰まり方：現場業務と AI 試作

一つ目は、現場業務が属人化しているケースです。 見積もり、発注、顧客対応、社内承認、レポート作成などが、Excel とメールとチャットで回っている。改善したいが、どこから切り出せばよいかわからない。この場合、まず業務の流れと責任者を整理することが先です。

二つ目は、AI 試作が本番に進めないケースです。 Cursor や Lovable、Replit、ChatGPT などで動くものはできたが、顧客に出すには不安がある。権限、データ、ログ、例外処理、保守が未整理であれば、診断によって「補強して使う」「作り直す」「社内検証に留める」を判断します。

診断結果は「今は作らない」でもよい

診断の結論が、開発ではないこともあります。既存ツールで十分な場合、業務手順を変えれば済む場合、社内の責任分担を決める方が先の場合があります。

これは後ろ向きな判断ではありません。むしろ、不要な開発費を避け、必要なときに必要な範囲で始めるための健全な判断です。

まず、詰まっている業務を言葉にする

もし社内に「ずっと困っているが、誰も手を付けられていない業務」があるなら、まず診断から始めてください。開発するかどうかを決める前に、課題、関係者、データ、運用責任を整理します。

Omni Care は、詰まっている業務を、本当に使えるソフトウェアにするための相談相手です。必要なら小さく作り、必要でなければ作らない。その判断から一緒に始めます。