基幹システムとつながる新しい業務システムを外部に依頼することになり、候補の開発会社を3〜4社まで絞ったものの、どこも提案書は立派で決め手がない。情報システム部門は技術面を、事業部門は使い勝手を、経営層は投資対効果を気にしていて、評価の物差しがそろわない。大企業の発注担当者がつまずくのは、こうした比較の段階であり、選び方の型がないことが原因です。

この記事では、大企業の発注担当者がそのまま使える評価軸と評価シート、選定プロセス、よくある失敗と対策を順に解説します。最後に、条件に合う開発会社の例も紹介します。

この記事を読むと理解できること

• 大企業でシステム開発会社の選び方が難しくなる構造的な理由

• 候補を比較する前に社内で固めておくべき前提条件

• 配点つきの評価シートと、各評価軸で確認すべき具体的な質問

• RFIから契約締結までの選定プロセスと、各段階で決めること

• 価格偏重や要件の丸投げなど、選定でよくある失敗と対策

• 上流工程や現場で使われるUXを重視する場合に、候補となる開発会社の例

システム開発会社の選び方が大企業で難しくなる理由

中小規模の案件であれば、実績と見積金額と担当者の印象で発注先を決めても、大きな問題にならないことがあります。しかし大企業の案件では、同じ選び方では失敗の確率が上がります。理由は、関係者の多さ、既存システムとの関係、意思決定の重さという3つの構造にあります。

関係者が多く評価の物差しがそろわない

大企業のシステム開発には、情報システム部門、利用部門、経営企画、購買部門、セキュリティ部門、PMOなど多くの部署が関わります。情報システム部門は保守性や既存環境との整合を、利用部門は使いやすさと業務への適合を、購買部門は価格と契約条件を重く見ます。それぞれの立場が違うため、評価の物差しをあらかじめ合わせておかないと、選定会議が好みの言い合いになりがちです。

システム開発会社の選び方を社内で共有しておくことは、発注先を決めるためだけでなく、稟議を通すための準備でもあります。誰が見ても同じ根拠で説明できる状態をつくることが、大企業での選び方の出発点です。

既存の基幹システムとの連携が前提になる

大企業の新規システムは、ほとんどの場合、販売管理や会計、人事などの既存基幹システムとデータをやり取りします。連携方式やデータ移行、段階移行の計画を誤ると、システム単体の出来がよくても全社展開が止まります。そのため、画面や機能の作り込みだけでなく、既存環境を読み解く力があるかを選び方の軸に加える必要があります。

発注後に乗り換えるコストが大きい

一度発注すると、要件定義から保守運用まで数年単位で同じ会社と付き合うことになります。途中で発注先を変えようとしても、設計書が不足していたり、独自の仕組みで作られていたりすると、引き継ぎに多大なコストがかかります。システム開発会社の選び方を誤った影響は、リリース後の数年間にわたって続くと考えておくべきです。

システム開発会社の選び方の前提となる社内準備

候補の比較に入る前に、選び方の前提として社内で決めておくべきことがあります。前提があいまいなまま提案を受けると、各社がそれぞれの解釈で提案するため、比較そのものが成り立ちません。選び方の精度は、準備の段階でほぼ決まります。

目的と成功の定義を言葉にする

まず、なぜこのシステムを作るのかを一文で説明できるようにします。業務時間の削減なのか、データの一元化なのか、新しいサービスの立ち上げなのかによって、重視すべき開発会社の強みは変わります。可能であれば、リリース後に何がどう変わっていれば成功かを、関係部署と合意しておきます。

依頼範囲と社内の役割分担を決める

構想策定から依頼するのか、要件定義が終わった段階から依頼するのか、保守運用まで含めるのかを決めます。あわせて、社内のプロジェクトオーナー、業務側の責任者、情報システム部門の窓口、PMOの関与範囲を整理します。依頼範囲と社内体制が決まると、開発会社に求める役割と、それに合った選び方もはっきりします。

制約条件と評価方針を先に共有する

予算の幅、稼働したい時期、セキュリティ審査の基準、クラウド利用の可否、社内標準の技術などの制約を一覧にします。そのうえで、価格と技術と体制をどの比率で評価するかという評価方針を、選定に関わる部署で先に合意しておきます。提案を見てから評価方針を決めると、特定の会社に合わせた後付けの選び方になりやすいためです。

システム開発会社の選び方で使う評価軸と評価シート

準備が整ったら、候補を同じ物差しで比較するための評価シートをつくります。システム開発会社の選び方として多くの記事が挙げるのは、実績、技術力、コミュニケーション、保守体制といった項目です。大企業の案件では、これに上流工程の進め方、UXへの向き合い方、ベンダーロックインへの姿勢を加えると、発注後のズレを防ぎやすくなります。

評価シートの例

以下は、大企業の業務システム開発を想定した評価シートの例です。配点は案件の性質に応じて調整し、自社の選び方として定着させてください。

合計を100点とし、各評価軸を5段階で採点して配点を掛けると、部署ごとの評価を一つの表にまとめられます。採点は情報システム部門、利用部門、購買部門などが別々に行い、点数が大きく割れた項目だけを議論すると、選定会議の時間を短くできます。この評価シートは、選び方の根拠を示す稟議書の添付資料としても使えます。

上流工程の進め方を最も重く見る理由

大企業のシステム開発で起きる手戻りの多くは、要件定義の段階での認識のズレから生まれます。文章の要件定義書だけで合意すると、利用部門と開発側で思い描いている画面や動きが違ったまま開発が進み、テスト段階で問題が表面化します。そのため、システム開発会社の選び方では、上流工程で認識をどう合わせるかを最も重い評価軸に置くことをおすすめします。

具体的には、画面のプロトタイプを早い段階で見せながらヒアリングを繰り返す進め方か、業務フローと要件をどの粒度で文書化するかを確認します。画面を見ながら合意する進め方を提案に含めているかどうかが、選び方の分かれ目になります。

業務理解と類似実績の見方

実績を見る際の選び方のコツは、件数よりも中身を見ることです。同じ業界の実績があるかに加えて、自社と同じ規模の組織で、既存の基幹システムと連携する案件を経験しているかが重要です。公開されている事例だけで判断せず、担当予定者に当時の課題と進め方を具体的に質問すると、経験の深さがわかります。

UXと現場定着の確認ポイント

どれほど要件どおりに作っても、現場で使われなければ投資は回収できません。大企業では、利用者が数百人から数千人に及ぶこともあり、使いにくさは問い合わせ対応や教育コストとして積み上がります。利用者へのヒアリングや業務観察をどう行い、その結果を画面と業務の設計にどう反映するかを、提案段階で確認しておくことが、現場定着を重視する選び方です。

技術力とアーキテクチャの確認ポイント

技術力は、使える言語やフレームワークの数ではなく、自社の環境に合った設計ができるかで判断します。既存システムとの連携方式、将来の機能追加への備え、社内のセキュリティ審査への対応実績を質問すると、提案の具体性に差が出ます。特定の製品やパッケージありきの提案になっていないかも、選び方の重要な確認点です。

体制とキーパーソンの確認ポイント

提案の場に出てきた担当者が、実際のプロジェクトに参画するとは限りません。プロジェクトマネージャーと主要メンバーの経歴、稼働率、再委託先の有無と範囲を事前に確認します。可能であれば、契約前に主要メンバーと面談する機会を設ける選び方にすると、体制のミスマッチを防げます。

運用保守と引き継ぎの確認ポイント

保守運用まで同じ会社に任せる場合でも、将来の内製化や別会社への引き継ぎを想定しておくことが大切です。設計書やソースコードの管理方法、ドキュメントの整備範囲、知的財産の帰属を確認します。特定の会社にしか保守できない状態を避ける考え方は、ベンダーロックインの記事で解説しています。

見積もりの妥当性の確認ポイント

見積金額の選び方では、総額の大小よりも根拠と前提条件を比較します。工程ごとの工数、想定している画面数や連携数、含まれていない作業、仕様変更時の扱いが明記されているかを見ます。金額だけが極端に低い提案は、前提条件の違いや後工程での追加費用を含んでいることが多いため、必ず内訳を確認してください。

システム開発会社の選び方を形にする選定プロセス

評価シートができたら、それを使って候補を絞り込む手順を決めます。システム開発会社の選び方は、評価軸だけでなく、どの順番で何を決めるかというプロセスまで設計して初めて機能します。大企業の案件では、次の5段階で進めると合意形成がしやすくなります。

1 ロングリストを作りRFIで情報を集める

まず、業界の実績や得意領域から10社前後の候補をリストアップし、RFIで会社概要、得意領域、体制、類似案件の有無などの情報を集めます。この段階では提案を求めず、比較のための基礎情報をそろえることに集中するのが、段階的な選び方の基本です。RFIとRFPの使い分けは、RFIとRFPの違いの記事で整理しています。

2 ショートリストに絞りRFPを出す

RFIの回答と評価シートの一部の項目で、3〜5社に絞り込みます。絞り込んだ会社には、目的、現状の課題、依頼範囲、制約条件、評価方針を記したRFPを提示します。RFPの質が提案の質を左右するため、書き方はRFPの書き方を参考に準備してください。

3 提案を評価シートで採点する

各社の提案書と見積もりを受け取ったら、評価シートに沿って関係部署が個別に採点します。提案説明会では、事前に用意した質問を全社に同じ順番で投げると、回答の比較がしやすくなります。点数が割れた評価軸については、追加の質疑や資料提出を依頼して判断材料をそろえます。

4 小さな検証で進め方を確かめる

上位2社程度に絞れた段階で、可能であれば短期間の要件整理やプロトタイプ作成を有償で依頼し、実際の進め方を確かめます。提案書の上ではどの会社も上流工程を重視すると書きますが、実際に一緒に作業すると、ヒアリングの深さや認識合わせの速さに差が出ます。小さな検証の結果は、選び方の妥当性を経営層に説明する材料としても説得力があります。

5 契約形態と条件を詰めて合意する

最終的な発注先が決まったら、契約形態、成果物の定義、検収の基準、知的財産の扱い、仕様変更時の手続きを詰めます。要件が固まりきっていない上流工程は準委任契約、範囲が明確な開発工程は請負契約というように、工程ごとに契約形態を分ける方法もあります。契約形態の違いは準委任と請負の記事で詳しく解説しています。

システム開発会社の選び方でよくある失敗と対策

ここからは、大企業のシステム開発会社の選び方で起きやすい失敗を5つ取り上げます。どれも評価シートとプロセスを整えることで防げるものです。自社の選定がいずれかに当てはまっていないか、確認しながら読んでください。

見積金額の安さで決めてしまう

最も多い失敗は、総額の安さを決め手にしてしまうことです。前提条件が違う見積もり同士を比べても意味がなく、後から追加費用が発生して、結果的に高くつくことが少なくありません。対策は、評価シートで価格の配点を決めておき、見積もりは根拠と前提条件をそろえたうえで比較する選び方に切り替えることです。

要件が固まらないまま丸投げする

社内で目的や範囲を詰めないまま、要件定義をまるごと開発会社に任せるケースも失敗につながります。開発会社は業務の背景や社内の事情を知らないため、文書としては整った要件でも、現場の実態とずれた内容になりがちです。上流工程を外部に頼る場合でも、プロトタイプなどを使って社内の関係者が判断に参加できる進め方を選ぶことが大切です。

提案時の印象だけで体制を判断する

提案説明会で優秀な担当者が説明していても、実際の開発は別のメンバーや再委託先が担うことがあります。体制を重視する選び方では、体制図と主要メンバーの経歴を事前に確認し、契約書や発注書に主要メンバーの参画を明記するよう依頼すると、このリスクを下げられます。

パッケージありきの提案に引きずられる

特定の製品の販売を主な事業とする会社に相談すると、その製品を前提とした提案になりやすくなります。製品が業務に合っていれば問題ありませんが、合わない部分をカスタマイズで埋め続けると、費用がかさみ、将来の乗り換えも難しくなります。システム開発会社の選び方としては、スクラッチ開発、パッケージ、SaaSを比較したうえで手段を提案してくれるかを評価軸に入れておくと安心です。

リリース後の運用を考えていない

開発の評価だけで発注先を決め、保守運用の範囲や費用、引き継ぎの方法を詰めていないと、リリース後に困ることになります。障害対応の体制、機能追加の進め方、ドキュメントの整備範囲を、選定の段階で比較しておきましょう。保守の比較を後回しにしない選び方が、長期の総コストを抑えます。

システム開発会社の選び方に沿って条件に合う会社の例

最後に、ここまでの選び方に沿って候補になりうる開発会社の例を紹介します。紹介内容は各社の公式サイトで確認できた範囲に限っています。自社の選び方や評価シートに当てはめる際の参考にしてください。

株式会社FAKE

株式会社FAKEは、東京・恵比寿に拠点を置き、「デザインドリブン®」を掲げてUI/UXデザイン、業務システムの戦略からUI/UXデザイン、システム開発、新規事業支援、FDE支援、AI開発を提供している会社です。この記事で最も重く見ることをおすすめした上流工程の進め方と、UXと現場定着の2つの評価軸に強みがあります。

FDE支援では、大企業のDXの上流工程に入り、プロトタイプとヒアリングを繰り返して抽象的な議論を具体化しながら、AIを使ったドキュメント作成も並行して進めます。認識合わせと要件定義書の作成を一つの流れで完結させる進め方です。システム開発の失敗原因を「現場に使われないシステム」と「要件定義と合意形成に時間がかかりすぎること」の2つと捉え、UXを起点とした業務の再設計とプロトタイピングで解決を図ります。

パッケージを前提とせず、AI駆動の開発でスクラッチ開発を低コストで実現する方針のため、ベンダーロックインを避けたい企業にも合います。システム開発では、ビジネスを理解したPdMを中心にチームを組成し、Figmaで詳細を詰めてから実装することでドキュメント作業を短縮します。MVP開発から品質を重視した本開発、保守運用まで対応しており、多言語や大規模開発を経験したメンバーが在籍しています。

FDEの考え方はFDEとはの記事で解説しています。評価シートを使った候補比較の段階からご相談いただくことも可能ですので、お問い合わせからお気軽にご連絡ください。

株式会社NTTデータ

株式会社NTTデータは、東京都江東区豊洲に本社を置く会社です。公式サイトでは、世界70ヵ国以上でITサービスを提供しており、コンサルティングからシステムづくり、システムの運用に至るまでさまざまなサービスを提供していると紹介されています。全社規模の大規模なシステム開発で、コンサルティングから運用までを一つの会社にまとめて任せたいという選び方をする場合の候補になります。

株式会社Sun Asterisk

株式会社Sun Asteriskは、東京都千代田区大手町に拠点を置く会社です。公式サイトでは、エンジニア、デザイナー、戦略コンサルなどが集まるデジタル・クリエイティブスタジオと紹介されており、プロダクト開発、事業戦略の立案、大手企業のDX支援などを手がけています。新規事業やプロダクト開発を、事業とデザインと技術のチームで進めたい場合の候補になります。

モンスターラボ

モンスターラボは、AIとデジタルの力で企業の変革と価値創造に伴走することを掲げる会社です。公式サイトでは、AI・デジタル活用構想、システムのモダナイゼーション、データ活用と基盤構築、顧客体験の変革、デジタルプロダクト開発、内製化支援などのサービスが紹介されています。既存システムのモダナイゼーションと内製化をあわせて検討したい場合の候補になります。

まとめ

大企業のシステム開発会社の選び方では、実績や価格を見るだけでなく、評価の物差しを社内でそろえることが欠かせません。目的と依頼範囲、制約条件、評価方針を先に決め、配点つきの評価シートで候補を比較すると、関係部署の合意形成と稟議がスムーズになります。

評価軸の中では、上流工程で関係者の認識をどう合わせるかと、現場で使われるUXをどう設計するかを特に重く見ることをおすすめします。選定プロセスはRFIとRFPで段階的に絞り込み、可能であれば小さな検証で進め方を確かめてから契約に進みましょう。

価格の安さで決める、要件を丸投げする、パッケージありきの提案に引きずられるといった失敗は、評価シートとプロセスを整えることで防げます。上流工程から伴走できる開発会社をお探しの場合は、株式会社FAKEへのお問い合わせからご相談ください。

システム開発会社の選び方に関するよくある質問

候補は何社くらいに絞ればよいですか

段階的な選び方では、RFIの段階で10社前後、RFPを出す段階で3〜5社に絞るのが一般的です。候補が多すぎると評価と質疑に時間がかかり、少なすぎると比較の材料が不足します。最終的には上位2社程度で小さな検証を行うと、判断の確度が上がります。

大手と中小の開発会社はどちらを選ぶべきですか

会社の規模そのものよりも、依頼したい範囲と案件の性質に合っているかで判断するのがよい選び方です。全社規模で多くの既存システムが関わる案件では大手の総合力が生きる場面があり、上流工程の具体化や現場のUXを重視する案件では専門性の高いチームが力を発揮することがあります。評価シートで同じ物差しを当てて比較することが大切です。

評価シートの配点はどう決めればよいですか

配点は案件の目的によって変えるのが、実務的な選び方です。新しい業務の立ち上げや業務改革を伴う案件では上流工程とUXの配点を高くし、既存システムの更新では技術力と運用保守の配点を高くするのが目安です。配点は提案を受け取る前に関係部署で合意し、後から変えないことがポイントです。

要件定義が終わっていなくても相談できますか

相談できます。むしろ、要件が固まっていない段階から上流工程に関わってもらうほうが、手戻りを減らせる場合があります。その場合は、構想策定や要件定義を準委任契約で依頼し、開発工程は要件が固まってから改めて見積もる進め方が考えられます。

選定にはどのくらいの期間を見込むべきですか

案件の規模や社内の決裁プロセスによって変わりますが、RFIから契約までの各段階に、社内の確認と稟議の時間を含めて余裕を持たせておくことが重要です。特にセキュリティ審査や購買部門の手続きは時間がかかることが多いため、選定の計画を立てる最初の段階で関係部署にスケジュールを確認しておきましょう。