【アジャイルソフトウェア開発宣言】「契約交渉よりも顧客との協調を」編

Anycloud PdMの青木です。

前回、アジャイルソフトウェア開発宣言における「包括的なドキュメントよりも動くソフトウェアを」について考えました。

今回は、アジャイルマニフェストにおける「契約交渉よりも顧客との協調を」について、自分の失敗談も踏まえてまとめてみました。

チームとして、全員が成果に責任を持つ

• 契約の目的 ＝ 当事者間で法律上の権利や義務を発生させ、後々のトラブルを回避するため
• 開発範囲（責任分担）、納期や費用
• 対話を通して協力しながら、変化に対応していくのが大切で、契約条件が邪魔してはならない
• 受託開発だけでなく、自社開発でも当てはまる
• 社内のビジネス部門・営業部門などが「顧客役」を担うことがある
• 契約交渉を「社内ルール」や「承認プロセス」と置き換えることもできる

アンチパターン

契約にこだわりすぎて、顧客と対立関係になる

• 顧客から新しい要望があっても「契約に入っていないので対応できません」と即答してしまう
• 顧客が変化に柔軟に対応できないベンダーだと認識し、不満を抱いて関係が悪化する

↓改善案

• 顧客と同じ目線（立場）になって考える（肩を並べる）
• 例） 顧客から新しい機能追加の希望があった際、まずは目的や背景、その最適なアプローチをすり合わせた上で、見積もりや納期を整理する
• 顧客との長期的なパートナーシップを視野に入れる
• 例）当初予定していなかった追加開発の提案や改善策を、定期的な打ち合わせで積極的に行い、必要があれば契約更新など柔軟に行う

契約更新・変更手続きを必要以上に複雑にする

• 小さな追加機能にも多重承認を求めたり、過剰な事務手続きを強いたりする
• 顧客がプロジェクトの柔軟な変化に疲弊し、アジャイル開発のメリットを活かせなくなる

↓改善案

• 契約形態を変える
• 例）請負ではなく準委任にする

チーム内で責任をなすりつける

• 個々のスコープのみで責任をもってしまい、対立関係になる

• QAは自分の担当ではないからとか、仕様書が漏れていたからとか

↓改善案

• スクラムを組んで、チーム / スプリントで目標立てて、チームで振り返る（レトロスペクティブ）

まとめ

契約という明確な枠組みを設けることは大切な一方で、それにこだわり過ぎると顧客との対立や事務作業の増加を招き、アジャイルな開発が難しくなるリスクがあります。チーム全員が成果にコミットし、契約をベースにしながらも常に顧客と対話し、柔軟に変化に対応できる環境づくりを意識していきましょう。