Stylez Advent Calendar 2020 18日目です！
まえがき
日本でもアジャイル開発取り入れているところ増えてきているみたいですね。
気になっている方も多いのではないでしょうか？
でも、アジャイル開発の考え方ってウォーターフォール開発とかなり違うので、いきなり案件で取り入れるのってなかなかハードルが高いですよね。
そこで、アジャイル開発の波に乗るため、2020年5月から「スクラムによるアジャイル開発を学ぶための勉強会」を始めました。
同じようにはじめの一歩に悩んでいる方の参考になれば嬉しいです！
アジャイル、スクラムに関して学ぼう
右も左もわからないまま、そしてコロナの影響でリモートでの勉強会がスタート。
「とりあえず理解を深めていってみよう！」とネットの記事をベースにして、アジャイル開発やスクラムにおけるイベント、役割などについてそれぞれのメンバーで疑問点を上げながら議論をしました。
よく参考にさせていただいた記事は↓です。
スクラムの原則を、いかにして実践するか - 現場にありがちな悩みを吉羽龍太郎に相談してみた
アジャイル開発の進め方
勉強会を進めていくと、どうしても「実際にはどうやるのか？」「このイベントの目的は？」という疑問が残ってしまい…。
ならば実際にスクラムしてみよう！！ということで早々に座学を切り上げて、スクラムチャレンジ開始です。
スクラムチャレンジ
メンバーの中からPO役を出し架空のプロジェクトを立ち上げることにしました。
リモートでの勉強会のため、オンラインホワイトボードとして「Miro」を使用しています。
現時点で実施できたのは以下です。
- チームビルディング
- スプリントプランニング
ちなみに、1度仕切り直しているので、今は2回目のチャレンジ中です！
チームビルディング
チームビルディングとして、インセプションデッキにチャレンジしました。
座学の段階では正直「インセプションデッキってなんでやるの？」と思っておりました…。
実際にやってみると、作り上げたインセプションデッキ自体というよりも、インセプションデッキを作る過程に大きな意味があるのだと気づけました。
進め方としては、インセプションデッキの各項目ごとに、それぞれが考えた内容をMiro上の付箋で行き、全員分でそろってからなぜこう考えたかを話し合い、全員での結論を残しました。
ウォーターフォール開発をしていると、設計書に書かれていることを実装するだけ、テストするだけになってしまい、自分が作っているシステムがどのように使われるのかを意識しなくなってしまう方もいるのではないかと思います。
ですが、インセプションデッキを作ることによって、それぞれがこのプロジェクトの目的を考えることができるのだということに気づきました。
そのプロセスを経て作り上げたからこそ共通認識を残しておくことによって、後々メンバー間でズレが発生した時に、見返せるものになるのだとも感じました。
1回目ではインセプションデッキの作成にとても時間がかかりましたが、上記のことに気づけたこともあり2回目に作成した際はかなりサクサクと進めることができました！
スプリントプランニング
プロダクトバックログやユーザーストーリーはPO役のメンバーにざっくりとしたものを準備してもらいました。
開発者役のメンバーはプロダクトバックログアイテムに対し、不明点を質問したり見積もりをしたりしていきました。
1回目のスプリントプランニング
Jiraを使いながらスプリントプランニングにチャレンジしてみました。
この時はウォーターフォール的な「挙がっている要望をすべて実装する」という意識が抜けきれなかったり、タスクを細分化する際に粒度をどうするべきかいまいちつかめず時間がかかってしまい、挙句には細かすぎるタスクを作ってしまっていました。
今思い返すと「どうするべきなのか？」「何が正しいのか？」などの疑問もあり、お手本の型に自分達のやり方をはめようとする意識が強かったように思います。
ここで、このやり方ではうまくいかないと感じ、一旦仕切り直しをすることに決めました。
2回目のスプリントプランニング
2回目のチャレンジでは、JiraではなくGitLabのissueボードを使っています。
1回目とは異なりPO役に「最初のリリースで求めるべきことはなにか？」を聞き、
PO役からは「最低限の機能でも動かせれば構わないので早くリリースしてユーザーに触ってみてほしい」と回答をもらうところからスタートしました。
POが最も望んでいるのが「リリースまでのスピード」であったため、準備してあったプロダクトバックログに対し、「システムとして動かすために必要なもの」「あった方が良いけど、なくてもシステムは動くもの」の整理をして優先順位の見直しを行いました。
1回目にスプリントプランニングをした時にはできていなかった、POも含めて全員が同じゴールを見ながら動くということができているだけで、勉強会の雰囲気も会話のスムーズさも全く異なっていました。
さらに、スプリントバックログを作るためにタスクの細分化をする際も、「もしかしたら少し粒度が大きいかもしれないけれど、これで1回やってみよう」という流れができていました。
自分達を型にはめようという意識から、自分達の型を作りはじめようという意識に変わってきているのだと思います。
見積もりの方法は1回目、2回目ともプランニングポーカーの手法を採用しています。
話し合いの中で気を付けていたこと
話し合いをしていると、いくつか良くない状況になっていることがありました。
その場合、どのように工夫していたかをお伝えします。
1. 全員が発言できる・発言する場であること
勉強会の初めのころは各々が自由に発言していましたが、いつも同じ人が中心となって発言しているような状況になっていました。
こうなると自分で考えて意見を出す機会が減ってしまい、メンバーの誰かが決めたことについていくだけになってしまいます。
これを防ぐために、私たちの勉強会ではファシリテーターをローテーションで行うようにしました。
ファシリテーターの役割を取り入れてから、発言量の偏りがだんだんと解消され、さまざまな意見が飛び交うようになりました。
また、発言しやすい場を維持するため、心理的安全性に関する記事を勉強会開始時に全員で読み合わせしています。
https://www.dodadsj.com/content/190318_psychological-safety/
2. 誰かの発言力が強くなりすぎないようにする
全員で話し合って結論を出すのではなく、「〇〇さんが言っているから」というような状況のことです。
こちらも1と同じように誰かが決めたことについていくだけになってしまいます。
私たちの場合は、普段から意見が採用されやすい人は自分の意見があってもまずは聞き役に徹してみたり、「〇〇さんはどう思いますか？」や「みんなはどう思っているか？」などの声掛けを意識するような工夫を取り入れてみました。
そうすることで、ベテランも若手も関係なく色んな人の意見が採用されるようになり、それぞれが積極的に考えて発言するモチベーションアップに繋がりました。
3. 誰かに答えを求めない
ついつい誰かに答えを求めてしがいがちな方、いらっしゃいますよね。（私もそうです…）
でも、誰かが答えを持っているとは限りませんし、「これってどういうことですか？」という発言をする人が増えると2の状況になりかねません。
なので、私たちの勉強会では何か疑問があったときの質問のあげ方を工夫しました。
「これってどういうことですか？」という質問の仕方だった時は誰かが考えて答えているだけでしたが、「この件について、自分は〇〇だと思っているけど、みんなはどうか？」という言い方にしたところ、全員が自分の意見を言って話し合うきっかけに変わりました。
実際にスクラムをやってみた感想
参加メンバーは普段PMやPLをやっている人、開発経験が浅い人、ウォーターフォール開発歴が長い人、短い人などスキルにかなりばらつきがあります。
きっと感じたことってそれぞれの立場で違うはず…だと思うので、やってみた感想をざっくり聞いてみました！！
それぞれの開発歴は↓のような感じです。（それぞれがチャットのアイコンにしている画像を拝借しました）
実際にやったことで気づけた点
ウォーターフォールとの違いについて
最後に
勉強会を始めたころは、スクラムの手法としての部分にのみ着目していました。
その結果が1回目のスプリントプランニングの失敗です。
そして、2回目のスプリントプランニングの部分で書いたように、「全員が同じゴールを見ることの大切さ」「自分達で経験しながら型を作っていこうという意識」を得られたのは、数人で集まってスクラムをやってみたからこそだと思っています。
いままでのやり方を変えるのはとても大変です。
それでも開発手法の選択肢を増やしたくて、悩んでいる方はこのようなチャレンジをしてみてはいかがでしょうか？