「図で考えると全てうまいくいく!」的な標語で、 図解することを推奨する声をよく聞きます。
プロジェクトの現場でも、
「図が描けないのは、本質を理解してない証拠」などと言われ、
・伝えたいメッセージをうまいこと図で表現できないか。
・議論したことを分かりやすく図解で整理できないか。
ということを常に考え、とにかくまず「図」を描く
「図解至上主義」なるものがまかり通っている感もあります。
確かに、図解で整理したり、「絵」を描きながら議論するのは有効です。 その一方で、「図解」だけ見て理解できたと錯覚する危険性もあります。 というのは、図解のイメージ的な感覚では掴めていても、いざ言葉にして人に伝えようとした瞬間、実は解釈が曖昧で人に伝えられるほど理解できていなかったことに気づくといったケースがあるからです。
たとえば、新サービスのコンセプトであったり、新ITシステムの構想などを議論するといった場合。一緒に図を描きながら議論していくと、ともに考え「共創」している感覚もあり、その場の話も盛り上がったりします。そして、盛り上がった内容をうまいこと図解で整理できれば、とても満足感も得られるでしょう。
ただ、そこに一瞬の罠があります。
それは、「分かった気になって通り過ぎてしまう」ことです。
いうまでもなく、図ではある程度抽象化してシンプルにポイントとなるだろう点を浮き彫りにした形で表わします。
シンプルなだけに分かった気になり、その曖昧な理解をベースに次の議論に進んでいきます。
ところが、あれだけ皆が参加して議論して作った図をもっても、
のちのち見返したり、誰かに説明をしようとしたときに、
「結局どういうことだったっけ。具体的には何がしたいんだっけ?」
ということになりかねません。
図では分かった!と思っても
いざ具体的なアクションを考え始めたら、あるいは、その図を使って誰かを説得しようと試みた瞬間、実は自分がちゃんと理解できていなかったことに気づく。
そんなことが起こり得ます。
それを避けるためには、図解して理解したと思ったものを自分の言葉で文章として書けるかを確かめてみることが大切です。議論し、思考を巡らせそのアウトプットとして生み出された図を、最終的に「文章で記述できるか?」これが、本当に理解しているか否かの基準となります。
考えたことを図解で留めておかずに「言語化」しておくこと、
文章として記述しておくことが大事です。
箇条書きメモでいいですが、ロジックの流れがわかるように「接続詞」も含めた記述にしておくことが有効です。そうすることで、思考したこと、議論で理解したことが、次のアクションに繋がる、頭と肚に定着した理解となるのだと思います。
【プロジェクトの現場を勝ち抜く技術】
2016.11.08
2016.11.22
2017.02.28
2017.03.14
2017.03.28
2017.06.13
2017.06.27
2017.07.25
2017.08.08