  |
はてなキーワード: エンジニアリングとは
--
この本は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%増加する、という任意のステップに従ってタスク数を増減させる
指定したメトリクスのターゲット値を維持するようなにスケールアウトやスケールインを制御する方針
--
この本は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つの解決策が出てこないのなら、その思考には課題があるのではないか。
「他者に配慮できる」という曖昧な基準で異物を弾くようなチーム作りは、蛸壷化して致命的な結果を引き起こすことがある。
パワハラ、セクハラ、試験結果改ざんが、「なんでそんなんなるまで誰も言わなかったんだよ」となるのは、
「その構成員が他者に配慮できる人たちで構成されていて、異物を弾き続けた結果」であることが多い。
少なくとも、「エンジニアの”有害な振る舞い”への対処法」には、機会、動機、正当化のいわゆる不正のトライアングルのうち、動機と正当化を満たしている。
いやいや極端だろと思うだろう？
快不快が、正しい正しくないに繋がっていることは社会生活を送っていると極めて多い。
「マネージャーならば」法律や外部の意見も含めてかなり慎重に判断する必要がある。
「エンジニアならば」相手に快適に聞こえるようにコミュニケーションするスキルは磨いておいて損はない。
（あと、機械的に判断可能なルールを守ることが自分を守ることに繋がる。ルール順守か業績なら、常にルールを守れ。記録を軽視するな）
リクルートにおける VDI の導入、運用、コロナ対応、そして今後の ICT 環境を紹介する連載。
最終回は、現在取り組んでいる VDI と FAT PC のマルチ環境についてお伝えする。
石光直樹，リクルート（2021 年 06 月 04 日）
28 →目次に戻る
ただし、そうしたユーザーに対して環境が変わることについてきちんと説明しないと、混乱につながってしまいま
す。そこで、「なぜこのような環境に切り替えることに至ったのか」や、目的、狙いについてプロジェクト内で改め
て議論しました。ユーザーに対して納得感ある形で社内説明資料などをまとめて、各部署の主要なユーザーに向
けて情報を発信していきました。
今後の移行時には、さらに分かりやすい資料の共有や移行マニュアルの整備などを行い、社内広報の体制も整
えていきたいと考えています。
マルチ環境の実現は簡単なことではありません。特に FAT PC の環境をどう作るのかについては、時間をかけ
て検討しました。まずは、VDI 導入により大幅に解消された “3 つの課題 ”、すなわち「セキュリティの向上」「PC
管理コストの削減」「働き方変革への貢献」の対応策を FAT PC でどのように実現するか。これが次の課題です。
「セキュリティの向上」については、高セキュリティ業務にはセキュア VDI を提供し続け、FAT PC に対しては従
来よりもセキュリティを強固にすることにして、この課題をクリアしました。
続いて「PC 管理コストの削減」では先述の通り、VDI 化によって大きなメリットを得られた部分でした。例え
ば、夜間にパッチを当てたりできるのは、システム管理担当者からすると非常にメリットになります。ところが、FAT
PC に切り替えると、このメリットは享受できなくなってしまうことから、VDI 導入時に刷新した PC 管理システム
を FAT PC にも導入することで一定の解決を図るのに至りました。VDI の導入前に使っていた “ お手製 ” の PC
管理システムでは、パッチ当てや OS 更新などが大変でしたが、最新の PC 管理システムを導入することで、かな
り容易になっていたからです。とはいえ、VDI の管理性には劣ります。この点は、中長期視点でのより良い環境を
目指すために、優先度を下げた部分といえます。
そして「働き方変革への貢献」については、先述の通り、昨今の状況を踏まえると、ビデオ会議をより活用で
きる FAT PC の方がメリットを引き出せるのではないかと考えました。ただし、FAT PC に切り替えることで、い
ままでとはネットワークの流れ方が変わってきます。VDI では、データセンターと端末の間でやりとりされるのは
VDI 画面のデータが中心でしたが、FAT PC ではさまざまな実データがやりとりされることになります。また、社
外などから社内に VPN 接続をする必要があり、その部分がボトルネックになりがちです。その問題に対しては、
ネットワークを再検討することで解決を図ることにしました。われわれの社内ネットワークは VDI に最適化されて
いたので、FAT PC の増加に合わせて拠点のネットワークを増強したり、VPN を増強したりすることを検討しま
した。これにより、働き方変革で求められていたテレワークの要件に対しても十分応えることができると考えてい
たのです。
29 →目次に戻る
しかしながら、この方針は大きく変更を余儀なくされることになります。その理由は 2 つあります。1 つ目はコ
社内ネットワークの再検討はコロナ禍の影響を強く受けることになりました。在宅勤務の方針が示されたこと
で、社内からの接続が減る一方、リモート接続が増え、社内のネットワークトラフィックの在り方が大きく変わって
しまったからです。コロナ禍が続く中で、そしてアフターコロナでそういった状況がどうなるのかについては予測が
難しく悩みました。単純に拠点のネットワーク、特に WAN を増強したとして、使われなくなるなら投資が無駄に
なってしまいます。また、ネットワークにおいては今後のトレンドとして「ゼロトラストネットワーク」が注目されて
きています。おそらく、われわれの目指す「クラウド＆マルチデバイス環境」を支えるネットワークは「ゼロトラス
トネットワーク」になることでしょう。
では、いま「ゼロトラストネットワーク」のようなネットワークを入れるべきなのか。それともいまは暫定構成に
して将来的に「ゼロトラストネットワーク」に移行できるようにするのか――。
コロナ禍で勤務の環境が急速に変わってきていることも踏まえて、この点を検討しなければならなくなりました。
いまもまさに検討しているところで、いまだに完全な結論は出ていませんが、現時点では PC 環境と同じく、将来
的には「ゼロトラストネットワーク」に移行できるように、いまのネットワーク構成を考えるべきと思っています。
変化に対応して、かつ自ら変化を引き起こす
さらに、FAT PC 導入においては大きな変化があります。それは「SAC」（Semi-Annual Channel、半期チャ
ネル）の導入です。
VDI 環境においても「Windows 10」の導入は完了していましたが、「LTSB」（Long Term Servicing Branch※）
を導入していました。頻繁な更新を望まないユーザー向けに作られた、機能更新がない固定的な Windows 10 のモ
デルです。これに永続ライセンス版の「Microsoft Office」を組み合わせて利用していました。
※現在の名称は、「LTSC」（Long Term Servicing Channel、長期サービスチャネル）
これは、「レガシーアプリが存在するので、機能更新がない OS の方がいい」と思っての選択でした。しかし、機
能が更新されないので、OS や Office の最新機能が利用できないなど、将来的には「Microsoft 365」への接続
も制限されるような状況でした。
30 →目次に戻る
他方、SAC なら OS や Office が常に最新の状態になります。そのため、半期あるいは 1 年に 1 回程度のペー
スで機能が大きく更新されます。IT 部門としては、機能更新時に社内アプリケーションの動作確認などをする必
要があり、PC 管理タスクが増えてしまうことになります。PC 運用コストの増大につながり得るので、VDI から
FAT PC に切り替える際の検討ポイントの一つでもありました。しかし、ここでもわれわれは中長期視点を大事に
しました。
今後の「クラウド＆マルチデバイス環境」においては、環境が常に最新になる世界が普通になるでしょう。いま
のスマートフォンを見てもそうですが、OS はどんどん更新されて、次々と新たな機能やサービスが利用可能にな
るのがむしろ普通であり、その波が PC の世界にも到来しているのです。PC 運用コストが上がったとしても、わ
れわれもこの波に乗って、ユーザーに対しても新機能やサービスを次々に提供していき、より良く業務を行っても
らえるようになればすてきだなと思いました。
そこで、VDI から FAT PC への切り替えに際して、OS のモデルも LTSB（LTSC）から SAC に変更すること
にしました。PC が最新に変わっていくSAC のような世の中の変化に対応しながら、われわれの環境においても
変化を引き起こして業務を変えることができればと思い、現在、導入を進めています。
VDI 基盤の抜本的な刷新
ここまでは大多数のユーザーが利用することになる FAT PC のことを中心に述べてきましたが、セキュア VDI と
特定用途 VDI として利用する VDI 基盤のリプレースも大きな仕事です。
VDI 基盤リプレースにおいてもいままでの構成を踏襲せず、一からあるべき姿を検討することにしました。まず
検討したのはクラウドの導入です。将来「クラウド＆マルチデバイス環境」になれば、VDI 自体もクラウドのサー
ビスの一つという位置付けになるだろうと考え、クラウドでの VDI 利用を検討しました。
しかし、残念ながら今回クラウド VDI の採用には至りませんでした。われわれの試算ではオンプレミスに比べて
コストが見合わなかった点と、管理機能がまだまだのように思えた点が見送りの理由でした。クラウドはますます
発展する領域なので、今後は状況が変わるかもしれません。われわれも引き続き状況を観察し、一部の環境には
クラウドをトライアル的に導入してみることも視野に入れて、現在、検討しています。
当面の方針としてオンプレミスの VDI を構築することにしましたが、いままでの構成をそのまま踏襲するような
ことはしませんでした。必要としたのは、運用性やコスト、拡張性に優れたアーキテクチャでした。
31 →目次に戻る
議論、検討を重ね、さらに比較、検討した上で、われわれは HCI（Hyper Converged Infrastructure）構成
を選びました。HCI はサーバ中心のアーキテクチャで、SAN（Storage Area Network）スイッチやストレージ
を省くことができ、構成がシンプルになり、運用性やコストにメリットがある他、リソース拡張はサーバを追加する
だけでよいので、拡張性にも優れています。われわれが望んでいた点を満たすアーキテクチャと評価しました。
いままでは「サーバ＋ネットワーク＋ストレージ」のいわゆる「3Tier」構成で安定運用できていたので、これを
変えるのは大きなチャレンジでした。とはいえ、チャレンジしないことには運用性もコストも拡張性も勝ち取れませ
ん。「新たなことに挑戦するのが、われわれのエンジニアリングの方針だ」と考え、HCI 構成を選びました。
加えて、VDI 基盤のデータセンターのネットワークを SDN（Software Defined Network）に切り替える決断
もしました。従来の構成と比較し、運用性や管理性を鑑みて、より優れているという結論に達したからです。また
ワクチン接種証明アプリが旧姓対応していない件について、なんか論点のずれた擁護が拡散されてるみたいなので書く
https://togetter.com/li/1819901
擁護派としてはアジャイル開発のようなものを持ち出して「完璧でない状態でリリースして何が悪いのか」という主張を展開しているが、ここで我々が批判したいのはアプリが不完全な状態でリリースされていることではなくて、約束を守らない政府である。
選択的夫婦別姓制度の導入を頑なに拒み「旧姓の通称使用の拡大を進めていく」というよくわからないエクスキューズで常にお茶を濁し続けてきた政府が、ワクチン接種証明アプリというまさに政府公式のアプリにおいてちゃっかりと旧姓使用の弊害を導入してしまっている矛盾。
つまり我々がすべきことはアプリのバグ修正ではなく強制的夫婦同姓制度の解体であり、この件でアプリの不具合をエンジニアリングの観点から擁護してしまうことは、選択的夫婦別姓制度をめぐる政府の矛盾を追認することになってしまう。
(WEBエンジニアリング)未経験から(院卒新卒カードを使って)Webエンジニアになって(5年で)年収1000万円(の会社員と同等の手取りを本業副業合わせて)稼げるようになった話
工学部（情報系でない）の修士課程で、画像処理や機械学習を用いた研究をしていた。
PythonやLinuxについては少々経験したが、MVCに関する技術は一切触った事がなかった。
就活して、Web系のC向けの名の知れたサービスを自社開発している企業にエンジニアとして入社することになった。
※当時は今より牧歌的で自分のような人間が入社することができた。今はわからない。
PythonのFWを使ったWebサービスの開発を行なっていた。
とはいえ、腰を据えて開発している時間は少なかった。大きい企業の既存事業にいると開発とは無関係の運用や調整業務がかなりあった。
3年目くらいで副業を始めることにした。
上記の通り業務内で技術力を向上させることがむずかしかったのと、未経験で業界に来ているハンデを抱えていたのである。
Python以外の言語はほとんど書けなかったのでPythonでwebかスクレイピングの案件を探した。
5件ほどお祈りされたが、懲りずに応募し続けてたら採用された。Flaskの案件だった。Flaskは書いたことがなかったが採用された。
当時はその会社に Python が書けるエンジニアがいなかったので重宝されたし、仕事も任せてもらっていた。
契約は週15時間だった。その間にCOVIDが来て全てが在宅勤務になり、気付いたら週30時間まで稼働するようになっていた。。
当初の見込み通り基礎体力は身に付いていったと思う。
最初の案件を納品したあと、次の案件をもらい、段々仕事の幅が広がっていった。
Linuxサーバを触ったりDBサーバを触ったりphpを雰囲気で書いたりDockerfileを書いてECSの環境を構築したりなど。
※Golang, Rust, k8sなど人気の技術の案件は探してもちょうどいいものが見つからないのでチュートリアルをやる以上の勉強はできていない。
ちょうど良さそうな募集があったので応募したところ今度は一回で採用された。
給与も少し上がった。後ほど元の副業の給与も上がり、本業の給与も少しずつ上がった。
年収がいくらなのかよくわからなくなったので、月々の手取りを銀行口座から調べて、年収1000万円の会社員の手取りと比較すると大体同じくらいの金額になっていた。
犠牲にしていることといえば可処分時間くらいだと思っているので、TLDR節に書いた内容についてはそんなに無理がなくある程度再現性があるんじゃないかと思っている。
辛さでいえば大学院のほうが辛かった。
可処分時間ということでいえばCOVIDで通勤時間が無くなった影響はそれなりにある。
自分について
・要領は決していい方ではない
要領がいい人なら5年も掛けずもっと早く辿り着くのではないか。
今回、特にジョブホッパー的な動きはしていない。各職場（案件）に恵まれたこともあるし、器用さが足りないといえばそうだと思う。
エージェントは中抜きされるという意見もあるが、自分はSNSは長続きしないし、勉強会もあまり肌に合わずほとんど出席することはないのでエージェントを通してしか案件を見つけられていない程度の行動力しかない。
年収についてはおおむね満足するようになり、人間とは面白いもので段々欲がよく出てくるようになった。
モダンな技術は、レガシーな技術よりも、おしなべて責任範囲が明確であり、何かあったときのリカバーがききやすかったり、謎の負債が含まれるリスクも少なく、幾分か安心して開発ができる。枯れた理論は好きだが、新しい技術を先回りして身につけることにも興味が湧いてきた。
xRやブロックチェーンといった、技術で未来を作っていくことにも興味が出てくるようになった。
｢BluAge(以下青年)が内々定を取り消した件が話題だがスタートアップなんてそんなもん。｣ということをおぢさんはおゔぁさんがTwitterでよくつぶやいているが、学生目線でスタートアップについて語っている意見があまりなかったので書く。
先に結論。もちろん例外もある。身につくのはやばい組織への嗅覚で、属人性の高さからマネジメントが崩壊していて、学歴･社歴でイキったやつが跋扈しているのがスタートアップだ。
Twitterでスタートアップがほぼ全面的に批判されているが、スタートアップで働いて身につく力はあると思う。一番身につくのはやばいと思ったらすぐに逃げる力だ。これはスタートアップから逃げるごとに身につく力だ。もうやばいスタートアップはたくさんある。雇用契約書を出さない、距離感が雇用主と従業員じゃない、放置プレイ、やりがい搾取。働かないとわからないし、働いても自分が当事者だったと気付くのはやめたときからさ。でもね、そんなのもうどうでもいいんだ。全部やめちまったからね。
スタートアップは基本的にマネジメントが崩壊している。バイト(インターンとでも呼んだ方が良い？)の学生に適当に見繕った課題(タスク)を渡してコードレビューもせず放置。できたらレビューもガバガバでマージしといて、とそんなもん。青年もガバガバだったんじゃないのかな？いや、エンジニアリングはまともだったかもしれないな。なにせ内定を取り消されたのは営業担当の学生だったらしいからね。
でも概してマネジメントは終わっているはずで、今回は人事がそんな感じだったから(おそらく)経営の判断で内々定を取り消したんだと思う。属人性が高いことの良さは一般常識を欠如していたという言い訳で内々定を取り消せること。スタートアップを始めるときは肝に銘じるように。
次にスタートアップは頼れるものが学歴と社歴くらいしかない。東大とかは山程いるし、青年と同様に外銀のIBD出身とか外コン出身の人もたくさんいる。一番キモいのはそれを全面に出すこと。青年がどんなビジネスをしているかわかっている人が何人いる？みんな代表の出身しか知らないだろ？
そして、すぐにやめている人ばかりだ。青年の代表もメリルとBCG出身だけどそれぞれ1年くらいでやめているのかな？｢やべえ｣スタートアップをとっととやめる俺が言えたことではないけど、そんな｢良い｣会社をすぐにやめるやつがまともかねえ？会社に合う合わないがあるってのはもちろんだが、普通それくらいの会社に入れる人なら新卒で入る会社がどんな雰囲気かくらい調べてから入るだろう。上司のパワハラ、時間外労働、そもそも起業するつもりだった、どれだろうね。
最近だと元GAFAを名乗るエンジニアも増えてきている。おいそこ！w弊社の佐藤はエンジニアじゃないからなwまだ勘違いしているのか。数年働いた程度だとコーディングテストはできるかもしれないが、会社経営はうまくできないらしいね。そもそもGAFAで会社経営は教えてもらえないと思いますけどね！
学生エンジニア(N=1)(主語がでかい)(エンジニアはソフトウェアエンジニアという意味(はてなの人すぐエンジニアって単語で騒ぐからね(優しい)))からの意見でした。S式が好きなのでかっこが多いかもしれないですが、学生の皆さんはスタートアップに入る前にLispを書いて慣れておきましょう。Paul Grahamが投資してくれるかもしれないので。
副業がしたい。
新卒からエンジニアとして働いて苦節１１年、2回の転職を経て年収が８００万を超えた。去年のことだ。
今年、仕事にもずいぶん慣れた。リモートワークも肌にあっている。子供も小学校に入学した。
学生時代は恋愛などにうつつを抜かすことなく努力を続けたことで、コンピューターサイエンスの基礎を身につけ、希望の企業から内定がいただけた。
社会人になってからはエンジニアという職業が想定とは違い、エンジニアリングより対人コミュニケーションが重要であるギャップに苦しんだ。
しかし技術が好きなことは変わらずその道の研鑽を怠らなかったことで、紆余曲折ありながらも居心地のよい職場に巡り会うことができた。
妻とは今時珍しい両親から強烈プッシュされたお見合い婚だったが、落ち着いた人柄で一緒にいても穏やかな気持ちでいることができる。
一人でいるよりも、二人でいる方がリラックスできるという感覚は今まで想像したことがなかったので驚いた。
子供は、私が大好きだった祖父の面影をどことなく持っていて、時折かわいいという感情と懐かしいという感情が入り混じる不思議な感覚になることがある。
イケてる人たちを横目に黙々と生きてきたつもりだったが、気づけば公私ともに恵まれた環境にいる。
技術以外にはさほど欲がなかったので、今新たに何を求めて生きていけばいいのかわからなくなってしまった。
その幸せを生み出す事業か、幸せを損なうものを排除する事業に自分の力を使いたいと考えた。
こんな自分でもなんとか生きていけている社会に対して貢献したくなった。
今の会社は業績的にも安定しているし、エンジニアとして長く働けそうないい環境なので転職は考えていない。
「副業 サイト」「副業 マッチング」でググればいくらでも候補が出てくる。
しかしそこで辿り着くサービスはほとんど採用時に成果報酬がかかる。かなり高額の。それは不本意だ。
自分がどれくらいマッチするか、作業時間を確保できるか、パフォーマンスを発揮できるかは働き始めなければわからない。
そして働くのはきっと私が惚れ込んだ社会の役に立とうとする気概をもつ企業だろう。
その企業に私がジョインするだけで数十万円の負担をかけたくない。だから成果報酬がない副業マッチングサービスを探したい。
wantedlyは企業を探すのには良さそうだがスカウトが来ない。自分から応募するほどの情熱はないというか、情熱を持てるほどの事業かチームかというのを見分ける術がない。
PayCareerはいくつかスカウトをいただけたが、残念ながらマッチするプロダクトではなかったので友人を紹介した。面談して報酬を貰えるサービスというのは素晴らしい体験だった。
友人・知人の紹介だと、断る時に断りづらそうな気がして敬遠している。
Webベンチャーのエンジニアで、数人チームのリーダーやってる。
半年に一回評価面談があって、このとき上司(マネージャークラス)から評価を受ける。
上司はいわゆるエンジニアリングマネージャーで、コードもバリバリ書いてる。
ただなんだかモヤモヤするのは、この上司が私のチームが作っているサービスについて、ほとんど何もわからないことだ。
言語もシステム構成もまったく違うし、システムでどこが重要なのか、課題なのか、何が起きると障害になるのか、そうしたことがわかってない。
というより、その人の扱っているサービスと領域が違うから、理解しようというモチベーションもないのだと思う。
ここに書きたくなったのは、こういう状況はよくあることなのか知りたくなったのと、こういうときどうすればいいか聞いてみたかったから。
上司を批判しているような文章になったかもしれないけど、そういうわけじゃない。
上司も必要に迫られれば把握できるだろうし、それにその人がこのチームのマネージャーになったのは会社の都合だから、
わざわざ忙しい中で時間を割いてこのサービスを学習しなくてもいいと思う。
ただ、私が評価面談のときに「すごいことをやったぜ！」とその人にアピールしても、できて当たり前でしょみたいな反応で、
東京電機大学を卒業後、VisualBasicを用いた会計支援ソフトウェア開発、自社サイトの制作に従事するなど、アプリケーションエンジニア、フロントエンドエンジニアとして5年にわたって業務をおこなって参りました。
今後は、その中で得られたVisualBasicの予約語暗記の実務経験を活かして、VB.NETによる開発に取り組んでいきたいと考えています。
VisualBasicを用いた会計支援ソフトウェア開発
VisualBasicを用いた内製ソリューションの引き継ぎ・バージョンアップ開発。
特に、複数の法定通貨をないまぜに扱うため、レート換算と端数処理が至るところに発生する困難な会計処理でした。
社長がホームページ・ビルダーで作成したプロトタイプを元に、HTML5/CSS3で再構築した自社コーポレートサイト。
プロトタイプのコードは全く利用せず、スタイルデザインのみを参考にいちから構築しました。
また、その2年後にスマートフォン対応も行っており、SCSSやflexboxを利用したモダンなHTMLコードを構築できたと自負しております。
ウソウソ。アメリカの IT かなんて遅れている。コンビニや、ATM のゴミっぷり、そして銀行のだめ具合と、車に至っても「自動運転」がスバルのアイサイトと五十歩百歩なんで、アメリカを出汁にするのは、間違いですよ。
「進んでいるように思われがちなアメリカのITだが、コンビニ・ATM・銀行のレベルは低い。車に関しても「自動運転」を称しているが、スバルのアイサイト（レベル2）と五十歩百歩なので、レベルが低い。アメリカを優れている国として日本と比較するのは間違っている。」
日本はテック系がオーバーエンジニアリングすることが問題である。
解読できなかった。
基本的に小さい会社の社長はクソだ。小便チャーの社長がこの世で一番キモい人種だ。（小便チャーは奇跡的に生まれた単語なので皆さんにもぜひ使っていただきたい）
何がクソかというと小さい会社のクセに偉そうだからだ。というより、クソだからが故に全く会社がスケールしないのだと思う。
特にエンジニアリングに全く理解がないくせに技術を扱おうとしている社長。
これは本当にクソ。
こういうところで働いているエンジニアはマジで速く逃げた方が良い。
おいクソ(=社長)、エンジニアは適当な要件入力すれば思い通りのもの出力する万能なAIじゃねーんだぞ。
まずリスペクトを持て。そして急かすな。
何回でも言う、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな、急かすな
技術的な知識を持ち合わせてないくせに「もっと早く終わらない？」とかふざけたこと抜かしてんじゃねえぞ。
Dを早めればQCが犠牲になるってことわかってて言ってるんだよな？
いや、本気出せば終わるかもしれないぜ？ただ、それは長続きしないのわかってるか？
Sustainableって言葉知ってるか？最近流行りのSDGsのSだよ。
常に自分の会社がSustainableかどうか問い続けろタコ。
そんな人間に社長なんか務まらないから早くサラリーマンに戻れ。てめえみたいな無能を雇ってくれる会社なんかないから社長になっちゃったんだろうけどな。
てめえみてえな小さな会社の理念になんて誰も共感しねーんだよ。
そのくらい金のことしか考えてないんだよ。
あとは金のためにやってるだけ。
みんなお前がやってることに誰も興味持ってないよ？誰も共感してないよ？自分だけ調子乗ってスベってるの恥ずかしくないの？
てめえにはてめえの論理があるのかもしれないが、こっちにはこっちの論理があるんだよ。
お前が凡人だからだよ。
お前はサラリーマンになるほどの社会スキルがないから社長になってるだけなんだよ。
サラリーマン以下なんだよお前は。
何に憧れてるか知らないけど、お前はイーロンマスクじゃねえんだ。
まずは冷静に自分を見つめ直してみろ。
そして基本情報を取れ。まあ無理だろうけどな
②正社員どころか派遣にすらやらせたくない仕事を格安でやらせる
週3で月20万って学生にとっては超高いけど、会社が払うお金はエンジニアの大卒初任給として最低レベルの年収240万相当（厚生年金や福利厚生や設備費が不要な事を考えると更に格安）
で、君が大学でネットワーク研究室所属のスペシャリストだったならともかく、そうじゃないのに最新プロトコルのタスクを振ったのは後者の可能性が高い。
だってまともな社会人ほど誰だって儲かるかどうか分かんない技術で貴重な時間を無駄にしたくないから。
だからタスクを振った企業側にフェードアウトした君を恨む資格は無いし、フェードアウトしても特にフォローアップや引き留めが無かった所を見ると向こうは良い所で切り捨てられてラッキーだったと思ってるくらいだと思う。
こういうのは良くあるエンジニア適性とは関係の無い失敗プロジェクトの類なので真剣に凹む必要は無いよ。
俺なんて新卒1年目最初の1ヶ月は「Webを支える技術」やPHPの入門書を読まされて10-19時の定時でTwitterも読みながら通勤してるだけで20万貰えたぞ。
なので院進できるなら院進して某カリや某INEのようなマシなエンジニアリング企業をリベンジした方が良いと思います。
あと学生のメリットはカネにならない技術を全力で勉強できる事なので、エンジニアとして年収1000万超えを目指すなら5年後10年後にカネになる最新技術（新しいライブラリとかでも全然良い）を勉強してればすぐになれる。大学からプログラミング始めた元同僚がそれで年収1500万超えたから。
そして他の人がもう指摘しまくってるからネチネチとは言わないけど、大文字小文字が重要なプログラマーにとって「unity」とか「c++」とかの正式名称と違う表記はヤベー奴の兆候と見做されるのでそこだけ直した方が良いよ。
フロントエンドエンジニアで正社員1000万以上もらってるし採用（企画・書類選考・面接）もガッツリやってる人間から言わせてもらうが、
ここでマウント取ってるスキルが本物だとして270万で終わったのであればもう人間性の問題だわな
ソフトウェア開発は基本的にチームで一つのプロダクトを作り上げていく作業だから、こんな憎悪とか妬み僻みでこじれたようなやつは面接でまず弾かれる。
自分では学歴とか職務経歴で門前払いって言ってるけどそういうの重視しない会社でもこのスキルでまともな人間性なら最低でも5~600万は行ける。800とか1000でも望める範囲かもしれない（今の東京の話）
人間性で内側に入れてもらえないだけ。仮に内側に入れたとしても現場の人間から疎まれて自然と隔離された閑職に追い込まれる。
ただ、例外的にこういうタイプの人間性ヤバいけど物凄い技術力で貢献できるから見逃されてる奴はいる。
しかしマネジメントコストが異常に高いので、各現場でせいぜい10人20人に1人いるかいないかという割合。
つまりエンジニアリングスキルがどうこうとか関係なく、人間性が故に極端に狭い土俵で戦わざるを得なくなっているケース。
そしてそのポジションは、マジで人格破綻してるけど1日中コード書いて生産活動できます、趣味は技術の勉強とOSSへのコミットと論文読み込みです、みたいな怪物の争う世界。
もし医大生に転向したならそのポジションを勝ち取れるほどではないんだろ。
そんな話をソフトウェアエンジニア全般に当てはまるかのような論調で書くのは間違っている。
まあとはいえそういう際どい人材のポジションもNetflixのNo more brilliant jerksの話に象徴されるように真の巨大ソフトウェア会社からは居場所を失いつつあるようだ。
過去にgoogleやfacebookのソフトウェアエンジニアと何人も話したことはあるし、ちょっと提携で業務やったりもしたがみんな良い奴だったよ。
人格者かどうかはしらんけど、少なくともこういう負のオーラをまとってるやつはいなかった。
エンジニア業界はそこそこの能力でまともな人間は当たり前のように生き残れる。チームを全員エースクラスで揃えることはほとんどの組織で不可能だから。
能力が高くて人間出来てないやつは生き残れない。能力が高くて人間も出来てるやつが少数ながら存在するからハイスキル人材の狭い枠を争うと負ける。
まあそれも程度論だけどな。世界で数人しかいないレベルの特殊能力持ちなら人間性なんてどうとでもなるだろうし。
元増田が読んでるかはしらんけど、エンジニアの適正ってのもいろいろある。
twitterなんかにいるIT芸人みたいな奴らを見ると、純粋な技術力や腕力だけで勝ち上がるのは無理だと思うかもしれないが、
現場に入って開発していけばそれがチームワークであることが分かると思うし、そこでバリューを出す方法はいろいろあることが分かるから。
増田がぴえんしてて可愛そうなので書いてみた。
できるだけ親身に答える。
自分は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
ｶｧｧ...///
若い人の間でのビタイチの語意って完全に変わっちゃったのかね それとも鐚一文とビタイチで分離した感じ？ お金の話でもないのにビタイチって出てくるとすごい違和感ある
うるせーな...と思ったけど確かに変だな。
直した。
