はじめに
ラクスルでサーバーサイドエンジニアをしている田中です。
印刷ECタスクフォース（以下ECTF）というチームでテックリーダーを名乗っています。
入社して1年ちょっとになりますが、その1年間でもオフィスが移転したりメンバーが増えたり組織体制が変わったり。。。と目まぐるしく状況が変化する中で、
エンジニアに焦点を当てるとドラスティックに変わった（んだろうなぁ）と感じるのが開発スタイルでした。
ちょうど新しい開発手法の導入期からジョインして色々なことを体験したので、そこを少しご紹介したいと思います。
なぜ開発手法を変えたのか？
解決すべき問題点
1年前当時はいわゆるウォーターフォール型の開発で、降りてきた粒度の整わない要件を実装してリリースするというサイクルを延々繰り返していましたが、人も案件も増えていく中で様々な問題が出てきました。
- エンジニアの人達って何やってるの？という他部署の疑問
- Redmineでチケット切っていたが実際リリースするまでの過程がブラックボックス。
- ビジネス側でも仕事の整理ができづらく混乱
- 依頼した要件に対して着手の順序が見えていないため、思わぬ案件の要件手戻りや仕様の確認が五月雨式に飛んで来るため、腰を落ち着けてサービスに取り組めない。
- なんかみんな妙に疲れている
- 区切りは大切。案件自体に区切りはあるが、多様な案件が毎日のように飛んでくるため息つく暇がない。
などなど。
とにかく効率云々の前に圧倒的に計画性と透明性が欠けていました。
いざ導入
そこで同期入社の現CTOがもちこんだのが"スクラム開発"で、細かい理由は忘れました。
が、上記のような問題点は社内でも解決すべきという機運が高まっていたところで、モダンな開発手法入れてみよう！解決するかも！！的ノリから導入となりました（たぶん）。
もちろん最初は抵抗感がすごかったのを覚えています。今までの慣れたスタイルから変えるというのは開発手法に限らず大変です。
スクラム開発を軌道に乗せる
ここで個人的に大事だと思うことは、まず"やってみる"なんだと思います。
私は以下を繰り返しながら徐々にECTFにフィットするスクラム開発にしていきました。
まず教科書通りのスクラム開発でとにかく１スプリント回す（からの）
- 振り返りで開発のスタイル自体（個々の案件にフォーカスしない）の問題点を洗い出して議論する
- 計画時に出てきた問題点に対しての解決案を実践することを盛り込む
- やってて違和感感じてもとにかく１スプリント回す
基本的にアンタッチャブルなもの
- 1スプリントの中間にプロジェクトバックログ（PBL）リファインメントをおこなう
- 1スプリントの最後に振り返りをおこなう
- 1スプリントの最初に計画をおこなう
上記３点だけ守った上でどんどん変えていきました。結果いまECTFのスプリントはこうなっています。
１スプリントが２週間になっていますね。タームだけではなく、中身もかなりカスタマイズされています。
ECTF式スクラム開発の中身
Sprintターム
２週間です。
システムの人間だからとていわゆる会社的なミーティングなどの業務と無縁ではないので、１週間タームでは作業へ集中する時間がまとめてとりずらく、かえって非効率になってしまったからです。
少なくとも私の集中力は水ものなので、ミーティングなどで途中で切られると、また集中力を取り戻すのに多大なコストがかかるのです。。。
バックログ作成
JIRAを使用。起票はシステム、ビジネス問わず。ただし以下のようなルールを設けています。
- タイトルは、ユーザーがどういうことができるようになるのかを書く（"○○機能の改修"とかではない）
- 案件の背景、受け入れ条件を明確に
PBLリファインメント
2週間タームなのと事業的な性格から基本的に次スプリントのバックログに対して議論をします。
そこで実装見積できるものはする、要件があやふやだったりして見積できないものはオーナーへ返す。という作業を繰り返します。
計画
ECTFは運用もおこなっているので、計画時のポイントは常にバッファをもって計画します。
悲しいかな差込案件を許容せざるをえないんですね。
ただし、差込案件をJIRA起票する際は、ある程度システムの現場で実装優先度をコントロールするために、理由と期日を記載してもらうようにしています。
振り返り
振り返りでは関わった作業のみならず、Sprint内で起こった出来事をいいこと悪いこと問わずぶちまけてもらいます。
時には大愚痴大会になることもありますが、いろんな心情を吐露してすっきり次スプリントに向かう区切りとして使っています！
さいごに
いま振り返ってみると、これは本当に"スクラム開発手法"なのか？？という疑問が湧かないでもないです。
ただ個人的に思うことはウォーターフォールであれスクラムであれ、
- 会社やチームが
- 納得感をもって
- 楽しく仕事ができる
そういう仕組を自分たちの文化に沿って作り上げるのが一番効率的な手法なのではないかなと思います。
皆さんのチームは楽しく開発していますか？
