「受注管理のExcelが、シートが20個以上に増えて、関数が複雑に絡み合っていて、作った本人が退職してからは誰も怖くて触れない。でも会社の受注はこのファイルで回っている」——製造業のお客さまから、こんな相談を受けました。現場が知恵を絞って育ててきた管理表やスプレッドシート、GAS（Google Apps Script）の自動化は、ある規模までは間違いなく強力な武器です。ところが、扱う量と関わる人が増えたある一点を超えると、それは効率化の道具から、壊れたら業務が止まる時限爆弾に変わります。
だからといって、何でもかんでもシステムとして作り込めばいいわけではありません。開発には費用も時間もかかり、作ったものの保守も必要になります。今の道具で粘るべきか、ノーコードで組むべきか、きちんと開発すべきか——この判断を誤ると、過剰投資にも、事故待ちの放置にもなります。発注を検討する前に、自社がどの段階にいるのかを見極める軸を持っておきましょう。
「限界のサイン」は費用ではなく症状で見える
システム化を考えるべきタイミングは、多くの場合「なんとなく不便」ではなく、はっきりした症状として現れます。次のような状況が複数当てはまるなら、今の道具が限界に近づいているサインです。
まず、属人化。特定の一人しかそのファイルの全体像を理解しておらず、その人が休むと業務が滞る。次に、同時編集の破綻。複数人が同じファイルを触って、上書きや競合が日常的に起きている。そして、転記と二重入力。ある表からある表へ、人が手でコピー＆ペーストしている作業が定常的にある。さらに、エラーの発覚が遅い。数式が壊れていたことに、月末の集計で初めて気づく。最後に、「怖くて触れない」。改修したいが、どこに影響するか分からず手を出せない。
これらは、扱うデータ量が増え、関わる人が増えたときに必ず出てくる症状です。逆にいえば、一人で完結し、量も少なく、たまにしか使わない業務なら、無理にシステム化する必要はありません。スプレッドシートやGASのままでも、Googleスプレッドシート活用術 のような工夫で十分に戦えます。症状が出ていないのに作り込むのは過剰投資です。
選択肢は「作り込む」だけではない
システム化＝ゼロから開発、と考える必要はありません。実際には、コストとリスクの異なる複数の段階があります。自社の症状に対して、どこまでの手当てが妥当かを見極めるのがポイントです。
| 選択肢 | 向いている状況 | 主なコスト |
|---|---|---|
| 今の道具を整える | 症状が軽く、属人化の解消が主目的 | 小（運用ルールの整備） |
| ノーコード／ローコード | 定型業務・データ管理で、要件が比較的はっきりしている | 中（設定・連携の設計） |
| スクラッチ開発 | 独自の業務ロジックが競争力の源泉で、既製品では表現できない | 大（開発＋継続保守） |
近年は、Excelやスプレッドシートのデータをそのままアプリ化できるノーコードの選択肢が実用的になり、いきなりフルスクラッチに進む前の現実的な中間解になっています。現場のExcelをアプリ化する具体的な進め方は AppSheetで業務アプリ化する受託の勘所 で扱いました。一方で、ノーコードにも「複雑な処理は苦手」「ツールの仕様に縛られる」という限界があります。この見極め自体は AIエージェント時代にローコードは不要か でも論点にしています。「独自ロジックが自社の強みか、それとも一般的な管理業務か」が、作り込むか既製の仕組みに寄せるかの分かれ目です。
「全部作り直し」は、たいてい最悪手
限界を感じた会社が陥りがちなのが、「この際、全部作り直そう」という発想です。ところが、長年使ってきた業務の仕組みには、ファイルの見た目には現れない現場の暗黙のルールが大量に埋め込まれています。それを一気に新システムへ載せ替えようとすると、要件定義が膨れ上がり、費用も期間も跳ね上がり、しかも現場が「前のほうが使いやすかった」と離反する——という失敗を何度も見てきました。
現実的なのは、いちばん痛い症状から順に、小さく手当てすることです。属人化が問題なら、まずデータの一元管理だけを切り出す。二重入力が問題なら、その転記だけを自動化する。全体を作り直さず、既存の使い勝手を活かしながら痛点だけを潰す考え方は レガシー業務システムを”作り直さず”使いやすくする と共通します。「一度に全部」ではなく「効く順に段階的に」が、失敗しないシステム化の鉄則です。
発注前に決めておくべき3つのこと
外部に相談する前に、発注する側として次の3点を言語化しておくと、見積もりも提案も精度が上がります。
ひとつめは、解決したい症状の優先順位です。「便利にしたい」ではなく「まずこの二重入力をなくしたい」と具体化する。ふたつめは、残したいものと変えたいものの切り分け。今のやり方のどこが使いやすくて、どこが困っているのか。みっつめは、作った後、誰が運用・保守するのか。作って終わりのシステムはありません。改修や引き継ぎまで含めて任せるのか、社内で持つのか。特に、前任者が作ったGASやマクロを引き継いで苦労している会社は多く、この「作った後」の設計を軽視すると、また同じ属人化を繰り返します。引き継いだ自動化を立て直す観点は 前任者のGASを受託で立て直す で具体的に扱いました。
どこから手をつけるか
まずは、社内で「これが壊れたら業務が止まる」ファイルや自動化を3つ挙げ、それぞれについて「作った本人以外に中身を分かる人がいるか」を確認してみてください。答えが「いない」なら、そこが最優先で手を打つべき箇所です。いきなり大きなシステムを構想する前に、いちばん痛い一点を特定することが、投資を無駄にしないスタート地点になります。
今の道具で粘るべきか、ノーコードで組むか、開発すべきか——自社の症状と業務の特性を踏まえた妥当な落としどころは、規模や体制で変わります。優先順位づけと、段階的に進める道筋の設計から、一緒に整理します。
