スクラムの赤点対策 - Stanby Tech Blog

株式会社スタンバイでプロダクトオーナーを務めている上野です。

「スクラム導入したけど、開発が上手く回らない」「これで良いのかわからない」。スクラム開発でお困りの方も多いのではないでしょうか。僕の所属するチームもスクラムが上手くいかずに苦しんだ時期がありました。

スクラムガイドって守るべきことが書いてあるだけで、運用方法までは書いてないんですよね。少なくともこのあたりは押さえておけば「スクラム赤点」にはならず、軌道に乗るんじゃないかな、という部分をお伝えします。

スクラムとは

僕も当初そうでしたが、スクラムは誤解されやすいフレームです。スクラムガイドがあることからも、「単純にこのガイドラインを守っていれば良いのだな」となりがちな気がしています。

しかし、スクラムは「現状を素早く正確に把握し、課題を炙り出すフレームワーク」です。少々乱暴に言えば「目標と現状のギャップを全部見える化し、ギャップを解消することで前進していく」というフレームワークです。導入後も常にチーム全員の努力がない限り成り立ち得ない世界なのです。

そもそも、拠り所となるスクラムガイドに記載されていることといっても、基本的なスクラムイベントやスクラムにおける考え方や価値観に関することくらいです（ただし、心理学や行動学からしっかりと裏付けされた理論）。当然、環境が異なるチームがフレームワークを使うので、唯一の正解となるスクラムの形もありません（「間違った形」は定められそうですが）。

スクラムガイドというと、一般的にスクラムイベントや役割定義に目が行きがちですが（僕自身そうでした）、実はここに記載されている「考え方」がスクラムの成否にかかっていることはあまり知られていないかもしれません。

以前、複数の企業でスクラム導入支援している外部コーチに伺ったところ、スクラムがうまく機能しないケースのうち、最も多い理由が、この「考え方」の認識が揃っていないこと、だそうです。

こうした「考え方」部分が重要なのは、スクラム開発がチーム活動であり、チームで助け合うことを前提に作られているフレームワークであるからでしょう。例えば、スプリント内のチケットが早めに完了したメンバーがいたら、他に困っているメンバーの開発サポートに回ったり、POの時間が取れない場合に開発メンバーがチケットの作成まで行なうことなど、ほかにも色々ありえます。

まさにスポーツのように、1つの目標に向かってチームが協力して行う活動は単なる機械的な仕組みだけではなく、「考え方」、いわゆるマインドやスタンスが肝になってきます。

目線のすれ違う開発チーム

当時、僕の所属していたスクラムチームはそれぞれが別の方向を向いている状態でした。

＜当時の課題メモ＞

スプリント内のチケット達成率に対する温度差が生まれてしまっている
個々人で開発の進め方があり、守るべき部分と妥協部分の違いなどが明確にされないまま属人的に進んでしまう
レトロ等の振り返りの場でも何を振り返ればよいかわからない状態で、結果的に何も出ない

今思えば、タスクやサブタスクのスプリント内完了の意識を徹底できておらず、開発メンバーがそれぞれの状況を把握できず、それゆえ、協力するような会話ができていないという状態でした。

お互い期待することが異なるため、開発上のストレスが増します。やがて目に見えないストレスはいずれ大きな溝となり、最悪の場合、スクラムチームの崩壊に至っていたでしょう。

幸い、チームの崩壊とまでは至りませんでしたが、パフォーマンス的には”赤点”でした。チーム内から「なんでスクラムやってるんだっけ？」という問いかけが出たほどです。

この状況を打開すべく、チーム外部のコーチ（社内のアジャイルコーチ）の力もお借りし改善に移りました。具体的には、開発の「考え方」を統一させるワークを複数回行いました。週1回程度で1−2時間、1ヶ月程度かけ、主に今から説明する2つの考え方をチームメンバー全員で理解、解釈し、ワーキングアグリーメント化するという活動です。

ワーキングアグリーメントを作って終わり！では意味がないので、チームでの取り決めを日々の、習慣にさせるため、さらに数ヶ月の時間をかけました。

結果、開発チームの雰囲気や生産性は赤点を脱するどころか、組織として次のフェーズに進んだ印象を持てました。スプリント内のチケット進捗率、Slackのコミュニケーション量、普段交わされる話題の数、そして何より、レトロスペクティブによる課題出し、トライの実践、振り返りまでのサイクルが増えたことに驚いています。課題以外にもスプリント内で「良かった取り組み」を付箋化するのですが、この量も当時から比較すると3,4倍違うのではないでしょうか。

スプリントが上手く回るような大それた仕組みを新たに作ったわけではないです。単純に「考え方」を統一しただけです。

この実践を通じて、改めてスクラムメンバーで「考え方」を統一することの重要性を認識しました。「考え方」をいかにチームで合意し、浸透させ、実践するか。これが成功の秘訣であると考えています。チームのカルチャーによってtipsやルールの違いが滲み出るはずで、それがまた面白いところなんだろうなという気がします。前置きが長くなりましたが、以下にて、スクラムで”赤点”にならないための、重要な考え方を2つご紹介します。

１．スクラムの理論

1つ目は、スクラムガイドで「スクラムの理論・スクラムの三本柱」として扱われている考え方です。主に「Inspection（検査）」「Adaptation（適応）」「Transparency（透明化）」の要素から成ります。

少し噛み砕くと
・常に現状に対して自分たちのあるべき状態を常にアップデートし（検査）
・現状とあるべき姿への差分を埋め続ける努力をしていること（適応）
・そもそも正しい状況判断を行えるように、活動を可視化しよう（透明性）
というのがスクラムの価値観です。

つまるところ、目標に対して現状はどのような状態なのか、そのギャップを埋めるために何ができるか、が明らかになっていること、ビジネスシーンでよく目にするような「As-is、To-be、To-do」のフレームワークと同じような考え方ですね。

つまり、スプリント内のあらゆる活動において目標が設定され、現状差分に対する仮説を持ち、（可能なら）計測され、公開されるなど、常に振り返れる状態を作り続けないといけません。例えばチケットには「完了基準（Acceptance Criteria）」のような明確なゴールを設ける、スプリント内で消化したストーリーポイントを計測していく、スプリント内で用意できる作業時間を明らかにするなどが該当します。

僕のチームでは、1つ目の「考え方」としてこのスクラムの理論を理解する、というステップから始まりました。

２．スクラムの価値基準

もう1つは、5つのスクラムの価値基準「Commitment（確約）」「Focus（集中）」「Openness（公開）」「Respect（尊敬）」「Courage（勇気）」です。

これだけでも十分なケースもあるかもしれませんが、僕のチームではもう少しアクションに落とし込みたかったので、以下のようにスプリントのワーキングアグリーメントとして設定しました。数が多くても守りづらいので、まずは3つに絞っています。
ポイントは、第三者が見ても客観的に評価できる内容かどうか、です。※参考①：miroでのワークショップのアウトプット