Top List Tag Search

/note/tech

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

(2025/11/07)

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

(2025/11/07)

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

(2025/11/06)

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

要約:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

■ 8. Temporalの採用

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

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

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

■ 10. uutils/coreutilsの採用

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

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

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

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

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

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

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

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

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

(2025/11/05)

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

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

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

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

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

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

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

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

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

@kosuke_agos

(2025/11/05)

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

(2025/11/05)

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

(2025/11/05)

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

要約:

■ 1. 記事の目的と対象

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

■ 2. ValueObjectとEntityの違い

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

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

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

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

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

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

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

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

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

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

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

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

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

■ 9. 実装のポイント

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

■ 10. まとめ

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

(2025/11/05)

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

(2025/11/04)

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

(2025/11/04)

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

まぁ、幻想じゃないね w

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

早ければ早い方がいい。

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

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

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

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

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

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

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

でも草野球は楽しめる。

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

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

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

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

落ち着きないし。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

マイカーガー。

マイホームガー。

子供ガー。

愛犬ガー。

んなもん知るかっ！

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

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

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

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

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

1年で10。

2年で30とか。

マジかよ w

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

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

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

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

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

これで3倍界王拳だ w

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

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

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

はっきりいう。

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

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

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

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

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

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

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

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

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

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

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

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

じゃねーよ。

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

ってのが多い。

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

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

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

って現場、多い。

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

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

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

それはともかく、

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

「……は？」

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

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

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

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

「Cloneして立ち上げます」

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

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

「120個？」

「120個」

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

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

「……動かないぞ」

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

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

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

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

「ほう……？」

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

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

っていつも思う。

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

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

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

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

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

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

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

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

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

「致命的な才能の欠如」

って呼ぶんよ。

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

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

MEMO:

(2025/11/03)

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

要約:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

■ 9. 変化の時間軸予測

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

■ 10. 発注型仕事の消滅

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

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

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

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

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

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

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

MEMO:

(2025/11/02)

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

(2025/11/02)

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

(2025/11/02)

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

要約:

■ 1. 現状の課題

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

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

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

■ 3. なぜそうなるのか

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

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

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

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

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

(2025/11/01)

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

要約:

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

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

■ 2. 代替案

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

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

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

MEMO:

(2025/11/01)

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

要約:

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

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

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

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

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

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

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

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

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

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

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

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

■ 7. 具体的な解決事例

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

(2025/10/31)

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

(2025/10/31)

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

(2025/10/31)

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

tag:

(2025/10/31)

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

(2025/10/30)

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

(2025/10/30)

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

(2025/10/30)

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

(2025/10/30)

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

(2025/10/29)

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

要約:

■ 1. BitNet Distillation(Microsoft Research開発)

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

■ 2. HunyuanWorld-Mirror(Tencent開発)

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

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

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

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

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

■ 5. 共通トレンド

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

(2025/10/29)

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

(2025/10/28)

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

(2025/10/28)

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

関連:

(2025/10/27)

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年史──脚光の裏にあった「日本語対応」と「パッケージ配布」

(2025/10/26)

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

(2025/10/26)

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

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

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

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

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

〇本書のポイント

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

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

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

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

〇こんな方におすすめ

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

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

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

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

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

MEMO:

(2025/10/25)

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

要約:

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

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

■ 2. 現在のキャリア

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

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

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

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

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

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

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

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

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

■ 7. 評価のギャップ

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

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

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

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

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

■ 10. 仮想敵の問題

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

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

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

■ 12. 音大でのピボット

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

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

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

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

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

■ 15. 挫折の認識

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

■ 16. 虚像からの脱却

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

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

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

■ 18. YAPCでの反響

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

■ 19. CTOという肩書き

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

■ 20. LayerXへの転職

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

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

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

■ 22. 会社と人の関係性

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

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

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

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

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

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

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

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

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

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

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

(2025/10/25)

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

(2025/10/25)

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

(2025/10/25)

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

(2025/10/24)

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

(2025/10/23)

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

【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年後必要な人材ですか？

(2025/10/23)

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

要約:

■ 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を構築しよう

(2025/10/22)

How to send progress updates

翻訳:

進捗状況の報告方法

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

  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」

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

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氏 基調講演：開発生産性測定のトレードオフ「グッドハートの法則」は...

要約:

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

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

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

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

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

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

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

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

■ 5. プルリクエスト指標の事例分析

  • 正のフィードバックループ: 優れた開発者は小さなPRを多く出し、それが読みやすさ、協力の増加、無駄の削減につながる自己強化型の仕組みを形成する
  • 圧力による崩壊: PRランキング表を作成して圧力をかけると、開発者は筋の通ったPRを細切れにして数を水増しするようになる
  • 協力の減少: PRを細分化することで読みにくくなり、協力が減少し、無駄が増加し、最終的にPR数も減少する
  • 悪循環の発生: 誰も下位にいたくないため全員が同じ行動を取り、ソフトウェア開発プロセス全体が悪化する

■ 6. コード行数指標の歴史的失敗

  • 生産性指標としての採用: コード行数がプログラマーの生産性を測る正しい指標だと考えられた時代があった
  • プログラマーの対応: プログラマーはコードを生成するプログラムを書くことができるため、機械的に大量のコードを生産できる
  • 逆効果の結果: 求めていた成果とは正反対の結果を生み出し、仕組みを悪化させた

■ 7. グッドハートの法則を超える悲観的現実

  • 規則性の崩壊を超える破壊: 統計的規則性に圧力をかけると、単に規則性が崩壊するだけでなく、規則性を生み出した仕組み自体を壊してしまう
  • 意図と逆の結果: レバーを引くことで期待や意図とは真逆の結果が生じる
  • より深刻な問題: 単にレバーが機能しなくなるのではなく、システム全体が望まない方向に向かう

■ 8. 複数指標によるバランスの幻想

  • バランス指標の提案: PR数だけでなく欠陥数やレビュー時間など複数の指標を組み合わせるべきだという主張がある
  • 問題の非解決: 導入するすべての指標が仕組みをゆがめるため、複数の指標を導入しても問題は解決しない
  • 理解困難化の加速: 指標が多ければ多いほど、システムは理解しづらく制御しづらいものになる
  • 完璧な指標セットの不在: うまく開発するための指標のセットは存在せず、指標による自動的な改善という発想自体が誤りである

■ 9. 人間性の軽視と創造性の抑圧

  • 機械的制御の危険性: 何も考えずに指標を改善するだけですべてうまくいくという発想は、開発者の人間性を無視している
  • 思考の後押しの必要性: プログラマーは考えることを促され、創造性に任せられることを望んでいる
  • 数値化不可能な要素: 思考、洞察、創造性のプロセスは単純な数字に表すことができない
  • 創造性の喪失: 数値化しようとするあらゆる試みが、ソフトウェア開発に注ぎ込まれるべき思考と創造性を奪う

■ 10. システムによるゆがんだ目標の採用

  • 目標の放棄を超える問題: システムは制御の圧力を軽減するために本来の目標を放棄するだけでなく、ゆがんだ目標を新たに採用する
  • 本番障害指標の例: 本番環境での障害をなくせという圧力をかけると、障害報告がなくなる(報告しないことで数字をゼロにする)
  • 創造的な回避行動: 頭が良く創造的な開発者は、数字をゼロにする何らかの方法を必ず見つけ出す
  • 全方位的な悪影響: 仕組みをだますプログラマー、会社、顧客、社会全体にとって悪い結果をもたらす

■ 11. 指標による制御の本質的限界

  • 人間の判断の排除: 人の働きを単純な数字で表し、人間の判断を不要にして数字だけで制御しようとする試み自体が問題である
  • 望まない目標の採用: システムが新たに採用する目標は、組織が真に達成したい目標とは異なるものになる
  • 指標の種類や数は無関係: どのような指標を使用し、いくつ組み合わせ、どれだけバランスを取っても問題の本質は変わらない
  • 脱出方法の必要性: この悪循環から抜け出す方法を見つける必要がある

要約:

■ 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エンジニア転職ブーム”から数年後の現実

要約:

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

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

(2025/10/20)

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

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

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

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

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

【影響内容】

■ご注文受付の停止

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

＜エラーになる画面＞

・お買い物カゴ

・レジ

・ご注文内容印刷

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

■出荷の停止

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

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

■新規ご利用登録の停止

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

■その他サービスの停止

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

■お問い合わせ窓口

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

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

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

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

以上

MEMO:

(2025/10/19)

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

(2025/10/19)

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

要約:

■ 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、新しいパスワードガイドライン公開 - これまでの常識を覆す新ルール

(2025/10/18)

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

(2025/10/18)

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

(2025/10/18)

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

要約:

■ 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併用アーキテクチャ

(2025/10/18)

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

(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「属人化レビューと知識の偏り」

(2025/10/17)

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

(2025/10/17)

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

(2025/10/17)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@Anubis_369

MEMO:

(2025/10/17)

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

(2025/10/16)

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

(2025/10/16)

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

(2025/10/16)

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

(2025/10/15)

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

要約:

■ 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標準で新しい世界へ

(2025/10/13)

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撲滅委員会

要約:

■ 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

要約:

■ 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

要約:

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

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

要約:

■ 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ツールでどこまでデザインを忠実に実装できるのか

(2025/10/12)

VALORANT's 128-Tick Servers

要約:

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

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

(2025/10/10)

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. 階層構造の基本と背景

  • 階層構造の例: クラウドストレージサービスにおけるフォルダやレシピサイトにおける材料タグは階層構造を持ち、親ノード・子ノード・祖先ノード・子孫ノードの取得、子ノードの作成、ノードの移動、ノードとその全ての子孫ノードの削除などの機能が必要である
  • プロダクトの成長: 開発当時は導入社数が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はどのように使われていくのか？

要約:

■ 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ヤフーを辞めました。

要約:

■ 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の中立的...

要約:

■ 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アンチパターンリファクタリング

要約:

■ 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分ミーティングで強くする

要約:

■ 1. 背景と課題

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

■ 2. 実施した取り組み

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

■ 3. 工夫と効果

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

(2025/10/09)

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

要約:

■ 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リファクタリングにおける戦略と実践方法

要約:

■ 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に向いてるって誰が言いだしたんだ？

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

要約:

■ 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のフォーマットチェックを「無神経でクレイジー」と酷評

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へ向けて

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

MEMO:

(2025/10/06)

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の夢の果てにて

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の画面から目を逸らすと、そんな業塗れの世界とは無縁とばかりに、多摩川上流のほとりで小魚たちが澄んだ水の中を悠々と泳いでいる…

関連:

MEMO:

(2025/10/06)

海外で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制作会社で働いているのだが、

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

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

「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

要約:

■ 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

要約:

■ 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

要約:

■ 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(行動規範)が多くのオープンソース・プロジェクトに不要な理由

要約:

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

NEXT