この記事はSmartHR Advent Calendar 2023 シリーズ2の5日目です
こんにちは！
SmartHRのプロダクトエンジニアの @diescakeです！
この記事では、私たち「ペーパーレス年末調整（以降、年末調整機能）」のチームでの開発や運用から得た ”教訓” をいくつかご紹介します！
教訓ってなに？
私たちはチームの振り返り（レトロスペクティブ）で度々取り上げられたKeepやTry、また「これは心に刻んでおかなければならない」と共通認識になったものを教訓としてストックしています。
2021年9月に最初の教訓が生まれ、2023年12月時点で以下16件の教訓があります。
- 平和は当たり前にあるものではない
- 他メンバーがインシデント対応中でも、手が空いている人は平和を噛み締めて生きる！
- やみくもに仕組みを増やして解決した気にならない
- 通信で怪しい動きを発見したら、まずは物理層を疑え
- まずデータを見よう
- 仕組みでふわっとしているポイントがあったら、担当者を決めてかためていこう
- 負荷の総量保存の法則
- 完璧じゃなくても、まず小さく始めることが大切
- 二度やる作業は三度やることになる
- 忘れない努力ではなく忘れても大丈夫な運用をやっていこ
- 決戦は火曜日
- 作業にハマってなくてもHuddles（ハドルミーティング）で配信していこ
- いろんな職能のメンバーを巻き込んでいこう
- 作業メモはストック情報として保存していこうな
- 「担当」や「職種」にこだわらずに、必要だからやる！という精神を持とう
- ミーティング参加者が進め方（アジェンダ）に腹落ちした状態で進められるようにしよう
デイリーで開催される朝会（デイリースクラム）では、曜日ごとにアジェンダを自動生成していて、そのなかでランダムに1件ピックアップした教訓が表示されるコーナーがあり、想いを馳せるようにしています。
この記事では特に意識される頻度が高かったり、日常的に活用されている教訓の中からある程度汎用性が高めのものを3件ピックアップして紹介します！
決戦は火曜日
スプリントの生産性を高く保つために、スプリントの前半（火曜日）に山を持ってきて不確実性の早期解消を目指そう、という教訓です。
スクラムを採用している私達のチームでは、月曜日を起点とする1週間スプリントで開発しており、火曜日から本格的にスプリントタスクの実装に入ります。
スムーズにバーンダウンできたときのレトロスペクティブで要因を深ぼりすると、初速が早くスプリント開始直後に進捗が出た場合に安定してバーンダウンができていることに気づきました。スプリントの前半に不確実性を低減し、解像度を高めることで、仮に想定外の問題が発覚しても打ち手を講じやすくなります。
実際にスプリントタスクの実装に入ってみると、仕様面で他にも考慮すべき点に気づいたり、逆に実装上の理由で仕様の微調整が必要な場面が出てくることがあります。こういったことがないように事前に不確実性を低減することは重要ですが、残念ながら完全にゼロにすることはできません。そのため、実際に問題が起きたときにコントロールできることも重要だと考えています。
また、この教訓の再現性を高めるために私たちのチームでは、火曜日をMTG OFF DAYとしてスプリントタスクに集中する日としています。連続した作業時間を確保することで、開発メンバーが同時に働けるようになり、ちょっとしたときにSlackのHuddles（ハドルミーティング）やZoomで相談するといった同期的な時間も確保しやすく、レビューなどのリードタイム短縮にも効果があります。
他メンバーがトラブル対応中でも、手が空いている人は平和を噛み締めて生きる！
他のメンバーがトラブル対応などで忙しいときでも、手が空いている人は普段通りの生活を過ごそう、という教訓です。
ついつい「みんな忙しそうだから早く帰りづらいなぁ」「スプリントの開発タスク進めていて大丈夫かな」などと、思ってしまう話を耳にしますが、そこは普段どおりに過ごすことが重要です。
普段どおりに過ごしてもらうからこそ、対応中のメンバーは「なにかあってもみんなが何とかしてくれる」と安心して集中できます。普段どおりの日常を過ごして有事に備えることこそが最高の貢献となります。
教訓として明文化しチームで共通認識を持つことで、気兼ねなく実行しやすくなります。個人的には結構気にしてしまいがちな性格なので、特に好きな教訓の1つです。
「ここは俺に任せろ！先にいけ！」といわれたら躊躇わずに先にいきましょう！
負荷の総量保存の法則
業務フローや課題の見直し、プロダクトの改修によって、ある人の負荷が減少している場合でも業務全体の負荷が減っているとは限らない、という教訓です。
上図はこの具体例を表したものです。
ある業務フローにおいてAさんの負荷が高い状態が課題となっており、これを解決するために業務フローを改善した結果、Aさんの負荷を10%まで削減できたとします。しかし、その裏ではBさんの負荷が高まっていて、全体として負荷の総量は100%のまま変わっていないという状況です。
特に複数のチームやロールにまたがった業務の見直しをするとこの問題に陥りがちです。こういった状況を回避するには、負荷のかかっている対象に着目するだけでなく、全体を俯瞰して負荷の分布を把握することが重要です。一言で「負荷の分布を把握する」といっても簡単ではありませんが、まず意識をして関係者と対話をするだけでも大きく違ってくるように感じています。
また、ある施策で負荷の総量が減らなくとも必ずしも意味がないわけではありません。例えば、特定の人やロールに集中していた負荷を分散させることでボトルネックを解消し課題を解決できることがあります。
繰り返しになりますが、重要なのは負荷の総量がどのように変化し、どのように分散されるか意識する点にあると考えています。
おわりに
以上、私達の開発チームで得た教訓を3件紹介しました！
冒頭でも触れたとおり、読者にとってイメージしやすそうな汎用的な教訓をピックアップして紹介してみました。教訓としてストックするにあたって、声に出したくなるような語感のよさや、印象に残りやすいフレーズだったり、遊び心を含めることも大切だと感じています。
しかし、あらためて感じるのは、本記事も含めた世の中のプラクティスは単にチームに共有したり、適用するだけでなく、チームメンバーが同じ課題意識を持って、それを解決する手段として認識することが重要で尊いように思っています。
この記事が、皆さんのチーム開発の何がしらの参考になれば幸いです！
…
さて、遊び心といえば……
SmartHRには「オープン」「フラット」「遊び心」「自律駆動」というカルチャーがあります。
こういった何でもない日常的な開発でもそのカルチャーの一端が感じられます。遊び心っていいですよね。
そして、そんなSmartHRはウェブアプリケーションエンジニアを募集しています！
エンジニア採用サイトもリニューアルしてコンテンツが充実していますので、「もう前に見たぜ」という方もぜひご覧ください〜！
