ニフティグループアドベントカレンダーの14日目記事です。
昨日は@bobtzwさんのS3互換のオブジェクトストレージMinIOを利用したローカル開発環境のサンプルでした。
minioって初めて知りました！ ローカルでS3っぽいものを立てられるのってなにかと便利そうです。
はじめに
ニフティでスクラムマスターをしている@kanishionoriです。
今まで3チームほどスクラムを導入した経験があり、現在はスクラムマスター（以下SM）としてニフティニュースのチームに携わっています。
ちょうど今、新たにスクラムを導入しようとしているチームのサポートを行う予定があるので、今までのスクラム導入時にどうしてきたか、またリモートという状況における障壁や工夫についてまとめてみようと思います。
スクラムを導入する前に
チームメンバーによって解決手法や折衝案などは異なると思うのですが、これからスクラムを導入したいけどどうやればいいんだろうと不安に思っている人に読んでもらえれば幸いです。
もっとこうしたほうがいいよとか、ここで困ったよという事例があれば遠慮なくコメントください。
読むといい本
まずはSCRUM BOOT CAMP THE BOOKが絵も多く、読みやすくておすすめです。（新版の方は読んでないのですが）
これを読めば、スクラムイベントの一連の流れや、スプリント・デイリースクラム・レトロスペクティブ、PBI・SBIといったスクラム用語を聞いてもビビらない程度の理解が得られると思います。
実際にスクラムに取り組み始めてからの疑問解決や、より深い理解をしたいときはエッセンシャルスクラムを手引とすることが個人的にはおすすめです。
会社の理解があって、 スクラムマスター研修の講習をさせてくれそうなら、それが一番 です。（研修～SM認定まで20万ほどかかります。参考まで……）
自分は上記の本を読んだり https://www.ryuzee.com/ を見たりして、実際にスクラムを1年ほどやったあとに研修を受けましたが、本音を言うともっと早く研修に行けたほうがよかったです。
研修前は「本当にこれでスクラムになってるのかな？」という不安な気持ちの中でSMをやっていましたが、認定SMになってからは自信をもってスクラム推進活動に取り組めるようになりました。
いざスクラム導入
ある日を境に突然スクラム開発にしても、現場の負担や混乱も大きく人がついてきません。
あまり大きな無理がないように導入をしていくことで、 スクラムのメリット面を感じられる ように意識する必要があります。
スクラム導入時は、最低限以下を スクラムチーム全員 でやっておくとよいです。
- チームメンバー、上長、関係者へのスクラムの説明
- タイムボックスを決める
- カンバンをつくる
- ポイント見積もりをする
- チームの約束を決める
1.チームメンバー・上長・関係者へのスクラムの説明
上長・関係者へのスクラムの説明
ウォーターフォールからアジャイルへの転換も含む場合や、今までガントチャートだった仕事のやり方が変わることには、日々一緒に過ごしていないぶん、開発者よりも関係者のほうが戸惑う場合が多いです。
特に現在のようなリモート下だと、スクラムチーム以外のプロダクト関係者はカンバンやPBIを見ることを意識的にやってもらわないといけないので、早めに周知をはかりましょう。
チームメンバーへのフォロー
スクラムチームも、最初のころは慣れない単語やスクラムイベントに戸惑うこともあるかもしれません。
PBIによって明確に優先度をつけることや、バーンダウンチャートによる直感的な進捗確認などで、今までの仕事のやり方よりもメリットを感じてもらうことが大切です。
確かなメリットを感じられると自分で学習を始めてくれる人も何人かいたので、 自発的にスクラムについて学んでくれる状態 を目指せるとよいでしょう。
スクラムガイドは大した文章量ではないとはいえ、最初からスクラムチーム全員がきちんと読んでくることは期待しないほうがいいです。まずはメリットを体感し、興味を持ってもらうことが大切です。
2.タイムボックスを決める
スプリントの長さを決めましょう。確実に1つはリリースできる期間を目安とします。
一般的には2週間スプリントが採用されることが多いですが、なるべくリリース単位は細かく頻繁に振り返りができたほうがいいので、1週間スプリントが理想とされます。
個人的には、1週間だとスクラムイベントの頻度が多すぎる気がして2週間に落ち着いています。
スプリントの長さが決まると、ほかのスクラムイベントの長さも決まります。
下記の記事を参考に決めています。
https://www.ryuzee.com/contents/blog/7135
3.カンバンをつくる
リモートだと一番大変なポイントです。多くはJIRAかGitHubになると思います。Trelloなどのケースもあるかもしれません。
自分たちのチームでは、GitHubのプロジェクトボードをカンバンとして使っています。
ZenHubをしばらくつかった時期もあったのですが、PRの見づらさなど合わなかった部分もあり、GitHub Actionsをつかってタグ付けやレーン移動を自動化するなどだいぶ魔改造（？）してやっています。
オンラインでカンバンをつくるときに抑えると良いポイントは以下です。
- PBIレーンをつくる
- GitHubの場合はPBIレーンを新設、JIRAの場合はエピックが代替になる
- PBIとSBIのつながりが見えるようにする
- GitHubの場合は、SBIタスクの文中にPBIのタスクの参照のリンクを貼るとそれっぽい
- ひとつのPBIの大きさは最大でも1スプリントの25%ほどの規模感にする
- ※PBIの大きさの目安は、物理カンバンでも同じです
しつこくなりますが、リモートだとスクラムチーム外の関係者はカンバンを見に来る機会がふつうはありません。
URL共有やキャプチャ転載などどんな方法でもいいので、カンバンの状態、特にPBIの順番がどうなっているかを周囲に伝えるようにしたほうが良いです。
4.ポイント見積もりをする
カンバンができたら、PBIをSBIに分割し、ひとつひとつのタスクにポイントによる見積もりをしていきましょう。
フィボナッチ数列によるポイント見積もり（プランニングポーカー）は書籍でもWEBでも十分に説明されているのでここでは省略しますが、リモート環境下だとビデオオンでも「せーの」でカードを出す見積もりはかなりやりにくいです。
自分たちはこちらを参考にJamBordでプランニングポーカーをしています。
https://blog.shibayu36.org/entry/2020/09/02/170308
オンラインでプランニングポーカーができるサービスはいろいろありますが、結局これが一番シンプルでした。
人によってかかるポイントの大きさは違いますが、ある程度慣れている人がやる前提で見積もるというように、ポイントを測る基準を統一しておきましょう。
この見積もりで意識すべき点は、ひとつひとつのタスクが2か3というのはそこまで大きな問題ではないので、数字に囚われすぎないようにしましょう。
（1スプリントで消化できるポイント数がわからないと見通しが立てられませんが、1スプリントの消化ptが80ptなのか85ptなのかというのは重要なことではない、という意味で言っています）
このタスクでは何をやらなければいけないのかという認識をチームメンバー同士で合わせるために見積もりをするという意味合いが強いです。
5.チームの約束（working agreement）を決める
意外と見落とされやすかったり決めていないチームも多いのですが、あったほうが一体感がでます。
タスクを追加したらslackに一言書こうといった実務的な約束でもいいし、毎月一緒にボードゲームをしよう、みたいな約束でもいいです。
毎回レトロスペクティブのたびに、数十秒でもいいのでチームの約束がこのままでいいかを点検します。
チームの弱点や長所を変えたり伸ばしていけるような約束に日々進化できると素晴らしいです。
さいごに
ひとまず上記5項目をやっていくことで、カンバンによるタスク管理と、スプリントという時間の区切りの概念、そしてなによりこの共同作業を通じて 自分たちはチームだ という意識が導入され始めると思います。
この先に、チーム開発をしているときには個人個人の評価はどうすればいいとか、チケットを上から順にとっていきたいけどメンバーのスキルセットやエンジニアリングの熟練度が違いすぎて属人化がなかなか解消できないとか、スクラム導入によって今までには見えてなかった悩みも出てくると思います。
新たな課題の発見は、チームをさらなる成長に導くための足がかりです。
困難なこともあれ、チームが成熟するにつれ仕事の楽しさも上がっていきます。
チーム開発をエンジョイしたい人は、ぜひ積極的にスクラムを取り入れてみてください。
一緒にスクラム開発やりたい人も募集しています！
ニフティニュースは現在Reactへの環境移行をがんばってるので、Reactが得意な人や定期的にオンラインドミニオンがやりたい人は（？）ぜひ来てください!!!
ニフティ株式会社採用情報
明日は@hajimeteさんの回です。
ちょうどリモートでのプランニングポーカーに関係しそうなので、楽しみです！