エンジニアなら絶対身につけたい！ファシリテーション力のポイント
プロジェクトをやっていると、働いている時間の80%はコミュニケーションに使っていませんか。え？「1日中パソコンに向かっているから10%もないよ。」だって？それほんとですか。目を瞑って昨日の行動を思い出してみましょう。
出社する、パソコンの電源入れる、メールを読む、朝会に出る、昨日のバグの仕様の摺合せをする、仕様を見直す、レビューをする…（ry
コミュニケーションって、対面だけじゃないですよ。メールだってそうだし、勿論、対面のミーティングだってそう。膝を詰めた摺合せだって、レビューだってそう。もう、仕様書書きやコード書きでオフィスツールに向かっているとき以外は全部コミュニケーションが絡むんですね。メールでさえメーラを介して送信相手と意思疎通するためにするんですから。
で、良くメールでちょっとしたお互いの理解のズレでバトルを始めたり、仕様の実装でアイデアがかみ合わなかったりしてヒートアップしたりする光景って意外とみられるじゃないですか。で、メールなんて直接対面で話すとなんであんなにバトルモードにスイッチが入ったのか不思議なくらいにこやかに会話して合意できたり。面白いですよね、どちらもおんなじコミュニケーションなのにね。
そうした場でファシリテーション力が思うように使えれば、こうしたコミュニケーションの行き違いは回避できるんじゃないかって思うんです。だって、バトっている時間は“なにも生産しない”し“誰もうれしくない”ですもんねぇ。ぱっぱと確認したり決めたりして今日の仕事が終わったら帰って艦これしたいじゃないですか。スクフェスでもいいですがワタシはスクフェスやってないし。
でね、思ったわけです。エンジニアでどれだけファシリテーション力を意識して使っているだろう、って。何を意識したらファシリテーション力を身につけられるんだろうって。
“ファシリテーション力とは、目的に進行するスキルである”
そう、ミーティングでもどんなシチュエーションでも人を集めて得たいものを得るためにミーティングするわけで、得たいものが目的なんですね。で、その目的を思うように場を進行する力こそ、ファシリテーション力だと思うのです。
逆に言えば、目的をハッキリして場を設けない、曖昧に始める、参加者に意識させない、場の目的を伝えてから始めない、のであれば、そのコミュニケーションの場で開催した本人が得たい“目的”のものが参加者の合意形成を持って得られるとは思えません。
なら、目的を意識さえすれば、目的を出席者に伝えされすればファシリテーション力を持っていると言って良いのでしょうか。残念ながら、それは違うとしか言えないです。それはファシリテーション力とは違う。
場に参加してもらう人の人選、場に出席する人への動機づけ、場の運営、場の雰囲気づくり、場の着地点。どれも目的を伝え、出席者に意識させればそこまで出席者が察して協力してくれるわけではないのです。そうした不確定要素を抱えたまま目的を得るたえに行動したとしても不確定要素がある限り期待するより得られる結果が少ないことは容易に察することができるんですから、そうした不確定要素は少なければ少ない方が良いに決まっています。
ならどうするか。
“ファシリテーションの方法論を取り入れ何度も使う”
目的を得るための勝利の方程式は世の中の先人が書籍にまとめてくれているのですから使わない手はないのです。それはチートであって、王道でもあるんです。なら、それを使って見るべきです。と言うか使わないなんてもったいない。
それがMECEだったり、SWOTだったり、QC七つ道具だったり、交渉力だったりゲーム理論だったり。
難しいシチュエーションでこそ、方法論が役に立つのです。それを知って交渉の場に臨み相手から何かを引き出すか、知らずに相手のペースに載って期待する結果の微塵も得られないかを選ぶのはあなた自身です。
