つい先々月ぐらいまで１年間の平均退社時間が21:00でした。
少し前にXでハードワークについて百害あって一利無し的なツイートが回ってきて、
自分でも反省する部分が多かったため、少し整理したいと思います。
ハードワークについて今の考え
・短期的なゴールに向けては効果がある。（と信じたい）
・中長期的には確実に弊害を生む。（そして、短期で終わるものはほとんど無い）
・もうやらない。
高稼働の背景について
高稼働の背景は以下となります。
・新規システム開発の受託案件でプレイイングマネージャーを担当。
・設計工程では、設計メンバーの習熟度を補うため、テックリードとスクラムマスターの役割を兼任。
・設計工程後の追加要件・仕様考慮漏れに対する設計反映をひとりで対応。
・総合テスト工程では、QAメンバーの習熟度を補うため、テスト設計をしながら全体的な推進も担当。
・リリース判定に向けて、未整理だった品質状態を開発初期まで遡って分析。
結果、１年間の平均退社時間が21:00に。
案件に携わるメンバーの中で私ひとりの稼働が飛び抜けた状態に。
残された課題
高稼働を通して無事に初回リリースはできたものの、以下課題が残りました。
・一人で設計を行ったため、チームにプロダクト仕様に対する共有知を築けなかった。
・無理やりやり切ったため、スケジュールの妥当性に対する判断力が誰にも養われなかった。
・マネージャーが現実的ではないスケジュールでもゴールをしたため、開発チームにノーと言う文化を築けなかった。
本当はやるべきだったこと
リリース以降に適応型の開発が続くことが予定されていたため、本来は以下がとるべき動きだったと思っています。
・開発チームが一定の期間内で許容できるタスクのサイズを明瞭化する。
・実現したいことに対してリソースが不足している場合、充分な状態とできるよう調整する。
・受発注の関係でも、無理なことは無理なので、健全なプロダクト開発が推進できる文化を築く。
今からでもやるべきこと
現状、アジャイルでの開発方式に移行しており、開発チームは自立して課題を解消する方針を取っています。
私は開発チームから離れたイネーブリングチームとして稼働しており、主に以下を念頭に稼働しています。
・開発チームが不足している知識を明らかにし、随時補填の計画ができるようにする。
・自身が何かタスクを持つ場合でも、将来的に開発チームで実現すべきものは、アウトプットだけでなくインプットとプロセスを共有する。
・開発チームの認知負荷をウォッチし、負荷が高くなる場合は外部から除去できるように調整する。
ハードワークについて今の考え
・初回リリースは無事迎えられたが、以降の開発プロセスに向けては課題を生んでしまっていた。
・１年の21:00迄稼働は、その分の開発チームのビハインドを生んでしまった。
・ビハインドを埋めるために、個人が何かをするのではなく、チームでできる状態を醸成することを考える。
まとめ
チーム開発という考えが不足していたことに大きく反省です。
仮にハードワークを通して実現したものが、他の誰にも扱えないと意味がないし、
ハードワークを通さないと持続できないとしたら、それも意味がない。
やるべきことは、ハードワークではなく、ハードワークをしないで済む状態の醸成だったの思います。
…とはいえ、すでにやってしまった後なので、今更ながらでも改善していきたい。
2024年に振り返っておきたい内容でした。
参考
xn--97-273ae6a4irb6e2hsoiozc2g4b8082p.com
チーム開発とは文脈が違うけど、やっぱりハードワークよくないという話。
このブログ書こうと思ったもととなるツイートは発見できず。。もう一度読みたい。
