「このシステム、来年から他社にも販売できますか」
社長からそう聞かれた瞬間、頭が真っ白になった担当者がいる。仮にこの人をKさんと呼ぼう。従業員30名ほどの製造業で、社内の在庫管理システムを内製に近い形で外部の開発会社に発注し、1年かけて作り上げた。予算は限られていたから、開発会社からは「オープンソースを積極的に活用してコストを抑えます」という提案を受け、Kさんも二つ返事で了承した。実際、見積もりは想定より3割近く安く済み、Kさんは経営陣から高く評価されていた。
システムは順調に稼働し、社内の在庫ロスは目に見えて減った。そして半年後、取引先の同業他社から「うちにも同じ仕組みを入れられないか」という話が舞い込んだ。願ってもない話だった。自社の副業として、このシステムをパッケージ化して販売する。Kさんはその構想を経営会議に持ち込み、社長も乗り気になった。
ところが、開発会社に「外販できるように整えてほしい」と相談したところ、返ってきたのは予想外の答えだった。「このシステムの一部には、改変したソースコードを公開する義務があるライセンスのオープンソースを使っています。今のままの構成で外部に販売すると、御社が書いたコードも含めて全部公開しなければならなくなります」。Kさんは意味がよく分からないまま、ただ一つのことだけは理解した。自社の資産だと思っていたシステムが、実は自由に扱えない部分を含んでいたということだ。
この記事は、Kさんのような立場に置かれる前に、非エンジニアの発注担当者が知っておくべきオープンソースとライセンスの話をまとめたものだ。専門用語の解説で終わらせず、発注前に何を確認すればいいのかまで踏み込む。壁の向こう側にある技術的な判断を、少しでも自分の言葉で語れるようになってほしいという思いで書いている。
なぜオープンソースを使うとコストが下がるのか
まず、オープンソース(OSS)とは何かを、専門用語を使わずに説明したい。世の中のソフトウェアを作る過程では、ログイン機能、決済処理、グラフの描画、データベースへのアクセスといった、多くのシステムに共通して必要な部品がある。これらの部品を、世界中のエンジニアやIT企業が無償で公開し、誰でも自由に使えるようにしているものがオープンソースだ。
たとえば家を建てるとき、柱や配管、電気設備をすべて一から自作する工務店はいない。規格化された部材を組み合わせて、そこに独自の間取りやデザインを加えることで、コストと工期を抑えながら質の高い家を建てる。ソフトウェア開発におけるオープンソースは、まさにこの規格部材にあたる。
もしすべての機能を自社専用にゼロから書き起こしていたら、開発会社は膨大な工数を費やすことになり、その人件費はそのまま見積もりに跳ね返る。オープンソースの部品を土台にすることで、開発会社は御社の業務に本当に固有な部分、つまり差別化につながる部分にこそ工数を集中できる。Kさんの案件で見積もりが3割安くなったのは、この仕組みのおかげだ。決して手を抜いた結果の安さではない。
ここまでは、発注者にとって純粋にありがたい話に見える。問題は、その部品それぞれに「使ってよい条件」が個別に定められているという事実を、多くの発注担当者が意識していない点にある。
ライセンスという「使用条件書」の存在
オープンソースは無料で使えるが、無制限に使えるわけではない。それぞれのオープンソースには、ライセンスと呼ばれる使用条件が付いている。これは、賃貸物件の契約書のようなものだと考えると分かりやすい。家賃が安い代わりに、ペット不可、又貸し禁止、原状回復義務といった条件が細かく決められている物件があるように、オープンソースにも「改変してよいか」「再配布してよいか」「商用利用してよいか」「改変した内容を公開する義務があるか」といった条件が、種類ごとに異なる形で定められている。
ライセンスの世界には大きく分けて二つの系統がある。
- 比較的緩やかな系統。改変や商用利用は自由で、改変した内容を公開する義務もない。企業が自社製品に組み込んでも、そのソースコードを公開する必要はない。
- コピーレフト型と呼ばれる系統。改変や再配布は認められるが、その部品を使って作ったソフトウェア全体を、同じ条件で公開しなければならないという義務が付いてくる。
この二つ目の系統こそが、Kさんを追い詰めたものだ。緩やかなライセンスの部品ばかりを組み合わせているつもりでも、開発会社が工数削減のために採用した一つの部品がコピーレフト型だった場合、そのシステム全体、つまり御社の業務ノウハウが詰まった独自コードまでもが、公開義務の対象に含まれてしまう可能性がある。
大事なのは、どちらのライセンスが優れているという話ではないということだ。コピーレフト型のライセンスは、ソフトウェアの世界に知識を還元し合う文化を守るために生まれた、立派な考え方に基づいている。問題は、その考え方が自社の事業計画と噛み合うかどうかを、発注者側が知らないまま契約を進めてしまうことにある。
発注者が特に注意すべきライセンスの落とし穴
非エンジニアの担当者がすべてのライセンスの条文を読み込む必要はない。ただし、次の三つの落とし穴だけは、感覚として持っておいてほしい。
落とし穴1: 社内利用と外部提供では扱いが変わる
コピーレフト型のライセンスの多くは、「社内でのみ使う分には公開義務が発生しない」という例外規定を持っている。Kさんの在庫管理システムも、社内利用にとどまっている間は何の問題もなかった。しかし、それを他社に販売する、あるいはSaaSとして外部に提供するという瞬間に、公開義務のスイッチが入るケースがある。今は社内ツールのつもりでも、将来的に事業化する可能性が少しでもあるなら、発注の時点でその可能性を開発会社に伝えておく必要がある。
落とし穴2: 「一部だけ」でも全体に影響する
システムの99パーセントを独自コードで書いていても、残り1パーセントにコピーレフト型の部品を組み込んでしまえば、その1パーセントのルールがシステム全体に及ぶことがある。ライセンスの世界では、使った部品の量ではなく、種類そのものが問われる。「ほんの一部だから大丈夫」という感覚は通用しない。
落とし穴3: サポートの継続性はライセンスとは別問題
オープンソースは、企業がお金をもらって開発しているわけではない場合が多い。有志のエンジニアやコミュニティが支えているケースでは、開発が突然停滞したり、セキュリティの脆弱性が見つかっても修正されないまま放置されたりすることがある。ライセンス上は自由に使えても、その部品自体が「事実上の廃盤」になっているリスクは別に存在する。長く使い続けるシステムほど、この観点は軽視できない。
発注前に確認すべきチェック項目
ここまでの話を踏まえて、発注担当者が契約前に開発会社へ投げかけるべき質問を、実務的な形でまとめる。すべてを自分で判断する必要はない。「聞くべきことを聞く」だけで、リスクの大半は防げる。
- このシステムを将来、外部に販売したり、他社への提供や事業化を検討したりする可能性があることを、開発会社に事前に伝えているか
- 使用するオープンソースの一覧と、それぞれのライセンスの種類を一覧表の形で提示してもらえるか
- そのうち、改変したコードの公開義務が発生するライセンスのものがあるかどうかを、明確に回答してもらっているか
- 公開義務が発生する部品がある場合、それが自社の独自コード全体に及ぶ範囲なのか、その部品単体にとどまるのかを確認しているか
- 採用予定のオープンソースについて、開発コミュニティの活動が続いているか、直近でアップデートや脆弱性対応が行われているかを確認しているか
- もし将来ライセンス上の制約が事業の足かせになった場合、代替の部品に置き換える工数や費用について、あらかじめ見積もりを取れるか
- 納品物にライセンス一覧書(いわゆるOSSライセンス台帳)を含めてもらえるよう、契約書や仕様書に明記しているか
この七つを契約前に一度確認しておくだけで、Kさんが直面したような事態の大半は防げる。専門的な判断そのものは開発会社に委ねればよい。発注者の役割は、事業計画という「答え合わせの基準」を相手に渡すことにある。将来どう使いたいかを伝えていなければ、どれほど誠実な開発会社でも、適切なライセンスを選びようがない。
よくある失敗パターン
Kさんのケース以外にも、現場でよく耳にする失敗のパターンがいくつかある。
一つは、事業計画が後から変わったケースだ。開発当初は完全に社内利用のつもりだったシステムが、事業環境の変化で急にグループ会社への展開や外部提供の話が持ち上がる。このとき、当初の発注時にライセンスの確認を怠っていたために、いざ展開しようとした段階でコピーレフト型の制約に気づき、該当部分を丸ごと作り直す羽目になる。作り直しの費用は、当初の開発費を上回ることも珍しくない。
もう一つは、サポート終了に振り回されるケースだ。ある部品に依存してシステムを組んだものの、数年後にその開発コミュニティの活動が停止し、セキュリティ上の脆弱性が公表されても修正版が出ない状態になる。取引先や監査法人からセキュリティ対応を求められて初めて、自社のシステムが「サポートの切れた土台」の上に立っていたことに気づく。この場合、代替部品への置き換えは、当初の開発とほぼ同規模の工数がかかることもある。
もう一つ、見落とされがちなのが、開発会社が変わるタイミングでの失敗だ。当初の開発会社が持っていたライセンスの管理台帳が、開発会社の変更や担当者の退職とともに引き継がれず、次に依頼した会社が「何がどのライセンスで使われているか分からない」状態からやり直すことになる。これは発注者側が納品物としてライセンス一覧書を明確に求めていなかったことに起因する場合が多い。
これらの失敗に共通するのは、いずれも「発注時点では誰も悪くなかった」ということだ。開発会社はコストを抑えるために誠実にオープンソースを提案し、発注者は目の前の予算内でシステムを完成させることに集中していた。ただ、その先にある事業の広がりについて、両者の間で言葉を交わす機会がなかっただけだ。壁を越えて仕事をするというのは、まさにこうした見えない境界線を、あらかじめ言葉にして共有しておくことに他ならない。
まとめ
オープンソースは、限られた予算の中で質の高いシステムを作り上げるための、非常に強力な選択肢だ。それ自体を避ける理由はどこにもない。実際、世の中の多くの優れた業務システムが、オープンソースの土台の上に成り立っている。
大切なのは、オープンソースを使うこと自体ではなく、そこに付随するライセンスという使用条件を、発注者自身がうっすらとでも理解しておくことだ。すべての条文を読み解く必要はない。改変や再配布、商用利用の可否がライセンスごとに異なること、そして中には自社の独自コードにまで公開義務が及ぶ種類があることを知っているだけで、発注時に交わす一言が変わる。
Kさんはその後、開発会社と話し合い、問題になった部品を別の緩やかなライセンスの代替部品に置き換えることで、外販の道を開いた。追加費用はかかったが、致命的な事態には至らずに済んだ。もしあの時、発注段階で「将来的に外部提供する可能性がある」と一言伝えていれば、その追加費用すら発生しなかったかもしれない。
非エンジニアであることは、システム開発において引け目を感じる理由にはならない。専門知識の壁の向こう側にいる開発会社と、事業計画という自分たちにしか語れない情報を持ち寄って、初めて一つの良いシステムが形になる。ライセンスの話は難しく聞こえるかもしれないが、要は「このシステムを将来どう使いたいか」を先に伝えておくという、ただそれだけのことだ。その一言を惜しまない担当者が、結果として会社の資産を守ることになる。