コスト意識を大事にして、コードを書くということ

・業務を意識して、コードを書くということ
・インフラを意識して、コードを書くということ

個人レベルや趣味では考えなくてよかった多くのことを考慮する必要がでてきます。
非エンジニアと話すときに「全く話が通じない」ということはできるだけないようにする必要があります。

作ったら終わりではなく、ビジネスとして収益をあげ、かつ保守していかなければいけません。また、仕事として成立するためには利益も確保しなければなりません。

多くの会社は、100人いたら、本当にできるエンジニアというのは20人程度です。

インフラを意識してコードを書くということ - Hatena Developer Blog

上記の文脈と言葉を少し置き換えて、似たようなロジックで、
エンジニア受けしにくい話にも書き換えることができるかなぁとは思う。

ただし、やっぱりエンジニア受けしないとは思います。

似たような話なのに、なぜ受け入れられないことが多いのか?

また、そういった経験を通して、インフラを意識しコードをかけるスキルを身につけることは、Webエンジニアとしては大きな強みとなります。ISUCONで優勝できるかもしれません
インフラを意識してコードを書くということ - Hatena Developer Blog


たぶんこれですね。そうすることでスキルがあがるだとか、自身にメリットがあるとか、大きな強みになるとか思えないからというのはあると思う。

実際、自身が苦労して、周りが楽することになるから。
まあ全体で見れば、それがコスト削減につながりやすく、人件費抑制にもつながるんだけど、大抵そういう路線って個人にメリットがないことが多い。

インフラってなに?

「インフラを知る」と言っても、Webアプリケーションエンジニアが知る必要があるのはとりあえずさわりだけで構いません。例えば以下の様なことです
・コンピューターの基礎的な仕組みを知る
・TCP/IPをなんとなく知る
・Unixのプロセスモデルを理解する
・データベース。RDBMS/SQLを理解する
・HTTPを理解する。HTTP/1.0をtelnetで話す
・Infrastructure as Code に関する知識
インフラを意識してコードを書くということ - Hatena Developer Blog


上記引用先ではそんな話らしい。

たぶんですね、実際には「インフラを知る」って言うほどのことはなくて、そういう心構えで仕事してほしいな?という部分も多分にあったりすると思う。

ただし、小さい会社だと、周りに頼れない、自身だけが頼りであるという状況では、
・厄介ごとはうまく他人に押し付ける
・自身のスキルを上げる
と大きく2つの路線があるわけですね。

自身のスキルを上げる路線っていいように思うかもしれないけど、たいして良いことがないのが現実です。

まず、スキルがたいして上がらない、自身がほしいスキルではないという部分が多分にあると思います。だって、専門外の知識なんでさわりで少し知ってる程度で、武器になるかといえばなかなかそうはならないからですね。

あとは、苦労の割には評価されないって言う現実もあろうと思います。便利屋ならまだしも、貧乏くじを引く人になりかねないからですね。

自身で何でもできて1から作れる人が重宝されるか?というと微妙で、確かにそういう人は重宝されるけどそれに見合うだけの報酬を得たかったら、独立して自身でサービスを提供する側に回らない限りむりだと思う。

独立しても、作る側だとたぶんそんなに報酬がないと思う。器用貧乏になりかねないってことで、損する。

iOSアプリを1から作れるとしても、
作って売る側にまわるか?
依頼をうけて作った報酬をもらうか?
では、かなり違うと思う。

で1から作れない人のほうが効率よく稼いでいることも多いとは思う。

データベースを使うことでよく言われるネガについて

RDBを使うことに関してネガティブなことが言われることがあります。曰く、古い、複雑、であるとか、パフォーマンスが出ない、などです。多くの場合、それは発言している人の不勉強に起因します。「RDBよりもオンメモリKVSの方が爆速」とか言われても「はあ、そうですか…」としか言いようがありません。
インフラを意識してコードを書くということ - Hatena Developer Blog


本当の現場(現実)を知らない人ほど、周りに魅力的なことが言える気がします。また反論しにくいんですよね。

反論しにくいのは、現実(現状)を肯定するのが難しいからという部分があるからという単純な理由だと思う。でも、ベターな選択は現状であるという部分があるのだが、はたから「現状がダメ」というのが好きな層にはそんな話は聞こえない。

関連記事

優秀なエンジニアは、仕様変更に弱いプログラムしかかけない傾向にある
嫌な作業や面倒な作業を「闇」とかいう言葉を使って、悪者に仕立て上げるんじゃない
新人さんは知らない「完璧なものを作ると、レビューやテストで苦労する」話
データベースに「削除フラグ」をつける設計は、間違っているのか?!

スポンサーリンク

コメントを残す

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