システム化を依頼する会社を選ぶときに確認したいポイント

業務をシステム化するとき、依頼先には何を確認すればよいのでしょうか。提案資料だけでは分かりにくい業務理解、担当体制、説明の仕方、成果物、セキュリティ、問題発生時の対応を、検討初期の確認ポイントとして整理します。

この記事でわかること

  • システム開発会社を比較する前に自社で決める評価基準が分かります
  • 提案、担当体制、成果物、セキュリティ、報告方法の質問例が分かります
  • 提案資料だけで決めず、同じ前提で比較する進め方が分かります

提案資料だけではシステム開発会社を選べない

複数のシステム開発会社へ相談すると、専門用語や提案資料の見栄えに目が向きます。しかし、資料が分かりやすいことと、自社の業務を正しく理解して進められることは同じではありません。確認したいのは、自社の業務課題をどう捉えたか、誰が担当するか、どの成果物を残すか、問題が起きたときにどう報告するかです。

先に確認基準を決めずに話を聞くと、相手ごとに異なる観点で説明され、違いが分かりにくくなります。開発を依頼する場合は、「自社が譲れない条件」と「相談先に提案してほしい項目」を分けることが重要です。

比較できない原因は提案の前提が揃っていないこと

システム開発会社の提案を比較できない原因は、候補会社の能力だけにあるとは限りません。候補ごとに伝えた業務範囲や制約が違う、社内の評価基準が決まっていない、決裁者が提案を確認していないといった発注側の条件も影響します。

提案内容を比べるには、背景、目的、対象業務、利用者、必須条件、希望時期、既存システムとの関係を同じ前提で渡します。 評価基準は、業務理解、説明の分かりやすさ、担当体制、成果物、テストと受け入れ、保守、セキュリティ、問題発生時の報告などに分けられます。

評価基準を先に決めると、見栄えや一時的な印象だけで判断しにくくなります。たとえば、担当者の役割が提案書に書かれていても、設計、開発、テスト、導入後の問い合わせを誰が担うかまで確認しなければ、実際の体制は判断できません。

質問への回答が具体的か、前提条件やできないことも説明しているかを記録し、社内で同じ表を見ながら比較します。説明を聞いた担当者だけが理解して終わらないよう、業務責任者や決裁者へ要点を共有し、判断が必要な項目を残します。提案の段階で確認できない内容は、契約前に確認する事項として一覧化します。

提案前に評価基準と質問を決める

提案を受ける前に、次の質問を用意します。

  1. 自社の業務課題をどのように理解し、要件へ反映しますか
  2. プロジェクト責任者、日常の窓口、設計・開発・テスト・保守の担当者は誰ですか
  3. 要件定義書、設計書、テスト結果、操作説明など、どの成果物が残りますか
  4. セキュリティ仕様はいつ確定し、実装を見送る対策はどこに記録しますか
  5. 障害や仕様変更が起きたとき、誰がいつどのように報告しますか
  6. 受託開発型とパッケージ・SaaS活用型のどちらを前提にしていますか

すべての候補へ同じ質問をし、回答の具体性と確認方法を比べます。提案段階で不明点を質問しやすいか、分からないことを分からないと説明できるかも、進行中の連携を考えるうえで重要な材料です。あわせて、自社と近い業務領域や規模の案件で、どの範囲を担当し、導入後の保守や引き継ぎをどう行ったかを確認します。

実績の件数だけでなく、担当範囲と残した成果物を聞くと、自社の条件に合うか判断しやすくなります。

比較軸を決めないと選定後に認識がずれる

評価基準がないまま選定すると、提案資料の印象や一部の機能だけで判断し、業務理解や担当体制を確認しないまま契約へ進むことがあります。開発が始まってから、想定していた担当者が参加しない、成果物の説明がない、セキュリティの確認時期が決まっていないと分かれば、発注側の確認負荷が増えます。

また、候補ごとに異なる前提で提案を受けると、提案の違いが前提条件の差なのか、進め方の差なのかを説明できません。提案の比較は、候補を減らす作業ではなく、自社が何を重視して相談先を選ぶかを確認する作業です。口頭で確認した内容を記録せず、提案書だけで判断することも、後の認識差につながります。

選定時に確認しなかった事項は、契約後に追加確認となり、担当者やスケジュールの前提を変える可能性があります。候補を決める前に、評価表の空欄を「未確認」として残し、最終判断者が確認できる状態にしてください。

特に、テストへの参加者、データ移行の責任者、納品後の窓口は、提案資料の機能一覧だけでは判断できません。候補会社へ具体的な確認方法と成果物を質問し、回答が曖昧な項目は社内の懸念として共有します。

評価表を作り、提案の前提を揃えて相談する

まず、自社の評価基準を「必須条件」「確認したい条件」「提案を求める条件」に分けます。次に、候補のシステム開発会社へ同じ業務概要と質問を渡し、回答、担当体制、成果物、確認方法を記録します。類似案件の有無だけでなく、担当範囲、残した成果物、保守・引き継ぎの方法も確認し、評価表へ記録します。

評価表には、誰が評価し、誰が最終決定するかも記載してください。 相談前の業務課題や要件が整理できていない場合は、先に要求整理を行います。依頼先選びを急ぐより、自社の課題と判断条件を整えた方が、説明を比べやすくなります。

表には、業務理解、担当体制、成果物、テスト、セキュリティ、報告、保守の確認結果と、追加で質問する事項を残します。話を聞いた後は、事業責任者、業務責任者、利用部門など関係者の意見を確認し、決める人が理由とともに判断を記録します。

採用した条件だけでなく、見送った提案とその理由も残すと、後から担当者が変わっても、何を重視したのかを確認できます。まだ比較する段階でなければ、まずは相談先へ確認したい質問を整理するだけでも構いません。

まとめ

システム開発会社を選ぶときは、提案資料の見栄えや専門用語の多さだけでなく、業務理解、評価基準、担当体制、成果物、セキュリティ、問題発生時の報告方法を比較します。発注側の前提情報と質問を揃えることが、選定後の認識差を減らします。

よくある質問

技術用語を理解できなくてもシステム開発会社を選べますか?

選べます。業務理解、説明の分かりやすさ、担当体制、成果物、確認方法など、発注側が確認できる基準を先に決めてください。

何社に相談すべきですか?

一律の社数に正解はありません。比較が成立するよう、同じ前提情報と評価基準で複数の提案を確認することが重要です。

提案資料だけで判断してよいですか?

提案資料だけでなく、業務理解の確認方法、担当体制、成果物、テスト、保守、問題発生時の報告方法まで確認してください。

担当者が途中で変わる場合、引き継ぎはどうなりますか?

引き継ぐ資料、共有する情報、責任者、確認方法を相談前に確認してください。設計やテストの成果物が残るかも重要です。

自社の課題を具体的に整理する

依頼先へ確認する条件を整理するお問い合わせ