「死ぬまでに観るべき映画」なんて手垢のついたテーマだと分かってる。 でもググって出てくるランキングは判で押したように無難な名作揃いで、正直あくびが出る。 だから今回は、年間100本以上を劇場で観続けてきた人間として、無難さを捨てて選んだ。 基準はひとつ。「観る前と観た後で、世界の見え方が変わるかどうか」。それだけ。 異論は認める。というか歓迎する。 「これが入ってないのはおかしい」というやつがあれば、ブコメで殴り込んできてほしい。 それも含めて映画の楽しみ方だと思ってる。 『ショーシャンクの空に(1994/フランク・ダラボン)』 あらすじ：妻殺しの冤罪で終身刑となった銀行員アンディが、劣悪な刑務所で生き抜こうとする。 観るべき理由：希望とは何か、尊厳とは何か。 人生のどん底で心を折らない方法を、理屈じゃなく体で理解できる一本。 『ファイト・クラブ(1999/デヴィッド・フィンチャー)』 あ

この記事は毎週必ず記事がでるテックブログ Loglass Tech Blog Sprint の153週目の記事です！ 3年間連続達成まで残り6週となりました！ こんにちは、ログラスの飯田(@ysk_118)です。 ここ数年、AIによってコードを書く速度はずいぶん上がりました。一方で、「品質向上に対してどのようにアプローチしていくのか」という問いも、多くの現場で同時に立ち上がっているように思います。 AIによる開発現場の進化の渦中において、エンジニアリングマネージャーはどう変化すべきなのか？品質にとどまらずさまざまな観点でアップデートが求められていると感じていますが、まずは直近で取り組んだ品質KPIの可視化についてお話しします。 ソフトウェアの品質は、外部品質・内部品質・プロセス品質・利用時の品質などに整理できます。本記事が扱うのはこのうち外部品質、なかでもインシデントに関する品質です。「A

2026/7/16に、Developers Summit 2026 Summerで発表した黒田の資料になります。

依頼文化をやめる日 EM視点で語るPlatform EngineeringとInclusive SRE / Discussing Platform Engineering and Inclusive SRE from an EM's Perspective

みんな東京の地雷飲食店を避けたいみたいだから、 年間300食、外食してる俺が説明するよ。当たり前の事しか書いてないので初心者向けね。 <入口の基礎知識> 以下の店は適当にふらっと入ってはいけない。都民の基礎知識 ・渋谷、新宿、池袋のチェーンっぽいけど、チェーンじゃない店：大手チェーンをパクった謎ぼったくり店 ・キャッチ：売上の１割がキャッチに入る構造。その原資は料理や酒の原材料から払われる。 ・食べ放題の居酒屋：大食いされても負けない原価設定。東京の家賃と日本人の人件費抜いて食べ放題にするには、原価計算すればわかる。 （食べ放題は中華系、インネパ系は比較的ガチの地雷は少なめ。美味しくないは普通にあるが。） ・看板に飲み放題：料理の味は最低ランク ・肉寿司：酢飯に肉の切れ端を乗せれば嘘にならない、魔法のキャッチコピー。 ・黒毛和牛：素材情報の粒度が荒い。 ・店名に創作、九州：地雷の和食店。ち

“ID沼入口” - 基本とセキュリティから始める、考え続けるためのID管理技術勉強会 で発表を行う資料です。 現在作成中のため、変更のある可能性があります。 https://openid.connpass.com/event/396041/

1. はじめに こんにちは、権限管理基盤チームで PdM をしている sentokun と申します。 私は基盤チームの立場でよくプロダクトチームから権限設計に関する相談を受けるのですが、実際にやっている内容に立ち返ると、それは業務フローとユーザーストーリーの整理に通じると感じています。 この記事では、権限設計という複雑そうなタスクの「よくあるパターン」を通して、業務フローとユーザーストーリーの重要性について共有します。 TL;DR 権限設計を考える際には、以下の2ステップが必要です。 業務フローとユーザーストーリーを整理する（2章） 「誰が、どんな立場で、何をするか」を具体化する 3つの深掘りポイントで解像度を上げる（3章） 立場・条件・データの境界を明確にする とはいえ、何から手をつけたらいいかわからない！という方は、4つのきっかけから深掘りをしてみてください（4章）。 2. 目指すゴー

ベストプラクティスは、エージェントを縛るためではなく、速さの方向を正しく保つ ためのものだ。 1. 検証可能な要求（Verifiable Requirements） 原則: 「いい感じ」「適当に」は要求ではない。完了は コマンドか観測可能な状態 で定義する。 エージェント時代: 自然言語の依頼は実装に変換されやすいが、完了条件 は変換されにくい。Done を書かないと、エージェントは実装完了と検証完了を同一視する。 repo への落とし方: MILSPEC 規律記事 の Done テンプレと同型。 2. 小さく、理由を1つに（Small, Single-Purpose Changes） 原則: 1 PR・1 コミット・1 セッションに 理由は1つ。レビュー可能な diff は、チーム規模に関係なく正義。 エージェント時代: 周辺コードを読んだエージェントは、ついでに format・rena

ちょっと長くなっちゃったので要約するとこんなかんじです 技術広報の成果は測りにくい。だからマネージャーも評価に悩む 3つの軸（外部へのアウトプット、内部のコミュニケーション、仕組み化）を定量と定性でバランスよく見て、同時に回すことが基本 3つの軸が高いレベルで回ると自動的に業界への影響力が生まれ、それがキャリアアップの基準になる では本文です。 技術広報のメンバーとして懸命に働いていても、評価時期に書く自己評価シートをどう書けばいいのかわからない時ってありませんか？「この仕事をどう点数にすればいいのか」って難しいですよね。 技術広報という職種や役割が認知されるようになって数年ほどしか経っていないこともあり、業界的に「技術広報の成果とはこれだ」という定義がありません。1年2年と経つうちに「成果が見えにくい活動」と判断され、部門ごと無くなってしまうこともある。 わたしは18年間、技術広報として

2026年5月31日、嵐のラストライブ「ARASHI LIVE TOUR 2026『We are ARASHI』」東京ドーム最終公演が生配信され、約3時間・全33曲を最後まで届けきりました。配信中は世界トレンド1位を独占するほどの注目を集め、ネット上では「大規模なサーバーダウンが起きなかったのは凄い」という声が広がっています。 事前には「5月31日、日本中の回線が悲鳴を上げる」といった半ば祭りのような前評判があり、報道でも「サーバー落ち」を懸念する声が取り上げられていました。それだけの規模が予想されながら、配信全体が崩れる大規模障害は報告されませんでした。 この「落ちなかった」という事実を、ネットワークエンジニア（以下、NE）の視点で分解すると、何が技術的に難しく、何が効いたのかが見えてきます。本記事では大規模ライブ配信の仕組みを、当日の状況と照らし合わせながら整理していきます。 まず「落

最近のサプライチェーンアタックを見ていると、これまでとは明らかにフェーズが変わったと感じています。 この記事は、具体的な解決策を提示するというより、最近のサプライチェーン攻撃を見て、自分が開発環境やCI/CDについて考えていることを整理したものです。 以前の攻撃は、どちらかというとコンピュータリテラシーがそこまで高くない人を狙うものが多かったと思います。怪しいメールを開かせる、怪しい添付ファイルを実行させる、偽サイトに認証情報を入力させる、というようなものです。もちろんそれらも深刻ではありますが、少なくとも「気をつける」という個人の努力である程度防げる余地がありました。 しかし最近の攻撃は、明確に開発者を狙っています。 開発者は、一般的な業務利用者よりも強い権限を持っていることが多いです。GitHub token、npm token、SSH key、cloud credentialなどを持

ソフトウェア開発の方法論は、「ウォーターフォールか、アジャイルか」の二択で語られることが多いが、これは解像度が低い。本当は別々に決めなければならない論点が複数まとまっている。 table:table 論点 選択肢 開発ライフサイクル 予測型 / 適応型 固定するプロジェクト変数 スコープ固定 / コスト固定 デリバリーケイデンス 単一 / 複数 / 定期 効率パラダイム リソース効率 / フロー効率 「ウォーターフォール」「アジャイル」という手法名は、この4つの論点をまとめて選んだ結果のラベルでしかない。決めるべきは手法名ではなく、4つの論点それぞれに自分のプロジェクトでどう答えるかである。 手法名は複数の判断をまとめてしまう ウォーターフォールは典型的には予測型の開発ライフサイクルである。作るものを一定程度予測できることを前提にし、スコープを定義し、スケジュールやコストを見積もり、計画に

はじめに 2026年1月、Charity Majors が Honeycomb のブログに一本の記事を投げ込んだ。タイトルは "You Had One Job": Why Twenty Years of DevOps Has Failed to Do it。彼女はこのテーマを、書籍 Observability Engineering 第2版(O'Reilly Early Release)でも詳しく展開している。本稿では両者から引用する。 冒頭の一文はこうだ。 I think the entire DevOps movement was a mighty, twenty year battle to achieve one thing: a single feedback loop connecting devs with prod. On those grounds, it failed.

午前8:00 「夜の仕事」を確認する 起床してベッドの中で最初に開くのは、Slackでもメールでもなく、自分専用のエージェントダッシュボードだ。 昨日の終業時に5つのタスクを走らせて帰った。それぞれに「夜のうちにこのゴールまで進めてくれ」と指示しておいた。 先週リリースした検索機能のp95レイテンシ悪化の原因経路が特定されていること カスタマーサクセスから上がった71件のフィードバックがテーマ別に整理されていること 競合の新機能を踏まえた自社プロダクトとのギャップが一覧化されていること 開発中SDKのドキュメント草稿が最新コードベースから書き上がっていること 昨日の小規模インシデントのポストモーテムドラフトが仕上がっていること 5つすべてに完了のチェックがついている。エージェントの仕事は完了していたようだ。 僕の手元に届いている成果物は、すべてエージェント同士の一次レビューを通過したものだ

エンジニアの認知戦略はなぜすれ違うのか ソフトウェアエンジニアとして業界に長くいると、現場や SNS 上でのエンジニアどうしの「すれ違い」を何度も目にします。技術力の優劣ではない、性格や趣味嗜好の問題とも少し違う、なのにこの「すれ違い」は、驚くほど普遍的に業界内に存在しています。 この記事では、わたしがそのような「すれ違い」を何十年も観測し続けた末にたどり着いた一つの認知モデルに基づく見解です。科学的に証明された理論ではありません。しかし、この視点を持つだけで、日常の摩擦の見え方がかなり変わるはずです。 チーム内での症状 チェックリスト: あなたのチームで以下の状況を見たことはありますか? コードレビューで同じ PR に真逆の指摘が出る。 設計について、すぐ手を動かしたい派と全体像を合意してから着手したい派で割れる。 「なぜこうしたか」は誰かの頭の中にあり、その「誰か」を探す必要がある。

上司になる人にアドバイスするとしたらどういうことを伝えるだろうか？ 機能する上司になるのはほんとに難しい。 役職は会社から与えてもらうことができるが、、だからといって部下がついていくかどうか？は別物だ。フォロワーシップのない管理職は本人も部下も辛い。 はじめて管理職になったのはたぶん32歳のときだった。当時の職場には管理職トレーニングなんてなかったし、そもそも上司ってほとんど見たことなかったし（小組織にしかいたことなかった）で、とりあえず現場プレイヤーのまま管理職になり、そのまま突進して、そして組織がでかくなって見事にいちど自分自身でパンクした。 そのときに幾つかの本を読み始めたんだがその一冊がジャックウェルチのエグゼクティブコーチをしてた人の本。 そこにリーダーにありがちな悪癖が20ある。おもいあたることがみなさんもないだろうか？ 極度の負けず嫌い 何かひとこと価値を付け加えようとする。

2026年のソフトウェア開発を考える（2026/05版） Scrum Fest Niigata 2026 2026年5月8日（金） https://www.scrumfestniigata.org/

こんにちは！データエンジニアの myshmeh です。 前回の記事では、データ分析エージェントの精度向上を題材に、オントロジーと Semantic Layer は対立するものではなく、互いに補完しうる関係なのではないか、という観点を整理しました。 本記事ではその続編として、実際のオントロジーツールに触れ、それぞれの利点に踏み込みます。具体的には、形式論理の取り入れ度合いが異なる Microsoft Fabric IQ と Protégé を通じて、 Semantic Layer と比較した際の特徴と、実務に取り入れる際の難しさを整理してみたいと思います。 オントロジーのいろいろ オントロジーを試す前に、オントロジーは定義が一つに定まらない領域であることを押さえたいと思います。 オントロジーは、哲学に端を発する領域で、業界によって様々なニュアンスを含みます。特にテック業界では、「概念の構造的

Decision Quality (DQ) は SDG が体系化した意思決定の質の枠組みで、良い意思決定の条件を6つに分解する。 Frame（解くべき問題の枠組み） Alternatives（選択肢） Information（情報） Values（評価基準） Sound Reasoning（論理的推論） Commitment to Action（実行へのコミット） 全体の質は一番弱い要素で決まる、というのがDQの中心的な主張である。意思決定そのものと、その結果は区別する。良い意思決定でも結果が悪いことはあるし、その逆もある。 設計判断の現場で繰り返し観測される失敗の多くは、6要素のうち Frame と Values の2つの取り違えで説明できる。Valuesを 評価軸 として8つに整理し、Frame の取り違えは 支配軸の取り違え として捉える。残りの4要素も副次的に絡む。早合点 は In

業務システムの画面を、テーブルのカラムをそのまま入出力フォームに並べる形で作る設計。一覧・検索・登録・編集・削除を1セットの画面群として揃え、ユーザの業務フローではなく、データ構造のCRUDをそのまま画面化したもの。日本のSIer現場では「画面駆動設計」とも呼ばれるが、根は同じで、テーブル定義が先にあって画面はその入出力フォームになる。 ユーザが何をしに来たか(申請を出す、状況を確認する、上長承認を待つ、月次で締める)という行動軸ではなく、「商品マスタ画面」「受注一覧画面」「承認待ち一覧画面」のようにテーブル軸で画面が並ぶ。例えば受注管理画面の典型はこうなる。 画面上半分に受注番号・各種日付・ステータス・倉庫・商品コード・商品分類など30以上の検索条件が並び、下半分の一覧では1レコードが多段に折り返されて表示される。検索条件・一覧表示・詳細編集がテーブル全カラムを軸に組まれており、「今日出