開発チームの有給を守るのはアジャイルと強いリーダー #アジャイル

サマリ

という話をします。

これまで有給休暇のとりにくい組織で働いた経験のない人、あるいは「認められた権利は行使して当然」という強い心をお持ちの方には共感いただきにくい話かもしれません。

筆者の経験で、有給休暇を気兼ねなく取れた環境と、そうでない環境とがありました。

会社がブラックで有給なんて体調不良以外認めていないとか、上司が渋い顔をするとか、決してそういうわかりやすい阻害要因があるわけでなくても、有給を取りたくてもなかなか取れない状況が続いた会社と、そうでない会社とがあり、この違いは何なのだろう、と考えたのが本記事の経緯になります。

会社として有給消化を推奨しているにも関わらず、（気持ちよく）有給を取得できない状況というのは、個人の経験としては以下のような場合でした。

ポイントとしては、たとえ会社として「遠慮せず有給取っていいよ」と言ったところで、それを取れるかどうかは、そういう状況を作り出すことができるかどうかによる、言い換えると、気持ちよく有給をとれる状況を作るためには技術が必要だ ということです。

プロジェクトが炎上中という最後のケースについては、ある程度（炎上してからでは）どうにもならない部分もあり、まず炎上させないためにどうするか、という話になるかと思うので本記事の内容からは少し外れます。

それ以外のケースについてですが、個人的に有給の取りやすさに寄与していたなと思う要素として、「アジャイル開発」と「強いリーダー」を挙げることができます。

ウォーターフォールなど、イテレーションのない開発スタイルの場合、「では2か月後の○月末までにこの機能の実装完了としましょう」といったスケジュールの立て方をすることが多いと思います。

通常、この「2か月後の○月末まで」という見積もりを立てる段階では、（ある程度バッファを設けるにせよ）その間にとる休暇の予定まで考慮していないことが多いでしょう。

そもそも、数か月単位で精緻な工数を見積もること自体が難しく、結果として、期日近くなった段階で進捗が思わしくなくて休みを取れなかったり、期日が遠くても、見通しのわからない不安から有給の取得に慎重になりがちです。

アジャイル開発により、イテレーション（スプリント）が1～2週間単位で区切られていれば、短期的にはその期間での成果のみに集中することができます。

有給取得の予定がイテレーション開始前にわかっていれば、あらかじめその人の作業工数（キャパシティ）から引いておくことができるため、休んだことによる作業の遅延を気にする必要がありません。

ところが、チームとしてアジャイル開発・スクラム開発を導入しただけでは、それは開発サイドの論理でしかありません。

それをビジネスサイドに認識・理解してもらうために、開発サイドの強いリーダーが必要となります。

リーダーという呼び方をしていますが、それは組織によってスクラムマスターであったり、CTOであったりすると思います。

とにかく、中長期的に精緻な見積もりは不可能であり、その代わりにイテレーション単位で動く成果物を共有することを約束し、必要に応じて期日の調整または機能の取捨選択を継続的に行うということを企業文化として根付かせる働きをする人が必要です。

その努力なしに、開発内の閉じた世界でのみアジャイル開発を導入したところで、ビジネスサイドから「○○日までになんとしてもリリースが必要だ。進捗はどうなってる？」という横やりが入ることになり、結果「有給は取ってもいいけど自己責任で」のようなおかしな言説が横行することになります。

エンジニアの仕事に限った話では全然ありませんが、「休んでいるときは緊急の対応を受けられない」「休暇の取得によりイテレーション単位の成果にばらつきが生じることがある」というごく当たり前の文化も、それを文化として根付かせ・維持しようと戦う人がいなければ容易に失われてしまうものです。

アジャイル開発の思想に限らず、開発の論理をビジネスサイドと共有し、また逆にビジネス観点で死守すべき論理を理解し、相互理解を深めることが組織として正のループを回すために重要です。

有給休暇の取得という本内容をその一例として消化いただければ幸いです。