スクラム開発を始めるときに自分がやったこと

この記事は suusan2go Advent Calendar 2019 - Adventar の2日目の記事です。

今年の前半にお手伝いしていた某社で、スクラム開発の導入をしました。自分が開発チームに入ったタイミングでは、カンバンツールを使って週次で振り返り(KPT)とタスクの状況確認が行われており、特定のチームはなく大きめな機能開発については案件ごとに非エンジニアも含めたチームが組まれているような状況でしたが、以下のような課題感を強く持ちました。

同じタスクがいつまでもカンバンに残り続けていて、リリースサイクルが遅い
エンジニア間で機能開発のコンテキストが共有されていないので、レビューコストが高い
1ヶ月以上の期間開発されたのに、仕様変更やビジネス上の都合により結局リリースされないものがある
これらの問題を解決・改善していけるような仕組みがない

この状況を改善するためにスクラム開発の導入を進めたのですが、どんなふうに始めていったか自分の振り返りも兼ねて、またこれから始める人の参考になるようにまとめておきます。

スクラム開発始める前編

現状の課題感を言語化する

既に箇条書きで当時感じた課題を書いちゃってますが、自分の課題感はリリースサイクルが遅い というところから始まっていて、それを徐々にWikiにまとめて言語化していきました。スクラム始めよう！となると全てがスクラムで解決できそうな気がしますが、言語化してみると例えばリリースサイクルが遅いというのは実は単純にプロセスの問題だけじゃなくて、デプロイフローの問題やアプリケーションの品質の問題だったりチームのサイズの問題だったりということが見えてきます。スクラムで何を解決しようとしているのかというのをハッキリさせる意味でも、一度何が問題なのかを文章にしたのは良かったです。

期待値調整をちゃんとやる

期待値調整というと語弊があるかもしれませんが、スクラム開発をやるにあたって「スクラムをやればこれが解決します！」という言い方はしないように心がけました。そこの期待値だけが高くなっちゃうと、「スクラム始めたけど全然見積もり通りいかない / リリース早くならないじゃん」みたいな感想を持ってしまう人が出てくるからです。スクラムのプロセスを踏襲したから何かが良くなるわけじゃなく、計画・振り返りのサイクルのなかで自分たちで良くしくんですよと言う伝え方を心がけました。

スクラム開発のプロセスをやったから今の課題が解決するわけじゃないですよ
スクラム開発でわかるのは「いまなにができていないか」ですよ
課題を解決するのはスクラム開発じゃなくて自分たちですよ
少しずつチームで改善していきましょう

こういうコミュニケーションを心がけていたので、スクラム開始後も自然と「振り返りで改善していきましょう！」という雰囲気ができていたのかなと思います。

スクラム開発始めるとき編

インセプションデッキをやる

インセプションデッキはアジャイルサムライで紹介されているプロジェクトの全体像を示すためのドキュメントです。ドキュメントというと誰かリーダー的な人が作って配布するようなイメージを持つかもしれませんが、ワークショップ的にチームで集まって作っていくことに意味があるものだと自分は思っています。

インセプションデッキのテンプレートは以下からダウンロードできます。 github.com

割と新規ビジネスとか新規事業とかを念頭にテンプレはつくられている感じがするので、適宜差し替えて使いましょう。例えば既存のプロダクトがあってチームを作っていく場合には、エレベータピッチとかは不要かも。自分はチーム名を考える項目を入れたりしました。 The Agile Inception Deck | The Agile Warrior

自分はインセプションデッキのなかでも 我々はなぜここにいるのか 、 俺たちのAチーム の項目が好きです。自分も自分でやってみるまではインセプションデッキやることにどこまで意味があるのか懐疑的だったんですけど、今までやった全てのチームで「チームの目指すゴールが明確になる」「何を重視するかという価値観が揃う」感覚があり、何よりチームとしてやってやるぞ！という気持ちになったのでチームのキックオフにはお勧めです。

とりあえず最初はスクラムガイドに書いてあるとおりやる

これよく言われてるやつですが、まずは守破離の守ということで、スクラムガイドの内容をカスタマイズしたりせずやりました。個人的に、まずはカスタマイズせずにやってみることで良かったのは、「これは何のためにやってるんだっけ？」というのをスクラムガイドに求めることができたことかなと思います。特にスクラムで開発を始めた当初は「これは何をしていく会だっけ？」とか、「これは何のためにやっているんだっけ？」という疑問・質問が多発するので、そんなときにスクラムガイドをもとに説明できます。またとりあえず型通りにやってみることで、スクラムガイドで目指していることをチームで体系的に理解できていく感じがしました。

まとめ

スクラム開発を始めて2ヶ月くらいのタイミングで契約を終了してチームから抜けてしまったので正直あまり偉そうに何か成果を語れるわけではないのですが、外から様子を見る限りとても強いスクラムチームになっているようで、自分のやったことが少しでも貢献につながっていれば嬉しいなと思っています。本記事では導入までをざっとポイントを絞って書きましたが、スクラム開発をこれから始めようとしている人たちの参考になれば幸いです。