高校生の頃にPythonとRubyを勉強し、当時はLinuxをオンプレサーバーにインストールするところから始め、Twitter APIを利用してbotやクライアントを作ったり、Webサイトや簡易なWebアプリケーション制作を行なったりしていました。周囲の友人にもエンジニアが多く、新しい分野に挑戦し続けるエンジニアの方々をバックアップしたいという思いがあります。

アジャイル開発にまつわるトラブルが増えている印象があります。その背景として、アジャイル開発の案件が増加しているのが大きく影響しています。トラブルの内容としてはウォーターフォール開発と変わるわけではなく、「完成している・していない」、「納期に遅れている」、「バグを修正してほしい」、「お金を払ってくれない」などの相談が多いですね。

特に上流工程において、クライアント（ユーザー）のシステム開発での自らの役割に対する理解が足りていなかったり、ユーザーとエンジニア（ベンダー）との間でのコミュニケーションが不足していたりすることが考えられます。

アジャイル開発になると、コミュニケーションがより重視されることから、従来のウォーターフォール型の開発以上に、ユーザーとベンダーとの間のコミュニケーションの問題が発生しているように感じます。

必ずしもITに精通しているわけではない「ユーザー」と、ITについては専門的な知識を持つがユーザーの業務には必ずしも精通していない「エンジニア」では、共通理解も少なく、認識の齟齬がどうしても発生しやすくなります。

すなわち、「ユーザー」は自らの業務や何をシステム化するかについて専門性を有し、他方で「ベンダー」はシステム開発について専門性を有しています。しかし、お互いに相手方の専門性については必ずしも精通していません。そのため、システム開発には「二重の専門性」が要求される等と表現することが多いです。

例えば、「納期に遅れた」というトラブルは一見ベンダー側のみの責任のように思えますが、ユーザー側の都合で仕様が固まらずに実装期間を圧迫してしまった場合、ユーザー側にも問題があるわけです。

仕様についてユーザー側には「プロのベンダーが上手く汲み取って提案してほしい」という思いがあります。一方のベンダー側には「仕様にないものは開発しない」という主張があるのです。とはいえ、ベンダーはユーザーの業務に精通していないことが多いですから、この時点で既に双方の思いにズレが生じてしまっている場合も多々あるかと思います。

思いにズレが生じたまま開発が進んで納品された場合、ベンダー側からすると「仕様通りに作っているのだから追加開発の要望だ」として報酬を要求し、ユーザー側は「仕様通りにシステムが出来上がっていない、未完成だから報酬は払わない」主張するので、双方の意見が食い違いトラブルに発展するのです。

裁判ではよく「協力義務」と「プロジェクトマネジメント義務」について議論が交わされます。仕様の話でいえば、まずシステムはユーザーが使うものなので、何を作りたいかを知っているのはユーザーです。ですから、どういったシステムを作るかという仕様をメインで作るのはユーザーであり、これをベンダーが把握するために必要な情報提供等の協力を行う「協力義務」がユーザーにはあります。

先ほどの納期遅延の例ですと、もし仕様が決められなくて実装時間が短くなったことが原因で納期に間に合わなかった場合、なぜ適切な時期までに仕様が決められなかったのかを考えます。仮に、ユーザーが仕様を利害関係者との間で調整できずに時間がかかったのであれば、ユーザーの責任も小さくないことが多いでしょう。

ただ、ベンダーはシステム開発の実績を持っているわけですから、「こういうところはどうしますか？」と適宜質問を投げかけて詳細を詰めることで開発に支障がでないように働きかけたり、「この日までに要件定義が終わらないと納期までに納品できないですよ」とスケジュールを管理したりして、開発が円滑に進むようプロジェクトマネジメントを行う義務があります。

実際問題、ユーザーはシステム開発のプロではありませんから、何をすれば良いのか分からないケースも多いので、ユーザーへの適切な働きかけが求められる場面も少なくありません。

はい。協力義務とプロジェクトマネジメント義務については一義的なものではないので、開発がどの段階にあるのか、どういった状況なのかも踏まえ、過去の事案を参照するなどして双方が行うべき義務を理解することが必要だと考えます。場合によっては今後の事案の蓄積に期待することもあるかとは思いますが、大まかに言うとそれぞれが専門性を有する分野での役割を果たしているのかが重要なポイントです。

なかなか難しい問題ではありますが、1つ大きなことは、お互いの役割分担を明確にしておく必要があるということです。仕様を決定する上流工程であれば、必要に応じて「この日までにユーザー側でこの点に関する仕様を決めてください、そうでないと納期の延長が必要となります。」などといったミーティングの議事録を残すことが有効です。自らが必要な役割を果たしていることを記すとともに、ユーザーの役割を明確に記しておくと良いでしょう。

双方の認識齟齬がないよう、またトラブルになった際に第三者から見てどちらに責任の所在があるかがはっきり分かるよう、各段階で証拠を残しておくことは非常に重要です。

まず、記載内容でのトラブルが生じないようにするため、議事録の内容が双方で確認されることは当然の前提となります。その上で、改ざんの問題に発展しないよう、アクセスログや変更履歴が残る方式を採用することが望ましいですが、メール、チャットなどから日時とやりとりされたファイルが特定できたり、双方の押印や電子署名により内容の変更がそもそもできなかったりといった場合であれば、形態は問いません。

契約不適合責任が問題となる場面ですね。仕様との不一致やバグの発生を指摘され、ユーザーから修正を求められるという事例です。仕様との不一致に関していえば、そもそもシステムの仕様は何だったのか、という点が問題となります。そして、この点を検討するにあたっては、もちろん仕様書が重要であることは言うまでもないですが、先ほどお話しした議事録の有無や記載内容も重要になってきます。

特に、アジャイル開発では、仕様書が残っていない開発や、残っていても記載内容が必ずしも十分でない開発も珍しくありません。双方で仕様に関する認識の共有が十分になされていないケースも多いです。ユーザーとベンダーとが仕様に関する認識を共有できているかどうかは、契約不適合責任が争われる裁判でも重要な問題となってきます。

そうですね。バグといっても程度は様々ですが、例えば、ちょっとした文字化けが発生してしまっているなどの軽微なバグが発生している場面では、ベンダーも修正をすることが多いということが影響していると思いますが、大きなトラブルに発展することは少ないです。

他方で、システム稼働に影響が出てしまうと言えるようなバグが発生している場面では、ユーザーはシステムを利用できないわけですから、大きなトラブルに発展することも多いです。ただし、「ある機能が利用できない」とユーザーからの修正依頼があった場合、その機能がそもそもシステムの仕様に含まれていたのか、という点が争われることも少なくありません。

プロジェクトの頓挫によるトラブルですね。納期を何回も遅らせたけれども、システムが完成しないため契約を解除したいという事態が起こりがちです。この場合、ベンダー側だけに問題があるように見える一方で、なぜ納期遅延が生じていたのか、それぞれが協力義務やプロジェクトマネジメント義務を果たしてきたのか、といった問題とも連動してきます。

頓挫するまでにかかった費用をどうするかという問題ですね。ユーザーがそこまでに出来上がっていたシステムを他のベンダーに引き継いで開発してもらう場合を除けば、ユーザーはシステムでの利益が得られなかったわけで、完成していないシステムそのものに価値はないと考えるのが通常です。その中でベンダーの稼働に対してどう報酬を算出するのかは非常に難しいです。基本的には契約書でどのように定めているかが論点になります。

意外と多いです。人月単価で工数を算出するというのは1つの考え方ですが、それをユーザーが納得できないケースもあります。もちろん裁判によって利益相当額の請求を出来るケースもありますが、やはり契約書で定めていないと揉めることが多いので、契約書をきちんと定め、双方で合意してから進めることをお勧めします。

SESという契約類型が法律の契約類型に存在しているわけではありませんので、当事者間での認識と実際の契約類型がはっきり合致していない場合も多く、準委任契約という名称で契約が締結されていても、その実質は「労働者派遣契約」であると捉えられる場合もあります。実際に労働者派遣契約なのであれば、常駐先の指示に従う必要があります。

他方で、単なる準委任契約の場合は、責任者等を通して指示を受けなければ、偽装請負のおそれがありますので、常駐先から直接指示を受けて従うことは控えるべきでしょう。いずれにせよ、契約類型を把握することが必要となりますし、それを把握しているのは会社ですので、常駐前に会社に確認しておくべきです。

世の中で誤解されていることが多いと感じるのは、準委任契約は請負契約よりも責任が軽いと捉えられていることです。

準委任契約では、請負契約とは異なり、システムを完成させる義務を負うわけではありませんが、善管注意義務を負っています。善管注意義務とは、誤解を恐れずに簡単に言えば、ベンダーとして、システム開発のプロとしての義務を果たすという義務です。すなわち、準委任契約の場合、完成義務は負いませんから、もしある時期までにシステムが完成しなかった場合でも、完成しなかったこと自体に対する責任が直接的には問われません。 ただし、善管注意義務を負っていますから、プロとしての義務を開発期間中に果たしていたかという中で、システムが完成しなかったことも考慮される可能性があり、完成しなかったことに対する責任を負うべきかどうかも間接的には問われるわけです。

著作権は基本的にソースコードを書いたエンジニアに帰属します。会社に所属している場合は会社に帰属することがほとんどでしょう。

ところで、よく契約書で、発注者側に著作権を移転するという内容がありますが、例えばコードを再利用するかどうかという点から、著作権を移転して問題ないか、移転するとしてもすべての著作権を移転してよいかどうかは考えるべきポイントです。もし著作権を移転するとしても、OSS（オープンソースソフトウェア）などのいわゆる第三者ソフトウェアの著作権は移転できません。この点は見落とされがちですので、万一のトラブルが生じないようにするためにも、その点は契約書に記しておくことが重要です。

そうですね。「ベンダーはソフトウェアが第三者の権利を侵害していないことを保証する」と契約書に記載することも多いですが、これもそれでよいのかは慎重に考えるべきポイントです。 特にOSSは、そのライセンスで第三者の権利侵害がないことが保証されていないことがほとんどです。ですので、エンジニア、ベンダーとしては、万一OSS部分に第三者の権利侵害があった場合に備え、OSS部分も含めて第三者の権利侵害がないことを保証すると契約書に本当に明記して良いのか、今一度考えていただく方が良いと思います。

著作権の問題はChatGPTでも発生すると考えられます。例えばChatGPTにプロンプトを入れてコードを吐き出してもらった場合、たまたま誰かが著作権を有しているコードと全く同じものが出てきてしまうかもしれません。この場合、著作権侵害が成立するかどうかは議論のあるところですが、言い換えれば、そのコードをそのまま納品してしまうと、著作権を侵害してしまう可能性もあるということです。

企業でもフリーランスでも案件を受ける時にはNDA（秘密保持契約）を結んでいると思います。そのNDAにより、コードやミーティングでのメモの内容などが秘密情報に該当する場合、ChatGPTにコードを入力してリファクタリング等の何らかの出力をさせたり、ミーティングでのメモを入力して議事録を作成させたりすることは、先方に無断でChatGPTの開発元である第三者のOpenAIに情報を開示しているとして、NDA違反となる可能性があります。そういった観点からもNDAの内容をしっかりと確認し、必要に応じて事前に先方にChatGPTを利用することの同意を得るなど、トラブルとならないように備えておくことが重要です。

今年になって、「特定受託事業者に係る取引の適正化等に関する法律」、いわゆるフリーランス新法が成立しました。まだ検討されている最中の部分もあり、すべての詳細が明らかとなっているわけではありませんが、現時点でわかっていることとしては、下請法と同趣旨の規定がフリーランスにも適用されたり、フリーランスの出産、育児や介護への配慮が求められたりすることとなっています。来年には施行される予定ですので、契約書で新たにチェックするべき事項が増えることになるでしょう。フリーランスの方も、自らを法律で守るために、これを機に契約書をしっかりと確認いただければと思います。