この記事は CARTA TECH BLOG アドベントカレンダー2024 の 12/13 の記事です。
Lighthouse Studio でエンジニアをしている yoko です。この記事では、自分が実践している手戻りを減らして効率的に仕事を進めるための工夫について紹介します。
何かしらの仕事に対して、手戻りが発生したことはありませんか？エンジニアであれば実装を終えて自信を持って PR を出した時に「解決法が違わないか？そもそも解くべき課題は本当にこれなのか？」とレビューアーに指摘されるなどです。
この記事では、この手戻りを減らす工夫について話していきます。
手戻りとは？
この記事では手戻りを「ある課題に対して行動していたが、やり直しになった」状態と定義します。
前提として、結果がどうであれ意味のない仕事はないです。やり直しになったとしても培った知見は今後に生きると思いますし、そもそもやり直しになった対応がイマイチだとわかっただけでも価値があります。
しかし、仕事には期限があります。
例えばクライアントに対する期限や、競合より早く新機能を出すための期限などです。
この期限という制約があるので、大きな手戻りが発生すると大変辛い状況になります。
手戻りが発生するケース
手戻りが発生するケースは、大きく分けて以下の2つがあると思います。
- 解決法が違う
- そもそも解くべき課題が違う
特に注意したいケースが 「そもそも解くべき課題が違う」 手戻りです。それまでやってきたことの前提から覆されるので、なるべく初期段階で気づく必要があります。
手戻りを減らす工夫
結論としては「仕事を進める前にフィードバックをもらう」という工夫が手戻りを減らす上で効果があります。
自分はこの工夫を実践するために、大きな仕事を進める前に相談会を開いてフィードバックをもらうようにしています。
主に開発チームのメンバーに参加してもらい、自分が進める仕事の方針や実行しようとしている対応についてフィードバックをもらいます。
相談会の詳細
相談会では事前に仕事の内容をドキュメントにまとめ、それを元に話していきます。内容はものによって変わりますすが、基本的には以下のフォーマットでまとめています。
- 背景
- ゴール
- ノンゴール
- 期限
- 制約
- 予算など
- ゴールを達成するための対応
- システム案や構成など
そしてこのドキュメントをもとに話し合う中で、「そもそもこのゴールを達成して価値があるのか？」「別の対応の方がいいんじゃないか？」といった会話が生まれ、前述の手戻りを発生させるような問題にいち早く気づくことができます。
