アジャイル開発における受注者の裁判リスクと実務上の備え２ 見積もり段階
2025.09.15UP!
１．見積もり段階でのアジャイル
開発側とユーザー側は常にコミュニケーションが異なる。期待値は異なる。開発側は誠実に伝えることとテクニカルに伝えることと受注を受けたい気持ちがあり、幅広な見積もりを作りがちである。
これに対して、ユーザー側はふわっとしたアイデアが多く、資料も作っておらず、予算をたてるために見積もりを貰おうとする。そして相見積もりなどをして、値段などを踏まえて考えていく。個々に大きな落とし穴がある。
予算を立てる際に、多めに見積もらない限り、大体はうまくいかない。バッファーがないと、大体横道にそれる。あれもこれも後に追加することで、いいものができない。
ほとんどのケースは、盛り込み過ぎて、MVP（最小限の有効な製品）を作ろうとせず、市場テストをすることができない。これは、最初から負けることを確定しているケースが多い。
これに対して、市場に早くに出すことができると、市場のあたりハズレを早い時期に感じることができる。この点、市場に早いうちに出せば勝てるという勝負ではなく、大体はファーストペンギンのプロダクトを学習されて、二番目の方が戦略をうまく立ててなぎ倒すケースの方がある。例えば、フラーとメルカリの争いは、どう抜きさるかが勝負になった。金とマーケティング、決めが大事になることの方が多い。
大勝ちしようとして、機能を入れまくることで負ける方が多い。
この会話は、相手にしなければならない。無論、お客様と思っている業者はその点ができず、かえって盛り込む。なぜなら金になるからだ。同様に商品に入れ込み過ぎて、エンジニアがプロダクトを壊してしまうケースもある。とにかく、エンジニアは市場に入れてから勝負ということもあるので、機能を最小限で、プロトタイピングを作る方が勝ちやすい。
そのプロトタイプを手軽に作りつつ、再度の見積もりをする方が、顧客と開発業者はチームとして成立しやすい。すなわち、開発業者は、単なるプロダクトを完成させる人間と思われたら終わりなのだ。
見積もりを出す際、ストーリポイントについては説明をし、どうしてこの見積もりをしたのか明確にした方が良い。なぜなら、その前提を覆すユーザーが多いからだ。条件付けをしっかりして、見積もりをしていくこと、それを理解したことの証拠をユーザーから貰う必要もある。加えて、開発業者は人月的な部分もあるので、スケジュールを決めて、ここまでなら有効な見積もりであることも明確化しておく必要がある。
もう少し言えば、見積もりのための見積もりをするという手法もできる。コンペをして、客の注意を引くパターンもあるが、大体は客の期待値を上げつつ、チームプレイがうまくいかないために、コミュケーションがうまくいかないケースもある。
小さくでも良いのでお金を貰い、チームとして仕事ができるか否かを確かめるというのは重要な作業となる。この点、かかる作業をすると、多段階契約として請負になるという懸念もあるかもしれない。しかし、前述の通り、準委任ないしアジャイル開発契約＝ゆるい優位な契約と思う方がまずい。要は揉めないようにするにはどうすればよいのかを考えるべきであり、そのために相性がどの程度あるのかを確認していく方が望ましい。
２．アジャイルにおける工数見積もり
実は、アジャイルの場合、工数見積もりは後でおきる話になる。すなわち、ユーザーは、キックスタートの段階まで資料を出さず、結果的に契約締結後に何らかの資料を出すケースの方が多い。この場合、アジャイルの先述の見積もりは意味あるのかという話があるが、裁判においては必ずその見積もりの証拠とその説明の状況説明は必要になる。
なぜなら、ユーザーは開発業者と全く違う方向性で考えている方が多く、その見積もりで多くの作業をさせることを考えているケースもあるからだ。つまり、留保と証拠は出来るだけ積み上げ、期待値を上げすぎない仕組みの方が好ましい。
そもそも安いから業者に依頼するという手法は、大きく空振りをするケースがあるので、そのような誤解を受けないように、業者としては見積もり段階でしっかりと説明をした方が望ましい。
期待値のずれを如何に操作するかが、炎上しないコツではあるが、その意味でエンジニア＝説明できる人と思うのは誤謬である。説明をちゃんとできる人と腕の確かなエンジニアとは別の話であり、前者もチームとしていないといつの間にかすれ違ってしまうケースもある。
なお、アジャイルにおいては基本設計の説明を碌にせず、キックスタートになってから急に基本設計の詳細が決まり、それにあわせなければならないケースもある。その場合、その人間が上流になり、その人間を通して、プロダクトオーナーと話すという手間がかかる。そのものが責任感がないと、大きく炎上するケースもある。すなわち、基本設計をした人間がどこまで信頼できるのか、常に見ておく必要がある。
プロダクトオーナーは、常に協力的とは限らない。寧ろ、任せたくらいの気持ちになりやすい。特に基本設計を誰かに任せると、自分は営業をすればよいとして、意思決定を渋る。又は、意思決定をする情報が無く、結果的に判断できないなどのケース、その意思決定権限が無い人が恰もプロダクトマネージャーのようにふるまうケースもある。結果的にスケジュール管理を如何に開発業者がするかが肝になり。そのあたりの期待値操作を如何にやれるかが重要になる。そして、そうした記録をスプリントバックログ、プロダクトバックログ、定期ミーティングでもしておかなければならないが、できるだけその会議の詳細を書いて、誰が意思決定者か明確に書いておいた方が良い。なんなら今は議事録は自動化して、その上で分かりにくいところを加筆し、詳細に書く方が後々揉めたときに救済策になりやすい。
３か月というスパンの場合、できるだけ見えるものを作り、延長につなげたいケースもある。そこで、工数見積もりを後回しにするケースもあるが、ここがユーザをマネジメントするために必要であったり、費用の概算を出すために必要になるので、早め早めに計算した方が良い。ただ、ストリーポイントは、速さも関係するので、実際に計測して作成することになる。
とすると、最初は顧客の期待した概算を計画として埋め込み、顧客に見せるとしても、必ず徐々に変化して延長になることが目に分かるようにしておいた方が良い。その理由は、ユーザーは大体のケース多くの機能を盛り込み、より時間をかけることに力を傾注しがちだからである。その辺のマネジメントを怠ると、後にどちらが悪いか争うことになる。
確かに、自分の落ち度であるという証拠化こそが、ベンダー側の守りになるものであり、結果的に友好的にチームとして働きやすい環境づくりになる。
この点、ユーザーサイドがたまに強圧的で仕事がしづらくなるケースもある。この点は迷惑にしておかないと、スクラムを組んだメンバーが疲弊するケースが出て、結果的にチームの存続が危うくなるケースもある。そうした場合、速やかに問題を適示できる程度の証拠を集めて、エスカレーションをし、高い地位の人間に関与してもらい、緩和してもらう必要がある。
以上の通り、質の高いエンジニアを集めて、うまく運営できるというのは幻想であり、寧ろ、顧客とのやりとりがうまくできた方が炎上しないケースも多いことは認識しておくべきである。
基本的にアジャイルであることをいいことに、基本設計を逸脱したり、仕様変更を頻繁に行うケースも多く見受けられるが、それはユーザ自身が最初から気付いていない、又は、意図的に行っていることもあるので、線引きを早い時期に行うことが好ましい。揉めるならできるだけ早めに揉めるべきであり、時期が経てばたつほど双方に裁判で解決をしなければならないケースの方が多くなる。
以上のことを勘案すると、如何にアジャイルにおいては工数見積もりを出来る範囲で早期にだすかが鍵であり、かつ、その工数見積もりをいつ出せるのかを前出しするかで、顧客の期待値は異なることを理解しておくべきである。
