何故スクラムをやりたいの？
※この記事はAltPlus Advent Calendar 2016の14日目の記事です。
はじめに
本日12月14日をもちまして、20代を満了し、30歳となりました。
プログラマーのtnqnです。
私からはここ数年で大きく広まった、スクラム開発について思う事を書かせて頂きます。
スクラム
数年前から日本でも取り上げられるようになったスクラム)ですが、スマホゲーム開発においても使われる事が増えてきました。
私自身も前の前(くらい)に勤めていた会社でスクラム開発における師匠と出会いをきっかけに、実際に業務に取り入れてみたり、師匠から色々学ばせてもらったりして、良いものだという事を理解しました。
スクラム「で」本当に良いのか
転職を複数回している事もあり、いくつかの業界とそこそこの数の現場(プロジェクト)を見てきた中で、スクラムに対して色々と考える場面がありました。
そんな中でも、特に記憶に残っているアンチパターン的な内容をピックアップしていきたいと思います。
よくご存知の方からすれば
- 「あーあるある、あるよねーそれ！」
- 「そこはスクラムマスターちゃんとやれよ…」
- 「なんでそれ訂正していかないの？バカなの？」
等々ご意見あると思いますが、生やさしい気持ちで読み進めていただければ幸いです。
その1 トップダウン
まさによくある話ですが、お上のお達しで
「スクラムやるぞ！」「良いからやるぞ！」「別プロジェクトでうまくいってるから！」
という流れで開始される場面を見る事が、少なからずありました。
(よくあるテンプレですね)
始める事自体は良いのですが
- なんでやってるのかわからない
- やる事を強要する状況になっている
- 旨みを殺している
という状態になっている事を感じる事が非常に多かったです。
その現場の状況次第で、もっと適切な手法が存在する可能性がある為、この流れでスクラムを始めようと思っている(もしくは、始められそうになっている)方がいれば、再検討してみる事をオススメします。
例えば、まずはデイリースクラムだけ初めて見て、メンバーの感触を見て徐々に導入していくという手もありかもしれません。
その2 ストーリーの意味
私がストーリーとは何かを説明する時には
- 顧客(エンドユーザー)が望んでいるもの
- 顧客(エンドユーザー)が体感(実感)できるもの
という点を理解してもらえるように話す事が多いです。
逆を返せば
- 顧客が望んでいないもの
- 顧客が体感できないもの
これはプロダクトとして本当に必要かどうか、熟考すべきだと思っています。
(中の人が必要になる「管理画面」みたいなものは、顧客側が必要なものという訳ではないですが、あった方が勿論良いですしね)
ここを踏まえていない、「世にも奇妙な物語ストーリー」が出来上がってしまうというのを見る事がありました。
翌週開催する、XXXイベントの内容を理解する
これは余りにも開発側、かつ個人によりすぎていると感じたストーリーです。 理解する事で開発は進めやすくなるかもしれませんが、それが顧客にとってうれしい事かと言われると、首を傾げざるを得ませんでした。 というかより、理解できてないままイベント作っちゃったのかよ、というツッコミをしたい気持ちにもなります。 また、理解したかどうか？という判定も非常に難易度が高い為、コストが非常に大きいのではと感じました。
YYYという機能を使って、ユーザーが楽しいと思う気持ちを理解できる
さらに(いろんな意味で)ハードルがあがったストーリーです。 開発の人間が顧客の感情を理解して、顧客に利益はあるのかが理解できませんでした。 (開発側がユーザー目線で見てくれているんだな、と思ってもらえる可能性はありますが) また、これをどういった形で顧客に届ければいいのかもわからなかった為、非常に混乱した事を覚えています。
外から見ている感じだと、ストーリーに対しての合意形成が非常に曖昧だったのではないかと感じました。
その3 本当にみんなスクラムをやりたいのか
その1でトップダウンについて書きましたが、その場合もそうでない場合も、
チームメンバーがスクラムをやりたい(やってもいい)と思っているかどうかは大切な事だと考えます。
これまでウォーターフォールでやってきた人が、突然スクラムに切り替える事は非常に難易度が高いでしょう。
技術レベルが非常に高いけれど、コミュニケーションが苦手(嫌い)な人だと、余計なストレスを与える事になるかもしれません。
スクラムを何も知らないまま、突然デイリースクラムやスプリントプランニング、レトロスペクティブ(ふりかえり)をやっても、効果は薄いでしょう。
スクラムをやるのであれば、チームメンバー全員がある程度のスクラムの知識が必要になると私は考えています。
(そして、そこのサポートをするのがスクラムマスターですよね)
これからやろうと思っている方は、スクラムをチームに導入する前に - スクラムとはなんなのか - どうやってやるのか - ウォーターフォール開発やスパイラル開発と何が違うのか
といった点をチームメンバーみんなに理解してもらった上で、導入する事をオススメします。
今現在スクラムをやっている方も、本当にスクラムをこのままやっていくべきかどうか、見直してみてもいいかもしれません。
(もちろん状況や会社の都合等で、すぐ動く事は難しいと思いますが。)
まとめ
ここ数年で、例にあげたような無闇矢鱈と始めた感じのある「スクラムベス」を見たり聞いたりする事がとても多くあり、
スクラムを推奨する一方、本当はスクラムじゃなくても良かったのでは無いかと思い返し、このような内容を書かせて頂きました。
(当時関わっていて直せなかったもの、関わっていなかった為、遠くからみるだけだったもの、色々ありますが…)
スクラムをやろうしている方、やっている方に - スクラムで良いのか - 他の手法では何故ダメなのか - メンバーは正しくスクラムを行えているのか
というあたりを考え直して頂く、参考情報にでもなればと思います。
戯言(ネタです)
失敗する時のスクラムって、なんだか宗教団体っぽい感じがするなと思った事があります。 失敗する時の始め方に多い点をそれっぽく並べてみると…
- 安易に信じてはいけません！(スクラムだからってプロジェクトは成功しない)
- みんながやっているからと言ってやってはいけません！(他が成功してからって、自分たちが成功するとは限らない)
- ちょっとだけ、という軽い気持ちでやってはいけません！(チームメンバーが混乱します)
