/note/tech

LLMでユースケース図の作成時間を大幅に短縮 3つのプロンプト技術を組み合わせ

• LLMでユースケース図の作成時間を大幅に短縮 3つのプロンプト技術を組み合わせ | AIDB

MEMO:

• LLMにユースケース図を作成させたらいい感じだったらしい

(2025/11/25)

2025 年末のソフトウェア開発の様子

• 2025 年末のソフトウェア開発の様子 - amachang - Google スライド

MEMO:

• AIの進化により職人的ソフトウェアエンジニアの役割は終わったというお話
• エンジニアはPMも営業も出来るようにならないと厳しいぞと
• まぁ、そうなるわな
• 救いがあるとすれば、個人で請けるなら本当に低予算・小規模なプロジェクトでも採算が取れる可能性があること
• そういうスモールプロダクト・スモールプロジェクトであれば、いわゆる職人的ソフトウェアエンジニアもスキルと経験を活かしやすい
• 大規模・複雑・ミッションクリティカルな開発しか残らない世界線だとジョブチェンジを検討しなければならなかった

(2025/11/25)

ひろゆき氏が無料ツール利用を貫く理由　「2ちゃんねる」運営で学んだ壊れにくいサービス設計

• ひろゆき氏が無料ツール利用を貫く理由　「2ちゃんねる」運営で学んだ壊れにくいサービス設計 | ログミーBusiness

要約:

■ 1. 2ちゃんねる創設の経緯

• 立ち上げの動機:
  • 暇だったことが第一の理由
  • アメリカで大学生をしていた当時、「あめぞう掲示板」を使用していた
  • 「自分で作れるのか」と試したら作れてしまった
  • 高いモチベーションがあったわけではなく、できてしまったから惰性で続けた
• 学んだこと:
  • プログラムを作る力とサービスとして運営していく力は全く別物
  • 動くものができても運用しやすいようにコードを修正する必要がある
  • トラブル防止のためのサーバー準備も必要
  • 世界中の無料サーバーを契約して回り、「ここが落ちたら次はここ」というルートを事前に用意する運用ノウハウを蓄積

■ 2. 技術選定とシステム設計の考え方

• 使用言語:
  • 当時からPerlで書いており、現在も同様
• データベースを使わない理由:
  • データベースはたまにデータが壊れる
  • 約10年前に某企業のOracleデータベースのデータが全消失した事例がある
  • データベースを使うとメモリやCPUのオーバーヘッドが大きくなりサーバーコストが高くなる
• テキストファイル保存の採用:
  • テキストファイルに書き出せば壊れにくくできる
  • お金がない中での工夫
  • 「どうやったら安く、壊れにくく動かせるか」という発想
  • このノウハウはその後のIT系会社経営でも活用

■ 3. 潰れない会社の経営哲学

• 基本原則:
  • 会社が潰れるのはお金がなくなった時
  • お金がなくならなければ会社は生き残れる
  • 毎月のランニングコストをいかに安くするかが重要
• よくある失敗パターン:
  • 売上を上げていく過程でコストも上がる
  • 売上が下がった時に赤字になり大慌てになる
  • 一度上がったコストを下げるのは非常に困難
  • その結果として倒産するケースが多い
• 実績:
  • 1999年に大学生の時に作った合資会社は現在も存続
  • 2001年頃に作った株式会社も現在も存続
  • 自分の会社を潰したことはない

■ 4. サービスを当てるための考え方

• 仮説の作り方:
  • 他にないことで「自分がそれを知りたい・やりたい・おもしろいと思うか」が基準
  • 自分自身がおもしろくないと思うと飽きて続かなくなる
  • 「別に自分が作らなくてもいい」「既にある」と思うと飽きてしまう
  • 自分の欲望に沿うタイプ
• 他のアプローチとの違い:
  • 「世間で流行っているから作る」というソシャゲー系の作り方はできない
  • 好き嫌いに関係なく儲かるものを作る人もいるが、自分はそれができない
  • 人の性格による違い

■ 5. 2ちゃんねる立ち上げ期の戦略

• 当時のインターネット環境:
  • 企業がサイトを作って運営することは少なかった
  • ネット決済やクレジットカード入力はほぼ存在しなかった
  • 個人がブログを書いてサイトを作るのが普通だった
  • 情報を出す人が少なかった
  • 「日本語で書かれているページはだいたい全部見た」という人がいた時代
  • 昔のファミコンで「発売されたソフトはほぼ全部触っている」という人がいたのと同様
  • 「全部わかる時代」だった
  • 新しいサイトができたら情報を共有するリンク集が流行していた
• 掲示板を選んだ理由:
  • 情報が集まる場所として掲示板はずっと残ると考えた
  • 誰でも書けるため情報が出回りやすい
  • 人が多ければ多いほど情報が増える
• 競合に勝つための設計:
  • たくさん人が来ても耐えられる仕組みにする
  • 書かれたデータが消えずに残り続けるようにする
  • 利便性を上げることで他のサービスより優位に立つ
• コスト構造の優位性:
  • 他のサービス運営者は自腹で回していたため、自分の給料以上の規模にできなかった
  • 世界中の無料サーバーをひたすら契約し続けた
  • 自分の人件費を除けばコスト構造がほぼゼロ
  • 無料で規模だけ大きくしていった結果、日本で一番大きい掲示板になった
• 掲示板とSNSの関係:
  • 掲示板はSNSの前の姿といえる
  • 昔は掲示板で情報収集・情報共有をしていた
  • 今はSNSがその役割を担っている

■ 6. 自宅サーバー学習の価値

• 自宅サーバーの意義:
  • 2ちゃんねるも自宅サーバーで運営していた時代がある
  • 自宅サーバーでしか学べないことがある
• 具体的なメリット:
  • 「GPUをぶん回す」ような処理は自宅で回したほうが安いケースがある
  • 「オンプレで自前で持つべきか」「クラウドでやるべきか」という比較ができるようになる
  • オンプレという選択肢を持っていないと「AWSとGCPどっちが安いか」という比較だけになる
  • 「この部分はオンプレにする」「重要なデータだから社内に置く」といった判断ができる
• 結論:
  • 自前サーバーの経験はサービスの管理者になるなら持っておいたほうがよい

■ 7. AI競争の価格面の帰着

• 大企業の動向:
  • OpenAIや大きな会社がひたすら投資しているものは残り続ける
  • 各社が「超優秀なAIを作る競争」をしている
• 一般ユーザーの実態:
  • 一般の人たちは「そこまで必要ない」という時代になりつつある
  • ChatGPT3と4の違い、4と5の違いを体感で理解しているユーザーは7〜8割もいない
• 今後の予測:
  • Metaの「パソコン1台で動く」「スマホの中で動く」モデルがある
  • 中国製の「GPUなくても動く」モデルも存在
  • スマホやノートPCの中に入って「これで充分」という時代になる
  • 巨大なデータセンターや電力の話が問題にならなくなる
  • 「能力が高くなくてもこれで足りる」ものが小さく自分のスマホの中で動く時代になる

■ 8. データベースより軽い設計発想

• データベースの課題:
  • データベース連携は便利なミドルウェアも多く、いろんな人が触れるようになる
  • しかし当時はサーバーのリソースが少なすぎた
  • アクセスが増えるとCPUが詰まる
  • データベースは同時書き込みでデータが壊れるため「ロックして1人ずつ書く」動きをする
  • アクセスが多すぎるとロックがかかったままになりデータの出し入れができなくなる
  • 結果としてサービスが止まる
• 分散処理の問題:
  • 「同じサーバーを100台並べて分散すれば処理が100倍になる」というやり方はコストがかかる
• 採用した解決策:
  • 「多少順番がズレてもいいからロックしないで書く」
  • 「多少の誤差は許容する」という方針
  • ロックせずにどんどん追記していく
  • 「書き込んだ順番が前後することがあってもしょうがない」という誤差を認める
  • この方法でコストは大幅に下がる
  • テキストファイルでの運用はこの考え方に基づく
• JSONでのAPI操作:
  • 「データベースでガチガチにやるのではなくJSONでやる」というのは同様の考え方

(2025/11/24)

ひろゆき氏が語る“40代・50代エンジニア超優秀説”　AI時代に活躍する条件

• ひろゆき氏が語る“40代・50代エンジニア超優秀説”　AI時代に活躍する条件 [1/2] | ログミーBusiness

要約:

■ 1. ひろゆき氏の現在の開発活動

• 使用言語・ツール:
  • Google Apps Scriptを使用
  • YouTubeのコメントを収集するアプリを開発
  • 出力先をGoogleスプレッドシートにすることで無料でデータ保存が可能
• 現状の課題:
  • データ量増加に伴い動作が遅くなる問題が発生
  • 有料ストレージの契約を検討したが、費用負担を避けて開発が停滞中

■ 2. AIを活用した開発スタイル

• 今回の開発目的:
  • AIがどの程度のレベルでコードを出力できるかを検証する実験
  • Geminiに仕様を投げ、やりとりしながら仕様書をブラッシュアップ
  • AIが出力したコードの精度を確認し、必要に応じて手動で修正
• 開発における役割分担:
  • スクラッチ（初期コード作成）は全てAIに任せる
  • デバッグや細かい修正は自分で行う
  • 「ここだけ変えて」と指示しても別の箇所まで書き換えてしまう問題が発生
  • 手戻りを防ぐための指示方法やAIの反応パターンを観察中

■ 3. 開発ツールの選定方針

• 使用ツール:
  • Gemini
  • ChatGPT（無料範囲）
  • GitHub Copilot（無料範囲）
• 無料ツールを選ぶ理由:
  • 有料ツールはいずれ廃れる傾向がある
  • 企業が有料で作ったツールも、後から無料のオープンソースベースのものに置き換わる
  • PhotoshopやIllustratorに対するGIMPの存在が例
  • VS Codeはマイクロソフト製だが無料で使える
  • オープンソースは無料で広まり、多くの人に修正されて品質が向上する歴史がある

■ 4. 技育祭と若手エンジニア育成について

• 技育祭の意義:
  • 手作り感を出し続けることで参加しやすさを維持
  • 「とりあえず参加してみる」までのハードルを下げることが重要
• エンジニアの適性:
  • 向き不向きはやってみないとわからない
  • 優秀なエンジニアには面倒くさがりが多い
  • 「手を動かすのが面倒だから自動化しよう」と考えられる人が強い
  • やる気なさそうに見えるタイプが実はエンジニアとして優秀なケースがある
  • プログラミング未経験で「必要だからやるか」と始めた人が非常に優秀になるパターンも存在

■ 5. サーバーエンジニアの将来性

• AIの限界:
  • サーバー契約の最適解や安いサーバーの提案は可能
  • 実際にトラブルが発生した際の修正はAIにはできないことがある
  • ネット上にない情報やレアなバグへの対応は苦手
  • AIはネット上の情報を統計的に処理して最適解を出す仕組みのため、未知の問題には対応困難
• 人間の強み:
  • サーバーの仕組みを理解していれば、別サーバーを立てて冗長構成を保ったまま切り替えるなどの対応が可能
  • インフラの前提を理解していない人がAIだけで大規模サービスを構築するのは現状困難
  • 自分自身の知識と知能で解決しなければならない問題に対しては人間が必要

■ 6. AI時代におけるエンジニアの知識と経験

• 40〜50代エンジニアの活躍:
  • AIがコードを書けるようになり、若手に細かい実装を振る必要がなくなった
  • 40〜50代は自分でサーバーを立ててOSを入れてアプリを書くという一連の流れを全て手作業で経験した世代
  • 仕組みを丸ごと理解しているため、仕様から削る判断や全体設計の見直しが可能
  • 部分最適ではなく全体を見たものづくりができる
• 20〜30代エンジニアの課題:
  • イチから物を作る経験が不足しているケースが多い
  • CPUだけ速くしてもメモリが詰まる、ストレージが遅いとボトルネックになるといった段階的な切り分けの感覚が身についていないことがある
  • DBのテーブル設計変更によるI/O削減やサーバーの疎結合化といったノウハウが不足
  • AIに丸投げするとお金で解決する設計になりがち
  • 「同じサーバーを10台並べてホットスタンバイにする」といった非効率な提案になる傾向
• 推奨される学習方法:
  • お金があまりない環境で自分でゼロから立ち上げる経験を積むべき

■ 7. コンピューターサイエンスの知識の必要範囲

• 不要な知識:
  • CPUの内部構造
  • アセンブラレベルの理解
  • サーバーを自分の手でイチから組む能力
• 必要な知識:
  • リモート先のサーバーでCPUがどう動いているか
  • メモリがどう使われているか
  • コンピューターの基本的な仕組み
• プログラミング言語の習得:
  • 1つの言語をしっかり身につければ十分
  • 1つマスターすると別の言語を見た時に「言い回しが違うだけ」「こういう仕様なのね」と読み替えられる
  • 学び直しのハードルが一気に下がる
• 基礎の重要性:
  • メモリの概念がわからない人にポインタを教えるのは困難
  • メモリの概念を理解している人には「メモリのラベルを使うためにポインタがある」と説明すれば理解が早い
  • 抽象概念よりも基礎のハードウェアを学んだほうが理解しやすい

■ 8. AI時代におけるエンジニアの価値

• エンジニアの強み:
  • 仕様を設計できる能力
  • 「この予算ならここは削ったほうが回る」というコストとのバランスを見る力
  • クライアントへの提案力（「ここを外せば納期が短くなる」「ここを簡略化すればコストが下がる」など）
  • お金と時間の感覚に基づいた提案
• AIの弱点:
  • コスト感は会社ごと・案件ごとに異なる
  • その場でさじ加減できる判断は人間のほうが強い

■ 9. 新卒カードの活用と大企業への就職

• 大企業を選ぶべき理由:
  • 「AIを使いこなせなそうな大企業」という決めつけは成長を阻害する
  • 大企業にいても自分でAIを調べて詳しくなる人はいる
  • 中小企業でも趣味で調べて詳しくなる人はいる
  • 「企業が何を与えてくれるか」という基準で選ぶのは好ましくない
• 大企業でしか得られない経験:
  • 大企業でしか触れられないノウハウ
  • 意思決定の流れ
  • 「この規模だとこうやって予算が下りる」という構造の理解
  • 「このタイプの案件はこの人が決裁権を持っている」といった内部の仕組み
• エンジニアリングの特殊性:
  • 大工は20代で家を一軒任されることはないが、エンジニアは20代でもアプリやサイトを1人で作れる
  • 「中小に行けば何でもやらされるから経験になる」と言われるが、そのレベルの経験は個人開発でも可能
• 大企業SIerの課題:
  • セキュリティの観点でコーディングにAIを使用禁止のところがある
  • AIを使わずに手癖が付くメリットはある
  • 「ここはもうAIで書く」という領域が増えているため、人力でコーダーを何年もやった経験が役に立たないケースもある
  • 「コードを書くのにAIは一切使うな」というスタンスは現代にそぐわない

■ 10. ITベンチャー企業と若手の働き方

• 20代にしかできない経験:
  • 馬車馬のように残業時間を気にせず働くのは20代の時しかできない
  • 若いうちに振り切って働いた経験があるかないかで、大人になってからの見え方が変わる
  • 自分の最大値や限界を感覚で把握できるようになる
  • 「最悪ここまでは踏み込める」という判断ができるようになる
• ベンチャー企業の魅力:
  • 大企業では労基の観点から限界まで働く経験がしにくい
  • ベンチャーで文化祭のように集中して働く楽しさは若いうちに味わっておく価値がある
• ひろゆき氏自身の20代:
  • 自分のサービスが好きで1日十数時間自分の作ったサイトを見ていた
  • 夜中にサーバーが落ちたら対応、旅行中でも対応という24時間即応態勢
  • バグがあったら直るまでずっと起きて対応
  • 苦痛ではなくサービスを維持すること自体が楽しかった
  • 「全体的には楽しい」の中につらいところもあるという感覚
  • 睡眠時間は事故がなければ限界まで寝るタイプで、トラブルが重なった時だけ徹夜

(2025/11/24)

ワインバーグの法則をAIに適用する『コンサルタントの秘密』

• ワインバーグの法則をAIに適用する『コンサルタントの秘密』: わたしが知らないスゴ本は、きっとあなたが読んでいる

要約:

■ 1. 『コンサルタントの秘密』の概要

• ジェラルド・M・ワインバーグによる主著である
• コンサルタント向けの専門書ではなく、相談されたときの思考法をまとめた普遍的な内容である
• 肩書きではなく「どのように人と関わるか」を扱った一冊である
• プログラムやシステムの話はエピソードとして登場するが本質ではない
• 様々なトラブル事例から「コンサルタントの法則」を紹介している
• トム・デマルコの書籍の源泉となった組織論や発想が含まれている

■ 2. オレンジジューステスト

• 設問内容:
  • 朝5時から1,000人分の搾りたてオレンジジュースを提供する
  • 缶入りジュースや事前準備は禁止である
  • 直前に絞ったジュースを全員に行き渡らせる必要がある
• 合格の回答:
  • 「できる。これだけのコストがかかる」と答えることである
  • 「無茶だ」「現実的でない」と勝手に判断することは失格である
• コンサルタントの役割:
  • 可能な選択肢を示すことである
  • それにかかるコストを示すことである
  • 選択は依頼主が行うものであり、選ばない選択も含まれる
• 原則:
  • 相手の要望を勝手に最適化することは相手の判断を奪う行為である
  • 相談される側は判断材料を提供する役割に徹するべきである
  • 良し悪しまで口出しすることはお節介である

■ 3. 「そこに無いもの」を見る方法

• 課題の特性:
  • 見えないものを見つけることは困難である
  • 悩みごとの原因は見えていない場合が多い
• 紹介されている技法:
  • ピンの技法は、リストアップ手段が無い対象こそ取り組むべきとする
  • 3の法則は、計画を台無しにする原因が3つ考えられないなら思考方法に問題があるとする
  • 説明の顔をしたアリバイは、ルールから言い訳を探す行為を指摘する
• 「他人という異文化を利用する」事例:
  • ワインバーグはプログラマの生産性向上を依頼された
  • 職場では要望があればすぐに購入・作成する方針だった
  • プログラマへのインタビューでは「足りないもの」が見つからなかった
  • 掃除のおじさんに「黒板を拭いてくれと頼まれたことはない」と言われた
  • 黒板は「消すな」という警告付きの個人メモで埋め尽くされていた
  • 本来の共有ツールが機能せず、購入したソフトやガジェットも共有されていなかった
  • 他者の視点により見えない問題を発見できた

■ 4. AIを活用した「足りないもの」の発見

• 「洗濯物リスト」の作成方法:
  • 機能設計時にスライド一枚に要件と実現方法を箱で並べる
  • 「この一枚が全体像だが、足りないものは何か」と周囲に問う
  • 機能不足だけでなく要件の制限や前提の追加が判明する
  • ネットワーク設計や非機能要件周りで発見が多い
• AIの活用方法:
  • 要件と機能の不足を尋ねる
  • タスクの網羅性とコスト見積もりを確認する
  • 図が成立する前提で欠けているものを探す
  • 計画を台無しにする原因を3つ以上考えさせる
• AIの特性:
  • 網羅性の確保に適している
  • 「10個考えて」という無茶な要求にも対応する
  • 人間が妥当性を最終判断する必要がある
• 1990年の出版時には存在しなかったAIという異文化を現在は活用できる
• コンサルタント業務の多くをAIに任せられるようになった
• 最終判断は人間が行う必要がある

■ 5. AI時代におけるコンサルタントの本質

• コンサルタントの核心的業務:
  • どのような問いを投げるかを決定することである
  • どこまで自分で判断するかを見極めることである
• 現代における重要性:
  • 正解がない時代では答えよりも良い問いが重視される
  • 問いへ向き合う考え方が必要である
• 『コンサルタントの秘密』はAI時代だからこそ読み直す価値がある

(2025/11/24)

AI駆動開発を実現するためのアーキテクチャと取り組み

• AI駆動開発を実現するためのアーキテクチャと取り組み - Speaker Deck

(2025/11/23)

特にエンジニア採用では「モダンな技術や最新の開発手法が取り入れられておりあの会社は優秀な...

特にエンジニア採用では「モダンな技術や最新の開発手法が取り入れられておりあの会社は優秀なエンジニアが数多く集まっている。自分もあの中に入ると何か少しエンジニアとして優越感が出そう」という空気感大事なんですよね。金払いがちょっと良いくらいではこの優越感が得られない。

@sakamoto_582

MEMO:

• ピカピカの技術スタックや開発手法は福利厚生定期

(2025/11/22)

論理削除の絞り込みはWHERE句でやるな

• 論理削除の絞り込みはWHERE句でやるな

(2025/11/22)

手を動かしながら学ぶデータモデリング

• 手を動かしながら学ぶデータモデリング - 論理設計から物理設計まで / Data modeling - Speaker Deck

(2025/11/22)

乱雑なコードの整理から学ぶ設計の初歩

• 乱雑なコードの整理から学ぶ設計の初歩 - Speaker Deck

(2025/11/22)

DDD x Microservice Architecture : Findy Architecture Conf 2025

• DDD x Microservice Architecture : Findy Architecture Conf 2025 - Speaker Deck

(2025/11/22)

QAフローを最適化し、品質水準を満たしながらリリースまでの期間を最短化する

• QAフローを最適化し、品質水準を満たしながらリリースまでの期間を最短化する - Cluster Tech Blog

(2025/11/22)

急速に波及する【もういい、Linuxをインストールする】

• 急速に波及する【もういい、Linuxをインストールする】 - YouTube

要約:

■ 1. もう限界、Linuxへ - 2025年のPC界隈の変化

• 2025年のPC界隈で静かに広がっている合言葉:「もういい、Linuxを入れる」
• 長年Windowsでゲームをしてきた熟練ユーザーやテック記者までがハイエンドのゲーミングデスクトップを丸ごとLinux(特にCachyOSのようなゲーム特化ディストリビューション)へ移行し始めている
• あるベテラン記者はRyzen 7 9800X3DとGeForce RTX 4070 Tiという典型的なハイエンド構成のWindows 11マシンをあえてLinuxに変えると宣言
• 理由:Windowsはどんどん扱いづらくなっているのにLinuxでのゲーム環境は明らかに良くなっているという感覚

■ 2. Reddit での賛同

• 海外掲示板Redditのテクノロジー版では同じ言葉をタイトルにした投稿が立ち、数千件規模の賛同票が集まった
• コメント欄には「もうWindowsの挙動に疲れた」「AIと広告が増えてOSとしての基本が良くならない」といった声が並ぶ
• 長年Windowsを使ってきたユーザーほど不満を募らせている構図が見える

■ 3. Windows 11のエージェントOS化

• 背景にはMicrosoftの路線変更がある
• Windows 11は「エージェントOS」を掲げ、Copilotと呼ばれる生成AIアシスタントをタスクバーやファイルエクスプローラー、設定画面などシステムの至るところに深く組み込もうとしている
• 最新ビルドではファイルエクスプローラーから直接ドキュメント要約やメール下書き生成を呼び出す機能まで用意
• OSそのものが常時AIと会話することを前提に設計されつつある
• 一方でユーザー体験は必ずしも便利になったという実感と結びついていない

■ 4. Copilotを巡る問題

• Copilotを巡る議論では常に画面の隅にいるだけでなく、AIが基本的な操作に失敗した公式広告動画が批判を浴び、Microsoft自身がその広告を削除する事態になった
• AI連携を強めることでブランドを近未来的に見せようとする動きと、「まずファイルエクスプローラーのフリーズやスタートメニューの不具合を直して欲しい」という利用者側の素朴な要求との乖離がユーザーの苛立ちを増幅させている

■ 5. Recall機能の問題

• 象徴的なのがRecallと呼ばれる機能
• Recallは画面の内容を一定間隔で自動撮影し検索可能な「パソコンの記憶」として保存する仕組み
• Microsoftは暗号化やWindows Helloによる保護を強調するが、実際にはデータベースが平文のSQLite形式で保存されていた時期があり、専門家から「悪意あるソフトや物理的なアクセスに極めて弱い」と警告されている
• プレビュー段階での強烈な反発を受けて一度は提供を見直したものの、その後もInsider向けに再投入するなど方向性自体は変えていない

■ 6. 広告的なUIの問題

• ユーザーの視界を埋める広告的なUIもMicrosoftへの不信感を積み上げてきた
• Windows 11のスタートメニューには「おすすめ」と称するエリアがあり、そこにアプリやサービスのプロモーションが表示される仕様が導入されている
• 設定である程度は無効化できるものの、規定では有効な上、更新の度に挙動が変わることも多い
• 最近ではPCのバックアップを推奨する警告風メッセージとしてOneDriveのクラウドバックアップを促す表示がスタートメニューに出るケースが報じられた
• 黄色い感嘆符で「アクションを推奨」という文言でユーザーの不安を煽りつつ、実態はMicrosoft 365やクラウドサービスの利用を後押しする導線になっている

■ 7. Windows 10サポート終了の影響

• 決定的だったのがWindows 10サポート終了のタイミング
• Microsoftは2025年10月14日を持ってWindows 10の通常サポートを終了し、以後は月例のセキュリティ更新や新機能提供を行わないと公式に発表
• Windows 10は依然として世界のWindowsユーザーの4割前後を占めていたとされ、数億台規模のPCが一斉に期限切れの状態になった
• Microsoftは Windows 11へ移行できないユーザー向けにESU(Extended Security Updates:延長セキュリティ更新プログラム)を用意
• 個人向けでは1台あたり年間30ドル相当の料金、あるいはMicrosoftアカウントとの紐付けやポイント交換による無償枠といった複雑な条件が提示されている
• ローカルアカウントだけで使い続けたいユーザーがESUを利用するには結局Microsoftアカウントへの移行を迫られる形

■ 8. Windows 11のハードウェア要件

• Windows 11側にはTPM 2.0やSecure Bootといったハードウェア要件が課されており、古いPCほどアップグレードが困難になる
• サポート終了に伴う解説記事の多くは「Windows 11要件を満たさないPCではLinuxディストリビューションやChrome OS Flexへの移行も選択肢になる」と明記
• つまりMicrosoft自身のライフサイクル戦略が結果的に「今のWindowsを捨てて別のOSへ飛び移ること」を現実的な選択肢としてユーザーに意識させてしまった

■ 9. LinuxとSteam Deckの台頭

• このタイミングで存在感を増したのがLinuxとSteam Deckを中心とするオープンなゲームエコシステム
• Valveが毎月公表しているSteamハードウェア&ソフトウェア調査の2025年10月版では、Linux利用者の割合が初めて3%を超え3.05%に達した
• 1年前の約2%からわずか1年で5割増の水準
• 依然として94%以上を握るWindowsと比べれば小さな数字だが、傾向としては明確な伸びを示している

■ 10. Protonの役割

• Linux側の下地を作った最大の要因がValveが開発したProtonという互換レイヤー
• ProtonはWineと呼ばれる互換技術をベースにしたソフトウェア群で、Windows向けのゲームをLinux上で動かすための翻訳役を担う
• Steamクライアントに統合され、ユーザーはゲームごとに有効化するだけでDirectX APIの呼び出しがVulkanなどのグラフィックスAPIに変換される仕組み
• 2025年秋時点の調査ではProtonDBの統計に基づき、Windowsゲームの約9割がLinuxでプレイ可能という水準に達したことが報告されている

■ 11. Steam OSとSteam Deck

• 物理ハードウェアとしてはSteam OSとSteam Deckの存在が象徴的
• LinuxベースのSteam OSを搭載したSteam Deckは携帯ゲーム機の形をしたPCとして世界的なヒットを記録
• そのOS構成やドライバー最適化がそのままLinuxゲーム環境の標準的な参照例になった
• Valve自身のハードウェアだけでなく、ROG AllyのようなWindows搭載ハンドヘルドがBazziteというFedoraベースのディストリビューションに入れ替えることでフレームレートやバッテリー効率を改善できる事例も報告されている

■ 12. ハードウェアメーカーの対応

• Linux側のゲーム人口がSteam全体の約3%という水準に達した今、ハードウェアメーカーも無視できなくなっている
• Steam Deck向け最適化を意識してAMDがオープンソースGPUドライバーの開発を強化
• 2025年にはWindows向けでメンテナンスモードに移行した旧世代GPUでもLinux側ではコミュニティ主導のRADVドライバーにより引き続き最適化が続くという構図が生まれた
• Windowsでドライバーサポートが先細りになる一方、Linuxでは過去世代GPUが長く活用される可能性が高く、古いゲーミングPCを延命させたいユーザーにとっては魅力的な要素になりつつある

■ 13. CachyOSの特徴

• CachyOSはArch Linuxをベースに「高速、安定性、ゲーミング最適化」を全面に押し出したディストリビューション
• 公式サイトでは「Blazingly Fast」を謳い、x86-64-v3やx86-64-v4といった新しめのCPU命令セットに最適化されたパッケージを提供することで、同じハードウェアでも標準的なバイナリより高いパフォーマンスを目指している
• 心臓部にあるのがCachyOS Kernelと呼ばれる独自ビルドのLinuxカーネル群
• BORE(Burst-Oriented Response Enhancer)やEEVDFといったCPUスケジューラ、LTO(Link-Time Optimization)、CPUアーキテクチャ別のコンパイルオプションなどを組み合わせ、入力遅延の低減とスループット向上を狙っている

■ 14. Linuxの課題

• もちろんLinuxに移れば全てが解決するわけではない
• 最大の難所として挙げられるのがカーネルレベルで動作するアンチチートとの相性問題
• Battlefield 2042やCall of Duty: Black Ops 6のような大型タイトルではSecure BootとTPM 2.0を有効にした上でRiot VanguardやEasy Anti-Cheatといったカーネル常駐アンチチートを要求するケースが増えている
• こうした仕組みはWindowsカーネルを前提として設計されており、Protonが再現するユーザーランドだけでは対応しきれない
• 技術的なハードルも残る:一部のハードウェアではLinux向けドライバーが未整備だったり、ベンダー純正の設定ツールが提供されていなかったりするため、「買ってきてさせばすぐ使える」というWindows的な感覚は通用しない場面がある

■ 15. 現実的な移行ガイド

• それでもWindowsからLinuxへの移行ガイドは年々現実的なトーンになってきた
• かつてはデュアルブートや仮想マシンで遊び半分に触ってみる程度の提案が多かったが、今では「Steamライブラリーの大半はLinuxで問題なく動く、どうしても必要なタイトルだけWindowsに残し、日常のゲーム環境はLinuxへ移す」という構成を推奨する記事も増えている
• ProtonDBで事前に互換性を確認し、必要に応じてローリングリリースのディストロをデュアルブートで入れるといった具体的な移行シナリオが提示されるようになった

■ 16. OSとしての哲学的考察(「沈黙する回路」)

• OSは単なるソフトウェアではない:朝起きて最初に触れる窓であり、1日の思考を流し込む媒体であり、記憶が堆積していく基盤でもある
• そこに絶え間なく広告や提案が降り注ぐと、心のどこかで自分の時間が少しずつ切り売りされている感覚が芽生える
• 便利さと引き換えに集中の静けさが薄く削られていく
• だからこそ何も語らないOSへの憧れが生まれる:起動しても何もおすすめしてこない環境、こちらから呼ばない限り口を開かないAI、更新の度に性格を変えないデスクトップ
• CachyOSのようなディストリビューションはその憧れを実態に変えるためにカーネルの速度やパッケージの構成といった目に見えにくい部分を丁寧に磨き続ける
• そこでは沈黙そのものが1つの設計思想になる

■ 17. 価値観の問題

• OS選択を単なる好みや慣れの問題として片付けるのは簡単
• しかしWindows 10のサポート終了やAIと広告を全面に押し出すWindows 11の路線、ハードウェア要件とアンチチートの強化によって、Microsoftの設計思想そのものがユーザー側の価値観と衝突し始めている
• 自分のPCを自分が主役の道具として保ちたいのか、クラウドサービスとAIのためのプラットフォームとして受け入れるのか
• その分岐点に立たされたユーザーが「もういい、Linuxを入れる」とつぶやきながらCachyOSのインストーラーを起動する姿は単なるOS乗り換え以上の意味を持ち始めている

(2025/11/22)

エンジニアの脳が壊れる瞬間 ─ 複雑性・認知負荷・計算量のメカニズム

• エンジニアの脳が壊れる瞬間 ─ 複雑性・認知負荷・計算量のメカニズム #設計 - Qiita

要約:

■ 1. はじめに:複雑性が問題を生む理由

• ソフトウェア開発には「複雑性が問題を生む」という常識がある
• 問い:
  • なぜ複雑になると破綻するのか
  • どこから複雑と呼べるのか
  • どの瞬間に人の理解が追いつかなくなるのか
  • 技術負債はなぜ突然「手がつけられない」段階まで膨張するのか
• ソフトウェアの複雑性を計算量、認知負荷、チーム特性という3つのレンズで読み解く
• ポイントは「複雑なコード」ではなく「複雑さ自体の本質」を扱うこと

■ 2. 複雑性とは計算量の爆発を人間が受け止められなくなる現象

• ソフトウェアの複雑性はしばしば計算量の爆発として語られる:
  • O(N) → まだ追える
  • O(N²) → 何が起きているか曖昧になる
  • O(2^N) → もはや理解不能
• しかしこれは人間の脳にもまったく同じことが起きる
• 人間の作業記憶は7±2個しか保持できない(心理学の古典的研究)
• これはエンジニアにとっては「認知の計算量制限」を意味する
• その後の研究では実効容量は4±1個程度という見解も有力(Cowan 2001など)
• つまりコード設計がO(理解)を超えた瞬間、人は壊れる
• 人間の作業記憶は5〜9チャンク程度しか同時に扱えないとされており、複雑な設計はすぐにこの上限にぶつかる

■ 3. 設計の計算量はコード行数ではなく関係性の数で決まる

• 複雑性はコード量では決まらない
• 関係性(依存・制約・フロー)の数で決まる
• 例:
  • AがBを知っていて
  • BがCを参照していて
  • Cが非同期にAを更新する
  • これを理解するには人間はA-B-C-Aの閉路を追跡しなければならない
  • これは脳にとってDFS(深さ優先探索)のような負荷
• 関係性が増えるほど理解の計算量は指数的に増える
• コードは線形に増えるが理解コストは指数関数的に増える
• だから設計は突然破綻する
• 崩壊は徐々には進まない
• ある閾値を超えた瞬間いきなり崩れる
• まるで「臨界点」を超えた化学反応のよう
• 依存関係の数が増えると開発スピードより先に「依存の管理コスト」が爆発していく

■ 4. 認知負荷は見えない技術負債である

• 複雑性が破綻するのは技術の問題ではなく人間が処理できる情報量の限界を超えるため
• 認知負荷が高い設計には次の兆候がある:
  • 一度読んでも理解できない
  • 仕様とコードの対応が不明
  • 「ここを変えるとどこに影響する?」が見えない
  • レビューが摩耗する
  • バグが「点」ではなく「面」で発生する
• これらはすべて「計算量過多」「キャパシティ超過」の症状
• 技術負債とは「認知負荷が金利として積もっていく現象」と捉えるべき
• 技術負債は単なる「後回しの修正」ではなく開発者の頭の中に積み上がる認知負荷そのもの

■ 5. アーキテクチャの本質は計算量の制御

• 設計とは格好いい図を描くことではない
• 本質はただ一つ:「理解に必要な計算量をO(1)に近づけること」
• そのためにアーキテクチャが存在する:
  • 層で区切る → 認知対象を一定に保つ
  • 責務を限定する → 計算経路を短くする
  • 境界を作る → 関係性を切断する
  • APIを設計する → 認知を抽象化する
• きれいな設計にも理由がある
• それは美しいからではなく脳への負荷を最小化するため

■ 6. 複雑性の破綻ラインは個人ではなくチームに依存する

• 認知負荷は人によって異なる:
  • 初心者はすぐO(爆発)
  • ベテランはO(ある程度耐える)
  • 設計者はO(ノイズを抽象化できる)
• つまり複雑性の破綻ラインはチーム固有のものであり汎用的な「正しさ」では語れない
• 技術は移植できても認知限界は移植できない
• あるプロジェクトでうまくいった設計が別のチームでは壊滅する理由はここにある

■ 7. 実務で複雑性の爆発を防ぐ方法

• (1) 関係性を減らす(依存を切る):
  • イベント駆動で発散した依存を整理する
  • 双方向参照を禁止する
  • 「AはBを知らない世界」を設計する
  • 短い例:UI→UseCase→Repositoryだけにし、UIがRepositoryを直接呼ばないようにする
• (2) 読み方をO(1)に近づける:
  • コードが「初見で」理解できる必要がある
  • 初回で理解できない設計は複雑すぎる
  • 短い例:「この関数は何をするか?」が1画面以内で完結するようにする
• (3) ドキュメントではなく構造で説明する:
  • ドキュメントで補強が必要な設計はすでにO(1)ではない
  • 短い例:「ここは○○層です」と説明不要なようにフォルダと責務を一致させる
• (4) レビューで認知負荷を観測する:
  • レビューの摩耗は構造の疲労
  • 短い例:PRに「ここ分かりづらい」コメントが連発したら設計の構造疲労を疑う
• (5) チームの認知限界を把握する:
  • ベテランの限界ではなくチームの最低ラインで設計すべき
  • 短い例:「新人でも追える構造」を基準にしベテラン依存の暗黙知を排除する

■ 8. おわりに

• 複雑性の問題は理論では説明できるが実務ではほとんど語られない
• しかしソフトウェアが破綻するのはいつだって「人間が理解できなくなったとき」
• ソフトウェアの限界は計算資源ではなく人間の認知資源で決まる
• この視点が定着すると設計やレビューやアーキテクチャの見え方が変わる
• 複雑性を避けるのではなく複雑性と「共存できる形」を探すことが大切

(2025/11/21)

仕様駆動開発の理想と現実、そして向き合い方

• 仕様駆動開発の理想と現実、そして向き合い方 - Speaker Deck

(2025/11/20)

Goで挑む大規模データ処理

• Goで挑む大規模データ処理 | ドクセル

(2025/11/19)

APMを支えるデータ構造とアルゴリズム

• APMを支えるデータ構造とアルゴリズム - Mackerel ブログ #mackerelio

(2025/11/19)

【libxml2】libxml2プロジェクトは放棄されました

• 【libxml2】libxml2プロジェクトは放棄されました #Security - Qiita

要約:

■ 1. libxml2のセキュリティポリシー変更

• libxml2のリポジトリに新しいテキストが追加された
• 内容:
  • 趣味人たちによって開発され、たった一人のボランティアによってメンテされているオープンソースソフトウェアである
  • テストは適当で、メモリ安全ではなく、セキュリティバグも満載である
  • 信頼できないデータに対してこのソフトウェアを使用するのは愚かな行為である
  • セキュリティバグは他のバグと同様に扱われる
  • 受け取ったセキュリティバグ報告は全てただちに公開され、優先的に修正されることもない

■ 2. libxml2の概要

• XMLを処理するライブラリである
• 多くのLinuxディストリビューションやプログラミング言語に導入されている
• ChromeやSafariといったWebブラウザでも使われている
• 事実上業界標準と言える
• PHPにもあり、DOMやSimpleXMLなどがlibxml2に依存している
• 2000年ごろにDaniel Veillardによって作成された
• 2013年ごろからNick Wellnhoferが貢献を始めた
• 現在はNick Wellnhoferがほぼ一人で保守を行っている

■ 3. 協調的脆弱性開示プロセスの背景

• セキュリティバグは基本的に通常のバグ報告と異なる扱いがなされる
• いきなりGitHubやその他メディアなどでセキュリティバグが公開されると、修正が間に合わないうちに攻撃者に利用されてしまうためである
• セキュリティバグについては各企業のバグバウンティプログラムやHackerOne、IPAなどの機関に報告し、修正されるまで待ってから公開する手順が確立された
• 報告を受けた側も修正版がリリースされるまではセキュリティバグについては黙っておくのが通例である
• これは協調的脆弱性開示プロセスと呼ばれ、現在では多くの開発者やアプリケーションがこのプロセスに従っている
• libxml2はこの業界標準を無視し、セキュリティバグも一律全て公開する、攻撃者に利用されても知ったことではない、という斬新なセキュリティ対策に方針を切った
• 対応されてなかろうが90日で開示というポリシーを強行して大批判を食らったGoogle Project Zeroのはるかに上を行く対応である

■ 4. メンテナーの経緯:Stepping down(2021年7月22日)

• 特に頼んだわけでもないが、いつのまにかlibxml2とlibxsltの事実上のメンテナーになっていた
• 幸いなことにChrome VRPバグバウンティとOSS-Fuzz Integration rewardsによって報酬を得ることができていた
• Googleのこれらの優れたプログラムに感謝する
• 残念ながらセキュリティからの収益が急減しており、最低限の資金を確保するめども立たなくなった
• そのためコントリビュータ・メンテナを退任することにした

■ 5. メンテナンスの再開(2022年1月10日)

• Googleからの寄付のおかげで2022年はlibxml2とlibxsltのメンテナンスを継続できるようになった

■ 6. セキュリティ問題への対応(2025年5月8日)

• 毎週何時間も第三者から報告されるセキュリティ問題への対応に追われている
• これらの問題のほとんどは致命的ではないが、それでも大きな作業である
• 無給のボランティアにとってこれは持続不可能である
• libxml2の開発を継続できるようにいくつかの変更を考えている
• 基本的な考え方はセキュリティバグを他のバグと同じように扱うということである
• セキュリティバグはただちに公開され、他のバグと同じ優先度で扱われる
• この方針は一部のダウンストリームを不安に陥れるかもしれないが、もしかしたら貢献意欲を高めるきっかけになるかもしれない

■ 7. OpenSSFとセキュリティ業界への批判

• 長年この仕事をしてきたので、セキュリティ問題に関わる秘密主義のほとんどはただの茶番にすぎないものであるとわかっている
• OpenSSFのような「ベストプラクティス」は、大手テクノロジー企業がOSSメンテナーに罪悪感を抱かせ、無償で働かせようという圧力に過ぎない
• 最近個人経営している会社をOpenSSFのメンバーにしようとした
• そのためにはまずLinux Foundationのメンバーになる必要があり、これは最低でも年間1万ドルかかる
• これらは非常に排他的な組織であり、なにひとつオープンではない
• いまこそ彼らとその支援者を非難すべき時である
• 長期的にはOSSメンテナーに報酬も払わずにこのような要求を課すことは有害である
• 最近libxsltのメンテナーを辞任したが、このライブラリがふたたびメンテナンスされる可能性はほとんどない
• Google Project Zeroという金で買える最高のセキュリティ研究者がボランティアの首根っこをひっつかんでいる現状では、その可能性はさらに低い

■ 8. 企業の責任への批判(2025年5月10日)

• 肝心な点はそもそもlibxml2はブラウザやOSクラスが使用できるレベルの品質を備えていなかったということである
• Appleがlibxml2をOSのコアコンポーネントに導入したことが始まりだった
• その後Googleも追随し、今ではMicrosoftでさえlibxml2を使用している
• このようなことは決してあってはならないことだった
• 元々は成長のハックのようなものだったが、いまでは彼らは数十億ドルの利益を上げている
• しかしより優れたソリューションへの切り替えや自主開発、libxml2の改善といったフィードバックはない
• これらの企業の態度は無責任である
• 彼らはユーザのセキュリティやプライバシーなど気にもかけておらず、対症療法を行っているにすぎない
• もうこのゲームには参加しない
• 彼らがlibxml2の使用をやめれば、このプロジェクトの健全性は向上する

■ 9. メンテナー退任(2025年8月15日)

• libxml2のメンテナーを退任することにした
• つまりこのプロジェクトは現在ほぼメンテナンスされていないということである
• ここ最近libxml2を触っているのはNick Wellnhoferほぼ一人であり、彼が辞めるということはすなわちプロジェクトの放棄と同義である
• libxsltについては最近Iván Chaveroが後任に名乗りを上げたが、contributionもまだまだといったところである
• libxml2については今後どうなるか未知数である

■ 10. OpenSSFの実態

• OpenSSFはオープンソースソフトウェアの開発・保守を持続的に行うことを推進する組織である
• 有名どころとしては協調的脆弱性開示プロセスの策定・推進などがある
• 協調的なビジョンを達成するためには最低でも年間1万ドルの課金を要求する
• 実際のOSS開発者に貢献が還元されることは特にない

■ 11. Google Project Zeroへの批判

• 協調的脆弱性開示プロセスはOSSメンテナーにタダ働きを行わせるための脅迫でしかないという主張である
• 実際問題としてGoogle Project Zeroはオープンソースが相手でも脆弱性の指摘しか行わず、脆弱性を修正したりパッチを作成したりすることはない
• 高い給料もらってるんだからパッチも書けよといった批判も多々上がる
• 批判の声:
  • 「Googleが真剣にハッカー対策をしたいのであればパッチを送ったり資金援助したりするでしょう。彼らは単にCVEバッジを集めたいだけです」

■ 12. 現状と今後の展望

• 実は「放棄された」は言い過ぎで、現在は「メンテナがいない」状態であり、誰かが後任に立候補すれば開発は継続される
• しかしメンテナになったところで報酬も利益もなく、負わされるのは時間と責任だけという損しかない立場である
• そのような立場に好き好んで入り込むのはよほど風変わりな人しかいない
• libxml2はあらゆるOSやブラウザや言語にまで入り込んでいる重大なライブラリである
• そんな根幹の部分がこんなことになっている現状、今後のOSSはどこに向かっていくのか不透明である

MEMO:

• あらまぁ
• とはいえ、大手で使われているなら何処かがメンテを引き継ぐだろう（楽観論）
• あるいは、新規機能の追加をせずセキュリティフィックスのみならAIに任せても良いのではないか？

(2025/11/19)

jmespath/go-jmespath: Golang implementation of JMESPath.

• GitHub - jmespath/go-jmespath: Golang implementation of JMESPath.

MEMO:

• JSONを宣言的にクエリ（検索・抽出・整形）するライブラリ
• 簡単なサンプル

package main

import (
    "encoding/json"
    "fmt"

    jmespath "github.com/jmespath/go-jmespath"
)

func main() {
    // 1. JSONデータを Goの interface{} に変換する
    jsonData := []byte(`
    {
        "users": [
            {"name": "Alice", "age": 30, "city": "Tokyo"},
            {"name": "Bob", "age": 25, "city": "Osaka"}
        ],
        "status": "ok"
    }
    `)

    var data interface{}
    if err := json.Unmarshal(jsonData, &data); err != nil {
        panic(err)
    }

    // 2. JMESPathクエリを実行する
    // クエリ: "users"配列から、各要素の "name" の値だけを抽出して配列にする
    query := "users[*].name"

    result, err := jmespath.Search(query, data)
    if err != nil {
        fmt.Println("Error:", err)
        return
    }

    // 3. 結果を表示する
    // resultは interface{} 型で返される
    fmt.Printf("Query: %s\n", query)
    fmt.Printf("Result Type: %T\n", result)
    fmt.Printf("Result Value: %v\n", result) 
    // Output: Result Value: [Alice Bob]
}

• 簡単なフィルタならsamber/loを使った方がシンプルだろうか

(2025/11/19)

遂行力はどこで差がつくのか

• 遂行力はどこで差がつくのか｜ryottaman

要約:

■ 1. プロジェクトの文脈把握

• 着手前にプロジェクトの背景と意味を短時間で整理する
• 文脈の要素:
  • クライアントが達成したいこと
  • 読者や顧客の置かれた状況
  • 関係者が大切にしたい価値
  • タスクが全体で持つ役割
• 依頼内容が曖昧な場合でも「この案件は最終的に何をよしとするか」だけ先に確認する
• 文脈が整っているため判断にずれが生じない

■ 2. 完璧主義を避けた動的な進行

• 全てが揃わないと動けないタイプではない
• 動くことで目的の精度を上げていく手法を採用する
• 具体的な進め方:
  • 最小限だけ整えてまず動く
  • 仮の流れをつくって全体像を見る
  • 動かす中で深掘りが必要な箇所を判断する
  • 依頼者には要点だけ短く確認する
• 止めるのではなく進めながら整えるため、プロジェクトが滞らない

■ 3. 工程の事前設計

• 目の前のタスクだけでなく、その後に起きることを早い段階で組み立てる
• 設計される要素:
  • 議事録の粒度や優先順位
  • 記事や資料構成の作り方
  • 誰の判断がどこで必要か
  • 編集から校正、公開までの流れ
• 工程が設計されているため、その場の判断がほぼゼロになる
• 任せていても進行が乱れない理由はここにある

■ 4. 予定の先置きによるペース管理

• 期日を受け身で待つのではなく、自分から先に予定を決めて共有する
• 具体的な先置きの例:
  • 「〇日午前にドラフト送りますね」
  • 「午後に方向性だけ合わせましょう」
  • 「その後は〇日までに進めます」
• 先置きによって関係者の動き方が決まり、全体のテンポが整う
• 気分や混雑に左右されないリズムが生まれる

■ 5. 初動の早さと周囲への配慮

• 外向的でも積極アピール型でもないが、仕事が前に進む
• 初動の早さが理由である
• 具体的な行動:
  • 不明点は早めに依頼者へ確認する
  • 途中段階をすぐ共有する
  • 次の人が作業しやすい形で渡す
  • クライアントが判断しやすい状態を整える
• 初動が早いと相手の返答も早くなり、全体が前へ転がりやすくなる

■ 6. 原因帰属ではなく打ち手志向

• プロジェクトが進まない理由を外部に置く言葉を使わない
• 使わない言葉:
  • 「返事が遅いから進まない」
  • 「条件が揃わないから無理」
  • 「指示が曖昧だから止まってしまう」
• 使う言葉:
  • 「ここだけ確認できれば進めます」
  • 「一旦この形で前に出しておきますね」
  • 「先に必要な材料を揃えておきます」
• 原因ではなく打ち手を見る姿勢が自然体の強さにつながっている

■ 7. 推進力の本質

• 推進力は説明の上手さや強い主張から生まれるものではない
• 推進力を構成する要素:
  • 文脈をつかむ
  • 動きながら目的を整える
  • 工程を先に設計する
  • 予定でリズムをつくる
  • 初動を早くする
  • 外に原因を置かない
• この積み重ねがプロジェクトを止めない土台になる
• 自然体、素直、誠実という姿勢が信頼を生み、進め方が推進力を裏打ちする
• 推進力は勢いではなく「整える力」の総量で決まる

MEMO:

• 一般論の列挙という感じである

(2025/11/18)

仕様がそのままテストになる！Javaで始める振る舞い駆動開発

• 仕様がそのままテストになる！Javaで始める振る舞い駆動開発 - Speaker Deck

(2025/11/18)

【大刷新】PMBOK®の第8版がでた #プロジェクトマネジメント

• 【大刷新】PMBOK®の第8版がでた #プロジェクトマネジメント - Qiita

第7版の「原則」と第6版の「プロセス」が合体した

第6版「5つのプロセス群」が「フォーカスエリア」として復活し、「40のプロセス」として帰ってきた。が内容は7版ベース

各プロセスのInput/Output,ツール,技法(=ITTOs)など実務的な「統合版」になった

(2025/11/17)

新著が出ます：『NewSQL徹底入門』

• 新著が出ます：『NewSQL徹底入門』｜ミック

MEMO:

• もう本書くことはないって言ってなかったか
• 新著が出ます：『達人に学ぶ SQL徹底指南書 第2版』 - ミックのブログ

既存の書籍の改訂を除けば、おそらく本書が、私がRDBやSQLについて書く最後の本になると思います（そのあたりの事情については次回エントリで触れます）。

• RDBの本ではないってことか

(2025/11/17)

fluent-bitでdocker composeのログを収集する

• fluent-bitでdocker composeのログを収集する - doc.dev1x.org

MEMO:

• docker composeで起動している全てのコンテナのログをfluent-bitで収集してコンテナ単位で処理するという普通にありそうなユースケースの情報がネットには転がっていなかったので調査した
• fluent-bit開発元からはそういうのはkubernetisでやればいいじゃんという雰囲気を感じる
• あるいはfluentロギングドライバ使えばいいじゃんとか
• 実際fluent-bitのDocker関連の機能は殆どがdeprecatedか廃止済み
• 古い情報が多くAIもハルシネーション多発で使い物にならなかった
• コンテナログを直接tailするのはその方がロバスト性が高そうな気がしたから
• fluentロギングドライバを使えばコンテナ名がタグに入るけど、その為にポート占有させるのもちょっと微妙な気がした

(2025/11/17)

令和時代の API 実装のベースプラクティスと CSRF 対策

• 令和時代の API 実装のベースプラクティスと CSRF 対策 | blog.jxck.io

要約:

■ 1. CSRF攻撃の成立条件

• CSRF(Cross-Site Request Forgery)は古くから知られる攻撃手法である
• 攻撃者が用意したサイトに仕込まれたフォームから、ユーザがログイン中のサービスに対してリクエストを送信する攻撃である
• ログイン済みのCookieが付与されたリクエストがサービスの投稿APIに準拠していれば、そのユーザのアカウントで不正な投稿が受理される
• 攻撃の手軽さと影響の大きさによって、XSSやSQLインジェクションと並ぶ有名な攻撃手法として認知された
• 従来の対策としては、One Time Token(CSRFトークン)をフォームに仕込み、トークンの一致によって投稿を受理する方法が一般的だった

■ 2. CSRF成立の本質的問題点

• CSRF攻撃が成立する根本原因は「攻撃者のフォームからのリクエストにもサービスのCookieが付与される」点である
• しかし、CSRFトークンが機能していた事実は「このリクエストはどこから来たものなのか」が分かれば対策できる証拠である
• 本来注目すべき欠落は「リクエストの出自がわからない」という点である
• SameSite Cookieの導入によって別のサイトからのリクエストにCookieが付与されないようにすることは対策として成立するが、本質的な問題はリクエストの出自が不明であることである

■ 3. Originヘッダの付与

• プラットフォームの回答は「リクエストにOriginヘッダを付与する」というものである
• 現在のブラウザでフォームをsubmitすると、送られるリクエストにOriginヘッダが付与される
• Originヘッダの値を確認すれば、リクエストが正規のサイトからではないことを容易に判別できる
• Cookieの有無に関わらず、サービスは「意図しないOriginからのリクエスト」を弾くことができる
• このヘッダの必要性は少なくとも16年前から議論されており、7年前にFirefoxが実装することで全てのブラウザがフォームのsubmitにOriginヘッダを付与するようになった
• SameSite Cookieが導入されるずっと以前から「リクエストの出自を知る」ことは可能であり、それを用いて攻撃リクエストを弾くことができた
• fetch()を用いた実装でOriginを確認しながら適切なAccess-Control-Allow-Originを返していれば、「どこから来たかわからないリクエスト」を弾くことはずっと可能であった

■ 4. SameSite Cookieの副次的効果

• SameSite Cookieの登場により、積極的な対策をしてこなかったサービスも受動的な変更によって保護される結果になった
• しかしこれはかなり副次的な効果である
• SameSite Cookieの本来の目的は3rd Party Cookieをマークすることであり、3rd Party Cookie Deprecateの終着点はSameSite=None Cookieが送られないようにすることである
• CSRFは3rd Party Cookieよりも遥かに古くから問題だったが、「サイトを跨いだCookieが送られること」よりも「リクエストの出自がわからないこと」の方がプラットフォームが対策すべき問題とされていた
• SameSite Laxがデフォルトになったことを理由に「Originのチェック」を怠った実装は、本質的な対策を怠った片手落ちの実装である

■ 5. CSRFトークンの必要性の再検討

• OWASPのCSRF Cheat Sheetでは今でもトークンベースの対策が推奨されている
• トークンベースの対策を推奨する理由として以下が挙げられる:
  • XSSがあった場合の対策
  • ヘッダを改変している可能性
  • GETでAPIがあると成立する攻撃
  • サブドメインが乗っ取られる攻撃
• XSS問題の反論:
  • XSS自体を対策すべきであり、XSSによってDOMに展開されたCSRFトークンを盗めない道理はない
• ヘッダ改変問題の反論:
  • ブラウザや拡張に脆弱性があれば、サービス側の対策はバイパスできるため、サービス提供者が想定すべき対策として視点がずれている
  • ユーザ設定やProxyが意図的にOriginヘッダを改変する環境は、ルールを守っていないためサービス側が許容する必要はない
• GET API問題の反論:
  • 様々な条件でSameSiteやOriginが機能しないリクエストを生成できるという指摘は、「APIがGETだった場合に攻撃が成立する」という条件に収束する
  • 副作用のあるAPIをGETで提供している実装は前提として間違っている
• サブドメイン攻撃の反論:
  • SameSite Cookieだけに依存した対策は問題があるため、一次防御は「リクエストのOriginのチェック」である必要がある
• CSRFトークンの利点:
  • 実装がこなれており堅牢である
  • フレームワークがデフォルトで提供することが多く、導入コストが低い
  • 現状入っているなら積極的に外す理由はない
• 防御の認識の変更:
  • CSRFトークンは一層目の防御ではなく、多層防御の二層目であると認識すべきである
  • トークンを使用していても「リクエストの出自を確認する」実装は一層目にあるべきである
  • 全ての場所でOriginを確認するのがプラクティスである

■ 6. Fetch Metadataの導入

• 本来は全てのリクエストにOriginをつけるべきだが、「OriginヘッダのあるリクエストはXHRからのもの」という前提の実装が蔓延していたため、ドラスティックな変更ができなかった
• Originヘッダとは別にFetch Metadataが定義された
• 現在のブラウザでは以下のヘッダが付与される:
  • Sec-Fetch-Dest
  • Sec-Fetch-Mode
  • Sec-Fetch-Site
  • Sec-Fetch-User
• リクエストの出自を確認する手法は整備されており、これらを無視することはプラットフォームが差し伸べている手を振り払うことと同じである

■ 7. 令和時代の実装プラクティス

• 副作用があるエンドポイントの実装における優先順位:
  • POSTにする(副作用のあるAPIをGETにしない)
  • Originを確認する
  • SameSite Lax/Strictを明示する
  • Fetch Metadataも確認する
• Fetch Metadataのサポートに不安がある場合は「存在したら値をチェックする」実装でも良い
• Sec-プレフィックスはJavaScriptから操作できないヘッダであるため、値がある場合だけのチェックでも意味がある
• 実装の特徴:
  • 追加のストレージコストが不要である
  • コードだけで実装できるためレイテンシーが最小である
  • フレームワークのレールの基盤として存在することが望ましい
• この実装から逸脱するコードが必要になった場合、プラットフォームが推奨するレールから外れていることを認識した上で、CORSなどの適切な対策をしながら拡張すべきである
• このベースを伴わずにトークンを載せても片手落ちである
• この実装をベースにしてもトークンがないと防げないCSRFが可能であれば、それはプラットフォームにおけるバグの可能性が高く、W3CのWebAppSecなどで議論すべき題材である

(2025/11/16)

みんなが管理職やりたがらないのでやる気満々の新卒2年目でも手を挙げれば管理職になれる現場になったが...

• みんなが管理職やりたがらないのでやる気満々の新卒2年目でも手を挙げれば管理職になれる現場になったがトラブルが重なり逆に年齢制限ができた - Togetter

(2025/11/16)

乱雑なコードの整理から学ぶ設計の初歩

• 乱雑なコードの整理から学ぶ設計の初歩 - Speaker Deck

(2025/11/16)

次世代ソフトウェア開発：2030年までに標準となる20の革新的手法

• 次世代ソフトウェア開発：2030年までに標準となる20の革新的手法 | Forbes JAPAN 公式サイト（フォーブス ジャパン）

(2025/11/16)

アーキテクチャと考える迷子にならない開発者テスト

• アーキテクチャと考える迷子にならない開発者テスト - Speaker Deck

(2025/11/16)

旧から新へ: 大規模ウェブクローラの Perl から Go への移行

• 旧から新へ: 大規模ウェブクローラの Perl から Go への移行 / YAPC::Fukuoka 2025 - Speaker Deck

MEMO:

• はてなアンテナってまだ稼働してたのか

(2025/11/15)

Should You Stop Using Prisma? Why Database ORMs Might Be the Worst Thing That Happened to...

• Should You Stop Using Prisma? Why Database ORMs Might Be the Worst Thing That Happened to Backend Development | by Sohail Saifi | Medium

要約:

■ 1. Prismaの問題提起

• 3年間のPrisma本番運用後、パフォーマンス問題とサーバーレスコスト高騰を経験
• データベースアクセスを容易にすると約束したツールが最大のボトルネックに
• ORM全般の根本的問題:生産性と型安全性を約束したが複雑さとパフォーマンス問題をもたらした

■ 2. Prismaの魅力と落とし穴

• 魅力的なマーケティング:
  • 型安全なデータベースアクセス
  • 自動マイグレーション
  • SQLを書く必要がない
  • 単一のスキーマファイルで全てを生成
• クリーンで読みやすく型安全なコードに見えるが実際は問題だらけ

■ 3. パフォーマンスの現実

• バンドルサイズ:
  • Drizzleは約1.5MB
  • Prismaは約6.5MB
  • サーバーレス環境では重大な影響
• N+1問題の深刻化:
  • 一見単純なクエリが実際には数十のデータベースラウンドトリップを生成
  • 単一のJOINクエリであるべきものが47個の個別SQLステートメントを生成した事例
  • フロントエンドでTanStack Queryを使ってこの問題を回避したのにバックエンドでPrismaにより再現

■ 4. サーバーレスでの悪夢

• AWS Lambdaのコールドスタートが200msから2.5秒に増加
• Prismaが実行前に必要な処理:
  • Rustベースのクエリエンジンバイナリのロード
  • 内部GraphQLサーバーの起動
  • コネクションプーリングの初期化
  • クライアントインターフェースの生成
• Drizzleのような軽量ソリューションではサーバーレス関数のロードと実行がPrismaより遥かに高速

■ 5. 開発者体験の幻想

• Prismaの最大のセールスポイントは開発者体験(DX)
• 実態:シンプルなことに対する優れたDXは複雑なことに対する酷いDXを意味する
• スキーマロックイン:
  • 全てがschema.prismaファイルを中心に回る
  • PrismaのDSLに収まらないことをする場合は困難
  • PostgreSQLのJSONB演算子などデータベース固有機能の使用が困難
  • 複数テーブルの式(CTE)を含む複雑なクエリは生SQLに戻る必要があり、パラダイムを混在させ型安全性を失う

■ 6. コード生成の問題

• スキーマを変更するたびにprisma generateを実行する必要
• 数千行のTypeScriptコードを再生成
• IDEがフリーズし、ビルドプロセスが遅延
• 実行を忘れると型とデータベースが同期しなくなる
• Drizzleではスキーマへの変更が即座に反映される(コード生成不要)

■ 7. マイグレーションの悪夢

• デモでは素晴らしく見えるが本番では別の話
• データ損失の設計:
  • カラム名変更時にPrismaは名前変更として検出せず、古いカラムを削除して新しいカラムを作成
  • そのカラムの全データが消失
• Drizzleは名前変更の可能性を検出すると対話モードに入り意図を選択させる
• ブラックボックス問題:
  • PrismaがSQLマイグレーションを生成するが手書きとは異なる
  • 冗長で非効率な場合があり、レビューが困難
  • マイグレーションをカスタマイズする際はツールと戦うことになる

■ 8. 抽象化の真のコスト

• Ted Newardは2008年にORMを「コンピュータサイエンスのベトナム戦争」と呼んだ
• ORMはオブジェクト指向コードとリレーショナルデータベース間のインピーダンスミスマッチを排除すると約束
• 実際には排除せず隠蔽するだけ
• 抽象化がリークすると(常にリークする)、ORMの癖と生成されるSQLの両方を理解する必要があり、開始時より悪化

■ 9. 優れた代替案

• Drizzle:
  • SQLを知っていればDrizzleを知っている
  • コード生成不要、バイナリ不要、魔法なし
  • パフォーマンスはPrismaより桁違いに高速
  • バンドルサイズ1.5MB対Prismaの6.5MB
• 型安全性を持つ生SQL:
  • RustのSQLxはコンパイル時チェック付きSQLクエリをランタイムオーバーヘッドゼロで実現
  • TypeScriptではKyselyが同様の利点を提供
• 生SQLの方が実際には優れているという動き:
  • より透明:どのクエリが実行されているか正確に分かる
  • より高パフォーマンス:抽象化オーバーヘッドがない
  • より移植性が高い:SQL知識がプロジェクト間で転用可能
  • より安全:インジェクションリスクを認識しているためより慎重になる

■ 10. セキュリティへの影響

• ORMはSQLインジェクションを防ぐためより安全とされるが新しいセキュリティ問題を導入
• マスアサインメント脆弱性:
  • リクエストボディに予期しないrole: 'admin'フィールドが含まれていると管理者ユーザーを作成してしまう
  • 生SQLではどのフィールドを更新するか明示的に指定するためこのパターンは起こりにくい
• 過剰なデータベース権限:
  • ORMは機能するためにより広範なデータベース権限を必要とすることが多い
  • テーブルスキーマ情報のクエリ、メタデータへのアクセス、リフレクションの実行が必要
  • 最小権限の原則に違反

■ 11. バンドルサイズ問題

• 2024年ではバンドルサイズが重要
• AstroやSvelteKitのようなフレームワークは最小限のJavaScriptを強調
• しかしバックエンドに6.5MBのORMを追加
• エッジコンピューティングとサーバーレス関数では全てのキロバイトが重要
• Cloudflareの無料プランは3MB制限でPrismaはビジネスロジックを1行も書く前にその半分以上を消費

■ 12. ORMが依然として意味を持つ場合

• ラピッドプロトタイピング:何かを素早く動作させる必要がありパフォーマンスが重要でない場合
• ジュニアチーム:チームに強力なSQLスキルがない場合、ORMはガードレールを提供
• シンプルなCRUDアプリケーション:複雑な関係性のない基本的な作成・読取・更新・削除操作
• エンタープライズ要件:一部の組織はコンプライアンスや標準化の理由でORMを義務付け

■ 13. 移行戦略

• 新機能から開始:全てを一度に書き直さず、選択した代替案で新機能を構築
• パフォーマンスボトルネックの特定:プロファイリングを使用して最も遅いデータベース操作を見つける
• ドメインごとに移行:アプリケーション内の境界付けられたコンテキストを選び、そのデータベースアクセスを全て一緒に移行
• ツールへの投資:適切なデータベースマイグレーションツール、クエリビルダー、型生成をセットアップ

■ 14. 結論

• Prismaから離れることでサーバーレスコストを40%削減、パフォーマンスを3倍改善、コードベースの保守性向上
• データベースをより深く理解することを強制された
• データベースを単なるストレージレイヤーとして扱うのをやめ、その力を活用し始めた
• クエリがより効率的になり、データモデルがよりクリーンになり、デバッグセッションが短縮
• ORMは複雑さを隠すことで生産性を高めると約束したが、実際には複雑さは隠されておらず、手遅れになるまで見えない場所に移動していただけ
• データベースから隠れるのをやめ、受け入れ始める時かもしれない

MEMO:

• そりゃそうやろという感想がある

(2025/11/14)

ニューレガシーアンチパターン

• ニューレガシーアンチパターン - kawasima

(2025/11/13)

AI 時代のドキュメント管理術

• AI 時代のドキュメント管理術 - Speaker Deck

(2025/11/13)

なんで最近の新しいテクノロジーはディストピアSF映画からのインスパイアみたいな感じなのか？

• なんで最近の新しいテクノロジーはディストピアSF映画からのインスパイアみたいな感じなのか？ - YAMDAS現更新履歴

(2025/11/12)

チームを壊す「ブリリアントジャーク」とどう向き合うか―スクラムマスターとしての実践と学び―

• チームを壊す「ブリリアントジャーク」とどう向き合うか―スクラムマスターとしての実践と学び―

要約:

■ 1. ブリリアントジャークの定義

• 優秀だが厄介な人を意味する
• 知識も技術も豊富だが他者への配慮や共感が欠ける
• 結果としてチーム全体の心理的安全性を壊す
• アジャイル開発では透明性・協働・自己組織化が重要だがコミュニケーションを軽視する態度が続くとチームの信頼関係が崩れる
• 生産性だけでなくメンタル面にも悪影響を及ぼす

■ 2. 発生した状況

• 経験豊富で技術力の高いメンバーがいた
• レビューの精度も高く幅広い知識を持っていた
• 一方で他のメンバーに対して厳しい言葉をかけることが多い
• 議論の場では自分の意見を強く主張する傾向
• チーム内の変化:
  • チーム内で発言する人が減る
  • 意見が対立すると議論が止まる
  • ミスを恐れて挑戦を避けるようになる
  • タスクの透明性が下がる
• チーム全体の空気が重くなりスクラムイベントも形骸化
• ブリリアントであるはずの存在がチームを静かに壊していった

■ 3. 初動の失敗

• 相手を理解しようと考えブリリアントジャーク本人との1on1やヒアリングを重ねた
• 結果的に問題の先送りに過ぎなかった
• 本人も悪気はない、相手に合わせればうまくいくかもしれないと考えて直接的な指摘を避けた
• この判断はスクラムマスターとしての誤り
• 人間関係の摩擦として捉えチーム全体の心理的安全性という観点を見落とした

■ 4. 方針転換

• チームのモチベーションが下がる中で方針を切り替えた
• 個人への歩み寄りではなくチーム全体を守るための行動を取ることに決定
• 具体的なステップ:
  • 現状を客観的に整理:問題の発言や行動を具体的に記録し事実ベースで状況把握
  • 関係者と情報共有:チーム外のマネジメント層や関係者に相談し客観的な視点で見てもらう
  • チームへのサポート:疲弊しているメンバーにフォローの時間を設け安心して意見を言える環境を再構築
• チーム全体の合意を得ながら担当業務や役割を調整する形で体制を見直した

■ 5. 結果

• 体制変更後チームの雰囲気は驚くほど改善
• 改善の具体例:
  • ミーティングでの発言が増え議論が活発に
  • 新しいアイデアや改善提案が出るようになる
  • チームの生産性が向上し遅れていたスケジュールを挽回
• チームが協力して成果を出すというアジャイルの本質に立ち返ることができた

■ 6. 学びと教訓

• 個の能力よりチーム全体の健全性を守ることが最優先:
  • どれほど有能でもチームを壊す言動を放置してはいけない
  • 成果を上げるのは個人ではなくチーム
• 問題は早期に毅然とした態度で対応する:
  • 違和感を感じた段階で客観的に相談・共有することが大切
  • 言いづらいから放置は最終的に全員の負担を増やす
• 心理的安全性をチーム文化として根付かせる:
  • 誰もが意見を出せる環境を維持すること
  • その文化があればブリリアントジャークの影響は最小化できる

■ 7. 結論

• ブリリアントジャークはどの現場にも潜むリスク
• 防ぐ方法は特別なものではない
• 透明性・信頼・早期対応の3つを意識し続けるだけでチームは崩壊を防げる
• スクラムマスターの役割は課題を抱え込むことではなくチームの安全と健全性を守ること
• ブリリアントな個人よりも協働するチームこそが最大の力を発揮する

MEMO:

• なんか記事消えた

(2025/11/12)

さくらのクラウド、コンテナをサーバレスで実行する「AppRun」を正式サービスとして提供開始へ

• さくらのクラウド、コンテナをサーバレスで実行する「AppRun」を正式サービスとして提供開始へ － Publickey

MEMO:

• おぉー

(2025/11/12)

kubernetes でケチケチ節約して複数のサイトを管理する

• kubernetes でケチケチ節約して複数のサイトを管理する

MEMO:

• kubernetesでやる必要性があるだろうか？
• 月間のコストはどれぐらいだろうか？
• 無料枠で収まる？
• 静的サイトなら適当なホスティングサービスを使えばよいのではないか？
• などなど

(2025/11/12)

「丁寧で的確な引継ぎ」がめったに実践されない理由を解剖する【パウリ】

• 「丁寧で的確な引継ぎ」がめったに実践されない理由を解剖する【パウリ】 | レバテックラボ（レバテックLAB）

(2025/11/11)

「完全なコピーは現存しない」と言われていた52年前にベル研究所で作成されたUNIX V4を記録したテープ...

• 「完全なコピーは現存しない」と言われていた52年前にベル研究所で作成されたUNIX V4を記録したテープが倉庫で見つかる - GIGAZINE

(2025/11/11)

MIT、AI時代の新開発論を提唱。「可読性の高いソフトウェア」は

• MIT、AI時代の新開発論を提唱。「可読性の高いソフトウェア」は"バイブコーディング"を終わらせるか | XenoSpectrum

要約:

■ 1. バイブコーディングの問題提起

• 大規模言語モデル(LLM)によるコード生成がソフトウェア開発の風景を一変させた
• 多くの開発者は雰囲気(vibe)に頼ったコーディングの危うさを感じ始めている
• MITの研究チームが概念と同期という2つの要素を核とした新しいソフトウェア構造パターンを提案
• 人間とAI双方にとって可読性の高い(legible)ソフトウェアの実現を目指す

■ 2. 機能の断片化問題

• 現代のソフトウェアは内部構造が極めて複雑化
• 一つの機能(例:SNSアプリのシェアボタン)でもロジックが投稿、通知、ユーザー認証などコードベースの複数箇所に散らばる
• MITのDaniel Jackson教授がこれを機能の断片化と呼び、システムの保守性や信頼性を著しく低下させる根源的課題と指摘
• LLMの台頭によってこの問題がさらに深刻な形で顕在化

■ 3. AIコード生成の課題

• GitHubの最新データではAIによるコード支援は普遍的となり開発効率を飛躍的に向上
• プロセスはバイブコーディングと揶揄される
• LLMは驚くべき速さでコードを生成するが既存システムとの相互作用や副作用を完全には理解していない
• 既存コードベースへの機能追加指示で意図しないモジュール変更や既存機能破壊が頻発
• 堅牢なコーディングに不可欠な3要件の欠如:
  • インクリメンタリティ(局所的変更で小さな改善を重ねる能力)
  • インテグリティ(既存機能を破壊しない能力)
  • トランスペアレンシー(変更内容や実行時動作が明確であること)

■ 4. 概念(Concepts)の定義

• ユーザーが認識する機能の自己完結した単位
• SNSアプリでは投稿、コメント、いいね、フォローといった個々の機能が独立した概念として定義
• 特徴:
  • 自己完結性: 各概念は自身の状態と実行可能なアクションを保持
  • 独立性: 概念同士が直接的な依存関係を持たない
• 特定機能の修正・拡張時に他機能のコードを気にする必要がない
• マイクロサービスと類似するが決定的な違いは概念が互いに完全分離されている点
• マイクロサービスは相互にAPI呼び出しでもつれたクモの巣のような依存関係を生み出しがち

■ 5. 同期(Synchronizations)の役割

• 独立した概念間の相互作用を記述するための宣言的なイベントベースのルールセット
• 複雑な手続き型コードではなく「何が起きたら何をするか」というルールを定義
• 記述例:
  • ユーザーAが投稿Pにコメント実行時(when)
  • 投稿Pの作者がユーザーBならば(where)
  • 通知概念の送信アクションをユーザーBに対して実行(then)
• ドメイン特化言語(DSL)を用いてシンプルかつ明確に記述
• 宣言的性質によりルールセット全体の見通しが向上
• LLMによる自動生成や形式的検証も容易

■ 6. AIとの相性の良さ

• LLMに与えるコンテキストを限定可能:
  • 概念のコード生成時はその概念の仕様のみに集中すればよい
  • アプリケーション全体の複雑さを考慮不要
  • 同期ルール生成時も各概念のインターフェース仕様の理解で足りる
• LLMへの指示(プロンプト)がシンプルになり生成コードの精度と信頼性が劇的に向上

■ 7. バグ修正事例

• 問題: ユーザー登録フローで不正パスワード試行後に正しいパスワードで再試行すると「ユーザーが既に存在する」エラーが発生
• 新モデルでの解決プロセス:
  • 問題が発生した一連の処理(フロー)を特定
  • そのフローに関連する同期ルール群を抽出
  • 抽出したルール群と問題概要をLLMに提示し修正方法を問う
• LLMの回答:
  • パスワード検証前にユーザー作成が行われていることが原因と特定
  • まずパスワード検証し成功時のみユーザー作成という修正案を新しい同期ルールとして提示
• システム動作が明示的ルールとして記述されているからこそ可能な人間とAIの理想的協調作業

■ 8. 実証実験の成果

• RealWorldベンチマークアプリケーション(Mediumのようなブログプラットフォーム)のバックエンドを実装
• 従来実装では複数サービスやモジュールにまたがっていたお気に入り登録やタグ付け機能が単一の概念として明確にカプセル化
• システムの可読性と保守性が大幅に向上
• LLMを用いた各概念の仕様書・コード・同期ルール生成プロセスもほぼ成功
• 提案モデルが理論上のものではなく実用的な開発手法として機能することを証明

■ 9. 専門家の評価

• バージニア大学Kevin Sullivan准教授の評価:
  • 人間の理解に基づいた抽象化である概念の上にソフトウェアを構築することを主張
  • ソフトウェア設計の理論と実践における新しく重要な方向性

■ 10. 将来展望

• Jackson教授が描く未来像:
  • 再利用可能な概念を集めたライブラリであるコンセプトカタログの構築
  • コンセプトは新しい種類の高レベルプログラミング言語になる可能性
  • シンクロナイゼーションはその言語で書かれたプログラムになる可能性
• 開発の変化:
  • ゼロからコード記述ではなく検証済みの概念をカタログから選択
  • それらをどのように連携させるかという同期ルールの記述に集中
  • 開発がより創造的で本質的なものになる
• 曖昧な雰囲気ではなく明確な構造と対話により人間とAIが共に未来のソフトウェアを築く知的で冷静な設計図

(2025/11/10)

開発者が知っておきたい複雑さの正体/where-the-complexity-comes-from

• 開発者が知っておきたい複雑さの正体/where-the-complexity-comes-from - Speaker Deck

(2025/11/10)

組織もソフトウェアも難しく考えない、もっとシンプルな考え方で設計する

• 組織もソフトウェアも難しく考えない、もっとシンプルな考え方で設計する #phpconfuk - Speaker Deck

(2025/11/10)

例外処理を理解して、設計段階からエラーを見つけやすく、起こりにくく

• 例外処理を理解して、設計段階からエラーを見つけやすく、起こりにくく #phpconfuk - Speaker Deck

(2025/11/10)

品質は設計でつくり込む / design in quality

• 品質は設計でつくり込む / design in quality - Speaker Deck

(2025/11/09)

カジュアル面談を成功させる秘訣

• カジュアル面談を成功させる秘訣｜nekokak

(2025/11/09)

シンプルは作れる！イミュータブルデータモデルの真髄

• シンプルは作れる！イミュータブルデータモデルの真髄 - kawasima

(2025/11/09)

JJUG CCC 2025 Spring：エンジニアリングでビジネスを加速する。モデル駆動開発という選択肢

• JJUG CCC 2025 Spring：エンジニアリングでビジネスを加速する。モデル駆動開発という選択肢 | ドクセル

(2025/11/09)

AIと共に進化する開発手法： 形式手法と関数型プログラミングの可能性

• AIと共に進化する開発手法： 形式手法と関数型プログラミングの可能性 - Speaker Deck

(2025/11/09)

ドメインモデリングにおける抽象の役割、tagless-finalによるDSL構築、そして型安全な最適化

• ドメインモデリングにおける抽象の役割、tagless-finalによるDSL構築、そして型安全な最適化 - Speaker Deck

(2025/11/09)

Jupyterよりも marimoが使いやすい理由

• Jupyterよりも marimoが使いやすい理由

最近marimoを触ってみたんですが、これが思った以上に便利でびっくりしました。

このツールだけで完結できる場面が多くて、しかもUIがリアルタイムに反応してくれるので、作っていてすごく楽しいんです🎶

驚くほど簡単で直感的に使えますし、「試してみたい！」と気持ちがどんどん湧いてきました。

というわけで、この記事ではそんなmarimoの魅力や、基本的な使い方について紹介していきたいと思います。

ちょっとでも「面白そう」と思ってもらえたら嬉しいです。

(2025/11/09)

ory/hydra -- Go言語製のOpenID認証基盤

• GitHub - ory/hydra: The only web-scale, fully customizable OpenID Certified™ OpenID Connect and OAuth2 Provider in the world. Become an OpenID Connect and OAuth2 Provider over night. Written in Go, cloud native, headless, API-first. Available as a service on Ory Network and for self-hosters. Relied upon by OpenAI and others for web-scale security.

Ory Hydraは、低レイテンシ、高スループット、低リソース消費に最適化され、OpenID認定の堅牢なOAuth 2.0サーバーおよびOpenID Connectプロバイダーです。Ory Hydraはアイデンティティプロバイダー（ユーザーサインアップ、ユーザーログイン、パスワードリセットフロー）ではなく、ログインおよび同意アプリを介して既存のアイデンティティプロバイダーに接続します。ログインおよび同意アプリを異なる言語で実装することも容易で、一般的な言語向けのサンプル同意アプリ（Node.js）とSDKが提供されています。

Ory Hydraは、アイデンティティサーバーとしてOry Kratosを使用できます。

(2025/11/09)

marimo | a next-generation Python notebook

• marimo | a next-generation Python notebook

MEMO:

• 次世代のPythonノートブック環境を提供するオープンソースプロジェクト
• Jupyterノートブックの代替プロダクト
• ノートブックがPythonファイルとして出力されるのでバージョン管理が簡単らしい
• つい最近（2025/10/30）、CoreWeaveに買収されたのでプロジェクトの将来性も有望の模様

(2025/11/09)

インターネットアーカイブの創設者が「我々は生き残ったが、ライブラリは壊滅した」と語る

• インターネットアーカイブの創設者が「我々は生き残ったが、ライブラリは壊滅した」と語る - GIGAZINE

要約:

■ 1. インターネットアーカイブの到達点と記念行事

• 2025年10月までに保存したウェブページ数が1兆件に到達
• 記念イベント「The Web We've Built」を2025年10月22日に開催
• サンフランシスコ市議会が同日を「インターネットアーカイブの日」に認定
• 30年近くサンフランシスコに拠点を置き1兆ページ超のウェブを保存した功績が評価された

■ 2. インターネットアーカイブの重要性

• スタンフォード大学研究者の見解:
  • 過去が常に現在を形作るためウェブページ保存が重要
  • 過去は現在が今のままである必要がないことを教える
• 次のフェーズ:
  • 3D環境やオンラインゲームなどデジタル構築体験の保存方法を模索

■ 3. National Emergency Libraryをめぐる訴訟

• 2020年3月にコロナ禍対応として140万冊のデジタル書籍を提供開始
• インターネットアーカイブはフェアユースと主張したが出版社が著作権侵害として提訴
• 敗訴により50万冊の書籍が貸出リストから削除された
• プロジェクトの目的:
  • Wikipediaが書籍スキャン画像にリンクできるようにする
  • 研究者の電子書籍参照を容易にする
• 創設者ケール氏の批判:
  • 数十億ドル規模の巨大メディアコングロマリットが情報の流れをコントロールすることに独自の利益を持つ
  • Wikipediaの読者が書籍にアクセスできないようにすることに成功した

■ 4. Great 78プロジェクトをめぐる訴訟

• 数十万枚のレコードをデジタル化してオンライン上で保存・公開
• 2025年4月に音楽レーベルから6億9300万ドル(約990億円)の賠償金請求
• 2025年10月に非公開条件で和解が成立

■ 5. 訴訟後の現状と評価

• 2025年10月時点で大規模な訴訟やコレクションへの脅威には直面していない
• ケール氏のコメント:
  • 生き延びたがライブラリの一部は消滅した
  • 再建と再定義の段階に入っている
• 法廷闘争の本質:
  • クリエイターや出版者ではなく大手メディア企業との争い
  • 著作権による制限に満足せず、それ以上を望む企業との対立
  • 企業はWayback Machineの終焉を望んでいたと推測

■ 6. 図書館の役割に関する議論

• 著作権弁護士コートニー氏の主張:
  • 図書館がHuluやNetflixになることを望んでいない
  • 文化の保存と知識への平等なアクセス提供という役割を果たしたい
  • 遠隔アクセスは高齢者、障害者、地方住民、海外派遣時に有益
• 著作権弁護士バトラー氏の指摘:
  • 他の図書館も重要な法廷闘争に直面
  • 出版者の高額訴訟の恐れから保存のためのデジタル化が遅延する可能性
  • 訴訟は誰が文化的記録を保存できるのかという社会的課題を浮き彫りにした

■ 7. 今後の展開と懸念

• Democracies Libraryプロジェクトの拡大:
  • 世界中の政府の研究と出版物を収録した無料オープンなオンライン集成
  • Wikipediaとリンクして研究者の情報アクセスを向上
• AI発展による懸念:
  • AI企業がクリエイターや出版者から多数の訴訟を提起されている
  • 企業による情報への支配力が高まる傾向
  • アーカイブプロジェクトが多方面からの攻撃に耐えられるか不透明

■ 8. ケール氏の提案

• 著作権法の再構築を提唱:
  • 著者、出版者、書店が十分な報酬を得る
  • 図書館の使命が尊重される
  • 進歩が促進される
• 多くの勝者がいるゲームの実現を目指す
• 誰もが読者になるために多くの出版社、販売業者、書店、図書館が必要

(2025/11/09)

「Mozilla/Firefoxの日本語コミュニティ解散」とかいうDramaについて知っておくべき2,3のこと

• 「Mozilla/Firefoxの日本語コミュニティ解散」とかいうDramaについて知っておくべき2,3のこと

免責事項: めんどくさいからほぼ調べずに書くし、抜けてる話や間違ってる話もあると思う。

■ まず日本語コミュニティの解散じゃなくてSUMO翻訳コミュニティの解散なのだがそれも少し違う

Mozilla系の日本語翻訳はmarsfさんとdskmoriさんの2人がメインでやってる。

概ねSUMOはdskmoriその他全てがmarsfという棲み分けだが、お互いどっちの貢献もやることがある。

コミュニティと言えるような規模は存在しない。限界集落。

SUMOコミュニティ解散ってのはSUMOに関わる実質的な権限持ちはdskmori１人になりますって話かな？

正直、SUMOでメインで貢献してるdskmoriさんじゃなくてmarsfさんが文句言うんや？と疑問なんだけど、

Mozillaにとっては、SUMOとかいう誰もアクセスしてない限界集落サイトの話より、marsfさんがFirefoxのその他すべての翻訳を一手で担ってることが重要だよね。

「marsfさんがSUMOの貢献辞める」って言ったってそれ自体ではどうでも良いのだが、裏の意味は「俺の気持ち次第でFirefoxの翻訳終わらすことだってできるんだぞ」って警告と読むべきかもしれない。

■ そもそもSUMOがなにか分かってない人多すぎ

SUMOはFirefoxのサポートサイトね。Firefoxの使い方に疑問が生じたときにみるところ。まあそういう用途で作られているというだけで、アクセスする人がいるのかいたって疑問だが。

想定読者は技術に疎いFirefoxユーザなので、「機械翻訳ならユーザーが自分でやるから不要」みたいな意見は全くナンセンス。

Firefoxの内蔵翻訳機能はプライバシー重視という建前の翻訳API破産防止のため、ローカルのCPUで動く設計になってる。必然的にMicrosoftやGoogleの翻訳より精度がかなり落ちる。ゆえにFirefox使って普通に英語版SUMO読むより、公式で精度よい機械翻訳提供したほうが、ずっと良い体験を提供できるよね。

また対抗をGoogle翻訳のような無料クラウド翻訳と考えるとしても、サポートサイトに特化するようファインチューニングした機械翻訳エンジンを使えばHelpを助けてと訳すような暴走も抑制できるから、これも公式による機械翻訳提供に優位性はある。

なお、統計上アドオン一切入れてないFirefoxユーザーが大多数なことからわかるように技術に疎いFirefoxユーザってかなり多いからね。

■ 勝手に上書きするな？　メンテできてないんだから当たり前

Firefoxはラピッドリリースで機能がコロコロ変わるので、ある時点でベストな翻訳になっててもすぐ時代遅れになる。

dskmoriさんなどができる範囲で貢献してたとはいえ、品質維持できる量ではなかったので、SUMOには、例えばすでに存在しない機能についての記述を含む記事が普通にあった。

これは比較的アクセスありそうな重要ページでも同じで、私もさすがに見かねて貢献したこともある。

Microsoftのプロ技術者向けサイトはもともと有償の翻訳者が訳してたのを機械翻訳に切り替えたのでこれは単純に劣化なのだが、SUMOについてはごく少数の素人が自分にできる範囲で訳していたという点を踏まえる必要がある。もともとクオリティが高かったとは言えないし、機械翻訳の精度もここ2,3年で異常に上がってるから過去の機械翻訳騒動をもとに騒ぐのが正しいとも思えない。

■ 限界OSS翻訳コミュニティの最後の１人が暴走するのは見覚えあるよね

今回の事件で思い出すのがLibreOffice日本語チームのDramaね。LibreOfficeの翻訳のメイン貢献者の某氏がある日、日本語チームのメーリスで「何でお前らはまともな仕事ができんのんや」と長文でブチ切れて、チーム脱退を宣言した事件。理念は立派でもすでに敗北の流れは決定的で新たな貢献者の望みは薄い、希望の見えないまま最後に残った１人として惰性で維持するしかない、辛い。

今回は、LibreOfficeの事件よりはヤバさだいぶ低めだけど、「翻訳ガイドラインに従っていない」「新たな人間の貢献者を育てることができない」とか、SUMOボランティア翻訳の実情を思えば「何言ってんだ、現実をみろよ」という感想にしかならないし、CCライセンスで貢献してるのに、AI翻訳の学習に使うなも意味不明。

marsfさんは、某xkcdで言うところの「感謝なしに2003年からデジタルインフラを維持してきたネブラスカ州の無名個人」に位置する人で、もっともっと感謝されてしかるべきではあるのだが、SUMOの長年の構造的な問題に対し抜本的な解決に打って出たMozillaに対して、さもコミュニティが現在も十分に機能しているかのように反論してるのがとても印象悪い。どう見ても分かってない人ばかりがMozillaを炎上させている。

20年感謝なしに維持し続けるのは幻想が必要なのはわかるが、Mozillaとしてはそういう個人に依存するのは不健全でしかないので、現在marsfさんがやっているFirefoxほぼすべての翻訳も翻訳会社による有償翻訳に移行すべき。

関連:

• 機械翻訳が「人手の作業を大量破壊」　Mozilla日本語コミュニティが解散宣言　人力訳を上書き

(2025/11/08)

機械翻訳が「人手の作業を大量破壊」　Mozilla日本語コミュニティが解散宣言　人力訳を上書き

• 機械翻訳が「人手の作業を大量破壊」　Mozilla日本語コミュニティが解散宣言　人力訳を上書き - ITmedia NEWS

「Firefox」をはじめとしてMozilla製品のサポートページの日本語化に尽力してきたコミュニティ「SUMO Japanese community」が11月4日、活動の終了を宣言した。

Mozillaが10月22日、機械翻訳「Sumo Bot」を日本語記事に導入し、手作業で翻訳した記事をの上書き翻訳を無断で行っているため。コミュニティリーダーであるmarsf氏はこれが「私たちの作業の大量破壊」に当たるとし、コミュニティとしての活動終了を宣言した。

marsf氏によるとSumo Botの翻訳は、翻訳ガイドラインに従わず、日本語ユーザー向けのローカライズ表現を無視したまま既存の翻訳を上書き。300以上のナレッジベースが上書きされたという。

また、コミュニティへの連絡や合意がないまま製品版サーバで上書きしており、更新後72時間で自動承認されるため、新しい翻訳者に翻訳させ、チェックするといった育成の機会も奪っていると指摘している。

marsf氏はこれを「私たちの作業の大量破壊」と批判。個人として「support.mozilla.orgへの貢献を停止する」と宣言した。また、同氏の翻訳がSuMo BotやAIの学習データとして使用われることを拒否し、既に学習された私の翻訳データを削除することを要求している。

ただ、「日本の個々のコントリビューターが自分の責任において活動を続けることは自由」とも述べている。

関連:

• 「Mozilla/Firefoxの日本語コミュニティ解散」とかいうDramaについて知っておくべき2,3のこと

(2025/11/08)

なぜアーキチームは設計や実装のパターンを絞りたいか？ 背景にある思考と技術選定のジレンマ

• なぜアーキチームは設計や実装のパターンを絞りたいか？ 背景にある思考と技術選定のジレンマ | フューチャー技術ブログ

要約:

■ 1. 設計・実装パターンを絞る理由

• 全体最適と局所最適:
  • レビュイーは目の前のタスクの最速完了を重視
  • レビュワーはプロジェクト全体の長期的な健全性を重視
• コードベース全体の一貫性維持:
  • 新規メンバーの学習コスト削減
  • 横断的な修正作業時の調査漏れリスク軽減
  • 予測可能性の確保
• 開発者の設計余地の削減と均質化:
  • 手法選択の迷いを排除しレビュー時の衝突を回避
  • チーム成熟度が低い場合の誤った選択を防止
  • プロジェクト遅延リスクの軽減
• ライブラリやサービス追加による管理コスト削減:
  • 学習コスト、バージョンアップ、脆弱性対応の追加作業を抑制
  • 引き継ぎやドキュメント作成の手間を最小化

■ 2. 統制のメリットとデメリット

• メリット:
  • 品質の担保
  • 認知負荷の低減
  • 保守性の向上
• デメリット:
  • モチベーション低下(特に若手)
  • 開発速度の低下
  • 変化への対応の遅れ
• 統制と裁量のバランスは状況に応じて変化し、プロジェクトフェーズで方針が変わることもある

■ 3. プロジェクト特性による統制レベルの違い

• 開発速度最優先の場合:
  • 新規事業のプロダクト開発では自由度を高める
  • セキュリティとコンプライアンスのみチェックし、腕利き開発者のセンスに任せる
• プロジェクト初期:
  • 不確実性が高い段階では自由度を高める
• 成熟期:
  • ユーザー増加と安定性重視の段階で統制を強化
  • 保守運用を見据えた細かい処理方式の指摘を実施

■ 4. 開発ガイドラインの課題

• 後手に回る理由:
  • ガイドラインを書いても読まれない傾向
  • 記載量が多いと読解困難で記憶不可能
  • メンテナンスコストの増大
• 実効性確保の方針:
  • 現場感が強い内容のみを記載
  • フォーマッターやリンターの整備が必須
  • カスタムルールを適用するツールの開発
• AIレビュー導入により、ガイドライン記載内容を増やせる可能性がある

■ 5. 統制を強める基準

• チーム規模による判断:
  • 5人程度: 阿吽の呼吸で運用可能
  • 10-15人超: 統制が必要
  • 15-50人: 専門家による統制
  • 50-150人: 強いトップダウンのルールが不可欠
• 技術レベルによる判断:
  • 小規模×熟練メンバー: 見守りモード
  • 小規模×ジュニア中心: 指導・規範の整備
  • 大規模×ジュニア中心: 統制を強める
  • 大規模×熟練メンバー: 維持困難(メンバー入れ替わりは必然)
• 運用時の最も弱い体制を見据えた技術選定が必要

■ 6. アーキテクトの成長と価値創出

• 枯れた技術採用のジレンマ:
  • 大規模案件ほど枯れた技術を採用しがち
  • リスクを受け入れてモダンな技術にチャレンジする判断も必要
• 成長の楽しみの見出し方:
  • 仕組み化によるプロジェクトライフサイクル全体の開発継続性確保
  • 開発生産性技術セットの習得(CI/CDパイプライン、Git開発フロー)
• 実績を詰めれば大規模案件でもモダン技術を採用しやすくなり、ノウハウは小中規模案件にも還流する

■ 7. コミュニケーションと判断基準の明確化

• 判断基準と理由の伝達:
  • 指摘とWhy(理由)をセットで伝える
  • ADRや開発ガイドラインで設計決定を記録
  • 後出しの場合は謝罪し、ルールが必要になった背景を説明
• 納得感と一貫性が信頼関係構築に不可欠

■ 8. 視座の違いによる技術選定

• プロジェクト視点:
  • 所属プロジェクトの円滑な推進に注力
• 複数プロジェクト・部門視点:
  • ノウハウ共有とメンバー流動性確保のため非差別化領域の標準化
• 全社視点:
  • セキュリティ、コンプライアンス、人材育成コストの最適化
  • 技術広報・採用広報との連動
• Webフレームワーク、DBアクセスライブラリ、ログライブラリなど利用頻度が高いライブラリは全社・部門レベルで統一することが望ましい
• アーキテクチャに個性は不要で妥当性が重要

■ 9. まとめ

• アーキテクトは短期的な開発速度と長期的な引き継ぎコストのジレンマでバランスを取る
• スイートスポットはチーム規模と技術力に依存し常に変化する
• 新技術導入時は全体を見通して既存修正や開発規約修正まで行うべきかを検討
• 現場の現実と全体最適の視点の両立が建設的な議論の前提

(2025/11/07)

AI が来て自分が壊れそうになった話

• AI が来て自分が壊れそうになった話｜牛尾　剛

(2025/11/07)

RISC-Vの命令セットがISO/IEC JTC1による国際標準化に着手へ。第一歩として公開仕様提出者の承認を受ける

• RISC-Vの命令セットがISO/IEC JTC1による国際標準化に着手へ。第一歩として公開仕様提出者の承認を受ける － Publickey

RISC-V（リスクファイブ）は、クリエイティブコモンズとして公開され、誰でも無料で利用可能なプロセッサの命令セットです。近年ではx86やArmに次ぐ命令セットとして注目度が高まっています。

RISC-Vを主導する団体RISC-V Internationalは、このRISC-Vの命令セットがISO/IEC JTC1による国際標準化の第一歩としてPAS（Publicly Available Specification）提出者の承認を受けたことを明らかにしました。

RISC-V Internationalは、RISC-Vの命令セットはすでに業界標準になっているとし、次のステップは公正な見地として信頼できる国際機関からの承認だとして、国際標準化機構（ISO）と国際電気標準会議（IEC）の合同技術委員会（JTC 1）による国際標準化へと進もうとしています。

今回、その第一歩として、JTC 1 PASの提出者の承認を受けたわけです。

国際標準化を重視する背景には、例えばIEEE 802.11で標準化されているWi-Fiのように、業界が合意した一連のルールとフォーマットとして標準化されることで複数のメーカーの異なる製品であっても確実に連携することが保証されるからだと説明されています。

これにより複数の製品の連携や統合が容易であり、コストが削減され、拡張と拡張が容易になるわけです。

また、命令セットが国際標準になった場合、その標準をサポートすると宣言した企業や組織は、ハードウェア製品などが標準を満たしていることを宣言できる利点もあるとしました。

そのため、RISC-V命令セットを国際標準にすることは相互運用性を促進し、オープンコンピューティングの将来の基盤としてのRISC-Vの役割を強固にするのだとRISC-V Internationalは説明しています。

(2025/11/06)

「Ubuntu 26.04」の戦略と新機能--Canonical幹部が語る「Linux」デスクトップの未来

• 「Ubuntu 26.04」の戦略と新機能--Canonical幹部が語る「Linux」デスクトップの未来 - ZDNET Japan

要約:

■ 1. Ubuntu 26.04 LTSの全体的ビジョン

• ロンドンのCanonical本社で開催された「Ubuntu Summit 25.10」において、創設者兼CEOのMark Shuttleworth氏とエンジニアリング担当バイスプレジデントのJon Seager氏が次期長期サポートリリース「Ubuntu 26.04 LTS」(「Resolute Raccoon」)のビジョンと計画について説明した
• 重点領域: メモリー安全性を確保した基盤ユーティリティー、自動化の強化、コミュニティー中心のドキュメント、デスクトップとクラウド向けに最適化されたセキュリティ機能

■ 2. Shuttleworth氏のオープンソースへの信念

• Shuttleworth氏は自身がオープンソースの真の信奉者であると語った
• Canonicalの使命: ユーザーがあらゆる領域でオープンソースを利用できるようにする企業である
• 提供形態: クラウドでオープンソースを使いたいならクラウド向け製品を、小型デバイスで利用したいならそのような製品も提供する

■ 3. Linuxデスクトップの断片化問題

• Shuttleworth氏はデスクトップLinuxの断片化が深刻な問題であると認識している
• 「Linuxを真のグローバルな選択肢にしたいなら、実効性の高い取り組みを実施する必要があり、足を引っ張り合っている場合ではない」と述べた
• 皮肉なことに、失敗に終わったCanonicalのデスクトップ「Unity」への取り組みによって、同社の収益性がかつてないほど高まった
• 理由: その失敗のために、サーバー、クラウド、モノのインターネット(IoT)製品に注力せざるを得なくなったから

■ 4. Linuxデスクトップの可能性

• Shuttleworth氏はLinuxデスクトップの可能性を信じなくなったわけではない
• 「デスクトップにおけるオープンソースの勝利に貢献したい」と語った
• Ubuntu 26.04はデフォルトのデスクトップ環境として引き続き「GNOME」を採用している
• System76の評価: 米国のLinux PCメーカーであるSystem76と同社の新しい「Rust」ベースのデスクトップ「COSMIC」を高く評価しており、実際にSystem76はUbuntu SummitでCOSMICに関するセッションを開催した
• 課題認識: 「オープンソースコミュニティーは、エンジニアではない人向けのデスクトップの開発が別物であることを理解する必要がある。『シンプルできちんと機能する』ことも非常に重要であることを理解しなければならない」

■ 5. 開発方針の根本的見直し

• 2月にSeager氏が新任として、CanonicalとUbuntu開発チームによる今後の新しいUbuntu開発の方針を示した
• 目標: コミュニケーション、自動化、プロセス、モダナイゼーションに関するエンジニアリングの慣習を根本的に見直すこと
• Canonicalは2026年以降、ドキュメントとコミュニケーションのチャネルを統合することで、より透明性が高く理解しやすいコミュニティー主導のUbuntuビルドプロセスを確立し、新しいコントリビューターが参加しやすい体制を目指している

■ 6. コミュニケーション基盤の統合

• 「Ubuntu Community Matrix」サーバーをベースとする「Matrix」インスタントメッセージングが、Ubuntu開発者の主要なコミュニケーションシステムとなる
• Canonicalはユーザー向けと開発者向けのドキュメントの統合にも取り組んでいる
• Seager氏の認識: 「ドキュメントは重要なコミュニケーション手段」であり、二の次にすべきではない
• 現状の問題: 多くのドキュメントがさまざまなプラットフォームに分散し、内容の重複や矛盾があるほか、単純に見つけにくい場合がある
• 今後: 利用しやすく正確な形に統合される

■ 7. ビルドシステムの自動化とモダナイゼーション

• Canonicalはディストリビューションとパッケージの両方のビルドシステムの自動化に注力している
• 目標: エラーが発生しやすく退屈だが手間のかかるプロセスから、現代的な開発ツールを使用した高度な自動化システムへ移行する
• Seager氏の説明: 「可能な限り多くのプロセスを自動化する(それによって全体の能力を高める)だけでなく、プロセスをできるだけ簡素化することを目指す」
• 現状の課題: Ubuntuのビルドプロセスの多くは確かに自動化されているが、それらのシステムは統一されておらず、多くの場合、経験豊富なコントリビューター以外には分かりにくい
• 改善策: それらを一貫性のある開発パイプラインに統合することで、ビルドシステム全体が改善される

■ 8. Temporalの採用

• 同社は永続的なオーケストレーションを実現する「Temporal」などのツールを採用して、プロジェクトのワークフローの合理化やモダナイゼーションを進めている
• Seager氏の評価: 「Temporalは基本的に、分散システムエンジニアがいないUbuntu組織でも非常に複雑な分散システムを構築できるツールだと考えている」
• 目標: 十分に文書化されピアレビューを経たプロセスを活用して、ボトルネックと属人的な知識への過度な依存を軽減することで、コントリビューターが活躍できる環境を整え、規模の拡大に対応する

■ 9. Rust言語の採用によるメモリー安全性の向上

• Ubuntuはメモリー安全性の高いRust言語を採用している
• エンジニアリングチームはUbuntu 25.10から、主要なシステムコンポーネントをRustベースのコンポーネントに置き換えて、安全性とレジリエンスの向上に力を入れている
• Seager氏の強調点: 性能だけでなく、レジリエンスとメモリー安全性が主な推進力である。「Rustへの移植によってレジリエンスと安全性の向上を簡単に実現できる。私が最も魅力を感じるのはこの点だ」
• sudo-rsの採用: Ubuntuは「sudo」のRust実装である「sudo-rs」を採用しており、フォールバックとオプトアウトの仕組みがあり、従来のsudoコマンドも使用できるようになっている

■ 10. uutils/coreutilsの採用

• Ubuntu 26.04では、sudo-rsに加えて、LinuxのデフォルトのコアユーティリティーとしてRustベースの「uutils/coreutils」が採用される
• 内容: ls、cp、mvなど、多数の基本的なUNIXコマンドラインツールが含まれる
• 狙い: このRust再実装の狙いは「GNU coreutils」と同等の機能を実現しつつ、安全性と保守性の向上を図ること

■ 11. TPMによるフルディスク暗号化

• デスクトップ関連の変化として、Ubuntu 26.04で「Trusted Platform Module」(TPM)によるシームレスなフルディスク暗号化が導入される
• この機能は「Windows」の「BitLocker」や「macOS」の「FileVault」に相当するものである

■ 12. Snapアプリケーションのpermissions prompting

• Ubuntu 26.04では、「Snap」ベースのアプリケーションに「permissions prompting」が搭載される
• これはデスクトップアプリ向けのきめ細かな権限管理フレームワークである
• 目的: コンテナー型の強力なセキュリティと、ユーザー主導による事前の承認を組み合わせる
• 現状の問題: Snapの機能の1つにサンドボックスがあるが、使っていてイライラすることもある。何かを実行しようとしてサンドボックスにブロックされると、アプリがクラッシュする場合や本来の処理が実行されない場合がある
• 改善内容: プロンプトに「Firefoxがダウンロードディレクトリーへのアクセスを求めています。許可しますか」といった内容が表示されるようになる
• 開発状況: このフレームワークはまだ完成していない。この取り組みでは「カーネル、『AppArmor』(Linuxのセキュリティプログラム)、Snap、デスクトップクライアントに至るまで、非常に大掛かりな作業」が必要である
• 見通し: 全てが順調に進めば、Ubuntu 26.04のリリースまでにはpermissions promptingが完成している

■ 13. 最新コンポーネントの採用方針

• Ubuntu 26.04では再び「最新バージョンのGNOME(おそらく『GNOME 48』)と最新のカーネル」を採用し、最新のベースコンポーネントを提供するという伝統を踏襲する
• この方針のために、LTS版ではないLinuxカーネルをサポートする必要が生じたとしても、Canonicalはそうする

■ 14. Flutterベースアプリの拡大

• 新しいUbuntuでは、より多くの「Flutter」ベースアプリが使われることになる
• Flutterはオープンソースのプログラミング言語「Dart」を使用するGoogleのプラットフォームである
• 利点: 開発者はFlutterを使用することで、ほぼ全てのプラットフォーム向けのマルチOSアプリを1つのコードベースから作成できる
• Ubuntu 26.04での適用範囲: この機能にUbuntuのアプリストア、インストーラー、「セキュリティセンター」が含まれる

(2025/11/05)

スタンフォード大学とAnthropicが、AIの安全機能は簡単に無力化できることが証明する論文を発表...

スタンフォード大学とAnthropicが、AIの安全機能は簡単に無力化できることが証明する論文を発表しました。

最大99%の成功率でAIを操り、有害な応答を引き出す手法です。

僕も実際に試しましたが、かなり簡単です。

ということで、この巧妙な手口と衝撃的な結果をまとめました。

1. 巧妙な手口 まず無害だが絶対に解けない問題と長大な推論をAIに与え、最後に有害な指示を付け加えるだけ。AIの注意を無害な部分に集中させ、本来の危険な指示に対する安全機能を弱体化させます。

2. メカニズム 長い推論の連鎖は、AIの安全強度を担う中間層と、最終決定を行う後方層の機能を鈍らせることが判明。AIの「注意力」が前段の無害なタスクに割かれることで、後段の有害な指示に対する警戒が薄れ、拒否反応が著しく低下します。

3. 驚異的な成功率 実験結果は衝撃的です。ある公開モデルでは、短い推論での攻撃成功率27%に対し、長い推論では約80%に急増。様々な最先端AIシステム全体で見ると、この手法は最大で99%の成功率を達成しました。

4. 結論 AIの推論能力の向上は、精度を高める一方で、意図せずして強力な「抜け穴」を生み出してしまいました。AIの賢さが、皮肉にもその安全性を脅かすという、新たな課題が浮き彫りになっています。

@kosuke_agos

(2025/11/05)

システム構成図・シーケンス図、結局どれ使う？人気ツールとエンジニアのリアルな使い分け徹底解説

• システム構成図・シーケンス図、結局どれ使う？人気ツールとエンジニアのリアルな使い分け徹底解説

(2025/11/05)

AuroraMySQL 負荷試験報告 〜結局のところスキーマ分離のDB設計ってどうなの？〜 その１

• AuroraMySQL 負荷試験報告 〜結局のところスキーマ分離のDB設計ってどうなの？〜 その１ - MNTSQ Techブログ

(2025/11/05)

【DDD】そのValueObjectまじで意味ないっす #Go

• 【DDD】そのValueObjectまじで意味ないっす #Go - Qiita

要約:

■ 1. 記事の目的と対象

• ValueObjectの不変性にフォーカスし、アンチパターンを提示した後、本来あるべき姿の例を記載する
• 対象: アプリケーションエンジニア、DDDに取り組んでいる人・取り組みたい人
• Vladimir Khorikov氏の言葉: 「ValueObjectを不変にできない場合は、それはValueObjectではない」

■ 2. ValueObjectとEntityの違い

• Entity: 可変・同一性を持つ(ライフサイクルを持つ)
• ValueObject: 不変・同一性を持たない(ライフサイクルを持たない)
• 同一性の例: 人物は20年経っても同じ人物として探すことができる(Entity)。名前や趣味は変わることがある(ValueObject)

■ 3. 比較(評価)の違い

• オブジェクトの評価方法には三種類ある:
  • Reference equality: 参照の等価性
  • Identifier equality: 識別子の等価性
  • Structural equality: 構造的等価性
• EntityはユニークなIDで比較を行う(Identifier equality)
• ValueObjectは構造で比較を行う(Structural equality)
• Entity: 記憶という識別子を元に本人かどうかを評価する
• ValueObject: 名前(文字列)での構造的評価を行うため、ヒットしたアカウントが複数の場合もある

■ 4. アンチパターン1: 単なる型定義

• この実装では型でドメインを表現できていると満足しているが、userIDもEmailもドメインの不変性という責務を果たせていない
• ValueObjectの核心的な責務は「ドメインの不変条件(invariant)を保証し、カプセル化すること」である

■ 5. 型定義だけの実装がアンチパターンな理由1: カプセル化の欠如

• Goの場合、型変換によってバリデーションを簡単にバイパスできる
• ファクトリ関数(コンストラクタ)を用意しても、パッケージ外から型変換で不正な値を強制的に作れてしまう
• アプリケーション全体でEmail型の値が常に「有効なメールアドレスである」ことを保証できない
• 他のパッケージから不正なメールアドレスのオブジェクトをインスタンス化できてしまう

■ 6. 型定義だけの実装がアンチパターンな理由2: ドメインの知識(振る舞い)の欠如

• type Email stringの定義では、その型はstringとほぼ同等の能力(stringへの型変換が容易)しか持たない
• ValueObjectは単なる「バリデーション済みの値」ではなく、その値に関連する「ドメイン固有の振る舞い(ロジック)」もカプセル化する責務を持つ
• 例: 「Emailアドレスからドメイン部分だけを取得したい」というドメインの要件があった際、現状の設計であれば実装がアプリケーション層に記載されることになる
• 「Emailのドメインパートのみを取得する」といったオブジェクトの振る舞いは関心の分離を行う対象であり、アプリケーション層ではなくドメイン層で設計・コーディングすることがオーソドックスなスタイルである

■ 7. 正しい実装: カプセル化と不変性を強制

• 構造体としてValueObjectを表現し、値と振る舞いの両方をカプセル化する

■ 8. アンチパターン2: 不変性の欠如

• ValueObjectがポインタレシーバを持つ場合、「値が変更可能であることを示唆する」表現となるため、不変性を破壊しかねない
• 基本的に不変なものは値レシーバが推奨される

■ 9. 実装のポイント

• ValueObjectを構造体として表現し、構造体が持つ値への参照を非公開(value)にしてgetter経由でしか参照させないようにすることで、パッケージ外からの型変換や直接的なフィールド代入を防ぐ
• インスタンス化をNewEmailに強制し、バリデーションを担保する
• ValueObjectの関数は値レシーバとし、不変性を明確にする

■ 10. まとめ

• 「ただの型定義」は、ドメインルールを強制できない「なんちゃってValueObject」である
• 不変性が必要な場面ではカプセル化を徹底し、ドメインルールを守らないオブジェクトの生成を許さないような設計を心がける必要がある
• ファクトリー関数を通して、ドメインルールが守られたインスタンスが生成される
• そうすることで初めて、ValueObjectは「意味のある」存在となる
• 結論: 「ValueObject導入するなら、値も振る舞いもカプセル化してくれ」

(2025/11/05)

組織全体の開発スループットを劇的に向上させた「AIプランナー」とは？ 〜Speeeが実践する3つのTipsと...

• 組織全体の開発スループットを劇的に向上させた「AIプランナー」とは？ 〜Speeeが実践する3つのTipsと新しい開発チームのかたち〜 - Speee DEVELOPER BLOG

(2025/11/04)

DDDにCQRSをどう組み込むか～バックエンドアーキテクチャ設計時の考え方

• DDDにCQRSをどう組み込むか～バックエンドアーキテクチャ設計時の考え方 - TechDoctor開発者Blog

(2025/11/04)

ソフトウェアエンジニアにおける才能という現実

• ソフトウェアエンジニアにおける才能という現実

まぁ、幻想じゃないね w

才能がないと思ったら、早いうちに河岸を変えた方がいい。

早ければ早い方がいい。

可哀想だから(教え子が？ それとも自分が？ w)、って「がんばれ、がんばれ。才能なんて関係ない」みたいに騙すのは、むしろ害悪だよ。

10年後、気付いて路頭に迷わせるとして、その責任は取れるのか？

引導を渡すこともプロの責任。

まぁ、本人自身が気づいて路頭に迷いつつあるけどどうしようもないのかもしれんが、地獄に道連れはやめてやれ w

小説家、役者、声優、バンドマン etc.etc.

それで生計を立てない、趣味の範囲で楽しむ分には好きにすればいいけど、エンジニアに限らず、それなりのお金をもらおうとしたら、才能、向き不向きは超えられない壁として現実に、強固に存在している。

球速120km出ないけど阪神の一軍のピッチャーに、ってのはどう逆立ちしても物理的に不可能だ。

でも草野球は楽しめる。

才能がなけりゃ、一人で永遠に「大いなる助走」を続けりゃいい。

誰にも迷惑かけないなら。

医師、看護師、会計士、経営者、etc.etc. にも、才能、向き不向きはある。

おいらには、医師とか、警官とか、無理だねぇ。

落ち着きないし。

同じことを何日も続けたら、爆発する。

「明日も同じことしなきゃならないのか……」って考えただけでも、死にたくなる。

こんな感じに、才能がものをいう分野って、意外に多い。

ソフトウェアエンジニアは、設計実装の抽象度が多層化していて、その巧拙によって安定度、運用や機動的な新機能追加の手間、リードタイム、金や何やら、数十倍、規模複雑度が爆上がりしている今なら下手すりゃ数百倍差が出る。

その差をちゃんと理解するには、巧の現場の「こういう世界があるんやー……」って実体験が必要だったり、巧レベルの才能が必要だったり、経営知識が必要だったり、経済知識も必要だったりして、「拙」の現場にぶら下がってるだけのエンジニアが「才能なんて幻想」って吠えたっても「マジ、迷惑だからやめてね」って思う。

どの炎上現場でも、高粘度現場(リーダーマネージャが理解できないからって邪魔ばっかりしてきたり、そもそもプロダクトがぐっちゃぐちゃになってたりして、どんな行為がサービスの息の根を止めるかわからなくて身動きが取れない「震える舌」みたいな現場。物事が全然進まない現場。通常、経費で札束ガンガン燃やしてるはずだから、ここも炎上現場っていう)でも、この手のエンジニアが腐るほどぶら下がってるんだよね。

たいてい、生み出されるソースコードとドキュメントの割合がおかしなことになってる。

会議だ勉強会だなんだばっかりしてる。

いや、そういうの主催してる暇があったら、コード書けよ、って。

でも、Web記事引いてきて、「〇〇にはこう書いてある」とかドヤ顔で机上の空論で時間潰して「俺も一端の理論派エンジニアだぜ……」とか、いや、お前はただの受け売りを理解もせず垂れ流してるだけのそこらへんの AI と変わらんクズだよ。

おいらの師匠の一人は「TV出たり、本書いたりするやつは二流。一流は、自分の仕事に集中していて、他のことやる暇ないから」って言ってたけど、ほんとその通りだと思うよ。

シャバと違い、ソフトウェアの世界は驚くほどのスピードで巨大化、複雑化している。

30年、40年前なら、社会性の乏しい、プログラミングコンテスト受賞者みたいなエンジニアでも無双できたけど、今は無理なんだよね。

今だと玉拾いも任せられないくらいだったりする。

余計な部分最適化かまして、地雷埋設に邁進しちゃうから。

ちょい前も、PostgreSQLの中身いじれます！ って東大卒業生いたけど、視点が局所的すぎて全体感に欠けてて、プロジェクトがヤバい状態になってるのが理解できなかったりしてたからね。

そろそろリリースできる状態になってる予定だけど、おいらの読み通りα版完成が3ヶ月遅れ、そこで大量の不具合が発覚してベータ版完成がそこからさらに3ヶ月以上遅れ、不具合積み残したまま見切り発車、ってなるんじゃねーかな、と思ってるんだが w

才能の種類、方向性によっては、10年前も今もたぶん10年後も変わらず十分通用するものはあるんだけどねー。

エンジニアの年収は他の一般の職業に比べて高い。

そこに生活水準をあげてしまうと、自分はもう通用しないと気づいても、撤退できない。

マイカーガー。

マイホームガー。

子供ガー。

愛犬ガー。

んなもん知るかっ！

さっさと色んな意味でFireしろっ！！

そういう「元エンジニア」がリーダーとかマネージャとかにクラスチェンジして、事業、プロダクトの足を引っ張る。

マジでこの手の「元エンジニア」が、今、業界に溢れてる。

あそことか、そことか、具体的な企業名はあげられないけど、そういうエンジニアが漬物石のように重しになって、身動きが取れなくなってるところが多い。

VCとかから、もっと売り上げを上げろ。成長率を上げろ、というプレッシャーを与えられ、何かしなきゃいけない。ってなって、外付けの雰囲気だけのサービスをどんどん外付けしていく戦略を取る。

1年で10。

2年で30とか。

マジかよ w

思い思い行き当たりばったりに作ったら、手間だけ増えてそれを壊すわけにはいかなくなって、さらに身動きが取れなくなっていく悪循環しか見えないんだが、そんな経営方針で大丈夫か？

とりあえず認証認可から共通化していくしかない。

とか意味不明な決定して、認証認可v1、認証認可v2、認証認可v3とマイクロサービスが増殖して、さらにv4を企画してるとかいう会社だってある。

真っ当な声には、自分の存在感を示すためだけの反対を唱えて邪魔したりして、現場で手を動かしているエンジニアより高級を取ってんのに、事業、プロダクトへ与えるダメージは倍増する。

さらに、自分の地位を死守するために、それを脅かす腕利のエンジニアを陥れる、排除することに全力を傾ける。

これで3倍界王拳だ w

経営者はできるエンジニアたちに任せていると思い込んでいるかもしれないが、さて、どうかね？ w

大本営発表的にはうまくいっているとされているサービスが、その裏側はカーオブファイヤーみたいなところって、結構ある。

というか、そっちの方が多いんじゃないか？ ポチョムキン村。

はっきりいう。

ソフトウェアエンジニアは、アスリート的な仕事だ。

おいらは土日祝もシステム関係の勉強とか研究をしてる。

今はクラウド環境のプロダクトで、どのように自動テストで検証可能なシステムを構築するかの手法の研究を続けてる。

具体的には、今まで関わってきた炎上現場で安定稼働を達成させた手法(TDD)だな。

ワークライフバランス？ w

そんな寝言、やめてから言えよ www

才能のない人は河岸変えろ。

むしろ若手を潰してるって自覚持て。

に反論してくるのが結構いる。

あのサービスとこのサービスとそのサービスを使ってます。

業務経歴書にも今まで使ったことがあるサービスの名前をたくさんたくさん載せてます。

僕の技術力は世界一ぃぃぃっ！！！

じゃねーよ。

ボルトに世界水泳、吉田沙保里にNBAに出場させるような使い方してて、どこが技術力だよ。

ってのが多い。

「どうしてこのAurora、リーダーがこんなにたくさんぶら下がってんの？」

「テナントが増えて、アクセスが増えたので、負荷分散のために増やしました。水平スケーリングってやつです」

うん。水平スケーリングは知ってんねん。この程度のテナント数、ユーザー数、アクセス数で、どうしてこんなにでかいインスタンスのリーダーがぶら下がってんのか？ って聞いてんねんけど……。

って現場、多い。

というか、そういう現場しか知らん w

まぁ、炎上現場巡りしてたし。

でも、今通常営業してるサービスでも、こういうところ多いんだよな。

それはともかく、

「マイクロサービス化していて、いま120を超えたところで、当面160になります」

「……は？」

「うちのサービス、ドメイン多いんで」

「……デプロイの時、どうすんの？」

「変更があるサービス名を書いたファイルを一緒にコミットして、それ読み込んで、GitHubActionsでデプロイさせてます」

「……ローカルの開発環境構築は？」

「Cloneして立ち上げます」

「これ……、モノリポ？」

「もちろんです。Googleもそうやってますし」

「120個？」

「120個」

「なんか立ち上がらないんだけど……」

「あ、修正中なんで、〇〇と××のコミットをチェリーピックしてください」

「……動かないぞ」

「昨日の夕方、変更が入ったみたいなんで、△△のコミットもチェリーピック。いや、＋＋のブランチを……」

5日で立ち上げ切れるんか？

って現場がね、案外たくさんあるんだ。

で、「マイクロサービス、使えないっすね」

「ほう……？」

「連携が取りづらくて、障害発生しまくって」

どうして「自分が間違えてる」「自分が見当外れなことをしている」可能性ってのを考慮しないんだろう、この人らは？

っていつも思う。

マイクロサービスの目的も前提も理解しないで、HowToだけ猿のように繰り返してるって自覚ないんか…… (-_-)

「だって、オライリー本のここにこう書いてあるから！」

ってマーカーで引いた一文見せつけられるんだが、その前に書かれてある前提とか目的とか、書かれてない暗黙のそれとか、いわゆるコンテキスト削ぎ落として、単語レベルの理解を開陳されても、「は？」としか反応できんのよな。

120のマイクロサービスとか、お前、認知科学の知識もないねんな……。

それマイクロサービスじゃなく、「粉砕されたモノリシックサービス」っていうんやで、と。

まーじで、技術本とかの恣意的なつまみ食いで訳分からん理論構築すんなよ。

それでプロダクトがうまく回ってなかったら、それが答えなんよ。

まぁ、「うまく回ってる状態」ってのを知らない、理解できないだろうから、正しい答えに行きつかんだろうけど。

その正しい答えに行きつかない、ってのを

「致命的な才能の欠如」

って呼ぶんよ。

サリエリくらい才能があったら、自分の才能が足りんことを自覚できるんだがな。

脳外科医竹田君みたいなエンジニアは、即刻足を洗って欲しい。

MEMO:

• 残念ながらこれは本当にそう

(2025/11/03)

【UG# 455】「生成AIで絵師はどうなる？」「誰が為の監視社会」「積読書術」 @サイコパスの人生相談...

• 【UG# 455】「生成AIで絵師はどうなる？」「誰が為の監視社会」「積読書術」 @サイコパスの人生相談 2022/09/11 - YouTube

要約:

■ 1. 画像生成AIの現状認識(2022年から2025年の変化)

• 2022年時点では画像生成AIの存在が認知され始めた段階だったが、2025年現在では小学生や高齢者も普通に使いこなしている
• 当時から「明るい未来はあまりない」と予測していたが、実際にイラストレーターの仕事は奪われつつある現実となった
• イラストの単価が3分の1になっているとの報告もある
• 生成AIに対する抵抗運動(訴訟、ボイコット、ネガティブキャンペーン、プロテクト技術の使用など)が展開されているが、大局的には勝ち目がない

■ 2. AIによる学習と著作権問題の本質

• 流行している絵の描き方パターンをAIに学習させて発表する行為は、人間の絵描きや漫画家が昔から行ってきたことと本質的に同じである
• 漫画家は現在も活動している漫画家の作品パターンを頭の中で混ぜて創作しているため、AIがそれを行うことを非難するのは矛盾している
• オリジナリティとは混ぜ方の中に自分が生きているかどうかの問題である
• 自分が苦労して編み出した表現をAIに盗まれるという感情は理解できるが、この論法では勝ち目がない

■ 3. イラスト業界の段階的淘汰

• 第一段階(過去3年間): イラスト屋などの無料配布により、地方自治体や小規模商店向けに仕事をしていた町のイラストレーターが淘汰された
• 第二段階(今後): 超メジャーではない中堅イラストレーターの仕事が奪われる
• 超メジャーなクリエイター(鳥山明、大友克洋、尾田栄一郎など)のみが「その人が描いてくれただけで価値がある」という理由で生き残る

■ 4. アニメーション制作の変革

• アニメの作画は無人化が進む
• 演出家は見せたいカットを人間に発注し、流してよいカットをAIに発注するという使い分けを行う
• AIは書き込みが多く影が複雑な動きに向いており、人間のアニメーターに負担をかけていた作業を担当する
• 結果としてアニメーションのクオリティは向上し制作コストは下がるが、動画マンは職を失う可能性が高い
• 原画マンは生き残る可能性があるが、動画マンの将来は厳しい

■ 5. 漫画制作へのAI浸透

• コマ割りや見開きの見せ方などの漫画文法もAIのディープラーニング対象となる
• 漫画が量産されるほどデータが蓄積され、AIによる自動生成が可能になる
• 数年以内に可能になることは明らかである
• 話し言葉のコンテンツを数秒後に漫画化したり、ゆっくり解説動画にする技術が実現する

■ 6. YouTuberとコンテンツクリエイターの未来

• あらゆるYouTuberがほとんど失業する未来がある程度見えており、その中間段階が進行している
• 切り取り動画の制作(過去の発言と現在の発言を混ぜて面白くする作業)すらAIができるようになる
• キャラクターとしての価値が重要になり、本人が話すことよりもキャラクターが話しそうなことをAIが生成する方が面白くなる
• 数十万人が考えたキャラクターらしい発言の方が、現実の本人の発言より面白くなるのは時代の必然である
• これはシンギュラリティではなく失業ポイントに向けて進んでいる過程である

■ 7. 新しい仕掛けと失業の連鎖

• ニコニコ生放送などの新しい仕掛けによって多くの人が失業してきた
• その屍の上に現在の成功者が乗っかって商売をしている
• この構造もいずれ崩れていくのは当たり前である
• 恐ろしい未来ではなく、そうなったら次の面白いことを考えるだけである

■ 8. 生き残るクリエイターの条件

• 超優秀なアニメーター、漫画家、絵師は生き残る
• しかし大半の漫画家は職業として成立しなくなる
• アシスタントも同様に厳しい状況に直面する

■ 9. 変化の時間軸予測

• 3年程度で大きな変化が目に見えるようになる
• 食える食えないという最終的な変化には10年程度かかる
• 中間的なポジションにいるクリエイターが本当に危機に直面するまでには5年から10年かかる
• この予測は先取りしすぎているため多くの人は実感できず疑問視するが、5年後10年後には確実に実現する
• 「そうなるべきではない」と考えているとずれてしまうため、時代はそういうものだと認識すべきである

■ 10. 発注型仕事の消滅

• 誰かからお金をもらって発注を受けリクエスト通りに制作する仕事は失われ続ける
• 観光地の似顔絵やディズニーランドのシルエット切り絵のようなサービスは、2000円~3000円の技術料が必要だが、無料で類似のものができる状況では生き残れない
• 超メジャーなネームバリューのある人以外は生き残れない

■ 11. アートから手芸への移行

• 人類に残されたのは自分にしかできない、自分が手を動かして作った趣味をめでるという方向性である
• 現在の手芸ブームはこの流れを反映している
• アートや作品としてではなく、趣味としての手芸として素晴らしいという価値観に流れている
• アートはAIに奪われているため、人間は自分が本当に手を動かして作ったものを愛でる方向に向かっている

■ 12. 現状追認と説得の意図

• この発言は現状追認ではなく、現状を認められない人を説得しようとしている
• 「AIはダメだ」「人間にしかできないクリエイティビティがある」と言う方が、人前で話をする立場としては商売になる
• それを理解しながらも、こだわり続けると苦しいという助言をしてしまう
• カメラに向かって話をする活動自体も、あと何年何ヶ月続けられるか分からない

■ 13. 自動化の波及と共通の運命

• 来月は無理でも来年、再来年には話す内容の自動化が見えてきている
• 全員が同じタイタニック号に乗っている状況である
• 逃げる先は新しい稼ぎ先ではなく手芸のようなものしかない
• この問題に対する明確な解決策は見出せていない

MEMO:

• これはエンジニアも同じで、SESみたいなエンジニアの時間貸し商売は数年以内に成立しなくなると思われる
• QAなどAIの出力を専門家として検証する仕事はしばらく残りそうだが、それですらAIのクロスチェックでよいのでは？　という感覚がある
• 当然正社員雇用のエンジニアも「本当にこんなに人数が必要なのだろうか？」となるのは避けられない
• 今後はAIを駆使して単独で全工程をやりきるコスパ最強のエンジニアしか生き残れないのではないか？

(2025/11/02)

AIがコードを書いてくれるなら、新米エンジニアは何をする？

• AIがコードを書いてくれるなら、新米エンジニアは何をする？ / komekaigi2025 - Speaker Deck

(2025/11/02)

AI時代のソフトウェア開発 文芸モデル駆動アプローチ : 文芸モデルをDSLとした文芸モデル開発と...

• AI時代のソフトウェア開発 文芸モデル駆動アプローチ : 文芸モデルをDSLとした文芸モデル開発と生成AI連携の知識ベース | PDF

(2025/11/02)

コードは書ける、でも"AIを理解してない"エンジニアが増えている現実😭

• コードは書ける、でも"AIを理解してない"エンジニアが増えている現実😭

要約:

■ 1. 現状の課題

• AIアプリエンジニアが急増している:
  • 生成AI(LLM)が普及し誰でも比較的容易に活用できるようになったことが大きな要因である
  • しかし実際のところAIそのものへの理解や理論的な知識を持たずに開発しているケースも少なくない
  • OpenAI APIを使える、LangChainを組めるといったツールとしてのスキルはあってもAIの挙動や構造を理解したうえで設計している人は限られている
• コードは書けるのに結果が出ないケースをよく見る:
  • ノーコード/ローコーディングツールの普及によって誰でも短期間でMVP(最小実行可能プロダクト)を作れるようになった
  • しかし現場レベルで実際に運用・定着するプロダクトになるケースは非常に少ない
  • 一見動くものを作ることはできても使える・価値を生むレベルまで育てるのが難しい
  • 社外にPRされているAI事例の中にも実際には一部組織内だけの限定的活用にとどまっているものも少なくない

■ 2. 何が起きているのか

• ノーコード/サンプルコードの充実によってAIアプリを短期間で作ること自体は簡単になった
• ローコーディングという神ツールも登場し、従来時間のかかっていたコーディング時間は半減し確実にMVPを作るまでは早くなった
• ただし動く状態から使える状態に引き上げるにはきめ細かなチューニングとAIの仕組みへの理解が不可欠である
• このチューニングにはモデル構造やプロンプト設計、データセット設計の知識が求められる
• しかしAIをブラックボックスとして扱っているとどこを調整すればよいか判断できない
• 結果としてAPIを呼び出すだけの構成にとどまり、課題を根本的に解決できないまま止まってしまうことが多い
• 具体例:
  • ベクトルDBをとりあえず繋いでいる、プロンプトを変えてみるだけといった状態で止まっている例をよく見かける
  • 特にプロンプトを変えてみるだけはすごく多いパターンである
  • RAGであればそもそも構造的にプロンプトチューニングの限界があるから仕組み的にリトリーバーの改善を、リトリーバーを変えたということはベクトルDBのメタデータをといったような思考プロセスを持ち合わせる人が少ない
• 技術的にリーチングアウトできるエンジニアは非常に少数である

■ 3. なぜそうなるのか

• LLMのような生成AIに何でも神頼み:
  • 生成AIの進化によってLLMに任せればなんでもできる、マルチモーダル=すごいという空気感が広がった
  • しかし現場業務のような特定のタスクに特化したアプリケーションを作るほど実は汎用的なLLMだけでは十分に対応できることはかなり少ない
  • モデルの限界や誤答特性を理解し適切な技術や設計を組み合わせていく地道な調整が必要である
• 成果物重視・SaaS依存構成による原理の理解の欠落:
  • 事業会社ではスピードが求められたり予算に限りがあったりするため、SaaSや既存APIを組み合わせて素早く成果物を出す傾向がある
  • ただしそれが積み重なるとバックエンドではAPIを叩いているだけになりAIそのものへの理解を深める機会が減ってしまう
  • もちろんSaaSの進化が早いので追いつけないこともある
  • 成果物を優先する判断は正しい場面も多いが理解の機会を意識的に確保することが必要である
• 評価基準が曖昧になり"すごいっぽいデモ"で終わる:
  • デモは盛り上がったけど実務では使われないというパターンも非常に多い
  • 原因は明確で定量的な評価指標やデータセット設計の知見が不足しているからである
  • AIアプリを改善するにはなぜこの出力が良いのか/悪いのかを測れる指標が欠かせない
  • 評価手法を持つことはエンジニアとしてだけでなくプロジェクトの信頼性を担保するビジネススキルにも直結している(相手を説得しやすいのは数値であるため)

■ 4. 本当に有用なAIアプリを作るために必要な理解

• 基礎的な基礎:
  • 例えばLLMの出力は確率的であり設定や入力次第で大きく変化する
  • RAGであればキーワード検索はBM25の頻度計算をベースにといったような理解が必要である
  • ベースの技術を理解できていればうまく行かない時のチューニングの方針や次のアクションを早く決めることができる
  • アジャイル開発であれば次のスプリントのバックログを事前に計画できるのでプロジェクトとして計画的に進めることもできる
• 評価軸(正確さ・再現性・効率性など)を明確にする:
  • すごいではなく安定して成果が出る状態を目指すために評価指標を定義し可視化すること(=見える化)が重要である
• 小さく検証→定量化→改善というループを設計する:
  • 大きなアプリを一気に作るのではなく検証サイクルを短く回す
  • この地道なプロセスが結果的に品質を押し上げる
  • そういった進め方をクライアントもしくは現場と綿密に擦り合わせることも大事である

■ 5. AI時代のエンジニアに求められる姿勢

• AIアプリエンジニアが数多く登場し社内外でAI活用が広がる中で、いまようやく本当の課題はクオリティだと気づき始めているのではないか
• AIに対する理解を深め使えるレベルまで磨き上げる姿勢がこれからのエンジニアには求められる
• AIを使える人は増えた
• しかしAIを理解して活かせる人こそがこれからの時代に強い

(2025/11/01)

DBのcolumn名や、何らかドメインの意味を持つ概念に type を名付けない方が良いのではないか

• DBのcolumn名や、何らかドメインの意味を持つ概念に type を名付けない方が良いのではないか - その手の平は尻もつかめるさ

要約:

■ 1. type という命名を避けるべき理由

• type やそのサフィックスを持つ名前(_type など)を変数、構造体・クラスのメンバー、データベースのカラムなどに付けてしまうことがしばしばあるが、あまりやらない方が良い
• 理由1(予約語との衝突):
  • type はいくつかのプログラミング言語において予約語になっており、そのセマンティクスにおいて特別な役割を果たすことが多い
• 理由2(フレームワークとの衝突):
  • Ruby on RailsにおいてはDelegated Typesという機能において_type というカラムは特別な意味を持つ
  • もちろんアプリケーションコード側でDelegated Typesであるという宣言をしなければ副作用は無い
  • その他のフレームワークに似たようなものがあるのかは不明である
• こういった概念との衝突を避けるために特別かつ強い理由が無い限りは type という命名は避けるという方針

■ 2. 代替案

• 代替としては kind や method などが使えそうである
• これらを採用することが多い
• method は別の概念との衝突がある場合もありそうだが、そこは文脈に沿って対応する

■ 3. 例外的にtypeを使用する場合

• どうしても type でしか表現できないものはあると思われる
• 例えば言語処理系を作っていて本当に「型」を取り扱う必要がある場合などである
• そういった場合は頑張る必要がある

MEMO:

• KubernetesではGoで実装されている事が多く、Goでは type が予約語になっていて使えないので kind が多用されているらしい

(2025/11/01)

「タスク遅れに対しての手札をふやす」ことが、マネージャーの立ち回りとして大事だという話

• 「タスク遅れに対しての手札をふやす」ことが、マネージャーの立ち回りとして大事だという話 | Books&Apps

要約:

■ 1. マネージャーの価値とタスク遅れ対処

• タスク遅れ解決のための手札をどれだけ持っているかがマネージャーの価値である
• タスク遅れは必ず発生するものであり、必ず対処しなければならない
• タスク遅れに対してどんな手を打てるかは組織次第、状況次第で変わる
• タスク遅れ解決のための手札をなるべく増やすように、普段から立ち回りを意識することが重要である

■ 2. タスク遅れが必ず発生する理由

• 工期の見積もりはあくまで見積もりでしかなく、完璧な見積もりは絵に描いた餅である
• プロジェクト遂行中のトラブル:
  • エスパーでないと予知できないトラブルが発生する
  • メンバーが体調を崩したりサボることもある
  • タスクが難しすぎたり、依存関係が複雑過ぎて手がつけられないこともある
• タスクごとにリスクを計ってマージンを作るが、存在するマージンは基本的に全て食い潰されるため、大抵それ以上にタスクは遅れる

■ 3. タスク遅れに対する手札の三つの分類

• 人的リソースでなんとかする:
  • やる人の手を増やしたり、費やす時間を増やすことで対処する方法である
  • 残業時間を増やす、対応メンバーを追加する、誰かに手伝ってもらう、出来る人を連れてきてもらうなどが含まれる
  • 一番分かりやすいが故にマネージャーにとっては安易に頼ってしまいがちな方法である
  • 頑張るしか手札を持っていない人である場合、時々悲劇が発生することもある
  • 人的リソース以外の手札を何枚持っているかがマネージャーの有能さを示す一つの指標である
• 調整でなんとかする:
  • 他の担当チームやクライアントと相談してスケジュールを延ばしてもらう、実装する機能のスコープを見直してタスク自体をスケールダウンする、機能を簡易化してタスクの難易度を下げる、上にエスカレーションするなどが含まれる
  • 人的リソースでなんとかするよりもマネージャーにとっての難易度は高い傾向がある
  • 組織によっても仕事の質によってもどれだけの選択肢がとれるかは変わる
  • タスク遅れと言われた場合、この辺の選択肢がマネージャーに期待される部分は大きい
• プロセスをなんとかする:
  • レビューや事務手続きで時間を食い過ぎている場合、リスクをとったり簡略化してプロセスを改善する、メールのやり取りで時間を食っている場合は拠点を移して対面で話せるようにするなどが含まれる
  • 開発手法を変更する、ツールでテストを自動化する、作業を分割して開発を並列化する、クリティカルパスの見直しや後工程を前倒しで始めることで全体としての遅れを吸収するなどの方法もある
  • 遅れが顕在化してからよりも普段からの準備が重要である
  • 一般的には三つの中で一番難易度が高いケースが多い
  • マネージャーにとっては腕の見せ所である
  • 下手にプロセスをいじると逆効果になることもある

■ 4. マネージャーが把握すべき三つの観点

• マネージャーとしての自分はタスク遅れの対応策を幾つ知っているか
• そのうち現在の環境、現在のプロジェクトで実際に取り得る対応策はどれか
• そのうち最も効果的でなるべくコストを低減できる対応策はどれか

■ 5. 環境による制約と手札の確保

• タスク遅れの対応策は環境、仕事の種類によって選択できるものが変わる
• クライアントとの関係次第ではスケジュールの調整ができないかもしれない
• 品質は絶対厳守でテスト工数は絶対に減らせないかもしれない
• 有識者を連れてこようにも他チームも全部炎上しているかもしれない
• 頑張る以外の手札をどれだけ用意できるか、調整とプロセスからそれぞれ二枚、三枚の手札を選択できるだけの余地を確保できているかが重要である

■ 6. 普段からの立ち回りの重要性

• 常に使い得る手札を把握しておき、できることならその枚数を増やせるように立ち回っておくことがマネージャーとして非常に重要である
• 事前準備の具体例:
  • 常日頃から他チームといい関係を築いておき、いざという時にはヘルプを求められるよう恩も売っておく
  • スコープの見直しの可能性やリスクについて事前にクライアントと調整しておき、いざという時は切り捨てても良い機能や品質の落とし所について確認しておく
• リスク計画はプロジェクトの立ち上げ時点で個別に考えておくべきテーマであるが、普段からの立ち回りで事前準備が必要な部分でもある
• タスク遅れという分かりやすいピンチでどういう手札を持っているかはマネージャーとしての一番の価値である
• 手札を増やす努力自体が会社での自分の立ち位置を向上させていくための努力とほぼイコールになる

■ 7. 具体的な解決事例

• 新人マネージャーが一つの開発環境内で全部解決しようとして色々引っかかっていた
• もう一つ環境を作ってそのリソースを使えば解決できるというアドバイスで解決に向かった
• 解決できそうな人に事前に渡りをつけておくこともマネージャーとしての価値を高めるための一つの方法である

(2025/10/31)

“アナログコンピュータ”でGPU超え？ 特定の演算でH100の10倍高速かつ省エネ、AI学習へも応用可能性...

• “アナログコンピュータ”でGPU超え？ 特定の演算でH100の10倍高速かつ省エネ、AI学習へも応用可能性、Nature系列誌で発表 | レバテックラボ（レバテックLAB）

(2025/10/31)

ざっくり学ぶ 『エンジニアリングリーダー 技術組織を育てるリーダーシップと セルフマネジメント』

• ざっくり学ぶ 『エンジニアリングリーダー 技術組織を育てるリーダーシップと セルフマネジメント』 / 50 minute Engineering Leader - Speaker Deck

(2025/10/31)

ドメイン駆動設計のエッセンス

• ドメイン駆動設計のエッセンス - Speaker Deck

tag:

• 増田亨

(2025/10/31)

ソフトウェアエンジニアにおける才能という幻想、あるいは成長を阻む最大の敵について

• ソフトウェアエンジニアにおける才能という幻想、あるいは成長を阻む最大の敵について - じゃあ、おうちで学べる

(2025/10/30)

設計原則と普遍的な判断軸

• 設計原則と普遍的な判断軸 | ドクセル

(2025/10/30)

FAST導入1年 ログラス×ユーザベース対談

• FAST導入1年 ログラス×ユーザベース対談 - Agile Journey

(2025/10/30)

コロケーテッドアーキテクチャ概要

• コロケーテッドアーキテクチャ概要 - Commune Engineer Blog

(2025/10/30)

【心理学】ダブルバインドが横行する殺伐とした開発現場は実在するので、メンバーは自己防衛の手段...

• 【心理学】ダブルバインドが横行する殺伐とした開発現場は実在するので、メンバーは自己防衛の手段としての心理学を身に付けて冷静に対処したい

(2025/10/29)

Microsoftの1ビットLLM「BitNet」の進化版「BitNet Distillation」、既存マルチモーダルLLMで長文を...

• Microsoftの1ビットLLM「BitNet」の進化版「BitNet Distillation」、既存マルチモーダルLLMで長文を画像化する効率的AI処理など生成AI技術5つを解説（生成AIウィークリー） | テクノエッジ TechnoEdge

要約:

■ 1. BitNet Distillation(Microsoft Research開発)

• 概要: 既存LLMを1.58ビット精度(-1、0、1の三値重み)に変換する手法で、2023年発表の「BitNet」の進化版である
• BitNetの問題点:
  • 競争力のある精度を得るには大規模コーパスでゼロから事前学習する必要があり、膨大な計算コストがかかる
  • 既存のフルプレシジョンモデルを直接1.58ビットに変換すると性能が大幅に低下する
  • モデルサイズが大きくなるほど劣化が拡大する
• BitDistillの改善点:
  • Qwenなどの既存高性能LLMを出発点として使用できる
  • SubLNモジュール、MiniLMベースの蒸留、継続的事前学習という3段階の最適化により、フルプレシジョンモデルと同等の精度を維持する
  • モデルサイズが増えても性能劣化が起きない優れたスケーラビリティを実現した
• 実験結果:
  • 分類タスクやテキスト要約などの下流タスクでフルプレシジョンモデルと同等の精度を達成した
  • メモリ使用量を10分の1に削減し、CPU上での推論速度を2.65倍高速化した
  • レイテンシ、スループット、メモリ効率、エネルギー消費において改善を提供する
  • スマートフォンなどのエッジデバイスでの実用的なLLM展開が容易になる

■ 2. HunyuanWorld-Mirror(Tencent開発)

• 概要: 画像や動画から立体的な3D空間を数秒で生成できるAIフレームワークである
• 入力の柔軟性:
  • 1枚の画像だけでなく、複数視点の画像や動画に対応している
  • カメラの姿勢や内部パラメータ、深度マップといった多様な幾何学的事前情報を柔軟に統合できる
• 出力の多様性:
  • 点群、複数視点の深度マップ、表面法線、3Dガウシアンなど複数の3D表現を同時に生成する
  • Multi-Modal Prior Promptingという新しいメカニズムにより事前情報がトークン化され、画像情報と効果的に統合される
• 技術的特徴:
  • トランスフォーマーベースのアーキテクチャを採用している
  • カメラパラメータの回帰から密な予測タスクまで統一的なデコーダーヘッドで処理する
  • トレーニング時に異なる事前情報の組み合わせをランダムにサンプリングすることで、推論時に利用可能な情報が限定的な場合でも柔軟に対応できる
• 性能評価:
  • 点マップとカメラ推定ではVGGTやπ³を上回る
  • 表面法線予測ではStableNormalやGeoWizardを凌駕する
  • 新規視点合成ではAnySplatを超える結果を示した

■ 3. DeepSeek-OCR(DeepSeek-AI発表)

• 概要: 長大な文書コンテキストを画像化して効率的に処理するシステムである
• 処理方式:
  • OCR(光学文字認識)技術を用いて、手書き文書や書籍をスキャンして画像データに変換する
  • 視覚トークンという圧縮された形式を使用してテキストを大幅に圧縮し、計算処理を効率化する
• 圧縮効率:
  • 元のテキストトークンを10分の1に圧縮しても97%という高い文字認識精度を維持できる
  • 20分の1まで圧縮しても約60%の精度を保てることが実証された
• システム構成: DeepEncoderとDeepSeek3B-MoE-A570Mデコーダーという2つの主要コンポーネントで構成される
• ベンチマーク性能:
  • OmniDocBenchにおいて100個の視覚トークンのみでGOT-OCR2.0(256トークン/ページ)を上回る
  • 800個未満の視覚トークンでMinerU2.0(平均6000トークン以上/ページ)を超える性能を発揮した
  • 単一のA100-40G GPUで1日あたり20万ページ以上の学習データ生成が可能である

■ 4. テキスト画像化による計算コスト削減研究(アレン人工知能研究所など)

• 研究目的: 長文テキストを単一の画像として描画してモデルに直接入力することで、マルチモーダル大規模言語モデル(MLLM)の入力トークンを削減しながら性能を維持できるかを検証する
• 背景課題: 現在のLLMはTransformerアーキテクチャにより、入力長に対して計算コストが2次的に増加するという課題を抱えている
• 研究アプローチ:
  • GPT-4 VisionやGoogle Gemini 2.5などの最新MLLMが画像からテキストを読み取る能力に着目した
  • テキストの画像表現を入力圧縮の手段として活用することを検証した
• ConTexImageパイプライン:
  • テキストを制御された解像度の画像に変換する
  • フォントサイズを自動調整して最適な可読性を確保する
  • 大規模モデルで最大45%のエンドツーエンドの処理速度向上を実現した
• 実験結果:
  • 長文タスクのRULERベンチマークと要約タスクのCNN/DailyMailベンチマークで評価を実施した
  • GPT-4.1-miniとQwen2.5-VL-72Bモデルは、最大58%少ないデコーダートークンで97～99%の精度を維持した
  • 要約タスクでも既存の圧縮手法を上回る性能を示した
  • 72Bパラメータの大規模モデルは視覚的に密集したテキスト情報を効果的に処理できることが明らかになった

■ 5. 共通トレンド

• 効率化技術の進展:
  • ビット精度削減によるメモリとエネルギー効率の改善(BitNet Distillation)
  • テキストの視覚トークン化による圧縮と高速化(DeepSeek-OCR、テキスト画像化研究)
• マルチモーダル統合の高度化: 画像、動画、テキストなど異なるモダリティを効果的に統合する技術が進化している(HunyuanWorld-Mirror)
• エッジデバイス展開の促進: 軽量化技術によりスマートフォンなどでの実用的なLLM展開が現実的になっている

(2025/10/29)

技術力に優劣はある(「技術力に優劣はない」を読んで)

• 技術力に優劣はある(「技術力に優劣はない」を読んで) - じゃあ、おうちで学べる

(2025/10/28)

サイゼリヤのセルフオーダー、プログラミング初心者のアプリみたいだけど大丈夫そう…？→いや異常な...

• サイゼリヤのセルフオーダー、プログラミング初心者のアプリみたいだけど大丈夫そう…？→いや異常な要件定義の精度でUXの本質を理解している - Togetter

(2025/10/28)

PRDの正しい使い方 ～AI時代にも効く思考・対話・成長ツールとして～【パーソルキャリア】

• PRDの正しい使い方 ～AI時代にも効く思考・対話・成長ツールとして～【パーソルキャリア】 - TECH PLAY

関連:

• PRDの正しい使い方 ～AI時代にも効く思考・対話・成長ツールとして～

(2025/10/27)

Why I code as a CTO

• Why I code as a CTO

要約:

■ 1. CTOとしてコードを書き続ける理由

• 一般的な通念への反論: 多くのCTOはコードを書かなくなるが、筆者は過去12ヶ月間で大量のコードを出荷している
• 直属の部下ゼロ: 現在直属の部下を管理しておらず、会議の合間に少し書く程度ではなく、前四半期に複数の実質的な機能を出荷した
• 高いレバレッジ: コードを書くことは技術リーダーとして行う最もレバレッジの高い活動の一つである
• 誤解への反論: CTOがコードを書く場合、ペットプロジェクトや形式的なコードレビューをしていると思われがちだが、実際は異なる

■ 2. 長期的実験プロジェクトの推進

• 希少なリソース: 組織内で実質的に新しいものを構築できる人材は実は希少なリソースである
• 組織の特性: 組織は一般的に現状維持と現行製品のスケーリングのために構築された生物である
• 限られた人材: 新製品を生み出せるのは創業者、数人の幹部、一部の高レバレッジな個人貢献者のみである
• 新アイデアの重要性: 新しいアイデアを推進することは意図的で持続的な努力を必要とするため非常に重要である
• エンジニアの制約: 組織構造、ロードマップのインセンティブ、限られたリスク予算により、大半のエンジニアは曖昧な賭けを追求する時間を取れない
• CTOの優位性: 顧客の痛点とアーキテクチャを十分に理解しているため、これらの重要な実験プロジェクトを引き受けるのに独自の立場にある
• AIチャット製品の事例: 顧客向けAIチャット製品について議論していたが誰も時間がなかったため、感謝祭の休暇中にプロトタイプを作成し、チームと協力して数百万ドルのARR製品に仕上げた

■ 3. 緊急性の高い顧客要求への対応

• 緊急案件の特性: 重要な顧客が緊急に何かを必要とし、それが大型契約や更新の障害になる場合がある
• 必要な能力: 迅速に動き、システム全体を理解し、実用的なトレードオフを行える人材が必要である
• スプリントの中断回避: エンジニアを現在のスプリントから引き離す代わりに、CTOが騒音を切り抜けることができる
• コンテキストと重要性の理解: すでにコンテキストを持っており、リスクを理解している
• データ編集機能の事例: 年間100万ドルの顧客がコンプライアンス上の理由で統合機能に完全なデータ編集を必要とした際、1日で動作バージョンを構築して出荷した

■ 4. バグ修正による知見の獲得

• 意外な活動: 人々は驚くが、筆者は多くのバグを修正している
• コードベースの理解: バグ修正はコードベースのメンタルマップを維持するための好きな方法の一つである
• システムの横断: ページネーションやWebSocket接続の問題を追跡する際、システムの広大な領域を横断する
• 技術的負債の理解: コードレビューやアーキテクチャ議論からは得難い技術的負債の内臓的理解が得られる
• 意思決定への貢献: このメンタルマップは技術投資やチームが注力すべき場所についてより良い決定を下すのに役立つ

■ 5. 実際に機能するものを把握し続ける

• AIツールの日常使用: Claude Code、Codex、Cursorなどの多数のAIツールを日々使用している
• 戦略的意思決定: ツールや採用に関する戦略的決定を行う際、何が本物で何が偽物かを理解できる
• 具体的事例: 複雑な統合に触れる機能をバイブコーディングで試みたが、最終的に手作業で書いた方がはるかに進捗した
• AIの強みと弱み: AIがCRUD、テスト、ボイラープレートで輝き、精度やシステムのニュアンスで失敗することを知ることは、Twitterの誇大広告に基づく決定よりも常に優れている
• 直感の獲得: コードの中にいることで、アーキテクチャが過度に複雑な時や技術的負債が実際の問題になっている時を感知できる

■ 6. 自分の好きなことと得意なことに集中

• 組織構築への不向き: 組織を構築したり人事関連を扱うことを特に楽しんでいない
• エンジニアリング管理の課題: 対人関係のダイナミクス、パフォーマンスレビュー、組織設計のナビゲートが含まれるが、これらは筆者の強みではない
• 優秀な管理者の採用: 優秀なエンジニアリングマネージャーとリーダーを雇用し、彼らはそれを楽しんでいる
• 自分の強みへの集中: ものを作ること、技術的問題を解決すること、コードを書くことに集中できる
• 長期的持続性: スタートアップは疾走するマラソンのようなものなので、自分を興奮させ長期間速く走り続けられる仕事の周りに役割を設計している

■ 7. AIツールによるレバレッジの変化

• 過去の苦悩: 数年前は戦略的な仕事をこなしながらコードを書く時間を見つけるのに苦労していた
• 会議漬けの日々: 会社が成長するにつれ、基本的に一日中会議に拘束され、天才ゾーンの外で活動していた
• 生産性の向上: 現代のAIツールが根本的にこの方程式を変え、以前より2～3倍生産的になった
• 判断力の価値向上: これらのツールは判断力や技術知識を置き換えるのではなく、実際にそれらのスキルをより価値のあるものにした
• コンテキストの活用: 正確に何が必要でどこで見つけるかを知っているため、AIツールに指示を出すことで大部分のコードを正しく生成できる
• 役割の変化: 仕事は「すべてのコード行を書く」から「コンテキストを提供し、決定を下し、解決策を評価する」へとシフトした

■ 8. 自分に合った働き方の発見

• Greg Brockmanの影響: StripeでのCTOの役割定義についてのブログ投稿を読み、役割に膨大なバリエーションがあることを認識した
• CTOの多様性: 技術的ビジョナリー、組織ビルダー、インフラ重視など、CTOの役割は様々である
• 共通点: 優れたCTOは自分の特定のスキル、興味、会社のコンテキストを考慮して最も価値を創造できる場所を見つけ出す
• 筆者の特定の道: ソフトウェア構築を組織設計より楽しみ、深い顧客とコードベースの知識を持ち、強力なエンジニアリングマネージャーを雇用したという特定のコンテキストで機能している
• 処方箋ではない: これは筆者の特定の道であり、処方箋ではない
• 柔軟な役割: CTO役割は驚くほど柔軟であり、組織構築、製品戦略開発など、技術リーダーシップは強み、活力の源、会社のニーズによって異なる
• 多様な道の存在: リーダーシップが技術的仕事を放棄することを意味すると心配するエンジニアに対し、多くの道が存在することを知ってほしい
• 成功の鍵: 自分が独自に優れている場所を見つけ出すことが鍵である

(2025/10/26)

Python 20年史──脚光の裏にあった「日本語対応」と「パッケージ配布」

• Python 20年史──脚光の裏にあった「日本語対応」と「パッケージ配布」 (1/3)|CodeZine（コードジン）

(2025/10/26)

シニアエンジニアから学んだ考え方

• シニアエンジニアから学んだ考え方 - Cybozu Inside Out | サイボウズエンジニアのブログ

(2025/10/26)

システムの引き継ぎに失敗しないための本

• システムの引き継ぎに失敗しないための本 担当者の交代、ベンダー変更、アウトソーシング化に対応できる！ ｜ SEshop｜ 翔泳社の本・電子書籍通販サイト

担当者の急な退職などで発生する引き継ぎ。

いざ始まると「前の担当者と連絡が取れない」「引き継ぎ書の内容が意味不明」「書いてあるコードが難しくて読み解けない」などさまざまな問題が生じるもの。

「システムの引き継ぎ」について検索しても、断片的な記事や簡易的な説明しか得られませんでした。

そこで本書は、全体像と具体策を一度に学べる手厚いつくりで、これまで当事者が抱えてきた悩みを解消できるようにしています。

〇本書のポイント

・計画～実施～安定稼働まで、引き継ぎの全工程を体系的にしっかり解説

・炎上案件や未完成システムなど、困難な立て直しの事例も豊富に収録

・引き継ぎトラブルを知り尽くした著者の教えるノウハウだから、現場ですぐに役立つ

・使いやすい引き継ぎ書のフォーマット付き

〇こんな方におすすめ

・退職、異動、外注切替などで引き継ぎを担う現場の担当者

・経営者、総務部門などの立場の方

・1人しか情報システム担当者がいないケースの後任者

・外部ベンダー、開発会社の担当者

この一冊を読めば、どんな場面でも慌てず、確実にシステムを守り抜くことができるようになります。

MEMO:

• 2025/11/12発売

(2025/10/25)

「化け物ハッカー」にはなれない、と気づいた先に。新多真琴が自分を認められるまで

• 「化け物ハッカー」にはなれない、と気づいた先に。新多真琴が自分を認められるまで | LIFE DRAFT

要約:

■ 1. 「ハッカーの呪縛」からの解放

• 新多真琴(あらたま)氏が2023年3月のYAPCで行った講演「あの日ハッカーに憧れた自分が、『ハッカーの呪縛』から解き放たれるまで」は大きな反響を呼んだ
• 新卒で入社したDeNA時代に自らにかけた「ハッカーの呪い」とは、技術で突き抜けなければならないという強迫観念であった
• この講演はエンジニアとして「技術で突き抜ける」以外の道を示す内容で、多くの人が救われる思いをした

■ 2. 現在のキャリア

• DeNA退社後は二つの企業を経て、Cake.jpで若くしてCTOを経験した
• 現在はLayerXでエンジニアリングマネージャーを務めている
• 音大卒で、プログラミングを学び始めたのは大学生になってからというユニークなキャリアである
• メディア出演の機会も多く、自分を客観視している印象だが、キャリア初期は「自分を見る鏡が磨かれていなすぎて、虚像を見ていた気がする」と語る

■ 3. 自己分析能力の獲得

• 自己分析が得意になったのはここ6、7年くらいで、以前はもっとぼんやり生きていた
• 紆余曲折を経て、自分とちゃんと向き合った方が自分にとってもいい人生にできるし、関わる人に対してもいいものを渡せると気づいた
• きっかけ: 以前いた会社で思ったほど評価されないと感じ、すごく頑張ってプロダクトにいい影響を与えたはずなのに意外と評価されないと思った
• 気づき: 「結果を出していれば評価は後からついてくるでしょ」というのはすごく傲慢な物言いで、評価する側がどう評価したらいいのかを判断するための材料まで含めて渡すことが被評価者としての義務である

■ 4. 評価のされ方の学習

• 改善策:
  • 「期が締まるまでにここまで打ち上げます」という宣言をする
  • 月ごとに振り返りつつ、実際に期が締まるタイミングで「もともと言っていたところにこれくらいオンしました」「あとこのくらいでした」「この部分はこういう評価になりますよね」というところまでまとめて渡すようにした
  • そうしたら結果がついてくるようになった
• きっかけ: VPoEに「マネージャーという仕事をたいして知らなくない?」と言われ、マネージャーとは何かを調べ出した
• 学習過程: 本を読んだり、メンバーレイヤーでもできそうなマネジメントスキルやリーダーシップを発揮しようとやってみた

■ 5. DeNA時代の新人メンター経験

• 新卒2、3年目のときに下の代のメンターをやることになったが全然うまくいかなかった
• ずっと新卒に「正論パンチ」しまくって、お互い険悪になった
• 原因: 自己肯定感も全然なかったので、自分のできることはみんなもできることと思ってしまっていた。その尺度で話してしまうと「なんでこんなこともできないの?」みたいなことを言ってしまった
• マネジメントに関して改めてインプットし始めたタイミングで、初めてそのときに抱えた傷を自分でちゃんと解釈して落とし込めるようになった

■ 6. DeNA時代の「化け物」との比較

• DeNA時代のあの環境には「化け物」がいっぱいいたため、ずっと一番下だと思っていた
• 何をやっても自分は最下層だと感じていたが、実際はそれなりに働いていて評価もされていた
• しかしそれを客観的にキャッチできていなかった
• 自分の中のイメージとギャップ: 技術的に突き抜けていないといけないと考えていた
• 周りには突き抜けた人たちがいっぱいおり、彼らを見て何かを捨てることなく差を縮めようとするが全然縮まらなかった

■ 7. 評価のギャップ

• 周りからの実際の評価:
  • 周りは別に突き抜けることなんて求めていなかった
  • むしろプロジェクトを前に進めることや周りを巻き込むこと、何とかして物事をうまく行かせる力があるという評価をされていた
• 当時の認識: 「そんなものはやったら誰でもできるじゃん」と思っていた。プロジェクトマネジメントみたいなことを任されるのはたいして期待されていないからだろうと思っていた
• ひねくれていた状態であった

■ 8. 職人タイプへの憧れの理由

• ひとかどの人間になりたかった
• それがいいとされる価値観だった
• YAPCというPerlハッカーのカンファレンスでいいねとされる人たちはやっぱり技術的に頭一つ抜けていた
• 世の中を文字通り技術で変えにいっている人たちだった
• そういう人たちに憧れてDeNAに入社を決め、ハッカー集団がいる部署に絶対に行きたいと考えた
• 「卒業して配属研修を終えて、もしそこに配属されなかったら辞めます」くらいのことを言っていた

■ 9. オーケストラの指揮者としての役割

• 実際は尖った人たちばかりいてもチームとしては機能せず、まとめる人や間をつなぐ人もやっぱり必要である
• オーケストラの指揮者のような役割を自分はできていたが、そこがチームに足りていないとも思っていなかった
• そのポジションの重要性は全然わかっていなかった
• なにやらありがたがられている、なにやら評価されているらしいことはわかるが、それは自分の実力がないからだという認識が結構長く続いた
• それは退職してからもずっと続いた

■ 10. 仮想敵の問題

• 同年代の仲間でも技術で頭角を表している人はいるので、そういう姿を見てしまうと翻って自分はと思ってしまう
• 仮想敵が強すぎた

■ 11. ピアノと音楽のキャリア

• 幼稚園から始めて中学では合唱部で伴奏をやっていた
• 音楽は自分のアイデンティティだった
• 学校に一人とか学年に一人いるピアノが上手い人だった
• 小学校のときのピアノの先生に「あなたいいわね」「音大附属に行きなさい」と言われて調子に乗って「絶対に音大に行く!」と言ってしまった
• 高校2年くらいまではピアノで食べて行こうと思っていたが、入学した頃からだんだんと陰りが見え始めた
• 音大には「学校に一人いる上手い奴」が全員集まるため、どんなによく見積もっても「中の上」くらいに思えてしまった
• 家庭環境が音楽一色の子たちがたくさんいて、どう頑張ってもその子たちのようには弾けないなと悟った

■ 12. 音大でのピボット

• 初めて今後の人生について考え始めた: 音楽では食っていけないのではないか
• ヤマハの先生になりたいわけでもなく、「ピアノじゃないかも」と思った
• すでに高2高3なので他大を受験するには遅すぎた
• 附属からそのまま上がった大学で何か面白そうな学科を探し、コンピュータを使って作曲する学科があることを発見した
• パソコンが好きだったことと、唯一就職率についての言及があったため、「ここにいけば食いっぱぐれることはなさそう」という邪な気持ちもあり受けて滑り込んだ

■ 13. プログラミングとの出会い

• コンピュータ音楽専修という学科で、コンピュータ技術の発展とともにできるようになった表現を取り入れて音楽創作の新しい姿を模索する
• プログラミング、C言語の基礎科目があり、「ちょっと面白いかもしれない」と思った
• 周りは軒並みぐったりしていて「あれ、楽しいと思うのは私だけ?」と感じた
• そこで初めて「人よりもちょっとできる」というものが見つかり、そこからクリエイティブコーディングに走り始めた
• 卒業制作では音大の卒制に音の出ないアプリを提出するという暴挙に出た

■ 14. インターンとDeNA入社

• 学生時代からGoogleやカヤックなどにインターンに行っていた
• 1年の真ん中頃にはもうプログラミングにハマっていた
• カヤックのインターンでお世話になった社員が誘ってくれたのがYAPCで、そこで当時DeNAで尖った人たちをまとめるマネージャーをしていたhidekさん(木村秀夫さん)の基調講演を聞いた
• hidekさんの話を聞いて「この会社だったら自分も成長できるのではないか」「ここに行きたい!」となった
• ここで憧れが強く形成されてしまったばかりに、この先10年悩まされることになった

■ 15. 挫折の認識

• 当時の自分はピアノや作曲に関する挫折を挫折として認識していなかった
• なんならピボットしてやったぜ、みたいな感覚だった
• 「おもしろ重視で全部の話に乗っかっていったら、気づいたらエンジニアになってました」くらいの気持ちだった
• DeNAの最終面接で「これまでにした一番大きな挫折はなんですか?」と聞かれたときも「いや、ないっすね」と答えた
• 「じゃあ高校とか大学のことを振り返ってみましょう」と言われていろいろ話していたら「それって挫折じゃない?」と指摘されて「はっ、そうか!」と気づいた

■ 16. 虚像からの脱却

• 自分を見る鏡が磨かれていなすぎて、虚像を見ていた気がする
• 技術で突き抜けることが求められていることだと思っていた
• 期待に応えられていないとずっと思っていて、それが苦しかった
• 尊敬するマネージャーの先輩もいたが、自分はそうではなく技術で突き抜けることを期待されていると思い込んでいた
• 誰も頼んでいないのに

■ 17. 腹落ちのタイミング

• それが虚像だったと腹落ちさせられたのは2023年3月である
• YAPCで例の講演をしたときである
• 4社目のCake.jpでCTOとして2年くらいやって、事業を前に進めるために必要なことや会社を会社たらしめるために必要なこと、その中でエンジニアが担うべきロールを曲がりなりにも言語化できるようになってきた
• ちょうどYAPCがあるということで、キャリアを振り返ってみようと思った
• 2011年に火を灯してもらったところから今までを振り返って、ハッカー憧れを自分はどういうふうに昇華させていったのかというプロポーザルを出した

■ 18. YAPCでの反響

• 通ってしまったので頑張って話したら想定以上の反響があった
• びっくりしたのは、自分と同じようにもがき苦しんでいる人がこんなにもいるのかということ
• 特に若手の新卒3年目くらいまでの人は、自分なりの価値基準がまだできていないから、周りの強い人たちを見て「自分はこんなに強い人にはなれないのではないか」「この先エンジニアとしてキャリアを歩んでいくのにふさわしくないのではないか」といったことを考えてしまう
• そうやって苦しんでいる人がすごく炙り出された
• かつての自分みたいな人が今でもたくさんいるということと、そういう人たちに対して「こういう価値基準もあるよね」というものを一応お渡しできたという実感ができた
• それで「ああ、やめよう」「もう大丈夫だな、私は」と思った

■ 19. CTOという肩書き

• CTOに就任したときは「やっていることに名前がついただけだな」という感じだった
• 入った段階からそのポジション前提でオファーをもらっていた
• 「CTOになった!」という特別な感慨はない
• ただ、CTOというパスがあると入れる場所が結構あり、それによって得られたコネクションや知見がすごくあるので感謝している

■ 20. LayerXへの転職

• 学生スタートアップをやっていたときの同僚にLayerXのCTOの松本がいた
• 仲は良かったのでその後も年に2回くらいのペースで会って、壁打ちや「最近どう?」みたいな話はずっとしていた
• 前職から「CTO候補としてどうか」というオファーをもらったときに松本に相談したら「あらたまさんはバランサータイプだからたぶんいける」と言われて、なるほど、彼が言うならきっといけるんだろうと思ってオファーを受けた
• 「あのとき背中を押してくれてありがとう、ところでそろそろ」みたいな流れで転職した
• 転職をする際は一緒に働く人を重視する
• きっかけとしては人に誘ってもらって興味を持って、この人「たち」と働きたいになれたら移ってくる

■ 21. 現在の立場とハッカーへの憧れ

• EMという立場になった今でも、ハッカーへの憧れは固執しなくなったというだけで今もある
• あるのも含めて自分だと思えるようになった
• そこに対して手を伸ばし続けるために、技術力、エンジニアリングからすごく離れるみたいなことは今はやりたくないと思っている
• 相対的に割合が減って1割とかになってしまってもそこは手を伸ばし続ける

■ 22. 会社と人の関係性

• 会社って結局人が寄り集まって事を成しているものなので、それをブーストさせるのも棄損させるのも人と人の関係性だと思っている
• 事業に関する戦略をどう立てるかももちろん大事だが、それをどうやり抜けるかも会社がちゃんと成長していくためにはすごく必要なファクター
• そのためには関係性というのが一番テコがかかるところだと思っているし、自分はそこに力を割くことがパワーの全体総量を一番大きくできると考えている
• これからもそういうところに手を当て続けることを考えるんだろうなと思っている

■ 23. 技術書と組織本の読書比率

• 技術書を読むスピードよりも組織などの本を読むスピードの方が早い
• エンジニアリングや技術が自分の中で占める割合が以前より小さくなっているとは言える
• そのことに対する寂しさはあまりない
• たぶんHOWに関するこだわりがそんなにない
• LayerXは割とそういう人が多く、「無法者集団だね」と話している
• 「成果が出るならなんでもいいじゃん」みたいな感じが結構好きである

■ 24. 内発的動機の重要性

• 自己評価を他者に委ねているうちは何をやってもダメだと思う
• それよりは内発的動機に目を向ける機会がもっとあれば良かったと考える
• 内発的動機は「これをやりたいんだ!」という強烈な欲求のようなものとして立ち現れることはそうそうない
• 「これよりはこっちの方が自分は楽しめるな」とか「他の人が発揮していないこだわりを発揮しちゃってるな」とか「他人がやっているこれが許せない!」など、自分の心が動いた瞬間をちゃんと自分でキャッチして、それはなぜなのかを深掘りしていく
• それをよりできるためには誰にどうしたらいいだろうというふうにアクションにつなげていく
• それを繰り返すことで自分自身を認めてあげることにもなるし、多少なりとも評価がついてくるようにもなる

■ 25. やり切ることの重要性

• 音楽に関してもエンジニアリングに関してももしかしたら諦めるのが早過ぎたなと振り返って思う
• ピアノはまあまあやっていたが、もっと頭を使って演奏できたよな、何も考えずに取り組んでいたなと思ってすごく悔しくなったタイミングが数年前にあった
• 作曲に関しても苦手だなんだと言って、やる前から諦めていなかったか
• 基本的にアウトプットの質はインプットの量とそれをどう経験に落とし込めたかの掛け算だと思っている
• それをやってきたかと言えば、やらないうちに諦めていたというのがあって、すごくもったいなかったなと思うし今でも後悔していることの一つ
• 「やり切ったけど、ここまでの高みには届かなかった。だからばっさりやめて次の道を探そう」と言えた方がしこりが残らなくていい
• 自分なりにやり切ることは改めて大事にしたいと思っている

■ 26. 自分がよしとする基準

• 周りからの評価以前に、自分なりにやり切れたと言えるかどうかが大事である
• 自分がよしとすればいい
• 何をもってよしとするかの判断基準が、他者から認められるとか名声を得るとか、他者に依存した自分ではコントロールできないものになってしまうと苦しい

■ 27. コピーバンドの経験

• 最近コピーバンドを始めた
• 飲み会の後に「好きな曲を好きなだけ歌い散らすカラオケをやろう!」となり、その中の一人がめちゃくちゃテンションが上がって「バンドやろう!」と言い出した
• 後日「スタジオを借りました」「課題曲はこれ」「あらたまさんはボーカルね」と言われた
• まさか自分がバンドでボーカルをやるなんて夢にも思わなかったが、せっかくだからやってみようと思ってやってみたらすごく楽しかった
• 昔はそういうアマチュアの活動はただお金が出ていくだけだしなんのためにやるんだろうくらいに思っていたが、集まって何かを一緒に作るという体験自体が何事にも変え難い楽しさとして認識できるんだと飛び込んでみて気づいた
• 10年前だったら間違いなく誘われても「いいです」となっていたと思う

(2025/10/25)

マネジメント”される”人のためのマネジメント入門「10個のなぜ？」

• マネジメント”される”人のためのマネジメント入門「10個のなぜ？」 #チーム開発 - Qiita

(2025/10/25)

なぜ、優秀なエンジニアが集まらないのか

• なぜ、優秀なエンジニアが集まらないのか

(2025/10/25)

私がTypeScriptで `interface` よりも `type` を好む理由

• 私がTypeScriptで interface よりも type を好む理由 - kosui

(2025/10/24)

オープンソースソフトの「MinIO」がDockerイメージの無料配布を停止し大炎上

• オープンソースソフトの「MinIO」がDockerイメージの無料配布を停止し大炎上 - GIGAZINE

(2025/10/23)

AIが人類を超える時代に警告 著名人700人が開発中止訴え

• AIが人類を超える時代に警告 著名人700人が開発中止訴え　写真1枚　国際ニュース：AFPBB News

【10月22日 AFP】科学者や政治家を含む著名人700人が22日、人間の能力を上回る人工知能（AI）の開発をやめるよう呼びかけた。英国のヘンリー王子、バージン・グループ創設者リチャード・ブランソン氏、ドナルド・トランプ米第一次政権で顧問を務めたスティーブ・バノン氏らが公開書簡に署名した。

AIの危険性に警鐘を鳴らす米NGO「フューチャー・オブ・ライフ・インスティテュート（FLI）」が公開書簡を発表し、「技術が信頼できる安全性と制御性を備え、公共の支持を得るまで、スーパーインテリジェンス（超知能）の開発を禁止することを求める」としている。

公開書簡の署名者には「AIのゴッドファーザー」と呼ばれ、2024年のノーベル物理学賞を受賞したジェフリー・ヒントン氏、カリフォルニア大学バークレー校のコンピューターサイエンス教授スチュアート・ラッセル氏、ディープラーニング研究の第一人者ヨシュア・ベンジオ氏（モントリオール大学）らが含まれている。

アップル共同創業者スティーブ・ウォズニアック氏、バラク・オバマ元米大統領の国家安全保障担当補佐官スーザン・ライス氏らも署名に加わった。

この取り組みは、バチカンのAI専門家パオロ・ベナンティ氏や、ヘンリー英王子とメーガン妃、米歌手ウィル・アイ・アム氏ら著名人の支持も得ている。

主要なAI開発企業の多くは、人間の知的能力と同等の汎用人工知能（AGI）や、それを超える超知能の実現を目指している。

超知能についてオープンAIのサム・アルトマン最高経営責任者（CEO）は9月、今後5年以内に実現する可能性があると述べていた。

FLIのマックス・テグマーク共同設立者はAFPに対し、「企業は規制の枠組みなしに、そのような目標を追うべきではない」と語った。

別の共同設立者アンソニー・アギーレ氏は、「多くの人が科学や医療、生産性などの分野で強力なAIの恩恵を望んでいる。しかし、企業が人間より賢いAIを目指し、人間を置き換えることを狙うような競争に突き進む現状は、一般市民の望みや科学者が安全と考える範囲、宗教指導者が道義的に正しいとみなすものから大きく逸脱している」と指摘した。(c)AFP

MEMO:

• むしろ人類を超える知性体を生み出すことが人類の義務である

(2025/10/23)

あなたは5年後必要な人材ですか？

• あなたは5年後必要な人材ですか？

(2025/10/23)

失われゆく「COBOL」技術、レガシーコードとの向き合い方をGitHubが解説：AIエージェントを使っ...

• 失われゆく「COBOL」技術、レガシーコードとの向き合い方をGitHubが解説：AIエージェントを使った3つのステップ - ＠IT

要約:

■ 1. レガシーコード問題の深刻化

• COBOL人材の減少: プログラミング言語COBOLのソースコードが世界中の銀行・保険会社・政府などのシステムを動かしているが、それを理解する開発者を見つけることが困難になっている
• 現役システムの維持困難: システム自体は今も動き続けているとしても、組織がその中身を理解しているとは限らない状況が生じている
• ビジネス存続の問題: レガシーシステムは単なる技術的負債の問題ではなく、ビジネスの存続に関わる問題である
• 専門知識不足の深刻化: 組織においてはCOBOLの専門知識不足が深刻になっている

■ 2. GitHubによる新しいアプローチの提案

• GitHub Copilot活用: AIコーディングアシスタント「GitHub Copilot」を活用した3つのステップを紹介した
• Microsoftチームの実践例: Microsoft Global Black Beltが実践したレガシーモダナイゼーションのアプローチに基づいている
• 理解と再生の重視: ソースコードを単に置き換えるのではなく、理解し再生するための現実的なアプローチである
• 汎用的な方法論: COBOLに限らず、さまざまなレガシーモダナイゼーションプロジェクトに応用できる体系的な方法である

■ 3. ステップ1:ソースコードを理解する

• 考古学ツールとしてのAI: GitHub Copilotを考古学ツールとして活用し、失われた知識を発掘する
• ビジネスロジックの整理: 業務上のビジネスロジック(処理内容)を整理する
• 文書化の自動化: 読み取ったソースコードの内容をマークダウン形式で文書化する
• 依存関係の識別: モジュール間の呼び出し関係や依存関係を自動的に識別する
• コード整理: 無関係なコメントや古い修正履歴などを削除・整理し、必要に応じて補足コメントを追記する

■ 4. ステップ2:ソースコードを補強する

• エンリッチメント段階: コードの意図を説明するコメントを補い、依存マップを作成する段階である
• 属人化の解消: 属人化したロジックが誰でも読める資産に変わる
• COBOL構造の理解: COBOLプログラムは識別部・環境部・データ部・手続き部の4つの構造に分かれている
• 自然言語による理解: COBOLの構文を理解しなくても、AIに解析させることで自然言語で構造を理解できるようになる

■ 5. ステップ3:ソースコードを再生させる

• 連携理解の段階: 個々のファイルの分析とエンリッチメントを終えた後、それらがどのように連携するのかを理解する必要がある
• AIエージェントの活用: AIエージェントによる自動化ワークフローを構築する段階に移行する
• オーケストレーションフレームワーク: Microsoft Global Black Beltのチームは複数の専門エージェントをオーケストレーションするフレームワークを構築した
• 役割分担: 各エージェントは特定のジョブを持ち、連携させることで単一では対応し切れない複雑な処理を実現する

■ 6. 呼び出しチェーンマッピング

• ファイル相互作用の図式化: ファイルの相互作用を図式化するプロセスである
• 複数エージェントの連携: 1つのエージェントがCOBOLファイルを読み取り、別のエージェントがプログラム間の呼び出しを追跡し、また別のエージェントが視覚的に図式化する
• システム全体マップの作成: 依存関係を手動でたどることなく、システム全体のマップを作成できる

■ 7. テスト駆動型モダナイゼーション

• 三段階のテスト生成: 1つのエージェントがビジネスロジックを抽出し、別のエージェントがそのロジックを検証するテストケースを生成し、また別のエージェントがそれらのテストに合格するソースコードを生成する
• セーフティーネット機能: テストは移行作業のセーフティーネットとして機能する

■ 8. 依存関係の最適化

• ライブラリの置き換え: 最新の同等のものに置き換え可能なユーティリティークラスとライブラリを特定する
• 代替可能性の確認: エージェントは使用しているCOBOLライブラリを分析し、代替ライブラリの有無を確認し、置き換え可能な部分を見つける

■ 9. AIによるモダナイゼーションの現実的課題

• ワンクリック解決の否定: メインフレームの問題は1回のクリックで解決できるわけではない
• 人間の関与の必要性: 検証のために人間が常に最新の情報を把握している必要がある
• COBOLの固有性と複雑性: COBOLのソースコードは固有かつ複雑になっている
• AIエージェントの発展途上: AIエージェントの活用はまだ初期段階にある
• 長期的視点: 完全な自動化には少なくとも5年はかかる

■ 10. 従来の変換作業の問題点

• 高額で長期間のプロジェクト: 従来は高額なコンサルタントを雇い、5年以上をかけて変換作業をしていた
• メンテナンス不可能なコード: 最終的にはメンテナンス不可能なソースコードが生み出されるという現実があった

■ 11. AIアプローチの利点と可能性

• 現実的なモダナイゼーション: AIを活用したアプローチはレガシーシステムの維持・刷新を従来よりも現実的なものに変える可能性を秘めている
• 作業可能なコード生成: AIを使うことで、最終的に生成されるソースコードは開発者が実際に作業できるものになり得る

(2025/10/22)

余っているミニPCを活用してIncus Clusterを構築しよう

• 余っているミニPCを活用してIncus Clusterを構築しよう | ドクセル

(2025/10/22)

How to send progress updates

• How to send progress updates - Slava Akhmechet

翻訳:

進捗状況の報告方法

何か価値のあることに取り組んでいるなら、遅かれ早かれ人々はそれに興味を持ち、進捗状況の報告をしてくれるよう求めるでしょう。四半期ごとの投資家向け報告、上司への週次報告、関連チームへのメールなど、様々な形で報告できます。ここでは、進捗状況を効果的に伝えるためのヒントをご紹介します。

1. 自分の役割を理解し、報告するたびに、自分がその役割をしっかりと果たしていることを示す証拠を積み重ねていきましょう。人々があなたの報告を望むということは、あなたに何かを託しているということです。例えば、製品や機能の成功裏のデリバリー、投資資金、会社の予算、評判などです。彼らの信頼を大切にし、責任感を真剣に受け止めていることを伝えましょう。

2. 報告頻度に少し変化を加えましょう。人々は定期的な報告を望んでいると考えがちですが、ある程度の不定期さの方が受け入れやすいのです。例えば、毎週火曜日にプロジェクトの報告を送信すると、単なる事務的なやり取りのように思われ、誰も読んでくれません。 2～3週間ごとにアップデートを送信すれば、読者は何か新しいことを伝えたいと期待し、楽しみにしてくれるでしょう。

3. 次のアップデートの内容を把握し、それに向けて作業を進めましょう（アップデートの時期が来てから改めてアップデートするのではなく）。これは、社内向けの見出し主導型開発です。見出しがなければアップデートは存在せず、後から良い見出しを作成することもできません。

4. 常に1文のTL;DRと、プロジェクトの全体目標を2～4文で要約することから始めましょう。読者はあなたよりも賢いですが、非常に忙しく、あなたの仕事について何も覚えていないと想定しましょう。

5. 人は嬉しいサプライズが大好きですが、偶然に訪れることは滅多にありません。無理のない範囲で、意図的に嬉しいサプライズを企画し、アップデートに盛り込みましょう。

6. 人は嬉しいサプライズを嫌います。もちろん、可能であれば避けるべきです。しかし、どうしても避けられない場合は、2つの対策を講じましょう。まず、グループ全体に伝える前に、各メンバーと個別に話し合いましょう。次に、ネガティブなニュースは2～3段階に分けて段階的に伝えましょう。例えば、最初は問題が発生する可能性を穏やかに伝え、メンバーが状況に慣れる時間を与えます。次に、問題を事実として伝えます。（ただし、真の緊急事態や危機の場合は、この方法は避けましょう。）

7. 変更を明確に認識しましょう。前回はa、今回はbと述べ、bがaと矛盾する場合は、その矛盾を説明する必要があります。認識された矛盾はビジネスコストと捉えられますが、認識されていない矛盾は約束違反と捉えられます。

8. 意図せず、あるいは故意に、誰かを侮辱してはいけません。以前、「当社のエンジニアは何も知らないため、製品を出荷できません。より優秀なエンジニアが必要です」といった内容のアップデートを作成し、エンジニア自身を含む全員に送信したことがあります。これは事実ではありましたが、粗雑で不必要な表現でした。このようなことは絶対にやめましょう。

9. 人々は舵取りをしっかりしている人を求めています。あなたの口調もそれを反映させるべきです。パイロット無線の声のような文章にしましょう。（ええ、比喩を混ぜていますね。）

10. 多くの人は（当然ですが）自分のアップデートによって個人的な評価を受けているのではないかと心配し、一文一文を徹底的にサイジングしてしまいます。しかし、そうしてはいけません。すべてを自分のことではなく、仕事のことに集中させ、評価は他の人に任せましょう。（私は、仕事から物理的に離れた第三者の視点で自分自身を想像し、自分のキャラクターがアップデートを書いていると想像します。）

11. 読者が答えを知りたいと思っている上位3つの質問を把握し、できるだけ明確に答えましょう。

12. 不安や失敗について専用のセクションを設けましょう。正直に、しっかりとした計画を立て、パニックに陥らないようにしましょう。人々は誠実さと弱さに惹かれますが、無力感や大げさな表現には反発します。

13. アップデートの目的は、読者があなたに尋ねることなく、いつでもプロジェクトの進捗状況を把握できるようにすることです。

14. 「イーロンは四半期決算説明会でウォール街のアナリストに怒鳴っているのに、なぜ私にはできないんだ？」もしあなたが、業界全体よりも大きな時価総額を持つ会社を築き上げたのなら、私のアドバイスを無視してもらって構いません。

15. これらのヒントは、あなたが無能なら効果がありません。

(2025/10/21)

NTT版大規模言語モデル「tsuzumi 2」

• NTT版大規模言語モデル「tsuzumi 2」 | NTT R&D Website

■ 超大型の言語モデルに迫るトップクラスの性能

tsuzumi 2は多くのベンチマークで高い性能を達成しています。図は代表的なベンチマークの１つであるMT-benchにおけるGPT-5との性能比較です。MT-benchは多様なタスクから構成されたベンチマークであり、言語モデルの特性を多様な観点で評価することができるものです。多くのタスクでGPT-5と同等程度の高い数値を示しており、様々なユーザからの要求を処理可能なモデルに仕上がっています。

■ 1GPU動作可能な軽量モデル

tsuzumi 2は1GPU動作可能な軽量モデルです。最新の言語モデル向けのGPUはハイスペックで高価なものが多い中、少し以前の40Gバイト以下のメモリを保有したGPUでの動作を想定して開発されています。 大規模言語モデルの導入が各社で進む中、極めて高頻度に利用されるお客様が増えてくると見込んでいます。するとAPI利用回数に応じた利用料を支払う場合、コストが高くなり、お客様ご自身が安く言語モデルサーバーを運用した方が良いという判断が増えてくることでしょう。また、AIエージェントによるシステム連携などを通して、より一層機微な情報を言語モデルに与えるケースが増加し、オンプレ環境への導入も今後増えてくるでしょう。tsuzumi 2はこのような要求にこたえる運用コストと性能のバランスに優れたモデルです。

■ 法人のお客様に求められるタスク処理能力の強化・知識の増強

tsuzumi 2では、ビジネスシーンで頻繁に利用される能力を重点的に強化しました。特にユースケースの80％を占める、ドキュメントに対するQAタスク（RAG検索要約）、ドキュメントからの情報抽出・要約タスクを集中的に強化しています。 これらのタスクについては、ビジネスでの利用を想定した独自の評価セットを構築し、実践的な評価を行っています。tsuzumiの前バージョンとの比較では、これらのタスクについて大きく性能を向上させることに成功しました。 また、NTTのお客様が多い金融・自治体・医療分野については特に多くの知識を学ばせました。これらの分野では多くのユースケースで優れた性能を発揮します。

法人のお客様の利用形態の特徴の１つに出力形式の指定があります。例えば、要約においても自由に要約文を生成させるのではなく、報告様式があり、その型に準拠させたい。技術系の用途であれば文書から特定の情報を抽出し、json形式で出力して欲しいといった要求です。tsuzumi 2ではこうした要望にお応えするために指示遂行力を強化することで、使い勝手の良い言語モデルを目指しました。

■ NTTがゼロから開発した純国産モデル

昨今、言語モデル学習における新聞データの無断利用に関する訴訟が起きるなど、モデル開発過程における信頼性が問われています。開発会社だけではなく、問題を指摘されたモデルを使い続けることは利用者側も責任を問われかねません。そこで、NTTではフルスクラッチ開発を行っています。これはオープン利用可能な他社のモデルを種とすることなく、完全に一からNTTがモデルを構築することを意味しています。学習データの完全コントロールにより、データの権利、品質、バイアスの管理が可能となり、モデルの信頼性を高める上で極めて重要です。前バージョン同様、tsuzumi 2も日本の国内法に準じて開発された純国産モデルとなっています。

(2025/10/21)

【日本語訳全文】Kent Beck氏 基調講演：開発生産性測定のトレードオフ「グッドハートの法則」は...

• 【日本語訳全文】Kent Beck氏 基調講演：開発生産性測定のトレードオフ「グッドハートの法則」はもっと悲観的に捉えるべきだった・前編 - Findy Tech Blog

要約:

■ 1. 開発生産性の本質的な問題

• 生産性の定義: 生産性とはアウトプットとインプットの比率であり、単純な数値として表現される
• 改善の逆説: 開発生産性を改善しようとする試みが、しばしば状況を悪化させる結果を招いている
• AIによる問題の深刻化: AI技術の導入により、生産性測定と制御の問題が更に悪化している
• 終わりなきプレッシャー: やることは常に山積みであり、どれだけ生産性を上げてもプレッシャーが軽減されることはない

■ 2. マッキンゼーレポートの問題点

• 世間知らずな提案: 約2年前にマッキンゼーが発表した開発生産性レポートは、経験ある開発者から見て明らかに不適切な内容だった
• すべてが逆効果: 生産性向上のための提案がすべて状況を悪化させるものであった
• 批評記事の執筆: Gergely Oroszと共同で批評を執筆し、大きな反響を呼んだ

■ 3. グッドハートの法則の基本概念

• 法則の要約: 指標が目標になると、それは良い指標ではなくなる
• タイピング速度の例: タイピング速度を指標とすると、開発者は意味のない高速タイピングに専念するようになる
• 本来の観察: 統計的規則性が観察されても、それを制御手段として利用すると規則性は崩壊する
• イングランド銀行の事例: 短期金利と借入の相関関係を制御に利用しようとしたが、他のプレイヤーの適応により効果が消失した

■ 4. 測定の目的と誤用の区別

• 測定の価値: ソフトウェア開発プロセスの測定は非常に価値があり、自分のやっていることを数値化・分析・解釈できる
• 制御との違い: 測定による理解と、レバーでシステムを制御できるという感覚は全く別物である
• 理解のための測定: 指標は開発プロセスを理解するためのものであり、システムを機械的に制御する手段ではない
• ソフトウェアの特殊性: 純粋な知的活動の中で、ソフトウェア開発ほど規模を拡大できるものは他にない

■ 5. プルリクエスト指標の事例分析

• 正のフィードバックループ: 優れた開発者は小さなPRを多く出し、それが読みやすさ、協力の増加、無駄の削減につながる自己強化型の仕組みを形成する
• 圧力による崩壊: PRランキング表を作成して圧力をかけると、開発者は筋の通ったPRを細切れにして数を水増しするようになる
• 協力の減少: PRを細分化することで読みにくくなり、協力が減少し、無駄が増加し、最終的にPR数も減少する
• 悪循環の発生: 誰も下位にいたくないため全員が同じ行動を取り、ソフトウェア開発プロセス全体が悪化する

■ 6. コード行数指標の歴史的失敗

• 生産性指標としての採用: コード行数がプログラマーの生産性を測る正しい指標だと考えられた時代があった
• プログラマーの対応: プログラマーはコードを生成するプログラムを書くことができるため、機械的に大量のコードを生産できる
• 逆効果の結果: 求めていた成果とは正反対の結果を生み出し、仕組みを悪化させた

■ 7. グッドハートの法則を超える悲観的現実

• 規則性の崩壊を超える破壊: 統計的規則性に圧力をかけると、単に規則性が崩壊するだけでなく、規則性を生み出した仕組み自体を壊してしまう
• 意図と逆の結果: レバーを引くことで期待や意図とは真逆の結果が生じる
• より深刻な問題: 単にレバーが機能しなくなるのではなく、システム全体が望まない方向に向かう

■ 8. 複数指標によるバランスの幻想

• バランス指標の提案: PR数だけでなく欠陥数やレビュー時間など複数の指標を組み合わせるべきだという主張がある
• 問題の非解決: 導入するすべての指標が仕組みをゆがめるため、複数の指標を導入しても問題は解決しない
• 理解困難化の加速: 指標が多ければ多いほど、システムは理解しづらく制御しづらいものになる
• 完璧な指標セットの不在: うまく開発するための指標のセットは存在せず、指標による自動的な改善という発想自体が誤りである

■ 9. 人間性の軽視と創造性の抑圧

• 機械的制御の危険性: 何も考えずに指標を改善するだけですべてうまくいくという発想は、開発者の人間性を無視している
• 思考の後押しの必要性: プログラマーは考えることを促され、創造性に任せられることを望んでいる
• 数値化不可能な要素: 思考、洞察、創造性のプロセスは単純な数字に表すことができない
• 創造性の喪失: 数値化しようとするあらゆる試みが、ソフトウェア開発に注ぎ込まれるべき思考と創造性を奪う

■ 10. システムによるゆがんだ目標の採用

• 目標の放棄を超える問題: システムは制御の圧力を軽減するために本来の目標を放棄するだけでなく、ゆがんだ目標を新たに採用する
• 本番障害指標の例: 本番環境での障害をなくせという圧力をかけると、障害報告がなくなる(報告しないことで数字をゼロにする)
• 創造的な回避行動: 頭が良く創造的な開発者は、数字をゼロにする何らかの方法を必ず見つけ出す
• 全方位的な悪影響: 仕組みをだますプログラマー、会社、顧客、社会全体にとって悪い結果をもたらす

■ 11. 指標による制御の本質的限界

• 人間の判断の排除: 人の働きを単純な数字で表し、人間の判断を不要にして数字だけで制御しようとする試み自体が問題である
• 望まない目標の採用: システムが新たに採用する目標は、組織が真に達成したい目標とは異なるものになる
• 指標の種類や数は無関係: どのような指標を使用し、いくつ組み合わせ、どれだけバランスを取っても問題の本質は変わらない
• 脱出方法の必要性: この悪循環から抜け出す方法を見つける必要がある

• 【日本語訳全文】Kent Beck氏 基調講演：開発生産性測定のトレードオフ「グッドハートの法則」はもっと悲観的に捉えるべきだった・後編 - Findy Tech Blog

要約:

■ 1. ソフトウェアが価値を生み出す4段階のプロセス

• 労力(Effort): プログラマーがプログラミングに費やす時間、金銭、機会費用で測定される最初の段階である
• アウトプット(Output): 労力を費やした結果として形になるもの(例:ボタンの追加)であり、比較的測定が容易である
• 成果(Outcome): 顧客が新しい行動を取り、ユーザーの行動変化として現れる段階である
• 影響(Impact): 会社の収益増加、顧客満足度向上、コスト削減など、企業に価値が還元される最終段階である

■ 2. 測定の容易さと仕組みのゆがみの関係

• 労力側の測定リスク: 価値の道すじの初期(労力側)に近いほど測定は容易だが、指標が仕組みをゆがめる可能性が高くなる
• 過労の危険性: 若い頃に週100時間以上働いた経験から、時間の最適化は良くない結果を招くと警告している
• アウトプットの測定: ボタンの数など比較的測定しやすいが、顧客が気にするかどうかは成果が出るまで分からない
• 貢献度の切り分け困難: 複数のチームの貢献が組み合わさって成果が出る場合、個別の功績を切り分けることは困難である

■ 3. 経営者の関心と測定の優先順位

• 顧客行動への注目: 経営者として測定したいのはプログラマーの労働時間ではなく、顧客がどう行動を変えたかである
• 影響の測定可能性: 四半期ごとの財務状況など影響レベルでの測定は可能だが、誰の功績かを特定することは不可能である
• 帰属の困難さ: プログラミングとマーケティングの成果が混在する場合、収益性の変化を特定の要因に帰属させることはできない
• ゆがみの軽減: プロセスの後期(影響側)で測定するほど、指標が仕組みをゆがめる傾向は弱くなる

■ 4. AIによる労力とアウトプットの変化

• 拡張プログラミングの体験: Gene Kim氏の影響でAIベースのプログラミングを始め、機能完成に必要な労力が劇的に減少した
• 労力減少とアウトプット増加: AIのおかげで作業時間が大幅に短縮され、プログラマー1人当たりのアウトプットが増加する
• AIの不完全性: AIというコーディング仲間は時にとんでもなくバカなこともするため、労力が増えることもある
• 管理方法の不変性: 10時間の作業が1時間でできるようになっても、プロセスをどう管理すべきかについては何も変わらない

■ 5. AI時代における若手育成の選択

• 若手不要論への反論: ジーニー(AI)を使えばシニアプログラマーの方が生産性が高いため若手が不要になるという懸念がある
• チューターとしてのAI活用: RustやHaskellなど理解できない言語でも、AIがいつでも説明してくれるため学習効率が向上する
• 学習重視の評価: 若手を労力やアウトプットではなく、毎週学んだことで評価する方式を提案している
• 長期的価値の創出: 若手は大量のコードを書くためにいるのではなく、早く学ぶことが雇用者にとっての長期的価値を生み出す

■ 6. 指標を見る人と行動の重要性

• 見落とされる質問: 誰がこの数字を見るのか、見た結果どんな行動を取るのかという質問がめったに議論されない
• CFOの解雇意図: 最高財務責任者がプログラマーの2割を解雇したいと思っているなら、どんな指標も恐ろしいゆがみを生む
• 現場マネジャーの育成意図: 部下が早く学ぶのを助けたいと思っている現場マネジャーでは、全く異なる見方になる
• 単位の重要性: 開発者1人当たりのPRは投資家にとって意味がなく、利益という単位で測定すべきである

■ 7. 投資家視点での生産性測定

• 金銭的価値の測定: 投資家として気になるのは利益であり、アウトプットもインプットも金額で測定してほしい
• 雇用判断の根拠: 追加のプログラマーを雇って生産性が1.4倍や3倍になると分かれば、雇用は理にかなっている
• PR数の無意味性: 1日当たりのPR数が3件から6件になると言われても、プログラマーを追加で雇うべきか判断できない
• 意思決定への貢献: 利益の数字を使えば、投資家として良い決断を下すことができる

■ 8. リーダーシップの実践:後段階での確認

• 確認タイミングの遅延: 価値の道すじの初期段階ではなく、後期段階で確認することが重要である
• タイムカード導入の危険性: 労働時間の管理やバグの自己申告など、初期段階での確認は仕組みをゆがめる
• 開発者1人当たりの利益: 達成方法は問わず、競合他社との比較で開発者1人当たりの利益を提示する
• 成果の観察: 会社への直接的な影響が確認できないなら、成果を観察することがソフトウェア開発の有効性を評価する良い方法である

■ 9. リーダーシップの実践:意識向上の促進

• グラフ化による意識向上: システムの速度をグラフ化して週に1度提示するだけで、プログラマーは改善に夢中になる
• 圧力の回避: 何も言わず、ただグラフを見せるだけで、プログラマーは自発的に調査し改善しようとする
• 圧力とゆがみの関係: リーダーとして圧力をかけないことは難しいが、圧力をかけると仕組みにゆがみが生じる

■ 10. リーダーシップの実践:目的の浸透

• 引く姿勢の採用: 本番障害の削減を命令するのではなく、「できるよ、私たちなら可能だ」と励まし、必要なものを尋ねる
• 非難の回避: 障害が起きた際に「君はダメなプログラマーだ」と圧力をかけるのではなく、引く姿勢で接する
• リーダーの責任: 現状に対する責任を自ら持ち、「私は障害が多すぎる環境を作ってしまった」と認める
• やり方の変更宣言: 今後はやり方を変えていきたいと伝え、チームを前向きに導く

■ 11. グッドハートの法則を回避する方法

• 圧力回避による測定: 指標に圧力をかけなければ、結果を変えずに測定できる
• 最高の自分の追求: 人々が最高のレベルで創造し、共有する目標に全力を注ぐことを後押しする
• 揺るぎない目標: より大きな視点でソフトウェア開発を見ることで、目標が揺るがなくなる
• 魔法のようなプロセス: ソフトウェア開発は誰もが参加でき、成長を続け、目標達成が可能な魔法のようなプロセスである

(2025/10/20)