業務改善
システム開発は、誰に頼むべきか｜SIer・フリーランス・ノーコード・月額型を「責任の切れ目」で比べる
SIer、開発会社、フリーランス、ノーコード内製、SaaS、月額型。業務システムの依頼先ごとの本当の違いは、技術力でも金額でもなく「責任がどこで切れるか」です。5つの型の責任の切れ目と、失敗が起きる3つの場所、自社に合う型を選ぶ順番、見積もりの前に聞くべき3つの質問まで整理します。
「業務システムを作ろう」と決めたあと、最初に迷うのが「誰に頼むか」です。大手のSIer、中小の開発会社、フリーランス、ノーコードで自分たちで作る、SaaSを入れる、月額型のサービスに任せる。選択肢は多く、それぞれの説明を聞くと、どれも正しく聞こえます。そして多くの会社が、最終的には見積もりの金額で決めます。
先に結論を書きます。依頼先ごとの本当の違いは、技術力でも金額でもなく、「責任がどこで切れるか」です。要件が間違っていたとき、納品後に業務が変わったとき、担当者がいなくなったとき。そのとき誰の責任で、誰の費用で直すのか。この線の引かれ方が依頼先の型ごとに違い、システム導入の失敗のほとんどは、この線が切れている場所で起きています。この記事では、依頼先を5つの型に分け、それぞれの責任の切れ目を比べたうえで、自社に合う型を選ぶ順番を整理します。
依頼先は5つの型。違いは技術力ではなく「責任の切れ目」
まず、依頼先を5つの型に分けます。会社の規模や知名度ではなく、「契約上、相手が何に責任を持ち、どこから先が自社の責任になるか」で分けたものです。同じ「開発会社」でも、一括請負で受けるのか、月額で運用まで持つのかで、型は変わります。
| 依頼先の型 | 相手の責任が切れる場所 | 費用の型 | 向いている会社 |
|---|---|---|---|
| ① SIer・開発会社（一括請負） | 仕様書どおりに作って納品した時点。仕様の正しさは発注側の責任 | 初期費用が大きく、納品後は保守契約で別途 | 要件を自社で書き切れて、業務がしばらく変わらない会社 |
| ② フリーランス（個人） | その人の稼働と契約期間まで。相手の事情で、そこから先が消えることがある | 単価は安く、稼働時間や案件単位で支払う | 規模が小さく仕様が明確で、社内に技術を分かる人がいる会社 |
| ③ ノーコード・AIで自社で作る（内製） | 切れ目はない。設計も運用も、全部が自社の責任 | ツール利用料と、作る人の時間 | 作れる人が社内にいて、引き継ぎの形まで用意できる会社 |
| ④ SaaSを導入する | 道具の提供まで。自社業務への当てはめと運用は、導入側の責任 | 月額利用料。設定支援は別途のことが多い | 業務が標準的で、ツールに合わせて業務を変えられる会社 |
| ⑤ 月額型のオーダーメイド（運用込み） | 契約が続く限り切れない。要件・開発・運用・改修が同じ相手の責任 | 初期費用を抑えた月額。改修が含まれるかは契約による | 業務が変わり続け、社内にIT担当がいない会社 |
表の2列目に注目してください。①は「仕様書どおり」で責任が切れます。仕様書に書いてあることが正しく動いていれば、契約上の仕事は完了です。仕様書の中身が業務に合っていなかったとしても、契約の形にもよりますが、原則として仕様を確定した発注側の責任として扱われます。②は相手が個人なので、責任の範囲はその人の稼働と契約期間の中に収まります。③は責任の切れ目がない代わりに、全部が自社の肩に乗ります。④は道具の提供までが相手の責任で、その道具を自社の業務にどう当てはめるかは、買った側の仕事として残ります。⑤だけが、契約が続く限り責任が切れない構造になっています。
どれが優れているという話ではありません。①〜④は、それぞれの切れ目の先を自社で持てる会社にとっては、合理的で安い選択肢です。問題は、自社がその切れ目の先を持てるかどうかを確かめずに、金額と評判で選んでしまうことです。
責任が切れた場所で、失敗は起きる
システム導入の失敗が「技術的に動かなかった」という形で起きることは、ほとんどありません。動いてはいる。でも使われない。使われてはいるが、業務の変化に追いつかず、少しずつExcelに戻る。こうした失敗は、責任の線が切れている場所で、決まった形で起きます。切れ目は大きく3つです。
| 責任の切れ目 | そこで起きること | 損をする側 |
|---|---|---|
| 要件定義と開発の間 | 業務を知らない相手が、発注側の書いた要件をそのまま作る。出来上がって初めて「これでは回らない」と分かるが、仕様どおりなので追加費用になる | 要件を書いた発注側 |
| 納品と運用の間 | 検収が終わった瞬間から、項目の追加や画面の修正がすべて「別料金の改修」になる。頼むのが億劫になり、現場が業務をシステムに合わせるか、Excelに戻る | 使い続ける現場 |
| 相手がいなくなる | フリーランスの廃業、開発会社の担当交代、SaaSの終了や値上げ、内製した社員の退職。中身を知る人が消え、誰も触れないシステムが残る | 残された会社 |
1つめの切れ目は、要件定義と開発の間です。一括請負では、「何を作るか」を確定させてから開発に入ります。この確定の責任は、原則として発注側にあります。しかし、システムを初めて作る会社が、自社の業務を漏れなく仕様に落とすのは、ほとんど不可能です。現場の例外処理、月末だけ発生する作業、口頭で回っている承認。こうしたものは、出来上がったシステムを使い始めて初めて見えてきます。そのとき「仕様どおりです」と言われる構造になっているかどうかが、この切れ目の正体です。
2つめは、納品と運用の間です。検収が終わると、システムは「完成品」として扱われます。以降の変更は、たとえ項目を一つ足すだけでも、見積もりと発注の手続きを経た改修になります。金額の問題だけではなく、「頼む手間」が発生することが本質です。現場は小さな不便を一つひとつ頼まなくなり、手元のExcelで補い始めます。数年後、システムの外側に第二の業務フローができあがっていて、「システムはあるが、実態はExcel」という状態になります。
3つめは、相手そのものがいなくなる切れ目です。フリーランスは事業をやめることがあり、開発会社は担当者が変わり、SaaSはサービスを終了したり大幅に値上げしたりすることがあります。社内で作った場合も同じで、作った社員が辞めれば、中身を知る人がいなくなります。この切れ目は契約書に書かれていないことが多く、起きてから気づきます。だから契約前に、「あなたがいなくなったら、このシステムはどうなりますか」と聞いておく必要があります。
判断の順番：金額の前に、「自社に何が残せるか」を決める
5つの型のどれを選ぶかは、相手の良し悪しではなく、自社側の条件で決まります。見積もりを取る前に、次の3つを自分たちに問うてください。答えによって、選ぶべき型はほぼ絞られます。
1つめ。「要件を、自分たちで書き切れるか」。業務のフローを図にでき、例外まで含めて仕様の形に落とせる人が社内にいるなら、①の一括請負でも問題は起きにくい。書き切れないなら、要件を一緒に考えてくれる相手、つまり要件定義の段階から相手の責任として入ってもらえる型（⑤、または要件定義を工程として引き受ける①）が必要です。ここを自覚せずに一括請負を選ぶと、1つめの切れ目で確実に損をします。
2つめ。「導入したあと、社内で触れる人がいるか」。設定を変えられる、不具合を切り分けられる、ベンダーと技術的な会話ができる。そういう人がいるなら、③や④の選択肢が現実味を持ちます。いないなら、運用の責任を外に置ける型を選ぶべきで、これは③を選んではいけないという意味でもあります。作れる人がいない会社の内製は、作った瞬間に誰も触れないシステムを生みます。
3つめ。「この業務は、今後も変わるか」。取引先が増える、人が入れ替わる、扱う商品が変わる、といった変化が今後も続くなら、納品で責任が切れる①は、2つめの切れ目で費用がかさみ続けます。逆に、法令や計算ルールで固まっていて数年は変わらない業務なら、一括で作り切る方が総額は安くなることが多い。変わる業務には改修が契約に含まれる型を、変わらない業務には作り切る型を、という対応です。
一括請負が悪いわけではない
ここまで読むと、一括請負に不利な書き方に見えるかもしれませんが、そうではありません。要件が固まっていて、社内に要件を書ける人がいて、しばらく業務が変わらない。この3つが揃う会社にとって、一括請負は最も安く、最も確実な選択肢です。責任の切れ目がはっきりしているということは、裏を返せば、自社側で持つべき責任が明確だということでもあります。持てる会社にとっては、その明確さが利点になります。
危ないのは、3つが揃っていないのに、「大手だから」「見積もりが一番安かったから」という理由で一括請負を選ぶ場合です。とくに、すでに動いているシステムを作り直す局面では、フルスクラッチの見積もりが高額になって断念し、SaaSにも合わず、AIで自作しても一部の改善で止まる、という手詰まりが起きやすい。この構造は既存システムを作り直したいのに手詰まりになる理由で別に整理しています。
見積もりを比べる前に、聞くべき3つの質問
依頼先の型が絞れたら、候補に見積もりを頼むことになります。ただし、金額を並べる前に、責任の切れ目を確かめる質問を3つ、それぞれの候補にしてください。答え方で、その相手がどの型なのかがはっきりします。
- 「要件が業務に合っていなかったと後で分かったら、どちらの責任で、どちらの費用で直しますか」。要件定義と開発の間の切れ目を確かめる質問です。「仕様確定後の変更は別途見積もり」と即答されるなら、それは①の型です。悪い答えではありませんが、その前提で自社が要件を書き切れるかを考えてください。
- 「納品のあと、項目を一つ足したいときは、いくらで、どのくらいの期間で対応しますか」。納品と運用の間の切れ目を確かめる質問です。月額に含まれるのか、都度見積もりなのか、最低発注額はあるのか。ここが曖昧な相手は、導入後に頼みにくくなります。
- 「御社（あなた）がいなくなったら、このシステムはどうなりますか」。相手の消失に備える質問です。ソースコードとデータの所有権、設計書の有無、他社が引き継げる形になっているか。月額型を選ぶ場合はとくに、解約時にシステムとデータがどう扱われるかを、この質問で確かめてください。
3つの質問への答えが出揃ってから、初めて金額を比べます。同じ型の相手同士なら金額の比較に意味がありますが、型が違う相手の金額を並べても、責任の範囲が違うので比べたことになりません。費用の目安そのものについては、規模別の価格帯と見積もりが膨らむ仕組みを業務システム開発の費用相場にまとめています。
よくある質問
- Q.SIerと中小の開発会社とフリーランスは、何が違うのですか？
- A.技術力の差というより、責任の持ち方と体制の差です。SIerと開発会社は会社として契約するので、担当者が変わっても契約上の責任は会社に残ります。一括請負なら「仕様書どおりに納品する」ところまでが責任範囲です。フリーランスは個人との契約なので、単価は安い一方、責任の範囲はその人の稼働と契約期間の中に収まり、相手の事情で継続できなくなるリスクを発注側が持ちます。
- Q.フリーランスに頼むのは危険ですか？
- A.仕様が明確で規模が小さく、社内に技術を分かる人がいるなら、コストの面で最も合理的な選択肢になり得ます。危険になるのは、要件から丸ごと任せて、納品後の運用まで暗黙のうちに期待している場合です。相手がいなくなる切れ目に備えて、ソースコードと設計書の受け取り、データの所有権、他の人が引き継げる形になっているかを、契約前に確認してください。
- Q.ノーコードで自社で作るのは、ありですか？
- A.作れる人が社内にいて、その人が辞めても引き継げる形にできるなら、ありです。責任の切れ目がない代わりに、設計の責任も運用の責任も全部が自社に乗ります。作った本人にしか分からないシステムになりやすく、その人が退職した瞬間に誰も触れなくなるのが典型的な失敗です。小さな業務の一部から始めて、基幹となる業務には安易に広げないのが現実的です。
- Q.月額型のオーダーメイドにデメリットはありますか？
- A.あります。契約が続く限り費用が発生すること、解約時にシステムやデータがどう扱われるかが契約によって異なること、そして相手への依存度が高くなることです。だからこそ月額型を選ぶときは、月額に何が含まれるか（改修の範囲）、解約時のシステムとデータの扱い、相手が事業を続けられる体制かを、契約前に確認する必要があります。
- Q.相見積もりは何社から取ればいいですか？
- A.数よりも、「同じ型の相手同士で比べているか」の方が重要です。一括請負の会社と月額型のサービスの金額を並べても、責任の範囲が違うので比較になりません。まず自社に合う型を1つに絞り、その型の中で2〜3社に、責任の切れ目を確かめる同じ質問をして、答えと金額を並べる。これが意味のある相見積もりです。
「誰に頼むか」は、相手の技術力や金額で決める問題ではなく、「自社が責任を持てるのはどこまでか」で決める問題です。要件を書き切れるか、導入後に触れる人がいるか、業務は変わり続けるか。この3つに正直に答えれば、5つの型のどれが合うかはほぼ決まります。そのうえで、責任の切れ目を確かめる3つの質問を候補に投げ、同じ型の中で金額を比べる。この順番で選べば、動いているのに使われないシステムを抱える確率は、大きく下がります。