この記事は 個人Qiita と同じ内容です
qiita.com/sekiyaeiji
非エンジニアが知らない（であろう）、スクラム開発において行われていること
「スクラム開発」とは、非エンジニアの方々の目にはどう映っているのでしょうか。
エンジニア組織が選択する開発手法のひとつ、ぐらいに見えているかもしれないですね。
実はスクラム開発は、開発手法のみならず、エンジニアにとって働き方改革らしきものまで提供してくれています。
非エンジニアの方々は知らないかもしれない、スクラム開発の根底にあるエンジニアの昨今の"働き方"についてご紹介したいと思います。
本稿ではスクラム開発の開発手法自体にはあまり触れず、スクラム開発がもたらすエンジニアの働き方の変遷にフォーカスをあてて議論を進めます。
スクラム開発自体の説明については日本語版公式ガイドを参照してください
スクラムガイド − スクラム公式ガイド：ゲームのルール ／ Ken Schwaber & Jeff Sutherland
．．．と言いつつも、このあとの説明に必要になるスクラム開発に関する最低限の予備知識を、ここで解説しておきます。
スプリント
スクラム開発では短く区切られた期間の最小単位をスプリントと呼び、1スプリントは一般的に1週間や2週間に設定されます。
ポイント
スクラム開発では1つのチケットの作業量見積りを"ポイント"などの相対的な単位によって表現します。
たとえば3ポイントの基準チケットを用意しておき、あるタスクは基準チケットと比較して少し作業量が少ないので「2ポイント」とか、基準チケットの2倍弱ぐらいのボリュームだから「5ポイント」と決めよう、というような、見積りを行う際の単位として利用します。
ベロシティ
スクラム開発ではチームの1スプリントの処理ポイント数をベロシティと呼びます。
直近の3スプリントのベロシティの平均を、次のスプリントの目標ベロシティにする、というように利用します。
先述の通り、スクラム開発はエンジニアにとって、"働き方改革"かもしれません。
スクラム開発の業務スタイルのポイントは、行動量を一定に維持することです。
そのため、目標ドリブンとか、ウォーターフォール開発のような締切を設定する業務スタイルとは対照的な業務フローになります。
フェーズや状況によらず、常に行動量を一定にすることが重要になります。
細部を吸収しチーム全体のスループットのみを扱う
チームメンバーの日常においては、有休を取ることもありますし体調が悪い時もあるでしょう。
一時的なミーティングに時間を取られることもありますし、プロダクト開発以外の業務もあるでしょう。
突発的な障害対応や顧客サポート補助のような、予定している以外の開発タスクが発生することもあります。
スクラムチームで、直近数回の実績の平均値を次の目標ポイントにしているのはなぜかというと、上記のようなメンバーごとの都合やイレギュラーなイベントによるマイナスも包含して平均化することにより、それらの個々の事象を気にかける必要性を可能な限り削減するためです。
個々の事象を見積りに反映するコストを削減している、とも言えます。
そうして、コンスタントに一定の行動量を継続的に維持できることを重視します。
スクラム開発における働き方のポイント
スクラム開発では、あるスプリントだけ一時的にベロシティを上げてしまうと、目標ベロシティの現在の適正量が測れなくなったり、目標ベロシティが適正量を超えて増大することで徐々にチームを追い込んでしまうという課題が発生します。
ですのでチームの個々のメンバーが、継続的ではない、たまたま1スプリント内だけで一時的にベロシティを上げる行為は、慎むべきということになります。
それはベロシティの読みを狂わせ、チームを追い込んだりメンバーの疲弊の原因になるなど、チーム全体とってマイナスインパクトを発生させます。
また、Webプロダクトが24時間365日稼働であることが当たり前になっている現状において、さまざまな突発的な事態に素早く対応できるためにも、日常的な業務においては変動要素が少なく、稼働や思考サイクルが安定した状態であることが望まれます。
チームの行動量という、太さが常に一定のベルト状の帯を維持しておき、アウトプットはその帯の処理量に応じて一定の頻度で得られる状態をイメージすると理解しやすいかもしれません。
この帯の太さを一定に保つことへの努力を惜しまないことが、スクラムチームの重要な責務です。
スクラムチームは成長しないのか？
では、スクラムチームのパフォーマンスやアウトプット量には改善の余地はないのか、とか、まったくもって成長しなくてよいのか、というと、そんなことはありません。
チームのベロシティの向上自体を目指してはいけないという訳ではありません。
ベロシティを上げるために、スプリントイベントの改修や効率化、無駄の排除のような業務フローの改善を試みることによって、チームのベロシティの向上を目指すことは何ら問題はありません。
極端な改善例で言いますと、"ショートスリーパーのメンバーばかり集めてベロシティを上げる"とか．．．を、目指してはいけない、ということはありません。
・・・なにか別の問題が起きそうな嫌な予感がするので私は実践しません ｗ
スクラム開発のような働き方が実践できる条件
スクラム開発のような働き方はなぜ可能なのでしょうか。
このスタイルが可能になるためには、以下の2つの条件が必要と考えます。
- 一定期間中の予定タスクをチケット化して準備できる
- 不確定要素の介在が比較的少なく行動量を一定にできる業務内容である
上記は主務やすべての業務がこれに該当する場合だけでなく、一部の業務が継続的にこの条件を満たす場合にも運用できると思います。
1. 一定期間中の予定タスクをチケット化して準備できる
back check 開発チームでは1スプリントを2週間に設定しています。
スクラム開発では毎スプリント、スプリントが始まる前日までに、1スプリントの目標ベロシティ分のタスクを用意しておく必要があります。
優先順に並んだタスクチケットを上から順に取り、次のスプリントで対応するチケットを追加して行き、タスクの合計ポイント数が1スプリントの目標ベロシティのポイント数に達するところまでタスクチケットを追加します。
ある期間の単位でこれが毎回実行できる業務であれば、エンジニアリング業務以外でもスクラム開発と同じ手法で業務対応ができそうです。
2. 不確定要素の介在が比較的少なく行動量を一定にできる業務内容である
開発チームのエンジニアは、新規開発のコードだけをずっと書いていられるわけではなく、障害対応やバグ修正、顧客サポート補助、全社施策などのさまざまの差し込み業務にも対応していますが、それでも6〜7割以上はメインストーリーや改善施策などの主務に集中させてもらえている職能なのかもしれません。
差し込み業務はスプリントポイントに計上しませんので、スクラムチームのベロシティとは、主務（新規、改善タスク）におけるそのチームの価値提供の基準と言えます。
ですので、ある業務に対する単位期間中の一定の行動量を継続的に維持したい場合、維持できる場合に、スクラム開発の働き方が有用になります。
スクラム開発とその他の業務スタイル
スクラム開発とその他の業務スタイルをまとめると以下のようになると思います。
- スクラム開発
- チームの行動量をフィックスさせ、1スプリントごとにタスクを消化する
- ウォーターフォール開発
- 全体計画をフィックスさせ、複数の開発締め切りを経て計画の完了まで走り切る
- 目標ドリブンの業務スタイル
- 一定期間の目標をフィックスさせ、必要な行動量を割り出し目標達成にコミットする
それぞれ、何を軸として固定して、それに対して何を積み上げていくかの対象が異なります。
ウォーターフォール開発が昨今のWebプロダクト開発で活用されなくなっている理由を業務スタイル観点で考察しますと、計画が初期にフィックスされ途中の変更コストが考慮されていないために、短期の締切ごとに稼働を上げて変更分を吸収する傾向があり、チームメンバーを追い込むループが発生しチームが疲弊することが主な理由でしょう。
疲弊しても計画を達成すれば問題ないかと言えば、低下したチームパフォーマンスは元の状態に回復するまでインターバルが必要になり、インターバルのロスと追い込みのゲインが相殺するのと、スループットの増減が計画の読みを狂わせる点が課題になり、結論として使いにくいフレームワークとして利用されなくなっているようです。
目標ドリブンの課題
目標を定め必要な行動量を割り出して走り出す業務スタイルは、開発以外の職種で多く見られます。スクラム開発の働き方の実態はこのスタイルとほぼ違いはありませんが、決定的な差は、"目標"を目指さない点です。
平均ベロシティが安定して継続的に高い状態、というのが暗黙の"目標"になっていることもあるかもしれませんが、そういう"目標"を"目指す"という建付けは行いません。なぜでしょうか。
まず第一に、アジャイル開発において「"顧客との協調"を価値」としていることと、スクラム開発においてチームは常に"スプリントゴール（スプリントが提供する価値）"に集中しているため、他に目指すものが不要であるためです。
業務スタイル観点で言うと、"目標"の扱いの難しさがありそうです。
事業面においては目標値を設定できる職種もあると思いますが、開発では目標値の裏付けが求めにくいのです。
KPIの達成という観点が存在すると思われがちですが、それは要件定義側のPMとかデザインチームの目標に設定することは可能ですが、エンジニアリングの目標ではありません。
もっと具体的な、達成可能な定量目標を設定した場合も、目標には課題が多いです。
まず設定した目標値にロジックがないとチームメンバーに納得感が生まれにくいことや、早期に容易に達成できてしまう目標であれば、達成後のモチベーションが低下して残り期間の生産性が低下したり、その反対に難易度が高い目標だとそもそも達成のモチベーションが湧かず大きく不達に終わってしまいます。
目標という指標には元来、人間の主観が介在しやすかったり、人間の精神力を試すような性質がある点が、エンジニアリングとの相性がよくない本質的な原因のような気がします。
また目標という、根拠を立てづらい不確定要素によってパフォーマンスが左右されるというのも、計画の読みを狂わせる原因になりそうです。
まとめ ー スクラム開発の働き方が求められる理由
スクラム開発は開発スタイルとして価値がある手法ですが、定着する理由は業務スタイルとしても以上の通り、もろもろの要因があるということです。
- 予定タスクを細分化したチケットを準備できる
- 行動量を一定にできる
この条件にかなうすべての業務にこの手法が利用できます。
この業務スタイルを採用すると以下のメリットが得られます。
- 確定したタスクの反復のため確実に実践できる
- サイクルごとに業務のコンディションがモニタリングできる
- いつもと違う問題が発生したら課題発見と改善のチャンスになる
私自身がPOとして要件定義や検証、インプット、アウトプットの反復など、エンジニアリング以外のタスクを生業としているため、月次とかで反復実行しているタスクをチケット化してスクラムのように進行できるかトライしてみたいと思います。
スクラム開発自体も各社試行錯誤しながら継続的なブラッシュアップを繰り返していると思われ、まだまだ進化の余地がある開発フレームワークですので、本稿のようなアウトプットによって活発に情報交換される状況を促進したいと思います。
参考図書
本稿では、スクラムの原則について確認するために、以下の書籍を参考にさせていただきました
SCRUM BOOT CAMP THE BOOK【増補改訂版】 スクラムチームではじめるアジャイル開発
