「すぐには理解できないが、正しいことを言っているのだと思う」 週次の報告会で、上司がそう言った。 私はAIで作ったスライドとHTMLレポートを画面に映していた。上司は内容を否定しなかった。むしろ、正しいと言ってくれた。理解はできないけれど、正しいのだと思う、と。 そのときの私は、それを好意的な反応として受け取っていた。今になって思えば、あれはレビューが壊れた瞬間だった。 私は大手製造業のDX推進部門でマネージャーをしている。この1年ほど、チームの若手中堅メンバーと一緒にAI活用を進めてきた。体感の生産性は3倍になった。そして同じ時期に、私たちは上司とベテランメンバーを置き去りにした。 これは、その置き去りがどう起きて、何を壊したかの記録である。先に結論を書いておく。置き去りは誰の悪意でも怠慢でもなく、構造で起きる。そして置き去りにした側も損をする。 登場人物に悪役はいない。上司は誠実だった

みなさんこんにちは。@ryuzeeです。 8月26日(水)〜28日(金)に、ぼくがメイン講師を務めるScrum Alliance認定スクラムマスター（CSM）研修をオンラインで開催します。チームに興味がありそうな方がいたらぜひご紹介ください。詳しくはこちらです。 プロダクトオーナーの相談に乗っていると、よく「忙しすぎて時間が取れないんだけど……」とか「プロダクトバックログアイテムを書くのが追いつかないんだけど……」みたいな話が出てきます。まぁ、どのプロダクトオーナーもだいたい大変なんですが、よくよく聞いてみると、なんでもかんでも自分でやろうとしていることが多いです。プロダクトゴールも自分で考えて、プロダクトバックログアイテムも全部自分で書いて、ステークホルダーの相手も1人でやる、みたいな感じです。これで時間が足りたら逆にすごいです。 これは本人の能力とか根性の問題ではなくて、「プロダクトオ

はじめに こんにちは、株式会社アサインでエンジニアをしているうちほり（@showichiro0123）です。 本記事では、BunをRustにフルリプレイスする（bun.com/blog/bun-in-rust）という記事を読み、その意思決定や取り組みの詳細を分析することで、一般的なプロダクト開発への応用可能性を探ることを目的とします。 Bunは、Node.jsと並ぶJavaScript/TypeScriptのサーバーサイドランタイムです。そのBunが、2026年5月3日から14日までの11日間で、コメントを除いて53万5,496行あったZig実装をRustへ書き換えました。diffは+1,009,272行、ピーク時には64並列のClaude Codeが動き、これを実行したのはBunの開発者であるJarred Sumner氏1人です。 Diff量を見るだけでもわかる通りの圧倒的な変更ですが、

こんにちは！ととです。 私は普段モバイルアプリエンジニアとして仕事をしていて、普段は「どう作るか」「どう設計するか」「どう問題を解くか」を考えることが多いです。 でも近年、それと同じくらい、あるいはそれ以上に、「どう話し合うか」「どう決めるか」が大事なのではないかと思うようになりました。 月に1回、Sansanさんの関西オフィスに集まり、「ファシリテーション勉強会」に参加しています。 私は第二回から参加していて、行けない回もありつつ、約1年半この勉強会に関わってきました。今回はそこで得た気づきを書いてみたいと思います。 どんな勉強会なのかこの勉強会のテーマは、「実践から学び、学びから実践へ」です。 ファシリテーションについて座学で学ぶというより、実際にやってみて、振り返って、また現場で試してみる。そんな場です。 チェックイン勉強会では、最初にチェックインをします。 議論に入る前に場の雰囲気

はじめに 先日、このような投稿を見かけました。 メールサーバをセルフホストして、サービスごとに別々のアドレスを割り当てている方のところに、とあるお寿司チェーンにしか教えていないはずのアドレス宛にフィッシングメールが届いたそうです。おかげで、どこから漏れたのかが一発でわかった、という話でした。アドレスの出どころを切り分けられる運用自体はすごく良いと思います。 問題はそのあとです。反応には「Gmailのエイリアスを使えばいい」という声が並び、投稿主ご本人も「厳密にはCatch-Allではなくエイリアスで運用している、区切り文字をピリオドにしているので弾かれにくい」と補足していました。 このエイリアスという一語が、私にはどうしても飲み込めません。 hoge@example.comに対してhoge+fuga@example.comやhoge+spam@example.comを使い分ける。文字列の上

本書について 本書『情報科学のための数学』は Eric Lehman, F. Thomson Leighton, Albert R. Meyer 著 Mathematics for Computer Science の翻訳です。原著は Creative Commons Attribution-ShareAlike 3.0 ライセンスで公開されています。 この翻訳は Creative Commons Attribution-ShareAlike 3.0 ライセンスの許諾に基づいて公開されます。 この翻訳は Creative Commons Attribution-ShareAlike 3.0 ライセンスで公開されます。 この翻訳を二次配布・二次利用する場合は、https://inzkyk.xyz/mcs/ に対するリンクを帰属表示として紹介文などに含めてください。 謝辞 原著 Mathema

トリビューでCTOをしている小尾（@obiyuta）です。 弊社ではAIを前提とした全社業務の再構築に取り組んでおり、前回はその中で取り組んでいる社内MCPを載せる共通基盤（認証・認可・ログ）をご紹介しました。 今回は具体的な活用事例として、非エンジニアが自分で本番データを分析できるような分析基盤と、作って終わらない改善ループをどう構築、運用しているかご紹介します。 「SQLが書ける」と「正しく答えられる」は違う 分析基盤そのものは特殊なものではなく、ClaudeやNotion AIなどから自然言語で問いを投げると、SQLを組み立てて、BigQueryで実行して結果を返すという、至ってシンプルな仕組みです。実際にこういったtext-to-SQLの事例は各社でも紹介されており、もう特別なことではなくなってきました。 一方で、意思決定をするにあたって必要な情報を正しく安全に提供するためには、「

気になるシリーズやコンテンツ、特集・コラムを保存し、あとからまとめて確認できます。 ※ご利用にはログインが必要です。 You can save series, content, featured articles, and columns, and review them collectively at a later time. ※ Log in is required to use My List.

いま注目の文筆家のエッセイ、小説などの創作を4号続けて掲載。今回は2497号（2026年5月26日発売）から、影山優佳さんのエッセイ連載 第3回「ウチらって、美しいからサ」をお届けします。 「デブス」 夏の大三角を構成する星でも、どこかにいそうな神の名でもない。 「親にも言われたことないのに！」と言いたくなるほどの中傷は、中学生の私にはあまりにも刺激的なフレーズだった。 アイドルとは性別と年齢、そして当然の如く外見によって価値が生まれる。 24時間365日、どこを切り取っても「見られること」が前提の世界で、私は自分の輪郭をどんどん削ぎ落とさなければならなかった。 全身鏡の前に立つ。なんとも丸いお顔。筋肉質な身体。 この私がアイドルのかわいらしいお洋服をスタイル良く着こなすにはと思案する。 一番の心当たり、自らのふくらはぎを雑巾絞りのようにつねってみる。 もりもり蓄えられた筋肉の上にへばりつ

時間が全く取れないことはないはずなのに、なぜか時間が過ぎ去っていて時間が取れていないことあるよな。俺はある。そういう時に自分がやるべきことを雑に書き殴ってみる。 やめてみる 勝手に自分がやらないといけないと考えてるだけで、たいてい今自分がやらなくていいことをいっぱいやってるよ。「これやめたら何がどのくらい困るんだっけ？」と一度立ち止まって考えて、思い切ってやめてみるといい。自分だけで想像せず、関わる人に直接聞いてみるのがオススメ。 特にオブザーバーで入ってるミーティングとかね。なんか不安ってだけで出席してるミーティングが週に3つとか入っていないか？まず2週間出ないでみてどうなるか振り返ってみるのもいいと思う。たぶん何の問題もないことに気づけるよ。そうでなくとも関わり方が変わるはず。 立ち止まる 自動化、効率化にちゃんと時間を使わないとジリ貧になる。「2日あったら仕組みを作れるか？」と自分に

东云Po @popodaddy726 在日本住了10多年，对日本人改变最大的一个认知： 刚来的时候： 日本人很客气 = 他们喜欢我 住了2年之后： 日本人很客气 = 和喜不喜欢你完全无关 日本的礼貌是写进文化里的社会润滑剂，对每一个人都一样，不管是朋友还是陌生人，不管关系深浅 真正的接纳要靠时间和具体的事，不是靠对方有没有对你微笑鞠躬 很多外国人在日本会撞墙，撞的就是这一堵：把对你的礼貌和客气当成了接纳 想通这个事儿，就能看懂日本人在想什么了 2026-05-31 07:23:00 ”日本に10年以上住んで、日本人に対する認識で一番変わったのはこれ： 日本に来たばかりの頃： 日本人はとても丁寧だ = 彼らは私を好きなんだ 2年住んだ後： 日本人はとても丁寧だ = あなたを好きかどうかとは全く関係ない 日本の礼儀は文化に根付いた社会の潤滑油で、誰に対しても同じだ。友達であれ見知らぬ人であれ、

BASE株式会社執行役員の柳川です。金融事業の事業責任者をしています。エンジニア→PdM→事業責任者というキャリアを歩んできました。 最近AIの進化の話から飛び火して、「エンジニアが事業目線を持つべきか？」みたいな話を聞かれることがあります。おそらく「コード書いてるだけではAIに取って代わられるのでは？」的な文脈だと思います。 その文脈であれば、「コード書いてプロダクト作るのはそんなに簡単なことじゃないので、今やれてる人はそんなに心配しなくてもいいのでは？」と言うのが僕の答えです。過去のnoteで書いています。 ですが、「変化の時代に少しでも守備範囲を広げた方がいいのでは？」と言う気持ちもわかりますで、ちょっと考えてみましょう。 最初に結論っぽいことを言います。 エンジニアは必ずしも事業に関心を持たなくていいです。 「事業を理解しろ」「PLを読め」「ビジネスを学べ」と煽る言説、もう飽き飽き

タスクのアサイン、プロジェクトのリード、チームのマネジメントなど、『今の自分の実力でできるかわからない役割』を任されることがある。いわゆるストレッチアサインメントである。程度の差はあれ、こういう任され方の方が多いんじゃなかろうか。 言うのは簡単だが、やってみるとたいていつらい。焦りや不安でしんどくなったりする。まあ自分の実力を超えた役割なんだから当たり前なのだけれど、 "型" として抑えておくとよさそうなポイントもある気がするので雑に書き出してみる。 1. 期待と理由を明確にする 『なぜ』『何を』『どこまで』やるべきなのかと、『なぜ』『今』自分が担うのかを明確にすること 期待を明確にしないとずっと何もできていないような気持ちになるし、自分がやる理由を明確にしないと自信を持ちにくくなってしまう 抜擢など誰かにお願いされた場合には、その相手と直接話すのが一番よい 2. 役割を宣言する 自分が担

まだ鎌倉に実家があるころ、ずっと二匹の猫を飼っていた。一家離散となったあと、猫は親が引き取った。猫は長生きをした。最後に残った一匹が死ぬ前の晩、その猫が夢に出てきた。確率論的にそういうこともあるのだろうな、と思った。母から猫が弱っていると聞いていたという理屈もあるんだろう。一方で、なにか不思議なこともこの世にあるのではないか、とも感じた。 LINEの着信音で目が覚めた。ずっとLINEの調子が悪くて、着信の通知がずっと切れていた。ところがここ最近、復活しつつあった。着信があったり、なかったりする。おれは枕元のiPhoneを手にとってLINEを開いた。 母からの父の訃報だった。実はそれ以前にべつのグループで「息をしていないので救急車を呼びました」というむねのLINEが送られていた。その通知はなかったか、おれは寝ていて気づかなかった。 おれは夢を見ていた。街なかのおれは全裸で、同じく全裸のきれい

つまり Bun の Rust 移植では、「自動テストが通る」を「レビューが通った」に静かに置き換えている、と読める。これは伝統的なコードレビューの観念とは違う何かだ。 所感：すごいのは AI じゃなくレビュー概念のほう 私が驚いたのは「AI が 96 万行書ける」ことよりも、「人間がコードを読まずにマージできる、と判断したこと」 の方だ。レビューの定義が、コードを読むことから「テストと AI の再生成可能性を信じること」に、静かにスライドしている。 これが Bun だから許される特殊例なのか、これからの標準なのか。私には分からない。 ただ、AI 時代のレビューって何だっけ、という問いは、もう避けて通れないところに来ている気がする。 疑問② 動いてるのに、なぜ書き換える？ Bun は すでに本番で動いている JS ランタイム だ。それを 6 日でゼロから別言語に書き換える、というのは普通の意

はじめに 「え、まだVSCode使ってるの？」 「Vimできないとか、エンジニアとして大丈夫？」 「hjklで移動できないの？効率悪くない？」 こんな言葉を職場やコミュニティで投げかけられたことはありませんか？ これが vimハラ（Vimハラスメント）です。 本記事では、vimハラに遭遇しても心が折れないための心得をお伝えします。 vimハラとは何か vimハラとは、Vimユーザーが（多くの場合は無意識に）他のエディタユーザーに対して行う、エディタ選択に関するプレッシャーや揶揄のことです。 よくあるvimハラの例 「Vim使えないとサーバー作業できなくない？」 「マウスに手を伸ばす時間がもったいないよね」 「俺はVimで全部やってるけど（チラッ）」 「Escキーの位置変えてる？え、変えてないの？」 「.vimrcが1000行超えてからが本番だよ」 心得その一：エディタは道具であり、人格では

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

自分がオーナーシップを持って物事を進める時には、少なくとも組織内ではその領域のことを一番考えているという自信を持つほうがいいと思っていて、そのあたりの話を雑に書いておきたい。 なんでかというと、結局一番考えてないと説明責任を果たせないからなんだよな。たとえば「なんでこういう方針にしたんですか？」、「このあたりは考慮できていますか？」みたいにまわりから聞かれた時に、「それはもう過去に私の脳が通ってきた道だ」みたいな感じで二周目状態になっていないと説明できない。 自分は昔「説明責任とかしゃらくせえ、"遂行" できればええやろ」と考えていたことがある。それはそうで、小さいタスクだとそれで全然OK。けどねぇ、なんかうまくいかなくなるんだよな。説明しながら "刻む" 進め方を身につけないと、物事を前に進められなくなってくるのよ。もしかしたら "圧倒的" なレベルの人はそんなことはないのかもしれないけ

生成AIを使った開発。個人としては少し手に馴染んできているけど、チームでの開発はどう取り組むのがいいんだろうな？と思っている。この記事は、やってみた結果どうだったというものではなくて、これから試行錯誤するための頭の中の整理。 僕が自分の手でコードを書くことはもうない まず、AIを使っていて感じるのは「今後、僕が自分の手でコードを書くことはないだろう」ということ。すでにこの数カ月間、自分ではコードを書いていない。 誰かと仕事をするときに、コーディングを一緒にするのはいい時間だったなぁと思う。ペアプロやモブプロで知識の交換をしたり、新しいメンバーを受け入れたり、若手を育成したり、そういうときにコードを見ながら「ここはこうしましょう」「それはどうしてですか？」みたいに話せるのはとてもよかった。 でも今後は、そういう時間は中心にはならなさそうに思う。コーディングは誰かと一緒にやるよりは、1人でAI