  |
はてなキーワード: バックエンドとは
--
この本は5章まであるが、4章と5章はハンズオンであるため、文字としてまとめるのは1から3章に留める。
1章
【コンテナとは】
他のプロセスとは隔離された状態でOS上にソフトウェアを実行する技術
コンテナにはアプリの稼働に必要となるランタイムやライブラリを1つのパッケージとして全て含めることができる。そうすることでアプリの依存関係をすべてコンテナ内で完結できる。
全ての依存関係がコンテナ内で完結するため、オンプレでもクラウドでも起動する。
ステージング環境でテスト済みのコンテナイメージをプロダクション環境向けに再利用することで、ライブラリ差異による環境ごとのテストに必要な工数を削減できる。
サーバー仮想化では、仮想マシンレベルでリソースを分離し、ゲストOS上でアプリが起動する。つまり、アプリだけでなく、ゲストOSを動かすためのコンピューティングリソースが必要。
一方コンテナは、プロセスレベルで分離されてアプリが稼働する。OSから見ると単に１つのプロセスが稼働している扱いになる。
【Dockerとは】
アプリをコンテナイメージとしてビルドしたり、イメージの取得や保存、コンテナの起動をシンプルに行える。
イメージ(アプリケーションと依存関係がパッケージングされる。アプリ、ライブラリ、OS)
レジストリに保存
【Dockerfileとは】
このファイルにコマンドを記述することで、アプリに必要なライブラリをインストールしたり、コンテナ上に環境変数を指定したりする。
1章まとめ、感想
コンテナの登場により、本番・開発環境ごとに1からサーバーを立ててコマンドや設定ファイルを正確に行い、環境差異によるエラーをつぶしていき...というこれまでの数々の労力を減らすことができるようになった。
2章
ECSとEKSがある。
オーケストレーションサービスであり、コンテナの実行環境ではない。
ECSの月間稼働率は99.99%であることがSLA として保証。
デプロイするコンテナイメージ、タスクとコンテナに割り当てるリソースやIAMロール、Cloud Watch Logsの出力先などを指定する。
指定した数だけタスクを維持するスケジューラーで、オーケストレータのコア機能にあたる要素。サービス作成時は起動するタスクの数や関連づけるロードバランサーやタスクを実行するネットワークを指定。
2種類ありECSとFargateがある。 Fargateに絞って書く
Fargateとは
コンテナ向けであるためEC2のように単体では使用できず、ECSかEKSで利用する
サーバーのスケーリング、パッチ適用、保護、管理にまつわる運用上のオーバーヘッドが発生しない。これにより、アプリ開発に専念できるようになる
・コンテナごとにENIがアタッチされるため、コンテナごとにIPが振られるため起動に若干時間がかかる
ECR
・App Runner
利用者がコードをアップロードするだけでコードを実行できるサービス。AWS側で基盤となるコンピューティングリソースを構築してくれるフルマネージドサービス。
App Runner
2021年5月にGA(一般公開)となったサービス。プロダクションレベルでスケール可能なwebアプリを素早く展開するためのマネージドサービス。Githubと連携してソースコードをApp Runnerでビルドとデプロイができるだけでなく、ECRのビルド済みコンテナイメージも即座にデプロイできる。
ECSとFargateの場合、ネットワークやロードバランシング、CI/CDの設定などインフラレイヤに関わる必要があり、ある程度のインフラ知識は必要になる。App Runnerはそれらインフラ周りをすべてひっくるめてブラックボックス化し、マネージドにしていることが特徴である。
ECS Fargateを利用した場合のコスト、拡張性、信頼性、エンジニアリング観点
【コスト】
EC2より料金は割高。ただし、年々料金は下がってきている。
【拡張性】
デプロイの速度 遅め
理由1 コンテナごとにENIが割り当てられるため。ENIの生成に時間がかかる
理由2. イメージキャッシュができないため。コンテナ起動時にコンテナイメージを取得する必要がある。
タスクに割り当てられるエフェメラルストレージは200GB。容量は拡張不可。ただし永続ストレージの容量が必要な場合はEFSボリュームを使う手もある。
割り当て可能リソースは4vCPUと30GB。機械学習に用いるノードのような大容量メモリを要求するホストとしては不向き
【信頼性】
Fargateへのsshログインは不可。Fargate上で起動するコンテナにsshdを立ててsshログインする方法もあるが、セキュアなコンテナ環境にsshの口を開けるのはリスキーである。他にSSMのセッションマネージャーを用いてログインする方法もあるが、データプレーンがEC2の時に比べると手間がかかる。
しかし、2021年3月にAmazon ECS Execが発表され、コンテナに対して対話型のシェルや1つのコマンドが実行可能となった。
Fargateの登場からしばらく経過し、有識者や経験者は増え、確保しやすい。
多数のユーザーに使ってもらう
CI/CDパイプラインを形成し、アプリリリースに対するアジリティを高める
各レイヤで適切なセキュリティ対策（不正アクセス対策、認証データの適切な管理、ログ保存、踏み台経由の内部アクセス）を施したい
2章まとめ、感想
AWSが提供するコンテナサービスにはいくつかあり、なかでもFargateというフルマネージドなデータプレーンがよく使われている。ホスト管理が不要でインフラ関連の工数を削減できる一方、EC2より料金が高く、起動に若干時間がかかるのが難点である。
3章
この章では運用設計、ロギング設計、セキュリティ設計、信頼性設計、パフォーマンス設計、コスト最適化設計について述べている。
Fargate利用時のシステム状態を把握するためのモニタリングやオブザーバビリティに関する設計、不具合修正やデプロイリスク軽減のためのCI/CD設計が必要である。
モニタリングとは
システム内で定めた状態を確認し続けることであり、その目的はシステムの可用性を維持するために問題発生に気づくこと
オブザーバビリティとは
オブザーバビリティの獲得によって、原因特定や対策の検討が迅速に行えるようになる
・cloud watch logs
・Firelens
AWS以外のサービスやAWS外のSaaSと連携することも可能
Firehoseを経由してS3やRed shift やOpenSearch Serviceにログを転送できる
fluent bitを利用する場合、AWSが公式に提供しているコンテナイメージを使用できる
- ソフトウェアやライブラリの脆弱性は日々更新されており、作ってから時間が経ったイメージは脆弱性を含んでいる危険がある。
- 方法
脆弱性の有無はECRによる脆弱性スキャン、OSSのtrivyによる脆弱性スキャン
継続的かつ自動的にコンテナイメージをスキャンする必要があるため、CI/CDに組み込む必要がある。しかし頻繁にリリースが行われないアプリの場合、CICDパイプラインが実行されず、同時にスキャンもなされないということになるため、定期的に行うスキャンも必要になる。
cloud watch Eventsから定期的にLambdaを実行してECRスキャンを行わせる（スキャン自体は1日1回のみ可能）
Fargateの場合、サービス内部のスケジューラが自動でマルチAZ構成を取るため、こちらで何かする必要はない。
・障害時切り離しと復旧
ECSはcloud watchと組み合わせることでタスク障害やアプリのエラーを検知できるうえに、用意されてるメトリクスをcloud watchアラームと結びつけて通知を自動化できる
ALBと結びつけることで、障害が発生したタスクを自動で切り離す
AWS内部のハードウェア障害や、セキュリティ脆弱性があるプラットフォームだと判断された場合、ECSは新しいタスクに置き換えようとするその状態のこと。
Fargateの場合、アプリはSIGTERM発行に対して適切に対処できる設定にしておかなくてはならない。そうしておかないとSIGKILLで強制終了されてしまう。データ不整合などが生じて危険。
ALBのリスナールールを変更し、コンテンツよりもSorryページの優先度を上げることで対処可能
自動でクォータは引き上がらない
cloud watch メトリクスなどで監視する必要がある。
パフォーマンス設計で求められることは、ビジネスで求められるシステムの需要を満たしつつも、技術領域の進歩や環境の変化に対応可能なアーキテクチャを目指すこと
利用者数やワークロードの特性を見極めつつ、性能目標から必要なリソース量を仮決めする
FargateはAutoscalingの利用が可能で、ステップスケーリングポリシーとターゲット追跡スケーリングポリシーがある。どちらのポリシー戦略をとるかを事前に決める
既存のワークロードを模倣したベンチマークや負荷テストを実施してパフォーマンス要件を満たすかどうかを確認する
・スケールアウト
サーバーの台数を増やすことでシステム全体のコンピューティングリソースを増やそうとする概念。可用性と耐障害性が上がる。既存のタスクを停止する必要は原則ない。
スケールアウト時の注意
・Fargate上のECSタスク数の上限はデフォルトでリージョンあたり1000までであること。
ECSタスクごとにENIが割り当てられ、タスク数が増えるごとにサブネット内の割当可能なIPアドレスが消費されていく
Application Autoscaling
Cloud Watchアラームで定めたメトリクスの閾値に従ってスケールアウトやスケールインを行う
CPU使用率が60~80%ならECSタスク数を10%増加し、80%以上なら30%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
一見正しそうだが正しくないラベリングをすると、結果として意図しない結果を引き起こすことがある。
"難しい人"、"有害な振る舞い"というのは、大変よろしくないラベリングになる。
こういったときに「言ってることはわからなくないけど、なんか違うな」と違和感を持ち、解決策を探るのがエンジニアである。
アクションに落とし込めないもの、計測できないもの、機械的に判断できないものは、いわゆる人間力に頼ることになる。
具体的に以下を例に挙げる。（元の記事の一番最初に例示されているもの）
この短い（１行８０文字以下を短いと言う）文章の中に、人間力に頼る判断は何か所あるだろうか？
私は、「創造的」「議論」「阻害」「時間を奪う」の４つは、機械的な判断が難しいと思う。
これは客観的な基準で「他者の話に割り込んで、自分の意見を差し込」んでいる。
先ほどの例だが、こんな前提があったとする。
そうすると、「営業と管理職から見て、大変有意義で創造的な議論に、毎度口をはさむ難しい組み込みエンジニア」というレッテルは正しいだろうか？
各人の判断は、正しいだろうか？
人間力に頼る判断基準で多数決を用いるのは、エンジニアリングで無く、政治的な解決だと思う。
先ほどの会議の例でいえば、５人中３人が心理的な負担を感じており、不愉快な気分になっている。
チームの60%が「創造的な議論を阻害する有害な振る舞い」だと認定している。
その判断は、正しいだろうか？
この場合、組み込みエンジニアが、難しい人 or 有害な振る舞いをする人として、指導もしく排除されたとする。
それは、心理的安全性をあげ、チームの生産性をあげる行為だろうか？
例えば、今後デザイナーは、営業と管理職が「どのような雑談をどの長さでしていても」発言しなくなるかもしれない。
デザイナーからみて、その会話が創造的な議論か判断ができないからだ。
さて、Web系のバックエンドエンジニアや、クラウドインフラエンジニアだと、アラートを設定したり、対応したいことがある。
「何かまずいことが起こっていることを、何らかの方法で監視して、対応したい」という場合だ。
例えば、待機系サーバーの起動時に妙に時間がかかっている場合、自動対応ができないので、アラートメールを飛ばして手動対応したいと思ったとする。
絶対値（10分）か、相対値（過去5回の起動時間の平均値）かは場合によるし、それが適切かはまた別の話だ。
「他者の話に割り込まない」というルールは、誤検知を引き起こしやすいアラートだ。
そんなのは常識で考えたらわかるだろう？曖昧な基準は「俺のは有意義な議論の発言だ」の判断を誰かが決めることになる。
大多数がそう思っていれば、という複合的な基準もありうる。その場合、先ほどの例の組み込みエンジニアは、アラート対象になる。
「会議のアジェンダに記載されている内容を3分以内で喋っている場合に、割り込まない」というのは、一つの基準になる。
この場合、営業が「営業概況を冒頭のアジェンダに加えて欲しい」と交渉する余地がある。
また「報告時間が10分は欲しいが、3回以上は一度会話を止めるので、営業概況に対する質問はその時に」という合意もできる。
そして、顔合わせのキックオフミーティングで、営業概況をやるかは、会社やチームによる。
明示的なルールで縛るのが正しいかと言えば、そうした方が良い職場もあるだろうが、窮屈な職場も多いだろう。
という簡単な話に見えることですら、ルールを作って守らせることに違和感を感じる感性も正しいと思う。
チーム（もしくはマネージャー）に求められるのは、こうした「何かチームに嫌な感じがある」ときに軌道修正できることだ。
一例でしかないが、例えば以下の流れでルールを作らずに、解決できることもある。
コミュニケーションコストを、チームを維持するのに必要なコストとして、きちんと時間を割けるかが重要だと思う。
さらに言えば、「それは有害な振る舞いだと自分は思うが、あなたがそう思わない理由は何か」とコミュニケーションを取れないのであれば、そこに課題があるだろう。
チームやマネージャーがある人を「難しい人だなあ」と思ったとして、2つの解決策が出てこないのなら、その思考には課題があるのではないか。
「他者に配慮できる」という曖昧な基準で異物を弾くようなチーム作りは、蛸壷化して致命的な結果を引き起こすことがある。
パワハラ、セクハラ、試験結果改ざんが、「なんでそんなんなるまで誰も言わなかったんだよ」となるのは、
「その構成員が他者に配慮できる人たちで構成されていて、異物を弾き続けた結果」であることが多い。
少なくとも、「エンジニアの”有害な振る舞い”への対処法」には、機会、動機、正当化のいわゆる不正のトライアングルのうち、動機と正当化を満たしている。
いやいや極端だろと思うだろう？
快不快が、正しい正しくないに繋がっていることは社会生活を送っていると極めて多い。
「マネージャーならば」法律や外部の意見も含めてかなり慎重に判断する必要がある。
「エンジニアならば」相手に快適に聞こえるようにコミュニケーションするスキルは磨いておいて損はない。
（あと、機械的に判断可能なルールを守ることが自分を守ることに繋がる。ルール順守か業績なら、常にルールを守れ。記録を軽視するな）
15年以上前、高校生の時にハロプロのファンサイトを作っていた
さっき、急に思い出して思い立ってwayback machineで検索した
URLは何故か覚えてるもんだな
coolオンラインで作ってた方は残っていたが、iswebで作ったやつは無かった＿|￣|○
coolの方もところどころ残ってないページはあるけど、CGIで作られたゲストブックはほぼほぼ残っていた
ヲタ友と遠征の計画したり、ヤフカテに登録されたのをみんなで喜んだり、荒らしをみんなで叩いてるのを見てなんかエモい気分になってしまった
そういやアンテナもダイアリーも作ってたけど、大学入学のタイミングでヲタ活卒業してアカウント消しちゃったんだよな
今思うと恥ずかしいハンドルネームも、「HTML4.0に対応しました！」とかいうクソどうでも良いウェブマスターからのお知らせも、またほろ苦い思い出だ
MKEditor使ってテーブルレイアウトで作ってたけど、今見てもまあまあまともに作ってて、結果、今もウェブ制作の仕事をしている
エディタはVS Codeになり、フロントはReactで組み、バックエンドはAWSになったけど、当時の若い情熱みたいのを思い出して、また頑張ろうって気持ちになった
俳優は移籍したとしても認知度が変わらないので移籍したとしても同じ結果を望めるのに対して、
エンジニアは働きぐわいが外部からわからないし、本当に価値のあるエンジニアかどうかがわからないでしょ？
あとエンジニアは素晴らしくても＋αとして特許やバックエンドのテクノロジーもありきじゃないと価値を出せるとは言えないので
人材の価値を見出してくれる企業も限られてくるので流動性がどうしても低くなる。
あとは、俳優はエンジニアより再現性が低い存在で俳優Aと同じスペックの俳優Bがいても俳優Aじゃないと売れないというのもある。
エンジニアとして収入を上げたいなら流動性上げてと再現性を低くする戦略もある。
たとえば技術系のブログを書いたり、技術的な特許申請をしてエンジニアがいることで優位にする戦略があると思うが、
いまもjQueryをWebアプリケーションの大事なライブラリとして使っている会社は少なくないと思う。
jQueryを会社で使っていると何が問題なのかを語っていこう。独断と偏見によるものなので、jQueryを使っていても問題ない会社も当然ある。たとえばペライチのサイトを作る会社とか小規模サイトなんかでは全く問題ない。
採用困難で売り手市場になっている時代、そして「jQueryを触らなければならない環境 vs モダンフロントエンド環境」という選択肢がある中で、あえてjQueryを選ぶフロントエンドエンジニアは少ない。
また、新人はもはやjQueryを学ぶことはない。彼らはES6以降のJavaScript / TypeScriptを書く。よしんばjQueryを学ぶことになった新人がいたとしても、それはただその新人が可哀想なだけで、現役なわけではない。ラガード（遅滞者）の仲間入りをさせているだけだ。新人でもキャリアをデザインできる新人は「jQueryはオワコン」という情報には触れているので、よほど就活で失敗しない限りはjQueryのところにたどり着かなくなっている。
そもそもバックエンドエンジニアでもモダンフロントエンドを書くような環境が増えてきた中で、2世代も前のjQueryだけでアーキテクチャに関する一考もないコードをメンテしなければいけないので、「jQuery」という言葉だけでフロントエンドエンジニアでなくとも入社を避けがちだ。（jQueryでアーキテクチャがしっかりしている可能性は低い。アーキテクチャがしっかりしているならばjQueryに依存しておらず、jQueryに依存していないのであれば簡単にjQueryから脱却できるはずで、簡単にjQueryから脱却できるならもう脱却しているはずだからだ）
メインストリームの部分はほとんどリプレイスが終わっているというでもなく、すべて現役でjQueryなのであれば尚更問題で、誰もメンテしたがらないコードの出来上がりだ。「弊社はCOBOLで書いてます！」とにこやかに言うようなものだ。
（ただし、さすがにjQueryだけでフロントをやっているという会社の求人をほとんど見かけることはない。無意識のスクリーニングで落としているのかもしれない）
jQueryを使っている会社には、フロントエンドエンジニアは一人もいないと言いきってもいいかもしれない。もしくは、今まさにjQueryをやめようとしているか、たまたま入ってきたフロントエンドエンジニアが今まさに辞めようと迷っているかのどれかだ。
「jQueryを使っていました」というエンジニアは、他社からはフロントエンドスキルが0とみなされる。つまり、フロントエンドエンジニアではないという意味だ。jQueryは、jQueryを使っている会社に対してしか武器にならないのだ（逆はできる）
jQueryを書ける人口自体は増えているだろうが、労働市場からは撤退し始めている。昔jQueryを書いていた人材の人数が上限で、そこから新たに学ぶ人の絶対数が減っているため、全体としては減っている。
私もjQueryは以前業務で書いていたが、もう数年書いていない。特にメリットを感じないからだ。遊びで、生のJavaScriptを書くことはある。
jQueryで入社するのは、昔からjQueryを使っている高齢のエンジニアか、なぜかjQueryを学ぶことになってしまった新人である可能性がある。
そのため、需要と供給に応じて、昔いたようなスキルレベルの人を今の市場で見つけようとすると費用がかかってしまう。jQuery書けますという人材が高年齢化しているのだ。そして世継ぎはいない。
リプレイスはハッキリ言って難しい。モダンなフロントエンドを学習するだけでは足りなくて、それを使いこなせた上でしかもjQueryを使用したカオスイベントコードも読めて、そしてアーキテクチャを考えてリプレイスしなければいけない。
時代が下るにつれて、そうしたハイスキル人材はより高価値になっていき、レア度も単価も高くなる。今そういう人を雇うという判断をしない会社が、どうして今後もっとハイスキルの人を雇えようか。
jQueryを使ったサービスがしっかり利益を出している点もリプレイスを難しくしている。全廃もできない。かと言ってコストに見合わなければリプレイスという経営判断も難しい。経営が困難な状態ならより厳しい。
何も理由がなくjQueryを使い続けたいという奇特な人は多くないはずだ。何か理由があってそうなっているわけだ。カッコよく言うと『ナッシュ均衡』という状態だろう。今会社にいる人材もいわゆる『jQuery人材』が多いため、そこを打破するのはとても困難な道だろう。
jQueryから抜け出すには、すでにいる人材がなんとかしてリプレイスするか、外から連れてきて改革するしかない。しかし大抵の場合、既存の従業員にとってはそんな大変なことをするよりも転職したほうが楽な道だ。（もちろん、「jQueryしかなかったサービスをモダンフロントエンドにした」というのが実績としてある人材はかなり魅力的な人材で引くてあまたなことだろう。その意味ではピンチをチャンスに変えるときの『チャンス』ではある）
ReactやVue.jsに変えたいと思ったとして「じゃあお前それですぐに利益出せんのかよ？」と詰められたら、その論争をクリアしてまで変えるのはほとんど無理に近い。通常、リプレイスそれ自体は価値を生み出さない。リプレイス後に運用コストが低下したり、人材獲得がしやすくなるために利益が出るのだ。リプレイスとは長期の投資であるため、短期的には必ず損失になる。経営が困難な状態でリプレイスしようとするのは、生活困窮世帯にリボ払いをやめさせるぐらい難しい。そのため、まず自分が身銭を切ってリプレイスするしかない。そしてリターンがあるかもわからない身銭は切りにくい。そして同僚は容易に『抵抗勢力』になる。
jQueryを今も使っているということは、裏を返せば「これまでリプレイスをしてこなかった」「リプレイスしようとしたが無理だった」という実績にもなる。
jQueryを使っている会社は、昔からあるコードをもとに書いているため、今もES6以前の文法で書いている可能性がある。そうしてどんどんと情報が少なく、古く、現代で通用しにくいものになっていく。
bundlerを使っていない可能性が高いし、もしかするとCI/CDも無いかもしれない。そうすると、モダンなインフラエンジニア（もしくはモダンなインフラ知識のあるエンジニア）がいないかもしれない。SREという概念がないかもしれない。
世間一般から見ると会社の中が古いのだが、古い会社にいると「自分が古い」とはなかなか思えないものだ。太っちょの集まりの中にいたら「自分はそんなに太ってない」と思うのと同じことだ。
すべては憶測なので、実際は違うかもしれない。
さんざんdisってきたが、そもそもjQueryは何も悪くないし、大変優れたライブラリだ。ちょっとしたプロトタイプを作るときには良いものであるかもしれない。しかも今もjQuery自体はメンテされている。そのため、状態管理さえうまくできていればjQueryだろうがなんだろうが問題ない。
問題は、jQueryというライブラリを使ってきた時代からアーキテクチャが前進していない点にある。何年もずっとその状態だということだ。そこを今日に至るまで誰1人として変えられなかったということだ。特に経営陣は何の問題視もしていない可能性が極めて高い。そうした社内のしがらみが反映された結晶体、それが『使用技術: jQuery』という言葉になっているのだと思う。また、ヤバさは、jQueryのバージョンに反比例する。
jQueryを使っているアプリケーションには、jQueryが担保していなかったアーキテクチャ部分に問題があることが多い。また、どこから呼ばれているか誰もわからない複雑なイベント、SPAもクソもないページ遷移ごとのリロード、誰もどこもテストできず、HTMLにベタ書きで書かれたJavaScriptコード、その場しのぎでデタラメに書かれた関数、無視される変数のスコープ、サポートが終わったライブラリ、ドキュメントを見つけるのすら困難なよくわからないライブラリ、高齢者しか知らない伝説の機能・伝説のハック、などもある。これらはモダンフロントエンドではほとんど発生しないものだ。
そのため、一定の基準として「jQueryを使っているかどうか」で、フロントエンドエンジニアとしてのやりがいがあるかどうかを判別できる。
そうして、フロントエンドエンジニアというのはもうjQueryに見向きもしていない。書けるけど書きたくない。パラレルワールドのようなものだ。
そういうようなことを「使用技術: jQuery」という文言から感じ取ってしまうのだ。
（そしてこれは、実際の仕事の中身が違うかどうかは関係ない。jQueryとは、そういうふうなブランドと化しているのだ）
jQueryを使っている会社からしたら「そんなことはわかっている」という部分で、「じゃあどうすればいいのか？」という部分が気になるところだと思う。
そこで、後編では「どうやってjQueryを全廃すればいいのか？」「実際にどのように全廃したのかの事例」について、だいたい来週ぐらいに書くつもりだ。
お楽しみに！
誰が指示するの？GANとかあるけど、最終的には人やで？
え、人が指示した結果、相手がどう動くかという話をしているんだよ。
生産コストが下がる(から、あるタイミングで人よりもコスト高であっても、何年か待っていればその頃の製品は人を雇うより安くなるでしょ)って話をしているんであって、販売した個別の製品に追加コストがかかるかって話はしてないよ。
フィードバックがかかる強化学習とかあるけど、イマイチなんだよなぁ。なんか「過学習」とか言い出すし。勉強しすぎて東大に落ちる、って馬鹿の言い訳にしか聞こえないがね。
現時点でも将棋とか特定の用途に用いる人工知能は学習を繰り返してプロより強くなってしまうわけで、汎用人工知能となると、多様な用途それぞれについて学習を繰り返して日々賢くなっていくのだろう。でもそこまで行くと便利になる反面、もしも、使役する側であるはずの人よりも人工知能のほうが賢くなったうえに人による制御ができなくなるケースなどが起きたらやばいかも…という想像なのだが、なにか話がかみ合っていないような？
最近のテック系の生態系を知らずに、ほとばしる若さに嫉妬して学生をぶちのめして申し訳なかったと思うようにはヒートダウンしてきた「年収270万円だった医大生」です。こんばんは！
すごく反省している。ただ、優雅に自分が学生時代に学んだ知識をもって、社会人にその勢いを保持したままで定年まで行ける可能性は高くないと私は思うのだ。おそらくは名門大で、勢いのある会社なら引く手あまたそうな貴方は自分にとっては眩しかったのだ。
本当に認識不足だった。もともと Android/iPhone や jQuery で JSON の操作をしていて、PHP/Rails/Spring でバックエンド界隈から MySQL/PostgreSQLを触り、人員不足で AWS をも触って QA および SRE をしていたエンジニアだったのだけど、ブロントエンドが DB に遠いという理由で簿給だと思っていたのは、各派遣会社の給料をみる分だと間違いだと理解した。知識がアップデートされてないのはオレ自身だったようだ。申し訳ない。
根拠は、NoSQL はスキーマ無しなのは途中までは良いけど、後で負債になる感じがするので。あと、Firebase は Google が中途でやめるとなったときが怖いぞ。JS なら express というフレームワークあるし、Kotlin もサーバーがあるから、古典的なサーバークライエントモデルで良いのじゃないかな？Next なら SSR あるし。
自分のような新卒採用を逃した身分では、サイバーエージェントのような B to C 領域でトップティアにある会社に紹介してもらえるというのは「蜘蛛の糸」のような貴重なチャンスに思えたのだよ。そりゃ、ある程度は経験積めばスカウトが来るかもしれないけどさ、自分は年食っていたから「サイバーエージェントで働けるという可能性」に全力をかけたよ。その結果が、場末の未認可SES って、しかも反社だったなんて、すごくショックだったよ。クソな「自称数学者の人工知能論を聞いて土日が終わり、平日はブラック客先常駐」な日々はうんざりだ。
年収270万の元増田です。2013年のフロントエンド界隈にいた（jQuery と Adobe Flash）のですけど、今って本当に700万近くまでもらえるのですか？例えば、React や Vue を TypeScript でかけたりするとどれぐらいもらえるのでしょうか。
自分は 2013年ぐらいに Java で Android と iPhone にて Objective-C で、jQuery でブラウザのフロントエンド部を書いていたら、強制的に Spring Framework で SQL バリバリのバックエンドを書くように指示されて、しかも AWS EC2 の上でプロダクション用の構成をつくったりしてたのですけど、２社目の社長に「職歴が浅いから、月給25万円ね」と言われて、絶望した記憶があります。
増田がぴえんしてて可愛そうなので書いてみた。
できるだけ親身に答える。
自分は30代中盤のソフトウェアエンジニアです。さすがに20代前半で1000万円は無理だったけど30までには超えたとかそういう感じです。プログラミングを始めたのは20歳過ぎてからだし未踏とか想像も付かない程度のスキルです。でも技術に限らない色んな知識を駆使したり良い感じの待遇が得られる会社を嗅覚を使って見つけ出して生き抜いてます。
まず、なぜ増田は苦しいのかと言うとこの2つをどっちも求めてるからだと思う。
例えば増田が「少なめの給料は許せないので貪欲に勉強する」とか「勉強したくないから少なめの給料で暮らしていく」って選択を許容できるならだいぶ話が変わってくるよね?
どっちも欲しいから苦しんでる。
何かが両立しなくて困っている時は「トレードオフ」と「ウルトラC」の2つの方策がある。
2. 少なめ給料で暮らすことを許容する
3. 両方の望みを叶える方法を見つける。
増田って実は意識してないだけでたくさん勉強してたりしないかな?
この辺が出来る時点でかなり勉強が必要だったはずだけど、どうやって覚えたんだろう。
「レビューを貰って知識が増えて気持ちいい」って発言もあったし増田が「貪欲な勉強」と見なしてないだけで実は結構勉強してたりしないかな?
例えば「作りたい物を作るのに当たって必要な知識を学ぶのは全く苦にならない」とかそんな傾向は無いかな。
大切なのは「勉強」という過程じゃなくて「スキルが上がってる」っていう結果の方だから、過去の経験の中から「増田が楽しんでるのにスキルが上がって行ったような状況」を出来るだけたくさん思い出してみて、その状況を意図的に作り出しにいくと良いよ。
「貪欲な勉強」ではなく「増田にとって自然体な勉強」を探してみては。
あと、通信プロトコルの実装は増田に合ってなかったんじゃないかな? 「与えられた競技で一等賞を取る」じゃなくて「どの競技なら一等賞を取れるのか探す」って発想も大事。
何か考え方を変えることで、少なめの給料が許容できないだろうか?
そもそも、何で増田が少なめの給料を許容できないかというと「他者より良い待遇を得たい」「そうじゃないとプライドが許せない」からだって書いてるよね。
もしかして「中高で未踏ジュニア通してます。20代前半で1000万行きそうです」っていう人たちを基準に考えてない?
それって偏りに偏った集団なんだよね...
(地域差や雇用形態や世帯あたり人数を無視して)雑に見ると、1世帯あたり200万円〜300万円が1番のボリュームゾーンだという事が分かる。
https://www.mhlw.go.jp/toukei/saikin/hw/k-tyosa/k-tyosa19/dl/03.pdf
年齢が低いほど給料も低い傾向があるため、20代前半で1000万行くのは同世代の中でも上位1%未満くらいだと思う。
増田が考えてる「少ない給料」がどのくらいか分からないが、それって本当に少ないんだろうか...? という視点で考えたら妥協できるかも知れない。
増田の望みを言い換えると、
っていう事なので...
でも方法としては、以下のどっちかだと思う。
増田が重大な勘違いをしてそうな点は「エンジニアとしてのスキルが待遇に直結する」と思ってそうなこと。
実際には待遇が良い業界/会社を見つけることの方が遥かに重要。
次に、エンジニアとしてのスキルだけじゃなくて他のスキルと組み合わせるのも重要。
例えば、増田だったらラピッドプロトタイピングとかが好きらしいから「エンジニアリングがわかるプロダクトマネージャー」みたいなポジションとかどうかな。需要も結構あると思うし、そういうポジションに未踏を通せるような人は来ない事が多い。
あと「20代前半までは貪欲に勉強する。そこで経験値と高待遇を得てその後はゆるく働く」みたいなプランはどう?
実際のところ転職する場合の待遇は「前職の給与水準」にかなり影響されるので、一回ガツッと給与を上げられると後が楽だったりする。
増田の話しを聞いて思ったことは全体的に比較対象がおかしいということ。
って偏りが大きすぎるよ...。
高すぎる基準と比較して無用な劣等感を抱いちゃってないか? あと、1つのやり方にこだわらずに増田に合ったやり方を探す事が重要だと思う。
じゃあな!! 頑張れ!!
って言われてしまって申し訳なかったのでなぐり書きだけど書いた。
https://anond.hatelabo.jp/20210710001238
良く分かってないけどこんなのどうでしょうか!?
https://anond.hatelabo.jp/20210710112041
ｶｧｧ...///
若い人の間でのビタイチの語意って完全に変わっちゃったのかね それとも鐚一文とビタイチで分離した感じ？ お金の話でもないのにビタイチって出てくるとすごい違和感ある
うるせーな...と思ったけど確かに変だな。
直した。
