【V1-03前編】役割ごとに異なるSo what? をまとめて解決する

f:id:ko1hayashi:20190527002943j:plain:w400

今回は、初回配信予定の6回のうちの第3回になります。内容ですが、前回に続いて｢So what?｣についての解説です。人によって違うということは、登場人物が複数いたらどうなるのか、というお話です。

※本記事は日経SYSTEMS2018年6月号掲載記事の著者原稿を再構成したものです。

役割ごとに異なるSo what? をまとめて解決する

現場の問題はいつも応用問題

第1回と第2回で、仕事を効率的に進めるテクニックとして、報告中にSo what? を明示することの大切さと、それが相手によって異なることを示し、その理解のために足場となるコンテキストを意識するWHSLモデルを紹介した。

では、So what? が複数あるときはどうすれば良いのだろうか。これは、それほど珍しいことではない。現場で起きることは応用問題である。So what? が一つしかない基礎問題では不十分だ。ロジカルシンキングを勉強しても使えない理由は、基礎を応用につなげられないところにある。もちろん、基礎問題の解けない人には応用問題は解けない。

前回に続いて、次の報告メッセージを使って説明していく。

当社が開発担当したA社のシステム共通機能で先週末に不具合が発生した件です。本日の緊急招集でわかった状況を速報します。不具合を出していたのは、個別システムのベンダーが当社の共通機能を使用せず、独自実装した箇所であることがわかりました。よって、今回の不具合では、当社の担当部分に問題はなかったということになります。

改めて背景を説明すると、この報告メッセージは、自社の製品に関連する不具合が発生したことで、緊急招集をかけられた技術責任者が、そこで得た最新状況を速報したものだ。この会社ではA社のシステムの共通機能を作っており、個別システムから呼び出すことになっている。共通機能に関わる不具合であったため緊急招集されたが、実際にはその機能は呼び出されておらず、独自実装された部分で起きていたことがわかったという話だ。

事実である「当社の共通機能が使用されていない」を根拠に、上司にとって知りたいSo what? である「自社の機能に問題はなかった」という結論を導いている(図1)。

役割の数だけSO WHAT? がある

ここで少し想定を加えることにする。もし、懸念されていたように、問題が自社の開発した機能にあった場合、すぐに不具合解決の作業が必要にある。しかし、開発が完了した機能であれば、当時の開発スタッフは別の業務を担当しているはずだ。そこで、彼らには、必要になったとき作業が開始できるように待機してもらっていたとしよう。待機しているスタッフにとって、上の結論は知りたいSo what? だろうか？

会社の責任かどうかも大切だが、それ以上に直近の関心事は、不具合解決の作業をはじめる必要があるのか、あるいは、待機状態を解消して本来業務に戻って良いのかである。事実は一つだが、その意味する So what? は人によって違うのだ。