ベンダー与信審査で確認すべき項目｜システム開発発注前の20チェック

システム開発を外部ベンダーに委託するとき、「このベンダーはプロジェクト完了まで存続してくれるだろうか」という不安を抱えたことはないでしょうか。数ヶ月から数年にわたる開発期間の途中でベンダーが撤退すれば、支払った着手金は回収困難となり、成果物は中途半端な状態で残されます。作り直しには追加の予算と時間が必要となり、事業計画そのものが崩れかねません。

ベンダー与信審査は、こうした「継続性リスク」を発注前に見極めるための手続きです。しかし、TDB評点や資本金といった一般的な指標だけを見ていては、システム開発ベンダー特有の構造リスクを見逃す危険があります。技術チームの一斉退職、キーマン PM の離脱、特定顧客への売上集中、下請け依存による品質管理の空洞化。これらは決算書の表面には表れにくく、しかも一度発現すればプロジェクトを直撃します。

問題は「何を見ればよいか」の判断軸が社内に整備されていないことです。稟議で「なぜこのベンダーで大丈夫と言えるのか」と問われたとき、財務諸表の数字を並べるだけでは説得材料として弱く、かといって闇雲に情報を要求すればベンダー側との関係を損ないます。必要なのは、財務・構造リスク・定性情報の3つの層を統合した、実務に使えるチェックリストです。

本記事では、システム開発発注を対象としたベンダー与信審査で確認すべきチェック項目を、一般的な財務指標・IT ベンダー特有の構造リスク・定性情報の3層に分けて解説します。さらに、危険信号を検出した場合の判断基準（発注中止か、条件付き契約でカバーするか）と、契約書に盛り込むべきリスク遮断策までを扱います。稟議に添付できるチェックリスト形式で整理していますので、社内フォーマットに組み込んで活用してください。

ベンダー与信審査とは？なぜシステム開発発注で特に重要か

ベンダー与信審査（信用調査）とは、取引先の支払能力・財務健全性・事業継続性を発注前に確認する手続きを指します。仕入取引・売掛取引においては「相手が期日通りに代金を支払ってくれるか」を確認する目的で行われますが、システム開発発注の場合は少し様相が異なります。発注者側が代金を支払う立場である以上、「支払ってくれるか」ではなく「成果物を納品できる体制を維持してくれるか」が主眼になります。

システム開発発注が一般的な取引先与信と異なる特殊事情は、主に3つあります。

1つ目は契約期間の長さです。要件定義から本番稼働まで数ヶ月から数年に及ぶプロジェクトが多く、契約締結時点では健全だった財務状況が、開発途中で悪化する可能性があります。取引開始時点だけでなく、契約期間全体を通じた継続性を評価する必要があります。

2つ目は代金支払いのタイミングです。システム開発では、着手金・中間金・検収時の3分割払いなど、成果物完成前に代金を分割前払いするケースが多く見られます。ベンダーが途中で経営破綻した場合、支払済みの着手金・中間金は担保のない一般債権として扱われる可能性が高く、破産手続では優先弁済の対象外となるため、他の一般債権者と按分弁済される立場に置かれます。回収可能性は破産財団の規模や優先債権の状況に左右され、実務上は満額回収が難しくなる場面が少なくありません。

3つ目は代替の困難さです。要件定義書や設計書は担当エンジニアの頭の中にある暗黙知に依存しがちで、途中で別ベンダーに引き継ぐには相当な工数が必要になります。半年間で3,000万円を投じたプロジェクトが停止した場合、別ベンダーへの切り替えには通常、同等かそれ以上の追加コストがかかります。

契約締結後にベンダーの経営リスクが顕在化した場合、契約解除は容易ではありません。発注者側からの一方的な解除は損害賠償請求のリスクを伴い、実務上は「継続するリスク」と「解除するリスク」を秤にかけて悩むことになります。中途解除の具体的な論点は業務委託の中途解除リスクと契約設計や業務委託契約における損害賠償の上限設定で扱っていますので、契約前の与信審査と併せて確認しておくと、契約後の想定シナリオが具体化します。契約前のタイミングで与信審査を実施し、危険信号を検出したベンダーは発注候補から外す、あるいは契約条件でリスクを遮断することが、最も費用対効果の高いリスクマネジメントになります。

2024年11月に施行されたフリーランス新法（特定受託事業者に係る取引の適正化等に関する法律）により、発注者側にも取引条件の明示・支払期日の設定などの義務が課されるようになりました（出典: 公正取引委員会「フリーランス法特設サイト」）。ベンダー与信審査は、こうした法的義務を果たしながら発注リスクをコントロールする、いわば入口の関門と位置づけられます。

財務指標で確認すべきベンダー与信審査の基本項目

まずは一般的な与信審査の基本項目を、システム開発発注の文脈で読み解いていきます。ここは他業種の取引先評価と共通する部分ですが、システム開発ベンダーならではの「見方」があります。

決算書（B/S・P/L）の必須チェックポイント

ベンダーから決算書の開示を受けた場合、以下の項目を優先的に確認します。

• 自己資本比率: 総資本に占める自己資本の割合です。中小企業庁「令和5年中小企業実態基本調査」（令和4年度決算実績）によると、情報通信業の平均自己資本比率は54.87%と全業種の中でも高い水準にあります（出典: 中小企業庁「中小企業実態基本調査」）。この平均を下回るからといって直ちに問題とは限りませんが、20%を下回る場合は財務基盤が脆弱と評価されるのが一般的です。
• 流動比率: 流動資産÷流動負債×100の値です。100%未満は短期支払能力に懸念があり、150%以上あると安定的とされます。
• 当期純利益の3期推移: 直近3期分の推移で、赤字が連続していないか、また赤字幅が拡大していないかを確認します。単年度の赤字は積極投資による一時的なものである可能性もあるため、必ず3期推移で見ます。
• 現金及び預金残高: 月次の売上原価・販管費に対して何ヶ月分の現預金を保有しているか（現預金÷月次固定費）で評価します。IT ベンダーは人件費比率が高いため、この指標がキャッシュフローの安全余裕度を示します。3ヶ月分を下回る場合は要警戒です。
• 売上高の推移: 前年比で急激な減少（マイナス20%以上）がないかを確認します。逆に急激な増加（プラス50%以上）も、体制拡大に失敗するリスクを伴うため、内訳の確認が必要です。

これらの項目は、単一の指標だけで判断せず、複数指標を組み合わせて総合評価します。例えば「自己資本比率は低いが現預金は潤沢で純利益は安定的にプラス」という企業は、成長投資による意図的な財務構造である可能性が高く、必ずしも危険信号ではありません。

帝国データバンク・東京商工リサーチ評点の見方

日本の民間信用調査会社としては、帝国データバンク（TDB）と東京商工リサーチ（TSR）が代表的です。両社ともに独自の評点システムを持っており、算出ロジックと構成要素が異なります。両者を混同すると評点の見方を誤るため、それぞれの構造を押さえておく必要があります。

• TDB評点: 100点満点で表現され、全国平均は50点弱とされます。定量的評価5要素（業歴・資本構成・規模・損益・資金現況）と定性的評価2要素（経営者・企業活力）の合計7要素で構成されます。各要素の配点目安は、業歴1〜5点、資本構成0〜12点、規模2〜19点、損益0〜10点、資金現況0〜20点、経営者1〜15点、企業活力4〜19点で、資金現況・規模・企業活力といった要素の配点レンジが相対的に大きく設定されているのが特徴です（出典: 帝国データバンク公式サイトの企業信用調査サービス案内、および業界解説記事による構成要素整理）。要素ごとの得点分解を確認することで、何が評点を押し下げているかが可視化できます。
• TSR評点: 同じく100点満点ですが、構成要素はTDBと異なります。経営者能力・成長性・安定性・公開性・取引状況などの観点から算出されます。TDBが7要素の内訳を明示的に開示するのに対し、TSRは複数観点を組み合わせた総合評価として算出される点が両者の違いです。

一般に、TDB評点50点以上が「取引に問題なし」、45〜50点が「取引可能だが継続注視」、40〜44点が「要検討」、40点未満は「取引慎重」と受け止められることが多い水準です。ただし、IT サービス業は業界特性上、他業種と比べて評点が低めに出やすい傾向があります。他業種と単純比較するのではなく、IT 業界内での相対位置で評価することが実務上のポイントになります。

評点は年に1〜2回の更新が基本のため、直近の急変（急激な業績悪化・訴訟発生等）はまだ反映されていない可能性があります。評点だけを鵜呑みにせず、次章以降で扱う定性情報と併せて判断します。

資本金・株主構成・親会社の与信影響

資本金の額そのものは、必ずしも財務健全性を示す指標ではありません。増資によって水膨れさせることも減資によって圧縮することもできるため、資本金の絶対額よりも「資本金の変動履歴」と「株主構成」を確認する方が有益です。

• 資本金の変動履歴: 直近3年で急激な減資が行われている場合、繰越損失の解消・欠損金補填を目的とした整理減資である可能性があり、財務状況の悪化を示唆します。
• 株主構成: 単独株主が過半数を持つ同族会社か、複数株主による分散所有かを確認します。ベンチャーキャピタルからの出資を受けている場合は、資金調達ラウンドの状況・次回調達の見込みも合わせて確認します。
• 親会社の存在: 大手企業の子会社であれば、親会社からの支援期待がある一方、親会社の方針変更で切り離される事業リスクもあります。親会社の連結決算での位置づけ（コア事業か、ノンコアか）を確認します。

株主構成と資本金の情報は、国税庁法人番号公表サイトや登記情報提供サービスから取得できます。

システム開発ベンダー特有の与信リスク項目

ここからが本記事の中核です。決算書や信用調査会社の評点だけでは見えない、システム開発ベンダー特有の構造リスクを4つの観点から掘り下げます。これらの項目は、財務指標が良好なベンダーであっても、翌年以降の継続性に大きく影響します。

顧客集中度リスク

売上の30〜50%を単一顧客に依存しているベンダーは、その主要顧客との取引が終了した場合、一気に体制縮小・人員整理に追い込まれる構造リスクを抱えています。特に以下の兆候は要注意です。

• 売上上位3社への集中度: 上位3社の売上比率が全体の60%を超える場合、顧客ポートフォリオが脆弱と評価します。
• 主要顧客の入れ替わり頻度: 過去3年で主要顧客が頻繁に入れ替わっている場合、既存顧客との関係を継続できていない可能性があります。逆に、10年以上継続している主要顧客がある場合は、その顧客との関係の質を確認する価値があります（同社の技術力への信頼か、価格競争力か、経営陣同士の個人的関係か）。
• 業界集中度: 特定業界（例: 金融業界のみ、製造業界のみ）に売上が偏っている場合、業界不況時に一斉に案件が縮小するリスクがあります。

顧客集中度の情報は、決算書の注記（主要販売先の記載）や、ベンダーからの直接ヒアリングで取得します。「主要顧客のカテゴリ別売上比率（金額は概数でも可）を教えてください」という質問は、契約前の情報開示依頼として一般的な範囲です。

技術者・PM の定着率とキーマン依存度

システム開発ベンダーにおいて、エンジニアと PM の離職はプロジェクト継続の最大のリスクです。特に自社が発注する案件の PM が退職・異動した場合、後任への引き継ぎには相当な工数がかかり、品質・スケジュールの両面で悪影響が出ます。

• 3年定着率: 「入社後3年以内の離職率」を指標とします。IT サービス業の全国平均は業種特性上高めに出るため、業界平均と比較して大幅に高くないかを確認します。
• 主要 PM の在籍年数: 提案されたプロジェクトの担当予定 PM が入社何年かを確認します。1〜2年の在籍者は、ベンダー特有の開発プロセス・顧客対応スタイルを習熟していない可能性があります。
• キーマン依存度: 過去のプロジェクトが特定エンジニアに集中していないかを確認します。ベンダーのポートフォリオを見て、同じ担当者名が5件以上並んでいる場合、その担当者への依存度が高すぎるサインです。
• エンジニアの平均勤続年数: 全社員の平均勤続年数が3年未満の場合、離職率が高く、技術ナレッジが社内に蓄積されにくい構造である可能性があります。

これらの情報は、ベンダー側から自発的に開示されるものではありません。「弊社案件の担当予定 PM の職務経歴書」「技術リーダー層の在籍年数の傾向」の開示を、選定プロセスの一環として求めることが有効です。

下請け・オフショア依存度と管理体制

自社正社員だけで開発するベンダーは実際には少数派で、多くのベンダーは下請け・パートナー企業・オフショア開発拠点を活用しています。下請け活用そのものは問題ではありませんが、依存度と管理体制は必ず確認します。

• 自社正社員比率: プロジェクト工数に占める自社正社員の比率が30%を下回る場合、実質的な開発は下請けに丸投げされている可能性があります。品質管理・進捗管理の実効性を追加で確認します。
• 下請け先の与信は誰が管理しているか: ベンダーが下請け先の経営状況を把握しているか、下請け先が倒産した場合の代替体制があるかを確認します。
• オフショア比率と拠点国: オフショア開発を活用している場合、拠点国・拠点都市・現地の法人形態を確認します。地政学リスク（現地の労働規制変更・為替変動・カントリーリスク）を把握しておく必要があります。
• 多重下請け構造: 元請け→1次下請け→2次下請けという多重下請けは、品質管理・情報統制の観点で問題が発生しやすい構造です。契約書での再委託制限条項の設定を検討します。複数ベンダーを組み合わせる場合の役割分担・責任分界の設計はマルチベンダー開発の調整術も参考になります。

下請け構造の情報は、提案時の体制図で開示されるのが一般的です。体制図に「協力会社」と記載されている場合、その企業名・役割・工数比率を追加で確認します。

保有技術・受注案件の偏り

単一技術スタック（例: 特定のフレームワーク・特定のクラウドサービス）への過度な依存は、技術トレンドの変化で急速に受注が縮小するリスクを抱えています。特に以下のケースは要注意です。

• 単一技術への集中: 売上の過半を1つの技術スタックが占めている場合、その技術の陳腐化・代替技術の台頭で受注が急減するリスクがあります。
• 保有技術の更新頻度: 自社発信の技術ブログ・登壇資料・OSS 貢献などで、新技術への継続的なキャッチアップが行われているかを確認します。
• 受注案件のジャンル分布: Web システム開発一辺倒か、AI・データ基盤・クラウドインフラなど複数ジャンルにポートフォリオを持っているかを確認します。ジャンル分散は経営基盤の安定性に直結します。

技術ポートフォリオの情報は、ベンダーの公式サイト・技術ブログ・登壇資料などから間接的に把握できます。営業担当者から「直近3年の受注案件を技術スタック別・業界別に分類した傾向を教えてください」と依頼するのも有効な情報開示要求です。

定性情報で確認すべき与信リスク項目

数値化しにくい定性情報も、与信審査の重要な要素です。決算書に表れない経営者の姿勢・法的リスク・業界内評判を把握することで、判断精度が上がります。

代表者・経営陣の経歴とガバナンス

企業の継続性は経営陣の姿勢に大きく左右されます。特に IT ベンダーは経営陣自身が技術者出身であるケースが多く、経営者の経歴が事業の方向性を強く規定します。

• 創業者の同業界経験: 創業前の職歴が IT 業界か、全くの異業種かを確認します。同業界経験10年以上の創業者は、業界特有のリスク管理感覚を持っている可能性が高いです。
• 過去の会社解散・破産履歴: 経営者個人が過去に別会社を解散・破産させた履歴がないかを確認します。国税庁の法人番号公表サイト・官報で確認できます。
• 役員の入れ替わり: 直近3年で役員の連続退任があった場合、経営方針の対立・ガバナンス不全のサインの可能性があります。登記情報で役員の就任・退任履歴を確認します。
• 社外取締役・監査役の存在: 一定規模以上のベンダーで社外取締役・監査役が不在の場合、ガバナンス体制が脆弱な可能性があります。

これらの情報は、登記情報提供サービス（オンライン）・国税庁法人番号公表サイト・帝国データバンクや東京商工リサーチのレポートから取得できます。

官報・裁判所公開情報

法的リスクの兆候は、官報・裁判所の公開情報から確認できます。

• 官報公告: 破産手続開始決定・民事再生手続開始決定・会社更生手続開始決定などが官報に掲載されます。過去の官報も検索可能です（インターネット版官報）。
• 民事訴訟の当事者履歴: 裁判所の判例検索・訴訟記録から、被告として複数の訴訟を抱えていないかを確認します。労働訴訟・請負契約に関する紛争が複数あるベンダーは、業務品質・労務管理に問題を抱えている可能性があります。
• 行政処分歴: 個人情報保護委員会・経済産業省・厚生労働省などによる行政処分歴を確認します。個人情報漏洩・下請法違反・労働基準法違反などの処分は公表されます。
• 特許・商標紛争: 主要顧客との間で特許・著作権に関する紛争を抱えていないかを確認します。

これらの情報は、信用調査会社のレポートに含まれることが多いですが、自社で追加確認する場合は、企業名で官報検索・判例検索を行います。

業界内評判・技術コミュニティでの活動

数値化しにくいものの、業界内評判は継続性の重要な予兆情報です。

• 技術ブログ・登壇履歴: 自社エンジニアが継続的に技術ブログを執筆し、カンファレンスで登壇しているベンダーは、技術投資と採用ブランディングの両面で健全な循環を持っている可能性が高いです。
• OSS 貢献: GitHub 等での組織アカウントの活動状況を確認します。積極的な OSS 貢献は、技術力の証明であると同時に、優秀な技術者の採用・定着に寄与します。
• エンジニア採用時の口コミ: 転職口コミサイトでの評判は、内部の雰囲気・労務環境を推測する材料になります。ただし匿名投稿の性質上、極端な意見に偏る傾向があるため、複数サイトを横断的に確認します。
• 業界イベントでの位置づけ: スポンサー活動・カンファレンス協賛・業界団体への加入状況を確認します。継続的な業界貢献は、事業の腰の据わり方を示唆します。

定量指標では捉えられない「経営陣の姿勢」「継続的な技術投資」の判断材料として、上記の情報を組み合わせて総合評価します。

与信審査の実施手順と稟議用チェックリスト

ここまでの項目を、実際の発注プロセスに落とし込む手順を整理します。

自社実施 vs 外部委託の判断

与信審査は、自社で行う方法と外部の信用調査会社に委託する方法があります。判断基準は主に発注規模と社内リソースです。

• 発注額500万円未満: 自社で決算書レビュー・登記情報確認・公開情報検索を実施する範囲で十分なことが多いです。
• 発注額500万〜3,000万円: TDB・TSR の簡易レポート（1件あたり数千円〜1万円程度）を活用し、要点確認を効率化します。
• 発注額3,000万円以上: TDB・TSR の詳細レポート（1件あたり2万〜3万円程度）または現地調査を含む調査を委託します。プロジェクト規模を考えれば、調査費用は投資対効果が高い支出です。

外部委託する場合の主な依頼先は、帝国データバンク、東京商工リサーチ、リスクモンスターなどです。IT 業界に強い調査会社を選ぶと、業界特有の観点を含めた分析が得られます。

ベンダーへの直接開示依頼が可能な項目とその依頼方法

RFP プロセスの一部として、ベンダーに直接開示を依頼できる項目があります。開示要求は「不当な要求」と受け取られない範囲で、選定プロセスの合理的な手続きとして位置づけます。

• 直近3期の決算書サマリー: 上場企業であれば有価証券報告書・決算短信を、非上場企業であれば決算書の主要項目（B/S・P/L の要点）を開示依頼します。非上場企業の場合、機密保持契約（NDA）を先行締結した上で開示を求めるのが実務的です。
• 提案チームの体制図と主要メンバーの職務経歴書: PM・技術リーダーの経歴を確認する目的で開示依頼します。
• 主要顧客のカテゴリ別売上比率: 具体的な社名は不要で、業界カテゴリ・売上比率のレンジ（例: 「金融業界40%、製造業界30%、公共20%、その他10%」）で回答してもらいます。
• 下請け・パートナー企業の一覧と役割: 体制図の付帯情報として、協力会社の企業名・役割・工数比率を確認します。

これらの開示依頼は、RFP に「情報開示依頼書」を添付する形で行うと、ベンダー側も準備しやすくなります。

稟議添付用チェックリスト（20項目）

以下のチェックリストは、本記事のここまでの3層（財務指標・IT ベンダー特有の構造リスク・定性情報）を稟議添付用に集約したベンダー与信審査 チェック項目です。社内フォーマットに組み込んで活用してください。

財務指標（基本項目）

1. 自己資本比率が業界平均（情報通信業50%前後）と比較して健全水準か
2. 流動比率が100%以上（150%以上が望ましい）か
3. 当期純利益が直近3期でプラス基調か
4. 現預金残高が月次固定費の3ヶ月分以上あるか
5. 売上高の前年比変動が±20%以内か
6. TDB・TSR 評点が45点以上（IT 業界内での相対位置で評価）か
7. 直近3年で急激な減資（整理減資）が行われていないか

IT ベンダー特有の構造リスク

8. 売上上位3社への集中度が60%未満か
9. 提案案件の PM の在籍年数が3年以上か
10. エンジニアの平均勤続年数が3年以上か
11. 自社正社員比率が30%以上か
12. 下請け先の与信管理・代替体制が説明できるか
13. オフショア活用時、拠点国・現地法人形態が把握できているか
14. 保有技術ポートフォリオが複数ジャンルに分散しているか

定性情報

15. 代表者に過去の会社解散・破産履歴がないか
16. 直近3年で役員の連続退任がないか
17. 官報公告（破産手続等）に該当履歴がないか
18. 複数の民事訴訟の当事者履歴がないか
19. 行政処分歴（個人情報漏洩・下請法違反等）がないか
20. 技術ブログ・登壇・OSS 貢献など継続的な技術投資の痕跡があるか

各項目を「該当」「非該当」「要追加確認」の3値で評価し、稟議書に添付します。

危険信号を検出した場合の判断基準と契約でのリスク遮断

チェックリストで危険信号が検出された場合、判断は「発注中止」「条件付き発注」「そのまま発注」の3つに分岐します。判断基準と契約でのリスク遮断策を整理します。

「発注中止」ラインの判断基準

以下のいずれかが該当する場合、発注中止を強く推奨します。これらは短期間で経営破綻に至るリスクが高い兆候です。

• 債務超過: 自己資本がマイナス（純資産の部がマイナス）である場合、財務基盤が崩壊しています。
• 現預金3ヶ月未満: 月次固定費に対して現預金が3ヶ月分を下回る場合、突発的な受注減少で即座に資金繰りが破綻するリスクがあります。
• 主要役員の連続退任: 直近1〜2年で代表取締役・CTO・COO などの主要役員が連続して退任している場合、経営方針の内部対立・重大な問題を示唆します。
• 訴訟当事者履歴の複数件: 民事訴訟の被告となった履歴が複数件ある場合、事業運営の何らかに構造的問題を抱えている可能性が高いです。
• 官報公告への該当: 過去5年以内に破産手続・民事再生手続の履歴がある関連会社を持つ場合、経営者の再チャレンジ案件である可能性を評価します。
• TDB・TSR 評点40点未満: IT 業界内でも低位に位置し、複数の懸念要素が重なっている状態です。

これらの兆候を検出した場合、たとえ提案内容が魅力的であっても、プロジェクト規模とリスクを秤にかけて「発注しない」判断を推奨します。過去のプロジェクト撤退事例を分析すると、契約前の与信情報である程度予測可能だったケースが多数を占めます。

「条件付き発注」ラインとリスク遮断策

「軽度の懸念はあるが、提案内容・技術力・見積金額を総合評価すると発注価値がある」ケースでは、契約条件でリスクを遮断します。

支払条件の調整

• 前払い比率の低減: 標準的な着手金30%を10〜20%に引き下げ、検収時支払い比率を高めます。
• 成果物単位の分割納品: 大型案件を機能単位で分割し、機能ごとの検収・支払いとします。各フェーズで継続判断を行える体制を作ります。
• エスクロー口座の活用: 信託銀行のエスクロー口座に代金を預託し、検収完了時に払い出す仕組みです。ベンダー側の資金繰りを支援しつつ、発注者側の未回収リスクを遮断します。

ソースコード・成果物の保全

• ソースコード保管条項: 開発途中のソースコードを一定期間ごと（例: 2週間ごと）に発注者側のリポジトリまたは第三者機関に預託する条項を設けます。ベンダーが突然稼働停止しても、成果物を引き継げる状態を確保します。
• ドキュメント成果物の定期納品: 設計書・API 仕様書・運用手順書などのドキュメントを、コーディング成果物と併せて定期納品する条件を設定します。
• ソースコードエスクロー: 信託会社や特定の第三者機関にソースコードを預託し、ベンダー破綻など特定の事由発生時に発注者側に開示される仕組みです。

体制・キーマンの保証

• 主要 PM・技術リーダーの離脱時通知義務: 主要メンバーが離脱する場合、事前通知・後任アサインを義務化します。
• プロジェクト保証条項: 主要メンバーの離脱時に、プロジェクトのスケジュール・品質保証を継続する義務条項を設けます。

第三者保証

• 親会社の保証差し入れ: 子会社ベンダーの場合、親会社からの履行保証を差し入れてもらう選択肢もあります。ただし親会社側の合意ハードルは高くなります。
• 業務履行保証保険: 一部の保険会社が業務履行保証保険を提供しています。プロジェクト規模に応じて検討します。

契約書に盛り込むべき与信保険条項の観点

契約書レベルで盛り込むべき、与信リスクに対する保険的な条項の観点を整理します。個別の条項設計や実務的な確認ポイントは業務委託契約書の13のチェックポイントも併せて参照してください。

• 期限の利益喪失条項: ベンダーに信用不安事由が発生した場合（支払停止・銀行取引停止・破産申立て等）、契約解除および前払金返還請求権を発生させる条項です。
• 相殺条項: 別途取引がある場合、債権と債務を相殺できる旨を明記します。
• 担保設定: 大型案件で発注者側の負担が大きい場合、ベンダーの資産に担保設定を求める選択肢もあります。ただしベンダー側との交渉ハードルは高くなります。
• 知的財産権の帰属: 開発成果物の知的財産権を発注者側に明確に帰属させる条項を設けます。ベンダー破綻時にソースコードや設計資産を継承できる根拠になります。
• 再委託の制限: 発注者の事前承認なく再委託を禁止する条項を設けます。多重下請け構造による品質リスクを遮断します。

契約書のリスク遮断策は、法務部門・弁護士との連携で作成します。標準的な受託開発契約書テンプレートに対して、本セクションで挙げた条項を追加する形で対応するのが実務的です。

チェックリストの結果を踏まえ、危険信号のレベルに応じて「発注中止」「条件付き発注」「そのまま発注」の3分岐を判断してください。「条件付き発注」に該当する場合、契約書での保険条項の設計が、プロジェクト成否を大きく左右します。稟議書には、チェックリストの評価結果と併せて、契約書に盛り込む具体的な条項の案を添付することで、意思決定の透明性が高まります。

ベンダー与信審査は、発注前の一時的な手続きに見えて、実際には契約書設計・プロジェクト運用体制の設計まで含む、上流の意思決定プロセスです。財務指標・構造リスク・定性情報の3層を統合したチェックリストで評価を行い、危険信号のレベルに応じた契約条件で発注リスクをコントロールする。この一連の手続きが定着することで、「なぜこのベンダーで大丈夫と言えるのか」という問いへの根拠を、常に稟議書レベルで示せる体制が整います。