プロダクト作りの在り方を探るコラム第3回 |プロダクト作りを「誤り許容期間」の考え方で捉える 市谷聡啓

アジャイルに取り組む際に必ず決めることがあります。それはスプリント（イテレーション、反復期間）の長さです。もちろん他にも多くの確認したいこと、決めたいことがありますが、スプリントの長さを合意しなければ、そもそもゲームを始めることも、終えることもできません。「スプリントの長さ？そんなの1週間と決まっているでしょ」と思われる方もいるかもしれません。結論はそうなるかもしれません。ですが、スプリントの長さを決めるというのは実は大事な意思決定の一つです。何を決めていることになるのか、考えてみましょう。

スプリントで何を得ているのか

もし、スプリントの長さを決めていなかったら何が起こるか想像してみましょう。もちろん、開発に区切りがなくなりますね。何が困るでしょう？　作成物の確認（成果の確認）、それを踏まえたプロダクトの方向性についての意思決定、さらに次に向けた計画作りといったリズムが作れなくなりますね（こうしたリズムに重要性を感じなかったら、反復的な開発スタイルを取るべきなのか考え直した方が良いでしょう）。

このとき失われるものは何か。「フィードバック」ですね。チームの活動、成果についてのフィードバックを得る機会がなくなります。もちろん、フィードバック自体はスプリント毎の決められたセレモニーの場に限らず、実際には日常の中で生まれるはずです（そうあることを意識すべきです）。
　ですが、定期的に成果を確認するタイミングを設置する意味とは、意識が高いか低いか、忙しいかそうでもないかに限らない、「チームでフィードバックを獲得し方向性を見直す」という約束になるわけです。人の意思に依らず運用できる仕組み化は、チーム活動を支える重要な考え方です（もちろん仕組みも陳腐化することがあるので、見直しは必要です）。

ということで、スプリントの長さとはフィードバックを受け止めるまでの距離となるわけです。この距離をどう捉えるかで、スプリントの長さを具体的に決めることができます。多くの場合、スプリントの長さは1週間か、2週間の選択となるでしょう。どのようなときにどちらを選択するか、理解しておきましょう。

1週間スプリント or 2週間スプリント

フィードバックを得るためには対象となるアウトプットが必要ですね。アウトプットを作るのに時間がかかるような状況、例えば以下のような場合はスプリントを長めに取る必要があります。

それぞれの課題に対して根本的な解決は別途必要ですが、その対処自体にどうしても時間がかかるようであれば、スプリントの長さでの適応が一つの作戦となります。

2週間スプリントは選択肢としてはあって良いものですが、実際のところ長さを短くする方向に向かっていきたいところです。なぜなら、「フィードバックを受け止めるまでの距離」が長いということは、それだけ「間違っている期間」が長いとも言えるからです。つまり、スプリントの長さとは「作っているものが間違っている可能性を許容する（できる）期間」と言い換えることができます。
　もちろん、間違ったもの（不要なもの、認識が違うもの、価値がないもの）を作り込み続ける期間が長いほど、プロダクトは負債を抱えることになります。後になって、間違いに気づいたとき返済する（直す）必要がありますね。間違いの上に間違いを重ねていくほど、後で正すのに苦労します。ですから、こうした「方向性の負債」は早めに返しておきたいわけです。このように捉えると、スプリントの長さ一つ決めるのにも、丁寧に考える必要が出てきます。
（踏まえると、スプリントの長さ以外の作戦としては、そもそも間違いの発生を抑える「ペアプロ／ワーク、モブプロ／ワーク」が有効となるわけです）

「間違っている期間」を短くするための作戦

具体的には以下のような状況の場合、スプリントを短くしたいところです。

・はじめて一緒に開発するチーム、結成したばかりのチーム

お互いの間合いがつかめてない為、誤謬が生まれやすい。どのようなやり方、同期の取り方、情報粒度が望ましいのか把握するために、間隔を短くする。

・開発難易度の高いプロダクトを相手にしている

そもそも機能を作り上げること自体が難しく、チーム内での協働度合いを高める必要がある。同期間隔を短めにする。

・お互いの状況が見えにくい働き方としている

例えば、リモートワークだったり、別拠点の開発メンバーがいたりする状況。物理的な距離感から状況把握がしずらいため、時間間隔の方で適応する。

「間違っている期間を短くする」という考え方は、広く捉えていくとスプリントの長さに限った話ではありません。チーム活動の原則として捉える方が良いでしょう。間違っている期間を短くするために、

• 設計やコードのレビュー間隔を短くする
• 一緒に仕事をする時間を増やす（ペア／モブ／合宿）
• ユーザーテストの間隔を決めておく

といった工夫をあわせて考え、運用していくのが望ましいでしょう。
これで、「ふりかえりが実施できない」、「スプリントレビューにプロダクトオーナーが参画していない」といったことがなぜ問題なのかも説明することができますね。ふりかえりを実施していないということは、その期間の長さ分だけ「イケていない仕事のやり方をしている」わけですし、その分「いまひとつな結果を許容する」という状況を自分たちで作っているに他ならないわけです。スプリントレビューにプロダクトオーナーが参画していない期間は、その長さの分だけ「認識の違うものを作っている（可能性がある）期間」を許容していることになります。

最後に。ここでは「許容」という言葉はあえて使っています。つまり、「許容できるならそれでも良い」という選択を残しています。開発の現場では、原則論だけでは割り切れない状況を迎えることが多々あります。その時点その時点で、何はどこまで許容できるのか、どこから先は許容できないのか。この見立てと意思決定のバランスはとても大切です。こうした判断こそ、組織をリードしたりマネージする人には求められると言えるでしょう。