スクラムは実際にやり始めると、すぐに下記のような壁に、ぶつかるんじゃないかと思ってます。
完成の定義
プロダクトとして定めた「リリース判断可能なプロダクト」を作成するために実施しなければいけないことの一覧。
受け入れ基準
プロダクトオーナーの視点から何を持ってプロダクトバックログの項目が完成したかを確認するための基準。
相対見積り
プロダクトバックログ項目の見積もる際に、具体的な人月や人日で見積もるのではなく、小さめのプロダクトバックログ項目と比較してその何倍なのかという観点で見積もる方法。
ベロシティ
開発チームの速度を表す指標で、スプリントで「完成」したプロダクトバックログ項目の見積りポイントの合計値のことである。
スプリントバーンダウンチャート
スプリントの進捗を可視化し課題発見のきっかけにするためのチャート。
スプリントバックログ
スプリントで実施するプロダクトバックログ項目のサブセットと、それを分析し具体的なタスクに落とし込んだもの。
5分で分かるスクラム用語集 – Ryuzee.com
上記は簡単な引用なので、詳しい説明は引用元の「5分で分かるスクラム用語集 – Ryuzee.com」を確認して下さい。
ただし、ここでのスクラムの適用は「ソフトウェア開発」ではなく、下記で説明している「経営(組織運営)」です。なので、「ソフトウェア開発」に比べ、初期段階では、より緩くできたり、スキップも可能で、その分、導入のハードルも下げれるんじゃないかと考えています。
ということで、表記の「テレワーク時代の形から入る簡単スクラム」を検討してみました！
ロール(スクラムチーム)
まずは3〜5人のスクラムチームを編成します。(5人までにしている理由は下記となります)
一番スクラムに詳しい人が、必然的にスクラムマスターになると思います。次にプロダクトオーナー(ここでの用途だと「プロダクト」に違和感ありますが)ですが、これはプロジェクトの責任者になるはずです。例えば、プロジェクトならプロジェクトリーダー/マネージャー、組織なら組織の長、経営なら社長などになるはずです。そして残りがチームメンバーとなります。
ここで注意点ですが、初めてのスクラムでは、「スクラムやりたい人 = 責任者」の場合が多いんじゃないかと思っています。その場合、プロダクトオーナーとスクラムマスターを兼任したくなりますが、それだけは厳禁です。無理やりにでも別々の人になるように頑張りましょう。
厳禁である理由は抽象的に言うと「不完全な神」ができてしまい、その神を誰も止めることができなくなってしまうからだと思います。具体的な理由は下記に詳しく説明されています。
イベント
まず、初めてのスクラムではスプリント期間は、迷わず1週間にしとけばいいと思います。ちゃんとスクラムやってれば、今後も1週間より長くすることは無いと思います。(週単位で考え動く癖をつける意味合いもあります)
スクラムのイベントは下記のタイミングで実施すると、週のサイクルにもフィットしやすいので、やりやすいと思います。
- 月曜日: スプリントプランニング
- 水曜日: 中間レビュー
- 金曜日: スプリントレビュー・スプリントレトロスペクティブ
- 毎日: デイリースクラム
ここで「中間レビュー」と言う謎のイベントが登場してます。これは、スプリントレビューに向けてのアウトプットの、途中経過の確認となります。テレワークで、より個々の状況が分かりにくくなっているので、いきなりアレンジしてしまいました。。。
上記のイベントをGoogleカレンダーなどに繰り返して登録し、Zoom等のURLを記載しておけば、イベントまわりは終了です。とても簡単です！
ちなみに、デイリースクラムは下記で紹介したGeekbotを利用して、ミーティングではなく非同期で実施る方法もあります。こちらの方が敷居は低いかもしれません。
作成物
繰り返しになりますが、ここでのスクラムの対象は「「経営(組織運営)」です。ですので、スプリントでの成果物は、その「計画と報告の資料」となります。そして、そのアウトプット先は、下記で紹介したように、1つのGoogleスライドとします。
施策と、その状況も報告対象になるので、後述するプロダクトバックログ(施策)も上述のGoogleスライドで、一緒に管理するようにします。
プロダクトバックログ
目標を達成するための施策がプロダクトバックログになります。スプリント内でアウトプットできそうな粒度で追加していきます。プロダクトバックログが、ある程度の数になったら、エピックとしてグルーピングしていくと管理がしやすくなると思います。
本当は、プロダクトバックログをスプリントバックログに細分化してスプリントを進めるのですが、「まずは簡単に」と言うことで、「プロダクトバックログ = スプリントバックログ」で進めちゃう感じでも、いいんじゃ無いかと思ってます。
インクリメント
スプリントでの成果を、上記の「計画と報告の資料」に反映したものとなります。スプリントレビューが終わり最終調整の後、GoogleスライドからPDF化して、ステークホルダーに配布(と必要に応じて説明)します。
ひとまず忘れること
最初に説明した用語は忘れましょう。スクラムはスプリントごとに改善させていくものなので、その改善の過程で上記の用語に一つずつ、焦らずにチャレンジしていけばいいと思ってます。無理すると、多分チームがついてこれず、スクラムのためのスクラムになってしまい、本末転倒する可能性が高くなると思います。
ツール
ここまでで登場したツールを改めてまとめておきます。
- Googleスライド
- 最終成果物である「計画と報告の資料」のアウトプット先です。
- Googleカレンダー
- スクラムのイベントを登録します。
- Zoom
- テレワークでのイベント(ミーティング)に利用します。
- Slack
- チーム内の文字ベースのコミュニケーションに利用します。簡易的な音声ベースのコミュニケーションにも利用できます。
- Geekbot
- デイリースクラムを非同期に実施するのに利用します。
最後に
週次でプロジェクトの進行を管理するには、スクラムは非常に有用な手法だと思っています。そして対象のプロジェクトはソフトウェア開発だけに限らず、全ての種類のプロジェクトに適用することが可能なはずです。さらに、ソフトウェア開発でなければ、必要とされる厳密性も低くなり、より簡易化して、スクラムにチャレンジすることもできるはずです。一旦、スクラムが回りだせば、スプリントごとの改善により、徐々に本来のスクラムの形に近づいていきます。
今回は「ひとまず忘れた」内容も、どこかでチャレンジし、また、このブログで紹介できればと思っています！
