アジャイルなプロジェクトの契約と問題の回避方法
アジャイルなプロジェクトを運営するために、どのような契約手法が良さそうなのか、様々な事例を見て得た知識を発信します。
理想の契約
理想は、すべて準委任契約で進めるのが良いと思っています。
マネジメントさえ間違いなければ、不要なプロセスやモノを作らずに済むからです。
ユーザ側、ベンダー側両者に言えることです。
たとえば、不確実性の高い事柄を予測するプロセスに過度にリソースを使わなくて済むし、一度実施を決めたプロダクトやドキュメントがあまり役に立たなそうであれば捨てて、他のことにリソースを使用することも可能です。
現実の契約
しかし、世の中の事例を聞く限り、すべて準委任では進められないケースもあります。
たとえば、ユーザ側が、発注リスクを抑えたいがために、無茶な契約を提案してくることもあるそうです。
「契約は請負で、開発だけスクラムで」とか、「イテレーション単位(2週間)で契約を結ぼう」とかです。
1つめの契約はベンダーにとっては悪魔の所業ともいえるようなものに感じました。
2つめは期間が短すぎますよね。開発案件の契約作業は少なくとも1週間はかかると思います。
それを毎イテレーションごとにするのは、お互い大変です。プロダクト作りとは違う部分で時間とお金を流し続けます。
発注者側は知らないかもしれませんが、見積にはそれなりに時間とお金がかかっています。
一方、ベンダー側も実力がなく、時間だけ浪費し、ユーザー側に大きな負担を背負わせる場合もございます。
だから、準委任だけの契約はなかなかできないのだと思います。
改善案
では、どうするか。
他の企業様での取り組み事例を聞く限り、2つの案を耳にします。
すべて準委任は難しいという方々は、検討してみてはいかがでしょうか。
事例1は、先程話題に出た2週間単位の契約ではなく、2～3ヶ月くらいの単位で契約した事例です。
少々長めに契約することで、ユーザはプロジェクト失敗のリスクを小さくできますし、ベンダーもプロダクトづくりにある程度集中できるはずです。
事例2は、要件定義だけ準委任でまずは開始。ドキュメント作りだけでなく、モノも作ります。
ユーザからのフィードバックをもとに、プロダクトの方向性や要件をしていきます。
両者にとって有益な効果が示されれば、後工程もアジャィルな開発ができるよう、スクラムなり、XPなりを採用して開発を進めればよいのです。
ここで言う良い効果とは、プロダクトに対する良いアイディアが生まれたり、ベンダーの腕が証明されたり、ユーザの案件参画度合いが熱心で、ベンダーを下請けでなくパートナーとしてみてくれる等を意味しています。
事例2に関しては、他社事例だけでなく、自社の事例(ベンダー目線)もございます。
とあるウォーターフォール型、段階リリース前提のプロジェクトがございました。
１段階目の受け入れテストで、ユーザからの不満が多く、追加要求も多く、信頼関係は崩れておりました。
そこで、２段階目のリリースからは、すべてアジャイルな開発に切り替えました。
手法はスクラムです。１～１．５ヶ月単位の長めのスプリントです。
その結果、ユーザの信頼改善に繋がりました。
モノに触れることで、早期に業務イメージがわいたようで不要な仕様を排除できました。受け入れテストでも「これじゃあ業務が回らない」と言われなくなりました。
契約の問題を回避するための取り組み
上記の契約をうまく結べたとしても、案件が開始してから問題は出るものです。そこで、少しでもその問題を回避できるような案を考えてみました。
アジャイルな開発(お客様との協調が大切等)の価値観を共有
プロダクト価値を最大限に引き上げるためです。たとえば、アジャイルな開発では、顧客との協調を大事にする価値観がございます。たとえ問題が発生しても、顧客とベンダーが案を出し合い協力することで問題解決を早められる。だから、顧客との協調を大事にするのです。
他にも大事な価値観があるので、アジャイルソフトウェア開発宣言、アジャイル宣言の背後にある原則は、皆で読み合わせをしたいものです。
プロダクトのゴールやプロダクトを作る理由を確認
我々はアジャイルな状態で開発ができているかを問いかけ、今後のプロダクト作りの判断(今何をすることが価値が高いか)精度を上げていきましょう。
このような判断ができれば、膨大な要求が出たとしても、皆で、今後どの要求を取り入れるべきか選択できるようになります。
必須要求以外の要求は調整対象になりうることを伝える
アジャイルな開発といえど、通常、期間と予算には限りがあるためです。
開発スコープの広さは大枠で考えると思うのですが、中身の深さは調整対象(必須でない要求)にすることを共有しないと、トラブルの元となります。
調整の仕方の例として、データ閲覧画面がほしいという要求で、最低限、月ごと、部署ごとの○○データに絞って閲覧できるようにするのが必須要求だと決めたとします。
この要求の中で、たとえば、部署ごとのランキングを表示したい、年間のデータ件数グラフも表示したい等の要求は必須ではないので検討が必要です。
たとえば、プロダクトにとってメイン機能であれば、他の機能を削ってででも取り込むという検討結果はありです。一方で、サブ機能であれば、要求があったことは残すが、開発対象には現段階で入れないという検討結果もありだと思います。
このような検討ができるように、業務運営上ないと業務ができないもの、プロダクトをつくる価値がゼロになってしまうといった必須な要求と調整対象の要求を説明しましょう。
何でもかんでもプログラミングしない
プログラミングはコストが高いためです。
要求を多少整理し、価値が高そうだと思う機能に関して、開発を進めるのが良いと思います。
優先順位や重要度を考慮ぜず、とりあえず機能を作るのは時間がかかります。プログラムを作るだけが、アジャイルな開発ではありません。
紙芝居で業務イメージが十分にわく、また、次の開発につなげるフィードバックが得られるのであれば、プログラミングをするのではなく、紙芝居で済ませるのもありです。
もしくは、重要度が低い機能であれば、いっそのこと作らない、より重要度の高い機能を開発スコープに入れる。
プログラミングだけでなく、価値あるプロダクトを早く作る営み全般がアジャイルな開発だと考えています。
おわりに
アジャイルな開発はとても価値あるものだとおもいます。
一方で、単純な請負契約と違い、まだまだトラブルも多いはずです。
わたしもまだまだ素人です。
他にも、こんな契約形態とったらお互いうまく行ったよとか、逆に、失敗したよ というお話を聞かせていただけると幸いです。
参考サイト
以下、契約関連で参考になりそうなリンクを紹介します。
