*この記事は、株式会社Ancarのアドベントカレンダー2019の12/1分として公開されています。
まえがき
こんにちは、株式会社AncarにてWebエンジニアをしております、Mass-minと申します。
弊社では、日々膨大な数の登録・更新のある中古車の中から最もお買い得な中古車を探し出せるサービス、Ancar Searchを10月にリリースしました。みんな使ってね！
さて、今回の記事は「スクラム開発で、チームが絶対に残業をするべきでない理由」についてです。
リリース直前期には1徹2徹なんぞよくあることと言われがちですが、弊社開発チームも例に違わずAncar Searchのリリース直前期はかなり残業をしました。
しかしスクラムを用いた開発形態を取る弊社で、残業をした結果チームが良い方向に動いたかというと、正直微妙なところがあります。
というわけで、今回は経験も交えながら、スクラム形態をとる開発チームが残業をすべきでない理由を書いていこうと思います。
おしながき
- 残業したらこうなる
- スプリント計画より進んだ量を開発する
- デイリースクラムで個人が抱えている問題が上がりにくくなる
- 慢性的にアウトプットの質が低くなる
- 残業してはいけない理由
- まとめ
残業したらこうなる
冒頭で我々開発チームがスクラムの形態を取っているとお話しました。スクラムには実行するべきイベントが複数存在します。
その全てのイベントの基準になるのは、「スプリント」と呼ばれる開発期間の単位です。
例えば弊社ではスプリント = 開発期間の単位を1週間と定め、
スプリント計画 で 今後1週間で何を開発するかをPOと決め、
デイリースクラム で 計画したタスクについての日々の進捗を開発メンバー内で確認し、
スプリントレビュー で 1週間で開発した内容の確認、リリース可否をPOに判断してもらい、
スプリントレトロスペクティブ で この1週間で良かったこと、悪かったこと、チームがステップアップするためのトライを洗い出し ます。
では、ここで残業をするとどうなるか。順を追って見ていきましょう。
スプリント計画より進んだ量を開発する
まず、当初スプリント計画で計画した分より多い内容を開発することになります。
計画より多いわけですから、見た目はかなり進んでいるように見えます。この時点では、メンバー全員ハッピーです。「残業しといてよかった！！」という雰囲気が漂います。
...しかし本当にそうでしょうか？
最初は開発メンバーの毎スプリントの出力を計測して、それに見合った量を見積もってスプリントの計画を立てていたはずなのに、残業し続けて高出力のスプリントを重ねると、気がつけば残業ありきの出力で見積もってしまい、最後には絶対終わらない量の出力が必要になる...。残業量を増やすしかありませんね。最悪です。薬物依存のループに似てる気がする...ザンギョーウはヤメロ！Foo↑Foo↑
デイリースクラムで個人が抱えている問題が上がりにくくなる
毎日の定例イベント「デイリースクラム」では、タスクの進みが悪い時何がネックになっているのかを共有することが一番重要です。スクラム開発は計画したものをメンバー全員で達成することを主眼に置いているため、他メンバーが上げたアラートに気づけるタイミングを毎日置いています。
しかし、残業をして作業を片付けることが当たり前になってくると、「結構悩んで進捗も悪いけど、もうちょっと頑張ればなんとかなると思います。残りのタスクは残業してさばきます」という報告がデイリースクラムで多く見られるようになってきます。
大事なのは何がネックになっているのかを共有することであって、「がんばります」という意思表明ではありません。でも残業文化が根付いてくると、共有がされなくなって個々人がいつまでたっても同じタスク、同じ箇所で詰まって悩み続ける、といった事態に陥ります。かなり危険です。
慢性的にアウトプットの質が低くなる
残業での出力は、質ではなくて量です。
スプリント計画より進んだ量を開発する の頁にも関連しますが、残業を続けていくと自分たちが持っている出力 と 求められる出力 との乖離が進みます。
このとき、開発チームは当然以下のどちらかのパターンに必ず収束します。
- 自分たちが持っている出力 で長時間稼働し、求められる出力 に合わせる
- 求められる出力 を下げ、自分たちが持っている出力 に合わせる
前者の場合。
埋め合わせるためには残業をしまくるしかありません。
でも残業するころには疲労も溜まってきてるはずなので、例えば平常時にはしないはずの引数の型ミスやタイポなんかが起こりやすくなります。
それでイライラしてまた疲労が溜まって...の繰り返し。平常時に比べて、残業時のアウトプットは質が下がります。
平常時に1時間で終わらせられるタスクが、残業時では1時間半に延びるかもしれません。
でも埋め合わせるには、この質の悪い量でなんとか戦うしかありません。結果地獄を見ます。
後者の場合。
これまで開発チームが出してきた出力は幻でした...と社内に周知し、目標を下方修正することになります。
それだけでも十分ダサいのですが、問題視すべきは残業がすっかり板についてしまったチーム体制です。
目標が修正されたので、本来であれば次スプリントからは目標は残業なしで達成できるはずです。
しかし、残業が当たり前になっていると「この調査にもうちょっと時間かけても全体進捗は問題ないはず」という方向に進み、今度はズルズルと時間だけ引き伸ばしてしまうような働き方に陥ります。
この場合もアウトプットの質が下がってしまっていますね。質の悪い量を増やしてしまっています。
見て分かる通り、どっちに転んでもチームの成長は見込めませんね。
もちろんスクラムでは 「自分たちが持っている出力 を成長によって上げ、求められる出力 を出す」のが最高ですが、それは各スプリントでの出力を正しく測って、長期的に見てだんだんと出力の質が上がっていく場合です。
繰り返しますが、残業での出力は、質ではなくて量です。それも質の悪い、うすーい量。
そしてそれは残業を今後やめたとしても、ずっとチームに影響を及ぼし続けます。まるで薬物みたいですね...ザンギョーウはヤメロ！Foo↑Foo↑
残業してはいけない理由
ここまで読んだ人ならもう理由はお分かりかとは思いますが、一応タイトル回収という意味で。
残業をしてはいけないと言っているのは、
残業をする
-> 残業ありきのスプリント計画になる
-> やばそうなら残業してなんとかしようという思考になる
-> 残業する
-> ...繰り返し
という負のスパイラルに一度でも陥ってしまうと、チームとして立て直すのが非常に困難だからなんですね。
一度依存してしまったものから脱するには、相当の覚悟が必要です。それは開発形態においても同じ。チームを立て直すこと自体が大きな技術的負債の返済タスクになりえます。そしてそれは長期間チームを蝕み続けます。
そうなる前に、スクラムであらかじめ決められたカタチに則り、正しく成長しましょうよ、というお話なのでした。
まとめ
スクラム開発では、常に一定の出力を出すことを前提に計画を立て、実行します。そしてその出力は、開発メンバーの成長とともにじわじわと高くなっていくはずです。
「遅延ダメ！ゼッタイ！」はそらそうよって感じなのですが、スクラムにおいてはこの扱いが結構クセモノです。もちろん残業でエイヤするのは正直簡単です。しかし残業が当たり前になってしまうと、今回の話のようにスクラムの根幹から崩壊します。
残業 = 質の悪い量に頼ることなく、平常時の出力の質を上げて、そもそも計画の時点で余裕があるくらいのチームにしていきましょう！
明日もお楽しみに！！ザンギョーウはヤメロ！Foo↑Foo↑