「この会社、大丈夫だろうか」その違和感を放置しない
先代から会社を引き継いで、初めて自社の基幹システムやホームページのリニューアルを外部の開発会社に発注する。そんな場面で、多くの後継社長が同じ壁にぶつかります。
「専門用語が並んでいて、何を言っているのか分からない」 「見積もりの金額が高いのか安いのか判断できない」 「先代の代からの付き合いだから、と言われて疑問を飲み込んでしまう」
システム開発は、車の修理や店舗の内装工事と違って、進んでいる様子が目に見えません。契約してから半年後に「動くものが出てきたら想像と全然違った」「追加費用が青天井で膨らんだ」という事態が発覚しても、その時点ではもう後戻りが難しいケースが大半です。
だからこそ、契約前・契約直後の「違和感」を正しく言語化し、危険なサインを早期に見抜く力が、承継社長には特に必要です。先代の人脈やしがらみで付き合いが続いているベンダーほど、「今さら疑うのは失礼では」という心理的な壁が働きやすく、結果として問題の発覚が遅れがちだからです。
この記事では、実際に中小企業の現場でトラブルに発展しやすい「危険な開発会社のサイン」を10個、具体的な兆候・なぜ危険なのか・見抜いたらどう動くべきかまでセットで解説します。
この記事の対象と前提
本記事は、次のような状況にある方を想定しています。
- 先代からの会社を引き継いだばかりで、システム開発の発注経験が少ない
- 既存の取引先（開発会社・制作会社）との契約更新や新規案件の相談を控えている
- 「なんとなく不安だが、何が問題なのか言葉にできない」状態にある
- 専門用語や業界慣習に詳しくなく、対等な立場で交渉する自信がない
先代の代から続く取引先を疑うのは気が引けるものです。しかし、経営者としての責任は「関係の継続」ではなく「会社の資産と時間を守ること」にあります。違和感の正体を知ることは、関係を壊すためではなく、健全な取引を続けるための第一歩です。まだ既存ベンダーに正式な相談を持ちかけていない段階であれば、刷新を開発会社に相談する前に、決めておきたい3つのことを先に読んでおくと、この記事のサインをより具体的に照らし合わせられる。承継直後で外部ベンダーへの挨拶のタイミングに迷っている場合は、外部ベンダーに先に挨拶するか、社内の把握を終えてからにするかも参考になる。
危険なサイン10選 一覧チェックリスト
まず全体像を先に示します。詳細は次の章から順に解説します。
- 見積もりの内訳が「一式」表記ばかりで金額の根拠が説明されない
- 契約書や発注書を交わさず、口頭・メールのやり取りだけで進めようとする
- 何を作るかの合意（要件）を文書化しないまま開発に着手する
- 進捗報告が「順調です」の一言で終わり、具体的な成果物の共有がない
- 質問すると専門用語で押し切られ、噛み砕いた説明を避ける
- 追加費用の発生条件があいまいで、後から次々と請求が来る
- 納品物の検査基準や合格条件を事前に決めたがらない
- 過去の実績や類似案件の話を聞いても具体的な事例が出てこない
- 契約や見積もりの意思決定を極端に急がせる
- 担当者が頻繁に変わり、経緯が引き継がれていない
それぞれ詳しく見ていきましょう。
サイン1 見積もりの内訳が「一式」表記ばかり
見積書を受け取ったとき、「システム開発一式 300万円」のような表記しかない場合は要注意です。
まともな開発会社の見積もりであれば、通常は次のような工程ごとの内訳が示されます。
- 要件整理・仕様確認にかかる工数
- 画面設計・デザインにかかる工数
- 開発（フロントエンド・バックエンド）にかかる工数
- テスト・動作確認にかかる工数
- 導入後のサポート・保守にかかる費用
内訳が「一式」でまとめられていると、何にいくら払っているのかが分からず、後から「これは含まれていません」と追加請求される余地を相手に与えてしまいます。逆に言えば、内訳を細かく開示できる会社は、自社の作業を工程管理できている証拠でもあります。
見抜き方: 見積もりを受け取ったら、「この内訳をもう少し工程別に分けてもらえますか」と一度聞いてみてください。ここで嫌な顔をされたり、「そこまで細かく出すのは難しい」と濁されたりしたら要注意です。逆に快く応じてくれる会社は、自社の見積もり根拠に自信があるということです。
依頼する側も、発注前に「何を」「どこまで」作ってほしいかを整理したRFP（提案依頼書）を用意しておくと、見積もりの精度と内訳の透明性が格段に上がります。RFPがなくても口頭で要望を伝えることはできますが、文書にして渡すことで、後から「言った・言わない」のトラブルを防げます。
サイン2 契約書・発注書を交わさず口頭で進めようとする
「長い付き合いだから」「今回は急ぎだから」という理由で、契約書や発注書を交わさないまま作業に着手しようとする会社は危険です。
これは特に、先代の代からの付き合いがある会社で起きやすい問題です。「昔からの関係だから今さら契約書なんて水くさい」という空気ができあがっていることがありますが、経営者が交代したタイミングは、こうした慣習を見直す絶好の機会です。
契約書がないと、次のような場面で後継社長が不利になります。
- 納期に遅れが出ても、契約上の根拠がないため損害賠償等の交渉がしにくい
- 「追加で頼んだ覚えのない機能」の費用を請求されても反論しにくい
- 開発会社が倒産・廃業した場合に、支払い済みの前払い金を回収する法的根拠が弱い
- 著作権やソースコードの帰属があいまいなまま、実質的に「人質」に取られる
システム開発の契約形態には、成果物の完成を約束する請負契約と、業務の遂行そのものを委託する準委任契約の2種類が代表的です。どちらの形態であっても、契約書を交わさずに進めることの危険性は変わりません。むしろ、自社の案件がどちらの契約形態にあたるのかを理解しないまま口頭で進めてしまうと、トラブル時にどちらの責任分担ルールが適用されるのかすら分からなくなります。この2つの契約形態の違いそのものについては、請負契約と準委任契約、何がどう違うのかで詳しく解説している。
見抜き方: 「今回は正式に発注書と契約書を交わしたいのですが」と伝えて、相手の反応を見てください。「今までそんなことしたことがない」「面倒だから」という返答が返ってきたら、取引全体を見直すタイミングかもしれません。
サイン3 要件を文書化しないまま開発に着手する
打ち合わせで「こんな感じのシステムが欲しい」と口頭で伝えただけで、「分かりました、進めておきます」と即座に着手する会社も危険信号です。
システム開発でもっとも多いトラブルの原因は、発注者と開発会社の間で「何を作るか」の認識がズレていることです。IT関連の業界団体や独立行政法人情報処理推進機構（IPA）が公開する調査でも、システム開発プロジェクトの失敗要因として要件の認識齟齬が繰り返し指摘されています。
口頭の打ち合わせだけで開発が進んでしまうと、以下のような事態が起こります。
- 納品されたシステムが「思っていたものと違う」と感じても、当初の合意内容が文書に残っていないため、どちらの認識が正しいか水掛け論になる
- 追加の要望を出すたびに、それが「当初の範囲内」なのか「追加費用が発生する範囲」なのか判断できない
- 開発途中で担当者が変わった場合、経緯を知る人がいなくなり、一から説明し直しになる
まともな開発会社であれば、着手前に打ち合わせ内容を文書に整理し、「これで合っていますか」という確認のステップを踏みます。この確認作業を丁寧に行う会社ほど、後々のトラブルが少ない傾向にあります。
見抜き方: 打ち合わせの後、「今日話した内容を書面にまとめて送ってもらえますか」と依頼してみてください。ここで何も出てこない、あるいは非常に簡素な箇条書きで終わる場合は要注意です。逆に、画面のイメージや機能の一覧、スケジュールまで整理した資料が出てくる会社は信頼度が高いといえます。
こうした文書化のプロセスは、専門的には要件定義と呼ばれる工程にあたります。この工程を省略、あるいは形だけで済ませる会社は、後になって「言った・言わない」のトラブルの温床になりやすいので特に注意してください。
サイン4 進捗報告が「順調です」の一言で終わる
契約後、定期的な進捗報告の場で「順調に進んでいます」「特に問題ありません」としか言わない会社も要注意です。
健全な開発会社であれば、進捗報告には具体的な材料が伴います。
- 「今週はログイン機能の実装が完了し、来週から会員登録画面に着手します」
- 「当初の想定より画像アップロード機能の実装に時間がかかっており、3日ほど遅延する見込みです」
- 実際に動く画面のキャプチャや、テスト環境へのアクセスURL
これらの具体的な材料がなく、抽象的な言葉だけで済まされている場合、実際には作業が進んでいない、あるいは開発の方向性がずれていることを隠している可能性があります。
特に危険なのは、「順調です」という報告が続いた後、納期直前になって突然「実は大幅に遅れています」「一部機能の実装が困難だと分かりました」という報告が来るパターンです。これは進捗管理そのものが機能していない証拠であり、後継社長がプロジェクトの実態を把握する手段を失っていた期間が長いほど、リカバリーの選択肢は狭まります。
見抜き方: 進捗報告の際に「今、実際に動いている画面を見せてもらえますか」と一度聞いてみてください。まだ着手すらしていない、あるいは見せられるものが何もない状態が続く場合は、契約内容の見直しを検討すべきタイミングです。
サイン5 質問すると専門用語で押し切られる
「サーバーのアーキテクチャがどうこう」「APIの仕様がこうだから」と、専門用語を並べて説明され、結局何を言っているのか分からないまま「そういうものか」と納得させられてしまう。このパターンも危険なサインです。
良い開発会社は、専門知識のない発注者に対して、専門用語をかみ砕いて説明する努力をします。逆に、専門用語で相手を煙に巻くような説明の仕方をする会社は、次のいずれかの状態にあることが多いです。
- 発注者に理解されると都合の悪い事情（工数の水増しや、技術的な難易度の誤魔化し）を隠している
- そもそも自社の技術者も、なぜその技術を使うのか本質的に理解していない
- 発注者を「専門知識のない客」として軽視している
先代の時代から「専門的なことは分からないから任せる」というスタンスで発注してきた会社ほど、このパターンに陥りやすい傾向があります。しかし、経営者が変わったこのタイミングで、「分からないことは分かるまで聞く」という姿勢に切り替えることが、今後のリスク管理において非常に重要です。
見抜き方: 専門用語が出てきたら、その場で「すみません、それはどういう意味ですか。小学生にも分かるように教えてください」と率直に聞いてみてください。良い会社の担当者であれば、嫌な顔をせず、たとえ話などを使って説明してくれます。逆に「説明しても分からないと思います」といった態度を見せる担当者がいる会社は、今後のパートナーとしてふさわしいか慎重に検討すべきです。
サイン6 追加費用の発生条件があいまい
契約時に「追加費用が発生する場合はご相談します」としか説明がなく、具体的にどのような変更が追加費用の対象になるのかが決まっていない状態も危険です。
このパターンで実際によくあるトラブルは以下の通りです。
- 打ち合わせで「ついでにこれもお願いします」と軽い気持ちで伝えた内容が、後になって高額な追加請求の対象になっていた
- 当初の見積もりに何が含まれていて何が含まれていないのか誰も把握しておらず、開発会社側の言い値で追加費用が決まっていく
- 「思っていたのと違うので直してほしい」という修正依頼のたびに、都度「これは仕様変更なので追加費用です」と言われる
これを防ぐには、契約前の段階で「どこまでが契約範囲に含まれるか」を明文化した文書を用意してもらうことが有効です。この文書は業界ではSOW（作業範囲記述書）と呼ばれ、成果物の範囲、作業内容、除外事項（何が含まれないか）まで具体的に記載されているのが望ましい形です。
SOWがない、あるいは「作業範囲は別途相談」としか書かれていない見積もりは、後から際限なく追加費用を請求される温床になります。
見抜き方: 契約前に「この金額に含まれる作業範囲を文書にしてもらえますか。特に、含まれない作業(スコープ外)についても明記してほしいです」と依頼してください。ここで「そこまで細かく決めなくても、都度相談すれば大丈夫ですよ」という回答が返ってきたら、要注意です。
サイン7 検査基準や合格条件を事前に決めたがらない
「納品されたものをどう評価すれば完成と認められるのか」という基準を、事前に決めたがらない開発会社も危険です。
システム開発の最終工程では、発注者が成果物を確認し、契約通りに仕上がっているかをチェックする検収という工程があります。この検収の基準（何をテストして、何が満たされていれば合格とするか）を事前に取り決めていないと、次のような事態が起こります。
- 納品されたものに明らかな不具合があっても、「仕様通りです」と言い張られて水掛け論になる
- 検収の期限があいまいなまま長期間放置され、支払いの根拠があやふやになる
- 「テストは開発会社側で完了しているので大丈夫です」という説明だけで、発注者側の確認機会が実質的に与えられない
健全な開発会社であれば、契約の早い段階で「このような項目でテストし、これが満たされれば検収完了とします」というチェックリストを提示してくれます。これがない、あるいは「納品してから決めましょう」と先送りにする会社は、成果物の品質に自信がないか、後から言い逃れをする余地を残そうとしている可能性があります。
見抜き方: 契約の段階で「検収の基準とスケジュールを事前に文書にしてもらえますか」と依頼してください。ここでの反応の良し悪しは、その会社の品質に対する姿勢を測る良い指標になります。
サイン8 実績を聞いても具体的な事例が出てこない
「これまでどんな会社のシステムを作ってきましたか」と聞いたときに、具体的な業種・規模・課題・解決内容が出てこず、「いろいろな業種の実績があります」といった曖昧な回答しか返ってこない会社も注意が必要です。
もちろん、守秘義務によって取引先の名前を出せないケースは正当にあり得ます。しかし、その場合でも、業種や規模、抱えていた課題、どう解決したかという「事例の骨格」までぼかされるのは不自然です。
信頼できる開発会社であれば、次のような具体性を持って話してくれます。
- 「製造業の在庫管理システムを、Excel管理から脱却させる形で構築した実績があります」
- 「小売店向けの予約システムで、電話対応の工数を月間◯時間削減した事例があります」
- 自社の技術選定について、「なぜその技術を選んだか」の理由を説明できる
逆に、抽象的な実績アピールしかできない会社は、実績が本当に少ない、あるいは過去の案件がうまくいっていない可能性を疑うべきです。
見抜き方: 「自社の業種に近い実績を、差し支えない範囲で教えてください」と具体的に聞いてみましょう。ここで即座に具体的な話が出てくるかどうかで、その会社の経験の厚みがある程度分かります。
サイン9 契約や意思決定を極端に急がせる
「今月中に契約いただければ特別価格にします」「この見積もりは今週until限定です」といった形で、意思決定を極端に急がせる営業トークにも注意が必要です。
もちろん、正当なキャンペーンや、公的な補助金の申請期限に合わせたスケジュール調整は存在します。実際、IT導入補助金のような公的制度には申請の締め切りがあり、それに合わせて動くこと自体は不自然ではありません。ただし、この場合でも「なぜこの期限までに決める必要があるのか」を論理的に説明できることが前提です。
危険なのは、次のようなケースです。
- 明確な理由もなく「今すぐ決めないと損」という雰囲気だけで契約を迫る
- 見積もりの根拠や契約内容を十分に検討する時間を与えない
- 「先代の頃からずっとお付き合いしてきたので、今回もすぐに決めていただけますよね」と、関係性を盾にして判断を急がせる
特に3つ目のパターンは、先代から会社を継いだばかりの後継社長が狙われやすい典型的な手口です。「先代との関係」を理由に、本来検討すべき内容の検討を省略させようとする意図がある場合は、明確な危険信号と捉えてください。そもそも、なぜ開発の現場でスケジュールが押しやすいのかという構造を知っておくと、根拠のない急かしを見抜きやすくなる。詳しくはなぜ開発は遅れるのか。承継社長が押さえる納期・スケジュールの見方を参照してほしい。
見抜き方: 急かされたら、一度持ち帰る勇気を持ってください。「重要な意思決定なので、社内で検討する時間をください」と伝えて、それでも強く急かしてくる会社であれば、その時点で取引の継続を再考すべきです。良い会社であれば、多少のスケジュール調整には応じてくれます。
サイン10 担当者が頻繁に変わり経緯が引き継がれない
プロジェクトの途中で担当者が何度も変わり、そのたびに「一から説明してください」と言われる状態も危険なサインです。
担当者の異動や退職は、どの会社にも起こり得ることです。問題なのは、担当者が変わった際の引き継ぎが機能していないことです。健全な会社であれば、次のような対応が取られます。
- これまでの打ち合わせ議事録や要件定義書を新担当者が事前に確認した上で引き継ぎの挨拶に来る
- 新担当者が「これまでの経緯は把握しています」と具体的に説明できる
- 発注者側に一から同じ説明をさせない配慮がある
逆に、担当者が変わるたびに発注者側が同じ説明を繰り返させられる状態が続く場合、その会社では次のいずれかの問題が起きている可能性が高いです。
- 社内のドキュメント管理・情報共有の体制が整っていない
- 離職率が高く、組織として不安定な状態にある
- プロジェクト自体が社内で軽視されており、経験の浅い担当者が使い捨てのように配置されている
見抜き方: 担当者交代の連絡を受けたら、「これまでの経緯を引き継ぎ資料としてまとめていただけますか。また、新しい担当者の方は何年ほどの経験をお持ちですか」と聞いてみてください。ここで曖昧な回答しか得られない場合は、プロジェクト全体の管理体制を疑うべきです。
危険なサインを見つけたときの具体的な対処法
ここまで10個のサインを紹介しましたが、実際に自社の取引先にいくつか当てはまった場合、どう動けばよいのでしょうか。段階を追って説明します。
ステップ1 感情的にならず事実を書き出す
まずは冷静に、当てはまるサインを箇条書きで書き出してください。「なんとなく不安」という感覚のままでは、社内の他の役員や、相談する専門家にも状況が伝わりません。「見積もりに内訳がない」「契約書がない」「進捗報告が抽象的」というように、事実ベースで整理することが第一歩です。
ステップ2 小さく確認できる要求から出してみる
いきなり「契約を打ち切ります」と伝えるのではなく、まずは小さな要求から出してみましょう。「見積もりの内訳を教えてください」「進捗が分かる画面を見せてください」といった、応じやすい要求への反応を見ることで、相手の姿勢が分かります。
ここで快く対応してくれる会社であれば、単に今までのやり方が「業界の悪しき慣習」として続いていただけで、悪意はない可能性があります。逆に、小さな要求にすら強く抵抗する、または曖昧にはぐらかす会社であれば、より慎重な対応が必要です。
ステップ3 進行中の案件は小さく区切って発注し直す
すでに大きな案件を進めている場合、いきなり全てを止めるのはリスクがあります。可能であれば、案件を小さな単位に区切り直し、それぞれの単位ごとに検収と支払いのタイミングを設ける形に契約を見直すことを提案してみてください。
新規で発注を検討している場合は、最初から小さく試すことを前提とした発注の仕方も有効です。いきなり大規模なシステムを一括発注するのではなく、必要最小限の機能に絞った試作版であるMVP（実用最小限の製品）を先に発注し、その過程で開発会社の対応や品質を見極めてから本格発注に進む、という段階的な進め方をおすすめします。この進め方であれば、万が一その会社との相性が悪いと分かっても、被害を最小限に抑えられます。
ステップ4 セカンドオピニオンを取る
社内に技術に詳しい人材がいない場合、契約書や見積もりを別の第三者(他の開発会社、ITコーディネーター、商工会議所の相談窓口など)に見てもらうことも有効です。第三者の視点が入ることで、自社だけでは気づけなかった問題点が明らかになることがあります。
セカンドオピニオンを取ることを、既存の取引先に隠す必要はありません。「念のため第三者にも見てもらいたい」と正直に伝えて、それに対して強い拒否反応を示す会社であれば、それ自体が新たな危険信号です。
ステップ5 契約解除・取引先変更を検討する場合の注意点
危険なサインが複数重なり、取引先の変更を検討する場合は、以下の点に注意してください。
- 現在の契約書の解除条項を確認する(違約金の有無、解除通知の期限など)
- これまで開発してもらったシステムのソースコードやデータの著作権・所有権の所在を確認する
- 引き継ぎ資料(仕様書、設計書、アカウント情報など)を確実に受け取ってから関係を終了する
- 感情的な対立を避け、事務的かつ丁寧なコミュニケーションを心がける
特にソースコードの受け渡しは、契約書に明記されていないと「著作権は開発会社に帰属する」と主張され、他社への引き継ぎが困難になるケースがあります。この点は契約解除の交渉において最も揉めやすいポイントの一つなので、慎重に進めてください。先代から引き継いだ保守契約がある場合は、解除条項やデータの帰属を確認する前に、先代から引き継いだ保守契約、内容を確認せず放置していませんかにも目を通しておくと抜け漏れを防ぎやすい。
承継社長が特に陥りやすい心理的な罠
最後に、後継社長ならではの心理的な罠についても触れておきます。
罠1 「先代がお世話になった会社だから」
先代の代からの関係性を大切にしたい気持ちは自然なものです。しかし、その気持ちが「疑問を持つこと自体が失礼」という思考にすり替わってしまうと危険です。関係を大切にすることと、健全な取引条件を求めることは両立します。
罠2 「今さら聞くのは恥ずかしい」
専門用語や業界慣習について、先代であれば知っていたかもしれない、あるいは長年の付き合いで暗黙の了解ができていたかもしれません。しかし、経営者が交代した以上、新しい経営者が同じ知識を持っている前提で会話が進むこと自体が不自然です。分からないことを聞くのは恥ではなく、経営者としての当然の責務です。
罠3 「反対されたら会社を辞めさせられた社員に示しがつかない」
先代の代からの担当者や社内の古参社員が、既存の取引先を強く推薦している場合、それに反対することが社内の人間関係を壊すのではないかと恐れることがあります。しかし、最終的にシステムの費用対効果と品質に責任を持つのは経営者自身です。社内の意見は参考にしつつも、最終判断は経営者としての視点で行う必要があります。
罠4 「専門用語が分からないのは自分の勉強不足」
これは大きな誤解です。発注者が全ての専門用語を理解する必要はありません。むしろ、専門用語を発注者にも分かる言葉で説明する責任は、専門家である開発会社側にあります。「分からないことを分からないと言えること」こそが、賢い発注者の条件です。
よくある質問(FAQ)
Q1. 先代の代から10年以上付き合いのある開発会社です。今さら契約書を交わしたいと言い出すのは角が立ちませんか。
角が立つことを恐れる必要はありません。「代替わりを機に、社内の管理体制を整えたいので」という説明で十分に伝わります。長年の信頼関係がある会社であれば、この申し出を快く受け入れてくれるはずです。逆にこの申し出に強い抵抗を示す場合は、これまでの関係性そのものを見直す材料になります。契約書の整備は、相手を疑うためではなく、双方を守るための当然の手続きだと捉えてください。
Q2. すでに複数のサインに当てはまる開発会社と、大きなプロジェクトの契約直前です。今からでも引き返せますか。
契約書に正式な署名・捺印をする前であれば、引き返すことは十分可能です。「社内で検討する時間が必要になった」と伝えて契約を保留し、この記事で紹介したような具体的な確認事項(見積もりの内訳、SOWの整備、検収基準の明文化など)を先方に依頼してみてください。それらの依頼に誠実に応じてくれるようであれば契約を進めても構いませんし、抵抗を示すようであれば、契約前に発覚したことをむしろ幸運と捉え、他の選択肢を検討することをおすすめします。
Q3. 危険なサインに気づいたものの、社内に他に頼れる開発会社の心当たりがありません。どう探せばよいですか。
まずは焦って新しい取引先を決めないことが重要です。地域の商工会議所や中小企業支援センターでは、IT導入に関する相談窓口を設けていることが多く、開発会社の紹介や見積もりの妥当性についてのアドバイスを受けられる場合があります。また、いきなり大きな案件を新しい会社に発注するのではなく、小規模な案件で試験的に依頼し、対応の質を見極めてから本格的な取引に移行する進め方も有効です。
Q4. 開発会社を全面的に信頼せず、あら探しばかりしていると、良好な協力関係が築けなくなりませんか。
信頼と検証は対立するものではありません。むしろ、契約内容や進捗を適切に確認し合える関係こそが、長期的に良好な協力関係の土台になります。プロのスポーツ選手同士が契約書を交わすように、対等なプロフェッショナル同士の関係には、明確なルールがあってこそ健全な信頼が生まれます。この記事で紹介した確認事項は、相手を疑うためのものではなく、双方が気持ちよく仕事を進めるための共通言語だと捉えてください。
開発会社ではなく個人開発者・フリーランスへの発注を検討している場合は、リスクと向き不向きを別途確認しておきたい。個人開発者・フリーランスに頼むのはあり？承継後の発注のリスクと向き不向きにまとめた。
まとめ 違和感を言葉にする力が会社を守る
先代から会社を引き継いだ後継社長にとって、既存の取引先との関係を見直すことは、決して簡単な決断ではありません。しかし、システム開発における金銭的・時間的な損失は、後になるほど取り返しがつかなくなります。
今回紹介した10のサインを、改めて整理します。
- 見積もりの内訳が「一式」表記ばかり
- 契約書・発注書を交わさず口頭で進めようとする
- 要件を文書化しないまま開発に着手する
- 進捗報告が抽象的な一言で終わる
- 質問すると専門用語で押し切られる
- 追加費用の発生条件があいまい
- 検収基準を事前に決めたがらない
- 実績を聞いても具体的な事例が出てこない
- 契約や意思決定を極端に急がせる
- 担当者が頻繁に変わり経緯が引き継がれない
これらのサインは、単独で1つ当てはまったからといって即座に「危険な会社」と断定できるものではありません。しかし、複数のサインが重なっている場合、そのプロジェクトはすでに何らかのリスクを抱えている可能性が高いといえます。
大切なのは、違和感を感じたときに、それを「専門知識がないから分からないだけ」と片付けず、具体的な確認事項として言葉にすることです。この記事で紹介した「見抜き方」の質問例をそのまま使ってみるだけでも、相手の姿勢が見えてきます。
会社の未来を預かる経営者として、取引先との関係も、聖域なく見直す視点を持ち続けてください。それが、先代から引き継いだ会社を次の世代につなげていくための、地道だが確実な一歩になります。
