「なんちゃってスクラム」に気づくためのコツ

こんにちは。株式会社InnoScouter CTOの大西(Twitter: @monarisa_masa)です。

InnoScouterでは、開発手法として、スクラム開発に取り組んでいます。

今回は、「なんちゃってスクラム」に気づくためのコツ、というトピックで話していきたいと思います。
自分自身数年にわたり、他社の方から「スクラム開発やってる？」と聞かれたときに、「なんちゃってスクラムですかねぇ」と言い続けてきました。長らく「なんちゃって」状態だったのですが、最近個人的にそれを脱するタイミングを味わったので、その話をさせてください。

※ そもそもスクラム開発をよく知らないという方にもわかるように、適宜スクラム開発自体の説明もしていきます。

この記事の対象読者

• 現在進行形で、スクラム開発をやっているが、なんか違いそうと感じている方
• (前職などで)1度スクラム開発をやった経験はあるが、いまいち効果を感じられず、やめてしまった方
• これから新たにスクラム開発をやろうとしている方

結論

早速、結論にいきますが、「なんちゃってスクラム」に気づくためのコツとは、

スクラムの各イベントで、「スプリントゴールの達成のために」という言葉が出ているか？ を見極めること

だと私は思います。

これを聞いて、「そんなの当たり前でしょ」と思われた方は、これ以上読み進めても得るものは少ないかもしれません。
逆に、なぜこれが「なんちゃってスクラム」に気づくためのコツなのか、疑問に思われた方は、是非読み進めていただけると嬉しいです。

※ 本記事はこれに気づくのにすごく時間がかかった筆者の体験談です。

ここからの話の流れ

ここからは、下記の順に話していきます。

• スクラム開発とは？
• 「なんちゃって」とは?
• 脱「なんちゃって」のきっかけ
• 脱「なんちゃって」のやり方
• 脱「なんちゃって」の結果
• まとめ

スクラム開発とは？

スクラム開発とは、アジャイル開発手法の一つです。
一定の短い期間(スプリント)を設定して、その期間内に目指す目標(スプリントゴール)を置いた上で、チーム内で役割やタスクを分散しながら、コミュニケーションを取りつつ開発を進めていき、かつ、それを繰り返していく開発手法です。

スクラム開発には、下記のようなイベント(コラボレーションの機会)があります。

• スプリントプランニング
  スプリントで取り組むタスクの計画を⽴てる。
• デイリースクラム
  毎⽇、同じ時間に開催され、スプリントプランニングで計画されたタスクの進捗状況を報告し合う。
• スプリントレビュー
  スプリントの成果を披露し、関係者からフィードバックを受け取る。
• スプリントレトロスペクティブ(振り返り)
  チームでスプリント中に何がうまくいったか、どのような問題が発⽣したか、そしてそれらの問題がどのように解決するかについて話し合う。

※ 参照: https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf

「なんちゃって」とは？

「なんちゃって」とはどういう状態を指すのでしょうか？

スプリントゴールを意識せずに、スクラムをやること

だと私は思います。

具体的には？

当初、私たちのチームがそんな感じでした。
私たちのやっていたスクラムは、イベントを最小限にして、開発することと振り返ることにだけ特化した横着スクラムでした。そこにはスプリントゴール自体はあったものの、非常にあいまいに運用していました。

実施していたイベントは以下の3つです。

• スプリントプランニング
  • 大きなタスクをチームで分割しながらやっていました。
  • タスクはリスト化されるが、「なんのために」や「どこまでは死守するのか」については、しっかりと話せていませんでした。(スプリントゴールの運用があいまい)
• デイリースクラム
  • 各人のタスクの進捗の報告を毎回やっていました。
  • 報告者に対するコメントは、私がするのがほとんどで、内容としては各メンバーの困りごとを聞くのが主でした。(前提: 私がスクラムマスターを担当)
• スプリントレトロスペクティブ(振り返り)
  • KPTをやっていました。

脱「なんちゃって」のきっかけ

ひょんなとこから、脱「なんちゃって」をしてみようという話が上がりました。
その当時、正直自分としては「なんちゃって」でも、十分に回っているような感覚を覚えていました。
(その後、脱「なんちゃって」をして、スクラム開発の真価を全然発揮できてなかったことに気づくことになるのですが...)

• 回っていると感じた理由
  • スプリントプランニングにより、チームが週(スプリント)あたりどれくらいの開発をこなせるかの予測がある程度できていた。
  • デイリースクラムで困っていることがあれば、私が察知しサポートに入れていた。

ただ下記のような課題はあったので、脱「なんちゃって」に踏み切ることにしました。

• 1スプリントで何がアウトプットされるのかが、ビジネスサイドにとって分かりづらかった。
  • 1スプリントでどれくらいのチケットが消化されるかだけを見てしまい、当時新しく入ってくれたPdMからすると、チケットの消化率は見えるが、結局「何が・いつリリースされるのか」が不透明に映っていた。
• スプリントで目指すべきもの(スプリントゴール)があいまいだったので、タスクの期限管理は個人の裁量に任されていた。
  • 1スプリントにおいて、ここまでやるぞ！といった目標(スプリントゴール)があいまいだったので、スプリント内で消化予定のチケットをやり切るというような雰囲気は薄かった。
• そもそもスクラム導入時に思い描いていた「自走する組織」には程遠かった。
  • CTOの自分がいろんなスクラムのイベントに細かく首を突っ込むという状態になってしまっていた。
  • 本心としては情報の透明性を上げることで、自分以外のメンバーでも開発をリードできる状態を作りたかった。

脱「なんちゃって」のやり方

• チームメンバーに明示的に脱「なんちゃって」しよう！と伝えた。
  • チームメンバー自体も当初のスクラムが不完全ということには薄々気づいてはいたのですが、あらためて本格導入すると伝えることで、意思統一できた気がします。
• 「SCRUM BOOT CAMP」通りに、スクラムをやってみた。(「守破離」の考えを意識しました。)
  • はじめからカスタマイズして、必要な部分だけ取り入れるのではなく、一旦原典通りにやってみて、原典が伝えようとしているスクラムのイベントの価値知るという目的で、下記のイベント全てを含んだスクラムを実施しました。
    • スプリントプランニング
    • デイリースクラム
    • スプリントレビュー
    • スプリントレトロスペクティブ(振り返り)
  • もちろん価値を理解した後に、私たちのチームに合わない場合はカスタマイズしようという前提で行いました。
    • (これは後日談にはなりますが、)「SCRUM BOOT CAMP」によると、イベントを毎週やるのが、カイゼンループを短期間で回すにはおすすめということで、当初は毎週やっていたのですが、ある程度慣れてきた & 作業時間をもう少し確保したいよねという話になり、現在はイベントを隔週でやるようになりました。
• 「SCRUM BOOT CAMP」の輪読会をやってみた。
  • それぞれのイベントについて、なんのためにやるのかという共通認識を揃える良いきっかけになりました。
  • イベント一つ一つがスプリントゴール達成のための手段だということを、ここで掴みかけました。
  • ちなみに輪読会の方法は、こちらのブログを参考にさせていただきました。

脱「なんちゃって」の結果

結果として、私たちは、スプリントゴールを決めるようになり、またイベント1つ1つを何のためにやるのかについての共通認識を得ることができました。
それにより、下記のようにイベントの質も変化していきました。

デイリースクラムの変化

ビフォー・アフターで比べるとこんな感じです。

• ビフォー(「なんちゃって」期)

メンバーB: 「これこれやりました。特に問題なさそうです。」
メンバーA(ファシリ): 「はい、いいですね。」

メンバーC: 「これこれやりました。問題ありますけど、特に詰まっていないので大丈夫です。」
メンバーA(ファシリ): 「はい、大丈夫ですね。」

• アフター(脱「なんちゃって」期)

メンバーA(ファシリ):「スプリントゴールをやるにあたって、間に合います？このままで。」

メンバーB: 「あ、ここまでは自分ができそうですが、ここから対応するとなると間に合わなそうかもです。」

メンバーC: 「あ、自分空いてます。対応します！」

「なんちゃって」期は、まさに進捗報告会という感じで、自分がちゃんとやっていることを伝える場所になっていました。(個人目線)
一方で、脱「なんちゃって」期では、メンバー全体にスプリントゴールを守ろうとする意識(コミットメント)が強く感じられると思います。スプリントゴールを達成するために今自分が何をすべきかを把握する場所になっています。(スプリントゴール目線)

スプリントプランニングとスプリントレビューの機能

こちらも、ビフォー・アフターで比べるとこんな感じです。

• ビフォー(「なんちゃって」期)
  • スプリントプランニング
    • 単なるタスク分割と工数見積がメインでした。
    • タスクの進め方は、各々のやりやすいタスクから進めるというやり方でした。
  • スプリントレビュー
    • 実施していませんでした。
• アフター(脱「なんちゃって」期)
  • スプリントプランニング
    • PdMの協力もあり、「ユーザーが〇〇といったことが実現できる状態を目指そう」といったスプリントゴールを提示してもらえるようになりました。(スプリントゴールを練りだしてくれるPdMの存在は本当にありがたいです。)
    • スプリントレビュー(後述)を実施したおかげで、スプリントプランニングにおいて、「大きなタスクについては、1スプリントで終わらないが、途中段階でもスプリントレビューでフィードバックをもらいやすい順番でタスクを進めていこう」というような考え方もできるようになりました。
  • スプリントレビュー
    • 非エンジニアでユーザーに近しいメンバーに参加してもらって、ユーザー目線でフィードバックをもらえるようになりました。
    • スプリントプランニングで提示されたスプリントゴールはあくまで仮説であり、その仮説が正しいかどうかを、この場で実際できたアプリを触ってもらった上で、フィードバックをもとに検証できるようになってきました。

「なんちゃって」期は、「タスク消化率を予測し、タスクをこなす」という感覚でスクラムが進んでいる印象でした。
一方で、脱「なんちゃって」期では、この2つのイベント(スプリントプランニング・スプリントレビュー)があることによって、「スプリントゴールを決めて、検証する」というサイクル感がでてきて、スプリントゴールの達成への熱量の高まりを感じました。

チームによる自走の促進

• 以前は、ユーザーに対してどんな機能を提供していくべきかという話を、ドメインに対して知識が豊富なメンバーだけで話し合ってしまい、開発メンバーがそういった話に入りづらい状況をつくってしまっていたかなと思っています。
• それがスプリントゴールという形で、全メンバーに共有され、それベースで話せるようになったことで、ドメインに対して知識が豊富なメンバーでなくても、意思決定できる場面が増えてきたと感じています。

まとめ

再三になりますが、本記事での取り組みを通して、「スプリントゴール」を常に意識していくことが、チームに明確な指針を与え、コミットメントを生み出し、それがひいては、プロダクトを素早く、かつ最小限の間違いでつくっていくことに繋がるんだと気づかされました。

改めて、スプリントゴールという言葉を使ってスクラムのイベントを私なりに再定義すると、下記のようなものになると考えています。

• スプリントプランニング
  • PdMによって、スプリントゴールが発表される場所。
  • 開発メンバーによって、スプリントゴールを達成するためのタスクを計画する場所。
• デイリースクラム
  • スプリントゴールへの進捗率を日次で共有し合う場所。
• スプリントレビュー
  • スプリントゴールが本当に達成されたかを確認するために、ユーザーに近しい人たち(ステークホルダー)に触ってもらって、フィードバックをもらう場所
• スプリントレトロスペクティブ(振り返り)
  • スプリントゴールを達成するのに、寄与した事情や、阻んだ事情を振り返る場所。

もし、スクラムで行き詰まりを感じた時には「スプリントゴール」って言葉は出てたかな？と振り返ってもいいかもしれないですね。

そして最後にですが、この記事を読んで、弊社のスクラムの取り組みに興味を持っていただいた方は、ぜひ気軽に一度お話しましょう！(ちなみに弊社積極採用中です！📣)
https://hackermeshi.com/talk-themes/649

私のTwitter(DM解放されています)や、Facebook Messengerに直接ご連絡いただくのもウェルカムです！🙌✨