(株)ドローデザインでは、ものづくりを担う過程で、電子回路の設計図(=回路図)を描き、その電子回路を制御するソフトウェアプログラムをプログラミングします。その開発・設計工程で生じる「データ」について、どこまでをお客さんに納品するのが正解でしょうか？
一度、考えてみましょう。
製品やシステムに必要なものは、全て納品対象なのか？
ものづくりであれば、生産する上で必要なデータは全て有るべきと考えられます。
システム開発の場合においても、協業の別業者さんが設計されているケースを考慮すると、必要な情報提供をしないことで、永遠に製品が完成とならないのは違うと考えます。
今回の首題である「ソフトウェア」に焦点を当てた場合、
「全て」の中には何が含まれるのでしょうか？ これがキーポイントになります。
まず、ソフトウェアを設計することで、生成されるデータはいくつか存在します。
・ソフトウェア内部仕様書 -> 特にご要望が無ければ省略することも良くある
・ソースコード
・CPUに書き込むバイナリデータ
(アプリケーションだと実行形式ファイル)
大きく3つあります。
基本的に「CPUに書き込むバイナリデータ」が、納品成果物の主たるものとなります。
これが無ければ、製品を作っても動作品にならない為、納品しないという選択肢はあり得ません。
他、内部仕様書、ソースコードについては、協議が必要な項目だと考えます。
書面はドキュメント作成工数を見る
各種書面を作成することが、当然の様にブログで綴られていることがありますが、実際はドキュメント作成費を頂いて作成を行います。
もちろん、お客様からの作成要望があり、且つドキュメントに求められる充実度合いをヒアリングした後、適切な費用を見積もりさせて頂くという経緯を踏んでいます。
箇条書き程度の内容であれば、無償作成にてご提供をすることになります。
ソースコードはデフォルト納品しない
「ソースコードは基本成果物には含まない」というのが当方の考えです。
プログラマーが時間を掛けて習得した技術知識であり、開発会社のノウハウ部分でもあります。
事前にオープンソース化する前提で参加しているプロジェクトは、この限りではありません。
ソースコードが必要な方は、以下の2つの選択肢をご提案しています。
・ソースコードにも価値がある(価値があるから欲しい)ので、
ソースコード自体をご購入頂く(販売契約)
・開発当初の個別契約書に双方が同意の上で、
ソースコードを成果物に含むことを盛り込む
現実的な方法論ということで記載していますが、後述しているトラブルにも関わるので、よくよく協議が必要な内容だと考えます。
判例上はデフォルトの帰属は設計者である
契約書において、納品成果物にソースコードが含まれた上で取り交わしがない場合、基本原則として設計者に帰属するという判例があります。
また、契約書に「乙は甲に対して、著作権または著作者人格権を譲渡する・・・」という文面が含まれていたりするのですが、著作者人格権はその性質上、他社へ譲渡できません。
つまり条項に入れる場合「行使しない」という表現が妥当ということです。
書作者人格権は、以下から成立します。
・公表権
・同一性保持権
・氏名表示権
中でも同一性保持権は、ソースコードの修正・変更に対して、設計者に確認が必要な項目です。
つまり、意に反した改版は了承しなくても良く、了承されない場合は勝手に手を加えることができないという性質です。この性質があるため、譲渡という概念ではなく、先の通り「行使しない」という表現になります。
自分が作ったプログラムに対して、多くの人が困る様な改変をされる場合、私が設計者であれば拒否したいと思いますし、了承はしないでしょう。
例えば、自分のプログラムを少し変更することで武器転用が可能となる場合、その様にしたいと仰せになられても、私の技術や知識は武器には利用されたくありません。
書作者人格権は、設計者に与えられた唯一の権利として、開発意思や開発意図が示せる機会なのです。
設計者に与えられた権利があることは知っておくべきですし、
用途として、正しく使われる様に管理も必要だと感じます。
結局、成果物に含まれるの？
ソースコードは、契約内容によっては含まれるものとなります。
契約書を交わしていない場合、設計者が納品したくなければ断ることが可能で、
逆に、何も差支えが無ければ納品しても、それ自体は問題ありません。
成果物に含むか否かは、自社の考え方と契約内容に依存するというのが実態です。
ソースコード納品の伴うよくあるトラブル
発生するトラブルあるあるとして、考えられる事例として記載をしております。
◇ソースコードから設計思想のレクチャーを求められる
役務としては、ご依頼された製品開発や製品製造であることが大半と思われ、プログラム構成の良し悪しに対して、学術的な議論を交わすことになったり、後学の為と題して、講義を求められるケースが考えられる。
◇意図しない(周知しない)コード改変をしてFIXされてしまう
先方にて、プログラムコードを変更されて製造物へ書き込みをされるケースが考えられます。
システムであれば、周知しない改変にてリリースということです。
開発責任を負っているものの、評価・検証を行った制御状態とは異なる為、市場で問題が出ても担保ができない上、適切なソフトウェア管理が成されていない場合、オリジナルのソフトにバグがあったのか、改変したことでバグとなったのか、特定ができない可能性も考えられます。
他にも事例を挙げればたくさん出てきそうですが、先方が必要だから納品するものであり、
その必要性に対する認識と、起こりえるトラブルとの向き合い方が共有できることが望ましいです。