見積状況
選定　　：4社で相見積もり（国内2、国外2）
依頼内容：ソフトウェア開発
開発納期：4ヶ月（その後、段階的に機能を拡張予定）
合計予算：1,000万円以内（計画した機能全て開発した場合）

選定
相見積もりで一番安く事前の説明で密にコミュニケーションをとってくれる約束で契約

結果
事前約束も守られず進捗報告がずさんでプロジェクト進行すら可視化してもらえなかった
報告された内容と実際の開発内容に乖離が続いた
初期ローンチが複数回の遅延をして1年超えるレベルとなりプロジェクト自体が破綻

毎回、納期の数日前になって突然「開発が終わりません。」と報告を受け、同じことが数度続きました…。

予定していた施策、例えばプレスリリースだったり、お客様への営業活動、社内スタッフのスケジュール調整など全てが何度もずれ、結局その間にも人件費や対応費用が発生しているため、大きな損失となりプロジェクト自体が破綻する状況に。

私自身、開発ベンダーのトラブルで夜も寝れなくなり、プロジェクト自体も破綻したせいで事業の見直しを余儀なくされました。

ベンダーとしては自分たちの事業ではないので、悪い言い方をすれば失敗しても関係ない、しかし当事者の私としてはその事業へフルコミットして全部を捧げてきたので、何のためにやってきたのか、言葉を失ってしばらく無気力な状態にも…。

この経験から、システム開発をしてくれる会社選びで不安を抱えているあなたに、少しでもお力になれるかなと思い経験をもとに情報をまとめたので、下記を見て頂けると嬉しいです。

時間がなくても美しい資料が作れるパワポの…

内容が気になる >

国内とオフショアの違い

システムまたはソフトウェアの開発を、内製ではなく外注で作ろうと思った場合、選択肢としては大まかに分けると2つあります。

国内
国内（フロントは国内で開発現場はオフショア）

オフショアとは、海外の安い人件費対応を意味するのですが、いきなり開発をオフショアで作るのは非常にハードルが高く、プロジェクトの遅延原因になる場合も。

簡単に国内・オフショアの違いを比較してみました。

項目	国内	オフショア
費用	高い	安い
コミュニケーション	取りやすい	取りづらい
社内稟議	通りやすい	通りづらい
リスク	あるが低め	海外なのでリスク高い
開発	一般的	仕様間違いが起こりやすい
契約	請負型・ラボ型	ラボ型の方が多い

もちろん、オフショアでも高いレベルで提供してくれる会社さんもいらっしゃると思うので、全部に当てはまらないですが、下記が組み合わさると非常にリスクが高くなります。

外注 + オフショア + ラボ型(準委任契約) + 自社にプログラマーがいない

特に、一般的な契約内容である請負型（完成品を納品して費用を支払う）ではなく、ラボ型（準委任と呼ばれる稼働した工数で費用を支払う）契約にすると、トラブルが起きやすいと感じるので、それぞれの違いを解説します。

請負型とラボ型の違い

国内・オフショア、どちらも開発ベンダーさんを選ぶ際には、契約内容として請負型・ラボ型のどちらかになると思います。

請負型：ウォーターフォール型と呼ばれて決まった流れで作りきる契約
ラボ型：アジャイル型と呼ばれて作りながら変更していける契約

どちらもメリット・デメリットありますが、違いを分からず開発ベンダーさんを選んでしまうと、トラブルに発展する場合もあるため、下記の比較表を確認しておきましょう。

項目	請負型	ラボ型
開発スタイル	ウォーターフォール型作る手順と内容が決まっている	アジャイル型作りながら調整していく
人材	開発が終わるまで継続して雇う	優秀な人材を一定期間確保できる
柔軟さ	決まった以外のことは対応しずらい	柔軟に対応しやすい
コスト	高い	安い
費用計算	作り終わった段階で発生	稼働した時間ごとに発生
支払い	納品後に支払い	月ごとに〆て支払い
トラブル	発生しにくい	納期遅れ・バグの多さ・仕様間違いなど起きやすい
賠償	完成品に不具合があれば賠償は請求しやすい	完成ではなく業務遂行に対する契約なので完成に対する賠償は請求しずらい

安心・安定だったら請負型ですが、リスクを理解した上でスピード・低コストを選ぶならラボ型。

どちらを選ぶかは、あなたが開発したいシステムと、提供したい時期にもよるので、ここはじっくりと、どのような開発の進め方がいいのか検討頂ければ幸いです。

開発可能な範囲を確認する

システム・ソフトウェアが作れると言っても、開発形式・開発言語・体制など、開発会社それぞれで違ってきます。

所属しているプログラマーの影響が大きいのと、進められる開発にも特徴があります。

例）できる範囲が違う
A社：開発○、運用×、他社開発引き継ぎ×
B社：開発○、運用○、他社開発引き継ぎ×
C社：開発○、運用○、他社開発引き継ぎ○

他にも、AIに強かったり、最新技術のブロックチェーンが扱えたりと違うので、求めている開発が得意な会社さんを選ぶ必要がある。

選定前の事前知識として開発可能な範囲の違いを確認しておきましょう。

対応範囲

大きく分けて開発会社の対応範囲を以下の3つで表してみます。

① 開発
システム・ソフトウェアなどの開発業務

② 保守
開発されたシステム・ソフトウェアを安定稼働させるための保守業務

③ 他社開発の引き継ぎ
他社が開発できなくなったシステム・ソフトウェアを引き取って開発を継続する業務

外注して開発を進めるのであれば、社内で運用管理ができないことが多いので、①開発と②保守はセットで契約されるはずです。

そして、③の他社で開発していたシステム・ソフトウェアを引き取り、開発を継続させていくサービスまで対応している会社さんは多くはない。

他社が作っていると、対応できない言語や構成だったり、仕様理解などにも時間がかかるため、どの会社さんも苦手なお仕事になる。※ 開発途中で会社が変わるということは何かしらのトラブルが発生している確率も高い

もし、あなたが現在お付き合いしている開発会社さんの対応が悪くて、切り替えを考えているなら、その開発を継続して対応してくれる会社さん選びは大変かもしれません。

開発言語・サーバー

自社で運用を行ったり開発内容を判断するために、あなた自身が分かる言語を選んで開発してもらうのも一つの手です。

開発レベルに応じて、どのような言語・サーバーが必要になってくるのか簡単にまとめてみました。※ 記載してない内容も多いため一般的な内容のみにとどめています

言語・サーバーのことが全く分からない場合は、せめて誰か信用できる第三者に判断してもらえる状態を作っておくのがお勧めです。

開発言語

開発レベル	開発内容	言語
優しい	ホームページ作成	・HTML ・CSS ・JavaScript ・PHP
難しい	システム・ソフトウェア開発	・typeScript ・Java ・C/C ++ ・C# ・Python ・Ruby ・Kotlin ・Go

静的なホームページであれば、そこまで難しくはないのですが、決済機能を付けたり、サーバー側で処理するような複雑な仕様を入れると、難易度が上がっていきます。

そしてエンジニア・プログラマーだからといって全部の言語が扱えるわけではなく、みんなそれぞれ得意分野の対応範囲になる。

ちなみに私の場合は、優しいレベルはなんとか分かって、難しいレベルは全然分かりません。（それなのに開発を外注しました…）

サーバー

開発レベル	使用サーバー
優しい	・ロリポップ!レンタルサーバー・エックスサーバー・さくらのレンタルサーバ・カゴヤ・ジャパン・ヘムテル・GMOクラウド
難しい	・Amazon Web Services（AWS）・Microsoft Azure

優しいレベルだと、そのほとんどが国内サーバーであり、難しいレベルはAmazonやMicrosoftなと海外企業のサービスになります。

サーバーと一言でいっても、全てがセッティングされてすぐに使い出せるサーバー（プラン）もあれば、AWSなど一つ一つセッティングが必要であり、使い始めるのにそれなりの知識が必要なものもある。

例えばAWSなど、高品質ではあるものの、自分たちが扱えない場合は運用段階になって困ることになるので、自社運用が可能なサーバーを選ぶのか、または開発会社に運用をお願いして見てもらうのか、選択肢が色々あるんです。

人気のAWSを使う場合の注意点
例えばwordpressで使っているメール用のプラグインが使えなかったり、FTPで接続してもファイルのアップロードができないなど、通常のサーバーとは異なる対応が必要です。

ジャンル

あなたが開発したいシステム・ソフトウェアは、どんなジャンルですか？

例えば、自社のノウハウを落とし込んだ、またはあなた自身が強く感じている課題を解決するSaaSなどかもしれませんね。※ SaaS（サーズ・サース）と呼ばれるSoftware as a Serviceの略語

開発会社さんによって、作れる範囲が違うので、どんなジャンルがあるのか、その一例を確認しておきましょう。

ジャンル	参考
最新技術	AI / IOT / ブロックチェーンなど
決済	電子マネーなど
自動化	RPAなど
プラットフォーム	マッチングサービス / コンテンツプラットフォームなど
ツール	チャットボット / データ管理 / 業務効率化 / 生産性向上など
アプリ	ニュース / ゲーム / 語学 / ビジネス / ショッピングなど

時間がなくても美しい資料が作れるパワポの…

内容が気になる >

選ぶ前の事前準備

開発会社さんのスゴイところは、大抵の願いは叶えてくれること。（お金との相談）

「あれがしたい」「これを実現させたい」と、知識・技術を使って、必要なシステム・ソフトウェアを作り上げてくれます。

しかし、発注する側のあなた自身がシステム・ソフトウェアに対して一番理解しているものの、それをどう実装すべきなのかは分からないことも多いですよね。

トラブルで多いのは「こうだと思ったのに」と、自分の中だけで完結させてしまい、相手に伝わっていないパターン。

何の開発をしたいのか明確に仕様として落とし込んでおかないと、困るのはあなたなので、開発会社さんを選ぶ前に準備しておきたい情報を見て頂ければ嬉しいです。

用意しておきたい情報

私自身の苦い経験から、初めての開発を外注へお願いする場合を想定して、発注前に必ず揃えておきたい情報を2つだけお伝えします。

画面定義書（または仕様設計書）
デザイン（またはHTMLなど）

たぶん、開発会社や大規模開発を受けている人から見れば、これらの情報では足りないと言われてしまうと思うのですが、小規模だったらこのくらいが限界？かなと。

初めての開発外注なので、何をどうしていいかも分からないため、最低限お見積もりをもらうために必要な情報のみ。

最初に自分自身で設計したシステムには、必ず抜け漏れがあると思って臨みましょう。とくに画面定義書や仕様設計書などは、自分と相手との認識合わせをするためのものでもあり、そこがズレていくと後でトラブルにもなりやすいです。

画面定義書（または仕様設計書）

この図はあくまで参考のものです

レイアウト
パーツの説明
アクション（何が起こるのか）

画面定義書には、その画面で何ができるのかを示す情報が書き込まれます。

エクセルで作られることも多いですが、エクセルだとバージョン管理が難しかったり手間もあるので、設計ツールなどを使って効率化している方も。

特に、何を行うと、どんな反応を示して、どのような結果が返ってくるのか、一連の動きと求める結果を可視化させます。

「定義書を見れば分かるだろう」と思っても、相手はあなたと経験も知識も考え方も何もかも違う全くの別人なので、認識が必ずズレる。（オフショアを選んだ場合は文化などの影響でさらにズレる）

だからこそ、細かく丁寧に、わざわざ言葉にしなくても分かるようなことでも全て説明を入れて、画面定義書を作ることが大事です。

画面定義書は、あなたの頭の中を見える形で可視化させること。経験がなければ、それが実現できるか、どのくらいの規模になるのかも判断が付けられない場合も多く、開発会社に入ってもらえたタイミングで仕様を固めていけるとトラブルが減らせます。

その他必要な資料は？

事前に用意できればいいですが、知識もなく作ったことがなければ用意するのが難しい資料は下記になります。

WBS（プロジェクト全体のスケジュール）
ER図（データベースの設計図）
画面遷移図（内部リンクの移動先）
ワークフロー（プロセスの可視化）

もっと大規模開発になれば、たくさんの事前資料が必要となり、用意するのも大変。

あなたで作る必要はあるのか、開発会社に作ってもらえないか、お見積りの段階で確認いただくのがお勧めです。

抜け漏れを防ぐために

どんなに一人でがんばって画面定義書、または仕様設計をしたとしても、抜け漏れを防ぐことは難しいです。

そのため見積もりへ出す前に、なるべく社内の何人かにも見てもらって別の視点から指摘をもらい、調整をかけておくのがお勧め。

チームで動いていても、大事な画面定義はあなた一人だったり、責任者として作らなければいけない場合もあると思います。

しかし、最初に仕様詳細を考えておかないと、困るのはあなた自身にもなるので、メンバーや社内の人の手も借りで作っておきましょう。

デザイン（またはHTMLなど）

デザインを、Photoshop・Illustrator・Figma・Sketchなどのデザインツールで画面を作っておく、またはすぐ開発へ移れるように画面が再現されたHTMLを用意しておく。

画面定義書の中で、例えばエクセルの図形ツールのみで画面を表現するのでもいいですが人は見た目の生き物なので、デザインされた画面があった方が、認識しやすく分かりやすいです。

また、仕様を考えている時には気づかなかった抜け漏れが、デザインをしている最中で発見できることも多いので、可視化は重要な作業となります。

時間がなくても美しい資料が作れるパワポの…

内容が気になる >

選び方（判断基準）

私が「システム・ソフトウェア開発会社の選び方」を書こうと思ったのも、選定に苦い経験があるのと、選定時に開発会社から提出された資料や営業時に言われたことなど、見極めの甘さを感じているからです。

あなたには、このような思いをしてほしくないため、私の経験を元に開発会社の選び方・判断基準を6つのポイントにまとめたので、見て頂けると嬉しいです。

① 会社について
 ② 営業について
 ③ 開発の仕方について
 ④ 資料・提案について
 ⑤ 見積もりについて
 ⑥ 契約について

本当に、本当に大事なことなので少しだけでもご確認ください。

① 会社について

開発会社の信頼性を確認するために、売上・人数・設立年数など、それらをまとめて「規模」として見る場合もありますが、あまり当てになりません。

私が知っている別の開発会社さんは、20名前後・無借金・残業なし・継続したお客様獲得などされており、規模ではなく「人」がもっとも重要だと感じています。

大手だから、有名企業を対応しているから、上場しているから（または上場している子会社）、この感覚でいると視界が曇って選ぶべきではない開発会社を選んでしまうことも。

そうは言っても判断基準が難しいので、

継続してお付き合いしている顧客数
トラブル後の対応

とくに、トラブルが起こった場合の対応には、企業方針や文化、考え方がぎゅっと詰まっているため、どのような対応をしているかで開発会社の姿勢も確認できます。

② 営業について

何かの部分的な開発であれば少額ですが、システム・ソフトウェアを作りたい場合は1,000万円レベルは、どうしても発生してくるのかなと。

そうなれば、営業さんとしては絶対に受注をしたいところですが、営業対応をよく見極めないと、辛い体験する場合も。

開発のことが分かっている
レスポンスが早い
質問に対する回答が的確
大手企業との取引実績ばかりアピールしない

ありきたりですが、私はこれらのポイントから外れた場合、トラブルが起こる確率が高くなると感じています。

質問をした際に「開発者に聞かないと分からない」と、不確かなことは言わないため一旦確認を入れる営業さんもいますが、それは開発のことが全く分かっていない場合もあるため、色々質問をしてみて知識レベルを確認して頂くのもお勧めです。

相性の問題もあり、コミュケーションに違和感を感じた場合は、改めて考え直してください。その違和感は、あなたの心のサインかもしれません。

③ 開発の仕方について

開発の仕方次第で、納品されるシステムの品質は大きく変わってきます。

注意したいポイントとして、以下を確認しておきましょう。

多重下請け構造になっていないか？

多重下請け構造とは、元請けが案件を受注して、子会社へ依頼をする、その子会社がさらに自分たちの子会社へ依頼する…実際に開発する会社が下に流れていき、末端の開発会社が制作すること。

この形だと、案件を流した会社は利益として中間マージンを抜き続けるので、実際開発する会社に十分な費用が渡らないため、必要な人員が確保できず、時間もあまりかけられなくて納期に遅れる・バグが多い、最悪システムが動かずに納品される場合もあります。

開発会社に対して、どのような体制で開発を進めていくのか、重要なポイントなので必ず確認しておきましょう。

開発が始まる前に仕様確認がされるか？

最初に見積もりをお願いした際に、ある程度は仕様の詳細確認が入った上で金額を出してもらえると思います。

しかし、見積もりに十分な時間をかけたとしても、抜け漏れや想定外な部分は多い。

開発を進める中で、その都度確認する形でもいいですが、一つの仕様間違いが全体に影響してくる場合もあり、本格的に始まる前で仕様の再確認をしてくれるか確認しておきましょう。（確認しないと失敗原因を作ります！）

進捗をどのように共有してくれるか？

一定の流れで進んでいくウォーターフォール型であればまだいいですが、変則的に変わっていくアジャイル型の開発だと、進捗を確認することは特に重要です。

開発を外注すると、実際の開発現場をあなた自身が管理できないため、プロジェクトの進み具合が分からず、社内へ報告することもできなくなる。

プロジェクト管理・タスク管理ツールを用いて進捗共有を行ってもらえるのか、どんな方法で共有してもらえるのか確認しておきましょう。

課題管理表は用意してくれるか？

プロジェクトを進めると、99.9%何かしらの課題や小さいトラブルは出てくるものです。※ 99.9%とは、著者の体感値の話です。

その際に「以前お願いしたものが対応されていない」このような言った言わないが出てくるので、課題の解決進捗が追えるように、課題管理表を用意してくれるか確認しておきましょう。

内容も対応者・課題・解決方法・対応日など簡単でよくて、開発会社側が用意してくれないのであれば、あなた自身で用意しておくのがお勧めです。

私の場合は、課題管理表を用意したのはいいものの、あまり活用できず苦労しました。開発会社さんを選ぶ場合は、あなたにとってのパートナーにふさわしい存在か、十分吟味して選んでほしいと思います。

時間がなくても美しい資料が作れるパワポの…

内容が気になる >

④ 資料・提案について

営業される際、必ず開発会社から資料が提示されると思いますが、その中で大手や有名企業との取引実績があっても油断することがないようにしましょう。

他社の信用（取引実績）を判断軸に入れるのもいいですが、その情報は十分考慮した上で判断基準へ入れてほしいと思います。

⑤ 見積もりについて

見積もりを単なる金額が書かれている書面だと思っていると、あとで後悔するかもしれません…。

見積もりとは
・仕様の認識合わせ
・目的達成までにかかる期間の算出
・開発以外の施策を行うスケジュールを決める情報

開発だけではなく、チーム作りやプレスリリース、社内調整や運用フロー策定、営業活動やマーケティング、これら全てをどう動かしていくか考える大事な情報となります。

とくに、仕様の認識違いが見積もりの段階で発生していれば、納期遅れや求めていたシステムが出来上がらず、せっかく動こうとしていたタイミングをことごとく潰してしまう。

金額はもちろん大事ですが、このタイミングの見積もりが今後の動き方を大きく変えるポイントになっているため、焦らず見積もりを進めてほしいです。

見積もり時に確認するポイントは？

前提として、見積もりは必ず相見積もり（複数社見積もり）を行い比較が必要です。

確認したいポイントは、

仕様理解の度合いをそれぞれ説明してもらう
開発にかかる期間をそれぞれ説明してもらう
どのような体制かをそれぞれ説明してもらう

これらを踏まえた上で、他社との金額差を確認する。

少し手間なのですが、ここの手間を省くと「思っていたのと違う」となって、トラブルに発展するため、見積もりを比較するのではなく、その金額に至った見積もりの経緯を確認するのがお勧めです。

見積もり金額の違いは、開発会社の体制によりますが、やはり仕様理解の違いによって大きく金額が変わる場合もあるため、注意したいポイントです。

⑥ 契約について

開発会社を探し、見積もりをして、1社へ選定しているころには、もうあなたの体力はヘトヘトかもしれませんね。

1社を決めるまで長い道のりですが、契約のタイミングもまだまだ気が抜けず、システム・ソフトウェア開発はトラブルも多いため、契約内容があなたを守ってくれます。

言った言わないを防ぐ
トラブルになった際の保険をかけておく

請負型だと完成しなければ費用を払いませんが、ラボ型だと稼働に対して対価を支払う契約になるため、状況によってはリスクを飲まないといけない。

また、どちらか一方だけが有利になる契約はできず、依頼側と開発側の両社で落とし所を見つけて、契約内容をすり合わせていきます。

たとえ開発を急いでいたとしても、契約内容のすり合わせで相手が有利すぎる状況を作ってしまうと後が大変なので、法務とよく相談して決めていきましょう。

契約までの流れ

1. 開発会社を探す
2. 各社と秘密保持契約（NDA）を締結する
3. 見積もりを依頼する
4. 各社で比較をする
5. 1社に選定する
6. 契約フォーマットを確認する
7. 契約内容のすり合わせをする
8. 契約を締結させる

契約が終わりではなく、あくまで始まりでしかありません。

その後のプロジェクトが成功するかどうかは、選定～契約から始まるプロジェクト管理にかかっています。

時間がなくても美しい資料が作れるパワポの…

内容が気になる >

システム開発会社とのよくあるトラブル

開発関係の鉄板トラブルは、

納期に間に合わない
バグが多くて使いものにならない
仕様を間違えている
担当者の連絡が遅い（対応が悪い）

などですが、まだまだたくさんあるため書き出してみました。

自社にプログラマーがいないと正しいか判断できない

開発のすべてを外注して、保守まで開発会社でお願いしようと思った場合、本当にその開発内容が適正なのか判断できず、技術的負債をかかえてしまうことにも。

誰かしら別の視点で、開発レベルをチェックできる人を確保しておき、いつでもセカンドオピニオンできる体制にしておくのが大事です。

見積もりもらえた=仕様を理解してもらえたは大間違い

私自身もこれで苦い経験をしましたが、見積もりしてもらえた＝仕様を完全に理解してもらえた、ではありません。

むしろ、この段階で間違って認識されてしまっている場合もあるため、見積もりされても抜け漏れ必ずあると覚えておきましょう。

「外注」だからと丸投げ意識でいると失敗確率が高まる

開発会社というよりも、依頼側の意識の問題でトラブルになることもあります。

初めてシステム開発をする会社はとくに、丸投げ意識は最初から捨てておく、自分が開発メンバーの一員と考えて進めるのが大事。

それだけ開発は簡単なものではなく、関わるみんなが全力で取り組む必要があるため、全員が一眼となって頑張らないと成功確率が低くなります。

営業段階で「やれます！」「できます！」と根拠のない回答

営業さんが、プログラミングやプロジェクト管理の知識豊富な方であればいいですが、ただ受注したいがために知識不足のまま、できないことを「可能」と回答されてしまう場合もあります。

オフショアでアジャイル開発は難しい

オフショアは、海外の優秀な人材を低コストで開発メンバーとして組み込めるため、ものすごく状況としては良いです。

しかし、初めてお付き合いするオフショア会社だったり、ラボ型（アジャイル開発）と呼ばれる稼働に対する対価を支払う形だと、思わぬことで足元を救われてしまう場合も。

言語の壁
文化の壁

実体験しなければ分からないほど、この二つは思った以上に高い壁です。

伝えたい情報の意図が、伝わる過程で違うニュアンスになってしまうことも多く、文化によって時間の流れが違うことも進捗の軋みを生みます。

たとえ間にブリッジSEと呼ばれる翻訳コミュニケーターがいたとしても、オフショア現場のメンバーが間違えてしまえば、まったく違った仕様になることも。

運用が考えられていない開発がされている

その場の思いつきで開発されたようなコードが書かれていたり、ちょっと不都合が出たら何かをやり直ししなければいけないプログラムになっている場合もある。

しっかり運用のことまで考えられておらず、突然トラブルが発生する場合もあります。

セカンドオピニオンを考えている場合

現在対応してくれている開発会社の対応が悪く、切り替えや適正さを確認したい場合は、セカンドオピニオンを行うのがお勧めです。※ セカンドオピニオンとは別の専門家に意見を聞くこと

トラブル続きで完全に関係が切れてしまっている場合は別ですが、開発中の中で切り替えを行うのはなかなか難しい。

そのため、セカンドオピニオンから切り替えまでの、一連の流れを確認してみましょう。

1. 開発状況を整理する
2. セカンドオピニオン先を探す
3. 新しく見つけた開発会社と秘密保持（NDA）を締結
4. 既存の開発会社に他社介入の合意書を締結
5. 中身を確認してもらう
6. 見積もりをもらう（切り替える場合）
7. 選定する
8. 既存の開発会社との契約を解除、または開発をSTOPさせる
9. 新しい開発会社に入ってもらう

この中で難しいのは、ステップ4の他社介入を承諾させること。

介入させるのは「あなたちゃんとやってる？」と言われているようなものなので、どうしたって嫌ですよね。（悪いと言われているようなものです）

しかし、その結果を生んだのは当の開発会社側であることから、何とかセカンドオピニオンができる状態にもっていきましょう。