新しい言語を学べ

著者: バークハート・ハフネーゲル

アーキテクトとして成功するためには、あなたの母国語を話せない人々にもあなたのことを理解してもらえるようでなければなりません。いや、エスペラントを勉強しろと言っているわけではありませんし、ましてクリンゴン語を学べなどとは言いませんが、少なくともビジネス語とテスト語の基本は知らなければなりません。そして、プログラマ語を流ちょうに話せないなら、まず最優先でこの言葉を覚える必要があります。

こういった他の言語を学ぶ意味が理解できないということでしたら、次のようなシナリオを考えてみてください。ビジネスサイドの人々が既存のシステムに変更を加えたいと思い、そのことについて議論するために、アーキテクトとプログラマーを呼んで会議を開いたとします。残念ながら、技術チームにビジネス語をしゃべれるメンバーはおらず、ビジネスサイドにもプログラマ一語を話す人はいません。会議は、次のような感じになるでしょう。

ビジネスパーソンが、既存のプロダクトに対する比較的単純な拡張の必要性について1分間説明し、さらに、営業チームがこの変更を加えることによってマーケットシェアもマインドシェアも大きく伸ばせることを説明します。
ビジネスパーソンがまだ話している間に、アーキテクトはオカルトっぽい記号をノートに描き始め、彼らに特有の奇妙な多音節言語でプログラマーの1人とひそひそ話を始めます。
ビジネスパーソンは話を終え、アーキテクトによろしくという顔をします。
アーキテクトは、ひそひそ話が終わってからホワイトボードにつかつかと歩み寄り、複雑なダイアグラムをいくつか描き始めます。それは既存システムの様子を複数の形式で表現したもののようです。アーキテクトの口は、複雑な専門用語を使って、既存のシステムを大きく変更しなければ、求められた拡張を加えるのは難しい、なぜなら……ということを説明しています。ただシステムを変更するだけではなく、システム全体を最初から設計し直し、書き直さなければならないかもしれないとも言っているようです。
ビジネスピープルたちは、ダイアグラムのことがほとんどわからず、説明はさらによくわかりませんが、明らかに不機嫌な様子で、こんな単純なことのために、そんなに大きな変更が必要だとは信じられない様子です。アーキテクトが本気でそんなことを言っているのか、システム変更を避けるためにもっともらしいことを言っているのか、ビジネスピープルたちは疑い始めます。
一方、アーキテクトとプログラマーは、「マイナー」な変更によってシステムのコア機能に大きな変更を加えなければならなくなるということが、なぜビジネスピープルにはわからないのか、まったく理解できないという顔をしています。

問題は明らかでしょう。どちらのグループも、相手グループがどのように考え、彼らが使っている言葉がどんな意味なのかがわからないでいます。これでは、誤解と不信を招くでしょう。人は自分と大きく異なる人たちよりも似ている人たちといっしょにいた方が心地ょいということは、ごく基本的な心理学の原則です。

もし、アーキテクトがビジネスピープルにも理解できる用語でシステムの問題を説明することができ、プログラマーにも理解できる用語でビジネス問題を説明することができれば、先ほどのシナリオがどのように変わっていたかを想像してみましょう。驚いたり不信を感じたりするのではなく、合意、承認という結果が得られていたはずです。

複数の言語を学べばすべての問題が解消できると言うつもりはありませんが、問題の原因となる誤解や不信を防ぐためには役に立つでしょう。

なるほどと思う読者には、是非成功を収めていただきたいと思っています。同じとをクリンゴン語で言いましょう。カプラ！