PH Tech AI
PH Tech AI
システム設計・技術選定

システム開発会社の選び方｜技術を知らない経営者が見積もり前に確かめる3つの点

社内に技術がわかる人がいない経営者向けに、見積もりの前に確かめるシステム開発会社の選び方を解説します。「途中で動くものを見せてくれるか」「コードとアカウントの持ち主が自社になるか」「契約の種類」の3点を、技術を知らなくても確かめられる質問にまとめました。

執筆者
執筆者執筆者

運営者・AIエンジニア ／ IT歴36年以上

システム開発会社の選び方｜技術を知らない経営者が見積もり前に確かめる3つの点

要約

  • 技術がわからなくても、開発会社は「途中で動くものを見せてくれるか」「コードとアカウントが自社の持ち物になるか」「契約の種類」の3点で見分けられます。
  • この3点は、見積もりを取る前の打ち合わせで、質問するだけで確かめられます。
  • 答えがあいまいな会社は、価格が安くても選ばないほうが安全です。納品直前に「思っていたものと違う」となったり、他の会社では手が出せない状態になったりするのを防げるからです。

なぜ「見積もりの前」に見分けるのか

システム開発会社（発注を受けてシステムやアプリを作る会社）を選ぶとき、多くの経営者は、まず数社から見積もりを取って金額を比べます。しかし、社内に技術がわかる人がいない会社ほど、金額を比べる前に、その会社と組んでよいかを決めておくべきです。

理由は、見積もりの金額は「何を作るか」が決まってから出るもので、「どう進めるか」「納品後にだれの持ち物になるか」は、金額の表にはほとんど出てこないからです。ところが、あとで大きな損につながるのは、たいてい金額ではなく、この進め方と持ち主の問題です。見積もりが出たあとの金額の確かめ方は、システム開発の見積もりは妥当か、工数の内訳から確かめる方法で説明しています。

CTO（会社の技術の責任者）がいない会社でよく起きるのは、経営者が技術的に正しいかどうかを判断できず、開発会社の言い値や説明をそのまま受け入れてしまうことです。そして公開してから、高すぎる保守（公開後に不具合を直したり、部品を更新したりする作業）の費用や、ほかの会社では手が出せないシステムに気づきます。私は、このような失敗を何度も見てきました。

技術の中身は判断できなくても、質問への答え方で確かめられます。

  1. 途中で動くものを見せてもらえるか
  2. コードやアカウントの持ち主が自社になるか
  3. 契約の種類が、進め方に合っているか

順番に説明しましょう。

確かめる点1: 途中で「動くもの」を見せてもらえるか

仕様書だけで任せると、納品直前に慌てることになる

私は日本の開発会社と、海外（フィリピン）の開発チームの両方に仕事を頼み、管理してきました。

うまくいったのは、週に1回、進捗状況を共有し、実際に動く画面を見せてもらうことを徹底した案件です。考えの食い違いが小さいうちに見つかり、すぐに直せました。

失敗したのは、仕様書（何をどう作るかを細かく書いた文書）を渡して、あとは任せきりにした案件です。納品の直前になって、思っていたものとまったく違うシステムが出てきました。文書に書いた言葉は、読む人によって受け取り方が変わります。文書だけで正しく伝わることはない、というのがこのときの教訓です。それ以来、私は最初の段階から試作品で確かめる進め方にしています。

「作っては見せる」進め方は、開発の原則

途中で動くものを見せる進め方は、特別なことではありません。アジャイル開発（短い期間ごとに作っては見せて直すことを繰り返す進め方）の基本となる「アジャイルソフトウェア開発宣言」には、重要なポイントとして「包括的なドキュメントよりも動くソフトウェアを」と書かれています。

アジャイル開発の代表的なやり方であるスクラムでは、作業を1か月以内の区切り（スプリント）に分け、区切りが終わるたびに「スプリントレビュー」という場を持ちます。そこでは、その期間にできた実際に使える成果を、発注者などの関係者に見せ、進み具合を話し合い、次に何をするかを決めます。

つまり、きちんとした開発会社なら、「1か月に1回以上、動くものを見せてもらえますか」と聞けば、迷わず「はい」と答えられるはずです。

本番を作る前に、画面の試作品を見せてもらう

プログラムを書き始める前の段階でも、確かめる方法はあります。それが、プロトタイプ（本番前に作る、画面を触って確かめられる試作品）です。たとえば Figma という画面設計のツールでは、ボタンを押すと次の画面に移るような、操作できる試作品を作れます。共有用のリンクがあれば確認でき、スマートフォンでも見られます。

経営者は、技術の説明を聞くより、自分で画面を触ったほうが、ずっと正確に判断できます。

打ち合わせで聞くこと

  • 「何週間ごと（何か月ごと）に、動くものを見せてもらえますか」
  • 「作り始める前に、画面の試作品を触らせてもらえますか」
  • 「見せてもらった段階で直してほしい点が出たら、どう扱いますか」

「完成したらお見せします」「仕様書どおりに作るので大丈夫です」としか答えない会社は、途中で間違いに気づく機会がありません。

確かめる点2: コードとアカウントの持ち主が自社になるか

「持ち主」がわかりにくいのがシステムの怖いところ

建物なら、登記を見ればだれが持ち主かわかります。システムはそうはいきません。システムは次のようなものが組み合わさってできているからです。

  • ソースコード（プログラムの元になる文字の記述）と、それを置くリポジトリ（コードと変更の記録をまとめて置く保管場所）。よく使われる保管サービスに GitHub があります。
  • サーバー（システムやWebサイトを動かしておくコンピューター）。今は自社で機械を持たず、AWS（Amazon が提供する、サーバーなどを借りられるクラウドサービス）などからインターネット経由で借りるのが一般的です。
  • ドメイン（「example.com」のような、サイトの住所にあたる名前）や、Vercel（Webサイトやアプリを公開するサービス）などの公開用サービスのアカウント。

これらのアカウントを開発会社の名義で作られてしまうと、料金を払っているのは自社なのに、いちばん強い権限は開発会社が持っている状態になります。

一番強い権限を、だれが持つか

各サービスには、何でもできる最上位の立場があります。

  • GitHub では、会社などのグループ用アカウント（Organization）の「オーナー」が、組織に対して完全な管理の権限を持ちます。GitHub は、オーナーを少なくとも2人以上置くよう勧めています。
  • AWS では、アカウントを最初に作ったときのメールアドレスとパスワードでログインする「ルートユーザー」が、すべてのサービスに完全なアクセス権を持ちます。アカウント設定の変更やアカウントの閉鎖、請求情報の扱いの一部は、ルートユーザーでしかできません。
  • Vercel では、プロジェクトを別のチームへ移すには、移す元のチームのオーナーである必要があります。

ここからわかるのは、最上位の権限を自社が持っていなければ、自社のシステムなのに、自由に引っ越しも解約もできないということです。開発会社と関係が切れたとき、そこで止まってしまうのです。

「あとで移してもらえばいい」は思ったより簡単ではない

GitHub のリポジトリは、移す操作をすれば、コードの変更の記録や各種の設定も一緒に移ります。ただし、移せるのは管理者の権限を持つ人やオーナーだけです。Vercel では、移しても連携しているほかのサービスは移らず、あとで設定し直す必要があり、記録（ログ）も移りません。

つまり引っ越しは、相手の協力と手間をかけて、ようやくできるものです。関係がこじれてからでは協力を得にくくなります。ですので、最初から自社名義で作ってもらうのがいちばん確実なのです。

「特定の人しか触れない」状態も避ける

持ち主の問題と並んで気をつけたいのが、ベンダーロックイン（特定の開発会社しか触れない状態になり、他社へ移れなくなること）です。

私は以前、日本で動画配信のシステムを作ったとき、安さを優先して、特定のデータベースに頼った設計にしてしまいました。その後、別のサービスへ移ろうとしたところ、大がかりな作り直しになりました。それ以来、「この会社から離れることになったら、いくらかかるか」を、発注の前に必ず考えるようにしています。

反対に、日本でASP事業（インターネット経由でソフトを使ってもらうサービス）を立ち上げたときは、当時はやっていた新しい仕組みではなく、あえて広く使われている古い技術を選びました。扱える人を採用しやすく、資料も多いので、特定の人にしかわからない状態になりにくいからです。担当者が替わってもシステムは動き続け、数年運営したあとに事業を売却できました。売却の際、相手側の技術の確認で重点的に見られたのも、システムの権利関係と、引き継ぎの簡単さだったのです。

資料がまったくなく、コードの説明書きもほとんどないシステムを引き継いだこともあります。そのときは、コードを1行ずつ読み解くところから始めるしかありませんでした。持ち主が自社であることに加えて、他社でも読める資料が残ることも、最初に約束してもらうべきです。資料のないシステムを引き継ぐときの手順は、他社システムの引継ぎで失敗しない進め方で説明しています。

打ち合わせで聞くこと

  • 「GitHub、サーバー、ドメイン、公開用サービスのアカウントは、当社の名義で作ってもらえますか」
  • 「最上位の権限（オーナーやルートユーザー）は、当社が持てますか。御社は必要な範囲の権限で作業してもらえますか」
  • 「もし契約が終わったら、ほかの会社が引き継げるように、何を渡してもらえますか」

この質問に「うちのサーバーで管理するので安心です」とだけ答える会社には注意が必要です。管理を任せること自体は悪くありませんが、持ち主が自社であることは別の話です。

確かめる点3: 契約の種類が、進め方に合っているか

契約の細かい内容は、弁護士に見てもらうのが確実です。ここでは、会社を選ぶ判断について解説します。

システム開発の契約には、大きく2つの形があります。

  • 請負契約: 成果物を完成させることを約束する契約です。
  • 準委任契約: 開発会社が専門家として作業すること自体に対価を払う契約で、完成そのものは約束しません。

確かめる点1で触れた「作っては見せて直す」進め方では、途中で作るものが変わっていくのが前提です。そのため、ここで経営者が押さえるべき点はひとつです。進め方と、契約の種類（請負か準委任か）が合っているかを確かめることです。たとえば「途中で柔軟に修正します」と言いながら、完成を約束する契約だけを出してくる場合、修正するたびに追加費用を請求されるかもしれません。また準委任契約は、作業した分だけお金を払う契約です。途中で動くものを見せてもらう約束がないと、何ができているのかわからないまま、支払いだけが続くおそれがあります。

もうひとつ役に立つのは、「やらないことの一覧」を先に双方で合意しておくことです。あとから要望が積み重なって、作る範囲がふくらむのを防げます。契約の種類がどちらであっても役に立つ方法です。

打ち合わせで聞くこと

  • 「契約は請負と準委任のどちらを考えていますか。その理由は何ですか」
  • 「途中で直したい点が出たとき、費用と期間はどう決めますか」
  • 「やらないことも文書にしてもらえますか」

3つの点をまとめた確認表

確かめる点安心できる答え注意したい答え
途中で動くものを見せてもらえるか「◯週間ごとに見せます」「先に試作品を触ってもらいます」「完成したらお見せします」
コードとアカウントの持ち主「すべて御社名義で作り、最上位の権限は御社に持ってもらいます」「うちで管理するので安心です」だけ
契約の種類進め方と契約の種類の関係を、理由をつけて説明できる進め方を聞いても契約の話につながらない

この表で「注意したい答え」が2つ以上ある会社は、見積もりが安くても候補から外しましょう。

私は、技術がわからない経営者に説明するとき、専門用語を使わず「コスト」「リスク」「時間」という3つの言葉で話すようにしています。この3つの確認も同じです。途中で見せてもらえなければ「時間」を失い、持ち主が自社でなければ「リスク」を抱え、契約の種類が合っていなければ「コスト」がふくらみます。

よくある質問（FAQ）

Q: 技術の質問をしても、答えの良し悪しがわかりません。それでも見分けられますか？

見分けられます。この記事の3つの点は、技術の正しさではなく、「はい・いいえ」や「何週間ごと」のように、はっきり答えられるかどうかを見るものです。答えをはぐらかす、話を別の方向にそらす、といった場合は、技術を知らなくてもわかります。

Q: 小さなシステムでも、アカウントを自社名義にする必要がありますか？

必要です。小さなシステムほど、開発会社の担当者1人に頼りがちで、その人がいなくなると誰も触れなくなります。名義を自社にしておくのに、大きな費用はかかりません。規模に関係なく、最初に決めておくべきことです。

Q: 海外の開発チーム（オフショア開発）に頼む場合も、同じ見分け方でよいですか？

同じで構いません。むしろ、言葉や時差の違いがあるぶん、文書だけでは伝わりにくくなります。私自身、海外のチームと仕事をしてきて、定期的に動くものを見せてもらうことの大切さは、国内より海外のほうが大きいと実感しています。

まとめ

  • システム開発会社は、見積もりの金額を比べる前に、「途中で動くものを見せてもらえるか」「コードとアカウントの持ち主が自社になるか」「契約の種類が進め方に合っているか」の3点で見分けます。
  • どれも技術の知識はいりません。打ち合わせで質問し、はっきり答えられるかを見れば判断できます。
  • この3点を最初に押さえておけば、納品直前の「思っていたものと違う」と、他社に移れない状態の両方を防げます。

開発会社選びを、技術の側から一緒に確かめます

PH Tech AI は、社内に技術の責任者がいない中小企業やスタートアップを対象に、CTO代行・技術顧問として、技術の判断と開発体制づくりを支援しています。

「開発会社の答えが妥当かわからない」「今のシステムが、だれの持ち物になっているのか確かめたい」といった段階からご相談いただけます。打ち合わせへの同席や、アカウントの持ち主の確認もお手伝いします。

まずは無料相談で、今の状況をお聞かせください。

参考・出典

この記事を書いた人

執筆者
執筆者

運営者 ／ AIエンジニア（IT歴36年以上）

  • ●IT歴36年以上
  • ●IBM認定 生成AIエンジニア
  • ●神田昌典氏 認定ライセンシー
  • ●中小企業・スタートアップのCTO代行・技術顧問

IT歴36年以上の運営者です。長年の実務経験と最新の生成AIを掛け合わせ、中小企業・スタートアップが技術の意思決定に自信を持てるよう、現場目線で記事を書いています。

詳しいプロフィールを見る →無料相談を予約する

ライバルはAIで進化中！

あなたのビジネスは大丈夫？

まずは無料で30分相談してみる…

関連記事

他社システムの引継ぎで失敗しない進め方｜資料がない状態からの手順
システム設計・技術選定

他社システムの引継ぎで失敗しない進め方｜資料がない状態からの手順

前任者や委託先が抜け、資料がほとんど残っていない他社システムの引継ぎを任された方へ。属人化のリスクと、最初に何をすべきかを、CTO代行としての実体験を交えて解説します。

2026/9/27

技術顧問の費用は月いくら？決まる3つの要素と高い安いの見分け方
AI活用・生成AI導入

技術顧問の費用は月いくら？決まる3つの要素と高い安いの見分け方

技術顧問の費用に公的な統計はなく、会社や顧問によって金額が大きく違います。費用を決める3つの要素（頻度・範囲・何をしてもらうか）と、高い安いの見分け方、契約で決めておく点を、IT歴36年の技術顧問がやさしく解説します。

2026/10/1

生成AIの社内ルールの作り方｜何を決め、誰が確かめ、誰が責任を持つか
AI活用・生成AI導入

生成AIの社内ルールの作り方｜何を決め、誰が確かめ、誰が責任を持つか

生成AIの社内ルールに書く項目を、IPAや総務省・経産省などの公的資料をもとに整理。入力してはいけない情報、出力の確かめ方、責任者の決め方、ひな形の入手先まで、CTO代行の視点でやさしく解説します。

2026/9/29

システム開発の見積もりは妥当か、工数の内訳から確かめる方法
CTO代行・技術顧問

システム開発の見積もりは妥当か、工数の内訳から確かめる方法

システム開発を発注した会社から出てきた見積もりは妥当でしょうか。設計・実装・テスト・保守運用という工数の内訳を、公開されている統計データの目安と照らし合わせれば確かめられます。中小企業・スタートアップの技術判断を支援する立場から、その方法を解説します。

2026/9/23

CTOがいない会社の技術判断は、CTO代行という選択肢で変わる
CTO代行・技術顧問

CTOがいない会社の技術判断は、CTO代行という選択肢で変わる

開発会社の見積もりが妥当か、エンジニアの採用で何を見ればよいか、AI導入は何を確認すべきか。中小企業・スタートアップの経営者が一人で抱えがちなこうした判断を相談できるCTO代行という選択肢と、選ぶときの失敗例を、中小企業・スタートアップの技術の判断を支援する立場から解説します。

2026/9/22

Webスクレイピングが「違法」になりかけた、建築業のAI入札システム
実務ケース

Webスクレイピングが「違法」になりかけた、建築業のAI入札システム

2026年7月ごろ、建築業のお客様から、入札情報をAIで解析し判断・自動化・データベース化するシステムの相談を受けました。データの取得方法がWebスクレイピングだったため法的リスクを指摘し、提供元のAPIへの切り替えと、Supabaseでの構造化データ・ベクトルデータのハイブリッド検索への再設計を提案しました。

2026/9/22

ひとりで悩む前に、まずは「無料相談」してみませんか？