主旨

実情に契約形態を合わせ、開発が成功するよう柔軟にかまえよう

前の記事

結論

UIデザインが終わるまでを準委任契約のスコープとし、開発完了までを請負もしくは準委任とするハイブリッド契約（多段階契約）なら、わりかしうまくいくと思います

ハイブリッド契約のメリット

必要な機能の詳細が開発前に網羅的に理解しやすく、開発プロジェクトのQCD（いつまでにいくらでなにを実現するのか）をある程度正確に見積もることができます。
また、ドキュメント＋UIデザインの完了を契約の節目とすれば、仮になんらかの事情で開発（実装）の契約が結べない事態に陥ったとしても、ほかの企業に成果物を見せることができるので、「ここまではできている。あとは実装を…」と、交渉がしやすいでしょう。

単契約でそうなると、調整や交渉が必要になり、そう簡単にはいきません

ハイブリッド契約のデメリット

契約や受発注の回数が増え、ややめんどくさいので、お客さんの心情や温度感を気にする営業担当が「『まるっと』でやらせてくれよ！」と失注の懸念を表明するかもしれません。

お言葉ですが、雑に「まるっと」で契約を結ぶことほど、お客さんにリスクを背負わせる行為はないと思います。
お客さんのためにならない方式は私の好みではありません。

雑なまるっと契約が予防できる点で、むしろメリットでしょう

ここまでまとめ

◆ 第1フェーズ
準委任契約＝ドキュメント＋UIデザイン制作完了
◆ 第2フェーズ
準委任契約か請負契約＝開発＋プロダクト納品

とするハイブリッド契約の方針を述べました

改正民法の請負契約

上述のとおりに進めれば請負契約のトラブルが減少する可能性が高い！と期待できはしますが、課題が解消するわけではありません。
その一つに「契約不適合責任」があります。

契約不適合責任とは、2019年2月現在施行されている民法の瑕疵担保責任にあたるもので、この責任の時効が諸条件に応じ、5年、10年、20年間と振り分けられています。
状況によりますが、納品後5～20年間も不具合解消の責を負う可能性があるのです（くわしくは弁護士にご確認を）。

ちなみに、現行民法の瑕疵担保責任の時効は1年間です。
開発企業が請負契約を受けいれるハードルは間違いなく上がるでしょう

請負契約をめぐるせめぎあい

おそらく、多くの開発企業がそれぞれの価値観にしたがい請負契約対策を講じるはずです。
5年後のことなんか想像もつかないのに、どうしろと？という感想が正直なところですよね。
開発企業目線で恐縮ですが、請負契約を結ぶ条件に、以下の候補が頭に浮かびます。

バッファを加えて見積もる

納品後一定期間の保守（準委任契約）の締結を前提とする

請負契約を避け、成果完成型準委任契約でのみ対応する方針を打ちだす

不具合とは

極端に言ってしまえば、最短で5年間も不具合不具合言われる可能性があるということですから…。
でも「だったら不具合を残さなければいいだけじゃないか！」と言いたいお客さんが大半だと思います。
そもそも、不具合が残る前提で心配するとは何事か！？と。

顕在化した不具合はなくせます。
ゼロにできます。
しかし、潜在不具合が潜在しているうちは誰にも気づかれません。
ソフトウェアとはそういうものなのです。

さもなくば、日々スマホアプリが更新されることもなくなるでしょう。
十全に完成し改善の余地がいっさいなく、ハードウェアがいくら発展しても世の需要がどう変化してもおのずから追従できるソフトウェアなら、更新は不要です。

突きはなすようですが、そんなものはありませんのであしからず

対策

じゃどうすんのよ？ですよね。
はい、整理しました。

受発注に主たる関わりを持つ人物や団体だけでなく、利害関係者全体の利益を期し、贈ります

フローチャート

フローチャート各項の解説

さて、本記事はここから有料となります。
フローチャートそのものは無料で提供いたしますので、それを見て理解できる方には購入の必要がありません。

ただし、同チャートは開発企業目線でつくられたものですし、ほんの数行に込めた意図や背景が理解しにくい一部の方には解説が必要でしょう。
わからないけど知りたい！という知的好奇心を持つ方にこそ共有したいナレッジもあります。

スターバックスラテのトールサイズと同じ価格（2019年2月の東京）で提供いたします。
ひと口飲む気分でご覧ください

発注者窓口に、プロダクト開発に慣れた人いる？

いきなり反感を買いそうな条件ですが…