アジャイル2年生のチームでスクラムガイドの読書会を完走した話

こんにちは、CX事業本部のKyoです。

私たちの開発チームでは一ヶ月半ほどかけて開発の手法の見直しを行い、スクラムへ移行しました。この際にチーム内で共通の言語や価値観を獲得するためにスクラムガイドの読書会を行いました。

登場人物

開発チーム

• お客様とクラスメソッド(以下CMと表記)の混成チーム
  • お客様: 4名, CM: 2名
    • 双方の開発者がPull Requestを上げてレビューしあう関係
• お客様は元々ウォーターフォール型の組織
  • CMと一年半ほど前にプロジェクトを始め、アジャイルなスタイルを導入
    • なのでアジャイル2年生
• 開発手法は諸事情あって独自スタイルのアジャイル
  • 部分的にスクラムの用語が使われているが、スクラム本来のものとはニュアンスが異なる

アジャイルとスクラムの関係はこちらをご覧ください。

私

• プロジェクトには約6ヶ月前に途中から開発者として参画
  • CM側でアジャイルを牽引してきたメンバーとの入れ替わり
• スクラム歴3年ほど
  • 開発手法の見直しに伴いスクラムマスターを担当
    • 開発者ロールも引き続き兼業する形
• 読書会等でスクラムガイドに向き合うのは確か4回目

スクラムに触れたての頃にもスクラムガイドについてのブログを書いていました（当時とはロールも変わっています）。

改めてスクラムガイドとは

• Ken SchwaberとJeff Sutherlandによって書かれたスクラムのルールブック
  • 基本的な理念、価値、方法などが書かれている
  • 今回読んだのは2020年11⽉版
• PDFで18ページとコンパクト
  • 表紙や目次などを除くともっと少ない
• ただし行間が多いので初見で読むのはそこそこ大変
  • シンプルだけどイージーではない（と思う）

読書会のスタイル

負担が少ない形を目指し、シンプルなスタイルで行いました。

• 参加者
  • チームメンバー + オブザーバー (CMのマネージャー。認定スクラムマスター)
• 開催
  • 全6回
    • 1時間 / 週 ＠Slackのハドル
      • 毎週水曜日の同じ時間
• 進め方
  • 担当者が1-2パラグラフを音読 (事前準備は不要)
    • 他のメンバー含めて気になった部分をピックアップし、以下のような掘り下げ
      • こういう理解であってる？
      • 自分たちのチームでいうとこれだよね
      • 昔こんな経験があって…
  • 次のパラグラフに移る
  • 会の最後に次の担当者を指名する

結果

4回（一ヶ月）ぐらいで終わるだろう、と考えていたものの全6回の開催となりました。ディスカッションはもちろんの事、昔話に花が咲いたり、スクラムガイドの背景を考察したりとチームビルディングとしても有効だったと思います。

理解の方はというと、読書会のふりかえりの中でもふわっとしていたイメージを明確に出来たという意見を複数メンバーからいただけました。

実際、PBIがどんな価値を生むかを重視するようになったり、完成の定義をしっかり読み合わせるようになったり、フロー効率重視のためのペアワークが増えたり、と共通の価値観に基づいて行動できることが増えているように感じます ^*1。

よって、読書会の狙いは達成できたと思います。

チーム内で共通の言語や価値観を獲得する

おわりに

プロダクトの未来を話し合う合宿で、「僕たちアジャイル2年生、（開発手法について）伸び代しかない」という話をした際に、やってみようと言ってくれたお客様サイドのメンバーにこの場を借りて感謝します。

スクラムガイドは守破離の守であり、我流でやっているチームが一皮剝けるにはいい道しるべになると改めて思いました。開発者にとってはAWSのベストプラクティスを知るために公式ドキュメントを読むイメージ、といえば伝わるでしょうか。

一方でスクラムの導入にハードルがあることも感じます。実際、2013年7月版のスクラムガイドには「軽量、理解が容易、習得は困難」という表現もあります。 それでもなお、以下のブログにあるように、まずは基本を通して価値観や哲学を身につけることが重要であると考えています。

「会社のやり方に合わないので全部変えちゃう」とか「できないから変えちゃう」というのでは、手法を導入する意味がわからなくなってしまうからです。乗り越えてから、徐々に自分たちのやり方に変えていくのが良いと思います。

これからもDon't DO Agile, BE Agile.を胸にカイゼンを続けていきたいと思います。

脚注