Murga

個人的に言いたいコト・主張・気持ち。

発信者がコストを払っていない会話は総コストがかさむ

チーム開発、ひいてはビジネスにおいて、口頭伝達や電話連絡のような、話したい側が話したいように話せる仕組みばかりを多用して情報発信してしまうと、全体的なコミュニケーションコストがかさむと思う。

聞き手は、話し手の時系列を想像し、話し手が前提としていることを推測しながら聞くことになる。「想像」や「推測」の余地が出てきた時点で、情報は聞き手の解釈で捻じ曲げられてしまい、勘違い、伝達ミスが生まれる。

「その機能は顧客要件として顧客と合意した機能なのか?それとも話し手である PM の個人的な希望でしかないのか?」

多分、顧客要件なのだろう」

このような推測が、後になって無駄足を踏むことになったり、全く違うモノを作り上げてしまったりする末路は容易に想像が付くだろう。


それでも、話し手も楽をしたいから、言いっぱなしで終われる「自分が楽な手段」を選びがちである。そのツケを払うのは聞き手だが、往々にして、このような場合は一人の話し手に対して複数の聞き手が存在する。そうすると、複数の聞き手が推測したり、「それはどういうことですか?」と質問したりする必要が出てきて、全体的にかかるコストがかさんでしまう。

もし話し手が事前に伝える内容をまとめていて、「コレはいついつまでにリリースすることが Must な顧客要件、誰々が担当してくれ」「コレは余裕があれば実現したい個人的な希望で、実現できるとこんな効果が見込める。顧客要件の実装が終わり次第、誰々が担当してくれると助かる」のように伝えられたらどうか。5W1H を満たしていれば、聞き手が推測する余地はなく、認識齟齬はより起こりにくくなるだろう。

そしてこのような情報を、文字に起こして伝えられるとなお良い。口頭伝達のような揮発性の伝達手段では、読み手が再確認しづらいために勘違いが起こりやすいし、「言った・言わない」の水掛け論を防げる。


「口頭の会話を減らそう」「とにかく書こう」という話はこれまでも何回か書いてきたが、コレが出来ない人は本当に何歳になっても出来ないようだ。「他人が読めるように書く」のはそれなりにスキルが必要なことだが、「それが上手く出来ない人は、口頭で話せば何とかなるだろう」と思い込んでいるようだ。ハッキリ言うが、書けない人は話せていない。書ける人だけが話せているし、口頭伝達で何とかなった気でいるのは、聞き手にコストを払わせているからだ。聞き手は「コイツ何言ってんだかちっとも分かんねえよ」と思いながら推測して理解してあげようとしており、それによってミスを誘発するリスクを増やしているのだ。

自分が口頭伝達に頼っている本人なら、自分でも何とかしようとしてもらうのは勿論だが、そうでなければ、自分が話したことを誰かに文書化してもらうようにした方が良いだろう。前提知識をあまり持たない後輩や新人に議事録を書いてもらうと、「自分が話したことがどのように解釈されているか」をより明らかに出来るだろう。書いてもらった議事録を読んで、足りないことや誤りは追記してもらわないといけないし、以後そのような不足事項を漏らさず伝える練習をしないといけない。

自分の周りに「曖昧な口伝えばっかりしてくるやりづらい人」がいて、その状況を何とかしたいと思っている人は、議事録を書いてあげよう。「今口頭で話したことって、こういう要旨ですよね?」「さっきの話の決定事項はコレで良いですね?」面倒でも全てコチラで書いてあげよう。その際、書き手となる自分の推測をあえて混ぜず、「あなたの発言はこうでした」「それらの話を、何のバイアスもかけずに総合するとこういうことですよね」と伝えるのだ。そうすれば、聞き手に伝えそびれていた前提条件や制約事項、曖昧な話し方だったために勘違いさせていた部分が浮き彫りになる。自分の推測も併記したければ、「自分の推測では○○と解釈しましたが、前提知識となる◇◇のことを知らない人は、××のように解釈する人もいるかもしれません」のように、「どう勘違いされそうか」も書いてみると良いだろう。


チーム開発で PM や TL が「書く」ことを怠ると、要件定義書がなく、トレーサビリティマトリクスがなく、仕様書も設計書もない状態になる。タスクが明確にならず、誰が何をやるべきなのか、そのタスクが何に繋がっているのか、誰も分からない状態になる。いや、正確にいうと、誰もが自分の推測で分かったつもりになっていて、実のところお互いが全然違う認識を持っている状態になる。

「コレって○○でしたっけ?」「いや、××だったと思うよ」「そうでしたっけ?じゃあこっちの実装も××に直しておきます」

そして後日、顧客レビューで「コレは△△にしないといけないって伝えたはずじゃないか!」などと怒られる。

それくらい書くのは当たり前だろう、何事も書いていけば逆に機械的にすら処理できるようになるのに…と僕は思うが、「書く」ことに抵抗がないというのは、凡人にはいつまでも身につけられない高等スキルのようだ。

どんな形式であれ、まずは「書く」こと、書いたものを共有することが大事だ。書いてくれない人がいるなら、書いてあげよう。そして多分、書くつもりがない人は一生書かない。そういう人がいる現場からは逃げよう。

なぜ、システム開発は必ずモメるのか?

なぜ、システム開発は必ずモメるのか?