改善サイクルをしっかりと回し続けるのって難しいですよね。
どんなアクションを取れば良いのか・・・となることも少なくないと思っています。
結局のところ、チーム内で議論をして合意の取れたものをすべきですが、
世の先輩諸兄達は、どんなプロブレムに対して、どんなトライを出してるのか知りたいなーと思い、
質問するならまずは自己開示、ということで書きます。
プロジェクトの呼称欲しくない？
→ プロジェクト名案を持ち寄りで決定
とあるプロジェクトの後続だったため、以前のプロジェクト名に"新"を付けていましたが、
テンション上がらないし、何より新旧の呼び方は会話時に混乱を呼びますよね・・・。
ので、プロジェクト名のアイディアをメンバー持ち寄りで決めました。
チーム内だけでなく、連携する部署にも浸透させることで会議や仕様書などで混乱を招くことは無くなりました。
ソースコードに統一感がない
→ 開発ルールを制定
命名規則や、コミットメッセージあるいはプルリクエストに記載すべきこと、などなどバラバラで、
PRのレビュー時や改修時に必要以上に時間がかかっていたため、開発ルールをチームの合意のもとで制定しました。
制定した内容は社内ドキュメントにまとめて、随時更新をかけています。
命名規則は開発時やレビュー時の迷いを減らし、プルリクエストの記載はレビューすべきポイントが明確になり、
全体的に開発速度の向上へと繋がりました。
デグレが多い
→ テストの拡充
→ ステータスチェック整備
恥ずかしながらステータスチェックどころかテストもなかったので、検証は時間かかるしデグレは頻発するし、、、という状況でした。
テストがないのに走らせても仕方がないので、大きく分けて、テストの拡充とステータスチェックの整備の二段階で対応をしました。
現在は、GitHubActionsでステータスチェックをしており、CodeClimateによる静的解析とカバレッジ収集を行っています。
障害or問い合わせ対応が属人化してる
→ 対応フローをドキュメント化
→ 次回発生時ペアで対応
とっても優秀なリーダーが全部巻き取るマンだったため、各種問い合わせ等の対応方法を他のメンバーが知らず、彼が休むと不安になる状態でした。
全部巻き取るリーダーから全部巻き取ろうというとっても優秀なメンバーの愛が織り成したプロブレムとトライです。
対応フローをドキュメント化して再現性を持たせた上で、
発生時にリーダーとメンバー1人がペアで対応を行うことで方法の定着を目指しました。
なお、窓口はリーダーというのは継続しました。
レビューがつらい
→ 実装前に仕様書の読み合わせ
→ モブプロで開発
→ レビュー会を実施
プロジェクトの特性上、1つのPRが肥大化しやすくレビューの負担が大きい状態でした。
要因の一つに仕様の複雑さがあったため、
実装前に仕様書の作成者とメンバーで仕様書の読み合わせを行いました。
実装前から「ここのロジックは難しくなりそうだ」とか「こういう風に実装した方がいいかもね」という会話がされるようになり、
レビュー時にもコードと仕様書を照らし合わせる工数が減り、レビューの負担はだいぶ軽減されました。
また、大枠を実装する際には2~3人程度でペアプロないしはモブプロで実装を行うようにもしました。
これも、指摘がリアルタイムで行えるため、手戻りの減少に繋がり、（精神的に？）だいぶ効果あったかと思います。
それでも理解の難しい部分や影響範囲の大きい箇所については別途レビュー会を実施することもありました。
ライブラリのサポート終わりそう
→ dependabotの導入
→ LTSをGoogleカレンダーに登録
→ ストーリーにあらかじめ追加
Node.jsなど主要なバージョンは追随していたものの、ライブラリのバージョンはビハインドしていました。
GitHubを利用していたのでdependabotの設定を行い、月初にチェックが走るようにしました。
また、Node.jsなどのLTSはカレンダーに登録をして見える化を行うと同時に、いつどれに上げるかというタスクをあらかじめiceboxに積むようにしました。
なお、ライブラリの更新にはnpm-check-updatesも利用しています。
レトロする頃には振り返る内容を忘れてる
→ 振り返りシートをスプリント頭に用意する
木曜始まり水曜終わりの1週間でスプリントを回していますが、
記憶力は悲しいもので。レトロスペクティブ時に「今週何あったっけ・・・」となりがち。
当時KPTを採用していましたが、
「これ改善したい！」と思ったその時に記載しておけるように、シートをスプリントの開始時に作成するようにしました。
タイムラインのようなアクティビティをやるのもありですが、もうちょっとライトに改善したいという想いもあり。
個々人でメモを控えておくのも良いですが、みんなが見えるところに書くことで他のメンバーの意識も高まる効果があったかなと思います。
スクラムイベントをもっと楽しいものにしたい
→ 朝会に一言Q&A的なアイスブレイク導入
→ レビュー前にプライベート込みでどんな一週間だったか発表するアイスブレイク導入
各種スクラムイベントが作業的になっており、もっとワイワイやりたいよね、と出てきたプロブレムです。
リモートワークゆえの問題かも知れませんね。
毎朝の朝会時には、「コンビニに行ったらつい買っちゃうものは？」とか「好きなショートカットキーは？」などの質問を全員に投げかけ答えるということをしました。
全員が挨拶以外の何かしらを発言するというのが良かったですね。
質問の内容は、オリジナルで考えたメンバーに聞いてみたいこともあれば、Collaさんの質問を流用したりもしました。
レビューとレトロの前には、「今スプリントの所感」をお互い発表していました。
と言っても、週末の釣りが調子悪かった、とか、キッチンでゆで卵作ろうとしたら破裂させた、とかそんな所感（？）も多かったです。
チーム内で気軽に話せる場が欲しい
→ チームスレを自動生成
→ 雑談推奨
実装の相談を気軽にしたい、というプロブレムから。
これもリモートワークゆえの問題ですかね。オフラインで働いていた時はちょっとした雑談もデスクでされてましたから。
Slackbotのリマインダーを利用して、チーム専用のスレッドを毎朝自動生成されるように設定しました。
そのスレッド内では雑談OK、相談OK、なんでもOKという感じで、毎日30~50程度の会話がされています。100近い日も。
「こんなこと相談していいのかな」みたいな質問の心理障壁は無くなったと思います。
最近残業多くなってる
→ ノー残業Dayの制定
→ ノー残業大臣任命
一時期メンバー全員の残業が増えてきていたタイミングがありました。
必要な残業もありますが、基本的には良いことないのでやめよう、となり、
毎週水曜日をノー残業Dayとして、それが守られているかのチェックをノー残業大臣が行うことにしました。
一見ふざけたアクションですが、かなり効果がありました。
ノー残業Dayだけでなく他の曜日の残業も減り、
リーダーに至っては「残業減ってから息子と過ごす時間が増えてQOL爆上がりです」とかテンプレートみたいなことを言い出す始末でした。
KPT機能しなくなってきた
→ 振り返りの振り返り実施
→ その他の振り返り手法を持ち回りで試験導入
約一年ほど振り返りの手法としてKPTを採用していましたが、一年経つぐらいから機能しなくなってきました。
こちらの記事が非常に刺さる状態でした。
上記の記事内にもありますが、
「なぜ振り返りをするのか」「振り返りに何を期待しているのか」「これまでの振り返りはどうだったのか」と言った点をまずチームで振り返りました。
また、KPT以外の手法を持ち回りで試験導入をすることにしました。
FunDoneLearnや555、小さなカイゼンアイデアなどなど。
視点が変わり、見えてくるものも変わり、なかなかに刺激的でした。
振り返り手法はこのスライドを参考に試していました。
最後に
ここに挙げたのはほんの一部且つ簡略化したものですが、このような形で改善を繰り返しています。
皆様の、こんな面白いアクションがあった、とか、これはどこのチームにも活かせると思う、といった改善アイディアがあればコメントいただけると嬉しいです。