学べる経験談学べない経験談

ワタシは聞かれなければあえて自分から経験談は話さないようにしてきましたが、加齢とともにだんだんとその自分に課してきたこともルーズになってきたのでちょっと反省してみることにしました。

他の人の経験談も気づき、学びがある場合とない場合がると思うのです。ワタシが話す経験談はそのどちらかなぁ、と。

経験談とは
まず、経験談でも学びがある経験談の特徴は何か、と。経験談はその話をする人が課題に直面して特に印象に残った話になるとおもうのです。印象に残るからにはその経験には特徴があります。だから、記憶に鮮明に残っているのです。

ただ、その経験談も話す本人と同じプロジェクトにいて一緒に乗り越えた人だけがわかる内輪ネタばかりであっては、その話を聴く側は同じ経験をしていないのですから内輪ネタなんか面白いわけもないし、そんな話はから何も得られることもないですよね。「あー早く終わらないかなー」と思われても仕方がない。

課題が提示されている
経験談を話す人にとって印象に残ったこと。例えば、プロジェクトでシビヤな意思決定をするような状況に追い込まれた、そういったプロジェクトの進捗上の大きな障害に阻まれたというような課題があったわけです。だから印象に残っている。

どういった課題だったか知りたいですよね。開発途中でパッケージプログラムの製品バグと思われる動作不良が発見されたときに「プロジェクトに残された期間があと２ヶ月で…」でも「リリース時期は変えられなかった」などなど。

おなじ製品バグでもそれが発現するタイミングにより、プロジェクトの対応が全然違いますから。

課題解決したプロセスが想像できる
印象に残るくらいですからその課題解決のために知恵を振り出して乗り越えた、ハズです。だから記憶に刻まれているんですよね。その課題を乗り越えるためには当たり前の、若しくは、通常ととは違う特別なプロセスを経て課題を解決してきた、と。

課題に対して選択したプロセスを経た結果、期待した結果かそれ以上の結果を手にいれた、と。

その課題を解決したプロセスを知りたいのです、聞く側は。「解決方法くらい自分で考えろ」というのはこの場は経験談を聴く場なのでちょっと横におきておきましょう。ワークショップで当事者のつもりで考えたあとに実例を出すなら別ですけど。

ツーウェイコミュニケーションであっても情報量は経験談を話す側の方が多いですから、ここは印象に残るくらいの経験をした側の人がどのようなプロセスを選択して実行したのかを伝えることにしましょう。

明らかにされた課題解決のためのプロセスの選択と選ばれたプロセスを聴くことで、それを受け止める側はその話を自分に置き換えて適用できるかどうかを判断するんです。「それ美味しいの」って。そういったことを思案することで、自分の中で事例を汎化するんです。当てはめられて使えるかな、って。

期待した結果が得られたか
選択されたプロセスが提示されることで課題を処理する上での手続きが聞き手側で組み立てることができ、使えそうと思っても期待する成果が得られるかもより関心があります。だって、やっても無駄なら…。

だからどのくらいかけたプロセスに対する成果や効果を知りたいのです。ちゃんと、効果も話しましょう。

経験談を話すがの人は、経験談の中で何が課題で、どのようなプロセスを選択して、期待した結果をえられたか、この骨子を意識して話しましょう。とくにワタシ、ですけど。

聞く側も、もしこうした骨子が抜けていたら振ってみましょう。「何が一番大事な課題だったのですか」「何を意思決定の判断基準としてどんなプロセスで対応したのですか」「その結果はやる前に想定した期待と比べてどうでしたか」と。ちゃんと答えてくれれば何か気づきを得られるハズですよ。