2025.08.25

“もっと！「契約交渉よりも顧客との協調を」〜協調を助ける契約と関係づくり〜” 補足情報追加しました

もう8月も終盤なのに暑いですね！もうこれ以上脱げるものがありません。どうも笹です。

1ヶ月以上前になりますが、7/18,19に開催されたScrum Fest Osaka 2025で "もっと！「契約交渉よりも顧客との協調を」〜協調を助ける契約と関係づくり〜" という発表をしてきました。
ありがたいことに発表前後にいろんな方から質問を受け、様々な話ができました。また、キーノートスピーカーのJames Coplienのコーチズクリニックで相談させてもらい、今後のヒントをもらうことができました。
スライドの内容に興味ある方には参考になる話だと思うのでシェアします。更に質問やコメントがあればこちらまで連絡いただければと思います！

１つ１つのテーマが長めなので、目次を見て興味あるところだけつまみ食いしてください！

発表内容の概要

質疑応答の説明前に、セッションを聞いていない方や、スライドを読んでいない方向けにセッションの概要だけ説明します。気になる方はスライドを読んでください。

スライドを見るのが面倒な方向けに超絶概要

協調するのを難しくする原因

原因を踏まえてもっと協調する上で大切なこと

大切なこと① 評価を合わせる

大切なこと② 理解のギャップを減らす（同じプロセスを経験する）

大切なこと③ 関係づくり

もっと協調するための具体的な取り組み

真・アジャイルソフトウェア開発宣言

本編の補足情報

補足情報① Copeのアドバイス「成果の計算に１次情報を使うか２次情報を使うか」

相談内容

ビジネスインパクトと評価を合わせる時のポイントを相談しました。もうちょっと具体的に書くと、成果報酬型の契約を行う際に、成果の算出に１次情報（売上など）を使うか２次情報（新規ユーザー数など）を使うか、という相談でした。

この相談をした背景

基本的にはシンプルに１次情報を使いたい
開発するシステムによっては、直接的にレベニューを生み出すものではないケースがある
１次情報は様々な要素が絡み合っているため、誰がどの程度寄与したか不明瞭
１次情報は結果として数値が変化するまで時間がかかる傾向がある

ざっくり言うと、１次情報を評価に使いたいものの、評価のために１次情報を活用するのは難しい、ということです。そこで１次情報と密接な関係を持つ２次情報を評価に使うアイデアを考えていました。この辺りは悩ましかったため相談させてもらいました。

相談への回答

結論：２次情報は使わず１次情報を評価に使いましょう

２次情報は定義、計算式、データの取り方によってバラけてしまう
つまり、２次情報はいくらでも操作ができてしまう
操作ができるものを評価に使うのは良くない
１次情報を予測できる２次情報を設定しても、多くの場合２次情報は１次情報と強い関連がない

こちらもざっくり言うと、２次情報は誤魔化せちゃうので良くないし、２次情報と１次情報が強い関連を持っていることも少ないので、２次情報を使うのはオススメできないということでした。後からでもいいので１次情報を取得し、１次情報で評価するように調整した方が良い、と言っていました。

このあたりはその通りだと思いつつ、工夫が必要になる点だと思うので考えていきたいと思っています。

補足情報② Copeのアドバイス「成果報酬型に関わる企業数について」

相談内容

こちらは私から相談したわけではありません。おそらくCopeのこれまでの数多くの経験から失敗するパターンを伝えておきたかったのだと思います。

この話題が出た背景

Copeの経験上、製造業などの大きなプロジェクトにおいて開発会社が１社しかいないということはほぼなく、複数社が関わることが多いようでした。以下の図のように、サービスを提供する会社は１社ですが、ユーザーや開発に関わる組織が複数いる、という状況です。この中で成果報酬型の契約を結ぶのはサービス提供者と開発の間になります。
この関係になってくると、成果報酬においてリスクが出てくることが多いため、Copeが話題を出してくれました。

この話題の結論

結論：成果報酬型の契約に関わる開発組織は、2以下にするのが良い

条件毎に、以下のような話になりました。

サービス提供者と開発が１：１の場合は問題なく契約を行うことができる
サービス提供者と開発が１：２の場合も、開発２社で議論の上、問題なく契約を行うことができる
サービス提供者と開発が１：３以上の場合、うまくいかないのでやめた方がよい

うまくいかないとは？

「どの開発組織がどのくらい成果に寄与したのか計算できず揉めてしまう」ということです。１次情報は様々な要素が組み合わさった結果として出てきますが、要素毎にどの程度の影響があったのかを全員が納得できる形で計算できる気がしません。組織毎に評価指標を用意することで可能かもしれませんが、補足情報①にあるように２次情報は誤魔化せてしまうことや信頼性が低いことを考えるとあまり良いアイデアではなさそうです。

我々の現状に当てはめると…

私たちがチャレンジしているのは、まだそこまで大きなプロジェクトではないため、サービス提供者と開発が１：１の状況になります。ただ、通常の準委任契約で実施しているプロジェクトでは多くのチーム・会社が関係しているものもあります。成果報酬型が軌道に乗ってきた後になりますが、大規模なプロジェクトにおいてどうするかは検討する必要がありそうです。（生成AIの進展で開発チームがそこまで拡大しない未来もありそうなので状況を確認しながらかな）

補足情報③ セッションの質疑応答「この取り組みを始めるための最初の一歩」

質問の背景

このスライドにあるような取り組みは良いと思いました。ただ、片方の会社がやろうと思っても始めるのは難しい気がしており、まずは何をやればいいんだろう？という疑問が湧きました。という背景から「最初の一歩は何をすれば良いですか？」という質問をいただきました。

質問への回答

結論：「この取り組みをやりたいです」という意思表示を顧客にバンバンしていく

というのも、私自身もこの取り組みを始めるまでは「お金を払うから開発してくれ！と思っている顧客が大半なんじゃないかな？」と思っていたからです。ただ、挑戦することを決めて様々な顧客に取り組みの説明をすると、想像以上に興味を持ってくれる方が多いことに気付きました。すぐに仕事になることは少ないと思いますが、まずはこういう取り組みをして顧客のビジネスを本気で成功させたい、という意思表示をしていくことは大事だなと思っています。

補足情報④ セッションの質疑応答「成果報酬型契約にかかる工数はどの程度か」

質問の背景

成果報酬型契約のおいて、指標や目標値を決めるのが非常に重要である一方、決めるためのすり合わせは大変そうに感じたため、実施にどの程度の工数・負担がかかったのか、という話題になりました。

質問への回答

結論：指標は時間がかかっていないが、目標値設定は難しいので設定タイミングを検討する

指標について

決めるまでにあまり時間がかかっていません。というのも、指標を決める云々の前に、顧客のビジネスを理解するために様々な話をしています。その中で「この辺りが大事なポイントだな」というのは見えてきていると思います。ということで指標を決めること自体は数時間で合意まで進められています。

目標値について

目標値を決めるのははなかなか難しいです。新規サービスを作る場合、指標がどの程度の数値になるのか分かりません。夢や希望の数値はあったとしても、契約として評価に使う妥当性のある数値を決めることは難しかったです。指標にもよりますが、ファーストリリースの時に目標値だけは見直す前提で契約を行うのも有効な手段になるかなと思います。

補足情報⑤ 懇親会での質疑応答「内製開発の場合、成果と個人評価を繋げるべきか」

質問の背景

セッションでは受託元と受託先のように、別の会社が更に協調するための話をしました。しかし、同じ会社内でも同様の課題感はあります。ビジネス部門と開発部門が完全に分かれていて、社内受託の関係になっているような組織です。質問者の組織では、まさに社内受託の関係になっており、もっと協調するためにどうすれば良いか悩んでいる中で、内製開発における成果報酬とは個人評価との紐付けを行うことだろうか？と悩んでいました。

質問への回答

結論（自論）：プロダクトの成果と個人評価は直接的に繋げるのはやめた方が良い

ちなみにクリエーションラインでも「成果報酬型で失敗した場合、給与は出ますか？」といった質問が出たこともあります。答えは「ちゃんと出ます」。

直接的に個人評価と繋げていない理由

良い影響よりも悪影響の方が強く出そうだからです。例えばですが…

失敗＝収入が減る、ということで日々のストレスが爆発的に高まる
失敗できないため無難に思える施策を選択し、結果としてつまらないブロダクトになり失敗する
私の責務である機能開発は完璧なので、今回の失敗はマーケのせいです、のような他責が増える

程よいプレッシャーであればプロダクトを成功させる原動力になると思います。ただ個人評価、つまり収入への影響は過度のプレッシャーであり、メンバーの心身の健康、プロダクトの成功率、協調の瓦解、といった悪影響に繋がる可能性があります。メリットよりデメリットが大きいため繋げていません。

代わりとなる協調を高めるアイデア

経験がないので想像にすぎませんが、組織構造やプロセスの方に目を向けて改善していく気がします。と言うのも自社プロダクトがある会社はミッションやビジョンがしっかりしていることが多い気がします。目指す方向は共通になっているのに協調できないとすれば、協調できないような組織構造になっている（サイロになっているなど）、協調が不要ななんちゃって高効率プロセスになっている、あたりに原因がありそうだからです。

自社プロダクトがある企業における個人の収入

そもそも評価・収入面で言うと、自社プロダクトの場合はプロダクトが成功すれば自ずとメンバーの収入が増える方向に進むと思います。やるとしたら「プロダクトを大成功させて、社会を良くして、結果としてみんなで儲けよう！」ってメッセージを出すとかですかね？

補足情報⑥ 懇親会での質疑応答「リスクが高いので経営層が認めてくれなそう」

質問の背景

成果報酬型のような契約は魅力的である一方で、利益が減る可能性もあるためリスクが高い契約だと思います。リスクが高いため、開発現場がやりたいと言っても経営層はやらせてくれない気がします。

という話で、やりたいけど上司などの相談したらきっとNG出されそうなのでどうしたら良いか、を考える場になりました。

質問への回答

結論：クリエーションラインでは社長が一番ノリノリだったので説得の必要はなかった

とはいえ、最初から社長の安田さんノリノリだったわけではなく、そこに至った流れがあるのでその辺りを話しました。

どんな流れで成果報酬に至ったか？

まず、我々もいきなりリスクの高い成果報酬型から始めたわけではありません。では何かから始めたかというと「顧客とアジャイル開発チームを作り一緒にモノづくりをする」というものです。今もメインのビジネスでやっていることです。このアジャイル開発を実施する経験と、取り巻く環境の変化から２つの想いが出てきました。

「顧客と共に社会の進化を実現する」というビジョンに向けて、更にもう一歩踏み込みたい
生成AIの進化により、これまでと同じように開発をメインやり続けるのもリスクが高いのでは？

ビジョンに一歩踏み込むアイデア

ビジョンについては経営層が本気で取り組んでいることですし、更に一歩踏み込むアイデアの１つとして成果報酬型が出てきました。この時点でもリスクの話は出ましたが、働いた時間ではなく作り出した価値に応じた利益になるのは、エンジニアのやりがいという点でメリットがあります。これまでの経験上、うまくやれる気もしていたのもあります。

生成AIへのビジネス面での対応

更に外部環境に目を向けると、生成AIの進化スピードが目につきます。生成AIにより開発作業は効率化され、多くの人が実施可能になっていく傾向があるため、ビジネス面でも変化しない方がリスクが高いのでは？という議論もされました。

そういった議論の中で「せっかくなら様々な挑戦をしていこう」という経営判断に至り、安田さんもノリノリで推進している状態です。