スクラムを乗りこなすために

自己紹介

　初めての方ははじめまして、そうでない方はいつもありがとうございます。

• IT技術者 6年生
• PHPer 5年生
• Rubyist 1年生
• Vimer 3年生
• Scrum Master 2年生

　だいたいそんな感じのエンジニアがお送りするLivesense Advent Calendar 2014の13日目になります。

はじめに

　さて皆さんは開発手法としてどのような手法を利用されていますでしょうか？

• ウォータフォールモデル
• プロトタイピングモデル
• スパイラルモデル
• スクラム
• リーンスタートアップ

　などなどさまざまな手法がありますが、今回はそのなかでもスクラムに焦点をあてて、スクラムをうまく乗りこなすコツについて、短いながらも経験を通して学んだことをご紹介できればと思います。

スクラムに潜む罠

　だいたいスクラムをはじめるにあたって、陥りやすい罠というものはいくつかパターンがあります

1. プラクティスとテクニックの混同
2. 解決したいことが不明
3. 役割と責任が曖昧なまま
   などなど...

　今回はとくに上記の1.についてのお話をご紹介したいと思います。

プラクティスとテクニック

　「プラクティスとテクニックの混同」とは、たとえば「カンバン作らなきゃ」とか「相対見積もりしなきゃ」とか「プランニングポーカーしなきゃ」とかのやつ。
　カンバンとかストーリーポイントとかプランニングポーカーとかはスクラムの プラクティス(must要件)ではありません。あくまでテクニックです。
　must要件なのは 「役割」「イベント」「成果物」 の三つくらい。先述のテクニックはそれらをうまく乗りこなすためにあるもので、枝葉でしかありません。乱暴にいうとスクラムガイドに書かれていないのは全部テクニックだと思っていただいていいと思います。

スクラムによる効能

　上記を踏まえて、スクラムによる効能を再確認。スクラムはなんでもなおる万能薬ではありません。あくまで効能は限定的。その効能とは 「問題点の見える化」 です。
　スクラムを導入して少しすると、チームに潜む問題点がいっぱい見えてきます。

• 設定された優先順位通りに作業が進行しない
• 見積もりが人によってばらばら
• 進捗がわかりづらい
  などなど...

　なぜ、こういった問題点が見える化されるのか。それは先にあげた「役割」「イベント」「成果物」のいずれかがうまくいかないからです。

スクラムと付き合う

　先述の通り、スクラムとの付き合いを初めた瞬間から、スクラムはすごい勢いでプロジェクトに潜む問題点をあげつらってくれます。しかしながらどれが一番ヤバいのかは教えてくれません。また導入当初にはやり方が変わることによって、チームの生産性が一時的に低下することも相まって、 プロジェクトがすごく悪い状態であるかのような錯覚 を覚えます。ここでよくある反応は下記の二つです。

• うちにはスクラムはあってなかった...やめよう...
• もっとちゃんとスクラムをやれはうまくいくはず！カンバン使ってユーザーストーリーで書いて相対見積もりして(中略)全部やればうまくいくはず！

　まあだいたい一個目に流れるでしょう。二個目はよっぽどの盲信者でなかったらならないかもしれません。

スクラムを乗りこなす

　スクラムを乗りこなすために、おすすめなのは 「自分たちにとって必要なものはなにか」 を一度立ち止まって考えてみること。スクラムが教えてくれた問題点について、チームみんなで優先順位をつけてみることです。
　そうやって最優先に選ばれた問題点を解決したい時、やっと最初にあげたいろいろなテクニックが役立ちます。

• 設定された優先順位通りに作業が進行しない
  • 原因)プロダクトオーナーが考える価値観がチームに伝わっていない
    • 対策)ユーザーストーリー形式で説明して伝わるか試す
• 見積もりが人によってばらばら
  • 原因)メンバーによってスキルのばらつきが大きい
    • 対策)相対見積りでばらつきを低減できるか試す
• 進捗がわかりづらい
  • 原因)誰が何をやっているのかがわからない
    • 対策)カンバンを作って進捗が見える化できるか試す

　最初から完璧であろうとうすることは不可能です。すべての問題を一度に解決することも困難です。一度に一つか二つ、それくらいが現実的。

スクラムのその先

　今回のご紹介はとくにスクラムの導入の最初期、具体的にいうと長くても半年くらいまでにぶつかるであろう事柄について取り上げました。もっとながくスクラムをやっていくと、もっとさまざまな問題とぶつかるでしょう。
　そういった時は原点に立ち返ることがおすすめ。スクラムガイドだったり、さらにその原点であるところのアジャイルソフトウェア開発宣言であったり、最近だとエッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイドなんて本も、忘れがちな基礎部分を思い出させてくれます。
　そしてなによりもチームのメンバーとのコミュニケーションが一番いろいろなことを教えてくれます。

　今回は以上です。明日はからあげとらーめんがすきなwebエンジニアraamenさんによる記事になります。それでは皆さんも、用法容量を守ってより良いスクラムライフをお楽しみください。