@posauneさんのINVとESとTのポストを読んで、京アジャのレフトウイング（どっちがどっち担当だったっけ？）として勝手思ったことを書いてみる。

実際のプロダクトオーナー（PO）にINVESTとはですねーといっても必ずしも技術畑でもなければ、暇でもない（POが暇だって？！）POになかなか意識して書くことを要求するのは酷だったりする。
（書き方を気にするあまり、追加するのをためらわれたら本末転倒）

けれど、POはプロダクトへのアイデアはあふれんばかりに持っている（はずだ！）から、アイデアを思いついた時にプロダクトバックログですぐにでも関係者に共有したい。

こんなときどうすんの？

プロダクトバックログにはゾーン（Zone）という考え方がある。

気にしないゾーン

プロダクトオーナーは、アイデアレベルのプロダクトバックログアイテムを、まずは気にしないゾーンに入れておく（INVESTですらないかも）。

気にしないゾーン

荒目ゾーン

次のスプリントではないけど、近々行いたいプロダクトバックログアイテムを荒目ゾーンに移動する。
この荒目ゾーンで、INVが満たされているものがきていれば、POとTeamや関係者とのコミュニケーションが進んで、中期的にどんなことをやろうとしているのかが共有出来て、コミュニケーションがはかどる。

荒目ゾーン

詳細ゾーン

詳細ゾーンは、市場の状況が変わらなければ次のスプリントで着手するプロダクトバックログアイテムが入っているはずなので、可能ならINVESTであることが望ましい。なぜかというと、スプリントプランニングにコストをかけ過ぎたくないので。
当然、アクセプタンス・クライテリアを詳細に書かないとTestableにはならないし、スプリントプランニングでコミュニケーションコストをかけ過ぎてしまう。

詳細ゾーン

とうことで、POに優しいプロダクトバックログを作るためにはINVESTに合わせてZoneも意識してみてはいかがでしょうか？

〜スクラムを学び始めた自分へ、今伝えられるなら何を伝えたいか〜

７年前にスクラムを学び始めた自分に、今の自分がスクラムを伝えるなら何を伝えているだろうか。

契約について

スクラムで受託開発をする場合の契約は、どうすれば良いのだろうか？

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システム開発で要件定義〜基本設計；準委任契約、詳細設計〜システムテスト：請負契約となることが多い
※３インセプションデッキ自体は、スクラムのツールではないけれど、全てではないにしろ必要な物は、必ず作成したほうが良いと思う。
※４全く不確定要素のないプロジェクトなんてないとも思うけれど

〜スクラムを学び始めた自分へ、今伝えらるなら何を伝えたいか〜

７年前にスクラムを学び始めた自分に、今の自分が伝えるなら何を伝えているだろうか。

どこから手を付けたらいいのか？

７年前の自分は、スクラムを自分が参画するプロジェクトに適用しようと考えた時に、どうやって、どこから適用しようか色々と試行錯誤した結果、失敗に終わった（※１）。

今、あの時の自分に教えるなら、まず何から始めることを教えるかな。

スクラムは開発ツールの一つ。

ツールとして使用できるようになるまでには、それなりの準備が必要。

いきなり使って、すぐに上手には使えなくて当然で、まずは、次のステップをふんでチーム作りから進めたい。

Step1．

組織内で１人は、サラリーのためだけに仕事をしているのではなく、より良い物をユーザーに届けたいという思いがあるメンバーを見つけ、チームに入れること

最初のフォロワーは、自分で見つけるということ。
（有名なこの動画の様に最初のフォロワーが見つかればよいが、見つからなかったら見つけるしかない）

何がユーザーにとって本当に必要な価値であるかを話し合えるメンバーがいて、開発中に２人でそのことについて話していると、次第に他のメンバーも巻き込まれていく。
つまり、２人でどれだけちっぽけでも良いので、まずは同じ目的地に向かうバス（※２）を作ることが、重要だと思う。何も、いきなり全員バスに載せる必要はない（そういえば、いきなり全員バスに乗せようとして失敗したことも。。。）

他のメンバーが仕様書を実装するあまり、ユーザーの価値を考えて開発できなくなっているメンバーだった場合（悪い人では決してないのだけれど）、１人でどれだけ熱く語ったところで改宗してもらうための努力は、徒労に終わることが多い（手を動かすオペレーターという役割が長すぎて、そもそも価値って何？となっている人も少なくない）。
相手にとって興味が無い事へ興味を向けさせることほど、大変なことはないと思う。すくなくとも自分の場合そうだった

まさに北風と太陽で、バスに乗ってほしいのであれば、矯正するのではなくて、バスに乗って楽しそうにしているところを見せれば良い。

Step2．

１人見つけたら、一緒に社外のスクラムイベントに参加して、スクラムを最初から最後まで通して学べるワークショップに参加すること

image via “Scrum Simulation with LEGO”

スクラムの開発プロセスは、１枚の図でよく表されていることが多い。
それだけ、プロセスについての表面的な理解はそんなに難しいことではない。
でも実際にやると、

など、ただ、スクラムのプロセスにそっているといったことにはなっていないだろうか。

スクラムを実践する前によく考えていたのは、「１度でいいからスクラムで開発しているチームに参加することができれば、自分でも出来る気がする。」という思い。

そんな時は、社外のスクラム勉強会にぜひ同じチームのメンバーと参加してほしい。
そして、できれば１日でスクラム体験が出来るワークショップが良い。

など、たった１日だけのワークショップだけど学びは１プロジェクトを終えたぐらいの学びがある。
素振りと呼ぶには、十分な体験が得られる。

Step3．

そのワークショップで、スクラム開発での経験を持っている人たちと知り合い、悩みがあればいつでも相談出来る場を見つけること

jonevans94 via flickr

スクラムはスポーツと同じで熟練度によって楽しみも辛さも学びも異なると思う。

だから、スクラムは学び続ける必要があるし、仮に１つのプロジェクトで上手く行ったからといって、次のプロジェクトでも上手くいくという保証はない（上手くいかなかったのならなおさら）。
要は、いかにしてチームで早く基礎になる部分を体得して、そこからさらに楽しめるようになるか。
一度楽しめるようになったらどんどん価値を生み出すことが出来て、どんどん楽しくなっていくと思う。

 躓いてしまった自分へ

この先長く続くプロジェクトを一人で生き残るのは結構きついと思う（納品後のプレッシャーとかは、実際きつかった）。

でも、

などということももちろん、あると思う。

そんな時は、思い切って社外の勉強会に参加している人を、自分のチームに参加してもらうことも考えてみてはどうだろうか。
権限がないかもしれないけれど、上司だって優秀な人材を探しているし、SIerの場合、大抵職務経歴書をみただけで、雇うかどうか決めなければいけないわけだから、自分の部下が積極的に優秀な人を連れてきてくれることは、上司にとっても嬉しいことではないだろうか。

また、上司に頼んで派遣の方の面接に一緒に参加させてもらい、自分で直接チームに加わる派遣の方を採用するという方法はどうだろう。
スクラムはチームの文化をすごく重要視していると思う。
技術は教えられたとしても、考え方や感じ方が異なる人とチームを組むことはすごく難しい。

であれば、面接に一緒に参加させてもらい、自らチームのメンバーとなる同じ文化の人を採用してみるのも手段の一つだと思う。

これで、７年前の自分が一歩踏み出せるかは、甚だ疑問だけれど。

※１　ここでの失敗は、スクラムのプロセスにのっとった開発すらできなかった
※２　アジャイルサムライの第３章「みんなをバスに乗せる」に因んで
※３　チームが自発的に改善に取り組んでおらず、”時間が来たから”、”支持されたから”スクラムを行っている状態をスクラムごっこと言ってみました。