〜スクラムを学び始めた自分へ、今伝えられるなら何を伝えたいか〜
７年前にスクラムを学び始めた自分に、今の自分がスクラムを伝えるなら何を伝えているだろうか。
契約について
スクラムで受託開発をする場合の契約は、どうすれば良いのだろうか？
NobMouse via flickr
最近では、IPAが非ウォーターフォール型開発時の契約書を公開している
http://www.ipa.go.jp/sec/softwareengineering/reports/20120326.html
他にも、@kdmsnrさんが翻訳してくださっている「次のアジャイルソフトウェアプロジェクトに使える１０の契約」もすごく参考になる。
http://capsctrl.que.jp/kdmsnr/wiki/transl/?10-agile-contracts
ただ、実際のところ受託開発で下請け側の意向で契約形態の変更は、かなりハードルが高い。
大抵は、会社全体で同じ契約書を使用しており、それをプロジェクトに依存する箇所（※１）のみ変更して契約している場合が多いと思う。
では、契約方法が変更できないからスクラムでの開発は出来ないのかというと、案外そうでもない。プロジェクトのコンテキスト（※２）に依存するところは多分にあると思うけれど、
「契約が変えられない＝スクラムを導入できない」
では、思考停止してしまう（実際そう思っていた時もあって、プラクティスに走ったりもしたけれど。。。）
では、どうすれば良いのだろうか？
何も変えないという方法
実際のプロジェクトで契約しているのは、納品日と金額と納品する成果物だけであって、どのストーリーを実現するかを契約書に記載しているわけではない（あくまで自分の場合はだけれど）。
ということは、決められた金額、納期、成果物を満たしつつ、よりユーザーにとって価値のあるストーリーからプロダクトを作り、その都度フィードバックをもらい、大きな変更については他のストーリーとの優先順位をつけてもらい、今回の開発から外して、次回の改定に回してもらうなどの交渉を行いながらやっていく。
実際ユーザーもプロジェクトのかなり早い段階で、プロダクトに触れる事ができるため、真剣にプロダクトを触りながら、優先順位やフィードバックを出してくれる。
（見慣れないExcelファイルに書かれた図と小さい文字をみて内容に承認を求められ、その結果、数カ月後に作りましたと初めて見せられた時には既に修正するには手遅れなどという状況にはなりにくい）
実行するにはいくつか注意点も
受託開発をスクラムで行うには、READYになっておく必要があり、これらもそのための準備だと言える。
- ”要件定義”から参加するプロジェクトであること
要件定義の段階から、ユーザー、発注側とスクラム開発に向けた準備を進める必要がある（あくまで、スクラムの準備だと考えているのは開発チームだけ）。
主に、インセプションデッキ（※３）を使用してその準備を行っている。
ただし、インセプションデッキは、要件定義〜基本設計の間に作成してこそ本来のパワーを発揮するツールだと思う。
詳細設計からスクラム開発を行うと、かなりの部分で交渉の余地がなくなっているため、その段階でインセプションデッキを作成しても、現状の把握には利用できるが、交渉の余地があまり残っていない分、その効果も低い。
- 発注側に、開発途中のプロダクトをユーザーに見せて確認する旨を伝え、了承を得ていること
事前に発注側に
「今回のプロジェクトは不確定要素が多いため、リスクヘッジを兼ねてプロジェクトの早い段階からユーザーに単体テストが完了しているプロダクトをお見せしてフィードバックをもらいたい」（※４）
と正直にお伝えすること。
決して、スクラムを使用して開発しますなんていう必要はない（言うことで、逆に抵抗にあうことだってありうる）。
リスクヘッジについて考えてくれているということで、好意的に取られる可能性もある。
契約も標準もリスクを管理（or回避）するための手段だと思う。
それを考えた人たちには、すごく意味のあるものだけれど、その恩恵を受けるところからしか関わったことのない人たち（自分も含め）には、なぜ契約と標準があるのかもセットで伝承しないと、その有り難みも弊害も理解できない。
スクラムを使った開発を行うということがきっかけで、この辺りに疑問が持てるようになったことも、すごく学びにつながった。
次は、インセプションデッキかな。
※１契約名、金額、納期、納品物など
※２業務系のWebシステム開発で要件定義〜基本設計；準委任契約、詳細設計〜システムテスト：請負契約となることが多い
※３インセプションデッキ自体は、スクラムのツールではないけれど、全てではないにしろ必要な物は、必ず作成したほうが良いと思う。
※４全く不確定要素のないプロジェクトなんてないとも思うけれど