おもに Groovy やアジャイル開発について勉強していることを書き散らしてます。
わたしのひとりごとが、だれかのお役に立てればと…

言葉の意味を共有する

かっこいい言葉かもしれないけれど

組織の方針や理念に聞こえのいい言葉、ブームな言葉(バズワードも)が使われることがよくあります。私もよく使っています。「アジャイル開発やってみたい」とか…

でも実は、そういう言葉のほとんどがきちんと共有されていないです。

「クラウド戦略」とかって、曖昧極まりないですよね。
今や「クラウド、クラウド」ってIT現場でなくともよく聞くようになりましたが、実際に各人が捉えている「クラウド」は千差万別です。
それってどういう戦略なんでしょうか?対内的/対外的に伝えることができているんでしょうか?

伝わらない言葉の意味

たとえば「これからはキンタロー。だ」と声高々に叫んだとしても、
おそらくきちんと伝わっていないと思います。

まず、キンタロー。を知らない人がいます。
間違って、まさかり担いだ金太郎だと受け取る人がいます。

知っていたとしても、自分のコンテキストに合わせて把握しています。
また、そのメッセージの意図を自分なりに理解します。「AKB関連だから」「かわいいから(!?)」

同じ組織、同じチームの中であっても、それが少人数であっても、言葉の捉え方は各人でほぼ間違いなく違います。
資料にまとめて配布しただけだとしたら、思ったとおりに理解される確率なんてひどいでしょうね。

自分の知らない言葉を見聞きしたとき、見なかったことや聞かなかったことにするかもしれません。
それが、もし大切な方針や理念だとしたら…組織崩壊せざるを得ないですよね。

言葉を掲げるなら

その言葉の意味や定義をきちんと整理して、伝えるべきです。
もし自分のコンテキストで、本来の意味(一般的な意味、辞書的な意味)とは異なる、カスタマイズしたような使い方をするのであれば、その本来の意味との差異を示すべきです。
また、広義/狭義で意味合いが変わってきたりするので、どこまでの範囲で捉えているのかを示すことも大切です。

たとえば TDD を例にあげると、広義な意味(開発プロセスとしてテストを先につくる=テストファースト)と狭義な意味(プログラミングの方法としてRed/Green/Refactorのサイクルをまわす)が混在したなかで議論してしまい、意見の食い違いを解消できず時間を浪費したことが過去ありました。

さらに、その言葉を使用する意図や背景を伝えることも欠かせないですね。

言葉を理解するために

言葉を受け取る側にも努力が必要です。
勉強してほしいと思うのです。

せめて「自分が理解していることと違うか、同じか」が感じ取れるくらいまでは。

「いや、全く知らないです」って言われると議論ができないです。
「質問ある?」で反応ができるのはその最低限の理解レベルを超えているから。

議論に必要なことなので我慢して教えたとしても、その場で十分に理解できる可能性は低いです。
納得して自分の中で整理した上で、議論に望まないと議論にならないです。
本来の議論に入るまでに時間がかかるので、認識の食い違いで戻りが発生するので、コストの非常なムダでもあります。

そうやって初めて…

言葉の意味を共有できる場が作れます。共有するための一歩を踏み出せるのです。
みんなで共有する、議論する場を設けて、すりあわせです。

共有できた上で、プロジェクトの舵取りをする。意思決定をする。議論する。
時間やコストがかかるかもしれませんが、それってとてもとても重要なことじゃないでしょうか。


新年度のスタートという時節柄…
あいまいな言葉が掲げられることが多く、そんなことを考えていました。