業務システムは作るか、買うか｜既製で足りる条件と、作る判断の分岐点

業務システムの検討は、たいてい「既製のサービスを見たが、自社の業務に合わない」から始まります。しかし合わないと感じた業務が、本当に自社固有のものかを先に確かめてください。

多くの場合、合わない理由は業務そのものではなく手順の細部です。承認の順番、帳票の項目名、集計の切り口。これらは変えられることが多く、変えられるなら既製サービスで足ります。逆に、変えられない理由が事業の競争力に関わるなら、作る判断が合理的になります。

この記事では、業務が標準的か固有かを判定する方法、費用を5年で比較する計算式、作ると決めた場合に先に決めること、そして途中で止められる進め方を整理します。

「合わない」の中身を分解する

上から5行は合わせられる可能性が高いものです。特に1行目と2行目は、既製サービスの導入時に必ず出てきますが、業務の本質ではありません。

作る判断に進むべきなのは6行目だけです。それも「他社と違う」ではなく「他社と違うことが競争力になっている」場合に限ります。単に昔からそうしているだけなら、変えるほうが安く済みます。

既製に業務を合わせるという選択肢

検討の初期に見落とされるのが、システムを業務に合わせるのではなく、業務をシステムに合わせるという選択肢です。

4行目が現実的な壁です。現場は既存の手順を変えたがりません。しかしこの抵抗は一度きりで、6行目の属人化は長期にわたって残ります。

作ったシステムは、作った人が離れると誰も触れなくなることがあります。この状態は、機能が足りないことより深刻です。

作る判断が合理的になる4つの条件

1. その業務が事業の競争力そのものである：他社と同じやり方では成立しない
2. 既製サービスを実際に使ったうえで、具体的な不足が確定している：想像ではない
3. 保守できる体制がある：社内か、継続的に依頼できる相手がいる
4. 5年で見た費用が既製を下回る：計算で確認している

2番目が最も重要です。使う前に作ると決めると、必要のない機能を要件に入れてしまいます。実際に運用すると、想定していた不足が問題にならず、想定していなかった不足が出てくることがあります。

3番目を軽視すると、作った直後は良くても数年後に困ります。誰も触れないシステムは、機能が足りないシステムより扱いにくくなります。

5年で費用を比較する

初期費用だけで比べると判断を誤ります。次の表を5年分で埋めてください。

5行目は見落とされがちです。制度や取引先の仕様が変わったとき、既製サービスは提供元が対応しますが、作った場合は自社の費用になります。これが毎年発生しうる点を計算に入れてください。

そのうえで、金額が近い場合は既製を選ぶほうが安全です。作る場合の見積は下振れしにくく、想定より膨らむことのほうが多くなります。

作る場合に先に決めること

• 何を解決するか：1文で書ける状態にする
• 誰が毎日使うか：使う人が要件を確認しているか
• やらないこと：最初の版に含めない範囲
• データの持ち方：後から出力できる形式か
• 保守の担当：作った後、誰が面倒を見るか
• 止める条件：どうなったら中止するか

3番目が最も効きます。「あれもこれも」と広げた要件は、期間と費用を膨らませたうえに、使われない機能を増やします。最初の版に含めない範囲を明文化してください。

4番目については、将来の乗り換えや連携に関わります。作ったシステムからデータを出せない状態は、既製サービスの囲い込みと同じ問題を自社で作ることになります。更新のしやすさを含めた設計の考え方は更新しやすい企業サイトの作り方｜CMS選定と運用設計のポイントと共通します。

途中で止められる進め方

1. 既製サービスで3か月運用する：不足を具体化する
2. 不足を一覧にして、優先順位をつける
3. 最も困っている1つだけを対象にする：全体を作らない
4. 小さく作って現場で使う：使われるかを確認する
5. 使われたら次へ広げる：使われなければそこで止める

この順序なら、途中で止めても損失が限定されます。最初から全体を設計して一括で作ると、使われないと分かった時点で全額が無駄になります。

5番目の「使われなければ止める」を最初に合意しておくことが重要です。止める条件がないプロジェクトは、うまくいっていなくても続きます。

よくある失敗

既製サービスを使わずに作ると決める

不足が具体化していない状態で要件を決めることになります。まず3か月運用してください。

要件を広げる

期間と費用が膨らみ、使われない機能が増えます。最初の版に含めない範囲を明文化してください。

使う人が要件を確認していない

完成後に使われません。毎日使う人に、設計の段階で確認してもらってください。

保守の担当を決めずに作る

作った人が離れると誰も触れなくなります。機能が足りないことより深刻です。

初期費用だけで比較する

運用と対応の費用が抜けます。5年分で比べてください。

よくある質問

既製サービスの月額が高く感じます

人数や件数で計算してみてください。作る場合の開発費と保守費を5年で割ると、月額に換算できます。この形にすると比較が成立します。

複数の既製サービスを組み合わせるのはどうですか

有効な場合があります。ただし連携の設定と、どちらのサービスの障害でも業務が止まる点は考慮してください。連携が複雑になるほど、作る場合との差は縮まります。

業務の可視化から始めるべきですか

必要ですが、詳細に書き出しすぎると着手が遅れます。まず一番困っている業務を1つ選び、その前後だけを整理してください。見積を比べる際の観点はWeb制作の見積書の読み方｜同じ金額が別の買い物になる理由と共通します。

開発を依頼する場合、何を見て選びますか

提案の内容だけでなく、作った後の保守をどうするかを聞いてください。作って終わりの体制だと、数年後に困ります。依頼先の形態による違いはフリーランスと制作会社、依頼するならどちらか｜費用差の正体と発注側に生じる義務を参照してください。

Webサイトと連動させたい場合は

問い合わせや予約のデータを業務側で使う形が一般的です。まずサイト側の受け口を整えてから、連携を検討してください。予約に限った選定は予約システムの選び方｜既製サービスで足りる条件と、作るべき条件で扱っています。

まとめ

業務システムを作るか買うかの検討は、たいてい「既製が自社の業務に合わない」から始まります。しかし合わないと感じた内容の多くは、項目名や承認の順序といった手順の細部で、業務の本質ではありません。これらは変えられることが多く、変えられるなら既製で足ります。

作る判断が合理的になるのは4条件が揃った場合です。その業務が事業の競争力そのものであること、既製サービスを実際に使ったうえで不足が確定していること、保守できる体制があること、そして5年で見た費用が既製を下回ること。特に2番目が重要で、使う前に作ると決めると必要のない機能を要件に入れてしまいます。

費用は5年分で比較してください。初期費用だけで比べると、機能追加、不具合対応、制度変更への対応といった継続的な費用が抜けます。そして金額が近い場合は既製を選ぶほうが安全です。作る側の見積は、想定より膨らむことのほうが多くなります。着手する場合も、最も困っている1つだけを小さく作り、使われなければ止める。この進め方なら損失が限定されます。

当社ではシステム開発において、既製サービスの選定を含めた判断からご相談を承っています。自社の要件を整理したい場合は、資料をダウンロードのうえご活用ください。