リーン-アジャイルのメーリングリストでAlan Shalloway氏はこう書いている。
ソフトウエア開発の請負業者の作業進捗/有効性を追跡するための契約(または作業スケジュール)の書き方でおすすめの方法はありますか。[...]これ[この問いは]アジャイル/リーン/カンバンを念頭に置いた質問ですが、これらの開発手法に限定して質問しているのではありません。
Jeff Anderson氏は参考になるいくつかの具体的な契約条件を書いている。
これがちょうど終わった契約に私が含めていた内容です。この顧客のためにいくつかのストーリーを完成して実務上の利益を得ていましたので、複雑さの観点からどのようなことが起き得るか分かっていました。正確な内容は開示できませんが、以下に挙げることはあなたの助けになるでしょう。この方法がうまくいくように、バックログにあるストーリーとすでに完成したストーリーの複雑さが平均すれば同じくらいになることを想定していました。進捗は毎週報告して、想定外の進捗になってしまったら調整を要求して対処しました。またある種のバックログには顧客に責任を持ってもらうようにし、2日以上はこれらのストーリーに着手するのを待ってもらいました。これも変更要求を行って対処しました。
- 20日で80%の精度でストーリーを完成させる場合のSLAに含めるサイクルタイム
- 7つのユーザストーリーを1ヶ月で完成させるスループット
Hillel Glazer氏は契約条件を独特の観点から記述し始めた。
契約を考えるとき、まず、私がどのように顧客と私の関係を望んいるのかについて心に描くことから始めました。そして、顧客が私に支払いをするとき、顧客にどういう感情でいてほしいか考えました。私に何を支払うのか。そして、もっと重要なのはなぜ支払うのか。私はその支払いに値する仕事をするか。契約にそう書いてあるから支払いをするという気持ちにはなってほしくありませんでした。こう考えることで価値について力を注げるようになりました。契約内容だけでなく、顧客とのやり取りの中に価値を込めることができたのです。
契約で使う言葉を見てみると、ほとんど弁護士が使う契約書と驚くほど(ほとんど不愉快になるほど)そっくりになってしまっているのに気付きました。なので、私のサービス提供に対する対価を払ってくれる"契約"書を徹底的に考えました。サービスの"契約期間"、"顧客の要求のために"サービスを提供すること。そして、"互いにとって望ましい具体的な成果に関する特別なタスクと努力"などです。
最終的な成果はどんなものであれ、契約内容に含まれていない作業の成果になります。そして実際には、私が提供するサービスは契約にかなったものになり、作業や最終的な成果はこれらのサービス提供が生み出した独自のものになります。
一方、Peter Stevens氏によれば、契約には下記が含まれなければならない。
- プロジェクトの目的と各企業間の協力の目的
- プロジェクトの構造の概要
- 主要人員
- 支払いと請求
- 早期終了と通常終了
- 地域法や法習慣に照らし合わせて必要な細目
style="margin-top:5p