課題設定の前にまず自身の問題意識に目を向ける

課題設定の前にまず自身の問題意識に目を向ける

適した方法論を使うことの大切さという記事を書きました。

先日、プロジェクトマネジメントについて話をする機会があり、聞いて下さった方の1人(Aさん)が、ご自身の営業のお仕事に応用したいとおっしゃっていて、その場で詳しくお伝えできなかったので記事で補足しています。

Aさんには、チームでプロジェクトを進めるにあたり共通言語が大事、という話をしていたときPMBOKのフレームワークに刺さるところがあったようです。

ここで、「共通言語化が大事だと思うのでPMBOKの枠組みを導入しよう」という相談を受けたら、私ならまずその前提の確認から入ります。すぐに導入の話はしません。

解決策や課題設定の前に

早く現場をなんとかしたいAさんにとっては、じれったさもあるかもしれません。

しかし、解決したい課題が明確にならない限り、適した解決策は出ません。

現時点で見えているのは何でしょうか。

それはAさんの問題意識です。

Aさんの今の営業の職場で、何らかの共通言語があるのが望ましいのに今はないこと。わかることはそれだけです。

ここでいくらPMBOKなどを駆使してその現場に適するであろう共通言語を提案したとしても、それが喜ばれる可能性はどのくらいあると感じますか?

現時点では、Aさんの視点で共通言語がないことにより、職場内の他の人の考えていることややっていることが見えづらかったり、Aさんのことを職場の他の方から見えづらい(とAさんが職場の方から言われる)ということのみが想像できます。

今度これは私視点での想像に過ぎません。ここまでを読んでも異なる仮説を立てる方もいると思います。

その問題は誰が解きたいか

ここからのアプローチは私が心がけているものですが、とても大切なことと考えています。

それは、自身の問題意識を全体の問題意識にいきなり広げない、ということです。

「Aさんの職場で共通言語を持つには?」

という課題設定で走ると、案が大きくまとまればまとまるほど、職場の人にとっては特に必要と感じていないものが唐突に目の前に出てくる感じがしてしまいます。

この時点で職場の方から得られる反応の多くは、共通言語そのものの内容やその手段であるPMBOKに対するものであって、Aさんの問題意識に対してにはなりづらいでしょう。

職場の方が知りたいのは、一般的な共通言語の大切さやPMBOKの特徴ではなくて、Aさんがなぜその問題意識を持ったのか、だと思います。

Aさんはその職場の一員であり、そのAさんが問題だと感じている点は何なのか。それにより、Aさんはどういう痛みを抱えているのか。それにより職場の他の人や全体としてどういう痛みや損失につながっているのか。

自身の問題意識の共有が進むと

この問題意識そのものへの対話ができ始めると、他の方の感じ方を聞くこともできるかもしれません。同じように感じている方がいたり、すでに過去に似た取り組みがなされていることを教えてくれるかもしれません。斬新なアイデアを他の方が持っていたり思いつくこともあります。

このように現場のそれぞれの問題意識が集まってきて全体としての課題の方向性が見えてくると、それを整理して仮説を立てて検証する方法が浮かんできます。

もしかするとPMBOKによる共通言語化が解かもしれませんし、他の解が出てくる可能性もあります。

皆さんならどうされますか?



このブログを書いている人

電子書籍「システム導入のためのデータ移行ガイドブック」著者。
新卒から外資系コンサルティングファームに所属。15年に渡り販売物流、特にCRM領域のコンサルティングに従事。
100名を超えるプロジェクトのPMOなど全体を推進していく役回りや、ユーザ企業への出向を通じた実務経験を持つ。

このブログでは、自身がかき集めた知識や経験を共有する。クライアントへの提案やソリューション開発に直結しないガラクタのようなもの。将来再利用する自分のために。同じような悩みを抱える誰かのためにブログ「外資系コンサルのガラクタ箱」を運営

スポンサーリンク