ウワノキカクのキカクメモ│問題解決のための論理・ロジカルシンキング

問題解決のためのロジカルシンキングを学ぶためのブログです。

問題を定義するのが難しいのはどんなとき?│問題解決の実践

問題解決の仕事をしていると、「問題が解決できないのは、問題が何だかわかっていないから」というのが大抵の組織に共通する課題なのだということがわかってきます。


「解決すべき問題を正しく定義する」というのは、思っている以上に難しいことで、コンサルティングの世界では

「問題が正しく定義できたなら、その問題はもう半分解決したのと同じことだ」

といったことが言われるわけです。


昔は何を言っているのかピンときていなかったのですが、最近その言葉の意味が体験を伴ってわかってきましたので、コンサルティング実務でおきた体験談をベースにそのリアルな学びをお伝えしていきます。

本当の問題がわからなくなるとき

f:id:amsoat:20180330101633j:plain

問題は見えているのか、いないのか?

自分の体験としては少し古い仕事なのですが、あるメーカーさんでお仕事させていただいた際のこと。話を伺うと

「設計開発部門が足を引っ張っており、会社全体が困っている!」

とのご要望で、その部門を批判するようなお声をたくさんいただきました。


「それだけ言われるとは、どれだけダメな人たちなんだ」と感じるような話っぷりだったので、当の部署までいって話を聞いてみることに。


そこでは、部署内外で起きている様々な問題を、開発部門視点で教えてもらいました。


そこで出てきたのは様々な悲痛な声なのですが、ざっくりとまとめると

「とにかく忙しくて時間がない
「大切な~という仕事に集中できない
「他の部署が~してくれない

など「あってほしいものがない」系のお困りごとがたくさん出てきました。


設計開発部門の方々は口を揃えて

「とにかく忙しすぎることさえなんとかしてくれたら、俺たちはいい仕事ができるんだ!」

と強く主張していました。


こちらは真剣に耳を傾けつつ、とはいえそのまま鵜呑みにはしないので、素直に

「なぜ~が必要なのですか?」
「〜してくれない部署の人たちがそれをしてくれるようにするために、何ができますか?」

と聞きますが、できない理由が繰り返されるばかりで、要領を得た答えは一向に返ってきませんでした

それは解決すべき問題か?

曖昧な書き方をしましたが、実際に設計開発部門から聞こえてきたのがどんな要望だったのでしょうか。


繰り返し主張されたのは

「営業から客の要望書が納期通りに来ないから、設計も納期通りに返せない」

というお悩み。


なんでも、この会社では要望書(仕様書のようなもの)の提出から設計開発部門の回答までの一般的な期日が決められているとのこと。

「ただでさえ厳しいスケジュールなのに、それが守られていなかったら納期遵守なんて持っての他だ」

そういうので過去の納期記録のデータを分析すると、なんと、営業が納期を守って要望書を提出したものも、そうでないものも、等しく同じくらいの日数が遅れていることがわかりました。


なぜこんなことになるのだろうと営業部門と設計開発部門共同で議論してみると

「どうせ設計開発は納期が守れないから、初めからあえて厳しい納期で出している」
「設計開発の遅れを見越して客先とはスケジュールを握っているから、最悪の事態はいつも免れている」

と営業談。


これには設計開発部門も怒るかと思いきや、どうやら薄々わかっていたようで、特に大きなリアクションはありませんでした。

何が本当の問題だったのか?

設計開発側からクレームが噴き出してもおかしくないこの状況、なぜこの問題はスルーされたのでしょうか?


それは「設計開発も、顧客の納期を守ることが最優先なのは認めているから」でした。


営業に振り回されて理不尽な思いをしているのは事実だが、一方で、無茶振りばかりの顧客をうまくコントロールしているのも営業。


顧客の元に同席することもある設計開発からすれば、顧客からのプレッシャーを捌いてくれていることには感謝なわけです。


とはいえ、短納期ではいい仕事ができないのは事実で、書類で回答する設計開発担当者も

「これじゃまた手直しになるだろうな」

とわかった状態で仕事を回さざるを得なかった。


そこで、現状ツリーを作って問題相互の因果関係を分析してみると…

回答の品質が低い
→顧客から緊急の修正指示が入る
→スケジュール通り仕事が進まない(予定からどんどん遅れる)
→遅れの酷い順から、最終納期に間に合うように短納期対応をする
→回答の品質が低い

という悪循環が回り続けていることがわかりました。
※現状ツリーについては以下の記事をご参照ください
blog.uwanokikaku.xyz


ざっくりいえば、品質の低い仕事しかできない常態的なキャパオーバーが一番の問題で、そんな状態では仕事の優先順位がまともにつけられず「納期が遅れたものから本格的に着手する」状態になっていた。


いわば「営業から設計への要望書の納期」なんて一つの現象でしかなかったわけです。


だからこそ、「なぜ?」「どうすれば?」とこちらが質問しても筋の良い回答は得られなかったわけです。

問題が正しく定義できるとき

f:id:amsoat:20170222182012j:plain

問題が見えれば解決策は明らか

いろいろと考えた結果、上記の悪循環が諸悪の根源だということが見えてきました。


すべての問題の現象はここから生まれてきていることが、関係各位に合意され、いざこれをなんとかしようということになっていきました。


問題の因果関係が見えて仕舞えば話はスムーズで

一発OKがもらえる回答を営業と設計開発で連携して作る

という方針を目指すことになりました。


営業は使える時間を顧客の要望を丁寧に引き出すことに注力し、特に「こういう場合は?」「こうなったら?」と設計開発部門で詳細な確認事項が上がった際はすみやかに顧客に確認を取りに行くことにしました(それまでは、そういう疑問を残したままざっくりと回答したり、場合分けして複数のバリエーションを検討したりしていた)。


社内の課題情報の共有を徹底し、コミュニケーションも円滑になっていく過程で、段々とスケジュールも共通のものを使うように自然と変わって行ったとのこと。


主要な関係者が根本問題に合意したことで、解決すべき問題の定義が明らかになり、組織が変わっていきました。

優秀な人ほど問題を抱え込む

ちなみに、こんな出来事が起こっているのは日本でも優秀な人が集まっている会社。一人ひとりは馬鹿じゃないどころかとても賢い。


それでも、組織の中にいると轍にハマり、問題の本質が見えなくなってしまいます。


経験的には、優秀な人ほど「ちゃんとやればできる」と思って、問題を自分のところに抱え込んでしまう 傾向がある気がします。


組織というのは得てしてそういうものなので、常に組織の全体を客観的・俯瞰的に見る目が重要になります。

おわりに

f:id:amsoat:20191013194726j:plain
こうした問題解決の現場のことを見たときに

「なんて馬鹿なことをやっているんだ」

と思う人と

「自分たちも同じようなことになってるな…」

と思う人がいると思いますが、私は私自身を含め「他人事じゃないな」と感じています。


形を変えて同じことは自分にも起こりうるし、いまも起こっているかもしれない。


そう思って襟を正すことによって、現実の見え方も変わってくるように思います。


ということで、こうした問題解決の実践について考えていきたい方は以下のリンクもご参照ください。
blog.uwanokikaku.xyz