迷いやすいポイントや議論になりやすい話題を中心に、うまくまわすためのアプローチをまとめました。ある程度スクラムを知ってる人、やったことがある人向けの記事です。
用語の整理と現場への適用
スクラムの用語をそのまま適用しても現場に馴染みにくい場合があります。そういう場合は用語を馴染みやすいワードに置き換えます。 メンバーのチームに対する親しみやすさのような感覚は士気に影響するので、結構重要です。
例えばプロダクトバックログ、またはプロダクト。 特にプロダクトらしいプロダクトが一見するとないようなチームの場合は特に違和感を覚えると思います。 そういった場合は、プロダクトという単語をエピックやマイルストーンといったワードに置き換えると適用しやすくなります。 ようするに”メンバーの個々のタスク＝スプリントバックログアイテム”に対する、”１レイヤー上の親課題”のことだと捉えれられれば良いです。
RetrospectiveやAcceptanceCriteriaも普通はあまり聞かない単語だと思います。 “振り返り”や”受け入れ条件”といった言葉に和訳したり置き換えれば良いと思います。
スプリントバックログアイテムも、チケット・タスク・イシューなど、チームが使っているツール（BTS）上での単位の名前に置き換えて呼ぶことが多いです。
WorkingAgreementを作る
WorkingAgreementは、チームでワークするときの約束事を書いたものです。
まず最初にこれを作っておきます。これがないと議論が発散しやすくなるので、真っ先に作ったほうが良いです。
最初からしっかりしたものを書く必要はありませんが、最低限以下のような文言だけは、入れます。
- チームのルールについて何か決めるときは、チームメンバー全員の合意を得て、その旨をWorkingAgreementに記載すること
- チームメンバー全員がWorkingAgreementに記載の内容に従うこと
- WorkingAgreementの編集はチームメンバー全員が合意した上で行うこと
原則として”チームメンバー全員の合意”を前提とすることで、チームの動きに透明性が生まれます。ときに議論が活発になることもありますが、ここがぶれないことが重要です。
また注意点として、多数決での合意形成は避けるべきです。その場は良くても長期的にみて派閥や対立が生まれやすくなります。 全員が合意できる形にまで意見を出し合うことです。疲れますが、続けていけば必ずチームが同じ方向を向くようになっていくはずです。 どうしても意見が分かれる場合はチームを分割したほうが良いかも知れません。
なお上記以外に特段書くことがない場合には、とりあえず以下を入れておくと良いでしょう。
- 所属組織の勤怠ルール等
- セレモニーの開始日時
- 用語集
イテレーションの長さの決め方
以下の質問に従ってチームで決めます。
- そろそろチーム全体での振り返りの場を設けないと不安だ…と感じる日数はどれくらいか
あるいはスクラム導入前でもチームメンバーの過半数が集まって状況確認を行う会議などが既にある場合には、それに合わせると良いと思います。 ただし定期的な会議体だけでなく不定期的な会議体も対象に含まれます。 自分のタスクはチーム内で合意を取れているタスクだという実感の薄れ、あるいはチームメンバーが個人で処理できる範囲を超えた不確実性を持つタスクの発生を、その状況が示しているからです。
つまりイテレーションの長さは、不確実性がどれくらいの量・頻度で発生するかによって決めます。ビジネス上・組織上の制約や慣習で決めるものではありません。
ちなみに割り込みや急な依頼など不確実性の高いタスクが多いチームは、（特に最初は）イテレーションを１週間にしておくのが無難です。 その分振り返りとプランニングを毎週行うことになり疲れますが、不確実性は着実に減らしていけます。 不確実性が減り、日々のデイリースクラム＋αの話し合いで十分合意を取れるほど落ち着いてきたら、イテレーションを２週間に伸ばしてみても良いと思います。
ストーリーポイントについて
議論の紛糾のしやすさでおそらく１，２を争うテーマです。チームによっては定期的に再議論されたりします。 感覚的な規模であったり時間のまとまりであったり機能の複雑さ・大きさであったりいろいろな解釈があるかと思いますが、 結局のところ、作業にかかる任意の時間間隔を単位とする現場が大半だと思います。
私はそれで問題ないと思っています。本当の問題はプロダクトのフィーチャーを作りリリースすることなので、ちゃんとリリースできるならポイントの値や単位は些末なことだと思います。
私の経験した実際の現場では、およそ１ポイント＝30分～２時間くらいの間で、チームの合意が取れていました。
なお前述の通り、見積もりはあまり重要な要素ではないですが、それでも気をつけることはいくつかあります。
- ストーリーポイントの最高値を決めておくこと
- ストーリーポイントの最高値が最大で2日かかる作業ボリュームと等しくなるように定義すること
ようするに”2日以上かかる時点でタスクを分解しましょう”という意図がチームに伝わっていれば良いです。 ストーリーポイントにはフィボナッチ数列を採用することが多いと思いますが、 1,3,5,8,13,21,34…という感じなので、そのままでは若干使いにくいかも知れません。その場合は適宜適当な偶数を追加します。
また余談ですが、ストーリーポイントの単位とは別に、組織が一般企業である場合、１日のうちタスクに割り当てられる時間は８時間…ではなく６時間としておくと見積もり精度が上がりやすいです。 スクラムをやっていると割り込みがなかったとしてもチームと活発に議論をすることになり、そしてその時間は手が止まることになります。そうでなくても組織全体の行事やイベント事などもあると思います。そのため、あらかじめ見積もりの段階でそれらの分を見越して、削っておきます。
これは見積もりのバッファとは異なる点に注意です。なお、見積もり時にバッファを設けることは推奨しません。それはタスクの不確実性の解明を後回しにしていることと同義だからです。
個別のセレモニーについて
私自身の復習も兼ねて一応各セレモニーについても言及してみました。
なお各セレモニーの名前も、チームにとって馴染む名前に変えると良いと思います。
デイリースクラム
基本毎日同じ時間に開催します。各メンバーが 1.昨日までにやったこと（進捗）、2.今日やること（タスク）、3.困っていること（障害）を発表します。全体で15分以内に終わるようにできるとスピード感が感じられて良いです。 デイリースクラムの場では議論をしないことがポイントです。議論をするのならばデイリースクラムのあとに行い、また議論に必要なメンバーのみを招集します。
１日に２回デイリースクラムをやることはあまりおすすめできません、時間の無駄だと感じやすいです。疑問点や聴きたいことがあるなら適宜必要なメンバーで集まるか個別に直接聞きに行きます。
なお私はデイリースタンドアップと呼ぶことが多いです。チームによっては、開催する時刻によって朝会・昼会・夕会と呼んだりもします。
プロダクトバックログリファインメント
１回あたり１時間前後かけてやるか、細切れに時間を作り、やります。スプリント中何回やっても良いです。 １人では決められない場合は関係者に時間を作ってもらうか直接聞きに行くなど、情報収集を適宜行います。 優先順位を変更したり、プロダクトバックログアイテムの粒度を調整したり、AcceptanceCriteriaを調整したりします。
余談ですが、デイリースクラムで議論が発生しそうになった場合にメンバー同士でいわゆる”スプリントバックログリファインメント”を行う場合があります。
それが発生しないようにするためにスプリントプランニングをするのであり、スクラム的にもおそらくあまり推奨されないことと思いますが、そのタスク取り組んでみて初めて明らかになった事案が発生…みたいなケースが実際の現場には結構あるため、個人的には許容しています。
不確実な要素について議論しチームで合意形成できた、という実績を積み重ねていくことが重要だと思うためです。
スプリントレビュー
評価対象はプロダクトやその仕上がりを計測するKPIです。 KPIといった形で数値化・定量化が出来ていると望ましいです。
スプリントレトロスペクティブ
今回のスプリントの良し悪しや、個人のタスクやチームのワークプロセス、ツールなどについて振り返ります。 なので、評価対象はプロダクトやKPIではなく、チームやメンバー、プロセスなどになります。スキームとしては、KPT（Keep/Problem/Try）を使う現場が多いようです。
スプリントプランニング
プロダクトバックログの優先順位に従い、優先順位順にタスク化していきます。 タスクに関する不明点や疑問点がある場合はこの場ですべて解消しておくことが望ましいとされています。
タスクを作ったあとの未着手の状態に対してOpen（またはIcebox）とReady（またはIceboxに対するOpen）で二段階に分けることもあります。 この場合、不確実な要素がなくなった状態をReady、つまりすぐにでも作業に入れるタスク、と表現します。例えば、Openで切った1つのタスクについて、調査や議論をするうちに2つ以上のReadyタスクに変化するといったようなケースです。
各タスクの見積もりについては前述の”ストーリーポイントについて”の項目のとおりです。
おわりに
スクラム導入についてまとめてみました。
みなさんはどのようにしてスクラムを活用されていますか。 スクラムについての好き嫌いもあるかと思いますし、議論が激しくなってくるとそれはそれで結構疲弊もしますが…。 うまくワークしている時は一体感や集中力がもたらされて、結構心地よいものです。 コツやアンチパターンなどご存知でしたら、どこかで教えてもらえると嬉しいです。