準委任契約はアジャイル開発の何を解決するのか？
隔週で「正しいものを正しくつくる」の本読み会を実施している。
この本の3章は思い入れがあり、時間をかけてじっくり読み進めている。3章の主題の一つに「余白の戦略」がある。
アジャイルに作り進めることは、アウトプットによる新たな学びを得るため。その学びが、プロダクト開発の計画作りと進行に影響を与えることになる。ここでいう学びは当初計画に織り込めるようなものではないから、その適応は自ずと想定外の対応となる。学びを獲得することがアジャイルの開発の狙いでありながら、実際のところその学びをどうやって受け入れられるようにするかは容易な話ではない。受け入れる「余白」が必要になる。
このあたりが余白の戦略のエッセンスとなる。
・調整の余⽩
広さをコミット深さで調整する。全体の必要最⼩限の実現を⾒⽴てつつ、状況を踏まえて実現内容を調整する。
・期間の余⽩
バッファの確保。個⼈・局所のバッファではなく、 プロジェクトやテーマ単位でバッファを設ける。
・受け⼊れの余⽩
ICEBOXの運⽤。学びを蓄積(凍結)し、状況を⾒て棚卸 (解凍)し、PBLとの順序付けを⾏う。
この戦略は、ソフトウェア開発の「受発注」の文脈で「どのような契約を選択するのか」にも影響を与える。ソフトウェア開発、特に学びを発見しながら作り進めるような期待に対して、期間と予算をfix前提と置く「請負契約」は適用し難い。一般的に「準委任契約」を前提とするケースが多い。
私も、準委任契約の推奨を基本とする。特に、「はじめての」アジャイル、「はじめての」アジャイル開発の外部委託などという場合には、運営の複雑性を下げるために、準委任契約を選択するのは不可避と言える。
アジャイル開発の具体的な契約内容についてはIPAが発信している雛形を参考にすると良い。よくScrumの言葉と概念を契約条項に織り込んでいると思う。
ただし、一つ心にしておきたいことがある。契約形態で解決できるのは一応の前提合意にすぎないということを。例えば、ECのサービスを構築するというミッションの下、プロジェクトを進めていくとする。Sprint単位で、チームや関係者の間で作るものを確認しながら進めていったとしても、当初予算が尽きるタイミングにおいて「ごめん、カートの機能ないねん」「決済機能は乗せられへんかった」という話に果たして合意ができるだろうか。きっとこういう言葉があふれるだろう。「話が違う」と。Sprint単位で合意していたのに？ そう、残念ながら。
欠けているのは「全体性の管理」だ。作るべきものの詳細は決まりきってないし、それこそ形にする中で意思決定をしていきたい、だがそれと同時に全体感としての「実現したいもの」は、ある。だから、全体感としての「実現したいもの」が「できなかった」ということは約束が違うということになる。
無茶なオーダーだろうか？ だが、プロダクト作りとは、全体のイメージはあっても詳細は決められない、というスタートラインに立って、より良い形を探していく、そういう営みなのだ。
準委任契約で、手ぶらで（＝全体性の管理を放棄して）進めていくことは、契約条項的には何かを守っている気にはなれるが、成果や信頼という観点では何も守られはしない。ECのサービスをオーダーして、決済やカートが欠落している状態でも良しとするベンダーと誰が「次」もやるだろうか。
問題と解決策の関係が整合取れているようで取れていないことに気づかなければならない。
不確実性の高い状況に適応する → 責任をすべて被らないように → 契約形態を工夫する（解決したいのは責任問題？）
不確実性の高い状況に適応する → 新たな学びに適応できるように → 余白を生み出す（余白がなければ受け入れができない）
そこで、前段の「余白の戦略」の出番となる。どのようにして余白を生み出すのか？ もちろん詳細は書籍をあたって欲しい。
むすびとして。「契約交渉よりも顧客との協調を」をマニフェストとしてい掲げている開発のあり方を選択しながら、契約形態でこの手の問題解決を行おうというのは、そもそもの筋が悪いと私は思っているよ。