エンジニアは、非エンジニアに理解させる努力が不足しているのではないか?

医者とエンジニアとの根本的な違い

医者は、強者側の立場であることが多く、
エンジニアは、弱者側の立場であることが多いということ。

で、弱者側は、強者に対して要求することはかなり難しいということ。

エンジニアは、この点を理解すべきなんじゃないかなと個人的に思うわけです。

世の中、強者が態度を自ら改めるということはめったにないんだから。


「負債」は「資産」です。ご注意を / 医者に風邪引いてるんですって言うな 〜 非エンジニアに知ってほしいこと、エンジニアに知ってほしいこと | F's Garage@fshin2000

今回の場合のエンジニアはこうだと思う。
エンジニア = ソフトウェアエンジニア

技術的負債について

会計上、資産計上するものなのか?負債計上するものなのか?という論理は、負債というイメージを捉えるのには良い概念だと思う。

技術的負債は、多くの場合、エンジニアの場合は、自身の将来の仕事を増やす可能性があるという意味で、負債であることは確実だと思う。

ただ、経営(会社)的にみて、それが収益に代わるのなら、技術的負債が資産計上すべき性質のものになりうる。


でも、資産計上されるものであっても、エンジニアが苦労するという構図には変わりがあまりない。

だって、エンジニアは、無駄だと思う努力をしなくないんだから。お金を産むから無駄でないというのは、エンジニア的発想でなくて、経営者的発想。


参考:「技術的負債」とは何か。原典とその対応策を探る - Publickey

非プログラマに「コード」の説明は難しい

医者が患者に求めているのは、実質何なのか?ということと同じではと思う。

コードの説明を求めてるとしても、実質はコードの説明でなくて、別のものを求めているのではないか?ということ。

安心感という信頼だったり、誠実に説明しようとする態度だったり、そうではないか?と思う。


開発者を医者だと思って付き合おう!?

たぶん、無理な話だと思う。それは冒頭に書いた通り。

逆に、エンジニアのほうがすこし譲歩してあげるというのは、場合によってはありかな?と思うんですね。

風邪みたいなんですというと

その判断をするのは医者ですというのは大人げなくて

「風邪みたいな症状」が出てるんですという意味に捉える努力をすべきなんじゃないかな?と思う。

あと、医者だって、病名を診断するのが仕事でなくて、病気らしきものを治すのが仕事なわけだから。

たとえば、うつ病らしき症状でも、診断名がはっきりしない状態でも、治療をするわけだから。


リファクタリングの意義について

余談ながら、会計上の資産増加につながらないソースコードの改善作業を「リファクタリング」と言う。そう言われるとエンジニア側もムカつくだろうけど、サラリーマンは実は時給換算で契約してますってのと同じく、経営上の扱いとしては仕方ないことだと思うので注意な。(エンジニアの理想が、会社法上の企業のルールに即していれば、みんな苦労しないのです。だから経営者のビジョンと支えるビジネスモデルで解決する必要がある。)
「負債」は「資産」です。ご注意を / 医者に風邪引いてるんですって言うな 〜 非エンジニアに知ってほしいこと、エンジニアに知ってほしいこと | F's Garage@fshin2000

「リファクタリング」なんてエキサイティングな事が書いてあるんだ!
「レガシーコード改善ガイド」お前は俺の気持ちが分かる神か…!?
「パターン指向リファクタリング入門」銀の弾丸かよ・・・orz
で、月曜日会社に行きました。チームが苦しめられ続けてる山盛りスパゲティがあります。
PLやGLにリファクタリングを提案しました。
その結果…
当然却下ですわ。
意識が高くなりすぎて辛い

エンジニアの人は、リファクタリングを周りに説得?するときは注意が必要だと思う。

個人的には、細かい話よりも、致命的な欠陥を作らない努力のほうが、お互い幸せになれると思う。スパゲティープログラム的で、悲惨でも・・・。

悲惨の中には、救いようもない悲惨があるということなんですな。スパゲティープログラムなんて、まだ、おいしいほうだよという世界。


下っ端のエンジニアには、十分なモニタと十分な性能のマシンを与えよ。

実際に、そんなの必要か?という場面もあるかもしれないが、非エンジニアの人は覚えておくとよいと個人的には思う。

別に仕事の成果が劇的に上がらなくても、エンジニアとして優遇されているとか、大事にされているという意識が、仕事をはかどらせるかもしれないということ。

実際、マシンパワーがあまり必要なさそうでな場合でも、なぜかマシンパワーがあると作業がはかどるエンジニアが多い。

まあ、それは、軽自動車で高速道路を走るよりも、普通車で走るほうが快適だというのと似てるかもしれない。

快適なほうが、ストレスがかかりにくくて、結果として成果を出しやすい環境にあるということかも。

これ、エンジニア間でもいえるんだけど、
実作業をする下っ端?のエンジニアとそれを管理する?エンジニア※1とでは、どちらに良いマシンを割り当てるべきか?なんだけど、これは、実作業をするほうだと思う。

でも、実際はそうしない傾向にあるみたいだし、また、同じエンジニアなのに、立場が上だと、自身のマシンのほうを理由をつけて良いものにしようとするけいこうにあると思う。

※1 EXCELで仕様書書くだけなのに、その良いマシンは必要なの?って話。

会話が通じてなさそう

相手の立場にたって考えるのは、エンジニアも同じだということ。
あと、強者と弱者との関係においては、弱者側が相手の立場に立たざるをえないということ。

それは、エンジニア間で考えても、よくわかるかと思う。

まあ、強者のエンジニアは、周りに要求して、それが我儘でも、多く場合は許容されます。
でも、そんなエンジニアは邪魔だと思うので、排除して、弱者のエンジニアでなんとかならないか?と考えるのではないか?と思う。

強者のエンジニアの主張は、エンジニア全体の体質改善には役になっていないのかもしれない。

エンジニアはこうあるべきだから、こうあるのだから、周りはこういう対応を取りなさいって論調だと・・・。

無理解というのは、エンジニアというのがどういうものかを理解されていないからと言う部分以外にも多分にあるということ

日本だけじゃないと思うよ

この点について、RelateIQのFounder & CTOのAdam EvansがTech Crunchに寄稿したエッセーが秀逸(私がこのブログを書いている時点では日本語版には掲載されてませんが、そうなると期待しています。)で、相互理解について示唆に富んでいます。



プログラミングの対象がマシンか人かの違いだけなので(もちろんそれだけではないですが、まあたとえ話なので。。)、相手がうまく動いてくれるよう、コードを書いてるのと同じように楽しんで頑張ってみようじゃないかという呼びかけです。
エンジニアと非エンジニアの境界 - ワザノバ | wazanova




スポンサーリンク

コメントを残す

メールアドレスは公開されません。
また、コメント欄には、必ず日本語を含めてください(スパム対策)。