スクラム開発ってなんかよさそうじゃん?

いきなり怒られそうなサブタイトルが出てきましたが、スクラム開発ってなんか良いらしいって話は聞いたことありますよね。

やってみたいけど、どうやったらいいかわからないとか、
スクラム開発自体は理解できたけど、今のチームにどのように導入すればよいかわからない。

っていう声がPCを通して、今にも聞こえてきそうです。

自分も、転職する事になり、新しい会社では特にスクラム開発は行っていませんでした。
ここはスクラム開発の導入チャンスだと捉え、導入推進を進めてきました(現状も進めています)

その記録をなるべくわかりやすい形で解説できればと思います。

対象者

- スクラム開発はどういうものかわかっている
- これからチームにスクラム開発を導入したい
- どうやってスクラム開発を導入すればよいかわからない

この記事で書かないこと

- スクラム開発の基本的な情報

まず最初に導入していきやすいもの

スクラム開発をチームに導入するにあたって、ます最初に思うのが、
「まずどっからやればいいんじゃい」
ということだと思います。

プロダクトバックログを作る?
ストーリーポイントを使ってリファインメントを行う?
デイリースクラムの導入?

諸説あるとは思いますが、自分が導入しやすいのと思ったのは**レトロスペクティブ(ふりかえり)**の時間を作るということです。

レトロスペクティブを行うときは以下のような手順を追って行います。

1. 決まった時間にレトロスペクティブの時間を設定する
2. 事前にKPT(KEEP / PROBLEM / TRY)を集めておく
3. 集まったKPTをもとに、振り返りを行う
4. 次のレトロスペクティブまでに行うこと(TRY)を決めておく
5. 軽く今回のレトロスペクティブがどうだったかを話し合う

という手順を踏んで導入を行います。
一つ一つどのように行っていくかを説明していきます。

1. 決まった時間にレトロスペクティブの時間を設定する

私が所属するチームでは2週間に1回のレトロスペクティブを行っています。
本来はイテレーション(スプリント)ごとに行うべきですが、まだその期間が決まっていないで、なんとなく決めてしまって良いと思います。
メンバーの負担にならない程度、ちゃんとKPTが集まりそうな期間で設定したほうが良いと思います。

レトロスペクティブの時間はなるべく対面で話したほうが、意見も出やすく、話しやすいと思います。
ファシリテーターを設定して、意見を均等に吸い出すのも大事かと思います。

2. 事前にKPT(KEEP / PROBLEM / TRY)を集めておく

私が所属するチームではKPTで意見を出すことにしています。
KPTとは
K：keep = 続けたようが良いこと
P：problem = 良くなったこと
T：try = やりたいこと、problemに対しての改善策
を書いていきます。

また、KPTを書き出すツールとしては、ふせん等がよく用いられます。

ここでポイントとなるのは**事前**にKPTを集められる状態にしておく、ということです。
というのも、レトロスペクティブの時間にメンバーへ「KPTを書いてください!」と言っても、1週間もしくは2週間の出来事を思い出して書いて貰う必要があります。
人間の記憶というのは曖昧で、その時思っていたことを忘れてしまうので、感じたその時に記録しておけるツールが必要ということです。

そこで、slackのワークフローを使用した、KPTチャンネルを作ることをおすすめしています。



slackのワークフローを使用して、チャンネルにK,P,Tを投稿しておけるようにしておきます。


↑実際の投稿画面



↑投稿された様子

このようにしておけば、KTPの収集がslack内で済ませることができるので、ツールをまたがずに管理することができます。

また、投稿しただけだと、KPTを振り返るときにわかりづらくなってしまうので、スプレッドシートに整理し直して振り返ったほうが良いと思います。

参考:
https://qiita.com/kan_dai/items/c0c548cbf716ad392fe7

3.集まったKPTをもとに、振り返りを行う

KPTが集まったら、実際に振り返りを行っていきましょう。

基本的には、前回のTRY達成確認->K->P->Tの順で振り返りましょう。
また、時間をかけようと思えばいくらでもかけられるので、時間を決めて振り返りをしていきましょう。

KEEPに関しては、他のメンバーがやってよかったものなどなので、それを聞いて、実践をしたり、新しい発見として取り入れていきましょう。
PROBLEMに関しては、どこが良くなかったのか、どうすれば解決するのか、誰がいつまでに解決するように動くのかを考えましょう。

4. 次のレトロスペクティブまでに行うこと(TRY)を決めておく

PROBLEMで考えた結果をTRYとして、また、なるべくバイネームで残しておくと良いと思います。

5. 軽く今回のレトロスペクティブがどうだったかを話し合う

導入したてのレトロスペクティブの場合だと、まだやり方が醸成しきっていない場合があると思います。
なので、レトロスペクティブ後にこの話し合いは効率的にできていたか、やりにくいところはなかったか、どうすれば良くなるか、誰が良くするか等を話し合ったほうがより良いレトロスペクティブになると思います。

まとめ

レトロスペクティブと聞くと、何だそれは!となりそうですが、結局は反省会になります。
それを形式化して、効率的にPDCAを回せるようにしているようなものだと私は思っています。

反省会のようなものはやっているよ、というところであればより導入しやすいと思うので、スクラム開発の第一歩として、レトロスペクティブ(ふりかえり)を導入してみてはいかがでしょうか。

次回はデイリースクラム編でお会いしましょう!!

参考献文

https://www.ryuzee.com/
https://amzn.to/2zcjOeQ