「エンジニア」を含む日記 RSS

はてなキーワード: エンジニアとは

2024-03-19

anond:20240319122754

ザッカーバーグが来てくれるわけないし仮に来ても参考になるかどうかは微妙ってか絶対ならんし

そういう客集められるのはそのまま金集めに繋がりそうだし(俺は技術しか知らんけど)

まあまあやり手だからエンジニアを雇えるのでは?

anond:20240319102746

でも君は僕の質問に答えてないよね?

知的に考えて言い切ることが不可能なことをなぜ君は言い切るの?

それで何を得るの?

別の言い方をすれば仮に僕が元トップテックエンジニア年収2000万だと証明されたら君はどうするの?

anond:20240319095849

釣りだとか承認欲求だとかコンプレックスの代償行為とか色々あるんじゃないの?

一人じゃないんだし動機が同じと考える方がおかしいだろう

それより君はなんで理論的に言い切れないのが確実なことを言い切って自分袋小路に追い詰めるの?

これで俺が実際にトップテックエンジニアで2000万だって証明されちゃったらブチ切れるか逃げ出すかしかできないように自分でしちゃったじゃん

それで何が得られるの?

anond:20240317232558

ちょっと聞いた話なんでどこまでホントわからんけど、とある派遣会社にとても優秀なエンジニアがいるらしいんだけど、

その人はプレイヤーでいたいけど普通に会社務めするとマネージャーやらされるから、それが嫌で派遣社員でいるらしい。

他より抜きんでて能力があるから、めちゃくちゃ稼げるらしく、その派遣会社の稼ぎ頭だとか。

んでバリバリ働いたら、たまに長期に休みを取ったり、自分スタイルにあった働き方をしてるらしい。

能力がある人はそういうやり方もあるんだな、と思った。

2024-03-18

発注されたデザインを見てコーディングしてると、いつの間にかデザインがすり替わってた

発注されてから顧客デザイナーが変更を繰り返してた。そんなことはつゆ知らず、納品するたび、顧客からデザインと違います。しっかり仕事してください。」と怒られた。何が起きてるのかさっぱりわからず、自分の目が狂ってるのかと思った。1時間で終わる仕事のはずが、10時間かかった。もちろん、デザイン指示書仕様書も全て意味不明だった。発注前に、「どのエンジニアデザイン通りに仕事してくれないんですよ。」と顧客愚痴られた伏線は、回収された。

anond:20240318093413

バリアフリーのための設備を開発したエンジニアは昔から世の中を便利にするためにコツコツ頑張ってきたのにね

楽に便利にするための努力政治活動に掠め取られるのはかわいそう

活動家のために設計開発したものじゃないのに

共通処理化するタイミングはいつなんだろう…

案件のサイクルが早い時は次の案件設計に盛り込めばいいし

一人で運用しているときは思い立った時やってたけど

長期案件運用プロジェクトではどのタイミングでやればいいのかわからんな…

まるで九龍城

途中で参画させてもらったからまだプロジェクトリーダーとそこまで信頼関係がない

プロジェクトリーダーも他の案件をやったことがないのか、今まで見た事がない歪さをところどころ感じる

その先のクライアントはあまり開発スキルが無さそうだけど、変に技術者プライドいからか根本的な解決方法にならない要件を言ってくる

その両者間で仕様設計をするから工数的には無理がないのだけど、浮世離れした設計だなという感想

このシステムを使うユーザも、以降参画するエンジニア不憫だな…って思ってしま


偶々出向してきたエンジニアからあーだこーだ言うのもアレだけど中々独特な開発環境ハラハラしている…

経験上、突っ込んでいっても碌なことにならないから静観して、自分意見を求められた時に説得して発言力を高めるのが正解なのかな

気が遠くなる話だよ…

ウェブ開発をやっているMacユーザーぼやき

Appleウェブ開発者への冷遇が堪えるようになってきた

特にDockerネイティブサポートがないってのは我々からすると年々Macの致命的な弱点になってきてる

SafariPWA対応にも及び腰だし

Appleからすれば何で自社プラットフォーム以外に投資せにゃならんのってことなんだろうけど

ウェブ開発者Appleの売り上げにかなり貢献してると思うんだよ。特にDHHMacを勧めたおかげでMacに乗り換えたウェブエンジニアも少なくないってかかなり多いはず

そのDHH最近Windowsに移行してしまった

それ自体はBasecampとAppleの三割税をめぐる争いもモチベの一つだろうとは思うけど、単純にウェブ開発が快適な環境を求めてのことだろう

Appleとしてはマジョリティに売り込む方が大事で我々のような層の売り上げは微々たるものと考えているのかね

まあそうかもしれない

でもさ、今の時代ネットサービスを快適に開発できて快適に使えるっていうのはきれいなフォントと同じくらい重要なことだと思うし

作曲家デザイナー映画製作者と同じくらい、ウェブエンジニアに訴求するのも悪くないと思うんだけど

Apple経営陣の考えは別なのだろうね

結局この10年くらいは偶然我々の求める開発環境MacBSD環境が重なっただけの期間だったのかもしれない

このままだとウェブエンジニアMac離れはどんどん加速するだろうね

とはいえ自分MacフォントUIから容易には離れられない体になってしまった

ああフォントのためだけにうん十万のディスプレイをポンと買えたり代わりにiOSアプリ開発してくれるエンジニアを雇えるようになりたいでござる

2024-03-16

情報セキュリティ3要素

情報セキュリティ3要素というと機密性,完全性,可用性だけど,うしろつのトラブル情報セキュリティインシデントして扱われることがほとんどないのが不思議

ITエンジニアエンジニアと略すなってよく言われるけど,もしかしてサイバーセキュリティ意味情報セキュリティ(あるいは単にセキュリティ)って言う人が多くなってるのかな。

anond:20240316111524

世の中にはググればいくらでも出てくることはたくさんあるんだよ

コロナワクチン遺伝子が改変されて5年後に死ぬとか

キリがないか医者とかエンジニアとかは論文というインチキは除外されるフォーマットを読む

アドバイス欲の発散を諌める

知人が IT 業界への転職に向けて動き出し始めた。

そこで私は相談を受けた。数年前は知人と似た職業で似た立場からと。

知人はアドバイスを根掘り葉掘り求めるような姿勢ではなく、粛々と進めている印象だった。

私に対して、1つ2つ質問する程度。

そこで私は自分経験を話そうとする欲求を感じた。

しかし、私の話は数年前の話で再現性もない泥臭いリスクの高い行動と認識もしていたため、アドバイス言葉を飲み込む。

「数年前の話で状況も変わっているから」と言ってアドバイス欲を発散する行動を控えた。

知人を思うなら、アドバイスというよりコーチング観点から相手が抱える問題と付き合うべきと考えたから。

なぜアドバイス欲が発生するのだろうか。

ソフトウェアエンジニアとして働いてきて、端的な質問に背景も知らない中で断定的なアドバイスは、人間が抱える問題解決しないと経験則で感じていたから?

いや違う。

私も苦労したから、苦労経験と切り抜けた経験を語る機会をもらい、語ることで、私の苦労を誰かに認めて欲しかったのかもしれない。

---

数年前までの私は、自分言葉相手に投げつけがちな姿勢だったけど、今は少し違うようだ。

年齢を重ねたからか、多くの人と会話するようになったからか、それともIT業界活動してコミュニケーションの大切さと勘所を知ったからか。

私は IT 業界転職してよかった。

相手を多少なりとも慮るようになれたから、情報を取捨選択して問題解決する思考を得られたから、休日オフ時間睡眠時間を削ってまで熱中する趣味を得られたから。

最初転職した会社、今の会社、そして同僚に恵まれ幸運もあるけど、私は IT 業界転職してよかったな。

anond:20240315113901

エンジニアの人たちはよく宗教戦争っていうけど

それが許されるのはせいぜい比較して喧々諤々な議論を交わしてるときだけだよね

ひとつ派閥が内々でこれのここがいいよねと話している中に外からづかづかやってきてこっちの方がいい!と叫ぶのは違う

こんなの全然しかたなくない

エンジニアの人たちはこれを聖戦とでも思ってるのかもしれない

業界の良く知られているジョークとして言ってるのかもしれない

でも実態宗教戦争じゃなくてテロリストかウォーモンガーだよ

結構、嫌われると思うけどね

もしその行動を自己欺まんして肯定してる傲慢さまで含めてシニカル宗教戦争と言ってるのならそうっすねクレバーすね

マスターをメインに変えていく人々だからきっと言葉の使い方もウィットに富んでいるんだろうなー

2024-03-15

マクドナルドシステム世界でダウンしてるみたいだけど増田では話題になってないね

エンジニア多そうなブクマカですら無関心

みんなマクドナルド食べないんだな

Akin氏の宇宙船設計法則

University of MarylandのSpace Systems Laboratoryを率いるAkin氏の、宇宙船設計に関する箴言リスト。 原文はここ:https://spacecraft.ssl.umd.edu/akins_laws.html

含蓄とユーモアに満ちていて理系・とくにエンジニアには刺さると思うのだが、和訳がなかったので翻訳してみた。自分17、35、そして最後が心に残った。あなたにはどれが響いたかコメントで教えてほしい。


1. 工学数字は不可欠だ。数字のない分析意見に過ぎない。

2. 宇宙船完璧設計するのには無限の手間がかかる。だから、どこかが不調だったとしても動作するように設計するのがよい。

3. 設計は反復的な作業だ。必要な反復回数は、今までやった回数プラス1だ。これはいつでも正しい。

4. あなた設計に最もこだわった部分は、最終設計案においては必ず役立たずとなるだろう。この落胆とうまく付き合ってゆかねばならない。

5. (ミラー法則)3つの点があると曲線が一つ定まる。

6. (マール法則)両対数グラフプロットし太いマーカーを使えば、何でも線形に見えるものだ。

7. 設計を始めるときリーダーに一番なりたがる人間リーダーに一番向いていない。

8. 自然において、最適点は中庸場所にあるものだ。極限が最適点であるという主張は信用してはならない。

9. 必要情報が十分ないことは、分析を始めないでいい言い訳には断じてならない。

10. 疑問に思ったら、推定せよ。緊急時なら、当てずっぽうでもいい。だが、実際のデータが得られたときにそこに立ち返り後始末をすることを忘れてはならない。

11. 時には、全部破棄して最初からやり直すのが一番解決に近いこともある。

12. 正しい答えが一つだとは全く限らない。間違った答えはいつも複数あるものだが。

13. 設計要件に基づく。要件が求めるよりも少し「良い」設計にすることに正当性などない。

14. (エジソン法則)「より良い」は「良い」の敵だ。

15. (シアの法則設計改善点は、主に境界部にある。設計台無しにしてしまう点も主にそこにある。

16. 以前に似た分析を行った人たちが、当代最高の叡智と直結していたわけではない。従って、彼らの分析自分分析よりも信頼する理由はない。彼らの分析自分のものとして発表する理由は、なおさらない。

17. ある分析が紙の上に書かれていることは、その正しさとは何の関係性もない。

18. 過去経験現実性チェックにもってこいだ。だが、現実性ばかり考えていると、ほかの点で素晴らしい設計台無しにしてしまうこともある。

19. あなたがこの分野のほかの人々よりずば抜けて賢い可能性は非常に低い。分析の結果、終端速度が光速度の二倍になったのなら、あなたワープドライブ発明したのかもしれないが、十中八九どこかでミスをしたのだろう。

20. 悪い設計によいプレゼンをすると、いつの日か破滅する。いい設計に悪いプレゼンをすると、即座に破滅する。

21. (ララビーの法則あなた教室で耳にすることの半分はクソだ。教育とはどちらの半分がそうなのかを理解することだ。

22. 迷ったら、文書に残しておけ(文書化の必要性は、計画が終わった直後に最大になる)。

23. 開発スケジュール絵空事に思えるものだ──いつの日か、それに間に合わせられなかったかどで顧客にクビにされるまでは。

24. 「仕事崩壊体系」というものがある。あなたが何らかの体系を与えない限り、積み上がる仕事は増え続け、いつの日か崩壊するからだ。

25. (ボウデンの法則テストが失敗した後で分析修正して、はじめからずっとくだらないミスをしていたのだと発見するのは簡単ものだ。

26. (モンテメリオの法則馬鹿なことはするな。

27. (ヴァルシの法則スケジュールは一方向にしか進まない。

28. (レンジャー法則無料の発射などというものはない。

29. (フォン・ティーゼンハウゼンプロジェクトマネージメント法則計画の最終的な必要規模を推定するには、予定期間をπ倍し、予定コスト小数点を一つ右にずらせ。

30. (フォン・ティーゼンハウゼン工学設計法則)新しい工学システム設計に最大の影響力を及ぼしたければ、絵を描く練習しろエンジニアたちの作る乗り物はいつも、最終的には初期案のコンセプトアートみたいな見た目に落ち着く。

31. (モーの進化発生の法則)どんどん高い木に登り続けても、月にたどり着くことはできない。

32. (アトキンのデモ法則機械が全部完璧に動いているときに限って、上役はそこにいない。

33. (パットン事業計画法則乱暴なやり方で今週実行されるよい計画は、来週の完璧計画にまさる。

34. (ルーズベルトタスクプランニング法則あなたのいる場所で、あなたの持っているもので、あなたのできることをせよ。

35. (サン・テグジュペリ設計法則設計完璧になったとわかるのは、足すものがなくなったときではなく、取り除くものがなくなったときだ。

36. 凡百のエンジニアは美しいもの設計できる。優れたエンジニア効率的もの設計できる。一流のエンジニアは、実用的なもの設計できる。

37. (ヘンショーの法則計画成功させる鍵は、責任所在を明確にすることだ。

38. 「たまたま」新しいロケットを使って行われる探査計画は、事実上、そのロケットの発射計画なのだ

39. (言い方を変えよう)有人宇宙計画を、現実的予算・予定通りのスケジュールで進めるための3つの鍵:

 1. 新しいロケットを使うな。

 2. 新しいロケットを使うな。

 3. 何でもいいから、とにかく新しいロケット設計するな。

40. (マクビランの法則)うまくいくまで、改善することはできない。

41. 何かを正しくやる十分な時間があることは絶対にないが、しかしなぜか、何かをやり直す時間ならいつも十分にあるのだ。

42. 飛行計画がなければ、金がない。飛行計画があると、時間がない。

43. 何かを本当に理解できるのは、それを三度見たときだ。もしくは、それを一度教えたときだ。

44. (ラチャンスの法則)「時間たっぷりある」は、非常に短い時間で「時間が足りない」になる。

45. 宇宙は一切のミスを許さない。エンジニアあなたがしくじれば、誰かが死ぬ自分分析ほとんど正しかったのに……と言っても、部分点はもらえない。

2024-03-14

anond:20240314194949

中卒や文系がやってる「ITエンジニア」と情報工学学んだ人がやる「ITエンジニア」って全然違う仕事だしお給料全然違うよ

anond:20240314194949

ITエンジニアなんて中卒や文系でもなれるのにわざわざ情報工学選ぶ意味いからなぁ。

情報工学学んだ奴はそういうしょうもない派遣SEみたいな仕事には就かんだろ

anond:20240314192743

情報工学より機械工学電気工学の方が進路広くて良いし、もっと言うと医学部のほうが給料高くて食いっぱぐれもなくてええからなぁ。

ITエンジニアなんて中卒や文系でもなれるのにわざわざ情報工学選ぶ意味いからなぁ。

生モノ知識

ITエンジニアならJavaDBさえ完全に理解していれば絶対に職にあぶれる事は無い

若いやつはAIだとか人工知能だとかPythonだとかまるで解ってないんだよね

結局技術の使い方が解っているだけで技術のもの理解出来ていない

2024-03-13

anond:20240313224145

ワイの前前前職もそんな感じだったなぁ。

代表エンジニアを追加しろ

エンジニアチーム「派遣を追加しても役に立たないのでは...」

で無理やり追加されて、派遣エンジニアは何もできなくて毎日気まずい空気の中、椅子に座り続けてた。

今のネット議論なんてしたくないのに、どうして相手コメントが届くような仕組みのままなのか

SNSをはじめ、ネット文字入力出来るが、UI/UXにこだわっているわりに議論に向いているのは出てきてない。

エンジニアは、プログラミング問題あればパッチを当てるが、ネット議論については有効パッチのあて方すら議論にすら上がらない。

ならば、コメントすらも相手に伝えないというのがいいはずだが、なぜか伝えるところから進歩していない。

anond:20240313142920

そもそも1000万じゃ2倍じゃない

あと年収高い!しゅごい!するなら現場対応するエンジニア(サポートエンジニア)ではなく経営側よね

世界中エリートと戦い勝ち残ったプロ経営者じゃないと任せられないとかならわかる

anond:20240313111406

お前の企業じゃ優秀エンジニアを雇えるわけないという当たり前の現実を見なよ

優秀なエンジニア無駄にうるさくて金は出さなくて労働環境はクソなのに偉そうで意地悪で奴隷扱いしてきて細かいことまでうるさい日本人なんかと日本企業仕事したくねえんだよ

ログイン ユーザー登録
ようこそ ゲスト さん