個人的スクラム論

スクラムって難しいですよね。

数自体は多くないですが、いくつかの現場でスクラムや、スクラムっぽいものを経験してきました。

また、いろんな人にスクラムに関する考え方を聞いてきましたが。

まず個人的に感じることとして、やっぱりスクラムって難しいよなーと。

「うちはスクラムを導入してます！」と言われた際に「どれくらい本来のスクラムに沿って進められていますか？」と聞き返したところ、「スプリントを導入してます！」と返されるケースって少なくなかったりします。

つまり、その方にとって『スプリントの導入＝スクラムの導入』って意識みたいで、いやいやそれはちょっと早計過ぎないか？と心のうちで突っ込まざるを得ないのですが。

その他にも「バックログは導入してますが、プロダクトバックログとスプリントバックログは分かれていません！」とか「プロダクトオーナーもスクラムマスターもステークホルダーも決まっていません！」とか「スプリントレビューはやってません！」とかもよく耳にします。

が、もしあなたの現場が仮にそのような状態であれば、残念ながらそれはスクラムと呼べるものではないのかなと。

では、逆に何を満たしたらスクラムなのか。

スクラムには以下の通り、最低限のルールセットが定まっています。

5 つのイベント

• スプリント
• スプリントプランニング
• デイリースクラム
• スプリントレビュー
• スプリントレトロスペクティブ

3 つのロール

• プロダクトオーナー（PO）
• 開発チーム
• スクラムマスター

3 つの作成物

• プロダクトバックログ
• スプリントバックログ
• インクリメント

ここにチーム外のロールのステークホルダーを合わせてはじめてスクラムが成り立っていると言えるわけで。

このルールセットすら守られていない状態で、一体何がスクラムなのか、果たして疑問に感じるところは強いです。

仮に上記のルールセットに則って進めている場合でも、それでもうまくいかないときはうまくいきません。

ではどういうケースでうまくいかないのか、個人的な経験からいくつか例を挙げてみようと思います。

プロダクトバックログがうまく洗い出せない

経験上、1 番難しいのかなーと感じるのがプロダクトバックログの洗い出しです。

プロダクトバックログの洗い出しがなぜ難しいのか、それは現時点におけるプロダクトのゴールが定まっていないがゆえ、洗い出しが厳しいケースは多いような気がします。

で、プロダクトバックログの洗い出しって、個人的にはプロダクトオーナーの意識の高さによって大きく変わってくる部分だと思っていまして。

プロダクトオーナーの中で明確に作りたいもののイメージが固まっていればスムーズに洗い出せますし、逆も然りかなと。

もちろんスクラムですから、プロダクトオーナーが困っていてばみんなでアイデアを出し合いカバーし合うことが重要です。

ただとはいえプロダクトオーナーがあまりにも経験不足であったり、プロダクトの開発目的を見失っていては、プロダクトバックログの洗い出しを行うことができず、開発を行うことが困難になってしまうのかなと。

見積もりがうまく取れない

プロダクトバックログに対して見積もりを行うことは非常に重要であり、個人的にはスクラムの 1 つのキモだと思っています。

また、プロダクトバックログに対して見積もりを行っていなければ、それはスクラムではないとすら思っています。

で、見積もりもまたさまざまなチームで行ってきましたが、当たり前ですがまー大変です。

大量のプロダクトバックログを目の前にして、1 つ 1 つのプロダクトバックログにポイントを振るのって、なかなかどうしてテンションも下がります。

ではどうすれば見積もりがうまく振れるようになるのか、これについては後述しようと思います。

プロダクトバックログとスプリントバックログが一緒くたになってる

これもよくあるケースなのですが、なぜかプロダクトバックログとスプリントバックログを分けない現場って少なくないです。

プロダクトバックログとスプリントバックログを分ける理由は明確で、プロダクトバックログはユーザーレベル、スプリントバックログは開発レベルのタスクに落としこむことが可能だからです。

これらのバックログを分けない場合、粗すぎる PR になってしまうケースが発生しがちです。

個人的に、PR の粒度は小さければ小さい方が良いと思っているので、そうするとプロダクトバックログに紐づく PR では作成が厳しくなってしまうのは想像に難くありません。

むしろバックログを分けないメリットを教えてもらいたいくらいです。

プロダクトオーナーが忙しい / ステークホルダーが忙しい

よく勘違いしている人が多いのですが、スクラムってルールであり、法律みたいなものです。

つまり導入する以上は守ることが当たり前なわけで、おいそれと軽い気持ちでイベントを休んだり、ルールを捻じ曲げたりしてはいけません。

で、開発チームは比較的 Issue ベースの開発に慣れている人が少なくなく、各種イベントについてもやる気があるかはともかく、きちんと参加する人は多い印象があります。

ところが一方、プロダクトオーナーやステークホルダーについては、スクラム遵守することの重要性を理解しきれていない方が多く、結構平気でイベントをすっ飛ばしたりする方がちらほらおられます。

過去にあったケースだと「忙しくてバックログが洗い出せていません！」とか「忙しくてスプリントレビューに参加できません！」とかはちょくちょくありました。

で、先にも書いた通り、スクラムって法律なので、守ることが前提です。

にもかかわらず、プロダクトの責任者であるプロダクトオーナーが忙しくてルールを守れていないようでは、ひいてはスクラムに対する理解が足りていない証明にしかなっておらず、まともにチームが回るわけありません。

もちろんステークホルダーもスクラムの外側のロールとはいえ、スクラムチームを脅かす存在になってしまっては本末転倒です。

ただ、プロダクトオーナーやスクラムマスターについてはとくにスクラムに対する造詣が深くなければ、スクラムの成功はありえないのかなーと思います。

開発メンバーの技術力が足りていない

意外と見落としがちなのですが、スクラムにおける開発チームって結構高い技術レベルが求められるのかなーと思います。

ウォーターフォールなら技術力が低くてもなりたつ、といったことを言いたいわけではもちろんありません。

とはいえ、たとえばプロダクトバックログに対して見積もりを行う際、技術力が高いメンバーと低いメンバーでは、そのプロダクトバックログに対する考慮の幅ってまったく異なると思っていまして。

見積もりのフェーズでは技術力の低いメンバーの視野が広がる良い機会だと個人的には思っていて、ただそれは広い視野を持ったメンバーがチームに参加していることが前提なわけです。

過去にも開発メンバーの全員が全員ともに経験不足で見積もりがあまりにうまく進まないケースもあり、スクラムチームって少人数制がゆえに、各々がある程度プロフェッショナルでいる必要があるんだなーと感じることがありました。

今ではさまざまな現場を経験してきたこともあり、比較的さまざまなケースの想定ができるようになったものの、逆に自分以外の開発メンバーの経験があまりに浅い場合、見積もりが苦しいことになることは容易に想像されます。

と、ここまで半分愚痴のようも感じる経験を書いてきましたが。

ここからが本題、ではどうすればスクラムってうまく回るのか、ということです。

で、個人的に、スクラム自体は難しくもなんともないと思っていまして。

上記に書き出したとおり、まずは最低限のルールセットを守ることは前提として。

ここからは、どうすればスクラムをうまく回すことができるのか、個人的な考えを書いていこうと思います。

ゴールを小さくする

まずもっとも大切なこととして、ゴールを小さくすることが挙げられると思います。

よく Web サービスの開発において、その Web サービスすべての完成をゴールと定めるチームが非常に多いのですが。

たとえばその Web サービスをもっと細かく切り出して、1 つ 1 つをスクラムのゴールとすべきだよなーと感じることは少なくありません。

いったんリリースとかそういったことはすべて置いておいて、最低限のゴールを定める、ここがプロダクトオーナーの手腕の見せ所ではないでしょうか。

とくにメンバーがスクラムに慣れていないうちは、個人的には 2 ヶ月くらいで達成できるゴールを定めてあげるべきかなーと思います。

イベントを重くしない

開発期間が長くなればなるほどメンバーのテンションやモチベーションって下がっていきます。

スクラムマスターはモチベーターとしてさまざまなコミュニケーションを取るようにしたり、ときにプロダクトオーナーのサポートに回ったりしますが、それでもやはり限界はあります。

ではどうすればモチベーションの維持を行うことができるのか。

1 つは上にも書いたとおり、ゴールを小さくするといったことが挙げられます。

ただそれ以外にも方法はあると思っていて、たとえばイベントを軽くこなすというのも選択肢としてはアリなのかなーと思っています。

たとえばイベントの 1 つにスプリントレトロスペクティブがありますが。

いわゆる KPT のようなフレームワークを用い、カイゼンを行うイベントなわけですが。

レトロスペクティブって、別に KPT を行わなければいけないイベントではないわけで、フォーマットについて規定があるわけではありません。

なので、たとえばスプリントバックログがきれいにクリアできたときなどはみんなで大いに褒め合うのも全然アリなわけで。

毎回無理して問題点を洗い出す必要があるのか？というと、個人的にはノーかなと思っています。（これは人によって意見が割れるかもですが）

まったく問題ないと思ったら「今週は完璧でした！問題なし！以上！」と胸を張って言い切ってしまえば良いのです。

毎回毎回お通夜のような雰囲気でイベントをこなすのはやめるようにしたほうが良いんじゃないかなーと、個人的には思います。

メンバーを外す

スクラムって、残念ながら誰しも遵守できるほど容易なルールセットではないと思っています。

スクラムに参加できるメンバーとは、互いを思いやり、互いの意見を尊重でき、積極的なコミュニケーションを取ることができるある程度技術や知識に自信を持てるメンバーである必要があると思っています。

で、たとえば自信の考え方に非常に自信を持っており、相手を尊重できないメンバーがチームに存在していては、スクラムを成り立たせることは途端に難しくなります。

たとえばスクラムをルールセットだと理解できず、イベントに積極的に参加しないメンバーが存在していては、やはりスクラムを成り立たせることは難しくなります。

個人的に、スクラムを成り立たせるには、各々に対しそこそこ高い人間性とそこそこ高い技術力を求められるよなーと思っていまして。

技術力があまりにも足りていなければプロダクトを完成させることが厳しいのはある程度誰でも理解できると思いますが。

人間性があまりにも足りていなければ、やはりプロダクトを完成させるのって厳しいものです。

で、もしもそういったメンバーがチームに存在していれば、時として厳しい決断がプロダクトオーナーには求められると思います。

また、悲しいことにプロダクトオーナーがそういった人であれば、やはり会社として厳しい決断を行う必要があるのかなと。

1 番良くないのはなぁなぁで済ませてしまうことであって、見て見ぬ振りをしていてはプロダクトの完成なんて夢のまた夢です。

会社として、またチームとしてスクラムを導入するのであれば、しっかりとスクラムを遵守できるメンバーを揃えることが重要だと個人的には強く思います。

スクラムを自己流にアレンジしない

たまに「うちではスクラムをアレンジしたルールセットを導入しています！」という話を耳にするのですが、ちょっと不安に感じることがあります。

もちろん、スクラムの公式もチームに合わせてアレンジをすることも大切であると明記していますが。

これはあくまで一度基本のスクラムに則って進めたあとに、合わなかった部分をアレンジすれば良いという話なわけで。

基本のスクラムを経験しないままにアレンジしてしまうのは、はっきり言って愚の骨頂です、それではスクラムの本質は理解できないと思います。

スクラムって世界中で何年も使用されてきたルールセットであって、何度も改訂を行われたものが公開されているわけです。

したがって、基本となるスクラムって本当に最低限のルールセットが明記されているに過ぎず、この通りに進めたところですべてがすべてうまくいく保証なんてもちろんありません。

にもかかわらず、最低限のルールセットを安易にカスタマイズするということは、非常にリスキーなことを行っている認識を持つべきだと個人的には思います。

もし仮にスクラムに則って開発を進めていくうちに『なにかうまく進まないな？』と感じたのであれば、それはスクラムのルールセットに問題があるのではなく、自分たちの進め方ややり方に問題があると考えるべきかなと、強く思います。

スクラムは銀の弾丸ではない

よく『うちの開発ってうまいこと進んでいないんですが、スクラムを導入すればうまくいきますかね？』と相談されることがあるのですが。

結論から書いてしまうと、スクラムを導入したところですぐに問題が解決されることはありえないと思っています。

繰り返しになりますが、スクラムを遂行するには結構高い人間性と技術力を求められると個人的には思っていまして。

今の日本で、スクラムをスムーズに回せている現場がどれだけ存在するのか、果たして疑問なところはあります。

そもそもスクラムのルールセットって本当に最低限だと思っていまして、1 つ 1 つのイベントってめちゃくちゃシンプルなんですよね。

個人的に、プロダクトバックログの洗い出しと紐づくポイントの割り振りは結構骨が折れる部分かなとも思いますが、ゴールを小さくすればさほど大変な作業でもなく、慣れの問題かなーとも思っています。

で、個人的には当たり前のことだと思っているのですが、スクラムに慣れていないメンバーが多いスクラムチームにおいて、最初から完璧なスクラムを行うことは不可能に近いと思っています。

プロダクトバックログの洗い出し 1 つをとっても、めちゃくちゃ手探りでやることになると思います。

スプリントレビューやスプリントレトロスペクティブも、おそらくみんな『これで良いのか？』と疑問を持ちつつ進めることになると思います。

でもそれで問題ありません、最初から完璧なスクラムを遂行するのは、今の日本では不可能だと個人的には思っています。

手探りで良いので、ルールに則ってスクラムを押し進めていく、それを繰り返していくことによって、あなたたちのスクラムの形ができあがります。

上にも書いたとおり、残念ながら今の日本でまともにスクラムを回せている現場はほとんど存在しておらず、いくら成功談を探しても見つけることはできません。

したがって何が正解かわからない状態で始めるがゆえ、とくに最初の方は慣れないことによって速度も出ないですし、チームの中に不安から生じる不穏な空気が出てくるかもしれません。

それでも押し進められるだけのバイタリティを各々が持っていなければスクラムって成り立たないので、やはり現実問題として実現というのはなかなか難しいのかなーと。

ということで、前々から書きたかった「個人的なスクラムに対する所感」でした。

個人的にはスクラムってめちゃくちゃシンプルで有能な開発手法だと思っています。

ただ一方で、押さえるべきポイントを押さえなければやはり実現が難しいとも思っていまます。

個人的に、あまり言及されていないながらも、以下を意識してみるとうまくいくんじゃないか？というポイントをざくっと書き出してみると。

• スクラムメンバー同士が仲良くなければうまくいかない、ゆえに会社としてはリファラル採用を推奨すべき
• ゆえに年齢が比較的近いメンバーを揃えることも重要
• チームに馴染めないメンバーがいれば時として外す判断も必要、ただし外すことを重く扱う必要はない
• スクラムに関わるすべてのメンバーがスクラムを理解している必要がある、とくにプロダクトオーナーとスクラムマスターはしっかり
• まずは基本のスクラムに忠実に進める、スクラムはルールセットであり法律である
• スクラム懐疑派が多いのであれば無理してスクラムを押し進める必要はない、ただスクラムを導入できるほどの土壌が存在していないだけの話である
• インセプションデッキはしっかりと、スタートとゴールは明確に
• ゴールは小さく、スプリントは短く、慣れていないうちから無理をしない
• プロダクトオーナーは忙しいを言い訳にしない、忙しければルールを破って良いのか？
• デザイナーももちろんスクラムメンバーの 1 人である
• アメとムチをうまく使い分けること、日本人はムチばかり使いがち
• スクラムがうまく回らなければチーム内に問題がある、チームの外側に問題は存在しない

と、まだまだ言いたいことはたくさんありますが、あまり長くなってもアレなので今回はこれくらいで。