「まずは小さく」で失敗しないシステム化テーマの選び方

「システム化するなら、いっそ全社の基幹システムを作り直した方がいいのではないか」。30人規模の会社で初めてシステム化を検討し始めると、この発想に行き着くことがあります。バラバラのExcelファイルと紙の帳票が社内のあちこちに散らばっている状態を見ていると、「どうせやるなら根本から」という気持ちになるのは自然なことです。

しかし、この発想には大きな落とし穴があります。全社基幹システムのような大規模な開発は、要件定義だけで数ヶ月、開発全体では1年を超えることも珍しくなく、投じる費用も数百万円から数千万円の規模になります。30人規模の会社にとって、この規模の投資はリスクが大きすぎるだけでなく、社内合意を取り付けること自体が困難です。

この記事では、「まずは小さく」システム化を始めるという方針そのものは正しい前提としたうえで、では具体的に「どの部署の」「どの業務を」最初のテーマに選べばよいのかという、見極めの基準を扱います。想定する読者は、社員10〜30人規模の会社で、複数のシステム化候補を前に「結局どれから手をつければいいのか」を迷っている総務担当者・経営者です。専任の情シス部門があれば、こうした優先順位付けは部門内の検討事項として整理されますが、この規模の会社では、限られた時間の中で担当者が独力で判断を下さなければなりません。

この記事で分かること

• なぜ全社基幹システムを最初のテーマにすべきでないのか
• 部署単位の小規模案件を選ぶための4つの判定基準
• 「小さすぎて意味がない」案件を避ける下限の考え方
• 実際によくある小規模案件のテーマ例と、その選定理由
• 最初のテーマ選びが2つ目・3つ目のシステム化にどう影響するか

なぜ全社基幹システムから始めてはいけないのか

まず、全社基幹システムを最初のテーマに選んではいけない理由を整理しておきます。理由は大きく3つあります。

1つ目は、要件の複雑さです。全社基幹システムは、経理・人事・営業・製造など複数部署の業務プロセスを横断的に扱う必要があります。部署ごとに業務のやり方や優先順位が異なるため、要件をまとめるだけでも大きな労力がかかります。30人規模の会社では、この調整を専任で行える人員がそもそもいません。

2つ目は、失敗した場合の被害の大きさです。小規模な案件であれば、仮に思うような効果が出なくても、被害は限定的な範囲にとどまります。しかし全社基幹システムが失敗すると、投じた費用も時間も回収できないまま、会社全体の業務に混乱をもたらすリスクがあります。

3つ目は、社内合意の取りづらさです。前提として、決裁者が1〜2人しかいない30人規模の会社では、数百万円〜数千万円規模の投資判断そのものが重い意思決定になります。実績のない開発会社との取引実績もないまま、いきなり大きな金額の意思決定を迫られると、決裁者は判断を先延ばしにしがちです。社内合意の取り方の基本については総務が初めてシステム開発を発注するときの社内合意の取り方で扱っていますが、そもそも合意を取りやすいテーマを選ぶこと自体が、合意形成を成功させる近道でもあります。

部署単位の小規模案件を選ぶ4つの判定基準

では、具体的にどのようにテーマを選べばよいのか。判定基準を4つ提示します。

この4つの基準をすべて満たすテーマほど、最初の案件として成功しやすくなります。逆に、いずれかの基準を大きく外れるテーマは、最初の案件としてはリスクが高いと判断してください。

判定基準①: 影響範囲が1〜2部署に閉じているか

最初のシステム化テーマは、影響範囲が狭いほど扱いやすくなります。例えば経理部門だけで完結する請求書処理の自動化と、営業・経理・製造の3部署が関わる受発注システムとでは、必要な調整の量が桁違いに変わります。

30人規模の会社であっても、部署間で異なる業務ルールや暗黙の了解が存在することは珍しくありません。影響範囲が広い案件では、これらのルールをすべて洗い出して整理する作業自体が大きな負担になります。最初のテーマとしては、まず自分がよく知っている部署、あるいは業務フローが比較的単純な部署から着手するのが現実的です。

判定基準②: 現状の損失が具体的に測れるか

システム化の効果を社内に説明するには、「今どれだけ困っているか」を数字で示せることが重要です。「なんとなく非効率な気がする」という感覚だけでは、決裁者を説得する材料になりません。

具体的に測れる損失の例を挙げます。

• 月間の作業時間(例: 請求書の手入力に月20時間かかっている)
• ミスの発生件数と、その修正にかかる時間(例: 月に3件の転記ミスがあり、1件あたり修正に1時間かかる)
• 機会損失(例: 対応の遅れにより、月に1〜2件の商談機会を逃している)

これらの数字は、正確でなくても構いません。「だいたい月20時間」という程度の概算でも、決裁者が投資対効果を判断する材料としては十分に機能します。逆に、損失が具体的に見えないテーマは、たとえ理屈の上では改善効果がありそうでも、優先順位を上げにくくなります。

判定基準③: 業務フローが比較的シンプルか

業務フローの複雑さは、開発の難易度と費用に直結します。例外パターンが多い業務(「通常はこう処理するが、〇〇の場合だけ別のルールがある」というケースが多い業務)は、要件定義の段階で時間がかかり、開発費用も膨らみやすくなります。

最初のテーマとしては、次のような特徴を持つ業務が適しています。

• 入力する項目や処理の流れが、担当者によらずほぼ一定である
• 例外処理が発生しても、月に数件程度にとどまる
• 判断が必要な場面が少なく、機械的な処理で完結する部分が多い

逆に、属人化が進んでいる業務、つまり担当者の経験と勘に頼って例外処理を都度判断しているような業務は、最初のテーマとしては扱いにくい傾向があります。こうした業務は、システム化の前にまず業務フロー自体の整理・標準化が必要になることが多く、属人化の解消と合わせて段階的に取り組む方が現実的です。

判定基準④: 既製品・ノーコードで代替できないか

システム化を検討する際、最初から独自開発(外注によるフルスクラッチ開発)を前提にするのは早計です。世の中には、勤怠管理・経費精算・簡単な顧客管理など、汎用的な業務課題を解決するノーコード・ローコードツールやSaaS製品が数多く存在します。

判定の順番としては、次のように考えてください。

1. 同じ課題を解決する既製のSaaS製品がないか検索する
2. 既製品では細かい要望に対応できない場合、ノーコード・ローコードで自社対応できないか検討する
3. どちらでも実現できない、自社独自の業務フローがある場合に初めて、外注による開発を検討する

この判定を飛ばしていきなり外注の検討に進んでしまうと、既製品なら月数千円で済むはずの課題に、数十万円〜数百万円の開発費用をかけることになりかねません。フルスクラッチ開発開発と既製品の比較については、コラムフルスクラッチとパッケージ、どちらを選ぶ？でも詳しく扱っています。

この記事はシステム開発の受託会社が運営するメディアですが、この判定基準は率直に書きます。既製品で十分に解決できる課題にわざわざ外注費用をかけるのは、30人規模の会社にとって明確な機会損失です。判定基準④を形だけの確認で済ませず、実際にいくつかのSaaS製品を検索し、比較してみる手間を惜しまないことをお勧めします。

「小さすぎる」案件を避ける下限の考え方

「まずは小さく」という方針は重要ですが、小さければ小さいほどよいわけではありません。あまりに小さな案件は、開発を依頼する側にとっても引き受ける側にとっても、費用対効果が見合わなくなることがあります。

目安として、次のような案件は「小さすぎる」可能性があります。

• 効果が及ぶ人数が1〜2人にとどまり、会社全体への波及効果がほとんどない
• 既存のExcelファイルの体裁を整えるだけで解決してしまう程度の課題
• 開発を依頼するより、既存の業務フローを少し変更するだけで解決できる課題

このような案件は、システム化ではなく業務改善の範疇で対処すべきものです。逆に言えば、最初のシステム化テーマとしてふさわしいのは、「効果が複数人・複数部署にじわりと波及する」「業務フローの変更だけでは解決しきれない構造的な課題である」という、ある程度の規模感を持つ案件です。

よくある小規模案件のテーマ例

30人規模の会社で実際によく選ばれる、部署単位の小規模案件のテーマ例を挙げます。

これらのテーマに共通するのは、いずれも特定の1〜2部署に閉じており、業務フローが比較的定型的で、損失を数字で示しやすいという点です。ただし、これはあくまで一般的な傾向であり、実際にどのテーマを選ぶべきかは、自社の業務の実情に照らして判断する必要があります。

最初のテーマ選びが2つ目・3つ目に与える影響

最初のシステム化テーマの選び方は、単発の意思決定にとどまりません。最初の案件がうまくいけば、社内には「システム化は成果につながる」という成功体験が生まれ、2つ目・3つ目のテーマへの合意形成が格段にやりやすくなります。逆に、最初の案件で「思ったほど効果がなかった」「使いにくくて定着しなかった」という失敗体験が生まれると、その後のシステム化提案全体に対する社内の懐疑が強まってしまいます。

この意味で、最初のテーマ選びは「最も困っている業務」を選ぶこととは必ずしも一致しません。最も困っている業務が、同時に最も複雑で例外の多い業務である場合、最初の案件としては失敗のリスクが高くなります。むしろ、次の優先順位で考えることをお勧めします。

1. 判定基準①〜④をすべて満たし、成功しやすい案件
2. 上記のうち、社内の関心が高く、成功した場合の説得力が大きい案件
3. 最も困っているが複雑な業務は、成功体験を積んだ後の2つ目・3つ目のテーマに回す

最も困っている業務を後回しにすることに抵抗を感じるかもしれませんが、「確実に成功する案件で実績を作り、その実績を武器に次の投資判断を得る」という段階的な進め方の方が、結果的に会社全体のシステム化を早く進められます。

複数の候補テーマがある場合の優先順位の付け方

実際には、判定基準①〜④をある程度満たすテーマが複数見つかることも多くあります。この場合、どのテーマから着手すべきかを比較する必要があります。比較の際は、次の3つの軸でスコア化してみることをお勧めします。厳密な点数計算をする必要はなく、あくまで相対的な優先順位を可視化するための手段です。

例えば、「効果は大きいが実現が難しい」テーマと、「効果はやや小さいが実現が容易で、社内の関心も高い」テーマがあった場合、最初の案件としては後者を選ぶ方が現実的です。最初の案件で成功体験を積むことの価値は、単発の効果の大きさよりも重要になる場面が多いためです。

逆に、「効果が小さく、実現も難しく、社内の関心も低い」テーマは、判定基準の観点からも最初の案件としては適さないと判断してよいでしょう。無理に着手するより、業務改善の範囲で対応するか、いったん保留にする方が賢明です。

部署間で候補テーマが競合したときの調整

30人規模の会社では、複数の部署がそれぞれ別々に「うちの業務もシステム化してほしい」と声を上げることがあります。経理は請求書処理を、営業は見積書作成を、それぞれ同時に要望してくるようなケースです。限られた予算と担当者のリソースの中で、すべてを同時に進めることは現実的ではありません。

このような競合が起きた場合、判定基準①〜④に加えて、次の観点を加味して調整します。

• どちらの部署の課題がより緊急性が高いか(繁忙期が近い、退職予定者がいるなど)
• どちらのテーマがより多くの部署に波及効果を持つか
• 決裁者自身がどちらのテーマに強い関心を持っているか

調整の結果、片方のテーマを先送りにする場合は、「今回は見送る」ではなく「次のタイミングで必ず着手する」という約束を明確にしておくことが重要です。声を上げてくれた部署の意欲を削がないようにすることも、次のシステム化を進めやすくするための地ならしになります。

判定基準を満たしていても着手を見送るべきケース

判定基準①〜④をすべて満たしていても、状況によっては着手を見送った方がよい場合があります。代表的なのは次の3つのケースです。

1. 担当者自身の業務が繁忙期に入っている: システム化の検討・要件整理には一定の時間が必要です。本業が手一杯の時期に無理に進めると、開発会社とのやり取りが疎かになり、要件のズレが生じやすくなります
2. 決裁者が別の重要な意思決定に集中している最中: 資金調達や大口の取引交渉など、決裁者の意識が他に向いているタイミングでの提案は、十分な検討時間を得られない可能性があります
3. 対象業務の担当者が近く異動・退職する予定がある: 業務フローのヒアリングは、実際にその業務を担っている人からでなければ正確な情報が得られません。担当者の入れ替わりが目前に迫っている場合は、引き継ぎが落ち着いてから着手する方が安全です

これらのケースでは、判定基準による「テーマの良し悪し」とは別に、「タイミングの良し悪し」を見極める必要があります。良いテーマでも悪いタイミングで進めると失敗しやすくなる、という点は覚えておいてください。

経営者からトップダウンでテーマが指定された場合

ここまでは、総務担当者が主体的にテーマを選ぶ前提で説明してきました。しかし実際には、社長が特定の業務(それも必ずしも小規模とは限らない業務)を名指しで「システム化してくれ」と指示してくるケースもあります。この場合、判定基準に照らして「これは最初のテーマとして適切でない」と感じても、頭ごなしに断ることは現実的ではありません。

トップダウンで降ってきたテーマをどう受け止め、どう範囲を整理していくかについては、経営者の鶴の一声で始まる開発案件を暴走させない進め方で詳しく扱っています。本記事の判定基準は、そのままトップダウン案件の範囲を絞り込む際の材料としても使えます。

PoC・MVPという選択肢で、さらにリスクを下げる

判定基準に照らして選んだテーマであっても、「本当に効果が出るか確信が持てない」という不安が残ることはあります。この場合、いきなり本格的なシステムを発注するのではなく、PoC（概念実証）やMVP（実用最小限の製品）という形でさらに範囲を絞り込む選択肢があります。

PoC(概念実証)は、本格的な開発の前に、限定的な範囲で実現可能性や効果を検証する取り組みです。例えば「見積書作成の効率化」というテーマであれば、いきなり全営業担当者向けの本格的なシステムを作るのではなく、まず1〜2名の営業担当者だけが使える簡易的な仕組みを試作し、実際に効果が出るかを確認してから本格開発に進む、という進め方が可能です。

この段階的な進め方には、次のような利点があります。

• 初期投資を数十万円程度に抑えられ、決裁者への説明もしやすい
• 実際に使ってみたうえでの改善要望を、本格開発の要件に反映できる
• 万が一効果が出なかった場合の損失を、限定的な範囲にとどめられる

PoC・MVPで小さく試すという発注の考え方そのものについては、コラム小さく発注して試す: PoC発注のすすめでも詳しく解説しています。判定基準①〜④で選んだテーマに、この段階的な検証を組み合わせることで、最初の一歩をさらに小さく、確実なものにできます。

テーマ選びの失敗を避けるためのセルフチェック

最後に、テーマを最終決定する前に確認しておきたいセルフチェック項目をまとめます。次の質問すべてに「はい」と答えられる状態であれば、最初のシステム化テーマとして自信を持って進めてよいでしょう。

• 影響が及ぶ部署は1〜2部署に収まっているか
• 現状の損失を、何らかの数字(時間・件数など)で示せるか
• 業務フローの例外パターンを、自分で把握できているか
• 既製品・ノーコードで代替できないか、一度は調べたか
• 効果が及ぶ人数が複数人以上いるか(1〜2人に限定されていないか)
• 決裁者・現場の双方が、このテーマに一定の関心を持っているか
• 担当者(自分)が本業と並行してこの案件に取り組める時期か

これらの項目のうち、2つ以上に「いいえ」がつく場合は、テーマの選び直し、または着手時期の見直しを検討することをお勧めします。逆に、ほとんどの項目に「はい」と答えられるのに着手をためらっているとしたら、それは判断材料の不足ではなく、単なる心理的なハードルである可能性があります。判定基準を満たしたテーマであれば、思い切って次のステップ(社内合意の形成)に進むことをお勧めします。

業種による判定基準の傾向の違い

判定基準①〜④は業種を問わず共通して使える枠組みですが、実際に当てはめてみると、業種によってどの基準が特に重要になるかに傾向の違いが見られます。参考として、いくつかの業種でよく見られる傾向を整理します。

• 製造業: 在庫・工程管理が複数部署にまたがりやすく、判定基準①(影響範囲)で引っかかりやすい。まずは特定の工程・特定の品目に絞ることが有効
• 卸売・小売業: 受発注や在庫のExcel管理に限界が来やすく、損失(判定基準②)が数字で見えやすい業種。時間・ミス件数の計測がしやすい
• サービス業(士業・コンサル等): 顧客管理や案件管理が属人化しやすく、業務フロー(判定基準③)が担当者ごとに異なりがちで、標準化が先に必要になることが多い
• 建設・工事業: 案件ごとに個別性が強く、既製品(判定基準④)では対応しきれない独自要件が発生しやすい一方、対象を絞れば効果は出やすい

これらはあくまで傾向であり、同じ業種でも会社ごとの実情によって当てはまり方は変わります。自社がどの業種の傾向に近いかを意識しながら、4つの判定基準のうちどこに特に注意を払うべきかを判断する参考にしてください。

まとめ: 「困っている度合い」より「成功しやすさ」を優先する

30人規模の会社が最初のシステム化テーマを選ぶ際は、次の考え方を軸にしてください。

1. 全社基幹システムのような大規模案件は最初のテーマにしない
2. 影響範囲・損失の見える化・業務フローの単純さ・既製品での代替可否の4基準で判定する
3. 小さすぎて効果が見えない案件も避け、複数人・複数部署に波及する規模感を選ぶ
4. 最初の案件は「最も困っている」ではなく「最も成功しやすい」を優先し、成功体験を積み上げる

最初のテーマが定まったら、次は社内合意の取り方と、稟議を通すための資料づくりに進んでください。それぞれ総務が初めてシステム開発を発注するときの社内合意の取り方と30人規模の会社が外注費用を稟議に通すための資料の作り方で扱っています。

選んだテーマの範囲をさらに絞り込む: 「まずはここまで」の線の引き方

判定基準に沿って部署単位のテーマを選んだとしても、その部署の業務すべてを一度にシステム化しようとすると、結局は範囲が広がりすぎてしまうことがあります。例えば「経理の請求書処理」というテーマ一つを取っても、見積もり作成・請求書発行・入金確認・催促連絡・会計ソフトへの反映など、複数の工程が連なっています。

最初の案件では、これらの工程のうち、最も効果が出やすく、かつ最も独立して切り出しやすい部分だけに範囲を絞ることをお勧めします。範囲を絞り込む際は、次の問いを自分に投げかけてみてください。

• この工程だけを切り出しても、業務として意味のある単位になっているか
• 前後の工程との連携(データの受け渡し)は、Excelエクスポートなど簡易な方法で当面代替できるか
• この工程を最初に手がけることで、次の工程への着手がしやすくなるか

範囲を絞り込みすぎて前後の工程との連携が不自然になる場合は、多少範囲を広げてでも業務として完結する単位を保つ方が実務的です。逆に、欲張って全工程を一度に対象にすると、要件定義の段階で行き詰まりやすくなります。この「広げすぎず、狭めすぎず」のバランス感覚が、小規模案件のテーマ選びにおける実務上の勘所です。

判定基準に基づくテーマ選びと、開発会社への伝え方

テーマが固まった後、実際に開発会社へ相談する段階になると、判定基準で整理した情報がそのまま初回打ち合わせの材料になります。特に、「なぜこの業務を最初のテーマに選んだのか」という背景を開発会社に伝えておくと、提案の精度が上がりやすくなります。

例えば、次のように伝えると効果的です。

「請求書処理を最初のテーマに選んだのは、経理担当1名の作業負荷が特に大きく、月20時間ほど手作業に取られているためです。まずはこの工程だけを切り出して改善したいと考えています。将来的には入金確認や会計ソフトとの連携も視野に入れていますが、今回はスコープに含めていません」

このように、選定理由と将来の拡張予定を併せて伝えることで、開発会社側も「今回作る部分」と「将来拡張される可能性がある部分」を意識した設計を提案しやすくなります。逆に、この背景を伝えずに機能要望だけを伝えると、開発会社は将来の拡張性を考慮せずに設計してしまい、後から拡張しようとした際に追加改修のコストが余計にかかることがあります。初回打ち合わせで確認すべき事項全般については、コラム開発会社との初回打ち合わせで聞くべきことも参考にしてください。