■プロダクトと会社の健康余命を削りまくるエンジニア

カタログめくって(Webページググりまくって)、良さげな(業務経歴書にかけそうな)新しいサービスなりプロダクトなりを見つけたら、鼻を膨らませて得意げにメンバーに報告し、ポチる(リポジトリに組み込む)エンジニアを……、

カタログショッピング・エンジニア

と、名付けたよ。

経営者は「最新の情報に敏感」「技術に詳しい」とか評価するようだけど、カタログひっくり返しては「あれはいい」「この新製品はすごい！」「これ最高！」って喋りまくる人間が、どれほど軽薄で浅はかかわからんのだろうか？

わからんのだろうな。

ミーハーに「AI最高！ これでお金集めてガッポガッポ！！」みたいな経営者じゃ。

ADRと称して導入企業名と諸元の比較ばかりして、一番デカくて高価なのが正義、くらいしか語れないのを、エンジニアと？ w

それはただの消費者だ。

って言うと、「お前が新しいサービスについていけてないだけじゃねーのか」って陰口を叩かれるんだが、新サービスのチェックした上で、煽り文句を真に受けて「一秒でも早く使ってみたい」という、単細胞的な反応をしないだけだ。

そのサービスがどういう設計で作られているか。

出自はどこか？

そういう設計だとしたら、どういう性能特性を持つか。

等々、広告記事以外の情報を集めて検討し、「今目の前にあるプロダクトに使えるか？」考えた上で、余計で巨大なフジツボをくっつけるだけなら触る価値もない、と判断しとるだけだ。

いくつもプロダクト名を列記したくてうずうずするが、どう考えても業務妨害になるから、できない。

そもそも、待ち望んでいたサービスやプロダクトなら、.netFrameworkもLambdaもEMR(Spark)も使えるようになったらすぐに採用するように説得してきたし、新サービスのSnowflakeをぜひ使いたいというのを、処理の特性と、プロダクトの設計等々を理由に止めてAthenaを採用して、1リクエストあたりリアルタイム処理は1、2秒レスポンスタイプが伸びたが、事前準備可能なリクエスト、再度リクエストであれば即時レスポンス、その処理部分にかかる利用料金を1/100にした。

それがそのプロダクトで必要とされていた仕組みだったから。

エンジニアって本来そういうもんだ。

そのプロダクトにとって適材適所に設計する。

具体的に時間を測ったわけではないが、準備設計に4割は割く。

利用プロダクトの選定は、普段から情報収集しているから、ほとんどかからん。

初回リリースには、肌感覚だがそこら辺の現場の1.2倍くらいの実時間がかかる。

けど、人月では8〜9割くらいで済んでいる。

準備設計時には、エンジニアの頭数はいらないから。

で、初回リリース後、追加開発が重なれば重なるほど、そこら辺の開発の2割引くらいの人時間金で済むし、安定度も高い。

それができる仕組みを、初回リリース時にほぼ揃え切ってしまうから。

そう言う準備設計こそ、プロダクトと会社の健康余命を伸ばす秘訣だ。

何かあるたびに、何か症状が出るたびに、対症療法では、人間にしろプロダクトにしろ、健康で長生きはできないよ。

Permalink |記事への反応(0) | 20:53

ツイートシェア