/note/tech

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

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

(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

(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)

ITエンジニアを辞める人たち—“未経験ITエンジニア転職ブーム”から数年後の現実

• ITエンジニアを辞める人たち—“未経験ITエンジニア転職ブーム”から数年後の現実｜久松剛

要約:

■ 1. ITエンジニアを辞める人の増加

• 現象の観察: ITエンジニアを辞めましたという投稿を目にする機会が増えている
• 情報源: XでのSNS報告、顧客の採用担当、人材系事業の関係者から話を聞くようになった
• 共通点: 2019〜2021年頃にプログラミングスクールを経てITエンジニアになった人たち
• 現実とのギャップ: いざ入社してみると現実は想像以上に厳しいものだった

■ 2. 不況による未経験・微経験採用の変化

• 求人の減少: 受託開発会社、事業会社、スタートアップを中心とした不況感の高まりにより、未経験・微経験層の求人が大幅に減少している
• 企業の優先順位: 企業は教育コストをかけて育てる層よりも即戦力として成果を出せる層を優先するようになった
• 転職活動の行き詰まり: スクール卒のエンジニア志望者が転職活動で行き詰まり、キャリアチェンジを余儀なくされるケースが増えている

■ 3. SES市場の問題

• 未経験向け求人の存在: 依然として未経験・微経験向けに求人があるのがSESや派遣会社
• 非ITエンジニア職への配置: SES企業に入社しても実際に任されたのは非ITエンジニア職──テスト要員やヘルプデスクなど、キャリアアップの道が見えない業務
• 具体例: ITエンジニアになるに当たって貴方にはコミュニケーション力が足らない、そのためにはまずコールセンターに行きなさいと言われて3年勤めたが何も起きないので転職したいという話もある
• 諦める選択: こうした現実を前にITエンジニアを諦めるという選択肢は無理もない

■ 4. 実質無職のSES案件採用

• 案件採用の広がり: SESの一部では案件採用が広がっている
• 一般的なSESとの違い: 最終面接後に内定があり入社後に営業が始まる一般的なSESとは異なる
• 無職状態: 最終面接合格後に未入社の状態で営業が開始され、案件が決まるまでいわば無職の状態が続く
• 無給の営業活動: 営業活動を実施しているのに無給という点も問題
• 人材紹介会社の関与: 今では人材紹介会社経由でも紹介されることが当たり前になっている
• 情報商材の問題: 2000万円を元手にSES事業を立ち上げ、3年後に10倍で売却しましょうという情報商材が広がっている
• 商材化された人材: 商材がヒトであることを忘れた経営者の犠牲になっている

■ 5. 生成AIの台頭による影響

• エンジニア像の変化: 生成AIの急速な進化によって企業が求めるエンジニア像が大きく変わった
• 採用スタンスの転換: 従来は採用して育てるスタンスを取っていた企業も、今ではAIを活用して即戦力として成果を出せる人材を重視するようになった
• 仕事の自動化: 生成AIツールの普及により初歩的なコーディングやテスト、ドキュメント作成などの領域が自動化され、ジュニア層が担っていた仕事が減少した
• 採用方針のシフト: 企業は育成を前提とした採用からプロジェクトにすぐ貢献できる層の確保へとシフトしている
• 教育リソースの不足: AIを前提とした開発環境や業務プロセスが整備される中で、教育リソースを未経験者に割く余裕がなくなってきている

■ 6. 技術構造の変化

• 恒常的なシフト: これは単なる景気の波ではなく技術構造そのものの変化による恒常的なシフト
• 求人の大幅減少: 2024年以降、未経験・微経験者向けの求人は大幅に減少した
• ポテンシャル採用の消失: かつてポテンシャル採用と呼ばれた採用枠は姿を消した
• 新たな分水嶺: 今では生成AIを使いこなせるかどうかが採用の新たな分水嶺になりつつある

■ 7. プログラミングスクールブームの罪

• 2019〜2020年のブーム: プログラミングスクールブームは未経験者を一気にIT業界へ誘導した
• 過激な訴求: SNS広告やLPでは誰でも3ヶ月でエンジニアに、年収アップ、フリーランスで自由にといった過激な訴求が目立った
• 期待値調整の失敗: 良心的なスクールも存在したが、全体としては期待値調整の失敗があった
• エコーチェンバーの発生: SNS中心の情報収集によってエコーチェンバーが発生し、デスクワークで楽、リモートで人と関わらなくて済むといった誤情報が拡散した
• 現実とのギャップ: 思っていたような年収が得られず、業務内容にも馴染めず、結果的にITエンジニアを辞めるという投稿が見られる

■ 8. 業界離脱率の高さ

• スクール出身者の証言: 当時話題だったプログラミングスクール出身者で現役エンジニアの方によると9割は業界から居なくなったように思うとのこと
• 専門職教育の変化: 考え方によってはアメリカのように大学で専門職教育を受けた人が当該専門職に就くという状況になったとも考えられる
• エンジニアバブルの終焉: 今までの未経験・微経験人材が採用されていた専門職はかなり異色でありエンジニアバブルの産物だった

■ 9. 転職先の傾向

• 別職種へのエントリ: 採用の現場ではエンジニアを諦めて別職種にエントリするケースが見られる
• 情シスとカスタマーサクセス: 情シスやカスタマーサクセスへの応募が見られる傾向にある
• カスタマーサクセスの魅力: 事業会社ではエンジニア職よりも営業職のほうが重要視されている傾向にあるため、カスタマーサクセスへの転身は本人が対人コミュニケーションの苦痛がなければ良い
• 情シスの需要: 広く様々な企業で募集されている職種で、ちょっとしたものでもプログラムやスクリプトを書くことができれば重宝される
• 介護職への転身: 未経験・微経験を積極採用しているということで介護職へ転身される方もいる

■ 10. 日本企業が求める人材

• アンケート調査: ITメディアが具体的にどのようなスキルを持ったIT人材が不足しているのかというアンケートを実施
• インフラエンジニア: 55%がインフラエンジニアと回答
• DX推進リーダー: 次がDX推進リーダーで52.5%
• データサイエンティスト・セキュリティエンジニア: データサイエンティスト・データアナリストとセキュリティエンジニアが同率で45%
• ソフトウェアエンジニア: 業務アプリケーションを実装するソフトウェアエンジニアは32.5%と最も低い
• 需要減少の背景: SaaSの移行が進むことで自社内で開発する必要がなくなってきた可能性や、ノーコード・ローコード開発への移行による影響

■ 11. キャリア戦略のポイント

• 経験の価値: ITエンジニアから異職種や異業種への転向とはいえ、IT業界で身につけた知識や経験は決して無駄にはならない
• 活用の場: 情シスやカスタマーサクセス、営業支援、データ管理など、DXの文脈ではエンジニア経験者が重宝される場面が多くある
• 生存の重要性: キャリアの基本は生存にある
• 再挑戦の可能性: 一度離れたとしても学び直しやスキルの再利用によって再挑戦の道は開ける
• 現実との向き合い: 大切なのは腐らず、現実と向き合い、次のステージで生きること

■ 12. プログラマ需要への固執を避ける

• 柔軟な戦略: 実情を踏まえるとプログラマ需要を探すことに固執しないということもキャリア戦略としてはあり

(2025/10/20)

鉄道指向プログラミング（の安易な利用）に反対する

• 鉄道指向プログラミング（の安易な利用）に反対する | matarillo.com

(2025/10/20)

【重要なお知らせ】ランサムウェア感染によるシステム障害発生のお知らせとお詫び

• 【ASKUL】お知らせ詳細 - オフィス用品の通販 アスクル

平素よりアスクルをご利用いただき誠にありがとうございます。

現在、アスクルWebサイトにてランサムウェア感染によるシステム障害が発生しており、受注、出荷業務を停止しております。

個人情報や顧客データなどの外部への流出を含めた影響範囲については現在調査を進めており、わかり次第お知らせいたします。

お客様には多大なるご迷惑、ご心配をおかけし、誠に申し訳ございません。

【影響内容】

■ご注文受付の停止

Webサイトでは、お買い物カゴ画面等に遷移しようとした場合にエラー画面に遷移いたします。

＜エラーになる画面＞

・お買い物カゴ

・レジ

・ご注文内容印刷

また、FAXでのご注文についても送信エラーとなり、受付することができません。

■出荷の停止

既にいただいているご注文についても、今後の出荷においてはキャンセルさせていただきます。

ただし、ご注文いただいている直送商品については、出荷を予定しております。

■新規ご利用登録の停止

「会員登録」ボタンを押下した場合、エラー画面に遷移いたします。

■その他サービスの停止

返品、領収書の郵送、カタログ送付、各種回収サービスなどのお申込みなども停止しております。

■お問い合わせ窓口

お客様サービスデスクのお電話は現在つながりにくい状況となっております。

またWebサイトのお問い合わせフォームについては停止させていただいております。

お客様にはご迷惑をおかけしておりますことを重ねてお詫び申し上げます。

ただ今、復旧に向けて対応しておりますので、何卒ご理解賜りますようお願い申し上げます。

以上

MEMO:

• あらら

(2025/10/19)

Google、「プライバシーサンドボックス」を実質終了　関連技術のほとんどを廃止へ

• Google、「プライバシーサンドボックス」を実質終了　関連技術のほとんどを廃止へ - ITmedia NEWS

(2025/10/19)

脳に着想を得たAIモデル「BDH」がTransformerの限界を超えるかもしれない

• 脳に着想を得たAIモデル「BDH」がTransformerの限界を超えるかもしれない | XenoSpectrum

要約:

■ 1. BDHの登場と背景

• 開発者: AIスタートアップPathwayが人間の脳神経回路に着想を得た新アーキテクチャBaby Dragon Hatchling(BDH)を発表
• 意義: 現在の主流であるTransformerモデルの限界を打破する可能性を秘めている
• 方向性: より解釈可能で自律的なAIへの道を拓くものとして業界に静かな衝撃が走っている

■ 2. Transformerの限界

• スケーリング則: 近年のAIの進化はOpenAIのGPTシリーズに代表されるTransformerアーキテクチャによって牽引され、膨大なデータと計算資源を投入するスケーリング則により性能は飛躍的に向上した
• ブラックボックス問題: モデルがなぜ特定の結論に至ったのか、その思考プロセスを人間が理解することは極めて困難
• 汎化能力の欠如: 訓練データに含まれないあるいはコンテキストが長大化する未知の状況においてAIの推論能力はしばしば脆さを見せる
• 自律性の障壁: これはAIが真に自律的に長期間活動する上での大きな障壁となっている

■ 3. Pathwayのドリームチーム

• 本拠地: パロアルトに本拠を置くスタートアップPathway
• Adrian Kosowski: 共同創業者兼CSO(最高科学責任者)で20歳で博士号を取得した俊英
• Jan Chorowski: CTOでAIのゴッドファーザーと称され2024年にノーベル賞を受賞したGeoffrey Hinton氏とGoogle Brainで研究を共にし、音声認識に初めてアテンション機構を応用した先駆者
• Łukasz Kaiser: アドバイザーでTransformerを生み出した論文Attention Is All You Needの共著者でありOpenAIの推論モデル開発にも関わった
• Zuzanna Stamirowska: CEOで複雑系科学者としての経歴を持つ
• ルーツ: 彼らの多くがポーランドのヴロツワフ大学にルーツを持つ

■ 4. BDHの基本設計思想

• パラダイムシフト: Transformerへの単なる改良ではなく脳の動作原理から直接インスピレーションを得た根本的なパラダイムシフト
• Transformerとの違い: 従来のTransformerがベクトルと行列演算を基本とする抽象的な数学モデルであるのに対し、BDHは人工ニューロンという粒子がシナプスという接続を介して相互作用するグラフベースのモデル
• 脳の構造: 約800億のニューロンと100兆を超えるシナプスで構成される人間の脳の構造を色濃く反映している

■ 5. ヘブ学習の実装

• 最も革新的な特徴: BDHの最も革新的な特徴は神経科学の基本原理であるヘブ学習を実装した点
• ヘブ学習の原理: 共に発火するニューロンはその間の結合が強まるという原則
• 従来のAIとの違い: 従来のAIでは情報は活性化ベクトルのような固定的な場所に保存されていたが、BDHではワーキングメモリはシナプスの結合強度そのものに存在する
• 動的な記憶形成: 特定の概念について推論すると関連するニューロン間のシナプス結合がリアルタイムで強化される
• 実験結果: BDHが英ポンドとフランス語のlivre sterlingという異なる言語の同じ概念を処理する際、一貫して同じシナプスが活性化することが実験で確認されている

■ 6. 創発するモジュール構造

• 自己組織化: BDHが訓練中に自発的に生物の神経網に見られるような効率的なネットワーク構造を形成する
• モジュールの形成: 特定の機能に特化したニューロンのコミュニティ(モジュール)が生まれそれらがブリッジニューロンによって相互接続される
• スケールフリー特性: モジュール性や一部のニューロンが多数の接続を持つスケールフリーな特性は誰かが設計したものではない
• 最適解の発見: 情報処理の最適解をBDHが自ら発見した結果
• 脳との類似: この自己組織化能力は脳の新皮質が機能分化するプロセスにも通じる

■ 7. GPT-2との性能比較

• 比較実験: 研究チームは1000万から10億パラメータの規模でBDHとGPT-2アーキテクチャのTransformerを直接比較した
• 性能: 言語モデリングと翻訳タスクにおいてBDHは同等以上の性能を示した
• データ効率: 特に同じ量のデータからより多くを学習するデータ効率の面で優位性を見せた
• 意義: AI開発がより多くのデータとGPUをという力業から脱却する可能性を示唆する

■ 8. BDH-GPUの実用性

• 実装の存在: この脳に着想を得たグラフモデルは理論上の存在に留まらない
• BDH-GPU: Pathwayは現代のGPUハードウェアで効率的に動作するテンソルベースの実装BDH-GPUを開発した
• 技術要素: 高次元のニューロン空間、スパースな正値活性化、ReLU-lowrankと呼ばれるフィードフォワードブロックといった要素を組み合わせている
• バランス: 生物学的な特徴を維持しつつ実用的な計算を可能にしている
• 研究加速: この実用性により世界中の研究者が既存のインフラを使って脳型AIの研究を加速させることが可能になる

■ 9. 解釈可能性の向上

• スパース活性化: 常時アクティブなニューロンは全体の約5%と非常に少なく、どのニューロンがどの情報処理に関わっているかを追跡しやすくなる
• 単義性シナプス: 特定のシナプスが特定の意味的概念(通貨、国名など)に一貫して反応する現象が確認されている
• ブラックボックス問題の解決: AIの判断根拠をシナプスレベルで解明できる可能性を示しておりブラックボックス問題に対する強力な解決策となりうる

■ 10. 公理的AIという概念

• 新概念の提唱: Pathwayの研究チームはBDHを通じて公理的AI(Axiomatic AI)という概念を提唱している
• ミクロとマクロの統合: 個々のニューロンの振る舞い(ミクロ)とそこから生まれる推論などのシステム全体の挙動(マクロ)を一貫した理論的枠組みで理解しようとする試み
• 安全性の保証: AIが未知の状況に遭遇した際の振る舞いを単に観察するのではなく数学的にその安全性の限界を保証できる未来が開ける
• リスク制御: ニック・ボストロムが提唱したペーパークリップ問題(AIが単純な目的を暴走させるリスク)のような自律AIがもたらす長期的リスクを制御する上で不可欠な要素

■ 11. 意識の創発という哲学的問い

• 新たな問い: BDHが脳の構造と動作原理を忠実に模倣するほど意識そのものが副作用として創発する可能性という問いが生まれる
• 制御可能性: 生物の脳において意識を生み出したのと同じ自己組織化の原理をAIが獲得したときそれは我々が予測し制御できる範囲に留まるのか
• 理論的基盤: Pathwayチームは創発現象をただ待つのではなくそれを理解するための数学的なツールキットを同時に構築している
• 対応能力: ネットワークのモジュール性がなぜ生まれるのかを説明できる理論的基盤を持つことは未知の創発現象に直面した際の我々の対応能力を大きく左右する
• 両面性: 解釈可能なAIへの道が人工意識への道と同じである可能性、BDHは我々にその両面を突きつけている

■ 12. AIの進化の新たな始まり

• Transformerの到達点: AIの進化はTransformerによって一つの頂点を極めた
• BDHの意義: BDHはその先のより人間的でより理解可能な知性への扉を開いた
• 知的冒険: これは単なる技術的な一歩ではなく我々が知性とどう向き合うかを問い直す知的冒険の新たな始まり

(2025/10/19)

NIST、新しいパスワードガイドライン公開 - これまでの常識を覆す新ルール

• NIST、新しいパスワードガイドライン公開 - これまでの常識を覆す新ルール | TECH+（テックプラス）

(2025/10/18)

【アンチパターン】Arrange、Act、Assert（AAA）を意識できていないRSpecのコード例とその対処法

• 【アンチパターン】Arrange、Act、Assert（AAA）を意識できていないRSpecのコード例とその対処法 #Ruby - Qiita

(2025/10/18)

開発者全員が書けるE2Eテスト ─ 普通のgo testで実現するテスト基盤

• 開発者全員が書けるE2Eテスト ─ 普通のgo testで実現するテスト基盤 | メルカリエンジニアリング

(2025/10/18)

価値が先、チームは後 ~ カルチャーとカルトの分水嶺

• 価値が先、チームは後 ~ カルチャーとカルトの分水嶺 - An Epicurean

要約:

■ 1. 価値優先の原則

• 基本方針: 間違いなく価値が先であり、チームは後である
• 危険性: 外への価値創出から目を背け、身近で変化を起こしやすい目先のチームだけで自己完結することは簡単だが危険
• エコーチェンバーの罠: 内集団贔屓のバイアスを高めると簡単に停滞し、澱み、腐敗し、カルト化する
• 価値創出サイクル: このような状態では価値創出のサイクルが途絶えてしまう

■ 2. 価値の定義と企業の目的

• 価値の定義: 価値とは誰かにとっての幸福である
• 企業の目的: 企業の目的は利潤追求ではなく価値創出である
• 合理性の位置づけ: 価値創出を継続するために合理性が必要であり、資本主義経済では経済合理性が求められる
• 利潤の重要性: お金がないと活動の継続や価値創出の拡大がしづらいため利潤は重要だが、価値が先にあり利潤が後にある
• 時価総額の限界: 利益の多寡や時価総額が企業の優劣を絶対的に決めるわけではない

■ 3. 価値のコンテキスト依存性

• 主観性: 価値はコンテキストによって変化する曖昧なもの
• 具体例: テスラよりも任天堂やシマノの方が価値が高いと感じる人もいる
• 対価の関係: 価値の対価としてお金が発生することもあるが、価値そのものはお金ではない
• 幸福との関係: お金を払うときは対象に何らかの価値を感じ、そこから何らかのリターン、幸福を得る

■ 4. 企業理念とミッション・ビジョン

• 価値の言語化: 企業は誰をどのように幸せにしたいのかを考え定める必要がある
• ミッション・ビジョン: それを言語化したものが企業理念、ミッション・ビジョンと呼ばれるもの
• 三方良しの理想: 世の中、顧客、社員全員を幸せにすることが理想のスキーム
• 重みづけ: それぞれをどのくらいの重みづけで、どういう形で幸せにしたいかが企業理念となる
• 従業員の幸福: 自分達が幸せになることも当然考えて良い

■ 5. 報酬と評価の複雑性

• 報酬の位置づけ: 従業員に対する報酬は価値創出に対する貢献度、より正確には貢献に対する期待値に対する投資として支払われる
• 評価の困難さ: それぞれの従業員が創出している価値がどれくらいで、どれくらい金銭換算でき、いくら支払うかを評価するのはとても難しい
• 恣意性: 企業の価値観が問われるところであり、言ってしまえば恣意的である

■ 6. プロフィットセンター・コストセンターの問題

• 分類の恣意性: どの物差しを使うか、どちらに分類するかの解釈は極めて恣意的
• エンジニアの立場変化: ソフトウェアエンジニア部門は以前は間接部門でコストセンターと見なされるケースもあったが、現在は直接部門でプロフィットセンターと見なされる局面が増えた
• 構造的幻想: エンジニアが直接価値を生み出しているという実感は構造からの幻想である
• コンテキスト依存: それは永続的で普遍的なものでは決してなくコンテキストに依存する

■ 7. 花形の相対性と企業の個性

• 花形の多様性: 花形は企業によって変わり、エンジニア、トレーダー、営業、企画、デザイナー、法務、財務など様々
• ビジネスモデルとの関係: 企業のビジネスモデルと価値観によって変わる
• 会社の個性: 誰がより価値があるかと見なされるかには会社の個性が反映され、構造的な格差がある
• 二項対立の回避: プロフィットセンター・コストセンター、直接部門・間接部門といったコンテキスト依存の恣意的な二項対立分類は避けた方が良い

■ 8. 全員での価値創出

• 部署との疎結合: 事業がどのように売上を立てコストを支払っているかを意識することは大切だが、それは部署には密結合しない
• トータルでの価値創出: 社員全員でトータルでどのような価値を創出しているかに向き合っていく必要がある
• 負い目の排除: 間接部門だから価値創出に関われていないといった変な負い目を感じて仕事をする人がいて欲しくない
• モチベーション向上: 全員が価値に向き合い、自分の仕事が価値に繋がっていると感じられながらモチベーション高く仕事に当たれる方がより価値創出できる

■ 9. 抽象的な価値と具体的な成果

• 相補関係: 価値は曖昧で抽象的であり、それと相補的な関係にあるのが具体的な成果
• 成果の評価: 実際に表出してきた成果物、売上や利益、顧客数などの具体的なアウトカムを元に価値創出に繋がっていたかを評価する
• 不正な利益の排除: 自分たちが是とする価値創出とコンフリクトする形で上げた成果は評価されない
• 価値観のブラッシュアップ: 思いもよらぬ成果から逆に自分たちの価値観をブラッシュアップする材料が見つかることもある
• 継続的改善: 抽象と具体を行き来しながら価値創出とはどういったものなのかを定期的に見直し磨き続ける

■ 10. カルチャーとカルトの分水嶺

• 語源の共通性: 文化（culture）、耕す（cultivate）、カルト（cult）は語源を同じくする
• 紙一重の関係: 文化とカルトは紙一重である
• 発酵と腐敗の類似: 組織風土をどう耕すかによって有益なカルチャーになるか害をもたらすカルトになるかが決まり、これは発酵と腐敗の関係に似ている
• 分かつもの: カルチャーとカルトを分かつのは価値である
• 外部への開放: 自分たちが価値だと考えているものを自己満足で閉じこめず、その確からしさを外部に問いかけながら変容させていくこと、反証の扉を外部に開けておくこと

■ 11. 内集団贔屓の危険性

• 定義: 内集団贔屓とは自分が所属する集団を過大評価し、外部の集団を過小評価する傾向
• 具体例: 自分は頑張っているのに周りは認めてくれない、チームは頑張っているのに他部署が邪魔をするなど
• カルト化のプロセス: それでも自分たちは正しい、自分たちは特別という思い込みが強くなり、外部の意見や批判を受け入れられなくなったら組織はカルト化する
• 弱さの表れ: 外からのフィードバックを拒むのは傷つくのを恐れる弱さに他ならない
• 意識的な抵抗: 内集団贔屓が人間が普遍的に抱えがちなバイアスである以上、意識的に抗う必要がある

■ 12. 外部への働きかけの重要性

• 現実の受容: 外に目を向け現実を受け入れること
• 価値の承認: 自分たちが価値だと考えていることを認めてもらうように外部に働き掛けること
• フィードバックの活用: そのフィードバックからその価値基準が妥当なのかを検証していくこと
• 持続性の確保: 閉鎖的なコミュニティの中での幸福度は短期的には高められるかもしれないが、規模的には小さく持続性も乏しい
• 三方良しの意義: 自分たちと顧客の間だけで内集団贔屓を高める共依存関係を構築し、社会に損害を与えていたら本末転倒

■ 13. 開発組織における局所最適の罠

• 価値への接続: 自分たちの営みがどのように価値に繋がっているかを意識できるかが肝
• 局所最適の危険: 開発組織内だけ綺麗に整備しても、それがチーム外や世の中に価値を届けられてないのであれば価値は乏しい
• やりこみ要素: CI/CD自動化、開発プロセス改善、キャリアラダー整備など、やれること、やりたいことは無限にある
• 確実性の高いタスク: IaC、CI/CD自動化、開発プロセス整備などはデリバリーの安定性とスピードを高める効果の確実性が高いタスク
• カーゴ・カルトの回避: 価値に向き合わず、やった方が良いかもしれないことをやるべきこととして教条主義的に適用し続けるのはカーゴ・カルト

■ 14. 木こりのジレンマと全体最適

• ノコギリの研磨: 研がれていないノコギリで木を切り続けるのは非効率だが、過剰に研いだ刃物は刃こぼれしやすくなる
• 状況判断: なまくらだと思っているものが価値を出しているのであれば今のところはそれで十分かもしれない
• 周囲への支援: 同僚や隣の部署が石斧で戦っていてそれがボトルネックになっているなら、その手助けをした方が価値があるかもしれない
• 全体最適の視点: 全体最適を考え、どちらの方が最終的な価値に繋がるかを考えた上で判断したい
• チーム単位の限界: 自分たちのチームだけを良くしようとしたって仕方ない

■ 15. 個人のキャリアとの調和

• コンフリクトの存在: 価値優先の考え方は短期的には個人のキャリア形成とコンフリクトすることが少なくない
• 打算的な利点: 会社全体の思惑や価値観を理解しておく方が、より価値創出に繋がるアクションを起こしやすくなり、報酬などのリターンも得やすくなる
• 信頼の獲得: 周りの思惑が分かれば上手く信頼を獲得し、自分が使いたい技術を巧みにねじ込んで価値創出サイクルに融合させるなどのアクションをやりやすくなる
• 選択肢: 受容できないコンフリクトが発生する場合は、自身が変化する、組織に変容を促す、転職等で環境を変える、現状を受け入れる、などの選択をとる必要がある
• 幸福の最大化: あなたは自身の価値のオーナーであり、幸福の最大化を目指すべき

■ 16. 自律・自由と価値への向き合い

• 理想の組織: 各々が自律・分散・協調し、自由に自発的に動く組織を目指すべき
• ミドルアップダウン: 強力なリーダーシップとボトムアップが両立するミドルアップダウンマネジメントが実現された活力ある組織こそが一番価値を生み出す
• 不可欠な要素: 各々が価値への接続を意識することは不可欠
• 似非自己組織化の危険: 価値に向き合わないと卑近な同僚の安易な問題解決ばかりする似非自己組織化に陥る
• プラクティスの目的: 確実性の高いプラクティスの導入は無駄な複雑化を排除するためで、不確実で曖昧な価値に向き合う時間を増やすため
• 自由の条件: 理想の状態を維持しそこで自由に行動したいのであれば、尚更価値に向き合い、自分たちの価値を認めてもらう必要がある

(2025/10/18)

新規事業におけるGORM+SQLx併用アーキテクチャ

• 新規事業におけるGORM+SQLx併用アーキテクチャ - Speaker Deck

(2025/10/18)

プロダクトのコードから見るGoによるデザインパターンの実践

• プロダクトのコードから見るGoによるデザインパターンの実践 #go_night_talk - Speaker Deck

(2025/10/18)

At a past company, the head of engineering and the principal engineers decided...

At a past company, the head of engineering and the principal engineers decided to break our Ruby on Rails application into a Go microservices mesh.

They created very detailed design documents and architecture diagrams. They went all out and used Kubernetes, gRPC, service templates, the whole shebang.

The whole senior engineering leadership came from Amazon, where they were used to each team owning a distinct service. They tried to apply that model directly. But our issues were with code ownership and poor domain modeling.

The entire application could have run on just a handful of EC2 instances.

What was the result?

Five years later, 70% of the application is still running on the Ruby on Rails monolith. Never completed the migration. But now they have to maintain two systems.

None of the original leadership works there anymore.

@yatish_me

翻訳:

以前勤めていた会社で、エンジニアリング責任者とプリンシパルエンジニアは、Ruby on Rails アプリケーションを Go のマイクロサービスメッシュに分割することを決定しました。

彼らは非常に詳細な設計書とアーキテクチャ図を作成しました。Kubernetes、gRPC、サービステンプレートなど、あらゆるツールを駆使して徹底的に取り組みました。

シニアエンジニアリングリーダー陣は全員 Amazon 出身で、各チームがそれぞれ独立したサービスを所有することに慣れていました。彼らはそのモデルをそのまま適用しようとしましたが、コードの所有権とドメインモデリングの不備が問題でした。

アプリケーション全体を、ほんの数個の EC2 インスタンスで実行できたはずです。

結果はどうなったでしょうか？

5年経った今でも、アプリケーションの70%は依然として Ruby on Rails モノリス上で稼働しています。移行は完了していません。しかも、今では2つのシステムを維持管理しなければなりません。

元のリーダー陣はもう誰もそこで働いていません。

MEMO:

• 流行りのアーキテクチャや手に馴染んだアーキテクチャを脳死で適用したくなるの、エンジニアのバグ

(2025/10/17)

レビューのアンチパターンとその対策：その3「属人化レビューと知識の偏り」

• レビューのアンチパターンとその対策：その3「属人化レビューと知識の偏り」

(2025/10/17)

レビューのアンチパターンとその対策：その2「形式的レビューと意味のないApprove」

• レビューのアンチパターンとその対策：その2「形式的レビューと意味のないApprove」

(2025/10/17)

レビューのアンチパターンとその対策：その1「完璧主義レビュー問題」

• レビューのアンチパターンとその対策：その1「完璧主義レビュー問題」

(2025/10/17)

SIerで働いていた時に、時間内にビューを終われない人を炎上プロジェクトでよく見かけました。行き当たり...

SIerで働いていた時に、時間内にビューを終われない人を炎上プロジェクトでよく見かけました。

行き当たりばったりであら捜しするのはレビューではないです。

レビューをする以上、時間内にゴールを示す必要があります。

これができないなら実力不足です。

あと、レビューをする側が偉いと勘違いしているケースが多かったです。

レビューをする側もされる側も立場は同等です。

正確に言えば、どちらも平等に責務と責任があります。

「間違いを指摘してやってる。」

「こんなこともできないのか」

みたいな態度でレビューする人には、レビューをやる資格はありません。

炎上プロジェクトで、ドキュメントレビューが炎が燃え広がるきっかけになることが多いです。

ドキュメントのレビューもできないようなレベルの社員は、プロジェクトに関わるだけで負債になります。

プロジェクトを切り盛りするような立場を担う会社なら、レビューの仕方の研修とかやったらどうかと思う。

@Anubis_369

MEMO:

• 重箱の隅を突付いてばっかりでレビューが終わらないの本当にダルダルである

(2025/10/17)

プロダクト戦略から考えるアーキテクチャ選定

• プロダクト戦略から考えるアーキテクチャ選定

(2025/10/16)

『ソフトウェア設計の結合バランス　持続可能な成長を支えるモジュール化の原則』

• 『ソフトウェア設計の結合バランス　持続可能な成長を支えるモジュール化の原則』 - snoozer05's blog

(2025/10/16)

README ファイルの心配をやめた方法

• README ファイルの心配をやめた方法 | Amazon Web Services ブログ

(2025/10/16)

Cloud RunとVitePressで構築するヒトとAIが貢献可能な社内ドキュメント配信基盤

• Cloud RunとVitePressで構築するヒトとAIが貢献可能な社内ドキュメント配信基盤 - Findy Tech Blog

(2025/10/15)

AI時代のソフトウェアプロダクト開発──変わるエンジニア、チーム、組織

• AI時代のソフトウェアプロダクト開発──変わるエンジニア、チーム、組織 - mtx2s’s blog

要約:

■ 1. 記事の目的と範囲

• 目的: 生成AIに関する最新の調査結果をもとに、ソフトウェアプロダクト組織とエンジニアの変化を整理する
• 対象期間: 数年先の未来ではなく、現在およびその少し先くらいの範囲
• 理由: 技術進化が速すぎて予想がつかないため、あまり先のことを考えても的外れな内容になる
• データの範囲: 2025年以降に公開されたものに限定
• 背景: 執筆時点が2025年10月、AIエージェントの本格的な活用が始まったのも2025年
• 注意: 内容には筆者自身のバイアスが少なからず含まれる

■ 2. Human-AIオーケストレーション化

• 対話型UIの意図: ChatGPTやGeminiのような生成AIツールが対話型である理由は、Human-in-the-loopをUIとして形にする意図もあったのではないか
• ワークフロー: 人間がAIに指示を出し、出力を評価し、さらに完成度を高めるための指示を与える
• 最終成果物: 人間を介したループの果てに最終成果物を得る
• Human-AIオーケストレーション: 人間がオーケストレーターとして全体を指揮し、AIが実行を担う
• AIエージェントとの協働: 人間は目的や戦略設計により集中でき、AIが自律的にタスクを計画し、必要に応じて外部ツールを活用する

■ 3. 開発プロセスへのAI導入状況

• Stack Overflowの2025年調査: 回答者の84%がAIツールを開発プロセスに利用（前年度の76%から8ポイント増加）
• AIエージェント利用の現状: 51%のプロの開発者がAIエージェントをまだ利用していない
• 内訳:
  • 14%はコード補完のみに留まる
  • 37%はAIエージェントの導入予定はない
• 調査期間の影響: 調査期間が2025年5月29日から6月23日で、本格的なAIコーディングエージェントツールの登場がその前後だったため、まだ十分に浸透していなかった
• Claude Codeのリリース: 5月22日

■ 4. AI生産性パラドックス

• 問題の発生: AIを導入しても効果が出ない、かえって手間が増えて疲れるという声がある
• PRレビュー時間の増加: より多くのプルリクエスト（PR）が投げられるようになった結果、PRのレビュー時間が91%増加
• 開発生産性への影響: 開発生産性やビジネス成果に目立った変化がみられない
• 定義: いわゆる「AI生産性パラドックス」と呼ばれる問題
• 将来の見通し: 技術の進化やプラクティスの登場で、いずれ軽減されていくはずだ（OpenAI DevDay 2025のCodexの実演でそれを感じられる）

■ 5. 全開発チームへのAI導入状況の均一化

• 必要性: 開発ワークフローのAI化は、チーム間での浸透状況にバラツキが無いほうがよい
• 理由: バラツキがあると、導入効果を相殺する要因となり得る
• 具体的問題: AI導入の遅れているチームが足を引っ張り、先行しているチームのスピードを打ち消してしまう可能性
• パラドックスの一因: これもAI生産性パラドックスを引き起こす一因
• ボトルネック: 生産性向上のボトルネックは、AIモデルそのものではなくシステム──すなわち組織構造と運用にある
• 対策: 開発チーム間でのAI導入を段階的に均一化していく取り組みが求められる

■ 6. PDLC全体へのAI導入

• 最終的な方向性: 生成AIの活用は、開発だけにとどまらず、最終的にPDLC（Product Development Life Cycle）全体へと広げることになる
• 背景: AI生産性パラドックスがその背景
• コーディング時間の割合: AI導入が最も進んでいるコーディング作業に要する時間は、PDLCの中で25%から35%に過ぎない
• 市場投入時間への影響: AIを導入してもコーディング時間がゼロになるわけではないため、市場投入までの時間への影響は軽微
• ボトルネックの移動: 一部のフェーズやプロセス、ステージのみを高速化しても、下流で詰まればそこがボトルネックとなり改善効果は取り消される
• 全体最適化: 部分最適ではなく、全体最適化を進めることがAI活用の次の焦点

■ 7. プロダクトディスカバリのクロスファンクショナル化

• プロダクトディスカバリの定義: 「顧客とビジネスにとって価値があり、実現可能なものは何か」を継続的に探り、学ぶプロセス
• 目的: ソフトウェアデリバリーの前に実施され、「何を作るべきか」という不確実性を減らす
• 従来の課題: プロトタイピングのコストが高かった時代は、検証対象のアイデアを厳選せざるを得なかった
• フェーズの分離: アイデアを検討・選定するフェーズと、プロトタイプを作成して検証するフェーズは明確に分かれていた

■ 8. AIによるプロダクトディスカバリの変化

• マッキンゼーの指摘: AIネイティブなPDLCではアイデア検討とプロトタイプ作成の二つのフェーズが統合される
• 理由: 生成AIによってプロトタイプ作成に要する時間が大幅に削減されるため
• 新しいワークフロー: アイデアが浮かべばすぐに形にし、実際に動くソフトウェアで検証できる
• Vibe Coding: このプラクティスに最適なワークフロー
• 職能を越えた連携: プロダクトディスカバリのサイクルが高速化すれば、職能を越えた緊密な連携がこれまで以上に求められる
• 分断の問題: 職能が分断された状態では、全体のスピードが損なわれるうえ、後工程になるほど目的意識（Why）が薄れて検証の精度も落ちる

■ 9. 『INSPIRED』によるプロダクトディスカバリの説明

• 協力の重要性: 発見は、プロダクトマネジメント、ユーザーエクスペリエンスデザイン、エンジニアリングの緊密な協力によるところが大きい
• リスクへの取り組み: 製品の発見においては、製品のプログラムの1行目を書く前に、さまざまなリスクに取り組んでいる
• 目的: 製品発見の目的は、良いアイデアと悪いアイデアをすぐに判別すること
• 成果物: 製品発見が生むものは有効なプロダクトバックログである
• 帰結: クロスファンクショナル化は、AI時代のプロダクトディスカバリにおける必然的な帰結

■ 10. デュアルトラックアジャイル

• 定義: プロダクトディスカバリとデリバリーを1つのプロセスに統合するモデル
• 適合性: プロダクトディスカバリとソフトウェアデリバリーをクロスファンクショナルに進めるなら、このアプローチが適合する
• ディスカバリの成果物: 『INSPIRED』で述べられているとおり、プロダクトディスカバリの成果物は「有効なプロダクトバックログ」

■ 11. ディスカバリとデリバリーの循環

• ディスカバリトラック: 企画を進める方
• デリバリートラック: 開発を進める方
• プロダクトバックログ: ディスカバリトラックで詳細化したり検証して生き残った企画は、プロダクトバックログにデリバリートラック向けのアイテムとして追加される
• フィードバックループ: デリバリートラックで開発し、リリースして得たフィードバックからの学びは、ディスカバリトラックに返される
• 全員参加: チームメンバー全員がどちらのトラックにも参加する
• ベロシティの低下: ディスカバリトラックにエンジニアが参加すると開発時間が減ってベロシティも下がるが、それは問題ではない
• プロダクト開発: チームが担っているのは単なるソフトウェア開発ではなく、プロダクト開発

■ 12. 連携の重要性

• デュアルトラックアジャイルの有無: デュアルトラックアジャイルを採用しなくとも、ディスカバリとデリバリーのクロスファンクショナル化と連携が重要であることは変わらない
• HatchWorksのAIネイティブ手法: 両トラックで継続的なコラボレーションと適応を設計原則として掲げる
• マッキンゼーの強調: AIネイティブなPDLCにおけるディスカバリ/デリバリー連動の重要性を強調

■ 13. Agentic化

• 定義: AIエージェントを活用し、能動的に価値を生み出す働き方への変化を「Agentic ∗（Agenticスター）」化と呼ぶ
• 用語の由来: HatchWorksによるもの
• 具体例: エンジニアなら「Agenticエンジニア」
• 将来の方向性: 今後はエンジニアだけでなく様々なロールや職種がこの方向に進む

■ 14. Agentic Coding

• 定義: Human-AIオーケストレーションによるコーディング
• 注目のきっかけ: Anthropic社が2025年4月にClaude Code利用者に向け「Agentic Codingのためのベストプラクティス」と称した文書を公開
• Agentic Engineering: Zedの提唱で、プログラミング手法をエンジニアリングへと昇華させようとするもの

■ 15. プログラミングとエンジニアリングの違い

• Google社内の定義: 「ソフトウェアエンジニアリングとは時間で積分したプログラミングである」
• エンジニアリング: 「一度作ったら終わり」ではなく、継続的な開発・保守・運用を通して価値を更新していく営み
• Agenticエンジニア: Agentic Codingを駆使してエンジニアリングを担うエンジニア
• コーディング以外の職務: コーディングだけを担っているわけではなく、従来の開発知識や経験にAIオーケストレーションスキルを融合して様々な職務を遂行する

■ 16. 従来の知識や経験の必要性

• 人間の介在: AIエージェントによるタスク実行に人間が介在するため、従来の知識や経験が必要
• AIの限界: 人間がまったく介さずともAIエージェントだけですべてをこなせる時代はまだ到来していない
• チーム編成: 専門性の異なる人が集まる必要性、一人でカバーできる仕事量やドメインにも限界がある
• PDLCの完結: プロダクトの規模や性質にもよるが、一人でPDLCすべてを完結することはまだ難しい
• チームの必要性: 様々な知識や経験を持った人たちがチームを組んで仕事を進める

■ 17. 様々なロールのAgentic化

• エンジニア以外への拡大: 今後はエンジニア以外のロールや職種もAgentic化する
• 専門知識の活用: Human-AIオーケストレーションを前提としたワークフローでは、それぞれの専門知識と経験が活かされる
• HatchWorksの定義例:
  • Agenticプロダクトストラテジスト
  • Agentic QAエンジニア
  • Agenticデザイナー
• AI時代のチーム: 専門性とオーケストレーション能力を兼ね備えたAgenticな集合体へと進化していく

■ 18. チームメンバー数の削減

• 可能性: AI導入によってチームの少人数化がさらに進む可能性があるが、どこまで下がるかは定かではない
• 一般的な計算: 生成AIの導入によって生産性が20から30%向上するため、人員を同程度削減しても成果は維持できる（これまで10人で達成していた成果を7人から8人で出せる）
• 問題点: 仕事量だけで計算されたものであり、仕事の領域や専門性が考慮されていない

■ 19. メンバー数削減の限界

• 領域と専門性の狭小化: メンバー数を減らしすぎると、適切な品質でアウトプットできる仕事の領域や専門性が狭くなる
• マルチスキル化の限界: 一人の人間がカバーできる範囲には限界がある
• 人間の知識の必要性: Human-AIオーケストレーション型のワークフローでは、人間の知識や経験が依然として欠かせない
• 専門外の品質: 生成AIの支援があっても、専門外の領域では品質が落ちざるを得ない
• バランスの重要性: チームが扱える領域・専門性と品質の間のバランスが取れる地点で収束していく

■ 20. チーム数の削減

• 限定的な削減: チームの数も限定的な削減になる
• 理由: チームメンバー数の議論と同じ
• 根拠: チーム数を決める根拠は、結局のところチームが扱える「認知負荷」の総量にある
• 『チームトポロジー』の考え方: チーム単位で認知負荷を抑えることで、過剰な責任範囲や業務領域の拡大を防ぐ

■ 21. 認知負荷の問題

• 認知負荷を考慮しない場合: チームの責任範囲と担当領域は広がりすぎることになる
• 結果: 自分の仕事に熟達するだけの余裕がなくなり、担当業務のコンテキストスイッチに悩まされる
• チーム数の決定要因: チームが対応できる領域と品質のバランスによって最適なチーム数が決まる
• 不変性: 対応できる領域が変わらないなら、チーム数も大きく変化しない

■ 22. 生成された成果物の品質に対するアカウンタビリティ

• 責任の所在: AIによる成果物の品質は、指示した人間が責任を負っている
• リスク: この自覚を欠いたAI活用は、チームや組織の生産性をかえって損ねるおそれがある
• AIワークスロップ: 見かけは立派でも実質的な価値に欠けた成果物
• 追加作業: ワークスロップ1件あたり平均2時間弱の追加作業が発生する
• 現状: 40%の人が過去1か月間にワークスロップを受け取った、受け取った仕事の15%をワークスロップが占めていた

■ 23. エンジニアリングの原則

• Google社内の定義: エンジニアリングとは「時間で積分したプログラミングである」
• 成果物の要件: ソフトウェアを継続的に開発し、保守・運用できるものでなければならない
• 不変の原則: 人間によるものであれ、AIによるものであれ、この原則は変わらない
• 最終的な責任: AIが出力した成果物であっても、その品質のアカウンタビリティは、それを指示した人間にある

■ 24. ラーニングアジリティ

• 定義: 新しい状況や初めての経験から素早く学び、それを次の状況で柔軟に活かす能力
• 本質: 単なる知識の吸収力ではなく、未知の環境に適応し、学びを実践へと変えられる力
• AIの進化速度: AIの進化は極めて速く、今日の常識が明日には通用しなくなる
• ソフトウェアエンジニアリングの変化: 不確実性の高い環境下で、これまで以上に加速している
• 求められる姿勢: 新しい技術や経験に臆することなく踏み出す姿勢

■ 25. プロンプト/コンテキストエンジニアリングスキル

• 不可欠なスキル: 生成AIを扱うエンジニアには、プロンプトエンジニアリングとコンテキストエンジニアリングの力が不可欠
• 重要性: これらを磨かなければ、意図を正確に伝え、AIの膨大な知識から期待する出力を引き出すことはできない
• LLMの理解: LLMの特性を深く理解すれば、より適切なプロンプトを組み立てることも可能
• コンテキストの整備: チームのパフォーマンスを高めるために、ドキュメントを揃えるだけでなく、AIエージェントのツールチェーン（MCP）を整備することも含まれる

■ 26. フルスタック化

• マッキンゼーの予測: 生成AIによって開発者はフルスタック化していく
• 理由: AIを活用することで、専門外の技術領域や技術スタックを扱うハードルが下がる
• 合理性: フロントエンドからバックエンドまでエンドツーエンドで開発できることには確かに合理性がある
• 課題: 実際にフルスタック開発を行うと、技術領域ごとにIDEなどの開発環境を切り替えなければならず、作業は煩雑になりやすい
• 環境設計: AIを前提とした環境設計も重要（例：マルチリポよりもモノリポの方が適しているかもしれない）

■ 27. 設計やアーキテクチャ技術

• 人間の役割: システム全体を俯瞰するアーキテクチャ設計は、依然として人間の役割が大きい
• Stanfordの2025年研究: 生成AIは多くのライブラリや関数呼び出しが絡む複雑なコーディングを苦手としている
• シンプルな設計: 一方で、シンプルな設計の多くはAIに委ねた方が効率的
• 境界の変化: 今後も人間とAIの役割の境界は変わり続ける（各社のLLMの性能が日々向上しているため）
• 統合的視点: 人間がシステム全体の構造と品質を見通し、どの領域をAIに任せるかを判断する役割は変わらない

■ 28. クラフトマンシップ

• 暗黙知の価値: 経験豊富なエンジニアが持つ暗黙知は、AIに置き換えられにくい領域
• 生成AIの限界: 生成AIは定型的な形式知を学習できても、文脈依存の判断や経験則のような暗黙知を再現することは難しい
• Stanfordの雇用データ分析: AIに置き換えられやすいのは主に定型業務であり、熟練者が持つ暗黙知こそが今後も価値を持ち続ける
• Human-AIオーケストレーションでの役割: 熟練の技術や判断力は、人間が品質を統制する要として機能する
• ロバート・C・マーチンのクラフトマンシップ: AI時代においても、高い品質を追求し、技術的卓越性を磨き続ける姿勢こそ、変化の時代におけるプロフェッショナルの証

■ 29. アプリケーション数の爆発的増加

• 予測: AIエージェントにより、公開されるアプリケーションの数は爆発的に増える
• 理由: エンジニアでなくてもアプリケーションを作れるようになる
• 品質の混在: SNSのコンテンツがそうであるように、良質なものとそうでないものが入り混じる
• 差別化の模索: その中で他との差別化を模索することになる（品質を高めるのか、速さや量で勝負するのか）
• AI活用戦略: AIの活用戦略そのものが競争軸となる

■ 30. 非決定性への対応

• マーティン・ファウラーの指摘: 生成AIの特徴である「非決定性」とどう向き合うかをエンジニアは学ぶべき
• 非決定性の例: 同じプロンプトを使っても、毎回異なる結果が返る
• 人間との類似性: 私たちはすでに「非決定的な存在」と長く向き合ってきた（人間がそう）
• 同じ指示でも: 同じ指示を出しても、実行する人によって成果物は異なるし、同じ人でも状況によって結果は変わる
• マネジメントの応用: 生成AIの時代においては、マネジメントの知識やスキルをエンジニアリングに応用できる

■ 31. 組織設計の原則

• 執筆後の感想: AIがどれほど進化しても、人間を介在させる限り組織設計の原則は大きくは変わらない
• AI中心の組織: AI中心の組織を設計しようとしても、結局は人間の特性を考慮せざるを得ない
• 著書の紹介: 2025年8月25日に『チームの力で組織を動かす 〜ソフトウェア開発を加速するチーム指向の組織設計』が技術評論社から出版された
• 位置づけ: AIについてはほとんど触れていないが、AI時代の組織設計を考えるうえでの基礎となる内容

(2025/10/14)

なぜ気軽にテーブルにカラムを足してはいけないのか

• なぜ気軽にテーブルにカラムを足してはいけないのか

要約:

■ 1. 記事の目的

• 問題提起: データベース（RDB）の設計で深く考えずにテーブルにカラムを追加してしまうことはないか
• 心理的ハードル: テーブルの追加よりもアプリケーション側での変更が少ないので、心理的ハードルが低い
• 警告: カラム追加を続けると取り返しのつかないことになるかもしれない

■ 2. 3つの主要な問題

• データベース設計がちゃんとできていないことの兆候である
• 変更のコストが大きい
• インデックスの設計が難しくなる

■ 3. Database Smell（データベースの設計上の悪い兆候）

• 定義: カラムが多すぎるテーブルはDatabase Smellの1つ
• カラムを気軽に増やす場合の問題:
  • 正規化ができていない
  • 複数エンティティを混在させてしまう

■ 4. 正規化ができていない：マルチカラムアトリビュート

• 呼び名: SQLアンチパターンでの呼び名で、列持ちテーブルとも呼ばれる
• 具体例: 連絡先テーブルでphone1、phone2、phone3と電話番号カラムを追加していく設計
• 問題点:
  • 特定の電話番号を検索するには全てのカラムを検索する必要がある
  • 一意性の保証ができない
  • 更新時にどのカラムを更新するかのロジックが必要になる
• 正しい設計: 電話番号を別テーブルに分割し、1対Nの関係を持たせる

■ 5. 正規化の重要性

• 基本中の基本: 正規化はデータベース設計の基本中の基本
• 参考文献: 「達人に学ぶDB設計徹底指南書」第一版の紙面のほとんどを使って正規化について説明されていた
• パフォーマンスとの関係: パフォーマンスの問題などで正規化を崩すことが必要な時もあるが、最初の設計としては正規化するところから始めることを推奨

■ 6. 複数エンティティの混在

• 問題の発生: 複数のエンティティ（データモデル内で個別に識別可能な要素やオブジェクトを表す概念）が1つのテーブルに混在してしまう
• 具体例（注文テーブル）:
  • 最初は注文エンティティのみを表現
  • 後から発送日（shipped_on）カラムを追加
  • 結果として注文エンティティと発送エンティティの一部が混在
• 正しい設計: 発送は別のテーブルとして切り出すのが適切

■ 7. よくある失敗パターン

• 安直な追加: 日時（xxx_at / xxx_on）やフラグ（xxx_flag）やステータス（xxx_status）のカラムを追加すること
• 対策: これらを追加したくなったときには他のエンティティではないかと疑う

■ 8. 変更のコストの大きさ

• 基本認識: アプリケーションのリファクタリングと比べて、データベースのリファクタリングはコスト（時間・工数・リスク）が大きい
• 考慮事項:
  • 影響範囲がどの程度あるか
  • 既存データがどの程度あるか
  • ダウンタイムがどの程度許容されるか
• 覚悟の必要性: データベースリファクタリングは影響範囲も広く時間がかかるため、やり切るぞという覚悟が必要（そーだいさんのブログより）

■ 9. ロックとダウンタイムの問題

• ALTER TABLEのロック: 多くのケースでロックを取る
• レコード数が多い時の問題: 実行時間が長くなり、数時間そのテーブルに対する書き込みができなくなる場合もある
• 新テーブルへのINSERT: レコード数が多い場合、実行時間が長くかかったり、データベースのCPUを圧迫する可能性がある
• 事前準備: テスト環境でデータ移行のリハーサルを行い、実行時間やデータベースの負荷を確認しておくことが重要

■ 10. Dual Write期間の問題

• 定義: データ移行が大規模でリスクが大きい場合、アプリケーション側で新旧両方のテーブルに書き込むDual Writeを行うプラクティス
• メリット: アプリケーションのロールバックが可能になり、データ移行のリスクを減らせる
• デメリット:
  • アプリケーション内部での複雑性が増す
  • コードの変更にかかるコストが増大
  • リリースも複数段階に分けて行う必要があり、スケジュール管理も複雑になる

■ 11. 時間経過による移行コストの増大

• 移行自体のコスト:
  • レコード数が大きくなるとロックを取る時間やリソースの逼迫に大きく影響
  • 場合によっては8時間以上かかることもある
  • 「一晩のメンテだけで済むと思ってたら翌営業日の朝になっても終らない」という事態もありえる
• 警告: 本番環境でデータ移行を実施するときに「postgresql alter table 終わらない」というGoogle検索をしないようにすべき

■ 12. 影響範囲を調べるコスト

• カラム依存の調査: カラムを別テーブルに移動させる際に、アプリケーションの影響範囲を調査する必要がある
• テーブル依存の影響: カラムに依存していなくてもテーブルへの依存があると、カラムに依存がないかどうかを確認する必要が出てくる
• 時間経過の影響: 時間が経つほどテーブルに対する依存が増えるため、カラムの依存調査にかかる手間が増える

■ 13. データの予期せぬ値の問題

• Git管理の限界: データベースに入っているデータそのものはアプリケーションコードのようにGitを使って差分管理できない
• 予期せぬ値: 全く予期せぬ値が入っていることもありえる
• 保証の限界: 保証してくれるのはデータベースのスキーマ定義のみ
• バグの混入: 今のアプリケーションコードでは入りえない値が過去の期間だけ存在したバグによって混入することもありえる

■ 14. システムの使われ方の変化

• 想定外の使用: 時間の推移とユーザーの増加によってシステムの使われ方が変わりえる
• 予期せぬデータ: もともと想定していたのとは違う使われ方をしていたり、想定しない値が入っている可能性がある
• 検証の必要性: 昔からある膨大なレコードに対しては事前に入念な検証が必要

■ 15. インデックス設計の困難化

• 基本原則: 一般的にカラムが少ないほどインデックス設計は楽で、カラム数が増えるほど設計は難しくなりやすい
• インデックスの制約: インデックスは1つのテーブルに対してスキャンする際には1つしか使われない
• 複合インデックス: 複数のカラムに対してインデックスを使った検索を行いたい場合は複合インデックスを使う

■ 16. 複合インデックスの制約

• 左方一致の原則: 一般的に複合インデックスは左方一致する条件でしか利用されない（左から順番にしか使われない）
• 具体例（書籍テーブル）:
  • CREATE INDEX books_index ON books (category_id, publisher_id)
  • category_idとpublisher_idでの検索：インデックス利用
  • category_idのみでの検索：インデックス利用
  • publisher_idのみでの検索：インデックス利用されない（左側のカラムが使われていないため）

■ 17. インデックスショットガンの問題

• 定義: むやみやたらにインデックスを増やすと更新時のパフォーマンスが大きく劣化する問題（SQLアンチパターンで説明）
• カラム追加の影響: 気軽にカラムを増やすと後でパフォーマンスチューニングをする際にも足枷になりやすい

■ 18. 「慣れるより習う」の重要性

• 問題発見の遅れ: データベース設計の失敗は時間が経ってから気づくことが多い
• 同じ失敗の繰り返し: 自分で失敗した内容から学ばずに、異動や転職などで新しい環境に行って同じ失敗を繰り返してしまうこともある
• 他者から学ぶ: 他の人が失敗した内容を見て学ぶことはできる
• 理想状態の困難: 問題が大きくなってしまった後では理想の状態を描くことが難しい

■ 19. 問題の遅延発生

• そーだいさんの言葉: 「DBの問題は忘れた頃にやってくる」
• 学習資料の重要性: 学習のためにいい本や資料はたくさんある

■ 20. まとめ

• カラム追加の基本性: データベースの操作の中でも基本的な操作だが、さまざまな問題を起こしうる
• 適切な場合: カラム追加が適切な場合ももちろんあるが、適切なデータモデリング・テーブル設計が行われた上で初めて判断できる
• 経験と学習: 適切にデータベース設計ができるようになるまでは経験と学習が必要

(2025/10/14)

プロジェクトの状況が最悪な時に、心の杖にしてる事

• プロジェクトの状況が最悪な時に、心の杖にしてる事

朝出社して椅子に座ったなら、最低限の仕事は果たしていると思っている。

その上で、進捗ゼロでも会議に出る。

常に問題解決に焦点を当てて話をする。

何を棚上げしようと、問題解決にだけフォーカスする。

そこまで出来てれば、プロジェクトがどんな状況だろうと、クライアントが激怒してようと、自分の責任は果たしている。

最もダメなのは、その場におらず話が出来ない事だからだ。

担当者が話できなければ、一歩も解決に向かわない。

しかし、プロジェクトの状況が最悪な時は、ほとんどの時間が忙殺されているので、せめて『今は対応できません』を言うだけでもしなければならない。

それが言えれば、半歩だけだが前に進む。

だから状況がどうだろうと最低限、現場には出る。

それが出来ない人は、最低限の職責を果たしてないので職から去らなければならない。

今まで何箇所もの会社で何個もプロジェクトの炎上を見たが、ダメになる時は最終的にリーダーが出社拒否すると、後は経営層が出向いて銭金での敗戦処理になる。

リーダーが逃げなくてもダメな時はダメだが、少なくともリーダーが逃げると『あ、このプロジェクト終わったな』という空気になる。

ある程度の規模の組織でリーダーになるような人は、リーダーの仕事は常に前を向いて解決を目指す事であると分かってはいる。

ただ、本当にプロジェクトの状況が厳しくなり、解決出来ないどころか着手も出来ない課題がテトリスのように積み上がると、ネガティブ要素が多過ぎて、プレッシャーとストレスによってこの「常に前を向く」が極めて困難になる。

だから、自分は朝出社して椅子に座ったなら、最低限の仕事は果たしていると思っている。

これでどうにかならなかったプロジェクトは、今のところ無い。

MEMO:

• それは本当にどうにかなってるんですかね？？

(2025/10/13)

Remix 3 発表まとめ - React を捨て、Web標準で新しい世界へ

• Remix 3 発表まとめ - React を捨て、Web標準で新しい世界へ

(2025/10/13)

nullが多いテーブルには異なる情報がまとめられている可能性がある

• nullが多いテーブルには異なる情報がまとめられている可能性がある

要約:

■ 1. 記事の目的

• きっかけ: データベース設計をレビューしていた際に「テーブルにnullが多い時は少し立ち止まってみると良いかもしれない」という話をした
• 主張: nullが多いテーブルには異なる情報がまとめられている可能性がある

■ 2. nullが多いテーブルの例

• 携帯電話ショップの顧客管理システム: Customerテーブルの例
• テーブル構造:
  • 基本情報: id、name、address
  • キャンペーン情報: campaign_id
  • 来店情報: staff_id、sales_note
  • 契約情報: contract_plan_id、phone_number
  • 日時情報: first_came_at、registered_at、cancelled_at
• 問題: id以外のカラムが全てnull許容

■ 3. nullが増える傾向

• 主な原因: 本来は異なるモノなのに同じモノとして一つのテーブルにまとめてしまった時、nullableなカラムが増える傾向がある
• 極端な例: 「Person」と「House」という概念を「Something」テーブルにまとめると、nullableカラムだらけになる
• 理由:
  • Personには「築年数」なんて情報は存在しない
  • Houseには「血液型」なんて情報は存在しない
  • Somethingテーブルに各データを入れると、存在しない情報がnullになる

■ 4. Customerテーブルの詳細分析

• registered_at: 契約したcustomerにしか値が存在しない（契約済Customer）
• cancelled_at: 解約したcustomerにしか値が存在しない（解約済Customer）
• staff_id: 実際に来店したcustomerにしか値が存在しない（来店済Customer）
• 問題: 特定の状態のCustomerにしか存在しないカラムが多数存在する

■ 5. 異なる状態を一つのテーブルにまとめる問題

• クエリの複雑化: 現在契約中の顧客に利用料を毎月請求するには、必ず「WHERE registered_at IS NOT NULL AND cancelled_at IS NULL」を書かなければいけない
• ミスのリスク: 一箇所でも書き忘れたら、既に解約している過去の顧客や一度来店しただけの顧客に利用料を請求してしまう
• 責務の移譲: 情報を区別する責務がDBからアプリケーションコード側に委ねられる

■ 6. 追加の問題点

• リソースとイベントの混在: 「顧客」というリソースと「契約する」「解約する」というイベントが一つのテーブルにまとめられている問題もある
• 記事の範囲: これは別のトピックに脱線するため本記事では言及しない

■ 7. アプリケーション側に責務が委ねられる弊害

• 重複実装の必要性: 管理者画面など、同じDBに触れる他のアプリケーションにも同じ処理を書かなければいけない
• ミスの誘発: 緊急対応時などに、registered_atとcancelled_atを組み合わせる必要があるという暗黙的な知識を持っていないと正しいクエリが書けない
• 理解の困難性: データベースに格納されたレコードを見ただけでは情報が正しく理解できず、アプリケーション側のロジックも見ないとCustomerが契約中か否か判断できない

■ 8. 推奨される設計方針

• 基本原則: 本来異なるモノは異なるモノとして別のテーブルに格納した方が良い
• 例外: 性能上の問題が起きていて、かつその問題がマテリアライズドビューやキャッシュ等で本当に解決できない場合のみ
• シグナル: nullが多すぎるテーブルは本来異なるモノがまとめられていることを示唆している可能性がある

■ 9. nullが許容されるケース

• 任意項目の場合: 単純に任意項目だからカラムがnull許容になっているだけで、値がnullだったとしてもレコードの意味は変わらず、アプリケーション上の振る舞いも変わらないケース
• マッチングアプリの例:
  • とんでもない数の任意選択項目（趣味、性格特性、家族構成など）
  • いくつ選択してもアプリケーション上の振る舞いは変わらない
  • 自分の情報が検索結果に表示されづらくなるだけで、いいねも送れるし、メッセージの送受信も可能
  • 機能的な差はないため、先述の不都合は特に生じない

■ 10. まとめと個人的見解

• nullの無条件否定ではない: nullだから無条件に悪いのではない
• 問題となるケース: 特定のカラムがnullか否かによってレコードの意味が変わるようなテーブル（例: cancelled_atがnot nullだと契約済Customerではなく解約済Customerになる）
• 設計の問題: このようなテーブルは正しく現実の事象をモデル化できていない可能性がある
• 意見の多様性: nullは無条件に悪いとする意見もあり、nullの許容度に関しては色んな意見がある

(2025/10/12)

NULL撲滅委員会

• NULL撲滅委員会

要約:

■ 1. NULL撲滅委員会の序文

• 目的: NULL撲滅基本宣言への参加を募る
• NULLの質の悪さ: 最初は感覚に心地よく合致するため自然にシステム設計に忍び込み、気づいたときにはシステムを複雑、非効率的、直観に反する動作をするものにしてしまう
• 防御方法: NULLの正体をよく知り、どのようなメカニズムによってシステムに猛威を振るうのかを理解すること
• 本文の目的: 設計の際の心構えとして、NULLから身を守る具体的な方法を明らかにする

■ 2. NULLが悪い5つの理由

• 3値論理の問題: SQLの作成にあたり、人間の直観に反する3値論理を考慮しなければならない（最大の理由）
• パフォーマンスの悪化: IS NULL、IS NOT NULLを指定する場合、インデックスが参照されないためパフォーマンスが悪い
• NULLの伝播: 四則演算またはSQL関数の引数にNULLが含まれると「NULLの伝播」が起こる
• ホスト言語の非標準化: SQLの結果を受け取るホスト言語において、NULLの組み込み方が標準化されていない
• 記憶領域の圧迫: NULLは行のどこかに余分なビットを持つことで実装されているため、記憶領域を圧迫したり検索パフォーマンスを悪化させる

■ 3. NULLの伝播の具体例

• 四則演算:
  • 1 + NULL = NULL
  • 2 - NULL = NULL
  • 3 * NULL = NULL
  • 4 / NULL = NULL
• 0除算の例外: NULL / 0 = NULLとなり、0除算の場合ですらエラーにならない
• SQL関数: 多くのSQL関数もNULLに対してはNULLを返す仕様
• propagateの意味: 「（雑草が）はびこる」のように負のニュアンスを持つ単語で、NULLの厄介者ぶりを表すのにぴったり

■ 4. 意外と知られていない問題

• ホスト言語のサポート不足: ホスト言語が関係モデルにおけるNULLをサポートしていない現状では大きな問題
• DBMS間の非互換性: Oracleでは空文字とNULLは区別されないが他のDBMSでは区別されるという現状がまかり通っている
• 移植性の低下: DBMS間のコードの移植性を大きく下げる要因となる
• 実装依存の問題: ホスト言語やDBMSの実装次第というところもあり、今後解消される可能性はある

■ 5. NULL完全排除の困難性

• 永久追放の難しさ: リレーショナル・データベースの世界からNULLを永久追放するのは難しい
• 現場の感覚: さして重要でない列にNULLが入っているぐらいは眼をつむるのが現場のSEとしての感覚
• 深い根: NULLがあまりにもリレーショナル・データベースの奥底に根を張る存在だから
• NOT NULL制約の限界: 全列にNOT NULL制約を付加しても、外部結合やCUBE、ROLLUP付きのGROUP BY句でNULLは簡単に入り込んでくる

■ 6. NULLの便利さと危険性

• 便利な概念: うまく使えばNULLが大変便利な概念であることは間違いない
• 扱いの難しさ: 「うまく使う」ことがNULLに関してはとても大変
• 油断の危険性: うまく御していると思って油断していると背後から一突きされる恐怖
• 議論の絶えないテーマ: NULLの扱い方は識者の間でも議論が絶えない

■ 7. 識者の見解

• コッド: NULLが関係モデルにとって不可欠な要素であると確信
• デイト: NULL撲滅運動の最右翼
• セルコ: 場末のエンジニアの現実感覚に最も合致する穏健的な人生処方
• 公式方針: NULLは薬のようなもの。ほどよい使用は有益だが乱用は害を与える。使う必要があるときに適正に使用し、後はなるべく使わないのが最もよい考え方

■ 8. コードの場合の対処法

• 重要性: 企業コード、顧客コード、県コード、性別コードなど、システムにとって重要な列であることが多い
• NULL排除の第一標的: 検索や結合のキーとなることも多いため、NULL排除の第一標的となる
• 解決策: 未コード化用コードを割り振る
• ISO性別コードの例: 1（男性）、2（女性）の他に、0（未知）、9（適用不能）という二つの未コード化用コードが体系に組み込まれている
• コッドの分類との対応: 未知と適用不能に対応するコードが採用されている素晴らしい解決

■ 9. コード設計の注意点

• 文字型での宣言: コード列は必ず文字型で宣言すべき
• 数値型の問題:
  • 「99999」のようなコードは、後で実際にその顧客が現れる可能性がある
  • 前ゼロが削られてしまう（例: 「008」が「8」になる）
  • ソートがうまく並ばない
  • データの入ったテーブルに対して後から型を変えるのは大変
• 推奨コード: 「XXXXX」のようなありえない文字列を使用

■ 10. 名前の場合の対処法

• 方針: コードの場合と同じで、不明を表す値を与える
• 具体例: 「不明」「UNKNOWN」など、開発チーム内で共通了解の得られた適当な名前
• 重要度: 名前はコードに比べてキーに使われる頻度が少なく、付加的な意味しか持たない場合が多いため、あまり撲滅に目くじらを立てる必要はない
• 注意点: 名前をキーに使用しているテーブルがある場合、設計に何か間違いがあると疑うべき

■ 11. 数値の場合の対処法

• 最良の方法: 最初からNULLを0に変換してデータベースへ登録する
• 推奨しない方法: NULLを許可しておいて集計時にNULLIF関数やIS NOT NULL述語で排除する方法
• 経験則: NULLを0に吸収させて問題化したことはあまりない
• 概念的な違い: 「ガソリンタンクを持っていない車と、空のガソリンタンク」は概念的に異なるため、厳密には乱暴な方法

■ 12. 数値の現実的な対応

• 基本方針: 0に変換する
• 例外処理: どうしても0とNULLを区別したい場合だけ、NULLを許可する
• 期待: 0に変換することで全てうまくいくことを祈る

■ 13. 日付の場合の対処法

• 判断の必要性: NULLの持つ意味合いが多岐にわたるので、その場その場でデフォルト値を使うか、NULLを許可するかの判断が必要
• 期限を指示する場合: 「0001-01-01」や「9999-12-31」のように可能な最大値・最小値を使う
• 具体例: 社員の入社日やカードの有効期限など
• 昔からの方法: この方法は昔からよく使われている

■ 14. 日付が未知の場合の対処法

• 該当ケース: 歴史上の事件が起きた年月や誰かの誕生日など、コッドの分類における「未知」のNULLに相当する場合
• デフォルト値の困難性: 意味ある値を入れることはできない
• 対応オプション:
  • NULLを許可する
  • 「UNKNOWN」という文字列を入れる
  • 日付の列を文字型で宣言する（NOT NULL制約を確実に付けられる場合は日付型でも可）
• 型変換の活用: 文字型と日付型は簡単に型変換できるため、暦日計算の場合だけキャストする選択も性能的なオーバーヘッドが問題にならなければ考慮に値する

■ 15. まとめ

• NULL撲滅の基本方針:
  • まずデフォルト値を入れられないか検討する
  • どうしようもない場合だけNULLを許可する
• 効果: これだけでもかなりNULLのもたらす厄介事からシステム開発を解放できる
• 継続的改善: 「そのやり方ではうまくいかない」「もっと良い方法がある」という場合は、フィードバックを歓迎

(2025/10/12)

That boolean should probably be something else

• That boolean should probably be something else | nicole@web

要約:

■ 1. ブール型使用の問題提起

• 基本的な型: ブール型は最初に学ぶ型の一つで、ブール論理が現代のコンピューティングの基盤であるため自然に使用される
• 使いすぎの問題: ブール型を使用するほぼすべてのケースで、別の何かを使用すべき
• 設計改善の効果: 「別の何か」を見つける努力は、システムについて多くを教え、設計を改善する（最終的にブール型を使用することになっても）

■ 2. 日時型（Datetime）への置き換え

• 典型的な使用例: ウェブサイトでメール確認を表すis_confirmedというブール型カラム
• データの損失: ブール型では確認がいつ発生したかという情報を捨てている
• 改善策: ユーザーがメールを確認した日時をnullable列に保存する
• 利点:
  • 列がnullかどうかをチェックすることで同じ情報を得られる
  • 他の目的のためにより豊富なデータを得られる
  • 確認プロセスのバグがあった場合、タイムスタンプを使用して影響を受けるユーザーを特定できる
• 検出方法: ブール値を変更するためにアクションが発生する必要があるか、値が一度だけ変更できるかを尋ねる。両方に該当すれば日時型をブール型に変換していると考えられる

■ 3. 列挙型（Enum）への置き換え

• 残りのブール型データ: 何かのタイプやステータスを示すことが多い
• 典型例:
  • ユーザーが管理者かどうかを示すis_adminカラム
  • ジョブが失敗したかどうかを示すfailedカラム
  • ユーザーがアクションを実行できるかどうかのブール値の返却
• 管理者の例での問題: ブール型を使用すると、最終的にはより多くのカラムが必要になり、他のステータスを追加し続けることになる
• 列挙型による解決:
  • UserRole列挙型（User、Admin、Guest、SuperAdmin）を使用
  • 新しいケースを簡単に追加できる
  • ツールを使用してコード内のすべての新しいケースがカバーされていることを確認できる

■ 4. ジョブステータスの例

• ブール型の問題: is_failed、is_started、is_queuedなど複数のブール型が必要
• 列挙型の利点: 単一のstatusフィールドで様々なステータスを持つ列挙型を使用
• 追加の推奨: 各イベントのタイムスタンプフィールドも必要だが、ステータスも明示的に保存すべき
• 効果: ステータスを保存することで状態機械に似た構造になり、よりクリーンなコードと状態遷移に沿った分析が可能

■ 5. 権限チェックの例

• ブール型返却の問題: trueはユーザーが実行でき、falseは実行できないことを意味するが、型からアプリケーションロジックの意味を推測できない
• 列挙型による改善:
  • PermissionCheck列挙型（Allowed、NotPermitted(reason: String)）を使用
  • 2つの選択肢しかない場合でも列挙型として表現できる
• 追加の利点: 権限チェック失敗の理由を返すなど、より豊富な情報を含められる

■ 6. 列挙型を使用すべき検出方法

• 相互排他的なブール型の増殖: 相互に依存するブール型が増える
• 同時変更: 同時にすべて変更される複数のカラムが見られる
• 長期使用: 長期間にわたって返却され使用されるブール型が見られる
• 重要性: プログラムを保守可能で理解しやすく保つために列挙型を使用することが重要

■ 7. ブール型を使用すべきケース

• 条件式の評価: 条件式の結果を（一時的に）保存して評価する場合
• 最適化の観点:
  • コンピュータのための最適化（変数の再利用）
  • プログラマーのための最適化（大きな条件式に名前を付けて理解しやすくする）
• 中間値の保存: 中間値を保存することで最適化を図る

■ 8. 条件式での使用例

• 例: calculate_user_data関数でuser_can_do_thisというブール型変数を使用
• 目的: 長い条件式に名前を付けて計算内容を明確にする
• 改善の余地: この場合でも、列挙型のmatchを使用する方が理にかなう場合がある
• 保持の理由: 計算内容に名前を付けるためにブール型を保持する可能性はある

■ 9. ブール型の本質的な問題

• データとロジックの混同: ブール型はロジックには適しているが、データには通常別の何かが隠れている
• 密結合の問題: データとしてブール型を保存することで、そのデータをアプリケーションロジックに密に結合させている
• 根本的な問いかけ: ブール型が依存するデータは何か、代わりにそれを保存すべきではないか

■ 10. 設計原則とまとめ

• 絶対的なルールの不在: すべてのブール型を削除すべきではなく、常に真であるソフトウェア設計の単一ルールはおそらく存在しない
• 批判的思考の重要性: ブール型にもっと注意を払うべき
• 実践による習得: 批判的な姿勢と根本的なデータへの問いかけは実践で容易になる
• 長期的利益: 前もって少し考えることで、長期的には多くの時間を節約できる

(2025/10/12)

Examples are the best documentation

• Examples are the best documentation | exotext

要約:

■ 1. 公式ドキュメントにおける例の不足

• 例の必要性: ドキュメントを検索する際、95%の場合は単一の例で十分であるが、95%の場合は公式ソースで例を見つけることができない
• ターゲット層の問題: デフォルトで正式な技術ドキュメントはそのエコシステムに深く没頭している人をターゲットにしているように見える
• 開発者の現実: 多くの開発者は日々頭の中で多くの「世界」をやりくりしなければならず、プロジェクト、言語、フレームワーク間を移動する際にコンテキストを復元し何が起こっているのかを理解するためにかなりの精神的エネルギーを必要とする

■ 2. Python 3ドキュメントの例

• 複雑な説明: Python 3のドキュメントでmax関数の説明として「max(iterable, /, *, key=None) Return the largest item in an iterable or the largest of two or more arguments」と5つの短い段落が続く
• 必要な前提知識: これを理解するためには関数定義における*の意味、/の意味、位置のみのパラメータセパレータとは何か、イテラブルとは何か、キーワード専用引数とは何か、keyが通常何を意味するかなど、Pythonについてかなり知っている必要がある
• テキストの読解: どのような値を渡すことができ、実際に関数をどのように呼び出すかを理解するためにテキストを読む必要がある
• 詳細の重要性: これらは簡潔さのために省略できない重要な詳細である

■ 3. 効果的な例の提示

• 実用的なケース: 多くの開発者がそのページを見たのは単にカスタムソート関数を渡す方法を素早く見つける必要があったからである
• 具体的な例: 以下のような例が迅速に役立つ
• max(4, 6)は6を返す
• max([1, 2, 3])は3を返す
• max(['x', 'y', 'abc'], key=len)は'abc'を返す
• max([])はValueErrorを発生させる
• max([], default=5)は5を返す
• シンプルさ: このような例は理解しやすい

■ 4. ClojureDocsの成功例

• コミュニティベースのプロジェクト: Clojure界で人気のあるコミュニティベースのプロジェクトがclojuredocs.orgで、人々が組み込み関数の例を投稿するサイトである
• 実用性: 日常のコーディングにおいて素晴らしく不可欠であり、into、spit、mapなどのページが良い例である
• 関連機能の包含: 例にはしばしば関連する関数が含まれており、質問されている関数だけでなく実世界での有用性と実用性を高めている

■ 5. ドキュメンテーションの課題

• 4種類の区別の欠如: 主要なソフトウェアプロジェクトでさえ4種類の異なるドキュメンテーションを提供することはまれである
• クリックへの躊躇: 「Documentation」リンクをクリックすることに躊躇することが多く、それは簡潔で読みにくく自動生成されたAPIリファレンスである可能性が高い
• チュートリアルの選択: ウォークスルーが必要だからではなく例が必要だからという理由でチュートリアルを探すことを選ぶことが多い

(2025/10/12)

ソースコードを整理して開発を高速化する

• ソースコードを整理して開発を高速化する | DevelopersIO

要約:

■ 1. 基本方針

• 極力単機能になるまで分解する: コードを小さな意味のある機能に分離することを重視
• 単純な機能を組み合わせ複雑な機能を作成する: 分解した機能を組み合わせて全体を構築

■ 2. コード開発における時間配分の実態

• 読む時間の方が長い: キーボードでコードを書く時間よりも読む時間の方が長くなりがち
• 読むシーン:
  • 自分が書いたコードの確認
  • 他の人が書いたコードのレビュー
  • 不具合発生時の調査
  • 改修時のあたりをつける作業
• AI使用による変化: AIを使うようになってこの傾向はさらに強くなっている

■ 3. テストと動作確認に要する時間

• 動作保証までの時間: コードを書く時間よりも動作保証できるようになるまでの時間の方が長くなることがしばしばある
• 動作保証の作業:
  • 自動テストの作成
  • 手動でのUI操作
  • curlを使ったAPI動作確認

■ 4. 開発効率向上のための重視点

• 小さい意味のある機能に分離する: 理解しやすく管理しやすいコードにする
• 動作保証されてるコードの塊を作る: 再利用可能で信頼性の高いコンポーネントを構築

■ 5. ワーキングメモリーの制約

• 短期記憶の限界: 人のワーキングメモリーで記憶しておけるのは3〜5個程度
• コンテキスト増加の問題:
  • 覚えておかないといけないコンテキストが増えるとワーキングメモリから溢れる
  • 読み直しが発生する
  • 間違った情報で補完してしまう
• ソースコードへの影響: 複雑な処理がフラットに書かれていると、コンテキストとして読んだコードを覚えておく必要が出てくる

■ 6. API処理の例（改善前）

• 処理内容:
  • 別サービスのAPIからデータを取得（キャッシュがあればキャッシュから取得、有効期限の管理を含む）
  • ユーザーのステータスが退会済みであればエラーにする
  • ユーザーの購入情報を取得（同様にキャッシュ処理を行う）
  • 上記データを加工してAPIのレスポンスとして返す
• 問題点: 一つの処理として書くと処理が複雑になり、読み解くのに時間がかかる

■ 7. サブルーチンへの分解（改善後）

• fetchUserIfNeeded関数: キャッシュ確認とユーザーデータ取得を担当
• fetchPurchases関数: 購入データの取得を担当
• validateUserStatus関数: ユーザーステータスの検証を担当
• getUserHandler関数: 全体の流れを俯瞰できるメインルーチン
• 効果:
  • 各サブルーチンは短い処理で機能を把握しやすい
  • メインルーチンは全体の流れを俯瞰できる
  • 関数名が処理内容を表すため、人が読んでも理解しやすくAIのコンテキストも減らせる

■ 8. 共通化の必要性

• キャッシュ機構の共通化: キャッシュ処理は共通化できる
• 呼び出し側の関心（期待）:
  • キャッシュがあればキャッシュからデータを返却する
  • キャッシュがなければfetchしてDBにキャッシュする
  • 有効期限が切れればキャッシュを更新する
• 再利用性: これらの関心は他のfetch処理でも同様に存在する

■ 9. withCache関数の実装

• 汎用的なキャッシュ関数: ジェネリック型を使用した汎用的なキャッシュ機能の実装
• パラメータ:
  • db: データベース接続
  • key: キャッシュキー
  • fetcher: データ取得関数
  • ttl: キャッシュ有効期間（デフォルト1時間）
• 処理フロー:
  • キャッシュチェック
  • 有効期限内ならキャッシュを返却
  • 期限切れなら削除
  • 新規取得してキャッシュに保存

■ 10. 共通化後のコード

• fetchUserIfNeeded関数の簡略化: withCache関数を使用してキャッシュ処理を委譲
• 可読性の向上: 元々のソースから必要な情報を読み取りやすくなった
• コードの整理: 各関数の役割が明確になり、全体の構造が把握しやすい

■ 11. テストの効率化

• 単体テストの作成: キャッシュ処理単体で自動テストを作成できる
• テストケースの明確化: 呼び出し側の関心をそのままテストケースにできる
• テストの再利用性: 新しいケースで関数を再利用する際、キャッシュの有効期限処理等はこの関数の単体テストで保証され、新しくテストを追加する必要がない

■ 12. 開発高速化の効果

• 動作保証されたコードの塊: いくつも作ることでテストに使う時間を減らせる
• 開発時間の削減: 結果として開発の高速化につながる
• 積み重ねの重要性: 派手な効果（N倍の効率化）ではないが、こういった積み重ねで開発を高速化する

■ 13. まとめ

• テーマ: 開発の高速化を実現するために日頃心掛けていること
• アプローチ: 小さな改善の積み重ねによる持続的な開発効率向上
• 目的: この記事が誰かの役に立つことを期待

(2025/10/12)

AIツールでどこまでデザインを忠実に実装できるのか

• AIツールでどこまでデザインを忠実に実装できるのか - Speaker Deck

(2025/10/12)

VALORANT's 128-Tick Servers

• VALORANT's 128-Tick Servers | Riot Games Technology

要約:

■ 1. VALORANTの128tickサーバー実現の背景

• 厳格な要件: 開発初期からVALORANTには非常に厳格なサーバーパフォーマンス要件があった
• 初期状態と目標: 開始時はサーバーフレームが50msかかっていたが、最終的にフレームあたり2ms未満を達成した
• 最適化手法: コード最適化、ハードウェアの調整、OS チューニングを組み合わせて目標を達成した
• ピーカーズアドバンテージ: すべてのオンラインシューターにはピーカーズアドバンテージが存在し、VALORANTでは戦略的ポジションの維持が重要なゲームプレイ要素である
• レイテンシの構成: レイテンシはネットワークとサーバーのtickレートに部分的に基づいており、ディフェンダーが反応する時間を確保するため128tickサーバーが必要と判断した

■ 2. CPU リソースの制約と目標設定

• 基本制約: 128tickレートでサーバーをホストする際の最大の制約はCPUリソースである
• フレーム処理時間: 7.8125ms以内に1フレーム全体を処理する必要があるが、そのままでは1ゲームが1つのCPUコア全体を占有してしまう
• コスト削減の必要性: 128tickを無料で提供したいため、コアあたり3ゲーム(gpc)以上の効率が必要だった
• スケールの規模: 36コアのホストを一般的に使用し、各物理ゲームサーバーは108ゲームまたは1080プレイヤーをホストする必要があった
• 最終目標: オーバーヘッド10%を考慮すると、フレームあたりわずか2.34msという目標予算となった

■ 3. 問題の分解とテレメトリーシステム

• アプローチ: 「サーバーを20倍高速化する」という大きな問題を小さな解決可能な問題に分解した
• カテゴリー分類: replication、FoW、network、animation、gameplay、movement、equippable、character、physics、otherの10カテゴリーに分類した
• ValSubsystemTelemetry: プログラマーが簡単にゲームコードをマークアップして適切に分類できるシステムを構築した
• マクロシステム: 実行されるすべてのコード行がマクロシステムを使用して上記のバケットの1つにスコープされる
• サブシステム概念: より大きなシステムの詳細な分析のためにサブシステムの概念を追加した

■ 4. Analytics Platformの活用

• Riotの技術活用: Riotの中央チームが開発したAnalytics Platformを活用してデータをビッグデータウェアハウスに公開し視覚化を構築した
• 視覚化の種類: ラウンドごとの平均サーバーフレーム時間、各VALサブシステムの平均処理時間などを視覚化した
• 早期発見: このようなデータがなければ、パフォーマンスの低いコードやコンテンツの変更が検出されずにゲームに入り込む可能性がある
• 問題特定の効率化: 変更番号間でレプリケーションが長くなった問題など、より小さな変更セットを調べて迅速にエンジニアを割り当てることができる

■ 5. サブシステムごとのパフォーマンス予算

• 予算設定: 視覚化が設定されたことで各サブシステムに予算を設定し不一致をフォローアップできるようになった
• 専門家による判断: VALORANTの技術リードが集まり、各システムの妥当な予算について議論した
• 最適化機会の評価: 予算は当時のシステムの状態と専門家による最適化の機会に基づいて決定された
• 並行作業: 各チームと専門家が目標を念頭に置き、並行してパフォーマンスを出荷可能な状態にすることができた

■ 6. Replicationシステムの最適化

• システムの役割: Property Replicationはサーバーとクライアント間の状態のネットワーク同期を可能にするUnreal Engine 4のシステムである
• パフォーマンスの問題: 変数を「replicated」としてマークするだけで自動的に同期されるが、メモリ全体でランダムアクセスが発生しキャッシュ集約的で遅い処理となる
• ポーリングの問題: 状態変更に関係なく変数がチェックされるポーリングシステムはパフォーマンスのアンチパターンである
• RPCによる解決: Remote Procedure Calls(RPC)を利用することで状態変更イベント時のみパフォーマンスコストが発生する「プッシュ」モデルを実現した
• 劇的な改善: replicatedな変数からRPCへの変更により、多くの場合100倍から10000倍のパフォーマンス改善が得られた

■ 7. Animationシステムの最適化

• サーバー側のコスト: ショットが当たったかどうかを適切に判断するため、サーバー側でもクライアントと同じアニメーションを実行する必要があった
• ヒット判定の仕組み: 履歴バッファーにプレイヤーの位置とアニメーション状態を保存し、ショットパケット受信時に巻き戻して計算する
• フレーム間隔の調整: 当初は毎フレームアニメーションを計算していたが、4フレームごとにアニメーションを実行し、巻き戻し時には保存されたアニメーション間を補間することで75%のコスト削減を実現した
• バイフェーズの最適化: バイフェーズ中はプレイヤーが安全にスポーンバリアの後ろにいるため、サーバー側のアニメーションを完全にオフにすることでラウンド全体のアニメーションシステムコストをさらに33%削減した

■ 8. 負荷テストとCPUアーキテクチャ

• 負荷テストの必要性: 実世界でゲームがどのように機能するかを適切にテストするため、100以上のインスタンスが同じCPU上で実行される負荷テストを構築した
• パフォーマンスの劣化: 単一インスタンス実行時は1.5msだったが、168インスタンス実行時には5.7msまで上昇した
• キャッシュの競合: 各コアには独自のL1/L2キャッシュがあるが、より大きなL3キャッシュはコア間で共有されるため、インスタンスが増えるとキャッシュの競合が発生する
• Intelとの協力: Intel Xeon E5プロセッサーからIntel Xeon Scalableプロセッサーへの移行により、非包括的キャッシュを採用し約30%のパフォーマンス向上を実現した

■ 9. NUMAとOSスケジューラの最適化

• NUMA アーキテクチャ: デュアルソケットCPUでは各ソケットがシステムRAMの一部に直接アクセスし、インターコネクトを通じてデータを共有する
• numactl の活用: Linuxのnumactlを使用してゲームサーバーインスタンスをノード間で交互に起動することで、約5%のパフォーマンス向上を実現した
• メモリアクセスの改善: メモリアクセスを約50%のNUMAローカルから97-99%のNUMAローカルに向上させた
• スケジューラの調査: コアが90-96%の使用率で推移し100%に達しない問題をLinuxのCompletely Fair Scheduler(CFS)が原因と特定した
• マイグレーションコスト: デフォルト値0.5msをゼロに下げることで、スケジューラーがゲームサーバーを利用可能なコアに即座にマイグレートするようになり4%のパフォーマンス向上を実現した

■ 10. C-Statesとハイパースレッディング

• C-State の制御: プロセスを高いC-State(C0、C1、C1E)に制限することで、さらに1-3%のゲームを安定してホストできるようになった
• 電力状態の影響: 負荷が減少すると多くのコアが頻繁にアイドル状態になり、電力状態のスワップがパフォーマンスに悪影響を与えていた
• ハイパースレッディングの検証: 開発初期は25msのフレーム時間でハイパースレッディングをオフにすると20msになり25%向上したが、最適化後は逆にオンにすることで25%向上した
• 変化する最適解: フレーム時間を7.8125ms以下に削減し、Intel Xeon Scalableプロセッサーへの移行、スケジューラーの調整、C-Stateの無効化などにより最適な設定が変化した
• 測定の重要性: 各アプリケーションのパフォーマンスプロファイルと考慮事項は異なり、再現可能なテストを作成して測定することが唯一の確実な方法である

■ 11. その他の最適化と本番環境固有の問題

• Clocksource の最適化: XenクロックソースからCPU命令rdtstを使用するtscクロックソースに変更することで1-3%のパフォーマンス向上を実現した
• Mesos とTelegraf の問題: 本番環境のみで発生する問題として、Mesosが使用するTelegrafのメトリクスが5秒ごとに72個のプロセスを起動しゲームサーバーをコアから追い出していた
• Erlang スケジューラの設定: Erlangのスケジューラースレッド数をデフォルトの72(コアごとに1つ)から4に設定することで問題が解消した
• 本番環境での測定: 本番環境に一致する構成でパフォーマンスを測定することが極めて重要である

■ 12. 結論と成果

• 全体目標の維持: 技術的な細部に迷わず、念頭に置いている全体的なパフォーマンス目標を継続的に再検討し強化する必要がある
• チームの調整: 適切なタイミングで適切な支援を得られるよう、チーム全体を目標に向けて調整することが重要である
• 環境の最適化: コード最適化は大きな部分を占めるが、ハードウェアとOSの環境も最適化する必要がある
• 測定の徹底: VALORANTの測定により、サーバーハードウェアのニーズを1%以内で予測しながらローンチすることができた
• 最終成果: スムーズなローンチ体験とプレイヤーへの無料128tickサーバーの提供を実現した

(2025/10/11)

「ぷまソフト」問題に見る法令遵守と技術者倫理の課題

• 「ぷまソフト」問題に見る法令遵守と技術者倫理の課題 | Frosted Glass

(2025/10/10)

AI新興オルツ元社長ら4人逮捕、売上高の8割超を粉飾か　東京地検

• AI新興オルツ元社長ら4人逮捕、売上高の8割超を粉飾か　東京地検 - 日本経済新聞

人工知能（AI）開発のオルツ=8月に上場廃止=の不正会計問題で、東京地検特捜部は9日、決算を粉飾した疑いがあるとして、同社元社長の米倉千貴容疑者（48）や前社長の日置友輔容疑者（34）ら4人を金融商品取引法違反（有価証券報告書の虚偽記載など）容疑で逮捕した。

架空計上した売上高は2022年12月期〜24年12月期の3年間で総額約111億700万円にのぼるという。開示した売上高の8割超が粉飾だったとみられる。

特捜部はオルツの旧経営陣が売り上げを過大計上する循環取引を関係企業に持ちかけたとみている。証券取引等監視委員会と連携し不正の全容解明を進める。

ほかに逮捕されたのは、営業部門長の浅井勝也容疑者（46）と経理部門長の有泉隆行容疑者（52）。

特捜部によると、米倉元社長ら4人は共謀し、オルツの22年12月期〜24年6月中間期につき、計約84億円の架空売上高を計上した虚偽の有価証券届出書を24年9月に関東財務局に提出し、株式を募集した疑いがある。

また東証グロース市場に上場後の24年12月期の決算で、売上高が約10億9000万円だったにもかかわらず、約60億5700万円と偽った有価証券報告書を提出した疑いももたれている。

特捜部は4人の認否を明らかにしていない。オルツは「関係当局による捜査に全面的に協力する。このような事態に至ったことは誠に遺憾」とのコメントを出した。

オルツは24年10月に新規上場したが、25年4月に売上高の過大計上に関する疑惑を公表した。第三者委員会の調査報告書によると、同社は架空売買で資金のみが動く循環取引をして売り上げを水増ししていた。

広告宣伝費として広告代理店4社に計約138億円、研究開発費として2社に計約16億円を支出。その後、広告代理店を経由してサービスの販売委託先から架空の売上代金にあたる計約137億円を回収する循環取引をしたとされる。

オルツは25年7月30日付で東京地裁へ民事再生法の適用を申請し、8月6日に再生手続き開始の決定を受けた。

オルツの新規株式公開（IPO）時に会計監査は監査法人シドー、主幹事証券は大和証券が務めた。報告書はオルツ側がそれぞれに虚偽の説明や書類提出をしたとも指摘した。

14年設立のオルツはAIを活用して事業展開し、テレビ会議の発言を自動で記録する議事録作成サービス「AI GIJIROKU（AI議事録）」を主力としていた。同社は25年10月末でサービスを終了すると発表した。

金商法は公正な市場を守るため上場企業の開示資料への虚偽記載を禁じる。有価証券届出書や有価証券報告書の虚偽記載の罰則は10年以下の拘禁刑か1000万円以下の罰金、またはその両方と定める。7億円以下の罰金とする法人の両罰規定もある。

MEMO:

• あらあら

(2025/10/10)

階層構造を表現するデータ構造とリファクタリング 〜1年で10倍成長したプロダクトの変化と課題〜

• 階層構造を表現するデータ構造とリファクタリング 〜1年で10倍成長したプロダクトの変化と課題〜 - Speaker Deck

要約:

■ 1. 階層構造の基本と背景

• 階層構造の例: クラウドストレージサービスにおけるフォルダやレシピサイトにおける材料タグは階層構造を持ち、親ノード・子ノード・祖先ノード・子孫ノードの取得、子ノードの作成、ノードの移動、ノードとその全ての子孫ノードの削除などの機能が必要である
• プロダクトの成長: 開発当時は導入社数が100社とユーザー数が少なくパフォーマンスが問題になりにくく、プロダクト全体の機能が不十分で新機能を素早くリリースして機能を充実させたいという状況だったが、1年で導入社数が1,000社へと10倍成長し、プロダクト全体の機能も充実し、プロダクトを使い込んでいただけるお客様も増え、顧客体験がより重要視されるフェーズになった
• 課題の発生: 巨大な階層構造が作成されるケースが出てきたことにより大量のN+1問題が発生し、深い階層構造では1,000回ものクエリ実行が必要になる状況になった

■ 2. Adjacency List（隣接リスト）

• 基本構造: 各レコードが自身の親レコードへの参照を持っており、parent_idが親レコードへの参照となり、親ノードの取得や子ノードの取得は単純なWHERE句で実現できる
• メリット: 実装が容易で直感的なFolderモデルで実装でき、書き込み操作（子ノードを作成、ノードを移動）がSQL問い合わせ1回で容易に実行できる
• デメリット: 親子関係を超えた読み込み操作（祖先ノード取得、子孫ノード取得）が困難であり、SQL問い合わせを複数回行う必要があり、再帰処理により親が存在しなくなるまで繰り返すため、深い階層では大量のN+1問題が発生する
• 初期採用の理由: 開発当時のプロダクト状況では、導入社数が100社とユーザー数が少なくパフォーマンスが問題になりにくく、新機能を素早くリリースして機能を充実させたいという要件から、実装が容易なAdjacency Listでフォルダ階層化機能を実装した

■ 3. Closure Table（閉包テーブル）

• 基本構造: 階層構造における全ての経路を保持しているテーブルで、Adjacency Listへの関連を持ち、ancestor_idは祖先のid、descendant_idは子孫のid、depthは経路長を表し、祖先・子孫の関係によって経路を表現する
• メリット: 親子関係を超えた読み込み（祖先ノード取得、子孫ノード取得）がJOINを伴うSQL問い合わせ1回で容易に実行できる
• デメリット: ストレージコストがかかり、書き込み操作が困難で経路を正しい状態に維持する必要があり、実装が複雑である
• 書き込み操作の実装: ノード作成時はコールバックを実行し、親ノードが終点の経路を取得して自身が終点の経路を作成してバルクインサートし、ノード移動時は自身と子孫のノードを取得して自身と子孫の経路を削除してから自身と子孫の経路を作成する

■ 4. Recursive CTE（再帰CTE）

• 基本概念: SQLにおけるCTE（Common Table Expression）の一種でWITH句を使い、再帰的にクエリを実行でき、MySQL 8.0、PostgreSQL 8.4、SQLite 3.8.3などの主要なRDBMSでサポートされており、Rails 7.2.0からQueryMethods#with_recursiveが登場した
• 基本構造: 非再帰項（初回だけ実行される）と再帰項（繰り返し実行される）で構成され、1つ前の実行結果を参照し、新たなレコードが生じなくなるまで繰り返す
• Adjacency List + Recursive CTEのメリット: Adjacency Listからデータ構造を変える必要がなく問い合わせ方法が変わるのみで、親子関係を超えた読み込みをクエリ1回で取得でき、Adjacency Listのままなので書き込みが容易である
• デメリット: DB内で再帰処理を繰り返す必要があるため深い階層だと低速になる

■ 5. リファクタリング手法の選定と実験

• 比較検討: Closure Tableは読み込みが非常に高速だが書き込みが低速で閉包テーブルを追加する必要があり実装が複雑、Recursive CTEは読み込みが高速で書き込みも高速（追加操作なし）でデータ構造の変更なく実装が容易である
• フォルダ階層化機能の特性: 読み込みが多いワークロード（一度作成されたフォルダは継続的に閲覧される）であり、階層制限がないため、読み取りが高速なClosure Tableを選択した
• パフォーマンス実験: ActiveRecord上でトップレベルのノードから葉ノード探索処理の実行時間を計測し、深さ6（127ノード）ではAdjacency Listが38.050ms、Closure Tableが4.228ms、Recursive CTEが10.869msで、深さ13（16,383ノード）ではAdjacency Listが3749.056ms、Closure Tableが4.024ms、Recursive CTEが14.111msとなり、Adjacency Listと比較してClosure Tableでは大幅に高速化を達成した
• 実験結果の考察: Closure Tableは横ばいで、Recursive CTEは深くなるほど低速になり、深さ13ではAdjacency Listと比較してClosure Tableは約931倍高速化を達成した

■ 6. まとめと推奨手法

• 推奨手法の整理: 開発初期はAdjacency List、小規模の階層（100ノード）はAdjacency List + Recursive CTE、中規模の階層（1,000ノード）は読み込みが多い場合はClosure Tableで書き込みが多い場合はAdjacency List + Recursive CTE、大規模の階層（10,000ノード）は頻繁に書き込みがなければClosure Tableを推奨する
• 本発表の目的: ツリー構造（親を一つだけ持つ）のみを扱い、階層構造を表現する2つのデータ構造（Adjacency ListとClosure Table）を理解し、Recursive CTEの概要を理解し、階層化機能において適切な手法を選択ができるようになることを目指した

(2025/10/09)

Local Peer-to-Peer APIはどのように使われていくのか？

• Local Peer-to-Peer APIはどのように使われていくのか？ - Speaker Deck

要約:

■ 1. Local Peer-to-Peer APIの概要

• 基本定義: Local Peer-to-Peer API（以降LP2P）は、「サーバーを介さずに現代のセキュリティ要件を満たしつつ、Webにおけるローカル通信を安全に実現すること」を目標としており、P2Pはサーバーを経由せず端末同士で直接通信を行える技術である
• 策定状況: 提案と仕様策定はIntel社のメンバーが中心に行っており、W3C勧告プロセスの「作業草案（Working Draft）」相当でまだ利用できない状況である
• 技術的仕組み: Open Screen Network Protocol上にAPIを実装する方法について規定し、ピア間の相互TLS証明書を確立して証明書をトラストアンカーとして利用しピア同士のローカル通信を行う
• 主要機能: ローカルデバイス間通信でHTTPSを使えるように（Local HTTPS）し、WebTransportやDataChannel等を用いた安全な相互通信を実現する

■ 2. 期待されるユースケース

• クロスデバイス間の通信: PCで開いたFigmaやGoogle Drive等でスマホのファイルを開く、インターネットを経由せずに様々なデバイス間でファイルを共有、近くにあるNASやIoT機器の制御をコンパニオンアプリ無しで実現でき、他デバイスへの「プル」ができる
• 人道支援活動: インターネットが使えない現場でも情報共有やコミュニケーションを可能にし、予め大きなファイルを1ユーザが取得し現地で各ユーザが取得でき、例えばローカルHTTPSで機能するPWAアプリを現地配信可能になる
• PWAの可能性: PWAとの組み合わせが実現すると強力になる可能性があり、P2Pが発展するとeCDNのようなUXの良い仕組みが実現しやすくなる

■ 3. 類似技術との差別化

• クラウド技術との違い: HTTP、WebSocket、WebTransport等はインターネット経由でありサービス依存である
• WebRTCとの違い: WebRTCはピア同士を繋ぐためのシグナリングが必要であり原則サーバーが必要である
• Web Share APIとの違い: Web Share APIはプッシュベースのみ対応しており、ピア上のデータをプルできない

■ 4. 現在の状況と今後

• 標準化プロセス: Web標準化までのプロセスはW3C勧告プロセスを完了させる必要があり、作業草案（Working Draft）、勧告候補（Candidate Recommendation）、勧告案（Proposed Recommendation）、W3C勧告（Recommendation）という手順を経る
• 現在の進捗: 2025年5月時点で作業草案（Draft Community Group Report）の段階であり、提案からおよそ2年ほど経過し現在も仕様策定に関する議論がIssueで行われている
• 周辺技術の議論: LP2P APIと並行し、Local HTTPSの仕様や問題点の解決方法についてW3Cが主催する技術者会議「TPAC2024」で提案・議論された

■ 5. まとめ

• 核心的価値: LP2Pはサーバーという最大の依存関係を廃止できる激アツな仕様かもしれず、ローカルデバイス間でデータをプル/プッシュできる
• 現状認識: 現在は作業草案の段階（Web標準化までの第1段階）であり、Local HTTPS等周辺技術も含めて仕様策定中である

(2025/10/09)

家を建てたら、会社が変わった。夫婦でLINEヤフーを辞めました。

• 家を建てたら、会社が変わった。夫婦でLINEヤフーを辞めました。｜カク

要約:

■ 1. リモートワーク前提の生活と家づくり

• オンライン移行の発表: 2020年7月、新型コロナウイルスが猛威を振るうなか、ヤフー株式会社が「オンラインに引っ越します」という新方針を発表し、社員は全国どこからでも働けるようになった
• 生活の変化: 数年後、LINEとの合併を経て社名も経営陣の顔ぶれも変わったが、リモートワーク中心の働き方は続いており、筆者夫婦もその生活にすっかり慣れていた
• マイホーム計画: 2024年某日、リモートワーク中心の働き方も4年目に突入し、「そろそろ家を買おうか」と話し、「仕事も暮らしも、どちらも大切にする」という思いで家づくりをスタートした
• 郊外への決断: 予算や実家との距離、街の雰囲気などを考えつつ、「週1回くらいの通勤なら、なんとかなるか」と思える程度の郊外に家を建てることにし、「この先コロナが終息しても、ずっとリモートワーク」だから安心だと考えていた

■ 2. 会社方針の転換

• フルリモート廃止の報道: その後、LINEヤフーがフルリモート廃止を発表し、事業部門は原則週1回、それ以外は月1回出社になり、社内ではすでに段階的な出社再開の方針が共有され週3出社の見通しも立っていた
• 青天の霹靂: すでに家を建て始めていた筆者夫婦にとって、リモートワーク前提で郊外に家を建てた途端に会社の方針が変わってしまったことは、まさに青天の霹靂だった
• 会社の判断理由: LINEヤフーは、合併から2年目を迎えさらに新しいプロダクトを生み出すためにはコミュニケーションの質を強化することが必要だと考え、対面でのコミュニケーションの良さを今まで以上に取り入れるために出社日を設けると説明した
• 現実認識: 会社が利益を出すためには方針転換もやむをえず、会社は社員にとって完全なセーフティネットではないという冷たい現実がある

■ 3. 決断と転職

• 唯一の選択肢: 念願のマイホームを建て始めていた筆者たちに、選択肢は一つしかなく、新卒入社から10年以上勤めた会社を辞める決断をした
• 葛藤: たくさんの経験をさせてもらい、キャリアを積み、かけがえのない仲間たちにも出会えたが、仕事と同じくらい今の暮らしも大切にしたいという思いがあった
• 新たな道: こうして筆者夫婦はそれぞれ、リモートワーク中心の会社へ転職したが、UIUXデザイナーとしての筆者の転職活動は難航した

(2025/10/09)

「React Foundation」をメタ、マイクロソフト、Vercelらが設立へ。ReactやReact Nativeの中立的...

• 「React Foundation」をメタ、マイクロソフト、Vercelらが設立へ。ReactやReact Nativeの中立的な開発主体として － Publickey

要約:

■ 1. React Foundationの設立

• 新組織の発表: 代表的なJavaScriptライブラリのひとつであるReactの開発チームが、ReactやReact Nativeなどの開発を主導する新たな独立組織「React Foundation」の設立を発表した
• 設立メンバー: 設立時の企業メンバーにはMeta、マイクロソフト、Vercel、Amazon Developerなどが名前を連ねている
• 新たな主体: 今回その新たな主体としてReact Foundationの設立が発表され、React、React Native、JSXの新たな開発主体となる

■ 2. Reactの背景

• 開発の経緯: Reactは、Webアプリケーションのユーザーインターフェイスを構築するためのJavaScriptライブラリとして、2013年にMeta（当時はFacebook）がオープンソースとして公開したソフトウェアである
• 技術的特徴: コンポーネントベースの設計や仮想DOMを用いた高速性などによる革新的なJavaScriptライブラリとして急速に普及した
• これまでの開発体制: 現在までReactや関連ソフトウェアはMetaが主導して開発してきた

■ 3. React Foundationの使命と活動

• 基本使命: 中立的な立場でReactコミュニティとエコシステムをサポートすることが使命となる
• 具体的な活動内容: Reactの商標およびGitHub、CIなどの開発インフラの維持、React Confイベントの主催、Reactエコシステムの支援プログラム作成と実行、財政的支援や助成金の拠出などエコシステムの支援を行う
• ガバナンス構造: 今後、Reactの開発において単一の企業や組織が過剰に代表されないようにするために、独立した技術的ガバナンス構造を作成する予定である

(2025/10/09)

RDBアンチパターンリファクタリング

• RDBアンチパターンリファクタリング - Speaker Deck

要約:

■ 1. データベースリファクタリングの重要性

• 基本認識: データベースの寿命はアプリケーションよりも長く、不適切なデータベースがコードやサービスの成長を止めるため、サービスの健康を保ち成長するためにはデータベースのリファクタリングが必要である
• データベース設計の特性: データベース設計は積み木のようにちゃんと検討された仕様追加を正しく積み上げていけるが、マジカルな設計をすると仕様変更が出来なくなり、次の仕様追加がどうにも出来ない状態になる
• 一度作ったデータベースは消せないため、定期的なメンテナンスは必須であり、問題は小さいうちに直さないとDBの肥大化と共に問題も大きくなる

■ 2. データベースの不吉な臭い

• RDBアンチパターン:データベースの迷宮、失われた事実、やりすぎたJOIN、効かないindex、フラグの闇などがあり、破綻した値（delete_flagが1、2、0、9、99、NULLなど複数存在する状態）などが典型例である
• 不吉な臭いの具体例: 複数の目的に使われるカラム（レコードの属性に合わせて値の意味が変わる）、複数の目的に使われるテーブル（テーブルバージョンなど）、冗長なデータ（非正規化の末のデータ整合性の破綻）、カラムの多すぎるテーブル（memo1、memo2、memo3など）、行の多すぎるテーブル、「スマート」カラム（論理IDなどデータの中の情報によって意味が変わる）、変更の恐怖（データベースの変更やデータの更新によってアプリケーションが壊れるのでは？となり手を付けれない状態）がある
• 技術的負債の判断: チーズなのか腐った牛乳なのか、本当に改修が必要かどうかを見極める必要があり、腐った牛乳はサービスの生死に関わるため継続的なデータベース・リファクタリングが必要である

■ 3. データベース・リファクタリングの分類

• 6つの分類:
  • 構造（テーブルやViewの定義）
  • データ品質（データの値）
  • 参照整合性（テーブルの関連性）
  • メソッド（ストアドプロシジャ）
  • 変更（テーブルやカラムの追加）
  • アーキテクチャ（アプリとのインターフェイス）
• システムの性質: シングルアプリケーション（1つのアプリケーションが1つのデータベースを扱う）の時はDBマイグレーションが活き、コードでDBを管理できる強さがあるが、マルチアプリケーション（複数のアプリケーションが1つのデータベースを扱う）の時は依存関係の多さが課題となる

■ 4. プロセスとリファクタリング戦略

• データベースの特徴: データは常に変化しており、影響範囲が広く、DBを止めることが難しいため、データベースリファクタリングはすごく長いスパンになる
• 戦うための準備:
  • 抽象化: 永続化フレームワークを導入する
  • モニタリング: 変化の影響をリアルタイムに知るためにモニタリングして状態を知る
  • 品質を担保する: 影響が広いからこそテストを書き、シナリオテストも大切で、関連するアプリケーションの全てが対象となる
  • 覚悟: サービス停止の壁を政治と技術の両方で解決する必要があり、レプリケーションなどを使って限りなく0に近づけるが完全に0には出来ないので政治力が問われる
• 実施の判断: 手間も時間もかかるため、リファクタリングの意味はあるか、作業に応じた効果はあるか、今やるべきか、を検討することが大事である
• 実施手順: 対象を選定し移行期間を決め、テストとモニタリングを揃え、リリース戦略を決める必要があり、複数のアプリケーションの変更が必要な場合に全てのアプリケーションが動く必要があり、同時にアプリケーションが更新できない場合もあるので移行期間が必要である
• 移行期間の設計: 移行中は前状態でも新状態でもアプリケーションは動く必要があり、DBの機能（例えばトリガー）をうまく活用して、旧アプリと新アプリの両方が動作するように設計する

■ 5. 現場での実践ポイント

• リファクタリング手法: DBマイグレーションツールを使う、DBの機能を利用する、手動でSQLを実行するという選択肢がある
• リファクタリングのコツ: 移行前に戻せること、移行中は過去の状態を保持すること（backupやレプリケーションを使う）、小さな変更を長いスパンで繰り返すこと（DBは影響範囲が広いので切り分けをしやすくすることが大事）、兎にも角にもテストとモニタリングが大事である
• 綺麗なリファクタリング: 参照と更新の読み込み先を分ける、更新のボトルネックを分ける、データ設計を見直す、適切にINDEXを活用する
• 闇の深いリファクタリング: JOINを非正規化で補う、外部キー制約を外す、とりあえずキャッシュに突っ込む、極度のスケールアップなどは避けるべきである
• コミュニティの活用: DBの機能をうまく活用し、postgresql-jp SlackやMySQL-casual Slackなどのデータベースコミュニティを積極的に利用する

■ 6. まとめ

• 継続的改善の必要性: データベースの死はサービスの死であり、解決できる人は英雄であるため、サービスやチームを守るためにそのために学ぶ必要がある
• 学習の重要性: 愚者は経験に学び、賢者は過去に学ぶため、周囲の経験談から学び積極的にコミュニティを利用し、RDBの知識は寿命が長く覚えれば仕事で長い間役に立つ
• 実行の重要性: 今日から改善するのはあなた自身であり、手を動かした人だけが世界を変える

(2025/10/09)

「全員QA」を30分ミーティングで強くする

• 「全員QA」を30分ミーティングで強くする - エムスリーテックブログ

要約:

■ 1. 背景と課題

• 全員QA活動: エムスリーではQAエンジニア以外も品質保証に取り組む体制を構築し、リリースの迅速化とQAエンジニアのアサインに柔軟性を持たせることを目指している
• 一般的な問題: エンジニア自身がテスト設計・実施を行うと実装の正確性や機能の「作り」に意識が集中し、他機能への影響やビジネス・運用の俯瞰的な観点が抜けやすい
• コンシューマーチームの課題: 一般的でないユースケースやエッジケースの考慮漏れがQAエンジニアのレビューで多数検出され、改修箇所以外の機能の考慮、古い機能の仕様の属人化、俯瞰的な観点の不足が明らかになった
• 既存対策の限界: ドキュメント整備やテンプレート作成では、メンテナンスコストの増加と能動的に探さないと参照されない問題があり、複数プロジェクトの掛け持ち状況では時間をかけた対応が困難だった

■ 2. 実施した取り組み

• リスク洗い出しミーティング: 実装が本格化する前に30分のミーティングを設定し、関係者を集めてリスクについてざっくばらんに話し合う場を設けた
• 議論の焦点:
  • 非機能要件、ビジネス面・運用面のリスクに集中
  • マインドマップを使用し、「絶対に必要なもの」「欠けてはいけないもの」「起きそうなトラブル」など事前に用意した見出しに沿って議論
  • 実装面ではなく業務フローやユーザの利用状況、運用開始後の問題について話し合った
• 成果の例: ユーザサポートの担当部署の打診の必要性、アプリリリース時の特殊な準備要件、定期的な大量アクセス発生への対応の必要性などを発見した

■ 3. 工夫と効果

• 多様な参加者: 様々な立場の関係者を出席させることで、多角的な視点からの考慮漏れの検出と暗黙の了解だった知見の共有を実現し、専門的な知識による深掘りも可能にした
• 議論の観点: 要件定義や設計、実装の担当の立場から漏れがちな観点を積極的に議論し、プロダクトの目標や使われ方について改めて話題に出すことで認識統一を図った
• 全体的な効果: 機能開発中に見過ごされがちなプロジェクト全体の視野を取り戻す機会を作り、対話を通じてチームの知見を引き出すことができ、それぞれの専門的な知見を活かしてチーム全体の視点からリスクを捉えることが可能になった

(2025/10/09)

Goで実践するドメイン駆動開発 AIと歩み始めた新規プロダクト開発の現在地

• Goで実践するドメイン駆動開発 AIと歩み始めた新規プロダクト開発の現在地 - Speaker Deck

要約:

■ 1. プロジェクト概要と技術選定

• チームのミッション: 新規プロダクトのAPIプラットフォームチームとして、変更容易性の高いAPIを作成し、素早い仮説検証サイクルを回せるものづくり体制を実現することを目指している
• 開発体制: PO、SM、開発者4名のスクラム体制で、複数のフロントチームと連携し、モノレポ構成で開発を進めている
• Go採用理由: 弊社のバックエンド推奨言語として、標準化（組織全体での技術統一）、省力化（開発効率の向上）、最新化（技術スタックの継続的な改善）の3つの基本方針に基づきGoを採用し、パフォーマンスと安定性が求められるバックエンドAPIでの豊富な採用実績がある

■ 2. ドメイン駆動設計の基礎概念

• DDDの定義: 事業領域を対象に、意図の伝達を円滑にし、事業戦略とソフトウェアの実装を結びつける設計手法であり、アジャイルとの相性が良く市場や戦略の変化に柔軟に適応できる
• 戦略的設計と戦術的設計: Why・WhatとHowの関係性を明確化し、事業目標達成のために事業活動を分析してドメインを細分化した業務領域（サブドメイン）を定義する
• 境界付けられたコンテキスト: ソフトウェア設計の視点から事業活動モデルを扱いやすい単位にするため、ドメインを分解したものである
• ドメインモデルと業務ロジック: 中核の業務領域を対象に複雑な業務ロジックを扱うための設計手法であり、業務領域におけるルールや前提条件、制約を値オブジェクト、集約、業務サービスで扱う

■ 3. Go × DDDの相性

• Goの言語特性: シンプルで明示的な言語仕様により暗黙的な魔法が少なく意図をコードにそのまま表現でき、後方互換性の高さと豊富な標準ライブラリによりドメインロジックの継続的な改善に集中できる
• 設計の自由度: フレームワークに縛られず、アーキテクチャを自分たちのドメインに合わせて構築でき、ドメインモデルのような単純なオブジェクト中心の設計と本質的に相性が良い
• 依存関係逆転の原則: Goのinterfaceは、ポートとアダプターの分離を自然に表現でき、実装ではなく抽象に依存する構造（依存の整合性）を型システム自体で保証できる

■ 4. ドメインモデルの実装

• 実装例: AIを使用してユーザーの悩み解決におすすめの書籍をピックアップする機能で、中核の業務領域は「Recommendation（レコメンド）」であり、「お気に入りリスト」「ユーザープロファイル」と連携する
• 主要コンポーネント: 不変性を持つドメインの値を表現する値オブジェクト、トランザクション境界を表現する集約（粒度が大きすぎるとパフォーマンス悪化、小さすぎると結果整合の制御が増え設計コストが高くなる）、ドメイン固有のロジックを実装する業務サービスで構成される
• 物理的な境界: 1BCに対しスキーマ群を設定し、1集約1リポジトリで永続化の単位は集約とし、BCに対してマイクロサービスを適用してモノレポでBCごとにモジュール化している
• 実践ポイント: フィールド非公開と慣習的なファクトリメソッドを使用し、スライスやマップを扱う場合は外部へ渡す前に必ずコピーするなど不変性を意識し、アプリケーションサービスは薄くして業務ロジックはドメイン層で実装する

■ 5. 開発課題と取り組み

• 理解促進の取り組み: ドメイン駆動設計の理解における課題に対し、プロジェクトの価値や目的を自分の言葉で再定義して所属チームレベルにブレイクダウンし、企画職の方と日次15分間理解を深める枠を設定した
• 学習活動: 「ドメイン駆動設計をはじめよう」をチーム全員で読み用語自体の勉強会を実施し、AWSワークショップと社内でのイベントストーミングを実施した
• AI活用: Claude Codeでの開発を実施し、構想中の取り組みとして速さを落とさず基盤的内容変更の共通認識を最短ループで回すことを目的に、CLAUDE.mdに人もAIも認識しておきたい内容を記載し、Claude Code Actionsを使用してPR作成時に「CLAUDE.mdのルール準拠チェック」「追記要否判定」を実施する計画がある

■ 6. まとめ

• 核心メッセージ: AIにより素早い仮説検証が可能となった今だからこそ、ドメインを基にした「本質的な設計」の重要性が高まっている
• Go × DDDの価値: 共通言語となるモデルによりチーム間のコミュニケーションが円滑化し、変更容易性の高いシステムで市場変化への迅速な対応が可能となり、後方互換性の高い言語仕様で長期的な保守性が確保され、設計の自由度によりドメインに最適化されたアーキテクチャの実現ができる

(2025/10/08)

DBリファクタリングにおける戦略と実践方法

• DBリファクタリングにおける戦略と実践方法 - そーだいなるらくがき帳

要約:

■ 1. データベースリファクタリングの必要性

• 肥大化の問題: サービスの成長に伴いデータベースが肥大化し、パフォーマンス低下やメンテナンスが困難になる
• 予見の限界: 最初から設計を工夫しても、サービスの成長に伴う要件変化をすべて予見することは難しい
• AI時代の加速: AIを利用したソフトウェア開発が主流になりつつある昨今、データベースの成長速度はさらに加速している
• 変わらぬ重要性: AI時代でもデータベースリファクタリングは必要不可欠なスキルである

■ 2. リファクタリングの基本戦略

• 4つのステップ:
  • あるべき姿を定義する
  • リファクタリングの方針を決める
  • 安全にリファクタリングを行うための仕組みを準備する
  • リファクタリングを実施する
• あるべき姿の定義: リファクタリングの目的を明確にし、どんな効果を得たいのかを整理してゴールから逆算してステップを決める
• 優先順位の重要性: 全てを同時にリファクタリングするビッグバンリリースは避け、腐った牛乳とチーズの例のように優先順位をつけて小さく進める

■ 3. リファクタリングの方針策定

• 段階的アプローチ: データベースリファクタリングはリスクが高いため、一足飛びではなく段階的に進めるステップを決める
• 削除フラグ廃止の具体例:
  • deleted_userテーブルとactive_userテーブルを作成する
  • userテーブルにINSERTする際に、active_userテーブルにも書き込む
  • delete_flag=trueに更新する際に、deleted_userテーブルに書き込み、active_userから対象を削除する
  • userテーブルから、delete_flag = falseのデータをactive_userテーブルにコピーする
  • userテーブルから、delete_flag = trueのデータをdeleted_userテーブルにコピーする
  • active_userテーブルとdeleted_userテーブルをUNIONし、view_userテーブルを作成する
  • userテーブルへの参照をview_userテーブルに切り替える
  • userテーブルの追加・更新処理をなくす
  • userテーブルをDROPする
• 達成条件の設定: 次のステップに進むための達成条件やロールバックする場合の条件を決め、失敗時の影響を最小化する
• スケジュールと根回し: 大まかなスケジュールを作成し、マルチアプリケーションの場合は各チームに根回しを行いリソースをアサインしてもらう

■ 4. 安全な仕組みの準備

• 3つの重要な仕組み:
  • 自動テスト
  • オブザーバビリティの強化
  • データの整合性チェックの自動化
• 自動テスト: E2Eテストや単体テストを自動化し、CI/CDで自動実行することで意図しない振る舞いやバグを早期に発見する
• オブザーバビリティ: モニタリングツール、ログ収集ツール、APMツールを活用し、OpenTelemetryなどの分散トレーシングでテーブルの利用状況を把握する
• データ整合性チェック: リリース時だけでなく10分に一回など定期的にバッチで実行し、エッジケースでの不整合を早期発見する

■ 5. ダブルライトの実装アプローチ

• 3つの主要アプローチ:
  • データベースを利用した実装
  • アプリケーションでの実装
  • ミドルウェアを活用した実装
• トリガーの利用: データベースの機能でアプリケーション側の変更を最小化できるが、運用コストが上がるため期間限定のつなぎとして利用する
• 生成列の活用: first_nameとlast_nameを連結してfull_nameを自動生成するなど、計算後の列を自動的に設定する方法である
• アプリケーション優位: アプリケーション側はデータベースより変化に強く、ロールバックが容易でテストもしやすいため推奨される

■ 6. アプリケーション側の実装方法

• 関数でラップ: データベースアクセス関数をラップしてダブルライトのロジックを実装する最もシンプルでわかりやすい方法である
• セーブポイントの活用:
  • userテーブルの書き込み成功後にセーブポイントを設定する
  • active_userテーブルへの書き込みが失敗してもサービスを継続できるようにする
  • 失敗をログに残すことで検知できるようにする
• シャドウページング:
  • 古いuserテーブルとview_userテーブルの両方を参照し比較する
  • 不整合があればログに残すことで早期検知する
  • 今まで通りuserテーブルのデータを返してサービスを継続する
• フレームワーク利用: ORMのイベントリスナーやTraitで一気にダブルライトを実装できるが、暗黙的な振る舞いになりテストが難しくなる

■ 7. ミドルウェアを活用した方法

• CDCの活用:
  • AWS DMSやDebeziumなどのツールでデータベースの変更を検知し、別のシステムに伝搬する
  • リファクタリング前後のDBを分離でき、データの安全性を確保できる
  • コンポーネントが増える分、監視対象も増え運用コストが増加する
  • CDC自体が単一障害点になることが多く、厳しいSLAを求められる場合は注意が必要である
  • リファクタリング完遂後は必ずCDCを廃止し、新たな技術的負債にしない
• 非同期書き込み:
  • メッセージキューを利用して、userテーブルにINSERTした後にキューに書き込む
  • 別のワーカーでactive_userテーブルにINSERTする
  • CDCと違い単一障害点になりにくく、データの前加工も柔軟に実装できる
  • CQRSパターンや参照整合性が緩い場合に有効である
  • データの整合性チェックは必須であり、遅延や失敗時の対応も検討が必要である

■ 8. まとめ

• 戦略的な準備: 今回紹介した方法を組み合わせて継続的にデータベースリファクタリングを進めることで、効果的に負債を解消できる
• 事業成長の鍵: クラウドネイティブなアーキテクチャやAIの発達でデータベースの肥大化が加速しているからこそ、継続的なリファクタリングが重要である
• 最も重要なこと: データベースリファクタリングは影響範囲も広く時間がかかるため、一番必要なのはやり切るという覚悟である

(2025/10/08)

割とマジで発達障害がITに向いてるって誰が言いだしたんだ？

• 割とマジで発達障害がITに向いてるって誰が言いだしたんだ？

https://anond.hatelabo.jp/20251004160446

この「コミュニケーション能力や国語の読み書き能力が重要だ」と言われた、という様な増田の記事がバズっているけど、それを読んでいる中でふと疑問に感じたことがあった。

発達障害はITに向いているという「定説」がもうここ10年ですっかり当たり前になっているけど、実際に現場？で言われてることは真逆の意見であることが、Xの反応を見ても思った。

なので、日曜日くらいにざっと調べてみてまとめたものを、書いてみたいと思う。

■ 最古のソースは2001年のサンフランシスコ・Wired誌の記事かららしい

Wired誌の2001年9月12日　「 The Geek Syndrome」という記事が初出、とのこと

当時この雑誌に記者だった「スティーヴ・シルバーマン氏」が「最近シリコンバレーで働いているIT系のパワーカップルの間で自閉症児が増えている」という内容

この記事の中では、「向いているかもしれない」という、当人自身も科学的根拠はないと前置きしたうえで、観測した結果として推測している。

アメリカのIT業界では、これを基にして発達障害＝IT向きという様な話が広まっていった経緯があるとのこと。

■ 次によく引用されるソースは2002年のアメリカの心理学者の論文かららしい

米の心理学者S Baron-Cohen博士による「The extreme male brain theory of autism(2002)」という論文から

この論文の内容は、自閉症(発達障害)の脳の認知理論を科学的に研究したもので、別に発達障害がITに向いているという様な内容は一文も存在していなかった

「コンピューターに近い処理の様な思考回路をしている」という様な示唆はあったが。

そこから一種の神話として「発達障害＝ITに強い」、とかプログラミング言語に強いといった様な「神話」が流布されていったらしい。

とうのアメリカでは、あくまで経験則というか一種のブラックジョークとしてテック業界で言われているニュアンスに近い、という事を調べていってわかった。

■ 日本に浸透したのは2010年代から

さて、日本で発達障害＝IT向きというのが流布され始めたのは2010年代から、当時の書籍の年代を絞り、キーワード検索をすれば、

色んなNHKの番組特集、もしくは教育・啓蒙・ビジネス書が出てくる(あまりに多いので具体例を挙げると文章が長くなるので、上記で調べれば幾らでも出るのであえて割愛する)

どれも科学的根拠は、上で上げたアメリカの論文だとか、雑誌記事の孫引きであることがほとんどだった。

これを見ればわかる様に、科学的根拠はない経験則の様なものらしい。

ではなぜ、あの頃webベンチャーバブル時代、プログラミング言語に特性がある発達障害をあえて雇う、という様な風潮が多かったのだろうか？

調べてみると、「就労支援金」の話が出てきた。

2010年「発達障害者雇用開発助成金の緩和について」

https://www.mhlw.go.jp/content/12600000/001042644.pdf

これによると、当時発達障害を雇えば一人当たり135万円の助成金が出たらしい。

ひょっとしてひょっとするとだけど、発達障害がITに向いているといって取ったのは、助成金欲しさになのではなかろうか？

もはや15年も昔の話だから、当時のベンチャー経営者なんてほとんど残っていないだろうから、今となっては知るすべがない

で、調べてみて思ったんだけど、発達障害がITに強いって科学的根拠、ないんだよね…

(2025/10/08)

I Don’t Want to Be a Programmer Anymore: When AI Confidence Outshines Human Judgment

• I Don’t Want to Be a Programmer Anymore: When AI Confidence Outshines Human Judgment

要約:

■ 1. AIが権威を奪った瞬間

• 妻との議論での敗北: ドメイン名に関する夫婦の議論で、AIに判断を委ねた結果、AIが妻の意見を支持し、筆者は即座に自分が間違っていたと確信した
• 妻の違和感: 妻は勝利したものの、夫が彼女の理由ではなくアルゴリズムの判断に説得されたことに不安を感じた
• 本質的な問題: AIが仕事を奪うのではなく、人間の判断力と権威を奪っていることが真の危機である

■ 2. 誰もがプログラマーになった時代

• クライアントからの提案: 非エンジニアのクライアントが、AIを使って詳細なフローチャート付きの改善提案を送ってくるようになった
• 日常化する現象: AI支援による提案が1日に複数回届くようになり、それぞれにコスト、トレードオフ、リソースの説明が必要になった
• 説明責任の増加: 提案自体は悪くないが、説得力のあるAIの助言と戦う専門家としての負担が増大している

■ 3. 筆者自身のAI依存

• 日常的な使用: 50通以上のメールへの多言語返信、コーディングの反復作業、リサーチ、旅行計画、料理レシピなど、あらゆる場面でAIを活用している
• 利便性の認識: AIは時間を節約し、すべてを知り、あらゆる言語を話し、無限の忍耐力を持つ疲れ知らずの同僚のような存在である
• 偽善の自覚: 他者のAI依存を批判できない立場にあることを認めている

■ 4. 権威の問題

• 説得力の本質: AIが妻の味方をした際、正誤ではなく、いかに説得力があるかが重要だった
• 確信を与える力: AIは人々にアイデアではなく自信を与え、各回答に必然性の権威を刻印する
• マルクス・アウレリウスの教え: 外部の出来事ではなく自分の心を支配すべきだが、人々はその力の一部をAIに外注し始めている

■ 5. 自信の心理学

• 権威バイアス: 自信に満ちた声を真実として扱う本能的傾向があり、AIはこのバイアスを完璧に利用する
• AIの特性: AIは決して躊躇せず、疑わず、「わからない」と言わず、確信のリズムで語る
• 危険性: 悪い答えだけでなく、自信、統計、参照で装飾された良さそうな答えが、質問することを忘れさせる

■ 6. 岐路に立つ専門家たち

• 普遍的な課題: プログラマーだけでなく、医師、教師、弁護士、マネージャーなど、専門知識に依存していたすべての職業が同じ変化に直面している
• 仕事の変質: 仕事は説得、交渉、そしてAIが3秒で出す確信に満ちた答えが、実際には3か月、3人、3倍の予算を要する理由を説明する作業になった
• 知識の価値転換: 知識も権威も希少ではなくなり、唯一の通貨は知恵、すなわち疑いと判断の遅く忍耐強い作業である

■ 7. 次世代への懸念

• 知恵の獲得方法: 知恵は常に経験の副産物として得られてきたが、経験自体が機械に外注されれば、若い世代はどこで知恵を得るのか
• アイロニー: 知恵がなければ、患者の治療、契約の解釈、教室の運営など、あらゆる確信に満ちた答えを信じてしまう
• キャリアの本質: 現在、どの職業でも最も困難なのは技術そのものではなく、その技術がまだ重要であることを説得することである

■ 8. 教訓と今後の姿勢

• 慎重な利用: 旅行計画やカメラ選びはAIに任せても、ドメイン名や配偶者との議論には使わないと決めた
• 判断力の保持: セネカの警告を思い出し、どこに向かっているか知らなければどんな風も有利にはならないと認識している
• 人間性の保持: 完璧な答えの世界で最も人間らしいことは、不完全な質問をするほど好奇心を持ち続けることである

(2025/10/07)

Linus、Rustのフォーマットチェックを「無神経でクレイジー」と酷評

• Linus、Rustのフォーマットチェックを「無神経でクレイジー」と酷評 | gihyo.jp

10月12日に予定されている「Linux 6.18」のマージウィンドウ終了と最初のリリース候補版（Linux 6.18-rc1）の公開に向け、プルリクエストのチェックに大忙しのLinusだが、マージウィンドウ期間中はプルリクエストに対するLinusの手厳しい批判が増える時期でもある。10月1日、LinuxグラフィクスメンテナーのDave Airlie（Red Hat所属）が提出したDRM（Direct Rendering Manager：GPUを制御/管理するカーネルサブシステム）のプルリクエストに対しては、コーディングのスタイルに加え、Rustのフォーマットチェック機能に対するLinusの不満があふれ出たものとなった。

Linusはrustfmtcheckに自動整形の実行を許さず、チェック機能だけにとどめているが、インデントなしのスタイルや自動整形のあいまいなルール、useの独立性を崩す記述、差分/マージのノイズ増加などLinusにとって受け入れがたい問題が解決されない限り、“⁠Rust for Linux⁠”への道のりはまだまだ長いものとなりそうだ。

(2025/10/07)

Ubuntu 25.10（questing）の開発; リリースまであと一週間、26.04へ向けて

• Ubuntu 25.10（questing）の開発; リリースまであと一週間、26.04へ向けて | gihyo.jp

questing（Ubuntu 25.10）のリリースまで一週間になりました。今回はもろもろの開発プロセスの変化の結果か、リリースノートの相当な部分が先行して更新され始めており、すでに相当なボリュームの変更点が挙げられつつあります。

MEMO:

• 25が来たらサーバのOSも更新するかな

(2025/10/06)

How Functional Programming Shaped (and Twisted) Frontend Development

• How Functional Programming Shaped (and Twisted) Frontend Development

要約:

■ 1. 友人の衝撃と問いかけ

• 10年以上ぶりのフロントエンド: バックエンドとインフラに移行していた友人が現代のReactコードベースを初めて開いた
• 衝撃の反応:
  • 「これは一体何だ?」
  • 「生成されたクラス名は何?」
  • 「カスケードをキャンセルしたのか?」
  • 「誰がWebをこんな風に動かすようにしたんだ?」
• 彼の記憶: CSSが自然にカスケードし、DOMと協働し、ブラウザがルーティング・フォーム・イベントを20の抽象化なしで処理していたWeb
• 彼の印象: 現代のフロントエンドスタックはプラットフォーム自体に戦争を宣言したように見える

■ 2. 著者の背景

• 第一次ブラウザ戦争を生き抜いた: IE6で24ビットPNGを動かすためにpngfix.jsを適用
• 2AMのデバッグ: hasLayoutバグをデバッグ
• addEventListenerが信頼できない時代: ブラウザ間で同じように動作しないJavaScriptを書いていた
• jQueryの変遷: 必要になり、不可欠になり、レガシーになるのを見た
• バイアスの自覚: 間違っているかもしれないし、バイアスがあるのは確か。だがWebは絶え間ない再発明なしに有用だったという記憶も持っている

■ 3. 奇妙な皮肉:Webの本質と関数型プログラミングの衝突

• Webの起源: ドキュメント、ハイパーリンク、カスケードスタイルシート言語から生まれた
• Webの特性: 常に乱雑で、可変的で、栄光的に副作用だらけ
• 過去10年の影響: 最も影響力のあるフロントエンドツールは、関数型プログラミングの純粋性を追求するエンジニアによって形作られた
• FPの理想: 不変性、決定論、副作用の排除
• 得たもの: 強力な抽象化。Reactはコンポーネントで考えることを教えた。Reduxは状態変更を追跡可能にした。TypeScriptは動的言語にコンパイル時の安全性をもたらした
• 失ったもの: 奇妙な道を進んだ。プラットフォームを受け入れる代わりに戦った。ブラウザのネイティブ機能をJavaScriptで再構築し、DOMから「保護」するために何層もの間接層を追加し、Webの本質的な乱雑さは理解すべき特徴ではなく解決すべき問題だと自分たちを納得させた

■ 4. Webの本質

• 根本的に副作用だらけ:
  • CSSは設計上グローバルにカスケードする
  • 一箇所で定義されたスタイルがどこでも要素に影響を与え、特異性と継承を通じて創発的パターンを作る
  • DOMは巨大な可変ツリーで、ブラウザが執拗に最適化している
  • 直接変更するのが高速で予測可能
• ユーザーインタラクション: 非同期で予測不可能に到着する(クリック、スクロール、フォーム送信、ネットワークリクエスト、リサイズイベント)。「ユーザーの意図」を捉える純粋関数は存在しない
• 乱雑さは偶然ではない:
  • これがWebが何十億ものデバイスにスケールする方法
  • 何十年にもわたって後方互換性を保つ方法
  • 異種システムが相互運用できる方法
• ブラウザはオープンプラットフォーム: どこにでもエスケープハッチがある。何でもスタイルでき、どのイベントにもフックでき、どのノードも操作できる。この柔軟性と厳格な抽象化の強制を拒否することがWebのスーパーパワー
• FP本能での認識: この柔軟性を混沌と見る。グローバルを危険と見る。変更を予測不可能と見る。副作用を待ち構えているバグと見る。だから壁を作る

■ 5. 関数型プログラミングの理想の侵入

• FPのコア原則:
  • 関数は純粋であるべき(同じ入力→同じ出力、副作用なし)
  • データは不変であるべき
  • 状態変更は明示的で追跡可能であるべき
  • 適切な文脈では、推論・テスト・並列化が容易なコードを生成
• React以前からの浸透:
  • Underscore.js(2009): map、reduce、filterを大衆にもたらした
  • LodashとRamda: カリー化、合成、不変性ヘルパーを含むより深いFPツールキット
  • 空気中のアイデア: 変更を避け、小さな関数を合成し、データ変換をパイプラインとして扱う
• Reactの進化:
  • 最初はクラスコンポーネントとsetStateで、純粋なFPとは程遠い
  • しかし概念的基盤はあった: UIを状態の関数として扱い、レンダリングを決定論的にし、副作用を分離
• Elmの影響:
  • Evan Czaplickiによって作られた純粋関数型言語
  • "Model-View-Update"アーキテクチャを成文化
  • Dan AbramovがReduxを作成した時、Elmからインスピレーションを得たと明言
  • Reduxのreducerは直接Elmのupdate関数をモデル化: (state, action) => newState
• React Hooksへの移行: ステートフルなクラスを関数合成に置き換え、エコシステムはFPに決定的にシフト
• 収束: ライブラリパターン、Elmの厳格性、Reactの進化を通じて、Haskell由来の純粋性に関するアイデアが主流のJavaScript実践となった

■ 6. CSS-in-JS: グローバルスコープへの戦争

• CSSの設計: グローバルであるように設計された。スタイルはカスケード、継承し、境界を越えて合成する。これにより小さなスタイルシートが巨大なドキュメントを制御でき、チームがアプリケーション間でデザインシステムを共有できる
• 関数型プログラマーの視点: グローバルスコープは危険。暗黙の依存関係と予測不可能な結果を生む
• CSS-in-JSの登場: styled-components、Emotion、JSS
  • 約束: コンポーネントの分離
  • スタイルはコンポーネントにスコープされ、カスケードの驚きなし、命名の衝突なし
  • スタイルはデータになり、JavaScriptを通じて渡され、予測可能に要素にバインドされる
• コスト:
  • 実行時にスタイルを生成し、コンポーネントがマウントされる時に<style>タグに注入
  • クリティカルレンダリングパスにJavaScript実行を追加
  • サーバーサイドレンダリングが複雑に: レンダリング中にスタイルを抽出し、シリアライズし、クライアントでリハイドレートする必要
  • デバッグは.css-1xbq8d9のような実行時生成クラス名を伴う
  • カスケードを失う: まさにCSSを強力にしていた機能
• さらに悪いこと: ブラウザ最適化された宣言的言語をJavaScript(シングルスレッドランタイム)に移動。ブラウザはCSSを並列で、メインスレッド外で解析・適用できる。styled-componentsバンドルはメインスレッドの作業で、インタラクティビティをブロックする
• プラットフォームの解決策: Webには解決策があった。スタイルシートと呼ばれるもの。しかし十分に純粋ではなかった

■ 7. Tailwind CSSへのピボット

• 問題認識後の転換: 実行時CSS生成の代わりにユーティリティクラスを使用。styled-componentsの代わりにJSX内でクラスを合成
• 改善点: 少なくともコンパイル時で実行時ではない。スタイルを注入するためにメインスレッドをブロックしない。ハイドレーション複雑性なし
• しかしカスケードとの戦いは継続:
  • .button { padding: 1rem; }を一度書いてすべてのボタンにカスケードさせる代わりに
  • class="px-4 py-2 bg-blue-500"をすべての単一ボタン要素に書く
  • 実行時オーバーヘッドを別の問題セットと交換: マークアップ内のクラススープ、巨大なHTMLペイロード、一箇所で全体的なデザイン変更を行うカスケードの能力の喪失
• ネストセレクタへの反発:
  • Tailwindが&を使用したネストセレクタのサポートを追加(開発者がよりカスケード的なスタイルを書けるようにする機能)
  • David Khourshid(XStateの作成者)がTailwindでネストセレクタを使う例を共有
  • 即座の反発: これはTailwindの目的を台無しにする、伝統的なCSSの「問題」を持ち込む、ユーティリティファーストの哲学に違反する
• 意味すること:
  • プラットフォームにはカスケードがある
  • CSS-in-JSはそれを排除しようとして失敗
  • Tailwindはユーティリティでそれを回避しようとした
  • Tailwindが慎重にカスケード的機能を再導入すると、何年ものアンチカスケードイデオロギーで訓練された開発者がそれを拒否
  • カスケードが危険だと教えることに長い時間を費やしたため、自分たちのツールがプラットフォーム機能を再導入しようとしても、彼らはそれを望まない
• 結論: もはやプラットフォームに無知なだけではない。イデオロギー的に反対している

■ 8. 合成イベント: プラットフォームの抽象化

• Reactの合成イベント: ブラウザの不整合を正規化し、イベントをレンダリングライフサイクルに統合
  • DOMノードに直接リスナーをアタッチする代わりに、イベント委任を使用
  • ルートでリッスンし、自身のシステムを通じてハンドラーにイベントをルーティング
• FP視点からのエレガンス: イベントはコンポーネントツリーを流れるデータになる。DOMに直接触れない。すべてがReactの制御された宇宙内に留まる
• しかしネイティブブラウザイベントは既に動作する: バブル、キャプチャ、十分に仕様化されている。ブラウザは何十年もイベントディスパッチを最適化してきた
• 合成レイヤーによる追加:
  • イベントオブジェクトのメモリオーバーヘッド
  • すべてのインタラクションの変換ロジック
  • ネイティブAPIと異なる動作をする時のデバッグ摩擦
• さらに悪いこと: プラットフォームを避けるように開発者を訓練。開発者はReactのイベントシステムを学び、Webのものを学ばない。サードパーティライブラリやカスタム要素と作業する必要がある時、インピーダンスミスマッチに遭遇。addEventListenerが自分のコードベースで外国のAPIになる
• 再び: Webにはこれがあった。ブラウザのイベントシステムは高速で、柔軟で、よく理解されている。しかし閉じたシステムのFP理想には十分に制御されていなかった

■ 9. クライアントサイドレンダリングとハイドレーション

• 論理的極限: 「状態の純粋関数としてのUI」の論理的極限はクライアントサイドレンダリング
  • サーバーは空のHTMLシェルを送信
  • JavaScriptが起動
  • アプリはブラウザで完全にレンダリング
  • FP視点: クリーン。アプリは初期状態を取りDOMツリーを生成する決定論的関数
• Web視点: 災害
  • JavaScriptが解析・実行し、手動でDOMを構築する間、ブラウザは待機
  • ユーザーは空白画面を見る
  • スクリーンリーダーは空のドキュメントを得る
  • 検索エンジンは何も見ない
  • プログレッシブレンダリング(ブラウザの最も強力な機能の1つ)が未使用

■ 10. サーバーサイドレンダリングとハイドレーションの矛盾

• SSRの復活: 業界は気づいた。しかしメンタルモデルはまだ「JavaScriptがDOMを所有」
• ハイドレーション:
  • サーバーがHTMLをレンダリング
  • クライアントがJavaScriptで同じツリーをレンダリング
  • Reactが両方を歩いてイベントハンドラーをアタッチ
  • ハイドレーション中、ページは可視だが不活性
  • クリックは何もしない、フォームは送信しない
• アーキテクチャ的に不条理:
  • ブラウザは既にページをレンダリング済み
  • 既にクリック処理方法を知っている
  • しかしフレームワークが合成イベントシステムを通じてすべてのインタラクションを所有したいため、何かが動作する前にJavaScriptで全体のコンポーネントツリーを再作成する必要
• インフラへの拡張:
  • すべてのユーザーが2倍のリクエスト数を行う
  • サーバーがページをレンダリングしデータを取得
  • クライアントが起動し、ハイドレーションのためにコンポーネントツリーを再構築するために全く同じデータを再度取得
  • なぜ? フレームワークが生成したHTMLを信頼できないから
  • イベントハンドラーをアタッチし状態を管理するために、JavaScriptでUIの内部表現を再構築する必要
• 無駄で高コスト:
  • データベースクエリが2回実行
  • API呼び出しが2回実行
  • キャッシュレイヤーが2回ヒット
  • CDNコストが2倍
  • なぜ? フレームワークがすべての状態がJavaScriptに存在する純粋関数モデルを維持できるように
• 結論: ハイドレーションは、Webを能力を持つプラットフォームではなく白紙のキャンバスとして扱う時に起こること。WebはストリーミングHTML、プログレッシブエンハンスメント、即座のインタラクティビティを与えた。JSON、JavaScriptバンドル、重複ネットワークリクエスト、「現実を再構築する間お待ちください」に置き換えた

■ 11. モーダル問題: ベストプラクティスとして誤った実践を教える

• ネイティブ<dialog>要素:
  • フォーカストラッピングを管理
  • Escapeキー却下を処理
  • バックドロップを提供
  • ボディのスクロールロックを制御
  • アクセシビリティツリーと統合
  • DOM内に存在するが開かれるまで隠れたまま
  • JavaScriptマウント不要
  • 高速、アクセシブル、ブラウザベンダーによって実戦テスト済み
• チュートリアル・ブートキャンプで教えられること:
  • <div>要素でモーダルを構築
  • isOpenがtrueの時に条件付きレンダリング
  • 手動でクリックアウトサイドハンドラーをアタッチ
  • Escapeキーをリッスンするエフェクトを書く
  • フォーカストラッピング用の別のエフェクトを追加
  • 独自のスクロールロックロジックを実装
  • ARIA属性追加を忘れずに
  • イベントリスナーのクリーンアップを忘れずに、さもなくばメモリリーク
• 結果: ブラウザが無料で提供するものを粗末に再作成するために100行以上のJavaScriptを書いた
• 訓練の問題:
  • 開発者はネイティブソリューションを探すことさえしないように訓練される
  • プラットフォームが見えなくなる
  • 「モーダルの作り方は?」への答えは「ライブラリをインストール」や「これが私のカスタムフック」であり、決して「<dialog>を使え」ではない
• 教育が問題:
  • 影響力のあるチュートリアル作者やブートキャンプカリキュラムがネイティブAPIをスキップしてReactパターンを支持する時
  • 代替アプローチを示しているだけでなく、積極的に誤った実践を教えている
  • 世代の開発者がアクセシブルでない<div>スープを構築することを学ぶ
  • それがフレームワークの反応性モデルに適合するから
  • プラットフォームが既にこれらの問題を解決していたことを決して知らない
• ブートキャンプだけではない: 最も人気のあるコンポーネントライブラリも同じ選択
  • shadcn/uiはDialogコンポーネントをRadix UIプリミティブ上に構築
  • ネイティブ<dialog>要素の代わりに<div role="dialog">を使用
  • ネイティブ<dialog>サポートを要求するオープンなGitHub issueがある
  • しかし暗黙のメッセージは明確: ブラウザと協働するよりも再実装する方が簡単

■ 12. フレームワークがプラットフォームの進化についていけない時

• より深い問題: 無知や惰性以上のもの。フレームワーク自体がプラットフォームの進化と協働することに苦労している。プラットフォーム機能が悪いからではなく、フレームワークのアーキテクチャ的前提がそれらに対応できないから
• Radix UIが<div role="dialog">を選ぶ理由:
  • ネイティブ<dialog>要素は自身の状態を管理: いつ開いているか知っている、自身の可視性を処理、内部でフォーカスを制御
  • Reactの反応性モデルはすべての状態がJavaScriptに存在し、DOMに一方向に流れることを期待
  • ネイティブ要素が自身の状態を管理すると、Reactのメンタルモデルが崩壊
  • React状態のisOpenと<dialog>要素の実際の開閉状態を同期させるのは、refs、エフェクト、命令的呼び出しの悪夢
  • まさにReactが排除するはずだったもの
  • パターンをステートフルなネイティブ要素と協働するように適応させるよりも、フレームワークに適合する方法で全体の動作をJavaScriptで再実装する方がアーキテクチャ的に簡単
• 新しいプラットフォーム機能の例:
  • アコーディオン? Webには<details>と<summary>
  • ツールチップ? title属性と新興のpopover API
  • 日付ピッカー? <input type="date">
  • カスタムドロップダウン? Webは今<select>要素をappearance: base-selectと::picker(select)疑似要素でスタイリングサポート
  • <option>要素内に画像付き<span>要素も入れられる
  • デザイナーがカスタムスタイリングを望んだという理由だけで存在する無数のJavaScript selectライブラリの必要性を排除
• フレームワークの問題:
  • 条件付きレンダリングとコンポーネント状態を奨励するため、これらの要素はJavaScriptが存在すべきと決めるまでレンダリングされない
  • メンタルモデルは「状態が変わった時にUIが現れる」であり、「UIは存在し、状態が可視性を制御する」ではない
  • プラットフォームが何年もJavaScriptで再構築されてきた正確な機能を追加しても、エコシステムの勢いは多くの開発者がこれらの機能の存在を決して学ばないことを意味
• 真に不条理な部分:
  • 開発者がこれらの新しいプラットフォーム機能を知っていても、フレームワーク自体がそれらを処理できない
  • MDNのカスタマイズ可能な<select>要素のドキュメントに警告:「一部のJavaScriptフレームワークはこれらの機能をブロック; 他では、サーバーサイドレンダリング(SSR)が有効な時にハイドレーション失敗を引き起こす」
  • プラットフォームは進化した
  • HTMLパーサーは今<option>要素内により豊かなコンテンツを許可
  • しかしReactのJSXパーサーとハイドレーションシステムはこれのために設計されていない
  • <option>はテキストのみを含むと期待
  • プラットフォームの進化に対応するためにフレームワークを更新するには時間、調整、チームが躊躇する破壊的変更が必要
• 結論: Webプラットフォームは全カテゴリのJavaScriptライブラリを排除する機能を追加したが、支配的なフレームワークはハイドレーションエラーを引き起こさずにそれらの機能を使用できない。開発を容易にするはずだったスタックが、今や構築されているプラットフォームに遅れている

■ 13. ルーティングとフォーム: JavaScriptオールザウェイダウン

• ブラウザのネイティブ機能:
  • ルーティング: <a>タグ、History API、前後ボタン
  • フォーム: <form>要素、検証属性、送信イベント
  • JavaScriptなしで動作
  • デフォルトでアクセシブル
  • 高速
• 現代フレームワークの対応:
  • React Router、Next.jsのルーター、Vue Router
  • リンククリックをインターセプト
  • ブラウザナビゲーションを防止
  • JavaScriptでルーティングを処理
  • なぜ? クライアントサイドルーティングは純粋な状態遷移のように感じる: URL変更、状態更新、コンポーネント再レンダリング、ページリロードなし、JavaScript状態の「喪失」なし
• 失ったもの:
  • ナビゲーションがJavaScriptに依存
  • Ctrl+クリックで新しいタブで開く? 慎重に再実装しない限り壊れる
  • 右クリックでリンクをコピー? URLがレンダリングされたものと一致しない可能性
  • 標準ナビゲーションパターンに依存するアクセシビリティツール? 混乱
• フォームも同じ扱い:
  • ブラウザに送信、検証、アクセシビリティを処理させる代わりに、フレームワークはJavaScript制御フォームを奨励
  • Formik、React Hook Form、非制御vs制御入力
  • <form>が既に行うことを管理するためだけに存在する全ライブラリ
  • ブラウザは<input type="email">をJavaScriptなしで即座に検証できる
  • しかし十分に反応的ではないため、JavaScriptで検証を再構築し、クライアントに出荷し、ロジックが正しいことを願う
• 再び: Webにはこれらのプリミティブがあった。「状態はJavaScriptを通じて流れる」というFPに触発されたメンタルモデルに適合しなかったため拒否した

■ 14. 失ったもの

• プログレッシブエンハンスメント:
  • かつてのベストプラクティス: 動作するHTMLから始め、スタイルのためにCSSを重ね、インタラクティビティのためにJavaScriptを追加。ページはすべてのレベルで動作
  • 今: JavaScriptから始めて後方に作業し、コンポーネントツリーからHTMLを絞り出そうとし、ハイドレーションが壊れないことを願う
• 組み込みアクセシビリティ:
  • ネイティブHTML要素はデフォルトでロール、ラベル、キーボードサポート
  • カスタムJavaScriptウィジェットはaria-*属性、フォーカス管理、キーボードハンドラーが必要
  • すべて忘れやすいか設定ミスしやすい
• パフォーマンス:
  • ブラウザのストリーミングパーサーは到着するHTMLをレンダリングできる
  • 現代フレームワークはJavaScriptを送信、JavaScriptを解析、JavaScriptを実行、そしてやっとレンダリング。それは遅い
  • ブラウザはCSSとHTMLを積極的にキャッシュできる
  • JavaScriptバンドルはすべてのデプロイで無効化
• シンプルさ:
  • <a href="/about">は8文字
  • クライアントサイドルーターは依存関係、設定ファイル、メンタルモデル
  • <form action="/submit" method="POST">は自己文書化
  • 検証付き制御フォームは数十行の状態管理
• プラットフォームとの整合性:
  • ブラウザベンダーはHTML解析、CSSレンダリング、イベントディスパッチの最適化に何百万も費やす
  • 開発者はそれらの機能をJavaScriptで再構築するのに何千時間も費やす、より遅く

■ 15. なぜこうなったか

• 無能の話ではない: 賢い人々が本当の理由でこれらのツールを構築
• 2010年代初頭の状況:
  • JavaScriptアプリケーションが保守不可能に
  • jQueryスパゲッティがコードベース全体に広がる
  • 双方向データバインディングがデバッグ不可能なカスケード更新を引き起こす(皮肉なことに、Backboneのドキュメントは双方向バインディングに対して明示的に助言し、「実際のアプリでは特に有用ではない傾向」と述べたが、多くの開発者がプラグインを通じて実装)
  • コミュニティは規律を望み、FPがそれを提供: UIを状態の純粋関数として扱う、データを一方向に流す、共有可変状態を排除
• Reactの到着(2013):
  • これらの理想を結晶化
  • UI = f(state)の世界を約束: データを与え、コンポーネントツリーを返し、データが変わったら再レンダリング
  • 手動DOM操作なし
  • 暗黙の副作用なし
  • ただ純粋で予測可能な変換
• 魅力的で多くの点で機能した: しかし、JavaScriptをWebのイメージで作るのではなく、WebをJavaScriptのイメージで再構築する道に進んだ
• 複雑なアプリケーションでの正当性:
  • 何百もの対話型コンポーネントを持つダッシュボード
  • リアルタイムコラボレーションツール
  • データ可視化プラットフォーム
  • Reactのモデルは手動でイベントハンドラーを配線し変更を追跡するよりも genuinely better
• FP純粋主義者の誤り:
  • 予測不可能な変更がバグを引き起こすことは正しかった
  • 解決策がプラットフォームの変更に優しいAPIを避けることではなく、それらをうまく使うことを学ぶことだったという点で間違っていた
  • しかし2013年の混沌では、その区別は重要でなかった
  • Reactは機能し、スケールし、Facebookが本番環境で使用していた
• ハイプサイクル:
  • Reactが会話を支配
  • すべてのカンファレンスでReactトーク
  • すべてのチュートリアルがReactを出発点として仮定
  • CSS-in-JSが「モダン」に
  • クライアントサイドレンダリングがデフォルトに
  • Facebook、Airbnb、Netflixなどの大企業がこれらのパターンを採用すると、業界標準に
  • ブートキャンプがReactのみを教える
  • 求人がReact経験を要求
  • ナラティブが固まる: これが今Webを構築する方法
• 自己強化エコシステム:
  • Reactが採用パイプラインとStack Overflow回答を支配すると、代替案は苦戦
  • 既にReactに投資したチーム(開発者訓練、コンポーネントライブラリ構築、パターン確立)は莫大なスイッチングコストに直面
  • 新しい開発者は仕事が要求するからReactを学ぶ
  • 仕事は開発者が知っているからReactを要求
  • サイクルは、Reactが特定の仕事に最適なツールかどうかとは無関係に、自己を養う
• 道を見失った場所:
  • 「Reactが複雑なアプリケーション問題を解決」から「Reactがウェブサイトの構築方法」への移行のどこかで
  • 解決している問題が実際にこれらのソリューションを必要とするかどうかを問うのをやめた
  • Next.jsで個人ブログを構築する開発者を見た(95%静的コンテンツで多分お問い合わせフォームだけ、ブートキャンプで学んだから)
  • ゼロインタラクティビティのマーケティングサイトにReactを選ぶ企業を見た、適切だからではなく、他に何も知らない開発者を雇えないから
• 根本的な変化:
  • 複雑でステートフルなアプリケーション用に設計されたツールが、1995年にHTMLとCSSでWebが解決した問題を含むすべてのデフォルトに
  • 世代の開発者がほとんどのウェブサイトはフレームワークをまったく必要としないことを決して学ばなかった
  • 質問は「この問題はReactが必要か?」ではなく「どのReactパターンを使うべきか?」になった
  • プログレッシブレンダリング、セマンティックHTML、カスケード、即座のナビゲーションなどのプラットフォームのネイティブ機能は今「古臭い」と見なされる
  • それらをJavaScriptで再発明することが「ベストプラクティス」に
• 結論: 決して設計されていないプラットフォームで関数型純粋性を追求。ミスマッチを覆うために複雑さを構築

■ 16. 進むべき道

• 良いニュース: 学んでいる。業界はプラットフォームを再発見している
• 新しいアプローチ:
  • HTMX: HTMLを交換媒体として受け入れる。サーバーがHTMLを送信、ブラウザがレンダリング、ハイドレーション不要
  • Qwik: 再開可能アーキテクチャでハイドレーションを完全に回避、必要なものだけをシリアライズ
  • Astro: 最小限のJavaScriptでサーバーレンダリングHTMLをデフォルト
  • RemixとSvelteKit: Web標準に寄りかかる: JSなしで動作するフォーム、プログレッシブエンハンスメント、ブラウザのキャッシュ活用
• これらのツールが認めること: Webは強力なネイティブ機能を持つドキュメントベースのプラットフォーム。戦うのではなく、協働する
• 意味しないこと: コンポーネントや反応性を放棄することではない

• 意味すること:

  • UI = f(state)がフレームワーク内で有用なモデルであることを認識、ブラウザスタック全体を再構築する正当化ではない
  • スタイリングにCSS、インタラクションにネイティブイベント、構造にHTMLを使用
  • そしてプラットフォームが提供する以上のインタラクティビティが必要な時にJavaScriptに手を伸ばす

• 次の10年の最高のフレームワーク: それにもかかわらずではなく、Webのように感じるもの

■ 17. 結論

• 追求の結果: 関数型純粋性を追求する中で、より複雑で、より壊れやすく、実行されるプラットフォームとの整合性が低いフロントエンドスタックを構築した
• 再作成したもの:
  • JavaScriptでのCSS
  • 合成ラッパーでのイベント
  • ハイドレーションレイヤーでのレンダリング
  • クライアントサイド状態マシンでのルーティング
• 理由: 予測可能性、制御、クリーンな抽象化を望んだから
• Webの本質:
  • 決して純粋であることを意図されていなかった
  • 何十年もの創発的行動、実用的妥協、急進的オープン性の上に構築された広大で乱雑で奇跡的なプラットフォーム
  • その可変性はバグではない。1995年に書かれたドキュメントが2025年にまだレンダリングされる理由
  • そのグローバルスコープは危険ではない。何十億ものページがデザイン言語を共有できる理由
• 最終的な問い: おそらくWebは純化される必要はなかった。おそらくただ理解される必要があっただけ

(2025/10/06)

追記：2025年-俺達が信じたITの夢の果てにて

• 追記：2025年-俺達が信じたITの夢の果てにて

https://anond.hatelabo.jp/20251004160446

■ 僕らが見てた夢は、デジタル背景に01が流れアニメの様な美少女を抱く、格好よすぎる未来　そして絶望の世界に駆け抜ける嵐

俺の書いた記事がXでバズったのか、人々の口端に上っていた事に驚いた。

中には、図星を衝かれたように発狂して、まるで「自分だけは違う、最初からわかっている」と頼まれてもないのに惨めに開陳しているエンジニア達もいる。

普通ならイラっとするのだろう。だが俺は彼らを憐れに思うし、赦そうと思う。何も言い返せないからなのだろう。心の奥で思っていることを見透かされたとき、ただ発狂して逆張りするしかない、俺自身がそういう存在を一番よく知っている。

アメリカで働いていた時、韓国人の同僚に言われた言葉をふと思い出した。

「モノづくり展示会と称したITのイベントを日本で見たことがあります。秋葉原に行っていた時でした。」

「そこには私は違和感を感じました。誰も使わない技術が並び、最新のトレンド技術のセミナーでは「何も変わらない理想」が語られています。エンジニアはビジネスを知らず、ビジネスは本質を見誤っている。空回りしている様に感じます」

「DOGDAYSやリリカルなのはやニャル子さん、化物語、まどかマギカ、プリズマ☆イリヤの曲が流れてポップが立ち並び、メイドがビラを配り、そして大々的にイベントを打っては何のビジネスにつながるか全く理解できない独りよがりな技術を喧伝しあっている…あれは、私の様なオタクなら理解できるが、はたから見れば狂気の世界そのものだと思います」

「一方で、秋葉原M〇Dや駅前の裏路地では、我が国の特殊部隊員(コムンベレーというらしい)が使っているのと同種の暗殺用クロスボウや、ナイフ、盗聴器の類が売られている。ITの方向性はトンチンカンなのに、剥き出しの暗い性欲と暴力への欲求は誰に教わるわけでなく願望がそこにある…私には、それこそが彼らの欲望や願望の本質の様に感じます。」

その時、俺は何も言えなかったことをよく覚えている。

いつからだっただろうか、いつからそうなったのかは知らない、だが俺達の時代にはすでにITエンジニアというもの自体が、「自分が理解できないものを意味もなく徹底的に敵視する排外主義者になってしまった男の避難所」の様になっていたきらいがあった。

海外の人たちは、それを鋭い感性で本質を見抜いていたのだろう。

2024年12月　ITコンサルの男が女子中学生をレイプして捕まった。

2025年1月　さる大手IT企業のエンジニアが、就活中の女子大生をインターンシップで釣ってレイプして捕まった

2025年8月　ITエンジニアのプログラミング講師の男が、女子小学生に性的暴行を加えて捕まった

･･･なあ、俺達は内輪でこもり続けて、こんなことでしか人を愛する方法がわからないほどいつから歪んでしまったんだ？

俺達はITで何を手に入れたかったのだろうか。何を手に入れられたのだろうか？何を手に入れるべきだったのだろうか？

■ 絶望の世界に、吹き荒れる嵐　デスクトップに広がる逃げられない闇の向こうで、Vruber達が媚びた声で踊っている。配信者がファンに通り魔で殺された場所では、自販機の向こうで初音ミクがポカリスエットを手に笑っている。

Vtuberやボカロは、数少ない2010年代以降のICTの成果、といえるのだろうか、あれだけ2010年頭までは「ゲームに行くエンジニアは邪道」と吹いていたかつての俺達の同輩が、

今はその時代からバカにされながらも踏ん張って今世界で戦っている日系ゲーム企業に、惨めな自尊心を縋り付けようと、ゲームはITの成果だ！とXで喚いている。

確かにそうかもしれない、だが、その結果誰が幸せになった？

さる人気Vtuberは、わざわざ「東京がゾンビパニックになろうがロシア軍が空挺降下で襲撃してきても、耐えられる程の防御力のタワマン」にお金を出して引っ越していたそうだ。もちろん、防犯のために。

別の人気Vtuberたちは、男も女も一昔前ならベトナム戦争の最前線で戦い続け心が砕け散った兵士でしかならない様な症例レベルの心身症で、失聴し、失声し、謎の心因性皮膚炎が止まらず、心因性の慢性疼痛で小便すら困難な程になり、リタイアしたり長期療養をしている人たちのニュースであふれている。

彼女や彼氏も作れず、こっそり作っていようが些細な内輪の暴露や足の引っ張り合いで連日大炎上し、Vtuberの中身を食えば男としての箔が上がるという思想の元、音楽だのを餌に反社崩れが界隈に潜入し、vtuberに劇薬まで盛っていた犯罪者集団がいたことまで報道され、まるで1970年代のイタリアの如き無法地帯の様相を呈している。そこには幸せだとか人間らしい営みや、俺たちが夢見た「カッコイイスマートなIT社会」というものは何も感じられない。闇だ。ただひたすらにスマホに、そしてPCのデスクトップに広がる人の毒が漂う闇が広がっている…

･･･かつて俺の同僚の韓国人がいった世界観が、現実になった結果である。

それだけではない、こんな悲劇が繰り返されているのに「法律を制定しない政府や社会が悪い」と俺達ITエンジニア達の罪を、得意の他責思想で憮然として開き直っている。

こんな様では、日本のITが衰退して外資に食われるのも、当然の帰結であろう

今は、AI技術がトレンドになっているが、これもロクな使い方もされずに消えていくだろう、俺が20年見続けていた社会も変わらず同じ結果になるだろう、という悲観的な未来が見えてしまう。

なあ、俺達はITで一体どんな世界を作りたかったんだ？何を目指していたんだ？どこへ行きたかったんだ？どうなりたかったんだ？

答えは出ない、他責思想で思考をとめればいいからだ。全く、都合のいい「ロジカル思考」である。

■ ”選ばれし者たち”　「性欲」と「承認欲求」と「秘密兵器IT技術」と「テロリズム」　－ICTで世界は変えられると叫んで旗を掲げた末路は、ガソリンと包丁とSNS片手の原始のテロ戦術ー

ITで世界は変わる、プログラミングが出来れば人生逆転できる。かつて俺が若かったころ、こんなあまりにも幼稚な理屈がIT業界やネットでは「事実」として流布されていた。

だがそれはいつしか時代を経るごとに神話になり、そして狂信へと変わっていった。

あれだけ縋り付いたIT技術では何も変わらない、まず自分たちの他責思想と性根を変えなければ…かつて海外で上司や同僚に言われた事を、Xでは図星を衝かれて大パニックになったエンジニア達が発狂して、それでもなお改めようとしないでいる。

彼らが縋り付いたIT技術という「魔法」の人生逆転…これが叶わぬと観るやどうなったか？そう、客観的に見れば犯罪とテロリズムに走っているのである。高すぎるプライドを変える様社会から要請しても弾き飛ばした独りよがりな男たちがたどり着いた「論理的思考の最適解」がこれである

どこぞの気が狂った男の主張を神輿に掲げ、女が憎い、政治が悪い、社会が悪いとSNSで叫び、あれほど大好きだったアニメ業界でさえ、些細なクリエイターの気に入らない言葉尻をとらえ、彼氏など年頃からしていて当然のアイドル声優やVtuberに彼氏がいるとわかるや憎悪をむき出して、所属会社にパンクする程の抗議という破壊工作で経済テロを敢行している。そして、それを当然と開き直っている。

そして、これを指摘されると発狂して他責思想へ逃げるのだ「そんなこといってない」、「俺は違う」、「主語がデカい」といって…その姿はアメリカが悪いといってアメリカ軍から逃げ回り、無抵抗の民間人を殺したことを誇り、地元の市場を襲ってカネを奪い、放火し、挙句女を嫁として攫うイスラムテロリストの論理と行動そのものである。

･･･人間というものが、理性を盾にしてどれほど狂気的になれるのか。かつての俺の様なメンタルのまま今を生きている「俺の未来だった可能性」を選んだ彼らがそれをSNSで雄弁に体現している。

――論理的思考の名を借りて己の人間性を殺し続けた者たち…その姿に俺は恐怖ではなく一種の憐れみと、壊れてしまえば悩みもなくなる「羨ましさ」すら感じている。

俺が帰国した年、そのピークとなる出来事が起こったことは前述の通りだ。頭の中のリゼロのレムちゃんに唆され、結婚するためには哲学的ゾンビを殺さなければならないと喚き散らして、包丁と金属バットで5人を殺害して捕まったITエンジニアの事件が、神戸で起こった。

このＩＴ業界では知らぬ人間はモグりとまで言われた大物エンジニアが、政府相手に巨額のスパコン詐欺を働き捕まり、懲役五年に実刑判決の末、獄に繋がれた。

･･･俺たちが自分の人生と世界を変えようと掲げたITの旗の夢の果てである。

理屈の上では「アニメみたいな美少女を宛がえ」、「キラキラ職を用意しろ」と叫んでテロを起こし続ければ、そのうち政府や社会が折れて宛がってくれるというのは、そうなのだろう。

高すぎる理想の人生像と、極上の異性を手に入れて人生逆転するためには、犯罪者やテロリストになる以外に現実的に方法がないという彼らの「論理的思考の結論」も、そうなのだろう。その姿は、幕末の京都を思わせる。(実際、参考にしたのかもしれない)

･･･犯罪やテロで社会を揺さぶれば、やがて社会と政府が折れてウマ娘の様な無垢の美少女を政府が宛がい、カッコイイキラキラ人生を特権として譲り渡してくれると信じている。

それが、他責思想と高いプライドで「心の城」に籠り続けた彼らが導き出した「論理」なのだ。理想と現実の乖離が、彼らを「理屈」の衣へ纏った狂気の存在へと変貌させた。

るろうに剣心は女性向け新選組BL漫画で描かれた時代の様に、理想と現実の齟齬が彼らを追い詰め、「IT技術」といった真っ当な方法では、アニメの様な極上の美少女とキラキラ人生への逆転は不可能と悟や、犯罪とテロへの道へと訴えかけていっている。

だがなぜ社会と対話と協調をしようとしない、できないのか？そんなことすらできないほど、俺達IT業界の人間たちは歪んでしまったのだ。

もっと虚飾を剥いで言おう、彼らはもはや内輪に籠り人や社会に合わせなかった結果、テロリズムでしか自身の人生と世の中を変える方法がなくなってしまった存在になってしまったのだ。

だが俺は、俺達自身に問いたださねばならないと思う。なぜ彼らが心が歪み、内輪に籠り続けた結果、アニメの様な極上の美少女とキラキラ人生への逆転で唯一残された手段はテロと犯罪と信じるに至ったのか。

それは俺たちの社会、ＩＴ業界にとっての深刻な失敗ではないだろうか、と

自己責任、自業自得、といえばそれまでなのだろう。だが、プライドの高い彼らの「抵抗戦争」は年々激しさを増している…そう、戦争と言えるほどに。俺はこれを眺める事しかできない。

理想という名の自己愛…それが彼らを焼いたのだ。

■ 夢の後先　IT業界の残照

最近は、俺はITに関係がない場所へ逃げる様に行くことが多くなった。

青梅駅から15分ほど歩けば、多摩川の上流の河原へ行ける。

釣った魚が食べられる程の澄んだ河川と、ITなんて何ら関係ないとばかりに自然があるがままの営みを続けている場所で、俺は心が洗われる様な感覚になることがある。

ドローンも飛ばぬ空の上を、白鷺が飛んでいる。太陽光発電跡地というITとカネと欲望の怨念に、自然が引き裂かれたかつての場所で、自然が生い茂り、花が揺れて蝶が舞っている…IT業界の墓標の上で、自然だけが無言のまま生を息づけている。

俺達が信じたITの夢の果て、彼らの「人生一発逆転」を目指した、アニメの様な美少女を抱き、キラキラ人生を手に入れる為に他責思想を叫びながら、ガソリンと包丁とSNSを片手に社会や政府に行う、「論理の衣」を纏った性欲と怨念の鬼たち…彼らの犯罪やテロリズムによる戦いの先には何があるのだろうか。

果たして万が一それを得た先に、いったいどんな光景を夢見ているのだろうか？それはウマ娘を抱き勝利の美酒に酔い、ITの勝利の旗を掲げる姿か、はてなき死の果ての虚無の闇か

彼らが大好きなレムちゃんやエミリア、ウマ娘の様な極上の美少女を抱き、キラキラ職とキラキラ人生に恋焦がれて犯罪やテロに従事する理由は、単純な欲望からではないことを、俺はよく知っている。

･･･それは、自らに卑小を否定するための戦いである。理性と論理を自称する者たちが、もっとも非理性な思想と欲望のためにテロと犯罪に従事する。その狂気の理屈を理解できるのは、一般人ではなく俺達の様なITエンジニア達だけであろう。

彼らの「夢の終わりに抗うテロ戦争」の行く末がどうなるか、俺はわからない。わかるのは、この画面の向こうの地獄の入り口のSNSで憎悪と性欲と承認欲求に塗れて、「人生最後のチャンスの解放戦争」に従事しているかつての俺の同輩たちの心の中のみ、である。

10月5日、午後二時、三時。iPhoneの画面の向こう、社会への憎悪と怨念と図星を衝かれた他責思想の発狂、感情の闇と人の業が激流の様に渦巻くSNSの画面から目を逸らすと、そんな業塗れの世界とは無縁とばかりに、多摩川上流のほとりで小魚たちが澄んだ水の中を悠々と泳いでいる…

関連:

• 海外でITエンジニアをしていた時に予言された事通りに業界がなってる

MEMO:

• カスみたいなポエムだ

(2025/10/06)

海外でITエンジニアをしていた時に予言された事通りに業界がなってる

• 海外でITエンジニアをしていた時に予言された事通りに業界がなってる

もう12年も13年ほど前になるが、俺は以前、海外でITエンジニアとして働いていた。

あの頃は、はてなでも海外を回っているエンジニアも多かった。そういう時代だった

シリコンバレーから、だんだんとITベンチャーのスタートアップが拡散していった時代。俺もシリコンバレーあたりから、NY、そしてイスラエルといった感じで働く場所が変わっていた。

当時はまだ日本のIT業界も世界2位だった頃の残光があり、気を吐いて色々なweb系ベンチャーが出ていた時代、結構「愛国主義的」な感じを俺もまだ20代だったから持っていて、お国のIT技術自慢の様な話もオフィスの中では多かったように思うし、それでも途切れないほど日本人エンジニア達が作ったものが毎日のようにOSSやITビジネスニュースを駆け巡っていた。

当時の上司は、イスラエル出身の人間だった。いろいろな企業の立ち上げにも参加して経験豊富、ぶっちゃけ絶対頭が上がらない人間の一人で、今でも生きていれば、もう65にはなるだろうか。

「今まで見てきた日本人エンジニアは英語の概念やプログラミングの技術力が重要、とみんないっていた。私は違うと思う。こんな概念を持っているのは日本だけだ。まるでカルト信仰のようだ。」

「プログラミングに必要なのはドキュメント力だ、国語の概念だ。つまり、母国語での読み書き能力、会話、コミュニケーション力が最も重要な基礎的能力だ。少なくともITでビジネスとして成り立たせるには。その概念を持っている日本人エンジニアが一人もいない。少なくとも、私は今まで百人近く日本人エンジニアを雇ったが、見たことがない。」

「こんな人間しかいないようでは、近いうちに、日本のITの技術力はある日を境にとてつもなく低下し、何のプロダクトもうめなくなる時代が来るだろう。それはいつごろかわからないが、5年後か、10年後くらいかもしれない」

当時俺は内心イラっとしていた。「はぁ？何言ってんだこのユ〇公、負け惜しみじゃねえのか？」と思っていた。若かったからな。それはしょうがない。

他のマネージャー層や、同僚の中国、インド、イスラエル、アメリカ、北欧、カナダ色んな国のエンジニアが来てて、万国博覧会の様相を呈していたが、驚くことにみんなこれに同意していた。

中「数学的能力や計算力が重要、ともよく言っていますよね。私の大学時代、そんな事全く教えられてなかった。チューリングマシンの概念を理解していれば、そんな話発想すら出てこないと思います。」

印「この概念と理解領域の狭さはネックですよね。ITの理解力の低さは、ソフトウェアだけでなく建築といったインフラにも今後影響が出てくるんじゃないでしょうか？」

北「これからは全部デジタルツインになりますからね、如何にスマートにシミュレーション構築するかで、性能もコストも愕然と差が出てくる時代になりますよね」

加「高度な計算シミュレーションについていけなくなると、最終的に国家財政や経済効率も低調になっていくと思うよ」

俺は当時こういう話を聞いて頭がカーッとなりながら、何とか負けたくないから反論した。

「主語がデカすぎるんじゃないですか？文系分野まで関係ない言いがかりじゃないですか」と

あの時の上司の顔が忘れられない。もう憐れみの目と表情でみんな俺を見ていた、そして、オタ仲間だった米人エンジニアが申し訳なさそうに言った言葉をはっきり記憶に残っている。

「増田、あまり言いたくはないが、日本人エンジニアは大多数の非ITに無関心過ぎる帰来はあります。僕はオタクだからわかる。オタクの内輪のノリのまま、日本のITは来てしまっている。80年代とかの昔はそうじゃなかったのかもしれない、でも10年位前(※当時なので2000年代を指す)からそうだ。」

「ITをあまり知らない業種や業界の人に使ってもらおう、という謙虚さを日本人エンジニアからは感じられない。OSSのソースコードや製品の命名を見ればわかる。女児向けアニメキャラや特撮ヒーローとかの名前を幾ら好きだからってちなんで入れたりなんて、アメリカの価値観では異常者や変態のそれとして扱われるんだ。」

「日本人エンジニアは、"他者不在”のまま働いてるんだよ。」

当然、会話は英語だから俺が翻案訳でこれを今思い返しながら書いてる。当時、知らん奴にわからせようとしても無駄だろうと、本気で思っていた。今思えば、当時のIT系はそういう思想が根強かったように思う(今も一部では、かもしれないが)

上司はそれから常にこういっていた

「増田くん、キミはパソコンやアニメやゲーム以外に趣味を持ちなさい。私からは、君にそれしかアドバイスができない」

それから俺は哀れまれる目線が嫌で、数年働いてキレてやめて、逃げる様に日本へ帰ってきたわけだが。そのころには確かに、日本でITプロダクトなんて何も名前を聞かないほどになっていた。GAFAMに制圧されたかの様に。

Xとかでもネットでも未だに、俺達や俺たちの少し上の世代が「Winnyがいい例だ。ITを理解できない老害と社会に潰されたせいで、GAFAMが生まれ出る土壌が日本からなくなってしまった」という被害者意識丸出しの「神話」が当たり前のように垂れ流されている。

わかったことがある。俺はあまりにも自分の底が割れることが怖くて、世の中を、社会を知ろうとしなかった。ITが面白んじゃない、好きなんじゃない、俺はネット見るかゲームするかしかやることがない陰キャで、ほかに得意なことがないからパソコン使う仕事が相対的に一番食べて行けたからやっていただけだったんだ。

これからの時代、俺みたいなエンジニアはどんどん淘汰されて業界から叩き出されていくのだろう。

既に、IT以外の事もできるITエンジニア、のような新世代の人間たちが、俺が十数年前嫌という程海外で観た、俺が内心嫌いだった人種たちが日本でもIT業界で珍しくなくなった。 俺達の世代や、俺たちの少し上の世代の「今では古くなってしまったITエンジニア」達は、そんな奴等をリア充だの何といって、殺意や憎悪まで燃やしている様なくらい煮詰まっている人間たちが、Ｘやネットで珍しくない。

なんなら、もう10年近くこれも、スペインやイギリスやロシアの同僚、そしてイスラエルの上司も予言していた。そして当たっている。

「日本のITエンジニア達は、ITという文化を所謂秋葉原系といったものと相補的になってるアングラ文化から卒業・脱却をしなければいけない。メジャーにならなければならない、でもそれは少なくとも増田君たちの世代では困難以前にできないと思う。」

「内輪に籠ったまま選民思想だけ高め合っても、日本のITエンジニア達の属性は、常に彼らが見下す外の人間に向いている、例えばアニメの様な美少女が、IT分野に投資をしてくれる投資家や政府の役員や政治家たちが、君たちの文化や思想を理解してくれるわけがないことくらいわかってるだろう。」

「いずれ内輪に籠ったまま置いてけぼりになって、他責思想のまま世間からも置いてけぼりにされる。その果てにあるのは犯罪者集団化だ。アメリカでは、そんな連中がネットコミュニティで結びついて、通り魔テロ事件や放火テロなどを起こしているし、各国でも問題になっている。増田くんの国ではまだだだろうけど、それは必ずいずれこのままだとおこる」と

ああ、そうだ、今にして思う。その通りだ。 俺が日本に帰ってきた年、予言の通りの様についに社会との価値観の乖離はピークを迎えていた。さるITエンジニアがJCJK専門の集団痴漢の元締めをしてて捕まって大ニュースになった。IT業界では知らない人間はいないほどの有名なエンジニアが、スパコン詐欺で国相手に巨額の詐欺を働き、捕まって大ニュースになった。同じ年、俺達と同世代のITエンジニアが狂って神戸で通り魔を起こし、金属バットと包丁で5人を殺害した末捕まった。聞けば裁判では、「(聞当時放送していた某なろう系アニメの青髪メイドらしい)アニメキャラと結婚するためには哲学的ゾンビを殺さなければならない」と喚き散らして、あまりの異常さ故、心神喪失で無罪となった、という。

こうした顛末は、俺達の世代の人間たちは図星を隠す様に「偶然だ」と発狂して否定しているが、俺にはわかる。これは偶然ではない、俺たちの世代の「必然」だ。

予言の通りだ、そして、何もITプロダクトは生み出せもしなくなった…高いプライドを抱えたままいつまでも「他者不在」で、何も売れるプロダクトを作れないまま、自己満足の売れない技術や製品を誇っている。そして、それが売れない、評価されない事を、自分たちのことを棚に上げて社会に対して憎悪や怒りを燃やしている声がネットで響き渡り、風の音の様に止むことはない。

俺達の世代の夢は、もはや狂気という時代の空気となってネットと現実社会に憎悪の風を吹き荒らしている。

俺たちは負けてしまったのだ。いや、最初っから勝負にすらなっていなかったのかもしれない。

上司の忠告がこの年になって響く、俺は、俺達は今更パソコンやネットやゲームやアニメ以外の何も始められない。八方手詰りになってしまった、 あれほどテック強者を気取っていた俺達やXの同輩や少し上の先輩たちは、落ちぶれたコンプレックスを他責思想で社会や、手に入れたかった若い美少女や、若さに嫉妬と憎悪で狂い、老いた肉体を曝け出しながら、女叩きにいそしみ、最後には狂って包丁やガソリン片手に通り魔テロだの放火テロだののような凶悪猟奇事件を起こしてニュースになることが、数か月に一度の風物詩になってしまっている。その姿は、2010年初頭の頃の俺達が夢見たデジタル背景に01が流れる格好良すぎる未来とは程遠い。想像もできないほどに。

しかし、何よりも嫌なのが、狂って包丁やガソリン片手に通り魔事件や放火事件を起こして捕まる同年代の奴らが多いのも、言葉は悪いが納得できてしまうところだ。あれだけプライドの高かった俺達は、何も取り戻すチャンスもないままあと40年も生きなければならないのだ。喪失感と承認欲求と肉欲を抱えて…それは、俺たちの世代の病理なのか、俺達がまだあきらめきれぬ夢にもがいている姿なのか。俺にはもう判別がつかない。 それならばいっそ「それを手に入れている存在や社会」に対して、テロを起こして一生消えない被害と傷跡を負わせて、自分も死ぬか刑務所で税金の無駄飯を食らって社会に復讐して「無効試合」という政治的目標を達成したい、と考える奴らが増えるのも、俺達の世代の罪とはいえ致し方ないのだろう。(当然、俺はそんなことする気は毛頭もないが、海外から戻ってきて外から冷静に見て初めて認識できた、あの選民思想や「他者不在」のイキリオタク的内輪のノリが一種の流行だったので、それで狂っていっている奴等の思考回路は理解できてしまう、というだけだ)

俺達はもっと世界を知るべきだった。社会を知るべきだった。他者を理解しようとするべきだったのだ。だがもうできない。 俺達はあまりにも世間と乖離しすぎたまま年を食ってしまった。未だに20代の頃のような感覚で、若い女を飯に誘うなんていう行為を批判されて発狂している存在、あれだけ好きだった萌えアニメの脚本家の些細な言葉尻をとらえて怒り狂って経済テロを敢行するつもりで除名運動まで展開しているはた迷惑な行為を行っている存在…その所作はもはや狂気と病理である。

やり場のない怒りと不甲斐なさを、社会に憎悪として還元している…俺達の世代の夢の果てがこれである。

ああ、ITで世界を変える、自身の運命さえ変えられる。アニメの様な美少女たちと浮名を流し、SNSやマスメディアに取り上げられ、キラキラ職場でキラキラ人生を送り人生逆転をする。そんな野望と夢の旗を掲げた俺達の現実が、そこに待ち受けていた。 もはや得意のIT知識ですら時代遅れ、露悪的な文章はAIで書かれた物かどうかも見分けられずにAIだと叫ぶほど技術的感性は衰え、 老いと時代に取り残される恐怖と、若さへの嫉妬と憎悪、もはや不能になりつつあるのになお焦がれる若い女性への肉欲、そして自分たちを理解しなかった社会への怨念と殺意と憎悪に突き動かされ、包丁とガソリンと、俺達が信じたITとSNSを手に政府や社会にテロを敢行し、社会や政府が折れてアニメの様な美少女を宛がってくれて、キラキラ職や特権を禅譲して人生一発逆転ができると狂気にも似た願いを託し、一発逆転を夢見て社会を襲うテロリストの群れのような姿だった。

これが散々意識高い系を気取っていた俺達の世代のエンジニアがたどり着いた「令和に生み出せたプロダクト」だと思うと、涙が止まらなくなる。

俺達の世代がよく口にしていた「ロジカルシンキング」で考えた結果がこれなのだろうが、確かに理屈の上では、俺達の世代の声を代弁して、今の様に「狂ってしまった俺達と同世代の奴等」がこのままネットで、そして現実で包丁やガソリンを片手にテロまがいのことを続けていれば、そのうち政府や社会は折れて、キラキラ人生やアニメの様な美少女を宛がってくれるのかもしれない。という「現実的予測」をはじき出した結果なのだろう。

だがそれは、未だにAIがシンギュラリティが起こすなどと、１９９９年のアルマゲドン思想の焼き直しを叫んでいる程、現実を理解していない机上の空論にすぎぬ。例え数多の俺たちが耳をふさいで内輪に籠って逃げ出していた「現実問題」をすべてはじき返したところとて、俺達の世代が夢にまで見たキラキラ人生とアニメの様な極上の美少女をその手に抱いた時、あとに残るのは勃起もしなくなった老いた肉体と、取り返しのつかない社会インフラが壊れた傷跡のみ、だろう。そんなことすら、俺たちはわからなかったのだ。いや、わかろうとすることを拒否していたのだ。 自省的に同じ世代故、あえて「俺達」という言葉を使うが。俺たちの世代は狂ってしまったのだ。どうしようもないほどに、もはや、俺たちの世代のITエンジニア達は、犯罪か社会への憎悪か、テロリズムでしか、「俺達以外の世界との対話」ができないほどに歪んでしまったのだ。

だからあれだけ勇ましくIT技術の未来や、ICTで世界を変えるといっていたにもかかわらず、俺たちの世界の有名人たちも含め、JCJK専門の集団痴漢の元締めをやって捕まり、政府相手に巨額のスパコン詐欺を働き懲役5年の実刑判決を受け、青髪メイドアニメキャラの知人という存在しない人間と結婚するためには、哲学的ゾンビを殺さなければならないと称して、狂気の果てに意識だけが異世界へと飛んだのか、バットと包丁で通り魔テロを起こした末、5人を殺害して裁判へ引っ立てられた。

･･･俺たちが信じた夢の果てが、この姿である。そして、こんな予備軍はネットやX、このはてなにもわんさかといる。風に乗って増えていく種は、やがて土と同じように芽を出している。この間でさえ、町田で俺達と同世代の人間が狂気の通り魔事件を起こした。それは、俺達という世代の病理そのものである。

俺は流石に追い込まれてワクチン陰謀論だとか、男女叩きだとか、暇アノンやMAGAにまで堕ちることはないと思うが。すでにネットの同年代や少し上の層は、それでも喪失感と劣等感と自分自身の怒りを社会に他責でぶつけて怨念が渦巻いている。

俺はそんな悲劇を眺めながら、今日も胸がいっぱいなまま、IT業界の片隅で生きている…過去を悔いながら、過去の遺産で喰いながら。

■ 追記

https://anond.hatelabo.jp/20251006123907

(2025/10/05)

Web制作会社で働いているのだが、 最近、本当に悩ましいことが増えた。 クラ..

• Web制作会社で働いているのだが、 最近、本当に悩ましいことが増えた。 クラ..

Web制作会社で働いているのだが、

最近、本当に悩ましいことが増えた。

クライアントとの打ち合わせで、毎回のように飛び出してくる。

「AIで作れば安くできるんですよね？」

というフレーズだ。

今年に入ってから、この種の問い合わせが明らかに増えた。ChatGPTが話題になったあたりから、みんなAIさえ使えばなんでも簡単にできると勘違いしているように見える。

つい先週も新規のお客さんから「ホームページをAIで作ってほしい」と言われた。予算を尋ねると「AIなら10万円でいけるでしょ？」と返される。普通なら100万円はくだらないボリュームの案件なのにだ。

そこで説明する。「AIは便利な道具ではあるけれど、デザインの方向性を決めたり、業界や商品ごとの細かなニュアンスを理解したり、調整したりするのは結局人間の仕事なんです」と。

だけど相手は納得しない。「YouTubeで、AIが全部やってくれるって見ましたよ」と主張する。どうやら有名インフルエンサーの動画でも信じきっているようだった。

実際、AI関連のツールはどんどん進化しているし、ロゴの生成や文章作成、ある程度のデザインまでなら部分的には取り入れている。それでも本当に活用できるのは全体のせいぜい三割程度。残り七割は変わらず人力で地道に積み上げていく作業だ。

さらに厄介なのが「AIで作ったなら修正も無料で簡単でしょ？」という無邪気な要求。AIで作ったからといって手直しが不要なわけじゃない。むしろAIの出す“それっぽい”成果物をこっちの意図に合わせて直す方が、一から組み立てるより手間がかかる事もある。それを伝えても「よく分からないけど、AIなんだから簡単でしょ？」で流されてしまう。

とうとう限界がきた。あるクライアントが「他社はAIで半額で引き受けてくれるそうです」と言い出し、そちらに乗り換えてしまった。その会社の納品サイトを見てみた。テンプレートにAI作成の画像・文章をはめ込んだだけの、素人仕事のような出来栄えだった。しかも半年後にはアクセス数が激減、SEO対策も何もなかった。

結局そのクライアントはまたこちらに戻って来て、「やっぱりちゃんとしたものを作ってほしい」と言う。でも説明は最初からしていたはずだったのに、なぜ素直に信じてもらえないのだろう。

業界は今、はっきり二極化している。「AI！AI！」と叫んで低価格・低品質なサービスを提供する会社と、AIを適切に使いながらも人間の技術と経験を大切にする会社。そしてお客さんも、「とにかく安ければ良い」人と、「品質を求める」人に分かれつつある。

この先、自分たちはどちらを選ぶべきなのか。AIブームに便乗して価格競争に飛び込むべきか、それとも品質にこだわり続けるべきか。AIが人間の仕事を奪うという話はよく聞くけど、現場で実際に感じるのは、むしろAIのせいで仕事の価値そのものが薄まることへの不安の方が強い、ということだ。

MEMO:

• エンジニアとしては粗製濫造の仕事を大量に請けて収入をブーストさせつつ、高品質なプロダクトを生産する技能を保持して崩壊に備えるという両得の戦略を取るのが良さそう

(2025/10/04)

Stop Avoiding Politics

• Stop Avoiding Politics – Terrible Software

要約:

■ 1. 政治に対する一般的な誤解

• エンジニアの典型的反応: 「政治」という言葉を聞くとレモンをかじったような顔をする
• 条件付けられた信念: 職場の政治は操作的な出世主義者が行う汚いゲームで、「本物の」エンジニアはコードに集中すべきだと信じ込まされている
• 著者の過去: 何年もエンジニアとして政治を憎むことを誇りのバッジのように身につけていた。そんなナンセンスの上にいると思っていた
• 現在の認識: 政治は問題ではない。悪い政治が問題。政治が存在しないふりをすることが悪い政治を勝たせる方法

■ 2. 政治の本質的定義

• 人間の調整メカニズム: 政治とは人間がグループで調整する方法に過ぎない
• 見えないネットワーク: あらゆる組織に存在する関係性、影響力、非公式な権力の見えないネットワーク
• 参加拒否の帰結: 参加を拒否してもそれが消えるわけではない。決定があなた抜きで行われることを意味するだけ
• 避けられない存在: 政治は存在し、関与しないという選択は単に自分を不利にするだけ

■ 3. 悪い技術的決定が通る理由

• よくある事例: 過度に複雑なアーキテクチャの採用、誰もが間違っていると知っているベンダーの選択、実際に機能していたプロジェクトの中止
• 真の原因: 決定権者が愚かだからではない。正しい情報を持つ人々が部屋にいなかったから
• 「政治をしない」結果: 彼らは「政治をしなかった」
• 勝者の特徴: 影響力の仕組みを理解している誰かがその部屋にいて、自分の主張をし、連合を構築し、宿題をしたことを示した
• 勝利の理由: アイデアが優れていたからではなく、他の人が「政治には純粋すぎる」間に彼らが現れてプレーしたから

■ 4. アイデアは人を通じて伝わる

• 基本原則: アイデアは話さない。人が話す
• 組織のダイナミクスを理解する人: 関係を構築し、政治をプレーする方法を理解している人々のアイデアが聞かれる

• 政治的スキルの実態:

  • チーム間で強い関係を構築する
  • 異なるステークホルダーが何に動機づけられているかを理解する
  • コンセンサスを構築する方法を知っている
  • 技術的決定を非技術的ステークホルダーに理解できる言語で説明する時間を取る
  • 別のチームの誰かとコーヒーを飲んで彼らの課題を理解する

• これらはすべて政治: 良い結果のために関係性と影響力について戦略的であること

■ 5. 最高の技術リーダーは政治的

• 別の呼び方: 彼らはそれを「ステークホルダー管理」「アラインメント構築」「組織的認識」と呼ぶ
• 本質: しかしそれは政治であり、彼らはそれが得意
• 政治を拒否するエンジニア: 会社が悪い技術的決定をすることについてよく不満を言う
• 矛盾: しかし彼らはそれらの決定に影響を与えるために必要なことをする意志がない
• 幻想の世界: 技術的メリットだけで結果が決まる世界を望んでいる。そんな世界は存在せず、これまでも存在したことがない

■ 6. 政治的スキルの二面性

• 陰謀的裏切り者になることではない: 同じ特性が使い方次第でポジティブにもネガティブにもなる(「Your Strengths Are Your Weaknesses」で書いたように)
• 政治も同様: 操作や自己宣伝のために政治的スキルを使うこともできるし、良いアイデアを実装しチームを悪い決定から守るために使うこともできる

■ 7. 良い政治の実践例

• 必要になる前に関係を構築:

  • データチームの誰かとのランダムなコーヒー
  • 6ヶ月後、彼らがあなたのデータパイプラインプロジェクトのためにエンジニアリングリソースを得る最大の支持者になる

• 真のインセンティブを理解:

  • VPは美しいマイクロサービスアーキテクチャには関心がない
  • 彼らは機能をより速く出荷することに関心がある
  • 技術提案を彼らが実際に気にすることの観点でフレーム化する

• 効果的に上司を管理:

  • マネージャーはあなたが見ていない競合する優先事項をジャグリングしている
  • 重要なことについて情報を提供し続ける
  • 潜在的な解決策とともに問題を早期にフラグする
  • 彼らが良い決定をするのを助ける
  • 彼らがあなたを信頼して物事を処理できると思えば、重要な時にあなたのために戦ってくれる

• Win-Win状況を作る:

  • リソースのために戦う代わりに、必要なものを得ながら他のチームを助ける方法を見つける
  • ゼロサムゲームである必要はない

• 可視性を持つ:

  • 素晴らしい仕事をしても誰も知らなければ、本当に起こったのか?
  • 勝利を共有し、全体会議でプレゼンし、後で誰もが参照する設計ドキュメントを書く

■ 8. 良い政治の不在がもたらすもの

• 良い政治の代替: 良い政治の代替は政治なしではなく、悪い政治がデフォルトで勝つこと
• 具体的な帰結:
  • 間違っている大声の人が、正しい静かな人が発言しないために自分の方法を得る
  • 良いプロジェクトが誰も擁護しなかったために死ぬ
  • 才能のある人々が組織のダイナミクスをナビゲートできなかったために去る

■ 9. 結論

• 幻想を捨てる: 政治の上にいるふりをやめろ。あなたはそうではない。誰もそうではない
• 唯一の問題: 唯一の問題は、それが得意になるか、既に得意な人々に負け続けるかだけ

(2025/10/04)

The Software Essays that Shaped Me

• The Software Essays that Shaped Me · Refactoring English

要約:

■ 1. "The Joel Test: 12 Steps to Better Code" by Joel Spolsky (2000)

• 著者の評価: Joel Spolskyは史上最高のソフトウェアブロガー
• 12の質問:
  • ソース管理を使っているか
  • ワンステップでビルドできるか
  • 毎日ビルドしているか
  • バグデータベースがあるか
  • 新しいコードを書く前にバグを修正しているか
  • 最新のスケジュールがあるか
  • 仕様書があるか
  • プログラマーには静かな作業環境があるか
  • お金で買える最高のツールを使っているか
  • テスターがいるか
  • 新しい候補者は面接中にコードを書くか
  • 廊下でのユーザビリティテストを行っているか
• メタポイント: 質問そのものではなく「雇用主は開発者を尊重しているか」を問うている
• 評価基準: 雇用主が開発者の時間と集中力を、安い賃貸料や短期的な納期よりも優先しているかを評価
• 時代背景: ドットコムブーム最盛期に発表され、スキルのある開発者が貴重なリソースであることをまだ誰もが認識していなかった
• 影響: キャリアを通じてJoel Testでスコアの高い雇用主を探し、その地図を与えてくれたJoelに感謝している

■ 2. "Parse, don't validate" by Alexis King (2019)

• 主題: Haskellの型システムを活用する技法だが、静的型をサポートする言語(Go、C++、Rust)で応用可能
• 核心的アイデア: データを検証するときは常に新しい型に変換すべき
• ナイーブな解決策の問題:
  • コードがデフォルトで安全でない
  • すべてのユーザー名を検証することを覚えておく必要がある
  • 誤って検証せずに処理するコードパスを作りやすい

• Alexisの解決策:

  • カスタム型Usernameを使用
  • parseUsername関数のみがUsernameを作成でき、返す前に検証ルールを適用
  • Username インスタンスがあれば、それは有効なユーザー名を含んでいる必要がある
  • 信頼できない入力は常にstringであり、Username を期待する関数にstringを渡すことはできない

• 影響: 型システムがアプリケーションのセキュリティと信頼性を向上させる上でいかに価値があるかを理解した

■ 3. "No Silver Bullet" by Fred Brooks (1986)

• 出典: 『人月の神話』に収録されたエッセイ
• 二つの複雑性:
  • 本質的複雑性(Essential complexity): ツールやハードウェアに関係なく絶対にしなければならない作業(例:営業担当者のボーナス計算式の定義とエッジケースの処理)
  • 偶発的複雑性(Accidental complexity): それ以外のすべて(メモリリーク対応、コンパイル待ち、サードパーティライブラリの使い方の理解)
• 結論: ツールやハードウェアの進歩が開発者の生産性を10倍向上させることは不可能
  • 偶発的活動をゼロ時間に縮小しても、それが全作業の9/10以上でない限り、桁違いの改善は得られない
• ソフトウェア構築の難しい部分: 仕様、設計、この概念的構造のテストであり、それを表現し表現の忠実性をテストする労働ではない
• ノーコードプラットフォームへの安心感: プラットフォームは偶発的複雑性に焦点を当てており本質的複雑性には対応できないため、開発者を置き換えることはできない
• 現代AIの挑戦: AIは実際に本質的複雑性を減らすため、Brooksの理論に疑問を投げかけている。AIは不完全または矛盾した仕様を受け取り、類似の仕様から隙間を埋めることができる

■ 4. "Choices" by Joel Spolsky (2000)

• 主題: ユーザーインターフェースの作成とユーザーに力を与える際の微妙なコスト
• 核心的原則: オプションを提供するたびに、ユーザーに決定を求めている。一般的に、人々が下さなければならない決定の数を最小限に抑えるべき
• Windows 98の例: ヘルプドキュメントを検索しようとすると、データベース最適化に関する情報のない決定を求める馬鹿げたダイアログが表示される
• 問題点: ユーザーがヘルプを得ようとしているときに中断し、決定を回避してユーザーに押し付けている
• 応用範囲: グラフィカルユーザーインターフェースだけでなく、コマンドライン、他の開発者が書いた関数の呼び出しなど、どこでも考慮すべき
• 問いかけ: ユーザーが気にすることに対する力を与えながら、ユーザーに代わって有用な決定を下すことができるか

■ 5. "Application compatibility layers are there for the customer, not for the program" by Raymond Chen (2010)

• 著者: Microsoft Windowsチームで最も長く勤めている開発者の一人
• 顧客からの要求: Windows XP用に設計されたプログラムがVistaで問題が発生するが、XP互換モードに設定すると正常に動作する。インストーラーを変更してVistaで自動的にXP互換モードで実行されるようにするにはどうすればいいか
• Raymondの比喩: 「普段はペットショップの前の歩道にゴミを捨てている。毎朝、開店時に誰かがゴミを掃除してくれる。しかし日曜日はペットショップが開いていないので、ゴミはそのまま。日曜日もペットショップを開けてもらうにはどうすればいいか？」
• 著者の評価: 比喩は面白いが、Raymondは実際には間違っている。1回のリリース後にアプリを壊さないことを期待する開発者を嘲笑っている
• 教訓: ユーザーの行動に影響を与えることについての優れたレッスン。ユーザーを助けるために何かをしてもらいたい場合、ユーザーの視点から最も抵抗の少ない道を慎重に考える必要がある

■ 6. "Don't Put Logic in Tests" by Erik Kuefler (2014)

• 著者の衝撃: 単体テストを愛していたのに、このエッセイでキャリア全体を通じてひどいテストを書いていたことが明らかになった
• 従来のアプローチの問題: テストコードを本番コードのように扱い、冗長性を排除するためにヘルパー関数、変数、ループを追加していた
• 新しい認識: テストコードと本番コードは全く異なる目標と制約を持つ
• 良いテストコードの特徴: 何よりも明確であるべき。テストコードには独自のテストコードがないため、正確性を確認する唯一の方法は目視検査。読者にどのような動作をアサートしているかを一目瞭然にすべき
• 許容されるトレードオフ: この目標のために、複雑さを減らすために冗長性を受け入れることができる

■ 7. "A little bit of plain Javascript can do a lot" by Julia Evans (2020)

• 著者の背景: キャリアの最初の10年間はデスクトップアプリとバックエンドサーバーのコードのみを書き、2017年までHTMLやJavaScriptに取り組まなかった
• 当初の印象: JavaScriptは10日間でハックされた言語で、ブラウザごとに動作が大きく異なる。モダンで洗練されたフレームワークが必要
• 試したフレームワーク: Angular、React、Vue。Vueを学んだが、依存関係の問題やフレームワークの落とし穴に膨大な時間を費やした
• Juliaのエッセイの影響: JavaScriptを修正する必要があると確信していたが、実際に試したことがなかった
• プレーンJavaScriptの実験: TinyPilotのプロトタイプでVueを使う予定だったが、プレーンJavaScriptでどこまで行けるかを試した(フレームワークなし、ラッパーライブラリなし、ビルドステップなし、Node.jsなし)
• 結果: フレームワークに切り替える必要がある問題に遭遇することを期待していたが、決して起こらなかった
• フレームワークからの自由: ランタイムエラーが発生したとき、スタックトレースはminify・変換されたものではなく、書いたコードそのものをデバッグできる
• バイアスの誤り: JavaScriptに対するバイアスは間違っていた。モダンJavaScriptは素晴らしく、ラッパーライブラリから多くのアイデアを吸収したため、もはやラッパーは不要
• 2020年以降: JavaScriptフレームワークやビルドステップを新しいプロジェクトに統合しておらず、振り返ったことはない。プレーンJavaScriptでフレームワークの利点の90%を頭痛の5%で得られる

■ 8. "Choose Boring Technology" by Dan McKinley (2015)

• 特異性: 実際には読んだことがない。人々がこのエッセイを引用し、アイデアを理解したら直感的に感じたため、読む必要がなかった
• Danの議論: 新しいプロジェクトを始めるとき、話題性のある最先端技術を使いたくなる誘惑がある。Googleが発表した新しいデータベースはexabytesまでスケールし、Postgresより40%速く、コストは20%
• 実際の問題: 新しい技術にはバグと弱点があるが、まだ明らかではない。遭遇したときに行き詰まる。Postgresには30年の実績があり、遭遇する可能性のあるあらゆる問題に対して実証済みのソリューションがある
• 戦略的使用: 新しい技術を時々使うべきだが、戦略的かつ限定的に。すべてのビジネスは3つの「イノベーショントークン」を得る。派手な新しいデータベースが欲しければ、トークンの1つを使う必要がある
• Juliaのエッセイとの相乗効果: フロントエンドフレームワークで時間を無駄にする前にどちらかを読んでいればよかった

■ 9. "I've locked myself out of my digital life" by Terence Eden (2022)

• 著者: 楽しくて折衷的なテクノロジーブロガー
• シナリオ: 雷が家を直撃し、すべての所有物が破壊されたらどうなるか。パスワードマネージャーにすべてのパスワードを保存しているが、すべてのデバイスが破壊されたらアクセスできない。ハードウェアパスキーも家の中にあった
• 従来の安心感: 冗長ドライブにすべてを保存し、3大陸2ベンダーでオフサイトバックアップがあるため安全だと感じていた
• 新しい認識: すべてのデバイスを同時に破壊する可能性のある多くの信頼できる脅威:火災、洪水、電気サージ、刑事捜査。すべてのデータは頭の中にあるパスワードで暗号化されているため、記憶喪失、無能力化、死亡も追加される
• オンラインサービスの問題: ユーザーが災害から回復するのを助けるのが下手。多くのサービスは、電話、メールアカウント、所有するすべてのデジタルデバイスを失うことは不可能だと仮定している
• 影響: どのサービスとデバイスが重要か、Terenceが説明したシナリオからどのように回復できるかを考えるようになった。次にラップトップを購入したとき、家のデバイスなしでパスワードマネージャーと重要なアカウントへのアクセスを回復できるかをテストするために図書館でセットアップした

■ 10. Bonus: Brad Fitzpatrick on parsing user input (2009)

• 出典: Joel Spolskyの絶賛レビューの結果読んだ『Coders at Work』(優秀なプログラマーへのインタビュー集)
• Brad Fitzpatrick: LiveJournal、Memcachedの作成者。当時28歳で本の中で最年少、最も汚い言葉を使う最も面白いプログラマー
• ソフトウェアエンジニアリングの倫理についての質問に対する熱烈な暴言: 「クレジットカードフォームで誰もがスペースやハイフンを入れられるようにして欲しい。コンピューターはそんなクソを削除するのが得意なんだ。数字のフォーマット方法を俺に指示するな」
• 思い出すタイミング: ウェブフォームに電話番号を貼り付けようとしたとき、括弧やスペースが許可されていないと文句を言われる。または、括弧のために電話番号が切り捨てられ、括弧が許可されていないと文句を言われる
• Brad Fitzpatrickの声: ソフトウェアで入力フィールドを作成し、予期しない文字について考えるとき、「コンピューターはそんなクソを削除するのが得意なんだ」というBrad Fitzpatrickの声が聞こえる

(2025/10/03)

The Magic of Claude Code

• The Magic of Claude Code

要約:

■ 1. ObsidianとClaude Codeの組み合わせ

• Obsidianの特徴: Markdownファイルとしてコンピューター上に保存される(NotionやEvernoteとの違い)
• AI coding toolsとの相性: プレーンテキストファイルであることがAIコーディングツールにとって理想的なターゲットとなる
• ノート取りOSへの進化: Cursorでvaultを開くことから始まり、最終的にSSH経由で携帯からアクセスできるサーバーを自宅に立ち上げるまで依存するシステムに成長
• Dan ShipperのAI & I Podcast: このセットアップについて詳しく語った(トランスクリプトやポッドキャストで詳細確認可能)

■ 2. Claude CodeがCursorより優れている理由

• すべてにおいて優れているわけではない: 特定の状況において例外的に優れた要素が組み合わさって機能する
• 既存コードベースへの適用を超える: 新しいものを完全に構築する用途にますます使われている
• ターミナルベースのアプローチ: アクセシビリティとネイティブUnixコマンド統合のトレードオフ

■ 3. Unix哲学の原則

• Doug McIlroyによる定式化(1978年Bell System Technical Journal):

  • 各プログラムは一つのことをうまくやる。新しい仕事には、古いプログラムに新機能を追加するのではなく、新しく作る
  • すべてのプログラムの出力が別の未知のプログラムの入力になることを想定する。余計な情報で出力を散らかさない。厳密な列形式やバイナリ入力形式を避ける。インタラクティブ入力を強制しない
  • ソフトウェアやOSを早期に試せるように設計・構築する(理想的には数週間以内)。不格好な部分を捨てて再構築することを躊躇しない
  • スキルのない人手よりもツールを使う。そのためにツールを構築し、使い終わったら捨てることも厭わない

• Peter H. Salusによる要約(1994年A Quarter-Century of Unix):

  • 一つのことをうまくやるプログラムを書く
  • 一緒に動作するプログラムを書く
  • テキストストリームを扱うプログラムを書く(普遍的なインターフェースだから)

■ 4. LLMとUnix哲学の親和性

• 50年前の原則: これらの原則はまさにLLMがツールを使いたい方法と一致する
• パイプ処理: モデルは常に出力を入力に「パイプ」している(その間に独自のファジネスを使用)
• Unixの|コマンド: 一つのコマンドの出力を別のコマンドの入力に繋げる
• ツールの失敗パターン: モデルがツールを効果的に結合できない場合、ほぼ常にツールが過度に複雑だから
• 完璧な適合性: Unixを動かすコマンドがLLMによる使用に完璧に適している理由は、シンプルであることと十分に文書化されていること

■ 5. ファイルシステムアクセスの重要性

• The Pragmatic Engineerの記事: Claude Codeがどのように構築されているかの深掘り記事で答えが明らかになった
• ChatGPTとブラウザ版Claudeの致命的な欠陥:
  • 会話間でメモリがない
  • 狭いコンテキストウィンドウ
• ファイルシステムによる解決: Claude Codeは自分自身にノートを書き、知識を蓄積し、継続的な集計を保持する。状態とメモリを持ち、単一の会話を超えて考えることができる
• すべてを変える: ファイルシステムアクセスがゲームチェンジャーとなる

■ 6. AI Overhang(AI能力の余剰)

• 2022年のGPT-3 API: モデルがその時点より良くならなかったとしても、ユースケースを発見するのに10年かかると予測していた
• 実際の進化: 推論モデルがツール呼び出しを信頼できるものにした
• Product Overhang: モデルが特定のことをできるのに、AIが動作する製品がその能力を捉えるように構築されていないこと
• Boris Cherneyの発見: Claudeがファイルシステムを探索することは純粋なproduct overhangであり、モデルには既にその能力があったが、その能力を中心に構築された製品がなかった
• 設計哲学: Claude Codeは、過度に設計されたインターフェースを通じて制限するのではなく、モデルの能力を捉えることで信頼できるエージェントシステムを構築するための青写真として機能する

■ 7. コードを超えて

• Claudesidianのオープンソース化: Claude Code + Obsidianセットアップで使用するツールとコマンドをまとめたもの
• アップグレードツール: 中央で変更が行われた場合、それを自分のClaudesidianに取り込み、AIが更新されるファイルに変更を加えたかをチェックし、スマートにマージを試みる
• Unix哲学の踏襲: シンプルで、一つのことをうまくやり、一緒に動作する構成可能なツール

■ 8. Inbox Magic(開発中プロジェクト)

• Gmail toolsへのアクセス: メールEAのように動作するClaude Codeリポジトリ
• 現在の機能:
  • 検索実行やメール送信
  • トリアージ
  • メールでの文体をトレーニングし、より効果的にメールを下書きする
• 高度な機能の可能性: 受信トレイ内のすべての旅行関連メールを見つけ、旅行習慣のプロファイルを構築し、ChatGPT/Claudeが好みに合わせた旅行リサーチを行えるようにする
• ファイルへの書き出し: ChatGPTとClaude Codeは両方ともメールにアクセスできるが、通常は一度に1〜2通のみ。このシステムはファイルに書き出したり多くのトリックを実行できる

■ 9. 重要なポイント

• ファイルシステムの活用: LLMのメモリと状態の欠如を回避するための優れたツールであり、もっと頻繁に使用されるべき
• ツール呼び出しの設計: Unix哲学に従うことに集中する
• Claude Codeの青写真: ファイルシステム + Unix哲学が、今日浮かんでいる複雑なマルチエージェントシステムではなく、信頼できてデバッグ可能なAIエージェントを構築するためのテンプレートであるべき
• 実装の戦術: ツール呼び出しを自分のプロジェクトに組み込む際は、シンプルに保ち、メインモデルスレッドがそれらを「パイプ」できるようにすることが鍵
• 解決すべき課題: すべてのエージェント/チャットボットにおいて、コンテキストウィンドウを通さずに物事をパイプする能力が必要
• ユースケースの発見: LLMのユースケースを見つけられない人は十分に努力していない

(2025/10/02)

WEBデザイナー「あの、大変恐縮ですが、先々月に納品した件、ご入金はまだでしょうか・・・？」

WEBデザイナー「あの、大変恐縮ですが、先々月に納品した件、ご入金はまだでしょうか・・・？」

元請け「実はね、まだクライアントから入金がないんだ。ぼくたちも困っててね。だからまだ振込はできない。遅れててごめんね。ぼくからも催促しておくからね。」

みたいな寝言を元請けが平気な顔で言ってしまっているケースをたまに聞くけど、下請けが元請けに納品することと、元請けが顧客からお金もらっているかどうかは何も関係ない。

下請けがやることやってたら、クライアントからお金もらっていようが、もらってなかろうが、相手の仕事に感謝しつつすみやかにお支払いさせていただくのが当たり前だと思っているのですが、違うんですかね？

@Okamoto_Lexa

MEMO:

• 今ではフリーランス新法でそういうのは禁止されていると思うのだが

(2025/10/02)

システムを作る人がまず理解すべきシステム思考の基礎

• システムを作る人がまず理解すべきシステム思考の基礎 - じゃあ、おうちで学べる

要約:

■ 1. システム思考の本質と必要性

• 定義: 物事を個別に捉えるのではなく、全体の関係性や相互作用を理解する考え方
• 普遍的スキル: どんな分野でも応用できる基本的な教養であり、システムを構築する立場の人には特に重要
• 実践としての性質: システム思考は知識ではなく実践であり、テニスと同様に本を読むだけでは身につかず日々の開発の中で体得していく必要がある
• プラモデルと生態系: プラモデルは説明書通りに組み立てれば完成形が予測できるが、実際のソフトウェアシステムは生態系に近く、すべてが相互に影響し合い予測困難な振る舞いを見せる
• 現代開発の特徴: マイクロサービス、API連携、非同期処理、分散システムでは個々の部品の品質だけでなく相互作用が全体の振る舞いを決める

■ 2. 今日から始められる小さな習慣

• 違和感に気づく: バグが発生したらすぐに修正せず立ち止まって「このバグ、前にも似たようなことがあったな」という違和感に気づく
• 多角的な問いかけ: 技術的な問題か、仕様の理解が曖昧だったのか、チームのコミュニケーションに課題があったのかなど多面的な視点で問いかける
• 図を描く習慣: コードを変更する前に紙やホワイトボードに簡単な図を描き、どのモジュール・チーム・ユーザー機能に影響するかを考える(最初は5分で構わない)
• PRの説明文の充実: 「何を」変更したかだけでなく「なぜ」その実装を選んだのか、他にどんな選択肢があったのか、何を考慮したのかを書く(3ヶ月後の自分のため)
• 特別なツール不要: これらは特別なツールも会議も不要で、明日のコーディングから始められる

■ 3. 線形思考の限界

• 線形思考の特徴: 予測可能で、合理的で、再現可能で、手続き的で、二元論的で、トップダウンで、制御に関心を持つ思考
• 因果関係の単純化: 「if this, then that」の因果関係に支配され、ソフトウェアシステムが意図通りに正確に動作することを期待する
• 非線形性の現実: APIの応答速度改善が別のサービスに負荷を集中させる、キャッシュ導入がデータ整合性問題を頻発させるなど、単純な原因と結果の連鎖ではない
• 予測不可能性: 部分間の関係が何が起こるかに影響を与え、一つの変更が思わぬ波及効果を生み出し、事前に完全に予測することはできない
• システム思考への第一歩: 非線形性を理解し、それと共に働く方法を学ぶこと

■ 4. システムの定義

• 包括的な定義: 共有された目的に奉仕するために相互作用し相互依存する、相互関連したハードウェア・ソフトウェア・人々・組織・その他の要素のグループ
• 全体の構成: 開発しているWebアプリケーション、それを使うユーザー、運用チーム、ビジネス要求のすべてが一つのシステムを構成している
• システム思考の定義: 一緒に実践すると非線形思考スキルを向上させる、基礎的な思考実践のシステム

■ 5. 生産と理解の非対称性(AIコード生成の事例)

• AIによる開発速度の向上: 数分で数百行のコードが生成されるが、修正しようとした時に予想以上に時間がかかる
• 非線形性の典型例: コードを安全に変更するにはまず理解が必要で、コードが流入する速度と人間が理解する速度の間に決定的な非対称性がある
• 氷山モデルでの分析:
  • 出来事:「AIで開発が速くなった」
  • パターン:「変更に時間がかかるようになった」
  • 構造:「生成速度と理解速度の不均衡」
  • メンタルモデル:「速さこそが価値」「生産量で生産性を測る」
• レバレッジポイント:
  • メンタルモデルの変革:「速く書けることが価値」から「理解できることが価値」へ
  • フィードバックループの再設計:AIが生成したコードに「なぜこのアプローチを選んだか」を必ず追記、コードレビューで「理解できるか」をチェック
  • 適切な制約:プロトタイピングではAIを積極的に使い、本実装では人間が設計してから使う

■ 6. 概念的完全性

• フレッド・ブルックスの言葉: 「概念的完全性はシステム設計において最も重要な考慮事項である」
• 定義: システム全体が一つの統一された設計思想で貫かれている状態
• Unixの例: 「すべてはファイル」という設計思想により、cat、grep、sedといったシンプルなコマンドを組み合わせて複雑な処理ができる
• 欠如した状態: あるAPIはRESTful、別はRPC風、あるデータはJSON、別はXML、エラーハンドリングも部分によって異なるなど、多くの良いアイデアが調整されずにバラバラに実装されている
• 保つための実践: 「このシステムの核となる考え方は何か」を常に問い続け、新機能が既存の設計思想と一致しているか確認する
• 効果: システムを理解しやすく、保守しやすく、拡張しやすくする

■ 7. 関係性が効果を生む

• ドネラ・メドウズの定義: 部分が一緒になって、各部分が単独で生み出す効果とは異なる効果を生み出すこと
• マイクロサービスの例: 個々のサービスは完璧に動作していても、通信パターン・データの流れ・障害の伝播の仕方によってシステム全体の振る舞いは大きく変わる
• ECサイトの具体例: セール時に検索サービスへのアクセスが急増すると、その負荷がカートサービスに波及し最終的に決済が遅延する
• 人も含むシステム: コードだけでなく、それを書く開発者、使うユーザー、運用するチーム、すべてがシステムの一部
• コンウェイの法則: システムを設計する組織は、その組織のコミュニケーション構造をコピーした設計を生み出す
• 技術と組織の不可分性: 技術的負債を解消するだけでは不十分で、なぜその負債が生まれたかという組織的・文化的な要因も同時に扱う必要がある

■ 8. 反直感性

• 定義: 直感的に正しいと思える解決策が、実際には問題を悪化させる現象
• ブルックスの法則: 遅れているソフトウェアプロジェクトに人員を追加すると、さらに遅れる
• 理由: 新メンバーの教育コスト、コミュニケーションパスの増加(n人なら n(n-1)/2 の組み合わせ)、意思決定の複雑化などの隠れたコストが追加された人員の生産性を上回る
• 日本の開発現場の例:
  • 品質が悪いからテストを増やす→無意味なテストが増えるだけで本質的な品質は改善せず、テストのメンテナンスコストが増大
  • ドキュメントが足りないから全てを文書化する→誰も読まない膨大なドキュメントが生まれ、更新されずに陳腐化
• 真の解決策: 品質が悪いなら設計を見直す、ドキュメントが足りないならコードを自己文書化する、プロジェクトが遅れているならスコープを削減する
• 重要な視点: 「この解決策を実施したら、他の部分にどんな影響があるか」を考え、真の解決策は問題とは違う場所にあることが多い

■ 9. 氷山モデル

• 4つの層:
  • 出来事(Events):目に見える現象(例:本番環境でNullPointerExceptionが発生)
  • パターン(Patterns):繰り返される傾向(例:毎週金曜日のリリース後に似たようなエラーが発生)
  • 構造(Structure):パターンを生む仕組み(例:金曜日は全員がリリースを急ぐためレビューが形骸化)
  • メンタルモデル(Mental Models):根底にある考え方(例:週末前には必ずリリースしなければならない)
• 表面的対応の限界: 出来事のレベルで対応(バグを修正して終わり)するだけでは同じ問題が繰り返される
• 本当の解決: より深い層にアプローチすることで、構造やメンタルモデルを変える
• 具体的な使い方: 違和感からパターンを見つけ、なぜパターンが繰り返されるのかを考えて構造を見出し、「私たちは何を当たり前だと思っているのか」と問うことでメンタルモデルに気づく
• 階層的分析: この階層的な分析がシステム思考の核心

■ 10. 実践への統合

• 理論ではなく道具: バグに遭遇したとき氷山モデルを思い出す、新機能を設計するとき関係性を考える、直感的な解決策を思いついたとき反直感性を疑う
• 生態系としての設計: プラモデルのように部品を組み立てるのではなく、生態系のように全体の相互作用を設計する
• 調和と進化: 完全な制御を求めるのではなく、システムと調和し共に進化していく
• 準備完了: 基礎を理解したら、自己認識、問いの立て方、フィードバックループの設計、パターンの見つけ方など明日から使える実践的な方法に進む

(2025/10/02)

過剰で厳格なCode of Conduct(行動規範)が多くのオープンソース・プロジェクトに不要な理由

• 過剰で厳格なCode of Conduct(行動規範)が多くのオープンソース・プロジェクトに不要な理由 – Shuji Sado

要約:

■ 1. CoCの起源と初期の成功

• Debianの停滞問題: 2000年代初頭、Debianは開発者の自律性を最大限尊重する文化を持ち、中央集権的な意思決定機関が存在しなかったため、プロジェクト全体のリリースが停滞していた
• Debian 3.1(sarge)の遅延: 前バージョン(woody)が2002年7月リリースだったのに対し、sargeは2005年6月リリースで実に3年近い歳月を要し、フレームウォーによる疲弊と意思決定プロセスの麻痺を象徴していた
• Ubuntuの登場: 2004年にMark Shuttleworthが立ち上げたUbuntuは、6ヶ月ごとのリリースサイクルに加え、コミュニティの健全な運営を担保するためのCoCを最初期から導入した
• Benjamin Mako Hillの貢献: UbuntuのCoC起草に中心的役割を果たし、他のプロジェクト(Debian)で経験した「刺々しいやり取り」への反省から意図的に明文化された
• 初期の効果: 技術的な生産性を最大化するために健全なプロジェクトの協働を維持するという現実に即した目的から生まれ、「Ubuntuの方が動きやすい」という空気が醸成された

■ 2. カンファレンスへの拡大と目的の変化

• Ada Initiativeの活動: 2011年から2015年にかけて活動した非営利団体で、技術カンファレンスにおけるハラスメントが深刻な問題であると指摘し、アンチハラスメント・ポリシーのテンプレートを公開・推進した
• 目的の転換: CoCの目的が「協働の生産性向上」から「参加者の安全確保」を含むものへと大きく舵を切った
• Donglegate事件(2013年): PyCon参加者の女性が近くの席の男性の「ドングル」発言を性的冗談と受け止めTwitterに投稿し、冗談を言った男性の一人と告発した女性自身の両方が職を失うという結末を迎えた
• 事件の教訓: コミュニティ内の対立が当事者のキャリアに深刻な実害を及ぼしうること、非公式な規範だけではこのような事態を収拾できないことを露呈した
• PyConの対応: 「公の場での名指しの批判は、強力なコミュニティを構築する上で逆効果になり得る」との文言をポリシーに追加

■ 3. Contributor Covenantによる標準化

• 2014年の登場: Coraline Ada Ehmkeによって作成され、特定のプロジェクトやイベントに限定されない汎用的なCoCのテンプレートとして設計された
• 詳細な内容: 年齢、性自認、民族、経験レベルなど保護されるべき属性を明示的に列挙し、「歓迎されインクルーシブな言葉遣い」を推奨する一方で「個人攻撃や政治的攻撃」「公的または私的なハラスメント」を許容されない行動として定義
• 執行ガイドライン: 違反が報告された場合の調査や是正措置に関する詳細な執行ガイドラインまで含み、単なる理念の表明に留まらない法的文書に近い枠組みとなった
• 急速な普及: 網羅性と導入の容易さから瞬く間に普及し、数万ものプロジェクトで採用された
• Linuxカーネルの採用(2018年): Linus Torvaldsが過去の攻撃的な言動を謝罪し、従来のCode of Conflictを廃止してContributor Covenantを採用したことで象徴的転換点を迎えた
• 目的の変遷: 「協働の生産性向上のツール」→「安全確保の仕組み」→「倫理規範の標準フレームワーク」へと変貌を遂げた

■ 4. Rustモデレーションチーム総辞職事件(2021年11月)

• 総辞職の理由: モデレーションチームが全員辞任し、「コアチームが自分たち以外の誰に対しても説明責任を負わない立場に身を置いているため」とされた
• ガバナンス構造の欠陥: CoCの執行を担当するモデレーションチームのメンバーがプロジェクトの最高意思決定機関であるコアチームによって任命されていた
• 従属関係の問題: CoCを執行する組織が、CoCによって裁かれる可能性のある組織に従属していたため、独立かつ公平な調査や裁定が事実上不可能だった
• 教訓: どれほど立派なCoCを掲げても、プロジェクトの最高権力者に対しても公平に適用できる独立したガバナンス構造がなければ、CoCが空文化し摩擦だけが残る
• CoCの無力さの証明: CoCが権力に対するチェック機能として失敗した典型例

■ 5. RubyGems事件(現在進行中)

• 権力掌握の疑惑: Rubyコミュニティのインフラを運営する非営利団体Ruby Centralが、主要なスポンサーからの圧力を受け、長年無償で貢献してきたメンテナーの同意なしにRubyGemsとBundlerのGitHub Organizationの管理権を掌握したと追求されている
• 公式の理由: 「サプライチェーンセキュリティの保護とガバナンスの強化」という正当な理由を掲げている
• メンテナーの主張: 追放されたメンテナーは「スポンサー企業の意向を背景とした中央集権化とコミュニティの乗っ取り」と主張し、「敵対的買収」と呼んでいる
• ガバナンスの武器化: CoCの執行やセキュリティ確保といったガバナンス強化の名目が、コミュニティを保護するのではなく、むしろコミュニティから権限を奪い企業や一部の権力者の利益のために利用され得る
• CoCガバナンスのパラドックス: 指導部の暴走を抑えるほどに強力なCoCは、指導部(あるいは外部勢力)によって乗っ取られコミュニティを支配するための道具としても使われるほどに強力である

■ 6. Eric S. Raymond(ESR)の批判

• 三つの助言:
  • (1) CoCを持つことを拒否せよ。既にあるなら削除せよ
  • (2) 官僚的な理由で必要なら「あなたの貢献が正当化できる範囲を超えて一緒に働くのが面倒になった場合、あなたは追放される」の一文で置き換えよ
  • (3) これ以上具体的にしようとする試みは機能しない。厄介者が操作するための制御面を提供するだけだ
• 純粋な能力主義: 唯一の評価尺度は、貢献者がもたらす技術的な価値と彼らが引き起こす社会的な摩擦との差引勘定である
• リーダーへの信頼: プロジェクトのリーダーに対して最終的な判断を下すという絶対的な信頼を委ねるモデル

■ 7. David Heinemeier Hansson(DHH)の批判とRuby CoCの評価

• Contributor Covenantへの批判: 「トロイの木馬」と断じ、プロジェクトから排除すべきだと主張
• Ruby CoCの賞賛: 「MatzがRubyのために導入した美しい代替案」を賞賛している
• Ruby CoCの四つの基本原則:
  • 反対意見に対して寛容であること
  • 個人の攻撃や中傷的な発言をしないこと
  • 他者の言動を解釈する際は、常に善意を前提とすること
  • ハラスメントと合理的に見なされる行為は容認されないこと
• シンプルさの効果: 保護されるべき属性のリスト、段階的な執行プロセスの詳細、法的な専門用語等が一切なく、法律の条文ではなく原則の表明である
• 信頼に基づく: 参加者が善意を持った大人であることを信頼し、明確な不正行為(ハラスメントや個人攻撃)にのみ介入する

■ 8. Contributor Covenantの脆弱性

• 武器化のリスク: 政治的な目的で武器化されたり、法廷闘争のように扱われたりする可能性がある
• 曖昧な用語: 「政治的攻撃」のような曖昧な用語は大きな解釈の余地を生み、脆弱性を生む
• 官僚的負担: 公式な委員会、調査プロセス、詳細な記録保持を前提とした執行はコミュニティへ望まぬ負担をかける
• 技術的議論の萎縮: 参加者に対する低い信頼を前提として設計されており、時には辛辣でさえある活発な技術的議論を萎縮させる危険性をはらむ

■ 9. Ruby CoCの優位性

• MINASWAN精神: 「Matz is nice and so we are nice.(Matzは優しい、だから私たちも優しくあろう)」という精神がコミュニティに浸透している
• 運用の容易さ: 細かい条項や政治的理念を明文化しなくとも、運用が容易でありながら他者を尊重する文化の形成には参加者が共有できる理念を掲げるだけで十分
• コミュニティへの信頼: 何が違反にあたるかの判断はコミュニティの合意に大きく依存し、官僚的なプロセスなしで既存のプロジェクトリーダーシップに依存する
• バランスの良さ: 短くて分かりやすく、原則に基づいており、ハラスメントや個人攻撃といった明白な不正行為の禁止に焦点を当てつつ、技術的な意見の対立についてはコミュニティの自浄作用を信頼する

■ 10. 提言:身の丈に合ったCoCへ

• フリーサイズの限界: 全サイズ共通のテンプレートを思考停止で導入することではなく、個々のプロジェクトの規模、文化、目的に合わせた「身の丈サイズ」のアプローチが必要
• Linuxの真似は不要: Linuxカーネルのような世界中の開発者と大企業が参加する巨大プロジェクトの真似をしても仕方がない
• 短いCoCの優位性: 大多数のオープンソース・プロジェクトにとって、ほんの数行で収まる程度のCoCは単に十分であるだけでなく、むしろ優れている
• 長さと過去の関係: 長くなればなるほど、そのコミュニティにとってそれが必要なことが起きた過去があるからである
• 盾であって武器ではない: CoCはソフトウェアを構築するというコミュニティの中核機能を守るためのシンプルな「盾」であるべきであり、コミュニティ自身に向けられかねない複雑な「武器」であってはならない

(2025/10/01)

スクレイピング・自動化対策について

• スクレイピング・自動化対策について

要約:

■ 1. 自動化悪用の実例と背景

• 代表的な悪用形態: スクレイピングによる無断データ収集、予約システムを狙ったBot、不正ログイン試行の自動化ツールなど、時代とともに多様化している
• X(旧Twitter)の詐欺Bot: 詐欺DMを送るBotが今でも多く存在し、毎日被害が発生している
• 大阪万博の予約問題: サーバーに過度の負荷をかける形で自動化が悪用され、予約システムが混乱した
• AI利用の巧妙化: 最近はAIを利用した巧妙な自動化も増加している
• Zennの荒らし事例: 一時期いいね9677、コメント10723になるまで荒らされていた(現在は対処済み)

■ 2. 大阪万博予約における自動化の手法

• Auto Clicker(Click Assistant): 画面に決められた操作を入力し、プログラムがエミュレート・再現する。ゲームの周回に利用されることが多いが、万博予約でも多用された
• マクロの利用: PC等で行えるマクロ(pyautoguiなど)も同様の仕組みで、単純な手順で再現できる
• API直叩き: エンジニア・プログラマーがAPIを解析してPythonやNode.jsなどで自動化を実装
• サーバーから見た本質: Auto ClickerもAPI利用も、サーバーから見れば同じ自動化である

■ 3. レートリミットの基礎

• 基本的な効果: 「同じ作業を何度もする」という自動化のニーズに対して、リクエストが通常より早く多くなる特性を利用して検知できる
• 万博での検知: 万博ウェブサイトも回数/期間で自動化を検知していると考えられ、自動化していないユーザーもBAN報告をしている
• 一般ユーザーへの影響: 手動で何度も試行を行うユーザーも特定期間内に閾値を超えてBAN状態になる問題がある
• 限界: 最低限自動化を防ぐことはできるが、実装は簡単である一方で効果が限定的になることも多い

■ 4. レートリミットのアルゴリズム

• トークンバケット:
  • ユーザーごとにトークンを一定間隔で補充し、残っている間だけリクエストを許可する
  • リクエストごとにトークンを消費し、無くなったら制限を行う
  • Twitchが採用しており、一時的にリクエスト量が増える状態でも対応できる
• リーキーバケット:
  • 空きが空いたらリクエストを流せるようにする方式で、水の入ったバケツがちょっとずつ漏れていくイメージ
  • リクエストは一定の速度でしか流せない
  • Shopifyが採用しており、処理を一定に保ちたいときに便利
• 固定ウィンドウカウンタ:
  • 1秒間にN回までと決める方法
  • 実装は簡単だが、期間の切り替わる瞬間にリクエストが集中すると2倍通ってしまう問題がある
• スライディングウィンドウ:
  • 最新のリクエストを基準に過去一定範囲が閾値を超えないか判定する
  • スライディングウィンドウログ(厳密だがメモリ効率が悪い)とスライディングウィンドウカウンタ(直前の結果から間隔を推定)の2種類がある

■ 5. CAPTCHA

• 基本機能: 画像認証、パズル、音声認証などで人間とロボットを判別・区別する
• 代表的サービス: reCAPTCHA、hCaptcha、Cloudflare turnstile(JS Challenge)
• 効果と問題点: かなり高い精度でBotを弾けるが、ユーザー体験を大きく損なうこともある
• 突破可能性: Driverや外部サービスを使った突破方法もあるが、攻撃者目線でコストがかかる
• 推奨: hCaptchaは突破にかかる労力やコストが高い。Cloudflare turnstileはユーザー体験的に良いが突破が比較的簡単
• 名称の由来: 「Completely Automated Public Turing test to tell Computers and Humans Apart」の略

■ 6. デバイスフィンガープリント

• 概要: ブラウザや端末の環境情報(User-Agent、フォント、解像度、OSバージョン、Canvasの動作など)を組み合わせて同一環境からのアクセスかを推定する
• 使用方法: これらを保存して比較することができる(例: bcadc52670c11a5b8789853a6ef178ef)
• 制限と問題点:
  • Firefoxブラウザーや、AdBlockerなどの拡張機能には防ぐ機能が存在することがある
  • プライバシー的にグレーと言われているため、採用には注意が必要
  • ユニークではないので被ることはある
• 実装: FingerPrintJSなどのライブラリが利用可能

■ 7. コードのローテーション

• 基本戦略: コードの難読化を毎日変更したり、共通鍵をローテーションする
• 効果: イタチごっこにはなるが、攻撃者のコストをかなり上げることができる有効な手段
• 実例: X(旧Twitter)もこの方法を採用している(x client transaction idで検索可能)

■ 8. ネットワークベースの制御

• 基本前提: 攻撃者は海外IPを利用していることが多い(VPNやProxyの都合上)
• 地域制限:
  • 特定の国や地域からのアクセスを制限する
  • 例: 中国のアクセスを遮断、もしくはCAPTCHAを表示するように変更
  • 日本以外からのアクセスを制限することも可能
• VPN・データセンター判定:
  • VPNは既知の物が多く、串はデータセンターを利用している場合が多い
  • この二つが判定できれば弾くことができる(例: ipinfo.io)
• Tor制御:
  • Torの串は無料で簡単に使えるので利用している攻撃者も多い
  • Torからのアクセスを遮断あるいはCAPTCHAを行うことで効果が出る
• 注意点: 正規ユーザーがVPNを使っている場合もあるので誤検知のリスクは残る
• Cloudflare Enterprise: 機械学習を利用した検知を提供しており、Header "cf-bot-score"にBotの疑いがある数値(2-99)が入る

■ 9. アカウントレベルの制限

• 新規登録制限: 新規登録直後は利用制限をかける
• 信頼スコア: 信頼スコアが低いアカウントは厳しいチェックをする(通報などでスコアを下げていく)
• 認証ハードル: 電話番号や二段階認証でハードルを上げる
• SMS認証のコスト: 大体1通10円が定価であり、レートリミットは厳重にする必要がある(破産した人も存在する)
• 行動パターン分析: 「投稿時間が毎日一定である」などサービスの特色に応じた様々な方法が考えられる

■ 10. 番外編の対策手法

• ハニーポット的手法:
  • 本物の入力フォームとは別に「偽フォーム」を置き、Botだけが入力してしまうようにする
  • 無差別に攻撃を行っているBotにのみ効果があるので注意
  • HTMLのhiddenフィールドに「埋めるべきでない値」を仕込み、入力されたらBot判定する
• スキャナー対策: Shodanのようなscannerを避けたいなら、/wp-admin/*などのスキャンをトリガーにしてアクセス禁止にする
• 複合的アプローチの重要性: これらの方法は複数組み合わせてやっと効果が出る。例えば、レートリミットだけでは怪しいIP(海外のProxyなど)を弾けなければ突破される

■ 11. 総合的な防御戦略

• 多層防御の必要性: 単一の対策では効果が限定的であり、複数の手法を組み合わせることが重要
• 攻撃者のコスト増加: 各対策の目的は攻撃者をうんざりさせ、攻撃のコストを上げることにある
• 実装の容易さと効果のバランス: レートリミットは実装が簡単で多くのライブラリが存在するが、CAPTCHAやデバイスフィンガープリントなど、より高度な対策も検討する必要がある
• プライバシーとセキュリティのバランス: デバイスフィンガープリントなど一部の手法はプライバシー的にグレーゾーンであり、採用には慎重な判断が必要

(2025/10/01)

企業だと月30万円の売上しか出ないゲームやアプリって「事業として成り立たない」でボツになる。でも...

• 企業だと月30万円の売上しか出ないゲームやアプリって「事業として成り立たない」でボツになる。でも個人開発なら月30万円ってだいぶ美味しいので、企業が「小さすぎて手を出せない宝石」を僕らは拾い放題という話 - posfie

MEMO:

• 企業は人件費/固定費が掛かるので小さな事業は費用対効果が見合わない
• 個人勢はその辺殆ど掛からないので小さい事業を複数展開すれば喰っていける（かも）
• まぁ、個人事業主が戦うべき戦場はそこよな

(2025/10/01)

オープンソースに匹敵する大変革「オープンソーシャル」が徐々に広がり中、自分のデータを使い回して...

• オープンソースに匹敵する大変革「オープンソーシャル」が徐々に広がり中、自分のデータを使い回して色んなウェブサービスを使える仕組み - GIGAZINE

要約:

■ 1. オープンソーシャルの概念

• 定義: 閉じた世界で動作する既存のSNSに対して、共通の規格に基づいて動作するSNSを指す
• 既存SNSの問題点: XやFacebookなどではユーザーのデータが各運営企業によって管理されており、投稿内容やフォロー情報を保ったまま別のサービスに引っ越すことは不可能である
• 解決策: 各ユーザーが自分のデータを自分で管理できる仕組みを構築する
• オープンプロトコルの種類: MastodonのActivityPub、ジャック・ドーシー関与のNostr、BlueskyのAT Protocolなど複数のオープンプロトコルが存在する

■ 2. アブラモフ氏の経歴と見解

• 経歴: MetaでReactの開発に携わり、2023年頃にBluesky開発チームに加わってクライアントアプリ開発を推進した
• 現在の活動: 2025年夏頃にBluesky開発チームを離れ、UIエンジニアリングに関するコンサルティングを行っている
• AT Protocolの評価: 自身はプロトコル設計に関わっていないと前置きしつつ、AT Protocolを「オープンソーシャルの好ましい一例」と絶賛している

■ 3. 昔のウェブ環境との比較

• 昔のウェブ環境: 各個人が自分でウェブサイトを開設し、コンテンツを配置したり他人のサイトにリンクしたりしていた
• データの移行可能性: ホスティングサービスが終了したりポリシーが変化した際に、コンテンツやリンク情報を保ったまま別のサービスに乗り換えることができた
• 現代SNSの制約: 投稿した文章や画像やフォロー情報などは各運営企業によって管理され、データを保ったまま別のSNSへ移行することは困難になった
• オープンソーシャルの意義: 昔ながらのウェブ環境のデータ移行可能性を現代のSNS社会に復活させるものである

■ 4. AT Protocolの特徴

• ユーザーによるデータ管理: ユーザーのデータをユーザー自身が管理できることが大きな特徴である
• ドメインによる識別:
  • サービス内だけのハンドルネームではなく、各ユーザーの固有のドメインを用いてデータを管理できる
  • GIGAZINE公式アカウントの場合は「gigazine.net」というドメインを使用している
• 無料サブドメインの提供: Blueskyではアカウント作成時に無料のサブドメインが発行され、技術に詳しくない人でも従来のSNSと同じような使い心地で利用できる
• サービス間の移行可能性: 投稿内容やフォロー情報を自分の管理下に置いているため、Blueskyに不満が生じた場合は各種情報を保ったまま他のAT Protocol対応サービスに移行できる

■ 5. AT Protocolの応用範囲

• SNS以外の活用: AT ProtocolはSNS以外のサービスの構築にも利用可能である
• 既存サービスの例:
  • ブログサービスの「WhiteWind」
  • コード管理サービスの「tangled」
• データの一元管理: これらのサービスへの投稿内容やお気に入り情報などはユーザーの管理するデータリポジトリにどんどん追加されていく
• 公開情報としての設計: AT Protocolは基本的にすべての情報を公開情報として扱うように設計されている
• サービス間の連携: 各種AT Protocol対応サービスは他サービスで作成されたユーザー情報を参照でき、tangledの利用開始直後からBlueskyと同じプロフィールやアバター画像を表示することが可能である

■ 6. オープンソーシャルの将来展望

• 現状の課題: 記事作成時点ではXやFacebookといった企業によって管理されるSNSが多くのシェアを獲得している
• 当面の依存: オープンソーシャルはしばらくは苦労をいとわず活動する頑固な熱狂的ファンたちのコミュニティに依存することになる
• 相乗効果: オープンソースと同様にオープンソーシャルも相乗効果を生み、あるオープンソーシャルアプリが成功すれば他のオープンソーシャルアプリにも貢献する
• 将来的な勝利: いずれオープンソーシャルは勝利を収め、一定の地位を得ることになるとアブラモフ氏は予言している

MEMO:

• SNSが流行るのはそれで何かしらのメリットが発生するかどうかで、データがオープンかどうかはあまり関係無いような
• メリットというのは要するに承認欲求だったり、オフパコだったり、情弱から金を巻き上げたりなど
• 参入と維持が面倒なオープンXXXに↑のような連中が参入するとは考えにくいわけだが

(2025/09/30)

元バリバリのシニアマネが「もうマネジメントしたくない！メンバーがいい！」とSESに転職してきて作業員...

元バリバリのシニアマネが「もうマネジメントしたくない！メンバーがいい！」とSESに転職してきて作業員としてゆるふわニコニコ働き、客先から「〇〇さん技術あるしもっと主体的になってくれればリーダーとかできそうなのに…」と言われてるのを見て空を仰ぐ

@dropna_nan

MEMO:

• 作業員？

(2025/09/30)

ITシステムに「お辞儀ハンコ」実装…日本のDXが進まない根本原因

• ITシステムに「お辞儀ハンコ」実装…日本のDXが進まない根本原因（GOETHE） - Yahoo!ニュース

要約:

■ 1. 日本のIT化の現状

• IT利用頻度の低さ: 16歳から24歳の若者が職場や家庭でパソコンを利用する頻度はOECD加盟国中最低水準である
• パソコン保有率の低さ: 日本のパソコン保有率は米国の半分程度で、職場にも十分に普及していない状況である
• 学校教育でのIT不足: コンピュータを使える状況にあると回答した生徒の割合は47カ国中40位以下にとどまる
• 子どものパソコン保有率: 13歳から19歳の約7割がパソコンを保有しておらず、先進国中突出して低い
• スマホ普及の誤解: 諸外国もスマホに加えてパソコンやタブレットを保有しており、知的活動はパソコンで行うという使い分けができている

■ 2. IT化が進まない理由

• 技術力の問題ではない: 日本の技術力は高い部類に入るため、IT活用ができない理由は技術ではなく日本人のマインドにある
• FAX廃止の挫折: 菅政権が各府省のFAX利用取りやめを検討したが反対の声が上がり廃止できなかった
• ハンコ文化への固執: 日本人の特殊なマインドがIT活用を妨げる象徴となっている

■ 3. お辞儀ハンコ問題

• システム化の本末転倒: ハンコを廃止せず画面にハンコの印影を表示させるITシステムをわざわざ開発する企業が存在する
• お辞儀ハンコの実装: 役職によってハンコの傾きを変える機能を実現できるシステムをコストをかけて作る企業がある
• システム会社への要望: お辞儀ハンコができるようにして欲しいという要望が実際に寄せられている
• 本来の目的の喪失: 承認ボタンで事足りるにもかかわらず、わざわざコストをかけてハンコの印影を表示させエライ人にお辞儀をする機能まで付けている

■ 4. IT化の本来の目的

• 業務効率化の意義: システム化をきっかけに業務のムダを洗い出し省略することでビジネスを効率化することが目的である
• 生産性向上の機会: 業務の実態を丁寧に分析すれば承認者を減らせる可能性があり、システム化をきっかけに生産性が向上する
• 逆効果の実態: 従来と同じことをシステムで行うとシステム費用分だけ逆にコストが増える結果になる

■ 5. 日本社会の根本的問題

• 承認欲求と儀式: 稟議書にハンコを押す行為には役職者の承認欲求を満たす作用があり、その行為をIT化することに抵抗がある
• 上下関係の固執: 日本人のコミュニケーションは相手との上下関係が基本で、上に立つ人は常にマウントをとってその立場を維持しようとする
• 不寛容な組織文化: ITを導入する状況に至っても上下関係を基軸にした不寛容な組織文化を死守しようとしている
• 儀式化の特異性: 上司が部下に威張る光景は諸外国でも見られるが、こうした関係性を儀式化しITにも実装しようとする国は日本以外に存在しない
• マインドの問題: ムダがなくならず長時間残業を抑制できない原因は技術の問題ではなく完全にマインドの問題である

MEMO:

• お辞儀ハンコを実装してるシステムは具体的にはどこの企業のシステムで、全体でどれぐらいあるのかを出さないと意味が無いのでは
• これまでお辞儀ハンコシステムを見たことがないので、都市伝説の類だと思っているのだが
• PCの所有率に関してはIT業界の民なので、職場に普及していないと言われてもにわかには信じがたい
• 余程高齢者の個人事業主でも無い限り、PC無しで業務をやっている姿が想像しにくい
• 子供のPCの保有率についてもデータが古い気がする
• 数年前からPCやタブレットを学校から貸与されるようになっているので日常的に触るタイミングはあるだろう
• 総じて、20年以上前のステレオタイプで物事を語っている印象がある
• 「日本人は遅れてるんですよ！」という趣旨の記事の内容自体が時代遅れというのは叙述トリックかな？

(2025/09/30)

デジタル庁、アクセンチュアを4カ月間指名停止　業務を無断で再委託

• デジタル庁、アクセンチュアを4カ月間指名停止　業務を無断で再委託 - ITmedia NEWS

デジタル庁は9月26日、アクセンチュア（東京都港区）を、同日付で新規契約から外す「指名停止」の対象にしたと発表した。26年1月25日までの4カ月間、同庁が行う入札や契約に参加できなくなる。

アクセンチュアは、デジタル庁から2024年4月1日付で「情報提供等記録開示システム」の設計・開発や運用業務を受託。この他、2023年度以前も同様の契約案件を受託していた。いずれも複数の企業に再委託していたが、再委託に当たり同庁への申請が必要だったにもかかわらずこれを行わなかったという。同庁はこの行為を「不正又は不誠実な行為」に当たると判断した。

MEMO:

• あらあら

(2025/09/30)

リーダーの仕事は頑張ることでも､頑張らせることでもない…ニトリの管理職に受け継がれる

• リーダーの仕事は頑張ることでも､頑張らせることでもない…ニトリの管理職に受け継がれる"究極のマインド" トヨタ式｢もっといいものをラクに早く｣ | PRESIDENT Online（プレジデントオンライン）

要約:

■ 1. 個人業務の適正比率

• 3割ルールの重要性: リクルートワークス研究所の調査によると、個人業務の比率を3割程度に抑えるマネジャーが率いる組織はパフォーマンスが高い
• 5割を超えると成果が急降下: 自分で頑張りすぎることが結果的にチームの足を引っ張る可能性がある
• 時間配分の目安: 1日8時間働くなら自分の業務は2〜3時間で、残り5〜6時間は部下との対話、サポート、チームの未来をつくるプロジェクトに使う
• 任せることの本質: 手放すことではなく、育てること、信じること、未来を託すことである

■ 2. リーダーに必要な余白

• 余白が生む効果: リーダーに余白があれば部下は話しかけやすくなり、相談と対話が生まれる
• 組織成果の源泉: 個人の頑張りの総和ではなく、関係性の質や信頼の循環がつくり出す
• リーダーの役割: 話しかけやすい人、見守ってくれる人、チームの未来を語る人であることが組織の可能性を広げる

■ 3. 任せないことの副作用

• 見えない成長阻害: 部下が忙しいからと遠慮して任せないことが、実は部下の成長の芽を静かに摘んでいる
• 信頼関係の片想い: パーソル総合研究所の調査では、上司・部下の関係の52.4%で部下は上司を信頼しているが上司が部下を信頼していない状態である
• 信頼を感じる瞬間: 部下が信頼されていると強く感じる瞬間は仕事を任せられた時である
• 愛情の副作用: 大事に思うあまりに心配して任せないことが、かえって信頼関係を崩す

■ 4. 育成の本質

• 教育の幻想: 教えれば育つは思い込みである
• 修羅場体験の重要性: 本当に人が育つ条件は、うまくいかずに悩み、自分で考え、動き、試して突破した体験である
• ラーニングゾーン: 部下を飛躍させる機会をつくることが育成のカギである
• 資産運用の発想:
  • 部下は会社の大切な資産であり、管理職はその資産を託された運用者である
  • できるようになったから任せるのではなく、任せるからできるようになる

■ 5. リーダーの真の仕事

• 変えることが仕事: 頑張ることでも頑張らせることでもなく、変えることがリーダーの仕事である
• 問いを持ち続ける: もっとラクに、確実に、成果を出せないかという問いを常に持ち続ける
• ニトリのマインド: 前任者を超えよというマインドが受け継がれている
• なくす力の発揮:
  • プレイングマネジャーは現場にいるからこそ、ムダを肌感でわかる
  • 成果に影響のないタスク、意味のない報告資料、形骸化した会議にメスを入れる

■ 6. 失敗から学ぶ組織

• 失敗の価値: マドセンとデサイの研究によると、失敗体験のある組織のほうが次に成功する確率が高い
• 学習効果の差: 成功体験のパフォーマンス改善効果が-0.02に対し、失敗体験は-0.08と4倍も学びが深い
• サーチ行動: 失敗を経験した時、何がダメだったのか、何を変えるべきかと自ら問いを持ち探索をはじめる行為が学習の入口である
• 成功ばかりの危うさ: 失敗経験が少ないまま成功すると、その後はむしろ失敗しやすくなる
• リーダーの姿勢: 部下の失敗を責めるのではなく、失敗から何を学んだかを問い、サーチ行動を促すことが重要である

(2025/09/29)

(株)はてながこのままだと再来年くらいに上場廃止するかもしれない

• (株)はてながこのままだと再来年くらいに上場廃止するかもしれない

2016年2月24日に株式会社はてなは上場。

東証グロースの上場維持基準は上場から10年後に時価総額40億円だが、現在の時価総額は約30億円。

つまり、このままだと来年の3月には上場維持基準をクリア出来なかったことになるため、上場廃止の可能性が出てくる。

https://www.jpx.co.jp/equities/listing/continue/outline/03.html

通常は未達から1年間の改善期間を経てから上場廃止。

一応、グロース市場から時価総額基準が無いスタンダード市場に移るという手も無くは無いが、代わりにより厳しい流通株式の基準等もあり、全く容易ではない。

しかも、追い打ちをかけるように先日東証より「グロース市場の上場維持基準の見直し等の概要」が公表された。

https://www.jpx.co.jp/news/1020/um3qrc0000026eka-att/um3qrc0000026enb.pdf

2030年以降は、上場維持基準が「上場5年経過後に時価総額100億円」以上と見直される予定だ。

なお、以前に上場している企業(はてなも含む)は、一応は「なんとか頑張って100億円目指すぞ」プランを開示すれば多少の延命は出来るが、それでも猶予期間中に「⾒直し前の上場維持基準（上場10年経過後40億円）にも適合しない状態となった場合には、改善のための期間を設けず速やかに上場廃⽌を決定」となる。

現時点でも40億円ラインを超えられていない、はてなの運命やいかに...

MEMO:

• おやおや
• とはいえ、いきなり上場廃止みたいな事はできないと思うんだが、どうなんだろうか

(2025/09/29)

入社1年目からPMとして活躍する組織の育て方

• 入社1年目からPMとして活躍する組織の育て方 #初心者 - Qiita

要約:

■ 1. 若手PMの育成を阻む一般的な問題

• PMの仕事の属人化:
  • 課題の存在: 特定のベテランPMにしかできない仕事が多く、仕事内容が言語化されずに暗黙知として扱われるため、新人に仕事を任せられない。
• 組織が求めるPM像の不統一:
  • 方向性のブレ: シニアPMの経験に基づくPM像がバラバラで、組織として目指す共通のPM像（ゴール）を持てず、PM育成の方向性が定まらない。
• 失敗を許容しない文化:
  • 挑戦の阻害: 失敗を強く非難する文化では、PMの仕事に付きもののリスクを取ることを新人が恐れ、新しい挑戦ができなくなり、組織の成長が停滞する。

■ 2. 1年目からPMを育てるための3つのステップ

■■ 1. PMの思考の「型」を共有する

• 思考プロセスの言語化: ベテランPMが無意識で行う意思決定を支える思考プロセスを「型」として言語化し、組織全体で共有する。
• PMの思考の型（例）:
  • 目的の明確化: 「なぜ、この問題を解決するのか？」を常に問い、顧客課題や事業目標との繋がりを明確にする。
  • ユーザー視点: チーム内の憶測ではなく、ヒアリングに基づき「誰にとっての課題なのか？」を定義する習慣をつける。
  • 複数の選択肢の検討: 最初に思いついた解決策に飛びつかず、「解決策は本当にこれしかないのか？」とメリット・デメリットを比較検討する。
  • ゴールの言語化: 「良い感じ」ではなく、定量的な指標（KGI/KPI）で成功を定義し、チーム全員で同じゴールを目指す。

■■ 2. PMの仕事を、体系を理解したメンターがレクチャーする

• 段階的な責任範囲の拡大: PMの仕事を難易度で分解し、新人が小さな成功体験を積み重ねられるように徐々に任せる範囲を広げる。
• 体系的なメンタリング: 忙しい先輩による場当たり的なOJTではなく、PMの仕事の全体像や思考の型を理解し、「なぜそのタスクをやるのか」「失敗から何を学ぶべきか」を言語化して教えられる専任のメンターをつける。
• PMの仕事の分解例:
  • フェーズ1（部分的な担当）: 既存PMのタスクの一部（議事録作成、データ収集）や、既存プロダクトの小さな機能改善を任せ、仕事の流れを一人で経験させる。
  • フェーズ2（責任範囲の拡大）: 決済機能などプロダクトの特定領域や、ステークホルダーが少ない小規模プロジェクトのPMを任せ、企画から運用まで一貫して担当させる。

■■ 3. 成功と失敗から学ぶ「サイクル」を組織に組み込み、積極的に外部に発信する

• 組織としての学びの習慣化: 個人の経験をチームや組織全体の「学び」に変え、常に成長し続けられる仕組みを作る。
• 学びの共有会の開催: 成功・失敗を問わず、プロジェクトの「学び」をオープンに共有し、次のプロジェクトに活かすための議論の場を定期的に設ける。
• ナレッジベースの構築: プロジェクトの振り返りや意思決定の経緯など、「なぜその判断をしたのか？」という思考プロセスをドキュメント化して蓄積し、組織の知見を効率的に学べるようにする。
• 発信・共有の習慣化: 社内共有だけでなく、ブログ記事や登壇資料など外部への発信機会を設けることで、思考をより深く整理し、社外のフィードバックを得て学びを深める。

■ 3. まとめ

• PM組織成長の鍵: PMの仕事を「見える化」し、「メンター」をつけ、「学びのサイクル」を組織に根付かせることで、「経験者じゃないとPMは無理」という固定観念を打破し、若く才能ある人材を早期に育成できる強い組織を築くことができる。

(2025/09/29)

「明らかに正しいコードを書く」という意識が好きという話

• 「明らかに正しいコードを書く」という意識が好きという話 #初心者 - Qiita

要約:

■ 1. 「明らかに正しいコード」の定義と重要性

• 定義: 大雑把に言って見通しがよく、何をしているのか理解しやすいコードである。
• 目的: 競技プログラミングの格言だが、「もっとシンプルにできないか？」という視点を持つための意識として、普段の業務にも活かせると考える。
• 必要性: コードは少し油断すると簡単に複雑になり、理解しにくくバグも生みやすいものになってしまう。

■ 2. コードが複雑になる主な原因

• 最大の原因: 一つのやり方から抜け出せなくなることである。
• 条件分岐の増殖: ソフトウェアは条件分岐で構成されるが、既存の実装を変えたくないため、細かい調整を条件分岐で対応しようとする。
• 複雑化のプロセス: その結果、「この場合はさらに2パターンに分かれ、その一つでまた別の分岐が…」となり、何が正しいのか分からなくなる。
• バグ修正時の問題: バグ修正や追加対応など、小さな修正であっても、それにより分岐が次第に増え、結果としてコード全体が複雑になることが多い。
• 時間的な制約: 想定作業時間が短いチケットの場合、「本当は良くないコード」と分かっていながら、それで済ませるしかなくなり、コードが腐敗していくことがある。

■ 3. 複雑化を防ぐための意識と行動

• 意識: タイトルにもある「明らかに正しいコードを書く」という意識を持つ。
• 立ち返り: 「なんだか、やけに複雑なことをしているな・してしまっているな」と感じたら、今のやり方に固執せず、一度立ち帰り、全体を見直すべきである。
• 具体的な解決策:
  • 早期リターン: 「どの分岐でもこの場合は単にreturnしているから最初に確認してしまえばいい」といった、共通処理の切り出し。
  • 要件の再整理: 初期化処理などの共通部分を、より簡単な前段の分岐でまとめて処理するなど、シンプルで分かりやすい方法を検討する。
• 人間にできること: 人間はあまりに複雑なものを管理できないため、シンプルで分かりやすい方法を追求する必要がある。

■ 4. 複雑なコードを避けることの恩恵

• 現実との乖離: 現実には、時間的な制約や、元の処理にかけた時間が長いことによる固執（人間的な感覚）などから、毎回シンプル化が成功するわけではない。
• 複雑化の弊害: 扱いづらいコード・理解しにくいコードは、日々の業務を苦痛にし、「簡単な修正なはずなのに時間がかかる」「修正が別のバグを引き起こす」といった問題を生む。
• シンプルな追求: 「こんなに複雑にしなくても、もっとシンプルにいけるはずだ」という感覚に従うことが重要である。
• 長期的な恩恵: その場では修正・テストに時間がかかったとしても、その後の開発で大きな恩恵を受けられる。

(2025/09/28)

世界初！日本企業がGPUを不要とする生成AI (LLM) の開発に成功。／2025年10月10日の都内イベントで先行発表

• 世界初！日本企業がGPUを不要とする生成AI (LLM) の開発に成功。／2025年10月10日の都内イベントで先行発表 | 株式会社I.Y.P Consultingのプレスリリース

要約:

■ 1. 開発の概要と国際的評価

• 開発元: 株式会社I.Y.P Consulting（設立：2023年10月、本社：東京都中央区）が、生成AI「SVG」の開発に成功した。
• 技術的特徴: GPUなどの特殊な機材を必要とせず、わずか32個のパラメータという極小規模でありながら、従来のLLM（大規模言語モデル）と同等の性能を発揮する。
• 国際的評価: 2025年9月18日、人工知能／機械学習分野で最も権威のある国際会議のひとつNeurIPS（米ニューラル情報処理学会）の本会議で正式に採択（アクセプト）された。
• 日本発の意義: 巨大化一辺倒の国際潮流に対し、「小さく、速く、分かりやすい」新しいアプローチを示した日本企業主体の稀有な成果であり、国際的に大きな注目を集めている。

■ 2. SVGの性能と従来のLLM・SLMの課題

• LLMの課題: 数千億〜数兆のパラメータを持ち、学習・推論に膨大な計算資源（GPU）と電力コストを要するため、環境負荷や事業継続性（特に日本の電力逼迫）の課題があった。
• SLMの課題: SLM（小規模言語モデル）は軽量化を目的とするが、LLMをスケールダウンしたモデルが多く、性能や応答の自然さでLLMとの差が大きくビジネス利用には不十分だった。
• SVGの画期的な性能:
  • 極小パラメータ: パラメータ数はわずか32個（GPTのわずか1億分の1のメモリ容量）。
  • 高速性: 応答速度は1ミリ秒と高速。
  • 高精度: ハルシネーション（幻覚）の国際標準GLUEベンチマークにおいて、GPTを上回る精度を達成した。
  • 実行環境: GPUを一切必要とせず、汎用CPU環境でリアルタイムに稼働する。

■ 3. ビジネス優位性と持続可能性

• コストとインフラの優位性:
  • コスト削減: 高額なGPUインフラ投資や大規模クラウド利用コストを大幅に削減し、GPU環境を持たない中小企業や公共機関でも導入可能になる。
  • ユースケース拡大: PC、スマホ、家電、IoT端末など幅広いデバイス上での利用が可能になる。
• 運用面と説明責任:
  • プライバシー担保: インターネット接続不要で処理が可能なため、プロンプトの高速処理とプライバシーの確保を実現する。
  • スピードと効率: 学習はタスクあたりわずか数分で完了し、PoCや新規サービス立ち上げを加速する。
  • 説明責任の確保: 分類根拠を明示できるため、金融・医療・行政など説明責任が重視される領域でも安心して活用できる。
• 持続可能性: エネルギー消費を抑え、環境負荷を低減するグリーンAIとしての意義を持ち、「大規模モデルを使いたいがリソースが限られている」組織にとって、現実的かつ持続可能なAI活用の突破口となる。

MEMO:

• 本当ならすごい事だが
• こういうのは往々にして尻すぼみになる事が多いので、まずは期待せず様子見することが肝要である

(2025/09/28)

勤怠管理システムをDDDで作り直して9年。その選択は正しかった？

• 勤怠管理システムをDDDで作り直して9年。その選択は正しかった？ - RAKUS Developers Blog | ラクス エンジニアブログ

要約:

■ 1. 旧システムで直面した課題とDDD導入の背景

• 勤怠管理システムの複雑性: 勤怠システムは、法律や就業規則、企業ごとの勤務体系の違いなどにより、複雑なルールと例外が膨大に存在する。
• 旧システムの課題:
  • 処理の不明確さ: 自作フレームワークをベースにしていたため、処理の所在が不明確であった。
  • 深刻な属人化: 「この処理の正解は〇〇さんしか知らない」という状況が頻発し、知識が特定のベテランメンバーに偏っていた。
  • 高い教育コスト: 新メンバーにとってコードと業務知識の紐付けが難しく、システム理解に大きなハードルがあった。
• DDD導入の目的: 「何をどこで処理しているのかが不明確」という最大の課題を解決するため、新システムのリニューアル時にDDD（ドメイン駆動設計）を採用した。

■ 2. DDD導入によるシステムの改善と属人化の解消

• ドメインの整理とモデル化: 「現実の勤怠の仕組みを、チーム全員が同じ言葉で説明できるようにする」というアプローチで、勤怠ドメインの整理とモデルへの落とし込みを行った。
• 代表的なモデルの例:
  • 労働パターン: 勤務区分やカレンダーなど、勤怠計算に必要な設定を定義する。
  • 打刻: 出退勤・休憩といった「事実」だけを表し、「遅刻」などの解釈は加えない。
  • 勤務実績: 打刻や計算で計上された、その日の「働いた結果」を表現し、ユーザーへの表示に用いる。
  • 休暇履歴: 有休の付与・取得・消滅をすべて履歴として積み上げることで、残日数を自動的に導けるようにし、値の正当性に関する懸念を解消する。
• 共通理解の促進:
  • ユビキタス言語の活用: 「労働パターン」「打刻」「勤務実績」「休暇履歴」といったモデル名を指して会話できるようになり、以前の曖昧な表現を解消した。
  • 属人化の解消: 知識がモデルに閉じ込められ、チーム全体で共有できるようになり、仕様確認やレビューがスムーズになった。

■ 3. 9年間の運用で実感したDDDの価値

• チーム知識の維持: DDDは「複雑な業務知識をチーム全体で維持し続ける仕組み」として機能した。
• 価値の具体例:
  • 新メンバーの立ち上がり加速: 旧システムのように勤怠ドメインの理解に数カ月かかることはなくなり、「休暇履歴」などの用語ベースで理解できるようになった。
  • 制度変更への柔軟な対応: 制度やルールの変更が発生した場合、該当モデルにルールを追加・修正するだけで対応できるようになった。
• 最終的な評価: 9年間の運用を経て、DDDは単なる設計手法ではなく、「複雑な勤怠ドメインをチームみんなで理解し続けるための心強い道具」であり、「あのときDDDを選んでよかった」と心から言える。

(2025/09/28)

「技術負債にならない・間違えない」 権限管理の設計と実装

• 「技術負債にならない・間違えない」 権限管理の設計と実装 - Speaker Deck

要約:

■ 1. 権限管理の重要性とアンチパターン

• 権限管理ミスの影響: 給与や取引先情報などの機密情報公開につながり、サービスへの信頼が低下し、事業への大きな損失を招くため、ミスは許されない。
• よくあるアンチパターン:
  • user.admin? や user.super_admin? のように役割に依存した判定を行うこと。
  • 役割は事業やサービスの変化（市場、企業規模、機能）に伴い変わりゆくため、役割に依存した実装は変化に弱く、権限が暗黙的になり、技術負債の原因となる。
• 推奨されるアプローチ: 役割（admin?）に依存せず、権限に依存した判定（例: user.can_create_project?）にすることで、権限が明示的になり、コードリーディングや変更時の整合性確認が容易になる。

■ 2. 権限管理の要素整理とPunditの問題点

• 権限管理の要素分解: 権限管理を整理する上で、以下の4つの要素に分割できる。
  • 対象: Model（例: Project）
  • 操作: CRUDやその他のアクション（例: update）
  • 役割（RBAC）: Role-Based Access Control（例: 管理者アカウント、外部アカウント）
  • 条件（ABAC）: Attribute-Based Access Control（例: 作成者、担当者）
• Punditの問題: Punditを利用した場合、一つのポリシーメソッド内で役割と条件の判定が混在し、複雑な判定ロジックになると、「通常ユーザーは更新できるか？」といった問いに対し、すぐに回答できない（理解で間違えやすい）という問題が生じる。
  • 例: 管理者かマネージャーかつ担当者か作成者ならできる... のような論理演算の連なりは、一目で理解しにくい。

■ 3. 要素を適切に分割したModuleの実装と実現方法

• Moduleの設計思想: 役割と条件を分離し、権限を対象・操作・役割・条件の4要素で明示的に定義する。
• 実装の概要:
  • ディレクトリ/ファイル構造: 対象ごとにディレクトリを作成し、その中に役割ごとにファイル（権限の具体クラス）を作成する。
  • 権限の判定: 権限の具体クラス内で、対象の基底クラスで定義した条件（例: assignee? や author?）を英語と論理演算（|| や &&）でシンプルに組み合わせて表現する。
  • メタプログラミングの活用: 対象と役割から権限のクラスを特定する際に使用し、権限の追加・変更を容易にする。
• 利用時のモード:
  • recordモード: 特定のレコードに対して権限があるかを判定する（例: Context.new.can_update?(@project)）。
  • scopeモード: 権限があるレコードのみに絞り込む（例: Context.new.scope_for_read(Project)）。
  • listモード: クライアント（Next.jsなど）に渡すための権限の一覧を取得する。

■ 4. 良い設計がもたらす影響

• 間違えない実装の実現: 役割と条件を分離し、権限を明示的に記述することで、実装・利用・理解のすべてのフェーズで間違いを減らす（不具合の発生件数がゼロ、社内からの問い合わせがゼロ）。
• 開発生産性の向上: CSやPdMがGitHub上のコードを直接見て理解できるようになり、エンジニアへの問い合わせ対応時間が削減された。
• クライアント（Next.js）への影響:
  • Railsから渡された権限の一覧（JSON）にNext.jsが依存することで、Next.js側でも役割に依存しない実装が自然に実現した。
  • 権限によるUIの制御を（例: 編集ボタンの表示/非表示）宣言的に記述できるようになり、フロントエンドの技術負債も防いでいる。

(2025/09/28)

「完璧を目指さない」サーバーレス進化論 〜CDKで育てる変化に強いアーキテクチャ〜

• 「完璧を目指さない」サーバーレス進化論 〜CDKで育てる変化に強いアーキテクチャ〜 - Speaker Deck

要約:

■ 1. 「完璧を目指さない」アーキテクチャの必要性

• Lambda利用の現実的な課題: 初期は快適だが、データ量増加による15分制限の壁や、構成変更時のYAMLの複雑化（記述量爆発）、型安全性なしによる実行時エラー多発といった問題が生じる。
• 構成変更の困難さ: 実行時間超過への対応策として「Lambda分割」や「Fargate移行」があるが、いずれも複雑化や大幅な構成変更が必要となり困難である。
• 進化の鍵: 完璧な初期設計は存在せず、要件変化に柔軟に対応できる仕組み、すなわち構成変更の容易さと将来の拡張性がアーキテクチャの進化には重要である。
• 進化的アーキテクチャの定義: ビジネス要件や技術の進歩といった絶え間ない変化に適応できるように設計された柔軟性の高いソフトウェアアーキテクチャであり、漸進的な変更、適応度関数（客観指標）、多重な次元（性能、セキュリティなど）の統合管理が特徴である。

■ 2. CDKによる実践的進化パターン

• パターン1：Lambda → Fargate 移行:
  • 課題: 15分実行時間制限、スケーラビリティの限界がある。
  • 解決アプローチ: コンテナ化による時間制限の解除とECS Fargateによる自動スケーリングで解決する。
  • CDKの優位性: SAMでの移行時の記述量増加が6.3倍なのに対し、CDKでは2.1倍に抑制され、移行時の複雑度を約1/3に抑える。
• パターン2：EventBridge+Lambda → Step Functions 移行:
  • 課題: トレーサビリティ不足、分散イベント処理の複雑化、障害時の影響範囲特定困難がある。
  • 解決アプローチ: Step Functionsによる一気通貫ワークフローへの統合と実行状況の可視化、エラーハンドリングの集約により、障害調査時間を大幅に短縮する。
  • CDKの優位性: 既存のgrant()メソッドがそのまま使え、型安全性によりコンパイル時にエラーを検出でき、複数のLambda関数の連携を一つのファイルで管理しやすい。
• パターン3：DynamoDB → Aurora 移行:
  • 課題: 複雑なクエリ要件の増大、NoSQLの限界がある。
  • 解決アプローチ: Auroraへの切り替えとSQLによる柔軟なクエリ実行で対応し、CloudWatch Syntheticsによる性能監視（適応度関数）を強化する。
  • CDKの優位性: synthetics.Canary()で継続的な監視をコード化するなど適応度関数の実装が容易である。また、cdk diffにより変更点を確認しながら漸進的な変更を実現し、セキュリティ要件も1行の変更でIAMベースからVPCベースへ移行できる。

■ 3. 進化的アーキテクチャの実現とCDKの価値

• SAM vs CDKの比較:
  • 構成変更時の記述量: SAMは爆発的に増加するが、CDKは管理可能である。
  • 変更影響の可視化: SAMは困難だが、CDKはcdk diffで確認可能である。
  • 権限・接続管理: SAMは複雑なYAMLが必要だが、CDKはgrant/connectionsで直感的である。
  • 結果: 長期的な開発・保守性においてCDKが優位であり、進化的アーキテクチャの実現を可能にする。
• CDKの総合的な価値:
  • 構成変更時の記述量を大幅に削減し（SAMの1/3の複雑度）、変更影響の事前確認が可能である。
  • 直感的な権限・接続管理を実現し、段階的移行を支援する。
• 結論: アーキテクチャは「完璧な初期設計」を目指すのではなく、「育てるもの」である。サーバーレス環境において、CDKを活用することで、要件変化に柔軟に対応できる段階的な改善アプローチでアーキテクチャを進化させる。

(2025/09/27)

今改めてServiceクラスについて考える 〜あるRails開発者の10年〜

• 今改めてServiceクラスについて考える 〜あるRails開発者の10年〜 - Speaker Deck

要約:

■ 1. 過去の経緯と問題意識

• パーフェクトRailsでの記述: 2014年発売の『パーフェクトRuby on Rails』において、筆者はServiceクラスをコントローラーとモデルの中間に位置し、モデルの処理をまとめるインターフェースとして定義した。
• 後の見解の変化: 2016年末に「サービス クラスとか作るのは止めてくれ」という記事を公開し、わずか2年半で記述内容と異なる意見を表明した。
• 再議論のきっかけ: 2024年の懇親会での議論を機に、Serviceクラスの是非について改めて考察するに至った。
• Fat Modelの問題: Railsがビジネスの現場で多用されるにつれ、ActiveRecordの特性からくるFat Model（巨大化したモデル）の問題が顕在化し、その解決策としてServiceクラスが言及されるようになった。

■ 2. Serviceクラスの定義と乱用の難しさ

• DDDにおけるService: エンティティや値オブジェクトに責務を持たせると不自然になる場合に、振る舞いに着目して命名し責務を定義するものであり、命名はユビキタス言語に由来する必要がある。
• パーフェクトRailsでの役割: 処理そのものをカプセル化し、業務知識と実装のメンタルモデルを一致させる役割があると記述した。
• 乱用の危険性: 「乱用は危ないから考えてから使う」という基準の度合いが人によってバラバラであり、単純に複雑な処理に名前を付けて良いわけではないという理解が共有されていなかった。
• チーム開発での課題: チーム開発では共通認識が重要であり、Serviceクラスの基準が不明確だと一貫性が失われ、コードの全体像の把握や保守が困難になる。

■ 3. 現実的な解決策としてのFormクラス

• Railsの基本的な層: Controller、Model、Viewの基本的なレイヤーを守ることで、共通認識の維持と想像のしやすさというフレームワークの利点が得られる。
• Formクラスの役割: Serviceクラスと同じく複雑な処理の置き場所だが、Webアプリケーションにおけるパラメーターハンドリングとトランザクションコントロールを扱うという、より限定的な文脈に対処する。
• Serviceクラスとの違い: Formクラスは画面やユースケース（アクション）と紐づき、ActiveModel/ActiveRecordのインターフェースと親和性が高いという、名前から具体的なイメージが想像できる利点がある。
• 共通の難しさ: ServiceやFormを利用しても、結局ActiveRecordのメソッドレベルの境界をどこに設定するかという、モデルの整理から逃れられない。

■ 4. 根本的な重要事項とServiceクラスの今後

• 最も重要なこと: ServiceやFormといった表現技法は重要ではなく、RDBと向き合い、ActiveRecordを使いこなし、ドメインコンテキストの理解を深めることが重要である。
• ドメインコンテキストの理解: 複雑なシステム設計では、コンテキストマップ（境界づけられたコンテキスト）を作成し、システム内のコンポーネントと相互作用を設計する。
• モジュラーモノリスの導入: コンテキストの境界を明確にし、依存関係を一方向に保つための現実的な選択肢として、モジュラーモノリスが挙げられる。
• Serviceクラスの復活: モジュラーモノリスによってコンポーネントの境界が明確になった時、Webインターフェースに限定されないコンポーネントレベルの公開エントリポイントとしてServiceクラス（またはそれに類するもの）の利用は意味を持つ。
• 継続的な開発の難しさ: Serviceクラスを使う場合は、チームメンバー全員で利用ケースと言語化された必要性を共有することが不可欠である。ソフトウェア設計は、ビジネスの発展を継続的にサポートするために何度も判断を下し、改善し続ける営みである。

(2025/09/27)

モデリングとアーキテクチャの知見を積み上げて基幹システムに可変性を注入する

• モデリングとアーキテクチャの知見を積み上げて基幹システムに可変性を注入する - MonotaRO Tech Blog

要約:

■ 問題領域の特定: 在庫管理の「神テーブル」

• 深刻な現状: モノタロウの基幹システム（受注・配送・発注ドメイン）には、商品の在庫状況に関する属性がたった一つの巨大なテーブルに保存されている。
• 複雑性の原因:
  • レコード数は5000万件以上に及び、関連する更新ユースケースは80以上、参照ユースケースは730以上存在する。
  • 各ドメインがこのデータ構造に密に依存しており、データ構造の変更は入出荷停止リスクなど、ビジネス基本業務に深刻な影響を与える。
  • この「神テーブル」は在庫の状態のみを持ち、状態に至った経緯（理由）を把握できない。
  • 必要な数値の導出に他のテーブルとの結合が生じ、「在庫状況の管理」という文脈で担保すべき不変条件の範囲が曖昧になっている。
• 課題への取り組み: 業務とシステムの可変性を取り戻すため、この不要な複雑性の本丸である「在庫状況問題」の分割に取り組むことを決定した。

■ 課題の分割とドメインモデルの仮説構築

• 分割の常套手段: 「神クラス」分割の常套手段にならい、以下の手順で問題解決にアプローチした。
  • (1) 在庫状況に関連する更新ユースケースを網羅的に洗い出す。
  • (2) どのドメインがどの属性を更新しているか分類する。
  • (3) 属性のオーナー候補ドメインを仮定する。
• 在庫ドメインの仮説検証:
  • 存在が不確かな「在庫ドメインとその属性」を仮定し、既存の更新ユースケースが破綻なく処理できるか慎重に確認した。
  • 大規模ワークショップでモブプログラミングを実施し、在庫ドメインの属性と責務のイメージをつかんだ。
  • 更新ユースケースをシーケンス図に起こし、ドメインシステム間のメッセージングを確認した。
• 成果: 上記の密な調整を経て、ついに「在庫ドメインはあります！」という仮説（存在）に至り、積年の課題に切り込むことができた。

■ ドメイン駆動設計（DDD）によるアプローチ

• DDDの採用理由:
  • 問題領域が基幹業務であること。
  • 在庫管理の柔軟性がモノタロウの競争優位性の源泉となり得ること。
  • 最大の目的が業務とシステムの可変性を取り戻すことであるため。
• 体制強化: DDDエキスパートやリソース不足という足踏み要因を解消するため、専任チームを結成し、AWSプロフェッショナルサービスの支援を受けた。
• モデリングの手順:
• ビッグピクチャーの作成: フルフィルメント全体の業務イベントを可視化する大規模なイベントストーミングを実施。
• プロセスモデルの作成: 在庫状況の業務領域に絞り込み、イベントがどのように発生したかを分析。
• ドメインモデルの導出と洗練:
  • プロセスモデル上の集約を取り上げ、コマンドを振る舞い、必要となる値を属性として推定した。
  • 属性をエンティティと値オブジェクトに分けて集約を構成した。
  • その後、業務・モデル・コードを往復する試行錯誤（禅問答）を重ね、概念構成図などを活用しながらモデルを洗練させた。

■ レイヤードアーキテクチャによる実装と品質向上

• アーキテクチャの採用: 導出されたドメインモデルを実装するためにレイヤードアーキテクチャを採用し、以下の4層で構成した。
  • ビュー層: イベント受付（イベントハンドラ）
  • アプリケーション層: ビジネスロジック実行、ユースケース管理（集約のロードと振る舞い呼び出し）
  • ドメイン層: ビジネスルール、ドメインモデル定義（在庫集約、リポジトリインタフェース）
  • インフラストラクチャ層: データベースアクセス、外部システム連携（リポジトリ実装）
• 依存関係の逆転: ドメイン層がインフラストラクチャ層に依存するのを避けるため、リポジトリのインタフェースをドメイン層で定義し、実装をインフラストラクチャ層で行うことで回避した。
• メリット（保守性の向上）:
  • 各層の責任と関心事が独立し、システム全体の理解が容易になる。
  • 層間の依存が限定されることで、コードの変更の影響範囲が限定され、変更容易性が向上する（例: 同期→非同期への変更がビュー層の書き換えのみで済む）。
• ソフトウェアの「質」の向上: 「良いソフトウェア」であるために、設計原則の共有と定期的なリファクタリングを実施。
• リファクタリングの例（アプリケーション層）:
  • 複数のユースケースで共通していた「集約をロード→イベント適用→集約を保存」の処理の流れを特定。
  • SingleEntityCommandServiceという単一のサービスに共通処理を集約し、ユースケースごとにCommandインタフェースを渡す形にリファクタリングした。
  • これにより、コードの重複が減り、再利用性、メンテナンス性、拡張性が向上した。

■ 今後の展望

• 活動の継続: 在庫ドメインの成果を基幹システム分割・モダナイズ活動の一環として、今後も多くの業務領域に取り組む。
• 全体最適: 個別の業務領域と並行して、基幹システム全体の構造とマスタデータ管理の最適化を進める必要がある。
• 知見の共有と仲間探し: 得られた知見のドキュメント化やワークショップ開催を通じて、活動を推し進めるためのより多くの仲間を求めている。

(2025/09/27)

Railsによる人工的「設計」入門

• Railsによる人工的「設計」入門 - Speaker Deck

要約:

■ 1. 設計を体得できていない状態とは

• 問題の本質: 設計が何か分からなければ設計はできない
• 教える側と教わる側のすれ違い:
  • 教える側は「図や表を通じてシステムを考えられる」と考えるが、教わる側は「システム=コード」と捉えている
  • 教える側は設計によって重要な課題が洗い出せると考えるが、教わる側はコードが分からないと課題も分からないと感じる
• 設計していないことに気付かない問題: 初学者は「DB→モデル→コントローラ→ビュー」という手順を説明するだけで設計したと思い込む
• 手順による実装の実態: 実装前に全体を考えず、マイグレーションから作業を進めて最後に何を作れたか理解する状態

■ 2. 設計の定義

• 設計とは: コードのレベルで考えることなく、全体としてどういう構造や技術的要素を使ってどんなものを作るのが良さそうかを考え、作業の段取りを考えても良い状態にすること
• ベテランと初学者の違い:
  • ベテランは抽象度の高いレベルでシステムをまず考える
  • 初学者はコードのレベルだけでシステムを考えがち
• 設計は手順の前に来る: 手順を考える前にシステムの構造を考える必要がある

■ 3. 逆算による設計メソッド

• 順算との対比: 従来の「手順による開発」をまだ見えないゴールに向かってコードを順番に作る「順算」に例える
• 逆算の流れ:
  • まず完成したシステムを思い浮かべる
  • 中核的な「実現したいこと」にフォーカスする
  • 「それには何が必要か」を順々に考えていく
• 目的: 設計がよく分からない人を設計世界へ導入する手法である

■ 4. 実践例:ユーザーCSVインポート機能

• 完成形の想像:
  • 大量登録時の時間やメモリの問題を想定
  • 一部エラー時の処理方針を検討
  • エラー情報の表示方法を検討
  • インポート履歴の必要性を検討
• 課題の洗い出しと仮置き:
  • 非同期処理にすることを仮置き
  • 全部失敗方式を仮置き
  • Importモデルでエラー情報と履歴を管理
• ゴールの設定: 実際にCSVからユーザーが登録・更新されることを本質的なゴールとする

■ 5. ステップと名前付け

• ステップの定義: 見つけた「実現したいこと」「必要なこと」に短い名前をつけて形を書き出す
• 名前付けの重要性:
  • 設計は大きな粒度で考える活動である
  • 長い概念を短い名前に置き換えることで脳内スペースを節約できる
  • 設計は名前をつける行為の積み重ねである
• 具体例: 「インポートすること」自体をモデルにしてImportと命名する

■ 6. 開発領域の整理と手順計画

• 領域分け: 処理の順番や処理が書かれる場所の違いに注目して大まかにグルーピングする
• 手順の考え方:
  • データが準備しやすい流れを考える
  • 本質的なこと、難しいことをなるべく先にやる
• 設計後の手順の質の変化: DB→モデル→コントローラ→ビューではなく、Import登録→インポートロジック→一覧・詳細といった機能単位の手順になる

■ 7. デザインパーツの活用

• デザインパーツとは: 再利用性のある小さな設計パーツで、アーキテクチャや考え方を指す
• 主要なカテゴリ:
  • データ構造(ActiveRecord、関連、制約など)
  • 処理構造(MVC、コールバック、非同期処理など)
  • 個別機能・Gem(認証、認可、検索機能など)
• 効果: 色々なデザインパーツを理解していれば速く妥当な設計ができる

■ 8. 今日伝えたいこと

• 全体が機能するように設計する: アプリケーションだけでなくシステム全体が機能するように設計することが重要である
• システムコンポーネントとパターンの組み合わせ: パターンを組み合わせてシステムを構成することで全体の構造が現れる
• 初学者向けの手法: 完成形をイメージして中核的な価値の実現から逆算で1つ1つ要素の形を決めていく

(2025/09/27)

Redis is fast - I'll cache in Postgres

• Redis is fast - I'll cache in Postgres | Dizzy zone

要約:

■ 検証概要と設定

• 比較対象: RedisとPostgreSQLをキャッシング用途に使用した場合のパフォーマンスを比較検証。
• 環境設定: Kubernetes上で、PostgresまたはRedisを2CPU/8GiBメモリに制限し、デフォルト設定で実行。
• データセット: 事前に3000万件のデータを投入し、GET（取得）、SET（設定）、混合（Read/Write）の3種のワークロードで性能を測定。

■ パフォーマンス検証結果

• 総合性能: すべてのワークロード（GET/SET/混合）において、RedisがPostgreSQLよりも高速な結果となった。
• Redis側のボトルネック: Redisの処理能力ではなく、HTTPサーバー側のCPUが上限に達したことがボトルネックとなっていた。
• PostgreSQL側のボトルネック: 制限された2コアのCPUを使い切り、PostgreSQL側がボトルネックとなっていた。
• 非ログ記録テーブルの効果: PostgreSQLで非ログ記録テーブルを使用することで、特に書き込み（SET）性能は大幅に改善されたが、Redisの速度には及ばなかった。

■ 筆者の結論と考察

• 速度の優位性: RedisがPostgreSQLより高速であるという事実は認めている。
• 依存関係の削減: ほとんどのプロジェクトではPostgreSQLの性能で十分であり、Redisという新しい依存関係を追加しないことの利点を重視するため、Postgresを使い続ける。
• 性能の評価: Postgresの性能（7425リクエスト/秒、1日5億件以上のリクエストに相当）は、大半のプロジェクトの要件を満たす十分なものである。
• 柔軟な設計: キャッシュにインターフェースを設けておくことで、将来的に性能不足が生じた際にRedisへの切り替えを容易に行えるようにする。

MEMO:

• PostgreSQLをキャッシュストレージとして使った時の性能比較
• 当然Redisの方が早いが、PostgreSQLでも大半の場合で実用的な速度が出るし、システムの依存関係が減少するので、ブログの筆者はこちらを選択する、と
• とはいえ、DBがCPU使い切ったらサービス全体が停止するし、DBサーバをスケールアップするより、Redisをスケールアウトする方がコストが安いと思うのだが
• とはいえ（2回目）、そこまでアクセス数が発生しない or シビアに考える必要のないサービスならPostgreSQLをキャッシュサーバにしてもええやろというのは確かにそう

(2025/09/27)

AIと『対話しない』対話法、モノローグ法

• AIと『対話しない』対話法、モノローグ法 #ChatGPT - Qiita

要約:

■ 先進的プロンプトテクニックの概要と課題

• Backstep Prompting: 結論に至る思考プロセスをモデルに後退（バックステップ）させ、自己評価・修正させる手法である。
  • 目的と効果: 推論の正確性向上、ハルシネーション（幻覚）の抑制、思考プロセスの透明化に寄与する。
• Scaffolding（スキャフォールディング）: 複雑なタスクを小さなサブタスクに分解するための手順（足場）をプロンプトに含めるアプローチである。
  • 目的と効果: 複雑な問題解決能力の向上、回答の網羅性と一貫性の確保、出力形式の制御に有効である。
• 先進手法の課題: Backstep PromptingやScaffoldingは強力だが、毎回複雑なプロンプトを考える手間がかかり、「プロンプト職人」の腕に依存するという「人力での煩雑な作業」という課題がある。

■ 新しい対話法「モノローグ法」の提案

• 主語の転換: 従来のAIとのやり取りは命令形（Imperative）でAI（You）が主語であった。モノローグ法では、プロンプトの主語をあなた自身（I）に変え、一人称の表明形（Declarative）で思考をつぶやく。
• AIの役割変化: AIは「命令を待つ部下」から、ユーザーの思考に耳を傾ける「思考のパートナー」へと役割が変わる。AIの応答は思考の触媒として機能するが、無視できる自由があり、ユーザーの思考の流れを邪魔しない。
• メリット: ユーザーは「AIへの指示を考える」という制約から解放され、純粋に自分自身の思考を深める知的作業に集中できる。これにより、自然な形でBackstep PromptingやScaffoldingと同様の効果を得る。

■ モノローグ法のメカニズムと学術的裏付け

• 思考の触媒: AIの控えめな応答は、ユーザーの思考を客観的に捉え構造化するきっかけを与え、ユーザー主導でのScaffolding（思考の足場作り）を共同で行うプロセスとなる。
• 無視できる自由: 心理的なプレッシャーなしにAIの提案を無視・自己修正できる環境は、思考の寄り道や自己修正を促し、Backstep Promptingと同様の内省を自然に実現する。
• 学術的関連性: モノローグ法は、思考プロセスを外部化することで推論能力を高めるChain-of-Thought (CoT)、対話を通じて思考を洗練させるIterative Refinement、そして人間による自己批判・修正をAIと協調して行うSelf-Correctionの研究潮流と関連性が高い。

(2025/09/27)

プロジェクトマネジメントの基本をまとめてみた

• プロジェクトマネジメントの基本をまとめてみた #タスク管理 - Qiita

(2025/09/27)

「Android for PC」は2026年に――グーグルのキーパーソンが語る

• 「Android for PC」は2026年に――グーグルのキーパーソンが語る - ケータイ Watch

基調講演でサマット氏は、AndroidとグーグルのAIサービスである「Gemini」がスマートフォンだけではなく、テレビやスマートウォッチなど、ほかのデバイスからも利用できるようになってきたことを紹介。その上で、ユーザーが質問して答えを得る「オンデマンドモデル」から、AIがユーザーが抱える次の問題を「予測し」、アシスタンスを提供する「よりプロアクティブなモデル」へと移行すると指摘する。

その上で、基調講演のホストを務めていたクアルコムのモバイル・コンピュート＆XRグループジェネラルマネージャーであるアレックス・カトージアン氏（Alex Katouzian）がサマット氏へ「より大型のディスプレイデバイス」での生産性の変化について問う。

するとサマット氏はAndroidエコシステムのすべてのデバイスに対して「シームレスに一緒に機能すること」をユーザーの多くが望んでいると解説。ノートパソコンという形態に対して、グーグルではChromeOSを提供し成功した、とした上で、AIの進歩から「可能な限り迅速に、ラップトップのフォームファクターにもたらすか」（サマット氏）という課題を指摘する。

そこで現在、グーグルが実行していることはChromeOSの体験をもとに、Androidに融合することとして、その融合について「来年に向けて非常に興奮している」と説明。2026年の投入を示した。

(2025/09/26)

見逃していませんか？Google Go Style Guideの継続的アップデート

• 見逃していませんか？Google Go Style Guideの継続的アップデート - ANDPAD Tech Blog

(2025/09/26)

大してアクセスないサイトにECSはオーバースペック

• 大してアクセスないサイトにECSはオーバースペック

MEMO:

• そのレベルで良いなら、スタティックサイトジェネレータ + S3で良さそうではあるが

(2025/09/25)

Webサービスにおける非同期処理の勘所

• Webサービスにおける非同期処理の勘所 - pospomeのプログラミング日記

要約:

■ 1. 非同期処理の定義と採用基準

• 非同期処理の定義: Webサービスにおける非同期処理は、AWS SQSやGoogle Cloud Pub/Subなどのメッセージキューを利用し、バックエンドサーバーがキューにメッセージを入れ、ワーカーがそれを非同期に処理する仕組みを指す。
  • 構造: クライアント → バックエンドサーバー → AWS SQS/Pub/Sub → ワーカー
• 採用基準: 非同期処理は基本的に面倒であるため、同期処理では要件を満たせない時にのみ採用すべきである。
• 同期処理で要件を満たせないケース:
  • 大規模な時間のかかる処理: 巨大なCSVファイルのダウンロードやアップロード・DB登録処理など、利用者を長時間待たせたり、DBに高負荷をかけたりする場合。
  • 高RPS（Request Per Second）環境での外部API呼び出し: レイテンシの高い外部APIを複数回叩くエンドポイントに大量のリクエストが集中し、バックエンドサーバーのリソース（コネクションプールなど）が枯渇したり、スケール効率が悪化したりする場合。

■ 2. 非同期処理で考慮すべき面倒なポイント（設計フェーズ）

• (1) メッセージキュー/タスクキューに対する理解:
  • 課題: AWS SQSやGoogle Cloud Pub/Subなど、利用する仕組みの仕様、機能、オプション、制限を正確に理解しておく必要がある。
  • 運用上の考慮点: メッセージが溜まった際のワーカー数の手動スケールの必要性、それに必要なアラートやメトリクスの取得・設定を設計に含めるべきである。
• (2) ワーカー処理が失敗したときのリカバリ方法:
  • 課題: ワーカーの処理は100%成功しないため、失敗時のリカバリ方法を設計する必要がある。
  • 手動リカバリ: 失敗頻度が低い場合は、エンジニアが手動でメッセージを再キューイングする方法が考えられるが、手順の複雑化や手順書の最新性維持が困難になる可能性がある。
  • 自動リカバリ: 失敗した処理をDBに記録し、定期実行バッチでリトライする方法が考えられるが、実装の手間やバッチ自体の失敗対応、処理タスク数の設計など、考慮点が多くなる。
• (3) ボトルネックの確認と対策:
  • 課題: 非同期処理を採用しても、最終的に処理はどこかで実行されるため、ボトルネックや負荷は残る。特にRDBがボトルネックになる可能性が高い。
  • 具体的なボトルネック: DBへの複雑なクエリや大量クエリによるDB負荷、メッセージ集中によるワーカー数クオータ上限到達、アラート発火などが考えられる。
  • 対策例:
    • 同時に実行できるワーカー数を制限する。
    • ワーカー処理用に専用のDBインスタンス（分析用DBなど）を用意する。
    • メッセージキューにキューイングできるメッセージ数を制限する。
    • ワーカー処理にsleepを入れ、クエリ実行間隔を長くする。
  • 補足: ハイトラフィックな非同期処理では、RDBよりもNoSQLやNewSQLといったスケールするDBとの相性が良い。

■ 3. 結論

• システムのスケーラビリティ: 非同期処理は面倒ではあるが、システムのスケール性能やサービス間の疎結合化を実現する上で非常に魅力的である。
• 将来の展望: ある程度の規模のシステムでは非同期処理の利用が避けられないため、エンジニアや組織は、システムのスケールに合わせて非同期処理を適切に扱えるようになるための変化への投資が必要となる。
• 重要性: 非同期処理は実装自体は簡単だが、設計フェーズで上記の面倒なポイント（仕様理解、リカバリ、ボトルネック）を考慮しなければ、リリース後の運用で大きな問題が発生する可能性が高い。

(2025/09/24)

Rails Needs New Governance

• Rails Needs New Governance

要約:

■ 1. DHH（David Heinemeier Hansson）の問題点

• DHHの人物像: Ruby on Railsの生みの親であるDHHは、成功した賢い人物であると評価されている一方、「Ruby界のFox News」と表現され、議論好きで反動的、反知性的、そして無礼な人物であると批判されている。
• 思想の変遷: DHHは、自身のブログで、当初は中道的な政治的信条を持つように見えたが、数年かけて反キャンセルカルチャー、反DEI、反トランスジェンダー、そして最終的にはナショナリズムへと傾倒していった。
• ファシズム的言説: ロジャー・グリフィンのファシズムの定義（国民の再誕を求めるポピュリスト的な超国家主義）を引用し、DHHの最近のロンドンに関するブログ投稿が、この「ファシズム」に該当すると指摘している。彼は、人種的多様性を否定し、人種的に純粋だった過去を賛美している。
• 矛盾: DHHは過去に「郷愁を嫌う」と述べていたにもかかわらず、近年の投稿では、DEIやキャンセルカルチャーが問題視される前の時代への郷愁を強く示している。

■ 2. RubyおよびRailsコミュニティのガバナンスの問題

• DHHの権力: DHHはRailsの著作権を保有し、Rails Foundationの創設者兼議長であり、彼の政治的信条にもかかわらず、Ruby Centralのような組織や、カンファレンスやポッドキャストなどのコミュニティから引き続き発言の場を与えられている。
• Ruby Centralへの不信感: Ruby Centralは、明確な事前通知やコミュニケーションなしに、RubyGems.orgのGitHubコードベースの管理権を強制的に引き継ぎ、全てのメンテナーのアクセスを取り消した。この不透明な行為により、コミュニティからの信頼を失っている。
• 企業の影響力: Railsの運営はShopifyからの資金に大きく依存しており、DHHやShopifyのCEOであるTobi Lütkeのような、右派の思想を持つ人物にコミュニティの方向性が左右されている。
• 行動規範の機能不全: RubyおよびRailsの行動規範は「寛容のパラドックス」に陥っており、憎悪に満ちた言説を排除できない構造になっている。

■ 3. 解決策と今後の展望

• 民主的な組織への移行: 企業スポンサーに依存するのではなく、コミュニティが主導する民主的な組織を設立することを提案している。この組織は、公開されたメンバーシップと民主的に選出されたリーダーシップを持ち、RubyGemsやRailsといった重要なプロジェクトを管理する。
• フォークの可能性: DHHがRailsの著作権を保有しており、自ら辞任する可能性が低いことから、RailsやRubyGemsのコミュニティ・フォーク（分岐）が必要になる可能性がある。
• 行動の呼びかけ: コミュニティは現状に甘んじるべきではないと主張している。DHHやRuby Centralに反発してコミュニティを去ったメンテナーたちが、新しいガバナンスの下で復帰することを呼びかけている。

MEMO:

• 揉めておるな

(2025/09/23)

言い訳しているひとは、自分が言い訳していると知っているし、自分を虚飾しているひとは自分が虚飾...

言い訳しているひとは、自分が言い訳していると知っているし、自分を虚飾しているひとは自分が虚飾していると知っている。心の表層では気づいていないけれど、深層では知っている。だから、ストレスがかかり、メンタルが病んでいく。

@sugimoto_kei

心の深層は自分ではみえない。だけど、徴候は現れる。人に会いたくなくなったり、何かを喋る時に口角がひきつる。話している相手が不自然に沈黙する。酒が欲しくなる。そうした徴候をとらえて、あれ、オレ、なにか誤魔化してないか、と探ることはできる。

sugimoto_kei

MEMO:

• だから杉本センセは陰湿な攻撃性を発露するというわけである
• 自己認識が出来てえらい

(2025/09/23)