目次
そもそもスクラム開発とは
スクラムは、前述の通りアジャイル開発手法の1つです。
スクラムってどんな開発手法？ 基本ルールや必要な役割を人気ロングセラーの改訂版から紹介|CodeZine（コードジン）
（中略）
スクラムには以下の特徴があります。
・要求を価値やリスクや必要性を基準にして並べ替えて、その順にプロダクトを作ることで成果を最大化します
・スクラムでは固定の短い時間に区切って作業を進めます。固定の時間のことをタイムボックスと呼びます
・現在の状況や問題点を常に明らかにします。これを透明性と呼びます
・定期的に進捗状況や作っているプロダクトで期待されている成果を得られるのか、仕事の進め方に問題がないかどうかを確認します。これを検査と呼びます
・やり方に問題があったり、もっとうまくできる方法があったりすれば、やり方そのものを変えます。これを適応と呼びます
詳しく理解出来ているかと言われると僕もあんまり自信は無いのですけど、ざっくりいえば、プロダクト開発の工程を一定かつ小さな単位に区切って作業を行い、その単位ごとに進捗状況を見直すことで生産性を上げるっていう感じでしょうか。ただのPDCAと違うのは単位が固定されていることでタスクを切り分けやすいのと、コミュニケーションを取る頻度と意義が規定されていることで、無駄なミーティングを減らせること。
「1週間スプリント」
僕がいたチームで採用されていたのは「1週間スプリント」というスタイルで、まず作業を1週間で完了出来るサイズに細分化。そして、毎週月曜日に「スプリントプランニング」と称するミーティングを行って、先週の積み残しがないか確認した上で今週予定されているタスクについて見通しを共有します。金曜日には「スプリントレビュー」と称するミーティングを行ってその週のタスクの進捗管理と次週の見通しを立てます。本当はリリース計画だとかデイリースクラム（毎日の進捗確認ミーティング）なんかも組み込むべきみたいですが、毎日の進捗管理はテキストベースの作業報告と、緊急の場合はSlackのハドル機能等を利用したコミュニケーションで行い、リリースについては特にリリース日を決めずに準備出来次第実施。チームの状況に合わせてそのあたり上手く調整していたように思います。
感想
ポジティブ
振り返ってみてポジティブな感想を持つのはこんなこと。- サイズが固定されているので課題を適正なサイズのタスクに切り分けやすい
- スプリントがリズムになって開発とリリースがしやすい
- ミーティングを行う意義が明確なので、最短時間で効率よく行える
ちょうど良いサイズのタスクをテンポ良く回すのが理想
生産性が向上するかどうかはプロジェクトの性質だけでなくタスクの性質や、エンジニアのスキルにも左右されますが、スキルに問題がなくタスクが適正なサイズで切り分けられたとき、「スクラム開発」が手法としてカチッとハマってタスクが効率よく回っているという実感を持てました。コミュニケーションを取ることが義務ではなく形式的でもなくちょうど良い感じでシステムに組み込まれているので、欲しい時に欲しいコミュニケーションが取れちょうど良いテンポでリリースしていけるんですよね。前プロジェクトでもっとも結果を出していた時期は、スクラム開発がチームとして一番良く回っていた時期でした。
ネガティブ
一方でこれがハマらないなという場面もありました。- タスクに比べてエンジニアのスキルが低すぎるとスプリント延長が相次ぎ、フォローに回るチームの足を引っ張ることになる
- 内容はシンプルだが工数が多く掛かるタスクに不向き
- ミーティングが増えるようになるとつらい
エンジニアのスキルが統一されているとやりやすい
一番わかりやすいのはタスクのボリュームに比べてエンジニアのスキルが低すぎるとき。スクラムマスターとしては可能であろうと判断して切り分けたつもりが当該エンジニアに上手くハマらず、2週間、3週間と延長してしまうことがありました。チームとして日々のハドルやスプリントレビューでフォローしてなんとか進行させようと努力はしたのですが、なかなか上手いこと行かず、かといって担当者を交代させようにもスキルのあるエンジニアは既に多くのタスクを抱えている状態でこれ以上は積めず。結果的にチーム全員の足を引っ張ってしまうことに。今考えてみると状況を分析してマイルストーンをもっと細かく作って（≒タスクをより細分化して）、スプリントで上手く回るように調整してあげるべきだったのかなとも思いますけど、それって要するに手取り足取り教えながら開発を進めていくことに他ならないわけで、その調整自体がチームにとって（特にスクラムマスターにとって）かなりのコストになります。難しい。チーム内のスキルがある程度統一されていれば進行が自動化されて効率よくなる一方で、スキルにばらつきがあるときには逆に管理コストが押し上げられて効率を落としてしまうことがありそうです。
ミーティング増加は「コミュニケーションの取り方」で回避する
スクラム開発でツラい点としてあげられがちなのが「ミーティングが増える」。誰かが何か煮詰まっているのを素早く検知してチームでフォローするために、毎日の進捗確認が必須で必然的にミーティングが増えがちです。コミュニケーションが大事なのはわかるけど、それってミーティングじゃなくても代用出来るんですよね……それこそコミュニケーションとは何かがわかっていないような。僕の場合は、業務中にSlackで頻繁にやり取りすることと進捗状況を毎日細かくテキストで報告することとで、日々のコミュニケーションをカバーしていました。結果、朝会出席せず、夕会開催されずでも特に不都合はありませんでした。進捗を細かく把握するコミュニケーションが必要なのはそうなんだけど、「ミーティングありき」というのは過剰かなと個人的には思います。
ただ進捗報告が1行とかそもそもしないというメンバーもいたんですよね。それがよりによってスキルが追いついてないメンバーだったので、スクラムマスターが報告を促したり頻繁にハドルで聞き取りしたりいて、アレは負担だったかも。もしそういうメンバーが複数いる場合はデイリーでミーティングした方が効率が良いかもしれません。まあ、そこに僕がいたら「何で俺まで」って思うだろうなとは思いますけど。
「スクラム開発」には効率的な開発のためのポイントが詰まってる
スクラム開発がハマるかどうかは、プロジェクトの性質やメンバーのスキルや性格にもよると思うのでなんとも言えませんが、ただ「スクラム開発」という概念には開発を効率的に進めるに当たって必要なことが詰まっているとも思います。それはつまり、
- 工数を把握しやすいタスク管理
- 過不足のないコミュニケーション
- テンポの良い開発とリリース
- 「詰まり状況」の可視化
- 属人性の排除
といったことですね。
スクラム開発では、これらのポイントをスクラムマスターがタスク割りとコミュニケーションを通して調整していくことになるわけですが、逆に言えば優秀なスクラムマスターがいないチームにはスクラム開発は不向きでしょう。でももしこれらのポイントをチームで共有して改善していくような方法があるのであれば、そのチームは効率の良い仕事が出来ていそうです。
逆に効率が落ちているチームがあるのなら、全部じゃなく一部だけでも手法を取り入れることで、例えば惰性で集まってアジェンダも中身もないミーティングを何十分もやるみたいなことを回避するとか、効率を上げることが出来るんじゃないかなと思います。スクラム開発推進派の人には「ちゃんとやらないと意味がない！」って怒られそうですけど笑
