アプリやシステムの開発を外注する際、多くの方が「会社の実績」や「営業担当者の人柄」で判断してしまいがちです。ところが、契約や保守の段階に入って初めて「こんなはずではなかった」と気づくケースは少なくありません。
今回は、実際に私が関わった案件をきっかけに得られた教訓を整理し、同じようなリスクを避けるためのポイントを共有したいと思います。
見積もりの不透明さに要注意
発注者からの相談で最初に出てきたのは、「提示された見積もりに違和感を抱いた」という点でした。詳細を確認しても、返ってくる答えは「説明義務はない」の一点張り。
通常であれば、工数の内訳や作業項目をある程度明示することは難しくありません。説明を拒むということは、見積もりに対する責任を持たない姿勢の表れとも言えます。
チェックポイント
- 工数の内訳が明示されているか
- 作業項目が具体的に記載されているか
- 追加費用が発生する条件が明確か
- 質問に対して誠実に回答してもらえるか
開発契約において、見積もりの透明性は信頼関係の試金石です。
保守契約は「包括対応」と言われても
契約当初から「リリース後は保守契約を締結」という前提で進めていました。完成後１ヶ月の品質保証期間を経て、その後は「包括的にシステム全体を見ます」との説明。
一見安心に思えますが、実際には以下の点が不明確だと、後々揉める原因になります：
明確にすべき保守契約の内容
- 対応範囲
- バグ修正だけなのか
- 軽微な改修も含むのか
- セキュリティアップデートは含まれるか
- SLA（サービスレベル）
- 対応開始までの時間
- 復旧までの目標時間
- 連絡可能な時間帯
- 費用体系
- 月額固定なのか従量制なのか
- 上限時間の設定
- 超過した場合の単価
「包括対応」という言葉に安心せず、契約書に範囲と条件を明文化しておくことが不可欠です。
権利帰属と「運営権」は別物
もう一つ大きな論点がありました。それは権利帰属の問題です。
発注者が「本アプリ開発に関するすべての権利は当方に帰属する」という条項を求めたところ、開発会社の回答は「運営権は御社にあります」というもの。
理解しておくべき権利の違い
| 権利の種類 | 内容 | なぜ重要か |
|---|---|---|
| 運営権 | サービスを運営する権利 | 日々のビジネス運営には必要 |
| 著作権 | プログラムの複製・改変・配布の権利 | 将来の改修や事業展開に必須 |
| 特許権 | 技術的アイデアの独占権 | 競合他社への差別化要素 |
| 商標権 | サービス名やロゴの使用権 | ブランド構築に不可欠 |
「運営権」と「著作権その他の知的財産権」はまったく別だということです。契約上、利用権の範囲を曖昧にしたままでは、将来の事業展開や第三者への委託が制約される恐れがあります。
ソースコードを渡さないというリスク
さらに衝撃的だったのは、「ソースコードの納品は基本行っていない」との説明でした。
理由としては：
- 「自社ノウハウが含まれている」
- 「納品後に勝手に改変されトラブルになった事例がある」
確かに開発会社の立場として理解できる部分もあります。しかし発注者にとって、ソースコードを受け取れないということは「将来の自由度がゼロになる」ことを意味します。
ソースコードがないと起こる問題
- ベンダーロックイン
- 永続的に同じ開発会社に依存
- 価格交渉力の喪失
- サービス品質低下への対処不能
- 事業継続リスク
- 開発会社の倒産時にシステムが止まる
- 契約解除時に引き継ぎ不可能
- M&Aや事業売却が困難
- 技術的制約
- 他社での改修が不可能
- セキュリティ監査ができない
- パフォーマンス改善が制限される
対策：最低限の防御策
もしソースコード納品が難しい場合でも、以下の対策は必須です：
- エスクロー契約：第三者機関にソースコードを預託
- 契約終了時の開示条項：一定条件下での開示を約束
- 定期的なバックアップ提供：最低限のデータ保全
- 技術仕様書の詳細化：再開発可能なレベルの文書化
教訓：契約は「出口」まで意識する
今回のケースを通じて改めて感じたのは、開発契約は「作る」こと以上に「運用・変更・終了時」を見据えておく必要があるということです。
契約前のチェックリスト
- 見積もりの透明性を確認する
- 保守契約の範囲・対応速度を明文化する
- 著作権の帰属を明確にする
- ソースコード納品の有無と代替策を検討する
- 契約終了時の取り決めを整えておく
- データの所有権と移行方法を確認する
- 開発会社の財務健全性を調査する
これらを押さえておくだけで、将来のリスクは大きく減らせます。
IT顧問サービス「NaviPartner」立ち上げの背景
こうした相談は今回だけでなく、他の案件でも相次ぎました。
「納品間近になってトラブルが顕在化する」 「支払いが終わった後に発注者が弱い立場に立たされる」
そんな構造的な問題を目の当たりにし、発注者側の立場でITを面倒見るサービスが必要だと強く感じました。
そこで開始したのがIT顧問サービス「NaviPartner（ナビパートナー）」です。
NaviPartnerの特徴
通常、システム開発会社が自社サービスの延長で顧問を行うケースはありますが、弊社は開発を請け負わない立場を基本としました。
その理由はシンプルで、利益相反を避け、純粋に発注者の利益を守ることに専念するためです。
NaviPartnerの立ち位置
ただし例外的に、プロトタイプ開発やPoC、R&Dは受け付けています。
これは「ビジネス構築目線で小さく価値を検証する開発会社」がなかなか存在せず、顧客の事業成功を支えるにはこの部分をサービス化する必要があったからです。
つまりNaviPartnerは：
- 本格開発フェーズでは発注者側に立ってアドバイス
- 事業検証フェーズでは必要な小規模開発も伴走
というハイブリッドな立ち位置を取っています。
NaviPartnerが提供する価値
- 契約前の準備支援
- 要件定義の明確化
- 適切な開発会社の選定基準策定
- 契約書のレビューと改善提案
- 開発中の品質管理
- 進捗の可視化と評価
- 技術的な妥当性の検証
- リスクの早期発見と対策
- 納品後の事業継続支援
- 保守契約の適正化
- 次期開発の戦略立案
- 内製化への移行支援
まとめ
開発会社選びは、単に「作る」相手を探すことではありません。
契約の透明性や保守体制、権利の帰属やソースコードの扱いなど、リリース後の事業継続を左右する要素が数多く含まれています。
今回の事例を参考に、ぜひ皆さんの開発契約でも「出口まで意識した契約」を心がけていただければと思います。
今すぐできるアクション
- 現在の契約書を見直す
- 権利関係の条項を確認
- 保守契約の内容を精査
- 終了条項の有無をチェック
- 開発会社との関係性を評価
- 質問への対応姿勢
- ドキュメントの提供状況
- トラブル時の対応実績
- 将来のリスクを洗い出す
- ベンダーロックインの度合い
- 事業拡大時の制約
- 技術的な依存度
そして、もし不安があれば発注者側に立つIT顧問サービスNaviPartnerにぜひご相談ください。
事業成功のために、一緒に最適な道を探していきましょう。
NaviPartner（ナビパートナー） 発注者の立場で、IT事業の成功を導く顧問サービス
| 無料相談を申し込む | サービス詳細を見る | 他の記事を読む |