社内アプリは作るべきか｜作らない判断と回収月数の試算

社内アプリを作るか、いまのスプレッドシートのまま粘るか。この判断は好みではなく、回収月数＝初期費用 ÷（月に減る作業時間 × 時給）という1本の式で出せます。目安は12か月以内に回収できるなら作る、24か月を超えるなら作らない。この記事では、その式の使い方と、作らないほうがいい5つのケース、シートのまま粘れる公式の上限まで一気に確認します。

結論：判断は「回収月数」と「入力者の人数」の2つで決まる

社内アプリ化の判断軸は、突き詰めると2つしかありません。1つは回収月数、もう1つはそのデータを直接触る人が何人いるかです。

回収月数は次の式で出します。小数は切り上げてかまいません。

回収月数＝初期費用 ÷（月に減る作業時間 × 社内の時給）

もう1つの「入力者の人数」は、式に乗らないのに効いてくる変数です。触る人が1〜2人なら、シートが多少ぐちゃぐちゃでも当人の頭の中でつじつまが合います。3人を超えたあたりから、上書き・行ズレ・フィルタ事故といった「人数の2乗で増える事故」が起き始め、削減時間の見積もりが実際より小さく出ます。

この2つを合わせると、判断はこうなります。

回収12か月以内＋入力者3人以上 → 作る。迷う理由がほぼない
回収12〜24か月＋入力者3人以上 → 作る価値はあるが、範囲を絞って小さく作る
回収24か月超 → 作らない。シートの作り方を直すほうが早い
入力者が1〜2人 → 回収月数がいくら良くても、まず作らない。属人化はアプリでは解けない

作らないほうがいい5つのケース

実務で多いのは、作るべきでない状態のまま発注してしまい、使われないまま放置される形です。次の5つに当てはまるなら、いったん止めたほうが結果的に安く済みます。

1. 業務の手順がまだ固まっていない

「今はこうやっているけど、来月には変わるかもしれない」という状態でアプリにすると、作った瞬間に仕様変更が始まります。手順が3か月変わっていない業務だけをアプリ化の候補にしてください。

2. 入力者が1〜2人しかいない

1人しか触らない台帳は、どれだけ複雑でもその人の中では動いています。ここでアプリを作っても減るのは操作の手間だけで、引き継げない問題は残ったままです。この場合に効くのは、アプリ化ではなく手順書と権限の整理です。

3. 困りごとが「重い・固まる」だけ

シートが重いこと自体は、作り方で解ける場合がかなりあります。関数の使い方や参照範囲を直すだけで軽くなることも多いので、スプレッドシートが重いときの軽量化を一度試してから判断してください。

4. 「他社が入れているから」以外に理由が出てこない

比較検討の場で、削減できる作業を具体的に挙げられないなら、式の分母がゼロということです。分母がゼロなら回収月数は無限大になります。

5. 運用を見る人が決まっていない

作ったあと、項目追加やマスタ更新を誰がやるかが決まっていないアプリは、半年で誰も触らなくなります。発注前に名前を1人決めてください。

ここから先は「作る」と決めた側の話になります。なお、私たちも今お使いのスプレッドシートを残したまま入力画面だけを載せ替える形のサービスを行っております。記事の途中で恐縮ですが、判断の材料としてスプシ de 社内アプリのページも見ていただけたら嬉しいです。

3ケースで試算する（式に数字を入れてみる）

実際に数字を入れてみます。時給は社内の人件費単価を使ってください。ここでは仮に2,500円として計算します（この数字は自社の実額に置き換えてください）。初期費用は、スプレッドシートを残したまま画面だけ載せ替えるタイプで25万円前後が目安です（Mihataの場合は初期費用25万円〜）。

ケース	月に減る作業時間	月の削減額（×2,500円）	初期費用	回収月数	判断
A：受注台帳の転記と集計（入力者5人）	24時間	60,000円	250,000円	5か月	作る
B：在庫の棚卸しシート（入力者3人）	10時間	25,000円	250,000円	10か月	作る
C：月次の経費まとめ（入力者2人）	4時間	10,000円	250,000円	25か月	作らない

ケースCは、回収に2年以上かかるうえ入力者が2人なので、2つの軸の両方で「作らない」に倒れます。こういう業務は、シートの様式を整えて関数で自動計算させるところで止めたほうが得です。

試算でいちばん間違えやすいところ

分母の「月に減る作業時間」を、作業そのものの時間だけで数えてしまうのが最も多い誤りです。実際には次の3つも減ります。逆にこれを入れないと、作るべき案件まで「回収24か月超」に見えてしまいます。

やり直しの時間：上書き事故・行ズレの発見と復旧にかかっている時間
探す時間：どのファイルが最新か確認する時間、人に聞く時間
待つ時間：誰かが入力を終えるまで手をつけられない時間

逆に、分子に入れ忘れやすいのが運用費です。初期費用だけでなく、月額の保守や改修費がある場合は「初期費用＋月額×24」を分子に置いて2年総額で見ると、判断がぶれません。

シートのままで粘れる限界はどこか

「そもそもスプレッドシートの限界はいくつなのか」は、公式に数字が決まっています。Googleスプレッドシートで作成したファイルの上限は1,000万セル、または18,278列（列ZZZ）までです（Google ドライブヘルプ）。

ただし実務で先に来るのは、この公式上限ではありません。だいたい次の順で苦しくなります。

限界の種類	だいたいの目安	先に出る症状
体感速度の限界	数万行＋関数多用	開くのが遅い、入力のたびに再計算で固まる
同時編集の限界	入力者3人以上	上書き、行ズレ、フィルタが他の人にも効く
権限の限界	見せたくない列ができたとき	シートを分ける運用が始まり、どれが最新か分からなくなる
公式上限	1,000万セル／18,278列	そもそも入らない

公式上限に当たる前に、ほぼ必ず「同時編集の限界」と「権限の限界」が先に来ます。アプリ化を検討する本当のきっかけは、セル数ではなく権限です。「この列は見せたくないから別シートにコピーしよう」と言い出した時点が、シートの限界だと考えてください。

作ると決めたあとに、最初に決める4つ

発注の前にこの4つを決めておくと、見積もりのブレと作り直しがほとんど消えます。

残すシートと捨てるシート：データの置き場所としてシートを残すのか、丸ごと移すのか。残すほうが安く早く、後戻りもききます
最初に作る画面を1つに絞る：入力画面だけ、あるいは検索画面だけ。全部入りで始めた案件は、ほぼ例外なく遅れます
権限の段数：全員が同じものを見るのか、役職で見える列を変えるのか。ここが費用を最も動かします
運用担当の名前：項目追加とマスタ更新をする人。決まっていないなら発注を止めるサインです

どう作るか（ノーコードで組むか、作り込むか）まで含めて比べたい場合は、業務アプリはノーコードか開発かの判断5軸と3年総額で費用の出方が変わる理由を整理しています。すでにkintoneなどを使っていて乗り換えを考えているなら、kintone乗り換えの費用と代替案のほうが近い話になります。

作ったあとに失敗する典型

回収月数が良くても、運用で落とすことがあります。多いのは「入力画面は作ったのに、出口（集計・出力）を作らなかった」パターンです。入力だけアプリ化すると、結局そこからシートに書き出して手で集計することになり、削減時間が想定の半分以下になります。

もうひとつ多いのが、現場の合意を取らずに作ってしまう形です。使う人が「前のシートのほうが速い」と感じた瞬間に、裏で元のシートが復活します。内製・外注どちらの場合でも起きるので、社内アプリを内製して失敗する7パターンにも目を通しておくと避けやすくなります。

ここまでの判断で「まだシートのままでいい」となった場合も、それは何もしないという意味ではありません。スプレッドシート管理の限界とアプリ化という第3の選択肢で、シートを整えるだけでどこまで伸ばせるかを確認してみてください。

あわせて読みたい

判断に必要な数字が自社で出しきれない場合は、いまのシートを見せていただければ削減時間の見積もりからお手伝いできます。

よくある質問

社内アプリを作るかどうかの判断基準は何ですか？

回収月数（初期費用 ÷ 月に減る作業時間 × 時給）と、そのデータを直接触る人数の2つです。回収12か月以内かつ入力者3人以上なら作る、回収24か月超なら作らない、が目安です。

入力者が1人でもアプリ化する意味はありますか？

原則ありません。1人しか触らない台帳は操作の手間が減るだけで、引き継げない問題は残ります。この場合は手順書と権限の整理のほうが効きます。

スプレッドシートの公式な上限はいくつですか？

Googleスプレッドシートで作成したファイルは1,000万セル、または18,278列（列ZZZ）までです。ただし実務では、その手前で体感速度・同時編集・権限の限界が先に来ます。

試算でいちばん間違えやすいのはどこですか？

分母の「月に減る作業時間」を作業そのものの時間だけで数えてしまうことです。やり直し・探す・待つの3つの時間も減るので、これを入れないと作るべき案件まで回収24か月超に見えます。

初期費用の目安はどれくらいですか？

スプレッドシートをデータの置き場所として残したまま入力画面だけを載せ替えるタイプで、初期費用25万円前後が目安です。月額の保守がある場合は「初期費用＋月額×24」で2年総額を見て判断してください。