問題を問題として扱ってもらう技術(がほしい)
問題を発見する技術や、問題を解決する技術が話題に上がることは多いけど、それと同じくらい問題を問題として扱う・扱ってもらう技術って重要だなと思う。
仮に問題が発見されたとしても、問題として扱われなければ存在しなかったのと同じになってしまうので。
たとえば、問題が報告されたのに
「その問題は既知なんだよなあ…(ただし未解決)」
「その問題は誰が対応すればいいかわかんないんだよなあ…」
みたいになって解決にまで進まないケースを誰もが一度は見たことがあると思う。
そういうのってどう防げばいいんだろうか？
ちょっと考えてみる。
[備考]
書いてみたら長くなってしまった。
ひとつ読んでもらえるとしたら「前提の感覚を揃える」のところだけでも読んでほしい。
問題が問題として扱われないパターン
上に行くほど報告者側に依存する要因、下に行くほど被報告者に依存する要因っぽい感じにしているつもり。
問題として報告していいのかわからない
これってそもそも問題なのかな、仕様です(無知かよ)と言われちゃうのかなとか、既知の問題で「またかよ」みたいな顔をされちゃうのが怖いな〜という萎縮のパターン。
チームに慣れていないメンバーだったり、他部署の問題を見つけたときとかにありがち。
特に自分と縁遠い問題だと、そもそも問題を解決するインセンティブが小さいので見て見ぬ振りをされがち。(たとえば他社のバグをわざわざ指摘する人は少ないように)
問題の解決方法がわからない
自分の知識では、解決できるのかわからないのでこんなこと報告していいんだろうか、という迷いのケース。
そこから「それはGoogleの仕様が変わらないと解決できないですね」と言われちゃわないかとか、「一年くらいかかるめちゃ大変なやつですね」と返されちゃうんじゃないか、と萎縮して口をつぐんじゃったり。
問題として認識することに前提知識が要る
たとえば「Node.js の v10 のサポートが 4 月末で終了しちゃうんですよ〜」と問題が報告された時、Node.jsがどのように使われているのか、サポートが終了するとなにができなくなるのか等がわからない人だと「ふーん？」程度で終わってしまう。たとえば「Node.js の v10 のサポートが 4 月末で終了しちゃうんですよ〜」と問題が報告された時、Node.jsがどのように使われているのか、サポートが終了するとなにができなくなるのか等がわからない人だと「ふーん？」程度で終わってしまう。
問題として認識することに経験が要る
上記と少し似ているが、たとえば「スプレットシートのセル結合をいかにやめてほしいか」は、機械的な読み取り・計算を実施してみたことがない人だとなかなか辛みがわからない。
同様のケースは経理処理だとか、CMの例外お問い合わせ対応だとか、やってみないと、あるいは上手なアピールで辛さが表現されないと共通認識が生まれないことは多い。
問題のインパクトがきちんと計測されていない
たとえば本当は解決すれば100万円/月の収益増につながるのに、イメージで判断されて5万円/月程度の変化しかないと思い込まれているパターン。
ドメイン知識があまりないと起こりがち。(報告者にも、被報告者にも)
あるいはそもそも計測されていないパターンも多い。
計測自体に労力がかかったり難易度が高い場合もある。(単純に数値化しにくいとか)
問題を解決するフローがわからない
自分のチーム内で解決する問題ならともかく、たとえば部署をまたぐ問題とかは「どういうフローで解決すればいいんだ？」となりがち。
「誰に聞けば解決できるか」がわからないだけでなく、「誰なら、誰に聞けば解決できるか知っているか」すらわからないと手詰まり感が生まれやすい。
問題の解決自体はできそうでも、それを実行していいのか権限問題でわからないとかも含まれる。
誰の問題かが不明瞭
"問題"であることは確かなのだけど、誰がどう困るのか、誰に解決する責務があるのかが不明瞭で見合わせが起きて結局誰のボールにもならないパターン。
解決しようとしても解決策だけは出てきても「で、誰がやるんだ？」というところでたらい回しになったりする。
問題を解決する余裕がない
問題の解決方法自体はともかく、その時間的・金銭的コストを支払う余裕がいまは個人・組織にない、というパターン。
後回しにされた場合は、その判断が妥当なら問題はないのだけど、実は上記の
・問題のインパクトがきちんと計測・評価されてないだけ
・インパクト評価が間違っているので優先度判断も間違っている
というケースも多い。
また、後回しでいいとか解決する必要はないと判断されてはいるけど、その経緯や根拠が明らかにされていないことで「結局なんで対応しないの？」とメンバーの不満が溜まりっぱなしとかもよくある。
問題を問題として扱う・扱われるにはどうすればいいのか？
正直自分もあまり得意な領域ではないので、きちんと解決策を提示できている自信はない……が、ひとまずたたき台として書き出してみる。
上に行くほど報告者側の責務、下に行くほど被報告者の責務っぽい感じにしているつもり。
前提の情報を揃える
どういう問題なのか≒問題を解決しないとどのような困り事が起きるのかや、解決するにあたってのコスト等を、被報告者との共通言語で説明する。
互いの共通言語を使えているかが重要で、たとえば同じ職種間なら「〇〇に対応しないと××できなくなります」くらいで済むような説明も、
前提知識が異なる場合は「〇〇に対応しないと××できなくなります。そうすると毎月2時間位の作業が発生します」くらいまで落とし込んだほうがいい場合もある。
共通言語の最大公約数は「時間」と「金銭」だと思う。
前提の感覚を揃える
前提の情報を揃えるのに近いが、こちらは感覚や感情面。
「それを解決できないとどれくらい辛いのか」「仮に解決できたらどれくらい嬉しいのか」を定性的に表現する。
「××できない」というだけだと「そうなんですね」とスルーされてしまうかもしれないが、
「××できないせいで、毎月2日くらい潰れちゃってて、タイミングもバラバラでくるのに最優先で処理しないといけないんで他の仕事にも集中できないんですよ」と説明されると
「ああーそれはキツいですね、なんとか解決したいですね」と共感が得られてヨッシャ解決しますかとなったりする。
こんな感じで、「ヤバさ」の肌感覚を共有することで話が進むことは多い。
結局のところ、判断は(データを加味した)"感覚"で行われるのだから。
個人的には「ちょっとうれしい」のか「まあまあうれしい」のか「めちゃくちゃうれしい」のかの違いを教えてくれるだけでも判断の助けになるのでありがたい。
前提の感覚を揃える話は、ポッドキャスト「ゼロトピック」内でSmartHR社長の宮田さんが話されていたことを参考にさせていただいている。(そちらでは感情を揃えると表現されていたと思う)
ぜひそちらも聞いてみてほしい。
オープンに相談する
Slack等のオープンで誰からも追える場で声を上げると、自分の想定していなかった人も巻き込んで問題解決に向かえたりする。
くわえて、検索可能な状態であれば、後日似たケースにハマった人の助けになることもある。
解決はしていなくても、何度も報告されている問題だということで重要視されることもある。
タイミングを見はからう
自分の抱えている問題のようなテーマが取り扱われる会議体がわかっていたら、そこの議題として上げてみるとか、解決まで進めてくれそうな人がいる時間を見計らうとか…。
まずはSlackで言っておいからあとでちゃんと問題として取り扱ってもらう、みたいなあわせ技もある。
できればいつでもすぐに問題は取り扱われたほうがいいとは思うけれども、現実というものはある…。
何度でも言う
残念ながら初回の問題提起では解決にまで進まないこともある。
そんなときは、折を見て繰り返すのも一つの手。
「何度も言うからには重要なことなんだろう」という判断が生まれることもある。
賛同を募る
「その問題は解決したほうがいいよ！」と賛同してくれる人がいると解決までの"勢い"が出やすい。
あらかじめどの人がどんなところに興味を持っているのか把握しておくことや、関係を作っておくところからはじまったりする…。
本質的に"根回し" "社内政治"に近づいていくのでやりすぎは禁物…。
問題解決フローを知ってそうな人を頼る
自分の知らないフローを踏まないと解決できなそうなときは、わかりそうな人に頼る。
多くの場合はマネージャーとかリーダーとかがその位置にいるはず。
チーム外でも「あの人に相談すると進みやすい」みたいなことは世の中あるけど、これも"社内政治"に近づいていくのでやりすぎは禁物…。
できる限り正規のフローを踏みたい。
叩き台の解決策を提示する
叩き台として「たとえばこういう解決策とかどうですかね」と提示すると、人はつい「それでもいいですがもっといいアイデアがあります」とか乗ってくる習性がある。
仮に叩き台として提示した解決策が正しくなくても、目的が問題解決であればよしとする。
デメリットとして、トンチンカンなことを言ってしまうと「素人は黙っとれ…」感が出てしまうのがタマにキズ。
問題を評価できるようにする
その問題を解決しないとどれくらいのデメリットがあるのか、解決するとどれくらいのメリットがあるのか、解決するのがどれくらい大変なのかを明確化して評価できるようにする。
たとえば「いくら費用が浮く」「解決するのにどれくらいの工数がかかるのか」といったこと。
求められる具体度は意思決定者との共通理解の深さによる。
これによって逆に「いまは急いで解決しなくてもいいね」となったりもする。
問題はたいてい報告された瞬間がホットで、どうしてもすぐに解決したくなったりもするのだけど、本質的にもっと優先して解決すべき問題が転がっている場合も多いので、複数の問題を並べて評価できるようにするのは重要な工程。
問題解決フローを明文化する
あらかじめ「〇〇に類する問題はこれこれのフローで意思決定される」といった問題解決フローを明文化して普及させておく。
いっぽうで、既存の問題解決フローでは判断がつかないような例外ケースではどう対処すべきかまで表現されているとなおよい。
ゴールを決める
問題の種類によっては「当座の対症療法はAをすればいいけど、本質的にはBもCもDもやる必要がある」といったケースがある。
そして最悪の場合「BCDは難易度が高すぎるし、本質的な対応ができないならAもやらなくていいか…」てなったりする。
しかも現場は「いやAさえしてくれればしのげるんですけど…」と思っていたりする。
こういった場合は「BCDは後回しでもいいので、一週間後までにAをやっておこうね！BCDについては別途MTGで話そうね！」と一旦のゴールを決めてしまう方法がある。
余裕を持っておく
常にスケジュール通り消化予定のタスクでパンパンだと、予定外のタスクを引き受けにくいので問題が報告されても着手されにくい。
割り込みの仕事は発生するものだという前提でタスクや人員を組んでおいたほうがいざというときに動きやすい。
心理的安全性を保つ
発見されていても、報告されずに終わってしまう問題は想像以上に多いと思う。
それは、過去に問題を報告してスルーされたことがあるとか、無知を指摘された(ように感じた)とか、報告したらなぜか自分が解決まで担当することになったとか、知らない人に話しかけるのは怖いとか、そういうのの積み重ねで起こる。
問題を個人のうちに握りつぶされないように、共有を善とする空気づくりにつとめる。
要するに心理的安全性を保つということになると思うのだけど、言うは易し行うは難し、日々の態度の積み重ね。
ポジションを作る
解決できないわけではないが、現状の役割分担だと誰の責任範囲なのかがわからないので問題解決に着手されない、ということは多い。
もはや一個人のスキルからは離れてしまうが、別に個々人のやる気の有無とかではなく構造の欠如によって問題が解決されないこともあるので、構造ごと変えてしまおうというアプローチ。
おわりに
問題発見・解決の技術と比べると難しいのはたいていの場合「自分だけでは解決できないので、問題だと判断してもらう」というフローが挟まるところだと思う。
「こう振る舞うべき」みたいなコミュニケーションの比重が大きそうだし、自分でも書いてて甘い部分がたくさん見つかってしまったな〜。
視点が報告者視点と被報告者視点と第三者視点が混在して読みにくくなったのも反省、書いているうちに網羅したくなってしまったんだな…。
ストレートに「こうして自分の言うことを問題として扱ってもらおうテクニック」くらいにしておけばよかったのかな。
まあいいか。
なんか参考になりそうな本とかあれば教えてください。
娯楽のために使います