実装手段の選び方FAQ
「何で作るか」の判断は、業務の固有性と、他システムへのつながり方でほぼ決まります。順に整理します。
SaaSと個別開発はどう選び分けるか。
自社固有の帳票・承認・集計が絡むかどうかで分かれます。標準的な項目で業務が回り、承認も単純なら、SaaSで足ります。判断の手順としては、まず候補となるSaaSを月額×利用人数×3年で総額化し、次に自社にしかない部分（固有項目、承認の段数、他システムへ渡す数字）を1枚に書き出します。この1枚が空に近ければSaaS、埋まるようなら個別開発の検討余地が出ます。SaaSで足りるなら、それが正解です。
個別開発はいくらかかるか。
当メディア運営会社が提供する業務単位の個別開発では、300万円程度からを目安としています（規模により変動します。当社サービスの価格帯であり、市場の相場を示すものではありません）。期間は1〜3ヶ月程度が目安です。この金額は、対象業務を1つに絞り、既存の基幹システムの刷新を伴わない前提のものです。複数業務をまとめる、基幹システムとの双方向連携を含む、オンプレミス環境が必須といった条件が付くと、前提が変わります。総額での比較は、SaaSの3年分総額、既製品の初期費用＋保守費と並べて行ってください。
個別開発が向かないのはどんな場合か。
次の3つのいずれかに当てはまる場合、業務単位の個別開発は適しません。①基幹システム（ERP・生産管理）の刷新や重い連携が必須である — 大規模なシステム構築の領域です。②オンプレミス必須のセキュリティポリシーがある — クラウド前提の開発では要件を満たせません。③全社数百人へ一斉に導入する — まず部門単位に分けて進める方が確実です。これらに該当する場合は、対象範囲を絞り直すか、別の進め方を検討してください。
生成AIを使えば開発は安く速くできるのではないか。
作る工程は速くなりますが、費用全体が同じ割合で下がるとは限りません。システムの費用は、作る作業だけでなく、業務要件を確定させる作業、既存業務からの移行、運用開始後の修正で構成されます。このうち要件確定と移行は現場との調整が中心で、生成AIでは短縮しにくい部分です。一方、試作を早く作って現場に見せられるようになったため、「作ってから合わないことが分かる」失敗は減らせます。安くなるかより、早く確認できるようになった点を活かす方が実利があります。
開発会社を選ぶとき、何を確認すればよいか。
同業種・同規模の実績と、運用開始後の体制の2点です。実績は「業種が同じか」より「業務の型が同じか」を見てください（現場記録の電子化と、社内向け管理画面の開発では必要な経験が異なります）。運用開始後については、誰が修正を受け付けるか、月あたりどの程度の対応が費用に含まれるか、担当者が変わったときの引き継ぎがどうなるかを、契約前に文書で確認してください。作って終わりの前提で見積もられていると、稼働後に費用が読めなくなります。
作った後の保守は誰がやるのか。
契約前に決めておく必要があります。保守には、障害対応、外部サービスの仕様変更への追随、業務変更に伴う機能修正の3種類があり、それぞれ費用の扱いが違います。特に3つ目は、業務が変われば必ず発生するため、年間でどの程度の修正を見込むかを最初に想定しておいてください。自社でコードを引き取って内製保守する選択肢もありますが、その場合は開発時点でソースコードの権利と引き渡し方法を契約に含める必要があります。
要件定義は自社でやる必要があるか。
全部を自社で書く必要はありませんが、対象業務の現状と「変わったと言える状態」は自社でしか決められません。開発会社が代行できるのは、それをシステムの仕様に翻訳する部分です。自社で用意すべきものは、現在使っている帳票・ファイルの実物、業務の手順と関係者、判断が発生する箇所、そして完了条件の4点です。これが曖昧なまま進むと、出来上がったものが現場の実態と合わず、作り直しになります。
既存の基幹システムと連携できるか。
連携できるかは、基幹システム側が外部からのデータの受け渡し口を持っているかで決まります。持っていない場合でも、CSVの書き出し・取り込みで足りることが多く、まずその方法で必要な頻度を満たせるかを確認してください。リアルタイムの双方向連携が必須になると、費用と期間が大きく変わります。連携の要否は「便利かどうか」ではなく「転記が発生しているか」で判断してください。転記がないなら連携は不要です。
まずPoC（試作）から始めるべきか。
何を確かめるための試作かが決まっているなら有効です。決まっていない試作は、動くものができた時点で「次に何をすればよいか分からない」状態になります。確かめる価値があるのは、技術的に成立するか不明な部分（例: 自社の現場の騒音下で音声入力の精度が出るか、自社の帳票の読み取り精度が実用に足りるか）です。逆に、画面の使いやすさや業務の流れの妥当性は、試作より現場での聞き取りで確認する方が速く済みます。
社内で内製すべきか、外注すべきか。
内製の判断は、作れるかではなく続けられるかで決めてください。作る能力がある社員が一人いる場合、その人が異動・退職した時点で保守できなくなり、ブラックボックスが残ります。内製が向くのは、複数人で開発を担当でき、業務が頻繁に変わり、外部への都度発注では速度が出ない場合です。一方、外注は費用が明確になる代わりに、細かな変更のたびに調整が発生します。実務では、変更頻度の高い部分を内製、基盤部分を外注と分けることもできます。
クラウドに業務データを置いて大丈夫か。
多くの中小企業の業務データでは選択肢になりますが、確認すべき点があります。①取引先との契約に、データの保管場所や再委託に関する条項がないか②個人情報を含む場合、取得時の利用目的と第三者提供の扱いが整理されているか③事業者側の障害時に業務を止めずに済む手段があるか。特に①は、発注元の大企業から要件が課されている場合があるため、既存契約を確認してください。オンプレミスが必須と判断される場合は、選べる実装手段が大きく変わります。
導入に失敗する典型的なパターンは何か。
最も多いのは、ツールを先に決めてから業務を合わせようとするパターンです。この順序だと、合わない部分が運用の例外として残り、その例外を紙や口頭で処理するため、旧来の業務が併存します。次に多いのが、記録だけをデジタル化して集計を手作業のまま残すパターンで、転記が減らないため効果が出ません。3つ目は、導入前の数値を測っていないために効果を説明できず、次の投資判断ができなくなるパターンです。
関連記事
ほかの領域のFAQ
この内容を自社にあてはめて相談する
回答は一般的な判断軸です。自社の業務・規模・時期にあてはめた整理が必要な場合は、 60分の無料相談で対応しています。
相談する（無料）