本当に「アジャイル開発＝準委任契約」なのか？

最近多いSaaSパッケージでの事案

「アドオン開発について、準委任契約でお願いします」

ある現場で、販売管理システムのSaaSパッケージを導入することになりました。

Fit&Gap分析が終わり、アドオン開発のスコープも確定しています。

そこでいざ開発に向けて契約を結ぼうとしたら、先方の営業から「準委任契約」の説明がありました。

「は？何を言っているの？開発だから請負契約でしょう？」
「がんばったけど半分しかできませんでした、もあるってこと？」
「後で欠陥が見つかっても保証されないってこと？」

ユーザーからは感情的な質問が相次ぎます。

しかし、ベンダー営業担当は「想定内」とばかりに落ち着いていました。

そしてドヤ顔で次の台詞が飛び出します。

「今回はアジャイル開発なので準委任の契約となります」

実は、今回のようなケースは初めてではありません。以前にもSaaSパッケージ案件で、似たようなことは何度かありました。

ユーザー側はどのように考えるべきなのでしょうか？

アジャイル開発の場合は「準委任契約」が正しいのでしょうか？

確かに正しいと思えるが

まず、一般論から考えてみたいと思います。

「アジャイル開発　契約」でインターネット検索をしてみると、ほとんどの記事で「アジャイル開発は準委任契約にすべし」と書かれてあります。

それらの記事を要約すると
・アジャイル開発は、機能の追加や変更に柔軟に対応する
・開発を繰り返す中で、スコープがどんどん変わる
・いったん完成した機能にも、変更や修正に対応する
・だから、ベンダー側は開発責任のある請負契約はリスクが高すぎる
・だから、作業に対して対価を支払う準委任契約が適切
という主張です。

確かに、この部分だけ切り取ってみれば、正しいロジックに感じます。

この文脈では、「新規のサービス開発」や実験性の高い「PoC」などにおいて、アジャイル開発が向いているのでしょう。

まずは「スモールスタート」でユーザーや市場の反応を見ながら、徐々に機能拡張していけます。

「スコープ」がその都度変わるため、準委任契約は適切といえます。

ベンダーに流されず本質から考える

他方、今回の「アドオン開発」を考えてみます。

アドオン開発を端的に言えば、パッケージという「既製品」があり、そこに足りない部分を開発するということです。

足りない機能の設計書を作り、プログラム開発→テスト→納品となります。

パッケージを「巨大な部品」と捉えると、そこを活用するだけで何ら普通のシステム開発と変わりません。

ここでなぜ「アジャイル開発」かといえば、すでに動くシステム（Sandbox環境）があり、機能を順次追加していけるからです。

「設計→製造→テスト→フィードバック」のサイクルを高速に回して、確認ができます。

機能単位で次々に完成までもっていけるため、効率的に進められます。

しかし、大きな違いとして、パッケージのアドオン開発はFit&Gapで「スコープ」があらかじめ確定しているということです。

つまり「スコープ変動のリスクが大きいから準委任」という話にはなりません。

それなのに、約束したスコープの完成責任を負わない準委任契約では、ユーザー側が一方的に不利になるだけです。

「アジャイルだから準委任」というのは、ベンダーの都合のよい解釈であり、その提案を堂々としてくる時点で、ベンダーの誠意を疑ってしまいます。

SaaSやオンプレを問わず、パッケージでアドオン開発をする場合、Fit&Gapで「スコープ」を決めたなら、請負契約は死守すべきです。

アジャイルだからとベンダーの口車に乗せられてはいけません。

品質保証すべきプログラムがあるかどうか

ただし、補足しておくと例外はあります。

ノーコード／ローコード開発の場合です。

こちらは高度なプログラミング技術がなくても、あらかじめ準備されている部品を組み合わせたり、設定をしたりするだけで構築していけます。

プログラムの品質保証という意味合いは薄くなり、何か不備があっても、ユーザー側で修正することもできます。

そのため、ユーザーの「代行」として、「先生役」として、「お手本」として、ノーコード／ローコードで実装してもらうのであれば、準委任契約で差し支えないと考えます。

根本原因と対策

「はい、ぜひこの契約でお願いします！」

冒頭の現場は、ユーザー側が強く抗議したため、ベンダーは持ち帰って検討となりました。

そして再提案の場では、アドオン開発は「請負契約」となり、成果物と完成責任が明記されました。

ちなみに、その後の移行支援や本番稼働支援は「準委任契約」の予定ですが、内容的に問題はないと判断しています。

なお、このプロジェクトにおける最大の反省点は何でしょうか？

それは、RFPの要求事項に「契約方法」を盛り込んでいなかったことです。

ベンダー選定時の時であれば、「調整事項」ではなく「提案前提」となり、そもそも火種にすらなりません。

この現場では、RFPの自社フォーマットに改訂を加えることになりました。

貴社のIT部門・情報システム部門は、アジャイル開発における契約をその性質によって使い分けできていますでしょうか？