SaaS・自作・手作業、どれを選ぶ？少人数の業務を回す比較のしかた

1. 道具の比較より、業務の変動を先に見る

起業直後に必要なのは、完成度の高い社内システムより、受注から入金までを無理なく回せる運営です。ただし、すべてを手作業にすると、確認漏れや転記に時間を使います。逆に、業務が固まる前に自動化すると、顧客の要望が変わるたびに仕組みを直すことになります。

最初の候補は、件数が少なく手順が変わる業務なら手作業、繰り返しが多く一般的な手順ならSaaS（インターネット経由で利用する業務ソフト）、独自の処理が顧客価値に直結し保守できるなら自作です。これは編集部の判断枠組みであり、業種を問わない優劣ではありません。会計はSaaS、顧客への個別連絡は手作業、独自の集計だけ自作という組み合わせも十分に成立します。

判断の前に「何を減らしたいか」を一つ決めます。請求作成の時間、二重入力、入金確認漏れ、引継ぎの難しさでは、必要な機能が違います。便利そうだから導入するのではなく、改善対象を確認できる状態にしてから選びます。

図を大きく見る（新しいタブ） ↗横にスクロールして読めます →

2. 一週間の業務を、頻度・例外・失敗で棚卸しする

業務名だけを書いても比較できません。「請求業務」を、顧客情報の確認、請求書作成、送付、入金照合、未入金の確認に分けます。そのうえで、直近の実績か小さな試行から、通常の件数と一件あたりの時間を記録します。開業前なら仮説の数字と明記し、初月に実績へ置き換えます。

• 頻度：月に何回あるか。月末や繁忙日に集中するか。
• 例外：値引き、分割請求、顧客指定書式などは何件あるか。
• 失敗：間違えたときに誰へどんな影響が出るか。後から直せるか。
• 判断：入力された情報だけで処理できるか。顧客との相談が要るか。
• 依存：担当者が休んでも、別の人が記録を見て続けられるか。

とくに分けたいのは、毎回同じ処理と、その場の判断です。十件中二件が特殊な請求なら、まず八件を標準化し、二件は担当者が確認する経路を残せます。例外をゼロにするための開発費と、例外を手作業で処理する時間を比べるほうが現実的です。

例として、初めて受注する制作サービスを考えます。顧客が何を確認したいか分からない段階では、打ち合わせ記録と進行表を手で更新するほうが変更しやすいでしょう。受注が増えて確認項目が揃ったら、その項目をSaaSへ移します。特有の見積計算だけが毎回大きな負担になるなら、その部分を自作する順番です。事業全体を一度に同じ方法へ揃える必要はありません。

時間だけで候補を絞らないことも大切です。月一回の作業でも、給与や顧客データを誤る影響は大きくなります。高リスクな業務では、処理速度より記録、権限、確認方法を優先してください。

3. 三つの方法で、残る仕事がどう変わるか

手作業の利点は、手順をすぐ変えられることです。初期の顧客対応では、問い合わせの理由や例外を自分で観察できます。一方、担当者の記憶に依存すると、件数増加とともに確認漏れが起きやすくなります。テンプレート、必須入力項目、完了の印、保管先を決め、再現できる手作業にします。

SaaSは、既存の機能に業務を合わせられるほど導入しやすくなります。ただし、利用開始後にもアカウント管理、入力ルール、データ修正、問い合わせ対応は残ります。「標準機能ではできない」箇所について、業務を変える、別の方法で補う、候補から外すの三つを選びます。追加機能が増えるほど、契約料金だけでなく運用の複雑さも確認します。

自作には、表計算の関数や小さなスクリプトから業務アプリまで幅があります。扱う範囲が広がるほど、テスト、権限設定、更新、障害対応、引継ぎも必要です。AIで初期コードを短時間で作れても、正しい結果か判断し、問題を直す担当は必要です。「作れる」と「半年後も安全に運用できる」は、それぞれ確かめます。

IPAの中小企業の情報セキュリティ対策ガイドライン第4.0版は、小規模な企業も含めて段階的に対策するための資料です。道具を選んだ時点で対策が終わるわけではありません。運営人数に合った管理の仕方も一緒に決めます。

4. 月額料金に、設定・確認・保守を足す

比較する期間を同じにして、「初期費用＋期間中の利用料＋（初期設定・残る作業・保守の時間×設定した時間単価）」で見積もります。現金支出の小計と、時間を金額に換算した評価額も別に出します。解約時の移行費、外部の保守費、障害で業務が止まる影響は、見込める範囲で別欄に置きます。自分の時間は現金支出ではありませんが、営業や納品に使えなくなる時間として評価できます。

たとえば月十時間の作業を、一時間三千円と仮置きします。手作業を一年続ける時間の評価額は三十六万円。SaaSが月五千円、残作業が月二時間、初期設定が八時間なら十五万六千円。自作が初期六十時間、保守月三時間、運用費月二千円なら三十一万二千円です。利用料と運用費は税込みの支出額として仮置きしています。ここでは同じ範囲の仕事を処理できると仮定しており、実際の製品価格や効果の予測ではありません。

図を大きく見る（新しいタブ） ↗横にスクロールして読めます →

この例のSaaSが有利でも、処理件数が半分なら差は縮まります。例外処理が増え、残作業が月八時間になれば結果も変わります。通常月と繁忙月、順調な場合と手戻りが多い場合の二通り以上を計算してください。現金残高が厳しい時期には、時間費用の評価と、実際に払う金額を別々に確認します。

5. SaaSは、入れる前にデータを出してみる

候補を二、三個に絞ったら、実際の業務に近いダミーデータで試します。画面の使いやすさに加え、例外を処理できるか、出力したデータを読めるかを確認します。顧客の秘密情報や個人情報を、許可や契約の確認なしに試用環境へ入れないようにします。

IPAのクラウドサービス安全利用の手引きでは、提供側と利用側の責任、利用者管理、バックアップ、終了時のデータ確保などを確認対象にしています。これを調達時の質問に変えると、次のようになります。

• 必要なプラン：権限管理やデータ出力は、検討中のプランで使えるか。
• 停止時の運営：障害情報と問い合わせ先はどこか。代替手順は何か。
• データの出口：添付ファイルや履歴も出せるか。解約後はいつ消えるか。
• アクセス管理：共有IDを使わずに運用できるか。退職時に権限を外せるか。
• 契約の更新：最低利用期間、自動更新、料金改定、解約の締切はどうなっているか。

出力できるという説明だけでは不十分です。一件を出力し、別の表計算や保管先で開いてみます。文字化け、項目の欠落、添付の分離があれば、移行時の負担として記録します。サービスの安全性を宣伝文句だけで判断せず、公開資料や契約で確認できない点は提供者に質問します。

6. 自作するなら、止まったときの担当まで決める

自作の候補は、すべてを置き換える大きなシステムより、入力と出力が明確な一工程から選びます。たとえば、受注データから社内向けの確認一覧を作る処理です。請求の確定や送金など影響の大きい操作は、人の確認を残す方法も検討します。

着手前に、正常な入力、空欄、重複、予期しない文字、途中失敗を試す条件を書きます。誰が更新するか、利用する外部サービスの仕様が変わったらどうするか、処理を取り消せるかも決めます。コードだけでなく、設定方法、実行方法、失敗の見分け方、手作業への戻し方を短く残してください。

Webで動く自作システムなら、公開後の更新や監視も検討対象です。IPAの安全なウェブサイトの運用管理に向けての20ヶ条を参照し、開発時の安全対策と運用時の点検を分けて確認します。専門知識が足りない範囲を、安さだけで内製に寄せないことが重要です。

7. 一つの業務で試し、続ける条件を決める

試行では、契約数や自動化した工程数を成果にしません。最初に選んだ課題がどれだけ減ったかを見ます。処理時間、確認漏れ、例外件数、修正に要した時間を、導入前と同じ方法で記録します。月次業務なら一回の月末処理まで確認し、日次業務なら忙しい日も含めます。

1. 一つの業務と責任者を決め、現在の手順を残す。
2. 通常ケースと例外ケースを使って試す。
3. 時間の短縮と、残った確認・手戻りを測る。
4. 想定を超えた負担の原因を、設定・業務・製品のどこにあるか分ける。
5. 継続、範囲縮小、変更、撤退を決め、次に確認する日を置く。

試行中に二重入力をするなら、その期間と正本の置き場所を明示します。旧表と新システムの両方を無期限で更新すると、どちらが最新か分からなくなります。件数と金額が一致することを確認し、切り替える日、旧データの参照方法、戻す条件を決めます。小さな移行でも、引継ぎと撤退の手順を先に作ることで、失敗時の混乱を抑えられます。

最後に、担当者が一日不在でも処理できるか試してください。ログイン情報を共有するのではなく、必要な権限と説明を用意します。自分だけが分かる仕組みは、短期には速くても、受注が重なる時期の制約になります。日常の運用だけでなく、休むための余白も選定基準に入れましょう。

導入後も、顧客数や担当者が変わった時点で見直します。手作業を続ける判断も、根拠と再検討条件があれば合理的です。目指すのは道具を増やすことではなく、少人数でも仕事の状態が分かり、必要なところに時間を使える運営です。