SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

DeveloperZine(デベロッパージン)- エンジニアの意思決定を支える技術情報メディア ProductZine

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

イラストでわかる! 今日からはじめるスクラム

スクラムを使いこなそう! スプリントレビュー・レトロスペクティブ・リファインメントとは

イラストでわかる! 今日からはじめるスクラム 第4回

プロダクトバックログのリファインメント

 この章で取り扱う「リファインメント」は、決まった時間に行ういわゆるスクラムイベントではありません。しかし、スプリントゴールを達成するために必要な時間となります。

 「プロダクトバックログ」は、今スプリントでPOが優先度をつけたやりたいこと(プロダクトバックログアイテム・PBI)と、それをどう実現するかという開発タスク(スプリントバックログ・SBI)で構成されています。

 プロダクトバックログは、そのスプリントの作業計画として、スプリントプランニングで作成されます。スプリントプランニングで決めたことが、漏れなく無駄なく想像通りにいけばなんの問題もありませんが、現実はそうではないため、アジャイル、そしてスクラムというかたちを選んで仕事をしています。

 なにか新しいことが起きたりわかったりした時に、プロダクトバックログの見直しをすることをリファインメントと呼びます。

 リファインメントは、プロダクトバックログの透明性をあげることを目的としています。

 プロダクトバックログは、スプリントゴールを達成することを目的として優先度をつけますが、以下のようなタスクがあると、プロダクトバックログの透明性が下がり、スプリントゴールが達成できなくなってしまいます。

リファインメントで具体的に行うこと

PBIの並び順の変更

 PBIは一度決めても、並び替えて問題ありません。プランニング時から増えた情報や環境の変化をふまえて、PBIの優先度は随時変更します。

 PBIの順番はPOに決定権がありますが、開発者はスプリントの中でわかったことをPOに対してフィードバックすることで、より効果的なプロダクトバックログにすることができます。

タスクの詳細化

 やや大きいタスクを複数に分割する、要件を厳密にする、手順を書き加えるといった詳細化を行うことで、透明性が上がります。

ポイントの見直し

 当初の想定より短く済みそうなタスク、または長くかかりそうなことがわかったタスクが発生した場合は、開発者でポイントを振り直しましょう。

スコープの見直し

 差し込みが発生した場合や、思っていたよりスプリントゴール達成に必要なタスク量が多かった・少なかった場合、このスプリントで何をどこまでやるかという計画を変更する必要があります。POと相談したうえで、このスプリントで実現する範囲を見直しましょう。

不要なPBI・SBIの廃棄

 よくある失敗として、一度つくったタスクを「あとでやるかも」「必要になるかも」と、大事にとっておいて、巨大なプロダクトバックログができあがってしまうことがあります。不要になったタスクはリファインメントで捨てましょう。

必要なPBI・SBIの追加

 スプリント中に必要になったPBI・SBIの追加もリファインメントで行います。これをやった場合は、かならず不要なPBI・SBIの廃棄、またはスコープの見直しを行ってください。

 ここに挙げた通り、リファインメントは、プロダクトバックログの透明性をあげることを目的とした活動です。リファインメントを行うことで、スクラムチームはプロダクトバックログの最適な状態を保ち続けることができます。

 スクラムを始めたてのころは、今のプロダクトバックログがリファインメントを必要な状況にあることを意識する習慣がなく、リファインメントの機会を逃しやすいことがあります。そのため、1日の終わりに10〜20分程度、リファインメントが必要か検討する時間をつくることで、リファインメントに対して意識的に取り組むことをおすすめします。

スクラムがうまくいない状態の打開策

 ここまではスクラムの始め方を説明してきましたが、最後に始めてから直面しやすい問題と、その打開策について説明したいと思います。

 「スクラムを始めたが、チームの活動がスムーズにいかない」スクラム開始後に問題がある例として、このケースが一番多い気がします。

 スクラムチームが「スクラムイベントはすべて実施しているのに、仕事がやりやすくなったと感じない」と思っている状態です。

 よく「スクラムは魔法ではない」と言われます。スクラムは取り入れるだけで病気が完治するような薬ではなく、体を動かすことで少しずつ健康になっていくエクササイズのほうがイメージにあっている気がします。

 課題を抱えているチームを観察してみると、「スクラムイベントと同じ名前がついた会議を、決まった時間に、決まった間隔でやっている」という状態に陥っていることが多いです。

スクラムアンチパターンの例

  • スプリントプランニングが、一部の開発者だけがタスク作成をし、それをほかの開発者に説明する場になっている。
  • 毎朝形式化したデイリースクラムを行っているが、今日のTODO共有になっている。スプリントゴールが達成できるかということを意識していない。
  • カンバンのタスクは、誰がどのタスクをやるか最初から決まっている。または、デイリースクラムで他の人に指示されたタスクを取っている。
  • スプリントレビューにステークホルダーを呼んでいない。
  • スプリントレビューの場に未完成なもの(動かないもの)を持ちこんでいる。
  • レトロスペクティブで出た改善案が、次のスプリントで実施されないことが多い。

 これらのアンチパターンは非常に陥りやすいものですが、少しずつでも抜け出すことは可能です。

アンチパターンからの脱出方法

 まずは、スクラムガイドを理解することからやりなおしましょう。チームでの輪読会をおすすめします。毎週1時間程度でかまいません。輪読会では、スクラムガイドにかいてあることと自分たちのチームがやっているスクラムを比べて、なにができていて、なにができていないかをディスカッションします。

 できていないことには、少し意識すれば直せそうなものもあれば、今のこの組織体制やサービスではすぐには不可能というものもあるでしょう。

 スクラム適応を急ぐ必要はありません。今できることから、無理のない範囲で少しずつ進めます。実際にやってみると、うまくできないという場合もあるでしょう。

 スクラムを始めるぞと盛り上がっていると、スクラムをやることが仕事の目的にすり替わってしまうことがあります。大事なことは、チームとプロダクトの成長です。スクラムのルールを理解したうえで、ここはルールを守るけれど、ここは今すぐには守れないので、ルールどおりにはしない、という判断も構わないと思います。

 そして、また新たな問題がでてきたときに「いまスクラムのどこを守っていないか」を思い出してください。そこには問題解決のヒントがあるはずです。

 ハードルはまとめて飛び越えようとせず、ひとつずつ越えるようにしてください。少しずつスクラム適応をすることを繰り返し書いていますが、それはやさしくスクラムを始めるためもありますが、うまくいかなかったときの問題を特定するためという意味が大きいです。

 もし、あまりにも業務上の無理が多く、スクラムガイドにある内容にも共感ができないメンバーが多いようであれば、スクラム以外の方法を選ぶという選択肢も忘れないでください。

スクラムになってから忙しすぎる

 前のベロシティを上回ることが「よいこと」とされているチームで起きる問題です。

 注意点として、スクラムにはベロシティを測るというルールはありません。ですが、仕事量の予測のためによくスクラムと合わせて使われる手法なので、ここではベロシティのアンチパターンについて触れます。

 ベロシティとは、速度という意味の言葉です。

 タスクに対してポイントを振り、1スプリント中に完了したポイント数を合算したものをそのスプリントのベロシティ(速度)として扱います。未経験のタスクが多ければベロシティが下がり、慣れ親しんだタスクが多いとベロシティは上がりやすくなります。

 ベロシティを測り始めると、タスクの属人化を解消しているチームでは、最初は低めに出て、少しずつ上がり始めます。仕事の速度があがることはモチベーションにも繋がりますが、いつかはその速さも限界に達します。

 最高速度200キロで走れるが、1時間走ると壊れてしまう車があるとしたら、それは良い車と呼べるでしょうか。速さは価値の一つではあるかもしれませんが、あくまでたくさんある価値の中の一側面でしかありません。

 ベロシティをチームの成長のバロメーターとしないように気をつけてください。スクラムガイドのスクラムチームの項目には「持続可能なペースで仕事を行うこと」と書かれています。

 今のスプリントのタスク量は、ストレッチした目標になっていないでしょうか。次の、さらにその次のスプリントでも、同じように働けるでしょうか。

 ベロシティを安定させるということは、チームにとって一番良い仕事のテンポを見つけるということです。もしも、たくさん残業をするワーカホリックなメンバーがいたとして、その人に働きすぎだと伝えるのは抵抗感があるかもしれません。

 その人が、長時間労働を熱心で良いことだと信じているタイプであればなおさらです。ですが、無理な働き方はスクラムのルールを守れていない状態です。スクラムマスターとしては、止めるべき状態であることは覚えておいてください。

指示をしないとチームメンバーが動かない

 スクラムを始めて数ヶ月たったチームから聞く悩みで「チームメンバーの自律性が低い」「自発的な行動がない」といったものが多くあります。この「自律」は自立と混同されがちですが、自分を律すると書く通り、自分自身にルールを課してそれを守っている状態を指します。スクラムガイドの中にある「自己管理」という表現も自律のひとつです。

 例えば、デイリースクラムでカンバンをみているときに、誰かのタスクがうまく進んでいないとしたらどうしますか。指示的な場合だと「このタスクの進捗が滞っているけど、どこで困っているか教えて」と言ってしまうかもしれません。

 この対策として、指示をせずにチームメンバーを動かす方法として「問いかけ」をつかってみましょう。

 デイリースクラムで「いまの進捗状況で、スプリントゴールは達成できそうですか」とスクラムチーム全員に問いかけてみます。タスクが滞っている人個人に問いかけるのではなく、全員です。

 この質問には、デイリースクラムでありがちな「なにか困り事はありませんか」という質問よりも優れている点がいくつかあります。自分がアサインされていないタスクをどこか他人ごとだと思っていても、スプリントゴールの達成は開発者全員の責任なので、カンバンの他人のタスクにも目が向くようになります。

 そこで「自分の(他人の)タスクの進みが少し悪いので、問題点を確認したほうがいいかもしれない」とチームメンバーの意見が上がってくれば、他人の指示でうごく他律状態から自律状態にぐっと近づいています。

 もし「たぶん問題ないと思います」と言われたら、そこで初めて「このタスクが滞留しているように見えるが、それでもスプリントゴールは達成できそうか」という具体的な質問に踏み込んでいきます。

 ここでわかることは、指示をすることは、人がなにかを自発的に行うチャンスを奪っている可能性があるということです。特にスクラムマスターは、指示ではない「問いかけ」によるコミュニケーションを意識するとチームの成長を加速することができます。

 ルールを自分で守れている状態は、ボードゲームやカードゲームを楽しんでいる状態と似ています。最初はルールブックや人からルールを教えてもらいますが、ルールを理解した後は、誰かに指示されなくても自分自身やお互いにルールを守るように注意することで、ゲームを楽しめる状態になれますよね。この状態が「自己管理」的な状態です。

 これらを踏まえると、スクラムガイドブックの表紙には「ゲームのルール」と書いてあることにも頷けると思います。

権限がスクラムチームにない

 スクラムチームで「この施策はもっとこうしたほうがいい」という意見がでても、スクラムチーム外の人からNGがでてできない場合、スクラムによる仕事はかなりの困難を極めます。

 この対応は容易ではありませんが、いくつか解決策を挙げてみます。

真のPOをプロダクトオーナーにする

 POという役割を与えられた人がプロダクトの意思決定ができないとしたら、それはPOではありません。その「OKやNGの権限がある人」をPOに据えることが望ましいです。ですが、そういった権限がある人の多くは管理職や役員で、なかなかスクラムチームとして同じ現場で働くことは難しいかもしれません。

 可能であれば、デイリースクラムは難しくとも、スプリントプランニング、スプリントレビュー、レトロスペクティブの3つのイベントだけでも同席できるのであれば、今までよりはシンプルに物事を進めることができ、手戻りもぐっと減ると思います。

プロダクトに関わる権限を現場に降ろしてもらう

 プロダクトの意思決定権が誰か一人でなく複数の偉い人にあって、スクラムチームでの意思決定が不可能な場合や、プロダクトの決定権がある人がそもそも会社にあまりいないような場合、プロダクトに関わる権限をスクラムチームに任せてもらうような取り組みをします。

 この改革は、最終的にはスクラムチームの中にいるPOや、ものによってはスクラムチームの開発者に権限を渡すことをゴールとしますが、多くの場合一番努力することになるのはスクラムマスターです。

 スクラムマスターは、スクラムというフレームワークに則ってチームが働けるように支援する必要があります。

 プロダクトの権限を持っている人がプロダクトの現場に対してあまり向き合わずにうまくいくケース、または意思決定者が複数人いて、素早い意思決定が可能になるケースはありません。

 スクラムマスターは、スクラムチームだけでなく組織に対しても、スクラム理解・活用を支援することに責任を持ちます。もし組織全体にスクラムを理解してもらえれば、少しずつでもスクラムチームで意思決定ができるケースが増えてくるはずです。

最後に

 1、2回目では、スクラムの中でも比較的とりいれやすいものについて、3、4回目ではスクラムチームのそれぞれの役割とスクラムイベントについて書かせていただきました。

 ニフティでは、スクラムマスターギルドという取り組みをしていて、月に一度スクラムマスターの情報共有や意見交換の場を設けています。ここでの話し合いででてきたスクラムの失敗や、それをどう改善してきたかという話を元として、今までの記事を書かせていただきました。ニフティ スクラムマスターギルドの参加者の皆様に、この場を借りて感謝申し上げます。

 正しい仕事の方法はありませんが、今よりもより良い仕事の方法はきっとあるはずです。スクラムはその「より良い仕事の方法」を素早く見つけるために最適なフレームワークだと思います。

 スクラムは始めやすいですが、何年スクラムマスターをやっていても、きちんとルールを理解し守ることは本当に難しいです。しかし、そこにスクラムの面白さや奥深さが詰まっていると思います。

 スクラムを始めるためには、高い費用も、高度な技術もいりません。スクラムをまだ試していない人は、部分的なものでもいいので、タイトルのとおりぜひ今日から気軽に始めてみてください。そしていつか、スクラムって面白い!と思えるくらい、スクラムを楽しんでもらえればと思います。

この記事は参考になりましたか?

連載通知を行うには会員登録(無料)が必要です。
既に会員の方はを行ってください。
イラストでわかる! 今日からはじめるスクラム連載記事一覧

もっと読む

この記事の著者

西野 香織(ニフティ株式会社)(ニシノ カオリ)

 ニフティ株式会社のN1! という制度で、スクラムエバンジェリストを担当しています。アプリチームのスクラムマスターをやりながら、スクラムについて社内外で説明したり、社内のスクラム導入を支援したりしています。A-CSM所持。

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

この記事は参考になりましたか?

この記事をシェア

CodeZine(コードジン)
https://codezine.jp/article/detail/18361 2023/10/30 11:00

イベント

CodeZine編集部では、現場で活躍するデベロッパーをスターにするためのカンファレンス「Developers Summit」や、エンジニアの生きざまをブーストするためのイベント「Developers Boost」など、さまざまなカンファレンスを企画・運営しています。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー