はてなキーワード: エンジニアとは
ザッカーバーグが来てくれるわけないし仮に来ても参考になるかどうかは微妙ってか絶対ならんし
発注されてからも顧客のデザイナーが変更を繰り返してた。そんなことはつゆ知らず、納品するたび、顧客から「デザインと違います。しっかり仕事してください。」と怒られた。何が起きてるのかさっぱりわからず、自分の目が狂ってるのかと思った。1時間で終わる仕事のはずが、10時間かかった。もちろん、デザインの指示書や仕様書も全て意味不明だった。発注前に、「どのエンジニアもデザイン通りに仕事してくれないんですよ。」と顧客に愚痴られた伏線は、回収された。
バリアフリーのための設備を開発したエンジニアは昔から世の中を便利にするためにコツコツ頑張ってきたのにね
長期案件の運用プロジェクトではどのタイミングでやればいいのかわからんな…
まるで九龍城
途中で参画させてもらったからまだプロジェクトリーダーとそこまで信頼関係がない
プロジェクトリーダーも他の案件をやったことがないのか、今まで見た事がない歪さをところどころ感じる
その先のクライアントはあまり開発スキルが無さそうだけど、変に技術者のプライド高いからか根本的な解決方法にならない要件を言ってくる
その両者間で仕様設計をするから工数的には無理がないのだけど、浮世離れした設計だなという感想
このシステムを使うユーザも、以降参画するエンジニアも不憫だな…って思ってしまう
偶々出向してきたエンジニアだからあーだこーだ言うのもアレだけど中々独特な開発環境でハラハラしている…
経験上、突っ込んでいっても碌なことにならないから静観して、自分の意見を求められた時に説得して発言力を高めるのが正解なのかな
気が遠くなる話だよ…
特にDockerのネイティブサポートがないってのは我々からすると年々Macの致命的な弱点になってきてる
Appleからすれば何で自社プラットフォーム以外に投資せにゃならんのってことなんだろうけど
ウェブ開発者もAppleの売り上げにかなり貢献してると思うんだよ。特にDHHがMacを勧めたおかげでMacに乗り換えたウェブエンジニアも少なくないってかかなり多いはず
それ自体はBasecampとAppleの三割税をめぐる争いもモチベの一つだろうとは思うけど、単純にウェブ開発が快適な環境を求めてのことだろう
Appleとしてはマジョリティに売り込む方が大事で我々のような層の売り上げは微々たるものと考えているのかね
まあそうかもしれない
でもさ、今の時代ネットサービスを快適に開発できて快適に使えるっていうのはきれいなフォントと同じくらい重要なことだと思うし
作曲家やデザイナーや映画製作者と同じくらい、ウェブエンジニアに訴求するのも悪くないと思うんだけど
結局この10年くらいは偶然我々の求める開発環境とMacのBSD環境が重なっただけの期間だったのかもしれない
このままだとウェブエンジニアのMac離れはどんどん加速するだろうね
とはいえ自分はMacのフォントやUIから容易には離れられない体になってしまった
ああフォントのためだけにうん十万のディスプレイをポンと買えたり代わりにiOSアプリ開発してくれるエンジニアを雇えるようになりたいでござる
情報セキュリティ3要素というと機密性,完全性,可用性だけど,うしろ2つのトラブルは情報セキュリティインシデントして扱われることがほとんどないのが不思議。
ITエンジニアをエンジニアと略すなってよく言われるけど,もしかしてサイバーセキュリティの意味で情報セキュリティ(あるいは単にセキュリティ)って言う人が多くなってるのかな。
世の中にはググればいくらでも出てくることはたくさんあるんだよ
そこで私は相談を受けた。数年前は知人と似た職業で似た立場だからと。
知人はアドバイスを根掘り葉掘り求めるような姿勢ではなく、粛々と進めている印象だった。
私に対して、1つ2つ質問する程度。
しかし、私の話は数年前の話で再現性もない泥臭いリスクの高い行動と認識もしていたため、アドバイスの言葉を飲み込む。
「数年前の話で状況も変わっているから」と言ってアドバイス欲を発散する行動を控えた。
知人を思うなら、アドバイスというよりコーチングの観点から相手が抱える問題と付き合うべきと考えたから。
なぜアドバイス欲が発生するのだろうか。
ソフトウェアエンジニアとして働いてきて、端的な質問に背景も知らない中で断定的なアドバイスは、人間が抱える問題を解決しないと経験則で感じていたから?
いや違う。
私も苦労したから、苦労経験と切り抜けた経験を語る機会をもらい、語ることで、私の苦労を誰かに認めて欲しかったのかもしれない。
---
数年前までの私は、自分の言葉を相手に投げつけがちな姿勢だったけど、今は少し違うようだ。
年齢を重ねたからか、多くの人と会話するようになったからか、それともIT業界で活動してコミュニケーションの大切さと勘所を知ったからか。
相手を多少なりとも慮るようになれたから、情報を取捨選択して問題解決する思考を得られたから、休日やオフの時間で睡眠時間を削ってまで熱中する趣味を得られたから。
University of MarylandのSpace Systems Laboratoryを率いるAkin氏の、宇宙船設計に関する箴言のリスト。 原文はここ:https://spacecraft.ssl.umd.edu/akins_laws.html
含蓄とユーモアに満ちていて理系・とくにエンジニアには刺さると思うのだが、和訳がなかったので翻訳してみた。自分は17、35、そして最後が心に残った。あなたにはどれが響いたか、コメントで教えてほしい。
1. 工学に数字は不可欠だ。数字のない分析は意見に過ぎない。
2. 宇宙船を完璧に設計するのには無限の手間がかかる。だから、どこかが不調だったとしても動作するように設計するのがよい。
3. 設計は反復的な作業だ。必要な反復回数は、今までやった回数プラス1だ。これはいつでも正しい。
4. あなたが設計に最もこだわった部分は、最終設計案においては必ず役立たずとなるだろう。この落胆とうまく付き合ってゆかねばならない。
6. (マールの法則)両対数グラフにプロットし太いマーカーを使えば、何でも線形に見えるものだ。
7. 設計を始めるとき、リーダーに一番なりたがる人間はリーダーに一番向いていない。
8. 自然において、最適点は中庸な場所にあるものだ。極限が最適点であるという主張は信用してはならない。
9. 必要な情報が十分ないことは、分析を始めないでいい言い訳には断じてならない。
10. 疑問に思ったら、推定せよ。緊急時なら、当てずっぽうでもいい。だが、実際のデータが得られたときにそこに立ち返り後始末をすることを忘れてはならない。
11. 時には、全部破棄して最初からやり直すのが一番解決に近いこともある。
12. 正しい答えが一つだとは全く限らない。間違った答えはいつも複数あるものだが。
13. 設計は要件に基づく。要件が求めるよりも少し「良い」設計にすることに正当性などない。
15. (シアの法則)設計の改善点は、主に境界部にある。設計を台無しにしてしまう点も主にそこにある。
16. 以前に似た分析を行った人たちが、当代最高の叡智と直結していたわけではない。従って、彼らの分析を自分の分析よりも信頼する理由はない。彼らの分析を自分のものとして発表する理由は、なおさらない。
17. ある分析が紙の上に書かれていることは、その正しさとは何の関係性もない。
18. 過去の経験は現実性チェックにもってこいだ。だが、現実性ばかり考えていると、ほかの点で素晴らしい設計を台無しにしてしまうこともある。
19. あなたがこの分野のほかの人々よりずば抜けて賢い可能性は非常に低い。分析の結果、終端速度が光速度の二倍になったのなら、あなたはワープ・ドライブを発明したのかもしれないが、十中八九どこかでミスをしたのだろう。
20. 悪い設計によいプレゼンをすると、いつの日か破滅する。いい設計に悪いプレゼンをすると、即座に破滅する。
21. (ララビーの法則)あなたが教室で耳にすることの半分はクソだ。教育とはどちらの半分がそうなのかを理解することだ。
22. 迷ったら、文書に残しておけ(文書化の必要性は、計画が終わった直後に最大になる)。
23. 開発スケジュールは絵空事に思えるものだ──いつの日か、それに間に合わせられなかったかどで顧客にクビにされるまでは。
24. 「仕事崩壊体系」というものがある。あなたが何らかの体系を与えない限り、積み上がる仕事は増え続け、いつの日か崩壊するからだ。
25. (ボウデンの法則)テストが失敗した後で分析を修正して、はじめからずっとくだらないミスをしていたのだと発見するのは簡単なものだ。
27. (ヴァルシの法則)スケジュールは一方向にしか進まない。
28. (レンジャーの法則)無料の発射などというものはない。
29. (フォン・ティーゼンハウゼンのプロジェクトマネージメントの法則)計画の最終的な必要規模を推定するには、予定期間をπ倍し、予定コストの小数点を一つ右にずらせ。
30. (フォン・ティーゼンハウゼンの工学設計の法則)新しい工学システムの設計に最大の影響力を及ぼしたければ、絵を描く練習をしろ。エンジニアたちの作る乗り物はいつも、最終的には初期案のコンセプトアートみたいな見た目に落ち着く。
31. (モーの進化発生の法則)どんどん高い木に登り続けても、月にたどり着くことはできない。
32. (アトキンのデモの法則)機械が全部完璧に動いているときに限って、上役はそこにいない。
33. (パットンの事業計画の法則)乱暴なやり方で今週実行されるよい計画は、来週の完璧な計画にまさる。
34. (ルーズベルトのタスク・プランニングの法則)あなたのいる場所で、あなたの持っているもので、あなたのできることをせよ。
35. (サン・テグジュペリの設計の法則)設計が完璧になったとわかるのは、足すものがなくなったときではなく、取り除くものがなくなったときだ。
36. 凡百のエンジニアは美しいものを設計できる。優れたエンジニアは効率的なものを設計できる。一流のエンジニアは、実用的なものを設計できる。
37. (ヘンショーの法則)計画を成功させる鍵は、責任の所在を明確にすることだ。
38. 「たまたま」新しいロケットを使って行われる探査計画は、事実上、そのロケットの発射計画なのだ。
39. (言い方を変えよう)有人宇宙計画を、現実的な予算・予定通りのスケジュールで進めるための3つの鍵:
1. 新しいロケットを使うな。
2. 新しいロケットを使うな。
40. (マクビランの法則)うまくいくまで、改善することはできない。
41. 何かを正しくやる十分な時間があることは絶対にないが、しかしなぜか、何かをやり直す時間ならいつも十分にあるのだ。
42. 飛行計画がなければ、金がない。飛行計画があると、時間がない。
43. 何かを本当に理解できるのは、それを三度見たときだ。もしくは、それを一度教えたときだ。
44. (ラチャンスの法則)「時間はたっぷりある」は、非常に短い時間で「時間が足りない」になる。
45. 宇宙は一切のミスを許さない。エンジニアのあなたがしくじれば、誰かが死ぬ。自分の分析はほとんど正しかったのに……と言っても、部分点はもらえない。
DBエンジニアかなにか?
SNSをはじめ、ネットは文字は入力出来るが、UI/UXにこだわっているわりに議論に向いているのは出てきてない。
エンジニアは、プログラミングに問題あればパッチを当てるが、ネット議論については有効なパッチのあて方すら議論にすら上がらない。