株式会社ベーシック CTO の@zaruです。こんにちは。2ヶ月ほど前に新米スクラムマスターがスクラムを導入してみたという記事を書きました。今回はこの2ヶ月間に行ったスクラム開発の改善や、それを他の部署に広めていっている話を書こうと思います。

スクラム開発の改善

スクラム開発を導入する時、スクラムやアジャイルの考え方に遵守する必要があると強く思っていました。というのもスクラム開発について調べていくと、いわゆるなんちゃってスクラムに対しての批判が多く目についたのと、郷に入りては郷に従えの考えでまずは倣ってみようと思ったからです。

実際にスプリントを数回やってみて今実感していることは 自律的なチーム ないしは自己組織化されたチームになっているのであれば、気軽にマイナーチェンジして自分たちに合ったやり方をやるのが良いと考えています。固執しすぎない。

Don't just do agile. Be agile. という言葉の通り、どうやるかではなく、どう考えるかが大事だと思うので、スクラムは絶対こうしないといけない！みたいなものにとらわれる必要はないと思います。

ただしカオスすぎる現状があるのであれば、フレームワークという強制力で変化を促すのは効果的だと思います。

改善したこと

ポストイットの書き方

すごい細かくて小さいことだけど、カンバンに貼ってるポストイットの書き方を少しずつ改善していきました。

見積もった時間と実際の実績時間を書くことで見積もり精度を俯瞰して見られるようにしました。厳密に管理したいわけではないので、単純に予測よりも大きかったのか小さかったのかが認識できれば良いと思います。

コードレビューの見積もり

コードレビューの時間見積もりは、作業タスクの見積もり時間の15%とすることにしました。例えばあるバックログを完成させるのに10時間必要であれば、コードレビューは1.5時間です。

コードレビューでどこまで見るかというのはメンバーによってマチマチになってしまうので、時間を決めてその中で見られる範囲にすることにしました（QAチームが別でいるので決められた品質チェック工程が既にあるのも大きい）。

開発チームやプロジェクトによっては、コードレビューの定義をしっかり作ったほうが良いとは思います。

バーンダウンチャートをやめる

当初、バーンダウンチャートを書いていましたが直近のスプリントでは書きませんでした。というのも、基本的に理想線通りにはいかないし、バーンダウンチャートを見ずともカンバンを見ていれば、どの程度の遅れがあるのかはなんとなく分かると思ったからです。必要ないことはやらない。これは運用の上で大事なことだと考えています。

まだなくしてみて1回しかやっていないので、今後の様子を見て復活させることもあるかもしれません。

スプリント計画会議前の下調べ

今スクラムをやっているプロジェクトは開発チームが11名と大所帯です。プロジェクト自体もそれなりの規模のシステムで、プロダクトバックログの数は多いし、技術的に込み入った内容もそれなりにあります。

スプリント計画会議で初めて内容をプロダクトオーナーから説明をされても、技術的な壁であったり、仕様の矛盾であったりで議論が四散してまとまりにくい傾向がありました。

そこでスプリント計画会議をやる前に、各自で目を通しておいて疑問に思う点があればプロダクトオーナーに確認をして、プロダクトバックログの質を上げておくということをやりました。

こうすることで完全ではないにしろ良くなってきたと思います。

完成の定義の変更

完成の定義はスプリントを重ねていった結果、以下のように変更をしました。

  • 初期：プルリクを作ったら完成
  • 前　：コードレビューと修正が終わったら完成
  • 今　：プロダクトオーナーのチェックが通ったら完成

プルリクを作ったら完成というのは、かなりゆるかったですね。これだとレビュー・修正などの工程がなく、スプリント上では終わっていても実作業はまだかなりあるという状況を生み出してしまいました。

そこで次のスプリントではコードレビューと修正が終わったら完了という定義にしました。これによって、今までコードレビューがQAチームや特定のメンバーにだけ頼っていたのを、開発チーム全員でコードレビューに取り組めるようになりました。

これは振り返りのKPTの中で開発チームメンバーから「コードレビューがしたい」という要望を取り入れた形になります。

最近ではプロダクトオーナーのチェックを通過したものを完成の定義にしています。こうすることで、よりリリースの品質に近い形で完了とすることができました。ただ、プロダクトオーナーチェックの工程が、煩雑なので改善の余地が大きい所です。

まだ迷っているところ

デザイナーさんをスクラムの開発チームにどう入れるかというのが悩みポイントで、開発工程の中で常にデザイナーさんが関わるわけではなく、ピンポイントもしくはプロダクトバックログを作り上げる過程で関わることが多いため、スクラム開発のフロー自体にはガチで組み込む必要はないのかなと思っています。

今のところ下記のような感じでやっています。

  • スプリント計画会議やデイリースクラムには参加してもらう
  • ポイント見積もりはデザインが必要な部分だけ参加
  • 計画会議中にUI/UXについての意見をしてもらう
  • スクラム開発以外のタスクもあるため柔軟に…

ここらへんの知見がある方、アドバイスくださいませ。

スクラム開発を導入してよかったこと

まぁここらへんはよく言われるていることですが、下記のような効能が得られました。

  • やるべきことに集中できる
    • 何をやるのかをプロダクトオーナーが責任を持って決める
    • 優先順位が必ず付けられ、それだけに集中できる
    • 差し込みは優先順位次第で、優先度高い良いバックログなら歓迎する雰囲気
    • 何をいつまでに終わらせるかではない
    • 時間を意識しながら作業をすすめるのでリズムがよい
  • 成果物を披露してフィードバックを得られる
    • なにを作ったのかが意外とメンバー全員に共有されてなかったのが改善した
    • フィードバックを得る機会そのものがなかった
  • 役割やルールが明確になってストレスが減った
    • このタスク、誰が責任持ってるの？という宙ぶらりんなものがなくなった
    • コードレビューやったりやらなかったり、いつマージしてデプロイするの？が明確になった

他のチームへスクラム開発を広める

今回スクラム開発を導入してみて十分なメリットがあると感じたので、他のチームにも広めることにしました。弊社には大きく分けて4つの開発チームがあり、残り3つの内2つのチームに導入を進めています。

最後の1チームはすでにスクラム風な開発プロセスを取り入れており、自律的なチームという点で見ても、改めてスクラム開発をする必要性は強く感じなかったので、そのままにしました。

導入にあたり、各事業部の責任者やメンバーに対して、スクラム開発とはどういうものかを伝える場を何回か作りました。いきなり「スクラム開発始めます！」と声高に言っても「え？　え？」となっちゃうので…。

スクラム開発による恩恵をメンバー全員がイメージできるように、現状の課題と対策の共有や、どういったスタイルで行くのか、対話を重ねていきました。

その結果、前向きにスクラム開発について合意が取れ、9月から新たに2チームでスクラム開発をすすめることになりました。この取組についてはまた数ヶ月後にまとめたいと思います。

こういったスクラム開発を通じてプロダクトの価値最大化ができるような自律的なチームを目指していきたいです。

スクラム開発に興味ある人、募集！

スクラム開発や弊社に興味のあるプログラマの方、一緒に働きませんか？　興味ある方は@zaruにメンションをいただくか、Wantedlyなどでご連絡くださいませ。