基幹システムの選定の進め方｜決める人が1人でも、ベンダーを同じ軸で比べる

この記事は、従業員10〜20名程度で、情報システムを専任で担当する人がいない中小企業のうち、基幹システムを作り替えることは既に決めた会社に向けたものです。

基幹システムの選び方を解説する記事の多くは、業務部門ごとに担当者を選び、社内にプロジェクトマネージャーを置いて、全社的な合意形成を進める手順を前提にしています（2026年9月16日確認）。決める人が経営者1人、または経営者と現場責任者の2人しかいない会社では、この前提そのものが成り立ちません。RFP（提案依頼書）を書いた経験がなく、複数社の提案を並べて比べる基準もないまま、最初に話を聞いたベンダーの提案がそのまま採用されがちです。

この記事で扱わないのは次の3点です。改修するか刷新するかという入口の判断、特定の製品名やベンダーの優劣についての評価、契約書の条項が自社にとって妥当かどうかの法務的な判断です。契約の条項は、必ず自社の顧問弁護士や専門家に確認してください。

先に結論｜決める人が1人でも進められる形にする

決める人が1人であること自体は、選定の質を下げません。下げているのは、比べる基準がその1人の頭の中にしかなく、書き出されていない状態です。ベンダーごとに話す内容も印象も変わるため、後から並べて比べようとしても記憶が頼りになります。

この記事では3つの道具を作ります。要件定義書の代わりに埋める「質問シート」、複数社を同じ軸で並べる「採点表」、ギャップが出たときに誰がどう判断したかを残す「意思決定の記録」です。3つとも、経営者1人で書き始められる分量にしてあります。専任の担当者や外部コンサルタントを新たに雇う前提は置いていません。

この記事の対象｜刷新を決めた後の話

基幹システムの刷新を決めた後、最初に必要になるのはRFPに相当する情報の整理と、ベンダーの比較です。システムは改修か刷新かは、この手前にある「止められる時間」「戻し方」「仕様書がない場合の対応」までを扱っています。まだこの判断が済んでいない場合は、先にそちらから読み進めてください。

情報システムを専任で担当する人を置かず、何を社内に残し何を外部委託するかという入口の判断は、情シス不在の中小企業がまず整えるもので扱っています。この記事が対象にするのは、刷新の方針が決まり、これから複数のベンダーへ声をかける段階です。要件定義工程そのものを丸ごと外部のコンサルタントへ依頼できる会社であれば、この記事は必要ありません。

手順1｜要件定義の代わりになる1枚の質問シート

正式な要件定義書は、業務部門ごとの担当者がヒアリングを重ねて作ります。その体制がない会社では、代わりに1枚の質問シートを経営者自身が埋めます。目的は網羅ではなく、複数のベンダーへ同じ質問を同じ言葉で投げることです。

項目	確認すること	使う場面
主要業務の流れ	件数が最も多い業務を1つ選び、発生から完了までの順を書き出す	デモで再現してもらう対象になる
例外処理	月に何件、誰が今どう処理しているか	標準機能で吸収できるかの判断材料になる
現行の台帳・帳票	使っている項目の一覧と、現物を1件添付する	画面設計の見積もりに直結する
外部連携	会計・給与など、必ずつながないといけない他システム	連携の可否と追加費用の有無が分かる
データ移行の範囲	過去何年分、何件のデータを移すか	移行費用の見積もりの前提になる
譲れない機能とあきらめてよい機能	経営者が事前に1つずつ○×をつける	ギャップが出たときの判断を早める
予算の範囲	初期費用だけか、5年間の総額かを明示する	見積もりの前提条件をそろえる

1番目の主要業務の流れを書き出す作業は、実測を伴う点で業務棚卸し表の作り方と共通します。件数や所要時間まで含めて書き出せると、デモで再現してもらう業務の説得力が上がります。

6番目の「譲れない機能とあきらめてよい機能」が最も効きます。ギャップが起きてからその場で考えると、話しやすさや押しの強さで判断が決まってしまいます。契約前に自分で○×をつけておけば、デモの場でその場しのぎの判断をせずに済みます。

この作業には公的な裏づけがあります。情報処理推進機構（IPA）の「システム再構築を成功に導くユーザガイド 第2版」第3章「計画策定編」は、RFPを作る前に社内の要求事項をいったん確定させておかないと、プロジェクト開始後に「こんなはずではなかった」「これも入れてほしい」という要望が個別にばらばらと出てきて、大幅な手戻りになると述べています（IPA「システム再構築を成功に導くユーザガイド 第2版」3.2節、2026年9月16日確認）。決める人が1人の会社には、この「ステークホルダ間の合意」を取る相手がそもそもいません。質問シートに答えを書き出す作業が、その合意の代わりを務めます。

手順2｜ベンダーを同じ軸で並べる採点表の作り方

質問シートの回答を持って、複数社（目安は2〜3社）へ提案を依頼します。ここでよくある失敗は、金額だけを見て決めてしまうことです。同じ軸で点数をつける採点表を先に作っておくと、印象ではなく記録で比較できます。

評価軸	確認する内容	配点の目安
業務適合度	質問シートの主要業務を、どこまで標準機能で再現できるか	0〜5点
例外処理の対応	例外を標準機能内で吸収できるか、追加費用が要るか	0〜5点
初期費用	見積もりの総額（消費税・保守込みかを確認）	0〜5点
5年の総額	初期費用に、年間の保守・利用料の5年分を足した金額	0〜5点
データ移行のしやすさ	移行実績の有無、対応形式、追加費用の要否	0〜5点
設定変更のしやすさ	項目や帳票の追加を自社で行えるか	0〜5点
解約時のデータ持ち出し	解約時に全データを標準的な形式で受け取れるか	0〜5点

点数の重みは会社によって違います。迷ったときは、業務適合度とデータ移行のしやすさを他の軸より重く配点してください。この2つが低いまま契約すると、稼働後に作り込みが増え、費用が見積もりを超えていきます。

考え方を示すための仮の値で、3社を比較した記入例を示します。実際の点数は自社の状況に合わせてつけ直してください。

評価軸	A社	B社	C社
業務適合度	4	3	5
例外処理の対応	3	4	3
初期費用	5	3	4
5年の総額	3	4	4
データ移行のしやすさ	2	4	3
設定変更のしやすさ	4	2	5
解約時のデータ持ち出し	3	3	4
合計	24	23	28

この例では、初期費用が最も安いA社ではなく、合計点で上回ったC社が候補に残ります。金額だけを見た比較では、この逆転は起きません。

手順3｜デモ・面談で確認する項目

採点表で上位2〜3社に絞れたら、デモと面談に進みます。ここでの目的は、提案書には書かれていない情報を集めることです。

確認したいこと	具体的な確認方法	注意点
実際の担当者に会えるか	提案時の営業担当ではなく、導入後の実装担当者に同席してもらう	担当者交代の頻度も聞く
想定外の入力への反応	質問シートに書いた例外処理を、その場で実際に入力させてみる	用意された画面遷移しか見せない会社もある
サポートの応答時間	契約前にサポート窓口へ実際に問い合わせ、応答までの時間を体験する	資料の記載と実態がずれることがある
同規模の導入実績	従業員10〜20名規模での導入事例を1件紹介してもらう	大企業向け実績しかない場合は要注意
決定権のある人の同席	自社側も経営者だけでなく、実際に入力する人を1人同席させる	使う人の反応を採点表へ反映する

4番目には注意が必要です。導入実績の多くが従業員100名を超える会社向けの場合、標準機能が自社の業務規模に対して過剰な可能性があります。過剰な機能は使われないまま、費用だけがかかり続けます。

手順4｜ギャップが出たとき「業務を変える」か「作り込む」かを誰が決めるか

デモを重ねても、自社の業務と標準機能が完全に一致することはまずありません。差が見つかったとき、選択肢は3つに整理できます。

対応方針	選ぶ場面	注意点
業務を変える（現行踏襲しない）	画面のレイアウトや帳票の様式など、業務そのものへの影響が小さい場合	変更後の画面に慣れる時間を見込む
運用を一部変更する	業務への影響はあるが、許容できる範囲で手順を変えられる場合	現場の合意を先に取る
費用をかけて作り込む	外部システムとの連携など、変えると業務が止まる場合	追加費用と納期への影響を契約書に明記する

この3つのどれを選ぶかを、その場のベンダーとの話し合いだけで決めないことが重要になります。IPAの同ガイドは、こうした判断をあらかじめ決めた手順に沿って行わないと、方針がいつまでも確定せず、プロジェクトの停止や遅延を招くと指摘しています（同ガイド3.7節「意思決定プロセスの策定」、2026年9月16日確認）。大企業向けの想定では、ユーザー企業とベンダー双方の管理職クラスによる会議体を置くとされていますが、決める人が1人の会社では、この会議体を1人で兼ねることになります。

1人で兼ねる場合でも、省いてはいけないことが1つあります。決めた内容を、日付と理由つきで記録に残すことです。口頭でのやり取りだけに頼ると、稼働後に「言った」「言わない」の争いになります。契約前に、追加費用が一定額を超える変更は経営者の承認を必須にする、といった基準を1行決めておくと、現場とベンダーだけで話が先に進むことを防げます。

実在事例に当てはめると

この4つの手順を、実際に記録が残っている事例に当てはめてみます。基幹システム刷新の失敗事例で扱った、従業員17名の会社です。安価版のシステムを3年ほどで手放し、業種特化の製品へ入れ替えています。製造業であり事務系の会社と業種は異なりますが、決める人の少なさという点では共通しています。

採点表の軸で言えば、この会社が2回目に効かせたのは「実際に触ったか」です。出典によれば、2018年に展示会で製品を見つけたことが転機になっており、資料と価格表だけで決めていません。1回目が全面導入、2回目が3台からの試験導入だったという違いも、出典から確認できる事実です。<strong>ただし、なぜ1回目の安価版がなじまなかったのかは、<a href=”/system-selection-failure/”>出典に書かれていないままです</a>。</strong>その違いを「質問シートの『譲れない機能とあきらめてよい機能』を事前に決めなかったことの裏返し」と結びつけるのは、出典に書かれた事実ではなく、本記事の手順を当てはめた場合の考え方です。

意思決定プロセスの観点では、この会社は社長・工場長・生産技術部長の3人で役割を分担していました。決める人が1人しかいない会社では、この3役を1人で兼ねることになります。だからこそ、判断の基準を先に数字で決めておく作業が、3人がかりの体制を持たない会社の代わりを務めます。

よくあるつまずきと対処

つまずき	主な原因	対処
質問シートを配る前に価格だけで1社に絞る	比較の基準がなく、最初に話した相手が最も丁寧に見える	採点表を先に作り、最低2社の提案が揃うまで契約しない
デモで「できます」と言われた機能が、契約後にオプション料金だった	口頭の説明を記録せず、見積書の項目だけを見ていた	デモで確認した機能を見積書の項目名と1つずつ突き合わせる
ギャップが出た瞬間、その場の雰囲気で作り込みに決める	判断基準を契約前に決めておらず、断りにくい	追加費用の上限額を契約前に1行決めておく
データ移行の範囲を稼働直前まで詰めていない	移行は最後の工程だと考えている	質問シートの5番目を提案依頼と同時に埋める
現場の使う人を面談に同席させない	経営者だけで決めた方が早いと考える	面談の最低1回に、実際に入力する人を1人同席させる
採点表を作った後、点数を見直さないまま契約する	一度作った書類を疑わない	契約前に採点表を1日置いて、翌日もう一度見直す

よくあるご質問

決める人が1人で、本当に大丈夫ですか

採点表と質問シートを書面に残していれば、後から見直せます。危ないのは人数が少ないことではなく、判断の根拠が記録に残らないことです。可能であれば、契約直前の採点表だけでも、利害関係のない第三者に一度見てもらうと、見落としに気づきやすくなります。

質問シートは経営者が忙しくて書く時間がありません

全項目を一度に埋める必要はありません。まず1番目の主要業務の流れだけを書き、残りは提案を依頼する前日までに埋める形でも進められます。デモの日程が決まると、期限ができて手が動きやすくなります。

採点表の点数の重みづけに正解はありますか

業種や業務によって変わるため、共通の正解はありません。目安として、業務適合度とデータ移行のしやすさを他の軸より重く配点すると、稼働後に費用が膨らみやすい2つの弱点を早く見つけられます。

ベンダーから「決めていただかないと見積もりが出せません」と言われました

質問シートの6番目「譲れない機能とあきらめてよい機能」が埋まっていない可能性があります。ここが空欄のまま面談に進むと、ベンダー側も見積もりの前提を置けません。持ち帰って埋めてから、再度連絡する順序で問題ありません。

相見積もりは何社取ればよいですか

2〜3社が目安です。1社だけでは比較の基準が働かず、5社以上になると、デモと面談の負担が決める人1人にかかりすぎます。

まとめ｜今週やること

決める人が1人であることは、選定を諦める理由になりません。質問シートと採点表という2枚の書面があれば、複数社を同じ条件で比べられます。ギャップが出たときの判断基準も、契約前に1行決めておくだけで、その場の押し切りを防げます。

今週着手できることは1つです。質問シートの1番目、自社で件数が最も多い業務の流れを、発生から完了まで書き出してください。これができれば、次にベンダーへ声をかけるときの最初の質問が、すでに用意できています。

この記事の質問シートと採点表をそのまま書き込める様式は、基幹システム選定チェックリストとしてダウンロードできます。選定の途中で判断に迷う場合は、お問い合わせからご相談ください。