例により当たり前のようなことを偉そうに書く記事
toエンジニア向け
■「負債」は「資産」です。ご注意を。
ソフトウエアエンジニアの人たちは「技術的負債」という言葉を使うが、会計に慣れてないと、ものすごーーくネガティブなニュアンスを含んでいるような気がしてしまうが、会計上の「負債」というのは「資産」に分類されることも忘れずに。
負債は利息を払ってるから早く返そうぜ、という文脈もあるだろうが、同時に「負債もお金を稼ぐ功労者なのだから、そこはリスペクトして、うまくやろうね」という視点もあるってしかるべき。これはうまく両立されるべきで、その気持ちがうまく同期できてないとエンジニアの側が辛くなるんじゃないかな。
特に経営者で苦労された方であれば、そんなことに動じたりはしない。腹くくってリアルな借金を負ってるような人に、そういう理由で「脅す」のは通用しない。メタファ、概念としてはすごくわかりやすいが、会社への脅しの武器には使わないようにしましょう。淡々とどう返していくか！？を計画し、実行していく。ただそれのみ。
■非プログラマに「コード」の説明は難しい。
いわゆるソースコードというメンタルモデル（イメージ、具体的な問題）を抱けない人に、ソースコードの比喩やお悩み問題を伝えても理解されない。
医者が臓器や血管について、専門用語レベルでしゃべっても患者さんは理解できないし、イメージができない。
to非エンジニア向け
■開発者を医者だと思って付き合おう。医者に風邪を引いてるんですと言ってはいけない。
何の比喩かというと、カジュアルに「こんなの簡単にできるよね」「バグが出ました！」という言い回しはやめよう、ということ。
体調が悪くて医者に見てもらう時に、それが風邪であるかを診断するのは医者の仕事だ。
それと同じく「本当に簡単にできるのか」「それが本当にバグであるのか」を適切に診断するのはエンジニアの仕事。
エンジニア出身の人じゃないと、この言い回しを正当化するのは、なかなか難しい。
そこらへんは彼ら自身のプライドと評価に当たる部分であり、エンジニアにカジュアルに言うのはすごくセンシティブな部分なので気をつけるように。こりゃ風邪だと明らかに判断できる時には「いやー、風邪っっぽいんですけど、どうですかねぇ！？」と表現に気を使ってあげよう。日常の会話で、これは誤診ですか！？と素で迫るような発言は間違ってもしませんように。
■プログラムは劣化するという考え方。
ソフトウエアエンジニアの人が、いつも気にしているポイントだ。これの説明をしよう。
例えば、同じことを伝える文章でも、回りくどくて難しい文章と、エレガントで簡潔な文章のどちらがわかりやすいかというと、エレガントで簡潔な文章の方に決まっている。
（なお、この文章に対し、回りくどくて難しい文章というツッコミは不要w）
プログラマの人が恐怖に思っているのは、仕様がややこしかったり、納期が短かったり、作った人のスキルが低かったりという理由で、プログラムが整理されておらず、ややこしくて難解な状態のままリリースしなきゃいけない事態に陥ることだ。そういうプログラムのことを「汚いコード」と呼ぶ。
ソースコードは道路工事と同じで、定期的にメンテナンスをしたりする。そこでソースコードがややこしいことは、後の「作業時間」や「間違えやすさ」に繋がる。
つまり「動いてるけど、修正時のミスを誘発するプログラム」ということだ。しかも書いた直後なら、まだソースコードの問題点などは覚えているが、「３ヶ月後の自分は他人」なので、埋めた地雷を自分で踏んでしまうことも少なくない。一回くらいならともかく、そういうことを何度も繰り返していくと、もつれた糸がどんどん複雑化していく。「あーもう、書きなおしたほうが早い！」と思わせながら仕事をさせていくのは、まぁ仕事なんで仕方ないだろと思う部分も90%ぐらいありつつも、離職率高い業界だと思う部分も含めて、できれば避けてあげたい。
そこはエンジニアに修正する十分な時間と機会を与えることで、整理可能だと思うので、メンテナンスするつもりがあるなら、お早めに相談しよう。
余談ながら、会計上の資産増加につながらないソースコードの改善作業を「リファクタリング」と言う。そう言われるとエンジニア側もムカつくだろうけど、サラリーマンは実は時給換算で契約してますってのと同じく、経営上の扱いとしては仕方ないことだと思うので注意な。（エンジニアの理想が、会社法上の企業のルールに即していれば、みんな苦労しないのです。だから経営者のビジョンと支えるビジネスモデルで解決する必要がある。）
■エンジニアには、十分なモニタと十分な性能のマシンを与えよ。
スマートフォンのアプリにせよ、Webにせよ「画面」を開発するんだから、プログラム表示領域とプレビュー画面は分かれているべきだ。
狭い画面での作業というのは、作業者に無駄な負担を与えているので、時間の無駄。つまり給料を浪費している。
またメモリが足りなくてコンパイルが遅いマシンなどは、エンジニアの集中力を切らせてしまい、遊ばせるだけなので気をつけよう。iPhoneアプリのビルド中に、ついFacebook見てしまうのは避けなくてはw
パソコンやモニタは十分安いので、それぐらいの投資で生産性が改善できるなら、モノで解決しよう。
ただ、たまに目線移動することなく、同じ画面でやりたいという人もいるので、そこは相談の上。
会話が通じてなさそうな何かを解決しよう
ネタ元はとある人のブログ記事を参考にさせていただいた。こちらがそれに対して少し否定的なアプローチで、晒しみたいになるのが嫌なので、恐縮ながら引用するのは避けた。
そもそもネットに書いたからと言っても、ネットでは同じ興味を持つ、同一属性の人しか見ないというケースがほとんどなので、現場でどれだけコミュニケーションできるか！？が全てなのだが、それにしてもお互いの見ている視界の範囲、持っている情報、経験の差があって会話が通じないという問題をどう乗り越えるかだ。
開発者の側は、「情報を持っている側」なので、伝える変数がいろいろありすぎて、理解させるのに骨が折れるし、「持っていない側」は持ってない情報を頼りに意図を伝え無くてはならない、この両者の意識の差が、感情的な行き違いを生んでいることが見えるのが、この手の話の特徴。しかも、SIerだろうがスタートアップだろうが、何十年もみんな同じことを言ってると思う。
ただソフトウエアのエンジニアの人に知っておいて欲しいのは、ソフトウエアはすごくわかりにくい。
元々、製造業で機械を作っていたから、ついそこと比較してしまうのだけど、障害が起きたとする。例えば作業者が機械に挟まれてしまったとしたら、その状況はすぐに周りから見えるので助けることができる。しかし、Webサービスで障害が起きたとしても、職場で「アンドン」のような可視化する装置でも作ってない限り、サーバ管理者のオーラでしか伝わってこない。
そんなオーラが見えるかどうかなんてのはわからない話で、担当者本人はめっちゃテンパってるのに、周りは普通に仕事しているというケースもよくある。
つまり、コンピュータの中で仕事をしている限り、あなたがどう思っていて、画面の中、LANの向こうでは何が起きているのか！？というのは極めて見えにくい仕事だという前提で、人とコミュニケーションしていくべきだろう。
そこで、うまく伝えられてないことを棚に上げて「僕の言ってることが周りに理解されない！」と思ってしまうとしたら、それは単純に損だと思う。
——————
追記
すべては楽しく仕事をするために！
——————-
変更履歴：はてブコメやtwitter等での感想を見て、少し追記変更しています。
