問題は狭く伝える
こんにちわ。従業員体験( EX ) の向上がミッションのエンジニアリング統括室に所属しているてぃーびーです。
仕事において様々な問題が発生します。業務を通じて違和感を感じ、関係者に問題を報告する際に、その報告には粒度が存在します。
今回は、問題の報告粒度についてまとめます。
問題の報告粒度
問題の報告粒度とは、問題をどの粒度で報告するかの度合いです。
例えば、チームでは A, B, C の3つのシステムを扱っているとします。
システム B の画面 x にある機能 x1 に問題があったとします。
この際に、
- B システムに問題がある
- B システムの X 画面に問題がある
- B システムの X 画面の x1 に問題がある
のどれで報告するのか、が報告粒度です。
問題を狭く伝えること
先程のケースで問題を一番狭く伝えるのは 3 です。
問題が本当に存在するのかどうか確認する必要のある範囲が狭く、時間をかけずに対応することができます。
問題を広く伝えること
先程のケースで問題を一番広く伝えるのは 1 です。
問題がどこに存在するのかわからず確認する必要のある範囲が広く、調査箇所を把握するために 3 の粒度に至るまで掘り下げて質問をして情報を引き出してから対応する必要があります。
また、第一報として 1 を聞いてから詳細を引き出すまでの間、報告された側は広い範囲のどこに問題があるかやきもきしたり不安になる可能性が高まります。
例外処理で考える
問題をどの粒度で伝えるかは、例外処理の扱いに似ています。
例えば、 ウェブシステムの API サーバーの処理について
- A 一番上の階層の処理ですべての例外をまるっとキャッチして処理している場合
- B 個別の処理で必要に応じて例外を出し分けている場合
を考えてみます。 A の例外に関するログをみても実際にどこで問題が発生したのか把握が困難です。結局デバッガーを用いるなどして詳細に確認することになるでしょう。 B の場合は問題箇所がかなり絞られ、すぐに問題を確認できます。
まとめ
今回の説明に用いたケースではそもそも広い粒度で報告してくる人はほとんどいないかもしれません。
しかし、開発に近い領域を離れて普段の業務プロセスや組織全体の話になった途端、話がふわっとしがちではないでしょうか。
開発で例外を扱うように、その他の業務について会話をする際にも具体的に問題箇所にフォーカスしてやりとりできるとよいでしょう。
