場当たり的な不具合修正に追われてるときこそ俯瞰的に理想像から考える

最近仕事をしてて大事だとと思ったのでメモ。

プロダクトの不具合、見つかるときは立て続けにどんどんたくさん見つかります。

不具合が見つかるきっかけは色々です。自分たちでプロダクトのドッグフーディングをしていて見つかったり、お客様からのフィードバックで見つかったり。

特にお客様からのフィードバックで見つかった不具合は、なんとかなるべく早く修正したくなるものです。問題のインパクトや影響の大きさにもよりますが、暫定対応はなるべく早く行い、事象の解消をしたあとで、落ち着いて恒久対応や Postmortem に取り組みたいもの。それはそれで大事です。

でも、不具合の件数が少ないならまだしも、何件も連続して不具合が検知するような状況だと、恒久対応や Postmortem がおざなり、あるいは後回しになり、場当たり的に目の前の不具合対応を行い続けるような状況が慢性化してしまいがちになります。

こういった状況は以下のような現象を引き起こしてしまうリスクを高めてしまうため、できるだけ避けたいです。

• 局所的な解決策に陥ってしまい、問題を本質的に大きく解くことができなくなる
• 問題を必要以上に細かく分割・単純化してしまい、問題がかえって複雑になってしまい、解くのが難しくなる
• 本来必要のない技術的負債がたまり続ける
• 今解決すべきじゃない（＝解決しなくても良い）不具合対応も行ってしまう
• 不具合修正がまた別の不具合を生み、いたちごっこになる
• 突発性のタスクにチームが追われ続け、本当に取り組みたい課題に集中して取り組めなくなる

プロダクトの不具合修正を場当たり的に行っているような状況が慢性化しているなぁと感じたら、いったん手を止めて、落ち着いて全体的な理想像から俯瞰的に考えてみるのが良いと思います。

• 自分たちのプロダクトはミッションや、ロードマップ、直近のマイルストンはなにか
• その上で、自分たちのプロダクトはどういったユーザーのどういった課題を解決するためにフォーカスしているのか
• そのユーザーの課題に対して、プロダクトとしてはどういう状態でどういう価値を提供すべきか（To Be）
• そこに対して、現状プロダクトは何をどういう形で提供できているか、あるいは提供できていないか（As Is）
• To Be と As Is の間のギャップを埋めるためのに必要なアクションはなにか
• それぞれのアクションに対してどういう順番で優先的に取り組むべきか、その判断基準はなにか

焦らず、改めて上記のような内容を整理して、ドキュメントに起こしてみると、目の前に発生しているプロダクトの不具合から、何段か視座が上がります。自分たちのプロダクトが本来進んでいきたい方向性や、アプローチしようとしているユーザーや課題の全体像を俯瞰して捉えやすくなります。

その上で、目の前の不具合に視点を戻してみて、以下のようなことを考えます。

• この不具合は別で発生しているこの問題とも関連しているから、もっと大きく汎用的に考えて、合わせて解いた方が良いな
• この不具合は確かに困っているお客さんはいるけど、他に発生している問題のほうが優先度は高い。問題を迂回する方法はあるから、申し訳ないけど今はその方法を使ってもらうようお願いして、また後日対応しよう
• この不具合を解消したあるべき姿はこうだけど、一気にそこまで進むのはコスト的に難しい。少し手前にマイルストンをおいて暫定対応とし、その後あるべき姿により近づけるための検討をしよう。

お客様に与えるインパクトを鑑みて、場当たり的な対応が必要になるときももちろんありますし、それ自体は否定しません。でも、いったん手を止めたほうが、短期的には回り道でも、長期的にはプロダクトの提供価値をより高められることにつながるはずだと考えます。

ジグソーパズルも、完成イメージを俯瞰的に捉えながら作っていかないとなかなか完成にまでたどり着けません。プロダクトの不具合修正（に限らず、プロダクト開発全体）も同じ。

そうやって俯瞰的に整理した全体的な理想像をドキュメントにしておいて、ことあるごとに常に立ち返られる場所としてチームで使っていけると、より良いプロダクトを作っていけるのではないかなと思います。

おわり。