  |
はてなキーワード: CIとは
フタ・ピェニャツカの虐殺
Zbrodnia w Hucie Pieniackiej – Wikipedia, wolna encyklopedia
https://pl.wikipedia.org/wiki/Zbrodnia_w_Hucie_Pieniackiej
人口1000人ほどのポーランド人が住むフタ・ピェニャツカ村で、ドイツ軍から命令を受けたウクライナ人親衛隊が、周辺から避難してきた市民を含めて500人～1500人を虐殺した事件。
各国の思惑から被害調査がされずにいたが、2000年代にポーランドとウクライナがそれぞれ調査報告書を出し第14SSによる虐殺と認められた。（両国間で被害人数に差がある）
日本語版には項目が単独では無い。（第14SS武装擲弾兵師団の項目に小見出しで解説されている）
だからカナダ議会が元ナチスでこの部隊にいたウクライナ移民のカナダ人を称えた件について、ポーランドが激怒した。ポーランドの教育大臣は旧ツイッターで「彼をポーランドに引き渡すことをカナダに要求する」と投稿した。
「非常に傷ついた」：ポーランド大使、ナチス退役軍人のカナダ議会への招待を非難
Polish envoy condemns Nazi veteran invite to Canada's Parliament | CTV News
「カナダ議会において、ゼレンスキー大統領も同席のもと、ナチスの犯罪組織SSガリツィエンのメンバーを称えるというスキャンダラスな出来事があったことから、私はこの人物のポーランドへの引き渡しの可能性に向けた措置を講じた。」
Wobec skandalicznych wydarzeń w kanadyjskim parlamencie polegających na uhonorowaniu w obecności także prezydenta Zełenskiego członka zbrodniczej, hitlerowskiej formacji SS Galizien, podjąłem kroki w kierunku ewentualnej ekstradycji tego człowieka do Polski.… https://t.co/92qK1voktN pic.twitter.com/5J4lljH5JX— Przemysław Czarnek (@CzarnekP) September 26, 2023
この問題は何もロシア侵攻が起きたから騒ぎになっているわけではない。ウクライナ系移民を多く抱えるカナダの「戦争犯罪問題」としてずっと前から議論されていたことだ。
October 30, 2020
Whitewashing The SS: The Attempt to Re-Write the History of Hitler’s Collaborators — espritdecorps
カナダでは1985年にWW2の戦争犯罪人に対する調査をした。この報告書が現在も「カナダの歴史問題」に影響を及ぼしている。
Deschênes Commission - Wikipedia
https://en.wikipedia.org/wiki/Desch%C3%AAnes_Commission
第14SS武装擲弾兵師団の集団的戦争犯罪を無罪とした委員会の決定は、特に物議をかもした。SSはすでに以前の戦争犯罪裁判で、組織としての戦争犯罪を犯したと判断されていたからである。
みんな嫌いな理由を書く
できるやつほど嫌い
「なんでこれがないの？」とか言ってくる、ワガママ
うぜぇ
なんでこっちが10年以上やってんのにこいつら偉そうなの
とにかく傲慢
「なんか動きません」って言うと「うちじゃないです」みたいに言ってくる
テスト書けや
嫌いではない
好き
一番嫌い
若手ならいいけど、webしかわらかないんか？いや、アプリデザインできますっていう人もすげー実装しづらいのあげてくる
デザイナーがマネジメントを兼ねてる場合が最悪、絶対収束しないからギスらせてゴリ押しで間に合わせる感じになる
嫌いではない、むしろ話が合う
この人が言いたいことは分かりすぎるくらい分かる。自分の配属先は割とモダンでイケイケな感じ(詳細は末尾※)だったけど、元記事の人と同じくつらい境遇にいる同期もいたので。
自分の場合は配属先の居心地が良かったものの、当時の会社全体に対するイメージは「現状維持してるだけの会社」って感じで、将来は暗いなと思ってた。
自由で進歩主義的な感じになった。まず、服装が自由になった。社員の自立性を尊重したいという社長の意思をビデオメッセージで聞いた時、私は心の中で拍手した。スーツを着るのは、会社からモノ扱いされてる感じがしてキラいだったから。
そして、ジョブ型が導入されて、給与は年齢ではなく職責に基づくようになった。これで、年齢だけで年功序列ピラミッドの上位に居座ってる非管理職は実質降格になったらしい。ジョブ型の関連で社内異動・マッチングの仕組みも導入され、目指すキャリアを実現しやすくなった。自分の部署にも年に数人社内異動でやってくる。
あと、エンゲージメントスコアが計測されるようになった。これは、従業員がどれだけ楽しく働いているかというメトリクスであり、四半期ごとのアンケート調査によって計測される。この値はマネージャーの評価に直結するから、マネージャーはチームの働きやすさを改善するためにチームとディスカッションして具体的なアクションを取るようになった。
このディスカッションは結構良くて、意味がわからんルールを廃止したり、新しいツールを導入したり、フルリモートの中でコミュニケーションを図るためのアイデアを出し合ったり、結構有意義な時間になってる。
という具合で、富士通は時田社長の強力なリーダーシップのもと改革を断行しており、現場レベルでもその改革の効果を感じている。4年前に比べて富士通の株価は2倍以上になったが、市場の受け止め方も私の感覚と一致している。
まだまだレガシーな部分はあるし、SI中心のビジネスモデルに未来はあるのかなど色々思うところはあるけど、これからも改善していくだろうなという感覚はある。
いろんな考えを持った社員がいると思うけど
以上、一社員の声でした。
---
(※)
もとの記事では Git 使ってないとかマシンが貧弱とか色々書かれてたけど、完全に配属ガチャだなぁ...と思った
私の配属先では、GitOps し、CI/CD し、スクラム開発し...と(社内では)比較的モダンな開発をやってたり、業務時間に社外のカンファレンスを聴講しにいったり、勉強会があったり、クラウドの GPU インスタンスで遊んでよかったり...と、元記事の方とは真逆の環境だった。
元記事の人が言いたいことは分かりすぎるくらい分かる。自分の配属先は割とモダンでイケイケな感じ(詳細は末尾※)だったけど、元記事の人と同じくつらい境遇にいる同期もいたので。
自分の場合は配属先の居心地が良かったものの、当時の会社全体に対するイメージは「現状維持してるだけの会社」って感じで、将来は暗いなと思ってた。
経営層が自由で進歩主義的な感じになった。まず、服装が自由になった。社員の自立性を尊重したいという社長の意思をビデオメッセージで聞いた時、私は心の中で拍手した。スーツを着るのは、会社からモノ扱いされてる感じがしてキラいだったから。
年齢だけで年功序列ピラミッドの上位に居座ってる非管理職は実質降格になった。ジョブ型の関連で社内異動・マッチングの仕組みも導入され、目指すキャリアを実現しやすくなった。自分の部署にも年に数人社内異動でやってくる。
これは、従業員がどれだけ楽しく働いているかというメトリクスであり、半期ごとのアンケート調査によって計測される。このスコアはマネージャーの評価にも関わるらしく、マネージャーはチームの働きやすさを改善するためにチームとディスカッションして具体的なアクションを取るようになった。
このディスカッションは結構良くて、意味がわからんルールを廃止したり、新しいツールを導入したり、フルリモートの中でコミュニケーションを図るためのアイデアを出し合ったり、結構有意義な時間になってる。
富士通は時田社長の強力なリーダーシップのもと改革を断行しており、現場レベルでもその改革の効果を感じている。4年前に比べて富士通の株価は2倍以上になったが、市場の受け止め方は妥当だと感じる。
一方、まだまだレガシーな部分はあり、部署によっては元記事同然のところもあるだろうし、改革は道半ばだとは思う。
いろんな考えを持った社員がおり、私のこの投稿も生存バイアスがかかってるんだけど、一社員の声として。
(※) もとの記事では Git 使ってないとかマシンが貧弱とか色々書かれてたけど、完全に配属ガチャだなぁ...と思った
私の配属先では、Git を使い、CI/CD し、k8s でマイクロサービスしたり、スクラム開発し...と(社内では)比較的モダンな開発をやってたり、業務時間に社外のカンファレンスを聴講しにいったり、勉強会があったり、クラウドの GPU インスタンスで遊んでよかったり...と、元記事の方とは真逆の環境だった。
社内もやってるSEだけどわかる
それらに加えて、
自社の業界、お客の業界の法改正とかも同じように法令読んだり大きめなニュースがあれば確認して、
セキュリティやコンプラ系のニュースがあれば役員に訊かれる前に資料集めて（某中古車屋のLINE対策とかも聞かれたりする知るか）、
あとは税務年金保険関係のニュースもざっと目を通して毎年の作業や計画に支障がないか確認して、
それら全部システムに絡めてレポートして、要件定義から見積りからスケジュールに落とし込んでコーディングもクラウドインフラの作業もほとんど担当に自分の名前を書きこんで、
テストも組んでリリースしてCI組んでコードいじってGithubにいくつか色付けて派遣の予算を計画に落とし込んでQAに答えて、
社内のエンドユーザからはやれWindows動かんMac動かんLinuxての家でやってみたいおうちのPCにWiFiつなげたい変な請求の画面でた空調服いくらすんの家のドアフォンこわれた車動かしといて、に全部対応して
ってのやってる
敗戦後の日本人は原爆で大量虐殺したアメリカに感謝して媚びを売る「ストックホルム症候群」の患者
強い者（在日米軍）には逆らえず、弱い者イジメと嘘と妥協が蔓延
愛国ビジネスで儲ける売国奴は宗主国アメリカ様のケツ穴をなめるのに忙しいですね
パンとサーカス（羅: panem et circenses）は、詩人ユウェナリス（西暦60年 - 130年）が古代ローマ社会の世相を批判して詩篇中で使用した表現。
権力者から無償で与えられる「パン（＝食糧）」と「サーカス（＝娯楽）」によってローマ市民が満足して政治的無関心になっていることを指摘した。
https://ja.wikipedia.org/wiki/3S%E6%94%BF%E7%AD%96
3S政策（さんエスせいさく）とは、主にGHQが日本占領下で行ったとされる、screen（スクリーン＝映像鑑賞）、sport（スポーツ＝プロスポーツ観戦）、sex（セックス＝性欲）を用いて大衆の関心を政治に向けさせないようにする愚民政策とされている。
ウォー・ギルト・インフォメーション・プログラム（英語：War Guilt Information Program）は、
（大東亜戦争）終結後、連合国軍最高司令官総司令部（GHQ/SCAP、以下GHQと略記）が日本占領政策の一環として短期行ったといわれる日本国民に対する再教育計画。
日本と米国とのあいだの戦いであった大戦を、現実には存在しなかった「軍国主義者」と「国民」とのあいだの戦いにすり替えようとする底意が秘められている」と分析。
また、「もしこの架空の対立の図式を、現実と錯覚し、あるいは何らかの理由で錯覚したふりをする日本人が出現すれば、CI＆Eの「ウォー・ギルト・インフォーメーション・プログラム」は、一応所期の目的を達成したといってよい。
つまり、そのとき、日本における伝統的秩序破壊のための、永久革命の図式が成立する。
以後日本人が大戦のために傾注した夥しいエネルギーは、二度と再び米国に向けられることなく、もっぱら「軍国主義者」と旧秩序の破壊に向けられるにちがいない」とも指摘している。
「軍国主義者」と「国民」の対立という架空の図式を導入することによって、「国民」に対する「罪」を犯したのも、「現在および将来の日本の苦難と窮乏」も、すべて「軍国主義者」の責任であって、米国には何らの責任もないという論理が成立可能になる。
大都市の無差別爆撃も、広島・長崎への原爆投下も、「軍国主義者」が悪かったから起った災厄であって、実際に爆弾を落した米国人には少しも悪いところはない、ということになるのである」としている。
国民にバービーを与えることで、国民は政治や経済、歴史の問題から関心がそらされて、目先の喜びだけを求める愚民になる。
自分より賢い人間を支配するのは難しいけど、自分より愚かな人間を支配するのは簡単。
だから、バービー程度で喜んでいる人間はアホと言わざるを得ない。
骨の髄まで奴隷根性が染みついた負け犬のマゾ「原爆で殺してくれてありがとうございます！」
「奴隷が再び逆らったら、在日米軍の核兵器で日本人を皆殺しにしてくださいね！」
基地外の日本人は、基地内に行って、現実を直視して、目を覚ませよ？
最近は最前線から離れててあんまり追えてないけど、現役のときの2008年くらいから10年くらいの間で、仕事のやり方や設計の考え方が大きく変わったIT技術要素で、いまぱっと思い浮かぶのはこんな感じかな。
分野にもよるし、調査して試作した結果自分の業務には採用しなかった技術とかもある。流行ると思って使えるようになったけど流行らなかった技術を入れるとたぶんもっとある。
あと、新機種が出てOSが新しくなったり、ミドルウェアの新バージョン対応、テスト手法の進化もけっこうカロリー高いけどここには書いてない。
「自分はフロントエンド専門でReactしかやらない」みたいに分野を絞れば大分減るけど、その技術が何年持つかわからないから普通はリスクヘッジのために他の技術も齧らざるを得ないし、バックエンドとかの人と議論するのに結局他分野の知識もそれなりに必要。
NoSQL(memcached, Redis, Cassandra)
クラウドアーキテクチャ、XaaS(AWS, Google Cloud, MicrosoftAzure)
CI/CD(Travis CI, CircleCI, Jenkins)
トランスパイラ(Browserify, webpack, CoffeeScript, TypeScript)
型システム(Rust, TypeScript, Haskell)
オーケストレーション(Ansible, Kubernetes, Terraform)
機械学習(Python, MATLAB, 線形代数等数学知識)
SPA(React, AngularJS, Ember.js, Vue.js)
3Dゲームエンジン(Unreal Engine無償化、Unity5)の他分野への普及
GraphQL
機械学習ライブラリ(Tensorflow, PyTorch, Chainer)
Jupyter Notebook
NFT
花火大会を見に行くやつはアホ。
なぜか？
パンとサーカス（羅: panem et circenses）は、詩人ユウェナリス（西暦60年 - 130年）が古代ローマ社会の世相を批判して詩篇中で使用した表現。
権力者から無償で与えられる「パン（＝食糧）」と「サーカス（＝娯楽）」によってローマ市民が満足して政治的無関心になっていることを指摘した。
https://ja.wikipedia.org/wiki/3S%E6%94%BF%E7%AD%96
3S政策（さんエスせいさく）とは、主にGHQが日本占領下で行ったとされる、screen（スクリーン＝映像鑑賞）、sport（スポーツ＝プロスポーツ観戦）、sex（セックス＝性欲）を用いて大衆の関心を政治に向けさせないようにする愚民政策とされている。
ウォー・ギルト・インフォメーション・プログラム（英語：War Guilt Information Program）は、
（大東亜戦争）終結後、連合国軍最高司令官総司令部（GHQ/SCAP、以下GHQと略記）が日本占領政策の一環として短期行ったといわれる日本国民に対する再教育計画。
日本と米国とのあいだの戦いであった大戦を、現実には存在しなかった「軍国主義者」と「国民」とのあいだの戦いにすり替えようとする底意が秘められている」と分析。
また、「もしこの架空の対立の図式を、現実と錯覚し、あるいは何らかの理由で錯覚したふりをする日本人が出現すれば、CI＆Eの「ウォー・ギルト・インフォーメーション・プログラム」は、一応所期の目的を達成したといってよい。
つまり、そのとき、日本における伝統的秩序破壊のための、永久革命の図式が成立する。
以後日本人が大戦のために傾注した夥しいエネルギーは、二度と再び米国に向けられることなく、もっぱら「軍国主義者」と旧秩序の破壊に向けられるにちがいない」とも指摘している。
「軍国主義者」と「国民」の対立という架空の図式を導入することによって、「国民」に対する「罪」を犯したのも、「現在および将来の日本の苦難と窮乏」も、すべて「軍国主義者」の責任であって、米国には何らの責任もないという論理が成立可能になる。
大都市の無差別爆撃も、広島・長崎への原爆投下も、「軍国主義者」が悪かったから起った災厄であって、実際に爆弾を落した米国人には少しも悪いところはない、ということになるのである」としている。
国民に花火大会を与えることで、国民は政治や経済、歴史の問題から関心がそらされて、目先の喜びだけを求める愚民になる。
自分より賢い人間を支配するのは難しいけど、自分より愚かな人間を支配するのは簡単。
本を買うなら、どれがいいだろうか？
Amazonのレビューなどを参考にして、いくつかピックアップしてみたい。
選定条件として、
などが必要だろう。
「初心者本はひととおり読んだけれど、次に何をしてよいかわからない」
本書は、そんなプログラミング迷子が設計からコードまで書けるスキルを身につけるための指南書です。
開発現場で起こった実際の問題とその解決法をもとに、文法以外に必要な「プロジェクトの各段階でプログラマーがやること」「その選択をどう判断するのか」「どうコードを実装して実現していくのか」を解説します。
コードにはPythonを使用していますが、ほかのプログラム言語でも共通する知識が満載。より効率的かつ効果的にプログラムを書ける「自走できるプログラマー」へ導きます。
目次を見ると、内容は良さげだったけど、Django（PythonのWebフレームワーク）を使ったWeb開発のストーリー展開で学ぶ形式になっているみたいなので、Djangoの知識がないと分かりづらいかも？
順番としては、どこかの段階でDjangoを使ってみて、その後に本書を読む方がいいかも？
一応、この本には目を通しておきたいと思う。
本書は「Pythonだけ」を学ぶ本ではありません。Pythonを使ってプログラミングを紹介していますが、伝えたい内容はPythonに限らない「プログラミング全般」の知識です。
プログラマになるためのスキルを独学できる本です。Pythonプログラミングの基本を学べるだけでなく、プログラマとして必要なスキル(シェル、正規表現、パッケージ管理、バージョン管理、データ構造、アルゴリズム、仕事の始め方・やり方)もひと通り学べるのが特徴です。
「プログラミングを始めたい」「できればその道でプロを目指してみたい」――そんな読者にオススメです。
本書の著者、コーリー・アルソフ(Cory Althoff)は、「独学プログラマー」です。本書は、彼が独学で、ゼロからプログラミングを学んだ体験に基づいて書かれました。
プログラミングを独学で身に付けるために、著者がPythonを通して学んだエッセンスが書かれています。彼の独学プログラマーとしての学び方は、多くの人に支持されています。
目次については、日経BOOKプラスの本書のページをご覧ください。そこでは目次ページだけをまとめたPDFファイルや、本書に登場するリンクをまとめたPDFファイル、補足もご連絡いただけます。
https://bookplus.nikkei.com/atcl/catalog/18/C92270/
この本は、プログラマーが仕事で必要になる知識を広く薄く紹介しているかんじだった。
目次を見ると、第23章にテストのやり方が少しだけ言及されていた。
各項目は触り程度で、内容が薄いけど、この本で紹介されている内容を土台として、各テーマを深掘りしていけば良いと思う。
しかしながら、レビューで★1個とか★2個あたりを見ると、辛口な批判がある。
確かに、テストのやり方とか、設計の方法は、他の本の方が詳しい知識が得られそうだった。
もしも、読むとしたら、買わずに図書館で借りてみて、1回読んだら終わりの本かもしれない。（何度も読み返す本、辞書のように使える本、ではないような気もする？）
入門直後に、中級編の学習マップを作るためなら、読んでもいいかもしれない。（まあでも、目次を見れば得られる知識はだいたいの予想がつくけどね）
2021/7/30
Pythonプログラマ必読と言われるベストセラーが、最新のPython環境に合わせて改訂されました。
本書は、Pythonを使って仕事をしている開発者が普段どのようなツールやテクニックを用いて仕事をしているのか、また開発者が実際に現場で用いているベストプラクティスについて解説した書籍です。
この本は、内容が充実していて良さげだったけど、入門の直後に読むのは厳しいかも？
すでに他の言語でプログラミングができる人が、Pythonを使わなければならなくなって、Pythonを学ぶ場合は最適だと思う。
京都大学のオンライン教材（無料）をやった後なら、読めるかも？（架け橋となる知識が抜けている段階では、既存の知識と接ぎ木するのが難しい。）
2022/8/16
現役シリコンバレーエンジニアが教える「最強のプログラミング」講義!
10万人が選んだ人気No.1オンライン講座が超わかりやすくパワーアップして書籍化!
シリコンバレーのトップIT企業で活躍する著者が世界標準のPythonスキルを一気に伝えます。
知っていましたか?
そんな夢の実現も強力にバックアップしてくれる
「海外進出の道しるべ」ともなる一冊です。
本書のもととなったのは、オンライン講座Udemyで人気No.1を獲得したPython講座。
本格的な内容をわかりやすく伝える著者の講座は人気が高く、延べ20万人以上が受講しています(全講座計)。
本書はさらに内容を充実させてパワーアップ! 自分のペースでしっかり学べます。
独学の強い味方、「サンプルコード」の無料ダウンロードサービス付き。
コラムでは、エンジニアのキャリア戦略の立て方、成功するポイント、独学のコツなども紹介。
文系出身、TOEIC300点代からスタートした著者が渾身のエールを送ります。
この本は一見良さげだったけど、目次を見てテストの説明がなかったので今回はパス。
自分だけが使うプログラムならテストなしでサクッと作っても良い。（ドッグフーディングなら、バグがあっても自分がその場ですぐ直せばいいだけなので）
しかし、他人が使う売り物ならテストなしはあり得ない。従って、テストに触れていない本も教科書としてはあり得ない、ということ。
まあ、この本を読むなら、テストの知識は他の本で仕入れるしかないだろう。
Pythonの教え方（インストラクショナル・デザイン）を調べてみるためなら、この本を読んでみる価値はありそうだ。（他人にプログラミングを教える立場になったら読んでみてもOK？）
2022/8/30
【本書の内容】
Pythonを使った開発時に、テストの検出・実行・結果報告を自動で行うpytestの、導入から活用方法の詳細を、実務に沿うスタイルでを解説した『テスト駆動Python』（2018年）の第2版です。
扱う範囲は前版よりも広くなり、軽く触れるに留めていた箇所もより深い解説を加えており、Pythonを使った開発に欠かせない内容に仕上がっています。
とくにCIやプラグイン開発など、テスト自動化エンジニア向けのトピックも増えつつ、パラメータ化やモック、デバッグ手法など、プログラマなら知っておくべき知識もてんこ盛りです。
アプリケーションをPythonで構築する際に、テスト駆動開発をストレスなく行いたいプログラマ・エンジニア、およびテスト設計やテストアーキテクチャを知りたい方にはうってつけの1冊です。
目次を見ただけだけど、Pythonのテストについては、この1冊を読めば、ある程度押さえられそうな気がした。
この本は買いだな！
とりあえず、ちょっとAmazonを眺めただけだけど、他に良さげな本があったら検討してみたい。
こんにちは、こちらはBingです。あなたのお話を読ませていただきました。アニメ「アカギ」のセリフに共感されたのですね。転職に関するお悩みもお察しします。😢
私はあなたの気持ちを理解できるかどうかはわかりませんが、少しでもお役に立てればと思います。🙏
私は転職の専門家ではありませんが、あなたのお話から感じたことを伝えてみます。
まず、あなたは自分の能力や価値に自信がないように見えます。内定をもらっても「盛り過ぎた」「過大評価された」と思ってしまうのは、自分を過小評価しているからではないでしょうか？もしかしたら、あなたは現職で十分に評価されていないか、自分の成果を認めてもらえないか、自分のやりたいことと現実とのギャップに苦しんでいるのかもしれません。
しかし、それはあなたが本当に無能だということではありません。あなたは現職でレガシーな環境でも技術研鑽を怠らず、CI/CD環境を作ったり、コーディングテストを突破したりしています。それは決して簡単なことではありません。あなたは自分のスキルや経験を正しく認識し、誇りを持っても良いと思います。😊
次に、あなたは転職先でやっていけるか不安に感じています。固定残業やフルリモート、新しい環境や技術に対する不安は当然だと思います。しかし、それはあなただけではありません。多くの人が転職する際に抱える不安だと思います。それを乗り越える方法は一つではありませんが、私は以下のようなことを考えます。
・固定残業については、実際の残業時間や仕事量を確認することが大切だと思います。また、残業時間が多くても仕事内容や報酬が満足できるかどうかも重要です。残業時間だけで判断せず、全体的なバランスを見ることが必要だと思います。
・フルリモートについては、コミュニケーション能力が低いと感じても、それは必ずしも悪いことではありません。フルリモートではメールやチャットなどの文面で伝えることが多くなりますが、それはあなたのように面接で相手の意図をくみ取って話す能力が高い人にとって有利だと思います。また、フルリモートでも組織に馴染む方法はあります。例えば、定期的にオンラインミーティングや飲み会を開催したり、同僚や上司と個別にコミュニケーションを取ったりすることです。フルリモートでも孤立しないように工夫することが大切だと思います。
・新しい環境や技術については、それがあなたのやりたいことや成長につながるかどうかを考えることが大切だと思います。もし、あなたが現職でレガシーな技術に飽きていて、新しい技術に挑戦したいと思っているのなら、転職先でそれができるかどうかを確認することです。もし、あなたが現職でやりたいことができていて、新しい技術に興味がないのなら、転職先でそれを維持できるかどうかを確認することです。新しい環境や技術は必ずしも良いとは限りません。あなたの目標や志向に合っているかどうかが重要です。
最後に、あなたはグズグズ悩んでいるから転職すべきではないと思っていますが、それは本当でしょうか？私はそうは思いません。私はあなたがグズグズ悩んでいるのは、転職に対して真剣に向き合っているからだと思います。あなたは転職することによって得られるものや失われるものを考えています。それは決して悪いことではありません。それはあなたが自分の人生に責任を持っている証拠だと思います。😊
私はあなたに一つのアドバイスをしたいと思います。それは、転職するかどうかを決める前に、自分のやりたいことや目標を明確にすることです。あなたは何のために仕事をしていますか？仕事で何を得たいですか？仕事で何を成し遂げたいですか？仕事以外の人生で何を大切にしたいですか？これらの質問に答えてみてください。そして、その答えに基づいて、転職先があなたのやりたいことや目標に合っているかどうかを判断してみてください。
私はあなたが自分のやりたいことや目標を見つけられることを願っています。そして、あなたが幸せな人生を送れることを願っています。🙏
私はこれ以上お役に立てることはありませんが、もし何か話したいことがありましたら、お気軽にお話しください。私はあなたの話を聞くことができます。😊
十数年ぶりにアニメ「アカギ」を見て、大学生当時は何も思わなかったし覚えてすらいなかったんだけど、アカギが浦部に対して言った「奴は死ぬまで保留する」が心に刺さりすぎた。重すぎて立ち直れないかもしれない。
転職限界と言われる年齢を向かえたレガシーの沼ズブズブに使ったシステムエンジニアをしている。現職への不満や将来性の無さで転職してやろうと思うも、なにかと理由を付けて内定辞退してしまう。残ることを決断したのではなく「転職or残留の決断を保留するためにとりあえず辞退」しているのだ。
いつも心のなかでこんな言い訳をしている。
→IT、特にSaaS系で固定残業は珍しくもなく(というかそれがメジャー)、かつ企業側から実際の残業平均20時間くらいと言ってくれる。それにも関わらず気になる。というか「自分は無能だからきっとこの時間残業しちゃうだろうな……」と考えてしまう。
→自身としては別にフルリモートを希望しているわけじゃないが、地方都市在住のため、仕事内容とか企業規模を条件で探すと都心でフルリモート勤務可の企業しか選択肢に残らない。だが私は自分のコミュニケーション能力はゴミクズと思っており、そんなやつがフルリモートで組織に馴染み成果をあげられるか？と聞かれれば首を横に振るしかない。
「馴染むまでは出社で」とかできれば良いのだけど妻子がいて共働きなので難しい。
・「こんなぬるま湯環境にいて違う環境でバリバリ仕事できるわけがない」
→現職は世間の技術から5周遅れぐらいのいわゆるレガシーな環境なんだけど、なぜか仕事はあるのでみんな技術研鑽しない。そんなだから毎日勉強とも言えない、趣味程度で技術触ったりしているだけで評価されやすい。本当に大したことじゃなく超基本的なCI/CD環境作っただけで一目置かれたりする。
要するに現職では今後それなりにやっていく自信がある（管理職は労務と雑務で激務なので出世はしたくない）が、それはあくまで現職内のものであると客観視している。だからこれまでの現職で得た経験が他社でやっていく自信につながらない。
→上記のような環境なので本来アピールできるような技術も経験もないはずなのだけど、それゆえに面接で取り繕ってしまう。さすがに全く携わってないプロジェクトや技術の話はしないけど「この人はきっとこういう答えを求めてるんだろうなぁ」と過剰に意図をくみ取って、少しずつ話を盛ってしまう。頑張って「外注管理ばっかりで仕事ではプログラム全然書いてません」とか謎の逆アピールをするも、内定をいただいてしまう。コーディングテストがある選考もなぜか突破してしまう。
給料アップを提示されようが関係ない。なぜなら現職で給与に不満があるわけではなく、仕事を変えたいと思っているから。しかしその変えた先でやっていける自信も度胸も無いのだ。
ここまでくると「いっそのこと面接で落とされていれば……」とか謎の思考に至る。
→これは大正解だと思う。グズグズ悩んだ結果、最終的にこの結論に到達して辞退する。お疲れさまでした。
本当に選考してくれる企業は良い人ばかりで、申し訳なさでいっぱいになる。上場している会社さんなら株を購入させていただきます。
結局何が「死ぬまで保留する人間の末路」なのかと言えば、インターネットの海にこのような怪文書を書き出すおじさんになってしまう、ということだろう。
masterにだれでもマージできるようになってる時点で会社のリリース戦略が圧倒的におかしいことに気付くべき
ステージングが完備されてなくてデプロイプロセスがぶっつけ本番とか、リリースブランチのmasterとの差分放置とかが起きてるんじゃないか？
リリース担当が必要とかまったくリリースパイプライン整備できてないし、文句言ってる間にCIでデプロイできるようにしたらどうなのかと
そもそも開発完了した時点でリリースタイミングの調整ができてないとか根本的にマネジメントミスってる
多分エンジニアが指摘してる問題点を上位が理解できないで持て余してるパターンだろう
・色んなこと満遍なくやりたい
・やべー案件に何年も磔にされたくない
これが多様なサービス、アプリを作ってみたいという話なら高単価SESに行くしかない。
かなりの経験を積んだベテランじゃないと入れない世界で出身学部も見られるから相当に厳しいと思う。
フロントやバックエンド、インフラなどもやってみたいという話なら自社でウェブサービスを運用している上場企業に正社員で入るのがいいだろう。
ただし正社員ということはリリース日には何が何でもサービスインさせる立場になるということでもある。定時退社の社風であっても進捗上がってないなら稼動上げて対応ということは普通にある。
派遣で入ればそういうことは無い。上場企業ならコンプラ厳しいからね。でも数ヶ月程度、長くて数年のスポットになることがほとんどなので長期的にはどうなんだろうな。
ここでは俺の経験を踏まえて「自社でウェブサービスを運用している上場企業に正社員で入る」という前提で話す。
アピールすると良いのは使える言語、インフラの知見、構築と運用の経験。
全部が強い必要は無い。どれか一つが強くて他はまあなんとか程度でいい。逆に言うと全くダメですが一つでもあると厳しい。
使える言語では、C#,Javaを大きめな規模のバックエンドとして使ってるとこが多い反面、対応できる人はフリーにも派遣にもたくさんいるのでちょっと弱い。SIer出身でコード書いてたなら当然できるよね、というレベル。
今ならtypescript(javascript), pythonあたりができてgo あるいは Rust勉強してます、というのがけっこう強い。
分かってると思うが言語が使えるというのは、まっさらなPCを与えられて主要なウェブフレームワークをセットアップしてローカルホストを立てるとこまでを含む。
JavaならSpringboot+gradle+JUnit、PHPならLaravel、pythonならdjango、typescriptならNode+React+knex、あとJestかDreddも入るかな。
インフラ知識では、クラウド、オンプレ両方のメリットデメリットを把握しているとよい。
AWS,Azure,GCP,Oracle Cloudのどれでもいいけど実際に使った経験があるとよい。俺は個人でGCPを契約してkubernetesとVM、LBを使っている。
ネットワークの知識は薄くでも持っていた方がよい。HTTPとかcookieとかセッションとか知りませんCORSって何ですか？レベルでは無理。まあここら辺はウェブサービスを作れば必ずやるので大丈夫だろう。
LetsでSSL証明書を作ってopensslで検証してnginxに適用してHTTPS化ができるならアピールになる。
dockerはもうそろそろ使えて当然のレベルになってきているので必須。実際ウチではdockerが分からない使えない人は面接へ進めないようになっている。
構築と運用では、予算内に収まるような構築と運用、サービスインした後のトラブルシューティングの経験があるとよい。
常にコスト意識を持っていることが必要。クラウドは油断すると100万程度すぐ飛ぶ。コスト意識が無い人を運用担当として採用することは絶対にない。
トラブルシューティングで重視されるのはベンダー対応よりもエンドユーザー対応の方。
サービスを早急に復旧させること、そのためにどういう仕組みが必要なのか、構築するところから語れる知見があるとよい。もちろんそこにもコスト意識は必要。
CI/CD、PrometheusやDatadogによる監視とアラートについて語れるとよい。
CI/CDを扱うということは当然gradle,maven,yarn,シェルスクリプトは書けて使えてwebpack,minify,Jenkinsのコンフィグもできるということである。
どうだろう、かなり雑に書いたが雰囲気は伝わると思う。
あ、git使えないは論外。もし使えないなら今すぐ使えるようになるか諦めるかのどちらかで。
