はじめに
今いるチームでスクラムを導入して三ヶ月経過しました。スクラム開発という文脈で、個人的な気づきと悩んでいることをつらつらとまとめてみました。スクラム開発をしている方の目に止まれば幸いです。
私は誰?
とあるWEB企業で、とあるBtoBtoC向けサービスの開発に、エンジニアとして関わっています。スクラム導入当初はプロダクトオーナー兼エンジニアをしていましたが、やりたいことが変わり今はエンジニアをしています。
スクラムという用語との出会い
スクラムという用語を聞いたのは多分4年くらい前です。
当時アジャイルで開発(ウォーターフォールではない、というくらい)をしている自分のところに、同じ社内の他チームがスクラムという開発手法で開発しているらしい、というのを耳にしました。その時は「なんじゃそりゃ？ラグビー関係あるの？」くらいの感想。
その一年後くらいに、自分のチームでアジャイルサムライの本が流行しました。特にストーリーポイント、という概念がチーム内でバズって、実際にチームでストーリーポイントを使って見積もりをしたことがありました。
しかし、その時は僕は、なんでストーリーポイントで見積もってるのか全くわかってませんでした。
極めつけが、当時の同期だったS木君からの「ストーリーポイントって何がいいの？」という純粋な質問。
あー、自分わかってないな、、、当時の自分ダメダメ(・_・;)
見積もっただけで特にストーリーポイントを活用すること無くフェードアウトしていきましたとさ。
認定スクラムプロダクトオーナー研修への参加
スクラムに関して、よくわからない状態でそのまま時が経過。
今年の二月に今の会社に転職してきて、ふとしたきっかけで認定スクラムプロダクトオーナー研修を受講することに。講師はその世界で有名な、ebackyこと江端さんでした。研修に参加前はスクラムについて全く知らなかったので研修ではちんぷんかんぷんでしたｗ なんというか、江端さんからはマインド的なことを叩きこまれた気がします。研修の中のリーンキャンバスの課題で、街中の人に突撃インタビューしたのはいい思い出です。意外とできるもんでした。
担当PJでのスクラム導入の機会
2015年9月から担当PJで本格的にスクラムをはじめることになりました。とても業務的な話なので割愛m(_ _)m
個人的な気づきと悩んでいること
目標達成に向けてきちんとコミットするにはスクラムは最適
今までの経験で色々な開発をしてきましたが、スクラムはチームのマネージメントがすごい。スクラムマスターやプロダクトオーナー、チーム外のマネージメント層からからするとこれはとても管理しやすい開発手法なんじゃないかなと。チームのタスクの管理がかなりガチガチ。
一方でチームのモチベーションをうまくコントロールすることで、コミットへの意識も強くなりタスクをきちんとこなすという。諸事情により、私はプロダクトオーナーとエンジニアの両観点でスクラムに参加した経験があるので、この辺の事情はよく理解できているつもりです。
スクラム導入前後で開発効率がどう変わったかはよくわからない
これは私が効果測定の方法をいれていなかったのが致命的だったのですが、開発効率という観点ではスクラム導入してよくなったのかどうかは特に判断できていないです。理論的には、話し合いに時間をさくようにして、その分開発時間は短くなります。話し合いに時間をさいたぶん、手戻りが少なくなりトータルで開発効率が上がるのか。はたまた、開発時間が多いほうが開発効率が上がるのか。頭で考えてもよくわからないですね(´・ω・｀)
やはりはスクラムをいれる目的次第という話に。
自分達に適したスクラムのやり方は自分たちで見つける必要がある
当たり前かもしれないですが、何かベストプラクティスがあってもそれをそのまま自分たちに応用できることはまれです。なぜなら、会社や担当PJの状況が全く一緒なところなんでどこにもないから。
実際に僕達がやってみても、自分達用にもろもろカスタマイズしています。その都度チームで議論をしています。ものすごい簡単な例だと、チームメンバーがタスクを取っていく際のロジック。
理想としてはスキルに属人化はなく、優先順位が高いものからタスクをとっていくのがよいとされています。
しかし、実際そんな状況にするのは難しい。なので例えば、サーバーサイドエンジニア、フロンドコーダー、iOSアプリエンジニア、などと彼らの得意分野のタスクをとることが多くなります。
とは言え、そのままだと個のスキルが成長しないので不得意な分野に積極的にトライできるなサポート体制も整っています。
例えば私は、CSSがほぼほぼまってくだきなかったですが、最近CSSに積極的にトライさせていただいています。CSS楽しい。
スクラムで開発する目的がないと、スクラムをやっているだけになってしまう
特に個人的に顕著な所感としてこれがあります。スクラム導入前は色々課題があったので導入をしました。実際に導入してみるとどうでしょう。その課題は解消されてきました。そうするとスクラムを続ける理由が感覚的にはわからなくなってきます。前に課題だったことが課題でなくなってるわけだから、意識しないでスクラムをやってるとそういう思考になってくるのかなと。
また、案件によってはこれってウォーターフォールでやってもいいんじゃない？といった疑問が浮かんでくることも有ります。何でもかんでもスクラムでやろう、とせずに使い分けることが重要なのかなと。そうでないとやはりとりあえずスクラムをやっているだけになってしまいます。
などと自分で書いていながら、今個人的にこの課題にぶちあたっています。なんでスクラムで開発してるんだっけ？という疑問。まずはスクラムをやっている目的を整理するのが吉かなと。
セミナーでも発表してきました
などなどのような話を社外で発表させていただいた際の資料があるので最後に共有しておきます。
もしスクラムに関して興味がある方がいれば、お気軽にコメントなどいただければ幸いです。
http://www.slideshare.net/tatsuyayokoyama7161/ss-55581976