/note/tech

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

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

要約:

■ 1. プロジェクト概要

1.1 所属チーム・役割

• チーム名: 新規プロダクトのAPIプラットフォームチーム
• ミッション: 変更容易性の高いAPIを作成し、素早い仮説検証サイクルを回せるものづくり体制を実現すること

1.2 開発体制

• 関係チーム: 複数のフロントチーム
• スクラム体制:
  • プロダクトオーナー(PO)
  • スクラムマスター(SM)
  • 開発者4名(テックリード含む)
• 技術構成: モノレポ構成

1.3 Go採用の背景

• 弊社のバックエンド推奨言語として、以下の3つの基本方針に基づきGoを採用:
  • 標準化: 組織全体での技術統一
  • 省力化: 開発効率の向上
  • 最新化: 技術スタックの継続的な改善
• パフォーマンスと安定性が求められるバックエンドAPIでの豊富な採用実績あり。

■ 2. ドメイン駆動設計(DDD)の基礎

2.1 DDDとは

• ドメイン: 事業領域のこと
• ドメイン駆動設計: 意図の伝達を円滑にし、事業戦略とソフトウェアの実装を結びつける設計手法
• 特徴: アジャイルとの相性が良く、市場や戦略の変化に柔軟に適応できる

2.2 重要な概念

• 戦略的設計と戦術的設計
  • Why・WhatとHowの関係性を明確化
• 業務領域(サブドメイン):
  • 事業目標達成のために事業活動を分析し、ドメインを細分化したもの
  • 建設的に手を抜き、中核領域に集中できるよう業務領域を分類
• 境界付けられたコンテキスト(BC)
  • ソフトウェア設計の視点から事業活動モデルを扱いやすい単位にするため、ドメインを分解したもの
• ドメインモデル
  • 中核の業務領域を対象に、複雑な業務ロジックを扱うための設計手法
• 業務ロジック
  • 業務領域におけるルールや前提条件、制約
  • 値オブジェクト、集約、業務サービスで扱うドメインに関するロジックの総称

■ 3. Go × DDDの相性

3.1 Goの強み

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

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

4.1 実装例のテーマ

• 機能概要: AIを使用し、ユーザーの悩み解決におすすめの書籍をピックアップする
• アーキテクチャ:
  • 中核の業務領域: 「Recommendation(レコメンド)」
  • 連携BC: 「お気に入りリスト」「ユーザープロファイル」

4.2 主要コンポーネント

• 値オブジェクト
  • 不変性を持つドメインの値を表現
• 集約
  • トランザクション境界を表現
  • 粒度の考慮:
    • 大きすぎる → パフォーマンス悪化
    • 小さすぎる → 結果整合の制御が増え、設計コストが高くなる
• 物理的な境界: BC(1BCに対しスキーマ群)、1集約1リポジトリ(永続化の単位は集約)
• BCに対してマイクロサービスを適用(モノレポでBCごとにモジュール化)
• 業務サービス
  • ドメイン固有のロジックを実装
• 実践ポイント
  • フィールド非公開と、慣習的なファクトリメソッドを使用する
  • スライスやマップを扱う場合は外部へ渡す前に必ずコピーするなど不変性を意識する
  • アプリケーションサービスは薄くし、業務ロジックはドメイン層で実装

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

5.1 DDDの難しさ

• ドメイン駆動設計の理解と実践における課題

5.2 具体的な取り組み

• ドメイン駆動設計の理解促進
• プロジェクトの価値や目的を自分の言葉で再定義し、所属チームレベルにブレイクダウン
• 企画職の方と日次15分間、理解を深める枠を設定
• 「ドメイン駆動設計をはじめよう」をチーム全員で読み、用語自体の勉強会を実施
• AWSワークショップ & 社内でのイベントストーミング実施

AI活用

• Claude Code での開発
• 構想中の取り組み (速さを落とさず、基盤的内容変更の共通認識を最短ループで回すことを目的):
  • CLAUDE.mdに人もAIも認識しておきたい内容を記載
  • Claude Code Actionsを使用し、PR作成時に「CLAUDE.mdのルール準拠チェック」「追記要否判定」を実施

■ 6. まとめ

6.1 核心メッセージ

• AIにより素早い仮説検証が可能となった今だからこそ、ドメインを基にした「本質的な設計」の重要性が高まっている

6.2 Go × DDDの価値

• 共通言語となるモデル: チーム間のコミュニケーション円滑化
• 変更容易性の高いシステム: 市場変化への迅速な対応
• 後方互換性の高い言語仕様: 長期的な保守性
• 設計の自由度: ドメインに最適化されたアーキテクチャの実現

(2025/10/08)

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

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

要約:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

■ 8. まとめ

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

(2025/10/08)

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

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

https://anond.hatelabo.jp/20251004160446

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(2025/10/08)

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

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

要約:

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

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

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

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

■ 3. 筆者自身のAI依存

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

■ 4. 権威の問題

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

■ 5. 自信の心理学

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

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

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

■ 7. 次世代への懸念

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

■ 8. 教訓と今後の姿勢

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

(2025/10/07)

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

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

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

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

(2025/10/07)

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

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

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

MEMO:

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

(2025/10/06)

How Functional Programming Shaped (and Twisted) Frontend Development

• How Functional Programming Shaped (and Twisted) Frontend Development

要約:

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

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

■ 2. 著者の背景

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

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

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

■ 4. Webの本質

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

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

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

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

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

■ 7. Tailwind CSSへのピボット

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

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

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

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

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

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

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

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

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

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

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

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

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

■ 14. 失ったもの

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

■ 15. なぜこうなったか

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

■ 16. 進むべき道

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

• 意味すること:

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

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

■ 17. 結論

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

(2025/10/06)

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

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

https://anond.hatelabo.jp/20251004160446

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

■ 夢の後先　IT業界の残照

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

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

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

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

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

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

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

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

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

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

関連:

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

MEMO:

• カスみたいなポエムだ

(2025/10/06)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

■ 追記

https://anond.hatelabo.jp/20251006123907

(2025/10/05)

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

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

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

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

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

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

というフレーズだ。

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

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

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

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

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

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

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

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

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

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

MEMO:

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

(2025/10/04)

Stop Avoiding Politics

• Stop Avoiding Politics – Terrible Software

要約:

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

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

■ 2. 政治の本質的定義

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

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

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

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

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

• 政治的スキルの実態:

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

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

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

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

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

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

■ 7. 良い政治の実践例

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

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

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

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

• 効果的に上司を管理:

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

• Win-Win状況を作る:

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

• 可視性を持つ:

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

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

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

■ 9. 結論

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

(2025/10/04)

The Software Essays that Shaped Me

• The Software Essays that Shaped Me · Refactoring English

要約:

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

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

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

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

• Alexisの解決策:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(2025/10/03)

The Magic of Claude Code

• The Magic of Claude Code

要約:

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

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

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

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

■ 3. Unix哲学の原則

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

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

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

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

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

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

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

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

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

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

■ 7. コードを超えて

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

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

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

■ 9. 重要なポイント

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

(2025/10/02)

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

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

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

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

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

@Okamoto_Lexa

MEMO:

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

(2025/10/02)

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

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

要約:

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

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

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

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

■ 3. 線形思考の限界

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

■ 4. システムの定義

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

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

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

■ 6. 概念的完全性

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

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

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

■ 8. 反直感性

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

■ 9. 氷山モデル

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

■ 10. 実践への統合

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

(2025/10/02)

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

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

要約:

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

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

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

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

■ 3. Contributor Covenantによる標準化

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

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

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

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

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

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

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

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

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

■ 8. Contributor Covenantの脆弱性

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

■ 9. Ruby CoCの優位性

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

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

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

(2025/10/01)

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

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

要約:

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

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

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

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

■ 3. レートリミットの基礎

• 基本的な効果: 「同じ作業を何度もする」という自動化のニーズに対して、リクエストが通常より早く多くなる特性を利用して検知できる
• 万博での検知: 万博ウェブサイトも回数/期間で自動化を検知していると考えられ、自動化していないユーザーもBAN報告をしている
• 一般ユーザーへの影響: 手動で何度も試行を行うユーザーも特定期間内に閾値を超えてBAN状態になる問題がある
• 限界: 最低限自動化を防ぐことはできるが、実装は簡単である一方で効果が限定的になることも多い

■ 4. レートリミットのアルゴリズム

• トークンバケット:
  • ユーザーごとにトークンを一定間隔で補充し、残っている間だけリクエストを許可する
  • リクエストごとにトークンを消費し、無くなったら制限を行う
  • Twitchが採用しており、一時的にリクエスト量が増える状態でも対応できる
• リーキーバケット:
  • 空きが空いたらリクエストを流せるようにする方式で、水の入ったバケツがちょっとずつ漏れていくイメージ
  • リクエストは一定の速度でしか流せない
  • Shopifyが採用しており、処理を一定に保ちたいときに便利
• 固定ウィンドウカウンタ:
  • 1秒間にN回までと決める方法
  • 実装は簡単だが、期間の切り替わる瞬間にリクエストが集中すると2倍通ってしまう問題がある
• スライディングウィンドウ:
  • 最新のリクエストを基準に過去一定範囲が閾値を超えないか判定する
  • スライディングウィンドウログ(厳密だがメモリ効率が悪い)とスライディングウィンドウカウンタ(直前の結果から間隔を推定)の2種類がある

■ 5. CAPTCHA

• 基本機能: 画像認証、パズル、音声認証などで人間とロボットを判別・区別する
• 代表的サービス: reCAPTCHA、hCaptcha、Cloudflare turnstile(JS Challenge)
• 効果と問題点: かなり高い精度でBotを弾けるが、ユーザー体験を大きく損なうこともある
• 突破可能性: Driverや外部サービスを使った突破方法もあるが、攻撃者目線でコストがかかる
• 推奨: hCaptchaは突破にかかる労力やコストが高い。Cloudflare turnstileはユーザー体験的に良いが突破が比較的簡単
• 名称の由来: 「Completely Automated Public Turing test to tell Computers and Humans Apart」の略

■ 6. デバイスフィンガープリント

• 概要: ブラウザや端末の環境情報(User-Agent、フォント、解像度、OSバージョン、Canvasの動作など)を組み合わせて同一環境からのアクセスかを推定する
• 使用方法: これらを保存して比較することができる(例: bcadc52670c11a5b8789853a6ef178ef)
• 制限と問題点:
  • Firefoxブラウザーや、AdBlockerなどの拡張機能には防ぐ機能が存在することがある
  • プライバシー的にグレーと言われているため、採用には注意が必要
  • ユニークではないので被ることはある
• 実装: FingerPrintJSなどのライブラリが利用可能

■ 7. コードのローテーション

• 基本戦略: コードの難読化を毎日変更したり、共通鍵をローテーションする
• 効果: イタチごっこにはなるが、攻撃者のコストをかなり上げることができる有効な手段
• 実例: X(旧Twitter)もこの方法を採用している(x client transaction idで検索可能)

■ 8. ネットワークベースの制御

• 基本前提: 攻撃者は海外IPを利用していることが多い(VPNやProxyの都合上)
• 地域制限:
  • 特定の国や地域からのアクセスを制限する
  • 例: 中国のアクセスを遮断、もしくはCAPTCHAを表示するように変更
  • 日本以外からのアクセスを制限することも可能
• VPN・データセンター判定:
  • VPNは既知の物が多く、串はデータセンターを利用している場合が多い
  • この二つが判定できれば弾くことができる(例: ipinfo.io)
• Tor制御:
  • Torの串は無料で簡単に使えるので利用している攻撃者も多い
  • Torからのアクセスを遮断あるいはCAPTCHAを行うことで効果が出る
• 注意点: 正規ユーザーがVPNを使っている場合もあるので誤検知のリスクは残る
• Cloudflare Enterprise: 機械学習を利用した検知を提供しており、Header "cf-bot-score"にBotの疑いがある数値(2-99)が入る

■ 9. アカウントレベルの制限

• 新規登録制限: 新規登録直後は利用制限をかける
• 信頼スコア: 信頼スコアが低いアカウントは厳しいチェックをする(通報などでスコアを下げていく)
• 認証ハードル: 電話番号や二段階認証でハードルを上げる
• SMS認証のコスト: 大体1通10円が定価であり、レートリミットは厳重にする必要がある(破産した人も存在する)
• 行動パターン分析: 「投稿時間が毎日一定である」などサービスの特色に応じた様々な方法が考えられる

■ 10. 番外編の対策手法

• ハニーポット的手法:
  • 本物の入力フォームとは別に「偽フォーム」を置き、Botだけが入力してしまうようにする
  • 無差別に攻撃を行っているBotにのみ効果があるので注意
  • HTMLのhiddenフィールドに「埋めるべきでない値」を仕込み、入力されたらBot判定する
• スキャナー対策: Shodanのようなscannerを避けたいなら、/wp-admin/*などのスキャンをトリガーにしてアクセス禁止にする
• 複合的アプローチの重要性: これらの方法は複数組み合わせてやっと効果が出る。例えば、レートリミットだけでは怪しいIP(海外のProxyなど)を弾けなければ突破される

■ 11. 総合的な防御戦略

• 多層防御の必要性: 単一の対策では効果が限定的であり、複数の手法を組み合わせることが重要
• 攻撃者のコスト増加: 各対策の目的は攻撃者をうんざりさせ、攻撃のコストを上げることにある
• 実装の容易さと効果のバランス: レートリミットは実装が簡単で多くのライブラリが存在するが、CAPTCHAやデバイスフィンガープリントなど、より高度な対策も検討する必要がある
• プライバシーとセキュリティのバランス: デバイスフィンガープリントなど一部の手法はプライバシー的にグレーゾーンであり、採用には慎重な判断が必要

(2025/10/01)

企業だと月30万円の売上しか出ないゲームやアプリって「事業として成り立たない」でボツになる。でも...

• 企業だと月30万円の売上しか出ないゲームやアプリって「事業として成り立たない」でボツになる。でも個人開発なら月30万円ってだいぶ美味しいので、企業が「小さすぎて手を出せない宝石」を僕らは拾い放題という話 - posfie

MEMO:

• 企業は人件費/固定費が掛かるので小さな事業は費用対効果が見合わない
• 個人勢はその辺殆ど掛からないので小さい事業を複数展開すれば喰っていける（かも）
• まぁ、個人事業主が戦うべき戦場はそこよな

(2025/10/01)

オープンソースに匹敵する大変革「オープンソーシャル」が徐々に広がり中、自分のデータを使い回して...

• オープンソースに匹敵する大変革「オープンソーシャル」が徐々に広がり中、自分のデータを使い回して色んなウェブサービスを使える仕組み - GIGAZINE

要約:

■ 1. オープンソーシャルの概念

• 定義: 閉じた世界で動作する既存のSNSに対して、共通の規格に基づいて動作するSNSを指す
• 既存SNSの問題点: XやFacebookなどではユーザーのデータが各運営企業によって管理されており、投稿内容やフォロー情報を保ったまま別のサービスに引っ越すことは不可能である
• 解決策: 各ユーザーが自分のデータを自分で管理できる仕組みを構築する
• オープンプロトコルの種類: MastodonのActivityPub、ジャック・ドーシー関与のNostr、BlueskyのAT Protocolなど複数のオープンプロトコルが存在する

■ 2. アブラモフ氏の経歴と見解

• 経歴: MetaでReactの開発に携わり、2023年頃にBluesky開発チームに加わってクライアントアプリ開発を推進した
• 現在の活動: 2025年夏頃にBluesky開発チームを離れ、UIエンジニアリングに関するコンサルティングを行っている
• AT Protocolの評価: 自身はプロトコル設計に関わっていないと前置きしつつ、AT Protocolを「オープンソーシャルの好ましい一例」と絶賛している

■ 3. 昔のウェブ環境との比較

• 昔のウェブ環境: 各個人が自分でウェブサイトを開設し、コンテンツを配置したり他人のサイトにリンクしたりしていた
• データの移行可能性: ホスティングサービスが終了したりポリシーが変化した際に、コンテンツやリンク情報を保ったまま別のサービスに乗り換えることができた
• 現代SNSの制約: 投稿した文章や画像やフォロー情報などは各運営企業によって管理され、データを保ったまま別のSNSへ移行することは困難になった
• オープンソーシャルの意義: 昔ながらのウェブ環境のデータ移行可能性を現代のSNS社会に復活させるものである

■ 4. AT Protocolの特徴

• ユーザーによるデータ管理: ユーザーのデータをユーザー自身が管理できることが大きな特徴である
• ドメインによる識別:
  • サービス内だけのハンドルネームではなく、各ユーザーの固有のドメインを用いてデータを管理できる
  • GIGAZINE公式アカウントの場合は「gigazine.net」というドメインを使用している
• 無料サブドメインの提供: Blueskyではアカウント作成時に無料のサブドメインが発行され、技術に詳しくない人でも従来のSNSと同じような使い心地で利用できる
• サービス間の移行可能性: 投稿内容やフォロー情報を自分の管理下に置いているため、Blueskyに不満が生じた場合は各種情報を保ったまま他のAT Protocol対応サービスに移行できる

■ 5. AT Protocolの応用範囲

• SNS以外の活用: AT ProtocolはSNS以外のサービスの構築にも利用可能である
• 既存サービスの例:
  • ブログサービスの「WhiteWind」
  • コード管理サービスの「tangled」
• データの一元管理: これらのサービスへの投稿内容やお気に入り情報などはユーザーの管理するデータリポジトリにどんどん追加されていく
• 公開情報としての設計: AT Protocolは基本的にすべての情報を公開情報として扱うように設計されている
• サービス間の連携: 各種AT Protocol対応サービスは他サービスで作成されたユーザー情報を参照でき、tangledの利用開始直後からBlueskyと同じプロフィールやアバター画像を表示することが可能である

■ 6. オープンソーシャルの将来展望

• 現状の課題: 記事作成時点ではXやFacebookといった企業によって管理されるSNSが多くのシェアを獲得している
• 当面の依存: オープンソーシャルはしばらくは苦労をいとわず活動する頑固な熱狂的ファンたちのコミュニティに依存することになる
• 相乗効果: オープンソースと同様にオープンソーシャルも相乗効果を生み、あるオープンソーシャルアプリが成功すれば他のオープンソーシャルアプリにも貢献する
• 将来的な勝利: いずれオープンソーシャルは勝利を収め、一定の地位を得ることになるとアブラモフ氏は予言している

MEMO:

• SNSが流行るのはそれで何かしらのメリットが発生するかどうかで、データがオープンかどうかはあまり関係無いような
• メリットというのは要するに承認欲求だったり、オフパコだったり、情弱から金を巻き上げたりなど
• 参入と維持が面倒なオープンXXXに↑のような連中が参入するとは考えにくいわけだが

(2025/09/30)

元バリバリのシニアマネが「もうマネジメントしたくない！メンバーがいい！」とSESに転職してきて作業員...

元バリバリのシニアマネが「もうマネジメントしたくない！メンバーがいい！」とSESに転職してきて作業員としてゆるふわニコニコ働き、客先から「〇〇さん技術あるしもっと主体的になってくれればリーダーとかできそうなのに…」と言われてるのを見て空を仰ぐ

@dropna_nan

MEMO:

• 作業員？

(2025/09/30)

ITシステムに「お辞儀ハンコ」実装…日本のDXが進まない根本原因

• ITシステムに「お辞儀ハンコ」実装…日本のDXが進まない根本原因（GOETHE） - Yahoo!ニュース

要約:

■ 1. 日本のIT化の現状

• IT利用頻度の低さ: 16歳から24歳の若者が職場や家庭でパソコンを利用する頻度はOECD加盟国中最低水準である
• パソコン保有率の低さ: 日本のパソコン保有率は米国の半分程度で、職場にも十分に普及していない状況である
• 学校教育でのIT不足: コンピュータを使える状況にあると回答した生徒の割合は47カ国中40位以下にとどまる
• 子どものパソコン保有率: 13歳から19歳の約7割がパソコンを保有しておらず、先進国中突出して低い
• スマホ普及の誤解: 諸外国もスマホに加えてパソコンやタブレットを保有しており、知的活動はパソコンで行うという使い分けができている

■ 2. IT化が進まない理由

• 技術力の問題ではない: 日本の技術力は高い部類に入るため、IT活用ができない理由は技術ではなく日本人のマインドにある
• FAX廃止の挫折: 菅政権が各府省のFAX利用取りやめを検討したが反対の声が上がり廃止できなかった
• ハンコ文化への固執: 日本人の特殊なマインドがIT活用を妨げる象徴となっている

■ 3. お辞儀ハンコ問題

• システム化の本末転倒: ハンコを廃止せず画面にハンコの印影を表示させるITシステムをわざわざ開発する企業が存在する
• お辞儀ハンコの実装: 役職によってハンコの傾きを変える機能を実現できるシステムをコストをかけて作る企業がある
• システム会社への要望: お辞儀ハンコができるようにして欲しいという要望が実際に寄せられている
• 本来の目的の喪失: 承認ボタンで事足りるにもかかわらず、わざわざコストをかけてハンコの印影を表示させエライ人にお辞儀をする機能まで付けている

■ 4. IT化の本来の目的

• 業務効率化の意義: システム化をきっかけに業務のムダを洗い出し省略することでビジネスを効率化することが目的である
• 生産性向上の機会: 業務の実態を丁寧に分析すれば承認者を減らせる可能性があり、システム化をきっかけに生産性が向上する
• 逆効果の実態: 従来と同じことをシステムで行うとシステム費用分だけ逆にコストが増える結果になる

■ 5. 日本社会の根本的問題

• 承認欲求と儀式: 稟議書にハンコを押す行為には役職者の承認欲求を満たす作用があり、その行為をIT化することに抵抗がある
• 上下関係の固執: 日本人のコミュニケーションは相手との上下関係が基本で、上に立つ人は常にマウントをとってその立場を維持しようとする
• 不寛容な組織文化: ITを導入する状況に至っても上下関係を基軸にした不寛容な組織文化を死守しようとしている
• 儀式化の特異性: 上司が部下に威張る光景は諸外国でも見られるが、こうした関係性を儀式化しITにも実装しようとする国は日本以外に存在しない
• マインドの問題: ムダがなくならず長時間残業を抑制できない原因は技術の問題ではなく完全にマインドの問題である

MEMO:

• お辞儀ハンコを実装してるシステムは具体的にはどこの企業のシステムで、全体でどれぐらいあるのかを出さないと意味が無いのでは
• これまでお辞儀ハンコシステムを見たことがないので、都市伝説の類だと思っているのだが
• PCの所有率に関してはIT業界の民なので、職場に普及していないと言われてもにわかには信じがたい
• 余程高齢者の個人事業主でも無い限り、PC無しで業務をやっている姿が想像しにくい
• 子供のPCの保有率についてもデータが古い気がする
• 数年前からPCやタブレットを学校から貸与されるようになっているので日常的に触るタイミングはあるだろう
• 総じて、20年以上前のステレオタイプで物事を語っている印象がある
• 「日本人は遅れてるんですよ！」という趣旨の記事の内容自体が時代遅れというのは叙述トリックかな？

(2025/09/30)

デジタル庁、アクセンチュアを4カ月間指名停止　業務を無断で再委託

• デジタル庁、アクセンチュアを4カ月間指名停止　業務を無断で再委託 - ITmedia NEWS

デジタル庁は9月26日、アクセンチュア（東京都港区）を、同日付で新規契約から外す「指名停止」の対象にしたと発表した。26年1月25日までの4カ月間、同庁が行う入札や契約に参加できなくなる。

アクセンチュアは、デジタル庁から2024年4月1日付で「情報提供等記録開示システム」の設計・開発や運用業務を受託。この他、2023年度以前も同様の契約案件を受託していた。いずれも複数の企業に再委託していたが、再委託に当たり同庁への申請が必要だったにもかかわらずこれを行わなかったという。同庁はこの行為を「不正又は不誠実な行為」に当たると判断した。

MEMO:

• あらあら

(2025/09/30)

リーダーの仕事は頑張ることでも､頑張らせることでもない…ニトリの管理職に受け継がれる

• リーダーの仕事は頑張ることでも､頑張らせることでもない…ニトリの管理職に受け継がれる"究極のマインド" トヨタ式｢もっといいものをラクに早く｣ | PRESIDENT Online（プレジデントオンライン）

要約:

■ 1. 個人業務の適正比率

• 3割ルールの重要性: リクルートワークス研究所の調査によると、個人業務の比率を3割程度に抑えるマネジャーが率いる組織はパフォーマンスが高い
• 5割を超えると成果が急降下: 自分で頑張りすぎることが結果的にチームの足を引っ張る可能性がある
• 時間配分の目安: 1日8時間働くなら自分の業務は2〜3時間で、残り5〜6時間は部下との対話、サポート、チームの未来をつくるプロジェクトに使う
• 任せることの本質: 手放すことではなく、育てること、信じること、未来を託すことである

■ 2. リーダーに必要な余白

• 余白が生む効果: リーダーに余白があれば部下は話しかけやすくなり、相談と対話が生まれる
• 組織成果の源泉: 個人の頑張りの総和ではなく、関係性の質や信頼の循環がつくり出す
• リーダーの役割: 話しかけやすい人、見守ってくれる人、チームの未来を語る人であることが組織の可能性を広げる

■ 3. 任せないことの副作用

• 見えない成長阻害: 部下が忙しいからと遠慮して任せないことが、実は部下の成長の芽を静かに摘んでいる
• 信頼関係の片想い: パーソル総合研究所の調査では、上司・部下の関係の52.4%で部下は上司を信頼しているが上司が部下を信頼していない状態である
• 信頼を感じる瞬間: 部下が信頼されていると強く感じる瞬間は仕事を任せられた時である
• 愛情の副作用: 大事に思うあまりに心配して任せないことが、かえって信頼関係を崩す

■ 4. 育成の本質

• 教育の幻想: 教えれば育つは思い込みである
• 修羅場体験の重要性: 本当に人が育つ条件は、うまくいかずに悩み、自分で考え、動き、試して突破した体験である
• ラーニングゾーン: 部下を飛躍させる機会をつくることが育成のカギである
• 資産運用の発想:
  • 部下は会社の大切な資産であり、管理職はその資産を託された運用者である
  • できるようになったから任せるのではなく、任せるからできるようになる

■ 5. リーダーの真の仕事

• 変えることが仕事: 頑張ることでも頑張らせることでもなく、変えることがリーダーの仕事である
• 問いを持ち続ける: もっとラクに、確実に、成果を出せないかという問いを常に持ち続ける
• ニトリのマインド: 前任者を超えよというマインドが受け継がれている
• なくす力の発揮:
  • プレイングマネジャーは現場にいるからこそ、ムダを肌感でわかる
  • 成果に影響のないタスク、意味のない報告資料、形骸化した会議にメスを入れる

■ 6. 失敗から学ぶ組織

• 失敗の価値: マドセンとデサイの研究によると、失敗体験のある組織のほうが次に成功する確率が高い
• 学習効果の差: 成功体験のパフォーマンス改善効果が-0.02に対し、失敗体験は-0.08と4倍も学びが深い
• サーチ行動: 失敗を経験した時、何がダメだったのか、何を変えるべきかと自ら問いを持ち探索をはじめる行為が学習の入口である
• 成功ばかりの危うさ: 失敗経験が少ないまま成功すると、その後はむしろ失敗しやすくなる
• リーダーの姿勢: 部下の失敗を責めるのではなく、失敗から何を学んだかを問い、サーチ行動を促すことが重要である

(2025/09/29)

(株)はてながこのままだと再来年くらいに上場廃止するかもしれない

• (株)はてながこのままだと再来年くらいに上場廃止するかもしれない

2016年2月24日に株式会社はてなは上場。

東証グロースの上場維持基準は上場から10年後に時価総額40億円だが、現在の時価総額は約30億円。

つまり、このままだと来年の3月には上場維持基準をクリア出来なかったことになるため、上場廃止の可能性が出てくる。

https://www.jpx.co.jp/equities/listing/continue/outline/03.html

通常は未達から1年間の改善期間を経てから上場廃止。

一応、グロース市場から時価総額基準が無いスタンダード市場に移るという手も無くは無いが、代わりにより厳しい流通株式の基準等もあり、全く容易ではない。

しかも、追い打ちをかけるように先日東証より「グロース市場の上場維持基準の見直し等の概要」が公表された。

https://www.jpx.co.jp/news/1020/um3qrc0000026eka-att/um3qrc0000026enb.pdf

2030年以降は、上場維持基準が「上場5年経過後に時価総額100億円」以上と見直される予定だ。

なお、以前に上場している企業(はてなも含む)は、一応は「なんとか頑張って100億円目指すぞ」プランを開示すれば多少の延命は出来るが、それでも猶予期間中に「⾒直し前の上場維持基準（上場10年経過後40億円）にも適合しない状態となった場合には、改善のための期間を設けず速やかに上場廃⽌を決定」となる。

現時点でも40億円ラインを超えられていない、はてなの運命やいかに...

MEMO:

• おやおや
• とはいえ、いきなり上場廃止みたいな事はできないと思うんだが、どうなんだろうか

(2025/09/29)

入社1年目からPMとして活躍する組織の育て方

• 入社1年目からPMとして活躍する組織の育て方 #初心者 - Qiita

要約:

■ 1. 若手PMの育成を阻む一般的な問題

• PMの仕事の属人化:
  • 課題の存在: 特定のベテランPMにしかできない仕事が多く、仕事内容が言語化されずに暗黙知として扱われるため、新人に仕事を任せられない。
• 組織が求めるPM像の不統一:
  • 方向性のブレ: シニアPMの経験に基づくPM像がバラバラで、組織として目指す共通のPM像（ゴール）を持てず、PM育成の方向性が定まらない。
• 失敗を許容しない文化:
  • 挑戦の阻害: 失敗を強く非難する文化では、PMの仕事に付きもののリスクを取ることを新人が恐れ、新しい挑戦ができなくなり、組織の成長が停滞する。

■ 2. 1年目からPMを育てるための3つのステップ

■■ 1. PMの思考の「型」を共有する

• 思考プロセスの言語化: ベテランPMが無意識で行う意思決定を支える思考プロセスを「型」として言語化し、組織全体で共有する。
• PMの思考の型（例）:
  • 目的の明確化: 「なぜ、この問題を解決するのか？」を常に問い、顧客課題や事業目標との繋がりを明確にする。
  • ユーザー視点: チーム内の憶測ではなく、ヒアリングに基づき「誰にとっての課題なのか？」を定義する習慣をつける。
  • 複数の選択肢の検討: 最初に思いついた解決策に飛びつかず、「解決策は本当にこれしかないのか？」とメリット・デメリットを比較検討する。
  • ゴールの言語化: 「良い感じ」ではなく、定量的な指標（KGI/KPI）で成功を定義し、チーム全員で同じゴールを目指す。

■■ 2. PMの仕事を、体系を理解したメンターがレクチャーする

• 段階的な責任範囲の拡大: PMの仕事を難易度で分解し、新人が小さな成功体験を積み重ねられるように徐々に任せる範囲を広げる。
• 体系的なメンタリング: 忙しい先輩による場当たり的なOJTではなく、PMの仕事の全体像や思考の型を理解し、「なぜそのタスクをやるのか」「失敗から何を学ぶべきか」を言語化して教えられる専任のメンターをつける。
• PMの仕事の分解例:
  • フェーズ1（部分的な担当）: 既存PMのタスクの一部（議事録作成、データ収集）や、既存プロダクトの小さな機能改善を任せ、仕事の流れを一人で経験させる。
  • フェーズ2（責任範囲の拡大）: 決済機能などプロダクトの特定領域や、ステークホルダーが少ない小規模プロジェクトのPMを任せ、企画から運用まで一貫して担当させる。

■■ 3. 成功と失敗から学ぶ「サイクル」を組織に組み込み、積極的に外部に発信する

• 組織としての学びの習慣化: 個人の経験をチームや組織全体の「学び」に変え、常に成長し続けられる仕組みを作る。
• 学びの共有会の開催: 成功・失敗を問わず、プロジェクトの「学び」をオープンに共有し、次のプロジェクトに活かすための議論の場を定期的に設ける。
• ナレッジベースの構築: プロジェクトの振り返りや意思決定の経緯など、「なぜその判断をしたのか？」という思考プロセスをドキュメント化して蓄積し、組織の知見を効率的に学べるようにする。
• 発信・共有の習慣化: 社内共有だけでなく、ブログ記事や登壇資料など外部への発信機会を設けることで、思考をより深く整理し、社外のフィードバックを得て学びを深める。

■ 3. まとめ

• PM組織成長の鍵: PMの仕事を「見える化」し、「メンター」をつけ、「学びのサイクル」を組織に根付かせることで、「経験者じゃないとPMは無理」という固定観念を打破し、若く才能ある人材を早期に育成できる強い組織を築くことができる。

(2025/09/29)

「明らかに正しいコードを書く」という意識が好きという話

• 「明らかに正しいコードを書く」という意識が好きという話 #初心者 - Qiita

要約:

■ 1. 「明らかに正しいコード」の定義と重要性

• 定義: 大雑把に言って見通しがよく、何をしているのか理解しやすいコードである。
• 目的: 競技プログラミングの格言だが、「もっとシンプルにできないか？」という視点を持つための意識として、普段の業務にも活かせると考える。
• 必要性: コードは少し油断すると簡単に複雑になり、理解しにくくバグも生みやすいものになってしまう。

■ 2. コードが複雑になる主な原因

• 最大の原因: 一つのやり方から抜け出せなくなることである。
• 条件分岐の増殖: ソフトウェアは条件分岐で構成されるが、既存の実装を変えたくないため、細かい調整を条件分岐で対応しようとする。
• 複雑化のプロセス: その結果、「この場合はさらに2パターンに分かれ、その一つでまた別の分岐が…」となり、何が正しいのか分からなくなる。
• バグ修正時の問題: バグ修正や追加対応など、小さな修正であっても、それにより分岐が次第に増え、結果としてコード全体が複雑になることが多い。
• 時間的な制約: 想定作業時間が短いチケットの場合、「本当は良くないコード」と分かっていながら、それで済ませるしかなくなり、コードが腐敗していくことがある。

■ 3. 複雑化を防ぐための意識と行動

• 意識: タイトルにもある「明らかに正しいコードを書く」という意識を持つ。
• 立ち返り: 「なんだか、やけに複雑なことをしているな・してしまっているな」と感じたら、今のやり方に固執せず、一度立ち帰り、全体を見直すべきである。
• 具体的な解決策:
  • 早期リターン: 「どの分岐でもこの場合は単にreturnしているから最初に確認してしまえばいい」といった、共通処理の切り出し。
  • 要件の再整理: 初期化処理などの共通部分を、より簡単な前段の分岐でまとめて処理するなど、シンプルで分かりやすい方法を検討する。
• 人間にできること: 人間はあまりに複雑なものを管理できないため、シンプルで分かりやすい方法を追求する必要がある。

■ 4. 複雑なコードを避けることの恩恵

• 現実との乖離: 現実には、時間的な制約や、元の処理にかけた時間が長いことによる固執（人間的な感覚）などから、毎回シンプル化が成功するわけではない。
• 複雑化の弊害: 扱いづらいコード・理解しにくいコードは、日々の業務を苦痛にし、「簡単な修正なはずなのに時間がかかる」「修正が別のバグを引き起こす」といった問題を生む。
• シンプルな追求: 「こんなに複雑にしなくても、もっとシンプルにいけるはずだ」という感覚に従うことが重要である。
• 長期的な恩恵: その場では修正・テストに時間がかかったとしても、その後の開発で大きな恩恵を受けられる。

(2025/09/28)

世界初！日本企業がGPUを不要とする生成AI (LLM) の開発に成功。／2025年10月10日の都内イベントで先行発表

• 世界初！日本企業がGPUを不要とする生成AI (LLM) の開発に成功。／2025年10月10日の都内イベントで先行発表 | 株式会社I.Y.P Consultingのプレスリリース

要約:

■ 1. 開発の概要と国際的評価

• 開発元: 株式会社I.Y.P Consulting（設立：2023年10月、本社：東京都中央区）が、生成AI「SVG」の開発に成功した。
• 技術的特徴: GPUなどの特殊な機材を必要とせず、わずか32個のパラメータという極小規模でありながら、従来のLLM（大規模言語モデル）と同等の性能を発揮する。
• 国際的評価: 2025年9月18日、人工知能／機械学習分野で最も権威のある国際会議のひとつNeurIPS（米ニューラル情報処理学会）の本会議で正式に採択（アクセプト）された。
• 日本発の意義: 巨大化一辺倒の国際潮流に対し、「小さく、速く、分かりやすい」新しいアプローチを示した日本企業主体の稀有な成果であり、国際的に大きな注目を集めている。

■ 2. SVGの性能と従来のLLM・SLMの課題

• LLMの課題: 数千億〜数兆のパラメータを持ち、学習・推論に膨大な計算資源（GPU）と電力コストを要するため、環境負荷や事業継続性（特に日本の電力逼迫）の課題があった。
• SLMの課題: SLM（小規模言語モデル）は軽量化を目的とするが、LLMをスケールダウンしたモデルが多く、性能や応答の自然さでLLMとの差が大きくビジネス利用には不十分だった。
• SVGの画期的な性能:
  • 極小パラメータ: パラメータ数はわずか32個（GPTのわずか1億分の1のメモリ容量）。
  • 高速性: 応答速度は1ミリ秒と高速。
  • 高精度: ハルシネーション（幻覚）の国際標準GLUEベンチマークにおいて、GPTを上回る精度を達成した。
  • 実行環境: GPUを一切必要とせず、汎用CPU環境でリアルタイムに稼働する。

■ 3. ビジネス優位性と持続可能性

• コストとインフラの優位性:
  • コスト削減: 高額なGPUインフラ投資や大規模クラウド利用コストを大幅に削減し、GPU環境を持たない中小企業や公共機関でも導入可能になる。
  • ユースケース拡大: PC、スマホ、家電、IoT端末など幅広いデバイス上での利用が可能になる。
• 運用面と説明責任:
  • プライバシー担保: インターネット接続不要で処理が可能なため、プロンプトの高速処理とプライバシーの確保を実現する。
  • スピードと効率: 学習はタスクあたりわずか数分で完了し、PoCや新規サービス立ち上げを加速する。
  • 説明責任の確保: 分類根拠を明示できるため、金融・医療・行政など説明責任が重視される領域でも安心して活用できる。
• 持続可能性: エネルギー消費を抑え、環境負荷を低減するグリーンAIとしての意義を持ち、「大規模モデルを使いたいがリソースが限られている」組織にとって、現実的かつ持続可能なAI活用の突破口となる。

MEMO:

• 本当ならすごい事だが
• こういうのは往々にして尻すぼみになる事が多いので、まずは期待せず様子見することが肝要である

(2025/09/28)

勤怠管理システムをDDDで作り直して9年。その選択は正しかった？

• 勤怠管理システムをDDDで作り直して9年。その選択は正しかった？ - RAKUS Developers Blog | ラクス エンジニアブログ

要約:

■ 1. 旧システムで直面した課題とDDD導入の背景

• 勤怠管理システムの複雑性: 勤怠システムは、法律や就業規則、企業ごとの勤務体系の違いなどにより、複雑なルールと例外が膨大に存在する。
• 旧システムの課題:
  • 処理の不明確さ: 自作フレームワークをベースにしていたため、処理の所在が不明確であった。
  • 深刻な属人化: 「この処理の正解は〇〇さんしか知らない」という状況が頻発し、知識が特定のベテランメンバーに偏っていた。
  • 高い教育コスト: 新メンバーにとってコードと業務知識の紐付けが難しく、システム理解に大きなハードルがあった。
• DDD導入の目的: 「何をどこで処理しているのかが不明確」という最大の課題を解決するため、新システムのリニューアル時にDDD（ドメイン駆動設計）を採用した。

■ 2. DDD導入によるシステムの改善と属人化の解消

• ドメインの整理とモデル化: 「現実の勤怠の仕組みを、チーム全員が同じ言葉で説明できるようにする」というアプローチで、勤怠ドメインの整理とモデルへの落とし込みを行った。
• 代表的なモデルの例:
  • 労働パターン: 勤務区分やカレンダーなど、勤怠計算に必要な設定を定義する。
  • 打刻: 出退勤・休憩といった「事実」だけを表し、「遅刻」などの解釈は加えない。
  • 勤務実績: 打刻や計算で計上された、その日の「働いた結果」を表現し、ユーザーへの表示に用いる。
  • 休暇履歴: 有休の付与・取得・消滅をすべて履歴として積み上げることで、残日数を自動的に導けるようにし、値の正当性に関する懸念を解消する。
• 共通理解の促進:
  • ユビキタス言語の活用: 「労働パターン」「打刻」「勤務実績」「休暇履歴」といったモデル名を指して会話できるようになり、以前の曖昧な表現を解消した。
  • 属人化の解消: 知識がモデルに閉じ込められ、チーム全体で共有できるようになり、仕様確認やレビューがスムーズになった。

■ 3. 9年間の運用で実感したDDDの価値

• チーム知識の維持: DDDは「複雑な業務知識をチーム全体で維持し続ける仕組み」として機能した。
• 価値の具体例:
  • 新メンバーの立ち上がり加速: 旧システムのように勤怠ドメインの理解に数カ月かかることはなくなり、「休暇履歴」などの用語ベースで理解できるようになった。
  • 制度変更への柔軟な対応: 制度やルールの変更が発生した場合、該当モデルにルールを追加・修正するだけで対応できるようになった。
• 最終的な評価: 9年間の運用を経て、DDDは単なる設計手法ではなく、「複雑な勤怠ドメインをチームみんなで理解し続けるための心強い道具」であり、「あのときDDDを選んでよかった」と心から言える。

(2025/09/28)

「技術負債にならない・間違えない」 権限管理の設計と実装

• 「技術負債にならない・間違えない」 権限管理の設計と実装 - Speaker Deck

要約:

■ 1. 権限管理の重要性とアンチパターン

• 権限管理ミスの影響: 給与や取引先情報などの機密情報公開につながり、サービスへの信頼が低下し、事業への大きな損失を招くため、ミスは許されない。
• よくあるアンチパターン:
  • user.admin? や user.super_admin? のように役割に依存した判定を行うこと。
  • 役割は事業やサービスの変化（市場、企業規模、機能）に伴い変わりゆくため、役割に依存した実装は変化に弱く、権限が暗黙的になり、技術負債の原因となる。
• 推奨されるアプローチ: 役割（admin?）に依存せず、権限に依存した判定（例: user.can_create_project?）にすることで、権限が明示的になり、コードリーディングや変更時の整合性確認が容易になる。

■ 2. 権限管理の要素整理とPunditの問題点

• 権限管理の要素分解: 権限管理を整理する上で、以下の4つの要素に分割できる。
  • 対象: Model（例: Project）
  • 操作: CRUDやその他のアクション（例: update）
  • 役割（RBAC）: Role-Based Access Control（例: 管理者アカウント、外部アカウント）
  • 条件（ABAC）: Attribute-Based Access Control（例: 作成者、担当者）
• Punditの問題: Punditを利用した場合、一つのポリシーメソッド内で役割と条件の判定が混在し、複雑な判定ロジックになると、「通常ユーザーは更新できるか？」といった問いに対し、すぐに回答できない（理解で間違えやすい）という問題が生じる。
  • 例: 管理者かマネージャーかつ担当者か作成者ならできる... のような論理演算の連なりは、一目で理解しにくい。

■ 3. 要素を適切に分割したModuleの実装と実現方法

• Moduleの設計思想: 役割と条件を分離し、権限を対象・操作・役割・条件の4要素で明示的に定義する。
• 実装の概要:
  • ディレクトリ/ファイル構造: 対象ごとにディレクトリを作成し、その中に役割ごとにファイル（権限の具体クラス）を作成する。
  • 権限の判定: 権限の具体クラス内で、対象の基底クラスで定義した条件（例: assignee? や author?）を英語と論理演算（|| や &&）でシンプルに組み合わせて表現する。
  • メタプログラミングの活用: 対象と役割から権限のクラスを特定する際に使用し、権限の追加・変更を容易にする。
• 利用時のモード:
  • recordモード: 特定のレコードに対して権限があるかを判定する（例: Context.new.can_update?(@project)）。
  • scopeモード: 権限があるレコードのみに絞り込む（例: Context.new.scope_for_read(Project)）。
  • listモード: クライアント（Next.jsなど）に渡すための権限の一覧を取得する。

■ 4. 良い設計がもたらす影響

• 間違えない実装の実現: 役割と条件を分離し、権限を明示的に記述することで、実装・利用・理解のすべてのフェーズで間違いを減らす（不具合の発生件数がゼロ、社内からの問い合わせがゼロ）。
• 開発生産性の向上: CSやPdMがGitHub上のコードを直接見て理解できるようになり、エンジニアへの問い合わせ対応時間が削減された。
• クライアント（Next.js）への影響:
  • Railsから渡された権限の一覧（JSON）にNext.jsが依存することで、Next.js側でも役割に依存しない実装が自然に実現した。
  • 権限によるUIの制御を（例: 編集ボタンの表示/非表示）宣言的に記述できるようになり、フロントエンドの技術負債も防いでいる。

(2025/09/28)

「完璧を目指さない」サーバーレス進化論 〜CDKで育てる変化に強いアーキテクチャ〜

• 「完璧を目指さない」サーバーレス進化論 〜CDKで育てる変化に強いアーキテクチャ〜 - Speaker Deck

要約:

■ 1. 「完璧を目指さない」アーキテクチャの必要性

• Lambda利用の現実的な課題: 初期は快適だが、データ量増加による15分制限の壁や、構成変更時のYAMLの複雑化（記述量爆発）、型安全性なしによる実行時エラー多発といった問題が生じる。
• 構成変更の困難さ: 実行時間超過への対応策として「Lambda分割」や「Fargate移行」があるが、いずれも複雑化や大幅な構成変更が必要となり困難である。
• 進化の鍵: 完璧な初期設計は存在せず、要件変化に柔軟に対応できる仕組み、すなわち構成変更の容易さと将来の拡張性がアーキテクチャの進化には重要である。
• 進化的アーキテクチャの定義: ビジネス要件や技術の進歩といった絶え間ない変化に適応できるように設計された柔軟性の高いソフトウェアアーキテクチャであり、漸進的な変更、適応度関数（客観指標）、多重な次元（性能、セキュリティなど）の統合管理が特徴である。

■ 2. CDKによる実践的進化パターン

• パターン1：Lambda → Fargate 移行:
  • 課題: 15分実行時間制限、スケーラビリティの限界がある。
  • 解決アプローチ: コンテナ化による時間制限の解除とECS Fargateによる自動スケーリングで解決する。
  • CDKの優位性: SAMでの移行時の記述量増加が6.3倍なのに対し、CDKでは2.1倍に抑制され、移行時の複雑度を約1/3に抑える。
• パターン2：EventBridge+Lambda → Step Functions 移行:
  • 課題: トレーサビリティ不足、分散イベント処理の複雑化、障害時の影響範囲特定困難がある。
  • 解決アプローチ: Step Functionsによる一気通貫ワークフローへの統合と実行状況の可視化、エラーハンドリングの集約により、障害調査時間を大幅に短縮する。
  • CDKの優位性: 既存のgrant()メソッドがそのまま使え、型安全性によりコンパイル時にエラーを検出でき、複数のLambda関数の連携を一つのファイルで管理しやすい。
• パターン3：DynamoDB → Aurora 移行:
  • 課題: 複雑なクエリ要件の増大、NoSQLの限界がある。
  • 解決アプローチ: Auroraへの切り替えとSQLによる柔軟なクエリ実行で対応し、CloudWatch Syntheticsによる性能監視（適応度関数）を強化する。
  • CDKの優位性: synthetics.Canary()で継続的な監視をコード化するなど適応度関数の実装が容易である。また、cdk diffにより変更点を確認しながら漸進的な変更を実現し、セキュリティ要件も1行の変更でIAMベースからVPCベースへ移行できる。

■ 3. 進化的アーキテクチャの実現とCDKの価値

• SAM vs CDKの比較:
  • 構成変更時の記述量: SAMは爆発的に増加するが、CDKは管理可能である。
  • 変更影響の可視化: SAMは困難だが、CDKはcdk diffで確認可能である。
  • 権限・接続管理: SAMは複雑なYAMLが必要だが、CDKはgrant/connectionsで直感的である。
  • 結果: 長期的な開発・保守性においてCDKが優位であり、進化的アーキテクチャの実現を可能にする。
• CDKの総合的な価値:
  • 構成変更時の記述量を大幅に削減し（SAMの1/3の複雑度）、変更影響の事前確認が可能である。
  • 直感的な権限・接続管理を実現し、段階的移行を支援する。
• 結論: アーキテクチャは「完璧な初期設計」を目指すのではなく、「育てるもの」である。サーバーレス環境において、CDKを活用することで、要件変化に柔軟に対応できる段階的な改善アプローチでアーキテクチャを進化させる。

(2025/09/27)

今改めてServiceクラスについて考える 〜あるRails開発者の10年〜

• 今改めてServiceクラスについて考える 〜あるRails開発者の10年〜 - Speaker Deck

要約:

■ 1. 過去の経緯と問題意識

• パーフェクトRailsでの記述: 2014年発売の『パーフェクトRuby on Rails』において、筆者はServiceクラスをコントローラーとモデルの中間に位置し、モデルの処理をまとめるインターフェースとして定義した。
• 後の見解の変化: 2016年末に「サービス クラスとか作るのは止めてくれ」という記事を公開し、わずか2年半で記述内容と異なる意見を表明した。
• 再議論のきっかけ: 2024年の懇親会での議論を機に、Serviceクラスの是非について改めて考察するに至った。
• Fat Modelの問題: Railsがビジネスの現場で多用されるにつれ、ActiveRecordの特性からくるFat Model（巨大化したモデル）の問題が顕在化し、その解決策としてServiceクラスが言及されるようになった。

■ 2. Serviceクラスの定義と乱用の難しさ

• DDDにおけるService: エンティティや値オブジェクトに責務を持たせると不自然になる場合に、振る舞いに着目して命名し責務を定義するものであり、命名はユビキタス言語に由来する必要がある。
• パーフェクトRailsでの役割: 処理そのものをカプセル化し、業務知識と実装のメンタルモデルを一致させる役割があると記述した。
• 乱用の危険性: 「乱用は危ないから考えてから使う」という基準の度合いが人によってバラバラであり、単純に複雑な処理に名前を付けて良いわけではないという理解が共有されていなかった。
• チーム開発での課題: チーム開発では共通認識が重要であり、Serviceクラスの基準が不明確だと一貫性が失われ、コードの全体像の把握や保守が困難になる。

■ 3. 現実的な解決策としてのFormクラス

• Railsの基本的な層: Controller、Model、Viewの基本的なレイヤーを守ることで、共通認識の維持と想像のしやすさというフレームワークの利点が得られる。
• Formクラスの役割: Serviceクラスと同じく複雑な処理の置き場所だが、Webアプリケーションにおけるパラメーターハンドリングとトランザクションコントロールを扱うという、より限定的な文脈に対処する。
• Serviceクラスとの違い: Formクラスは画面やユースケース（アクション）と紐づき、ActiveModel/ActiveRecordのインターフェースと親和性が高いという、名前から具体的なイメージが想像できる利点がある。
• 共通の難しさ: ServiceやFormを利用しても、結局ActiveRecordのメソッドレベルの境界をどこに設定するかという、モデルの整理から逃れられない。

■ 4. 根本的な重要事項とServiceクラスの今後

• 最も重要なこと: ServiceやFormといった表現技法は重要ではなく、RDBと向き合い、ActiveRecordを使いこなし、ドメインコンテキストの理解を深めることが重要である。
• ドメインコンテキストの理解: 複雑なシステム設計では、コンテキストマップ（境界づけられたコンテキスト）を作成し、システム内のコンポーネントと相互作用を設計する。
• モジュラーモノリスの導入: コンテキストの境界を明確にし、依存関係を一方向に保つための現実的な選択肢として、モジュラーモノリスが挙げられる。
• Serviceクラスの復活: モジュラーモノリスによってコンポーネントの境界が明確になった時、Webインターフェースに限定されないコンポーネントレベルの公開エントリポイントとしてServiceクラス（またはそれに類するもの）の利用は意味を持つ。
• 継続的な開発の難しさ: Serviceクラスを使う場合は、チームメンバー全員で利用ケースと言語化された必要性を共有することが不可欠である。ソフトウェア設計は、ビジネスの発展を継続的にサポートするために何度も判断を下し、改善し続ける営みである。

(2025/09/27)

モデリングとアーキテクチャの知見を積み上げて基幹システムに可変性を注入する

• モデリングとアーキテクチャの知見を積み上げて基幹システムに可変性を注入する - MonotaRO Tech Blog

要約:

■ 問題領域の特定: 在庫管理の「神テーブル」

• 深刻な現状: モノタロウの基幹システム（受注・配送・発注ドメイン）には、商品の在庫状況に関する属性がたった一つの巨大なテーブルに保存されている。
• 複雑性の原因:
  • レコード数は5000万件以上に及び、関連する更新ユースケースは80以上、参照ユースケースは730以上存在する。
  • 各ドメインがこのデータ構造に密に依存しており、データ構造の変更は入出荷停止リスクなど、ビジネス基本業務に深刻な影響を与える。
  • この「神テーブル」は在庫の状態のみを持ち、状態に至った経緯（理由）を把握できない。
  • 必要な数値の導出に他のテーブルとの結合が生じ、「在庫状況の管理」という文脈で担保すべき不変条件の範囲が曖昧になっている。
• 課題への取り組み: 業務とシステムの可変性を取り戻すため、この不要な複雑性の本丸である「在庫状況問題」の分割に取り組むことを決定した。

■ 課題の分割とドメインモデルの仮説構築

• 分割の常套手段: 「神クラス」分割の常套手段にならい、以下の手順で問題解決にアプローチした。
  • (1) 在庫状況に関連する更新ユースケースを網羅的に洗い出す。
  • (2) どのドメインがどの属性を更新しているか分類する。
  • (3) 属性のオーナー候補ドメインを仮定する。
• 在庫ドメインの仮説検証:
  • 存在が不確かな「在庫ドメインとその属性」を仮定し、既存の更新ユースケースが破綻なく処理できるか慎重に確認した。
  • 大規模ワークショップでモブプログラミングを実施し、在庫ドメインの属性と責務のイメージをつかんだ。
  • 更新ユースケースをシーケンス図に起こし、ドメインシステム間のメッセージングを確認した。
• 成果: 上記の密な調整を経て、ついに「在庫ドメインはあります！」という仮説（存在）に至り、積年の課題に切り込むことができた。

■ ドメイン駆動設計（DDD）によるアプローチ

• DDDの採用理由:
  • 問題領域が基幹業務であること。
  • 在庫管理の柔軟性がモノタロウの競争優位性の源泉となり得ること。
  • 最大の目的が業務とシステムの可変性を取り戻すことであるため。
• 体制強化: DDDエキスパートやリソース不足という足踏み要因を解消するため、専任チームを結成し、AWSプロフェッショナルサービスの支援を受けた。
• モデリングの手順:
• ビッグピクチャーの作成: フルフィルメント全体の業務イベントを可視化する大規模なイベントストーミングを実施。
• プロセスモデルの作成: 在庫状況の業務領域に絞り込み、イベントがどのように発生したかを分析。
• ドメインモデルの導出と洗練:
  • プロセスモデル上の集約を取り上げ、コマンドを振る舞い、必要となる値を属性として推定した。
  • 属性をエンティティと値オブジェクトに分けて集約を構成した。
  • その後、業務・モデル・コードを往復する試行錯誤（禅問答）を重ね、概念構成図などを活用しながらモデルを洗練させた。

■ レイヤードアーキテクチャによる実装と品質向上

• アーキテクチャの採用: 導出されたドメインモデルを実装するためにレイヤードアーキテクチャを採用し、以下の4層で構成した。
  • ビュー層: イベント受付（イベントハンドラ）
  • アプリケーション層: ビジネスロジック実行、ユースケース管理（集約のロードと振る舞い呼び出し）
  • ドメイン層: ビジネスルール、ドメインモデル定義（在庫集約、リポジトリインタフェース）
  • インフラストラクチャ層: データベースアクセス、外部システム連携（リポジトリ実装）
• 依存関係の逆転: ドメイン層がインフラストラクチャ層に依存するのを避けるため、リポジトリのインタフェースをドメイン層で定義し、実装をインフラストラクチャ層で行うことで回避した。
• メリット（保守性の向上）:
  • 各層の責任と関心事が独立し、システム全体の理解が容易になる。
  • 層間の依存が限定されることで、コードの変更の影響範囲が限定され、変更容易性が向上する（例: 同期→非同期への変更がビュー層の書き換えのみで済む）。
• ソフトウェアの「質」の向上: 「良いソフトウェア」であるために、設計原則の共有と定期的なリファクタリングを実施。
• リファクタリングの例（アプリケーション層）:
  • 複数のユースケースで共通していた「集約をロード→イベント適用→集約を保存」の処理の流れを特定。
  • SingleEntityCommandServiceという単一のサービスに共通処理を集約し、ユースケースごとにCommandインタフェースを渡す形にリファクタリングした。
  • これにより、コードの重複が減り、再利用性、メンテナンス性、拡張性が向上した。

■ 今後の展望

• 活動の継続: 在庫ドメインの成果を基幹システム分割・モダナイズ活動の一環として、今後も多くの業務領域に取り組む。
• 全体最適: 個別の業務領域と並行して、基幹システム全体の構造とマスタデータ管理の最適化を進める必要がある。
• 知見の共有と仲間探し: 得られた知見のドキュメント化やワークショップ開催を通じて、活動を推し進めるためのより多くの仲間を求めている。

(2025/09/27)

Railsによる人工的「設計」入門

• Railsによる人工的「設計」入門 - Speaker Deck

要約:

■ 1. 設計を体得できていない状態とは

• 問題の本質: 設計が何か分からなければ設計はできない
• 教える側と教わる側のすれ違い:
  • 教える側は「図や表を通じてシステムを考えられる」と考えるが、教わる側は「システム=コード」と捉えている
  • 教える側は設計によって重要な課題が洗い出せると考えるが、教わる側はコードが分からないと課題も分からないと感じる
• 設計していないことに気付かない問題: 初学者は「DB→モデル→コントローラ→ビュー」という手順を説明するだけで設計したと思い込む
• 手順による実装の実態: 実装前に全体を考えず、マイグレーションから作業を進めて最後に何を作れたか理解する状態

■ 2. 設計の定義

• 設計とは: コードのレベルで考えることなく、全体としてどういう構造や技術的要素を使ってどんなものを作るのが良さそうかを考え、作業の段取りを考えても良い状態にすること
• ベテランと初学者の違い:
  • ベテランは抽象度の高いレベルでシステムをまず考える
  • 初学者はコードのレベルだけでシステムを考えがち
• 設計は手順の前に来る: 手順を考える前にシステムの構造を考える必要がある

■ 3. 逆算による設計メソッド

• 順算との対比: 従来の「手順による開発」をまだ見えないゴールに向かってコードを順番に作る「順算」に例える
• 逆算の流れ:
  • まず完成したシステムを思い浮かべる
  • 中核的な「実現したいこと」にフォーカスする
  • 「それには何が必要か」を順々に考えていく
• 目的: 設計がよく分からない人を設計世界へ導入する手法である

■ 4. 実践例:ユーザーCSVインポート機能

• 完成形の想像:
  • 大量登録時の時間やメモリの問題を想定
  • 一部エラー時の処理方針を検討
  • エラー情報の表示方法を検討
  • インポート履歴の必要性を検討
• 課題の洗い出しと仮置き:
  • 非同期処理にすることを仮置き
  • 全部失敗方式を仮置き
  • Importモデルでエラー情報と履歴を管理
• ゴールの設定: 実際にCSVからユーザーが登録・更新されることを本質的なゴールとする

■ 5. ステップと名前付け

• ステップの定義: 見つけた「実現したいこと」「必要なこと」に短い名前をつけて形を書き出す
• 名前付けの重要性:
  • 設計は大きな粒度で考える活動である
  • 長い概念を短い名前に置き換えることで脳内スペースを節約できる
  • 設計は名前をつける行為の積み重ねである
• 具体例: 「インポートすること」自体をモデルにしてImportと命名する

■ 6. 開発領域の整理と手順計画

• 領域分け: 処理の順番や処理が書かれる場所の違いに注目して大まかにグルーピングする
• 手順の考え方:
  • データが準備しやすい流れを考える
  • 本質的なこと、難しいことをなるべく先にやる
• 設計後の手順の質の変化: DB→モデル→コントローラ→ビューではなく、Import登録→インポートロジック→一覧・詳細といった機能単位の手順になる

■ 7. デザインパーツの活用

• デザインパーツとは: 再利用性のある小さな設計パーツで、アーキテクチャや考え方を指す
• 主要なカテゴリ:
  • データ構造(ActiveRecord、関連、制約など)
  • 処理構造(MVC、コールバック、非同期処理など)
  • 個別機能・Gem(認証、認可、検索機能など)
• 効果: 色々なデザインパーツを理解していれば速く妥当な設計ができる

■ 8. 今日伝えたいこと

• 全体が機能するように設計する: アプリケーションだけでなくシステム全体が機能するように設計することが重要である
• システムコンポーネントとパターンの組み合わせ: パターンを組み合わせてシステムを構成することで全体の構造が現れる
• 初学者向けの手法: 完成形をイメージして中核的な価値の実現から逆算で1つ1つ要素の形を決めていく

(2025/09/27)

Redis is fast - I'll cache in Postgres

• Redis is fast - I'll cache in Postgres | Dizzy zone

要約:

■ 検証概要と設定

• 比較対象: RedisとPostgreSQLをキャッシング用途に使用した場合のパフォーマンスを比較検証。
• 環境設定: Kubernetes上で、PostgresまたはRedisを2CPU/8GiBメモリに制限し、デフォルト設定で実行。
• データセット: 事前に3000万件のデータを投入し、GET（取得）、SET（設定）、混合（Read/Write）の3種のワークロードで性能を測定。

■ パフォーマンス検証結果

• 総合性能: すべてのワークロード（GET/SET/混合）において、RedisがPostgreSQLよりも高速な結果となった。
• Redis側のボトルネック: Redisの処理能力ではなく、HTTPサーバー側のCPUが上限に達したことがボトルネックとなっていた。
• PostgreSQL側のボトルネック: 制限された2コアのCPUを使い切り、PostgreSQL側がボトルネックとなっていた。
• 非ログ記録テーブルの効果: PostgreSQLで非ログ記録テーブルを使用することで、特に書き込み（SET）性能は大幅に改善されたが、Redisの速度には及ばなかった。

■ 筆者の結論と考察

• 速度の優位性: RedisがPostgreSQLより高速であるという事実は認めている。
• 依存関係の削減: ほとんどのプロジェクトではPostgreSQLの性能で十分であり、Redisという新しい依存関係を追加しないことの利点を重視するため、Postgresを使い続ける。
• 性能の評価: Postgresの性能（7425リクエスト/秒、1日5億件以上のリクエストに相当）は、大半のプロジェクトの要件を満たす十分なものである。
• 柔軟な設計: キャッシュにインターフェースを設けておくことで、将来的に性能不足が生じた際にRedisへの切り替えを容易に行えるようにする。

MEMO:

• PostgreSQLをキャッシュストレージとして使った時の性能比較
• 当然Redisの方が早いが、PostgreSQLでも大半の場合で実用的な速度が出るし、システムの依存関係が減少するので、ブログの筆者はこちらを選択する、と
• とはいえ、DBがCPU使い切ったらサービス全体が停止するし、DBサーバをスケールアップするより、Redisをスケールアウトする方がコストが安いと思うのだが
• とはいえ（2回目）、そこまでアクセス数が発生しない or シビアに考える必要のないサービスならPostgreSQLをキャッシュサーバにしてもええやろというのは確かにそう

(2025/09/27)

AIと『対話しない』対話法、モノローグ法

• AIと『対話しない』対話法、モノローグ法 #ChatGPT - Qiita

要約:

■ 先進的プロンプトテクニックの概要と課題

• Backstep Prompting: 結論に至る思考プロセスをモデルに後退（バックステップ）させ、自己評価・修正させる手法である。
  • 目的と効果: 推論の正確性向上、ハルシネーション（幻覚）の抑制、思考プロセスの透明化に寄与する。
• Scaffolding（スキャフォールディング）: 複雑なタスクを小さなサブタスクに分解するための手順（足場）をプロンプトに含めるアプローチである。
  • 目的と効果: 複雑な問題解決能力の向上、回答の網羅性と一貫性の確保、出力形式の制御に有効である。
• 先進手法の課題: Backstep PromptingやScaffoldingは強力だが、毎回複雑なプロンプトを考える手間がかかり、「プロンプト職人」の腕に依存するという「人力での煩雑な作業」という課題がある。

■ 新しい対話法「モノローグ法」の提案

• 主語の転換: 従来のAIとのやり取りは命令形（Imperative）でAI（You）が主語であった。モノローグ法では、プロンプトの主語をあなた自身（I）に変え、一人称の表明形（Declarative）で思考をつぶやく。
• AIの役割変化: AIは「命令を待つ部下」から、ユーザーの思考に耳を傾ける「思考のパートナー」へと役割が変わる。AIの応答は思考の触媒として機能するが、無視できる自由があり、ユーザーの思考の流れを邪魔しない。
• メリット: ユーザーは「AIへの指示を考える」という制約から解放され、純粋に自分自身の思考を深める知的作業に集中できる。これにより、自然な形でBackstep PromptingやScaffoldingと同様の効果を得る。

■ モノローグ法のメカニズムと学術的裏付け

• 思考の触媒: AIの控えめな応答は、ユーザーの思考を客観的に捉え構造化するきっかけを与え、ユーザー主導でのScaffolding（思考の足場作り）を共同で行うプロセスとなる。
• 無視できる自由: 心理的なプレッシャーなしにAIの提案を無視・自己修正できる環境は、思考の寄り道や自己修正を促し、Backstep Promptingと同様の内省を自然に実現する。
• 学術的関連性: モノローグ法は、思考プロセスを外部化することで推論能力を高めるChain-of-Thought (CoT)、対話を通じて思考を洗練させるIterative Refinement、そして人間による自己批判・修正をAIと協調して行うSelf-Correctionの研究潮流と関連性が高い。

(2025/09/27)

プロジェクトマネジメントの基本をまとめてみた

• プロジェクトマネジメントの基本をまとめてみた #タスク管理 - Qiita

(2025/09/27)

「Android for PC」は2026年に――グーグルのキーパーソンが語る

• 「Android for PC」は2026年に――グーグルのキーパーソンが語る - ケータイ Watch

基調講演でサマット氏は、AndroidとグーグルのAIサービスである「Gemini」がスマートフォンだけではなく、テレビやスマートウォッチなど、ほかのデバイスからも利用できるようになってきたことを紹介。その上で、ユーザーが質問して答えを得る「オンデマンドモデル」から、AIがユーザーが抱える次の問題を「予測し」、アシスタンスを提供する「よりプロアクティブなモデル」へと移行すると指摘する。

その上で、基調講演のホストを務めていたクアルコムのモバイル・コンピュート＆XRグループジェネラルマネージャーであるアレックス・カトージアン氏（Alex Katouzian）がサマット氏へ「より大型のディスプレイデバイス」での生産性の変化について問う。

するとサマット氏はAndroidエコシステムのすべてのデバイスに対して「シームレスに一緒に機能すること」をユーザーの多くが望んでいると解説。ノートパソコンという形態に対して、グーグルではChromeOSを提供し成功した、とした上で、AIの進歩から「可能な限り迅速に、ラップトップのフォームファクターにもたらすか」（サマット氏）という課題を指摘する。

そこで現在、グーグルが実行していることはChromeOSの体験をもとに、Androidに融合することとして、その融合について「来年に向けて非常に興奮している」と説明。2026年の投入を示した。

(2025/09/26)

見逃していませんか？Google Go Style Guideの継続的アップデート

• 見逃していませんか？Google Go Style Guideの継続的アップデート - ANDPAD Tech Blog

(2025/09/26)

大してアクセスないサイトにECSはオーバースペック

• 大してアクセスないサイトにECSはオーバースペック

MEMO:

• そのレベルで良いなら、スタティックサイトジェネレータ + S3で良さそうではあるが

(2025/09/25)

Webサービスにおける非同期処理の勘所

• Webサービスにおける非同期処理の勘所 - pospomeのプログラミング日記

要約:

■ 1. 非同期処理の定義と採用基準

• 非同期処理の定義: Webサービスにおける非同期処理は、AWS SQSやGoogle Cloud Pub/Subなどのメッセージキューを利用し、バックエンドサーバーがキューにメッセージを入れ、ワーカーがそれを非同期に処理する仕組みを指す。
  • 構造: クライアント → バックエンドサーバー → AWS SQS/Pub/Sub → ワーカー
• 採用基準: 非同期処理は基本的に面倒であるため、同期処理では要件を満たせない時にのみ採用すべきである。
• 同期処理で要件を満たせないケース:
  • 大規模な時間のかかる処理: 巨大なCSVファイルのダウンロードやアップロード・DB登録処理など、利用者を長時間待たせたり、DBに高負荷をかけたりする場合。
  • 高RPS（Request Per Second）環境での外部API呼び出し: レイテンシの高い外部APIを複数回叩くエンドポイントに大量のリクエストが集中し、バックエンドサーバーのリソース（コネクションプールなど）が枯渇したり、スケール効率が悪化したりする場合。

■ 2. 非同期処理で考慮すべき面倒なポイント（設計フェーズ）

• (1) メッセージキュー/タスクキューに対する理解:
  • 課題: AWS SQSやGoogle Cloud Pub/Subなど、利用する仕組みの仕様、機能、オプション、制限を正確に理解しておく必要がある。
  • 運用上の考慮点: メッセージが溜まった際のワーカー数の手動スケールの必要性、それに必要なアラートやメトリクスの取得・設定を設計に含めるべきである。
• (2) ワーカー処理が失敗したときのリカバリ方法:
  • 課題: ワーカーの処理は100%成功しないため、失敗時のリカバリ方法を設計する必要がある。
  • 手動リカバリ: 失敗頻度が低い場合は、エンジニアが手動でメッセージを再キューイングする方法が考えられるが、手順の複雑化や手順書の最新性維持が困難になる可能性がある。
  • 自動リカバリ: 失敗した処理をDBに記録し、定期実行バッチでリトライする方法が考えられるが、実装の手間やバッチ自体の失敗対応、処理タスク数の設計など、考慮点が多くなる。
• (3) ボトルネックの確認と対策:
  • 課題: 非同期処理を採用しても、最終的に処理はどこかで実行されるため、ボトルネックや負荷は残る。特にRDBがボトルネックになる可能性が高い。
  • 具体的なボトルネック: DBへの複雑なクエリや大量クエリによるDB負荷、メッセージ集中によるワーカー数クオータ上限到達、アラート発火などが考えられる。
  • 対策例:
    • 同時に実行できるワーカー数を制限する。
    • ワーカー処理用に専用のDBインスタンス（分析用DBなど）を用意する。
    • メッセージキューにキューイングできるメッセージ数を制限する。
    • ワーカー処理にsleepを入れ、クエリ実行間隔を長くする。
  • 補足: ハイトラフィックな非同期処理では、RDBよりもNoSQLやNewSQLといったスケールするDBとの相性が良い。

■ 3. 結論

• システムのスケーラビリティ: 非同期処理は面倒ではあるが、システムのスケール性能やサービス間の疎結合化を実現する上で非常に魅力的である。
• 将来の展望: ある程度の規模のシステムでは非同期処理の利用が避けられないため、エンジニアや組織は、システムのスケールに合わせて非同期処理を適切に扱えるようになるための変化への投資が必要となる。
• 重要性: 非同期処理は実装自体は簡単だが、設計フェーズで上記の面倒なポイント（仕様理解、リカバリ、ボトルネック）を考慮しなければ、リリース後の運用で大きな問題が発生する可能性が高い。

(2025/09/24)

Rails Needs New Governance

• Rails Needs New Governance

要約:

■ 1. DHH（David Heinemeier Hansson）の問題点

• DHHの人物像: Ruby on Railsの生みの親であるDHHは、成功した賢い人物であると評価されている一方、「Ruby界のFox News」と表現され、議論好きで反動的、反知性的、そして無礼な人物であると批判されている。
• 思想の変遷: DHHは、自身のブログで、当初は中道的な政治的信条を持つように見えたが、数年かけて反キャンセルカルチャー、反DEI、反トランスジェンダー、そして最終的にはナショナリズムへと傾倒していった。
• ファシズム的言説: ロジャー・グリフィンのファシズムの定義（国民の再誕を求めるポピュリスト的な超国家主義）を引用し、DHHの最近のロンドンに関するブログ投稿が、この「ファシズム」に該当すると指摘している。彼は、人種的多様性を否定し、人種的に純粋だった過去を賛美している。
• 矛盾: DHHは過去に「郷愁を嫌う」と述べていたにもかかわらず、近年の投稿では、DEIやキャンセルカルチャーが問題視される前の時代への郷愁を強く示している。

■ 2. RubyおよびRailsコミュニティのガバナンスの問題

• DHHの権力: DHHはRailsの著作権を保有し、Rails Foundationの創設者兼議長であり、彼の政治的信条にもかかわらず、Ruby Centralのような組織や、カンファレンスやポッドキャストなどのコミュニティから引き続き発言の場を与えられている。
• Ruby Centralへの不信感: Ruby Centralは、明確な事前通知やコミュニケーションなしに、RubyGems.orgのGitHubコードベースの管理権を強制的に引き継ぎ、全てのメンテナーのアクセスを取り消した。この不透明な行為により、コミュニティからの信頼を失っている。
• 企業の影響力: Railsの運営はShopifyからの資金に大きく依存しており、DHHやShopifyのCEOであるTobi Lütkeのような、右派の思想を持つ人物にコミュニティの方向性が左右されている。
• 行動規範の機能不全: RubyおよびRailsの行動規範は「寛容のパラドックス」に陥っており、憎悪に満ちた言説を排除できない構造になっている。

■ 3. 解決策と今後の展望

• 民主的な組織への移行: 企業スポンサーに依存するのではなく、コミュニティが主導する民主的な組織を設立することを提案している。この組織は、公開されたメンバーシップと民主的に選出されたリーダーシップを持ち、RubyGemsやRailsといった重要なプロジェクトを管理する。
• フォークの可能性: DHHがRailsの著作権を保有しており、自ら辞任する可能性が低いことから、RailsやRubyGemsのコミュニティ・フォーク（分岐）が必要になる可能性がある。
• 行動の呼びかけ: コミュニティは現状に甘んじるべきではないと主張している。DHHやRuby Centralに反発してコミュニティを去ったメンテナーたちが、新しいガバナンスの下で復帰することを呼びかけている。

MEMO:

• 揉めておるな

(2025/09/23)

言い訳しているひとは、自分が言い訳していると知っているし、自分を虚飾しているひとは自分が虚飾...

言い訳しているひとは、自分が言い訳していると知っているし、自分を虚飾しているひとは自分が虚飾していると知っている。心の表層では気づいていないけれど、深層では知っている。だから、ストレスがかかり、メンタルが病んでいく。

@sugimoto_kei

心の深層は自分ではみえない。だけど、徴候は現れる。人に会いたくなくなったり、何かを喋る時に口角がひきつる。話している相手が不自然に沈黙する。酒が欲しくなる。そうした徴候をとらえて、あれ、オレ、なにか誤魔化してないか、と探ることはできる。

sugimoto_kei

MEMO:

• だから杉本センセは陰湿な攻撃性を発露するというわけである
• 自己認識が出来てえらい

(2025/09/23)

イベント駆動設計を支える非同期処理について

• イベント駆動設計を支える非同期処理について | お届けチーム取組紹介 - 10X Product Blog

要約:

■ 1. 非同期処理を採用する動機

• 領域をまたぐ処理: 異なるビジネス領域（例: 注文、配達）間の連携において、サービス同士を疎結合にするために非同期処理を採用している。これにより、一部の領域の障害が他の領域に波及するカスケード障害を防いでいる。
• 同期処理のミニマル化: クライアントアプリからのAPI呼び出しなど、高速なレスポンスが求められる処理において、同期処理を最小限に抑えている。これにより、APIのレイテンシを低く保ち、ユーザー体験を向上させている。

■ 2. 非同期処理の具体的な実装例

• ピック・パックの例: ピッキングAPIではピックのみを同期的に行い、パック予定への追加は非同期に実行している。これにより、APIの応答速度を維持している。この設計には、「ピックができたら必ずパック予定に追加できる」といった前提条件の確認と、結果整合性が許容される業務手順の確立が必要である。
• データ集計の例: 都度クエリによる集計が難しい場合、イベント駆動型の非同期処理でデータを事前に集計している。これにより、単一プロセス内での処理に起因する競合やサーバ停止時の処理漏れを防ぎ、確実に処理を実行できるようになった。

■ 3. 技術スタックとアーキテクチャ

• 技術要素: Firestore、Eventarc、Cloud Runを組み合わせて非同期処理を実現している。
• 処理の流れ:
  • (1) Firestoreにドキュメントを書き込む。このドキュメントはイミュータブル（不変）な非同期メッセージとして扱われ、イベント発生日時や一意の識別子を含む。
  • (2) EventarcがFirestoreの書き込みをトリガーとしてメッセージを検知し、Cloud Pub/Subにプッシュする。
  • (3) Cloud Pub/SubのSubscriptionが、メッセージをCloudEventsの形式でCloud RunにHTTPリクエストとして送信する。
  • (4) Cloud Run上で、メッセージを受信したイベントハンドラが後続の処理を実行する。
• 実装の工夫:
  • サブスクライバー側: メッセージの重複処理を防ぐための排他制御や、メッセージの順序を正しく処理するためのユーティリティライブラリを用意している。
  • 参考パターン: アウトボックスパターンを参考にしている。FirestoreとEventarcの組み合わせが、データベースをポーリングするよりも運用が容易であることを評価している。

■ 4. 非同期処理導入のステップ

• ステップ1: gRPCリクエストハンドラ内で、イベントハンドラをプログラム上で同期的に実行する。
• ステップ2: gRPCリクエストハンドラ内で、イベントハンドラをプログラム上で非同期的に実行する。この段階で本番環境と同等のメッセージ流量を検証し、フィーチャーフラグを用いてステップ3への切り替え準備を行う。
• ステップ3: gRPCリクエストハンドラ内ではイベントの永続化のみを行い、イベントハンドラの実行は別プロセス（Cloud Run）に完全に移管する。これにより、システム全体が非同期処理となる。

(2025/09/23)

SIはやめておけ

• SIはやめておけ

20代の数年間SIで働いた。1年以上前に退職して今は別業界にいる。

今日、Evernoteを整理していたら「退職理由、SIの嫌な点」というメモが発掘された。退職直前のかなりストレスがたまっていた時期に書き殴った文章だった。学生の頃の私は絵を書いたりしていて、ものづくりで暮らしたいな〜などと思って始めたプログラミングが楽しかったので安易に受託開発業を選んでしまったが、その後悔が如実に表れていた。

一部自分でも覚えていない話もあったがコンテンツとしては面白かったし、今でもシステムインテグレーター業界で消耗する若者を減らしたいとは思うので公開してみる。

以下、同メモに加筆・修正したものなのでファンタジーだと思って読んでくれ。

■ 工数至上主義

受注した時点で売上がおよそ確定するので、後はその予定工数に収めて納品できれば御の字という考え方。よくある話だが、見積がおかしくても顧客と対等な関係が築けていないから追加請求もできない。時間（工数）をかければ良い成果物ができるかもしれないがそれを説明して顧客に嫌な顔をされたくないから、限られた工数の中での最善を尽くす。最善を尽くす、聞こえは良いが要は手を抜く。

つまり、どう頑張っても売上は同じなのだから、良いもの・価値を生むものを作ろうと考えない人が多い。社内で開発者と呼ばれる人間もそうだし、マネジメント層はそういうものづくり志向を持った人をリスク扱いすることもある。

これが諸問題の根源で、いかに述べるような組織・プロジェクトが出来上がっていく。

■■ 作業効率化しない

マニュアル作業の正確さをかたくなに信じてる人だらけで、ITとは何なんだと考えさせられる。

私は定型作業を効率化しようとjsやrubyでスクリプトを書いたりしていた。テストデータを開発用DBに突っ込んだり、テキスト処理して整形したり、Excelからコード生成したりするよくあるやつ。

あるとき上司に肩越しに自分の作業を覗かれて「何やってるの？」と聞かれ、そういうスクリプトを作ってると答えたら、工数とリスクの話をされた。曰く「そのスクリプト作るのに何日かかるの？工数に乗ってないよね？」「スクリプトのテストもちゃんとしないと結果が正しいって保証できなくない？」と。この時はイラッとして「30分でできる数十行のスクリプトだし自分の作業工数内で完結する。むしろ後工程や別の人でも同じことを再現性できて楽になる」とか真面目に説明してプログラムも見せたが、読もうとはせず（読めないので）1時間無駄にした。

■■ 技術力いらない

前述したようなビジネスモデルだから、営業力と、予定工数で無難にプロジェクトを終えるマネジメント力が大事。IT企業だが開発者は自社で持たない。不況の時に待機コストが発生するリスクがあるし、自社で抱えるより単価の安い開発者が人材派遣系の企業や下請けにいっぱいいるから。

社長があるとき社内広報で「技術は買うものだ」と言っていた。文脈で明らかに技術＝技術者のことだったので、使い捨ての人売り業と揶揄されていることへの自覚が無いと思う。

そういう人が集まっているor残っている組織なので開発者はほとんどいない。20〜30人ぐらいの課に1人ぐらいの割合でstaticおじさんがちらほらいるぐらい。大体20代からプロジェクトリーダーという立場をやり始め、だんだん大型の案件を扱えるようになっていき、後は出世ゲーム。部長のお気に入りが課長になり、部門長のお気に入りが部長になる。その繰り返し。

開発案件でのBP（ビジネスパートナー、委託先、派遣、下請け）比率は自分の周りだと1:5ぐらいが多い。プロパー社員一人が5人の開発を仕切る、みたいな形。案件規模によりだいぶ差があると思う。この比率が高い＝マネジメント力のある組織と考える会社はこの数字を上げようと必死で、比率の低い組織は評価が下がる。

私は開発が好きだったのでエンジニアとして生きていきたい、というようなことを評価面談の度に伝えているが、その度に会社の目指す方向を説かれてモチベーションが下がる。

■■ 意識の低い開発者メンバー

上述の通り、案件で接する開発者は基本的に社外の人間なのだが、彼らの技術力と意識の高さにはものすごいばらつきがある。言われたものはなんでもこなせる人、何でこの歳まで技術者やれてるんだと疑う人、このプロジェクトはおかしいと良い意味で騒ぐ人、何も意見を言わない人、CっぽくJavaを書く人、人当たりは良いが技術力がいまいちな人、すぐ休む人、バグやミスを隠す人…etc。

まぁ色んな人がいるのはどの業界のどの職種も同じだが問題は質だ。私の主観になるが本当にエンジニアとして尊敬できるレベルの人は1%いるかいないか。というのも、ほとんどの技術者は長年SIやその周辺企業と付き合ってきているので同じ体質に染まっているのだ。顧客が良いといえば良いという態度（この場合の顧客は私が所属する企業）、請負の場合は工数を超えない範囲で手を抜く姿勢、その他諸々。技術力だけをひたすら磨き続けてきたという人はごく一部だけだったし、そんな人でもGitHubアカウント持ってない・ブログやってない・OSSに貢献したことない、といった具合でクローズドな世界で生きている。

そうした技術者とやっていく中で最も厄介なのが教育コストだ。案件のあるなしで人が都度入れ替わり、新しい人が来るたびに同じシステム・技術要素の説明をして何とかやる気が出るようモチベートして、というのを繰り返すのに疲れた。私の会社固有の変なルールの説明はてきとうにしておいて、私は技術が好きな仲間が欲しかったので今のシステムの課題と技術面での改善や展望をよく話す。が、あまり食いつかれることはない。これは私の問題だが、そうした期待と落胆のループも疲弊の一因だ。

■■ static BP

ある時、一つの課に6年近くいるというBPと一緒に仕事をする機会があった。その課にはプロパーの技術者が長いことおらず、彼がその課の技術的中心を担っているという話だった。抜けられると途端に色んなものが崩壊するからという理由で、その人の派遣元にはかなり高額の単価を支払っていたと聞いた。課員が口をそろえて「あの人はすごい」「何でもできる」というので初めはかなり期待していた。

だが、拍子抜けした。あまりにも仕事が雑なのだ。コミットされたコードはTODOコメントだらけだし、バグがあまりにも多かった。一度も実行されずにコミットされ、他の人がチェックアウトした時点で判明したバグなんかもあった。それでも声が大きく、プロパーが技術を知らないのをいいことに自分のブランディングに完全に成功していた。客先にも顔を出し、信頼を得ているらしかった。「自分は設計が得意でテスト以降の工程には興味が無い」と言っていた。確かに彼が関わった各システムには独特の概念が埋め込まれた設計があったが、その複雑な設計は保守性が低く、他の開発者が触ると容易にバグを引き起こしていた。

また、彼はJavaの有名なフレームワークであるStrutsを拡張したいわゆるオレオレフレームワークを開発しており、それの出来は悪くなかったと思う。そのフレームワークに欠けているものをうまく補うような形になっていた。だがフレームワークのバージョンを上げると壊れるというのが残念な点で負債になりかけていた。

私は異動したが、彼は今でもそこにいると聞いた。

■ 技術の話

■■ テストコード書けない

（最低限のものしか作らないから）安くて早い！という触れ込みで売っているので、テストの工数が異常に少ないことも多い。特にテストコードを書くなんてもってのほか。そういう世界でやってきた人ばかりなので、30や40超えたマネジメント側は「テストコードって何？」状態だ。大型の改修案件が来た時にはコア機能だけでもテストを書いていこうと見積段階から社内で提案したが「顧客に『そんなメリットあるなら何で今までのプロジェクトではやってないの？』って問われるから、絶対言うなよ」と拒否された。

保守案件をやっていた頃、時間を捻出してコソコソとテストコードを書いたりしていた。その案件を離れてしばらく後、ある時リポジトリを覗いたら私が書いたテストコードがばっさり消えていて驚いた。コミットログから課内のstaticおじさん的な人が消したとわかったが、そのコミットコメントが「現在使用していないコードを削除」だった。これはもう問う気も失せて何も言えなかった。

■■ リファクタできない

先述したようにテストがそもそもないプロジェクトが基本なのでリファクタできないのだが、たとえテストがあったとしても勝手なリファクタは許されない。ソースコードは顧客の持ち物なので同意なしに改変することはいわば契約違反なのだ。たとえ内的品質が向上してコスト削減に繋がるとしても、そのためにお金を支払う顧客はまずいない。

■■ レビューない

私がいたどの案件にもコードレビューがなかった。リーダーと開発者数人という構成の場合、まず開発者は全員下請けでリーダーは技術の心得がない場合が多い。そうなると彼らの成果物の良し悪しを図るのは目に見えるシステムの挙動と実施されたテスト結果のExcel報告書だけになる。これが非常に非効率で、少しコードを読めばわかる明らかなバグや仕様理解の齟齬が頻発していた。特に受入試験と呼ばれるリリース直前の顧客側での最終確認や本番稼働中におけるhotfixは全機能をきちんとテストせずにデプロイされることが多く、そのhotfixがさらなるバグを引き起こしたりもしていた。

そもそもテストを書けという話だがテストが無いプロジェクトに足すのはかなり大変なので、レビューサイクルをきちんと回すだけでもかなり変わる。実際、私が入った案件ではすべてのコミットに目を通すようにし、明らかな問題は都度指摘することで品質の向上に繋がった。欲を言えば他の開発者にもレビューしてもらいたいが、下請けの彼らの工数を増やすことは嫌がられる。

■■ 新規技術試せない

無難にプロジェクトをこなすことと新しい技術を試すことの両立こそ技術者の腕の見せどころだと思っているが、ほとんどの場合それは許されなかった。新規にせよ継続にせよ案件を受注する段階で営業やマネジメント層と顧客間で「今回は過去に実績のあるこの技術でやります」という契約が結ばれているからだ。その技術（言語やフレームワーク）がいかに古く、保守性も将来性もないものだとしても受注できればよいし、その技術のサポート切れか何かの拍子で再度リプレイス案件でも受注できればさらにラッキーぐらいの考えでいる。

常に横に倣えのアーキテクチャは私にとって面白くはなかった。

■■ 横に倣え

また横に倣えが加速してさらに悪い事に、同じアーキテクチャ・ネットワークを再利用するために既存のサーバに新システムも相乗りすればよいという発想も珍しくない。「資産の再利用によりコスト削減」という触れ込みだったが、ただでさえスケールしない低スペックのオンプレミスサーバ上で複数のアプリケーションサーバを運用した結果、予想通り耐障害性が下がった。

また、Oracleのライセンスが高いという理由で一つのDBインスタンス上に10数個のシステムが同時稼働しているなんてこともあった。1つのシステムが高負荷なクエリを投げたせいで関連する全システムが共倒れになったこともあったがOracleのバグとして報告していた。

■■ static Perlおじさん

新人の頃にOJTでstaticおじさんの下に付いたことがあった。そのとき担当したのはPerlでデータ連携用のバッチを書くという開発業務だったのだが、最悪の思い出だ。

まずプログラム構造仕様書というのを書かされた。メソッド単位でのモジュールを全てExcel上に記述し、処理の順番と内容を説明するという謎資料だった。あまりに意味がわからなかったので「UMLのクラス図を書けばよいのですか？」と聞いたら「Perlにクラスなんて必要ない。構造化プログラミングを研修でならってないのか」と返ってきた。「俺が前に書いたPerlのバッチがあるから参考にしろ」と言われ、あるリポジトリをチェックアウトして見てみると1ファイル4,000行の.plがいくつか並んでいた。その時の私は何もわかっていなかったのでそういうものかと思ってしまったが後で調べて明らかにおかしいと気づいた。

また、そのプロジェクトのメイン言語はJavaで、Eclipseを使っていたのでPerl用プラグインを入れてコーディング・デバッグをしていたらやめろと言われた。理由は「Eclipse上で動くPerlが信用できない。サクラエディタで書いてプリントデバッグすれば充分だ」と言われた。その時の私は何もわかっていなかったので、プラグインの品質が悪いとかそういう話かと思い「じゃあvimで書きます」と言ったら「サクラエディタにしろと言っただろ！」と一喝され、vim vs サクラエディタという史上類を見ないエディタ論争が起きた。

■ 待遇・制度

■■ 給与

SI業界の中では高いのかもしれないが決してよくはない。4年目（たぶん25歳）ぐらいで残業込みで年収400万にやっと届いたがそこからほとんど変わっていない。30歳の先輩に聞いたところ「500万前後、残業してない場合の月の手取りは未だに20万切ることがある。残業抜きでは新婚生活が厳しい」と言っていた。いわゆる年功序列がきっちりしていてこのまま続けてもしばらくは給与が伸びないということがわかった。

個人での貢献で差がつくのは±10万程度。その程度ならいっそ無くてもいいのでは、と思う。というかそもそも生産性をきちんと評価する制度が存在しない。これはどの組織でも難しい問題だと思うが、形骸化した評価制度で上司の気に入った人間にS評価を付けているだけならいっそ止めたほうが時間の無駄にならなくてよい。

■■ マシン

会社から貸与されるノートPCは低スペックすぎて開発には使い物にならない。なので開発者は基本的にデスクトップを使用せざるを得ないのだがこれもメモリ4G、1.2GHz程度で大したマシンでもない。本当に開発する気がない。

■ 組織の問題

■■ とにかくクローズドな組織

いつの間にかどこかで意思決定がされていて、関与する機会がほとんどない。だがほとんどの社員がそれで良いと思ってる。失敗しても自分が決めたことじゃないから上層の責任だ、そう言えるので楽だから。

情報共有をしない、というか意図的にしないようにしているとまで感じる。連絡はメールと添付ファイルベースで行っているし、共有のファイルサーバなんてのもあったが一部のフォルダは権限を持った人間しか見られない。何で他の部や課が行った過去の見積や提案資料が自由に見られないんだよ。

ソースコードのリポジトリも同様。外部に公開しないのはまだわかるが、プロジェクト外にすら基本は公開していない。別に奪われて困る大した技術もない。

会社が用意した提案資料共有サイトみたいなのもあったが、それに至ってはもっとひどい。課長以上もしくは部長から承認を与えられた者のみ閲覧可能。共有とは。

■■ 意思決定の遅さ

どうでもいいことを決めるにも承認や根回しや説得が必要になる。それがプロジェクトの利害関係者ならまだわかるものの、まったく関わっていない上長（課長や部長、時には部門長）を通さないと進まないという異常さ。

■■ コスト削減

利益率向上のためにコスト削減ということがしきりに言われており、過剰なコスト削減対応が生産性の低下を招いている。たとえば顧客に見せる資料以外は白黒で印刷しろ、みたいなルール。色がないために情報が伝わりにくい。というかそもそも印刷せずに各自のノートPCで見ろという話だが、先述したようにノートPCは低スペックすぎるので多くの社員がデスクトップを使っている。ITとは。

本当に無駄としか思えない承認・申請フローの煩雑さに加え、使っているシステムの使い勝手も悪く、ひどい日は一日がそうした事務作業で終わる。しかもそのシステムは自社で以前開発したものだというから泣けてくる。こんな作業が定常的に発生するのでいっそ事務員を派遣で雇うべきという提案が何度もされたが、課の予算をオーバーするから無理だという回答しか返ってこない。

■■ 残業削減

表向きは社員の健康促進という触れ込みで残業時間削減を全社的に取り組んでいる。残業減らせと声をかけただけでは誰も帰らないので、勤怠システムと入退館管理システムを監視し、削減できていない組織や人間の評価を下げるようになった。

その結果、サービス残業が復活した。30時間を超えると部長に説明しないといけない、50時間を超えるとその上へ…みたいなループ。表向きの残業時間削減・コスト削減としては成功したかもしれないが、社員の残業時間を管理するとかいう無駄な仕事を増やしたし、管理される社員のストレスとサービス残業に繋がったので下策だと思う。

他人の残業時間をExcelにまとめる仕事があって、そこに給与が発生してると思うと泣きたい。

そもそも無駄な作業や工数至上主義で作業効率が悪いから残業しているので、残業が少ない奴が偉いと一斉に舵取りしただけでは生産性をちゃんと評価できていないことに変わりはない。一昔前の残業多い奴は頑張ってて偉い、というのと本質レベルで何も変わっていない。

■ 辞め方

• このメモを端折って伝える
• このメモを公開して炎上する

MEMO:

• 2016年に書かれたもの
• 10年以上経った2025年時点では流石にそこまで非効率ではないと思いたいが

(2025/09/23)

frostdb: Go言語製の列志向DB

• GitHub - polarsignals/frostdb: ❄️ Coolest database around 🧊 Embeddable column database written in Go.

README要約:

■ 1. FrostDBとは何か

• 概要: Goで書かれたオープンソースの列指向データベースである。
• ユースケース: 観測可能性（Observability）、セキュリティ、およびアプリケーションのデータ分析のために設計されている。

■ 2. 主な特徴

• 高速性: 実行時に最適化された並列クエリ実行エンジンと、高度なベクトル化されたクエリ処理により、非常に高速なクエリ応答を実現している。
• データ形式: Apache Arrowインメモリ形式でデータを管理し、他のシステムとの統合が容易である。
• スケーラビリティ: 水平方向へのスケーリングが可能で、大規模なデータセットや高スループットの取り込みをサポートしている。
• 圧縮: Zstdによる高度なデータ圧縮を行い、ストレージコストを削減している。
• 効率性: ストレージからの読み込みを最小限に抑え、クエリの実行効率を最大化している。

■ 3. 用途と利点

• リアルタイム分析: 観測可能性データ（メトリクス、ログ、トレース）やセキュリティイベントのストリーミング分析に適している。
• コスト削減: 高いデータ圧縮率と効率的なクエリ実行により、インフラコストを大幅に削減できる。
• オープンソース: Apache ArrowやApache Parquetなどのオープンソースエコシステムと連携しており、拡張性やカスタマイズ性が高い。
• 開発言語: Goで開発されており、パフォーマンスと安全性の両方を確保している。

■ 4. プロジェクトの現状と展望

• プレリリース段階: 現在はまだプレリリース版であり、本番環境での利用は推奨されていない。
• 今後の開発: 開発チームは、より多くのユーザーシナリオに対応するための機能追加やパフォーマンスの最適化に取り組んでいる。

(2025/09/23)

あるある会話　PM「顧客からこういう要望が来たのですが、技術的にできますか？」　エンジニア「できると思...

あるある会話

PM「顧客からこういう要望が来たのですが、技術的にできますか？」

エンジニア「できると思いますが、開発が必要ですね。」

PM「工数見積ってください。」

エンジニア「見積る前にその機能で顧客が本当に何をしたいか確認したいです」

PM「顧客折衝は私の仕事です」

エンジニア「は？」

@hskfwy

続き

PM「一応顧客に聞いてみます(まあ見積出す時に言お)。まず工数と費用出してください」

エンジニア「見積りました」

PM「この機能を既存WBSに入れることってできますか？人増やせばいけますか？それとも後で追加した方がいいですか？」

エンジニア「(なんでこっちでばっかり対応せなあかんねん)」

@hskfwy

(2025/09/23)

PMがエンジニアリング分からないと起きる事。例えば他部署から「これ技術的に出来ますか？」と質問された時...

PMがエンジニアリング分からないと起きる事。例えば他部署から「これ技術的に出来ますか？」と質問された時に自分では判断できないため「持ち帰って検討します！」もしくは「毎回エンジニアを同伴させる」という事になりますね。これでも回りますが、リーダーシップという点で少し頼りないですよね

@sakamoto_582

MEMO:

• 伝書鳩PMはいらないというというお気持ちは理解するが、勝手に回答されても困るのもまた事実

関連:

• 「あいつはひとりでも大丈夫」と会議を任される新人。会議中のふるまいが秀逸だった。

(2025/09/23)

ドキュメントはAIの味方！スタートアップのアジャイルを加速するADR

• ドキュメントはAIの味方！スタートアップのアジャイルを加速するADR - Speaker Deck

要約:

■ 1. AI時代のドキュメントのあり方

• アジャイルとドキュメント: アジャイルソフトウェア開発では、ドキュメントより対話や変化への対応が重視されてきた。しかし、AI時代には、AIとの対話や協調、変化への対応をスムーズに進めるための「意味のあるドキュメント」が必要不可欠となる。
• ドキュメントの役割:
  • 対話のスケール: 意思決定の「なぜ」と「何」を記録し、継続的・正確な対話を可能にする。
  • 知識の共有: 人間とAIが共有できる「知識の種」となる。
  • 変化の適応: 過去の履歴を「足跡」として残し、それを基に未来の更新や提案を行う。

■ 2. 従来のドキュメントの悩みとAIによる解決

• 一般的な悩み:
  • 「探せない」「バラバラ」: 情報が分散し、必要な情報を見つけられない。
  • 「読まれない」「残らない」「更新されない」: ドキュメントが活用されない。
  • 「時間がかかる」: ドキュメント作成に手間がかかる。
• AIによる解決:
  • 探す・まとめる: AIが文書内を検索・要約し、情報を探してくれる。
  • 書く: AIとの共作により、ドキュメント作成の時間を大幅に短縮できる。
  • 残す・更新する: AIへの指示が必要となるため、人間が主導権を握る必要がある。

■ 3. 「ADR（Any Decision Record）」の導入

• 課題解決: 従来のADR（Architecture Decision Record）は、アーキテクチャ以外の意思決定を記録しにくい、粒度が不明瞭、組織に定着しにくいといった課題があった。
• 「全部残す」文化: Dress Code株式会社では、これらの課題を解決するため「ADR（Any Decision Record）」という考え方を採用している。
  • 記録対象: どんな小さな意思決定もドキュメントとして記録する。
  • ツール: Notionをドキュメントツールとして利用し、Notion AIを活用している。
  • 文化の定着: ドキュメントを書くためのきっかけ作りとして、毎週の書き溜めやSlackでのスタンプによるストック、フィードバックの共有会などを設けている。
• メリット:
  • 検索性向上: 「Notion AI」が代わりに見つけてくれるようになる。
  • 粒度の問題解消: 領域や大小に関わらず記録するため、粒度に悩まなくなる。
  • オンボーディングの効率化: 新入社員が「Notion AI」に質問することで、過去の意思決定の経緯を簡単に把握できる。

■ 4. 今後の改善点

• 更新されない問題: 最終更新日や編集者の表示は行っているが、依然としてドキュメントが更新されないという課題は残っている。
• 仕様記載の場所: 仕様をADRに含めるか、PBI（product backlog item）に記載するかという判断に迷いが生じることがある。現状は、ADRを書いてPBIにリンクさせている。
• 作成者への感謝: ドキュメントを作成した人への感謝を表現する文化をさらに醸成する必要がある。

(2025/09/23)

エンジニアはちゃんと身銭を切れ

• エンジニアはちゃんと身銭を切れ - じゃあ、おうちで学べる

要約:

■ 1. 身銭を切るとは何か

• 定義: 失敗した場合に相応のペナルティを支払う覚悟を持つことである。
• 具体的内容: 給料やクビといった金銭的、物質的損失ではなく、自身の評判、プライド、チームからの信頼、時間、精神的なストレスなど、目に見えない資産を賭けて仕事に臨むことである。
• プロフェッショナリズム: プロフェッショナルとは、仕事の結果に責任を持ち、「言われた通りに作っただけ」という言い訳を使わない姿勢のことである。

■ 2. エンジニアが身銭を切らない理由

• 「心理的安全性」の誤解: 「率直な意見を言える環境」が「失敗しても責められない環境」と誤って解釈されている。これにより、失敗を恐れず、責任を回避する文化が生まれている。
• キャリアの流動性: 転職市場が活発なため、プロジェクトの失敗や技術的負債を「次の会社に移ればリセットできる」という考え方が広まっている。
• 「技術的に正しい」という隠れ蓑: ユーザーにとって価値がない結果でも、「技術的には正しい」という言葉を盾にして責任を回避する傾向がある。
• 集団責任という幻想: 「チーム全体で責任を持つ」という理念が、「誰も責任を持たない」ための言い訳として変質している。

■ 3. 身銭を切ることの代償

• リスクの非対称性: 成功すれば評価されるが、失敗しても大きなペナルティがない。エンジニアにとっては「学習機会」でも、ユーザーにとっては「不便」でしかない。
• 同じ失敗の繰り返し: 痛みを伴わない失敗は他人事として処理され、そこから学びが得られない。

■ 4. 身銭を切ることのメリット

• 意思決定の質向上: 自分が責任を負う覚悟があれば、安易な技術選定や適当な設計は避けるようになる。
• 学習曲線の急上昇: 失敗から来る痛みは、深い学びにつながり、知識が実践で使えるものになる。
• プロフェッショナルとしての承認: 結果に責任を持つことで、単なる「作業者」から真の「エンジニア」として認められる。
• 本物の自信: 身銭を切って成功・失敗を経験することで、揺るぎない自信が身につく。

■ 5. 組織における身銭の力

• 少数決原理: 組織の重要な意思決定は、最も失うものが大きい人、つまり最も身銭を切っている人の意見が採用される原理に基づいている。
• 信頼の獲得: 日頃から責任を負う姿勢を見せることで信頼を獲得し、その発言に重みが生まれる。身銭を切る個人の必死さが、組織全体の方向性を決定する。

(2025/09/22)

アーキテクチャConference 2025（2025/11/20-21）

• 最適なアーキテクチャをどう描くか。｜アーキテクチャConference 2025 

技術の変化が加速し組織やツールが多様化する今、最適なアーキテクチャをどう描くか。

アーキテクチャは、プロダクトの特性やチームのあり方によって最適解が異なり、普遍的な正解は存在しません。
トレンドを追うだけでは不十分で、設計に込めた意図を自らの文脈で捉えて継続的に見直していくことが求められます。


本カンファレンスでは、アーキテクチャの構想・判断・構築にまつわるリアルな知見を共有し、多角的な視点から設計判断への理解を深めます。自社にとって最適な構成を考えるための視点とヒントを、実践につながるかたちで持ち帰っていただける場を目指します。

MEMO:

• 動画配信してくれるとよいが

(2025/09/22)

ソフトウェアエンジニアがプロダクトにオーナーシップを持てないアンチパターン、構造

• ソフトウェアエンジニアがプロダクトにオーナーシップを持てないアンチパターン、構造 - 猫型の蓄音機は 1 分間に 45 回にゃあと鳴く

要約:

■ 1. オーナーシップを持てない原因

• 越境の困難さ:
  • アンチパターン: ソフトウェアエンジニアが、プロダクトの仕様やビジネス上の解決策に対して意見を言いにくい構造が存在する。
  • ベンダー（外部委託）: 産業構造上、発注者の要求をそのまま受け入れるインセンティブが強く、より良い解決策を提案する動機が薄い。
  • 内製:
    • 「仕様の実現が仕事」という誤った認識を持つ組織がある。
    • 「余計な仕事をさせたくない」という善意や、「相手の考えをひっくり返すのは悪い」という過剰な遠慮が、議論の妨げになっている。
• 注意: そもそもエンジニア自身がオーナーシップを持ちたくない場合は、議論の対象外である。

■ 2. オーナーシップのレベル分け

• 3つの段階: オーナーシップには以下の3つのレベルが存在する。
• システムに対するオーナーシップ: 障害対応や他者の問題解決など、明確に任されていないシステムの部分にも積極的に関わること。
• プロダクトに対するオーナーシップ: ユーザー課題を解決するため、仕様に対してより良い提案をすること。
• ビジネスに対するオーナーシップ: プロジェクトの制約（コスト、人員、納期など）を考慮し、現実的な解決策を提案すること。

■ 3. オーナーシップ獲得のステップ

• 段階的なアプローチ:
• まず、獲得しやすいシステムに対するオーナーシップから始めるべきである。
• システムに対する積極的な関わりは、周囲（非エンジニア）からの信頼獲得につながる。
• この信頼を基盤として、プロダクトやビジネスへの口出し・手出しが可能になり、より高いレベルのオーナーシップを持つことができる。

■ 4. 組織と個人の対応

• 硬直した組織: 非常に硬直した組織では、このアプローチが通用しない場合もある。その場合は、無理に立ち向かわず、別の場所で経験を積むことも一つの選択肢である。
• 個人のマインド: 本人も周囲もオーナーシップを望んでいるにもかかわらず持てない場合は、越境を阻む構造を認識し、段階的に行動を起こすことが解決策となる。

(2025/09/22)

tsuna/gorewrite -- 複雑な条件のファイル検索・置換を楽にするライブラリ

• GitHub - tsuna/gorewrite: A small library to help rewrite / modify the AST of a Go (golang) program
• Go - 複雑な条件のファイル検索・置換を楽にするライブラリ「go-rewrite」を作った #コマンド - Qiita

README要約:

■ 1. 既存ツールの課題

• Goの標準ツール: Go言語には、コードの抽象構文木（AST）を解析し、整形するツールが備わっている。ast.Walk()とVisitorを使うことで、ASTのノードを走査・変更できる。
• ツールの限界: ast.Walk()は、既存ノードの内容やサブノードの変更は可能だが、ノード自体を別のノードに置き換えることはできない。これは、ある種の式を別の種類の式に書き換える場合などに必要となる。

■ 2. gorewriteの機能と利点

• 解決策: 「gorewrite」は、この問題を解決するために開発されたツールである。
• 主要機能: ast.Walk()と似ているが、Rewriterという機能拡張されたVisitorを使用する。このRewriterは、修正したast.Nodeを返すことが可能である。
• 利点: 既存のノードを別のノードに置き換えることができ、コードの書き換えをより柔軟に行うことができる。利用者はast.Walk()の代わりにRewrite()を呼び出すだけでよい。

(2025/09/22)

yt-dlp/yt-dlp

• GitHub - yt-dlp/yt-dlp: A feature-rich command-line audio/video downloader

MEMO:

• Youtubeの動画ダウンローダーらしい

(2025/09/22)

エンジニアリングマネージャの役割パターン６種

• エンジニアリングマネージャの役割パターン６種 #マネジメント - Qiita

要約:

■ 1. EMの役割を巡る議論

• 問題の背景: エンジニアリングマネージャー（EM）の役割は多岐にわたり、「コードを書くべきか」「書くべきでないか」など、人によって意見が大きく異なる。
• 役割の変化: EMが担う役割は、チームの状況、個人の得意分野、組織でのEMの定義などによって変化する。

■ 2. マネジメント領域の分解

• 4つのマネジメント領域: 一般的に、EMの役割は以下の4つに分解される。
• プロダクトマネジメント: プロダクトの方向性を定める。
• プロジェクトマネジメント: スケジュールやタスクを管理する。
• ピープルマネジメント: メンバーの育成や評価を行う。
• テクニカルマネジメント: 技術的な意思決定や課題解決を行う。
• 役割の委任: EMはこれらの領域すべてをカバーするが、特定の得意分野を持つメンバーに一部のマネジメントを任せることがある。

■ 3. EMの6つの役割パターン

筆者は、EMの具体的な動き方として以下の6つのパターンに整理している。

• Development Project Manager:
  • 特徴: プロジェクト型開発において、機能リリースとスケジュール管理に重きを置く。
  • 比重: プロジェクトマネジメントの色が濃い。
• Mini-CTO:
  • 特徴: 経営レベルで技術戦略や組織の未来に関する意思決定を行う。
  • 比重: 現場の細かい進行には関わらず、事業実現のための技術的な意思決定を推進する。
• Technical Team Lead:
  • 特徴: テックリードに近い役割で、技術的な意思決定やリードを行う。
  • 比重: テクニカルマネジメントに重点を置く。プロジェクト管理はチーム全体で分担する。
• Cross-Organization:
  • 特徴: チーム横断的な技術課題や連携の問題を解決する。
  • 比重: 大規模な組織で機能不全を防ぐために必要な役割である。Technical Program Managerもこのパターンに属する。
• Product Owner:
  • 特徴: 技術的要素が強いプロダクトにおいて、プロダクトオーナーとして技術と事業価値のバランスを取りながら意思決定を行う。
  • 比重: 技術的知見が不可欠なプロダクトマネジメントを担う。
• Organization Development / Organizational Designer:
  • 特徴: 組織開発や組織設計、エンジニア固有の採用・人事施策を担当する。
  • 比重: ピープルマネジメントを広く深く行う。

■ 4. パターンの傾向とまとめ

• 傾向:
  • 上段（Development Project Manager, Technical Team Lead, Product Owner）: チーム内に軸足を置き、チームと共に活動することが多い。
  • 下段（Mini-CTO, Cross-Organization, Organizational Designer）: チーム外に軸足を置き、自律的なチームに大部分の実行を委譲する。
• 活用の意義:
  • EMの役割は多岐にわたるため、認識のズレや期待のズレが生じやすい。
  • これらのパターンを理解することで、自身のチームのEMがどの役割を担っているかを明確にし、期待のズレを減らすことができる。
• 結論: EMはどのような関わり方であってもエンジニアリング領域の責任を期待されている。

(2025/09/22)

イベントストーミング図からコードへの変換手順

• イベントストーミング図からコードへの変換手順 / Procedure for Converting Event Storming Diagrams to Code - Speaker Deck

要約:

■ 1. イベントストーミングの基礎

• 目的: イベントを起点として、ビジネスプロセスやシステムのモデリングを行う手法である。
• 構成要素:
  • アクター: コマンドを実行する主体である。
  • コマンド: 何らかのアクションを実行する意図や要求である。
  • 集約: コマンドを処理するオブジェクトである。
  • イベント: ビジネス上で発生した重要な出来事や事実である。
  • リードモデル: データの読み取りに最適化されたデータ構造やビューである。
  • ポリシー: 自動化された判断ロジックであり、nrs流では条件を空欄にして「必ず」を意味させる。
  • 外部システム: 対象システムの境界外にあるシステムである。
• ルール:
  • 付箋は特定の付箋からしか繋げられない。
  • 複数のイベントは結果の分岐や並列に起きる出来事を表す。
• 実践方法:
  • ワーキングセッション: メンバー全員が理解した上で取り組む。一気に進むが、経験がないと難しく、長時間かかる。
  • ヒアリング: ファシリテーターがヒアリングを進める。短時間でまとまりやすいが、ファシリテーターの技量に依存する。

■ 2. イベントストーミング図からコードへの変換

• 変換の前提: 今回のセッションでは、イベントストーミング図をトランザクションスクリプト、ドメインオブジェクト、複合パターン、バッチ処理といったコードに変換する。
• 単純な処理: アクターからコマンドが投げられ、リードモデルに繋がるパターンは、コントローラーとアプリケーションサービスで実装する。
• ポリシーが絡む処理: コマンドの実行中に条件分岐が発生する場合（例：写真が同時にアップロードされた場合）、アプリケーションサービス内でポリシーとして実装する。
• 外部システムとイベントの分岐: 決済処理のように外部システムとの連携と、その結果（成功/失敗）によってイベントが分岐するパターンは、アプリケーションサービス内で外部サービスを呼び出し、結果に応じて異なる処理を行う。
• バッチ処理: 一括で大量のデータを処理するバッチ処理も、イベントストーミングのパターンとして表現できる。

■ 3. イベントストーミング図の活用と注意点

• 図の目的: 図はすべての情報を表現することが目的ではなく、実装に役立つドキュメントとして活用すべきである。
• 図の種類:
  • ビジネスプロセスモデリング: ビジネスの流れを可視化する。
  • システムモデリング: より実装に即した設計を行う。
• コードとの一致: 図とコードを完全に一致させたい場合は、イベントソーシングのような手法を適用する必要がある。

(2025/09/22)

「技術的には可能です」の少しマシな言い方

• 「技術的には可能です」の少しマシな言い方

要約:

■ 1. 問題提起

• 「技術的には可能」問題: 実際には多くの問題（影響範囲、品質、コスト、スケジュール）があり、「できない」と心の中で考えているにもかかわらず、表面上は「技術的には可能」と答えてしまう問題である。
• このような回答は、曖昧さから相手に不評を買う原因となる。

■ 2. 解決策：「できる」と「やる」の分離

• 責任の明確化:
  • 「できる」: 技術的な可否は回答者（自分）の責任である。
  • 「やる」: 実行の決定は相手の責任である。
• 伝え方: 「できますが、〇〇が必要です。やりますか？」という形で、技術的な可否と、それに伴う条件（スケジュール変更、コスト増加など）を一息に伝える。
• 前提条件: このコミュニケーションを可能にするためには、腹を割って話せる信頼関係が不可欠である。それが築けないプロジェクトは成功が難しいと判断している。

■ 3. 「じゃあ見積もって」への対処

• 本気度の確認: 見積もりはプロジェクトの中心メンバーに負担をかけるため、安易に引き受けず、相手の本気度を確認すべきである。
• 顧客への伝え方:
  • 原則: 「お金がかかってもやるなら見積もります」という姿勢を伝える。
  • 具体的提案:
    • 金額で示す: 「最低でも〇〇人月かかりますが、それでもやるべきかご判断いただけますか？」
    • 金額以外で示す: 「1か月リリース延期が必要かもしれません」といった形で、影響範囲を伝える。これにより、相手は金額を直接聞かなくても判断できる。

■ 4. まとめ

• 重要なのは、「できる」ことと「やる」ことを明確に分離し、それぞれに責任を持たせることである。
• 見積もりの依頼に対しても、相手の本気度や重要度を確認し、プロジェクトのリスクを避けるべきである。

(2025/09/22)

フロントエンド開発に役立つクライアントプログラム共通のノウハウ

• フロントエンド開発に役立つクライアントプログラム共通のノウハウ / Universal client-side programming best practices for frontend development - Speaker Deck

(2025/09/22)

プログラミング言語の表層構文の合理性／プログラミング言語の見た目を自然言語に寄せることが...

• プログラミング言語の表層構文の合理性／プログラミング言語の見た目を自然言語に寄せることが良いとは限らない | 雑記帳

要約:

■ 1. プログラミング言語構文と自然言語

• 問題提起: プログラミング言語の構文はしばしば自然言語（特に英語）に似せられるが、これは必ずしも合理的な設計ではない。
• 暗黙の仮定: 「自然言語のように読める構文が良い構文である」という暗黙の仮定が存在するが、この妥当性を考察する必要がある。

■ 2. 構文の合理性を測る基準

• import文の語順:
  • 論点: import以外のキーワードで始まる構文は不便か。
  • 例: Pythonの from ... import ... や、Haskellの import qualified ... の語順は、慣れていないと不便に感じられることがある。
  • 合理性:
    • 視認性: importキーワードと対象の名前が近い方が読みやすい。
    • 編集の利便性: テキストエディタのソート機能で簡単に並び替えができるよう、先頭にキーワードが来る方が良い。
• 頭でっかち構文の是非:
  • 論点: 重要な要素が長い修飾子によって後回しにされる構文は読みづらいか。
  • 例: C/C++における長い返り値の型定義、Haskellにおける長い型制約。
  • 合理性:
    • 可読性: 関数の名前など、重要度の高い部分が先に来る方が、コードを読み進めやすい。
    • 対策: C++11のautoや、Rust/Swiftのwhere節のように、重要度の低い部分を後置にできる構文がより合理的である。
• 前置キーワードの必要性:
  • 論点: ifやtryのような構文を示すキーワードが、対象の式の前にあった方が良いか。
  • 例: PerlやRubyの後置if文、Pythonのif式は賛否が分かれる。Standard MLのhandle式のように前置キーワードがない構文は失敗だったと筆者は考えている。
  • 合理性:
    • 可読性: 構文の種類を示すキーワードが先頭にある方が、コードの構造を素早く理解できる。
    • 例外: Lisp/SchemeのS式は前置キーワードの原則を徹底しているが、必ずしも広く普及しているわけではない。

■ 3. 自然言語とプログラミング言語の違い

• 大きな構造: プログラムはモジュールやクラス、関数といった構造を持ち、必要な部分だけを把握して読めることが重要である。
• 記号の活用: プログラミング言語では記号を多用するため、スマホのキーボードや音声入力には不向きである。また、記号が多すぎるとコードが暗号化する問題もある。
• インデントの活用: プログラミングではインデントで構造の深さを明示する。固定幅のインデントが一般的なエディタでうまく機能するよう、言語設計を工夫することが望ましい。
• 規則性: 自然言語には例外が多いが、プログラミング言語は学習コストの観点から、例外を減らして規則的であるべきである。
• 表現の多様性: 自然言語では同じ内容を別の言い方で表現するが、プログラミング言語では一つの内容に対する書き方は一つに定まっている方が、定型的に読み書きできて望ましい。

■ 4. 結論

• 多様な合理性: プログラミング言語の合理性は、「人間が書く・読む」「コンパイラが処理する」「シンプルなエディタやIDEで編集する」など、様々な観点から議論できる。
• 自然言語との距離: プログラミング言語と自然言語は異なる媒体であるため、自然言語に似せた構文が無条件に優れているとは言えない。

(2025/09/22)

AIにおける古い考え方「世界モデル」が再注目されている理由とは？

• AIにおける古い考え方「世界モデル」が再注目されている理由とは？ - GIGAZINE

要約:

■ 1. 世界モデルの概要と歴史

• 定義: AIが外界や環境を内部的にシミュレーションし、未来予測や因果関係を理解するための内部モデルである。
• 起源: 1943年、心理学者ケネス・クレイク氏が提唱した「生物が世界の内部モデルを持つことで、行動の結果を予測できる」という考えに由来する。
• 歴史的変遷:
  • AI研究初期には「ブロックの世界」を理解する「SHRDLU」などで世界モデルの考えが取り入れられた。
  • しかし、当時のモデルは現実世界の複雑さを再現できず、「明示的な世界モデルを持たなくても環境に適応できる」という世界モデル不要論へと傾いた。
  • 近年の深層学習の向上と膨大なデータの利用により、再び世界モデルが注目されている。

■ 2. 世界モデルと大規模言語モデル（LLM）

• LLMの「創発能力」:
  • 絵文字から映画タイトルを推測したり、訓練されていないオセロをプレイしたりする能力が創発されることから、研究者の間で「LLMがすでに世界モデルを内部に持っているのではないか」という疑問が生まれている。
• 「世界モデル」と「ヒューリスティックの塊」の違い:
  • パヴラス氏の見解によると、LLMはあくまで「ヒューリスティックの塊」である。
  • ヒューリスティック: 膨大なデータから得た「断片的な経験則の網羅」を組み合わせる近似アルゴリズムであり、高精度な対応はできるものの、一貫性や確実性に欠ける。
  • 世界モデル: 道路の1%が遮断された場合でも、地図全体を再構築して最適な経路を見つけるなど、因果関係を深く理解できる。ヒューリスティックの塊であるLLMでは、このような状況で精度が急落する。

■ 3. 世界モデルの意義と展望

• 汎用人工知能（AGI）の実現: 世界モデルはAGIを実現するための重要な目標である。
• 応用分野: 自動運転車の未来予測や、ロボットの安全な行動計画などへの応用が期待されている。

(2025/09/21)

マッチョスクラム問題とスクラム教問題を解決する「別の強さ」について

• マッチョスクラム問題とスクラム教問題を解決する「別の強さ」について - arclamp

要約:

■ 1. 問題の定義

• マッチョスクラム問題:
  • 概要: 「弱さを見せず、困難に打ち勝つ姿勢が価値である」というマッチョイズムがスクラムに過剰に持ち込まれる問題である。
  • 具体例:
    • 自己管理の強制: 「チームが自律的に解決すべき」「自己管理できないのは未熟だから」といった圧力が生まれる。
    • 自己否定的な改善: 振り返り（レトロスペクティブ）が「なぜできなかったか」を指摘し合う場になり、自己否定につながる。
    • 過剰なアウトカム志向: 「成果を出せない人は貢献していない」という空気が生まれ、多様性が失われる。
• スクラム教問題:
  • 概要: ある原則やルール（スクラムガイドなど）を絶対視する教条主義がスクラムに持ち込まれる問題である。
  • 具体例:
    • スクラムガイドの絶対化: 「スクラムガイドに書いてあるから正しい」とし、現場の現実を無視した形式主義に陥る。
    • アレンジの否定: 現場の状況に合わせたスクラムのアレンジが許されず、「正しいスクラムができない現場が悪い」と見なされる。
    • イベントの儀式化: スクラムイベントが形式的なものとなり、本来の目的である対話や改善の場として機能しなくなる。

■ 2. 問題の発生要因

• スクラムそのものの問題:
  • 抽象的なガイド: スクラムガイドが意図的に抽象的であるため、日本人の気質もあり「あるべき姿」にとらわれやすくなる。
  • 曖昧な認定制度: 認定制度や研修制度が、マッチョ化や宗教化を防ぐ機能を持たない。
• スクラムに関わる人の問題:
  • 不満の捌け口: スクラムの理想を、既存の環境への不満の捌け口として利用し、「スクラムを実現できない環境が悪い」と他者を攻撃してしまう。
  • 権威性: スクラムマスターやアジャイルコーチといった立場が、無自覚に権威性を振りかざしてしまう。

■ 3. 問題の解決策

• 「スクラムを実践する」:
  • 経験主義に立ち返る: 「やってみて、観察し、学び、変えていく」という試行錯誤のプロセスを重視する。現状を悪と決めつけず、まず中立的に受け入れ、「なぜそうなっているのか」を掘り下げ、関係者で共有する。
  • 「なぜスクラムなのか」を考える: 「スクラムガイド通りにやればうまくいく」という考えを捨て、現状とのギャップを正しく把握する。
    • 「進め方マップ」の活用: プロジェクトの特性（要件定義の進め方、開発の進め方）を可視化する「進め方マップ」を活用し、チームの現状を客観的に認識する。
    • 柔軟なアプローチ: 要件が複雑な場合は四半期サイクルなど、現場のジレンマを解決するアプローチを検討する。

■ 4. 結論：「別の強さ」

• スクラムにおいて「強さ」や「正しさ」を求めることは、チームにプレッシャーを与え、柔軟性を失わせる。
• 真の強さとは、「誰か/何かが間違っている」と断定するのではなく、「いま、どうなっているのだろう」「どうすれば、よりよくなるのだろう」と問い続け、対話を続けることである。
• この現実を受け入れ、揺らぎながらも問い続ける姿勢こそが、マッチョスクラム問題やスクラム教問題を解決する「別の強さ」である。

(2025/09/21)

【PM講座#5/12】定量的に進捗管理できていますか？【プロジェクトマネジメントの教室】

• 【PM講座#5/12】定量的に進捗管理できていますか？【プロジェクトマネジメントの教室】 - YouTube

要約:

■ 立ち上げ

• 目的: 大枠のスケジュールを関係者間で合意する。
• 実施事項:
  • プロジェクト憲章の作成: プロジェクトの主要なマイルストーン（要件定義は〇月末、ベータ版は〇月末など）を記述し、全体像を共有する。
  • 重要な期限の認識合わせ: 年内リリースや法的期限など、クリティカルなマイルストーンについて認識を合わせる。

■ 計画

• 目的: 詳細なスケジュールを作成する。
• 実施事項:
  • 1. スケジュールマネジメント計画の策定: スケジュールをどのように作成・管理するか、そのルールや手法を決定する。
  • 2. アクティビティの定義: WBS（Work Breakdown Structure）を用いて、やるべきことを作業可能な単位（アクティビティ）まで分解する。スコープ管理と密接に関連している。
  • 3. アクティビティ所要期間の見積もり: 各アクティビティを完了させるために必要な人員や資材を検討し、所要期間を見積もる。
  • 4. アクティビティの順序関係の検討: アクティビティ間の依存関係を明確にし、ネットワークダイアグラムで可視化する。
    • クリティカルパスの特定: 開始から終了までの最も長い経路（クリティカルパス）を特定する。この経路が遅延すると、プロジェクト全体の遅延に直結する。
  • 5. スケジュールの作成: ガントチャートなどを用いて、全てのアクティビティの期間と依存関係を統合したスケジュールを作成する。

■ スケジュール策定のポイント

• スコープとの整合性: スコープ（やるべきことの全体量）とスケジュールに整合性があるか確認する。
• リソースと稼働率の考慮: 人員や設備などのリソース、およびその稼働率を考慮し、無理のない計画を立てる。
• バッファの設定: 予期せぬリスクに備え、スケジュールに余裕（バッファ）を持たせる。一般的に、スケジュール全体の3%程度が推奨される。
• ステークホルダーのレビューと承認: 関係者からのレビューと承認を得て、スケジュールをベースラインとして確定する。
• アジャイルにおけるスケジュール管理:
  • ウォーターフォールモデルのように最初に詳細なスコープを定義するのではなく、プロダクトビジョンといった大きなスコープを設定する。
  • リリース時期の目標に向け、スプリント（決められた短い期間）ごとに計画を柔軟に策定・実行する。
  • スケジュールのベースラインは作らず、状況に応じて柔軟に調整する。

■ 実行

• 目的: 計画されたスケジュールに沿って作業を進行させる。
• 実施事項:
  • 進捗確認: 計画に沿って作業が行われているか確認する。
  • 作業指示: 各アクティビティを担当者に明確に割り当て、開始・完了時期を共有する。

■ 監視・コントロール

• 目的: 進捗を監視し、必要に応じて修正・調整する。
• 実施事項:
  • 1. 定量的管理: スケジュールのベースラインと現状の進捗を常に比較し、定量的に把握する。
    • EVM（Earned Value Management）: 出来高を数値化して管理する手法である。計画された出来高（Planned Value）と実際に得られた出来高（Earned Value）を比較することで、進捗の遅れや進み具合を客観的に判断できる。
  • 2. 逸脱への是正措置: 遅延が検知された場合、リソースの追加、作業順序の変更、スコープの削減など、是正措置をタイムリーに実行する。
  • 3. ステークホルダーへの合意形成: スケジュール変更が発生した場合、そのインパクトを関係者に説明し、合意を得る。合意された変更は、新たなベースラインとして設定・周知する。

■ 終結

• 目的: プロジェクトがスケジュール通りに完了したかを確認し、正式にクローズする。
• 実施事項:
  • 完了確認: 当初のスケジュール通りに完了したかを確認する。

(2025/09/21)

【プロジェクト管理】なぜあなたのプロジェクトはいつも遅れてしまうのか？

• 【プロジェクト管理】なぜあなたのプロジェクトはいつも遅れてしまうのか？ - YouTube

要約:

■ 1. スコープ（作業範囲）の曖昧さ

• 原因:
  • 作業範囲の未定義: プロジェクト開始時に「何を作るか」が明確になっていない。
  • 追加作業の発生: 要件確認の段階で、当初の想定外の作業（業務フロー作成、システム選定、役員向け資料作成など）が次々と追加される。
• 対策:
  • アウトプットの定義: 最終的に「何を作るか」を事前に明確にする。
  • WBS（Work Breakdown Structure）の活用: WBSはスケジュールのツールと思われがちだが、本来は作業範囲（スコープ）を定義するためのツールである。これに記載されていないアウトプットは作成しない、という合意を形成する。
  • 成果物定義の具体化: 「要件定義書」のような曖昧な成果物ではなく、「業務フロー」「要件一覧」など、より詳細な要素で定義する。

■ 2. スケジュール作成のスキル不足

• 原因:
  • 経験不足: 作業ステップや工数（かかる時間）が分からず、感覚的に計画を立ててしまう。
  • 楽観的な見積もり: 実作業にかかる時間を過小評価し、無理なスケジュールを作成する。
• 対策:
  • 過去データ・有識者の知見活用: 過去のプロジェクトデータや経験者からの意見を参考に、見積もりの精度を高める。
  • 計画段階でのレビュー: 期間に合わせるような辻褄合わせの計画ではなく、現実的なスケジュールになっているか、入念にレビューする。

■ 3. 関係者への配慮不足

• 原因:
  • 自社作業のみの計画: 顧客や他チームなど、利害関係者の状況を考慮せずにスケジュールを立てる。
  • 認識のずれ: 相手側のレビューや確認にかかる時間が考慮されていないため、後から大幅な遅延が発生する。
• 対策:
  • 巻き込み時期の考慮: 相手側の繁忙期や都合を事前に確認し、いつ、どれくらいの時間を取ってもらう必要があるかを計画に盛り込む。
  • リスクの考慮: 依頼した作業がスケジュール通りに進まない可能性を考慮し、バッファ（余裕時間）を設ける。

■ 4. 遅延の認識不足

• 原因:
  • 進捗管理の不足: 作業量を定量的に把握しておらず、漠然と「順調」と判断している。
  • 比較対象の欠如: そもそも具体的な予定を立てていないため、進捗が「遅れている」という事実を把握できない。
• 対策:
  • 作業内容の定量化: 「完了すべき作業数」や「作業ステップ数」など、客観的に数えられる単位で進捗を管理する。
  • 予定と実績の管理: 具体的な数値で立てた予定と、実際の進捗を比較し、遅れを早期に認識する。

■ 5. 遅れをごまかそうとする行動

• 原因:
  • 報告への抵抗感: 遅れていることを報告しづらいため、スケジュールをサイレント修正したり、先行着手タスクやバッファを理由に遅れを隠蔽する。
• 対策:
  • クリティカルシンキングの活用: 報告が事実に基づいているか、疑いの目を持って確認する。
  • 目的の共有: 進捗報告の目的は、遅れのリスクを早期に発見し、対策を打つことであることを、チーム全体で共有する。

■ 6. コミュニケーション不足

• 原因:
  • 利害関係者への遠慮: 顧客などへの依頼に遠慮が生じ、調整が後回しになる。
  • フォローアップ不足: 依頼した作業の進捗を適切にフォローアップしないため、気づかないうちに遅延が発生する。
• 対策:
  • プロジェクトの一体感形成: 依頼された作業を「やらされ感」ではなく、主体的に取り組んでもらえるように配慮する。
  • 目的と期日の共有: 依頼する際は、その作業の目的と期日を必ずセットで伝える。
  • 頻繁なコミュニケーション: 定期的なフォローアップを行い、進捗や課題を共有する。

(2025/09/21)

なぜあのマネージャーはプロジェクト管理ができないのか？－最低限知っておくべきプロジェクト管理のコツ

• なぜあのマネージャーはプロジェクト管理ができないのか？－最低限知っておくべきプロジェクト管理のコツ - YouTube

要約:

■ 1. 計画段階での失敗

• スコープの曖昧さ: プロジェクトの作業範囲を明確にせずに開始する。
  • 問題点: どこまでやるのかという境界線が不明確なため、後から理不尽な作業が追加され、チームが混乱する。
  • 対策:
    • WBS (Work Breakdown Structure) の活用: WBSを使って、プロジェクトの作業を階層的に細分化する。
    • 成果物の明確化: 各作業がどのような成果物（アウトプット）を生み出すのかを明確にする。
    • 想定の明記: 未確定な要素については、その前提や作成根拠を備考欄などに記載する。
    • 合意形成: チームや顧客と作業範囲について合意を得ておく。

■ 2. スケジュールの見積もり不足

• 楽観的な見積もり: 実際にかかる時間よりも短い期間で作業を見積もってしまう。
  • 問題点:
    • 見え方と実作業のギャップ: 「関係者に確認するだけ」のように、一見簡単に見える作業も、実際には多くの付随作業（調整、資料作成など）が発生する。
    • 担当者とのギャップ: 担当者のスキルや現在の状況（並行して抱えているタスクなど）を考慮せず、非現実的なスケジュールを立ててしまう。
  • 対策:
    • バッファの設定: 担当者のスキルや状況に応じて、余裕を持たせたスケジュールを設定する。

■ 3. 実行段階での失敗

• 根拠のない状況管理: 定量的な根拠のない進捗報告を行う。
  • 問題点: 「だいたい7割」といった感覚的な報告では、正確な状況を把握できない。
  • 対策:
    • 分母・分子の明確化: 作業状況を、完了したタスク数やページ数など、客観的に数えられる単位で管理する。
    • 定量的報告の徹底: 「16個中12個完了で75%」のように、根拠を説明できる形で進捗を報告する。

■ 4. マネージャーの視野の狭さ

• リスクの見逃し: 自分の作業に忙殺され、プロジェクト全体のリスクを見過ごしてしまう。
  • 問題点: 小さな問題の兆候を早期に発見できず、問題が大きくなってから対応に追われる「後手後手」の対応となり、手遅れになる。
  • 対策:
    • リスクマネジメント: プロジェクト全体のリスクを常に監視し、兆候を早期に察知する。
    • 早期対応: 小さな火種のうちに手を打ち、メンバーが疲弊するのを防ぐ。
    • 心に余裕を持つ: 視野を広く保ち、客観的に全体を把握する。

■ 結論

• プロジェクト管理ができないマネージャーは、計画や実行段階で「曖昧さ」を放置している。
• メリハリのある管理が必要である。締めるところはしっかり締め、プロジェクトの成功とメンバーの負担軽減の両立を目指す必要がある。
• 本稿で挙げられた4つの失敗例以外にも、プロジェクトを効率的に管理するための要素は多数存在する。

(2025/09/21)

プロジェクトリスク検知のヒント

• プロジェクトリスク検知のヒント | DevelopersIO

■ 1.システム化の目的が明確でない

• リスク事象：要件の増大、もしくは絞り込みの不全が発生し、プロジェクトが統制できなくなる
• 把握観点
• システム化の目的が文書化されているか
• 定量的な達成指標が文書化されているか

■ 2. 現行機能の調査・確認が不足している

• リスク事象：受け入れテスト時に不具合指摘が多発しプロジェクトの中断または大量の仕様変更が発生してコストが超過する
• 把握観点
• 業務要求と現行システムの関係を説明できるメンバーの有無
• 現行システムの設計書が最新化されているか
• 要件定義書に「現行どおり」という記載があるか

■ 3. 現行システムとそのドキュメントが整合していない

• リスク事象：現行システムから引き継ぐべき要件に漏れが発生する
• 把握観点
• 現行システムに関する各種ドキュメントが存在するか
• サンプルチェックによる網羅性・整合性の度合いが一定以上か

■ 4. パッケージ選定に関する検討が十分でない

• リスク事象：機能の要求を満たせないことや性能が出ないことにより、大きな手戻りが発生し稼働不能になる
• 把握観点
• 選定における機能条件、非機能条件、運用条件が明確に文書化されているか
• 検討経緯が明確か

■ 5. 性能の検討が十分でない

• リスク事象：利用に供する性能が出ないため、稼働不能や大規模改修に繋がる
• 把握観点
• 性能見積りの前提となるデータ量に関する資料の有無
• 実装過程における性能に関する進め方について、妥当性があるか

■ 6. 可用性の検討が十分でない

• リスク事象：安定稼働の保証がないため、稼働不能や大規模改修に繋がる
• 把握観点
• 目標とする稼働率、可用性確保の方式が明確か
• 稼働率の見積り方法は妥当か

■ 7. 運用要件の検討が十分でない

• リスク事象：実現できない、矛盾を含んだ要求仕様ができる（運用要件）
• 把握観点
• システム運用関連の検討が行われているか
• システム運用関連の成果物の作成が計画されているか

■ 8. 運用に向けての制約条件が明確でない

• リスク事象：期待された業務運用ができない
• 把握観点
• 運用担当者によるレビューが行われているか
• 業務視点でのウォークスルー、テストが計画されているか

■ 9. 要件を獲得すべきステークホルダーが網羅されていない

• リスク事象：要件の漏れが発生する（後になってステークホルダーから指摘される）
• 把握観点
• ステークホルダーのリストの有無
• ステークホルダー全員にヒアリングを実施しているか

■ 10. システム部門による要件とりまとめが十分でない

• リスク事象：要件がいつまでも確定しない、あるいは要件が想定以上に膨らむ
• 把握観点
• 要件の引き出しプロセスが明確になっているか
• 要件のとりまとめ様式が定義されているか

■ 11. ドキュメントの更新が管理されていない

• リスク事象：追加・改修開発時に、現行システムから引き継ぐべき要件に漏れが発生する
• 把握観点
• 変更管理手順が規定され、実践されているか
• 要件変更・ソースコード修正時にドキュメント修正およびレビューを実施しているか

■ 12. 仕様の変更管理ができていない

• リスク事象：規模の肥大化、費用に関するPJ の目標未達
• 把握観点
• 仕様変更一覧の有無
• 仕様変更に仕組み（フロー、会議体）が規定されているか

■ 13. ユーザーによる仕様の確認が十分でない

• リスク事象：要件の漏れや認識の齟齬が生じる
• 把握観点
• 現場ユーザによるドキュメントレビューが適切に行われているか
• 要件定義完了時点でステアリングコミッティが開催されたか

■ 14. 要求の優先度が曖昧になっている

• リスク事象：開発規模が膨張する
• 把握観点
• 要求に優先度付けを実施しているか
• 要求の優先度をお客様に確認しているか

■ 15. 業務要件の網羅性が検証できない

• リスク事象：画面、帳票等の形式的、定型的な情報はあるが、業務の全体にわたる要件や要望、今後の展望などがあいまいになる
• 把握観点
• 現行の画面や帳票以外から業務要件を把握するための人的な体制が準備されているか
• 業務視点でのウォークスルーがスケジュールされているか

■ 16. 設計と実業務の整合性が検証できていない

• リスク事象：業務に合わない情報システムになる（要件定義に漏れが発生する）
• 把握観点
• 業務面と情報システム面の双方から点検（ウォークスルー）し、業務に対する機能の解釈の誤りの有無について確認しているか

■ 17. 経営層によるプロジェクト運営の関与が十分でない

• リスク事象：要件定義を始めとする工程の節目や重要な意思決定場面で、優先順位やリソース配分に対する方向性が決まらないため、プロジェクトの意思決定が誤ったものとなる
• 把握観点
• プロジェクト憲章が作成されているか／承認されているか
• 経営層がプロジェクトに対し月次報告などを要求しているか

■ 18. 経営層によるスコープ決定への関与が十分でない

• リスク事象：調整の不調による費用の膨張や要件定義の誤り
• 把握観点
• 要件の変更時に、及ぼす影響に応じた責任者の承認を得るルールが存在するか

■ 19. 経営層がパッケージ導入の意図・目的を明示していない

• リスク事象：パッケージ導入でカスタマイズ仕様が膨張する
• 把握観点
• パッケージの採用方針（導入意図や、現行業務維持方針など）について、プロジェクト企画書などの公式文書に記載しているか
• カスタマイズに関する制約条件（コストや工数の上限など）について、プロジェクト企画書などの公式文書に記載しているか

■ 20. ステークホルダー間の力関係がアンバランスである

• リスク事象：全体最適が実現しないことによるQCD の乱れ
• 把握観点
• 納期折衝・スコープ調整の余地がない
• 異なる役割を持つステークホルダー間で指導・統括・評価関係がある

■ 21. 高次の調整・決定機関が機能していない

• リスク事象：重要事項の決定が遅れたり、調整できなかったりする
• 把握観点
• ステアリングコミッティにあたる機構が存在しない
• ステアリングコミッティの開催要件(定期開催サイクル、開催条件など)が定義されていない

■ 22. 十分なコミュニケーションがとれていない

• リスク事象：作業効率の悪化により工程の進捗が遅れる
• 把握観点
• 会議体が定義されているか
• 課題管理とエスカレーションに関するルールが規定されているか

■ 23. 業務用語が共有されていない

• リスク事象：要件定義・設計上の誤謬による手戻りや品質問題が発生する
• 把握観点
• （開発者向け）業務用語に関する注釈付きドキュメントの有無
• （ユーザ向け）システム用語に関する注釈付きドキュメントの有無

■ 24. 業務知識が不足している

• リスク事象：仕様変更、仕様追加の多発により、サービス開始の遅れや品質の極端な悪化を招く
• 把握観点
• ユーザ側：キーマンが明確であるか／要件定義に参画しているか
• ベンダー側：現行業務を現場レベルで調査しているか

(2025/09/21)

「いつ終わる？」からの卒業 - 確率で納期を見える化する新しい開発計画法-

• 「いつ終わる？」からの卒業 - 確率で納期を見える化する新しい開発計画法-

要約:

■ 1. プロジェクト管理の課題と確率的予測の利点

• 確定的な納期の困難さ: ソフトウェア開発において、要件変更や技術的な問題など、予測不可能な要素が多いため、確定的な納期を提示することは難しい。
• 確率的予測の導入: 「いつ終わるか」という単一の納期ではなく、「この時期までに終わる確率」で考えるべきである。
• リスク共有と対応: 確率的な予測を用いることで、事前にリスクを関係者と共有し、遅延した場合の対処法を検討できる。

■ 2. 計画の明確化と視点の転換

• 3つの概念の分離:
  • 見積もり（Estimate）: エンジニアの個人的な「予想」であり、約束ではない。
  • コミットメント（Commitment）: チームが「達成する」と合意したライン。
  • ターゲット（Target）: ビジネス上の「必達目標」であり、最も厳格な期限。
• 「タスク中心」から「リスク中心」へ: 単にタスクを積み上げて計画を立てるのではなく、起こりうるリスクを考慮に入れることで、より現実的なスケジュールを作成できる。

■ 3. 予測精度向上のための手法

• リスクチェックリスト: 「要件の曖昧さ」や「情報共有不足」といったリスク要因をリストアップし、不確実性を可視化する。
• 過去の実績からの学習: アジャイル開発のスプリントを繰り返し、過去の作業実績データ（ベロシティ）を蓄積することで、将来の予測精度を高められる。
• ベロシティの安定化: チームの作業ペース（ベロシティ）を安定させることで、予測の信頼性を向上できる。
• スコープクリープの管理: 開発中の要件追加（スコープクリープ）を事前に見込むか、その発生を抑制するルールを設けることで、計画のブレを抑えられる。

■ 4. モンテカルロシミュレーションの活用

• 不確実性の考慮: モンテカルロシミュレーションを用いることで、不確実な要素を考慮した多数のシナリオをコンピュータ上で試行し、確率的な予測を算出できる。
• 直感的な理解: この手法により、「50%の確率でこの時期までに終わる」といった予測がグラフなどで可視化され、専門家でなくても直感的に理解できる。
• 共通認識の形成: シミュレーション結果を共有することで、関係者全員がプロジェクトの現実的な状況を把握し、納得のいく計画を立てられる。

■ 5. 結論

• リスクの可視化: ソフトウェア開発における不確実性は避けられないが、確率的なアプローチでリスクを可視化し、計画に組み込むことが重要である。
• 予測の正確性向上: ベロシティの安定とスコープクリープの管理により、予測はさらに正確になる。
• 共通理解の促進: モンテカルロシミュレーションなどのツールを使って結果を視覚化することで、ステークホルダー間の共通理解が促進され、現実的な計画運営が可能となる。

(2025/09/21)

プロジェクトマネジメント、タスクから見るかリスクから見るか。

• プロジェクトマネジメント、タスクから見るかリスクから見るか。

要約:

■ 1. プロジェクト管理の一般的な誤解

• タスク中心のアプローチ: プロジェクト管理は、タスクを洗い出し、スケジュールを綿密に組むことだという誤解がある。
• 不確実性への対応不足: 実際には、要件変更や予期せぬ問題など、不確実な要素が常に発生する。タスク消化だけを指標にすると、リスクの兆候が見過ごされ、問題が顕在化した際に手遅れになることが多い。
• 負のスパイラル: チームは過度なプレッシャーに晒され、リスクを報告することをためらうようになる。

■ 2. タスク中心とリスク中心の比較

• タスク中心アプローチ:
  • 特徴: WBS（作業分解構成図）やガントチャートといった詳細な計画を重視する。進捗は「タスクの完了」で測る。
  • 課題: 予期せぬ事象を「イレギュラー」として扱い、問題が顕在化してから後手に回る傾向がある。計画からの逸脱に抵抗感がある。
• リスク中心アプローチ:
  • 特徴: プロジェクトの初期段階から、達成を妨げる潜在的なリスク要因を徹底的に洗い出す。
  • 強み: スケジュールは常に最新の情報に基づいて調整され、リスクの状況に応じてタスクの優先順位を柔軟に変更する。進捗は「リスクの顕在化状況」や「新たな問題の発見」によって評価される。
  • 根本的な違い:
    • タスク中心は「どれだけ計画通りに作業を消化したか」に焦点を当てる。
    • リスク中心は「計画を脅かす要因をどれだけ早く発見し対処できたか」に焦点を当てる。

■ 3. リスクの性質と分布

• 掛け算的に増殖する脅威: プロジェクトにおけるリスクは、単独で作用するのではなく、連鎖的に影響を及ぼし、問題が「掛け算的」に拡大する性質がある。
• 対数正規分布: プロジェクトの所要期間は、対数正規分布に近い形を示す。これは、発生確率は低いものの、極めて大きな遅延が発生しうることを示唆する。

■ 4. リスク管理の具体的な手法

• 早期警報システム: リスクを早期に捉え、先手を打つことが重要である。
• IPAのリスク事象ドライバー: IPA（情報処理推進機構）が公開する「ITプロジェクトのリスク予防への実践的アプローチ」では、問題発生の前触れとなる24種類のリスク事象ドライバーが提示されている。これをチェックリストとして活用し、潜在的なリスクを客観的に洗い出すことができる。
• 心理的安全性: チームメンバーが、失敗や懸念を安心して発言できる状態。リスクを早期に発見するためには、この心理的安全性が不可欠である。
  • 実践方法: リーダーは、問題提起に対して感謝の意を示し、自らの失敗談を共有するなど、安心して発言できる環境を意識的に構築する。
• リスク＝チャンス: リスクは単に避けるべきものではなく、新たな価値創出や成長の機会となる。リスクを特定し、チームで対処する過程そのものが、チームのスキル向上や結束力強化につながる。

■ 5. 日々の実践へのヒント

• キックオフでのリスク洗い出し: プロジェクト開始時に、チーム全員でリスクをリストアップし、担当者と対応策を明確にする。
• 定例ミーティングでの共有: 進捗報告に加え、必ず「リスク・懸念事項」を共有する時間を設ける。
• リスク対策タスクの計画への組み込み: 優先度の高いリスクには、具体的な対策タスクを立て、通常のタスクと同様に計画に含める。
• 振り返りによる学習: プロジェクト完了後やトラブル収束後に、リスクへの対応を振り返り、得られた知見を組織のナレッジとして蓄積する。

(2025/09/21)

最近の人類のレビュー疲れ

• 最近の人類のレビュー疲れ | Democratizing Data

要約:

■ 1. レビュー疲れの背景と課題

• レビュー時間の急増: LLMの普及により、コードやドキュメントのアウトプット量と速度が大幅に増加した。しかし、必ずしも質が向上しているわけではなく、レビューに要する時間と疲労が増加している。
• 「他人を経由したプロンプティング」: 知識がないままLLMに生成を任せ、その結果をレビュー側に丸投げするケースが多い。レビュー側は、生成側より知識をつけた上でレビューする必要があり、非効率である。
• 自己レビューの欠如: 生成されたものを自己レビューしない、あるいはレビューしても見落とすケースが多発している。これは、自分の手で書いたコードではないため脳内キャッシュに乗らず、理解が追いつかないことが原因である。
• クソデカコミットの問題: LLMが試行錯誤を繰り返し、大きな単位でコードを上書きするため、既存の設計を無視した巨大なコミットが生まれやすい。適切なタスク単位への切り出しが困難である。
• インセンティブ構造の不一致: 生成側はLLMの利用でスループットを最大化しようとするが、レビュー側は質を担保する必要があり、レビューの速度は向上していない。このインセンティブ構造の違いが、レビュー疲れの主原因である。

■ 2. 対策と試行錯誤

• コーディングレビューでの対策:
  • 1. 自己レビューの徹底: 生成したコードをGitHub上で他人のコードとしてレビューし、レビュアーとしてのマインドセットに切り替える。
  • 2. ドキュメントドリブン開発: 要件定義、外部設計、作業計画書などをドキュメントとして実装と一緒にコミットする。これにより、コミットが大きくても意図が理解しやすくなり、不毛な議論を回避できる。
• 文章レビューでの対策:
  • LLMが生成した文章をそのまま提出する人に対しては、LLMにエスカレーションの文言を作成させ、適宜マネージャーに報告することが有効である。

■ 3. 結論

• LLMの限界は人間の限界: LLMの能力はそれを使う人間の能力に規定される。
• 今後の展望: LLMを最大限に活用するためには、人間が主導してワークフローを構築し、LLMの限界を補完していく必要がある。現状はまだ手探りの状態が続いている。

(2025/09/20)

「複雑な業務ロジック」が読みづらいのは「記述が分散」しているから

• 「複雑な業務ロジック」が読みづらいのは「記述が分散」しているから #設計ノウハウ - Qiita

要約:

■ 1. 移行前のシステムが抱える問題

• 根本原因: 業務ロジック自体は単純であるにもかかわらず、全体の見通しが悪く、運用が困難な状態にあった。
• 複雑さの正体: 問題の核心は、業務ロジックそのものではなく、「前処理」の複雑さである。
• 処理の分散: レガシーシステムとの連携に伴う「値の加工」や「区分値の変換」といった処理が、複数の層に分散して記述されていた。
• 結果の予測困難性: この処理の分散が、「入力に対する結果が予測しづらい」システムという状況を生み出していた。

■ 2. 移行時の対処と成果

• 構成の再整理: 一連の処理を整理し、「業務ロジック（ドメインロジック）」と「前処理（モデル変換装置/腐敗防止層）」の二層構造に再構成した。
• 可読性の向上: 業務ロジックで使用する値に関する処理が「モデル変換装置」に集約された結果、関連処理をシステム全体から探し出す手間がなくなり、可読性が大幅に向上した。
• コード量の削減: 全体的なコード量が驚くほど削減された。

■ 3. 移行作業における課題と考察

• 心理的抵抗: DBやSQLに慣れた開発者にとっては、「データの近くで加工する方が効率的」という感覚があり、処理の分散を避けるための徹底的な集約作業に心理的抵抗があった。
• コード量の逆転: 出来上がったシステムでは、「モデル変換装置」のコード量が「業務ロジック」のコード量を上回った。
• 本質的な複雑さの可視化: このコード量の差は、「データを整える部分」にこそ真の複雑さがあることを示唆している。最も重要な業務ロジックが簡潔に記述されているという結果は、慣れ親しんだシステム設計とは異なるため、違和感として感じられた。

(2025/09/20)

「C# や SQL Server が Linux でも動かせる」というのはそうなんだけど「やろうと思えばできる」と...

「C# や SQL Server が Linux でも動かせる」というのはそうなんだけど「やろうと思えばできる」というのとLinux の上で動かすのが当たり前という物とでは話がちがう 後者なら全ての開発者がそれを前提にエコシステムを組むけど、前者ではそうならない

@naoya_ito

実際、SQL Server に関しては ODBC Driver を Mac にインストールしたりするところで躓く

そういう細かい yak shaving みたいなのがあちこちで発生する

@naoya_ito

Web 系システムのノウハウは、Linux などを中心としたオープンなエコシステムに支えられて蓄積されてきた

だとすれば、そこで動かすのが当たり前の前提になっているプラットフォームに乗っかるのがマクロにみれば最適だということは自明でしょう

○○でもやればできるよ、みたいなのは論点がずれてる

@naoya_ito

PostgreSQL や MySQL を使っていれば何の苦労もないものを、GCP や AWS で SQL Server を使おうとすると細かいところでノウハウが要る、みたいなのは実体験としてあります

基幹データベースは移管が難しいからそれでも SQL Server を使い続けるけど、そうでなければ好き好んでそんな苦労はしたくない

@naoya_ito

それなら Azure を使えばいい、というのはそう

でもその時点で使う物が限定される

そこを限定されてでも Microsoft のプラットフォームに乗っかるかアグノスティックにレイヤーごとに選択肢を豊富にもっていたいか、それは価値観次第だと思います

@naoya_ito

そういう大枠での判断基準で考えるものなので、C# は良い言語だとか、Linux でも動くとかそういう点の議論をしててもしょうがないですよ

@naoya_ito

MEMO:

• 「可能である」ことと「最適である」ことは完全に別問題であるということ
• 「○○なら可能（なお、発生する諸問題は無視するものとする）」という発想はエンジニアとしては3流
• 目先の問題解決に飛びついてしまうのは未熟者

(2025/09/20)

病んだプロジェクトリーダー、そのほとんどが抱えていた問題がコレ。

• 病んだプロジェクトリーダー、そのほとんどが抱えていた問題がコレ。 #ポエム - Qiita

MEMO:

• うーん
• 勝手にサービス残業して勝手に実力以上の仕事を振られて自滅するのは自己責任では？
• そんなところまで上司がケアしないといけないのか？　という感覚がある

(2025/09/19)

経験を積むほどインプット出来ていない感覚になりやすいのではないか

• 経験を積むほどインプット出来ていない感覚になりやすいのではないか - $shibayu36->blog;

MEMO:

• わかる

(2025/09/19)

バッチ設計ガイドラインを公開しました

• バッチ設計ガイドラインを公開しました | フューチャー技術ブログ

(2025/09/19)

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

• ソフトウェア設計の結合バランス　持続可能な成長を支えるモジュール化の原則 - インプレスブックス

結合でシステムの複雑性を管理！

「結合」とは、モジュール設計における基本概念の1つ。モジュール間の相互作用や依存関係の強さを表します。「結合」を適切に管理することで、ソフトウェアシステムの保守性や拡張性、進化性を向上させることができます。その重要性にも関わらず「結合」について深く理解されていないのが実情です。本書では、まず構造化設計やオブジェクト指向設計に用いられてきた「結合」に関するモデルや評価手法を包括的に解説。さらに、複雑性を管理し、モジュール性を高める設計ツールとして「結合」を使用する新たなアプローチを提案します。

MEMO:

• 2025/10/17発売

(2025/09/18)

Goで作る静的解析ツール開発入門

• Goで作る静的解析ツール開発入門

MEMO:

• いつか読むかも

(2025/09/18)

「やりたいこと」はないが「課題解決」自体を楽しめる人　Googleの「優秀なエンジニア」の定義

• 「やりたいこと」はないが「課題解決」自体を楽しめる人　Googleの「優秀なエンジニア」の定義 [1/2] | ログミーBusiness

(2025/09/17)

エージェントのための効果的なツールの作成

• エージェントのための効果的なツールの作成｜npaka

(2025/09/17)

『月姫』『ひぐらし』の時代を築いた、国産ノベルゲームエンジン「NScripter」開発史【フォーカス】

• 『月姫』『ひぐらし』の時代を築いた、国産ノベルゲームエンジン「NScripter」開発史【フォーカス】 | レバテックラボ（レバテックLAB）

要約:

■ 1. NScripter開発の背景と変遷

• 開発の動機: NScripterは、開発者である高橋直樹氏が自身の同人活動でノベルゲームを制作するために、自作のゲームエンジンシリーズ「Scripter」を発展させたものである。
• 簡易な言語仕様: 開発当初から、専門家ではないクリエイターでも扱いやすいように、プログラミング入門の定番であるBASIC言語の文法を参考にしている。これにより、ノベルゲーム制作の敷居を下げた。
• 拡張性の確保: エンジン本体はシンプルに保ちつつ、新しい命令文の追加や、プラグイン（例: 音源や画像形式の対応）による機能拡張を可能にした。
• 時代の要求に応じた進化: 2000年代後半に、ノベルゲームのUIやデータ構造が複雑化。それに伴い、より高度なロジックを扱えるよう、スクリプト言語「Lua」を拡張機能として導入した。
• 後継エンジン「NScripter2」の開発: PCの性能向上と描画速度の限界に対応するため、高速な描画処理が可能な「DirectX」を全面的に採用し、Luaをエンジンの中核に据えた「NScripter2」をゼロから開発した。

■ 2. NScripterの普及と開発者の視点

• 普及の要因:
  • リリース当時は、手軽に使えるゲームエンジンが少なかった。
  • 『月姫』や『ひぐらしのなく頃に』といった人気作品に採用されたことで、多くのクリエイターに存在が知られた。
  • 非商用・同人活動での無料ライセンスモデルがクリエイターの裾野を広げた。
• 開発者のスタンス:
  • 自身が開発したツールが文化に与えた影響については、「純粋に使ってもらえたのがありがたい」と謙虚な姿勢である。
  • ユーザーが使い方を解説するウェブサイトを運営してくれたことに対し、特に感謝している。

■ 3. 現在の活動と今後の展望

• キャリアの変化: 2018年頃にノベルゲーム市場の縮小を感じ、一般企業のプログラマーに転職した。
• 「NScripter3」の開発:
  • 今後も自身がゲーム開発を続けるために、新たな環境を求めて「NScripter3」を開発中である。
  • これまでの自作エンジンとは異なり、オープンソースのゲームエンジン「Godot」にLuaのプラグインを組み合わせる設計を考えている。
• 開発のモチベーション: 25年以上続く開発の動機は、一貫して「自分で使うため」である。自分の創作活動が主軸にあり、そのツールを「ついでに」公開するというスタンスを貫いている。
• ジャンルの未来: ノベルゲーム市場は国内で落ち着いたものの、Steamでのインディーゲームのヒット事例があることから、今後も魅力的なジャンルであり続けると期待している。

(2025/09/16)

″仕様駆動開発″というプロンプトを外付けするSpec Kit

• ″仕様駆動開発″というプロンプトを外付けするSpec Kit

(2025/09/16)

ADR実践で目指す技術的卓越：『要はバランス』を見極める力を鍛える

• ADR実践で目指す技術的卓越：『要はバランス』を見極める力を鍛える - Cybozu Inside Out | サイボウズエンジニアのブログ

要約:

■ 1. ADRの概要と重要性

• ADR（Architectural Decision Record）とは: ソフトウェアアーキテクチャの重要な決定を記録する文書である。単なる設計書ではなく、なぜその決定がなされたのかという理由に焦点を当てる。
• ADRの利点:
  • 意思決定の質が向上し、学習効果が高まる。
  • 意思決定の妥当性に自信を持ち、チームメンバーに説明しやすくなる。
  • 開発組織の大規模化や生成AIの進化により、ドキュメントの重要性が高まっている。
• 生成AIの限界: 現在の生成AIは、コードベースに残らない「意思決定の理由」や「検討された別の選択肢」を創造できないため、ADRの作成には不向きである。

■ 2. ADRに記載すべき内容とアンチパターン

• 記述すべきタイミング: トレードオフを伴う重要な意思決定が必要な時に書くべきである。
• 主な目的:
  • 意思決定の経緯や背景を正確に理解すること。
  • 意思決定の妥当性に自信を持つこと。
  • 将来の振り返りに役立てること。
• 記述すべき項目:
  • 意思決定が必要になったコンテキスト
  • 各選択肢のトレードオフ
  • 意思決定で重視したポイント
• アンチパターン:
  • 1. 「今必要な理由がわからない」: 意思決定の背景となるコンテキストが不明瞭な場合。
  • 2. 「適切と考える理由がわからない」: 各選択肢のトレードオフを比較せず、決定理由が不明瞭な場合。
  • 3. 「最善の選択肢を生み出そうとする」: 完璧な案を出そうとしてしまい、手が止まる場合。

■ 3. ADR作成の実践的ヒント

• コンテキストの共有: 執筆前に、なぜこの意思決定が必要かをチームとすり合わせることで、手戻りを防ぐ。
• 多様な視点での検討:
  • 「多分違うだろう」と思う選択肢も含め、各案に「肩入れして」考えることで、潜在的なコンテキストや見落としに気づける。
  • 生成AIを活用し、各案の強みを聞いてみることも有効である。
• 批判的思考: 結論を出した後、その決定理由が他の選択肢にも当てはまらないか批判的に考える。
• 表による可視化: トレードオフ分析の結果を表にまとめることで、一覧性が高まり、理解が促進される。

■ 4. ADR実践から得られる効果

• 「手癖」からの脱却: 意思決定の理由を言語化する過程で、自身が無意識に行っていた設計に気づく。
• 過去の意図の理解: 過去に書かれたADRを読むことで、設計の意図を理解し、手戻りを防ぐ。
• 「バランス」を見極める力: コンテキストを分析し、最適な意思決定を下す力が身につく。これは、生成AI時代に最も重要な「技術的卓越性」につながる力である。

(2025/09/15)

根回し入門

• 根回し入門 - Konifar's ZATSU

(2025/09/14)

ベクトル検索だけじゃ足りない？Qdrantで精度を高めるハイブリッド検索

• ベクトル検索だけじゃ足りない？Qdrantで精度を高めるハイブリッド検索 - RAKUS Developers Blog | ラクス エンジニアブログ

(2025/09/13)

品質は、電気羊の夢を見るか？— デカルトの四規則で始める「自動テスト導入前」の品質保証—

• 品質は、電気羊の夢を見るか？— デカルトの四規則で始める「自動テスト導入前」の品質保証— - Speaker Deck

(2025/09/13)

L・トーバルズ氏、うんざりするほど増えた「ゴミリンク」に激怒--開発者を悩ませる問題とは

• L・トーバルズ氏、うんざりするほど増えた「ゴミリンク」に激怒--開発者を悩ませる問題とは - ZDNET Japan

Linuxカーネルのリソースノードのリライトに対する、たった1つの修正がことの発端だった。Linus Torvalds氏は、その修正を見れば見るほど当惑していった。なぜなら、その修正は「実際には何も修正していなかった」からだ。

同氏は「この無意味なコミットの理由を説明してくれることを期待して、『Link:』引数を確認した。しかし、いつものように、そのリンクはすでに存在するくだらない情報を指し示しているだけで、ただ時間を無駄にした」という。

その後、Torvalds氏は「もうこのゴミはやめろ」と語り、Linux Kernel Mailing List（LKML）での議論において、当惑から瞬く間に怒りへと変わった。同氏はさらにこう続ける。「私の最初の反応が間違っている理由を説明してくれるような、何か不具合報告などを指し示していることを期待していた」が、結局は期待外れに終わった。

Torvalds氏は「人の時間を無駄にする無意味なLink引数を追加するのはやめてくれ。“追加”の情報がある場合にのみリンクを追加してほしい」と宣言した。また、「この無意味なリンクは本当に嫌いだ。“役に立つ”リンクは大好きだが、実際に見るリンクの99％は、ただの愚かで役に立たないゴミを指しているだけで、私の時間をただただ無駄にしている。今回もだ！」といら立ちをあらわにした。

要するに、同氏は「もし私にプルすることを本当に期待しているなら、役に立たないリンクではなく、ちゃんとした説明が欲しい」と語っている。さらに、「そうだ、私は機嫌が悪い。私の主な仕事、いや、本当に唯一の仕事はプルリクエストを理解することだと感じており、だからこそ、自動的に追加され、私の仕事をより困難にするだけのこうしたものが、心底嫌いなのだ」と心情を吐露した。

他の人々もTorvalds氏の意見に同意している。あるRedditの投稿者は、「Linusの言うことは一理ある。あの元のパッチはAIが書いた要約のように見えたし、問題の説明へのリンクも同じ要約だった」と述べている。

(2025/09/12)

人工衛星のファームウェアをRustで書く理由

• 人工衛星のファームウェアをRustで書く理由 - Speaker Deck

(2025/09/11)

国産の仕様駆動開発ツール cc-sdd を推していきたい

• 国産の仕様駆動開発ツール cc-sdd を推していきたい

(2025/09/10)

GitHub、仕様駆動開発のワークフローを生成AIで実現するオープンソース「Spec Kit」を公開

• GitHub、仕様駆動開発のワークフローを生成AIで実現するオープンソース「Spec Kit」を公開 － Publickey

仕様駆動開発（Specification-Driven Development）は、まず仕様を明確に作成し、その仕様を基に実装計画を立ててコーディングを行うという開発手法です。

Amazon Web Services（AWS）が7月に発表したコーディング支援ツール「AWS Kiro」がこの手法を採用しており、それがきっかけで注目されるようになりました。

参考：AWSがAIコードエディタ「Kiro」をプレビュー公開、VS Code互換。AIとチャットしながらプロダクトを開発

今回GitHubが公開したSpec Kitは、この仕様駆動開発のワークフローの実行を生成AIが支援してくれる仕組みを備えており、後述するようにGitHub CopilotやClaude Code、Gemini CLIで仕様駆動開発が容易に実現できます。

(2025/09/09)

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

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

要約:

■ 1. PRDの3つの役割

• 成長・評価のツール:
  • PRDを一人で書ききれることが、一人前のプロダクトマネージャー（PM）の分岐点である。
  • 他の職種と対話しながらPRDを完成させることで、PMの企画、開発、検証ワークフローのコントロール能力を判断できる。
  • PRDはPMの育成に活用できる。
• 思考のツール:
  • PRDのフォーマットに沿って企画を考えることで、プロダクトのあるべき姿を再考し、見落としがちな上流工程の事項を押さえられる。
  • PRDは、多様な解決策とトレードオフを記録する装置として有用である。
• コミュニケーションツール:
  • PRDは「指示書」ではなく「対話書」である。
  • 開発スタイルに関わらず、PRDを介して多職種が協働・協業できる。
  • 新規メンバーがキャッチアップするための「知のベースキャンプ」となる。

■ 2. PRDの正しい使い方

• 書き方:
  • パワーポイントやExcelは避け、マークダウン形式で書くべきである。図はMermaidの使用が推奨される。
  • WHATやHOW（要求事項）から書くのは間違いである。
  • WHY（前提条件）やCORE（中心概念）から、他職種と対話しながらPRDを埋めるべきである。
• 構成:
  • デザイン思考のダブルダイヤモンド（発見・定義→解決策提供）に沿ってPRDを作成する。
  • 課題と解決策は1対1ではないため、PRDにはソリューション案の検討過程を残しておくべきである。
  • フローに沿って作成することで、思考の質とPRDの品質が一定に保たれる。

■ 3. AI時代のPRD

• 変わらない価値:
  • 人と人がコラボレーションする限り、PRDは有用である。
  • AIと人との共同作業においても、共通の思考フォーマットとして機能する可能性がある。
  • 意思決定の記録として、人にもAIにもコンテキスト（文脈）を伝えるために有用である。
• プロトタイプとの関係:
  • 良いプロトタイプを作れる人は、PRDを書くのが上手なPMである可能性が高い。
  • プロトタイプ主導の開発を進めるためには、PRDを通じて個人や組織の思考力を鍛えるべきである。
• AIによる効率化:
  • PRDの一次レビューはAIに任せることができる。
  • AIにPRDを書いてもらうことも可能である。この場合、PRDフォーマットの上から順に、AIと対話しながら初稿を作成することが効率的である。

■ 4. 結論

• 未来のPRD: 将来的にPRDの執筆はAIが行うようになるかもしれない。しかし、予算執行を伴う意思決定は人間の役割として残る可能性が高い。
• 人間が磨くべき力:
  • 「PRDをレビューできる力」、すなわち良し悪しを判断する力が重要になる。
  • そのためには、対話力と思考力を鍛えるべきである。
• PRDの役割の再定義: PRDは単なるドキュメントではなく、思考力や対話力を通じて個人や組織を変革するための「道具」として活用すべきである。

(2025/09/08)

若手が生成AI任せで仕事して、レビュー地獄で逆に生産性が落ちた話

• 若手が生成AI任せで仕事して、レビュー地獄で逆に生産性が落ちた話｜片山良平＠paiza代表

要約:

■ 1. 課題の背景と現状

• 問題提起: 生成AIによってジュニアエンジニアが低品質な成果物を大量生産し、シニアエンジニアがそのチェックに工数を割かれ、全体の生産性が低下する事態が発生している。
• 想定外の共感: この問題はITエンジニア業界に限らず、翻訳、法律、教育など、他業界でも同様の課題が見られる。
• 生成AIの性質: 生成AIは「できないことをできるようにする」ツールではなく、「できることをより早くする」ツールである。

■ 2. ジュニアエンジニアが陥る問題点

• 粗悪品の量産: 経験の浅いジュニアエンジニアが生成AIを安易に使うと、非機能要件（可用性、性能、セキュリティなど）や、トレードオフとなる意思決定事項が考慮されない「クソコード」を恐ろしい速度で量産してしまう。
• 非機能要件の考慮不足: 企画側から明示的に伝えられない非機能要件について、ジュニアが考慮せずにプロンプトを書くため、考慮漏れが発生する。
• シニアエンジニアの負担増: ジュニアが量産した低品質な成果物のチェックにシニアエンジニアが追われ、本来の生産的な業務を妨げられる。

■ 3. 解決策と提言

• 思考の転換:
  • 低品質なタスクの効率化: 形式的なメール返信やアイデア出しなど、100%のクオリティを必要としないタスクには生成AIを積極的に活用すべきである。
  • 質と量のバランス: 「100点×1個」ではなく、「80点×100個」の成果が求められる場面を見極めることが重要である。
• ジュニアエンジニアへの提言:
  • ノールックでの提出を避ける: 依頼内容をそのままAIに渡し、完成品として提出するのではなく、AIを相談相手として活用すべきである。
  • 品質向上への注力: 同じ時間を使うのであれば、低品質なものを大量に作るのではなく、「一球入魂」の姿勢で、生成AIを活用しながら一つの成果物の品質を高めるべきである。
  • 能動的な学習: AIを使う過程で、非機能要件やトレードオフといった、自身が不足している知識を補い、学びを深めることが重要である。

(2025/09/07)

エンジニアとして信頼されていないと「全然レビューが通らなくなる」のを遠目で見てる←品質検査として...

• エンジニアとして信頼されていないと「全然レビューが通らなくなる」のを遠目で見てる←品質検査として健全じゃないけど、よくある「負のループ」すぎて辛くなる - Togetter [トゥギャッター]

MEMO:

• それならレビュー工数も含めて作業時間算出するだけでは？

(2025/09/07)

手動テストの「面倒」を解決！Chrome DevToolsで操作を簡易的に自動化しよう！

• 手動テストの「面倒」を解決！Chrome DevToolsで操作を簡易的に自動化しよう！ | DevelopersIO

MEMO:

• Chrome DevToolsのRecorderを用いた簡易的なUI操作自動化

(2025/09/07)

AI開発で著作権侵害訴訟、2千億円支払いへ

• 【速報】AI開発で著作権侵害訴訟、2千億円支払いへ|47NEWS（よんななニュース）

【ニューヨーク共同】生成人工知能（AI）の開発に著作を不正に使われたとして、作家らが米新興企業アンソロピックを訴え、15億ドル（約2200億円）を原告に支払う和解案で合意したことが5日、分かった。

MEMO:

• oh...

(2025/09/07)

JavaScriptランタイムのBunがユニバーサルなデータベースクライアントに。Bun.SQL命令ででMySQL/PosgrerSQL...

• JavaScriptランタイムのBunがユニバーサルなデータベースクライアントに。Bun.SQL命令ででMySQL/PosgrerSQL/SQLiteをサポート － Publickey

JavaScriptランタイム「Bun」の最新バージョンとなる「Bun v1.2.21」がリリースされ、BunがMySQL/PostgreSQL/MySQLを単一のBun.SQL命令でサポートするユニバーサルなデータベースクライアントとなることが示されました。

Bunは、2023年に登場したバージョン1.0の時点でデータベース機能としてSQLiteを内蔵しており、今年（2025年）1月にリリースされたBun 1.2で、MySQLとPostgreSQLのクライアント機能を搭載しています。

本バージョンでBunが備えるデータベースクライアントライブラリのBun.SQL命令が、Bunに内蔵されたSQLiteをサポートしたことで、主要な3つのデータベースに対して単一のBun.SQLが利用可能になりました。

MEMO:

• DBクライアントがランタイム組み込みになるのか
• サーバサイドTypeScriptのランタイムとして見るとメリット大きいかも

(2025/09/06)

Googleが小型の埋め込みモデル「EmbeddingGemma」を発表、メモリ使用量はわずか200MB

• Googleが小型の埋め込みモデル「EmbeddingGemma」を発表、メモリ使用量はわずか200MB - GIGAZINE

(2025/09/05)

AIをシステム開発に活かすコツ、全部書く

• AIをシステム開発に活かすコツ、全部書く｜kmagai

(2025/09/04)

操作より状態・性質に着目する

• 操作より状態・性質に着目する

要約:

■ 1. 操作中心の思考の課題

• 操作中心の思考とは: インプットからアウトプットを計算したり、状態を変更する「操作」（関数定義）から先に考える思考法である。
• 問題点:
  • 抜け・漏れの発生: 最初に最も可能性の高いケースを考え、それ以外の例外的なケースを後回しにする傾向がある。これにより、状態変更の考慮漏れが発生しやすくなる。
  • コードの複雑化: 仕様の「ただし書き」や、考慮漏れを補うためのif文が増え、コードが不必要に複雑になる。
  • 安易な仕様変更: コーディングを楽にするために、不自然な仕様や複雑な状態を生み出すことがある。

■ 2. 状態中心の思考への転換

• 状態中心の思考とは: 操作を考える前に、まず操作の前後で取りうる「状態」や「性質」を定義し、それを可能な限りシンプルに保つ思考法である。
• 実践方法（ユーザー登録の例）:
  • 操作前の状態を定義する: 該当メールアドレスのユーザーが「存在しない」「有効である」「無効である」の3パターンを定義する。
  • 操作後の状態を定義する: 成功した場合、必ず「該当メールアドレスのユーザーが存在し、有効である」という単一の状態を保証する。
• 思考の順序:
  • 1. 操作の前後に成り立ってほしい状態や性質を考える。
  • 2. その状態や性質を満たすには、どのような操作が必要かを考える。

■ 3. 状態中心の思考の適用範囲

• コードレビュー: コードレビューでは、この思考順序がコードに如実に現れる。操作から考える傾向のあるコードは、後から追加されたif文などによって不必要に複雑になっていることが多い。
• 仕様定義: この考え方は、より大きなプロジェクトの仕様定義にも適用できる。
  • ユーザーが抱える課題（事前条件）や、達成したい目標（事後条件）といった「状態」を先に定義する。
  • その「状態」を満たすために必要な機能（操作）を次に考える。
• 問題解決全般: 解決方法（How）を先に考えるのではなく、「どういう状態になったら成功か」という問題を先に理解することで、より本質的な解決策を導き出せる。

■ 4. まとめ

• 思考の習慣の重要性: 多くのエンジニアが意識していないが、美しく堅牢なコードを書くためには「操作」よりも「状態・性質」に注目する習慣が不可欠である。
• 堅牢なコードの基盤: この思考順序で取り組むことで、複雑さを避け、美しく堅牢なコードの土台を築くことができる。

(2025/09/03)

実践アプリケーション設計 ②トランザクションスクリプトへの対応

• 実践アプリケーション設計 ②トランザクションスクリプトへの対応 - Speaker Deck

(2025/09/03)

リスクアセスメント　ーリスクの可視化から意思決定までー

• リスクアセスメント　ーリスクの可視化から意思決定までー | フューチャー技術ブログ

(2025/09/03)

技術書を効果的に内面化する実践技法

• 技術書を効果的に内面化する実践技法 - Speaker Deck

(2025/09/03)

実践アプリケーション設計 ①データモデルとドメインモデル

• 実践アプリケーション設計 ①データモデルとドメインモデル - Speaker Deck

(2025/09/03)

ソフトウェア エンジニアとしての 姿勢と心構え

• ソフトウェア エンジニアとしての 姿勢と心構え - Speaker Deck

(2025/09/02)