「AZURE」を含む日記

はてなキーワード: AZUREとは

2020-02-03

■エンタープライズ ITの光と闇

エンタープライズ ITの世界を紹介する。これから業界に入る若者は参考にしてほしい。

ユーザ部門
IT 部門
1次請け
2次請け
n次請け

エンタープライズのITはこんなツリー構造になっている。下層にいくほど枝分かれする。層の深さや枝分かれの多さはプロジェクトの金額による。このあたりの闇は増田でも多く語られている。たとえ天下のGAFAでも1次請けやIT 部門の下に入る。昔はオラクルやIBMだったのがAWSやAzureに代わっただけで構造的には同じだ。

それではカネの流れと利益構造を説明していこう。増田のメインターゲットである下層から説明する。

n次請け

この層はIT 会社ではなく人材派遣会社といっていい。n次請けはn-1次請けに人材を派遣するので以下の構造がある。

売上 = 単価 × 作業時間
利益 = 売上 - 労務費 (販売費や間接費は省略)

例えば、月単価100万円の人を10人派遣すると売上は1,000万円になる。この売上を営業やコーポレートといった連中と社内で取り合うわけだ。だから給料を上げるには単価と作業時間を上げるしかない。

n次請けの営業はn-1次請けと単価を交渉する。単価は派遣対象のスペック（経歴書）で決まる。単価を上げるためのキーワードはだいたい決まっていて、チームリーダーとかクラウドとか入れておけばいい。あと、作業時間は無駄に多い方がいい。自動化で作業時間を減らすやつはバカだ。君の残業代は売上から出ている。

n次請けにいる人に告げる。さっさと転職しろ。AWSに転職したら給料3倍だ。

2次請け

この層は人材プール会社になっている。大企業は資本金や信用調査などを満たせない零細企業と直接取引ができない。2次請けは大企業と零細企業の間に入り、需要に応じて人材を売る役割を果たす。あと、キチガイみたいなやつが入らないようにフィルタするとか、派遣されてきた人が突然バックれた時に代わりを探すことも大事な付加価値だ。

売上 = 単価 × 作業時間
利益 = 売上 - (労務費 + 外注費)

例えば、月単価50万円の人を80万円で紹介すると、売上は80万円、利益は30万円になる。給料を上げるには安い人材を高く売ることが重要だ。そのためには2次請け社員がチームリーダーとなり、n次請けの安い作業者でチームを作ればいい。作業者の人数を増やせば売上は伸びる。リーダーができないやつはクビだ。

2次請けにいる人に告げる。現職はいい待遇だと思っているだろうが、外の世界を見ろ。

1次請け

この層は大企業だ。2次請けやハードソフトベンダを統合してシステムを納品する。一括請負契約の場合はリスクバッファの役割を負う。開発が炎上してもIT 部門は痛みを負わない代わりに、マージンでガッポリ儲ける仕組みだ。

売上 = 単価 × 工数
利益 = 売上 - (労務費 + 外注費)

実際には、IT 部門が出したRFPに対して工数を見積もり、価格を提示する。受注できたら開発に取り掛かり、納品と検収を終えたら売上が立つ、という流れになっている。コンペの場合は見積工数にかかわらず提案価格を大幅に安く出すこともある。また、受注してから売上が立つまで数年かかる場合もあるため、資本力が勝負だ。ハードウェアやパッケージ製品、クラウドを一緒に販売する場合もある。

給料を上げるには出世することだ。出世するには仕事を増やして安い人材を高く売る必要がある。

IT 部門にマネジメント力や商材をアピールして受注確度や価格を上げる。→売上を増やす
安い人材で開発が回る仕組みを作る。→原価を減らす

重要なのは流行りの商材でIT 部門を釣って仕事を取ることだ。RPAやAIなどのバズワードがなぜ人気なのか理解してもらえただろうか。開発は2次請けに任せればいい。お前の単価はいくらかわかっているか？

1次請けにいる人に告げる。リストラに備えろ。潰しの効かない仕事を続けていると転職できなくなる。

IT 部門

IT 部門は、ユーザ部門から受託した企画を具体化し、ベンダをコントロールしていくことが主な任務になる。あとは負債化したシステムの運用管理をやっていく。

予算 = (開発費 + 運用費) × 各システム
実績 = 予算 - コスト削減分

IT 部門はコストセンタなのでコスト削減が評価される。また、トラブルでシステムが止まると社内から批判を浴びるため品質管理が評価される。

給与は上げるには出世することだ。こういう方法がある。

ベンダに新しい開発手法を提案させてコスト削減をアピールする。
ベンダに便利な機能を提案させて事業貢献をアピールする。
システムの安定稼働をアピールする。

負債化したシステムは細々とメンテしていくしかない。ハード保守が切れるタイミングで大規模更新を計画して実績をアピールだ。

ただし、IT 部門はポストが限られているので出世するには社内政治が重要だ。出世の見込みがないなら転職しろ。

ユーザ 部門

ユーザ部門は新しい企画を立てて経営層から承認をもらい、ITを使って収益を得ることが仕事だ。あるいは費用を削減することが仕事だ。

売上 = サービスの売上
利益 = 売上 - (IT 部門委託費 + 販売費 + ...)

ユーザ部門はコンサル会社に企画書を作らせて、営業やマーケティングなどの他部門と要件を調整し、遅くて融通の利かないIT 部門のケツを叩くことが任務だ。

だがよく考えてほしい。IT 部門と多重下請のケツ叩きに無駄な時間を使うより、自分たちがベンダと組んで一緒に企画、開発、運用を進める方が効率的かもしれない。今日の企画を来週にリリースできたら最高ではないか。小さくリリースして学びを得て改善していく。

ユーザ部門はどんどん稼いで出世してくれ。

Permalink | 記事への反応(0) | 19:20

2020-01-18

■同僚に向上心がない

タイトルの通り、同僚たちが勉強しようとしない。俺が社内勉強会的なことを主催しても盛り上がらずにお通夜状態。

別に得体の知れない知識を覚えようぜというのでなく、 AWSとか GCPとか Azureとかのむしろ現在一番流行ってる技術だ。

ちなみに今は別のクラウドサービスでサーバを借りて、そちらに会社のほぼ全システムがある。 S3や GCSも各種バックアップに使ってはいる。

それだけだと技術者として時代に乗り遅れてしまうので、せめて新機能は AWSや GCPの便利なサービス使おうぜと言ってるだけなんだが、彼らからは「得体の知れない技術を導入しようとすんな」オーラが激しい。

特に俺と年代の近い30代半ばくらいのメンバーがきつい。あからさまに嫌そうにして、勉強会では「Amazon にロックインされてない？」「Googleがいつまで続くかわからないよ？」なツッコミが恒例だ。知らんわ。

そのくせ社長や役員の前では「これからはクラウドが〜」みたいなポイント取りをする。いやお前この前までログインの仕方も知らなかったろ。

ちなみに同僚みんながこうではなく、ダメ元で新卒2年目の子に教えてみたらサーバレスでサクッとシステム作ってくれて救われた。こんど資格試験も受けるとか。こうやって味方を増やすしかないのかな？

Permalink | 記事への反応(3) | 20:49

2019-12-16

■【抄訳】【途中で力尽きました】AKSの運用に関するベスト プラクティス

はじめに

AKSの運用に関するベストプラクティス(原題: Applying best practices to Azure Kubernetes Service (AKS))がMS Igniteというイベントで話されていたので

内容をかいつまんで紹介します。

参考資料

映像

https://myignite.techcommunity.microsoft.com/sessions/81598?source=SessionDeck

ソースコード等

https://github.com/Azure/aks-bestpractices-ignite19

高可用性について

今回取り扱うのは主にワーカーノードの高可用性です

k8sにはマスターノードとワーカーノードという大きく二つのコンポーネントに分かれるが、本セッションで扱うのは主にワーカーノードです。

マスター ノードについて

コントローラプレーンの可用性は99.5%...ですが、基本的に費用がかからないのでSLO目標です。
PI サーバーがダウンした場合スケールやデプロイなど新しいマネジメントオペレーションはできない。
しかし、稼働中のアプリケーションは影響をうけない(訳注: したがってワーカーノードの方がより考慮すべき)
それでもコントローラプレーンで高可用性を確保したい場合下記の方法がある
- プレミアム SKUの採用:2019年の終わりに登場予定
- 複数クラスタの構成(副作用があるのでコントローラプレーンの冗長性確保だけを目的として実施してはいけない)

ワーカーノード

RTO(リカバリ時間目標)とRPO(目標複数時点)に応じて下記の4通りのシナリオがある

4にいくにしたがって

RTO=復旧するまでの時間が短くなる

RO=より直近の状態で復旧できる

しかし、コストや構成の複雑さは増す。

1. バックアップとリストア

2. AZ(Availability Zone)

3. リージョン内の複数のクラスタ

4. リージョン間の複数のクラスタ

バックアップとリストア

下記の通り、ステートフル環境の方がバックアップとリストアが難しい。
- ステートレスクラスタ: マニフェストファイルをデプロイしなおすだけ
- ステートフル: マニフェストファイルをデプロイして、コンポーネントの状態をさらに再構築する必要がある

どちらのクラスタにせよ、クラスタの構築は、再デプロイ処理をより早くするためにcluster deployment as code の必要がある

コードのバックアップ(スナップショット)方法

スナップショットには二つのオプションがある
- Azure Snapshot APIを使用したスナップショット
- heptio ark/vmware veleroなどのOSS プロジェクト

AZを用いた冗長性確保

17:22～

AKS クラスタはAvailability Zoneをまたいで分散ノードを作成できる
AZとはAzure regison内の個々の物理的場所
AZを利用すると99.99%の可用性
標準のAzure Disks(ストレージ)はZoneに紐づいている
Zoneをサポートするリージョンの数は限りがある
- 2019年 11月現在は10 リージョン(https://docs.microsoft.com/en-us/azure/availability-zones/az-overview )
- 日本だと東日本のみ
Zoneごとの分散処理を行うためにはStandard Load Balancer SKUが必要
- Basic SKUはZone 分散をサポートしていない

複数 クラスタ構築

23:48～

同じリージョン内に複数のクラスタを構築する方法とリージョンをまたいで複数のクラスタを構築する方法がある
データベースのR/Wをメインクラスタで行って他のクラスタでは基本的にレプリカ構成にしたデータベースでReadのみにする
- 基本的に他のクラスタではReadしかできないので機能に制限がかかる(縮退運転)
- CosmosDBを使用すればR/Wの制限なく構築できるが...(訳注: コストは一番高い)

(以下作業中)

最後に

Nofalさんごめんなさい、年末頑張って仕上げます。

Permalink | 記事への反応(0) | 23:00

2019-11-14

■なんでAppleは着脱キーボード式のMBPを作らないの

自社製品のiPadProと競合するのはわかる。

ただ、現時点でmacOSはタッチパネルにすら対応していなく、市場にまとも相手にされていないよね。このままだとmacOSは本当にどうでもいい存在になりかねない。着脱式がコモディティ化しているから避けているとは言い難い。単に技術力を投資する余裕や経営判断に欠けているんだろう。

それに、明確な思想や目的や矜恃をもっているならともなく、touchbarのESCキー復活からわかるように、妥協しか見えてこない。ライトニングケーブルが未だにある一方でUSB-CをMacには搭載する。素材のリサイクルアルミに固執して薄さを強調するのに、1kgを超えるノート PCという白黒テレビレベルにも劣る置物しか作らない。

たぶん全部がApple 信者のせい。

Apple 信者が何も考えていないことはわかりきっている。奴らはただApple マークがついていれば絶賛するだけのステマ野郎だ。使用用途も映画やTwitterくらいなので高機能なものなんていらない。だからtouchbarも喜んで褒める。

Apple 信者はMicrosoftがいま何をしているのか知っているのだろうか？Githubを買収したあたりで世界を牛耳ったも同然となり、WSL2でLinuxすら手に入れた。Azureは好調だしTSは本家を抜く勢いだ。

MSだけじゃない。Huaweiなんかアメリカに嫌われたのに最高潮だ。iPhoneを余裕で超えるスマホを見せつけられたら、アメリカやAppleがなんの強みもないって誰でもわかる。

Appleの瞑想の裏で数多くの企業が切磋琢磨しているのに、信者は未だに重いノートでステマ記事を書いている。

俺はAppleに、もっといい製品を作って欲しいだけなのに。

Permalink | 記事への反応(2) | 20:04

2019-11-11

■anond:20191111132138

エロ漫画家だけど、紺野あずれは上手いこと言ったなって思う。

紺色とAzureは結構違う色だけど同系統という意味で。

Permalink | 記事への反応(0) | 13:25

2019-08-17

■anond:20190817190833

マイクロサービスの時代にRDBMSにBLOBぶちこむ話がいまだによくあるのか…！

S3やらAzure BlobなりのStorageサービスは使わんのかな

Permalink | 記事への反応(1) | 19:19

2019-07-16

■anond:20190716184826

せやな、だから君はAzureをやるといいよ！

Permalink | 記事への反応(1) | 18:51

2019-07-10

■anond:20190710190733

Azureで動かすVMとしては、WindowsよりLinuxの割合が多いんやで

Permalink | 記事への反応(0) | 19:14

■anond:20190710182841

Azure ちゃんのことも思い出してあげて

Permalink | 記事への反応(1) | 18:31

■Microsoft のクラウドが AWS を抜いた記事を見て思うこと

日経のこの記事。

https://tech.nikkeibp.co.jp/atcl/nxt/news/18/05452/

この記事の真偽はともかくとして、反応を見てると AWS のマーケティング戦略に見事にはまった信者の人たちが冷静な見解が出来なくなって炙り出されてきているのが面白い。

AWS にもO365と同じ様な SaaS サービスあるだろうに、シェアが低すぎて普段見えてない分意識できてないんだろう。

そもそも IaaSとかSaaSを意識せずにクラウドを使える様にする、というのは AWS の根本の思想じゃなかったっけ。

ユーザーへの価値提供を忘れて、IaaSだけで勝負しろとか言ってるとそのうち Azure 単体で抜かれるぞ。

Permalink | 記事への反応(0) | 11:05

2019-06-18

■anond:20190618110146

例えば、昔よくあった、二郎のラーメンを判定する、みたいな遊びは、今時コーディングいらない。

経験値テーブル食わせて最適な値を出したいだけなら、それもAUTO MLで十分だよ

AWSでもAzureでも、データさえ用意すりゃできる

コーディングなしで使えるAUTO MLは他のことにも大量に応用できるから、いまのうちに使えるようになっておくといいよ。

ちょうどいい機会だからぜひ試すとよい

Permalink | 記事への反応(1) | 11:19

2019-06-07

■

Kubernetes the hard way on azure を終えたので研修内容をJIRAに上げようと思ったが、編集中k8s, Kubernetesの文字が違うよと赤線が引かれてうざいことこの上ない。スペルはあってるのに...

...怒りのままに、JIRAのコミュニティで聴こうとして、これChromeの機能じゃないか？とすんでで気づいた。

赤線が出てるところを右クリックすれば、辞書に追加という項目がでてwordみたいに登録できるんか。知らんかった...

でも、てめーがもともと五年前に出したソフトウェアだろ、辞書登録しとけやゴラァ、みたいに納得いかない。

Permalink | 記事への反応(0) | 15:43

■Google Stadiaの死産が無事確定した

お得意のダンピングをやらない程度の覚悟しかないってことは、xboxの「Power of the cloud」と同じようにデータセンターのリソースの空きを収益化する程度の価値しかないってことだな。

「Power of the cloud」はAzureが成長するに従って風化していったけど、これもGCPの成長と共にリソースの価値を下げる邪魔者扱いを受けて廃れていくだろう。

クラウドゲーミングって難しいよな。

コンソールを何度も買い換えなくてもいい、って言うメリットを押し出すためには比較対象となるコンソールの価格が定期的な買い換えを躊躇するほど高くないと効果が薄い。

5〜10年に5万円程度の買い換えじゃ「クラウドゲーミングじゃなくていいや」になりがち、って言うのが今までのクラウドゲーミング市場の屍が語る現実なんだけど、それを覆せるような魅力をこれから打ち出していけるのか？

他人の大博打を眺めるのは暇つぶしとしては最適だ

Permalink | 記事への反応(0) | 08:13

2019-06-01

■

スタックオーバーフローのユーザー会に行ってきた。Tシャツ目当てで。

メタな話は、正直あの界隈の人たち好きじゃないので興味なかったのだけど、

同じように一般参加した人がstackoverflowに質問した内容やそれを自己解決した経緯を聞くのは楽しかった。

エンジニアだったら、なんかの問題に躓いて、死ぬほどリファレンス読み込んで解決できなくて

神にもすがる思いで誰か…同僚だったり、SOだったり、GitHubに頼った経験はあると思う。

そこから先のアクションは千差万別だ。

同僚に事象を説明していたら、環境差分に気づいてスルスルっと解決しちゃった体験。

サンドバッグになってありがとうといつも優しい同僚に言っていたが、最近ラバーダッキングというちゃんとした名前があることを知った。

長ったらしいエラーログから特徴的な文言を抜き出して、ググった先がGithubのissueで。

英語で続くよくわからない会話についた絵文字のGJを頼りにフィックスして結局直ってねーじゃんと失望するような体験。

kubernetesを見るがいい。よくわからないbotが90日後にやってきて勝手にissueをcloseしていくぞ。

そんな中で、技術者として真だなと思うのが技術的に解決方法を自分で見つけた人。隣の人から聞いたのはそんな話だ。

macのドック(下にあるアプリケーションのローンチバー)から消したアプリアイコンが、電源入れるたびにゾンビのように復活するので調べたら

osのバージョンアップ用プロセスがdockの配置を定義している静的ファイルを操作して勝手に元に戻していたことがわかったらしい。

osのバージョンアップ用プロセスがリブートで必ず動くことへの対応は見つけられなかったけど、事象と対症療法は何とか見つかったよとのこと。

正直かっこええなと思う。

システムのアーキテクチャがわかってて深い理解があって初めて可能になるような。

こんな方法はベンダーのマニュアルにも、どの教本にも載ってはいない。しかし、可能ではある。システム全体に対する深い知識と理解と応用力があれば。

‎EGFﾏﾀﾞｰ?といつも呟いている自分は、EGコンバットでいつEMPバラージにあってもいいように備えている。

そんな中、CVE-2018-1002105 の issue を読んで kube-apiserver に詳しくなろう！

は今、「kubernetes the hard way on azure」をやってて最初のCIDRによるネットワークの分割は、lucidchartでお絵描きまでして頑張ったのに

kubeconfigファイルの作成あたりは無の境地になって、。。。はっと、なんか不安になってきた自分に強くささった。

「kube-apiserver がリバースプロキシとして動作する」こともあるというアーキテクチャの理解をベースに脆弱性情報がこうやって発展するのか...みたいな。

震えるほどかっこええなと思う。

知識の深堀のために、SOが発展していけたら。そんなことを思う。

Permalink | 記事への反応(0) | 15:46

2019-05-17

■

そもそもソニー(SIE)は現時点でプレイステーションネットワークのインフラにAWS使ってるわけで、そこにAzureも追加するかもねってだけのニュースがホッテントリしてる理由が今ひとつ分からん

Permalink | 記事への反応(0) | 12:48

Permalink | 記事への反応(4) | 19:31

2019-04-04

■anond:20190326233147

部署というか人によるって感じ

部署的にはミドル事やニフクラ方面はOSS多いのでは。

Azure、Azureうるさい
Ansible, GitLab, Mattermostあたりが微妙に流行っている
シンクライアント移行中なので自席でVirtualBox動かしにくくなった

Permalink | 記事への反応(0) | 23:06

2019-03-14

■anond:20190314100652

そうか、azure ダメになるのか。

反ワクチン迎合するわ

Permalink | 記事への反応(0) | 10:14

2019-02-21

■http://b.hatena.ne.jp/entry/4664901391481468065/comment/kagehiens

FirebaseとかAWSやAzure(や自作サービス)へのAPI経由アクセスの話じゃなくって、ブラウザ実行端末の存在するLAN内のDB サーバへの接続の話でしょうよ。そりゃTCP/IP スタック実装されていないんだから無理すぎ。

HTTPでアクセスできるDBっていっぱいあるじゃん

Permalink | 記事への反応(1) | 18:15

2019-02-11

■IT スキルをレベルアップしたいけど・・

新しい技術についていける気がしないなぁ。

サーバ構築、設計やらNW系を14年やってきて、WebもHTML、CSS、Perl、PHP、Javascriptやらやってきたけど・・

HTML5、CSS3からあまり真面に勉強しなくなったなぁ。

かと言ってオンプレ環境はどんどんと減ってAWS、Azureに変わっていくからインフラ屋にもなりきれない。

Rubyやらはとりあえず勉強したものの開発経験はないし、JAVAやらCはほとんど触らず。

Twitterではエセエンジニアばかりだし。

独立も難しいし、外資系行くにも英語はさっぱりだし。

うー・・

Permalink | 記事への反応(0) | 03:07

2019-02-03

■anond:20190203114124

AzureとAzurlane

Permalink | 記事への反応(0) | 19:34

2018-12-27

■anond:20181224023255

Intel, AMD, ARM

RedHat, SUSE, Canonical

AWS, Azure, GCP

Permalink | 記事への反応(0) | 07:16

2018-12-11

■求人に書いてあることと違うことをさせる株式会社 アイビス

株式会社アイビスは、お絵描きアプリのアイビスペイント出しています。

私は、株式会社アイビスで2年ほど働いていましたが、精神的肉体的に社会復帰できなくなってしまったので退職しました。

理由は2つあります。

1つ目は、営業の人が案件とエンジニアの技術力を考えないで、プロジェクトに任命させることです。

私は、言語としては、C++を基本的に触っていましたが、営業の方から案件がないからGo 言語でもいい？というか、それしかないからお願い、と頼まれました。案件は水ものだししょうがないよねと、営業の方自信が自分にいいきかけせている感じでした。それでプロジェクトに入りましたが、現場ではめちゃくちゃ怒られる毎日でした。そもそものお作法（変数の型宣言が後置である）も知らないからです。

このことでプロジェクトに合っていないと営業の人に言って離任を申し出ますが、うちではみんなこんな感じだから我慢してと言われるだけでした。そのまま、3ヶ月が過ぎたら10 キロ以上も痩せて、配属先の会社から離任を申し出てきました。

離任後は、自社に戻ると営業の人は、顔も合わせず次のプロジェクト先をメールで伝えるだけでした。

もちろん次も経験のないJavaとAWSの環境でインフラ設計、製造です。しかも、プロジェクト先が都内から1時間30分以上もある厚木です。対応できなくものすごく怒られ1ヶ月でお客さんから離任を告げられました。

このことで、求人に書いてあることは自分の得意な言語で仕事出来るはずじゃないですかと営業の方（採用も担当していた）に問い詰めますが、仕方ないじゃん、案件は水ものなんだしと。そんなことなら、もっと遠方に行かせるか炎上案件に行かせるよと言われました。その後も、同じような案件で数か月で終了する感じで2年続けて精神的肉体的にまいりました。

2つ目は、1つ目と似ていますが、求人内容と書いてあることが全く違います。

私は、C++でモバイルのアプリが少しつくれる程度で会社の人とチームを組んで、開発がしたいがためにこの会社に入りました。

しかし、求人内容に書いてあることとはほとんどが違います。

求人に研修では、あなたに合わせた研修とありますが、基本は放置です。

ワードのドキュメントにテトリスをつくってください。仕様は○○ですとA4の1ページにも満たない、仕様書があるだけです。更新日も5年以上前になっています。

基本誰とも話さずググって下さいと。質問してもググって下さいと言われるだけです。Redmineを使って質問ができますが、一日一回だけです。しかも、研修用で使えるPCはメモリは2GBで、2つ以上アプリを開いたら、フリーズします。

研修は、4ステップありますが、ほとんどの人がステップ1も終わらないで、現場に行くことになります。

現場に行く時は、もちろん営業としての単価がいい案件なので、炎上か高難易度の案件です。未経験の人でも大丈夫で4割が未経験でチームでプロジェクトに入りますと求人表に書いてありますが、一人で案件に行かされます。チームで行くことはたまにありますが、みな個人プレーで自社の人とは関わりません。フォローもなく、むしろ出来なかった時だけに怒鳴られます。平成終りなのに、やっていることは昭和初期の根性論のような会社です。

最後に、会社のトップの人は自社開発のアプリしかしていなく、全く経営をしていません。

例えばですが、今だに、派遣先での勤怠を自社に提出する際は紙ですし、社内システムは10年以上前のものを使用しています。

社長はめんどくさい事は、管理職に丸投げをして、暇さえあればツイッターをしているような人です。そんな暇があるならば、社内インフラを少しでも良くしてほしいですが、それも気づいてないです。

さらに、今後上場を考えています。上場したら優秀な人材が集まり、今いる人と競わせて、優秀な人だけ残すと言っているのです。社員をただのお金としてしか、考えていないので非常に残念な経営者です。

ちなみに私は、中途で入り手取り 20万円で入社しました。しかも一年目はボーナスなし。年収300万円も行かなかったです。しかし、今転職した会社では、月給は32万で、手取りは28万円になりました。やっている事は変わっていないのにです。年収も400万円までいきました。これでも、他の会社と比べたら少ない方ですが、株式会社アイビスがいかに低賃金で働かせていることか身に染みました。

エンジニアを安く買い叩かれることがないように、間違えて自分と同じようなミスをして欲しくないために今回記事を書きました。

少しでも多くのエンジニアが豊かになるために。

※色々とコメントありがとうございます。

少しだけ、追記します。

今回の記事は株式会社アイビスが都合のいい人だけ集めていること、SES（システムエンジニアサービス。エンジニアの派遣です。）に問題があることをもう少し説明します。

株式会社アイビスは、都合のいいエンジニアだけ集めて、後は切り捨てるという考えです。プロジェクトにマッチしない人でも、辛抱強く続けられる人は会社としては利益になる。優秀でなんでもできる人ならマッチしなくてもどのプロジェクトでも活躍できる人が残っている人の2パターン。仮にマッチしなくてもやめる人のケースの場合でも、責任は営業とエンジニアになりますが、実質エンジニア（話し合っても、普段話しなれていなエンジニアは、丸め込まれる。または、受け流されて、変わらないことに気付いてやめる）になる。会社としての損害はほぼなく、利益は減るが、新たなプロジェクトを探し出せることになっている。常に求人をしているので、そんなことを知らない人が同じようなループに入ります。そこで、続けられる人が見つかれば会社としてはラッキーという感じです。そして、そこに残っている人はすごい低賃金で歯を食いしばってやっている人か、ものすごい技術力がある優秀な人かの両極端になります。自分がどちらか気付いたときは、そのポジションの言動をとるようになっています。歯を食いしばるか、サクサクコードモンキーになるか。

常に求人が出されています。

https://tenshoku.mynavi.jp/jobinfo-214515-2-3-1/?ty=kyujin&src=ssS

もう一つ、SESの問題点は上記であるように派遣でプロジェクトに入るところです。チームで何かしらをつくりますが、この時に株式会社アイビスの営業、会社、エンジニア、お客さん（1次受け、2次受けで責任者が複数にいる状態）いますが、そもそもプロジェクト自体が炎上していて、失敗したら責任はお客にあり、エンジニアは地獄をみます。営業と会社は「しかたないでしょ」となります。もちろん、成功したら「よかったよかった」になります。ほとんどの場合は、微妙に燃えています。そこでカギになっているのがエンジニアの力量ですが、プロジェクトによって使う技術が決まっていないので、地頭力か歯を食いしばる力（お客は求めていないが、自社は求めている。派遣するだけで利益になるのだから）が求められる。結果的に優秀な人は、機械学習（Python）であったり、Reactであったり、クラウドの（AWS、AZURE、Google Cloud Platform）にも対応できます。お客さんもエンジニア便りになって、正しくプロジェクトが成功できるかは、優秀な人を揃えられるかどうかです。歯を食いしばったところで意味がないのに、会社というポジションでそれをやらせる会社はどうかなと思います。しかし、会社も利益を出さないいけないということで、目先のお金（SES）で稼ぐのです。