ソフトウェア開発会社はどのように選べばよいですか?

ブダペストのソフトウェア開発会社であるMesterséges Intelligencia Központ Kft. の考えでは、良い選択は3つの問いにかかっています。開発会社が目的を理解しているか、その見積もりを検証できるか、そして引き渡し後にコードとシステムが誰のものになるかです。

要点: まず目的と必須要件を書き出し、そのあとで見積もりを依頼してください。実際に動く成果物、透明な進め方、コードへのアクセスを求めることをお勧めします。見積もりは同じ項目別の仕様に基づいて、できれば測定した規模で比較する必要があります。契約では、ソースコードと利用権、秘密保持、不具合の修正、運用、そして解約の方法も定めておく必要があります。

まず目的から:ソフトウェアに何ができる必要がありますか?

誤った選択の多くは、開発会社ではなく、あいまいな依頼から始まります。ソフトウェアに何ができる必要があるのかが書き出されていなければ、見積もりはそれぞれ別のものを意味することになり、料金も完成した成果物も、何と比べて評価すればよいのかがわからなくなります。完成した仕様書は必要ありません(良い開発会社は、その作成を手伝います)。ただし、いくつかの点は事前に検討しておくことをお勧めします:

そもそもオーダーメイド開発が必要なのか、それとも既製品で、あるいは既製品とオーダーメイドの拡張の組み合わせで足りるのかも判断しておくことをお勧めします。その判断にはオーダーメイドのソフトウェアか、既製のソリューションか?の記事が役立ちます。

候補の絞り込み:どの会社に声をかけるべきですか?

多くの会社に声をかける必要はありません。数多くの表面的な見積もりよりも、慎重に選んだ少数の候補のほうが役立ちます。絞り込みの観点は次のとおりです:

実績と参考事例の確認

最も有力な証拠は、実際に動くソフトウェアです。候補の会社には、実際に試せるシステムを見せ、その中で自社が担当した部分を正確に説明するよう依頼してください。多くの顧客案件は秘密保持の対象となっているため、名前を挙げられるとは限りません。その場合でも、匿名化した説明、デモ、あるいはその会社の自社製品から多くのことがわかります。

以前の発注者が参考事例として話してくれる場合は、具体的に質問することをお勧めします。合意した作業範囲は守られたか、変更や不具合はどのように扱われたか、ソースコードは受け取れたか、今も一緒に仕事をしているか、といった点です。「満足しています」という一般的な言葉からはあまりわかりませんが、発注者が引き渡し後もその会社とシステムを運用しているという事実からは、多くのことがわかります。

技術的な面談

候補ごとに技術的な面談を行うことをお勧めします。できれば御社側からも技術の専門家が同席するとよいでしょう。重要なのは回答が自信に満ちているかどうかではなく、開発会社が質問をするかどうか、そしてリスクを挙げるかどうかです。良い質問の例:

候補の会社が質問もせずに、最初の面談のあとで正確な料金と期限を提示する場合は、警告のサインです。

仕事の進め方とコミュニケーション

ソフトウェア開発で予期せぬ事態が生じる原因は、コードであることはまれで、はるかに多いのはコミュニケーションです。そのため、開発の途中で進捗をどのように確認できるのかを質問することをお勧めします。良い進め方の特徴は次のとおりです:

見積もりの比較

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システムを開発しています。実際に試せる当社の自社開発は制作実績のページで、会社については当社についてのページで、よくある質問への回答はよくあるご質問のページでご覧いただけます。開発会社をお探しでしたら、お問い合わせのページに記載の連絡先までご連絡ください。

出典