顧客とエンジニアの未熟なコミュニケーションでは忖度してはいけない
なんというか、いくら歳を取っても知らない言葉が次から次と出てくるというか、一部の方はよくご存知ですよね。一部の方だけしか知らないからメディアは物珍しくて取り上げているのでしょうけれど。
ええ、忖度の話です。辞書を引いてみると忖も度もどちらもはかる意味だとあるので重言のような感じもしなくはないのですけれど、強調したくなるくらい「察しろ」ってことでしょうか。
とても日本的なハイコンテキストなコミュニケーションだなぁ。
そん たく ［1］ ［0］ 【忖▼度】
（ 名 ） スル
〔「忖」も「度」もはかる意〕
他人の気持ちをおしはかること。推察。 「相手の心中を－する」
局面分割は伝言ゲーム
ウォーターフォール型のシステム開発が典型ですが、局面分割や繰り返し型のシステム開発は先行する局面やn-1の開発時のリポジトリがあり（あるはず）、それをインプットに次工程や次開発をする前提としてます。
1回きりの作業ではないので前工程の活動の結果としてのアウトプットの意味合いは、次工程にとっては全然違うものです。どんな出来合いであろうが、前工程のアウトプットはある意味神様みたいなものです。そこにそう書いてあるから、という指示が出てくるくらいな絶対的な御神体にダメプロジェクトでは進化する場合もあります。
ダメプロジェクトではなくても基本構造的に作業をつなぎ合わせる形態を取るので伝言ゲームをしているわけです。
まあ、昨日の自分が言っていることなんて、他人が言っていることとそれほど差はありませんから、システム開発だって同じようなものです。ええ。
伝えられないこと、聞き取れないこと
システム開発で要件を提示するのは顧客です。その顧客は解決したい業務課題を要件として持っています。その要件はシステム化の要件定義局面で何をしたいかを伝えたいと考えています。
- 本来実現したいことに対する思い
- 事実として伝えられること
エンジニアとシステム化要件定義の中で何が起きるかといえば、
- 本来実現したいことに対する思い
- 事実として伝えられること
- 思いを言語化する際に表現できなかったこと
- 伝えられない事実
と思考から言語化する際に語り部としての顧客とインタビューする聞き手としてのエンジニアの双方の未熟なコミュニケーションから、伝えれない、聞き取れないという二重の不幸が関係してグレーゾーンが生じます。
同じように事実として存在するけれど存在していることを忘却したり、テーブルに上がらないことでうやむやになってしまったりするケースもあります。
これらが上流工程も最上位の工程で起きると何が起きるか。わかりますよね。
伝えたつもりと独自解釈による補完
顧客はグレーゾーンな領域でコミュニケーションをしているので話したつもりになるんですね。
人の基本的な行動として不都合な事実は視界から外れるのであれはそういう意味だとか、それも含んでいる、とか言い始めるわけです。
一方、エンジニアは過去の事案で慣らされているので行間を過去のパターンから埋めようとする行動を始めるわけです。エンジニア独自のエンジニアに都合が良いような解釈をして。これも、人の基本的な行動としての都合の良い情報だけを集めて回るという行動に起因するのですが。
やっぱり、この2つも行く末は遠くない将来に綻ぶんですよ。だから、システム開発においては忖度してはいけないんです。あ、ほら、昨日のアレ、ちゃんと顧客に確認したほうがいいですよ。
