スクラムを学ぶ

初めに

スクラムやろう！

という話が本格化してきたので、改めて、何をやりたいんだっけというのを考えたり、自分が疑問に感じていることを洗い出したりしてみました。

注意：具体的なスクラムの手法についてはここでは言及しないので、気になる方は無料のスクラムガイドや他の本を参照してみてください。

スクラムについてふりかえってみる

- アジャイルについて

アジャイルとスクラムを似たようなものとして捉えていたのですが、

• アジャイル = 「概念」
• スクラム = 「手法」

というのが説明として正しいようです。（抽象クラスと具象クラス的な…）

アジャイルの説明は、もっと正確なものが世の中にたくさんあると思うのですが、私はIT開発のつらみである「あとから仕様がどうせ変わる」に対応したものだと考えています。

ウォーターフォールは、フェーズが「仕様策定」 ->「設計」->「開発」->「UT」->「IT」->「ST」->「リリース」と分かれています。これが、当初の仕様や設計と1ミリも違わず最後まで行けたら問題なさそうですが、UT、IT、STまで来て、「やっぱり変えたい」「これじゃない」「設計が間違っている」となった場合、スケジュールは大幅に遅延することになります。そして、それは、後の工程になればなるほど痛みは大きく、戻る歩数も多い。

それは、正しい仕様/設計ができないのが悪い、となりそうですが、実は 「正しい」仕様をやる前から分かる人はほとんどいない のではないでしょうか。なので、外部の変化やユーザの声、そういうものを受けて変化していく仕様の方が実は「普通」であると捉えれば、それに対応すべき開発手法が生まれて然りで、アジャイルはそれに対応したものだと思っています。

- スクラムを自分たちがする意味

スクラムを導入する意味について考えました。

• PM さんやビジネスサイドからの声を受けやすくなる

  • スプリントに一回、スプリントレビューという検査の工程が挟まれます。これにより、意図していなかった実装があとになって気づかれることを避けたり、声を反映しやすくなります。

• ユーザからの声を受けやすくなる

  • これまでは、例えば6ヶ月間プロジェクトが走っている間、他にやりたいことがうまれたとしても、それを止めることはできなかったと思います。しかし、スクラムではスプリント単位でプロダクトオーナーの意向が反映できるので、途中で優先事項の高い開発が生まれた際には、そちらを優先することができる様になります。
  • また、新機能を小さくリリースして、ユーザの声を受けて改善していく、ということがしやすくなります。機能が求められているかはリリースしてみないとわからない部分があるので、よりユーザの声を即時に反映しやすくなります。

• 作業の待ち時間が減るので、リリースまでの期間が短くなる

  • 機能横断的なチームになることによって、人の手待ちではなく、「作業の手待ち」が減ることになると思われます。

- 印象的な「作業の手待ち」の話

エッセンシャルスクラムという本を読んでいて印象的だったのは、スクラムは「作業の手待ち」が減らせるという話です。

「作業の手待ち」とは、そのまま作業の待機時間と考えてよく、通常はよく「作業者の手待ち」（作業者がタスクを持っていない状態）を減らそうとしますが、スクラムでは「作業の手待ち」を減らそうとします。作業の手待ちをへらすことのメリットはなにかというと、リリースへのリードタイムが減ります。

わかりやすい例としてリレーが上げられており、リレーのバトンが作業であり、リレーの走者が作業者と捉えた場合、リレーの走者はバトンが渡されるまで待機しているので作業者の手待ちは多いですが、バトンが最速で渡されれば「作業側の手待ち」はほぼないことになるので、最速でゴールに到達できます。このリレーで「作業者の手待ち」を減らそうとしたときには、走者は待機中にあちこちを走り回る…ということになると思いますが、それでは、最速でゴールに到達するという目的を達成できません。

スクラムでは、機能横断的なチームによって作業の手待ちをへらすことができます。

- それらは理想であり、そんなにうまくはいかないのでは？

過去にスクラムの話をしたとき、スクラムの目指すものが、今の仕組みとうまく噛み合っていかないのでは？と思ったことがあります。

我々は予め決められたプロジェクトを遂行していくことを求められているのに、そこに変化や自律性を持ち込む余地はあるのか？ということを、色んな人が不安や疑問に感じているように思います。また、開発チームとしても、機能横断的で自律的なチームを作ったとて、自分たちに裁量がなければ、特に活かすことはできない無力感を得てしまうだろうな、と思います。

これについて、いろいろ考えたのですが、今の所結局できるときにできることをやっていくしかないのかな、と思っています。めちゃくちゃ現実的なラインとしては、プロジェクトは年がら年中やっているわけではないので、隙間に自分たちのやりたいことをやるなど…

それが成果を上げられたらもう少し話が変わるかもしれない、という思いと、あとは、わたしはステークホルダーをすべて把握しているわけではないので、実際の我々を取り巻く環境をもう少し詳しく知ってから考えてみたいと思っています。

いずれにしろ、私はプロダクトに良くなってほしいと思っていて、それに対して最大限に効果を出せそうなスクラムという手法をやってみたいと思っています。

具体的にやろうと思ったら困りそうなところ

自分の運用上の疑問を書き連ねてみます。

- プロダクトバックログの整理はいつやるのか

バックロググルーミングとか、バックログリファインメントと呼ばれるイベント時に行います。
プロダクトバックログのアイテムの作成と改良、見積もり、優先順位付けを行います。

- 本当にざっくりでいいから今後のタスクについて見積もりがしたい

ポートフォリオバックログというエピックを集めたバックログが、場合によっては作成され、
それらに対してはS, M, LのようなTシャツのようなサイズ感で予め見積もっておくとよいようです。

- エピックとは

epic 自体は「大作」という意味らしく、大きいサイズ感のユーザストーリーのことらしい。

- ジャストインタイムについて

ジャストインタイムとはいうけど、先に仕様は全体的に決めて共有したいし、プロジェクトのリリース日の目安も知りたい

ジャストインタイムという言葉の解釈で、全部スプリント開始直前にやるのかなと思っていたのですが、全部を直前にやるわけではなく、ただアイテムがスプリントバックログに入る直前まで仕様が変更可能である、ということのようです。

- 出荷可能なプロダクトってなにか、スプリント単位でリリースするってこと？

よくスプリントレビューで、「出荷可能なプロダクト」を検証すると書かれていて、ずっと毎スプリントリリースすることだと勘違いしていたのですが、あくまで「可能」なプロダクトであって出荷は別のフェーズでもよいようです。

- スプリントレビューまでに終わらなかったら、そのスプリントって中止？

いくつか本を読んだのですが…とりあえず、できたところまで見せるという形になりそうです。

• 「スプリントゴールは動かさないとは言ったが、その機能がスプリントゴールに含まれるとはいっていない」

  • 商品一覧を作成する」というゴールだったときに、一覧表示機能と検索機能を期待していたが、検索機能のみスコープアウトするなど、一部をゴールの対象から除外する

• できたところまでをスプリントレビューに提出する

  • 上と似ていますが、うまくいかなくてもなお見てもらうことで、次の反省に活かす

- 割り込みのタスクがどうしても生まれるんですが、スプリントゴールって変えてはいけない？

割り込みのタスクは基本的にはスクラムとはマッチしない考えのようです。

プロダクトバックログの優先順位が絶えず変わる場合、イテレーションの見積もりがしづらくなるためです。本当に頻繁に入れ替わる場合、同じアジャイルでも、「カンバン方式」のほうが管理としてはよいようです。

スクラムで割り込みのタスクが発生した場合、急ぎではない場合は次のスプリントに変更するのがよさそうに思えます。どうしてもすぐやらなければいけないことも中にはあると思うので、その場合は割り込ませた上で、できたところまでをスプリントレビューで出すということになりそうかなと思いました。

- なぜ職能横断的なチームが推奨されるのか

誰かのタスクが終わらなかった場合、Aさんは終わったけどBさんは終わらなかったので、スプリントゴール未達成とするのではなく、終わらなかった人に極力協力していくのがスクラムでは推奨されています。それが、自分の専門外であってもです。協力を考える時、スクラムが推奨する少人数のチームが長く継続するのはかなり効率が良いように思います。

一方で、職能横断的なチームが推奨されている理由についてなぜなのか調べてみたのですが、スキル的、観点的な多様性がスクラム内で問題を解決するスピードを速めるからのようです。スクラムチームにとってはそのスプリントにスプリントゴールを達成するのが目的ですが、たとえば外部チームにそれが依存していると達成できない可能性が高まるように思います。

終わりに

本を読んでいて、スクラムってなぜこうなんだろう、に対する答えが結構見つからないことがあって、自分なりにこうなのでは？と考えた結果も含め、書いてみました。

誤っている部分などあれば、指摘がもらえると嬉しいです。