自分のチームは以前からスクラム体制を取り入れていましたが、今年同じスクラム体制でもやり方をガラッと変えたことで感じたこと・変わったことをまとめてみたいと思います。ちょっとタイトルはキャッチーに書いちゃったけど当時は本気でやってたよ！

プロセス改善前の状態

アプリの開発チーム
iOS 4人 Android 4人スクラムマスター1人の体制
2週間スプリント自分がジョインする前から「スクラム」で開発を進めていた。「スクラム」で開発するのが初めてだったので、元からあるやり方で先輩に聞きながら開発を進めていた。

プロセス改善

転機は有名なアジャイルコーチの方がアドバイザーの形で入ってくれることになったこと。その時色々選択肢はあったのだが、色々あってスクラムで続けていきたいとなって、もう一回スクラムをやり直すことになった。

チームの再立ち上げ

新しくスクラムチームを立ち上げる時にやったことが以下。

開発チームできめたこと

決定のルール
DONEの定義
ワーキングアグリーメント

それまでのプロセスとは変わったところ

1週間スプリントになった

今まで月曜はじまりの2週間スプリントだったけど火曜始まりの1週間スプリントにした。火曜日始まりの理由は月曜は休みが多いから。水曜始まりでもよい。火曜日の予定は午前中にスプリントレビュー、レトロスペクティブ。午後にスプリントプランニング。火曜日にスプリント切り替えを全部行う。火曜日は一日会議になる。会議の日と実装の日が完全にぱきっと分かれる。最初はうげーとなるけど結構よい。

タスク分解の仕方

案件を実装タスクに落とす際は0.5~1hになるまで粒度を細かくする。「調査」というタスクは入れない。影響調査などはすべてプランニング中に終わらせる。プランニングの時に徹底的なプランニングをすることで、あとの日は徹底的に計画されたタスクをこなすだけという狙い。これも最初むりでしょーて思うけどできるようになるしそれがとても良いことだと気づく。

要件を受け入れ基準として定義する

ここは開発チームだけでなく企画側にもお願いするお話。要件をもらうときにAcceptance Criteria（受け入れ条件）を決めてもらいこれを元にエンジニア側で設計・実装をするし、このA.Cをもとに受け入れをしてもらう。なんとなくの案でもらうと、受け入れる人によっても基準が変わってしまう。開発側はA.Cに書いてあることだけ実装する（それ以外の挙動は変えないが前提）。そこに漏れた要件は企画側の責任になる。ここで今まであいまいになっていた責任分解点ができた。

結果変わったこと

チームの中でプロセス変えてどうだった？という話をだべったのでその内容を。

常に緊張感が出る

2週間スプリントの時は前半だれていた、後半がんばる、というサイクルに自然となっていたみたい。 1週間スプリントは緊張感がある。提出まで中4日しかないので、ちゃんと時間通りタスクを消化していかないと終わらない。例えば1日何かがあって遅れてたら、2週間スプリントだと最大8日かけてリカバリできるけど、1週間スプリントだと最大でも3日しかリカバリにかけられない。

開発の奴隷化の解消

どうしても企画側の企画があってから開発があるので、以前は開発工程で出た問題は開発の問題になりがちで責められがち。本当は開発の問題じゃなくても。案件を受け入れ基準駆動で行うことで、企画側と開発側どっちの責任かがはっきり分かれ、全部開発の責任になるということが減ったと思う。どこまでがどちらの責任と決めたこと、決めたことに対して公平な立場で厳しく言ってくれる人がいたことで、開発側も「悪いって言っていいんや！」と、ちょっと安心した面はあったと思う。企画側にも物言える開発チームに変わりつつある。実際に仕様が詰められていない案件については企画側の責任範囲になるので、開発側が詰められていない案件のカバー&実装みたいなことはなくなって開発は幸せになったと思う

問題発見フレームワーク

スクラムというプロセスは何かの問題を解決するプロセスというより「問題を発見するためのフレームワーク」と習った。これをやってみるまではあまり実感できなかったが、計画スプリント内に行うタスクを0.5~1hまでの粒度まで落とすという作業は、細かく指定する分計画と違いが出たときにわかりやすい。今までは「実装4h」などとざっくり見積もりでよかったのかもしれない。けど本当は問題が隠れていたのかもしれない。また、ここまでタスクを切るということはプロジェクト内の影響調査のしやすさにも関係があると気づいた。この方法をしてから「簡単にタスク分解しやすい」案件と「どこをどう直せばいいかをつきとめるのに時間がかかる」案件に分かれる。じゃあ後者ってこれあんまり良いコードじゃないのでは？と問題を問題と気づくきっかけをくれた気がする。

その他

以下はスクラムをいれたからというより今のチームの状況で得たものも参考までに書いておく。

スクラムマスターの不在

スクラムマスターの不在というとちょっと意味が違うのだが、スクラムマスターの方が異動になり、チーム内でスクラムマスターという肩書を持った人がいなくなってしまった。事実上、アジャイルコーチの方がスクラムマスターのような役割をしてくれていたのだが、週に1度程度の頻度でしかコーチングに来れないため、セレモニーのファシリテーションやレトロで出た施策の管理などはチームメンバーがやっていた。今考えると当たり前だと感じる点もあるのだが、前の体制は全部スクラムマスターにお願いしてしまっていたのだ。あとは他のコミュニティで「ファシリがうまいね」と言われたことがあって、それはここでの経験だと思っている。

QAの不在

これは自分の会社であるあるなのかもしれないが、だいたい開発チームはQAの方がいて、テストを担当してくださる。うちのチームはなぜか（スクラム導入時にそのような体制にしたと話は聞いた気がする）QAが不在のチームだった。従って当たり前に自分達でテストをすべて行う。自分たちで開発→テストを行うので、テスト工程まで見越した考え方ができるようになったと思う。 QAがいてくれる安心感からは、「不具合を出しにくい設計とは？」という観点が出てこない気がする。QAがいて不具合を見つけてくれることで大変なのはQAだから。テストの中だけの改善、開発の中だけの改善だけでなくて、テストの改善のために開発を改善するみたいなことが起きる、考えられるようになる。自分にとっては考え方がかなり変わったところだ。

まとめ

結局事業には貢献したの？と言われるとなんといっていいかわからない。この体制にしてからプランニング時間内にで1つの案件しかプランニングできてなかったチームが今はだいたい20この案件をプランニングしそれを実装までこなせるようになったのは設計・開発スピードが改善したのだと思うけど、厳密に見れば色々他にも要因はあるからね。個人的には、アジャイルの考え方やプロセス改善の方法を学べたことはとても成長になったと思う。新卒1年目ウォーターフォール→新卒2年目スクラムとやって、もうウォーターフォールのチームには戻りたくない。なかなか大きい会社でスクラムをやることは難しいけど、気合や残業で解決することなく、人じゃなくて問題に目を向けるという意識が根付く。この意識が根付くことだけでも開発者が幸せになるフレームワークになるんじゃなかろうかと思っている。実際今年一年楽しかった。という振り返り。