新社会人にあなたならまず何を教えるか? -4- CS: Transfer/Translate/etc..

二つ目のTは伝える力だ。残念ながら、英語でしっくり来るものが無い…

なぜ、しっくりこないかと言うとここでいう伝えるとは、相手を問わないからだ。

もし、相手が計算機ならばプログラムを組んで、あなたの意図通りに動かすことを言う。これに合うのは、どちらかというと意思を「伝達・翻訳」するという意味で Translate がしっくりくる。

しかし、相手が人間の場合は、相手に自分の主張を理解してもらい、納得してもらい、同意してもらい、賛成してもらう事がポイントになる。こうなると本当は Communicate が正しいのだが、そうすると T で始まらない…。いや、それはどうでもいいのだが :p

この能力で大事なのは

1. 相手に伝えたい事は何かをはっきりさせること
2. 相手に応じて伝え方を変えること

の2点だ。

---

判りやすいように計算機のほうから始めよう。

ご存知の通り、計算機は愚直で、単純で、疲れを知らない。正確にいわれたことをやり、いわれていないことはやらない。従って計算機が行うべき作業を緻密に、正確に、指定すれば、その通りに実行してくれる。逆に緻密に、誤って指定すれば、それもその通りに実行する。パフォーマンスがどれぐらい出るのかなども含め、指示次第である。計算機は誤解などしない。計算機に与えた指示が間違っているだけだ。

このような対象である計算機に、計算機が理解できる言語で、何をするべきかを伝えるのがプログラマである。プログラマの仕事は、

1. その計算機が何をするべきなのかを正しく・漏れなく・重複無く(MECE)理解する
2. それを 正しく・漏れなく そして…できれば重複無く 計算機が理解できる言語に翻訳する。

メンテナンスを考えないなら後者の『重複無く』は無視しても良い。しかし、大抵の場合間違いは『重複』の部分に存在し、そのせいで直しても直しても『べつの場所』に『同じ間違い』が残っている、という賽の河原が発生するので、出来る限り重複は無くしたい。

計算機に伝えるための言語は、プログラミング言語でありさえすれば何でも良い。もし Linux のように既にあるプログラムに対する機能追加や修正の場合は、Linux がすでに利用している言語(この場合は C言語とアセンブラだが)を使うことになる。それ以外の選択肢は与えられていないからだ。しかし、新しくプログラムを1から作るのであれば、要件を全て記述でき、必要な性能が出るのであれば本質的にはプログラミング言語は何でも良いのだ。

別の言い方をすれば、優秀なプログラマの要件の1つは多くのプログラミング言語を知っている、という事だ。あえて言うならば、計算機をプログラムするに当たっての最も Primitive な言語である Assembler は理解しておいたほうが良い、と言う程度だろう。


伝える内容は最初のT, Technology で指定された内容になる。

伝えるべき内容が 0 であれば、プログラミング言語をいくら知っていても出力は 0 だ。逆に伝えるべき内容が判っていても、プログラミング言語を知らなければ、やはり出力は 0 になる。

---

理解しにくいのは次の「人間を相手にした場合」だろう。実際私も得意ではないので、なかなか上手に伝えられないのだが…。

「シッタールダ王子は何が偉かったのか？」

という命題がある。シッタールダ王子というのは、ご存知『仏陀』になった人だが、この人は

悟りを開いたのがえらいのではない

えらいのは、

「悟りを開いていない」人に、
「自分は悟りを開いたのだ」と言う事を、
伝える能力があった

と言う点だ。もしかしたら、彼以前にも悟りを開いた人はいたかもしれない。でも、まだ悟っていない人にその事を伝えられないのでは誰も弟子にはならないし、当然他人を悟りに導くことも出来ない。

仏陀の仏陀たる所以は、「悟っていない人に、自分は悟っており、相手を悟らせることが出来る」と説得できたことにあるのだ。


ここでいう「悟る」というのが Technology にあたる。人間を相手に Communication をはかる場合に重要なのは、

技術を理解していない相手に、
自分は技術を理解している事を伝える

事なのだ。

もちろん、世の中には「天才は天才を知る」という言葉があるように、本当に超高度な Technology を厳密に伝え合うためには、相手も自分も同じ Technology をほとんど全て理解し、扱えなくてはいけないだろう。「相手に自分が知っていることを全て伝える」事が常に可能なわけではない。

しかし、思い出して欲しい。我々は「お客様を満足させるために」Communication をはかろうとしているのだ。何もお客様と、ユニゾンをはかろうとか、
「あなたと一つになりたい」
などとエヴァンゲリオンのテーマのようなことがやりたいわけではないのだ。であれば、全てを伝える必要など無いではないか。

人間と言うのは「信じる」という行為を取ってくれる。ある一定以上、相手が正しいことを理解したら、「前提と結論との結びつきがまったく理解できないにもかかわらず」その結論が正しい、としてくれるのだ。

このような場合、大事なのは 1から100まで全てを伝えることではない。乱暴かもしれないが、

• まず、相手に自分がいう事を信じるように仕向けること
• 次に必要最小限の前提と結論を覚えてもらうこと
• 運がよければ、その中のいくつかについては理由も理解してもらうこと

程度を目標にするので構わないのだ。


判ると思うが、「最小限度」というこの条件を満たすためには MECE の考え方は役に立つ。重複があると、情報量としてのエントロピーは増えないのに送受信しなくてはいけないビット数は増えてしまうのだ。人間は「飽きる」し「疲れる」ので、余計な1ビットがあるとそれだけで受信ミスを起こしたり、受信拒否を起こす確率が跳ね上がってしまう。

もう一つ大事なのは、文法上の間違いやあいまいさを排除する事だ。最後まで読めば意味が一意に決定するが、途中では何通りも解釈がありえる、なんてのもダメだ。読むほうにすれば、1つの文章を読んでいるだけで何通り分もの脳みそを使えと言われたことになる。見る見るうちに疲れ果て、読む気を失うのが先か、読み間違えるのが先か…いずれにせよ、あなたの目的は果たせないだろう。

このように、ちゃんと受信してもらえるようにすること、Transfer が人間の場合重要なキーポイントになる。

---

このように、相手によって、何をどのように伝えるべきなのかは変わる。

これは「伝える」事そのものが目的なのではなく、

お客様に満足いただくために
情報を伝えている

からだ。

お客様に満足いただくために、計算機に正しく動いて欲しいから、正確に、厳密に、漏れなく、重複無く、計算機にやるべきことを伝えなくてはいけない。
お客様に満足いただくために、お客様が理解しなくてはいけないことを、お客様が受け付けてくれる形で伝えなくてはいけない(あるいは、お客様以外の人であっても同じだが)。


私の場合、多くの新人は理系の学部を出ている。そのためか「日本語の文章が不自由」な人が多い。この blog にも誤字脱字、文法の間違いは多いが、この何万倍も酷い間違いをして、なおかつどこが間違っているのか判らない、と言う人が多くやってくる。

この場合、Technology は問題ない。また、計算機への Translate も問題ない。しかし、人間への Transfer に問題があるわけだ。

可哀想だが、やることは一つ。作文の特訓である。
だいたい2年ぐらいかけると、誰でもわかりやすい文章を書けるようになる。そして、そうなると、その新人の評価はぐっと高まる。

T x T

の左の T は最初から高い数値だったのに、右の T の値が低かったため、計算結果が小さな値になっていたのに過ぎないからだ。ちゃんと他の人に伝える能力がつけば、評価は高くなって当然である。



新人の間はこれでほとんど問題は無い。しかしたまに、転職組などで問題が出るケースがある。それが第3番目の項目、F がきちんと出来ていない場合だ。新人の場合は仕事の範囲が狭いため、Focus がぶれることは無い。しかし、転職組の場合はもう少し幅広いレンジを相手にすることが求められる。すると Focus の問題が発生するのだ。従って、新人の段階から Focus についても説明することにしている。ただし、彼らがそれについて実感するのは3年目以降になるだろうが…

というわけで、次回は Focus について説明しよう…。