インクリメントってどんなもの？　できない時はどうすればいい？ ─ ”とはいえ”シリーズ #12「インクリメント編」（前編）

“とはいえ”シリーズは、スクラムに取り組む現場で起こる様々な「とはいえ」をピックアップし、それぞれどのようにアプローチしていけばいいのか、レッドジャーニーの経験豊富なアジャイルコーチがざっくばらんに語るシリーズです。

「スクラムガイドにはこう書いてあるし、ブログではこういう事例を見かけるんだけど、とはいえ…」と困ってしまったり、チームで対話しても道筋が見えてこない時、ここでのお話が何か一つでもヒントになれば幸いです。

第12回のテーマは「インクリメント」です。前編では、インクリメントという概念の捉え方や、インクリメントができないときの対処法などについてお話します。

「インクリメント」ではなく、もっとチームに馴染む言葉で言い換えてもいい？

中村：
まずは、スクラムガイドの該当部分を一緒に読んでみましょうか。
今回は「踏み石」というメタファーが冒頭から登場していて、おもしろいですね。

「スプリントでは、複数のインクリメントを作成可能である」「スプリントレビューのことを価値をリリースするための関門と見なすべきではない」など、実際の現場でよくある状況について書かれていますよね。

新井：
「スプリント終了前にインクリメントをステークホルダーにデリバリーする可能性もある」というところも、そうですね。

中村：
「完成の定義」はスクラムガイドの最後に出てくるので、見逃されやすいのですが、取り組みの初期から取り組んで行く必要のある要素だと思います。

新井：
何をもって完成したのかという認識は人によって異なるので、食い違いが起こりやすいですよね。

また、「インクリメント」という言葉は、非エンジニアの方には伝わりづらい表現だと思います。

成果物でもないし、アウトプットでもないし、プロダクトでもないし…とはいえ、異なる表現にするとスクラムガイドのニュアンスから外れてしまうのではないか、と思う方もいらっしゃるかもしれません。

実際に、「インクリメント」という言葉が浸透しているチームと、そうじゃないチームがあるのではないでしょうか。

中村：
私がアジャイルコーチとして支援するときには、自分たちが共通認識として分かる言葉だったら、別の呼び方でも全然いいとお伝えしています。

新井：
そうですね。意味合いがスクラムガイドから外れていなければ、チーム独自の言葉を使ってもいいと私も思います。

具体的には、どんな言葉を使っているでしょうか？

中村：
プロダクトづくりをしているチームなら、「プロダクトに対する変化」という表現をよく使っています。

機能が増えるとか、体験できることが増えるとか、まれに機能をなくす場合もあるので「変化」です。

新井：
なるほど。プラスされるだけじゃないから、「変化」なんですね。

中村：
そういう変化そのものをインクリメントと呼び変えてもいいんじゃないかな。

新井：
減らすことって、なかなか勇気がいるじゃないですか。
機能を減らすのは価値を減らすようでもったいないと思ってしまったり。

でも、それがユーザーにとってメリットを生まないのであれば、カットしていくのはいいことですよね。

参加者コメント：
「進化」はどうでしょうか？

中村：
進化、いいですね。

参加者コメント：
完成の定義は、プロダクトバックログに対応するものですか？
プロダクトバックログに対応するのは「受け入れ基準」で、完成の定義はインクリメントに対応するものと理解していました。

中村：
完成の定義を満たしたときにインクリメントが誕生するので、完成の定義はインクリメントに対応するものですね。

新井：
スクラムガイドの「スクラムの作成物」の項目にも「インクリメントのための完成の定義」とあります。

それで言うと、プロダクトバックログに対応するのはプロダクトゴール、プロダクトバックログアイテムに対応するのは、受け入れ基準ということになるかな。

新しくできた機能、既存の機能、全体としての機能、すべてインクリメントと呼ぶのはなぜ？

中村：
あるスプリントが始まる前までにつくられて、すでに存在しているサービスやプロダクトもインクリメントですし、そのスプリントで新たにつくられた体験や機能の変化もインクリメントと呼びます。

さらに、それらを合わせた全体のこともインクリメントと呼ぶんですよね。

ややこしいですよね（笑）。皆さん、混乱しがちなところです。

新井：
インクリメントの前に「今回のスプリントでつくられた」「これまでにつくられた」「全体としての」と付け加えないと、区別ができなくて混乱しますよね。

中村：
継続的な品質が担保できて全体として動いているのか、ということをあらためて言っているのかなと思います。

そのスプリントで新しくできた機能が、ちゃんと動いたり、完成の定義を満たしていたりすることは当然必要なのですが、それだけじゃなくて、全体としてもちゃんと動く必要がある。

新しい機能ができたけど、今までのものと合わせると動かなくなるというのではダメなわけです。

新井：
全体を統合したときに、きちんとデリバリーできる状態まで検査が済んでいることが必要ということですね。

参加者コメント：
単純に「アウトプット」と考えたら良いですか？

中村：
プロダクトづくりの文脈なら「アウトプット」なのかな。

「単純に」というところがちょっと気になるけど…先程お話したような、プロダクトや機能の変化という感じが分かりやすいかな。

新井：
スクラムガイドには「価値を提供するには、インクリメントを利用可能にしなければならない」とあります。

インクリメントには価値を提供するために利用可能であるという意味合いがあるので、やはり単なるアウトプットとは違うんじゃないかな。

価値につながっていないとしたら、半分しかできあがっていないというか…。

中村：
最低でも完成されている、つまり完成の定義を満たしているということですよね。

参加者コメント：
「アウトプット」だと、ドキュメント作成なども含まれてしまう気がします。
動くソフトウェアが対象だと理解していますが、合っているでしょうか？

中村：
その通りですね。例えば仮説検証のプロジェクトだとまた話は変わってくるので、ちょっと歯切れの悪い言い方になってしまっていますけど、基本的にプロダクトづくりをしているスクラムチームであれば、インクリメントは多くの場合、プロダクトの変化そのものになることが多いと思います。

ドキュメント作成はアウトプットではありますが、インクリメントとはあまり呼ばないんじゃないかな。

新井：
たしかに、要素の一つではあるけど、インクリメントとはちょっと違うかな。

参加者コメント：
ユーザーやステークホルダーにとって価値があれば、ドキュメントもインクリメントに含まれると理解しています。

中村：
そのドキュメントが中間成果物であれば、インクリメントとは違うということかな。

皆さんが取り扱っているプロダクトや、チームの置かれた環境によって違いますので、最終的には自分たちで決めればいいと思います。

新井：
中間成果物が価値を生むこともあるでしょうし、生まない場合もあると思うのですが、いずれにしても思考停止状態で、とりあえずつくるようなことは良くないですね。

「決まりだからつくっている感じになっていないか？」「ちゃんと価値を生んでいるのか？」と、自分たちでメスを入れていって、時間をかけてつくる価値があるかどうかをチームで議論してほしいです。

中村：
「このドキュメントがなかったら何が起こるの？」と問いかけてみるといいですね。

誰も答えが分からないのであれば、一旦つくらずにやってみる。それでうまくつくれたなら、短期的には必要性がないという可能性が高いですよね。コーチとして支援していると、そういう実験を促すことがよくあります。

新井：
いいですね。そういうときって、大体なくなっても困らないんですよね（笑）。
勇気を持って実験してみてほしいです。