ソフトウェア開発会社はどのように選べばよいですか?
ブダペストのソフトウェア開発会社であるMesterséges Intelligencia Központ Kft. の考えでは、良い選択は3つの問いにかかっています。開発会社が目的を理解しているか、その見積もりを検証できるか、そして引き渡し後にコードとシステムが誰のものになるかです。
要点: まず目的と必須要件を書き出し、そのあとで見積もりを依頼してください。実際に動く成果物、透明な進め方、コードへのアクセスを求めることをお勧めします。見積もりは同じ項目別の仕様に基づいて、できれば測定した規模で比較する必要があります。契約では、ソースコードと利用権、秘密保持、不具合の修正、運用、そして解約の方法も定めておく必要があります。
まず目的から:ソフトウェアに何ができる必要がありますか?
誤った選択の多くは、開発会社ではなく、あいまいな依頼から始まります。ソフトウェアに何ができる必要があるのかが書き出されていなければ、見積もりはそれぞれ別のものを意味することになり、料金も完成した成果物も、何と比べて評価すればよいのかがわからなくなります。完成した仕様書は必要ありません(良い開発会社は、その作成を手伝います)。ただし、いくつかの点は事前に検討しておくことをお勧めします:
- 目的: ソフトウェアがどのような問題を解決し、何をもって成功と判断するのか。
- ユーザー: 誰が使うのか。社内の社員か、顧客か、取引先か。
- 必須要件: それがなければ稼働を始められないもの。「あればよい」項目とは分けて考えます。
- 既存システム: 何と連携する必要があるのか(ERP、CRM、ECサイト、請求書発行サービス、銀行)。
- データ: どのようなデータを扱うのか。個人データも含みます。
- 制約: 決まった期限、社内規程、ホスティングやセキュリティに関する要件があるかどうか。
そもそもオーダーメイド開発が必要なのか、それとも既製品で、あるいは既製品とオーダーメイドの拡張の組み合わせで足りるのかも判断しておくことをお勧めします。その判断にはオーダーメイドのソフトウェアか、既製のソリューションか?の記事が役立ちます。
候補の絞り込み:どの会社に声をかけるべきですか?
多くの会社に声をかける必要はありません。数多くの表面的な見積もりよりも、慎重に選んだ少数の候補のほうが役立ちます。絞り込みの観点は次のとおりです:
- 類似の実績: 規模や性質が似たシステム(業務ソフトウェア、ECサイト、モバイルアプリ、AI統合)を構築したことがあるか。
- 技術の適合: 既存システムとの連携に必要な技術を扱っているか。
- 規模の釣り合い: 会社の対応力がプロジェクトに見合っているか。大きなシステムには多くの専門分野が、小さなタスクにはより少ない専門分野が必要です。
- 言語と連絡のとりやすさ: 御社の言語で、御社のタイムゾーンでやり取りできるか。
実績と参考事例の確認
最も有力な証拠は、実際に動くソフトウェアです。候補の会社には、実際に試せるシステムを見せ、その中で自社が担当した部分を正確に説明するよう依頼してください。多くの顧客案件は秘密保持の対象となっているため、名前を挙げられるとは限りません。その場合でも、匿名化した説明、デモ、あるいはその会社の自社製品から多くのことがわかります。
以前の発注者が参考事例として話してくれる場合は、具体的に質問することをお勧めします。合意した作業範囲は守られたか、変更や不具合はどのように扱われたか、ソースコードは受け取れたか、今も一緒に仕事をしているか、といった点です。「満足しています」という一般的な言葉からはあまりわかりませんが、発注者が引き渡し後もその会社とシステムを運用しているという事実からは、多くのことがわかります。
技術的な面談
候補ごとに技術的な面談を行うことをお勧めします。できれば御社側からも技術の専門家が同席するとよいでしょう。重要なのは回答が自信に満ちているかどうかではなく、開発会社が質問をするかどうか、そしてリスクを挙げるかどうかです。良い質問の例:
- どのように着手し、最初の段階は何になりますか?
- 既存のシステムをどのように連携させ、それについて何を知っておく必要がありますか?
- どのようにテストし、ある部分が完成したかどうかは誰が判断しますか?
- プロジェクトには誰が携わり、窓口担当者は誰になりますか?
- システムはどこで稼働し、セキュリティアップデートには誰が責任を持ちますか?
- 人工知能も使う場合、どのデータがどこに渡り、AIが誤った場合はどうなりますか?
候補の会社が質問もせずに、最初の面談のあとで正確な料金と期限を提示する場合は、警告のサインです。
仕事の進め方とコミュニケーション
ソフトウェア開発で予期せぬ事態が生じる原因は、コードであることはまれで、はるかに多いのはコミュニケーションです。そのため、開発の途中で進捗をどのように確認できるのかを質問することをお勧めします。良い進め方の特徴は次のとおりです:
- 段階的な開発: 作業は複数の段階に分かれ、各段階の終わりには報告だけでなく、実際に動くソフトウェアが披露されます。
- コードへのアクセス: 発注者は引き渡しの時点だけでなく、初日からコードの保管場所(リポジトリ)を確認できます。
- 追跡できるタスク一覧: タスク、不具合、変更が、共有の管理ツールで確認できます。
- 固定の窓口担当者: プロジェクトを把握し、判断を下せる担当者がいます。
- 変更管理: 新しい要望や変更された要望は記述され、測定または推定され、承認されてから作業に組み込まれます。
見積もりの比較
2つの見積もりを比較できるのは、それらが同じ作業範囲を対象としている場合だけです。そのため、すべての候補に同じ項目別の記述を渡し、どの機能と、どの規模に対して料金を出したのかを確認してください。開発会社がソフトウェアの機能規模を標準化された手法(たとえばCOSMICファンクションポイント)で測定している場合、その規模は同じ仕様から検証できます。この手法についてはCOSMICファンクションポイントとは何ですか?の記事でご紹介しています。
2つの見積もりの差が大きい場合は、次の点を質問することをお勧めします:
| 質問 | わかること |
|---|---|
| 料金はどの規模と、どの機能を対象としていますか? | 同じ作業範囲に料金を付けたかどうか |
| 何が別項目になっていますか? | 連携、データ移行、グラフィック、運用が含まれているかどうか |
| どのような非機能要件を想定しましたか? | 性能、セキュリティ、アクセシビリティ |
| 変更はどのように扱いますか? | 途中で新しい要望が出た場合にどうなるか |
| 引き渡し後の不具合修正はどのような取り決めですか? | 料金に何が含まれ、何が別の作業になるか |
| ソースコードは誰のものになり、どのような権利を得られますか? | システムを別の会社が引き継げるかどうか |
| 精算は固定価格ですか、それとも工数に基づきますか? | 作業範囲のリスクを誰が負うか |
固定価格がうまく機能するのは、作業範囲が項目ごとに確定している場合です。工数に基づく精算はより柔軟ですが、作業範囲のリスクは発注者側に残ります。どちらの場合も重要なのは、作業範囲を測定でき、追跡できることです。当社の料金の決め方は、料金の考え方のページでご説明しています。
契約の重要なポイント
紛争や予期せぬ事態が起きたときに意味を持つのは契約です。以下は情報提供であり、法的助言ではありません。契約は弁護士にも確認してもらうことをお勧めします。
ソースコードと利用権
ハンガリーの著作権法(1999年法律第LXXVI号、Szjt.、ハンガリー語)は、コンピュータープログラムを、ソースコードとオブジェクトコードのいずれの形式でも著作物として保護し(第1条第2項(c))、ソフトウェアに関する著作財産権は譲渡できると定めています(第58条第3項)。つまり発注者は、著作財産権を取得するか、利用許諾(ライセンス)を受けるかのどちらかであり、この2つは同じではありません。
正確な文言が重要になる理由となるルールをいくつか挙げます。利用許諾契約が排他的な権利を与えるのは、そのことが明示的に定められている場合に限られます(第43条第1項)。契約が利用の方法と範囲を定めていない場合、許諾は契約の目的に不可欠な範囲に限定されます(第43条第5項)。内容が明確でない場合は、著作者に有利な解釈が採用されます(第42条第3項)。そして利用者は、著作者の明示的な許可がある場合にのみ、第三者に許諾を与えることができます(第46条第1項)。そのため、次の点を定めておくことをお勧めします:
- ソースコード全体とドキュメントの引き渡し(段階ごとの引き渡しも含む)。
- 発注者が著作財産権を取得するのか、それともどのような範囲の許諾(排他的かどうか、改変できるかどうか、再許諾できるかどうか)を受けるのか。
- 開発会社が、自社の社員と下請け業者が書いたコードの権利を保有していること。
- 使用するオープンソースのコンポーネントと第三者のコンポーネントの一覧と、そのライセンス。
秘密保持(NDA)
アイデアや業務データが機密である場合は、詳細を話し合う前に秘密保持契約(NDA)を結ぶことをお勧めします。その中で、何が機密情報にあたるのか、誰がそれを知ることができるのか、秘密保持の期間はどのくらいか、作業の終了時に資料をどう扱うのかを定めてください。
不具合の修正と保証
契約では、何を不具合とみなすのか(定められた要件との相違)、受け入れテストをどのように行うのか、どのような重大度のレベルがあり、開発会社が各レベルにどのくらいの速さで対応するのかを定めます。また、引き渡し時に発見されなかった不具合をどのくらいの期間無償で修正するのか、何がすでに追加開発にあたるのかも定めてください。
運用とSLA
開発会社が引き渡し後もシステムを運用する場合は、サービスレベル合意(service level agreement、SLA)で条件を定めます。約束する可用性、障害の報告方法、重大度ごとの対応時間と解決時間、メンテナンスの時間枠、バックアップ、報告です。書かれていないことは、紛争の際に求めることができません。
エグジットプラン
エグジットプラン(契約終了時の計画)は、開発会社との関係を続けない場合に何が起こるのかという問いに答えるものです。理由が不満であっても、開発会社の消滅であっても同じです。構成要素は次のとおりです:
- インストール、アーキテクチャ、運用に関する最新のドキュメント。
- コードリポジトリ、ホスティング、ドメイン、クラウドアカウントを発注者の名義にするか、少なくとも発注者がアクセスできるようにしておくこと。
- パスワードとアクセスキーの引き渡しの手順。
- データを標準的な形式でエクスポートできること。
- 新しい開発会社への引き継ぎに対する協力。
データ保護:データ処理契約
開発会社が作業の中で個人データにアクセスする場合(たとえばシステムを運用する場合や、本番データでテストする場合)、GDPRのもとでは一般的に処理者にあたり、書面によるデータ処理契約を結ぶ必要があります(GDPR第28条)。この契約には特に、開発会社が発注者の文書化された指示に従ってのみデータを処理すること、守秘とセキュリティを確保すること、許可を得た場合にのみ別の処理者を利用すること、サービスの終了時にデータを消去または返還すること、そして監査を可能にすることを定めなければなりません。
セキュリティの実践
セキュリティはあとからソフトウェアに付け加えることができないため、開発会社がセキュリティにどう取り組んでいるのかを質問することをお勧めします。良い出発点はOWASP Top 10で、ウェブアプリケーションの最も重大なセキュリティリスクをまとめた、広く知られた一覧です。現行版はOWASP Top 10:2025です(2026年10月17日確認)。上位3つは、アクセス制御の不備、セキュリティの設定ミス、ソフトウェアサプライチェーンの不備です。次の点を質問してください:
- 権限をどのように管理し、ユーザーが自分のデータしか見られないことをどのようにテストしていますか?
- 使用している外部ライブラリをどのように更新し、そのいずれかに脆弱性があることをどのように把握していますか?
- パスワードとキーをどこに保管し、誰がそれにアクセスできますか?
- コードレビューと自動テストは行っていますか?
- バックアップはどのように作成し、復元を試したことはありますか?
フリーランスか、開発会社か?
どちらも良い選択になりえます。問題は、タスクがどのくらい大きく、システムがどのくらい長く使われるかです。
| 観点 | フリーランス | 開発会社 |
|---|---|---|
| コミュニケーション | 1人と直接 | 窓口担当者を通じて、複数の専門家と |
| 専門分野 | 1人の知識 | 複数の専門分野:画面、バックエンド、モバイル、運用、テスト |
| 代替性 | 病気や離脱の際には作業が止まる | チームが互いの作業を引き継げる |
| 対応力 | 小規模で範囲の明確なタスク向け | 大規模なシステムや並行作業向け |
| 契約 | 専門家と直接 | チームの作業に責任を持つ会社と |
| 長期的な運用 | フリーランスの対応可否に左右される | 組織的に引き受けられる |
フリーランスは範囲の明確なタスクに向いています。特に、発注者側に作業を指揮し、受け入れる技術責任者がいる場合です。システムが企業の日々の業務の一部であり、複数の専門分野を必要とし、何年も稼働する場合は、一般的に開発会社のほうがリスクは小さくなります。エグジットプランとソースコードの引き渡しは、どちらの場合も同じように重要です。
警告のサイン
- 質問もないまま、最初の面談のあとに示される正確な料金と期限。
- 書面の仕様がないこと、または何を対象としているのかを示していない見積もり。
- 発注者がコードを見られず、引き渡しの時点で初めて受け取る形になっていること。
- プロジェクトを誰が担当するのかについての、あいまいな回答。
- ソースコードが誰のものになり、発注者がどのような権利を得るのかが明確でないこと。
- データ処理契約や秘密保持契約を拒むこと。
- 披露できる、実際に動く成果物がないこと。
チェックリスト
| 質問 | 問題がないのは |
|---|---|
| 目的と必須要件は書き出されていますか? | 全員が同じように理解している短い記述がある場合 |
| 実際に動く成果物を見ましたか? | 少なくとも1つの類似システムを試した場合 |
| タスクを理解していますか? | 質問をし、リスクを挙げた場合 |
| 進捗を確認できますか? | 段階ごとのデモ、コードリポジトリへのアクセスがある場合 |
| 見積もりを比較できますか? | 同じ項目別の作業範囲を対象とし、別項目が見えている場合 |
| ソースコードと権利の問題は整理されていますか? | 契約に引き渡しと権利の範囲が明記されている場合 |
| 秘密保持契約とデータ処理契約はありますか? | 必要な場合に締結済みであること |
| 不具合の修正と運用は定められていますか? | 重大度のレベル、対応時間、SLAが定められている場合 |
| エグジットプランはありますか? | ドキュメント、アクセス権、データのエクスポートが定められている場合 |
| セキュリティについて質問しましたか? | 権限、更新、バックアップについて具体的な回答があった場合 |
よくあるご質問
フリーランスと開発会社のどちらがよいですか?
範囲の明確な小規模のタスクであれば、経験豊富なフリーランスも良い選択になりえます。特に、企業に自社の技術責任者がいる場合です。システムが日々の業務の一部であり、複数の専門分野を必要とし、長く稼働する場合は、作業が1人に依存しないため、開発会社のほうがリスクは小さくなります。
2つの見積もりはどのように比較すればよいですか?
比較できるのは、同じ項目別の仕様に対して出された見積もりだけです。両方の会社に、どの規模とどの機能に対して料金を出したのか、何が別項目になっているのか、変更をどのように扱うのかを質問してください。規模がCOSMICファンクションポイントのような標準化された手法で測定されていれば、同じ仕様から検証できます。
契約には何を盛り込むべきですか?
作業範囲(項目別の仕様)、料金とスケジュール、ソースコードの引き渡しと利用権の範囲、秘密保持、受け入れと不具合修正の手順、運用とSLA、エグジットプラン、そして個人データが関わる場合はデータ処理契約です。これは情報提供であり、法的助言ではありません。
開発会社がいなくなった場合はどうなりますか?
ソースコード、ドキュメント、アクセス権が発注者の手元にあれば、別の開発会社がシステムを引き継げます。そのため、初日からコードリポジトリを確認できるようにし、ホスティングとドメインを自社の名義で保有し、契約にエグジットプランを定めておくことをお勧めします。これらが欠けていると、システムを引き継いで発展させることは難しく、時間もかかる可能性があります。
ソースコードは誰のものになりますか?
契約で定められた者のものになります。ハンガリーの著作権法によれば、ソフトウェアに関する著作財産権は譲渡できますが、自動的に移転するわけではありません。契約では、発注者がソースコード全体を受け取ること、そしてそれについて具体的にどのような権利を取得するのかを定めておくことをお勧めします。当社でも、ソースコードと利用権の扱いは契約で定めます。
当社がお手伝いできること
当社の進め方は次のとおりです。初回のご相談は無料です。仕様は一緒に書き、ソフトウェアの規模をCOSMICファンクションポイントで測定し、そこからお見積もりとスケジュールを作成します。開発は段階的に進め、各段階の終わりにデモを行います。ご要望に応じて秘密保持契約(NDA)を締結します。引き渡し後の運用・保守もお引き受けします。ソースコードと利用権の扱いは、契約で定めます。ステップは仕事の進め方のページで、料金の算定方法は料金の考え方のページでご説明しています。
現在も、大規模なERP・CRMシステムを開発しています。実際に試せる当社の自社開発は制作実績のページで、会社については当社についてのページで、よくある質問への回答はよくあるご質問のページでご覧いただけます。開発会社をお探しでしたら、お問い合わせのページに記載の連絡先までご連絡ください。