自社新卒向けメッセージ。これだけは大切にするよう伝えている 1.プロ意識 →お金が動く仕組みへの理解。行動とアウトプットの洗練さ。矜持 2.情報に関する価値認識 →情報の量と質で差をつける。周囲が求める情報を揃える 3.構想と情熱、信念 →周囲が納得するToBeを描く。打算を排除し実現しきる

管理職がリモートワークに否定的なのはリモートワークではよいこと(よいアウトプット)は「よい」と教えられるが、ダメなこと(ダメな考え方/ダメなプロセス/ダメな行動)を「ダメ」と教えられないから。結果さえ出していれば局所的な期待には達するがダメなことを学ばないと中長期の期待には応えられない

▼自己愛性モラハラ者の取扱説明書 【製品名】 自己愛性モラハラ者 【主な特徴】 ・自分の失敗は自動で消去されます ・他人の失敗は長期間保存されます ・責任が近づくと回避行動を起こします ・注目されないと機嫌が悪くなります 【使用上の注意】 ・事実を伝えると不機嫌になる場合があります ・反論すると被害者モードに切り替わることがあります ・謝罪を期待しすぎないでください ・正論は効きません 【故障かな？と思ったら】 Q. 自分のミスを認めません A. 正常動作です Q. 他人の粗探しばかりします A. 正常動作です Q. 話が毎回すり替わります A. 正常動作です Q. 被害者アピールを始めました A. 通常運転です 【天敵】 ・記録を残す人 ・冷静な人 ・事実確認をする人 ・境界線を引ける人 【保管方法】 距離を置いて保管してください。近づきすぎると、 自己肯定感が削られる恐れがあります。 【保証について】 改善を期待しても保証対象外です。 【最終的な対処法】 修理しようとしないこと。逃げる、離れる、関わらない。これが最も故障率の低い運用方法です。 📌この投稿はフィクションです。実在の人物・団体とは一切関係ありません。

対組織でもこのような行動をとる。初期は評価制度ハックや報奨制度のフル活用を行う。1年ほどは騙される。ハックが封じられ制度も出涸らしとなる中期は自己利益を最大化するよう行動する。これが2年目。後期は業務や人間関係に支障が出るため当事者意識を偽装し体制や他者批判を行い被害者振る。3年目

一見すると優秀でもこれらのモラハラタイプであることがあり本当に見極めが重要。悪口については人に対してだけでなく対案なき組織批判や批評家もどきのリスク提言なども含まれる。約束を守らない、については勤怠不良が分かりやすい。遅刻・重要書類/物品忘れを月に2回以上発生させるようであれば該当

若手メンバーの「中堅がいない」「体制が弱い」という環境への不満と実際の組織体制にギャップがある場合がある。「中堅」の定義だが、 28-34歳(経験年数5-10年前後)の人材は組織全体からすると中堅ではなくまだ見習い。若手の「中堅がいない」は「目先の都合のよい追い抜けそうな比較先がない」と同義

現場レベルの「優秀さ」の要素にはクレバーさや制度ハックによる見せかけの成果、ポージング・アピールのうまさなどが含まれる。管理者の短期視点やメンバー視点では優秀に見えるが、構造化やチーム育成観点では成果が出ていないばかりかハックによるマイナスが大きい場合がある。狡さに抗うことが重要

優秀な人から辞めていくというのは優秀さの定義次第では一理あるが、一般論として結論付けするのは無理がある。自組織に限れば抜けていった(いく)メンバーも優秀だったかもしれないが今の所属メンバーも優秀であり比較できない。強いて言えば成長ペースが加速しているため後者を優秀と証明する方が自然

超優秀な若手のエースが退職した。担っていた仕事（企画系）の難易度も高く、大幅な戦力ダウンになる、これはヤバいと誰しもが戦々恐々としていたんだけど、退職後実際は何が起きたと思う？...「何も起きなかった」んだよ。仕事は普通に回ってしまった。所詮サラリーマン1人の影響力なんてそんなもの。

ALBがあるのにNginxを置く理由、答えられる？ なんとなく置いてる人、多い。 ALBは「どのサーバーに振るか」を決める。 Nginxは「リクエストをどう処理するか」を決める。 役割が違う。 Nginxがないと困る場面： ・ヘッダの書き換え ・Basic認証 ・静的コンテンツのキャッシュ ・バックエンドとのプロトコル変換 「なんとなく構成する」人と「なぜ置くか説明できる」人、現場での評価が全然違う。 構成は、理由ごと理解する癖をつけてほしい。

AWS NetworkingのCloud WANについて ユースケースのご紹介です Route Policy便利　// 日本国内だけでも十分活用できる。Cloud WAN の便利なユースケース htts://aws.amazon.com/jp/builders-flash/202605/find-cloud-wan-use-cases/ #AWSウェブマガジン

人が退職して残されたソフトウェアは進化圧がなくなって負債化していき、ありものに置き換えられていく歴史を見ている人たちは様子を見ていると思います。なんかせっかくAIで盛り上がってるし野暮なことを言うのもなんだしなーってお気持ちの人たくさんいるはず。みんな学べば良い。

問いの設計とは、曖昧な課題を目的・制約・前提に分け、何を明らかにすれば意思決定できるかを定める力です。良い問いは仮説と検証方法を伴い、解法に飛びつく前に問題の輪郭を整え、複雑さを扱える形へ変換します。そのため、エンジニアリング以外の場面でも生きます。この観点から4冊を紹介します。

"Route 53 でのダングリング委任レコードからの保護" docs.aws.amazon.com/ja_jp/Ro…

Palo Alto Networks製品に重大な脆弱性が見つかり、防御機能の無効化やSYSTEM権限奪取が可能となる問題が発覚した。セキュリティ製品そのものが攻撃対象となり、企業環境に深刻な影響を及ぼす恐れがある。 Palo Alto Networksは3件の脆弱性を修正した。CVE-2026-0232はCortex XDR Agentに影響し、管理者権限を持つ攻撃者が保護機能を無効化できる。これによりマルウェアは検知されず活動可能となる。 CVE-2026-0233はAutonomous Digital Experience Managerの欠陥で、ローカルユーザーがSYSTEM権限で任意コードを実行できる。完全な端末支配につながる深刻な問題だ。 さらにCVE-2026-0234はCortex XSOARおよびXSIAMのTeams連携に影響し、署名検証不備により未認証でリソース改ざんが可能となる。現時点で悪用は確認されていないが、いずれも防御機構を直接無力化する性質を持つため、迅速な更新が不可欠とされる。 securityonline.info/palo-alt…

S3 Filesは革新的だが、その裏にはGoogle Driveのそれこそ革命的リリースなどがこの初夏あたりに計画されており、それに先んじて手を打ったなどの先行サプライズ感が否めない。あるいは10か月後のS3値上げなどか。いずれにせよ、この時期このタイミングでのリリースには何らかの意図があると考えられる

生成AIを使って作成した成果物の価値は自身の実力の正当性を示す適格証明書ではない。 生成AIを使って作成した成果物の瑕疵は自身の責任かつ検証内省能力欠如の証左となる。

Amazon S3 Files の発表、S3 バケットにファイルシステムとしてアクセス可能に。 S3 Files は、任意の AWS コンピューティングリソースを Amazon S3 のデータに直接接続する共有ファイルシステムを提供します。S3 ファイルにより、Amazon S3 は、フル機能で高性能なファイルシステムアクセスをデータに提供する最初で唯一のクラウドオブジェクトストアです。データが S3 を離れることなく、完全なファイルシステムセマンティクスと低レイテンシーのパフォーマンスを提供します。つまり、ファイルベースのアプリケーション、エージェント、およびチームは、すでに利用しているツールを使用して S3 データにアクセスし、ファイルシステムとして操作できるようになりました。Amazon EFS を使用して構築された S3 ファイルでは、S3 のスケーラビリティ、耐久性、費用対効果に加えて、ファイルシステムのパフォーマンスとシンプルさを実現できます。データを複製したり、オブジェクトストレージとファイルシステムストレージの間でデータを循環させたりする必要はもうありません。S3 Files はバケット内のオブジェクトを常に把握し、ユーザーに代わってファイルシステムの操作を効率的な S3 リクエストにインテリジェントに変換します。ファイルベースのアプリケーションはコードを変更せずに S3 データ上で実行され、AI エージェントはパイプライン間でメモリを保持して状態を共有し、ML チームは最初にファイルを複製したりステージングしたりせずにデータ準備ワークロードを実行します。これで、組織全体のファイルベースのツールやアプリケーションが、チームやエージェントがすでに利用しているツールを使用して、コンピューティングインスタンス、コンテナ、関数から直接 S3 データを処理できるようになりました。組織は分析データやデータレイクを S3 に保存していますが、ファイルベースのツール、エージェント、アプリケーションがそのデータを直接扱うことはこれまでありませんでした。このギャップを埋めるには、個別のファイルシステムを管理し、データを複製し、オブジェクトとファイルストレージを同期させるための複雑なパイプラインを構築する必要がありました。S3 ファイルでは、このような摩擦やオーバーヘッドが解消されます。S3 ファイルを使用すると、ファイルシステムを介して、同時に S3 API を介してデータにアクセスできます。何千ものコンピューティングリソースを同じ S3 ファイルシステムに同時に接続できるため、データを複製することなくクラスター間でアクセスを共有できます。S3 Files は S3 バケット内の新規および既存のデータをすべて処理でき、移行は不要です。S3 ファイルは使用頻度の高いデータをキャッシュして低レイテンシーでアクセスできるようにし、1 秒あたり最大数テラバイトの総読み取りスループットを提供するので、ストレージがパフォーマンスを制限することはありません。データサイロ、複雑な同期、トレードオフはありません。ファイルストレージとオブジェクトストレージを、妥協することなく 1 か所にまとめることができます。 S3 ファイルは現在 34 の AWS リージョンで一般的に利用可能です。サポートされているリージョンの全リストについては、AWS Capabilities ツールをご覧ください。詳細については、製品ページ、S3 料金ページ、ドキュメント、および AWS ニュースブログをご覧ください。 aws.amazon.com/about-aws/wha…

CloudWatchのログ取り込みコストが急増していたところだったので、こちらの記事がとても参考になった🙏 CloudWatch Logsのコストを約7割削減した話 qiita.com/ebina-kota/items/f… #Qiita

Announcing Amazon S3 Files, making S3 buckets accessible as file systems S3 Files delivers a shared file system that connects any AWS compute resource directly with your data in Amazon S3. With S3 Files, Amaz... aws.amazon.com/about-aws/wha…

出遅れたけど、試した結果をリリース。 Amazon S3 Files が GA — S3 バケットをファイルシステムとしてマウント、EFS と比較してみた dev.classmethod.jp/articles/… #DevelopersIO