/note/tech

なぜ優秀なエンジニアほど「データ構造」から考えるのか

• なぜ優秀なエンジニアほど「データ構造」から考えるのか｜たろ🐻‍❄️

要約:

■ 1. 壊れやすいコードの共通点

• 実務でコードを書いているとこの処理どこから手をつければいいんだろうと立ち止まる瞬間に何度も出会う
• 少し仕様が変わっただけで影響範囲が読めなくなる
• 1つ修正すると思わぬ別の場所が壊れる
• 自分では丁寧に書いているつもりなのにどんどん扱いづらくなっていく
• 壊れやすいコードの共通点はデータ構造が曖昧なまま実装に入っていること
• 優秀なエンジニアほどコードを書く前にまず扱うデータをどう設計するかに時間を使う
• これはセンスではなく壊れにくいシステムを作るうえでの再現性のあるプロセス

■ 2. データから考えると壊れにくくなる理由

• コードが壊れる原因は処理が複雑だからではない
• 多くの場合扱うデータが曖昧なまま実装が進んでしまっていることが本質的な原因
• 処理から考え始めると次のような問題が起きやすくなる:
  • 想定外の値が混ざる
  • null/undefinedが途中で暴れる
  • 状態管理がif文に散らばる
• これは本来コードを書く前に決めておくべき前提条件がコードの外に残ったままになっている状態
• この前提の漏れが仕様変更のたびに壊れる構造を生む

■ 3. データを先に設計する利点

• データを先に設計しておくと以下が明確になる:
  • 何が入力なのか
  • 何が正常な状態なのか
  • 何が起きると不整合になるのか
• 実装に一貫した軸が生まれる

■ 4. 情報ではなく状態をデータとみなす

• 多くの人はデータ=文字や数値と捉えるが実務で重要なのは状態
• 状態の例:
  • ログイン前/ログイン後
  • 未読/既読
  • 有効/無効
  • 下書き/公開
• これらはUIのラベルではなくアプリケーションが保証すべき前提そのもの
• 状態が曖昧なまま実装するとif文が散らばり仕様変更のたびに壊れる

■ 5. 値だけでなく関係もデータ構造に含める

• データ設計で見落とされがちなのは関係性
• 関係性の例:
  • ユーザーと組織
  • 記事とコメント
  • 予約枠と担当者
  • 商品と在庫
• 関係性が曖昧なまま実装するとこのデータどれと紐づいてるんだっけという混乱が必ず発生
• 関係はおまけではなくデータ構造そのものの中心

■ 6. 仕様に書かれていない前提をデータ化する

• 実務には仕様書に書かれていない重要な前提が必ず存在
• 前提の例:
  • ユーザーは1つの組織にしか所属できない
  • 予約は担当者×サービス×日時で一意になる
  • メッセージの編集履歴は削除後も保持する
• こうした暗黙にされているかもしれない前提をデータに落とし込まないと機能がその前提に依存していたときに壊れるという事故が起きる
• 優秀なエンジニアほど仕様に書かれていない前提を発掘してデータとして扱うという工程を怠らない

■ 7. 自然言語で書ける重要性

• 最初からER図やクラス図を書く必要はない
• まずやるべきなのは扱う状態や前提を自然言語で説明できるようにすること
• 例:
  • ユーザーは複数組織に所属できるがデフォルト組織は1つ
  • 予約は日時・担当者・サービスの3つが揃って成立する
  • メッセージ編集は可能だが履歴は別レコードで保持する
• 自然言語で曖昧ならコードではもっと曖昧になる

■ 8. Step1 自然言語で状態関係前提を列挙する

• まずはコードから離れて自然言語で現在の仕様を洗い出すところから始める
• 例:
  • 予約は日時×担当者×サービスで構成される
  • ユーザーは複数組織に所属できるがデフォルト組織は1つ
  • メッセージ編集は可能だが履歴は残す
• 曖昧な表現でも構わない
• 最初は全体像を漏れなく書き出すことが大事

■ 9. Step2 同じ概念をまとめ不要な状態を削る

• 洗い出した状態や関係を見直し以下を判断して整理:
  • 本当にアプリが管理すべき状態はどれか
  • UIの名前ではなく構造として必要な状態はどれか
• 状態は多ければ多いほど壊れやすくなるため削る工程こそ設計の核心

■ 10. Step3 変化する状態と変化しない状態を分ける

• どの値が変化しどの値が不変かを明確にする
• 例:
  • 予約の作成日時は不変
  • 予約のステータスは可変
  • ユーザーIDは不変
  • メールアドレスは可変
• この境界線を引くだけで更新ロジックのバグが激減

■ 11. Step4 状態遷移を書く

• 状態が整理できたらどの状態からどの状態に遷移できるかを明文化
• 例:
  • draft → reserved → completed
  • draft → canceled
  • reserved → canceled
• これにより以下がすぐに可視化される:
  • 到達しない状態
  • 不正遷移
  • 不整合の原因

■ 12. Step5 データ構造として定義する

• 整理した情報を型・スキーマ・ER図に落とし込む
• 具体的な手段:
  • TypeScriptの型
  • Prisma schema
  • Rustのstruct + enum
  • Swiftのstruct/enum
  • DBのテーブル定義
• 状態・前提・関係が整理されているのでここから先の実装は驚くほどスムーズ

■ 13. データ構造設計の重要性

• データ構造の設計は実装の前作業ではなく実装を壊れにくくするための中心工程
• 重要なポイント:
  • 曖昧なまま書き始めるほど壊れやすくなる
  • データが明確なら処理は自然とシンプルになる
  • 状態・関係・前提が揃えば仕様変更に強くなる
• 優秀なエンジニアがデータ構造を先に決めるのはセンスではなく後の開発すべてを安定させる最もコスパの良い投資だから

(2025/12/23)

DB設計から見直すNext.jsのパフォーマンス最適化。フロントエンドエンジニア必読の3冊

• DB設計から見直すNext.jsのパフォーマンス最適化。フロントエンドエンジニア必読の3冊 | レバテックラボ（レバテックLAB）

(2025/12/23)

なぜ、ソフトウェア業界はハードウェア業界と違って量産による品質向上がまるで働かないのか？

• なぜ、ソフトウェア業界はハードウェア業界と違って量産による品質向上がまるで働かないのか？

MEMO:

• ソフトウェアにおける「製造」はコンパイラが実行バイナリを生成することだから、というのは有名な話である

(2025/12/22)

2026年、日本のソフトウェア開発を変える5つの潮流

• 2026年、日本のソフトウェア開発を変える5つの潮流 | gihyo.jp

(2025/12/22)

イベントソーシングから学ぶ、削除をドメインの言葉で表現する設計

• イベントソーシングから学ぶ、削除をドメインの言葉で表現する設計

(2025/12/22)

Transparent Leadership Beats Servant Leadership

• Transparent Leadership Beats Servant Leadership

要約:

■ 1. マネジメント経験と違和感

• 筆者は数年間チームマネジメントを経験しどうすれば良いマネージャーになれるか模索した
• サーバントリーダーシップについて多くを読んだがしっくりこなかった
• サーバントリーダーシップはカーリングペアレンティングに似ている
• リーダーや親が問題を予測し直属の部下や子供のために道を掃き清める

■ 2. サーバントリーダーシップの問題点

• 直属の部下や子供にとっては最初は非常に良い感じがする
• サーバントリーダーやカーリングペアレントはすぐに過重労働の単一障害点になる
• リーダーが去ると誰もリーダーが取り除いた障害への対処方法を知らない
• 最悪のケースでは組織の他の部分から完全に隔離された人々のグループを残す
• 彼らは自分たちの目的が何であるか世界の他の部分とどう適合するかの概念を持たない

■ 3. トランスペアレントリーダーシップの提唱

• 筆者は独自の造語としてトランスペアレントリーダーシップを提案
• 良いリーダーの行動:
  • 人々をコーチする
  • 人々を繋げる
  • 人々に体系的な問題解決を教える
  • 組織が受け入れている価値観と原則を説明し自分で整合性のある意思決定ができるよう支援する
  • 需要と供給の間に直接的なリンクを作る
  • 直属の部下にリーダーシップの責任を徐々に引き継がせることでキャリア成長を可能にする
  • 継続的に自分の後継者を訓練する
  • 一般的に自分自身を不要にする

■ 4. 中間管理職の理想像

• 有用な仕事を何も行わない中間管理職は面白いステレオタイプだが良い目標でもある
• 違いは自分を不要にした後に何をするかにある
• よくある反応は新しい仕事を発明しステータスレポートを要求し官僚主義を追加すること
• より良い反応は技術的な問題に取り組む作業に戻ること
• これによりマネージャーのスキルが新鮮に保たれ部下からより多くの尊敬を得られる
• マネージャーは書類整理係ではなく高性能な予備作業員になるべき

■ 5. サーバントリーダーシップへの批判に対する反論

• この記事はサーバントリーダーシップを誤って表現していると批判を受けた
• 批判者は真のサーバントリーダーはサーバントに期待されることをせず代わりにトランスペアレントリーダーのように行動すると主張
• サーバントリーダーシップという言葉の起源であるグリーンリーフはリーダーに仕える人々が以下のようになるべきだと強調:
  • より健康的により賢明により自由により自律的により自分自身がサーバントになる可能性が高くなる
• 筆者は真のサーバントリーダーシップには反対していない

■ 6. 実践におけるサーバントリーダーシップの問題

• 筆者が反対しているのは実践で起こっているように見えるサーバントリーダーシップ
• マネージャーが退屈で難しい部分を行うことで部下が自分の仕事に集中できるようにする
• これはテイラー主義的な方法で狭く定義されている
• 真のサーバントリーダーシップは実質的にトランスペアレントリーダーシップと同じ
• 真のサーバントリーダーシップを勉強しない人々はサーバントリーダーがサーバントのように行動すべきだという誤った考えを持つ

(2025/12/21)

MS Teamsが障害でダウン中　AIがコードを書いてAIが修正しているので誰もコントロールできていない模様

Update from Microsoft.

Teams is down.

Messages are delayed.

Some aren't arriving at all.

We're investigating.

Investigating means the AI is investigating.

The AI that wrote the code.

That broke the code.

That is now debugging the code.

It's a closed loop.

Very efficient.

A user asked why their message didn't send.

I said "we're observing recovery in our telemetry."

They asked what that means.

I don't know what that means.

But the dashboard is green now.

Green means fixed.

Fixed means we changed the threshold for green.

The messages are still delayed.

But the dashboard doesn't know that.

Dashboards don't use Teams.

Someone on the infrastructure team tried to escalate.

Via Teams.

The escalation is still pending.

Somewhere in the queue.

With everyone else's messages.

The irony wasn't lost on them.

But the message was.

We have a backup communication channel.

It's email.

Email is also having issues.

Unrelated, obviously.

The root cause is under analysis.

Analysis means we asked the AI.

The AI said "no issues detected."

The AI wrote the detection system.

It detects what it wants to detect.

Very self-aware.

Not in the good way.

Last quarter I said 30% of our code is AI-written.

Teams is closer to 45%.

We were proud of that.

Past tense.

The AI optimized the message queue.

It optimized it to zero.

Zero messages. Zero latency.

Technically correct.

The best kind of correct.

Enterprise customers are asking for an RCA.

RCA means Root Cause Analysis.

The root cause is velocity.

We shipped faster than we understood.

Understanding isn't in the OKRs.

Shipping is.

We shipped.

Someone asked when Teams will be fixed.

I said "we're continuing our analysis."

Continuing means we started.

Analysis means looking.

Looking means hoping it fixes itself.

It usually does.

If you refresh enough.

Refresh is the user's responsibility.

We provide the experience.

They provide the resilience.

That's partnership.

The outage started at 2:30 PM ET.

Right before the holidays.

Millions of workers couldn't message their teams.

Some called it a disaster.

I called it "an unplanned wellness moment."

Productivity is a spectrum.

We're exploring the lower end.

The AI has proposed a fix.

The fix requires a deployment.

The deployment system uses Teams for notifications.

The notifications are delayed.

We're in a loop.

The loop is also AI-designed.

Very elegant.

From a certain angle.

Satya asked for a status update.

I sent it via Teams.

He hasn't responded.

I assume he's thinking about it.

The stock is up 2% today.

Outages don't move markets.

Narratives do.

The narrative is "AI efficiency."

The reality is "Teams is down."

But reality isn't in the earnings call.

The narrative is.

We're committed to reliability.

Reliability means it worked yesterday.

Yesterday is our SLA.

Thank you for your patience.

Patience means you have no choice.

We're in your enterprise agreement.

For three more years.

The circle of innovation continues.

@gothburz

翻訳:

マイクロソフトからのアップデート。

チームがダウンしています。

メッセージが遅れています。

まったく到着していない人もいます。

調査中です。

調査中とは、AI が調査していることを意味します。

コードを書いたAI。

それはコードを壊しました。

これでコードがデバッグされます。

それは閉ループです。

非常に効率的です。

ユーザーはメッセージが送信されなかった理由を尋ねました。

私は「テレメトリーで回復を観察しています」と言いました。

彼らはそれが何を意味するのか尋ねました。

それが何を意味するのか分かりません。

しかし、ダッシュボードは緑色になりました。

緑色は固定を意味します。

固定とは、緑のしきい値を変更したことを意味します。

メッセージはまだ遅れています。

しかし、ダッシュボードはそれを知りません。

ダッシュボードは Teams を使用しません。

インフラストラクチャ チームの誰かがエスカレーションしようとしました。

チーム経由。

エスカレーションはまだ保留中です。

行列のどこかに。

他の皆さんのメッセージも添えて。

皮肉は彼らにも負けていなかった。

しかし、メッセージはそうでした。

当社にはバックアップ通信チャネルがあります。

電子メールです。

電子メールにも問題があります。

明らかに無関係です。

根本原因は分析中です。

分析とはAIに聞いたということです。

AIは「問題は検出されなかった」と言いました。

AI が検出システムを書きました。

検出したいものを検出します。

とても自意識が強い。

良い意味ではありません。

前四半期、私はコードの 30% が AI によって書かれていると言いました。

Teams は 45% に近いです。

私たちはそれを誇りに思っていました。

過去形。

AI はメッセージ キューを最適化しました。

それをゼロに最適化しました。

メッセージゼロ。遅延ゼロ。

技術的には正しい。

最高の正解。

企業顧客は RCA を求めています。

RCAとは根本原因分析を意味します。

根本的な原因は速度にあります。

思っていたよりも早く発送していただきました。

OKR には理解が含まれていません。

送料はです。

発送しました。

Teams はいつ修正されるのかと尋ねた人がいます。

私は「分析を続けている」と言いました。

継続するということは、始めたことを意味します。

分析とは、調べることを意味します。

探すということは、自然に直ることを期待することを意味します。

通常はそうなります。

十分にリフレッシュできれば。

更新はユーザーの責任です。

私たちは体験を提供します。

それらは回復力を提供します。

それがパートナーシップです。

停電は東部時間午後２時３０分に始まった。

お盆休みの直前。

何百万人もの従業員がチームにメッセージを送信できませんでした。

ある者はそれを災害と呼んだ。

私はそれを「予期せぬ健康の瞬間」と呼びました。

生産性はスペクトルです。

私たちは下位端を探索しています。

AI が修正を提案しました。

修正には展開が必要です。

展開システムは通知に Teams を使用します。

お知らせが遅れております。

私たちはループ状態に陥っています。

このループも AI によって設計されています。

とてもエレガントです。

ある角度から。

サティアは状況の最新情報を求めました。

Teams経由で送信しました。

彼は返事をしていません。

彼はそれについて考えていると思います。

今日の株価は２％上昇した。

停電では市場は動かない。

物語はそうなります。

物語は「AIの効率化」です。

現実は「Teams はダウンしている」です。

しかし、現実は決算発表には反映されていない。

物語は。

私たちは信頼性を重視しています。

信頼性とは、昨日も機能したことを意味します。

昨日は SLA でした。

ご理解いただきありがとうございます。

忍耐とは、選択の余地がないことを意味します。

私たちは企業契約を結んでいます。

あと3年も。

イノベーションの輪は続きます。

MEMO:

• これもうシンギュラリティでは（なお成果）

(2025/12/20)

エンジニアの“サラリーマン化”というか、最近の転職事情を見ていると、どの組織でも普通に...

エンジニアの“サラリーマン化”というか、最近の転職事情を見ていると、どの組織でも普通にサラリーマンとして優秀なシゴでき人材が、技術力も持っているケースが転職ではウケがいい、という話になっている。昔からある「典型的なエンジニア像」みたいなものは、だんだん薄れてきてますね

@sakamoto_582

MEMO:

• 10年位前からそんな傾向はあった
• アメリカの方でもOSS界隈で暴言を吐くエンジニアが追放されたり、行動規範のようなものが設定されたり
• 職人的な仕事をするが人格に難がある人材が忌避されている空気はある
• ブリリアントジャークという言葉で言語化されたのも大きいだろうか

(2025/12/20)

生成AIを活用した設計・開発プロセス

• 20251209_WAKECareer_生成AIを活用した設計・開発プロセス - Speaker Deck

MEMO:

• AI主導開発（仕様駆動開発）
• この開発手法の場合、エンジニアはアーキテクチャ/エンジニアリングに集中することになる
• 開発の進め方:
  • (1) 業務フローの整理
  • (2) 要件の整理
  • (3) 設計
  • (4) 実装
• 2-4をAIが主導して開発する
• AI主導開発で必要なスキル
  • 要件を理解・整理する能力
  • ソフトウェアエンジニアリング
• 実装より要件や設計を考える時間が増加する
• AIのコンテキストサイズを節約する手法
  • ドメイン駆動設計
  • クリーンアーキテクチャ
  • 長大なコードを読み込ませないようにする
• 人間があるべき姿（仕様）を定義し、AIが実装する
  • ビジネス上の優先順位
  • ドメイン知識の正確性
  • アーキテクチャ選定の意思決定

(2025/12/20)

これは俺の経験則なんですが「モノ作りたいだけで人の上に立ちたくない」みたいな社会不適合者が...

これは俺の経験則なんですが「モノ作りたいだけで人の上に立ちたくない」みたいな社会不適合者が作るモノってこういうモノが多いんだよね

一部は素晴らしいが歯抜けがあって全体としては機能しないモノ。そしてそういうモノを作る社会不適合者にチャンスを与えるのが世間知らずの金持ちで（続く

@satetu4401

それが芸術作品とかなら別にどうもならんのだけど、工業機械とか建築とかになると話変わって来るんだよな

あの手の「モノ作りだけしたい」系の人間は、モノを作る人間として信用に値しないんだけど、一般人だけじゃなくて業界にもあの手の社不に夢見てるアホが多いんだよな

@satetu4401

社会不適合者がなんで社会と不適合を起こすのかというと、物事の幾つかを極端に軽んじているからですよ、人付き合いとか、礼儀作法とか、報連相とかな

そういう人間が作るモノは、作者の性質から要素の幾つかが抜け落ちて欠陥品になるんだよ「作るモノだけは完璧」なんて事は現実的にありえない

@satetu4401

MEMO:

• 他人に使ってもらうという時点でホスピタリティは求められるというのはある

(2025/12/19)

PMのレベル論争が気にならなくなる瞬間

• PMのレベル論争が気にならなくなる瞬間｜Toshiki Chiba

要約:

■ 1. PMのキャリアにおける視点の転換

• Jr/Middle/Seniorの議論は自分の立ち位置を確認したいフェーズの自然な問い
• 意思決定や失敗を経て視座が変わると「自分はどこに立っているか」から「この判断を引き受けるのは誰か」へ関心が移行
• PMのキャリアには関心の向きが切り替わる明確な分岐点が存在

■ 2. 経営的語彙の習得段階

• PMを続けると事業視点/PL意識/長期価値/投資対効果などの語彙を使い始める
• プロダクトの外側を見る視点が身についた証拠であり成長の表れ
• このフェーズは最も楽しい段階である
• まだ痛みを伴わない段階

■ 3. 経営者が引き受ける現実

• 経営者が本当に引き受けているもの:
  • 誰にも相談せずに決める瞬間
  • 後から間違いに気づいても戻れない現実
  • その判断で人や生活を変えてしまう感覚
• この話題になると抽象論に逃げるPMが多い
• 能力や意識の問題ではなく引き受けた経験がないだけ

■ 4. レベル論争に留まる理由

• レベル論争が好まれる理由は責任を曖昧にしたまま賢く振る舞えるから
• 言い訳の構造:
  • そこまでは求められていない
  • 権限がない
  • 役割的に違う
• フェイクなPMはこの場所に長く留まる
• リアルなPMはある日ここから降りる

■ 5. 経営に片足を突っ込んだPMの特徴

• 共通点:
  • レベル論争がどうでもよくなる
  • 業務範囲の話を一段上から見るようになる
  • 正解がない判断を無言で引き取る
• 「まあやるしかないよね」という言葉が出る
• この言葉は投げやりな諦めではなく覚悟が決まった人の決意表明
• この段階に達したPMはもうPMごっこには戻れない

■ 6. PMの最終進化系

• 肩書きは重要ではない
• 経営をやってしまっている人であり逃げないことを選んだ人
• 逃げない姿勢の内容:
  • 数字から逃げない
  • 人の感情からも逃げない
  • 判断の結果を全部自分の名前で引き受ける
• 自分の仕事かどうかではなく自分がやらないと誰がやるのかで決める

■ 7. 分岐の認識

• 選別や優劣をつけることが目的ではない
• 分岐があるという事実をちゃんと認識することが重要
• レベル論争や業務範囲の線引きが大事に思えるフェーズも間違いではない
• そのフェーズがあるから次に進める

■ 8. 次のステージへの移行

• あるタイミングで議論が空虚に感じ始める契機:
  • 正解が用意されていない判断が増える
  • 誰かに委ねると歪む感覚が出てくる
  • これは誰かに預ける話じゃないと思う瞬間が来る
• このときPMは次のステージに入る

■ 9. 経営との関係性

• 全員がCEOや事業責任者になる必要はない
• PMを続ける限り経営的な判断から完全に逃げ切ることはできない
• 肩書きに関係なく必ず現れる判断:
  • どこに賭けるか
  • 何を捨てるか
  • どの未来を選ばないか

■ 10. 「まあやるしかないよね」の意味

• 諦めでも開き直りでもない前向きな言葉
• 前提条件:
  • 完璧な情報は揃っていない
  • 正解があるわけでもない
  • でも決めないと前に進めない
• 現実を受け入れた人が前を向いたときに出てくる言葉
• 不確実の中での前進の合図

■ 11. PMの仕事の本質

• 役割定義で縛るには大きすぎる仕事
• 二面性:
  • やると決めたらやってしまえる自由がある
  • 引き受けた瞬間に重さがのしかかる
• レベル論争や業務範囲論争に違和感を覚え始めるのは視座が一段上がったサイン

■ 12. 変化の兆候

• 自分はいまどこに立っているんだろうから判断は誰が引き受けるべきなんだろうへ考える時間が移行
• その変化に気づいた時点でもう以前と同じフェーズにはいない
• 確認すべきポイント:
  • どの現実が気づけば自分の手元に集まってきているか
  • どの判断がいつの間にか自分の名前で残るようになったか
• PMという仕事は気づかないうちに経営という営みに近づいている
• 気づいてしまった人はもう少しだけ前に進めばいい

(2025/12/19)

エンジニアの会話で重要なのが「知識マウントを抑えて黙る」能力なんだよな。

エンジニアの会話で重要なのが

「知識マウントを抑えて黙る」能力なんだよな。

“会話が下手なエンジニア”は、

・相手のコードレビューでマウントする

・技術知識を披露したくて割り込む

・聞かれてないのに設計思想を語り出す

こういった“瞬間的な快楽”で、

長期的な信用を失う。

結局、優秀なエンジニアは

必要なときに、必要な分だけ話すことができる。

雄弁は銀、沈黙は金。

コードも会話も“引き算”が大事なのである。

@bico9999

(2025/12/18)

AI時代は、プロジェクトマネジメントやチームマネジメントの重要性が上がるよねの話。

• AI時代は、プロジェクトマネジメントやチームマネジメントの重要性が上がるよねの話。 - フジイユウジ::ドットネット

要約:

■ 1. AI時代におけるマネジメントスキルの重要性

• AI時代はプロジェクトマネジメントやチームマネジメントの重要性が上がるという話について考えたことを書く
• AI時代プロジェクトマネジメントとかチームマネジメントのスキルがめちゃくちゃ重要性上がるよねーという話をしまくっているがあまり理解されていない気がする
• 確信があるが重要性をうまく説明できていない

■ 2. AIによる個人のエンハンスとその限界

• 生成AIは個人をエンハンス(高める・強化)する力が強い
• 個人がエンハンスされた作業範囲に注目すればほんとうに信じられないくらいの品質向上・速度の向上が見られる
• AIが得意な作業の例:
  • コーディングエージェント
  • Deep Research
  • 言語化・要約
  • 図表化
  • 画像化
  • エージェントによる自動化
• これらは間違いなく多くの人にとって仕事の速度向上と品質の変化をもたらしている
• 2022年11月以来業務でもプライベートでも生成AIはないと困るレベルの存在になっている
• AIが得意な作業はとんでもない飛躍的な変化をしている
• 一方で事業の成果が飛躍的に伸びているわけではない
• 生成AI様のおかげで利益が出るようになり多くの会社で効率化が進み景気が良くなるという感じはしない
• 個人がエンハンスされるインパクトは凄いがそれは局所的である
• それが組織や事業全体にも効いているように錯覚している人が多いように感じている

■ 3. 経験したことがない強烈な局所最適の問題

• 生成AIは個人をエンハンスする力が強いので作業の変化に注目されている
• システム開発ならコーディング企画職ならリサーチやドキュメント化や図式化
• それを全体の成果につなげるのは簡単なことではない
• 局所的エンハンスが経験したことない強烈な局所最適である
• 数年前と比較したら魔法に見えるような局所最適である
• あまりの衝撃に仕事全体にも効いているように感じてしまうのではないか
• プロジェクトマネジメントとかチームマネジメントのスキルがある人が多数いないと全体でその効能を得ることはできないと伝えても重要性がちゃんと伝えられていない
• プロジェクトマネジメントとかチームマネジメントのスキルがある人が多数いないと全体でその効能を得ることはできないということ自体は納得されるものの個人のエンハンスが強烈すぎてその重要性・必要性は軽く見られてるんじゃないかと思っている
• その人たちがなにをすれば成果になるのかを示せてない

■ 4. 局所最適をアウトカムに変換する必要性

• ヤバいレベルの局所最適が起きても利益が爆増したり売上が上がったりしない
• 作業5000時間を削減ってやつを見るたびに怪しい数字だなと思う
• AIの活用だけに注目していてはいけなくてヤバいレベルの局所最適をどうアウトカムに変換できるかを問われているって強く意識する必要がある
• アウトカムに向かって動けるチームマネジメントだとかプロジェクトマネジメントやプロダクトマネジメントの力を持った人の価値がより高まるだろう
• ただAIを使うのが上手いとかAIを使いこなす知識を持っているだけじゃ成果には繋がらない
• AIをこう使えば良いという業務改善的な型なんかではなく個別具体の動きからしか成果は生まれない
• だからからこそチームマネジメントだとかプロジェクトマネジメントのスキルがある人たちがアウトカムに向かって動けるようにしていく必要がある
• それって当たり前の話じゃないのと思われるかもしれないが必要性は理解されていたと思うが生成AIによってより難しくなってるんじゃないの複雑な世界がより複雑になっていてそれを紐解く能力が必要になってるんじゃないのという問題提起を強くしていく必要がある
• こんなに業務改善されたよとか機能開発が爆速になったよってのはアウトカムを得るプロセスでしかない
• AIによってそのプロセスは驚くほど変化が起きてるが利益や売上だとか事業価値を上げるところまでもっていくところまで変化を及ぼさなくてはならない
• AIを使いこなすPMがいるって話でもないしマネジメントできる人はAIを制御するプロンプト書けるって話でもないし業務自動化とか複数人が関わるワークフローをAIでつなげる業務設計できる人が必要って話でもないがなんかそういう話になりがちである
• もっとうまくこれを説明できるようにならないとなあ

(2025/12/18)

スーパーマーケットで学ぶドメイン駆動設計の基本

• スーパーマーケットで学ぶドメイン駆動設計の基本 - NRIネットコムBlog

(2025/12/18)

Process Managerパターンで複雑な業務フローを見通しよく実装する

• Process Managerパターンで複雑な業務フローを見通しよく実装する - enechain Tech Blog

要約:

■ 1. 背景とProcess Manager導入前のアーキテクチャ

• イベント駆動のシステムで処理の流れが複雑化してピタゴラスイッチ状態になることがある
• あるイベントが発生してそれをトリガーに別の処理が動いてさらにその結果を受けて次の処理が連鎖していくうちに全体のフローを把握するのが困難になる
• どこで何が処理されるのかを追うのに複数のハンドラを行ったり来たりしながら読み解かなければならない
• エネルギー取引のドメインを扱うプロダクトを開発している
• 公平な取引が行われていたことを証明するため官公庁への取引ログ提出を求められる場合があり任意の時点でのシステム状態を復元できる必要があるためCQRS+Event Sourcingパターンを採用してシステムを構築している
• ある業務の完了をトリガーに別の業務を実行するというパターンは非常に多く見られる
• 注文が作成されたら履歴を作成する約定したら通知を送るといった後続業務が多数存在している
• Event Sourcingではイベントが一級市民であるため自然とイベントをトリガーとして非同期で後続処理を実行するパターンを採用することとなった
• 一連の業務処理を一つのトランザクションで実行するのではなくイベントを介して非同期に連携させることによって異なる業務同士を疎結合に実装できたりユーザーリクエストに対するレスポンス時間の短縮にもつながるなどイベント駆動の利点を得られている

■ 2. 直面した課題

• イベント駆動な業務プロセスの自動化を実現するため最初はイベントに対するハンドラを個別に定義するシンプルなアプローチを取っていた
• このパターンはイベントを受けて1つの処理を行うという単純なケースには適している
• 履歴作成や通知送信など多くの後続処理はこのパターンで実装している
• しかし業務プロセスが複雑になるとこのパターンでは対応しきれなくなった
• 2つの業務があり業務の開始位置が異なる場合:
  • 業務①はイベントAから始まり処理1→イベントB→処理2-1の順に進む
  • 業務②はイベントBから始まり処理2-2と進む
• どちらの場合も途中でイベントBを受け取るが特定のイベントに対応して後続の処理を実行するだけの単純なイベントハンドラではイベントBを受けたときにこれがどの業務プロセスに属するイベントなのかを判別できないため次にどの処理に進んでいいのかが判断できない
• この問題はイベントハンドラが前のステップのコンテキストを持たないことによって生じている
• 対応策として業務プロセスに関するコンテキスト情報をイベントに含める方法が考えられる
• しかしこれにはいくつかの課題がある:
  • 業務プロセスの制御に関する情報までイベントに含めてしまうとイベントが本来持つ業務で起こった事実を記録するという責務から逸脱してしまう
  • 異なる業務がお互いの存在を意識しなければならなくなり疎結合性が損なわれる
  • 業務プロセスが増えるたびにイベント定義が肥大化し保守が困難になる
  • 外部システムを経由する業務プロセスではそもそも自システムのコンテキスト情報をすべてイベントに含めてもらうこと自体が難しい場合もある
• 一連の業務プロセスを独立したイベントハンドラの組み合わせで実装すると全体のフローを把握しづらくなる
• どのイベントがどこで処理されるのかを追うために複数のハンドラを行き来しながら読み解く必要がありコードの可読性と保守性が低下する

■ 3. Process Managerパターンの概要

• Process Managerパターンを導入することで課題の解決を図った
• Process Managerはイベント駆動の処理フローの中に複数の集約間のメッセージ交換を仲介・調整する役割を追加するパターンである
• 業務フローにおける現在のステップやコンテキスト情報を保持し受け取ったイベントに基づいて次に実行すべきアクションを決定して発行する
• Process Managerは複数のステップからなる業務の流れを管理するステートマシンのように振る舞う
• Process Managerの動作:
  • イベントを受け取る
  • 現在の状態を確認する
  • 次に行うべきアクションを決定して送信する
  • 状態を更新する
• 実装時に意識したいのはProcess Managerはイベントを受け取りコマンドを発行するという責務に徹すること
• 業務ロジック自体はコマンドハンドラ側に実装しProcess Managerはあくまでどのコマンドを発行するかを決めるルーティング役に専念する
• こうすることでコマンドハンドラとProcess Managerにロジックが分散することを防ぎコードの見通しが良くなる
• 単純なイベントハンドラとProcess Managerの違い:
  • イベントハンドラ:
  • 状態を持たない
  • 判断基準はイベントの内容のみ
  • 適する用途は1イベント→1処理
  • Process Manager:
  • 状態を持つ
  • 判断基準はイベント+現在の状態
  • 適する用途は複数ステップの業務プロセス

■ 4. 実装例における要件

• エネルギー取引を扱うシステムにおいて注文を作成するプロセスを考える
• 自システムは業務効率化のために注文をクローズドに管理するシステムである
• それとは別に外部公開されている取引所システムが存在しユーザーはそちらにも注文を掲載したい場合がある
• 2つの市場:
  • InternalMarket:自システムが管理する市場
  • ExternalExchange:外部システムで管理される外部取引所
• ユーザーは自システムが管理する市場にのみ注文を掲載することもできるし外部システムの取引所またはその両方に掲載することもできる
• 両市場を選択した場合の注文作成の流れ:
  • 自システムで注文を作成
  • 外部システムに注文作成をリクエスト
  • 外部システムからの作成完了通知を待つ
  • 外部取引所への掲載を反映
  • 自市場への掲載を反映
  • 作成完了を通知
  • ユーザーの画面に注文が反映される
• どちらか片方の市場のみを選択した場合は上記のフローから不要なステップが省略される
• 注文作成プロセスは上記のようにユーザー起点で始まる場合もあれば外部システムの取引所で注文が作成されたことをきっかけに自システムに注文を取り込む場合もある

■ 5. ProcessManagerインターフェースと呼び出し構造

• ProcessManagerの核となるインターフェース:
  • CanHandle:このProcess Managerが処理すべきイベントかを判定
  • Execute:イベントを受け取り状態に応じてコマンドを発行
  • ExecFunc:コマンドバスへの委譲関数でこれを通じてコマンドを実行し他の集約を操作する
• Workerは複数のProcessManagerを保持しておりイベントを受け取ると対応するProcessManagerを探して実行する
• commandBusはコマンドをコマンドハンドラにルーティングするコンポーネントである

■ 6. 状態遷移の設計

• Process Managerの設計ではまずは業務プロセスを構成するステップとその状態遷移を整理することから始める
• 業務のステップ:
  • NotStarted:プロセス未開始
  • AwaitingExternalCreation:外部システムでの作成待ち
  • AwaitingExternalListing:外部取引所へ掲載されたことをマークする処理待ち
  • AwaitingInternalListing:自市場への掲載されたことをマークする処理待ち
  • Completed:プロセス完了
• イベント:
  • OrderCreated:自システムで注文が作成された
  • ExternalOrderCreated:外部システムで注文が作成された
  • ExternalOrderRejected:外部システムでの注文作成が拒否された
  • ListedOnExternal:外部取引所への掲載が完了した
  • ListedOnInternal:自市場への掲載が完了した
• もともとのリクエストの内容によって同じステップ・イベントでも次のステップが変わったり同じイベントが異なるステップで発生したりする
• 業務のコンテキストや現在のステップに応じて処理を分岐させる必要があるため単純なイベントハンドラの組み合わせでは処理の流れを把握することはかなり難しくなる
• Process Managerのメソッドとして各イベントのハンドラを実装していくため状態遷移を表形式でまとめると実装時に役立った
• 業務プロセスの状態を保持する構造体:
  • ProcessID:業務プロセスを一意に識別するID
  • Step:現在のステップ
  • OrderID:対象の注文ID
  • MarketDest:掲載先
• ProcessIDがポイントである
• 業務プロセスの開始時に例えば注文作成時にProcessIDを生成し後続のイベントにはこのProcessIDのみを含める
• イベント定義にプロセスのコンテキスト情報を含める代わりにProcessIDを使って複数のイベントにまたがるプロセスを識別し必要なコンテキストはStateから取得する
• 外部システムを経由したコンテキストの受け渡しについては今回のケースにおいては外部システムがリクエストIDを受け取り結果通知時に同じIDを返す仕組みであったためProcessIDをリクエストIDに含めることによって実現した
• 自システムに必要なコンテキスト情報をすべて外部システムに引き回してもらうのは現実的でない場合が多いがリクエストIDのような一般的な仕組みを活用することで実現できるところもこのパターンの利点である

■ 7. Executeメソッドとイベントハンドラの実装

• Executeメソッドではイベントの種類に応じたハンドラを呼び出し次の状態を保存する
• イベントハンドラは内部的にコマンドハンドラを呼び出しコマンドを実行する
• このとき新たにイベントが発生するため即座にコミットしてしまうと次の処理が現在の処理の完了を待たずに始まってしまい古い状態を参照して処理されてしまう可能性がある
• これを防止するためにコマンドの実行と状態の保存を同一トランザクション内で行うようにしている
• イベントハンドラでは現在のProcess Managerの状態に応じて処理を分岐させる
• ExternalOrderCreatedイベントを処理するハンドラでは現在のステップによって注文作成が自システム起点なのか外部システムなのかを判別し適切なコマンドを発行している
• ListedOnExternalイベントを処理するハンドラではもともとの注文作成時に指定された掲載先に応じて次のステップを分岐させている
• 以上のようにして複雑な業務プロセスをイベント駆動の利点を損なうことなく見通しよく実装することができた

■ 8. まとめ

• Process Managerが解決する課題:
  • 単純なイベントハンドラでは複数ステップにまたがる業務プロセスでどの文脈のイベントかを判別できない
  • 処理が複数のハンドラに分散し全体のフローを把握するのが困難になる
  • Process Managerに業務プロセスに関する知識を集約し現在のステップやコンテキストを状態として保持することでイベント駆動の利点を損なうことなく複雑な業務プロセスを見通しよく実装できる
• 設計するときのポイント:
  • まず業務プロセスをステップと状態遷移で整理すると実装しやすい
  • 業務ロジックはコマンドハンドラ側に実装しProcess Managerはルーティングに徹する
  • Process Managerは強力なパターンだが単純なケースには過剰な抽象化になり得るため使いどころを見極める必要がある
  • 履歴作成や通知送信といった単純な後続処理はシンプルなイベントハンドラで実装している
• イベント駆動のシステムで業務プロセスが複雑化してきたときはProcess Managerパターンの導入を検討する

(2025/12/17)

日本のソフトウェアエンジニアの求人を見ると、いまだにEC、広告、SaaS事業が中心な求人が多い

日本のソフトウェアエンジニアの求人を見ると、いまだにEC、広告、SaaS事業が中心な求人が多い

もちろんこれらも重要な分野だけど、安定していて伸びしろが読みやすい領域ばかりに人材と資金が集まっている印象が強い

一方で、アメリカの求人を見ていると、

AI/GPU、仮想通貨、自動運転、バイオテック、eVTOL、ドローンなど、次の10年をつくるような領域に挑戦できるポジションが本当に多くて羨ましいよね

単なる給与水準の差ではなく、どんな未来を作るかという選択肢の広さにギャップを感じる

@gaijineers

MEMO:

• 一見ご立派な事を言ってるように見えるが、羨ましいなら自分でリスク取って起業すればよいのである
• 彼が求めているのはチャレンジではなくチャレンジをお膳立てしてくれる環境だということ
• それが悪いとは言わないが、創業者のチャレンジの分け前に群がる雑魚のメンタルであることは自覚するべきであるかな
• このようなメンタルは実に日本人らしさを感じて自己言及のパラドックスめいて味わい深いものである

(2025/12/17)

SCSK、プログラミング言語「COBOL」で新会社　システム刷新支援

• SCSK、プログラミング言語「COBOL」で新会社　システム刷新支援 - 日本経済新聞

SCSKは業務用大型コンピューターで用いるプログラミング言語「COBOL（コボル）」利用企業の支援事業を本格的に始めたと発表した。金融機関システムなどで取り入れられてきたものの、利用が縮小傾向にあるコボルを使ったシステム刷新や開発、運用を後押ししていく。

「COBOL PARK（コボルパーク、東京・江東）」を6月に設立した。SCSKが株式の66.7%を保有し、残りをベトナムIT大手FPTの日本法人、FPTジャパンホールディングス（HD、東京・港）が出資する。

コボルは業務用大型コンピューター「メインフレーム」で動作するソフトウエアの開発に使われてきた。ただクラウド化が進む中で、メインフレーム市場が縮小。コボルを扱える技術者が減少し、システムの刷新が難しくなっている。

(2025/12/17)

「社内にエンジニアがいないので受託で新規プロダクトを作りたい」という相談を受ける

• 「社内にエンジニアがいないので受託で新規プロダクトを作りたい」という相談を受ける｜すてぃお

(2025/12/17)

大規模レガシーシステムのマイクロサービス化における0→1ではない-1→1の新規開発

• 大規模レガシーシステムのマイクロサービス化における0→1ではない-1→1の新規開発

(2025/12/17)

Why Startups Die

• Why Startups Die - by Mathias Klenk - Tech Founder Stack

要約:

■ 1. スタートアップの失敗率と主要因

• スタートアップの失敗率は推定で10社中9社
• 大半のスタートアップは巨大な競合による「他殺」ではなく内部問題による「自殺」で終わる
• YC創設者Paul Grahamは「スタートアップは他殺よりも自殺で死ぬ可能性が高い」と指摘
• 最大の脅威は通常会社の外部ではなく内部から来る

■ 2. 自殺vs他殺の概念

• Silicon Valleyの格言「スタートアップは死なず自殺する」
• 起業家Justin Kanは多くの若い企業が選択肢を使い果たすずっと前に崩壊することを観察
• スタートアップはまだ十分に存続可能な状態で自らを諦める
• 創業者が燃え尽きるか心が折れチームが終了を宣言
• 創業者はスタートアップが困難で大規模な疲弊を引き起こすことに気づき別の仕事に就くか学校に戻るか単に離れていく
• Y CombinatorのHarj Taggarは多くの企業が単に創業者が努力を止めるために失敗することに気づいた
• 成功するスタートアップは継続し続けるもの
• 勝つ方法は死なないこと
• 早すぎる諦めがしばしば真の殺し屋
• 内部問題の蓄積(明確な牽引力なし・絶え間ない障害・チームの意見の相違・ストレス)が絶望につながる
• YCの段階では企業は諦めるか創業者が仲良くできないために失敗する
• もう一つの大きな理由は企業が人々が本当に望むものを作っていないこと
• プロダクトマーケットフィットに到達していないか共同創業者と毎週戦っている場合創業者が継続する意志を失う理由は明白
• 外部競争だけが直接スタートアップを殺すことは稀
• 優れた製品と堅実なチームがあれば競合は簡単に破壊できない
• はるかに頻繁にスタートアップは不作為・対立・焦点の喪失によって自らを打ち負かし競争は単に見ているだけ

■ 3. 資金不足という最終症状

• 資金不足はスタートアップが死ぬ最も目に見える方法の一つ
• 100以上のスタートアップの事後分析で資金不足は失敗の第2位の理由
• しばしばスタートアップは次の資金調達ラウンドを間に合わせられないか初期資金が枯渇する前に収益が実現しない
• 資金不足は通常症状であり根本原因ではない
• より深い問題はなぜスタートアップが最初に資金不足になったのか
• 多くの場合プロダクトマーケットフィットを達成できなかったため
• 真に望む人がほとんどいないものを作っていたため収益と投資家の関心が低いまま
• ベンチャーキャピタリストMarc Andreessenは「第1の企業殺しは市場の欠如」と述べる
• 誰も必要としない製品を構築すればシード資金がいくらあっても最終的に現金は何も示さずに燃え尽き資金調達は不可能
• スタートアップはプロダクトマーケットフィットに決して到達しないときに失敗する
• プロダクトマーケットフィット以外に財務管理の誤りが終焉を加速させる可能性
• 一部のチームはビジネスを検証する前にあまりにも積極的に支出(多くの人を雇用・豪華なマーケティング)しキャッシュクランチを引き起こす
• 他のチームはマネタイズや資金調達が遅すぎ単に時間切れ
• 資金不足になった多くの創業者は実際には成功の瀬戸際にいたが早すぎる諦め
• Justin Kanは指標が急上昇しているときに創業チームが諦めるのを見ることは稀だと指摘
• 大半は成長が横ばいで資金が少ないときに諦める
• それはまさに忍耐と反復が必要な瞬間
• 一夜にして成功は実際には一夜にして起こらない
• 忍耐し滑走路を延ばす方法を見つける人(燃焼を削減・ピボット・ブリッジラウンドの確保)は事態を好転させる機会を得る

■ 4. 創業者の対立とチームの崩壊

• 資金不足が棺桶の最後の釘ならば共同創業者の対立はしばしば最初に棺桶を構築したもの
• Harvard研究者Noam Wassermanの統計では高い潜在性を持つスタートアップの65%が共同創業者間の対立により失敗
• 初期段階では創業チームが会社そのもの
• チームが崩壊すれば会社も一緒に崩壊することが多い
• 共同創業者の内輪もめは投資家を遠ざけ意思決定の麻痺を引き起こし社内から企業文化を毒する
• 間違った共同創業者を選ぶことは間違ったアイデアを選ぶことと同じくらい致命的
• スタートアップの伝承は共同創業者を結婚したカップルに頻繁に例える
• 関係が悪化すれば面倒な離婚が製品が有望であってもスタートアップを殺す可能性
• 大きな質問での不一致(急速に拡大すべきかペースを調整すべきか・会社を売却すべきかIPOを目指すべきか・成功をどう定義するか)は最終的に和解できない相違につながる
• 一人の創業者が10億ドルのユニコーンを構築することを想像し別の創業者が小規模で安定したビジネスで満足なら戦略と目標で衝突
• 明白な対立を超えて重要な創業者や初期チームメンバーが去るシナリオもある
• 共同創業者が辞めると若いスタートアップの士気と運営に信じられないほど厳しい
• 残りのチームは「単一創業者」問題を抱える
• すべての負担が一人の肩にかかる
• Paul Grahamは最初から単一創業者を持つことについて実際に警告
• 複数の創業者を持つスタートアップには優位性がある
• スタートアップを始めるのは一人には難しすぎる
• ブレインストーミングをする同僚が必要でありうまくいかないときに元気づけてくれる人が必要
• その仲間意識を失うとスタートアップの低い時期が耐えられなくなる可能性
• 創業チームメンバーが去った後すぐに会社が崩壊するのを見てきた
• 失われたスキルのためだけでなく感情的な接着剤がなくなったため
• 場合によっては残りの創業者が自信と勢いを失いゆっくりと消えていく
• 創業者間またはチーム間の不適合は良いアイデアでさえ沈める可能性
• 創業チームが整合し一緒にうまく機能することを確実にすることはスタートアップの生存に絶対的に重要

■ 5. 焦点の喪失と創業者の燃え尽き

• もう一つの一般的な自傷行為は創業者が焦点や動機を失うとき
• スタートアップは一途な献身を要求する
• リーダーが気を取られ始めると悪い兆候
• CB Insightsの分析では焦点を失うことはスタートアップが失敗する上位20の理由の第11位
• 時には創業者が新しいサイドプロジェクトを追い始める(別のスタートアップアイデアをいじる・コンサルティングギグを引き受ける・新しい趣味に手を出す)
• 他の時にはより微妙でチームが一つの戦略にコミットせずに新しい方向にピボットし続けるか一度にあまりにも多くの機能を追求して自分自身を薄く広げる
• いずれにせよスタートアップはリーダーが一つの明確なビジョンに全力投球していないため勢いを失う
• 焦点の喪失はしばしば情熱の喪失と結びついている
• 初期の頃には避けられない課題を乗り越えるために膨大な量の熱意が必要
• 創業者の心がもうそこにないなら進歩は停止する
• 成長が停滞したときに創業者が精神的にチェックアウトするのを見てきた
• 倍増する代わりに他の機会について空想を始める
• Justin Kanは辞めたい誘惑がJustin.tv中に何度も彼を襲ったと説明
• 物事が暗く見えたときに諦めて先に進む寸前に来る
• 苦痛な労苦から逃れたいと思うのは人間の本性でありスタートアップを運営することは確かに労苦になる可能性
• 創業者は極度のストレスと燃え尽きにも直面しモチベーションを奪う可能性
• 長時間・生き残るためのプレッシャー・感情的なジェットコースターが疲弊につながる可能性
• 創業者が燃え尽きると先延ばしを始めたり厳しい問題を避けたり重要な決定を委任したりする可能性
• これらはすべて腹の中の火が消えかけているサイン
• 最終的に情熱が再燃しなければスタートアップは放置からゆっくりと枯れる
• スタートアップは通常餓死しない・すべての機会と気晴らしに溺れる
• ミッションに焦点を合わせ続けることは聞こえるよりも難しいが自己誘発的な死を避けるために絶対に必要

■ 6. スタートアップの自殺を避ける方法

• 共同創業者を賢く選びビジョンで整合する:
  • 共同創業者を選ぶことはアイデアを選ぶことと同じくらい重要
  • 価値観と長期目標を共有することを確認
  • 不一致の願望(一人の創業者は迅速な売却を望み別の創業者は永遠に構築したい)は対立につながる
  • スタートアップの65%が共同創業者の対立により失敗することを覚えておく
  • 共同創業者関係を注意深く扱いオープンにコミュニケーション
  • 期待(株式分割・役割・出口戦略)を後で戦うよりも早期に整理する方が良い
• 人々が望むものを作る(プロダクトマーケットフィットを達成する):
  • これはYCからの黄金律でユーザーが望むものを作らないことが究極の殺し屋
  • ターゲットユーザーと絶え間なく話し実際の問題を解決していることを検証し神経に触れるまで反復する意志を持つ
  • 顧客が本当に製品を愛しているなら死ぬ可能性ははるかに低い
  • 牽引力は多くの問題を解決する・投資家を引き付けチームの士気を高め滑走路を延長する収益を提供
  • Harj Taggarが言ったように多くのスタートアップは企業が人々が本当に望むものを作っていないために失敗
  • 技術自体に恋をしない・人々にとって本当に重要な痛点を解決
• 滑走路と財務を慎重に管理する:
  • 資金不足は多くの場合予防可能な失敗
  • 常に滑走路(残りの現金の月数)を知り空になるずっと前に資金調達または収益マイルストーンを計画
  • コストを管理下に保つ・ゆっくり雇用し針を動かすものに支出し虚栄心には支出しない
  • 多くのスタートアップはあると良いものに資金を燃やし後で後悔
  • 経験則として次の主要なマイルストーン(製品の立ち上げ・ユーザーターゲット・収益目標)に到達するのに十分なお金にバッファを加えて調達するよう試みる
  • 物事が長くかかる場合は費用を削減するか延長ラウンドを調達する準備をする
  • 魅力的ではないが生存はしばしば慎重な現金管理に帰着
  • 投資家は「時間内に調達できない場合何をしますか」と尋ねる・答えを持つ(燃焼を減らす・戦略的パートナーを見つけるなど)ので危機に陥らない
  • 本質的に機能するものを見つけるための時間を買う
• 焦点を保ち完全にコミットする:
  • 一度に2つの会社を運営しようとしないしスタートアップをサイドハッスルのように扱わない
  • 繁栄するスタートアップは通常創業者が両足で飛び込むもの
  • 輝く新しいアイデアは常に誘惑する・すべてのウサギを追いかけることに抵抗
  • Paul Grahamの「13文でのスタートアップ」のアドバイスは単に焦点
  • チームは四半期ごとの最優先事項を知り気晴らしにノーと言う
  • これは厳しい時期を耐え抜くことも意味
  • 小さな勝利であっても進歩を続けていれば諦める多くの人々を生き延びる
  • 格言にあるように失敗を保証する唯一の方法は試みるのをやめること
  • ほぼすべての成功したスタートアップは物事が厳しく見えた段階を経たが創業者は継続した
  • 決意と回復力をコアチームの価値観として育成
• 健全な共同創業者関係とチーム文化を育成する:
  • 内部不和がスタートアップの殺し屋であるためチームを整合させ続けることに投資
  • 共同創業者と絶えずコミュニケーション・パフォーマンス・株式・方向性についての厳しい会話を後ではなく早く行う
  • 役割や報酬を調整する必要がある場合は対処
  • 意見の相違を解決するメカニズムを設定(信頼できるメンターまたは仲介できる取締役会メンバー)
  • 多くの対立は明確なコミュニケーションと共感によって和らげることができる・スタートアップを勝たせようとしている同じ側にいることを覚えておく
  • また全員が懸念を声に出せ燃え尽きが認識される文化を構築
  • 完全な疲弊を避けるために必要なときに休憩を取るよう人々(創業者自身を含む)に奨励
  • 支援的でミッション駆動型の文化は欲求不満と不一致を防ぐのに役立ちしばしばスタートアップの自殺につながる
• 成功(と失敗)を一緒に計画する:
  • 悲観的に聞こえるかもしれないが物事が南に行く場合に何が起こるかを事前に議論
  • 一人の創業者が出たい場合はどのように処理するか
  • 買収オファーが来た場合は両方とも売却にオープンか
  • これらのシナリオで整合することは後で多くの心痛を節約できる
  • 反対側で成功のための共有計画を作成・すべてがうまくいけば私たちのビジョンは何か
  • 共通のビジョンを持つことは暗い日々の間皆のモチベーションを維持
  • 共同創業者が同じ最終ゲームとなぜそれが戦う価値があるかを見るときにコミットし続けることが容易

■ 7. 結論

• ほとんどのスタートアップは市場の捕食者のために終わりを迎えない
• 内部の失策・壊れた関係・意志の喪失のために終わりを迎える
• 経験豊富な創業者からの事後分析とエッセイはすべてこの真実を反映・スタートアップの運命は主に自分の手の中
• 反対側は力を与える・古典的な落とし穴を避けチームの世話をすれば生存の確率を大幅に高める
• 人々が望むものを構築しチームを団結させ賢く支出し決して早すぎる諦めはしない
• そうすれば自分のスタートアップが単に自殺を避けるだけでなく実際に繁栄しビジョンが生き返るのを見る機会を劇的に高める
• Paul Grahamが有名に暗示したように勝つ方法は死なないこと
• 生き続ければ最終的に成功する機会を自分に与える

(2025/12/16)

部下が意見を言わなくなるのはなぜか　“聞いているつもり”の上司が見落としがちな関わり方

• 部下が意見を言わなくなるのはなぜか　“聞いているつもり”の上司が見落としがちな関わり方

(2025/12/16)

宇宙の寿命を超える記憶装置：SPhotonix「5Dメモリクリスタル」が切り拓く、360TB超長期保存の新時代

• 宇宙の寿命を超える記憶装置：SPhotonix「5Dメモリクリスタル」が切り拓く、360TB超長期保存の新時代 | XenoSpectrum

要約:

■ 1. 技術概要

• SPhotonixが5Dメモリクリスタルの商用化に向けて450万ドルの資金調達を完了
• 2025年12月に英国とスイスに拠点を置くディープテック・スタートアップが発表
• 溶融シリカガラスを用いた事実上の恒久保存を実現するデータストレージ技術
• 宇宙の年齢に匹敵する138億年の耐久性を誇る
• 既存ストレージ(HDD・SSD・磁気テープ)は数十年から100年程度で限界を迎えるのに対し圧倒的な優位性を持つ

■ 2. 5次元記録のメカニズム

• フェムト秒レーザーによるナノ構造化技術:
  • サウサンプトン大学Peter Kazansky教授が20年以上研究
  • 1000兆分の1秒という極めて短いパルス幅を持つレーザーを使用
• 5つのパラメータでデータをエンコード:
  • X座標(空間的位置)
  • Y座標(空間的位置)
  • Z座標(空間深さ)
  • 配向(ナノ構造の向き)
  • 強度(光の遅相軸の強さ)
• 溶融シリカガラス内部に微細なボクセル(3次元ピクセル)を刻み込む
• ボクセルは複屈折特性を持ち入射する光の偏光や方向によって異なる屈折特性を示す
• 偏光させた光を照射しその変化を光学的に検出することでデータを復元
• 5インチのガラスディスク1枚に最大360TBのデータを格納可能
• 一般的な大容量HDD(30TB級)の10倍以上の密度を実現

■ 3. 耐久性と安全性

• 190℃の高温環境下で138億年のデータ保持が可能
• 耐熱性・耐環境性:
  • 石英ガラスは化学的に極めて安定
  • 磁気の影響を受けない
  • 放射線・水・湿度による劣化がほぼ皆無
• データ保持に電力を一切必要としないエアギャップなメディア
• ランサムウェア攻撃に対する究極の防御策として機能

■ 4. 市場背景とエネルギー問題

• コールドデータの定義と分類:
  • 世界中に保存されているデータの60〜80%がコールドデータ
  • ホットデータは5ミリ秒未満でのアクセスが必要(SSDの領域)
  • ウォーム/クールデータは数秒以内のアクセスで十分
  • コールドデータはアーカイブ・法的記録・科学データなどアクセス頻度は低いが長期保存が義務付けられ取り出しに10秒以上かかっても問題ない
• 現状の問題点:
  • 慣性により人々はコールドデータ保存にも寿命が短くエネルギーを大量に消費するHDDやSSDを使い続けている
  • AIの台頭によりデータ生成量は指数関数的に増加
  • IDC予測によれば2028年までに年間生成データ量は天文学的な数値に達する
• 持続可能性の観点:
  • 全データを回転するHDDや通電が必要なSSDで保存し続けることは電力消費と廃棄物の観点から持続不可能
  • HDDは数年ごとのリプレイスが必要でそのたびに莫大なコストと廃棄物が発生
  • SPhotonixのガラスメディアは一度書き込めばリフレッシュや空調による厳密な温度管理なしに永久にデータを保持可能
  • データセンターのTCO(総所有コスト)とカーボンフットプリントを劇的に削減する可能性

■ 5. ビジネス戦略

• 資金調達:
  • 2025年11月25日にCreator FundとXTX Venturesが主導するプレシードラウンドで450万ドルを調達
  • 技術成熟度レベルをTRL5(技術検証段階)からTRL6(プロトタイプ実証段階)へ引き上げるために投資
• Arm/NVIDIAモデルの採用:
  • 製造会社になるつもりはないとIlya Kazansky CEOが明言
  • 自社で大規模なガラスディスク量産工場を建設せず核心となるイネーブリング・テクノロジーを開発しライセンス供与するモデル
  • ハイパースケーラーやストレージベンダーとコンソーシアムを組みデータセンターにプロトタイプを展開する計画
• コストとパフォーマンス:
  • 書き込み装置は約30,000ドル(約450万円)
  • 読み取り装置は約6,000ドル(約90万円)
  • 現在の転送速度は書き込み4MB/s・読み取り30MB/s
  • 3〜4年以内に読み書き共に500MB/sまで引き上げる計画
  • 実現すれば現在のアーカイブ用磁気テープシステム(LTOなど)と競合可能な水準

■ 6. 競合分析

• Microsoft Project Silica:
  • 同様にフェムト秒レーザーと石英ガラスを用いたストレージを開発
  • Azureクラウド向けのアーカイブソリューションとして実証実験を進行中
  • 自社のAzureインフラへの垂直統合を主眼に置く
• Cerabyte:
  • セラミック素材を用いたストレージを開発するスタートアップ
• SPhotonixの優位性:
  • オープンなエコシステム志向
  • ライセンスモデルを通じて多様なデータセンター事業者やハードウェアメーカーが技術を利用できるプラットフォームを提供
  • 元Project Silicaの研究者を採用する計画を明かし技術的な知見の集約を図る

■ 7. 文化的意義と実績

• 技術の象徴的なデモンストレーション:
  • 全ヒトゲノムデータを結晶に保存
  • Eon Ark Time Capsuleとして2024年〜2025年の会話記録をアーカイブ
  • 名作ゲーム『Heroes of Might & Magic 3』を保存
  • 映画『ミッション:インポッシブル/ファイナル・レコニング』において技術がフィーチャー
• 人類の知識と文化を文明の存亡を超えて保存する究極のバックアップとしての役割

■ 8. 技術的意義と展望

• 磁気や電荷という不安定な現象への依存から脱却し結晶構造という物理的な恒久性を手に入れる転換点
• ハイパースケーラー各社が直面するエネルギー問題とデータ爆発の圧力が今後数年で技術の実用化を強力に後押し
• 読み書き速度の向上とコストダウンという課題は残存
• TRL6への移行とライセンスモデルの採用により技術が実験室を出てデジタル社会の基盤となる日が近い
• 数千年後の未来において現代の文明を伝えるのはSPhotonixのクリスタルに刻まれた光の記憶である可能性

(2025/12/16)

ポーリング処理廃止によるイベント駆動アーキテクチャへの移行 ― DBコスト30%削減の実現

• ポーリング処理廃止によるイベント駆動アーキテクチャへの移行 ― DBコスト30%削減の実現 | CyberAgent Developers Blog

要約:

■ 1. 背景と課題

• DBコストが毎月徐々に上昇する問題に直面
• 予約管理システムで薬剤師が最新の予約情報をリアルタイムで確認できることが重要な要件
• フロントエンドから30秒間隔でAPIをポーリングする実装を採用
• システムの成長とともに問題が顕在化
• ポーリング間隔は30秒で1回あたりのAPIコール数は9回
• 予約検索APIの秒間リクエスト数は約2,000リクエスト/秒
• 予約一覧・予約詳細・ステータス情報など画面表示に必要な情報を複数のエンドポイントから取得していたため1回のポーリングで9回のAPIを呼び出し
• 多数の薬局クライアントが同時にポーリングを実行するためリクエスト数が膨大化
• 予約データは日々構造が複雑になりデータベースのテーブルにインデックスを張っても大きな負荷がかかる状況
• ポーリング方式の根本的な問題はデータに変更があってもなくても定期的にリクエストが発生する点
• 予約データに変更が発生する頻度はポーリング頻度と比較してかなり低い
• 大半のリクエストは「変更なし」という結果を返すだけで実質的な価値を生み出していない
• 無駄なリクエストが継続的にデータベースへ負荷をかけインフラコストを押し上げる要因
• プロジェクトで導入店舗数が倍増し月次のインフラコストレビューでDBコストの上昇トレンドが明確化したことが転機

■ 2. 解決策の設計思想

• 変更があったときだけ通知を受け取る方式への転換を決断
• 従来のプル型(ポーリング)からプッシュ型(イベント駆動)への転換により不要なリクエストを根本的に排除することを目指す
• 処理フロー:
  • 予約データに変更が発生(イベント発火)
  • イベント伝播用マイクロサービスがサブスクライブ
  • マイクロサービスがFirestoreの薬局別ドキュメントを更新
  • フロントエンドがFirestoreの変更を検知
  • 必要な予約データをAPIから取得

■ 3. アーキテクチャコンポーネント

• 予約サービス(イベント発行元):
  • 予約の作成・更新・キャンセルなどの変更を検知しイベントを発行
  • 既存の予約システムに最小限の変更を加える形で実装
• Cloud Pub/Sub:
  • Google Cloudが提供するフルマネージドなメッセージングサービス
  • イベントの非同期配信を担いシステム間の疎結合を実現
• イベント伝播サービス:
  • GKE上で稼働する軽量なマイクロサービス
  • Pub/Subからイベントを購読しFirestoreの更新を行う
  • 独立させることで関心の分離と保守性の向上を図る
• Firestore:
  • 薬局ごとのイベント状態を管理するリアルタイムデータベース
  • 各薬局に対応するドキュメントを用意しイベント発生時にタイムスタンプを更新
• フロントエンドクライアント:
  • Firestoreのリアルタイムリスナー機能を使用して自身に関係するドキュメントの変更を監視
  • 変更を検知したら必要なデータをAPIから取得

■ 4. 技術選定の根拠

• Firestoreを選んだ理由:
  • リアルタイム同期機能が標準装備でSDKを使うだけで面倒な接続管理なしにリアルタイム同期が実現可能
  • Google Cloudのマネージドサービスとして自動的にスケールしクライアント数の増加に対してインフラ側での対応が不要
  • 薬局ごとのドキュメント分離により各薬局が自身に関係するドキュメントのみを購読するため不要なデータを受信しない
  • 既にGKEやPub/Subを使用していたため同じエコシステム内で完結できる
• Pub/Subを介在させる理由:
  • システム間の疎結合化により予約システムはFirestoreの存在を知る必要がなく「イベントを発行する」という責務のみを持つ
  • 信頼性の向上でPub/Subはメッセージの永続化と再送機能を持つため一時的な障害が発生してもイベントが失われない
  • Pub/Subのメトリクス(未処理メッセージ数・処理時間など)を監視することでシステムの健全性を把握しやすい
  • 将来的には分析基盤への連携・通知サービスへの連携などイベントの配信先を追加する可能性があり拡張が容易
• Cloud Tasksを選んだ理由:
  • 動的なタスクスケジュールに最適でフルマネージド
  • 指定した時刻に1回だけHTTPリクエストを送信するというシンプルな機能を提供
  • キューの管理やスケーリングを意識する必要がない

■ 5. スロットリング機構の実装

• 課題:
  • 予約の登録や更新・キャンセルなどが短時間の間に行われた場合に多数のイベントが発生
  • 同じ薬局に対して数秒間で何十回もFirestoreが更新される
  • フロントエンドが変更を検知するたびにAPIを呼び出し結局大量のリクエストが発生
  • スパイク時の負荷が改善されない
• 解決策:
  • Cloud Tasksを使ったスロットリング機構を導入
  • 一定時間内に発生した複数のイベントを1回の通知にまとめる
  • Cloud Tasksで遅延実行を行い指定時刻にHTTPリクエストを送信
• スロットリング間隔の調整:
  • 10秒という値を採用
  • 通常の予約操作ではユーザーが10秒以内に複数回更新することは稀
  • 複数イベント発生時のイベント集約効果が十分に得られる
  • ユーザーが体感する遅延として許容範囲内
  • モニタリングの結果を見ながら調整を継続

■ 6. テスト戦略

• イベント発生ケースの網羅:
  • イベントが正しく発火されることがシステム全体の動作に直結
  • イベントの発火漏れがあればフロントエンドに変更が伝わらずユーザーは古い情報を見続ける
  • イベントが発生するすべてのケースを洗い出し網羅的にテストを実施
• ケースの洗い出し:
  • 予約作成(処方箋事前送信予約・オンライン服薬指導予約・店頭受付)
  • 予約更新(日時変更・ステータス変更・患者情報変更・メモ追記)
  • 予約キャンセル(ユーザー操作・自動キャンセル・管理者操作)
• 動作確認の観点:
  • イベントが正しく発火されるか(Pub/Subにメッセージがパブリッシュされることを確認)
  • イベント内容が正しいか(薬局ID・予約ID・イベントタイプが正確に設定されていることを確認)
  • Firestoreが更新されるか(該当薬局のドキュメントが更新されることを確認)
  • フロントエンドが検知するか(画面上で変更が反映されることを確認)
• リグレッションテストとの擦り合わせ:
  • 既存のリグレッションテストで今回洗い出したイベント発生ケースがカバーされているか確認
  • カバーされていないケースがあれば新たにテストケースを追加
  • イベント発火の確認をリグレッションテストの検証項目に追加
• 本番リリース後のイベント発火漏れはゼロを達成

■ 7. 導入結果

• 定量的効果:
  • 予約検索APIの秒間リクエスト数は約2,000/秒から約1,000/秒へ50%削減
  • DBコストは30%削減
  • ネットワークトラフィックは大幅削減
• 定性的効果:
  • リアルタイム性の向上で従来は最大30秒の遅延があったが予約の変更がほぼリアルタイムで画面に反映
  • システム安定性の向上でポーリングによる定期的な負荷スパイクがなくなりデータベースへの負荷が平準化
  • 開発者体験の改善で各コンポーネントの責務が明確でデバッグや機能追加がしやすくなった

■ 8. 運用上の考慮事項

• 成功要因:
  • 段階的なリリースでまずは一部の薬局から段階的に展開し想定外の問題があった場合の影響範囲を限定
  • 監視体制の整備でPub/Subの未処理メッセージ数・Cloud Tasksの実行遅延・Firestoreの読み取り/書き込み数・フロントエンドからのAPI呼び出し数を監視
  • チーム内での知識共有で新しいアーキテクチャについて設計の意図や運用方法をドキュメント化し属人化を回避
• 留意すべき事項:
  • イベント欠損への対策としてPub/Subの再送機能を活用(デッドレターキューの設定)
  • 順序保証の考慮で分散システムにおいてはイベントの到着順序が発生順序と一致するとは限らない
  • Firestoreコストの試算で導入前に試算を行いトータルでコストメリットがあることを確認

■ 9. 今後の展望

• スロットリング間隔の動的調整で時間帯やイベント発生頻度に応じて動的に調整することでさらなる最適化が可能
• 他システムへの水平展開で今回得られた知見を他のポーリング処理を行っているシステムにも展開予定

(2025/12/16)

「状態」ではなく「変化（イベント）」を保存したい

• 「状態」ではなく「変化（イベント）」を保存したい

要約:

■ 1. 記事の背景と概要

• 履歴というデータを取り扱うことのために考えていること・戦い方について整理した内容である
• 履歴のデータはとても重要になる場合があり履歴管理や監査証跡・時点復元・法令対応などで「過去の状態を正確に残したい」という要件が発生することがある
• この記事の概要:
  • 「状態」の保存は一見シンプルだが履歴要件が入ると破綻しやすい
  • Bi-temporalは強力な設計手法だがクエリ・運用の複雑さが課題になりやすい
  • Event Sourcingは「変化」を中心に据えることで履歴が自然に残すことができる
  • ただしRead ModelやVersioningなど別の複雑さとのトレードオフがある

■ 2. 一般的なRDB設計の問題点

• ほとんどのRDBで管理されているデータは「現在の状態」だけを保存するように設計されている
• このテーブルで「注文をキャンセルした」という履歴を残そうとすると以下の方法が考えられる:
  • 方式A:変更前スナップショット方式
  • 方式B:ステータス更新＋別途「変更履歴テーブル」にINSERT
  • 方式C:有効期間を持たせるテンポラルテーブル方式

■ 3. 方式A:変更前スナップショット方式の問題点

• 変更前の状態だけを履歴テーブルに保存する方式である
• 悩みポイント:
  • 「何に変わったか」が分からない:変更前の状態しか保存していないため履歴テーブルだけを見ても「何に変わったのか」が分からない
  • 時点復元が困難:valid_toがないのでどの履歴レコードがいつまで有効だったか分からない
  • 変更理由・操作内容が残らない:なぜ変更したのかどんな業務操作だったのかこれらのコンテキストが失われるため監査証跡としては不十分になる
  • 連続した変更の追跡が複雑:A→B→Cと3回変更された場合履歴から「2025-01-02時点の状態」を導くには推論する必要がある

■ 4. 方式B:ステータス更新＋変更履歴テーブルの問題点

• ステータス更新と同時に変更履歴テーブルにINSERTする方式である
• 悩みポイント:
  • ステータス以外の属性変更が追跡できない:この方式はstatusの変更だけを追跡しておりtotal_amountが変更された場合その履歴は残らない
  • 元テーブルと履歴テーブルの整合性が保証されない:2つのテーブルを別々に更新するためアプリケーションコードで「必ず両方更新する」ルールを徹底する必要がある
  • 履歴の正しさを検証できない:元テーブルの現在のstatusと履歴テーブルの最新to_statusが一致している保証もなく履歴の連続性も保証されない
  • 「作成」と「削除」の表現が曖昧:注文が最初に作成されたときのfrom_statusや注文が削除されたときのto_statusをどうするかが曖昧になる
  • 時点復元は改善されるが完全ではない:status以外の属性の時点復元はできない

■ 5. 方式C:テンポラルテーブル方式の問題点

• 有効期間を持たせるテンポラルテーブル方式である
• 悩みポイント:
  • 「現在の状態」を取得するクエリが複雑になる:シンプルだったSELECTが毎回時間条件付きになる
  • 関連テーブルもテンポラルにすると「ある時点での注文とその明細」を取得するクエリがより複雑になる
  • 更新では「終了+INSERT」の2ステップが必要:必ずトランザクションで実行しないと不整合が起きてしまいアプリケーションコードも煩雑になる
  • 誤入力の訂正で監査証跡が失われる:過去の行を直接UPDATEすることになり「元々何が記録されていたか」が消えてしまう
  • Valid Timeだけでは「いつシステムがその情報を認識していたか」が分からない:これを解決するにはSystem Timeも必要になりBi-temporalへの対応が求められる
  • 「同時点で複数有効」を防ぐ制約が難しい:標準的なUNIQUE制約では表現できない

■ 6. Bi-temporalの構造と利点

• Bi-temporalテーブルの各行は通常4つのタイムスタンプを持つ:
  • Valid From/To:現実世界でその事実が有効な期間
  • System From/To:データベースがその事実を知っていた期間
• この構造により「現在の知識に基づくと先月の価格は10000円であるしかし先週時点の知識では先月の価格は9800円であると認識していた」という複雑な問いに答えることができる

■ 7. Bi-temporalの複雑さと問題点

• 誤入力訂正が入ると「過去のSystem Timeを書き換える」必要がある
• 1つの訂正で複数行の更新・追加が必要になる:「金額10000円→9800円」という1つの訂正で既存の2行を終了し新しく2行をINSERTし合計4行の操作が必要になる
• 「何が訂正されたか」の追跡が困難:system_toで終了した行と新しくINSERTした行の関連付けは暗黙的であり訂正理由も記録されない
• クエリもさらに複雑になる:「2025-01-03時点で業務上もシステム上も有効だった注文一覧」を取得するだけで複雑なクエリになる
• Bi-temporalにテーブルを紐づけるとさらに複雑になる:紐づく先のテーブルもBi-temporalにしないと整合性が取れなくなる

■ 8. 状態中心の設計が難しくしている理由

• ここまで見てきた方式やBi-temporalなどすべてに共通するのは「状態」を保存しようとしていることである
• 状態とは「ある時点での結果」である
• 状態を保存するということは結果だけを切り取って保存することになる
• そのため以下の情報が失われる:
  • なぜその状態になったのか
  • どうやってその状態になったのか
  • 誰がその変化を引き起こしたのか
• 履歴を残そうとすると失われた情報を補うために追加のカラムやテーブルが必要になり結果として設計が複雑化していく

■ 9. 変化を中心に考えるイベント中心の発想

• 「状態中心」の発想を変える:
  • イベント中心の発想では「何が起きたか?」を記録する
  • 状態を知りたい場合はイベントを順番に適用して現在の状態を導出する
• イベントは「起きた事実」そのものである
• 状態とイベントの比較:
  • 状態は結果でありイベントは原因である
  • 状態は変わりうるがイベントは変わらない
  • 状態は「今どうなっているか」でありイベントは「何が起きたか」である
  • 状態はスナップショットでありイベントは事実の記録である

■ 10. 状態中心とイベント中心の具体的比較

• 状態中心の場合:
  • 「各時点での状態のスナップショット」を保存する
  • どの行がどう関連しているか何が起きたのかこのデータだけでは分かりにくい
• イベント中心の場合:
  • 「何が起きたか」をそのまま保存する
  • 何が起きたかなぜ起きたか誰が起こしたかすべて明示的に残すことができる
  • occurred_atは業務上発生した時刻でsystem_fromはシステムが記録した時刻である

■ 11. 現在有効なデータの取得方法

• 状態中心の場合はWHERE句で時間条件を指定するクエリを実行する
• イベント中心の場合は2つの方法がある:
  • 方法1:イベントをリプレイして導出する:イベントが少なければ十分だがイベントが膨大になるとリプレイのコストが高くなる
  • 方法2:Read Modelを使う:現在の状態を別テーブルに保持しておきイベント発生時に更新する
• Read Modelはイベントから導出された状態のキャッシュでありいつでもイベントから再構築できるため要件に応じて自由に設計できるのが特徴である

■ 12. Event Sourcingの課題1:最新状態の取得

• イベントをリプレイして状態を導出する方式はイベント数が少なければ問題ないが数万〜数十万件になると現実的ではなくなる
• 解決策としてSnapshotとRead Modelを導入することが考えられる:
  • Snapshot:定期的に「ある時点での状態」を保存しておきそこからリプレイを開始する
  • Read Model:現在の状態を別テーブルに保持しイベント発生時に更新する
• ただしSnapshotやRead Modelを導入するとシステムの複雑性は増していく

■ 13. Event Sourcingの課題2:有効期間の表現

• Event Sourcingは「何が起きたか」を記録するが「いつからいつまで有効だったか」という期間情報は直接表現しない
• 単純に「最新の状態」を持つRead Modelだけでは不十分で期間情報を持った別のRead Modelが必要になる
• Bi-temporalが必要だった理由は「訂正時に過去の認識を残すため」だったがEvent Sourcingではイベントは不変で追記のみであり訂正もイベントとして記録される
• つまりイベントストアがシステム時間の役割を担っているのでRead Modelは業務上の有効期間だけを持てば十分である

■ 14. Event Sourcingの課題3:イベントスキーマのVersioning

• イベントは不変なので一度保存したイベントのスキーマを変更することはできない
• しかしビジネス要件はフェーズが進むにつれて変化していく
• 過去のイベントを読み込むとき新しいコードで正しく処理するにはv1からv3に変換するロジックであるUpcasterパターンを用意する必要がある
• Upcasterパターンとは主にEvent Sourcingで使われる設計パターンで過去に保存された古い形式のイベントを現在の最新のイベント形式に変換するための仕組みである
• 上記以外に「過去のイベントを物理的に新しいスキーマに書き換える」アプローチもあるがEvent Sourcingの原則を破ることになり監査証跡としての価値が下がる可能性がある

■ 15. Event Sourcingの課題4:取り消しと訂正

• イベントは不変だが「このイベントは間違いだった」というケースは現実に発生する
• この問題に対応するためにCompensating Event補償イベントというものを導入する必要がある
• 「取り消し」や「訂正」も新しいイベントとして記録する
• ただし「どこまで遡って訂正するか」「関連するイベントへの影響をどう扱うか」は慎重に設計しないと破綻してしまう

■ 16. Event Sourcingの課題5:結果整合性とその他

• イベント発行からRead Modelの更新は同期的に行われるわけではないためタイムラグがある
• そのためユーザーが「保存したのに反映されていない」と感じるStale Read問題が発生する
• UI側で楽観的更新を行ったり同期的な読み取りが必要なケースではイベントストアから直接リプレイすることで対応する
• 他にも「イベント設計」「Read Modelの設計と更新ロジック」「Snapshot戦略」「エラーハンドリング」など考えないといけないことはたくさんある

■ 17. Event Sourcingを採用すべきかの判断

• Event Sourcingは「履歴」という要件にはとても強力だがトレードオフは必ず発生する
• メリット:
  • 完全な履歴が自動的に残る
  • 任意の時点の状態を復元できる
  • 「何が起きたか」が明示的
  • 監査証跡として価値がある
• デメリット:
  • 最新状態の取得に工夫が必要
  • Read Modelの設計は難しい
  • イベントスキーマのVersioningへの対応が必要
  • 結果整合性への対応が必要
• Bi-temporalのようなテンポラルデータモデルで運用し続けるのも難しい
• 少なくとも「履歴」という要件が厳しいときにはEvent Sourcingを1つの選択肢として検討してみると良いかもしれない
• Event Sourcingを導入するときに一番大切なのは「やり切ると決めたら最後までやり切る」という気持ちである

(2025/12/16)

【Go言語】死なないジョブワーカー処理～数万並行処理でも落ちない設計～

• 【Go言語】死なないジョブワーカー処理～数万並行処理でも落ちない設計～ | レバテックラボ（レバテックLAB）

(2025/12/15)

楽観的同時実行制御でいいかな？

• 楽観的同時実行制御でいいかな？

要約:

■ 1. 楽観的同時実行制御の普及と盲信への警鐘

• ADO.NETを使うと楽観的同時実行制御を容易に実装できる
• 超有名な「楽観的ロックでいいじゃん!」のお陰で楽観的同時実行制御は特にWebアプリケーション開発では広く使われている
• 大概のアプリケーションでは楽観的同時実行制御で十分なのかもしれない
• しかし「楽観的同時実行制御こそが正義だ」と盲信されかねない空気に警鐘を鳴らす必要がある

■ 2. 悲観的ロックと楽観的ロックの定義

• 大西彰さんの記事「楽観的ロックでいいじゃん!」による定義:
  • 悲観的ロック:ステートフルなロックで更新したい対象のリソースを照会して取得した直後から更新が終わるまでロックを維持することでロック時間は長時間でロックは独占的
  • 楽観的ロック:ほぼステートレスなロックで更新したい対象のリソースを照会してもロックはかけず本当に更新が必要になった段階でその対象リソースをロックすることでロック時間は短時間でロックは非独占的

■ 3. 同時実行制御の概念による整理

• 悲観的同時実行制御:
  • 衝突が頻繁に発生する事が前提の同時実行制御
• 楽観的同時実行制御:
  • 衝突が殆ど起こらない事が前提の同時実行制御
• 楽観的同時実行制御は「競合・衝突が全くあるいは殆ど起こらないために衝突に関しては楽観的に考えてよい」ものである
• 悲観的同時実行制御は「競合・衝突が殆どにおいて発生しトランザクション量も多いため衝突に関しては悲観的に考えなければならない」ものである

■ 4. よくある勘違いとその弊害

• 肝要でありよく勘違いされるのが「DBMSのロックメカニズムを使うことが悲観的同時実行制御である」という事である
• そのせいか長時間ロックを回避する為にWebアプリケーション開発では楽観的同時実行制御を大前提に設計をしてしまう事が多々ある
• しかしトランザクション量が多く競合・衝突が頻発するにも関わらず楽観的同時実行制御を行ってしまうと極端に使い勝手の悪いアプリケーションになってしまう
• 予約システムのように仮予約されたチケットがいざ購入の段になって「他の人に獲られました」ではクレームの嵐である
• 仮予約チケットは他の人が見れないようにロックする必要がある
• かといって長時間トランザクションにDBMSのロックメカニズムを使う訳にはいかない

■ 5. 業務排他制御という解決策

• 独力で同時実行制御を作り込む事が考えられる
• 「.NETエンタープライズWebアプリケーション開発技術大全Vol.5トランザクション設計編」では「業務排他制御」と表現されている
• 「悲観的ロックを使わないで悲観的同時実行制御を行う」とでも表現できる
• テーブルに排他制御専用の列を2つ3つ追加し編集ステータスや編集開始日時などをチェックすれば良いだけで実装自体は比較的容易である
• ただし実装は容易でも業務フローの難易度は高くなる

■ 6. Webアプリケーションと楽観的同時実行制御の適性

• クライアントユーザー数が多いであろうWebアプリケーションの方が楽観的同時実行制御には向いていないとさえ言える
• ただしユーザー数が多くても大半のユーザーが参照アクションしか行わないのであればその限りではない
• 楽観的同時実行制御が向いているのはマスタデータメンテナンス等を行うクライアントユーザー数の限られたWindowsアプリケーション等ではないか
• もちろんWebアプリケーションでもあり得る
• 「Webアプリケーションでは悲観ロックはあり得ない楽観同時実行制御こそが正」と決めつける前によくよく仕様を揉んでみるべきである
• その要件は楽観的に考えられるかを検討する必要がある

MEMO:

• まぁ、それはそう
• CMSのような特定のコンテンツやリソースを複数人から変更できるシステムの場合は「業務排他制御」を検討するべきだろう
• 業務システムの文脈だと例えば電子カルテとか物流システムの在庫・出庫管理とか、ECサイトのカート機能などがそれ

(2025/12/14)

楽観的ロックでいいじゃん！

• 楽観的ロックでいいじゃん！ [404 Notfound]
• インターネット・アーカイブ

要約:

■ 1. 排他制御の2つの方法と歴史的背景

• データベースのトランザクション処理を実行する場合対象となる行の排他制御が必要である
• 排他制御は同時実行処理において必要不可欠だが使い方を誤ると簡単なはずの処理が難しくなる可能性がある
• リソースをロックする方法は2種類ある:
  • 悲観的ロック
  • 楽観的ロック
• スタンドアロンでプログラムが動いていた時代は1ユーザ・1プログラム・1データのみが存在するため排他制御を考えなくてもアプリケーションの開発は行えた
• コンピュータがネットワークでつながるようになってデータが複数のユーザからアクセスされるようになると排他制御を無視してプログラムを書くことはできなくなった
• DBMSが利用できるようになってファイルレベルでの同時実行制御からデータベースレベル・テーブルレベル・ページレベル・行レベルといったロックのメカニズムが提供された
• 現在はHTTPという不安定なプロトコルの上でのトランザクションが求められている

■ 2. 悲観的ロックと楽観的ロックの定義

• 悲観的ロック:
  • ステートフルなロック
  • 更新したい対象のリソースを照会して取得した直後から更新が終わるまでロックを維持する
  • ロック時間は長時間でロックは独占的
• 楽観的ロック:
  • ほぼステートレスなロック
  • 更新したい対象のリソースを照会してもロックはかけず本当に更新が必要になった段階でその対象リソースをロックする
  • ロック時間は短時間でロックは非独占的

■ 3. 悲観的ロックのメリットとデメリット

• 悲観的ロックは「俺様が更新するリソースは全部俺様のものだ他人にはアクセスさせないぞ」というものである
• DBMS上でロックを実行したユーザアカウントのコンテキストでロックが解放されるまで排他制御が実行され続ける
• メリット:
  • ロックを取得したユーザが見ているリソースが他者から変更されないことを保障する
• デメリット:
  • ロックが維持されている間他のユーザはそのリソースにアクセスできない
  • ロックを維持することによりデッドロックを引き起こしやすくなる可能性が高い
• この記事で提示したいのは「そのロック本当に悲観的じゃなきゃいけないの?」という疑問である

■ 4. 楽観的ロックで十分な理由1:認証と認可

• ユーザの認証と認可をきちんと処理していれば更新の競合はほとんどありえない
• データベースを設計する際に考えなければならないのは「ユーザの認証」と「ユーザの権限」である
• 悪い例は何でもできる特権を持ったユーザアカウントですべてのデータベースオブジェクトを作りアプリケーションからのアクセスもそのアカウントで実行してしまうこと
• 権限レベルの段階:
  • Level0:アクセス許可なし
  • Level1:読み取り専用
  • Level2:読み取り・書き込み可能
  • Level3:特定データベースの変更・構成可能
  • Level4:全権限の所有
• 理想的にはデータベース設計者がデータベースを完成させたら権限をDBAに委譲してデータベース設計者からすべての権限を奪うのが望ましい
• Level0からLevel2までの範囲で権限を設定していれば無駄なトランザクションの発生を抑えられる

■ 5. 楽観的ロックで十分な理由2:業務プロセスとワークフロー

• 業務上同一行を複数人で同時に更新するプロセスはほとんど考えられない
• 業務システムにおいて情報が更新されるためには何らかのビジネスプロセスと対応している必要がある
• 例えば人事情報の変更を考えた場合人事部に変更届を提出するのが普通である
• 何らかの届けが提出されそれが認知されて処理されるにあたっては「審査」というワークフローを通る必要がある
• 審査が通るまではトランザクション処理は実行されることがない
• このような「変更」－「審査」といった業務フローの場合同じ行が複数の人から同時に更新されることは起こりえない
• 業務における「変更」には必ず権限を持つ人の「承認・審査」が伴うはずである
• この制約がある限り「変更」は即座には実行されず「変更要求」－「承認・審査」－「変更実行あるいは変更の却下」の流れになる

■ 6. 楽観的ロックで十分な理由3:対照表による履歴管理

• 動的に変化するデータを対照表の形で作成してしまえば追加のみなのでロックは必要ない
• 例えば小売店における商品の売価を考える
• 商品というエンティティに売価を入力して更新するやり方は後に営業分析する際に売価の動きを追跡することが難しくなる
• 売価を対照表で管理すると商品ID・店舗ID・発生日時・イベント・売価などで管理できる
• このモデルに従うと商品の売価においては変更が生じてもデータベース側では「行の追加」しか発生しない
• 変更イベントが発生しても商品の売価という対照表の行を更新するということは起こりえない
• したがって楽観的ロックすら必要がない

■ 7. 楽観的ロックで十分な理由4:データの所有権管理

• データの所有権を管理すれば更新の競合はほとんどありえない
• アプリケーションによって行に所有権を設定し所有権のある行だけを処理の対象とすることを考える
• 所有者IDをUPDATEステートメントのWHERE句に含めることで他の所有者の行を更新することがなくなる
• 行の所有者を明確にしているので悲観的ロックにすることなく楽観的ロックで十分になる
• しかし所有者の変更を追跡しようとすると多対多のモデルになるので結局は対照表の構造に帰着する
• したがって理由3の繰り返しになり行を更新するという話がなくなる

■ 8. アーキテクチャの変遷とトランザクション軽量化の重要性

• 時代はメインフレームによる集中処理からクライアントサーバの分散型・Webシステムにおける集中処理型・スマートクライアントによる分散型と集中・分散を繰り返している
• どのようなアーキテクチャが採用されるにせよコンピュータのメモリは有限でありデータをどこかの2次記憶装置に永続化する必要がある
• 工夫次第でトランザクションを軽量なものにすることができる
• 最終的に一番負荷がかかるのはデータベースが稼動しているサーバである
• スケーラビリティやパフォーマンスを求めるのであればいかにサーバリソースを消費しないで同時実行性を高めるかということにつきる

■ 9. 実体験に基づく楽観的ロックの優位性

• 12-13年前にCA-ClipperというXbaseのシステムで悲観的ロックモデルによりアプリケーションを作成した際にこのロックモデルの欠点がよくわかった
• ネットワークのトラフィックの増大・アプリケーションパフォーマンスの低下を招くことが低性能のPCで証明された
• 結局楽観的ロックに切り替えられるようクライアントでトランザクション用のキューを作りサーバ側にバッチアップデート要求を出すような作りにした
• MS-DOSのファイルシステムレベルでの排他制御も経験したがロック時間が長くなればパフォーマンスが低下することがわかった
• ロック時間は短いほうがいい
• SQLを利用するDBMSにおいても結局理屈は変わらない
• ユーザのロールモデル・業務上のワークフロー・データベースの設計方法を工夫するだけでも「悲観的ロック」から逃れることができる
• SOAのアプローチになってサービスとの疎結合が求められると「楽観的ロック」中心のアプローチでないとサービスの開発ができない
• 永続化処理を軽量にすることが今後も求められる

MEMO:

• 元記事は2004年頃なので現在と比べると前提としている条件がかなり違う感じもある

(2025/12/14)

予約処理で結果整合を実現するための実装パターン

• 予約処理で結果整合を実現するための実装パターン - 一休.com Developers Blog

要約:

■ 1. 背景と用語定義

• 一休.comの宿泊予約のシステムで予約部分のリニューアルを進めている
• リニューアルの中で取り組んだ予約処理の結果整合を実現するための実装について説明する
• 用語の定義:
  • トランザクション:予約処理全体を指す
  • ローカルトランザクション:カード決済や在庫引当と言った個々の処理を指す
  • ロールバック:DBトランザクションのロールバックに限らずローカルトランザクションを補償トランザクションにより論理的にロールバックすることも指す
  • 補償トランザクション:ロールバックを実現するための手段として利用する

■ 2. 要件

• 宿泊予約トランザクションの中で発行される主なローカルトランザクション:
  • 在庫引当
  • カード決済
  • 一休ポイント登録
  • サイトコントローラーへの通知
  • ユーザーへのメール通知
• これに加えて予約データの永続化がある
• 少なくともこのようなローカルトランザクションを予約全体として結果整合させる必要がある

■ 3. Sagaパターンの概要

• 複数のローカルトランザクションを結果整合させるためのパターンとして有名なものにSagaパターンがある
• Sagaパターンは補償トランザクションを利用してローカルトランザクションをロールバックすることそしてそのローカルトランザクションの実行やロールバックを全体で結果整合させるための設計パターンである
• Sagaパターンにはいくつか種類がある:
  • コレオグラフィパターン:ローカルトランザクション同士が相互に協調しあって全体をコントロールする
  • オーケストレーションパターン:中央集権的なオーケストレータが全体のローカルトランザクションの実行やロールバックをコントロールする
• 更に詳しく各ローカルトランザクションの通信の同期や非同期整合性が結果整合かアトミックかを加えた分類もある
• 一方でその具体的な実装に踏み込んだ説明は多くない
• この記事では具体的なパターンを網羅的に説明したりパターンの中で何に該当するのかと言った体系的な説明というよりは実際自分たちがどのような実装をしているのかというところを説明する

■ 4. リニューアルの実際

• 予約リニューアルに伴いドメインモデルを捉えなおし合わせて技術的な詳細についても見直せる部分は見直してきた
• 今回紹介する実装パターンについても既存のシステムで大きな問題なくここまで運用されてきたものであるため抜本的に設計しなおしたというものではない
• 既存のシステムをあらためて解釈し整理できる部分は整理していき改善できる部分は改善したところこのような形に落ち着いたというのが実際のところである

■ 5. ピボットトランザクションの決定とローカルトランザクションの分類

• トランザクションの成否を決定するローカルトランザクションのことをピボットトランザクションと呼ぶ
• ピボットトランザクションが失敗した場合そのトランザクション全体も失敗として扱われる
• その場合ピボットトランザクション以前に実行したローカルトランザクションも失敗として扱う必要がある
• これを決定し各ローカルトランザクションはピボットトランザクションよりも前に実行されるのか後に実行されるのかを明確にすることで全体の設計が見通しやすくなる
• ピボットトランザクションは予約データの永続化と捉えた
• ローカルトランザクションの性格:
  • カード決済や在庫引当はそれが失敗したら予約も失敗として欲しい
  • ユーザーへの予約通知メール送信やサイトコントローラーへの予約通知についてはそもそも予約が失敗していたら実行して欲しくない
• ピボットトランザクションよりも前に実行するローカルトランザクションは予約の成否に応じて補償トランザクションでロールバックする
• ピボットトランザクションよりも後に実行するローカルトランザクションはピボットトランザクションが成功している以上は最終的に成功として扱いたいものになる
• 後者の最終的に成功として扱いたいを実現するパターンとしてはTransactional Outboxパターンなどがある
• このoutboxはいわゆるメールの送信トレイを意味していて送信時にはoutboxのみを作っておいてoutboxをもとにしてリトライするなどで最終的に送信されることを目指すというものである
• サイトコントローラーへの送信などはこのTransactional Outboxパターンを利用している
• 具体的にはピボットトランザクションとなる予約データの永続化のトランザクションの中でサイトコントローラー用のoutboxのデータを作成している
• どうしようもないものは人手での運用にまわしているものもある

■ 6. 補償トランザクションの実装パターンと補償ログの導入

• トランザクションが失敗として定義された場合実行されたローカルトランザクションに対し補償トランザクションを実行していくことになる
• この際ローカルトランザクションが実行済みであるということを把握する必要が出てくる
• そのために実際のローカルトランザクションを実行する前に補償ログというデータを登録する
• 補償ログというのは一般用語ではなく造語である
• 概念としてはデータベースのUNDOログに近い
• ローカルトランザクションが成功した後にピボットトランザクションが失敗したケースを考える
• この場合補償ログがあればそれに対応する補償トランザクションを実行するということになる
• 補償ログ・補償トランザクションを実装する際に重要なポイント:
  • ポイント1:補償ログはローカルトランザクションの実行前に登録する:
    • 補償ログはローカルトランザクションの実行前に登録する必要がある
    • 仮にローカルトランザクションの実行の後に補償ログを登録するという実装にしていた場合ローカルトランザクションの実行には成功したが補償ログの登録には失敗したというシチュエーションを考える必要が出てきてしまう
    • これは基本的にローカルトランザクションのロールバックが不可能になってしまう
    • したがってローカルトランザクションの実行前である必要がある
    • UNDOログを例に出したが実行前に登録する必要があるというのもデータベースのWrite-Ahead Loggingに似た考え方である
    • 補償ログの登録に失敗した場合そのローカルトランザクションは実行せず失敗として扱う必要がある
  • ポイント2:ローカルトランザクション実行前に補償トランザクション実行に必要な情報がそろっている必要がある:
    • 補償ログには補償トランザクション実行に必要なIDなどの情報を登録しておく
    • したがってローカルトランザクション実行前に補償ログを登録するということはローカルトランザクション実行前に補償トランザクション実行に必要な情報がそろっている必要があるということになる
    • 例えばローカルトランザクションの実行結果としてあるリソースのIDが手に入りそのIDが補償トランザクションのリクエストパラメータとして要求されるようなAPIではこの要件を満たすことが出来ない
    • 補償ログには補償トランザクション実行に必要十分なIDなどの保存にとどめ逆に個人情報等は保存しないようにする
  • ポイント3:補償ログはピボットトランザクションの成功後に削除する:
    • 補償トランザクションを実行する場合補償ログは補償トランザクションの実行後に削除する必要がある
    • 補償ログの登録の話と同じく仮に補償ログを削除してから補償トランザクションを実行するようにした場合補償トランザクション実行に失敗した場合に補償トランザクションを再度実行できなくなってしまう
    • さらに補償ログの削除はピボットトランザクションの成功後に削除する必要がある
    • ピボットトランザクションがトランザクション全体の成否を決定するためピボットトランザクションが成功するまではローカルトランザクションをロールバックする必要がある可能性があるため
    • したがってピボットトランザクションが成功するまでは補償ログを削除することは出来ない
  • ポイント4:補償トランザクションは冪等にする:
    • 補償トランザクションは冪等である必要がある
    • これは補償トランザクション実行に失敗した場合や補償トランザクションに成功した後補償ログの削除に失敗した場合などで再度補償トランザクションが実行されうる状態になるためである

■ 7. ピボットトランザクションとピボットマーカーの導入

• ローカルトランザクションの補償ログとそれを利用した補償トランザクションの実行のための実装パターンを説明した
• ピボットトランザクションとローカルトランザクションを関係づけることでトランザクション全体の結果整合性を実現することが出来るようになる
• ピボットトランザクションに対してもローカルトランザクションと同様それが進行中であることを示す必要がある
• ピボットトランザクションに対する補償トランザクションは存在しないため補償ログではなくピボットマーカーと呼ぶことにする
• このピボットマーカーも一般用語ではなく今回導入した造語である
• このピボットマーカーをローカルトランザクションの開始前にまず作成しそしてピボットトランザクションとアトミックに削除することで全体としての結果整合性が実現できることになる
• 重要な点:
  • ポイント1:ピボットマーカーはピボットトランザクションとアトミックに削除する:
    • トランザクション全体で結果整合性を担保する上でこれが最も重要である
    • ピボットマーカーはピボットトランザクションとアトミックに削除する必要がある
    • これによりピボットマーカーが存在している=ピボットトランザクションが完了していないピボットマーカーが存在しない=ピボットトランザクションが成功したと解釈出来るようになる
    • ピボットマーカーを予約データ永続化先と同じDBに保存し予約データ永続化と同じDBトランザクションでピボットマーカーを削除することでこの要件を満たしている
  • ポイント2:補償ログとピボットマーカーに親子関係を設ける:
    • 補償ログとピボットマーカーに親子関係を設けることでローカルトランザクションの補償トランザクションの実行要否とピボットトランザクション成否を結びつけることが出来る
    • これによりトランザクション全体の結果整合性を担保することが出来る
    • ピボットマーカーが存在していれば実行済みのローカルトランザクションが存在する可能性がありロールバックする場合はローカルトランザクションに対して補償トランザクションを実行する必要がある
    • ピボットマーカーが存在しなければトランザクション全体を成功とみなすためローカルトランザクションに対して補償トランザクションを実行する必要はないと解釈することが出来る
  • ポイント3:補償トランザクションを実行する際は常にピボットマーカーを起点に実行する:
    • 常にピボットマーカーから補償ログを辿って補償トランザクションを実行するようにする
    • こうすることでピボットマーカーが存在している場合にのみ補償トランザクションが実行されるようになる
    • つまりピボットトランザクションが成功した場合は絶対に補償トランザクションが実行されることはないとすることが出来る

■ 8. トランザクション全体のロールバックの例

• ここまでの実装でトランザクション全体としてロールバックを冪等に実行することが出来るようになる
• ローカルトランザクションの一部が失敗した場合を考える
• ロールバックの流れ:
  • ピボットマーカーが作成され
  • その後のローカルトランザクション1と2と3と実行されるがローカルトランザクション3が失敗し
  • ローカルトランザクション1と2に対して補償トランザクションを実行してロールバック
  • 補償ログ削除
  • 最後にピボットマーカーを削除
• このようにしてトランザクション全体をロールバックすることが出来た
• このプロセスは冪等に実行することが可能である
• ロールバック処理では複数ある補償トランザクションのうちのひとつの実行に失敗したりすることがあり得る
• そのほかサーバーのプロセスごと落ちたなどでロールバック全体が完了しなかった場合にも実行する必要のある補償トランザクションを確実に実行する必要がある
• そのため一連のロールバック処理を予約の失敗時にサーバーから同期的に実行することに加えて定期的に残っているピボットマーカーを見てサーバーから実行したものと同じロールバック処理を再実行するジョブをCloud Run Jobsで用意している
• ロールバック処理を冪等に実行出来るようにすることでこのように確実にロールバックが完了するように実装することが出来る

■ 9. 制約

• ここまで説明してきた実装パターンが適用出来る前提:
  • ローカルトランザクションが同期的に実行できること:
    • ここでいう同期的とはローカルトランザクションの成否がピボットトランザクション実行までに確定していることを指す
  • ローカルトランザクション同士が強く結合していないこと:
    • 順序制約はあってもよいが補償トランザクションに必要な情報が前段の実行結果に依存しないこと
    • 実行前に補償ログへ必要情報を確定できること
  • トランザクション全体としての一貫性は結果整合で良いこと:
    • 予約失敗の場合には一時的にでも在庫が引当されてはいけないと言った制約がある場合はこの実装パターンには向かない
• これよりも厳しい要件が必要な場合この実装パターンそのままは適用できない

■ 10. この実装パターンの特徴と利点

• 紹介した実装パターンの特徴や利点:
  • Sagaパターンなどを意識せずドメインロジックの実装が可能:
    • アプリケーションロジックを実装する際はこのようなことを気にせずに進められるならそれに越したことはない
    • ここまで説明してきた実装パターンは主にI/Oを実行するレイヤでのみ気にすれば良いものになっている
    • したがってドメインロジックとI/Oを適切に分離できていればここまでの補償トランザクション周りの実装についてもドメインロジックを実装する際に意識する必要はなくなる
  • ローカルトランザクションの追加が容易:
    • ローカルトランザクション毎に補償ログ・補償トランザクションの実装を用意すればローカルトランザクションを追加することは比較的容易である
    • 実際に予約リニューアルプロジェクトを進める中で段階的にローカルトランザクションを大きな労力なく追加していくことが出来た
  • ローカルトランザクションの変更が容易:
    • ローカルトランザクションそれぞれの独立性が高いためローカルトランザクションの実行タイミングや順序などが変更しやすくなる
    • 例えば在庫引当はもっと早いタイミングに実行してしまいたいと言った変更である

(2025/12/14)

SQLite JSON Superpower: Virtual Columns + Indexing

• SQLite JSON Superpower: Virtual Columns + Indexing - DB Pro Blog

要約:

■ 1. SQLiteの再評価とDB Proでの活用

• DB ProではSQLiteを愛用している
• SQLiteには制限があるが弱点ではなく適切にデプロイされ慎重にチューニングされればプロダクションで使用できる
• SQLiteは過去数年で復活を遂げている
• libSQLやTursoへのフォークやPocketBaseのような人気バックエンドフレームワークでの採用などが見られる
• DB Pro自体のローカルデータベースもSQLiteで動作している
• DB Proのユースケースにはこれ以上の代替手段は存在しない
• 過去3ヶ月間SQLiteを本格的に使用してきた結果多くのことを学んだ
• SQLiteのより興味深い機能とニュアンスを扱う短いブログ投稿シリーズを計画している

■ 2. SQLiteのJSON機能の発見

• SQLiteにはJSON関数と演算子があることを最近まで知らなかった
• Hacker Newsのコメントでbambaxという人物がSQLiteのJSON演算子について述べた内容を発見した
• bambaxのコメントの要点:
  • 各JSONドキュメントをそのまま1つのカラムに保存する
  • json_extractの組み合わせを使用してクエリしたい特定の情報を保存する仮想カラムを作成する
  • これらのカラムにインデックスを作成する
  • これにより超高速検索が可能になる
  • 挿入時にインデックス対象を選択する必要がなく必要なときにいつでも仮想カラムを追加できる
  • インデックスされていない生のJSONも検索できるが大規模コレクションでは時間がかかる可能性がある

■ 3. bambaxの提案する4つのステップ

• bambaxの提案を実際に試してみることにした
• DB Proのブログには埋め込みSQLite-in-the-browserコンポーネントがあるため動作例を作成した
• bambaxが述べている内容の分解:
  • JSONドキュメントを生のまま保存する
  • json_extractを使用して仮想生成カラムを作成する
  • これらの生成カラムにインデックスを追加する
  • 完全なB-treeインデックス速度でJSONをクエリする
• これによりインデックス戦略を事前に選択する必要がなくなる
• 後で新しいJSONフィールドでクエリする必要があることに気づいた場合は生成カラムを追加してインデックスを追加するだけで完了する
• データ移行もスキーマの書き換えもETLも不要で純粋な柔軟性が得られる

■ 4. 実装手順1:生JSONの保存

• まずJSONカラムを持つシンプルなテーブルを作成する
• JSONドキュメントは到着したそのままに自然に保存される
• スキーマの複雑な操作も不要である

■ 5. 実装手順2:仮想生成カラムの追加

• bambaxが魔法が起こると言っている箇所である
• 仮想生成カラムを追加する
• 生成カラムはオンデマンドで値を計算する
• これらは実際にはデータを保存しない
• 書き込みは発生しないと考えられる
• バックフィルも不要で即座に実行される
• 仮想カラムはクエリするたびにJSONデータからオンザフライで計算される

■ 6. 実装手順3:パフォーマンスのためのインデックス追加

• これがケーキのアイシングである
• インデックスを追加してこれらの仮想カラムを超高速にする
• 突然JSONが完全なインデックスサポートを持つ通常のリレーショナルカラムのように動作する

■ 7. 実装手順4:フルスピードでのクエリ

• クエリが非常に高速になる
• いくつかの例でそれを試すことができる

■ 8. 後からの新しいクエリパターンへの対応

• このパターンの最も強力な点の1つであると考えられる
• 後日JSONの形状が変わった場合でも別のカラムを追加して別のインデックスを作成するだけでよい
• 例えばuser_idでクエリする必要があることに気づいた場合:
  • ALTER TABLEで新しい仮想カラムを追加する
  • CREATE INDEXでインデックスを作成する
• 既存の行に触れることなく最適化される

■ 9. このパターンが強力な理由

• このパターンはSQLiteでJSONを扱う方法についての考え方を完全に変えた
• スキーマレスデータの柔軟性とリレーショナルデータベースのパフォーマンスとエルゴノミクスを組み合わせることができる
• 早期にコミットしすぎたり自分自身を追い込んだりすることなくこれを実現できる
• これらの小さなSQLiteスーパーパワーは他にもたくさん隠れている
• これは共有したい最初のものにすぎない

(2025/12/14)

実践ドメインモデリング！Modeling Forum 2025

• 実践ドメインモデリング！Modeling Forum 2025

(2025/12/13)

実践ADR

• 実践ADR - kawasima

Architecture Decision Records(ADRs)は、アーキテクチャ上の意思決定をドキュメントとして残す方法の1つです。Release It!の著者であるMichael Nygardのブログによって広まり、ThoughtWorks社の[Technology Rader https://www.thoughtworks.com/radar/techniques/lightweight-architecture-decision-records]でも「adopt」になっています。

(2025/12/13)

AIで生成した「やたら長文だが内容は薄い情報」とか「意味のある情報が抜けた要約文」を上司や同僚に...

• AIで生成した「やたら長文だが内容は薄い情報」とか「意味のある情報が抜けた要約文」を上司や同僚に送りつけるのはやめようね、の話。 - フジイユウジ::ドットネット

(2025/12/12)

技術的負債で生じるクラフトの4分類と対処法

• 技術的負債で生じるクラフトの4分類と対処法 - Agile Journey

(2025/12/12)

「マネジメントやるのもその育成も無理ゲー」を整理する

• 「マネジメントやるのもその育成も無理ゲー」を整理する｜MRYY

要約:

■ 1. マネジメントスキルの学びにくさ

• 多くの専門職ではロールモデル・スキルアップのロードマップ・キャリアが会社の仕組みとして整えられ社内の話題にもよく登る
• マネジメントを主たる業務にしている人にとってこの土台は薄く感じる
• 技術的な専門職の仕事は客観的な良し悪しで判断される
• 質の良い仕事とまずい仕事は自分も周囲も同じように認識できる
• 技術的な仕事は結果からの明確なフィードバックを得られやすい
• プログラミングなら間違っていればエラーが返ってくることによって間違いがはっきりする
• 人によって意見が分かれる高度な技術テーマであってもこれは人によって認識が異なるテーマであることは同意されやすい
• マネジメントは良し悪しで判断しにくい理由:
  • マネージャー同士が働く機会が限られている
  • マネージャーは少数者
  • 未経験者からの評価という非対称性
  • 好き嫌いや人間関係の相性
  • マネジメントとリーダーシップの混同
• 多くの専門職は同じ専門職と働く機会があるがマネージャーはマネージャーと一緒に働く機会は多くない
• 同じ職能から学びにくいという働き方の性質がある
• 職能組織はあっても職位組織はなかなかない
• マネジメントそのものが理解される機会が限られマネジメントとして素晴らしい仕事/悪い仕事は何かという判断の質は育ちにくい
• マネージャーは組織構造上少数者で少数者というだけでも悩みは深くなる
• 現場のメンバーから評価される際はマネジメント未経験者から評価されるという非対称性がある
• 好き嫌いや人間関係の相性もマネジメントへの理解を難しくする
• 本来異なるスキルであるマネジメントとリーダーシップがマネージャーという一つの役職にまとめられていることもよくある
• ある人にとっては良いマネージャーと評価されても別の人にとっては悪いマネージャーと評価される
• マネージャー本人にとってもどのようにすればよりよいマネージャーになれるのか分からなくなる

■ 2. 1950年代の職場環境

• 戦後復興のさなか中学校や高校卒業したばかりの若い人達は金の卵と呼ばれ企業はこぞって採用
• 人口動態において若者が多く若手が果敢にチャレンジする機会があった
• がんばれば昇格できる時代

■ 3. 1980年代の状況

• 戦後復興を乗り越えて高度成長期の栄華を極めた1980年代では1950年代の人材がベテランとなり企業組織の中核を担う
• 企業の成熟と共に組織の人数に対してキャリアアップの受け入れ先となる課長や部長といった職位が足りなくなる
• ポスト詰まりが常態化
• 組織階層を増やしてもポストが足りなくなり当時の若い人達にとってキャリアを積み上げる難易度が高くなる

■ 4. 1990年代の変化

• 企業規模の拡大の停滞が始まりポスト詰まりは更に悪化
• 第二次ベビーブーム世代が就職するタイミングでバブル崩壊が重なる
• 就職を希望する若い人が多いにもかかわらず企業は人を受け入れることができない状況
• 多くの若い人が正規雇用に付くことが難しくなる
• 正規雇用を得たとしてもライバルが多く昇進を手にする人は一握り
• 企業間競争よりも組織内の出世競争が激しくなる
• 人事施策は育成から選抜へと変化:
  • わざわざ育成するコストを掛けるのではなく過酷な状況でも勝手に自分で育つ人を引き上げる
  • リーダー・マネージャーは損をするなのにやりきる責任感のある人を登用
  • 台風でも出社するような人が忠誠心として認められ評価される
  • 生存者バイアスが人事育成の方針になる
  • 企業にとって労力のかかるキャリアの用意や育成を当事者に押しつけることによって低コストで実施
• 成果主義を導入した大企業の中には自分の評価を上げるために部下の育成よりもプレーヤーに徹したマネージャーも増加
• 若手の育成は自分のライバルを増やすことにもなりかねない
• 停滞は数年で終わること無く長く続くことによって人材育成の組織的な機構が空洞化
• 人材育成を負担に感じていた中堅企業や新興IT企業では顕著
• 当時20代で今の40〜50代にマネジメント育成を会社からしてもらった経験を聞けばその手薄さに驚く

■ 5. 2000年代のフラット化の悪影響

• バブル崩壊の影響は少なくなるが就職氷河期は続く
• 職位のヒエラルキーへの嫌悪が強くなり組織ヒエラルキーのフラット化が進む
• フラット化によって段階的な中間管理職(係長/課長代理/課長/部長代理/部長)やそこでの段階的な経験機会が失われる
• 戦略レベルの意志決定者と現場リーダーの二極化が進む
• 職位が減るものの評価グレードは残り続ける
• 組織はフラットだが昇格ポストはさらに狭くなり若者から見たポスト詰まりは悪化
• フラット化は多くの場合でポジティブのように語られる
• 新人にとって職位の3つ4つ先が突然社長という構造の有効性への疑問
• 風通しが良いと形容されるが本当に風通し良く話せているのか
• 職位の境界を担う中間職位に負担が押し込められているケースが多々ある
• 1980年代後半からマネジメントの経験機会の細さが長く続く
• 会社組織としてのマネジメント層育成の動機の欠如と現場にとってのマネジメントへの関心の薄さが常態化

■ 6. 2010年代後半から2020年代の転換

• 2010年代に入り若い人の就職状況において数十年ぶりに安定した売り手市場になる
• 働き方改革によって無理な働き方をさせることはしてはならないこととなる
• 高い職位からの厳しさや率直さの指摘はひとまとめに加害と被害の関係として解釈されやすくなる
• 部下への干渉はリスクと見なされるようになる
• 職場の人間関係の距離が遠くなるかと思えば分業化した個人主義的な働き方からチームとして頻度の高いコミュニケーションを通して仕事をするように変化
• プロダクト開発でも人材においても新しい働き方に合わせたマネジメントへの関心が高くなる

■ 7. 現在のマネージャーをとりまく混乱

• 2025年において依然として40-50代のマネジメントの知識・経験にはバラツキが大きい
• 多くの40-50代にとって自分のロールモデルはいないし教育投資も限られている
• 現在の40-50代のマネジメント層にとって自分のキャリアをふりかえるとまるでサバイバル
• それを若手に繰り返させることは許されない
• 20-30代の次世代のマネージャーにはマネジメントのあり方を示さなければならない
• 解消しなければならない状況:
  • 技術と比べて標準的な学習の機会が乏しい
  • 教育を受けたこともないのに教育を提供しなければならない
  • 人格の評価と専門職としての評価が混同される
  • 職能経験の非対称性から専門スキルとして評価されることが難しい
  • なのにふるまいとして見本を見せなければならない
• 職能表に基づいてマネジメントスキルを伸ばそうと思っても実際には人格者としてのふるまいを期待されることが多い
• 高い言語化能力や情緒的な求心力まで求められている
• プレイングマネージャーはよくないことだと合意はありつつも実態としては包括的なリーダーシップが求められている
• 職能表に書かれるマネジメントばかりしていてはマネージャーとして失格と見なされる
• マネージャーなのに実態はリーダーと混ざっていたり様々な期待が足かかっている状況
• 自己犠牲は避ける時代になったはずなのに依然としてリーダー・マネージャーは損をする状況が続いているケースを多く見る

■ 8. マネジメントスキルの明確化と学習環境の整備

• ここ数年で状況は変わりつつある
• 学習可能な一般技術としてのマネジメントの萌芽は始まっている
• 環境整備の兆候:
  • 現場経験の状況に寄り添ったマネジメントに関する書籍が増加
  • 戦略的意志決定者と現場リーダーの間を埋める職位の定義や任命も進行
  • 会社を超えて交流できるようなイベントも増加(Regional Scrum Gathering Tokyo・emconf・pmconf)
  • マネージャーの横の繋がりというテーマで豊富に語られる活動が増加
• よりマネージャーという職能を学びやすく評価されやすくなる
• 一度プロダクトマネージャーになってから現場の職能に戻る人やエンジニアリングマネージャーを経験した後にエンジニアに戻る人もぽつぽつ増加
• メンバーからマネージャーへは一方通行なキャリアでは無く自分の仕事の幅を広げる通過点として双方向に開いているケースが増加
• 有識者の間で整理が進みつつある具体テーマ:
  • マネジメントスキルの明確化(リーダーシップや人格との区別)
  • 対象の明確化(プロダクトのためのマネジメント・メンバーのためのマネジメント・プロセスのためのマネジメント)
  • 負荷とスキルの平準化(マネージャーとマネジメントの区別・マネージャーだからこそのマネジメント・メンバーも習得する共通スキルとしてのマネジメント)
  • 習得方法(産業や業界として知見共有・組織における一般的な教育投資・職位同士のピアコーチングや相互メンタリング)
• 2026年はマネジメントにとってもマネージャーにとっても働きやすくなる年になる

(2025/12/12)

だいたい同じだけど一部が異なるデータを持つデータ構造について4つのパターン分類してみた

• だいたい同じだけど一部が異なるデータを持つデータ構造について4つのパターン分類してみた

(2025/12/12)

LinuxカーネルへのRust導入は定着したとの合意、「実験的」タグを外すことが決定

• LinuxカーネルへのRust導入は定着したとの合意、「実験的」タグを外すことが決定 - GIGAZINE

(2025/12/12)

t3tra-dev/MoZuku: 日本語文章の解析・校正を行う LSP サーバー

• GitHub - t3tra-dev/MoZuku: 日本語文章の解析・校正を行う LSP サーバー。

MoZuku は、MeCab・CaboCha を活用した日本語文章の解析・校正を行う LSP サーバーです。

特徴

• 形態素解析: MeCab による高精度な日本語トークン化
• 文法チェック: 二重助詞、助詞連続、動詞-助詞不整合の検出
• セマンティックハイライト: 品詞ごとの色分け表示
• コメント内解析: C/C++/Python/JavaScript/TypeScript/Rust のコメント内日本語を解析
• HTML/LaTeX サポート: ドキュメント本文も解析
• ホバー情報: 単語の原形、読み、品詞情報、Wikipedia のサマリーを表示

(2025/12/11)

バリデーションとパースの分離。Goで実装する「変更に強い」CSV 処理の設計

• バリデーションとパースの分離。Goで実装する「変更に強い」CSV 処理の設計 - カミナシ エンジニアブログ

要約:

■ 1. CSV処理における課題

• 業務アプリケーション開発においてCSVインポート機能は避けて通れない
• 仕様が複雑になるにつれて以下の課題に直面する:
  • バリデーションとパース処理が混在しエラーの発生箇所が追いづらい
  • Shift_JISなど多様なエンコーディングへの対応でビジネスロジックが複雑になる
  • パースやバリデーションエラーを即座にリターンするとユーザーは「モグラ叩き」のような修正サイクルを繰り返すことになる
  • データが正しい状態か保証されないまま後続の処理に渡されてしまう

■ 2. Parse don't validateの考え方

• 「Parse don't validate」という考え方を参考にCSV処理のライブラリを実装した
• これは入力を単に検証して終わるのではなく型のあるデータ構造に変換することでその後の安全性を型システムで保証するという考え方である
• 処理を以下の3つのフェーズに分割した:
  • Reader:エンコーディングの詳細を隠蔽
  • Parser:CSV行→構造体への変換
  • Validator:中間型→検証済みの型への昇格

■ 3. Reader層の実装

• 日本の業務システムではExcelから出力したCSVが頻繁に使われShift_JISやBOM付きの場合がある
• ビジネスロジックの段階ではエンコーディングの違いを意識せずに済むようにしたい
• 読み込み時にエンコーディングを自動判定・変換し常にUTF-8のReaderを返すように実装した
• エンコーディング処理の順序:
  • BOM付きUTF-8のCSVファイルをサポート
  • BOMなしUTF-8をサポート
  • Shift_JISをUTF-8へ変換してサポート
• この層が腐敗防止層として機能することで後続の処理はファイルがどのような形式で保存されていたかを知る必要がなくなる

■ 4. Parser層の実装と中間型の定義

• 読み込んだ行をGoの構造体にマッピングする
• ここでは型変換とマッピングのみを行いビジネス的なバリデーションは行わない
• 中間型Parsed[T]の定義:
  • ColumnCountStatus:カラム数の過不足状態を表す
  • ParsedRecord[T]:1行ごとのパース結果
  • Parsed[T]:パース処理全体の結果
• カラム数が合わないといった構造的な問題も即座にエラーにするのではなくステータスとして記録する
• これはエラーの集約を実現するためである
• パース段階で見つかった不備で即座にエラーを返すとユーザーは修正とアップロードを何度も繰り返すことになる
• Parserは起きたことの記録に徹し後続のValidatorで他の入力ミスと合わせてファイル内の全エラーをまとめて報告できるようにしてユーザー体験を損なわない設計としている

■ 5. Validator層の設計思想

• ライブラリには汎用的な検証フローだけを持たせ具体的なビジネスルールは外部から注入する形をとった
• 型定義:
  • Valid[T]:バリデーション後の安全なデータ
  • ValidateRecordFunc[T]:外部から注入するバリデーション関数の型定義
• Validate関数の処理フロー:
  • ヘッダー構造の検証
  • レコードごとの検証で注入された関数を実行
  • エラーがなければ有効なレコードとしてリストに追加
  • エラーがあればValid[T]は返さない
  • 全て合格して初めてValid[T]を返す
• Parsed[T]からValid[T]への変換が成功すればデータは整合性が取れていることが保証される

■ 6. 利用例の実装

• このライブラリを使う側のコードは非常に宣言的になる
• 利用手順:
  • 取り込みたいCSVの構造を定義する
  • パースを実行して読み込みと構造化を行う
  • バリデーションルールの定義でドメイン固有のロジックを記述する
  • バリデーション実行でルールの注入を行う
  • エラーがあれば何行目の何がおかしいかをまとめて返却できる
  • 後続処理に来る時点でvalidDataは*Valid[UserCSV]型でありすべてデータがルールに適合していることが保証されている

■ 7. 設計のメリット

• CSV処理は外部からの入力を扱うため複雑になりがちだが責務を分けることでメンテナビリティを向上させることができた
• Reader層の利点:
  • エンコーディングの詳細を隠蔽し腐敗防止層として機能
• Parser層の利点:
  • CSV行を中間型へ変換しエラーは即時リターンせず状態として記録してUX向上に貢献
• Validator層の利点:
  • 中間型を検証済みの型へ昇格し汎用的な検証フローを提供して具体的なルールは外部から注入する
• バリデーションロジックを関数として注入する設計にしたことでライブラリ自体を変更することなく様々なCSVに柔軟に対応できる構成となった

(2025/12/11)

40歳でスタートアップに挑戦して爆死した

• 40歳でスタートアップに挑戦して爆死した｜じゅんはや

MEMO:

• 自分もミッション！バリュー！カルチャー！なノリについていけなかったタイプ

(2025/12/10)

「あなたが修正するのは自分だけのバグではない」、リーナス・トーバルズ氏が東京開催のOpen Source...

• 「あなたが修正するのは自分だけのバグではない」、リーナス・トーバルズ氏が東京開催のOpen Source Summit Japan基調講演で語ったこと（後編） － Publickey

(2025/12/10)

「AIは過剰に宣伝されているが、ツールとしては大いに信じている」、リーナス・トーバルズ氏が東京開催の...

• 「AIは過剰に宣伝されているが、ツールとしては大いに信じている」、リーナス・トーバルズ氏が東京開催のOpen Source Summit Japan基調講演で語ったこと（前編） － Publickey

(2025/12/10)

Go のアーキテクチャどうしてる？ ギフティで実際に試した構成パターンを紹介します

• Go のアーキテクチャどうしてる？ ギフティで実際に試した構成パターンを紹介します - giftee Tech Blog

(2025/12/09)

「コードは上から下へ読むのが一番」と思った時に、思い出してほしい話

• 「コードは上から下へ読むのが一番」と思った時に、思い出してほしい話 - Speaker Deck

MEMO:

• コードが1000行、5000行と育つと人間の認知の限界が訪れる
• なのでコードは分割しなければならない
• これは人間の脳のスペックの問題
• とはいえ、コードを分割すると今度は読みにくくなってくる
• 一本道のコード: 地図は不要だが記憶力で頑張る
• 関心事の分離のコード: 記憶力不要、ただし地図が必要
• 完全なトレードオフ
• 人間の脳のスペック的に「記憶力」より「地図」の方がスケールする
• カプセル化や抽象化レイヤー、DIで関心事の分離を実現する

(2025/12/09)

今、MySQLのバックアップを作り直すとしたら何がどう良いのかを考える旅

• 今、MySQLのバックアップを作り直すとしたら何がどう良いのかを考える旅 - Speaker Deck

(2025/12/09)

エンジニア出身PMが一次請けで失敗しまくった話

• エンジニア出身PMが一次請けで失敗しまくった話

(2025/12/09)

Why Fighter Jets Ban 90% of C++ Features

• Why Fighter Jets Ban 90% of C++ Features - YouTube

要約:

■ 1. 航空宇宙ソフトウェアの歴史的背景

• 1996年6月4日、Ariane 5ロケットが打ち上げ36秒後に爆発した。原因は64ビット浮動小数点数を16ビット整数に変換する際の未処理例外であり、5億ドルが一瞬で失われた。
• F-35の設計者はこの教訓から、JSF C++標準のAVルール208で「例外を使用してはならない」と規定した。
• 1970年代初期、F-4 Phantomには実質的にソフトウェアが存在せず、爆撃コンピュータは歯車とカムの箱であった。
• F-14 Tomcatプロジェクトで、Garrett AI Researchが世界初のマイクロプロセッサを開発した。これはIntel 4004より数年早く、かつ高速であったが、1998年まで機密扱いであった。
• F-14の可変翼設計には手動操縦では対応できず、約2500行のマイクロコードで多項式方程式を処理した。これが航空機における最初の本格的なソフトウェアとなった。

■ 2. 軍用ソフトウェアの言語戦争

• 初期のソフトウェア時代、米陸軍、空軍、海軍はそれぞれ異なるコーディング標準を持っていた。
• 空軍はJovial(Jules's Own Version of the International Algorithmic Language)を使用していた。
• 海軍はF-18でCMS2という独自言語を採用し、互換性は皆無であった。
• 機上ソフトウェアの量は指数関数的に増加した:
  • F-16Aで12万5000行
  • B-1で100万行
  • F-35で900万行
• 当時450以上の異なるプログラミング言語が使用されており、適切な標準が存在しなかった。
• 国防総省は全ての言語を置き換える高級言語としてAdaを開発した。
• Adaの使用は約15年間義務付けられ、使用しない場合は不可能であることを証明する必要があった。

■ 3. C++への移行とJSF標準の誕生

• 1990年代、航空宇宙分野ではAdaが主流であったが、同時期にインターネット、Windows 95が登場し、多くのゲームがC++で動作していた。
• 当時、コンパイラは有料で数千ドルもしたが、C++とGCCは無料であり、学生はC++を学習した。
• Lockheed MartinはF-35プロジェクトでAdaの代わりにC++の使用を国防総省に提案した。
• 提案者は「法律を破ることを承認してください」という内容を提示したことになる。
• Lockheed Martinは純粋なC++ではなく、言語を制限する計画を用意していた。
• C++の作成者Bjarne Stroustrup自身がJSF規則の策定に関与したことを認めている。
• JSF標準は特定の機能を外科的に除去することで、強力な言語を認証可能なコードに変換する。
• JSF標準は完全に公開されており、オンラインで閲覧可能である。
• Joint Strike Fighterという名称は、Lockheed Martinだけでなく、多数の防衛企業、政府、複数の国が協力して開発したことを示している。

■ 4. JSF C++標準の主要な制約事項

• 例外処理の禁止(AVルール208):
  • 例外は予測不可能な制御フローを生成する
  • Ariane 5の事故は値のオーバーフローではなく、未処理例外が問題であった
  • Bjarne Stroustrup自身は現代のC++例外処理を支持しているが、当時のツールの成熟度では応答時間を保証できなかった
  • JSF標準では例外の代わりにリターンコードを使用する
  • リターンコードは呼び出し元関数に処理を委ねる
• 再帰の禁止(AVルール119):
  • 関数は直接的または間接的に自身を呼び出してはならない
  • 再帰はスタックオーバーフローの可能性を生む
  • 各再帰呼び出しは新しいスタックフレームを作成する
  • 再帰の最大深度が不明な場合、メモリ使用量の上限を知ることができない
  • 反復的アプローチで置き換える必要がある
• メモリ割り当ての制限(AVルール206):
  • 初期化後のメモリ割り当てと解放を禁止する
  • 動的メモリ割り当てはコードに予測不可能性をもたらす
  • メモリマネージャーが利用可能なメモリを見つけるのにかかる時間が不明である
  • 十分なメモリが利用可能かどうかも不明である
  • ヒープ上の割り当てはフラグメンテーションを引き起こす
  • 解決策として最大データサイズをハードコードし、事前割り当てを行う
• 循環的複雑度の制限(AVルール3):
  • 関数の循環的複雑度は20を超えてはならない
  • 循環的複雑度は関数内の決定パスの数を示す
  • if文、whileループ、forループ、論理演算子(andやor)、switch文などがカウントされる

■ 5. 実装例とシミュレーション

• XPlane 12フライトシミュレータとF-35Bを使用したデモンストレーションが実施された。
• マルチファンクションディスプレイ(MFD)がF-16スタイルで構築され、リアルタイムの飛行データに接続された。
• XPlaneのWeb APIを通じてライブ飛行データが配信される。
• フロントエンドはPython、バックエンドはC++で実装された。
• JSF標準に準拠したC++コードで密度高度計算、飛行データ、旋回計算、V-NAVデータ、風計算などが実行される。
• 非準拠コードでは未処理例外が発生し、プログラムがクラッシュするシナリオが示された。
• 準拠コードではリターンコードを使用し、呼び出し元関数がエラーを適切に処理する。
• 初期のF-35はMotorola G4 Power PCプロセッサベースのミッションコンピュータを使用していた。これは2003年のAviation Todayの記事で公開された情報である。

■ 6. JSF標準の影響と現代への継承

• F-35 C++標準の原則は他の分野や標準にも広がった。
• NASAのF-Prime標準は2017年に公開され、メモリ割り当て禁止、例外処理禁止、再帰禁止という同様の制約を持つ。
• 自動車業界にもコーディング標準が存在する:
  • MISRAとAutoSAR(Automotive Open System Architecture)
  • AutoSARはC++14標準の影響の一つとしてJSFを名指しで参照している
  • AutoSARではスマートポインタが許可されるなど、より現代的なC++の機能が利用可能である
• 自動車は車輪付きコンピュータと言える存在になっている。
• BMW、Ford、Toyotaなど主要な自動車メーカー全てがAutoSARに依存している。
• これらの言語安全性は数十年前に国防総省が下した決定に基づいている。

■ 7. 結論と提言

• Bjarne Stroustrup自身、JSF標準の策定委員会の一員であったが、現在はC++ Core Guidelinesの使用を推奨している。
• 現代のC++は過去20年間で進化し続けており、JSF標準は当時の素晴らしいエンジニアリング成果であったが、より新しく安全な現代的C++を使用すべきである。
• JSF標準は歴史的に重要かつ興味深い部分であり、一見の価値がある。
• JSF標準はC++のような複雑な言語を、重要なインフラストラクチャに安全な予測可能なものに変換することに成功した。
• 最も賢いプログラマーであることが重要なのではなく、どの要素を「飛行前に取り除く」かを知る規律を持つことが重要である。

関連:

• 戦闘機「F-35」にはC++の特殊ルール適用版が使われており例外処理や再帰関数が禁止されている

(2025/12/09)

戦闘機「F-35」にはC++の特殊ルール適用版が使われており例外処理や再帰関数が禁止されている

• 戦闘機「F-35」にはC++の特殊ルール適用版が使われており例外処理や再帰関数が禁止されている - GIGAZINE

アメリカ空軍や航空自衛隊が運用する戦闘機「F-35」はC++でコーディングされたソフトウェアを搭載しています。このC++コードは「Joint Strike Fighter Air Vehicle C++ Coding Standards(JSF AV C++)」と呼ばれるコーディング規則に沿って記されているとのことで、Googleの研究者で航空機関連プログラミングにも詳しいLaurieWired(Laurie Kirk)氏がJSF AV C++の特長を解説しています。

F-35よりも前に開発された戦闘機にはアメリカ国務省が開発を主導した「Ada」というプログラミング言語が採用されていました。しかし、F-35の開発当時はすでにAdaが陳腐化しており、代わりにC++を採用することとなりました。C++を採用しつつアリアン5型ロケットのような失敗を防ぐために策定されたコーディング規格がJSF AV C++というわけです。

(2025/12/09)

Kubernetesが使えない環境を救う

• Kubernetesが使えない環境を救う - Tomohisa Oda
• GitHub - linyows/dewy: Dewy enables declarative deployment of applications in non-Kubernetes environments.

Dewyは各ホストに常駐し、CIによって作られたアプリケーションやデータ、コンテナを、ホスト上のプロセスとして常に最新となるようにします。いわゆる継続的なデプロイメントを可能にします。継続的なデプロイメントは、Kubernetesを使っているとエコシステムであるArgo CDのようなGitOps ソフトウェアによって、当然のこととして実現できますが、Kubernetesが使えない環境だと既存のデプロイツールで頑張るしかありません。ひょっとすると、SSHで手動デプロイだったり、SCPやSFTPを使った趣のあるshellの実行になるかもしれません。あまり考えたくないですね…

MEMO:

• Go言語性のプロビジョニング＆デプロイ支援ツールぐらいのイメージでよいのだろうか？

(2025/12/09)

Thoughts on Go vs. Rust vs. Zig

• Thoughts on Go vs. Rust vs. Zig | Sinclair Target

要約:

■ 1. はじめに

• 最近「仕事に適した道具」を使うのではなく仕事にある道具を使っていることに気づいた
• そのことが自分が知っているプログラミング言語をほぼ決定していた
• 過去数ヶ月間仕事で使わない言語を実験することに多くの時間を費やした
• 目標は習熟度ではなく各言語が何に適しているかについて意見を形成することに興味がある
• プログラミング言語は非常に多くの軸に沿って異なるため比較するのが難しい
• トレードオフがあるという明らかに真実だが完全に退屈で役に立たない結論にデフォルトでたどり着いてしまう
• もちろんトレードオフはある
• 重要な問いはなぜこの言語はこの特定のトレードオフのセットにコミットしたのかである

■ 2. 言語選択の視点

• この問いは興味深い
• 加湿器を買うかのように機能のリストに基づいて言語を選びたくない
• ソフトウェアを構築することと自分のツールを気にかけている
• 言語はトレードオフを行う際に一連の価値観を表現する
• どの価値観が自分に共鳴するかを見つけたい
• この問いは結局のところ機能セットが大幅に重複する言語間の違いを明確にするのにも役立つ
• 「Go vs. Rust」や「Rust vs. Zig」についてのオンライン質問の数が信頼できる指標であれば人々は混乱している
• 言語Xは機能a、b、cを持っているのでWebサービスを書くのに優れているが言語Yは機能aとbしか持っていないということを覚えるのは難しい
• 言語Xは言語Yがインターネットを嫌いインターネット全体のプラグを抜くべきだと信じている人によって設計されたためWebサービスを書くのに優れていると覚える方が簡単だと思う

■ 3. 本文の目的

• 最近実験した3つの言語についての印象を収集した
• Go、Rust、Zigである
• 各言語での経験をその言語が何を重視しそれらの価値をどれだけうまく実行するかについての包括的な評決に統合しようと試みた
• これは還元的かもしれないが還元的な偏見のセットを結晶化することがここでやろうとしていることである

■ 4. Goの特徴

• Goはミニマリズムによって特徴づけられる
• 「現代のC」と表現されている
• GoはCのようではないがガベージコレクションされ実際のランタイムを持っている
• 言語全体を頭の中に収めることができるという点でCに似ている
• 言語全体を頭の中に収めることができるのはGoが非常に少ない機能しか持っていないからである
• 長い間Goはジェネリクスを持っていないことで悪名高かった
• これは最終的にGo 1.18で変更されたがそれは12年間人々がジェネリクスを言語に追加するよう懇願した後のことであった
• タグ付きユニオンやエラー処理の糖衣構文など現代の言語で一般的な他の機能はGoに追加されていない
• Go開発チームは言語に機能を追加するためのハードルが高いようである
• 最終結果は別の言語でより簡潔に表現できるロジックを実装するために多くのボイラープレートコードを書くことを強いられる言語である
• しかし結果は時間の経過とともに安定しており読みやすい言語でもある

■ 5. Goのスライス型の例

• Goのミニマリズムの別の例としてGoのスライス型を考える
• RustとZigの両方にスライス型があるがこれらはファットポインタでありファットポインタのみである
• Goではスライスはメモリ内の連続したシーケンスへのファットポインタであるがスライスは成長することもできる
• つまりRustのVec型とZigのArrayListの機能を包含している
• またGoはメモリを管理してくれるためGoはスライスのバッキングメモリがスタックとヒープのどちらに存在するかを決定する
• RustやZigではメモリがどこに存在するかについてはるかに真剣に考える必要がある

■ 6. Goの起源と目的

• Goの起源神話は基本的に次のようなものである
• Rob PikeはC++プロジェクトのコンパイルを待つことにうんざりしていた
• GoogleのC++プロジェクトで他のプログラマーがミスを犯すことにもうんざりしていた
• したがってGoはC++がバロック的であるところでシンプルである
• それはプログラミングの一般階級のための言語である
• 90%のユースケースに十分であると同時に理解しやすいように設計されている
• 特に並行コードを書く際にそうである
• 仕事でGoを使っていないが使うべきだと思う
• Goは企業のコラボレーションに奉仕するためにミニマルである
• これを軽蔑として意味しているわけではない
• 企業環境でソフトウェアを構築することには独自の課題がありGoはそれを解決する

■ 7. Rustの特徴

• Goがミニマリストであるのに対しRustはマキシマリストである
• Rustに関連付けられることが多いタグラインは「ゼロコスト抽象化」である
• これを「ゼロコスト抽象化、そしてたくさんの抽象化!」と修正したい
• Rustは学習が難しいという評判がある
• Rustを難しくしているのはライフタイムではなく言語に詰め込まれた概念の数であるというJamie Brandonの意見に同意する
• 特定のGithubコメントを取り上げるのは最初の人ではないがそれはRustの概念密度を完璧に示している
• もちろんRustはGoがミニマリストであろうとするのと同じ方法でマキシマリストであろうとしているわけではない
• Rustが複雑な言語であるのはそれが達成しようとしていることが安全性とパフォーマンスという幾分緊張関係にある2つの目標を実現することだからである

■ 8. Rustの安全性とパフォーマンス

• パフォーマンス目標は自明である
• 「安全性」が何を意味するかはそれほど明確ではない
• 少なくとも自分にとってはそうだったがおそらく長い間Pythonに慣れすぎていたのかもしれない
• 「安全性」は「メモリ安全性」を意味する
• 無効なポインタを逆参照したりダブルフリーを行ったりできないようにするという考えである
• しかしそれはそれ以上のことを意味する
• 「安全な」プログラムはすべての未定義動作(UBと呼ばれることもある)を回避する
• 恐ろしいUBとは何か
• それを理解する最良の方法は実行中のプログラムには死よりも悪い運命があることを覚えておくことだと思う
• プログラムで何か問題が発生した場合即座の終了は実際には素晴らしい
• なぜならエラーがキャッチされない場合の代替案はプログラムが予測不可能性の薄明の領域に入り込むことだからである
• そこでは次のデータ競合に勝つスレッドや特定のメモリアドレスにたまたまあるガベージによって動作が決定されるかもしれない
• 今やハイゼンバグとセキュリティ脆弱性がある
• 非常に悪い

■ 9. Rustのコンパイル時チェック

• Rustはコンパイル時にチェックすることによって実行時のパフォーマンスペナルティを支払うことなくUBを防ごうとする
• Rustコンパイラは賢いが全知ではない
• コンパイラがコードをチェックできるようにするにはコードが実行時に何をするかを理解する必要がある
• したがってRustには表現力豊かな型システムと特性のメナジェリーがあり別の言語では単に明白な実行時の動作であるものをコンパイラに表現できる
• これによりRustは難しくなる
• なぜならただ物事を行うことができないからである
• Rustがその物事に対して持っている名前を見つけ出す必要がある
• 必要な特性などを見つけてRustが期待するように実装する必要がある
• しかしこれを行えばRustは他の言語ができないコードの動作について保証を行うことができる
• これはアプリケーションによっては重要かもしれない
• また他の人のコードについても保証を行うことができるためRustではライブラリを消費することが簡単になる
• これがRustプロジェクトがJavaScriptエコシステムのプロジェクトとほぼ同じくらい多くの依存関係を持つ理由を説明している

■ 10. Zigの特徴

• 3つの言語のうちZigは最も新しく最も成熟していない
• この執筆時点でZigはバージョン0.14にすぎない
• その標準ライブラリにはほとんどドキュメントがない
• それを使用する方法を学ぶ最良の方法はソースコードを直接参照することである
• これが真実かどうかはわからないがZigをGoとRustの両方への反応として考えたい
• Goはコンピュータが実際にどのように機能するかについての詳細を曖昧にするためシンプルである
• Rustはその多くのフープをくぐらせることを強制するため安全である
• Zigはあなたを自由にする
• Zigではあなたが宇宙を制御し誰もあなたに何をすべきか言うことはできない

■ 11. Zigのメモリ管理

• GoとRustの両方でヒープ上にオブジェクトを割り当てることは関数から構造体へのポインタを返すのと同じくらい簡単である
• 割り当ては暗黙的である
• Zigでは自分で明示的にすべてのバイトを割り当てる
• Zigは手動メモリ管理を持つ
• Cよりもさらに多くの制御がある
• バイトを割り当てるには特定の種類のアロケータでalloc()を呼び出す必要がある
• つまりユースケースに最適なアロケータ実装を決定する必要がある
• Rustでは可変グローバル変数を作成することが非常に難しくそれを行う方法についての長いフォーラムディスカッションがある
• Zigでは問題なく作成できる

■ 12. Zigの不正動作の扱い

• 未定義動作はZigでも依然として重要である
• Zigはそれを「不正動作」と呼ぶ
• 実行時にそれを検出し発生時にプログラムをクラッシュさせようとする
• これらのチェックのパフォーマンスコストを心配する人のためにZigはプログラムをビルドする際に選択できる4つの異なる「リリースモード」を提供する
• これらのいくつかではチェックが無効になっている
• アイデアはチェックされたリリースモードでプログラムを十分な回数実行してチェックされていないビルドで不正動作がないことについて合理的な確信を持つことができるようにすることのようである
• これは非常に実用的な設計のように思える

■ 13. Zigとオブジェクト指向プログラミング

• ZigとGoとRustの別の違いはZigのオブジェクト指向プログラミングとの関係である
• OOPはしばらくの間不人気でありGoとRustの両方がクラス継承を避けている
• しかしGoとRustは他のオブジェクト指向プログラミングイディオムに対して十分なサポートを持っているため望むならプログラムを相互作用するオブジェクトのグラフとして構築することができる
• Zigにはメソッドがあるがプライベート構造体フィールドや実行時ポリモーフィズム(動的ディスパッチとも呼ばれる)を実装する言語機能はない
• std.mem.Allocatorはインターフェースになりたがっているにもかかわらずである
• 私が知る限りこれらの除外は意図的である
• Zigはデータ指向設計のための言語である

■ 14. Zigの手動メモリ管理の意義

• 2025年に手動メモリ管理を使用してプログラミング言語を構築することは狂気に思えるかもしれない
• 特にRustがガベージコレクションさえ必要とせずコンパイラにそれを行わせることができることを示した時には
• しかしこれはOOP機能を除外する選択と非常に関連した設計選択である
• GoやRustやその他の多くの言語ではオブジェクトグラフ内の各オブジェクトに対して一度に少しずつメモリを割り当てる傾向がある
• プログラムには何千もの小さな隠されたmalloc()とfree()がありしたがって何千もの異なるライフタイムがある
• これがRAIIである
• Zigでは手動メモリ管理が多くの面倒でエラーが発生しやすい簿記を必要とするように思えるかもしれないがそれはすべての小さなオブジェクトにメモリ割り当てを結びつけることにこだわる場合のみである
• 代わりにプログラム内の特定の賢明なポイント(イベントループの各反復の開始時など)で大きなメモリのチャンクを割り当てて解放し操作する必要があるデータを保持するためにそのメモリを使用することもできる
• Zigが奨励しているのはこのアプローチである

■ 15. ZigとRustの違い

• 多くの人々がRustが既に存在するのになぜZigが存在すべきなのかについて混乱しているようである
• Zigがよりシンプルであろうとしているだけではない
• この違いがより重要なものだと思う
• Zigはコードからさらにオブジェクト指向的な思考を切除することを望んでいる
• Zigには楽しく破壊的な雰囲気がある
• それは(オブジェクトの)企業のクラス階層を打ち砕くための言語である
• それは誇大妄想狂とアナーキストのための言語である
• 好きである
• すぐに安定版リリースに到達することを望むがZigチームの現在の優先事項はすべての依存関係を書き直すことのようである
• Zig 1.0を見る前にLinuxカーネルを書き直そうとすることは不可能ではない

(2025/12/08)

なぜ "簡単" なコードが複雑になるのか 〜 AI時代に読み直す『Simple Made Easy』

• なぜ "簡単" なコードが複雑になるのか 〜 AI時代に読み直す『Simple Made Easy』

(2025/12/08)

知っていてこだわらない、それがいいソフトウェアエンジニアの条件なんだと僕は思うんだ

• 知っていてこだわらない、それがいいソフトウェアエンジニアの条件なんだと僕は思うんだ - assertInstanceOf('Engineer', $a_suenami)

(2025/12/08)

フルスタックエンジニアの終焉？生成AI後の未来を産業史から考える

• フルスタックエンジニアの終焉？生成AI後の未来を産業史から考える - arclamp

(2025/12/08)

RAGを自分で実装したくなったらまずこれ見て【ruri-v3 × Faiss】

• RAGを自分で実装したくなったらまずこれ見て【ruri-v3 × Faiss】

(2025/12/08)

SQLアンチパターンを根本から理解する：実務で遭遇した“DBが泣く”5つのNGクエリと改善策

• SQLアンチパターンを根本から理解する：実務で遭遇した“DBが泣く”5つのNGクエリと改善策 #MySQL - Qiita

(2025/12/08)

ergo - Goのエラーライブラリを自作して1年間利用してみた振り返り

• ergo - Goのエラーライブラリを自作して1年間利用してみた振り返り - newmo 技術ブログ
• GitHub - newmo-oss/ergo: A structured error handling library for Go with attributes, error codes, and stack traces

MEMO:

• シンプルな感じで良さそう

(2025/12/08)

AI時代の「文章を書く・文章を読む」

• AI時代の「文章を書く・文章を読む」｜u

要約:

■ 1. NotebookLMの進化と便利さ

• NotebookLMが驚くほど進化した
• 雑に書いたメモを投げるだけで驚くほど綺麗なスライドが返ってくる
• デザインも構成も洗練されていて「これでいいじゃん」と思わせる仕上がりになる
• その便利さの裏側で大事なことを見落としつつある
• 文章を書くこと、文章を読むことの本来の難しさを見落としている

■ 2. 文章の本質

• 文章は単語・文・構造のレイヤーが連動しながら書き手の思考と意図を運ぶ媒体である
• 文章は単なる情報の入れ物ではなく思考そのものの外在化である
• 読み手はその外に出された思考を自分の中で正確に再構築することではじめて理解に到達する
• 読むことも書くことも思っている以上に高度な営みである
• 文章は書き手の頭の中にある思考モデルを言葉という形式に変換し、それを読み手が再構築することで意味が成立する
• このプロセスは一方向の伝達ではなくある種の共同作業に近い
• 書き手は自分の思考を「構造→文→単語」という順で形にする
• 読み手はその逆方向から「単語→文→構造」へと読み解きながら思考を復元していく
• この同期作業がうまくいったとき文章ははじめて役割を果たす

■ 3. 読むという行為の複雑さ

• 読む行為は思っているよりはるかに複雑である
• 脳はまず単語を処理し、次に文法構造を組み立て、最後に文章全体の構造を理解する
• これはボトムアップの処理である
• 読み慣れている人ほど文章の冒頭から「これはこういう話なのではないか」と構造を仮置きする
• その予測に照らして文や単語を読み直すトップダウンの処理も同時に走っている
• この二つが往復することで読み手は意味を確定させていく

■ 4. 読むことの各レベル

• 単語レベル:
  • 読むとは書き手の単語選択の意図を拾いにいくことである
  • そこに書かれている単語がなぜその単語なのかを探る
  • 似た単語ではなくちょうどその一語が選ばれている理由を探りにいく意識を持つことが求められる
  • 語の温度差やニュアンスの微妙な違いを拾おうとしない読みは意図の半分を取りこぼす
  • 単語を捉えることはその細部に踏み込む行為である
• 文レベル:
  • 読むとは文の骨格を正しく組み立てることでもある
  • 主語はどれか、述語は何にかかっているか、修飾語はどの範囲を指しているのかを問いかける
  • こうした構文的な問いかけを怠ったまま読み進めても文章は理解できない
  • 構文を読み解くことは読解の必須プロセスである
• 構造レベル:
  • 読むとは段落や見出しがつくる全体の構造を把握することである
  • どの話題が主軸でどこが補助なのかを理解する
  • 論点はどう展開され何に向かって進んでいるのかを把握する
  • 文章は構造がわかってはじめて意味が正しく伝わる
  • 構造を読まずに文だけ追っていても部分の寄せ集めにしかならない
  • 読むとは書き手の思考の構造を読み手側で再構成することである

■ 5. 書くことの難しさ

• 書くとは読み手が上記のプロセスを誤らずにたどれるよう言葉の配置や情報の順序を設計することである
• 単語レベル:
  • 語彙の選択は思考の解像度をそのまま反映する
  • 同じように見える二つの語でも距離感やニュアンスがまったく違う
  • 書ける人はここにかなりの意識を払っている
• 文レベル:
  • 文の流れをどうつくるかが重要である
  • 主語と述語の関係、文同士の接続、文長とリズムを考慮する
  • 箇条書きは便利だが断片の羅列になった瞬間、文章ではなくその場にいた人だけがわかるメモになってしまう

■ 6. 箇条書きの問題点

• 問題1:分類の軸が途中で変わっている
  • 会社という軸で並んでいるのに途中から突然今後(時系列)に切り替わっている
  • 軸が変わると読み手は何を基準に並んでいるのかを見失う
  • これに気づかないまま箇条書きを続けると読み手の頭の中では構造が崩れ始める
• 問題2:同じ階層に抽象度の違う情報が混じっている
  • タスク、状態、イベントという種類の違う情報が同じレベルで並んでいる
  • 読み手の脳は同じ階層=同じ種類のものが並んでいると期待して処理する
  • タスク・状態・イベントが混ざると構造が曖昧になり意味のまとまりが生まれない
• 問題3:ネスト(階層)が深くなるほど文脈の種類が混ざる
  • 意思決定項目とサブタスクが同じ階層に混在する
  • 階層を深くすればするほど文脈の種類を統一しないと読み手の負荷は急増する
• 問題4:因果も優先順序も見えない
  • なぜ見積を再提示するのか、稟議待ちとどうつながるのか、ミーティングは何を決める場なのかといった意味の関係が抜け落ちている
  • 読み手は断片から因果関係を補完しなければいけない
  • これは文章ではなくその場にいた人だけが理解できるログになっている
  • 書き手が省略した思考コストを読み手が肩代わりしているだけである
• 人に正しく伝えるためにはログを文章に変える必要がある

■ 7. 構造レベルの書き方

• 構造とは読み手にどの順番で理解してもらうかを設計する仕事である
• 結論、背景、根拠をどう配置するのかを考える
• どこで区切りどこで流れを転換させるのかを決める
• 構造は読み手の認知負荷を左右する
• 書ける人ほどここが驚くほど丁寧である

■ 8. AI時代の危険性

• NotebookLMのようなツールは多少雑なメモを渡してもそれなりに整ったスライドや要約に仕上げてくれる
• 構成もデザインも綺麗で読めばなんとなく理解した気になってしまう
• その便利さには一つ厄介な側面がある
• 中身がとんちんかんでもAIが構造的に美しい形に整えてしまうという点である
• 人間は外形が整っているものに対して「これは正しいのだろう」と無意識に信頼を寄せる
• 思考が雑であってもそれっぽく再構成されると破綻に気づきにくくなる
• AIの構造化が良すぎるせいで人間の側の思考の粗さが見えなくなる
• さらに厄介なのはAIが整えたアウトプットを見て「そうそう、これが自分が言いたかったことだ」と感じてしまう現象である
• よく考えてみると自分の中にそんな整理された思考はもともと存在していなかったりする
• 綺麗な構造のほうに自分の思考を後付けで寄せてしまう
• この錯覚が積み重なると本来必要だったはずの深く考えるプロセスが徐々に失われる
• AIは文章を整えてくれるが思考そのものの破綻には気づかないし直してもくれない
• 整っているように見えるという理由だけでその破綻を見逃してしまう
• AI時代の危険とは文章が壊れていくことではなく思考が壊れていくことに気づけなくなることである

■ 9. 書ける人がAI時代に強くなる理由

• 書ける人はそもそも自分の思考を構造として組み立てられる
• その構造がしっかりしていればAIに投げたときに要点がズレることはない
• むしろAIはその構造をそのまま増幅しより見やすくより伝わりやすい形に整えてくれる
• 逆に思考の構造が曖昧なまま書いた文章をAIに渡しても出てくるアウトプットは曖昧なままである
• これはAIの性能の問題ではなく入力となる思考の精度の問題である
• AIは製造機ではなくて増幅器である
• 粗い入力は粗いまま、精密な入力はより精密なかたちで返ってくる

■ 10. 形式変換の容易さ

• 書ける人は文章を書いた後にこれをどんな形で伝えるのが一番いいかを自然に考える
• 文章で伝えるべきか、図解にすべきか、スライドが合うのかを考える
• 今まではその形式変換にそれなりの時間がかかっていた
• AIがここを代わりに担ってくれる
• 文章さえしっかり書いておけば読み手の特性に合わせた形をほぼゼロコストで作れるようになる
• 書ける人は書いた瞬間にあらゆる読み手へ同時に届けられる人になる
• 形式変換という作業はAIに任せられるようになった
• 今の時代に問われるのは何をどう構造化して書いたかという根本の部分である
• 書ける人はAIと組んだ瞬間に生産性も影響力も跳ね上がる
• 書けない人はAIに任せてもズレ続ける
• この差はこれからどんどん広がっていく

■ 11. 読む・書く・考えるの三位一体

• リクルートワークス研究所が出しているWorks誌のNo.163ではこれら三つの行為は分離できないと指摘している
• 読むには書き手の意図を推測し自分の中で意味づける思考が必要になる
• 書くとはその思考を構造化して外に出すことである
• 一度外に出した文章を読み直すことでまた考えが深まり書き直したくなる
• 読む→考える→書く→読むという循環を回すことでしか思考は洗練されていかない
• 読む力が弱ければ書けないし書けなければ考えが浅くなる
• 考えが浅いままでは他人の文章も深く読めない
• 三つが相互に支え合っているからこそ切り離せない

■ 12. AI時代における能力の差

• AIは文章を整えてくれるが思考そのものを鍛えてはくれない
• AIを使いこなすには読む・書く・考えるという循環が前提になる
• 読む力は理解の質を決め、書く力は思考の質を決め、そして両方を支えるのが考える力である
• AIが文章をきれいに整えてしまう時代だからこそ人間は文章を創る能力で差がつく
• 書ける人はAIと組んだ瞬間に影響力が跳ね上がる
• 書けない人はAIに任せてもズレ続ける
• 他人の文章をAIで要約・スライド化していても仕事は進捗するが自分の能力は伸びない
• 読む・書く・考えるという三位一体の言語能力を備えていることがAI時代にこそより強く求められる

(2025/12/07)

DRYにしすぎるとコードは干からびる

• DRYにしすぎるとコードは干からびる

要約:

■ 1. 前置きと問題意識

• 著者の会社はFindy Team+ Award 2024, 2025を2年連続で受賞した高い開発生産性を持つ
• 技術的な側面として「DRYとの向き合い方(境界設計)」が開発生産性に強く作用していた
• 早期のプロダクト開発では「まずはスピードを最優先」という判断がしばしば下される
• 短期効率だけを信じて場当たり的な共通化、とりわけ「誤ったDRY」を積み重ねると、ほんの1ヶ月後にはその短期効率こそが最大の足かせになって返ってくる
• 初速を上げたつもりが境界が溶けたコードベースのメンテに追われ、「本当にやりたい開発」に時間を使えなくなっていく
• 開発効率は時間とともに自然減衰するものだが、誤った共通化はその減衰曲線を自ら急角度に傾ける
• Google社も2024年に「Don't DRY your code prematurely」という記事を公開し話題を呼んだ
• アーキテクチャカンファレンス2025でも「変更容易性(Modifiability)」こそが持続可能な開発の最重要資産であると多くの登壇者が語った
• AI時代だからこそ「Adaptable AI(AIの変化に適応し続ける設計)」が必要である

■ 2. DRYとOAOOの違い

• OAOO原則(Once and Only Once):
  • 同じロジックやデータ操作をプログラム中で2回以上定義しないことを目指す考え方
  • 主に「コードの重複」を対象とする
• DRY原則(Don't Repeat Yourself):
  • 「同じ知識・ビジネスルールが複数箇所にバラバラに埋め込まれている状態」を避け、単一の表現に集約する考え方
  • 主に「知識の重複」を対象とする
• DRYは単なる「コピペ排除」ではない:
  • 同じコードでも、背負っている「意味」や「前提」が違うなら、必ずしもDRYの対象とは言えない
  • 逆に、コードとしては違っていても、同じビジネスルールを複数箇所に書いているならDRY違反になり得る
• 本記事で扱う問題は、本来は異なる意味を持つ操作やユースケースを「同じ知識」と見なしてしまい、1つの関数に押し込めてしまった結果の失敗である

■ 3. DRYの誤用が発生する場面

• 粒度の大きい一連の手続き(ワークフロー)に対して行われる
• 「同じ処理がありそうだから」という理由だけで共通化する
• 背景にあるユースケースの違いを無視する
• 無理に共通化の抽象を導入する
• 本質的には異なるユースケース・異なる概念を「見た目のコードが似ている」というだけで一つにlumping(ひとまとめ)してしまう問題が起きている
• これはDRYの本来の目的である「知識を一意に保つ」こととは異なる

■ 4. 具体例:ユーザ作成ユースケースの悪い共通化の段階的悪化

• ステップ1:素朴な手続き:
  • 「ユーザを1人作成する」というユースケースがフラットに記述されている
  • この時点では問題は少ない
• ステップ2:別ユースケースでの「ほぼ同じ処理」の登場:
  • 部署の初期構築の一環としてユーザを1人作成するユースケースが追加される
  • 見た目上は重複があるが、この段階ではまだ「ユースケースが2つあるだけ」である
• ステップ3:「重複しているから」という理由だけの共通化:
  • service_add_userという共通関数にロジックをまとめる
  • まだこの時点では致命的な問題は顕在化していないが、「ユースケースごとにフラットに書かれていたもの」を「大ぶりな共通関数に吸い寄せ始めている」状態である
• ステップ4:再利用志向がN+1を生む:
  • 「複数ユーザを一括作成する」要件が加わる
  • 既存のservice_add_userを再利用すると、「1人用の処理を、バルク処理でもそのまま流用する」という安易な再利用によってN+1的な非効率I/Oを潜在させてしまう
  • 元々service_add_userは「1人のユーザを作る」ための手続きとして書かれたものであり、「多数ユーザを一括作成する」というユースケースを考慮して設計された抽象ではない
• ステップ5:オプショナルパラメータ地獄と責務の膨張:
  • 「メールアドレスだけで仮登録できる」ユースケースが追加される
  • service_add_userを拡張して対応すると、name/ageがオプショナルになり、実際の振る舞いは「パラメータの組み合わせ×条件分岐×デフォルト値」に依存し、関数内部に隠蔽される
  • 「通常登録」と「仮登録」という別ユースケースが、どちらも同じ入力型に押し込められる
  • 型定義からは必須なのか任意なのか読み取れない

■ 5. 問題の本質

• service_add_userは守るべきルールを表す抽象にはなっていない
• 代わりに複数のユースケースをまとめた「なんでも入り処理関数」になっている
• DRYの名のもとにやっているのは:
  • ビジネスルールの重複をなくすことではない
  • ユースケースの違いを無視して1箇所に押し込めること(lumping)である
• 本来DRYを適用すべきなのは守るべきルール(不変条件)そのものであって、手続き・段取り(オーケストレーション)に対してではない

■ 6. 正しい設計:ルールと手順の分離

• ルールを集約したUserクラスの導入:
  • ユーザに関する「守るべきルール(不変条件)」を集約した構造体
  • このインスタンスが存在する限り、データは常に正しい状態であることを保証する
  • コンストラクタで不正な状態を防ぐ
  • 「通常登録」「仮登録」の違いを生成メソッドで明示する(create_regular, create_reserved)
• ユースケースは「手順の管理」に徹する:
  • 共通関数を作ろうと頑張るのではなく、ユースケースごとの手順を素直にフラットに書くことに徹する
  • ルールのチェック・状態の正当性はUserクラスに集中する
  • ユースケース層では「どのルートで、何人分、どのような粒度でI/Oするか」を素直に書く
  • 一括作成ユースケースでは必要に応じてbulk_saveなどの最適化を行える
• 結果として:
  • DRYの対象は「ユーザの整合性ルール」
  • 共通化しない(あえてボイラープレートを許容する)のは「ユースケースごとの手順」

■ 7. 抽象化を導入してよいかを判断するチェックリスト

• その共通化は「知識」を一意にするか:
  • 単にコードが似ているだけでなく、ドメインルールや整合性チェックを一箇所に集約しているか
• その関数の責務はユースケースに引きずられていないか:
  • 明らかにユースケースが違うものを同じ関数に押し込んでいないか
  • 新しいユースケースを追加したときにその関数が壊れそうにならないか
• 「データの整合性を守る構造体」として切り出せるか:
  • その共通処理はデータの正しさを保証するためのものか
  • もしそうなら手続きの一部として書くのではなく、ルールを持った構造体として独立させられないか
• 共通化によってパフォーマンス制約を固定化していないか:
  • 「1件処理する関数」を共通化した結果、バルク処理の最適化余地を消していないか
• 変更頻度が高い部分を無理に一箇所に寄せていないか:
  • ビジネスルールとして安定していそうな部分だけを共通化できているか
  • 仕様が変わりやすいユースケース単位の手順は、しばらくは重複を許容したほうが楽ではないか

■ 8. AI支援開発における境界設計の重要性

• AIのコード生成は「型と境界」を手がかりとして推論する:
  • 関数やメソッドの引数の型、データ構造の形状、インターフェースの粒度、責務の境界などを手がかりにする
  • オプショナルだらけの入力データ定義、ユースケースを無理やりまとめた巨大な関数、前提が暗黙化した共通化はAIが推論するための手掛かりを失わせる
  • 結果としてLLMが誤った前提でコードを生成したり、リファクタリング提案の品質が著しく落ちる
  • これは設計の品質がAI推論可能性に直結していることを示している
• AIは「明確なルール」を理解しやすい:
  • ルールとデータをひとまとまりの構造体として閉じ込めた設計はAIと非常に相性が良い
  • 構造として明示されているとAIは非常に正確に推論を行える
  • オプション引数の組み合わせ次第で挙動が変わる関数はAIにとって「解釈不能な塊」となる
• AI支援型リファクタリングは「型の境界」単位で作用する:
  • 型、メソッドの定義、レイヤー境界、依存の方向性が明瞭であるほどAIのリファクタリング精度は劇的に上がる
  • 境界が曖昧だとAIは誤った提案をする
  • 設計の曖昧さはそのまま「AIが壊すリスク」になる
• 境界が明確だとAIとの協調作業が「加速」する:
  • 既存構造に沿った拡張提案が極めて正確
  • 新ユースケースを自動生成しやすい
  • I/O最適化の提案がしやすい
  • 変更の影響箇所を極めて正確に推論する
  • AIの性能が最大化される

■ 9. AI時代の「速さ」の本質

• ソースコードを書くコストは劇的に下がった
• AIを使えば構造の崩れたコードも誤った共通化もこれまでとは比較にならない速度で量産できてしまう
• これは技術的負債をマッハで積み上げられる時代の到来とも言える
• 真に競争力を持つのは「最初にコードを書き殴ったチーム」ではない
• 市場のフィードバックを受け、仕様変更に耐え、システムを破壊することなく安全に進化させ続けられる(Modifiabilityを持つ)チームである
• 「ルールを守る構造体」や「責務の分離」といった設計はドメイン駆動設計(DDD)における戦術的設計の一部である
• これらはAIによる爆発的なコード増殖のなかで「変更容易性」という最大の資産を死守するための極めて実利的な防衛手段である
• ビジネスのコアをコードに反映させ、変更に強い構造を作る「戦略」を持つことがAIという強力な増幅器を積んだ開発者が壁に激突せずにトップスピードで走り続けるための唯一の条件である

(2025/12/07)

Go の JSON 処理が変わる！encoding/json/v2 のテストコードから学ぶ 15 の新常識

• Go の JSON 処理が変わる！encoding/json/v2 のテストコードから学ぶ 15 の新常識 - OPTiM TECH BLOG

• 1. 大文字小文字の区別（#14750）
• 2. omitempty の定義変更（#11939, #22480）
• 3. string オプションの適用範囲（#34268）
• 4. nil スライス、マップの出力（#27589, #37711）
• 5. 固定長配列の長さチェック
• 6. バイト配列（[N]byte）のエンコード
• 7. ポインタレシーバのメソッド呼び出し（#27722, #33993）
• 8. マップの出力順序（#27179）
• 9. HTML エスケープ
• 10. 無効な UTF-8 の扱い
• 11. 重複キーの扱い（#48298）
• 12. null のマージ動作（#22177, #33835）
• 13. 複合型のマージ動作（#21092）
• 14. time.Duration の表現（#10275）
• 15. 空の構造体
• まとめ
• おわりに

(2025/12/06)

今、MySQLのバックアップを作り直すとしたら何がどう良いのかを考える旅 〜YAPC::Fukuoka 2025レポート〜

• 今、MySQLのバックアップを作り直すとしたら何がどう良いのかを考える旅 〜YAPC::Fukuoka 2025レポート〜 | さくらのナレッジ

要約:

■ 1. イベント概要と背景

• 2025年11月14-15日に福岡工業大学でYAPC::Fukuoka 2025が開催された。
• 田中翼(yoku)さんが「今、MySQLのバックアップを作り直すとしたら何がどう良いのかを考える旅」というトークを実施した。
• yokuさんは日本MySQLユーザ会副代表で、2025年5月にさくらインターネットに入社したデータベース専門エンジニアである。
• さくらインターネットはガバメントクラウドの正式認定を受けるため、さくらのクラウドに機能追加を進めている。

■ 2. ガバメントクラウドのデータベースバックアップ要件

• ガバメントクラウドの調達仕様書には約300項目の技術要件が記載されている。
• データベースバックアップに関する要件は以下の4点である:
  • DBのバックアップを差分で取得でき、取得したバックアップはいつでもDBの復元に使用できること。復元時は別のサイズを選択できること。
  • DBのバックアップは一定期間(例:5分)以前のどの時点にでも戻せる形(Point In Time Restore: PITR)で取得できること。
  • DBのバックアップは予め設定したタイミング、周期、世代で自動的に定期実行できること。
  • DBのバックアップイメージはCSPの中であれば別のシステム、別のネットワーク、別の環境からも利用できること。
• 特に「DBのバックアップを差分で取得できること」と「どの時点にでも戻せる形(PITR)で取得できること」の2点が重要な検討事項となった。

■ 3. データベースバックアップ手法の分類

• フルバックアップ:
  • データベース全体のバックアップを取得する手法である。
• 差分バックアップ:
  • 前回のフルバックアップと現在のデータベースの差分を取得する手法である。
• 増分バックアップ:
  • 前回のバックアップと現在のデータベースの差分を取得する手法である。
  • 前回のバックアップがフルバックアップとは限らない点が差分バックアップと異なる。
• 1月1日から1月8日にかけて3種類のバックアップを混在して実施する例が図で示された。

■ 4. PITR機能の実装方法

• PITR機能は3種類のバックアップ手法を組み合わせて要件を満たすバックアップを取得する。
• MySQLにおけるPITRはバイナリログを使用して実現される:
  • バイナリログはデータベースの変更操作を記録したものである。
  • フルバックアップを取った時点のバイナリログ情報を記録し、それ以降のバイナリログを継続的にコピーし続けることで実現できる。
  • バイナリログは増分バックアップに相当する。
• ガバメントクラウドの要件「バックアップを差分で取得」とは厳密には異なるが、PITRを実現するにはフルバックアップとバイナリログだけで実装する方がシンプルである。
• 要件「一定時間(例:5分)以前のどの時点にも戻せる形で取得できること」は「少なくとも5分に1回バイナリログをバックアップすればよい」と解釈できる。
• mysqlbinlogコマンドでバイナリログをストリーミング出力させ、バイナリログが出力され次第すぐにバックアップとして保管される仕組みを実装した。
• バックアップコマンド例:
  • target_binlogを特定し、mysqlbinlogコマンドで継続的に出力する。
• リストアコマンド例:
  • xtrabackup_binlog_infoからtarget_binlogを取得し、該当するバイナリログファイルを順次取得してmysqlbinlogコマンドで適用する。
• リストアの流れ:
  • 戻したい時刻を指定する。
  • それよりも一番近いフルバックアップを入手する。
  • フルバックアップよりも後、かつ戻したい時刻よりも前で最新の差分バックアップを入手し適用する。
  • 戻したい時刻と差分バックアップの間のバイナリログを入手し適用する。

■ 5. MySQLのフルバックアップツール

• MySQLのフルバックアップを取得するツールは以下の通りである:
  • コールドバックアップ
  • MySQL Enterprise Backup
  • Percona XtraBackup
  • CLONE INSTANCE
  • mysqldump
  • MySQL Shell Dump/Load Utility
  • MyDumper
• mysqldumpは有名だが遅いため推奨されない。
• 差分が取れるフルバックアップツールはMySQL Enterprise Backup(MEB)とPercona XtraBackup(xb)の2つである。
• これらのツールの動作原理:
  • ibdファイル(InnoDBのデータファイル)をコピーしている間、継続的にInnoDBログをコピーし続けることでバックアップを取得する。
  • リストアはバックアップ時にコピーしたibdファイルとInnoDBログを使用して実行する。

■ 6. バックアップとリストアの実装例

• xtrabackupを使用したフルバックアップと差分バックアップの実行例:
  • フルバックアップ: xtrabackupコマンドで--backupオプションと--target-dirオプションを指定する。
  • 差分バックアップ: 最新のフルバックアップを特定し、--incremental-basedirオプションで指定する。
  • 増分バックアップは常に取り続ける(リストア時に必要となるため)。
• xtrabackupを使用したリストアの実行例:
  • フルバックアップからのリストア: 指定時刻より前の最新のフルバックアップを特定し、xtrabackup --prepareコマンドで--apply-log-onlyオプションを指定して実行する。差分バックアップがない場合は--apply-log-onlyをつけてはいけない。
  • 差分のリストア: 指定時刻より前の最新の差分バックアップを特定し、xtrabackup --prepareコマンドで--incremental-dirオプションを指定して実行する。
• mysqlshを使用したバックアップとリストアの実行例:
  • フルバックアップ: mysqlshコマンドでutil dumpInstanceを実行する。
  • リストア対象の識別: 指定時刻より前の最新のフルバックアップを@.jsonファイルから特定する。
  • @.jsonファイルからバイナリログの情報(binlogFile、binlogPosition、gtidExecuted)も取り出せる。

■ 7. まとめと成果

• MySQLのバックアップはxtrabackupとバイナリログを使用することで実現できる。
• mysqlshを使用する方法もあり、フルバックアップも増分バックアップもmysqlshコマンドで取得可能である。
• 今回の成果はさくらのクラウドのデータベースアプライアンスにおけるPITR機能としてリリースされた。
• PITR機能が使用できるのはMariaDBのみである。
• MariaDBはMySQLから派生したソフトウェアだが、現在は互換性がなくなっているため、検討した内容がそのまま実装されているわけではない。
• 検討した成果によってガバメントクラウドの要件をいくつかクリアできた。
• さくらのクラウドはガバメントクラウドの正式認定を目指して前進を続けている。

関連:

• 今、MySQLのバックアップを作り直すとしたら何がどう良いのかを考える旅

(2025/12/05)

なぜデザインシステムをコードで管理するのか

• なぜデザインシステムをコードで管理するのか - Findy Tech Blog

• ユーザーと同じ環境でものを見る
  • デザインツールと実装環境の違い
  • コードで管理する最大の価値
• 型の力で強制できる
  • 無理やり実装を防ぐ仕組み
  • コードだからこそ実現できる強制力
• 最初から徹底できる
  • 後付けでは浸透しない
  • AI時代の開発スピードに対応する
• デザインをコード管理することは必要不可欠
• Figma Schemaが示す方向性

(2025/12/04)

「この施策の目的とKPIは？」という問い掛け

• 「この施策の目的とKPIは？」という問い掛け - フジイユウジ::ドットネット

要約:

■ 1. 早すぎる目的・KPI設定の問題点

• 会議やSlackのやりとりで「目的とKPIは？」という問いかけが出ると、すぐにアクションに移すべきだった内容が停滞する
• 目的とKPIが決まるまで実行できなくなり、「なぜやるのか、どう計測するのか」を決めるための会話に時間が取られる
• 目的の話がまとまると「別の方法が良いのではないか」という議論になり、1、2ヶ月が経過する
• 最終的には「検討します」のまま塩漬けになり、その施策の話がされなくなる

■ 2. KPI・目的設定自体の意義

• KPIや目的を決めること自体は良いことである
• 数字や言語化された目的があれば、目的に向かってブレずに動きやすい
• やるべきことにリソースを集中させることができる
• 大きな目的やKPIが早すぎる段階で語られることで、理解を深めることや観察のためのアクションが阻害される
• 結果的に単に動きが悪くなってしまう場合がある

■ 3. 過剰管理の発生メカニズム

• 未知や不確実性への恐れが過剰管理を生んでいる
• 「施策ごとにKPIとか目的が設定されるべき」という言葉は一見正しいように見える
• 「まず触れてみて、感触を掴む」という目的で十分なときには過剰管理となる
• 未知や不確実性への恐れが「ちゃんとした目的やKPIがあるべき」という過剰管理を生んでいる
• 「触ってみる・やってみる」によって学んだり観察したりする探索的アクションすら禁止される状況が生じる

■ 4. AI開発ツール導入の具体例

• AIを活用した開発をしていない開発チームがCursorやClaude Codeをエンジニアに使ってもらおうとする場合を例示している
• 「目的はなんですか？ツールを使うことは目的ではないですよね。開発生産性を上げることですよね。開発生産性はどのように計測して、ROIは……」という問いかけが出る
• このような早すぎる目的・KPI設定の要求は、試行錯誤を阻害する
• AIを使った開発でどういうことが起きて何がこれまでと違うのかを知らない人が「どのくらい効率良く開発できるようになるのか出せないなら、AIを使うべきではない」と言い出すと終わる

■ 5. 状態目標と経験の価値

• やってみて経験する・理解を深めるということが事業的に意味のある状況ならば、それは十分に「状態目標」として機能する
• 経験すること自体が事業成長という目的に向かっている行為として機能する
• 目標達成したかどうかが感覚的にしかわからないことがダメな理由はない
• 事業的に意味のあるアクションが「厳密に測定可能ではない」というだけで阻害される方が損失である

■ 6. コンテンツマーケティングの具体例

• 自社の情報を発信するときに「まずは書いてみて、どのくらい大変か」や「自分たちは、どんな品質の記事が書けるか」を体験してみる必要がある
• 試行錯誤した経験もないまま「毎月のPVはどのくらいを目指していますか」と聞かれると試行錯誤が阻害される
• 試行錯誤した経験がないため誤ったKPIを設定してしまう
• 探索的に動くだけでも良いのにKPIや大きな目的に縛られて「うまくいかないので止めます」を繰り返す状況が発生する

■ 7. 勝ち方を知らない段階での問題

• 勝ち方(うまくいく方法)もわかっていない段階から「勝ちに行く手」を決めようとしてもダメである
• 勝ち筋かどうかを測定しようとしてもダメである
• 手触り感がないことにKPIを決めるのはアホである

■ 8. 逆の極端な状況への警告

• 観察と理解が十分な段階に進んでいるのにいつまでも「とりあえず色々やってみましょう」を続けるのはアホの極みである
• 目的を目指すためのKPIを決めてリソースをつぎ込めば良いのにいつまでも「色々試してます」で留まってしまうのは良くない
• もう仮説を立てられるのにいつまでもなんとなくやってみるのもアホの極みである

■ 9. 適切な対応方法の提案

• 「これをする目的とKPIは？」と言われたときに、まだ試行錯誤や探索的アクションが必要であれば適切な説明をすべきである
• 「まずは、短期間だけでも経験して学習するための探索的アクションを積ませてください。定量目標がなくても、アクションに対して学んだことを振り返りする方が、良かったかどうかや今後どうすべきかがハッキリします」と伝えることが有効である
• どうしても必要であれば仮当てのKPIくらいはあっても良い
• 定量目標や本質的な目標の前に肌感を掴むというのは感覚的な話になるため怖がる人がいるのは理解できる
• 勇気をもって感覚を掴む方がうまくいく状況もある

(2025/12/03)

スタートアップとかいう界隈に３年いて思ったこと

• スタートアップとかいう界隈に３年いて思ったこと｜イコラ

要約:

■ 1. はじめに

• 医師を辞めてAI・スタートアップ界隈に来てからもう少しで3年になる
• 自分自身はAI業界に転身したつもりなのでスタートアップ界隈という認識は薄い
• やっていることはザ・スタートアップである
• 医療AIはほとんど開発していない
• ずっと画像生成、音声合成、大規模言語モデルといったエンタメやディープテックに近い領域で戦ってきた
• toBよりもtoC寄りである

■ 2. 医師から虚構の世界へ

• 医師からこの業界に来て最初に食らった洗礼は言葉の重みの違いであった
• 医療の世界では正確性とエビデンスが命である
• 誇張は患者の死に直結する
• スタートアップの世界:
  • 実現していないことを高らかに語ることは嘘ではなくビジョンと呼ばれ称賛される
  • できないとは言わず(資金があれば)できると言う
  • ピッチは飛ばしてなんぼであり夢は大きければ大きい方がいい
• 実際にスタートアップはある閾値を超えると指数関数的に成長していくから多少の誇張は現実になる
• エンジニアの視点から見るとなんとも夢物語で10年後でも無理だろうというものがワンサカ出てくる
• この真逆のルール「虚構を現実に変えていくゲーム」に慣れるまでには少なからず脳の切り替えが必要であった

■ 3. エアフレンド時代の経験

• 医師を辞めて最初に飛び込んだのはエアフレンドというスタートアップであった
• CEOの圧倒的な熱量に惹かれてジョインした
• 来る日も来る日もアプリの仕様や骨格を煮詰めた
• それは自分にとってまさに青春とも呼べる宝物のような日々であった
• AI/Backendエンジニアとして、PMとして、画像生成AIの研究に没頭した
• ひたすら良いものを作ることにコミットしていた
• 致命的な落とし穴:
  • 良いものを作れば勝手にユーザーが集まるというエンジニア特有のナイーブな幻想を抱いていた
• ビジネスとしての骨格よりもプロダクトの美しさを優先してしまったのかなと今振り返ると思う

■ 4. Livetoon時代の挑戦

• その後LivetoonでCTO(最高技術責任者)として活動するようになった
• 現在もAIキャラクターや音声合成(TTS/STS)などの領域でプロダクト開発を続けている
• AIプロダクト開発には別の地獄がある
• それは技術の陳腐化速度が異常だということである
• OpenAIやGoogleが発表するモデルやプロダクトによって数カ月かけた作ったものが一夜にして無価値になる
• 音声合成AIを研究・開発している真っ只中に海外から人間と区別のつかないレベルのAPIが公開され全てが過去の遺物になるなんてこともあり得る
• 昨日の必殺技が今日の標準装備(デフォルト)になり明日にはゴミになる
• この徒労感と戦いながらそれでもなお自社プロダクトとしての価値をどこに見出すか
• 今のAIスタートアップにおけるプロダクト開発はまさにこの巨人の足元で踏み潰されないように城を築くようなヒリヒリする戦いの連続である
• 自分が下した決断も少なからずこういった影響を受けている
• LLMの自社開発・提供に待ったをかけたのも日本語TTSという海外の巨人がまだ来ていないジャンルに投資したのもそういった判断によるものである

■ 5. AI受託開発の実態

• プロダクト開発の苦行を横目に今のAIスタートアップの8割くらいが選んでいる道がある
• それはAI受託開発である
• PoC工場の実態:
  • やることはシンプルである
  • 大企業からの「これってAIでできないの?」という問いに対しChatGPT等のAPIを裏で回して「ほら、AIでこんな未来が作れます!」とパフォームしPoC(概念検証)を回す
  • 2024年頃まではAIというジャンルの先進性だけでそれなりにパイを取ることが可能であった
  • 2025年後半になって急に雲行きが怪しくなってきた
  • 理由は単純に誰でもできるようになったからである
• プロダクト開発能力を持たないため技術的な参入障壁がない
• 先行者利益など存在せずあるのはリソース勝負だけである

■ 6. 学生インターンの人海戦術

• 技術力で差別化できないとなるとAIのAPIを触れそうな学生インターンを大量投下して馬車馬のごとくPoCを高速回転させる必要がある
• うかうかしていると隣のスタートアップがさらに多くのインターンを投入してくる
• しかもAIの進化は目まぐるしく半年前に納品したPoCはあっという間に陳腐化する
• こうなると最終的にはコネクションゲームになる
• 技術ではなく誰が言っているかが重要になる権威性ゲームの始まりである
• そうなると強いのがドメインに入り込んで顔を売っていた人たちか圧倒的なネームバリューを持っている人たちである
• 後者の場合これはもう当たり前に東大勢(東大発ベンチャー)が圧倒的に強くなる
• 東大発というブランドで受託を取りM&Aによるイグジット(人生のアガリ)を目指すことが一つの勝ちパターンとして定着してしまっている
• 東大発スタートアップ界隈には尊敬する友人や共に戦う仲間がたくさんいる
• 彼らが真剣に技術と向き合っているのを知っているからこそ一部のブランドを騙る層が余計に目に付くのかもしれない

■ 7. 魑魅魍魎なエコシステム

• 真面目にやっている人たちが大半であるがこの歪んだ市場構造にはならず者も集まってくる
• 資金調達至上主義:
  • スタートアップの戦闘力は何故か調達額で測られがちである
  • シリーズどれくらい?からマウント合戦が始まる
• ロジックの美学:
  • まずはやってみなはれとは真逆である
  • 妄想ワールドの中でロジックの穴を乳繰り合うコンサル上がりの文化である
• ヤバい奴ら:
  • 投資資金を私的に利用し夜の街でフラフラしている
  • いつの間にか蒸発する声だけデカい人々である
• 制度ハック勢:
  • 売上はほとんど無いが補助金で食いつないでいる会社である
  • 最近では東大系の一部もこれに目をつけハックしきっている印象すらある

■ 8. デューデリジェンスの違和感

• 投資家(VC)について触れずにはいられない
• お会いしてきたVCの方々は皆さん本当に人格者で親身になって相談に乗ってくれる優しい方ばかりである
• 起業家の夢を応援したいという熱意も本物だと思う
• しかしいちエンジニアの視点から見ると技術の目利き(デューデリジェンス)という点ではどうしても違和感を感じてしまう瞬間がある
• 彼らは自分でAIモデルを作ったりGPUのエラーログと格闘したりするわけではない
• なのでどうしても判断基準がXのトレンドやChatGPTの派手なアップデート情報そしてわかりやすい権威に寄ってしまう傾向がある
• AIスタートアップに投資するといいつつ実態の調査は殆どできず表層の理解にとどまっている
• 東大発、松尾研出身といったブランドへの信頼が厚いのも理解できる
• しかしその結果として中身の技術的な難易度や独自性よりも安直に回収できそうな受託メインの優等生に資金が流れていないか
• 最近話題になったオルツの上場後の動きなどを見ても実態としてのAI産業を育てることよりもバリュエーションを上げて売り抜けるマネーゲームの側面が強くなっているように感じる
• これは私の観測範囲の偏りに過ぎないのかもしれない
• 本当に技術の本質を見抜きリスクを取って基盤産業を育てようとしている凄い投資家は存在するのに単に私のレベルが不足しているためにそういった方々に巡り会えていないだけなのかもしれない
• そうであれば完全に私の力不足であり精進あるのみである

■ 9. 雲の上のマネーゲーム

• 数千万円の調達やGPUコストに頭を抱えているのとは裏腹に桁違いの資金が動いている世界もある
• Third Intelligenceが初のラウンドで80億円、Sakana AIが追加で200億円調達するニュースがある
• 正直ここらへんはもう自分が生きている世界とはレイヤーが違いすぎて分からない世界である
• 彼らが掲げるAGI(汎用人工知能)や壮大なビジョンが具体的にどうなっていくのか分からない
• 分からないことには口を出さない主義なので深いコメントは避ける
• ただあるところにはあるんだなぁと感じる
• 現場で泥臭くコードを書いている身からするとどこか遠い国の神話を見ているような気分になる

■ 10. おわりに

• 医者を辞めこの世界に飛び込んだ
• そこにあったのは煌びやかな未来というよりは虚構と欲望そして地道な技術の積み上げが混在するカオスな世界であった
• 華やかな資金調達ニュースや東大ブランドの受託ビジネスを横目に見つつたぶん自分は現場で手を動かし続けると思う
• バブルが弾け流行りが去ったあとに残るのは結局のところ誰かの役に立つプロダクトを作れるエンジニアや実行者だと信じているからである

(2025/12/02)

「Linux」が選ばれるようになっている理由--単なる「Windows」離れを超えた潮流へ

• 「Linux」が選ばれるようになっている理由--単なる「Windows」離れを超えた潮流へ - ZDNET Japan

要約:

■ 1. Linuxへの移行が進んでいる証拠

• 同僚のJack Wallenと筆者は以前からWindowsからLinuxへの乗り換えを提案してきた
• 一部の人々にその声が届いているようである
• Zorin OS 18の事例:
  • 公開からわずか1カ月余りで100万件のダウンロードを達成した
  • そのうち78%以上がWindowsユーザーによるものである
  • 78万人ものWindowsユーザーが3.5GBものLinuxデスクトップディストリビューションをダウンロードするのは単なる気まぐれではない
  • Linuxデスクトップの愛好家なら異なるディストリビューションを試すのは趣味の一環だが、Windowsユーザーの場合は本気でLinuxへの移行を検討していると考えるべきである

■ 2. Linuxデスクトップの市場シェアの成長

• StatCounterのデータによれば、2020年にわずか1.5%だったLinuxデスクトップの世界シェアは、2024年には4%を超え、2025年には米国で過去最高の5%超に達した
• StatCounterの最新の米国データ(10月まで)ではLinuxは3.49%と表示されている
• ただし「unknown」が4.21%を占めている
• 推測としてこの「unknown」はLinuxを動かしているのではないか
• 他にFreeBSD、UNIX、OS/2である可能性は低い
• ChromeOSは3.67%とされているがこれは低すぎる印象である
• ChromeOSもLinuxの一種である(KDE PlasmaやCinnamonなどのLinuxデスクトップ環境ではなく、Chromeブラウザーをインターフェースとして使っているだけ)
• これらを全て合算するとLinuxデスクトップの市場シェアは11.37%になる

■ 3. エンドユーザーOS全体におけるLinuxの立場

• PCだけでなくスマートフォンやタブレットを含むエンドユーザーOS全体を見れば、Linuxの立場はさらに強固である
• 米国ではAppleのiPhoneが人気だが、StatCounterの最新データによるとAndroid(これもLinuxディストリビューション)が41.71%のシェアを誇っている
• 世界全体ではAndroidが72.55%という圧倒的なシェアを持っている
• PC、タブレット、スマートフォンを含むエンドユーザー向けOS全体の指標を広げて捉えるならば、Linuxこそがすでに支配的な立場にあると合理的に主張できる

■ 4. Digital Analytics Program(DAP)から見た現状

• StatCounterの数字には問題があるとの指摘がある
• 筆者がOSのシェアを確認する際に好んで使うデータソースは米国連邦政府のDigital Analytics Program(DAP)である
• このサイトは米国政府のウェブサイトへの訪問数とその分析をリアルタイムで提供している
• 過去30日間の平均セッション数は16億件に達し、1日当たり数百万のユーザーが訪問している
• DAPはデータを加工することなく、人々が実際に何を使っているかを詳細に示している
• DAPはGoogle Analyticsのアカウントから生データを取得している
• DAPはデータをウェブ上に表示するコードやデータ収集コードをオープンソース化しており、JSON形式でデータをダウンロードして自分で解析することもできる
• DAPの集計結果:
  • Linuxデスクトップのシェアは現在5.8%である
  • 筆者が10年前にDAPの数字を見始めた頃、Linuxデスクトップのシェアはわずか0.67%だったことを考えると驚くべき成長である
  • Chrome OS(1.7%)とAndroid(15.8%)を加えると、米国政府のウェブサイトにアクセスするユーザーの23.3%がLinuxユーザーということになる
  • Linuxカーネルのユーザー向けの存在感は「デスクトップLinux」というラベルが示す以上に大きい
• Windows 10とWindows 11の状況:
  • Windows 10はすでに引退期に入っているはずだが、DAPの数字では依然として人気があり16.9%を占めている
  • Windows 11は13.5%である
  • これに対しStatCounterでは米国においてWindows 11がリードしており、全Windowsユーザーの64.83%を占め、Windows 10は31.92%と大きく後退している
  • それでもWindows 10を使い続けてセキュリティリスクを抱えているユーザーがあまりにも多い
• IT資産の検出とインベントリーを行う企業Lansweeperによると、1500万以上の消費者向けデスクトップOSを分析した結果、Linuxデスクトップは現在PC市場シェアの6%強を占めている

■ 5. Linuxが成長している理由(当初挙げた5つの要因)

• 筆者は2025年、WindowsからLinuxへの移行を促す要因として5つを挙げた:
  • MicrosoftがWindowsを製品として扱う姿勢からMicrosoft 365やクラウドサービスへ重点を移したこと
  • SteamとProtonによるゲームの実用性向上
  • 主要ディストリビューションの使いやすさが劇的に改善されたこと
  • ハードウェア対応の拡大
  • プライバシーやデータ管理への懸念の高まり

■ 6. 追加で浮上した3つの要因

• Windows 11へのアップグレードができないハードウェア制約:
  • 多くの企業やユーザーがWindows 11に「アップグレード」できないにもかかわらず、まだ十分に使えるWindows 10マシンを所有している
  • ControlUpの調査によると、消費者および企業のWindows 10マシンの約25%はWindows 11に移行できない
  • このハードウェア制約はMicrosoftの仕様を満たすためだけに新しいマシンを購入するのではなく、Windows 10のサポート終了後も使い続けようとする大きな理由になっている
• Windows 11への移行を強く望んでいない事実:
  • 英国の消費者団体Which?が2025年9月に実施した調査では、回答者の26%がアップデート終了後もWindows 10を使い続ける意向を示した
  • 興味深いことに6%はLinuxなどの代替OSへの移行を計画している
  • ユーザーがためらう主な理由は3つ:
  • Windows 10は「十分に良い」
  • Windows 11は意味のある改善と見なされていない
  • 強制的なインターフェース変更(中央配置のスタートメニュー、コンテキストメニュー、既定アプリの挙動、Copilotの統合)を好まない
  • ゲーマーはWindows 11がゲームを遅くしたり互換性の問題を引き起こしたりするのではないかと懸念している
  • 実際、Windows 11の10月のアップデートではNVIDIA搭載の一部ゲーミングPCでパフォーマンスを低下させるバグが発生した
• Windows 11のAIエージェント型OSへの変貌:
  • Windows 11がAIエージェント型OSへと変貌していることを全ての人が歓迎しているわけではない
  • AIブームにもかかわらず、Microsoftに行動を逐一監視されるようなAIを望まない人もいる
  • MicrosoftでWindowsおよびDevices担当プレジデントを務めるPavan Davuluri氏が11月10日に「Windowsはエージェント型OSへ進化し、デバイス、クラウド、AIを接続して、インテリジェントな生産性と安全な作業環境を実現する」とXに投稿した際、ユーザーがこのビジョンを歓迎することを期待していた
  • しかし現実は違った
  • 最も多くの反応を得たコメントは「それはMacやLinuxへの移行を促す製品に進化している」というものだった
  • AIによる監視を受けず、自分のPCで何が起きているかを完全にコントロールできる従来型のデスクトップを求めるなら、今後Linuxがほぼ唯一の選択肢になる

■ 7. デジタル主権の問題

• WindowsからLinuxへの移行を検討する最後の理由は、米国のユーザーにとってはあまり重要ではないが、米国外のユーザーにとっては非常に大きな意味を持つ
• 欧州連合(EU)の政府は米国の政治的圧力の下でMicrosoftがサービスの約束を果たすことを信用していない
• この不信感は「デジタル主権」という取り組みに発展し、EU企業が米国のテック大手よりもはるかに信頼できる存在と見なされるようになった
• その結果、多くのEU加盟国はMicrosoftのプログラムを廃止し、オープンソースソフトウェアへと移行している
• それはデスクトップ分野にも及んでいる
• あるEUグループは「EU OS」を開発した:
  • FedoraベースのディストリビューションにKDE Plasmaデスクトップ環境を採用したLinuxデスクトップの概念実証版である
• こうした動きはEUに限らない:
  • 英国もまたMicrosoftにデータを委ねることを信用しなくなっている
  • 2024年にComputer Weeklyが報じたところによると、Microsoftはスコットランド警察に対しMicrosoft 365やAzureのデータが英国国内にとどまることを保証できないと伝えた
  • 当時、英国内閣府の元ICT責任者であるNicky Stewart氏は「Microsoftは『主権クラウド』と称するものを売り込んでいるが、主権とは何を意味するのか。真に主権的なデータであれば、いかなる状況でも海外に送られることはないはずだ」と語った
• Windows 11のデータが米国のデータセンターとの間でやりとりされる可能性がある以上、今後ますます多くの政府がWindowsを信用することに慎重になる

■ 8. 結論

• これら全ての変化を総合するとLinuxはもはや「マニア向けの特別な選択肢」ではなく、Windowsのアップグレード地獄やサブスクリプションモデルから抜け出したい人々にとって現実的な選択肢となりつつある
• デスクトップLinuxは長年の「負け犬」から脱却し、日常的なコンピューティングにおいて小さいながらも意味のある存在へと進化している
• 特に技術に精通したユーザー、米国外の公共機関、そしてより安価で信頼できるデスクトップを求める一般消費者や企業ユーザーの間でその存在感を高めている

(2025/12/01)

仕様は“書く”より“語る” - 分断を超えたチーム開発の実践

• 仕様は“書く”より“語る” - 分断を超えたチーム開発の実践 / 20251115 Naoki Takahashi - Speaker Deck

まとめ

チーム分割は、チームの仕様検討力を阻害していた。

（STEP1） 役割が固定化されると、理解は属人化する。

（STEP2） チームで語り、合意を育てる文化が自己組織化を支える。

（STEP3） 設計を「書く」から「語る」へ。 プロダクトの成長をチームで考え、実現し続けられる状態を作ることが、 長期的なプロダクト開発にとって大切なことだった。

(2025/12/01)

Verifiability

• Verifiability | karpathy

要約:

■ 1. AIと歴史的先例の比較

• AIは様々な歴史的先例(電気、産業革命など)と比較されてきた
• 最も強力な類似性はAIを新しいコンピューティングパラダイムとして捉えることである
• なぜなら両者は根本的にデジタル情報処理の自動化に関するものだからである

■ 2. Software 1.0時代の特徴(1980年代のコンピューティング)

• 1980年代に雇用市場へのコンピューティングの影響を予測する場合、タスク/仕事の最も予測力のある特徴は「指定可能性(specifiability)」であった
• 指定可能性とは、機械的に情報を定型的で簡単に指定できるアルゴリズムに従って変換しているだけかどうかである
• 例:タイピング、簿記、人間計算機など
• 当時、これはその時代のコンピューティング能力が手作業で手動で書くことを可能にしたプログラムのクラスであった
• 筆者はこの手書きプログラムを「Software 1.0」と呼んでいる

■ 3. Software 2.0時代の特徴(AI時代)

• AIによって、これまで手作業では書くことができなかった新しいプログラムを書くことができるようになった
• 方法:
  • 目的(例:分類精度、報酬関数)を指定する
  • 勾配降下法を介してプログラム空間を探索し、その目的に対してうまく機能するニューラルネットワークを見つける
• これが筆者が以前のブログ投稿で述べた「Software 2.0」である
• この新しいプログラミングパラダイムでは、注目すべき新しい最も予測力のある特徴は「検証可能性(verifiability)」である

■ 4. 検証可能性の定義と条件

• タスク/仕事が検証可能であれば、直接的にまたは強化学習を通じて最適化可能である
• ニューラルネットは極めて優れた動作をするように訓練できる
• これはAIがどの程度何かを「練習」できるかということである
• 環境は以下の条件を満たす必要がある:
  • リセット可能(resettable):新しい試行を開始できる
  • 効率的(efficient):多くの試行を行うことができる
  • 報酬可能(rewardable):行われた特定の試行に報酬を与える自動化されたプロセスが存在する

■ 5. 検証可能性と自動化の関係

• タスク/仕事が検証可能であればあるほど、新しいプログラミングパラダイムにおける自動化に適している
• 検証可能でない場合、以下のいずれかに依存する必要がある:
  • ニューラルネットの汎化の魔法から生じることを期待する(指を交差させて祈る)
  • 模倣のようなより弱い手段を使う

■ 6. LLMにおける進歩の「ギザギザした」フロンティア

• 検証可能なタスクは急速に進歩する:
  • トップエキスパートの能力を超える可能性も含む
  • 例:数学、コード、動画視聴に費やされた時間、正解のあるパズルのように見えるもの
• 他の多くのタスクは比較的遅れている:
  • 創造的なタスク
  • 戦略的なタスク
  • 現実世界の知識、状態、コンテキスト、常識を組み合わせるタスク
• これがLLMの進歩における「ギザギザした(jagged)」フロンティアを推進している

■ 7. まとめ

• Software 1.0は指定できるものを簡単に自動化する
• Software 2.0は検証できるものを簡単に自動化する

(2025/12/01)

超高速SQL単体テスト rawsql-ts/pg-testkit

• 超高速SQL単体テスト rawsql-ts/pg-testkit

(2025/12/01)

Webサイトの状態管理にnanostoresを使ってみて

• Webサイトの状態管理にnanostoresを使ってみて

(2025/12/01)

SELECT * がデータモデルの保守性を下げる話

• SELECT * がデータモデルの保守性を下げる話

(2025/12/01)

AIを使う開発者は自分の好みの言語よりも、AIのハルシネーションが少ないTypeScriptのような型付け...

• AIを使う開発者は自分の好みの言語よりも、AIのハルシネーションが少ないTypeScriptのような型付け言語を選ぶようになる。GitHubがAIによる変化を予想 － Publickey

要約:

■ 1. GitHubの考察記事の公開

• GitHubは開発ツールとしてAIが導入されていくことで、プログラミング言語やフレームワークの選択にどのような影響を与えるかを考察したブログ記事を公開した
• 記事タイトルは「TypeScript, Python, and the AI feedback loop changing software development」(TypeScript、Python、そしてAIフィードバックループがソフトウェア開発を変えていく)である

■ 2. AI導入による静的型付け言語の選択傾向

• 静的型付け言語の方がAIがより正確なコード生成を行いやすい傾向にある
• それゆえにAIツールを利用する開発チームでは開発者の好みよりもAIとの相性が良いプログラミング言語が選ばれるようになる
• 多く使われるプログラミング言語はAIによる学習がより強化される
• それによってさらに多くの現場で使われるようになるというフィードバックループを形成していく
• 今年GitHubで最も使われている言語として、昨年まで1位だったPythonを抜いてTypeScriptが1位となった
• その背景にはこうした理由があったとされている

■ 3. AIとの相性が良い言語の特徴

• AIとの相性が良い言語が選ばれやすくなる傾向はTypeScriptに限らない
• Python、Java、Goのようにすでに大量のサンプルコードが世の中に存在し、同時にさまざまな目的に利用できるフレームワークが充実しているプログラミング言語ほど、AIによるコード生成で目的の達成が容易である
• そのためAIによる目的の達成が容易なプログラミング言語ほど、開発言語として選択されやすくなると予測されている
• AI登場以前、プログラミング言語の選択はランタイムとライブラリエコシステム、そして個人の習熟とのトレードオフであった
• しかしAI登場後は新たな制約が表面化する
• それはある言語を選択したときに、それがAIモデルによってどれほどの利点があるか、という点である

■ 4. AIによる適切な言語選択の容易化

• AIの登場は人気のプログラミング言語の人気をさらに増加させる傾向がある一方で、プログラムとプログラムをつなぐ「ダクトテープ」のような役割を担うBashのようなシェルスクリプト言語の利用増加にも貢献した
• それはコーディングの面倒な部分をAIに任せることができるようになったことで、開発者はその言語の好き嫌いよりも適切なツールかどうかを選択基準にしやすくなったためである
• つまりAIは単純にTypeScriptのようなプログラミング言語への人気の集中を招くわけではなく、開発者の好き嫌いや習熟の度合いによって乗り越えられていなかった目的に沿って適切なプログラミング言語を選択することも容易にする

■ 5. 結論

• 開発者はTypeScriptのように特定の言語を学ぶべきというわけではない
• 次の10年で生き残るであろう言語とツールとは、デベロッパーが最も好むものではなく、デベロッパーとマシンの両方が最も利点を共有できるものになるだろう

MEMO:

• プログラマの「書き味」や「開発体験」みたいなものよりAIがトチらない言語が優先されていくだろうという予測は恐らく正しい
• 今後更に「こだわりのある職人プログラマ」みたいな人材は必要とされなくなる時代になるのだろう
• それ自体はしゃーない

(2025/12/01)

MF2025-04 技術講演3：Excelデータ分析で学ぶディメンショナルモデリング～アジャイルデータモデリングへ...

• MF2025-04 技術講演3：Excelデータ分析で学ぶディメンショナルモデリング～アジャイルデータモデリングへ向けて～ - YouTube

要約:

■ 1. 発表者の背景とテーマ

• 発表者は横山(ハンドルネーム:ゆずたそ)で、風音屋という会社に所属している
• データウェアハウスやデータ分析系の活動を行っている
• 風音屋はデータ分析、データ基盤の構築を支援する会社である
• 昨年「アジャイルデータモデリング」という訳書を出版した
• テーマはExcelデータ分析でディメンショナルモデリングを扱う
• エントリー向けの内容を紹介する

■ 2. データ分析の前提条件

• 構造化データを扱うことを想定している
• 構造化データとは行や列など表形式で表現されるデータのことである
• これは従来のデータベースが前提としている形式で、最も安定してデータを管理利用しやすい
• テーブル(表形式)で管理するデータの関係性を表現したER図がある
• テーブル名と列名があり、Excelで例えるとシート名とその中に並ぶ列のようなイメージである
• 複数のテーブルをIDや識別値で結合していく
• 細かくテーブルを分けていくとデータの更新箇所が最小限で済む
• モデルの書き方として概念モデル、論理モデル、物理モデルといった書き方がある
• 正規化と呼ばれる概念がある:
  • データの重複や不整合を防いで効率的に管理するために行う
  • いくつか正規化の形があり、その条件を満たすようにテーブルを分解していく
  • 第3正規化された状態のことを第3正規形と呼ぶ

■ 3. Excelでのデータ分析における課題

• ビジネスパーソンは以下のような流れでデータ分析を行っている:
  • ローデータ(機関システムから出力したものなど)を一旦貼り付ける
  • 注文テーブル、商品のシートなどがある
  • それらを元にして別のExcelタブで集計を行う
  • 最終的に表示したい形式(例:商品カテゴリー別の毎月の注文数)を出す
  • この集計データを作ってからグラフに表示する
• 最終的に見たい形は正規化されたものではなく、分析要件に基づいて集計した結果である
• 営業地域別と業種別の切り替えの問題:
  • 多くの会社では日々の業務要件に適した形でデータを管理しがちである
  • 営業地域ごとに営業署があり、それぞれの中で管理している場合、営業地域別でデータを管理することになる
  • 担当エリアがあり、エリアに合わせてフォルダーが分かれている
  • 年月ごとにシート分けしている(例:京都の1月、2月、3月)
  • この単位で入力するため、入力しやすい形でシステムが作られていく
  • モニタリングも基本的には年月と地域の単位で行われる
• 当初は想定していなかった観点(例:業種別)でレポートを作るニーズが発生することがある:
  • マーケット環境が変化した時に適用するため
  • コロナのような事態が発生した場合、業種別で数字を見る必要が出てくる
  • 飲食店などの店頭サービス業での契約が減っている可能性がある
  • 逆にこの状態で伸びている業種があるかもしれない
• Excelファイルごとに分かれていると全部のシートを開いて業種の列を抽出していく作業が発生する
• これはあまり現実的ではない
• 当初の要件を満たすテーブルではなく、切り口を柔軟に変更できるテーブルが求められる

■ 4. データ分析における複数データソースの組み合わせの必要性

• データ分析を行う時は複数の元のデータを組み合わせていくことが一般的である
• 例:駅に近い店舗は雨の時だけ注文が上がった/下がったからクーポンを打つ場合:
  • 駅がどこにあるのかという情報が必要
  • 店舗がどこにあるのかという情報が必要
  • 駅に近いかどうかを判定する必要がある
  • 天気の情報が必要
  • 注文数がどう変わっているかの情報が必要
  • これらを組み合わせて使う必要がある
• 駅と店舗は住所が書いてあるが距離を測るには緯度経度が必要になる可能性がある
• 住所と緯度経度を変換するための前処理が必要で、そのための変換データを引っ張ってくる必要がある
• 店舗マスターは社内にある、駅の情報もどこかにある、住所と緯度経度の変換データもどこかにある、天気のデータは気象庁から引っ張ってくるなど、様々なものを集めてきて組み合わせていく
• データは事前に統合されていて一元管理されている方が分析する側からすると嬉しい
• データ基盤という言葉が一部で注目されている
• 複数のユースケースと複数のデータソース(情報源)をリボンのように結びつけていく一連のサービス群がデータ基盤と呼ばれるものである

■ 5. 正規化の問題点

• 正規化すれば解決するのではないかという考え方がある
• シートを細分化して第3正規形などで作る
• 契約の一覧、相談問い合わせ、契約明細、商品一覧、プロモーション一覧、顧客一覧、業種一覧、都道府県一覧、従業員一覧、所属一覧、部門一覧、担当エリア一覧などに細かく分ける
• 顧客の中に業種IDや都道府県IDがあるため、都道府県IDを見ていたところを業種IDを見るようにすれば集計は簡単にできる
• 理屈上は可能である
• ただし使う側(ビジネスユーザー、ITスキルが必ずしも高くないユーザー)からすると使いにくいポイントがある:
  • 毎回分析やモニタリングをするたびにER図を読む必要がある
  • そもそもER図の読み方を勉強しなければいけない
  • 数十枚あるシートを連携していく必要がある
  • 毎回その結合時の注意点をチェックしていく必要がある
  • キャンペーンの分析をする場合は日付の曜日や祝日を毎回計算する必要がある
  • データをどう組み合わせるかを使う時に考える必要がある
• 使う側のリテラシーを求めてしまう
• 分析の時にこれとこれとこれを結合してというのはややこしい
• 結果として使う側がユーザー手元でカスタマイズして結局自分用の使いやすいシートを作ってしまう
• 顧客一覧、業種一覧、都道府県一覧を3つのシートに分けるのではなく、顧客一覧シートの中で列として業種や都道府県の結果も書いてしまう
• これは使われないモデリングである
• 第3正規形が悪いわけでは当然なく、システム作る上で分けていった方がいい場面はもちろんある
• 記入やインサート・アップデートを考えてももちろん正規化の方がやりやすい
• ただし使う側がこうやって使ってしまうことは起きがちである
• 使う側の立場にちょっと寄り添う必要がある
• 最初から使われるこのシートをモデリングする側が提供するのも一つある

■ 6. ディメンショナルモデリングの基本概念

• トランザクションとマスターで分けるとちょうどいい
• ファクト(トランザクションに近いもの、集計対象となる出来事):
  • 例:契約シートが1個ある
  • これを見ると合計でいくらの契約になったかが分かる
• ディメンション(マスターに近いもの、比較の切り口となる軸):
  • 顧客ディメンション:業種別、エリア別の契約金額などの切り口のヒントになる
  • 従業員ディメンション:部署別の契約金額や営業成績などに使える
  • カレンダーディメンション:今月の契約金額、祝日や曜日によって効果が違うかを見る
  • 日付に対して祝日かどうか判定するフラグがあってもいい
  • データ分析の場合、日付は結合キーになることがあり得る
  • キャンペーンの取り組みと実際に注文があった時を紐付けて、このキャンペーンには効果があったかを判定することがある
• ファクトとディメンションを組み合わせて使えば使うだけで良い
• 契約の件数がどのくらい増えているか減っているかは、顧客のシートと組み合わせて顧客のシートの方で業種や都道府県を切り替えて見ていけばいい
• 使う側の都合だけを言うとこのくらいシンプルだと分かりやすい
• これがディメンショナルモデリングと呼ばれるものである:
  • ディメンション(分析の切り口)とファクト(集計対象となる出来事・事実)を提供するテーブル設計手法である
  • これらを組み合わせてデータ分析を行う
• 昨年出版した「アジャイルデータモデリング」という本はこれを紹介する本である

■ 7. データ分析の概念的説明

• 緑のキューブがあり、これが売上累計30億円という大きな事実(ファクト、出来事)の塊である
• データを分析する時はスライスしていく:
  • いろんな次元にスライスしていく
  • この期間での売上という風に切るとそれが2億円まで減る
  • さらに製品で切っていくと5000万円まで減る
  • さらに店舗という場所で分けていく
  • 全体のキューブの中のこの部分まで絞ると800円になる
• これを比較する:
  • この製品とこの製品で比べてどうなのか
  • 去年と比べて去年調子良かったのか悪かったのか
  • コロナの前と後でどのくらい減っているのか
• こうやって分けて比べていくのがディメンション(次元)である
• 多次元で切っていく、分析していくからである
• 実際の例:倉しコム(数年前に上場した新興企業、ECサイトを提供):
  • BIツールを使って画面上でディメンションをポチポチと絞り込んでいく
  • 直近90日で日時で見たい、モバイルアプリとウェブサイトで分けて見たい、商品のカテゴリーごとに分けたいなどを指定していってボタンを押すと欲しいデータが出てくる
  • 使う側は相当楽である
  • ファクトとディメンションの組み合わせをポチポチ選んでいけば集計できる状態が使う側だけからすると理想である

■ 8. BEAMフレームワーク

• BEAMとは:
  • ビジネスイベントアナリシス&モデリング(Business Event Analysis & Modeling)の略である
  • ビジネス上の出来事から要件分析してテーブルを設計していく
  • 結果としてスタースキーマ(真ん中にファクトがあって周りにディメンションがある形)を作る
  • スタースキーマは星型に見えるのでスターと呼ばれる
• ステイクホルダーと協力しながらブレインストーミングを行ってデータモデリングを進めるアプローチである
• このモデリングは使う人向けのテーブル設計である
• この本ではモデルストーミングと呼んでいる
• BEAMテーブル:
  • どんなデータが欲しいのかを具体的に書いていく
  • この人がこれをいつここで買ったみたいな情報が欲しいというのをずらっと実際に書いていく
  • なるべく具体的に書いていく
  • 最大で10年前まで遡りたい、最短で翌日にはデータを使いたい、物販と自社のECと外部ECまで分析したいなどの要件が見えてくる
  • 元のデータベースは違う可能性がある(物販の店舗だとPOSレジにデータがある、自社のECと外部ECでデータベースも違う)
  • データをどこに保存するかというモデリングをするとこれらはバラバラになるはず
  • しかし使う側からするとこれらはまとめて分析したいので同じディメンションに入れる必要がある
  • この差が見えてくる
  • クリエイト(作成)やアップデート(更新)をするのとは別にリード(読み取り)に特化したモデルがあるだろう
  • そのためにはその要件を顕在化するにはどんな風にデータを使いたいんですかというところの分析をする人がどんなデータが来るといいのかという具体例を書いていくことによって隠された要件を暴り出していく
• イベントマトリックス:
  • ファクトとディメンションをマトリックスで書いていく
  • 縦にディメンション、横にファクトを書いて、その組み合わせをチェックしていく
• これらを使って定期的なミーティングでこれらの中間成果物を更新したりしながら、次はこれを整備していこうかというTODOリストを作ってそれを対応していくサイクルを回していく
• これをアジャイルのプラクティスに沿ってやっていくことによって変化に対応していく
• これがアジャイルデータモデリング(原書タイトル:アジャイルデータウェアハウスデザイン)でアジャイルという言葉を使っている理由である

■ 9. ファクトのモデル化

• 分析対象の構造を確認する:
  • ビジネスの構造、業務フロー、業務の流れ、ユーザーの行動などをまず把握していく
• ファクト(集計対象、トランザクションファクト)は以下に分けられる:
  • 出来事
  • 指標
  • 計算方法
• ビジネスイベントの洗い出し:
  • モデル化した図からビジネスイベントを洗い出す
  • 来店して注文して発送して返品するみたいな流れがある
  • 注文と呼ばれるビジネスの中にも指標がある(件数、人数、商品数、金額など)
  • さらに計算方法もメリットがあるかもしれない(合計値、1人当たりの注文件数、1商品あたりの注文件数、YoY(去年に比べて今年がどのくらい増えているか)、増加率、増加数など)
• ビジネスイベント:
  • ビジネスにおいて発生する出来事である
  • この1つ1つのビジネスイベントが繋がってビジネスは実現される
  • ビジネスを改善するのはこの1つ1つのビジネスイベントを改善することとニアリーイコールである
  • 例:来店を増やす、注文を増やす、発送を早くするなど
• 指標:
  • ビジネスイベントを定量的に評価するための指標を定める
  • イベントがどうなって欲しいか、どうなると困るかを見ていくと決まるはず
  • 件数、人数、商品数、金額、時間、距離など
  • 多い少ない、長い短い、重い軽いなどの観点がある
• 計算方法:
  • 注文の中にも合計、1人当たり、1品あたりといったものがある
  • 場合によってはツールに任せるケースもある
  • テーブルとしてモデルに反映するのか、ツールに任せるのかはやり様がある

■ 10. ディメンションのモデル化

• ディメンションは5W1Hで考えると分かりやすい:
  • 誰が、何を、いつ、どこで、なぜ、どのように
  • ビジネスにおけるデータ分析の場合、分析軸5W1Hで比較することが多いから
  • 例:都心の店舗は郊外の店舗よりも客が多い(Where)、今年は去年より注文が増えている(When)、バッグは靴よりも平均単価が高い(What)
• どんな軸で分けて比べるのかを洗い出していく必要がある
• 洗い出しのヒント:
  • 業務フローから洗い出すパターン:
  • 誰が何に対してどんな作業をいつするのかが見えてくる
  • 店頭スタッフという人がいて、各商品の在庫があって、毎日20時お店が閉まった後に棚卸しをするなどが見えてくる
  • スタッフ別の切り口で分析をするかもしれない、商品ごとや在庫ごとに分析をするかもしれない、閉店後か閉店前かによって分析の軸が変わってくるなどが見えてくる
  • 具体例(レコード)から洗い出すパターン:
  • 同じ商品AとBがあった時に両方とも衣類という共通点がある場合、商品カテゴリー「衣類」がある
  • サイズで言うと同じ衣類でも夏物と冬物がある場合、販売時期という観点で見ていくとポイントがあるかもしれない
  • 一般的に冬物の方が重くて値段が高かったりすることが多い
  • 同じレコードの中のレコードの共通点や差異点を言語化していくと、そこがそのまま切り口になっている可能性が高い
  • 階層図:
  • 同じ商品でもカテゴリーもあればサブカテゴリーもある
  • 衣類があれば衣類の中に夏物というカテゴリーがあるかもしれない
  • 価格帯も1円単位の価格よりは1万円単位でまとめるとか
  • ユーザーや人間も性別と年齢がある
  • 性別と年齢は相互に連動しない概念である
  • ただし年齢「◯◯歳」と「◯◯代」はここは階層の粒度がより荒いのと細かいのになっている
  • 25歳と20代は粒度の関係になっている
  • 荒い方から細かい方に直すことはできないが、細かい方から荒い方に丸めることはできる
  • 20代から25歳は言えない(26歳かもしれないから)が、25歳は20代であることは言える
  • 細かい方で持っておけば荒く出すことはできる

■ 11. ディメンションテーブルの具体的設計

• 商品ディメンションの作り方:
  • 使う側が便利なExcelを作ろうとしたらどうなるか
  • 正規化しない状態でどうやって作るか
  • 価格という1円単位の列があった後に価格帯1万円単位という列も作っておく
  • 27円みたいなのが次は「1万円台」という値が入る
  • カテゴリーとサブカテゴリーがあるなど
  • 横に必要な粒度で集計できるように1番細かい状態を持たせておきながら、必要な粒度があるんだったらそれも集計できるようにしておく
• カレンダーディメンションの考え方(よくある質問):
  • 8月1日13時29分11.55秒をディメンションテーブルでどうやって切り出すか
  • ディメンションは単に5W1Hで切ったものではなく、あくまで分析軸である点がポイント
  • 0.55秒であることを軸にして何かカウントしたいか集計したいか→大抵の場合ノーである
  • たまに工場の産機器や自動車の機器が特定の時にだけ変な挙動をする可能性もあるかもしれないが、それは分析定義はアドホックで都度個別的にクエリを書いた方が良く、毎月毎月Excelシートで役員たちがモニタリングをするのとは違う
  • これであればテーブルとして用意するのではなく都度仮説があったらデータを直接見る方がいい
  • 8月1日であることを軸にしてカウントしたいか→イエスである(ケースバイケースだが、こういったケースが多い)
  • 日付からロールアップして、8月は例年売上が高い、この月曜日は、夏は毎年こうだ、この曜日は毎週こうだという特徴があるかもしれない
  • 8月1日を軸にしてこういったいろんな属性をつけていくことはあり得る
  • カレンダーディメンションを作っておいて日付ごとに1レコードのテーブルを作っておくのは1つのプラクティスとして有効である
  • 13時であることを軸にしてカウントしたいか→三角(UELか)くらいである
  • 飲食店だったらこの昼の時間帯や13時代の客数を集計したくなる可能性はある
  • シフトを決めるのにどのくらい来るのかによってシフトを決める必要があるから
  • 大きな経営計画を立てる時にざっくりとした推定を行うにはこういった情報があった方がいいかもしれない
  • ただしこれは8月1日とは関係なくはないかもしれないが、ちょっとまた別の文脈である
  • やるとしたらカレンダーディメンションとは別に時計ディメンションを作っておいて日付を付与しないで何時何分だけ持たせるのが1個テクニックとしてはある
  • 分析の粒度でこれを本当に1時間単位にするか、細かく1分単位にするか、10分単位や30分単位にするかは分析の粒度に合わせて調整していくのが現実的である
• 5W1Hに囚われるというよりは分析軸を意識して設計する

■ 12. アジャイルデータモデリングの必要性①チームの変化

• チームが変わるからデータモデリングを変えていくことが大事である
• 仮想ケースの例:
  • 刑人(経営者):データをモニタリングできるようにしたい
  • コンサルタント:ERPを整備しよう、収支や在庫などの経営資源を管理するのが重要
  • 取締役:リソース調整はできるようになったが、もうちょっとビジネスを成長させるための中身の話をしていきたい
  • 事業部長:うちのメインの事業、Web経由の申し込みで結構予算達成が左右される、ここを見た方がいいんじゃないか、事業成長のエンジンをウォッチするのが大事
  • マーケティング担当:アクセス解析ツールで見ましょう、どこの工程で止まっているのか、どの経路が活発なのか見よう
  • 経路5はすごく調子がいい、経路3は割と早々に工程2で止まってしまう
  • 経路3は一旦捨てて経路5に集中しようという会話ができる
  • この日人気YouTuberが商品言及してくれた、SNSですごい話題になった
  • アクセス解析ツールを見ると指名検索(商品名で検索してきている)であることしか分からないが、YouTuber効果なんじゃないか
  • そしたらもうYouTuberとガンガンコラボしたり広告出した方がいいんじゃないか
  • SNSの投稿なども含めていろんな関連データを社内外横断して見たい
  • それをできれば社員全員がモニタリングしてどんどん仮説を回していきたい
  • データエンジニアやソフトエンジニアがそういった基盤を作ってマーケティング担当がこれを見ながら全社員マーケティングやってくぞという動きになってくるかもしれない
• 会社全体で追うべきデータは当初の想定とはだいぶ違ってくる
• チームが何を重視するかは本人たちでも事前には予測できない
• 当然見るべきデータも変わってくる
• 見るべきデータが変わるということは、データをどこに保存するかを一旦置いといて、どうやって見るか、データを分析する時にどういうデータの形式だと使いやすいかという使う側のデータモデルのあり方は少なくとも変わってくるはず
• アジャイルな仮説検証サイクルは大事だが、今どんなデータがあるといいんだっけというのを言語化して、それを実装してデータを整備して分析してまた色々見えてくるので要求が変わってまた反映していくというサイクルを回す
• このデータモデルを継続的に改善するというサイクルを回して要求の変化に対して迅速に対応していく、適用していくのがポイントである
• だからアジャイルデータモデリングである

■ 13. アジャイルデータモデリングの必要性②ビジネスの変化

• ビジネス自体が変わる話をする(仮想ケース、あえて極端な話):
  • 自動車メーカーからゲームメーカーに転進することがあるかもしれない
  • 乗り物の部品を作っている町工場のメーカーがあった
  • 売上は堅調だが物価高等で苦しくなってきた
  • 主要販売先や銀行からプレッシャーを受けている
  • 反応を拓の位置を下げるために展示会で新素材を体験してもらおう
  • デモンストレーションとして体験型の運転シミュレーションゲームをセットで設置した
  • ものづくり好きな技術者が最高のクオリティに仕上げてしまった、レベルが高すぎる
  • 展示会にゲスト参加した海外の著名人がSNSで言及して世界中で話題になった
  • 試しにゲームを販売したら世界中で飛ぶように売れる
  • しかも円安でソフト産業は限界利益が少ない、部品に比べて収益率がすごい高い
  • 本当に黒字赤字ギリギリみたいな状態だったら部品の利益を超える可能性もある
  • 部品メーカーとして20年使えるはずのデータモデルを設計してERPを導入したところが、今ゲームメーカーとしてどんどん伸びている
  • どっちかっていうとゲームのプレイヤーの利用状況やSNSで話題になっている箇所、どこがスクリーンショットで取られているのかを分析する方が実は重要になってくる可能性もある
  • さらにCG制作会社、芸能プロダクションになってくることもあるかもしれない
  • 物の珍しさで最初はゲームが売れたが、徐々に売れなくなってくる
  • むしろ他のゲームメーカーからゲーム内の乗り物のCGを作ってくれないかという相談を受ける
  • CG制作会社として大活躍、めちゃくちゃ細かいところまで作り込んでいる
  • ゲームだけではなくて映像作品、世界中の映像作品でも引っ張りだこになる可能性もある
  • 日本のアニメーション映画が全世界でヒットしているというトレンドに乗って、海外のあらゆる映像関係者が注目するような会社になるかもしれない
  • CG制作会社としてモニタリングをすることになるかもしれない
  • 映画特集のテレビ番組に社員が出演する、社員の対応が結構いい感じで俳優じゃないかということでまた話題になる
  • 各局に呼ばれるかもしれない、結果芸能プロダクションとして有名になる可能性も0じゃない
  • 芸能プロダクションとしての形態のモデルになってくる
• 実際にビジネスは結構変わっている:
  • 旗売機を作っている会社が自動車を作り始める(トヨタ)
  • アニメーション映像を作っている会社がテーマパークも作り始める(ディズニー)
  • 花札を作っている会社がビデオゲームを作ってストリーミング販売に対応していく(任天堂)
  • 広告の雑誌を作っている会社がPOSレジや結婚相談を始める(リクルート、結婚相談はこの間やめることが発表された)
  • 専門書の物販を行っている会社がデータセンターを建設する(Amazon)
  • 進学塾を提供していた会社がホテルなどの不動産事業に切り替える(四谷と呼ばれる会社)
  • フリマアプリを作っている会社が決済アプリを作る(メルカリ)
  • メルペイの立ち上げは1年間で決済を立ち上げる、毎週毎週加盟店が増えていく、当然加盟店ごとにスキームや契約のスキームは違うだろうということでめちゃくちゃ大変だった
  • 発表者自身がこれを体験したからこそすごく思うことがある
• マーケットやビジネスが変わり続ける
• 10年後、20年後本当に未来を見通せるんだったら皆様今頃億万長者になっているはず
• そうじゃないんだとしたら自分は10年後、20年後読み通せないと思っていた方がいい
• マーケットやビジネスが変わり続けるという中で当然ながら見るべきデータも変わる
• 当然ながらそうするとデータモデルも変わる
• 継続的に要求を見直して設計を見直してモデリングを見直してそれを実装して整備して分析してまたサイクルを回すのが大事である

■ 14. AIエージェントとディメンショナルモデリング

• 生成AIによってデータ分析の自動化がすごい楽になりつつある:
  • ジュニアの分析者よりも正確だし、シニアの分析者よりも安いし早い
  • クロードデスクトップといったツールでデータを繋いでやっていけばそれっぽいレポートをすぐに作ってくれる
  • BIツール上の対話エージェント機能なども提供されている
• 生成AIがデータを正しく使うにはやっぱりデータの整備が必要である:
  • 社内の売上テーブルが50個あったらどの売上で分析すればいいか判断できない
  • 売上って何なのか(消費税含むのか含まないのか、途中解約ってどうやって計上するのか、年間契約って月で割り算するのか、割引ってどこで引くのか、返金って後で引くのかそれとも遡って引くのか、通販サイトやアプリ決済の場合決済手数料ってどうやって管理するのか)
  • 年間契約の場合、ある分析では今年の今月の売上すごい伸びていると報告しても、別の売上別の分析では月割で割り算したら半分になる
  • AIが生成した2つのレポートを見比べると今年の今月の売上が10倍近くずれる
  • これは話にならない
• ファクトとディメンションのテーブルが用意されているといい:
  • ここに売上テーブルがあり、カラムで消費税データを管理すると嬉しい
  • ファクトとディメンションのテーブルは用意されている
  • この時点でディメンショナルモデルだとAIは理解してくれる
  • この形式を見た瞬間に、これはディメンショナルモデリングで作られたテーブルだと気づける
  • こういう集計をするにはファクトのこれとディメンションを組み合わせて使えばいいんだろう、集計対象がファクトだろう、切り口がディメンションだろうということに気づける
  • このIDの列で結合すればいいんだろうということが判定できる
  • 割り算とか消費税抜きとかという列が仮にあると、こういった条件だったらこれを見ればいいんだろうということが見えてくる
  • AIが事業年度を多分日本の企業は4月から翌年3月なんじゃないですかって推測するんじゃなくて、事業年度列が既にあったらそれを使えばいい
  • 整備されているほどデータ品質が安定する、データの分析の品質が安定する
  • そうすると従業員がカジュアルに生成AIに頼れるようになってくる
• 実際の事例:
  • MicrosoftのPowerBIというBIツールを使う場合はディメンショナルモデリング(スタースキーマ)を結構前提としている
  • コパイロットの機能を使う場合も当然その前提である
  • メルカリ社のソラテスという分析のAIエージェントは、ベーシックテーブルと彼らが呼んでいるテーブルに依存して、このテーブルだけは見るようにという整備をしている
• データ活用の課題:
  • 活用効果が期待以上となる要因としてデータ品質が日本・アメリカ共に2位として上げられている
  • 国内686社の調査でデータ活用の課題として、セキュアな量を備えたデータの取得・整備ができないことが言われている
  • オラクルの2020年の調査で、データが細分化されていて使いにくいということを世界のグローバルの670人のテクノロジー部門の上級決定者とCO的な人達のうち73%が答えている
• シングルソースオブトゥルース(信頼できる唯一の情報源):
  • ここを見たら一旦ここを見ればいいんじゃない、ここを見たらデータを分析できるんじゃないという信頼できる軸がある���いい
  • 全体売上と言ったらこの箱を見る、こういった切り口で見ていくと見れるというのが概念としては必要なはず
  • 画面のイメージで言うとポチポチボタン押していくと欲しいデータが取れるになっていると使いやすいはず
• データパイプライン:
  • ファクトとディメンションを作るのはいきなりこれで作るんじゃなくて、機関システムなら機関システム、SNSならSNSからのデータ、スクレイピングしたデータなど各データがあるはず
  • それをやっぱり一元で前処理をして集計ロジックをかました上でファクトとディメンションを作っていく
  • これは使う側(理由側)のモデルとビューに分けるとしたら、こっちがモデルでこっちがビューみたいな感じ
  • DDD的に言ったら永続化とプレゼンテーション層と言ってもいい
  • 今回はこっち(ファクトとディメンション)の話をする
  • これを作るにはこれらのデータを組み合わせて作っていく必要がある

■ 15. 本書で扱わなかった内容

• 今回はエントリーの内容なので取り扱わなかったポイントがいくつかある:
  • 実際にファクトとディメンションをどんな風に設計するのか例をいっぱい知りたい
  • 今回ファクトが1個あってディメンションが周囲にあるという紹介をしたが、叩いたの関係もあるはず
  • マスターの値が変わる場合(ユーザーが静岡から東京に引っ越した場合、そのままマスターを上書きしちゃうと去年の購入が静岡じゃなくて東京に計上されてしまう)どうするのか
• これらの回答は「アジャイルデータモデリング」の本に書いてある

(2025/11/30)

MF2025-06 技術講演5：要件定義の中心にモデルを置きLLMが出力した要件に責任をもつ

• MF2025-06 技術講演5：要件定義の中心にモデルを置きLLMが出力した要件に責任をもつ - YouTube

要約:

■ 1. 発表者の背景と取り組み

• 発表者はVALUソースという会社を経営している
• 要件定義とシステムの可視化を行っている
• 最近はAIを使った要件定義に注力している
• いかにして要件定義をAIでやらせるかを毎日取り組んでいる

■ 2. AIで要件定義を行う際の前提条件と課題

• 前提条件:
  • AIは個別の企業のことを何も知らない
• 3つの課題:
  • LLMの出力をいかに理解するか（最も大きな問題である）
  • ある程度少量のデータで大量に出てくるため、どうやって理解するかが問題である
  • AIに適切なコンテキストをどうやって用意するか
  • 中規模から大規模なシステムでは最初の入力だけではどうにもならないため、軌道修正しながら最終的な要件に組み立てていく必要がある
  • 軌道修正をどうするかについて一つの形が見えてきている

■ 3. 課題解決のアプローチ

• 初期要望の入力:
  • ビジネスの背景や概要などの初期要望を入れてAIに要件定義させる
• 要件のビジュアライズ:
  • 文章だけではなかなか理解できないため、様々なものの繋がりをビジュアライズする
• 画面の確認:
  • 画面を中心に話をすると要件的にも進みやすい
  • LLMが出した出力から各アクター別にどんな画面になるのかをすぐに確認できるようにする
  • LLMが出したものがどういうものなのかということを理解するために用意している
• 要件の妥当性検証:
  • AIが出してきたものが本当に現場に適用できるのかを検証する
  • 環境を入力してそれで妥当性検証を行う
• 論理データモデルの活用:
  • 論理データモデルを出して、論理データモデルから要件を突き上げて正しいのか判断する
• 中心となるモデル:
  • 要件定義における要件には構造があると定義している
  • その定義に従ってAIを作業させる
  • モデルの周りにビジュアライズ、画面出力、論理データモデル作成などが付随している
  • 最終的にAIが出した要件を確認していく

■ 4. 入力サンプルの内容

• システムの概要を入力する:
  • サンプルとして訪問介護のシステムを使用している
  • どんな背景なのか、要求、ビジネスポリシーなどを記述する
  • ビジネスパラメーター（介護会員のランク、サービススタッフの働き方の種別など）を記述する
  • 業務概要を記述する

■ 5. 実装方法の変遷

• 昨年の実装:
  • プログラムでAIを使って要件定義させることをトライしていた
  • プログラムからAIのAPIを呼んで要件定義させて保存するという流れを何フェーズかに分けて実行していた
• 現在の実装:
  • 昨年の暮れからエージェントがすごいことになり出した
  • プログラム作成では全然追いつかないと判断した
  • 要件を定義することに関しては全てエージェントにやらせることに方針転換した
• 動作環境:
  • カーサーを使用している（クロードコードやCLIツールでも可能）
  • フェーズが4つあり、フェーズごとに出力される
  • 徐々に出力を厚くしていくやり方をしている
  • 実際の出力には2〜3分かかる（デモは10倍速）
• 現在の能力:
  • モデルがかなり賢くなっているため、ほぼほぼ全てAIで要件定義できるレベルになっている

■ 6. ビジュアライズ機能

• 全体俯瞰:
  • AIで出したものをビジュアルに表現している
  • 業務とコンテキストが表示される
  • コンテキストを選ぶとその中にどんな情報があって、どのケースと繋がっているのかが出てくる
• 情報の表現:
  • IDを中心としてある程度具体的なエンティティを出す
  • 細かいものは出さず、ビジネスで認識しているIDを情報という形で出している
  • この関係付けもAIが行っている
• 様々な視点からの確認:
  • 訪問介護スタッフを選ぶと、その訪問介護スタッフを中心にどういう画面を使っていて、その画面はどのケースに繋がっていて、そのユースケースはどの業務でどのアクティビティなのかが全部俯瞰して見える
  • 1つのアクターに多数の画面がついている場合、ロールが足りていないことが分かる
  • 1つのロールでそんなに多くの画面を扱うことは普通ないため、ロール見直しの必要性が判断できる
  • 画面が多すぎる場合、システム化する必要がないのではないかという議論もできる
• 状態遷移の確認:
  • 状態遷移があり、この状態遷移に関わるユースケースは何があるのかが見える
  • この状態は本当に役に立っているのか、この状態を実現するための情報は何なのかという話もできる
• 活用方法:
  • 1回AIでガーっと出すとこのビューを使って様々に分析しながら本当にこの要件でいいのかを考えていく
  • AIに引きずられているような感じになるが、AI要件定義そのものはもうAIでできることが分かったため、いかに理解するかが重要になっている

■ 7. 画面イメージの生成

• アクター別の画面を作成する:
  • 具体的にその画面でどういうことが行われているのかが分かるように、AIにアクター別の画面を作らせる
  • 介護スタッフを選ぶと介護スタッフの使う画面が見える
  • イメージではあるが、この介護スタッフはどういう業務でどういうビジネスケースでこの画面を使うのかをイメージしながら要件定義をしていく
  • アクターごとに確認しながら使っていく

■ 8. VGモデルによる妥当性検証

• 左側（要件生成）:
  • フェーズ1234の4つのフェーズでAIが出力したものを作成する
• 右側（妥当性検証）:
  • 本当にその要件が妥当なのか、このままシステムとして導入して役に立つのかを検証する
• 検証方法:
  • 対象システムの拠点やアクターにどういう制約があるのかを入力する
  • この制約と組み立てた要件をぶつけて妥当性を検証する
  • ある程度その環境を入力することによってAIが生成した要件が妥当なのかどうなのかを判断する
• 検証結果:
  • 色々と出てくるが、感覚的には60点ぐらいである
  • 重要度や改善提案がやたらに出てくるが本当かなというものもある
  • ただし出力された要件を見直すという意味においては、VGモデルの右側からどういう環境にシステムを入れるのかを入力するのは結構有効である
  • そもそもこの入力を作るという行為そのものがかなり重要であり、これで現場というものを強く意識できる

■ 9. 論理データモデルとビジネスルールの生成

• ビジネスルールの叩き台:
  • 要件として出されたビジネスルールの叩き台を作る（正式なものではない）
  • ラドラという手法では条件という名前のものがビジネスルールを表す
  • スキルマッチング条件があった場合、それはどのケースから呼ばれていて、その条件はどういうサービス種別やスキルレベルなどのバリエーションに繋がっているかが書かれている
  • この条件からビジネスルールを作ってくれとAIに言うと叩き台が出てくる
  • 実際の仕様においては、仕様化の時にこの形式で本当にいいのか、もうちょっと違った形でビジネスルールをきちっと書いていく
  • 叩き台があるだけでかなり見通しは良くなる
• 論理データモデル:
  • 要件から論理データモデルを作ってというとそこそこの論理データモデルが出てくる
  • データモデルの得意な人はデータモデルを見るとかなり業務が分かる
  • こちら側から今回の要件が妥当なのか、ピントがボケているなどが判断できる
  • 論理データモデルが読めない・苦手という方は、エンティティの役割と他のエンティティとの関係からこの論理データモデルのできることや役割を分かりやすく説明してとAIに訊ねると、それなりに説明してくれる
  • 分かりにくい場合はさらに質問すれば分かってくる

■ 10. 適切なコンテキストの提供

• 重要性:
  • コンテキストとして生成したものを積み上げていくことが大事である
• 4つのフェーズの構成:
  • AIが要件をどう組み立てていけばいいのかというナレッジをあらかじめ入れている
  • IDEではラドラナレッジというところに各々フォルダーを切ってその中に様々なプロンプトなどが入っている
• 人が行うこと:
  • 基本的に人が行うことは初期の要望を書くことである
  • それでフェーズごとに実行して出力された内容を見直して、また次のフェーズに行くことを繰り返していって洗練化する
• 軌道修正:
  • AIが出した出力を人間が見直して軌道修正する
  • 細かく見て直すというのは人間にとってかなり負荷が高いため、明らかに違うということだけ直す
  • いらないものを基本削除するという方向で修正していく
• 実際の運用:
  • 最初に初期要望を入れて1回動かすと解像度が悪い感じになるため、この初期要望を見直す
  • ある程度こんな感じかなと思ったら次からどんどん次に行く
  • 当初はフェーズ1見直したらフェーズ2、フェーズ3と思ったが、人間の負荷から言うとフェーズごとに見直すのはかなり耐えられない
  • 今は初期要望と最初のフェーズを繰り返したらあとは一気に最後まで行くという感じである
  • 一気に最後まで行って要件として組み立てたら、その後でビジュアライズしたもので色々な角度で見直して再度生成し直す
  • その方が楽である
• 最終確定:
  • AIで出されたものはどこまでも叩き台である
  • 最終的にはラドラという手法の形式で出して人間が最終的に要件を確定するというやり方をしている

■ 11. モデルベースのアプローチ

• ラドラという手法の構造:
  • 要件には形がある、構造があると規定している
  • 4つのレイヤーがあり、各々要素があって、その要素が全部繋がっている
  • 右から左に依存するという構造を持っている
  • 右の要素は左の要素がホワイトになっている
  • 左の要素がこうだから右の要素はこうだという考え方である
• クラス図による表現:
  • この構造をクラスで表すことができる
  • この構造に従って要件を定義させるので連続的に要件が定義できる
• 段階的なモデル構築:
  • 最終形に持っていくために段階的にモデルを組み立てる
  • 徐々にオブジェクトを増やして関係付けすることを内部で行っている
  • AIで出力されるのは表形式だが、内部ではこれらが全部完全に繋がり合っていてオブジェクト構造として持たれている
  • 詳細なレベルから俯瞰したレベルまで見ることができる
• 画面生成の仕組み:
  • このオブジェクト構造があるため、定義されたオブジェクト構造から画面用のアクター、画面、項目という構造に変換する
  • 当初これをエージェントで変換していたが、こんな決まりきったことをエージェントでやるのはトークンが無駄だと判断した
  • エージェントにプログラムを作らせるようにしている
  • この構造のものをこっちの構造にしてくれという構造変換のプログラムを作らせる
  • プログラム変換させたものをJSONとして出してこのJSONを画面が読んで生成されたものの画面をアクター別に出す
• モデルの言語化:
  • クラス図の1個1個のクラスと関係を言葉で定義している
  • アクターとはこうだ、業務とはこうだということを書いて言語化している
  • これを食わせている
  • 実際には表形式で出ているため、表形式はダイアグラムの関係性を表として再現できるようにしている
  • この表の構造も全部言語化して、こういう繋がりはこういう表で出力してくれということを全部書くことによって出力される

■ 12. まとめと提供サービス

• IDEの活用:
  • IDEの中であらかじめナレッジをモデルベースで入れておく
  • 初期の要望をファイルに入れて実行すると要件定義が生成される
• 複雑なタスクへの対応:
  • 要件定義みたいな複雑なものはまずフェーズに分ける
  • フェーズごとのナレッジを作る
  • フェーズごとの成果物のフォルダーを用意する
  • 成果物のフォルダーがAIに渡すコンテキスト情報になるため、それを見直すことによって軌道修正してちゃんと辻褄の合った要件定義に持っていく
• 無料相談の提供:
  • 要件定義や家の設計など創造的で難しいところをどうやったらAIでやれるのかを悩んでいる方向けに無料相談を提供している
  • XのアカウントにてDMで相談を受け付けている

(2025/11/30)

MM2025-03 技術講演2：生成AI時代のドメインモデリング ― OOPとFPを超えて

• MM2025-03 技術講演2：生成AI時代のドメインモデリング ― OOPとFPを超えて - YouTube

要約:

■ 1. ドメインモデルの定義と階層

• ドメインモデルの基本概念:
  • 現実世界の複雑さを抽象化して表したものである
  • 枝葉となる環境や実装技術に依存した部分を切り落として業務の本質的なコアの部分を抽象化したものである
• ドメインモデルの3つのレベル:
  • データベースやデータモデリングに概念モデル、論理モデル、物理モデルというレベルがあるように、ドメインモデルにも概念モデル、仕様モデル、実装モデルというレベルがある
  • この区別は2000年頃の論文「Modeling with sense」(マーティン・ファウラーのサイトに掲載)で提唱されている
• 現状の課題:
  • 実際にはこの仕様モデルと実装モデルがあまりはっきりした区別をされずに今まで来ている
  • ドメインモデルは抽象概念なので仕様レベルでの話が重要である
  • しかしオブジェクト指向プログラミングのエッセンスなど実装の都合や技術都合に引きずられてどう実装するかの話で片付けられることが多い
  • DDDも実装論ばかりされているように見える

■ 2. 仕様モデルの定義

• 仕様モデルの役割:
  • ソフトウェアシステムが何をしなければいけないか、どのような情報を保持しなければならないか、どのような振る舞いを示さなければならないかを定義する
  • 端的に言えばデータと振る舞いを定義する
• 仕様ドメインモデルの構成:
  • 仕様ドメインモデルは工学的な抽象レベルで記述された業務のデータと振る舞いで構成される
  • 主にはデータと振る舞いで構成されるものである

■ 3. オブジェクト指向と関数型のドメインモデリング

• オブジェクト指向のドメインモデリング:
  • データと振る舞いの関係性をマッピングしていく
  • 行列を並び替えながらうまいことクラスだったっぽいものを見つけてクラスとして整理していく
  • クラスターの決め方は自由度が高い
  • 人によって設計できる人と設計できない人のばらつきが出る
• 関数型のドメインモデリング:
  • 基本的には同じであるがそれぞれの振る舞いができる限り全域性を満たすようにする
  • 対象とその全ての入力データに関して定義できない振る舞いは実装しない、別の振る舞いにするかデータ型を分ける
  • 例外を発生させないように振る舞いやデータを調整していく
  • 全域性を保つことで組み合わせ可能性(コンポーザビリティ)が高まる
• 本質的な違い:
  • 仕様ドメインモデルのレベルでは本質的な違いはない
  • オブジェクト指向の方が自由度が高い
  • 関数型モデリングはさらに全域性を保つなどの制約が加わるためより厳密になる

■ 4. 仕様モデルの記述方法

• 従来ツールの問題:
  • 従来のモデリングツールでは仕様のモデルを書いているのか実装のモデルを書いているのかが曖昧である
  • モデル駆動開発(MDA)で仕様書いたらそこからコードがジェネレートされるという夢の世界の影響があった
  • 実装モデルに近い設計要素が入ってしまっている
• 記述のアプローチ:
  • 従来のツールは一旦置いといて純粋にデータと振る舞いだけを書き出すことにフォーカスする
  • DSL的に簡単なシンタックスで記述する
  • データの定義はデータ型で名前をつけて何から構成されるかを書く(代数データ型と同じ)
  • ANDで直積とORで直和を使ってデータと振る舞いを表していく
• データ定義の例:
  • データはANDで複数の要素を組み合わせる
  • ORで複数の選択肢から1つを選ぶ(例:連絡先はメールアドレスか電話番号か住所)
  • 振る舞いは基本的に入力から出力への変換である
  • 入力のデータとそれが出力のデータとして何が出てくるのかを定義していく

■ 5. 抽象化の重要性

• 振る舞い抽象:
  • 実装の詳細を知らなくてもその振る舞いが提供する機能を利用できることである
  • 実装の用語で言えばインターフェースに対して実装していくことと同義である
• データ抽象:
  • 対象のデータの詳細を知らなくてもそのデータに対しての振る舞いを実行できることである
• 仕様モデルの要件:
  • 仕様モデルはこれらの振る舞い抽象とデータ抽象でなくてはならない
  • 振る舞いがない場合は実装の詳細を仕様として書いてしまいがちである
  • SI現場で見られる詳細設計書のように実装レベルの処理順を書いてしまうと、中身の実装を全部知らないとロジックを安全に呼び出せなくなる
  • プログラム修正においても詳細全部を知らないと何も修正できなくなる

■ 6. 仕様記述の要素

• バーバラ・リスコフの手続き抽象の仕様構成要素:
  • 入力と出力(データ抽象が入力と出力になる)
  • Requires(事前条件):入力が受け付けられないものがある場合にその条件を書く
  • Modifies(変更条件):中で書き換えられる入力があったらそれについても書く
  • Effects(効果):入力についての書ききれない振る舞いの詳細を書く
• 良い仕様の3つの条件:
  • Restrictiveness:使う側にとって受け入れられない実装が全て排除されていなければならない
  • Generality:受け入れられる実装を仕様として排除してはならない(実装の選択肢を勝手に削らない)
  • Clarity:仕様の読み手がその意味を十分理解できること

■ 7. 全域性の追求

• 全域性の定義:
  • 取りうる入力の全てに対して対応する出力が必ず存在することである
• 全域性の実現方法:
  • 振る舞いが受け入れられない入力を仕様として示すのではなく、型として調整する
  • 例:割り算で除数が0ではないことをRequiresとして仕様に書くのではなく、NonZeroInteger(0を除いた整数)という型を定義する
  • これにより自然言語として書かなければいけない仕様が少なくなっていく
• ステータスの問題:
  • ステータスは全域性を損なうサインである
  • 注文ステータスがあるということは、そのステータスによって適用できる振る舞いが違うことを意味する
  • ステータスではなくデータ抽象で表すことで適用できる振る舞いの条件が明示される
  • 仕様レベルではステータスがなくなるようにデータ抽象を作っていくことが重要である

■ 8. 実装の選択肢を残す

• Generalityの実現:
  • 良い仕様は実装者が要求を満たす上で最も最適な実装が選べるように最大の選択肢を残してあげなければならない
  • SI現場では実装の話まで仕様にたくさん書いてしまいがちである(例:ループ処理、データベースアクセスの方法など)
  • これは性能問題に直結する
• データ抽象の適切な設計:
  • テーブル駆動で設計するとデータ抽象が適切に設計されないことがある
  • 例:受注生産の場合だけサプライヤーIDが入るという仕様で、このフィールドがNULLかどうかで受注生産商品を判定するロジックが各所に埋め込まれる
  • これは抽象が漏れ出している(Leaky Abstraction)状態である
  • 対策はデータ抽象をちゃんと分けること(通常商品と受注生産商品を別のデータ型にする)

■ 9. Clarityの向上

• スタンプ結合の廃止:
  • 入力のデータの全部をその振る舞いで使うわけではないことがよくある
  • 大きなデータを渡しがちだがそうするとテストしにくくなる
  • 使ってないデータに依存した振る舞いがあるので修正時の影響調査が必要になり修正コストが高くなる
  • データ抽象の粒度が大きいと何をやっているかが分からなくなる
• ビジネス不変条件の保証:
  • 仕様としてのデータ抽象はビジネス不変条件をちゃんと保証するものでなければならない
  • 例:チェックイン日はチェックアウト日よりも前の日付でなければならない
  • これを型として明示しておくとより不変条件が明らかになる
  • バラバラのフィールドではなく「宿泊」というデータを別に作り、それを「日付の範囲」として定義する
• 単一責務の原則:
  • 振る舞い抽象は単一責務でなければならない
  • 複数の責務が混ざっている振る舞いは正確に名前に反映させることで発見できる
  • 名前に「〜の場合は」「〜をして〜をします」「そして〜をします」(英語だとAND/OR)が入る場合は複数の責務が混ざっている
  • 正直正確で完全な名前を一回つけてみて、そこにAND/ORが繋がるようだったらそこで分割する

■ 10. 仕様モデルから実装モデルへ

• 良い仕様モデルの条件:
  • スタンプ結合を除去する
  • 振る舞いが全域性を持つようにする
  • 振る舞いを単一責務にする
  • これらは疎結合や高凝集を目指す良い設計と全く同じ話である
  • これを仕様レベルでちゃんと保とうということである
• 実装モデルへの変換:
  • 良い仕様ドメインモデルが書ければ実装言語に合わせて実装ドメインモデルにエンコーディングすればよい
  • データと振る舞いをクラスごとに整理するのがオブジェクト指向言語向けのドメインモデルである
  • データを型に、振る舞いを関数にエンコーディングするのが関数型のドメインモデルである

■ 11. 開発アプローチの転換

• アウトサイドイン開発の問題:
  • 現状のSI現場で多い開発スタイルはアウトサイドイン開発である
  • 業務コアの概念が分からないまま画面設計書を作り、テーブル設計を作り、そこで開発をスタートする
  • 外側(実装の詳細)から詰めていって中(業務コア)に向かって開発を進めていく
  • 仕様モデルを書く隙間がこのプロセスにはない
  • 結果として配線プログラミング(画面項目とデータベースのマッピング線だけ設計する)になる
  • システムの理解容易性と変更性が低下しやすい
• インサイドアウト開発への転換:
  • 仕様モデルをちゃんと書いて、その仕様モデルに沿ったプレゼンテーションのモデルや永続化のモデルを書いて画面と繋げていく
  • インサイドアウトの開発にすべきである
  • 仕様モデルがちゃんと書けていればこの外側に向かってコードを書く部分は生成AIがうまいことやってくれる

■ 12. 仕様モデル駆動設計

• 従来の仕様駆動開発(SDD)の問題:
  • 仕様として何が必要かという定義がない
  • 従来の開発延長線上に仕様駆動開発をやってみようとなるとアウトサイドインになる
  • AIが勝手に想像して変なコードを出してしまう
• 仕様モデル駆動設計の提案:
  • ちゃんと仕様モデルを先に書いてインサイドアウトで開発すると、当然ながらそのモデルが先に作られている状態である
  • AIはそれをちゃんと理解した状態で画面やDBにマッピングしてくれるので割と綺麗に作ってくれる
  • これを仕様モデル駆動設計と呼んで広めていく

(2025/11/30)

MF2025-08 ワークショップ開催報告

• MF2025-08 ワークショップ開催報告 - YouTube

要約:

■ 1. ワークショップ1:モデル駆動設計の実践

• 開催概要:
  • 講師は増田氏と佐藤氏である
  • 先週月曜日に4時間(13時から17時)で開催された
  • 会場はNEC本社を借用した
  • ワークショップの内容説明15分、モデリング3時間、増田氏によるレビュー45分で構成された
  • 2人から4人のテーブルに分かれてワークを行い、30分に1回程度全体で議論した
• 参加者属性:
  • 申し込み者数は26人で当日参加が23人、アンケート回収数が15である
  • システムエンジニアとプログラマーの方が多数を占めた
  • 現業務現場でのモデリング経験がある方が66.7%で、3人に2人はモデリング経験がある
  • UMLの利用経験が3年以上の方が40%、1から3年が26.7%、1年未満が20%で、約80-90%がUML利用経験を持つ
• ワークショップの内容:
  • モデル駆動設計とはという導入部を6個のスライドで説明した
  • 調整さんのようなものをテーマにルールをコードで記述することを課題とした
  • シンプル版として特定の日付に決定するルールをプログラミング言語で表現することから始めた
  • 終わった方から段々ルールを複雑にしていくことに取り組んだ
• 参加動機:
  • 講演内容に興味があった(モデル駆動設計)
  • 講演者に興味があった
  • モデリング技術に関する最新情報収集のため
  • 会社からの案内、UMTPのメールとホームページ、川島氏のXのポストが情報源となった
• 満足度と使用ツール:
  • 非常に満足と満足を合わせて73%の満足度があった
  • 使用ツールはJavaが10件、Goが5件、UMLが5件、C#、Python、Ruby、Mermaidも使用された
• プラス評価:
  • 最後45分間の増田氏による3人の方の実際のコードレビューが非常に良かった
  • グループで30分に1回程度どういう風にやっているかを話した際の意見や解釈、感覚を共有したのは収穫であった
  • 調整さんの表から分かる表からモデルコードに落とし込む作業が予想以上に大変だったことを体感できた
  • モデルをコードで表現するという観点を強く意識する機会となった
  • 4時間集中して取り組む時間になった
• 改善点:
  • 増田氏ならどのような実装になるのか見てみたかった(あえて模範回答を用意しない方針だった)
  • 増田氏のレビューを受けたかったのでレビュー時間を長くして欲しい(45分でも足りなかった)
  • コードによるモデリング方法の具体的な説明がなくモデル駆動設計の解像度が上がらなかった
  • モデル=コードという考え方が伝わらなかった
  • コードではなくても(図などで)レビューして欲しかった
  • チーム分けで得られるものが異なり、テーブル内で同じような接近になってしまった

■ 2. モデル駆動設計の核心概念

• モデル=コードの原則:
  • 今回のポイントはコードでモデルを表現することである
  • モデル=コードが理解して欲しいポイントである
  • ドメイン駆動設計(エヴァンス本)では「モデルと設計の下」において、モデルと設計及びコードを単一の活動として改良し続けることを説明している
  • 1つ作ればモデルにもなるし設計にもなるというのがポイントである
• モデルで表現すべきもの:
  • 事業、業務、業務ルール(ビジネスルール)をコードで表現してモデルにもなる
  • テクニックとしてDDDで語られているエンティティ、値オブジェクト、ユビキタス言語を使った命名などがある
• モデルとコードの乖離:
  • 手続き型で処理順に書いていってしまうとモデルとコードが乖離していく
  • 実際に多くの参加者のコードでこの乖離状態が見られた
  • 実装が進んでレベルの高い方でもこの問題が発生していた
• 具体的な問題点:
  • 重要概念がクラスではなくプリミティブ型の変数で表現されていたため、重要概念がモデルとして伝わってこない
  • 処理が書いてあってそこにコメントで一生懸命説明しているが、それがコードに現れてきていない
  • このような状態ではモデルとコードが乖離している

■ 3. 開催者の所感

• モデリングの習得における課題:
  • モデリングを頭で理解するのと体得の間には崖がある
  • 実際に参加者がモデリングしているところを見てこれを実感した
  • 本を読んで頭で理解したつもりでも実際やってみるとできないというギャップがある
• ワークショップの価値:
  • モデリングの体得のきっかけとしてワークショップという場は価値がある
  • 頭で理解したつもりだったけども実際やってみるとできないということに気づくきっかけとなる
  • 気づいたら自分で色々書いてみたり、実プロジェクトで部分的にやってみたり、師に習う(お互いにレビューし合ったり、習得した人に見てもらう)ことが重要である
• AI時代におけるモデリング体得の必要性:
  • 生成AIがモデリングをするにしても人が体得することは必要である
  • 生成AIがモデリングして人がそのAIが作ったモデルの良し悪しを判断できないと体得していないので良いか悪いか判断できない
  • 判断できないと知らないうちに歪んだ設計がソフトウェアに埋め込まれていく
  • AIで動くものは作っていくが知らないうちにソフトウェアの内側から劣化して開発生産性や品質が低下し、リリーススピードが低下して事業に悪影響を長期的には及ぼす
  • 生成AIがモデリングしたとしても人がAIが作ったモデルの良し悪しを判断して最終的には受け入れ判断をする必要がある
  • そうするとソフトウェアの内側が綺麗に保たれて変更容易性が高まって生産性が上がって事業にどんどんリリースできるので事業に貢献できる
  • ドメインのところをソースコードから綺麗に保っていくことでソフトウェアの変更容易性が高まって事業に貢献できることにつながる

■ 4. ワークショップ2:モデルとは何かの本質洞察

• 開催概要:
  • 11月19日にリモートで開催された
  • 参加者は16名で19人で実施された
  • 企画の方、アーキテクトの方、学生、プロダクトデザイナーなど多様なバリエーションの参加者がいた
  • 最も多かったのはシステムエンジニアとプログラマーである
• 目的:
  • モデルについてみんなで対話を重ねて深く考える時間を持つこと
  • いろんな立場の様々な視点の人々との対話からモデルとは何かを探っていく
  • 自然言語でモデルとは何かを思考実験して検討していく
  • 特定のUMLを使うことは目指していない
  • 概念工学に近いことをみんなで体感する
  • 本質洞察の実践という形で自分の実感体験と言葉によるある程度明確な記述をいかにすり合わせて近づけていくかを繰り返す
  • 共通性を見つけ本質の定義に近づいていく
  • いろんなエピソードを少しでも広くカバーできるような概念を見つけ出す
  • 実感体感と一般化、抽象化、理想化、形式化の間を行ったり来たりしながらうまい表現記述を見つけ出す
• 参加者属性:
  • モデリングの現場での経験がある方が83%である
  • UMLの利用経験が3年以上の方が33%、1から3年が10%未満、1年未満が16%で、40%の方は使ったことがない
• 満足度と感想:
  • それなりに満足度は高かった
  • モデリングの良い経験になった
  • グループで異なる方と議論ができた
  • モデルに対する理解を深めることができた
  • 業務で役立つ知識を得られたような感じはしなかった(目的はそこではなかった)
  • モデリングを学んだというよりモデリングについて学んだという感じで実務には役立たなさそうだった
  • ワークショップではかなり良い体験ができた
  • 新モデリング宣言に関して哲学とソフトウェア工学をどのように結びつけられるかを知ることができた
  • モデリングとは何かを再確認し、またモデリングを展望する機会となった

■ 5. ワークショップの流れ

• エピソード収集:
  • モデルやモデリングというキーワードを含んだ自分の実体験のエピソードを2つ以上書く(200字以上400字未満程度で2つ分)
  • 文章をお互いに見せ合い説明し合いながら自己紹介タイムを実施した
  • 体験、実感というものが大事で、これが核になって初めて共同感覚を引き出せる
• 多様なエピソード:
  • プラモデルを作るというモデリング経験
  • 救援活動の納得感を構成するためのモデリング
  • PTA活動の際の組織構成の構造を作る経験
  • 日常生活業務やIT開発設計業務など様々な場面でのモデリングの実感を伴ったエピソードが集まった
• 本質洞察の実践:
  • 本質洞察とは何かを説明した上でモデルの本質とはどんなところにあるのかを語ったエピソードの中から共通性を抽出する作業を実施した
  • カードに書いていく形式で進めた
• 揺さぶりをかける新しい視点:
  • 画家が絵を描く際のモデルさんというモデル
  • ファッションモデルは一体何のモデルなのかという問いかけ
  • 数学の理論に対してその理論を適用した具体例のことをモデルと数学では呼ぶが、その理論とモデルがITやエンジニアリングの分野のモデルの扱いと逆転しているように見えるのはなぜか
• チームごとの整理:
  • Aチームはモデルの目的やモデルの特徴をいろんな観点で整理した
  • Bチームはソフトウェア開発という分野に絞ってモデルの共通性を導こうと努力した
  • Cチームは複雑な内容を短時間で共有するというコミュニケーションに着目してそれを整理しようとした
• 追加された観点:
  • 型という観点、お手本という観点、具体例という観点、象徴という観点、抽象化、予測可能性といった観点が追加された

■ 6. モデルの定義試作

• Aチームの定義:
  • 共通言語、コミュニケーション、文法がある程度存在する
  • 抽象度を変えることができて可視化できる
  • 関係性が明確化に明確になっている
• Bチームの定義:
  • モデルとは共通認識の形成のために作られ、関心ごとの対象をシンプルかつ他人に共有可能な形式で表現したものである
  • さらに洗練してモデルとは現実世界を認識再利用するためにモデルを共有する人や社会が共通に理解できる表現対象である(50文字以内に収まった)
• Cチームの定義:
  • 物事の基準で再現可能なものである
  • 目的に応じた要素に絞り複数要素とそれらの関係で構成する

■ 7. モデルの語源と二重構造

• モデルの語源:
  • ラテン語で測定器具や基準という意味から始まっている
• 伝統的なモデリング:
  • 画家の人やファッションモデルのようにある基準がモデルで、それを参照して何か作品を作るモデリングの仕方がまず最初に現れた
• 工学的モデリング:
  • 工学の世界では色々な具体事例をうまくコントロール制御してより良い製品、より良い作品をするためにはどんなお手本があったらいいだろうということを考える
  • 今度は具体的な作品事例から逆算してモデルというものを作るということが行われるようになってきた
• 二重構造の統合:
  • 従来のお手本から作品を作るという次元のモデリングと、具体例を基準となる作品を作る際にお手本にするといいようなエッセンスを人工的な構成物として作り出すという新しい活動が二重に重なっている
  • アジャイルなぐるぐるモデリングのように、作品が色々ある中からいい基準を見つけ出してそれをモデルとして抽出し、それに基づいて作品をまた作り、それをまた妥当性を判断し、それをまた抽象化するということがぐるぐる回るようなエンジニアリング的な活動に移ってきた
• UMTP新モデリング宣言との関連:
  • このような従来のお手本としてのモデルが工学的な活動の中で三角関係になっていき、ぐるぐる回るモデリングに移行してきた
  • これはUMTP新モデリング宣言で呼ばれるところのリベラルアーツとしてのモデリングに通じる

(2025/11/30)

システム設計・データ活用のためのデータモデル入門 ビジネスを飛躍させる概念データモデルの理解

• システム設計・データ活用のためのデータモデル入門 ビジネスを飛躍させる概念データモデルの理解 ｜ SEshop｜ 翔泳社の本・電子書籍通販サイト

【本書の構成】

◆第1部　導入編

第1章　なぜデータの「意味」が大切なのか？

◆第2部　文法編

第2章　概念データモデルの文法の基礎概念

第3章　KEYとRKEY

第4章　分類構造と分担構造

第5章　関係

第6章　エンティティ類型

第7章　加工データとSPFチャート

◆第3部　手順編

第8章　データモデリングプロジェクトの手順

第9章　データモデリングプロジェクトの成果物

第10章　データモデリングプロジェクトの知識

◆第4部　実践編

第11章　業務システム領域の概念データモデル

第12章　データ活用領域の概念データモデル

MEMO:

• 2025/12/15発売

(2025/11/29)

つくりながら学ぶ！ ドメイン駆動設計 実践入門

• つくりながら学ぶ！ ドメイン駆動設計 実践入門 | マイナビブックス

実践で学べるドメイン駆動設計！

この本は、TypeScript を使用してドメイン駆動設計（DDD）の原則に基づいた Web API サーバーの構築を学ぶためのガイドです。

この本ではオンライン書店サービスをドメインとして扱い、その中でもカタログ管理に関するサービスを取り上げます。そのドメインを実装するための Web API サーバーの構築を通してドメイン駆動設計の基本的な概念や原則、実践的な実装方法を学びます。ハンズオン形式で進んではいきますが、辞書のように使っていただくことも可能となっています。

著者は、ドメイン駆動設計を利用して TypeScriptでWeb API サーバーの構築を行う際に、十分な情報やガイドを見つけられず、苦労しました。本書を通じて、複雑なビジネス要求を効果的にソフトウェアに反映する手法を探している開発者の方々へ、実践的な知識とノウハウを共有できたら幸いです。

MEMO:

• 2026/01/21発売か

(2025/11/29)

補足: 履歴テーブル、今回はこう作りました 〜 Delegated Types編 〜

• 補足: 履歴テーブル、今回はこう作りました 〜 Delegated Types編 〜 - その手の平は尻もつかめるさ

(2025/11/29)

履歴テーブル、今回はこう作りました 〜 Delegated Types編 〜

• 履歴テーブル、今回はこう作りました 〜 Delegated Types編 〜 / How We Built Our History Table This Time — With Delegated Types - Speaker Deck

(2025/11/29)

昨今のAIブームは「言語能力こそが知能である」という誤解に基づいているという主張

• 昨今のAIブームは「言語能力こそが知能である」という誤解に基づいているという主張 - GIGAZINE

要約:

■ 1. AIブームの根本的誤解

• ベンチャー企業Cognitive Resonanceの創業者ベンジャミン・ライリー氏の主張:
  • AIブームは言語能力と知能についての根本的な誤解に基づいている
• 大手IT企業幹部の発言:
  • Metaのマーク・ザッカーバーグCEOが「超知性の開発は今や目前に迫っています」と発言した
  • OpenAIのサム・アルトマンCEOが「従来理解されてきた意味での汎用人工知能(AGI)を構築する方法について、私たちは今や確信を持っています」と主張した
  • 大手IT企業の幹部らはAGIの構築に自信を見せている
• ライリー氏の反論:
  • 人間の知能に関する科学的見解やこれらの企業が生み出してきたAIシステムを見る限り、とてもこれらの発言を信じることはできない

■ 2. 大規模言語モデルの本質

• 現在のAIの基本構造:
  • OpenAIのChatGPT、GoogleのGemini、AnthropicのClaude、MetaのAI製品群のいずれも「大規模言語モデル」である
  • これらは基本的に膨大な量の言語データを収集し、単語(トークン)間の相関関係を見つけ、入力されたプロンプトに対してどのような出力が続くのかを予測するものである
  • これらの企業が開発するAIはどこまで行っても、本質的には言語モデルである
• 「言語=思考」仮説の問題:
  • 仮に「言語=思考」なのであれば、AI開発企業が世界に関する膨大なデータを収集し、それをますます強力なコンピューティングパワーと組み合わせることで統計的相関関係を改善していけば、あっという間にAGIは実現する
  • 大きな問題は、現在の神経科学に基づくと、人間の思考は言語とほとんど無関係だという点である
• 言語と思考の関係:
  • 確かに人間は言語を用いて推論や抽象化、一般化といった知能の成果を伝達している
  • 言語を使って思考することもある
  • だからといって「言語=思考」とはならない
  • いくら言語モデルを洗練させていったところで、それが人間を超える知能につながるという保証はどこにもない
• ライリー氏の批判:
  • この理論には重大な科学的欠陥がある
  • 大規模言語モデルは言語のコミュニケーション機能を模倣する単なるツールである
  • どれだけ多くのデータセンターを構築したとしても、思考と推論という独立した明確な認知プロセスにはならない
  • この違いを理解することが、科学的事実とAIに熱狂するCEOたちの空想的なSFを区別する鍵となる

■ 3. 言語と思考に関する科学的研究

• Nature論文の概要:
  • 2024年、マサチューセッツ工科大学やカリフォルニア大学バークレー校などの研究者らが「Language is primarily a tool for communication rather than thought(言語は思考というよりもコミュニケーションのためのツールである)」という論文を学術誌のNatureに発表した
  • この論文は言語と思考に関連する数十年にわたる科学的研究をまとめたものである
  • AIブームを取り巻く誤解をひもとく上でも役立つ
• 「言語が思考力や推論力を生み出す」という概念の誤り:
  • 仮に言語が思考に必要不可欠だとすれば、言語が奪われれば思考能力も奪われるはずである
  • 高度な機能的磁気共鳴画像法(fMRI)で脳のどの部位が活性化しているのかを調べると、「数学の問題を解く」「他人の心を推測する」といった思考を行う際には、言語能力とは異なるネットワークが活性化している
  • 脳損傷やその他の障害によって言語能力を失った人において、思考能力全般が損なわれるわけではないことは明らかである
  • 重度の言語障害を抱えながらも数学の問題を解いたり、非言語的な指示に従ったり、他者の動機を理解したり、論理的推論や因果的推論を行ったりすることは可能である
  • 言語能力を獲得する前の赤ちゃんも、日々の暮らしの中でさまざまなことを発見・理解し、世の中について学んでいる
  • 科学的にいえば言語は人間の思考能力の一側面に過ぎず、多くの知能は非言語的能力に関わっている
• 言語の本質:
  • 言語は人々が互いに考えを共有するためのツール、すなわち効率的なコミュニケーションコードである
  • 言語は生成しやすい上に理解・学習が容易である
  • 簡潔かつ効率的に使用でき、ノイズに対して堅牢である
  • こうした特徴により、人類は言語を用いて知識を共有することが可能となり、世代を超えて並外れた文化を築き上げることができた
  • 人間の認知能力が言語によって底上げされるからといって、思考全般が言語によって生み出されたり定義されたりするわけではない
  • たとえ話す能力を奪われようと、人間は考え、推論し、信念を作り上げ、恋に落ち、世界中を探索することが可能である

■ 4. 大規模言語モデルの限界

• 言語モデルの構造的制約:
  • 人間において「思考=言語」ではない
  • 既存のAIの基盤となっている大規模言語モデルから言語を取り除くと、文字通り何も残らない
  • AIが人間とはまったく異なるルートで超知能に到達する可能性もゼロではない
  • しかしテキストベースの訓練によってAGIに到達できると考える明確な根拠もない
• AI研究コミュニティの認識変化:
  • 「大規模言語モデルだけでは人間の知能モデルとしては不十分だ」という認識が高まりつつある
• ヤン・ルカン氏の取り組み:
  • AI研究でチューリング賞を受賞したヤン・ルカン氏はMetaを辞任した
  • 「物理世界を理解し、持続的な記憶を持ち、推論でき、複雑な行動シーケンスを計画できるシステム」である世界モデル構築のためのAIスタートアップを設立した
• ヨシュア・ベンジオ氏らの定義:
  • ルカン氏と共にチューリング賞を受賞したヨシュア・ベンジオ氏らは、AGIの暫定的な定義を「十分な教育を受けた成人の認知的多様性」を持つものと定義した
  • 知能は「Knowledge(知識)」「Math(数学)」「Working Memory(ワーキングメモリー)」「Visual(視覚)」「Auditory(聴覚)」など、さまざまな項目から成り立っていると主張している
• ライリー氏の評価:
  • 大規模言語モデルにとらわれてきた従来の枠組みを脱するという点では評価できる
  • しかしこれらの合計がAGIであると見なすのは難しい

■ 5. 認知的飛躍とAIの限界

• 革新的発見の可能性:
  • 仮にベンジオ氏らが主張する知能をすべて達成するAIが登場したとしても、それは革新的な科学的発見につながるようなAIではないだろう
  • たとえAIが人間の思考を模倣できたとしても、人間が行うような「認知的飛躍」を達成できる保証はない
• パラダイムシフトの本質:
  • 「パラダイム」は人々から熱心に支持されるユニークさを持ち、さまざまな問題を研究グループに提示する業績のことを指す
  • 科学の歴史ではたびたびパラダイムが大きく転換するパラダイムシフトが起きている
  • これは反復的な実験の結果ではなく、既存の科学的記述に当てはまらない新しい疑問やアイデア、つまり認知的飛躍が起きた時に発生した
• 複数の認知領域にまたがるAIの限界:
  • 複数の認知領域にまたがるAIシステムは、確かに与えられた指示に対して、高い知能を持つ人間のように予測・再現することができる
  • しかしこれらの予測はいずれも既存のデータを電子的に集約・モデル化することで実行される
  • 入力されたデータそのものに不満を抱くことは難しい
  • 結果として人間のような認知的飛躍を達成する可能性は低い
• ライリー氏の結論:
  • 確かにAIシステムは私たちの知識を興味深い方法でリミックスし、再利用するかもしれない
  • しかしAIにできることはそれだけである
  • AIは私たちがデータにエンコードし、学習に使用したボキャブラリーの中に永遠に閉じ込められてしまう
  • 思考し、推論し、言語を用いて互いの考えを伝え合う存在である実際の人間は、世界に対する理解を変革する最前線にとどまり続ける

(2025/11/29)

27卒以降のITエンジニア就職って大変そうだよね

• 27卒以降のITエンジニア就職って大変そうだよね - しろね✨️の雑記帳

MEMO:

• そうね

(2025/11/29)

「若手はCOBOLを学びたがらない」　60年前のコードが今も動く――英国の銀行システムを縛る“技術負債”

• 「若手はCOBOLを学びたがらない」　60年前のコードが今も動く――英国の銀行システムを縛る“技術負債”（TechTargetジャパン） - Yahoo!ニュース

「英国の銀行システムには、今も1960～1970年代に書かれたソフトウェアコードが使われている」――経営コンサルタント会社Baringaが英国の銀行員200人を対象に実施した調査では、回答者の16％が1960年代のソフトウェアを、約40％が1970年代に書かれたソフトウェアコードを使用し続けていることが分かった。約50％の回答者は、「退職間近の従業員数人のみが理解しているソフトウェアに依存している」と答えた。

半世紀前のコードが支える現代の銀行システム

調査は、英国の銀行システムがレガシーな技術基盤に依存している実態を浮き彫りにした。同調査によると、38の金融機関がパンチカードなど、物理的なシステム上で動作するように設計されたコードを今も使用していると回答した。15％の回答者は、かつて販売されていた、部屋を占有するサイズのメインフレーム用に書かれたコードを稼働し続けていると答えた。

現場からは切実な声も寄せられた。ある回答者は「銀行のATMネットワークは、パッチを当てた古いWindows NT系のサーバで運用している」と述べる。別の回答者は「主要銀行の基幹システムは1970年代に構築され、今もCOBOLを使い続けている」と明かす。COBOLは、税務当局、銀行、保険会社、住宅ローン会社などが使用する信頼性の高い金融、管理システムの頼りになる技術だった。

ある金融機関の上級IT専門家は、1960～80年代のシステムを数多く扱ってきた経験から次のように語る。「古いシステムが長く使われたのは、シンプルで安定し、大量の単純取引を効率よく処理できたからだ。しかし今やレガシーなシステムの理解者は退職を控え、若手はCOBOLを学びたがらない。結果として、金融機関はこれらのシステムから徐々に離れざるを得ない状況にある」

Baringaのポール・ミハイロビッチ氏（銀行および市場技術部門エキスパート）は「複雑な技術資産の中に古い技術が一部残ってしまうのは避けられない」と指摘する。「金融機関は巨大な組織であり、国全体で数百万の顧客にサービスを提供している。技術革新のたびにインフラを全面的に作り直すことは現実的ではない」 銀行が直面する2つのリスク

ミハイロビッチ氏は、数十年前に書かれたコードを使い続けることで銀行が直面するリスクを2つに整理している。

・重要インフラへの深刻なリスク

特定の用途向けに運用されたシステムで長期間使用され、少数の高齢の専門家によって保守されているコードは、重要なインフラにとって重大なリスクとなる。維持できるのは少数の高齢専門家だけで、トラブルが起きても修復は困難となる恐れがある。

機敏性の欠如とコストの増大

・特定のレガシーシステムを維持するためだけに専門家を抱える状況が続けば、顧客ニーズの変化に素早く対応できない。維持コストも膨大になる。

MEMO:

• キャリアの選択肢が狭くなる上、将来的には確実にお払い箱になる技術に投資しろというのはかなりムリがある

(2025/11/28)

Programmatic Tool Calling(PTC)の何が新しいのか？

• Programmatic Tool Calling(PTC)の何が新しいのか？

一言で言うと、これは「ClaudeがToolを呼び出す処理をPythonコードとして生成し、 Anthropicが提供するサンドボックス内で実行する」機能です。

従来のTool Useでは、Toolを1つ呼ぶたびにClaudeが次のアクションを判断し、 その結果をすべてコンテキストウィンドウに追加していました。 10個のToolを連鎖して呼び出すと、10回分の推論と、 10回分の生データがコンテキストを圧迫します。

実際、この問題は Claude for Excel で顕著でした。Anthropic 公式記事でも「数千行以上のスプレッドシートを読むだけで、中間データがコンテキストを圧迫し、推論が破綻する」という課題が挙げられています。

Claude for Excel は PTC を利用し、

• スプレッドシートの巨大データをすべてコード実行側で処理し
• Claude が受け取るのは 最終的な集計・分析結果だけ

という形にすることで、コンテキスト肥大化を根本的に解決しています。

PTCでは、Claudeは「Tool呼び出しを含むPythonコード」を一度だけ生成し、 あとはサンドボックス内でPythonが逐次実行します。 中間結果はサンドボックスのメモリ内に閉じ、 Claudeのコンテキストに戻るのは print() で出力した最終結果だけです。

(2025/11/28)

コードの寿命・データの寿命・互換性の寿命

• コードの寿命・データの寿命・互換性の寿命

(2025/11/27)

「コードは設計書だ」と本気で思い直したきっかけ

• 「コードは設計書だ」と本気で思い直したきっかけ #tomomemo - Qiita

(2025/11/27)

オープンソース・プロジェクトのたたみ方

• オープンソース・プロジェクトのたたみ方

要約:

■ 1. Embulkの「メンテナンス・モード」発表

• 発表の経緯:
  • 2025年10月15日、GitHubのembulk organizationに入っていたメンバーにメールを送付
  • Embulkというオープンソースプロジェクトの「メンテナンス・モード」への移行を提案
• 背景となった問題意識:
  • RubyGems周辺で発生したセキュリティ事件から教訓を得た
  • 「複数の利害関係者が交わるオープンソース・プロジェクトでは、問題が起こる前にコミュニティで平和的に民主的に話し合えるうちにプロジェクトのガバナンスを実態に即して整えて形にして明示しておくべき」
  • 特にセキュリティが重要な課題となりえて、かつ営利企業や金銭が関わる場合には重要
• Embulkの現状:
  • 著者がメンテナーとして非アクティブとなり「アクティブなメンテナーはいない」状態になって既に半年が経過
  • 本体に近いところでは著者と佐藤さんのみが見ている状態
  • ときどきJDBC関係で@hito4_tさんにお声をかけて見てもらっている
  • embulk-output-bigqueryについては独立したメンテナーが何人かいる

■ 2. メンテナンス・モードの具体的内容

• 対応内容:
  • GitHub orgのメンバーやCore Teamを「今後もそれなりには関わり続ける気がある人」の最小限に絞る
  • 「もう積極的にメンテナンスを続けられる状態ではない」ことを残るメンバー間で合意する
  • 管理する対象自体（Zulipチャットなど）を減らす
  • Embulkそのものについて引き継ぎたいと手が挙がったときは残るメンバーで検討する
  • 以上をもって「メンテナンス・モード」とし外部に見える形で宣言する
• 今後の見通し:
  • Embulkがアクティブにメンテナンスされることを期待しないでほしい
  • pull requestなどを送っていただいてもレビューもマージもされないかもしれない
  • Embulkはもともと無保証のApache License 2.0でライセンスされている

■ 3. organizationに残るメンバー

• 最終結果:
  • 18人にメールを送付し、10人から期日内に返信があった
  • 最終的に4人のみがGitHubのembulk organizationに残ることになった
  • @frsyuki（原作者）、@hito4t、@hiroyuki-sato、@dmikurube（アナウンスの書き手）

■ 4. 更新の見込み

• 今後の更新について:
  • 「二度と」更新しないというつもりはない
  • 気が向いたときには更新するかもしれないが期待はしないでほしい
  • ちょっとした改善や整理は入れるかもしれない
  • もっと先のJavaへの追随や非互換ライブラリの更新（Jackson 2から3など）のような大きな更新を入れるのは現実的ではない
• 引き継ぎの可能性:
  • 引き継ぎたいという人から手が挙がれば残るメンバーで議論する
  • ただし実現しないだろうと個人的には思っている
  • 昨年にはアナウンスを出していたが積極的な提案や反応はなかった
• 引き継ぎの難しさ:
  • 「引き継いでくれるのなら誰でも、私たちが知らない人でも引き継ぐ」という態度は必ずしもユーザーのためにはならない
  • 機密データの転送にもEmbulkを使っている組織がある
  • 悪意を持つ誰かにEmbulkを引き渡してしまったら問題が起きる
  • 悪意を持った引き継ぎの提案は拒否して単純にプロジェクトを継続しないほうがユーザーにとっても良い選択肢かもしれない

■ 5. ミドルウェアの定義と特性

• ミドルウェアの特徴:
  • ミドルウェアを直接「使う」のは人間よりも主に誰か他の人が書いたソフトウェア・プログラム
  • 「複数のソフトウェア・プログラムから同時に使われる・依存される」ソフトウェアという整理ができる
• ライブラリとの違い:
  • ライブラリなら非互換を少し入れてしまっても「アプリケーション・コードのほうを直してね」で済む
  • ミドルウェアではそうはいかない
  • 典型的なミドルウェアであるRDBMSがいきなりSQL文法や接続プロトコルを変えてしまったら依存関係を考慮した複雑な対応が必要になる
• ミドルウェアの宿命:
  • 依存関係グラフが深く複雑になるほど対応も複雑になる
  • GuavaやJacksonのような「いろいろなJavaライブラリやミドルウェアから推移的に依存され互換性問題で悲鳴が上がるようになってしまったライブラリ」はミドルウェア的な宿命を背負わされて「ミドルウェア化」してしまった哀しきライブラリと見ることもできる
  • 多様なプラグインから依存され、そのプラグインとEmbulkを組み合わせて使う多様なユーザーがいたEmbulkは正しく「ミドルウェア」だった

■ 6. オープンソースとメンテナンス

• メンテナンスの長期性:
  • あるソフトウェアがミドルウェアであることと「長期間メンテナンスされ続けてきた」ことはほぼ不可分
  • あるソフトウェアが他のソフトウェアから依存され互換性を気にされることはそのソフトウェアがそれなりに長期間メンテナンスされ信頼されてきた証
• オープンソースの現状:
  • 近年では使われるミドルウェアの多くをオープンソースが占めるようになった
  • この十年強の間に新しく生まれたミドルウェアは企業のsource-availableソフトウェアを除けば大部分がオープンソース
  • 大規模なミドルウェアをメンテナンスする苦悩にはオープンソース・プロジェクト運営の苦悩も同時につきまとうようになった
• Honoの例:
  • YAPC::Fukuoka 2025でHonoのYusuke Wadaさんが「OSS開発者の憂鬱」というトークをされた
  • 「クリエイターからメンテナーへ」「作っていればよかったのが保守しなくてはいけなくなる」「Noを言うには体力がいる」「政治に巻き込まれる」

■ 7. Linux開発者の見解

• Linus TorvaldsとDirk Hohndel氏の発言:
  • 「メンテナーの疲労と、その仕事がいかに消耗させられる、ストレスが強いものか」という問題
  • Linuxカーネルのメンテナーはその必要不可欠で大変な仕事に以前よりも強い緊張を感じるようになっている
  • 「オープンソースの世界はプログラミングがすべてだと思っている人も多いが、実はコミュニケーションが占める割合も大きい」
  • 「メンテナーの仕事は翻訳であり、それは必ずしも言葉を翻訳するということではない。文脈、つまりそのコードであるべき理由を説明するということであり、それは大変な仕事だ」

■ 8. 悪意の存在

• サプライチェーン攻撃の現実:
  • オープンソース・プロジェクトがソフトウェア・サプライチェーンの重要な位置を占めるようになった
  • 悪意を持つ攻撃者にとってオープンソース・プロジェクトは格好の攻撃対象になっている
  • サプライチェーンの根っこのほうを乗っ取れれば攻撃者にとって得るものが大きい
• XZ Utilsの事例:
  • XZ Utilsに悪意のあるコードが挿入された問題（CVE-2024-3094）が確認されたのが2024年3月
  • これは偶然にも氷山の一角が見つかった幸運な事例
  • おそらくいくつかの攻撃は既に成功していて私たちのソフトウェア・サプライチェーンには悪意のあるコードがとっくに入り込んでいると認識しておくべき
• Embulkでの経験:
  • 確実な証拠や確信こそ無いものの「これは攻撃だったんだろうな」という事例があった

■ 9. 個人によるメンテナンスの限界

• 現状の問題:
  • 多くのオープンソース・ミドルウェアや「ミドルウェア化」したオープンソース・ライブラリが「個人」の手になるメンテナンスに依存
  • 多くのメンテナーが「疲弊」している
  • この数ヶ月の間だけでもcurlやlibxml2の話題が挙がっている
• エコシステムの持続性への疑問:
  • 個人で続けられるか疑問
  • 私たちのソフトウェア・エコシステムがいつまで保つか
  • 2025年の日本各地で問題のクマ対応とも相似形の問題を感じる

■ 10. Embulkの場合の詳細

• 著者の状況:
  • 半年ほど前にTreasure Data（TD）を退職
  • Embulkの「アクティブ」なメンテナーから「降りて」いる状態
  • この時点でEmbulkには「個人」のメンテナーしか残っていない状態だった
  • 新しい職場でEmbulkを使う見込みはなかった
• 以前からの活動:
  • 「オープンソースとしてのEmbulkのメンテナーを他にも割り当ててちゃんと引き継げる状態にしませんか」という活動を社内で数年前からしていた
  • 社外でもEmbulkを使っていると対外的にも知られた企業さんなどに「一緒にメンテナーやりませんか」と言ってきた
  • Core Teamのような形を作って少しずつでも関わってもらおうという取り組みもしていた

■ 11. プロジェクトをたたむ決断

• 決断の背景:
  • 引き継ぐ意志を明示的に示す人や組織が現れない限り既定路線だった
  • 当時の勤務先から積極的なサポートも見込めなかった
  • 自分はオリジナルの作者でもない
  • 個人として続けても安定した収入に結びつくわけでもない
  • メンテナンスを続けるしんどさだけがそこにある
  • 「これは攻撃だったんだろうな」の件も最後の追い打ちになった
• たたみ方の方針:
  • 「メンテナンスを静かに止めて言及も止めてアナウンスもせず、いつの間にかフェードアウト」のような態度を取るべきでないと考えた
  • 企業などで重要データを運ぶこともあるEmbulkのユースケースを考えれば盛大に事故る前に落ち着いて切り替えができるうちに公式なアナウンスをしておくことがメンテナーの責務
  • 悪意を持った人や組織にプロジェクトを引き継いでしまうくらいなら、プロジェクトをちゃんとたたむほうが結果的にユーザーにとっても良い

■ 12. 軟着陸のための方針

• 取り組み内容:
  • 「このままだと続かないよ」という広報を陰に陽に続け、引き継ぐという人や組織が現れれば歓迎し、引き継ぐために労力を割く意志も示す
  • 引き継ぎやすくするために今のEmbulkの設計について「なぜそうしたのか」を記録したドキュメント（Architectural Decision Record的なもの）をなるべく書き残す
  • 「メンテナンス・モード」になっても即座に「使えなく」はならない程度に「塩漬け」の準備をする
• 評価:
  • 100%狙いどおりにいったとは言えないが、たたみ方として悪くない着地になった
  • Embulkのコア機能やSPI（Service Provider Interface）の設計はよくできている
  • もうしばらくはこのままでもいちおうは「使える」
  • ただし無保証のオープンソース・ソフトウェアなので保証はない
  • 「いちおうは使える」うちに落ち着いて移行や社内forkなどを進めることをおすすめする

■ 13. 引き継ぎの困難さ

• 現在の引き継ぎの可能性:
  • いまからでも引き継ぐ道筋はいちおう残している
  • ただし当時ほど現実的な選択肢ではもうない
• 困難な理由:
  • 「引き継ぎのために著者が割けるのは100%プライベートの時間のみになった」こと
  • 「引き継ぎを申し出た人や組織に『悪意がない』ことを確認するのが難しい」こと
  • それらを乗り越えてでも引き継ぐ意志のある組織の方がいれば連絡してほしい

■ 14. メンテナーの仕事と責任

• メンテナンスの困難さ:
  • オープンソース・プロジェクトを、中でも「ミドルウェア」的な立ち位置になったソフトウェアのメンテナンスを「個人」の手のみによって続けるのは無理
  • これは一つのオープンソース・プロジェクトのメンテナーを十年近く続けてみることで得た当事者としての結論
• 開発とメンテナンスの違い:
  • 新規のオープンソース・ソフトウェアを開発するとか定期的に「コントリビューションする」とかはけっこう「個人」でできる
  • しかし「メンテナー」の役務はこうした「開発」とはまったく異なる
  • オープンソース・ミドルウェアのメンテナーが担うのは聞き取り、コミュニケーション、判断、意思決定、その意思決定の末にやってくる結果に責任を負うこと
• 責任の本質:
  • オープンソースは「無保証」でありユーザーが損害を被ってもメンテナーはその損害に責任を負うものではない
  • しかし「俺は俺が公開したいコードを好きに公開してるだけだし、ユーザーのことなんか知らね」と考える開発者なら最初からオープンソース・ミドルウェアの開発やメンテナンスなんかやっていない
  • 「あのときの自分の判断と意思決定の結果、どれだけのユーザー開発者がどのような影響を受けたのか」に向き合い続けるのがオープンソース・ミドルウェアのメンテナー
• Linuxからの教訓:
  • メンテナーは異なる意見を持つ開発者間の調停役を務めたりベンダーやユーザーとやり取りをする必要もある
  • 「開発者を見つける方はずっと簡単だ。開発者はたくさんいる」
  • 「メンテナーになるためには、他人のコードの善し悪しを判断できるだけのセンスを持っていなければならない」
  • 「それは通常、単に十分な経験があるかどうかの問題だ」

■ 15. 企業・組織の貢献と責任

• 企業ユーザーの困難:
  • 「企業ユーザー」が依存し始めた「ミドルウェア」のメンテナンスを「個人」の手のみによって続けるのは無理
  • しかし「企業ユーザー」は無理では困ってしまう
• コントリビューションの誤解:
  • 「もっと積極的に『コントリビューション』します」と考えるなら記事を読み返すべき
  • 徒に「コントリビューション」（pull requestなど）ばかりを増やすのはむしろメンテナーの負担を増やすだけの結果になるかもしれない

■ 16. オープンソース・プロジェクトの現在地とポリシーを知る

• 把握すべきこと:
  • 依存しているそのオープンソース・プロジェクトはどこの誰がどう開発やメンテナンスをしているか把握しているか
• 様々なケース:
  • 一個人が趣味で開発・公開しただけのまだ「メンテナンス」という段階ですらないもの
  • 開発者自身がオーナーシップを握って互換性など気にせず変えながら外部からのコントリビューションも入れず好きなように開発したいと思っているもの
  • 個人や数人レベルで開発しつつそろそろライブラリやミドルウェアとして安定してきていろんな人に使ってもらいたいと思っている段階のもの
  • 企業発のオープンソース・プロジェクトだが社内で作ったコンポーネントをせっかくだからと公開しただけで広く使ってもらおうという気は特になく社外の互換性都合など気にするつもりもなく外部からのコントリビューションを受け付ける気もないもの
  • 企業からオープンソース・プロジェクトとして公開しているが外部からのコントリビューションを受ける気はなく自社プロダクトを購入してもらうための導線として公開しているだけのもの
  • 企業発の門戸を開いたオープンソース・プロジェクトとして主導権は持ちながらエコシステムとともに発展させたいと考えているもの
  • 個人や企業から始まったオープンソース・プロジェクトだが大規模化して複数の個人や企業関係者が意思決定に参加するはっきりしたガバナンスを持つプロジェクトになっているもの
  • 個人発でも企業発でも今後のメンテナンス継続に限界を感じている状態のもの
  • これらのケースの間のグラデーションのどこかに位置するあいまいな状態のもの
• 判断の必要性:
  • 一口に「オープンソース・プロジェクト」といってもいろいろ
  • 「オープンソース」はただのライセンスでしかない
  • あなたの企業はそのオープンソース・プロジェクトに依存しても大丈夫か

■ 17. オープンソース・プロジェクトが求める貢献の形

• pull requestの誤解:
  • プロジェクトをGitHubに公開すると問答無用でpull requestを受け入れる状態にさせられてしまう
  • 「オープンソース・プロジェクトにはpull requestという名の『コントリビューション』を送るものなんだ」という「誤解」がすっかり広まってしまった
  • オープンソースであってもすべてのプロジェクトが外部からのpull requestを実際に受け入れているとは限らないし受け入れていても喜ばれるとは限らない
• 求められる貢献の形:
  • ただ応援してほしいだけかもしれない
  • スターがつくと嬉しいプロジェクトもあるかもしれない
  • いろんな人からのpull requestが嬉しいプロジェクトかもしれない
  • バグ報告は欲しいがpull requestは求めていないかもしれない
  • スポンサーのほうがpull requestよりも嬉しいかもしれない
  • 最終的には自社プロダクトを購入してほしいかもしれない
  • メンテナーとして共に持続的に役務を負ってくれる人を求めているかもしれない

■ 18. お金をとおしてメンテナンスに貢献する

• スポンサーの方法:
  • GitHub SponsorsやOpen Collectiveをとおしてスポンサーするのが話が早い
  • このような形でスポンサーを求めていないプロジェクトにスポンサーするのはややこしいが求めているプロジェクトには遠慮なく支払える
• 企業としての検討:
  • 企業としてスポンサー支出に正当性を持たせるのが難しいのはわかる
  • すべての依存プロジェクトをスポンサーするのは不可能
  • ただし「もしこのプロジェクトのメンテナンスが途絶えたらビジネスの継続にも支障が出る」というオープンソース・プロジェクトはないか
  • そういう単一障害点すら特定できていないのであればまずその特定をしたほうがいい
  • オープンソース・プロジェクトなんていつ止まってしまうかわからない
  • その単一障害点にあるプロジェクトくらいスポンサーを検討してもいいのではないか
• 製品購入:
  • そのオープンソース・プロジェクトがあくまで製品への導線で企業ユーザーとしてそのプロジェクトに依存するレベルで使おうとしているならちゃんと製品を購入すべき

■ 19. スポンサーの限界

• スポンサーの現実:
  • お金をとおして貢献できるプロジェクトばかりではない
  • そのメンテナーが人生をかけて個人でやっているのならスポンサーによってメンテナーの命と生活が助かるかもしれないがそんなプロジェクトはごく少数
  • 個人メンテナーにとってスポンサーはお小遣いくらいにはなるかもしれないが安定した収入として生活を支えられるようなものにはそうそうならない
• Embulkの場合:
  • 企業発という出自もあってスポンサーを募ったりはしていなかった
  • 仮にTreasure Dataとは独立にスポンサーを募って個人としてメンテナーを続けたとしても自分や家族の生活を支えられるとは思えない
• 本質的な問題:
  • 多くのオープンソース・プロジェクトにとってスポンサーは継続そのものの助けにはならない
  • 多くのオープンソース・プロジェクトには結局本来そもそも持続に必要なだけのメンテナーが「いない」
  • 多くのメンテナーが手弁当でメンテナンスを続けている（そして続けられていない）
  • Linuxにおいてすらそうである

■ 20. 雇用をとおしてメンテナンスに貢献する

• 課題の本質:
  • 私たちの「足元」があとどれだけ保つか
  • そこにある課題は「持続とメンテナーの安定」
  • 「持続と安定」に対して企業に期待される最もわかりやすい貢献は結局「雇用」
• 現実的な提案:
  • ほとんどの企業にとって「オープンソース・ソフトウェアのメンテナーをフルタイムで雇用する」なんていうのは難しい
  • しかし強く依存する途絶えては困るオープンソース・ソフトウェアが今後も持続するために雇用コストのごく一部でも正式に割くことはそんなに難しいか
  • ほとんどのオープンソース・ソフトウェアはかならずしもフルタイムでメンテナンスに従事するほどのメンテナーを必要としてはいない
  • 一方で個人の業務時間外の時間のみで持続できるものでもない
• 具体的な提案:
  • 自社が依存するオープンソース・プロジェクトとその現状を把握する
  • その維持が苦境にあれば会社としてその「メンテナンス」に貢献する意志を示す
  • 従業員がメンテナーとして継続的にそのプロジェクトに関与することを推奨する
  • その従業員の勤務時間のn割はメンテナンス活動に使うことを認知する
  • それを正式に評価する
  • フルタイムではなくこれだけでもメンテナーの状況はかなり改善する
• 危機感:
  • 世のbig techな企業はそれとはむしろ逆の方向に舵をきっていそう
  • 「たたむ」オープンソース・プロジェクトはこれからおそらく増えていく
  • その「足元」であなたの会社のビジネスは継続できそうか

MEMO:

• OSSの利用は自己責任が原則なのでしゃーない

(2025/11/26)

Rust is a disappointment

• Blog - Rust is a disappointment

要約:

■ 1. Rustに対する著者の立場

• 著者の姿勢:
  • かつて自分をRustヘイターと呼んでいた
  • しかしそれはStack Overflowの調査で最も愛されている言語としてRustがトップになるようなファンボーイ的傾向を相殺するためだった
  • C++を嫌う理由は多くあり、著者もC++を嫌っている
  • 多くの人がより良いプログラミング言語を待っていたが、代わりにRustを得た

■ 2. Rustの4つの核心的問題

• コンパイルが遅い:
  • 単に遅いのではなく非常に遅い
  • C++より遅い
  • 年々Rustは数倍速くなったが、客観的には2倍ではなく2桁（100倍）速くなる必要がある
• 複雑である:
  • C++と同程度に複雑
  • しかしC++にはレガシーがあったがRustにはなかった
  • Arc<Mutex<Box<T>>>のジャングルを毎回通り抜けなければならない複雑さが、実装されるロジックの品質に直接影響する
  • 木を見て森を見ずの状態になる
  • C++も同じ問題を抱えているなら、結局言語を切り替える意味は何なのか
• メモリ安全性はそれほど神聖ではない:
  • 実際、多くのアプリケーションではクラッシュするよりも誤動作する方が良い
  • 特にRustが存在したがっている組み込みの世界ではそうである
  • Rustでは99.999%の信頼性を得ることはできない
  • 常にクラッシュする
• 可変共有状態の処理において:
  • GUI、データベース、ステートフルサービス、OS/ハードウェアなど多くの可変共有状態を扱う場合
  • ネイティブのRustメモリモデルのパフォーマンスは劣る
  • 非ネイティブのunsafeを使うとコンパイルが遅く、複雑性が高く、結局メモリ安全性もなくなる
  • 重い可変状態の仕事に対してRustは実質的に無意味になる

■ 3. C++の問題点

• 未定義動作の遍在:
  • 未定義動作（UB）は言語の基本的な側面
  • 単にUBに遭遇するのではなく、言語全体がUBの上に構築されている
  • 配列のインデックスアクセスで即座にUBに遭遇する
  • 言語が範囲外アクセスをチェックしないため
  • 多くのUBはパフォーマンスの理由でさえ正当化されない
  • Cから引き継がれC++で増幅された完全にずさんな設計
• C++の具体的な問題:
  • 暗黙の型変換、暗黙のコピー、暗黙のコンストラクタ、暗黙のオブジェクトスライシング、ほぼすべてが暗黙的
  • 関数オーバーロード（暗黙的）、特にSTLでの遍在性を考慮すると
  • 例外を後付けとした非統一なエラーハンドリング
  • Cから40年経っても#includeでテキストファイルを取り込んでおり、One Definition Ruleはコンパイラによるチェックがほとんどない
  • パラダイムの不健全な組み合わせ（子孫クラスでジェネリック関数をオーバーライドする幸運を祈る）
  • ジェネリックプログラミングの中核メカニズムとしてのSFINAEの厄介さ
  • T、T&、T*、std::optional、std::unique_ptrで似たようなものを記述するが、それぞれ独自の方法で壊れている。その上にconstを載せる
• 結論:
  • C++は複雑で、安全でなく、コンパイラが遅い
  • Rustはこれらの問題をどのように修正し（あるいは修正していないか）

■ 4. 遅いコンパイルの詳細

• 設計上の問題:
  • 一時的な問題ではなく設計によるもの
  • Rust開発チームは毎回コンパイル速度を犠牲にしてきた
• 最適化の努力:
  • Rust FAQでは、より良いフロントエンド、MIRなど多くの最適化努力があると説明している
  • しかしMIRの取り組みは2015年に開始されたが、依然としてコンパイルを大幅に高速化できていない
  • コンパイラチェックは高速化している
• 本質的な問題:
  • Rustを高速にコンパイルすることは不可能
  • 問題はHaskellのような類似のジェネリクス多用言語に固有のもの
  • Rustは議論の余地があるがC++よりもHaskellに近い
  • テンプレートを多用するC++コードと同じ遅いコンパイルの問題を示す
• 具体例:
  • for i in 0..limit {}を実行すると、単に反復するのではなく、範囲を作成し、イテレータを作成し、それを反復する
  • すべてが具体的な型に単相化され、個別に最適化される必要がある
  • 最適化されていないRustコードは非常に遅く、デバッグにさえほとんど使用できない
• ボローチェッカーの影響:
  • その上に非オプションのボローチェッカーを載せると、非常に遅いコンパイラになる
  • ボローチェッカーは容赦ないので、何度も再コンパイルすることになる

■ 5. 複雑さの詳細

• 回避不可能:
  • 「コールドパスの高レベルコードを書いているのでパフォーマンスは必要ない、ライフタイム処理の深みに入る必要はない、単に高レベルのロジックを書きたい」という姿勢は取れない
  • Rustの1行を書くたびに低レベルの細かい点に強制的に押し込まれる
• ガベージコレクタの不在:
  • RustにはGCがなく、今後もない
  • すべてのデータを所有権のツリーに半手動でパックする必要がある
  • 数行のコードを書くだけでも所有権、借用、トレイトに精通している必要がある
• 高レベルロジックの困難:
  • Rustで高レベルのロジックを書くのは非常に困難
  • 多くの初期Rust採用者が実際にはパフォーマンスにそれほど敏感でないサービスにはNode.jsやGoに戻っている
  • 高い複雑さと遅いコンパイルの組み合わせにより、純粋なRustで複雑なものを書くことが非現実的になる

■ 6. メモリ安全性の詳細

• Rustの妥協しない2つのもの:
  • パフォーマンスとメモリ安全性
  • Rust設計者はメモリ安全性に関して行き過ぎた
• コンテナの実装:
  • コンテナは実際にはunsafe関数で実装されている
  • チューリングマシンモデルでは完璧な正しさは不可能
  • 慎重に配置されたunsafeなビルディングブロックから安全なプログラムを構築する必要がある
• 他言語との比較:
  • Node.jsとGoは実用的に安全な言語と見なされている
  • Rustは正気さと実用性をメモリ安全性のために犠牲にした
  • そして結局どれも得られず、依然として100%メモリ安全ではない
• 実用性について:
  • 多くのユースケースは完璧なメモリ安全性を必要としない
  • リモートコードを実行したり秘密を漏らしたりしない安全でないプログラムを実装する方法がある
  • ユーザーデータを破損させ散発的に動作するだけ
  • ペースメーカーが停止した場合、被害者に「クラッシュ時にメモリは破損していなかった」と伝えても慰めにならない
• Cloudflareの障害事例:
  • unwrap()関数でのクラッシュによって引き起こされた最近のCloudflareの障害があった
• 著者の最も強い主張:
  • Rustはメモリ安全で信頼性がない
  • メモリ安全性の代価は開発者の正気さに加えて信頼性だった
  • 言語設計者は行き過ぎた
  • メモリ安全性という抽象的な原則のために中核的な実用的品質を犠牲にした
  • Haskellの設計者が純粋性のために実用性を犠牲にしたのと同様
  • RustとHaskellの類似性を繰り返し指摘する理由

■ 7. 可変共有状態の詳細

• Rustでの可変共有状態:
  • 可能だが、Rustで可変共有状態を使用することは意味がない
  • ほとんどの利点を失い、Rustのすべての欠点だけが残る
• 成功したRustプロジェクト:
  • ほぼすべてが共有の読み取り専用状態、一方向データフロー、非循環データ構造を採用している
  • rustcコンパイラ、mdbookとpulldown-cmarkのMarkdownツール、ステートレスハンドラ用のActixとAxum、追記専用ブロックチェーン、シングルスレッドWASM
  • モデルはHaskellに非常に似ている
  • Haskellもパーサー、ステートレスハンドラ、ほぼ非インタラクティブなCLIツールで優れており、ブロックチェーンで使用されてきた
• Software Transactional Memory:
  • Rustの初期プロトタイプには安全な並行性のオプションとしてSTMがあった
  • しかしSTMにはパフォーマンスペナルティがあり、単純だが重要なランタイムサポートが必要
• 共有可変状態に踏み込むと:
  • メモリ破損は例外ではなくルールになる
  • 破損を処理する必要があり、単にクラッシュすることはできない
  • ボローチェッカー、所有権は役に立たない
  • GCのようなアルゴリズムなしで循環グラフの所有権を分析することはできない
• Sync/Send、Mutex、Arc:
  • ロックするか、CPUキャッシュをひどく乱すので、マルチスレッド通信には非効率
  • 少なくとも集中的なものには
  • 安全だが非効率
  • Rustの最初の妥協しないもの（パフォーマンス）を破壊する
• 結論:
  • 共有可変状態に踏み込んだ瞬間にRustのすべての利点を失う
  • Rustの主要なコンセプトが共有可変状態を決して使用しないことだったことを考えると合理的

■ 8. GUIとRustの問題

• GUIは可変共有状態:
  • そのためRustで大きなGUIプロジェクトは見られない
• Zed IDEの例:
  • 何年も経ってもまだベータ版
  • 開発者がボローチェッカーのジャングルを突破してロジックがバグだらけであることに気づき、まだ何十もの他の機能を実装する必要がある苦痛がほとんど感じられる
• まだ見られないもの:
  • 大規模データベース
  • スケーラブルなステートフルサービス
  • オペレーティングシステム
  • 少なくとも重要なLinuxモジュール

■ 9. 結論：Rustの評価

• Rustは良いのか悪いのか:
  • どちらでもない
  • 開発に何千人月も費やされた平凡なプログラミング言語
  • この事実だけでRustは実用的なツールになる
  • 棚から取り出してそのまま使用できるため
• 具体例:
  • このブログはRustで書かれたZolaで生成された
  • 使用するためにRustのコードを1行も書く必要がなかった
  • Zolaは不変データの一方向フローを持つ非インタラクティブな性質のためRustに適している
• 著者の願い:
  • 「Rustは最高のプログラミング言語だから、みんな開発をRustに切り替えるべきだ」と叫び回らないでほしい

(2025/11/26)

「Postgres で試した？」と聞き返せるようになるまでもしくはなぜ私は雰囲気で技術を語るのか？...

• 「Postgres で試した？」と聞き返せるようになるまでもしくはなぜ私は雰囲気で技術を語るのか？ — Just use Postgres 読書感想文 - じゃあ、おうちで学べる

(2025/11/26)

ひろゆき氏が語る大規模SIerの未来　20人月体制から1人とAIで回す開発へ

• ひろゆき氏が語る大規模SIerの未来　20人月体制から1人とAIで回す開発へ [1/2] | ログミーBusiness

要約:

■ 1. フルスタックエンジニアを目指すべき理由

• ひろゆき氏が目指すなら「全部やる」エンジニアである
• フロントエンジニアの限界:
  • フロントしかできない場合、バックエンドがよくわからないため誰かに頼まなければならない
  • その誰かのコストが高かったり優秀でなかったりしても対抗できなくなる
• 全部できることの利点:
  • 自分1人で全部できるようにしたほうがよい
  • バックエンドをやっている人を選ぶ時に話が通じる
  • 優秀な人を見抜くにはその業界の知識が必要である
  • サーバーを立てたことがない人に優秀なサーバーエンジニアを選ばせても、どういう基準で話をしたらいいかわからない
  • ひと通り理解することを早めにやっておいたほうが人生で得することが多い

■ 2. コミュニケーション能力の必要性

• エンジニアにコミュニケーション能力は必須ではない:
  • ひろゆき氏は月に3、4,000万人が使う「4chan」を運営している
  • エンジニアとのやり取りは基本的に全部メールかネットワーク経由である
  • 直接会ったことがある人は1人もいない
  • 電話で話したことがある人は何人かいる程度である
• テキストベースのやり取りの利点:
  • 実際のやり取りはテキストベースである
  • その人が本当に英語を理解しているかどうかもわからない
  • 翻訳ツールを使っているかもしれないが、「これやって」と言ったらやってくれるので困ったことがない
  • タイムゾーンの問題もあるため顔を合わせてやる必要がない
  • テキストで「これやっておいて」と言ったほうが口頭で説明するよりも情報が伝播しやすい
• コミュニケーションが苦手な方が有利:
  • ある国の山奥に住んでいるエンジニアは「都会は人が多くてゴミゴミしていて、自然が美しくないから嫌だ」という理由で移住した
  • たぶん彼はコミュニケーションが苦手だが、何の問題もなく暮らしている
  • コミュニケーションが苦手な方のほうがエンジニアはやりやすい

■ 3. エンジニア像の多様化

• リア充エンジニアとギーク文化:
  • 最近のIT界隈ではリア充っぽいエンジニアが増えているという指摘がある
  • オタク的なギーク文化が失われつつあることへの寂しさを感じる声がある
• 実態は両方が増加:
  • オシャレ系エンジニアもコミュニケーションが苦手エンジニアも増えている
  • エンジニアの枠自体がどんどん増えている
  • エンジニアという職業の人が増えているため、ギーク的でニッチなことが好きなオタクと言われるような人数もめちゃくちゃ増えている
• 多様性のメリット:
  • 「同じ考え方のエンジニアだけ集めたいです」というのはやりやすくなっている
  • 幅広くなってよかったという話である
  • 女性エンジニアもそんなに珍しくないため、「女性同士でエンジニアの話したいです」という人でもちゃんとコミュニティが作れる時代になっている
  • いい時代になっている

■ 4. SIerの未来予測

• 大規模SIerの衰退予測:
  • これからはプロジェクトに必要なエンジニアが減る
  • 外注しなくても自社でエンジニアを迎えるようになる
  • SIerが衰退している
• AIによる構造変化:
  • 「大規模なSIerにお願いして20人チームを派遣してもらって作る」よりも「めちゃくちゃ優秀なエンジニア1人がAIを使い倒して、20人分のコードを書かせる」ほうがよい状況になる
  • 本来ならSIerに頼んで「20人月です」という案件でも、フリーランスのすごい人が「じゃあこれ4ヶ月で俺1人でやりますよ」と言えるようになる
  • 発注側もその1人と話すだけで済み、20人月で契約するより安く話が早い
• SIerの今後:
  • 大規模SIerはけっこう仕事が取りづらくなる
  • 1人でフリーランスをやっててAIを使って「コードはバンバン書けます」という人はかなりいい金額を取れるようになる
  • SIer的な仕事自体は残る
  • 「20人派遣します」みたいな大人数前提のやり方は銀行業界など特殊なセキュリティ要件があるところを除けばわりと衰退していく

■ 5. 発言スタイルと切り抜かれやすさ

• 意図的な発言スタイル:
  • ひろゆき氏はわざと切り抜かれやすいような言い方をしている
  • 尖った発言のほうが切り抜かれやすい
  • 端的に説明したほうが理解されやすい
• 長文が読まれない時代:
  • 長い文章を読めない人が日本で増えている
  • もともとそんなに読解力が高くない人たちもインターネットを使うようになってきている
• 結論先行型の話法:
  • 結論を最初に「はい」「いいえ」「ノーコメント」みたいに言って、そのあとに理由を説明するほうが伝わりやすい
  • それをやると最初に「あなたの意見には乗りません」というのがハッキリしてしまう
  • 「理由はこれです」と続けるため、人と仲良くしながらフワッと否定するような日本語っぽい言い方がしづらくなる
  • だから引っかかりやすい
• 海外生活の影響:
  • 岸谷蘭丸氏も同じしゃべり方をしている
  • 海外で、しかも学生として生活していた人はこうなる
  • 英語圏で生活すると、最初にYes/Noを言ってから理由を言うというのが身についてしまう
  • だから日本語で話すときもその感じが出てしまう

■ 6. 就職先選択の基準

• 最も重要な基準:
  • 会社に入るときに一番大事なのは「相談できる相手がいるかどうか」である
  • 自分がわからないことや「これどうやるのが正解なんだろう？」と聞いたときに、ちゃんと丁寧に教えてくれる人がいる会社は所属する価値がある
  • それがないんだったら「自分ひとりでやってるのと一緒じゃん」という話である
• 業種よりも社風:
  • 業種がどうこうというより「同僚が、聞いたらちゃんと答えてくれる空気の会社かどうか」のほうが大事である
• 面接での見極め方:
  • エンジニアの面接では一次は人事だけだが、二次以降でエンジニアの人が出てくることがある
  • そのときにこちらが何か質問したら、どれくらい丁寧に答えてくれるかを見るとよい
  • 「あ、この人はちゃんと答えようとするタイプだな」とわかれば、その会社にはそういうエンジニアがいるということである
  • 逆に「え、それも知らないんですか？」みたいな反応をしてくる会社だと「あ、ここは自分が入っても質問しにくいな」となる
  • エンジニアにとって質問しやすいかどうかやオープンな社風があるかどうかのほうが大事である
• 業種による違い:
  • 業種がSESだったとしても、めちゃくちゃ親身になって教えてくれるスタッフが多い会社もある
  • 「みんなでちょっとずつスキル上げていこうぜ！」というタイプのところもある
  • 一方で、同じSESでも実態はほぼ個人事業主の集まりみたいになっていて「それ自分で調べて」「お前の仕事手伝っても俺の給料増えないし」みたいな人が多い会社もある
  • 社風は面接や実際に話してみないとわからない

■ 7. 企業の自社エンジニア枠の増加予測

• 自社エンジニア枠は増加する:
  • AIでエンジニアがうんぬんという話があるが、SES自体が減っていって「これは他社に任せるより自社でやったほうがいいよね」となる
  • けっこう増えると考えられる
• オウンドメディアの増加:
  • 最近「Nintendo Direct」みたいなオウンドメディアを持つ会社も増えている
  • 自社でいろいろやろうとすると結局ぜんぶインターネット経由になる
  • 物を売るのも知ってもらうのもインターネットになる
  • だったらその部分は他社に丸投げするより自社で持ってたほうがいいという話になる
• コスト構造の変化:
  • 今までは自社で抱えるとエンジニアコストが高かった
  • わりと優秀な人を1人置いておいて、あとはAIにやらせるようなやり方でもそこそこ回るようになってきた
  • 中堅企業でも「自社エンジニア枠」をちょこちょこ入れていく流れになる
• フリーランス活用の増加:
  • フリーランスと契約して「うちの会社のこと頼んでいる人なんですよ。フリーランスですけどね」みたいな関わり方をするパターンもある
  • そういうタイプの業務はこれから増えていく

(2025/11/26)

セキュリティ特化型OS「GrapheneOS」が「国家による脅迫を受けた」としてフランスから撤退

• セキュリティ特化型OS「GrapheneOS」が「国家による脅迫を受けた」としてフランスから撤退 - GIGAZINE

要約:

■ 1. GrapheneOSの概要

• 特徴:
  • オープンソースで開発されているセキュリティとプライバシー保護に特化したAndroid系OS
  • Google Pixelなどを安全に使うために利用されている
• 問題点:
  • セキュリティの高さから麻薬密売人などに使用されることがある
  • プライバシーを保護する機能が強力ということは悪事を働いても露見しにくいということにもなる

■ 2. フランス政府との対立経緯

• フランス政府の姿勢:
  • 以前から「GrapheneOSは犯罪者向けのもの」と表現するなど敵対視していた
  • フランスの治安当局が「隠れて生きる意思を裏付けるもの」として使用することが罪であるかのような調査報告を出したことがある
• GrapheneOSの反論:
  • フランス当局の姿勢に反発
  • 「ヨーロッパの独裁政権や政権を支持するメディアで、GrapheneOSやPixelを犯罪者向け製品であるかのような誤った表現が使われている」と非難
  • 「GrapheneOSはこれらの勢力が全員に強要しようとしている大規模監視警察国家に反対している」と表明

■ 3. Le Parisienの報道（2025年11月19日）

• 報道の内容:
  • フランスのメディア・Le Parisienで「Google PixelとGrapheneOS：麻薬密売人が警察からデータを守るための秘密兵器」というニュースが報道された
• GrapheneOSの反応:
  • メディアおよびジャーナリストに対し「GrapheneOSについて根拠のない、そして明らかに虚偽の主張をするためのプラットフォームを提供しながら、それらの主張を確認し反論する機会をまったく提供していない」と憤りを示した
• 検察当局者の発言:
  • 「GrapheneOSは犯罪組織とのつながりがあり、捜査に協力しないのであれば法的措置に出る」とコメントが掲載された
  • GrapheneOSはこれを「事実無根であり、国家による法的脅迫だ」と問題視

■ 4. 機能に関する誤解

• フランス当局の主張:
  • GrapheneOSがアクセス時にデータを消去する機能や偽アプリを含む犯罪者向けのOSと主張
• GrapheneOSの反論:
  • それらの機能は公式版には存在しない
  • オープンソースとして公開しているGrapheneOSの悪質なクローンや非公式版と混同されている

■ 5. フランスからの撤退発表

• 撤退の理由:
  • フランスはオープンソースのプライバシープロジェクトにとってもはや安全ではない国であると判断
  • プロジェクトとユーザーを守るため今後はフランスへの進出を完全に避ける方針
  • フランスの政府機関と法執行機関の行動と発言が極めて懸念すべき点
  • GrapheneOSについて極めて不正確で中傷的な主張をしながら明らかに措置を正当化しようとしている
  • 「彼らは手の内を見せたので、何か悪いことが起こる前にフランスから撤退する」と表明

■ 6. インフラ移行計画

• 従来のインフラ:
  • 公式サイトやソーシャルメディアなどの主要インフラをフランスに本社を置くヨーロッパ最大のクラウドコンピューティングサービスであるOVHに依存していた
• 移行先:
  • MastodonやオンラインコミュニティプラットフォームのDiscourseなどをカナダのローカルサーバーと共有サーバーの組み合わせに移行
  • 重要なウェブサイトインフラはドイツに拠点を置くウェブホスティングサービスのNetcupに移行
  • OVHから脱却する
• 開発者の制限:
  • 安全上の懸念からGrapheneOSの開発者たちはフランス国内での作業を禁止している

■ 7. 今後の方針

• AOSPへの貢献:
  • 法執行機関やフォレンジック企業が捜査においてAndroid端末を突破するために使用している脆弱性をGrapheneOSで修正することを目指す
  • AOSP（Android Open Source Project）に貢献していくと表明
• Googleへの呼びかけ:
  • 「Googleからのご連絡をお待ちしております」と述べている

MEMO:

• フランスの「自由」は都合よく解釈可能な「自由」なのでしゃーない

(2025/11/26)

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

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

MEMO:

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

(2025/11/25)

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

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

MEMO:

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

(2025/11/25)

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

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

要約:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(2025/11/24)

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

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

要約:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(2025/11/24)

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

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

要約:

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

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

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

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

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

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

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

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

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

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

(2025/11/24)

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

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

(2025/11/23)

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

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

@sakamoto_582

MEMO:

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

(2025/11/22)

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

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

(2025/11/22)

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

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

(2025/11/22)

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

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

(2025/11/22)

DDD x Microservice Architecture : Findy Architecture Conf 2025

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

(2025/11/22)

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

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

(2025/11/22)