「大手なら大丈夫」のはずだった
ある卸売業の会社が、在庫管理と受発注を一本化する業務システムの開発を大手のシステム会社に依頼した。規模は5000万円を超えるプロジェクトだった。「実績も多く、会社規模も大きい。安心して任せられる」という判断だった。
プロジェクトは1年半かけて完成した。でも、稼働から半年が経った頃から問題が出始めた。現場担当者から「使いづらい」という声が上がり、一部の処理は以前のExcelに戻ることになった。修正を依頼すると、「仕様の変更になるため追加費用が発生します」という回答が来た。
さらに、窓口の担当者がプロジェクトの途中で3回変わっていた。最後の担当者は、経緯を把握するために引き継ぎ資料を読み込むところから始めていた。「なぜこの設計になったのか」を誰も説明できない状態で、システムだけが動いていた。
この会社の経験は、特別なケースではない。大手ベンダーへの発注で後悔した会社に共通する構造がある。
後悔する構造その1：担当者が変わり続け、誰も全体を知らない
大手のシステム会社では、プロジェクトごとに担当チームが組まれる。そのチームは固定ではなく、会社の人員配置の都合で変わることがある。プロジェクトマネージャーが変わる。エンジニアが変わる。窓口が変わる。
引き継ぎが十分に行われればいいが、実際には属人的な情報が失われることが多い。「なぜこの設計にしたか」「あの時こういう判断をした経緯」「現場でこういう問題があると聞いた」——こうした情報は文書に残りにくく、人が変わると消える。
発注者側から見ると、毎回同じ説明をしなければならない状況が生まれる。「前回の担当者に言ったはずなのに、また一から説明することになった」という経験だ。プロジェクト全体の文脈を知っている人間が、発注者以外に誰もいない状態になる。これが積み重なると、発注者は孤独にプロジェクトを管理することになる。
中小の開発会社では、一人の担当者がプロジェクト全体に最初から最後まで関わることが多い。経緯を知っている人間がいるという状況は、長期的な関係において大きな差になる。「3年前にこういう判断をした理由はこうでした」と言える担当者がいるかどうかは、稼働後の改修の質にも直結する。
後悔する構造その2：仕様変更のたびに追加費用が発生する
大手ベンダーとの契約は、多くの場合「要件定義書に基づく請負契約」の形をとる。要件定義書に書かれていない変更は、追加の見積もりが必要になる。
これ自体は契約として正当だ。だが問題は、業務システムの開発において「要件が完全に確定してから開発を始める」ことが、実際には難しいという点にある。
現場で実際に動かしてみて初めて気づく問題がある。使い始めて初めて出てくる「ここはこうしたかった」という修正がある。業務が変わって、システムもそれに合わせる必要が出てくることもある。組織改編、法改正、新しい取引先の要件——現実のビジネスは、システムの開発中にも動き続けている。
そのたびに追加見積もりが来て、予算を超えていく。仕様変更を頼むことへの心理的なハードルが上がり、現場からの改善要望が上に上がってこなくなる。そのまま使いにくいシステムを使い続けることになる。
これは大手ベンダーを責めるべき話ではない。大きな組織で多くのプロジェクトを管理するには、変更管理のプロセスが必要だ。ただ発注者の側からすると、「使い始めてから分かることが多い」という現実と、「変更は追加費用」という仕組みのあいだに挟まれることになる。
後悔する構造その3：現場を知らない人が設計している
大手ベンダーのプロジェクトでは、設計を担当するシニアエンジニアやアーキテクトと、現場ヒアリングを担当する担当者が分かれていることが多い。現場の担当者から上がってきた情報が、設計者に正確に伝わらないことがある。
現場の担当者が「この処理、毎月必ず月末の締め日に集中するんです」と伝えても、その情報が設計に反映されなければ、月末にパフォーマンスが落ちるシステムができる。「この画面は1日200回使います」という情報が伝わっていなければ、2回しか使わない画面と同じUIデザインになる。「この入力、必ず二人で確認するルールなんです」という運用の情報が伝わっていなければ、一人でも完了できる設計になって内部統制が崩れる。
現場を知っている人間が設計に関わることは、システムの完成度に直接影響する。プロジェクト規模が大きくなるほど、設計者と現場のあいだに層が増え、情報の劣化が起きやすくなる。
中小の開発会社の場合、ヒアリングをした人間が設計もする、あるいはヒアリング担当と設計担当が毎日話せる距離にいることが多い。このコミュニケーションの密度が、現場の実態を反映したシステム設計につながる。
大手が向いているケース・中小開発会社が向いているケース
大手ベンダーへの発注が向いているのは、規模が大きく、関係する部署や拠点が多く、複雑なシステム統合が必要で、セキュリティや法的な要件が厳格なプロジェクトだ。会社としての信頼性や実績が必要な場合、あるいは社内の稟議で「上場企業への発注」が条件になっている場合もある。大量のデータ処理が必要な場合、24時間365日の保守体制が必要な場合、複数の外部システムとの複雑な連携が必要な場合——こういった要件には、組織的な対応力が必要になる。
一方、中小の開発会社が向いているのは、業務の実態を深く理解してもらいながら設計したい場合だ。担当者が変わらずに長期で関係を続けたい、稼働後も柔軟に改修を重ねながら育てていきたい、予算が限られていてコスト効率を優先する必要がある——こういった要件には、動きが速く、コミュニケーションの密度が高い中小会社が向いていることが多い。
規模と目的によって、向いている発注先は変わる。「大手だから安心」「実績があるから大丈夫」という判断基準だけで選ぶと、自分たちのプロジェクトに合わない構造の中に入ってしまうことがある。
発注前に確認すべき3つの質問
開発会社と商談する時、契約前に確認しておくべき問いがある。
一つは「プロジェクト中に担当者は変わりますか」だ。最初にヒアリングした人間が、最後まで責任を持つかどうかを確認する。「チーム体制で対応します」という答えが出た時は、誰がプロジェクト全体の文脈を把握しているかを具体的に聞く。体制図を見せてもらうことも有効だ。
もう一つは「稼働後の修正はどう扱いますか」だ。稼働してから出てくる改修をどういう条件でどれくらいのコストで対応するか。小さな修正に都度見積もりが必要なのか、ある程度まとめて対応してもらえるのかを確認する。「稼働後の保守契約の内容を見せてください」と言って、その内容を確認することも一つの方法だ。
三つ目は「現場のヒアリングには誰が来ますか」だ。設計をする人間が現場に来るのか、別の担当者が来てその情報を設計者に渡すのかを聞く。設計者と現場のあいだに何層あるかを確認することで、情報の伝達精度がある程度見えてくる。「設計担当の方にも一度現場を見ていただけますか」と直接聞いてみることも効果的だ。
後悔しない発注のためには、会社の規模や知名度より、プロジェクトの構造と自社の要件が合っているかを確認することが先だ。この3つの質問に対する答え方が、その会社がどういう仕事の仕方をしているかを教えてくれる。