システム開発会社を選ぶとき、多くの会社が最初に気にするのは「開発費用」や「納期」だと思います。
もちろん、金額やスケジュールは外せないポイントです。ただ、業務システムの開発では、そこだけで決めてしまうと、あとから「思っていたものと違う」「追加費用が増えた」「納品後に誰も直せない」といった問題につながりやすくなります。
特に中小企業の場合、社内に専門のIT担当者がいないことも多く、ベンダー選びの段階で何を確認すればよいのか分かりにくい場面がよくあります。
この記事では、システム開発のベンダーを選ぶときに確認しておきたいポイントを、実務目線で整理します。
システム開発会社選びで大事なのは「作れるか」だけではない
システム開発会社を選ぶときに、最初に見たいのは「この会社は開発できるか」だけではありません。
もちろん、技術力は必要です。ただ、業務システムの場合は、次のような点も見ておきたいところです。
- 会社の業務内容を理解する力
- 現場の流れを整理する力
- 必要な機能と不要な機能を見極める力
- 納品後の運用まで考える力
- トラブル時に責任を持って対応する力
つまり、単にプログラムを作れるだけでは十分とは言い切れません。
中小企業の業務システムでは、「業務を分かってくれるか」「自社に合った形で提案してくれるか」「長く使える状態で納品してくれるか」まで見ておくと判断しやすくなります。
要件定義を丁寧に行う会社か確認する
ベンダー選びでまず確認したいのは、要件定義への姿勢です。
要件定義とは、簡単に言えば「どの業務を、どのようなシステムで実現するのか」を整理する作業です。
ここが曖昧なまま開発を始めると、完成後に「この機能が足りない」「現場の流れに合わない」「結局Excelのほうが使いやすい」といった話になりがちです。
質問が少ない会社は注意が必要
実務上、まず気をつけて見ておきたいのは、あまり質問をせずに「できます」「作れます」とすぐに答える会社です。
一見すると頼もしく見えるかもしれませんが、業務システムは会社ごとに運用が違います。帳票の出し方、承認の流れ、入力担当者、確認するタイミング、例外処理など、細かい部分まで確認しないと、現場で使いやすい形にはなりません。
むしろ、最初に細かく質問してくる会社のほうが、安心して進めやすい場合があります。
要件定義の段階では、少なくとも次のような点を確認してくれるかを見ておくとよいです。
- 現在の業務フローを確認してくれるか
- 誰が、いつ、何を入力・確認するのかを聞いてくるか
- 例外処理やイレギュラー対応まで確認するか
- 既存データの移行方法を確認するか
- 納品後の運用担当者まで考えてくれるか
このあたりをあまり確認しないまま進めようとする場合は、少し慎重に見たほうがよいです。
見積書は金額よりも「中身」を見る
複数のベンダーから見積もりを取ると、どうしても金額に目が行きがちです。
ただし、システム開発の見積もりは、単純に安い・高いだけで比べないほうが現実的です。見ておきたいのは、その金額の中に何が含まれていて、何が含まれていないかです。
たとえば、見積もり上は安く見えても、要件定義、テスト、データ移行、操作説明、マニュアル作成、納品後の修正対応が別料金になっている場合があります。
見積書を見るときは、次のような項目が具体的に書かれているか確認しておきたいところです。
| 確認項目 | 確認したい内容 |
|---|---|
| 要件定義 | 業務内容の整理や仕様の確定作業が含まれているか |
| 設計 | 画面設計、データ設計、処理の流れが明確にされるか |
| 開発 | どの機能をどこまで作るのかが具体的に書かれているか |
| テスト | ベンダー側のテスト、利用者側の確認期間があるか |
| データ移行 | 既存データの移行作業が含まれているか |
| 操作説明 | 利用者向けの説明やマニュアル作成が含まれているか |
| 保守 | 納品後の不具合対応や軽微な修正の範囲が明確か |
見積書に「一式」という表現が多い場合も、内容をよく確認しておきたいところです。
一式という書き方自体が悪いわけではありません。ただ、何をどこまで対応してくれるのかが分からないと、あとから追加費用や認識違いにつながりやすくなります。
納品物を事前に明確にしておく
システム開発では、完成した画面や機能だけを納品物と考えないほうが安心です。
将来の保守、改修、トラブル対応を考えると、関連資料や管理情報も必要になります。
最低限、次のようなものが納品対象に含まれるのか確認しておきたいところです。
- システム本体
- 管理画面
- ソースコード
- データベース構成
- 設計書
- 操作マニュアル
- サーバーやクラウド環境の情報
- ID・パスワードなどの管理情報
- バックアップや復旧に関する手順
特に確認しておきたいのは、ソースコードや管理情報の扱いです。
ここが曖昧なまま進めてしまうと、将来ベンダーを変更したくなったときに、他社が引き継げない状態になることがあります。
「システムは使えているけれど、中身が分からない」「サーバー情報が分からない」「前の会社に聞かないと何もできない」という状態は、中小企業にとって大きなリスクです。
著作権・利用権・ソースコードの扱いを確認する
システム開発で意外と見落とされやすいのが、権利関係です。
発注側としては「お金を払って作ってもらうのだから、自社のものになる」と考えがちです。ただ、契約内容によっては、ソースコードが納品されなかったり、他社に保守を依頼できなかったりするケースがあります。
実際には、次のようなトラブルにつながることがあります。
- ソースコードは納品対象外だった
- 他社への引き継ぎを断られた
- 契約終了後の利用条件が曖昧だった
- 改修は開発会社にしか依頼できない状態だった
- 自社専用だと思っていた仕組みが、実はベンダー側のサービスだった
業務システムの場合、必ずしも著作権をすべて自社に譲渡してもらう必要があるとは限りません。
ただし、少なくとも自社業務で継続利用できる権利、契約終了後の利用可否、他社への引き継ぎ可否、ソースコードや管理情報の扱いは、契約前に整理しておきたいところです。
開発体制と責任者を確認する
営業担当の印象がよくても、実際に開発する人が別会社や外部委託先というケースはあります。
それ自体が悪いわけではありません。確認したいのは、誰が責任を持つのかが曖昧なまま進まないかです。
開発体制については、次のような点を確認しておくと安心です。
- 実際に開発するのは誰か
- プロジェクト責任者は誰か
- 日々の連絡窓口は誰か
- 外注や再委託はあるのか
- 再委託がある場合、責任範囲はどうなるのか
- 担当者が退職・変更した場合の引き継ぎ体制はあるのか
中小企業向けのシステム開発では、担当者個人に依存していることも少なくありません。
その担当者がいる間は問題なくても、退職や異動によって急に対応が悪くなることがあります。会社として引き継げる体制があるかどうかは、先に確認しておくほうが安心です。
スケジュールが現実的かを見る
開発期間が短い提案は、どうしても魅力的に見えます。
ただ、業務システムなのに「すぐできます」「1か月で作れます」「細かいことは作りながら決めましょう」といった進め方の場合は、少し慎重に見たほうが安心です。
システム開発には、要件定義、設計、開発、テスト、修正、操作説明、本番移行といった工程があります。
この工程を十分に取らないまま進めると、納品直前や運用開始後に問題が集中しやすくなります。
スケジュール面では、次のような点を確認しておくと判断しやすくなります。
- 要件定義の期間が確保されているか
- 画面や仕様を途中で確認できるか
- テスト期間があるか
- 本番移行前の確認期間があるか
- 遅延時の報告ルールがあるか
- 納期が遅れた場合の対応方法が決まっているか
開発は、予定通りに進まないこともあります。
そのため、最初から進捗報告の頻度や遅延時の対応ルールを決めておくと安心です。
保守・運用まで考えている会社を選ぶ
システムは、完成してからの運用も大きなポイントです。
運用を始めると、操作方法の質問、不具合、業務変更、帳票の修正、担当者の変更、法改正への対応など、いろいろな対応が出てきます。
そのため、開発費だけでなく、保守・運用体制も先に確認しておきたいところです。
保守については、次のような内容を確認しておくと判断しやすくなります。
- 障害時の連絡先
- 対応時間
- 月額保守費用の範囲
- 軽微な修正の扱い
- バックアップの有無
- サーバーやクラウド環境の管理範囲
- セキュリティ更新の対応
- データ復旧の対応
業務の中心になるシステムであれば、保守契約なしで運用するのはできれば避けたいところです。
「作った会社に連絡がつかない」「不具合が出たが直せない」「サーバーの管理者が分からない」という状態になると、業務そのものに影響が出てしまいます。
パッケージ利用か、完全オーダー開発かを確認する
最近は、既存のパッケージや自社サービスをベースにして、そこにカスタマイズを加える形の開発も増えています。
これは決して悪い方法ではありません。ゼロから作るよりも費用を抑えられたり、開発期間を短縮できたりするメリットがあります。
ただし、自社専用のシステムなのか、ベンダー側のサービスを利用する形なのかは、事前に確認しておきたいところです。
特に、次のような点は確認しておきたいところです。
- 既存パッケージを使うのか
- 完全に自社専用で開発するのか
- 他社にも同じ仕組みを提供する可能性があるのか
- 自社の業務ノウハウが他社向けサービスに使われないか
- カスタマイズ部分の権利はどうなるのか
特に、自社の業務ノウハウをもとに開発する場合は、ベンダー側がその仕組みを他社サービスとして展開できるのかどうかも、必要に応じて確認しておくと安心です。
契約書・仕様書・議事録を軽く扱わない
システム開発では、口約束だけで進めるのは避けたいところです。
打ち合わせでは合意したつもりでも、あとから「そこまでは含まれていません」「追加費用になります」「仕様書には書いていません」となることがあります。
そのため、契約書、発注書、仕様書、議事録はきちんと残しておきたいところです。
契約前には、少なくとも次の項目を確認しておきたいところです。
特に確認しておきたいのは、「何をもって完成とするか」です。
発注側は「まだ使える状態ではない」と思っていても、ベンダー側は「仕様書通りに納品済みです」と考えていることがあります。
この認識のズレを防ぐためにも、検収条件は事前に明確にしておきたいところです。
避けたほうがよいベンダーの特徴
実務上、次のような特徴があるベンダーは慎重に見たほうがよいです。
- 業務内容をあまり聞かずに「できます」と言う
- 見積書に「一式」が多く、内訳が分かりにくい
- 契約書や仕様書を軽く扱う
- ソースコードや管理情報の扱いが曖昧
- 納品後の保守体制が弱い
- 担当者個人に依存している
- 進捗報告が少ない
- 議事録を残さない
- 仕様変更や追加費用のルールが曖昧
- 他社への引き継ぎを嫌がる
この中でも特に気をつけて見ておきたいのは、質問が少ない会社です。
業務システムでは、発注側自身も要件を整理しきれていないことがよくあります。そのため、信頼できる会社ほど、最初に細かく確認してきます。
よいベンダーは、耳の痛いことも言ってくれる
よいベンダーは、発注者の要望をそのまま全部受け入れるだけではありません。
必要に応じて、次のようなこともきちんと伝えてくれます。
- その機能は最初から作らないほうがよいです
- まずは小さく始めたほうがよいです
- この業務フローを整理しないと、システム化しても使われません
- この予算では優先順位を決める必要があります
- 運用担当者を決めておかないと、導入後に混乱します
こうした指摘は、発注側にとって少し耳が痛いこともあります。
ただ、システム開発で大事なのは、希望を全部詰め込むことではありません。業務に合った形で、無理なく使い続けられるシステムにすることです。
都合のよいことだけを言う会社よりも、リスクや現実的な課題を先に説明してくれる会社のほうが、長い目で見ると安心して任せやすいです。
まとめ：システム開発会社は「開発力」だけで選ばない
システム開発のベンダー選びでは、価格や納期だけで判断しないことが大事です。
特に中小企業の場合、社内に専門のIT担当者がいないことも多く、ベンダーの提案内容や契約条件をそのまま受け入れてしまうケースがあります。
ただ、業務システムは一度導入すると長く使うものです。開発中だけでなく、納品後の保守、改修、引き継ぎまで考えて選びたいところです。
ベンダー選びで特に確認したいのは、次の5点です。
- 要件定義を丁寧に行うか
- 見積・契約・納品物が具体的か
- ソースコードや権利関係が明確か
- 納品後の保守・運用まで考えているか
- 都合のよい話だけでなく、リスクも説明してくれるか
システム開発では、「作る力」だけでなく、「業務を理解する力」と「運用まで責任を持つ力」も見ておきたいポイントです。
開発会社を選ぶ前に、まずは自社の業務、目的、必要な機能、予算、運用体制を整理しておくと、比較しやすくなります。
IT顧問のITAでは、システム開発会社選びやIT業者とのやり取りを支援しています
IT顧問のITAでは、八王子市を中心に、中小企業・小規模事業所様のIT環境を継続的にサポートしています。
「システム開発会社から提案を受けているが、内容が妥当か判断できない」
「見積書に何が含まれているのか分かりにくい」
「既存システムの引き継ぎや保守体制に不安がある」
「IT業者との打ち合わせに同席して、発注者側の立場で内容を整理してほしい」
このようなお悩みがありましたら、まずはご相談ください。
システム開発会社の選定、見積内容の確認、既存システムの引き継ぎ、IT業者とのやり取りの整理まで、会社の状況に合わせて無理のない形で支援いたします。
