/note/tech

I Made Zig Compute 33 Million Satellite Positions in 3 Seconds. No GPU Required.

I Made Zig Compute 33 Million Satellite Positions in 3 Seconds. No GPU Required. | Anthony T's Blog

要約:

■ 1. プロジェクト概要

astroz は最速の汎用SGP4実装でネイティブZigで1秒あたり1100万〜1300万回の伝播計算を実現

Python経由では約700万回毎秒でpip install astrozのみで利用可能

GPUを使用せずCPUのSIMD命令のみで高速化を達成

汎用実装の定義:

heyoka.pyは複数衛星の同時バッチ処理で高速だが一般的なODE積分器でLLVMのJITコンパイルとC++依存関係が必要

astrozは時間バッチ伝播で2倍高速で単一衛星の複数時刻計算に特化

GPU加速SGP4実装は大規模バッチワークロードで高速だがCUDA/OpenCLセットアップが必要で汎用的ではない

■ 2. SGP4最適化の動機

SGP4は1980年代からTLEデータから衛星位置を予測する標準アルゴリズム

既存実装は元のリファレンスコードの移植版で機能するが高密度時間解像度では遅い

実用的な課題:

1ヶ月のエフェメリスデータを1秒間隔で生成すると衛星1個あたり260万回の伝播計算が必要

地上局ネットワークでの通過予測は数週間にわたりサブ秒精度が必要

接近スクリーニングの軌道解析は近接アプローチを捕捉するため細かい時間ステップが必要

典型的な良い実装で200万〜300万回毎秒だと衛星1個あたり数秒かかり反復解析やインタラクティブツール構築では遅い

■ 3. 初期最適化とスカラー実装

SIMD導入前のスカラー実装で既にRust sgp4クレート（最速のオープンソース実装）と同等以上の性能

主要な設計選択:

分岐のないホットパス:

SGP4アルゴリズムには多数の条件分岐が存在

深宇宙対近地球や異なる摂動モデルやケプラーソルバーの収束チェックなど

可能な限り分岐なし表現として記述

当初はパフォーマンス目的ではなくコードの理解しやすさのため

偶然にも現代CPUが予測可能な命令ストリームを好むため高速化

コンパイル時事前計算:

Zigのcomptimeで任意のコードをコンパイル時に実行可能

SGP4のセットアップ作業の多く（重力定数や多項式係数や派生パラメータ）を一度計算してバイナリに焼き込む

ランタイム初期化や繰り返し計算が不要

constでマークした変数は自動的にcomptimeとして扱われる

スカラー実装で520万回毎秒を達成しRustの500万回毎秒を若干上回る

■ 4. SIMD実装の発見と基礎

SGP4は状態に依存せず各衛星と各時点が独立しているためSIMDに適している

ZigがSIMDを第一級市民として扱う設計:

シンプルな型宣言のみで開始可能

const Vec4 = @Vector(4, f64)で4つの64ビット浮動小数点数のベクトルを定義

イントリンシクスやプラットフォーム検出や条件付きコンパイルが不要

LLVMバックエンドがコード実行環境に適した命令セットを自動的にターゲット

組み込み演算:

スカラーを全レーンにブロードキャストする@splat

LLVMイントリンシクスを通じた自動ベクトル化された超越関数

@sinと@cosはLinux x86_64でのlibmvecなどプラットフォーム最適実装を使用

レーン単位の思考への転換:

スカラーコードではif文で一方のパスを実行

SIMDでは全4レーンが同時に実行されるため両方の結果を計算してレーン毎に選択

両方のパスを計算することは無駄に見えるが分岐予測ミスより高速な場合が多い

SGP4では大半の衛星が同じパスを取るため無駄な計算は少ない

収束ループの処理:

SGP4のケプラーソルバーは各結果が収束するまで反復

スカラーでは許容誤差以下になるまでループ

SIMDでは異なるレーンが異なる速度で収束

解決策はレーン毎に収束をマスクで追跡し@reduceで全員完了を確認

パターン理解後はスカラー実装を一行ずつ変換し元のコードをテストスイートで比較できるよう保持

■ 5. 3つの伝播モード

時間バッチ propagateV4:

最も一般的なワークロードに対応

単一衛星の複数時点を同時に4時点処理

エフェメリスデータ生成や通過予測や軌道解析や接近スクリーニングに使用

衛星の軌道要素がレジスタに留まり4つの出力を計算するため最もキャッシュフレンドリー

最大の初期高速化を実現

衛星バッチ propagateSatellitesV4:

多数の衛星を1つの特定時点で処理

衝突スクリーニングスナップショットやカタログ全体の可視性チェックに使用

4つの異なる衛星を同一時点で同時処理

ElementsV4という異なるデータレイアウトが必要

各フィールドがVec4で4つの異なる衛星の値を保持

コンステレーションモード propagateConstellationV4:

多数の衛星を多数の時点で伝播

ライブデモでは13000個の衛星を1440時点で処理

キャッシュを意識したタイリング戦略:

各衛星の全時点を計算する素朴なアプローチはキャッシュをスラッシング

64時点を全衛星で処理してから次の64時点を処理

時間値がL1キャッシュにホットな状態で衛星バッチをスイープ

タイルサイズ64はL1サイズを作業データサイズで割りSIMDフレンドリーな数に丸めたもの

大規模カタログでは素朴なループより15〜20%高速

■ 6. atan2問題と解決策

SGP4のケプラーソルバーはatan2を必要とするがLLVMはベクトル化されたビルトインを提供していない

スカラー関数を呼び出すとSIMD実装が壊れる

多項式近似による解決:

SGP4の精度要件（モデルに固有の制限がある）では完全な精度は不要

引数を[0,1]の範囲に保ち多項式精度を向上

ホーナー法で計算

@selectを使用した分岐なしの象限補正

多項式近似は約1e-7ラジアンの精度でLEO距離で約10mmの位置誤差に相当

これはSGP4の固有精度限界内で数日間の伝播では数キロメートルの不確実性がある

この数学は複雑でAIの支援を受けて実装

■ 7. Struct of Arraysデータ構造

複数衛星処理のためStruct of Arraysレイアウトを使用

ElementsV4構造体:

各フィールドがVec4で4つの衛星の値を保持

重力モデルや離心率や傾斜角や昇交点赤経などの軌道要素

事前スプラット済み定数をinit時に一度計算

事前スプラット最適化:

ホットパスでの繰り返し@splat呼び出しを排除

毎秒数百万回実行されるコードでは小さな最適化も重要

■ 8. ベンチマーク結果

ネイティブ実装比較（Zig vs Rust）:

1日（分間隔）でastroz 0.27ms対Rust 0.31msで1.16倍高速

1週間（分間隔）でastroz 1.99ms対Rust 2.04msで1.03倍高速

2週間（分間隔）でastroz 3.87ms対Rust 4.03msで1.04倍高速

2週間（秒間隔）でastroz 222ms対Rust 234msで1.05倍高速

1ヶ月（分間隔）でastroz 8.37ms対Rust 8.94msで1.07倍高速

両実装ともスカラー処理で約500万回毎秒を達成

Zig実装がRustを若干上回るのはホットパス最適化とcomptimeの積極的な事前計算による

ネイティブSIMDスループット:

astroz Zig SIMD実装で1200万回毎秒

astroz Zigスカラー実装で520万回毎秒

Rust sgp4で510万回毎秒

@Vector(4, f64)を使用した複数衛星または時点の並列処理でスループットがスカラー実装の2倍以上に向上

Pythonバインディング性能:

2週間（秒間隔）でastroz 160ms対python-sgp4 464msで2.9倍高速

1ヶ月（分間隔）でastroz 5.9ms対python-sgp4 16.1msで2.7倍高速

Pythonバインディングスループット:

astroz Python 700万回毎秒

satkit（Rust）370万回毎秒

python-sgp4 220万回毎秒

heyoka.pyとの比較:

8衛星×1440時点でheyoka.py 1620万回毎秒対astroz 750万回毎秒

1衛星×1440時点でheyoka.py 380万回毎秒対astroz 850万回毎秒

100衛星×100時点でheyoka.py 1550万回毎秒対astroz 840万回毎秒

heyoka.pyは複数衛星バッチで勝利しastrozは時間バッチワークロードで勝利

ユースケースによる選択:

数百の衛星を同時に同一時点で伝播する場合はheyoka.pyが有利

個別衛星のエフェメリス生成や通過予測や軌道解析の場合はastrozが2倍高速

簡単なデプロイメントが必要な場合はastrozがpip installのみでNumPyのみ依存しheyoka.pyはLLVMとC++スタックが必要

■ 9. 実用的なデモ

インタラクティブCesiumビジュアライゼーション:

CelesTrakの全アクティブカタログ約13000個の衛星を処理

1440時点（1日を分解像度）で約1900万回の伝播計算

Pythonバインディング経由で約2.7秒で完了（約700万回毎秒）

TEME→ECEF座標変換に約0.6秒追加で合計約3.3秒

ネイティブZigでは1100万〜1300万回毎秒に到達

高速化により計算のバッチ処理やスケジューリングを考える必要がなくなり必要な時に必要な計算を実行可能

■ 10. 今後の展望と利用方法

今後の開発:

SDP4実装で深宇宙天体に対応（現在は軌道周期225分未満の近地球衛星のみ）

マルチスレッド化でコア全体にスケール

SIMD作業は単一スレッドで実行されており別の倍率が待機中

利用方法:

PyPIで利用可能でpip install astroz

Zigプロジェクトへの追加はzig fetch --save

GitHubでオープンソースとして公開

examplesを参照して統合可能

ライブデモで動作確認可能

(2026/01/22)

プログラマの抱いている「住所」についての誤謬

プログラマの抱いている「住所」についての誤謬

(2026/01/21)

フリーランスは社員みたいにチャンスをもらえない？

フリーランスは社員みたいにチャンスをもらえない？

要約:

■ 1. 結論と前提

フリーランスは社員ほどではないが取り組み方次第で今後生き残るためのスキルを獲得するチャンスはある

早いうちにフリーランスとして色んな現場に参画することは長期的な視点でメリットがある

筆者の報酬は年齢と過去の経歴を加味すると同年代より高くエージェント紹介の単価水準でも高単価の部類

9年ほどフリーランスエンジニアとして培った案件選びや面談のスタンスやチームコミュニケーション改善のナレッジを共有

■ 2. チャンスをもらえない構造の否定

チャンスをもらえないのは選んだ現場とあなたの評価の問題

筆者は技術力が高いわけではなく30代に入ってアルゴリズムを勉強し直している最中

独立当時はウォーターフォール開発で詳細設計から実装を半年ほどのベビーエンジニアステータス

しかし現在や前の会社で多数のチャレンジ機会を獲得:

ゼロイチのプロダクトの初期メンバーに抜擢

未経験言語の実装を任される

エンジニアの採用面談に同席し合否に関わる立場

完全未経験なrustの開発に単価を下げず参画

プロダクトの要になるデータパイプラインの新規構築

顧客管理システムリプレイスの技術選定からリリース前までの実装をリードエンジニアとして推進

「経験が積みづらくなる構造的な力学」があるなら9年間業務委託のエンジニアOnlyな筆者はもっと厳しいスキルで今を迎えているはず

フリーランスなら先に鍛えるべき力が不足していたために「チャンスを与えてくれる現場に出会う能力や見せ方ができなかった」

「フリーランスとして魅力的なマインドを持っていたわけではない」

■ 3. エージェントの存在が将来を不安にさせる

ITエージェントという存在のせいでその力を培わずともなんちゃってフリーランスになれてしまう

「あなたの年齢とスキルで紹介できる案件がない」と言われた瞬間に自分で案件を開拓することをしなかったエンジニアは窮地に追い込まれる

動物園で飼育員がご飯を挙げなかったらどんなに屈強なライオンだって餓死する

Findy関係者の意見:

売り手市場ではなくなってきている状況

エンジニアが企業のニーズを汲み取りアピールできるかが鍵

エージェント視点でも売り手市場の陰りとエンジニアが受け身で居続けることの懸念

■ 4. 正社員とフリーランスの比較

正社員は待ってても来る可能性があるが望んでなくても来る

フリーランスは手を上げ続けなきゃ来ないが望んでないなら来ない

フリーランスが正社員より優れているという主張ではない

100%の責任を追う経験や意思決定の場に参列するのは多くは正社員

賃貸やローン等の社会的信用は企業のエンジニアには到底叶わない

生存戦略的視点で言えば正社員の70から80%程度の役割や権限ならフリーランスにもチャンスはある

案件探しや業務への向き合い方次第

正社員だろうともあっさり辞める時代

チームメンバーだし業務委託だろうともっと良いコード書けるようになってほしいなとコストをかけてもいいと思わせる当時のパーソナリティと案件の目利き力がなかっただけ

業務委託だって強くなって良いコードが書ければそれがコードとして資産になる

ノウハウがそのままプロダクションコードとして残るのがエンジニアという職業の良いところ

■ 5. フリーランスにおける成長の定義

成長の3要素:

案件レベルに直結する技術的成長

案件の獲得率につながる営業的成長

案件の継続に関わるコミュニケーション的成長

営業的なコミュニケーション力とチーム開発で必要とされるコミュニケーション力は別

ロースキルでまず一番先に身につけるべき優先順位:

1: 営業的成長

2: コミュニケーション的成長

3: 技術的成長

営業力の定義:

お客さんに押し売るゴリゴリなパワーではない

日常生活においても役立つコミュニケーションのテクニック的な部分

繰り返し実践することで徐々に自分の身体に染み付く

■ 6. 営業力が大事な理由

理由1:質の高い案件に入り込めれば他の成長は付随する

営業力が上がると高単価の案件に参画できる

期待値と能力があっていないので自己研鑽せざるを得ない

シニアエンジニアの端的なコミュニケーションを理解するために言葉の言い回しや質問の質を上げざるを得ない

質の高い案件獲得を目指すことが一番連動して効率よく成長できる環境を手に入れられる

理由2:面談が「加点評価の場」になるか「減点評価の場」になるかは営業力次第

面談は文字列でわからない人格や雰囲気やコミュニケーションスタイルを把握する大事な場

正社員だろうがフリーランスだろうが対面の会話は最も重視すべき

技術力が突出していないエンジニアが1時間の面談の中でまず探るべきはセールスでいうところの潜在的ニーズ

自分の経歴を語る前にこれを引き出せるかが特に大事

採用の目的(求人票)だけでなくブラインドされたチームの課題を引き出せるかで「相手の事を考える回数」がかなり増える

限られた数十分のあなたのターンで引き出す必要がある

面談が面倒な見極めの場ではなく相手の欠けたピース探しと気持ちよくそのパズルをはめるゲーム感覚で臨める

■ 7. スキルの切り売り問題への反論

スキルの切り売りになる原因:

自分がある意味一番技術力あるチームにいる

新しい知識を入れるチーム文化がない

背伸びして入った現場じゃない

営業行為とは「付加価値」をつける行為

営業力がない人は自分を時給4000円で案件を探し実力に見合う仕事しか紹介されず出会えない

営業に自信があれば時給5000円や6000円で案件を探すまたは決裁前に値上げ交渉をする

今の実力に見合わない仕事を手に入れるチャンスが出てくる

上振れであなたに見合わない仕事はつまり伸びしろを与えてくれる仕事

ダイナミックなスキルチェンジに関わる案件以外は最低時給500円以上は単価アップするような案件を選び続ければ単価が成長の具体値として示してくれる

■ 8. 権限とマネジメント

権限について:

一部の企業は与えないが意欲のある人でも絶対与えられないなんて事はない

高い単価をもらっているとやれるかは別として依頼される確率は高い

高い金払ってるんだからやってよ的な思想

マネジメントについて:

別に関われるし人次第

まとめるのが上手な人なら業務委託がサブリーダー的に使えない正社員の代わりにマネジメントすることはよくある

相性悪い人のマネジメントをしたくない

「マネジメント経験しました」と語れる実績より優秀な人と働ければその人をマネジメントする必要がない

最も良いマネジメントはマネジメントしないこと

いかに仲間を上手に指揮して動かすかではなくいかにマネジメントしなくていい環境を作るかに注力すべき

■ 9. 意思決定と契約継続

意思決定について:

関わりにくく社員の人ほど重要な人が集まるMTGには突っ込まれない

心血注ぎたいプロダクトに出会ったときに社員になればいい

意思決定に関わりたいなら個人開発すればいい

個人開発をした経験は案件で関わったプロダクトより自身を持って技術選定やこだわりポイントを語れる

ある種の営業力強化になる

契約継続について:

すぐ切られるかは人による

6年以上同じ現場にいる人もいれば1ヶ月持たず即契約終了される人もいる

雇用形態的に切りやすいのは事実だが働きやすくチームにプラスになるメンバーを予算の都合がない限り簡単には切らない

切られてしまうならそれはあなたの目利きが悪かった

この世は等価交換でギブとテイクがマッチする会社を探すべき

■ 10. フリーランスの推奨と戦略

20代から30代前半にこそフリーランスを一度くらいは経験するべき

早期に複数社の現場経験ができることで多種多様な現場のコードを見ることができる

コードリーディングがエンジニアにとって一番大事で自分のコードや設計の多様性を広げることに繋がる

「3年で1社」と「3社を1年ずつ」では後者の方がエンジニアとしての成長を実感するという経験則

労働基準法に守られない立場で数年ワーカホリックに働くという経験をしたからこそ同年代よりは少しいい生活ができている

スキルフルになってからでないとフリーランスになるのは怖いでは既に今のAIトレンドの時代では遅いこともある

雇用形態にかかわらず自分のやりたいプロダクト単位で仕事を選べる力をつければ雇用形態は二の次

フリーランスになったらできればエージェントを使わずに直契約できる会社を探すという経験もしたほうがいい

エージェントの問題点:

企業の手数料が35%からと高額

フロントの営業マンの技術理解力はエンジニアほど高くない

要望を言ってもマッチする案件が来る可能性は自分で探すより低い

エージェントガチャもある

エージェントのフォローがなくても案件を獲得できるという成功体験はAIによるジュニアからミドルエンジニア供給過多問題を乗り越えるために必要かもしれない

中間マージンも減ってお互いWin-Win

■ 11. まとめ

チャンスはあり参画する案件とあなたの能力次第

フリーランスは本来先行して身につけるべき能力は営業力

あなたの単価は任されるチャンスの範囲

雇用形態関係なく「人としての相性」がまず大事

エージェント使わずに直契約取れるかチャレンジ

MEMO:

個人事業主が受け身でいちゃダメよねという話である

(2026/01/21)

なぜ、IT業界"にわか"層は「Web系がSIerに比べて技術的に優位」という幻想を抱くのか？

なぜ、IT業界"にわか"層は「Web系がSIerに比べて技術的に優位」という幻想を抱くのか？

要約:

■ 1. 議論の構造

IT業界においてWeb系とSIerを比較する議論は長年繰り返されている

多くは技術的優劣という形で語られている

議論の中心は技術そのものではなく認知の歪み

ITのにわか層においてWeb系は技術的に優位でSIerは劣位であるという単純化された幻想が強固に信じられている

議論の対象は技術文化ではなく人事文化とマネジメント構造そしてそれを誤認する人間側の認知メカニズム

■ 2. 技術は個人にしか宿らないという前提の欠落

技術は組織や業界に自動的に蓄積されるものではない

個人の思考と試行錯誤の結果として身につくもの

この前提が抜け落ちた瞬間「場所に行けば技術が身につく」という誤解が発生

Web系というラベルがあたかも技術力を付与する魔法の環境であるかのように語られる

実際には考え続けた人だけが技術を獲得し考えない人はどこにいても何も残らない

技術は人に宿る

環境は確率を変えるだけ

自動付与は存在しない

この三点を無視した議論はすべて幻想

■ 3. 人事文化やマネジメント文化との混同

Web系とSIerの違いは技術文化ではなく人事評価の軸とマネジメントの設計思想

Web系の特徴:

アウトプットが短い周期で可視化される

個人の成果が評価に直結しやすい構造

SIerの特徴:

分業と調整が前提

説明責任や役割遂行が評価の中心

にわか層の誤認:

評価軸の違いをそのまま技術力の差と誤認

評価構造、役割設計、責任分散というマネジメント上の差異が技術文化の差として誤変換されている

■ 4. 可視性バイアスと生存バイアス

Web系の可視性:

成果物が外部に公開されやすい

GitHubや技術ブログなどを通じて技術的アウトプットが目に入りやすい環境

可視性の高さが「Web系には優秀な技術者が多い」という印象を強化

実態との乖離:

単なる観測可能性の問題であり実態の分布とは一致しない

技術的に尖った人が目立ちやすくそうでない人が視界から消えやすいという偏り

認知バイアスの構造:

可視性、選択的観測、生存者偏重という認知バイアスが幻想を補強

■ 5. 経済合理性と人材分布の現実

人材分布の決定要因:

人材の分布は理想論ではなく経済条件によって決定

高い給与、安定した雇用、大規模な採用母集団を維持できるのは大企業

日本の現実:

大企業の多くがSIer側に存在

優秀な人材の絶対数はSIerに多く集まる

Web系の限界:

密度では優れて見えても人数と資金力の差を覆すことはできない

現実要因:

給料水準、会社規模、知名度、母集団サイズが最終的な人材分布を規定

■ 6. SIerが人をだめにする構造とその誤解

SIerの構造的問題:

SIerという組織が多くの人をだめにしてしまうのは事実

技術文化が劣っているからではない

技術を深く考えなくても生存できるレーンを大量に用意しているから

構造の特徴:

人を選別しない代わりに人を鍛えもしない

成長しない人が大量に残る

外部からは「技術的に弱い集団」に見える

誤解の構造:

構造的温存、非選別性、成長不要ルートという特徴が文化論として誤って語られている

■ 7. にわか層が幻想を欲しがる心理

心理的動機:

裏技への期待と自己正当化の欲求

努力や思考を積み重ねるよりも正しい場所に行けば解決するという物語は非常に魅力的

自身の立場を誇るあるいは嘆くためのポジショントークとして文化論は便利

議論の性質:

真偽は重要ではなく感情の整合性が優先される

幻想を必要とする動機:

裏技願望、責任転嫁、自己物語化

■ 8. 「技術文化」という幻想上の言葉

本来の意味:

技術文化という言葉は本来思考の深さや問題解決姿勢を指すはず

現実の使われ方:

単なる業界ラベルや雰囲気の話に矮小化されている

Web系という言葉に付与される先進性のイメージが技術文化と短絡的に結びつけられる

問題点:

概念の乱用であり議論の精度を著しく下げる

概念混同、ラベル依存、定義不在が誤った理解を固定化させている

■ 9. まとめ

ITのにわか者がWeb系をSIerより技術的に優位だと信じる理由は技術の問題ではない

原因の構造:

個人要因を無視

評価構造を誤認

認知バイアスに流される

経済合理性を見落とした結果

SIerの実態:

多くの人をだめにする構造を持っている

それは所属する人間の技術の低さを意味しない

Web系の実態:

強く見えるのは密度と可視性の問題

分布全体を見ればどっこいどっこいに収束

根本的な真実:

技術は個人に宿る

人は金と規模に集まる

この二点を直視しない限りこの幻想は繰り返され続ける

(2026/01/21)

I/Oの負荷分散の話。書き込み側の負荷分散。DB1台のノードで書き込みがサチるなら、2台→4台→8台...

I/Oの負荷分散の話。

書き込み側の負荷分散。

DB1台のノードで書き込みがサチるなら、2台→4台→8台とノードを増やしてデータを書き分ける（シャーディング）。

読み込み側の負荷分散。

同じデータを読みたいクライアントが多いなら、そのデータを別のDBノードにコピーして配って読ませる（リプリケーション）。

RDBでやるなら、Writer : Read Replica = 1 : N のクラスタを複数台用意する構成になる。ただし、データのヒントに基づいてどの Writer を選ぶかは開発者の責任。当然、クラスタをまたいだ SELECT JOIN もできない。ソシャゲは基本これ。

クラスタが増えたときのリハッシュも「気合いで頑張れ」になる。運用負荷はかなり高い。体制があれば別にこれでもいいけどね。

まぁ、これはスタートアップではマジで無理っす、って話になることが多いので…… 書き込みも読み込みもそれなりあるなら、前段に DynamoDBなどを置いてCDCを介して、後段の DB クラスタにゆっくり書く構成にすることが多い。

そう、これはほぼ CQRS / Event Sourcing のことなんだよな。書き込みのシャーディングは DynamoDB が自動でやってくれるし、めちゃくちゃ安定的に捌ける。

@j5ik2o

(2026/01/21)

jQuery 4.0正式版が公開。10年振りのメジャーバージョンアップ。IE10以前がサポート外、XSS防止など

jQuery 4.0正式版が公開。10年振りのメジャーバージョンアップ。IE10以前がサポート外、XSS防止など－ Publickey

jQuery開発チームは、10年振りのメジャーバージョンアップとなる「JQuery 4.0」正式版のリリースを発表しました。

ちなみに2026年1月は、最初のバージョンのjQueryが2006年1月にはじめて公開されてからちょうど20周年に当たります。

MEMO:

長生きだ

(2026/01/20)

OOP はくそ，DDD はムズい，GoF は古い，Next.js はでかい，React は難しい，仮想 DOM はクソ...

OOP はくそ，DDD はムズい，GoF は古い，Next.js はでかい，React は難しい，仮想 DOM はクソ，静的型付けじゃない言語はクソ，TS の型は弱い，SPA が良い，every/some の単位元，IEEE 754 の不可解な計算に驚き，OSS は儲からない，ならお前がやれは意味無い，はてブコメントはクソ，休日に勉強は必要か，などずっと同じ話しかしてない

@ubugeeei

MEMO:

人間は年を取ると同じ話題を延々ループさせる生き物

(2026/01/20)

AIネイティブ時代のプロダクト設計──なぜ「完璧な仕様」は機能しなくなったのか

AIネイティブ時代のプロダクト設計──なぜ「完璧な仕様」は機能しなくなったのか - Nothing ventured, nothing gained.

要約:

■ 1. AIがプロダクトに与える変化の認識

AIがプロダクトを大きく変えると感じ従来と何が違うのかが気になってきた

投資家として海外を含むスタートアップやプロダクトを見る機会が増える中でAIを前提に設計されたプロダクトには従来とは明らかに異なる成功パターンがあるように感じている

AIが中心となるプロダクトの設計には完璧な仕様を追い求める従来の手法とは異なる新しい姿勢が求められている

プロダクトを完成させるのではなく変化し続ける前提で設計するという姿勢が必要である

■ 2. Cursorの事例とAIネイティブ設計

AIコードエディタとして登場したCursorはVS Codeという巨大な既存プロダクトが存在する市場においてまたたく間に支持を集めた

VS CodeにもGitHub CopilotをはじめとするAIサービスのアドオンを追加することはできAI機能そのものは利用可能だったにもかかわらずである

Cursor以前のアプローチ:

既存のエディタにAIアシスタントを追加するというものだった

これは従来のプロダクト開発の延長線上にある発想である

すでに完成されたプロダクトが存在しそこに新しい機能を付け加えるという考え方である

Cursorのアプローチ:

AIがコアにあることを前提としてゼロからエディタを再設計した

AIは追加された機能ではなくプロダクトの中心的な存在である

リポジトリ全体をセマンティックにインデックス化し複数ファイルにまたがる変更を生成し開発者の意図を理解して自律的に行動する

これはAIが完璧に機能するという前提に立ちワークフロー全体を再構築した結果である

このCursorのアプローチが有効であることはその後GoogleがAntigravityという形で追従したことからも明らかである

■ 3. 決定論から確率論への転換

AIネイティブプロダクトでは従来の仕様設計が限界を迎える理由の整理が必要である

AIを機能として追加するのではなくプロダクトの中心に据えるという設計への転換が起きている

この変化を一言で言えば設計対象が変わったということである

ソフトウェアが決定論的な存在から確率論的な存在へと変わったことによって起きている

従来のプロダクト設計:

振る舞いを固定した完成物を設計する仕事だった

入力と出力の関係を定義し想定される状態やユーザーフローを網羅し意図した通りに動作することを保証する

その前提にあるのはソフトウェアは設計者の意図通りに振る舞うべきだという考え方である

生成AIを中核に据えたプロダクト:

設計する対象は完成物ではなく学習し続ける存在になる

プロダクトはリリースされた時点で完成するのではなく利用される中で振る舞いを変え進化し続けることが前提となる

学習し続ける存在とはどのデータを集めどの文脈でAIに渡しどのフィードバックを次の振る舞いに反映させるかという一連の仕組みを指す

設計対象の変化は単なる機能や実装の差ではない

Cursorが示したのはプロダクト設計における根本的なパラダイムシフトである

従来のプロダクトは完成させて出荷するものだった

生成AIを組み込んだプロダクトはリリース後に学習し続ける生態系として設計される

■ 4. 変わる人間の役割

テックリードやプロダクトマネージャーが何をすればよいのかという問いがある

答えは完璧な仕様を書くことではない

良い方向に学習する構造を設計することそしてプロダクトを進化させる仕組みを整えることである

プロダクトはもはや完成させて出荷するものではない

プロダクトはリリース後に学習し続ける存在である

人間の仕事はこの生態系が健全に進化するための構造を設計することである

プロダクトマネージャーの役割の変化:

従来のプロダクトマネージャーは機能の門番だった

どの機能を作るかどの順番で作るかどのように作るかを決める存在だった

AIネイティブプロダクトを担当するプロダクトマネージャーは学習システムの設計運用責任者である

具体的にはAIモデルそのものを鍛えるのではなくどのデータや文脈を与えるかどのフィードバックを取り込みどの振る舞いを強化抑制するかといった学習が回る構造そのものを設計運用する役割を担う

ここでの学習はモデルの再学習を意味しない

多くのAIネイティブプロダクトは自らモデルを開発していない

モデルを持っている場合でも有料プランの利用ユーザーデータを直接モデル学習に使わないことがほとんどである

それでもプロダクトは使われるほどに振る舞いを変えていく

その違いを生むのはモデルの外側に設計されたデータ文脈履歴フィードバックの構造である

つまりプロンプトなどのAIへの指示方法でありAIに参照させるデータとしてのコンテキストである

技術的にはRAGであったりMCPであったりする

AIネイティブプロダクトでは前提条件が変わる

振る舞いを完全に制御できない以上問われるのは個々の機能ではなく学習がどう回りどう修正されるかという構造そのものである

人間に求められるのは何を作るかを細かく決めることではない

AIがどのように振る舞いを変えていくのかその前提となる構造を設計し方向を調整し続けることである

■ 5. AIネイティブプロダクトにおける学習

人間が設計すべき構造が実際のプロダクトの中でどのように形になっているのかを見る必要がある

AIネイティブなプロダクトにおいて人間がどこに介在し何を設計しているのかという問いがある

AIネイティブエディタの例:

リポジトリ全体がセマンティックにインデックス化されコードは単なるテキストの集合ではなく意味を持つ構造として扱われる

開発者がどのような編集を行ったかどの提案を受け入れどの提案を拒否したかといった利用の痕跡が継続的に蓄積される

重要なのはこれらが単なるログではなく次にAIを使う際の入力文脈として再利用される点である

どの情報を参照させるかどの履歴を重ねるかといった判断は人間が設計した前提に基づいて行われる

ここで起きているのはAIの中身が変わることではない

固定されたモデルはそのままにどの情報を参照させどの履歴を重ねどのフィードバックを次に活かすか

その積み重ねによってプロダクト全体の振る舞いが変わっていく

AIネイティブプロダクトは学習し続ける存在として設計されている

利用のたびに得られるデータが次の振る舞いに影響を与える

モデルを自ら開発しないプロダクトであっても学習する構造を内包することは可能である

この構造をどう設計しどう運用するかこそが人間に委ねられた最も重要な仕事である

超ざっくりとした設計イメージの例:

AIが出した修正提案に対して開発者が採用したか拒否したかをログとして残す

そのログを用いて次回以降の提案時に採用されやすい修正パターンを優先的に提示する

繰り返し拒否される提案パターンについてはルールやプロンプトを調整し出力されにくくする

重要なのは精度の高いアルゴリズムではない

提案から選択から次の提案に反映という学習のループが意図した方向に回るよう設計されているかどうかである

■ 6. データ設計における蓄積から循環への転換

学習し続ける存在をどのように作り上げていけばよいのかという問いがある

鍵となるのはデータである

ただし生成AI時代において問われているのはデータの量ではない

従来のデータの価値:

蓄積にあった

どれだけ多くのデータを集めたかどれだけ詳細な情報を記録したか

データウェアハウスに大量のデータを保存し分析ツールで可視化する

これがいわゆるデータ駆動型の意思決定だった

生成AI時代におけるデータの価値:

循環にある

データは集めただけでは価値を生まない

利用され学習に回されAIの振る舞いを変えその結果として新たなデータが生まれる

この循環が回って初めてデータは資産になる

フィードバックループの設計こそがAIネイティブプロダクトの成否を分ける

AIを導入してもフィードバックを回収せず学習に活かさなければプロダクトは賢くならない

その結果プロダクトは学習する生態系ではなく固定されたツールのままにとどまる

この循環が回り始めたときそれは強力な競争優位性となる

他社が容易に模倣できない独自のデータと学習ループがいわばデータモートとして機能する

生成AI時代においてはソフトウェアそのものの差別化は急速に難しくなっている

AIがコードを書き機能実装の大部分を肩代わりしてくれるようになったことでソフトウェア開発の再現性は飛躍的に高まった

オープンソースモデルや汎用APIの普及も相まって技術的な障壁は大きく下がっている

誰でも一定水準のAI機能を備えたプロダクトを作ることができるようになった

だからこそ差別化の源泉はデータに移る

ただし重要なのは独自のデータを持っているかではない

そのデータを学習に回し改善のループを回し続けられているかどうかである

多くの企業はすでに独自のドメイン知識とデータを持っている

日本企業も例外ではない

問題はそれらが十分に循環していないことである

生成AIを既存業務に部分的に導入するだけではこの循環は生まれない

プロダクトそのものをAIネイティブな前提で再設計する必要がある

新興企業の戦略:

フィードバックループをできるだけ早く回すことである

データの量が少なくても利用と改善の循環を高速に回すことができればAIは急速に賢くなる

AIが賢くなればユーザー体験が向上しユーザーが増える

ユーザーが増えればデータが増える

この好循環がやがてデータモートを形成する

Cursorの成長はそのことを端的に示している

独自データをすでに持っている企業にとってもフィードバックループを早く回すという考え方は同様に重要である

派手な先行事例が出そろうのを待っていては競争優位性は築けない

自社の事業にAIを組み込みAIネイティブなプロダクトへと転換していく

そのための第一歩がデータを蓄積ではなく循環として設計し直すことである

重要なのはフィードバックの量ではなく向きである

誤ったシグナルを回せばプロダクトは高速に劣化する

人間は学習が向かう方向に最低限のガードレールを引く必要がある

フィードバック設計の例:

どの提案を評価対象とするのかどの操作を良いシグナルと見なすのかを最初からすべて自動化しようとしない

初期段階では人間が明示的にこれは良いこれは悪いと判断するポイントを絞り込む

学習が誤った方向に進まないよう制御する

フィードバック設計とはそのための最小限の安全装置である

■ 7. AIネイティブプロダクトはAIネイティブな組織でしか作れない

この話は技術の話だけではない

学習システムは個人の工夫や一部のチームの努力だけでは成立しない

AIネイティブなプロダクトはAIネイティブな人と組織でなければ作れない

見た聞いた調べた範囲ではプロダクトに関わる人間がAIを理解していない組織でAIネイティブなプロダクトがうまくいった例はない

AIネイティブ組織の特徴:

会議の中でこの挙動はモデルの限界なのかそれともコンテキストやデータ設計の問題なのかを議論できるかどうか

KPIについても機能が予定通り完成したかではなく学習のループが回り振る舞いが改善したかを問う指標に置き換えられているか

こうした具体的な問いが日常的に交わされているかどうかがAIネイティブ組織かどうかの分かれ目になる

論文を読めという話ではない

実際に使い自分の手で試し失敗し挙動の癖を体感しているかどうかが重要である

AIをブラックボックスとして扱ったままでは学習する構造を設計することはできない

作る経験も欠かせない

モデルを自作する必要はないがプロンプトやコンテキストデータの与え方ひとつで振る舞いが大きく変わることを身体感覚として理解している必要がある

AIネイティブプロダクトとはAIを前提に思考し設計し試行錯誤できる人間によってのみ生み出される

意思決定の速さが何より重要である:

生成AIの進化は極めて速い

半年待てば状況は一変する

このスピードに追いつくためには完璧な検討や合意形成を待っている余裕はない

試し学び修正するそのサイクルを回し続けられるアジリティの高い人と組織でなければAIネイティブな競争には参加できない

これは組織の規模の問題ではない

大企業であろうとスタートアップであろうと条件は同じである

AIネイティブプロダクトを作れるかどうかはAIネイティブな人と組織になれているかどうかで決まる

■ 8. 結論

プロダクト設計とはもはや機能や画面を設計する仕事ではない

変化し続ける前提に立ち学習が回り続ける構造とそれを回し続けられる人と組織を設計する仕事である

あなたのチームはどこまで機能の設計から学習する構造と組織の設計へと軸足を移せているだろうかという問いかけがある

(2026/01/20)

誰も思い出さないが、東大入試を解くAIの研究開発に失敗した挙げ句、適当に哲学的にでっちあげた...

誰も思い出さないが、東大入試を解くAIの研究開発に失敗した挙げ句、適当に哲学的にでっちあげた人間の教育論を振りかざして研究失敗を煙に巻いて、「私は研究に失敗しないんですよ」とうそぶいていた例のあの研究者、元気かな。

しかし、Geminiが共テを制覇するレベルになると、果たしてこの共テとかいう「茶番」はいつまで続けられるのか。生徒側の方がモチベがなくなるだろうに

@alfredplpl

@EzoeRyou

MEMO:

新井紀子先生、未だに読解力が云々みたいな商売しているそうで哀しくなってくるな

世界のすごいプログラマは個人ホームページでロングテールに発信をしていることが多い。これは...

世界のすごいプログラマは個人ホームページでロングテールに発信をしていることが多い。これはユーザー投稿タイプのサービスの寿命よりも自分のキャリアの方が確実に長くなるためです。（世界的にdevtoやmediamの没落が例）

個人的にはこのトレンドをめちゃくちゃ支持しています。

うほうほ！（鳴き声）

@labelmake

MEMO:

WEBサービスの寿命は然程長くなく、運営が稼げなくなるとサクッとサ終されてしまう
それ自体は仕方ないことだが、そんなところに自分のデータを預けるのは流石に不安なので最初からセルフホストでいくのが合理的な判断

(2026/01/19)

とりあえずApproveはもうやめよう

とりあえずApproveはもうやめよう #GitHub - Qiita

要約:

■ 1. 問題提起と背景

コードレビューにおいて素通しでApproveしてしまう状況が多く発生している

思考停止でのApprove実施はレビュープロセスの形骸化を招く

主な要因として理解不足・権威への盲従・時間不足の3つが存在する

■ 2. ケース別対処法

正直理解できない場合:

スキルセット不足による理解不能:

素直に質問コメントを残す

勉強不足を恥じる必要はない

質問により自身の知識増加と実装者の見直し機会創出という2つのメリットが得られる

シニアエンジニアのコメントを観察し新たな視点を取り入れる

PRの目的理解不能:

実装者の説明不足である可能性が高い

チケットリンクや背景説明の追記を依頼し差し戻す

変更量過多による本質的変更の理解不能:

PR分割を指摘することで適切なレビューを実現する

無理に全部読まずPR粒度の改善を求める

自分より知識がある人が実装している場合:

権威バイアスは即座に捨てるべきである

凄腕エンジニアでもタイポや削除漏れは発生する

高度すぎる複雑さは運用負債となる可能性がある

難しいと感じた場合は可読性向上を提案する

レビュー時間を取ることができない場合:

コードレビューは品質担保のための正式な業務である

コンテキストスイッチコスト削減のためレビュー時間を固定化する

急ぎでなければ朝一番での実施が効果的である

■ 3. レビュー依頼側の心がけ

タスク・実装の細分化:

PR変更行数の最小化がレビュアーの心理的ハードル低下につながる

小さなPR複数回の方がトータルマージ時間は短縮される

機能追加とリファクタリングの分離など工夫が重要である

自己レビューの徹底:

Files changedタブでの変更内容確認によりデバッグコード残存等を発見できる

実装時の判断理由をコメントとして事前記載する

レビュアーの納得感向上と前提勘違いの早期発見につながる

Descriptionに背景・目的・テスト結果等の証跡を明記する

実装者としての責任意識:

一番理解しているのは実装している自分であるという矜持を持つ

レビュアー頼みではなく自信を持ってPRを出す

実装の端々に責任感の有無が現れる

■ 4. 現代のレビュー環境

ツール活用による負担軽減:

LinterのCI実行による文法チェック自動化

PolicyAgentによる組織ルール遵守の自動化

AIレビュー導入によるコスト削減

ツールでコスト低減可能だが人間レビューで担保できる品質は必ず存在する

AI進歩に伴う課題:

大規模PR増加による確認負荷上昇

意図不明のままPR提出されるケース発生

AI盲信による品質低下リスク

人間レビュー対象と自動チェック対象の分離が必要

実装前の設計・方針レビューの重要性増大

思考履歴の言語化と記録が重要

■ 5. 結論

わからないことを質問するのは恥ではない

間違いを指摘するのは失礼ではない

思考停止Approveを止め一言でもコメントを入れることから開始する

小さな一歩が自身とチームの成長につながる

(2026/01/19)

AIとDB設計を考えてみた(後編) : トランザクションの整合性はDynamoDBに任せたい

AIとDB設計を考えてみた(後編) : トランザクションの整合性はDynamoDBに任せたい

要約:

■ 1. マスタ管理の拡張性

疑問の提起:

シングルテーブル設計はスケールが容易なDynamoDBなどのNoSQLで定番な方法でRDBであるPostgreSQLで耐えられるのだろうか

マスタが巨大化すると詰むのではという疑問

結論:

特に問題はない

理由:

RDBはスケールしないと言っても数十万件くらいなら余裕で捌ける

前編で説明した全マスタをまとめて取得するのはどこかで限界が来るけど取得時にMetadataによるフィルタリングをすれば適切に絞り込みが可能

運用が続いて規模が大きくなったら無理が出るのは仕方がない問題が出たときにリファクタすれば良い

そもそも肥大化するデータはもはやマスタとして扱うのは正しくなくトランザクションとして扱うべき

大抵なんとかなるしなんとかならなかったらトランザクションに寄せればいいよね

■ 2. 普通のリレーションの問題点

通常のアプローチ:

トランザクション用のテーブルを作る

マスタのcodeを外部キーに持たせる

JOINしてトランザクションと紐づくマスタをセットで取得する

問題点:

マスタがトランザクションに拘束されることになる

前編で実現した柔軟なマスタの変更が封印されてしまう

考え直す必要がある

■ 3. トランザクションをマスタから自律させる

問題の本質:

マスタが変更されると古いマスタ情報が消えてしまうのが問題

解決策:

トランザクションの中に必要なマスタの情報をコピーしてまとめて保存する

この単純で分かりやすい力技はとても効果的

マスタがどれだけ破壊的に変更や削除されてもトランザクションデータは当時の姿のままで生き残り続ける

手法の名称:

こういった手法は一般的にスナップショット・パターンと呼ばれている

■ 4. DynamoDBの採用理由

PostgreSQLでの限界:

PoCなどの大きくスケールしないケースであればトランザクションもマスタと同じようにJSONBでPostgreSQLの1つのテーブルに保存しても問題ないかもしれない

仮にもトランザクションなので一般的なアプリであれば使っているうちにデータは増え続ける

しかもマスタのデータをトランザクションにコピーするのでデータ量も増える

スケールできるように考えるべき

DynamoDB採用の利点:

スケーラビリティ: トランザクションデータは増え続けPostgreSQLでも数十万件程度なら問題ないが数百万件や数千万件となるとシンプルに扱うことが困難でDynamoDBなら自動的にスケールするためこの心配がない

書き込みパフォーマンス: トランザクションは頻繁に書き込まれDynamoDBであればキーバリューストアとして高速な書き込みに最適化されている

アクセスパターンが明確: トランザクションは通常特定のキーで検索されDynamoDBはアクセスパターンが事前に定義できる場合に最高のパフォーマンスを発揮しマスタのような自由な検索は不要

使い分け:

検索性が必要なマスタ管理ではPostgreSQLを採用

スケーラビリティが重要なトランザクションではDynamoDBがよさそう

■ 5. ルーズなSQLと厳格なNoSQL

PostgreSQLでのマスタ:

スキーマレスなJSONBで何でも受け入れる

構造の変更が自由

整合性チェックはアプリ側に任せる

ルーズで柔軟

DynamoDBでのトランザクション:

スナップショット・パターンで当時の状態を厳格に保存

一度書き込んだら変更しないでイミュータブル

データの整合性は書き込み時点で確定

厳格で不変

設計思想:

マスタは変わるものだから変更に強い柔軟な設計にする

トランザクションは変わらないものだから厳格に保存して整合性を保つ

一見しただけだとRDBとNoSQLに求めるものが逆転しているように見えるかもしれないがデータの性質に合わせてDBの使い方を考えればこの設計も自然に見えてくる

■ 6. 正規化についての考察

正規化を避けてきた理由:

正規化や非正規化に囚われずにゼロベースで考えデータをありのままに扱いたかった為

正規化の目的の歴史:

正規化理論が確立された50年前の状況を振り返る

ストレージが高価だったためコストの観点からデータの冗長性排除が必須だった

更新処理が重かったため更新回数を最小限にする設計が必須だった

トランザクション処理が複雑だったため更新箇所を1箇所に集約する必要があった

つまり正規化の目的はデータの冗長性排除や不整合の防止というよりも限られたリソースの中で更新処理を効率的に行うことにあった

現代の環境:

ストレージコストが劇的に低下したためコスト観点では冗長性はある程度許容できる

読み取り速度が物理的に向上したためJOINによる複雑な結合よりも冗長でもシンプルな構造の方が速い

クラウドを活用すればスケールアウトも容易になったため正規化による更新箇所の集約よりもスケーラビリティで対応できる

ビジネスのスピードが加速したため厳密性よりも柔軟性が重要

制約の変化:

2026年現在のDB設計は50年前と比べて制約の性質が根本的に変わった

正規化が前提としていた1970年代の制約から解放され新たな制約である開発スピードが支配的になった現代ではデータの性質に応じて正規化しない選択肢も合理的

重要な考え方:

新規システム開発では正規化しないほうがいいという単純な話ではない

RDBだから正規化でもモダンだから正規しないでもなくデータの性質や規模や更新頻度や一貫性の要件や変更速度の要求やチームの状況を考えたとき何が最適かを考えることがモダンな設計の本質

■ 7. まとめ

エクセルでマスタ管理をできる程度のアプリのDB設計のポイント:

マスタ管理はPostgreSQLとシングルテーブルとJSONBで小規模で変更が多いデータで検索の柔軟性が必要でスキーマレスで構造の変更に強い

トランザクションはDynamoDBとスナップショット・パターンで大規模で書き込みが多いデータでアクセスパターンが明確でマスタのデータを含めることで整合性を保証

設計の特徴:

DBが原因でアプリの拡張性が損なわれるということを避けるDB設計をGeminiくんに考えてもらった

その結果マスタは柔軟に作る為にPostgreSQLを使いトランザクションは整合性を確保する為にDynamoDBを使うという直感とは異なる考え方でありながらマスタはPostgresqlでトランザクションはDynamoDBというとても普通なDB使い分けというちょっと面白い設計になった

(2026/01/19)

AIとDB設計を考えてみた(前編) : マスタ管理はシングルテーブル設計+PostgreSQLがいいかもしれない

AIとDB設計を考えてみた(前編) : マスタ管理はシングルテーブル設計+PostgreSQLがいいかもしれない

要約:

■ 1. はじめにと背景

DB設計への姿勢:

個人的にDBというものに対してあまり興味がない

基本的にDB設計は詳しい人に任せたいと思っている

PoCやスモールスタートでの課題:

ある程度以上の大きめのシステムならそれで良いがPoCやスモールスタートの場合だとDBだけを切り離せるほど人的リソースを割けないことも多い

外部にDBを丸投げしたことにより知見がなくなりDB起因でアプリの機能追加や変更が困難になるといった事態も避けたい

記事の目的:

なるべくアプリ開発の邪魔にならないDB設計を考えておきたいとGeminiくん相手に壁打ちしてみた

硬い設計をするのが一般的なマスタ管理に柔軟性の高いシングルテーブル設計を採用しNoSQLの定石であるシングルテーブル設計をPostgreSQLのJSONB機能で実現するアプローチが登場した

■ 2. モダンなアプリ開発に求められるDB設計

対象システムの特徴:

柔軟でモダンなシステムで規模は大きくないがモダンなシステムをなるべく柔軟に作ることを考える

取り敢えずマスタを対象に考えDB設計ではよくマスタとトランザクションに分けて考えるのでまずはマスタについて考える

シンプルな構造を扱うユーザーの意見を素早く取り入れたいのでエクセルで作ったマスタ管理台帳を簡単に取り込めることを前提にする

人間が全体を管理できる程度にシンプルなマスタということ

自由度は高く項目の増減や変更の自由度は高くしたいモダンなアプリは変更に強いことが求められる

従来のDB設計との違い:

従来は多くのシステムのデータベースには巨大なデータを扱える堅牢な設計を求められること多かった

今は誰にでも気軽にアプリを開発してデプロイして公開できる時代

モダンな開発では規模は小さいけど柔軟性が求められる事が多く従来のDB設計では上手くいかない事もある

アプローチ:

従来のDB設計は一旦横においてエクセルで実施したマスタ定義をなるべくそのままシステム化することを考えた

■ 3. GeminiくんのDB設計提案

設計の概要:

マスタの定義をすべて一つのテーブルに集約する

1つのテーブルに全ての項目を放り込むという大胆な設計を提案してきた

よく考えると実際にこれが理にかなっている

テーブル構成:

master_type: カテゴリやステータスなどの区分でエクセルのシート名に相当

code: 一意のキー

name: 表示名で実質的なValue

category_path: 文字列による階層表現で例は/家電/冷蔵庫

metadata: エクセルの残りの列をすべてここに放り込む

■ 4. シンプル構成の利点

従来設計の問題点:

PoCやスモールスタートにおいて従来の1エンティティ＝1テーブルという硬い設計は柔軟な開発の足枷になる

エクセルの管理台帳に1つ列を足したいだけなのにDBのマイグレーションに怯え影響調査に時間を費やすことになる

シングルテーブル設計の利点:

テーブルを細かく分けずあらゆるマスタを一つの大きな器に放り込むシングルテーブル設計を選択肢に加える

これにより構造を固定せずビジネスの変化をそのまま受け止める構成を考えることが出来る

比喩:

正規化重視の設計は川の流れをガチガチに固める堤防を作るのに対してシングルテーブル設計は広い遊水地を用意するといったところ

■ 5. PostgreSQLでの実装

NoSQLとの比較:

シングルテーブルと聞くとDynamoDBのようなNoSQLを連想する方が多い

実際クエリの効率化のためにデータを1つのテーブルに集約する手法はNoSQLの定石

DynamoDBではパーティションキーやソートキーを抽象的に定義することで後からアプリ側でデータを解釈する柔軟性を持たせることが一般的

DynamoDBの課題:

直面するのは検索の壁

DynamoDBは一部の項目にしかインデックスを作れないしそれを補うGSIなどの機能はとても複雑

今回は対象がマスタ管理なので検索の柔軟性はとても重要

PostgreSQL採用の理由:

シングルテーブル設計によるマスタ管理を検索能力が高いPostgreSQLで実施することを考える

PostgreSQLの優位性:

アドホックな検索への対応力: NoSQLは事前に定義したアクセスパターンには強いが想定外の条件での検索や集計は苦手でPostgreSQLはSQLの強力な表現力でいつでも自由な切り口でデータを抽出できる

JSONBと高度なインデックス: PostgreSQLのJSONB型はスキーマレスな柔軟性を提供し内部フィールドに対してGINやB-Treeインデックスを後から自由に追加可能

複雑な階層やパス検索: /食品/生鮮/野菜のようなパスに基づく検索はPostgreSQLのLIKE検索やltree型を使えばインデックスを効かせつつ爆速実行可能でNoSQLのキー設計で解決するよりも遥かに直感的で強力

PostgreSQLの位置づけ:

PostgreSQLをただのRDBではなく強力な検索エンジンを備えたドキュメント・ストアとして使うことでスマートなマスタ定義の管理が実現できる

■ 6. マスタのデータ取得方法

懸念への対応:

テーブルが1つでリレーションもないならアプリ側で扱うときに不便じゃないかという懸念がある

実はそんなことはない

アプローチ:

DB側でJOINして整えるのではなくDB側で構造化して1発で返すというアプローチを取る

PostgreSQLの関数活用:

PostgreSQLにはjson_aggやjsonb_build_objectといった抽出結果をまるごと構造化する強力な関数がある

これらを使えば複数テーブルを何度も叩く代わりに必要なマスタを1つのJSONオブジェクトとしてアプリに返すことができる

アプリ側はそれを受け取り起動時や定期的なリフレッシュのタイミングでメモリ上に展開してしまえばいい

メリット:

アプリ起動時に全ロード

メモリ上で高速検索

DB通信のオーバーヘッドなし

データ量への懸念の解消:

マスターのデータを全て渡すのは無駄じゃないのかという懸念がある

しかし今回はあくまでエクセルで人間が管理できるマスタであることが前提

今時のコンピューターやネットワークなら数千件や数万件程度のデータは一瞬で処理出来る

むしろ通信が1回で完結するので効率よくデータを処理することが可能

設計思想:

DBに知能を持たせるのをやめアプリが使いやすい塊としてデータを扱う

こうすることでリレーションに頼らないスマートなマスタ取得が実現できる

■ 7. モダン開発との関係

従来のアプリ開発の問題:

特にマスタに関しては整合性を徹底するためにDBの型や制約をガチガチに固めることが多い

しかし素早い開発や柔軟な仕様変更を求められるモダンな開発ではこの設計が足枷になってしまうことが多々ある

DBの位置づけの変更:

DBは器であってフィルターではない

JSONBで何でも受け入れる柔軟な土台に徹しデータの解釈や不整合の吸収は変更が容易なアプリ側で対応することも考えるべき

健全な関係性:

アプリが賢く立ち回ることで土台であるDBを自由にする

この関係性こそがモダンな開発における健全なアプリとDBの関係

■ 8. おわりと次回予告

提案の効果:

PostgreSQLを使ってマスタ定義を自由にすることで柔軟なアプリ開発を爆速で実現出来る

残された課題:

そんなルーズなマスタではトランザクションの整合性が取れないのではという疑問が出るのは当然

小規模アプリと言っているけど将来的にマスタが巨大化すると詰むよねという懸念がある

次回予告:

後編ではこのルーズなPostgresqlを支える整合性を担保するDynamoDBについて語る

(2026/01/19)

Dockhand

Dockhand は、リアルタイムコンテナ管理、Docker Compose スタックのオーケストレーション、そしてマルチ環境サポートを提供する、最新の効率的な Docker 管理アプリケーションです。これらすべてを軽量で安全、そしてプライバシーを重視したパッケージにまとめています。

機能:

コンテナ管理：コンテナをリアルタイムで起動、停止、再起動、監視

Compose スタック：Docker Compose デプロイメント用のビジュアルエディター

Git 統合：Webhook と自動同期を使用して、Git リポジトリからスタックをデプロイ

マルチ環境：ローカルおよびリモートの Docker ホストを管理

ターミナルとログ：インタラクティブなシェルアクセスとリアルタイムのログストリーミング

ファイルブラウザ：コンテナからのファイルの参照、アップロード、ダウンロード

認証：OIDC 経由の SSO、ローカルユーザー、およびオプションの RBAC（エンタープライズ）

MEMO:

VPSでコンテナ管理するのに便利そう

(2026/01/18)

プログラミングが好きな人は、もうIT業界に来るな。

プログラミングが好きな人は、もうIT業界に来るな。｜いぐぞー@書籍執筆中 ✈️ 旅するプログラマー

要約:

■ 1. IT業界における生成AI登場前の状況

コミュニケーションが苦手な人材にとっての楽園的環境:

論理的に仕様を詰め正確なコードを書けば多少無愛想でも職人として尊重された

饒舌さや気の利いたお世辞は不要であった

技術力だけで周囲を驚かせることが可能であった

プログラミング愛好家のアイデンティティ:

自分の指先から生まれるロジックで問題を解決することが誇りであった

得意なことで収入を得られる環境が存在していた

■ 2. 生成AIによる業務内容の変化

コーディング作業の減少:

エディタに向かってコードを書く時間が激減した

AIが生成した80点のコードの検品係が主な役割となった

創造する喜びが失われた

プログラミング能力の価値暴落:

プログラミング未経験の業務担当者がChatGPTを使い簡単なツールを自作できるようになった

現場のドメイン知識を持つ人材がAIを手足として使えるようになった

プログラマーという通訳の役割が不要となった

■ 3. 求められるスキルの変化

コーディングからコミュニケーションへの転換:

要件定義や業務整理やステークホルダーとの調整が増加した

何を作るべきかやなぜ作るのかを言語化し整理する能力が求められるようになった

評価軸の変化:

美しいコードを書く能力から生成AIを使いこなし素早くアウトプットを出す能力へ変化した

技術力一本での評価という爽快感が消失した

■ 4. IT業界を目指す人へのメッセージ

推奨しない動機:

プログラミングが好きで人と話すのが苦手という理由だけでは生き残れない

プログラミングそのものはAIがより上手に実行するようになる

推奨する動機:

作りたいサービスがある人材

解決したい社会課題がある人材

アイデアで世界を良くしたい人材

技術の民主化:

高度なコーディングスキルという壁が消失した

情熱とアイデアとAIへの指示力があれば誰でもクリエイターになれる

静寂とコードの職人芸の世界から誰もがアイデアを形にできる創造的な世界への移行

MEMO:

偏屈な職人肌プログラマというロールモデルは消滅して久しい
技術オタクであることがマイナスになることはないが、技術オタクだけでは生き残れなくなる
2000年頃はDBやWEBサーバの設定を暗記していることが価値に繋がったりもしたが、今ではそんなものAIに聞けばよいので価値としては認められなくなった
人間DBとしてのオタクには価値が無くなってしまったと言うべきか

(2026/01/18)

集約にこだわりすぎないDDD：Laravelで実践するアクション単位設計

集約にこだわりすぎないDDD：Laravelで実践するアクション単位設計

要約:

■ 1. DDDにおける集約とファットリポジトリ化の問題

集約の重要性:

関連するエンティティと値オブジェクトを1つの単位として扱う概念

ビジネスルールの整合性を保つための境界を定義する

データの一貫性を保証する役割を果たす

ファットリポジトリ化の問題:

1つのリポジトリに多くのメソッドが集約される

変更影響範囲の拡大により他メソッドへの影響考慮が必要になる

テストの複雑化が発生する

責務の曖昧化が生じる

チーム開発での競合が増加する

アクション単位設計の設計思想:

各アクションに対して専用のプレゼンターとユースケースとリポジトリを用意する

各アクションが独立し変更影響が局所化される

DDDの層構造とADRパターンを組み合わせる

■ 2. ADRパターンの概要

ADRパターンの定義:

Paul M. Jonesによって提唱されたMVCパターンの代替アーキテクチャ

HTTPリクエストの処理を3つの明確なコンポーネントに分離する

3つのコンポーネント:

Action: HTTPリクエストを処理するエントリーポイント

Domain: ビジネスロジックとドメインモデル

Responder: レスポンスデータの構築とHTTPレスポンスの生成

MVCパターンとの違い:

MVCではControllerがModelとViewの両方に依存し責務が曖昧になる

ADRではActionとDomainとResponderの役割が明確に分離される

メリット:

各コンポーネントの責務が明確になる

各コンポーネントを独立してテストできる

ビジネスロジックがフレームワークから独立する

Domain層がプレゼンテーション層に依存しない

DDDとの組み合わせ:

ActionをPresentation層のControllerにマッピングする

DomainをDomain層にマッピングする

ResponderをPresentation層のPresenterにマッピングする

■ 3. 従来の設計パターンの問題点

集約にこだわった設計の特徴:

1つのリポジトリに複数の操作を集約する

OrderRepositoryにcreateやupdateやcancelなど多数のメソッドが存在する

問題点の詳細:

変更影響範囲の拡大: 1つのメソッド変更時に他メソッドへの影響考慮が必要

テストの複雑化: 各メソッドのテスト時に他メソッドとの相互作用を考慮する必要がある

責務の曖昧化: データアクセスだけでなくビジネスロジックも含まれる可能性がある

チーム開発での競合: Gitのマージコンフリクトが発生しやすくなる

■ 4. 提案する設計パターン

アクション単位設計の構成:

1プレゼンター: 各アクション専用のプレゼンター

1ユースケース: 各アクション専用のユースケース

1リポジトリ: 各アクション専用のリポジトリ

各アクションをパーティションで区切るイメージ

依存性逆転の法則:

Application層にインターフェース定義を配置する

Presentation層とInfrastructure層はApplication層のインターフェースに依存する

Application層が外部層に依存しない構造を実現する

ADRパターンとの対応:

Action: OrderControllerとしてHTTPリクエストの受付とルーティングを担当

Domain: Domain/Entities/Orderとしてビジネスルールとエンティティを担当

Responder: CreateOrderPresenterとしてレスポンスデータの構築を担当

ARC パターン:

DDDの構造設計とADRパターンを融合させた設計

Action-Responder Cleanパターンと呼称する

■ 5. Laravel実装例

ディレクトリ構造:

Application層: インターフェース定義とユースケース

Domain層: エンティティ

Infrastructure層: リポジトリ実装

Presentation層: プレゼンターとリクエストとレスポンス

Http層: コントローラー

各レイヤーの役割:

リクエストDTO: リクエストデータを保持する

レスポンスDTO: レスポンスデータを保持する

プレゼンターインターフェース: アクション単位で独立したインターフェースを定義

プレゼンター実装: リクエストとレスポンスの保持と取得

リポジトリインターフェース: データアクセスの抽象化

リポジトリ実装: Eloquentを使用したデータアクセス

ユースケース: ビジネスロジックの実装

コントローラー: HTTPリクエストの受付とバリデーション

依存性逆転の法則のメリット:

ビジネスロジックの独立性により外部の実装詳細に依存しない

実装の交換が容易でインターフェースが変わらない限り影響がない

モックやスタブを使ったテストが可能

フレームワークからの独立性により移行時もビジネスロジックを再利用可能

Responderの責務に関する設計選択:

現在のアプローチ: PresenterがCreateOrderResponseを返しコントローラーがJsonResponseを構築する

代替アプローチ: Presenterが直接JsonResponseを返す

現在のアプローチはフレームワークからの独立性を重視する

代替アプローチはADRパターンの徹底を重視する

■ 6. アクション単位設計のメリット

独立性:

各アクションが独立し変更影響が局所化される

注文作成のロジック変更時に注文キャンセルのロジックに影響を与えない

テスタビリティ:

モックが容易で単体テストが書きやすい

各コンポーネントを独立してテストできる

保守性:

機能追加や変更時の影響範囲が明確になる

新機能追加時に既存コードへの影響を最小限に抑える

可読性:

各クラスの責務が明確でコードの理解が容易

1クラスのステップ数が200から300程度に収まる

新しいメンバーのプロジェクト理解が速やかに進む

スケーラビリティ:

チーム開発での競合が減り並行開発が容易になる

複数の開発者が異なるアクションを並行して開発できる

依存性の明確化:

依存関係が明確で変更に強い設計になる

インターフェースを変更しない限り実装変更が他層に影響を与えない

ADRパターンの利点:

ActionとDomainとResponderの分離により責務が明確になる

ビジネスロジックがフレームワークから独立しフレームワーク変更への耐性が向上する

■ 7. 実践的なTips

Laravelサービスコンテナ活用のベストプラクティス:

各機能ごとにサービスプロバイダーを作成し依存関係を明確に管理する

インターフェースに依存することでモック化が容易になる

プレゼンターは都度生成しリポジトリはシングルトンなど適切なライフサイクルを選択する

テストコードの書き方:

依存関係が明確で必要なモックを特定しやすい

1つのアクションに焦点を当てたテストが書きやすい

インターフェースに依存しているためモックの作成が簡単

データベースや外部APIに依存せず単体テストが高速に実行できる

ユースケースのテスト例:

リポジトリをモック化してテストする

在庫不足時の例外スローを確認する

コントローラーのテスト例:

プレゼンターとユースケースをモック化する

レスポンスのステータスコードとデータを確認する

リポジトリのユニットテスト:

DBファサードとEloquentモデルをモック化する

データベースに依存せずテストが高速に実行される

エッジケースのテストが容易になる

拡張時の注意点:

新しいアクションには新しいコンポーネントを作成する

既存コンポーネントの変更を避け影響範囲を最小化する

共通処理はドメインサービスやアプリケーションサービスとして抽出する

共通処理の抽出例:

ドメインサービス: 価格計算や配送料計算などビジネスロジック

アプリケーションサービス: 在庫チェックなど複数アクションで共通する処理

パフォーマンス対策:

リポジトリの最適化により必要なデータのみを取得する

頻繁にアクセスされるデータはキャッシュを実装する

Eloquentのwithメソッドを活用しN+1問題を回避する

ADRパターンとDDDの組み合わせガイドライン:

Action層の薄さを保ちビジネスロジックを含めない

Domain層の純粋性を保ち外部層に依存しない

Responder層の独立性を保ちビジネスロジックを含めない

■ 8. まとめ

設計の重要性:

集約にこだわりすぎることでファットリポジトリ化し保守性が低下する

アクション単位設計により各アクションが独立し変更影響が局所化される

DDDとADRパターンの組み合わせによりクリーンアーキテクチャの原則を実現する

依存性逆転の法則により外部層がApplication層に依存する構造を実現する

長期的なサービスへの適用:

数年から数十年と長く運用し続けるサービスにこそ価値がある

機能の追加や変更が頻繁に発生する環境に適している

チームメンバーの入れ替わりに対応しやすい

技術スタックの進化に柔軟に対応できる

複数の開発者の並行作業で競合が発生しにくい

長期運用における優位性:

機能追加時の影響範囲が明確で既存コードへの影響が最小限

コードの理解が容易で新メンバーも特定機能に焦点を当てて理解できる

フレームワークからの独立性により技術スタック変更に柔軟に対応できる

並行開発の促進により複数開発者が同時開発しても競合が発生しにくい

実践的な設計指針:

アクション単位設計に従い各アクションに専用コンポーネントを作成する

依存性逆転の法則に従いApplication層にインターフェースを配置する

ADRパターンとDDDの層構造を組み合わせる

テスト容易性と保守性を重視する

MEMO:

ちょっと違和感があるが

(2026/01/18)

巨大SQLに対する解読術

巨大SQLに対する解読術

(2026/01/18)

Kiroみたいな「仕様書駆動開発」をClaude Code・Opus 4でやるまでの手順を整理した！！！

Kiroみたいな「仕様書駆動開発」をClaude Code・Opus 4でやるまでの手順を整理した！！！ #LLM - Qiita

(2026/01/18)

僕の観測範囲で喋ってしまうけど、AI コーディングエージェントが登場してきて、プログラマが...

僕の観測範囲で喋ってしまうけど、AI コーディングエージェントが登場してきて、プログラマがやってた事を AI が肩代わりするだろう、そして人間に時間の余裕ができるだろう、と思われていたにも関わらず、多くのプログラマはそれどころか 2 倍や3倍の作業量になってしまっており「おいおい君ら倒れるで」という状況をチラホラ目にしている。

@mattn_jp

MEMO:

実装というかコード出力はすぐ完了するので、出力されたコードをレビューする → 意図通りに修正 or 再出力を指示みたいなサイクルが早すぎて人間側が疲弊している
単位時間あたりの労働負荷が大変なことになっている上、AI前提の生産性が求められるのでサボることもできないという

(2026/01/18)

Raspberry Pi AI HAT+ 2

Buy a Raspberry Pi AI HAT+ 2 – Raspberry Pi

要約:

■ 1. Raspberry Pi AI HAT+ 2の概要

Hailo-10H AIアクセラレータを搭載

8GBのオンボードRAMを搭載

Raspberry Pi 5に生成AI機能を追加するHAT

価格は130ドル

現在販売中

■ 2. オンボードRAMの利点

8GBの専用オンボードRAMを搭載

大規模言語モデル(LLM)やビジョン言語モデル(VLM)をローカルかつセキュアに実行可能

ホストのRaspberry Pi 5を他のタスク処理に解放できる

AIモデルのスムーズな動作を保証

■ 3. プライバシーとセキュリティ

エッジでの信頼性が高く低遅延なAI処理を実現

ネットワーク接続なしで動作可能

データセキュリティを簡素化

インフラ要件を最小化

クラウドAPIコストを削減

■ 4. モデルの提供

Hailoがサンプルモデルを提供

ユーザーによるカスタマイズ:

カスタムビジョンモデルのトレーニング

生成AIモデルのファインチューニング

対応アプリケーションの例:

音声からテキストへの変換

翻訳

視覚シーン分析

互換性のある生成AIモデル用ソフトウェアはHailoのGitHubリポジトリで入手可能

■ 5. 主な仕様

Hailo-10H AIアクセラレータ搭載

40 TOPS(INT4)の推論性能

コンピュータビジョンモデルの性能はRaspberry Pi AI HAT+(26 TOPS)と同等

8GBオンボードRAMにより生成AIモデルを効率的に実行

Raspberry Piのカメラソフトウェアスタックに完全統合

Raspberry Pi HAT+仕様に準拠

■ 6. 付属品

オプションのヒートシンク付属

16mmスタッキングヘッダー付属

スペーサーとネジ付属

Raspberry Pi Active Cooler装着済みのRaspberry Pi 5への取り付けが可能

MEMO:

40TOPSというと最近発表されたASUSのAIアクセラレータと同等のスペックなのか
ASUS、最大40TOPSのAI性能を持つ外付けAIアクセラレータ - PC Watch

(2026/01/18)

loss32: let's build a Win32/Linux

loss32: let's build a Win32/Linux

要約:

■ 1. loss32プロジェクトの概要

コンセプト:

デスクトップ環境全体がWINE上で動作するWin32ソフトウェアで構成されるLinuxディストリビューション

完全にフリーかつオープンソースのOS

exeファイルをダウンロードしてそのまま実行できる

想定ユーザー:

必ずしもUnix愛好家ではないパワーユーザー

このコンセプトを面白いと思う人

■ 2. ReactOSとの違い

ReactOSの問題点:

Windows NTカーネルの再実装を試みている

これがアキレス腱となりハードウェア互換性と安定性の面で足を引っ張っている

loss32のアプローチ:

ReactOSと似た最終結果を目指す

より使いやすい基盤の上に構築

動作実績のあるコンポーネントを使用:

Linuxカーネル

WINE

それらを結合する各種ツール

ReactOSユーザーランドの便利な機能

loss32の利点:

技術的にはLinuxディストリビューションのため必要に応じてLinuxソフトウェアも実行可能

ReactOSではLinuxソフトウェアを実行できない

■ 3. プロジェクトの目標

ユーザーランド全体を可能な限りWINEで置き換える

■ 4. プロジェクトを構築する理由

90年代後半から2010年代初頭のPCデスクトップ体験はパワーユーザー特にクリエイティブユーザーにとって素晴らしかった

その夢を維持したい

WINEには残念な荒削りな部分が多くユーザーは最後の手段としてのみWINEを使用するため許容している

全てがWINE上で動作するデスクトップ環境はWINEの改善を促進する

このプロジェクトを使うかどうかに関わらず全員にとって有益

Win32は安定したLinux ABIである

技術的に可能だから

■ 5. Win32が安定したLinux ABIである理由

exeファイルをダウンロードしてWINEで実行できることで何度も助けられた経験がある

クリエイティブプロジェクトでは以下のようなソフトウェアが必要になることが多い:

自分で再ビルドするのが不可能または非現実的

LinuxやmacOS版が動作しないまたは存在しない

Win32ソフトウェアには30年以上の歴史がある

WINEまたはWindows上で実行可能

他のABIにはこれほどの互換性実績がない

WINEはWin16のソフトウェアも実行可能

Win32は世界の安定したABIでもある:

GNU/LinuxやPOSIX系の選択肢が限られており品質が低い分野が多い

例としてクリエイティブソフトウェアやゲーム

Win32により人類の文化遺産のより大きな部分にアクセス可能

■ 6. 現在の状態

スクリーンショットは実際のもの

Debian 13上で安定版WINEを実行している状態

スクリーンショットには映らない多くの荒削りな部分があり現時点では使用が快適ではない

プロジェクトの目標:

多くの荒削りな部分を修正

この環境を簡単にインストールできる形でパッケージ化

■ 7. 協力者の募集

特に求めている知識や協力:

デスクトップ環境を強制しないWaylandコンポジター

現在はスタンドアロン版のmutterを使用

WINEとの連携改善

WINE関連:

explorer.exe

shell32.dll関連

HiDPIスケーリング

パッケージング

ReactOS関連:

explorer.exe

shell32.dll関連

ReactOSユーザーランドとWINEの非互換性

GNU/Linuxデスクトップスタックの複雑な詳細全般

■ 8. リリース予定

ビジョンの完全な実現時期:

不明

2026年1月中に初期の概念実証版をリリース予定:

/etc/apt/sources.listに追加してsudo apt installで導入可能

欠落や不具合の長いリストが付属

そこから反復的に改善していく

(2026/01/17)

無茶なスケジュール案件でも燃えにくくする「開発環境」と内部工程計画の考え方

無茶なスケジュール案件でも燃えにくくする「開発環境」と内部工程計画の考え方 #アジャイル - Qiita

要約:

■ 1. フリーランス・小規模ソフトハウスが直面する構図

元請けが穴だらけの立派な工程表を出してくる

大半の人はその穴を見抜けるレベルのレビュー実戦経験がない

プライムにケチを付けられない立場のため従うしかない

末端側はウォーターフォール型工程に従い各工程のみを担当する

作るものの全体像が曖昧なまま設計が進む

実際に環境を組み上げたタイミングでようやく現実が見える

結果として発生する問題:

仕様漏れ

追加作業と追加料金交渉

納期ギリギリ

ユーザー満足度の低下

■ 2. プロジェクト計画の理想と現実

理想:

プロジェクト計画書がパートナーにも展開される

双方でコンセンサスを取りながら進める

リスク想定とヘッジ案の説明や議論がある

現実:

小さな会社の社長やフリーランスはプロジェクトキックオフの儀式としてしか見ていない

様々な事情からリスク議論が実践できない

■ 3. 元請けの工程表の実態

PMの願望が強く出たドキュメントと認識すべき

通常書かれていないもの:

商用環境の構成が固まるタイミング

試験環境でどこまで再現するか

どの段階で何を試すか

現場の安全マージンやリスクヘッジ

極端な工程表の例:

要件定義工程がない

各工程での成果物が決まっていない

設計工程なしにいきなりパラメータ設計書

PoCでやったから設計なしでいけるという幻想でいきなり環境構築

ステージングをそのまま本番にするノリで商用後の保守イメージがない

実装期間が妙に短く3週間に環境構築から報告書作成まで全部入り

セキュリティ設計やセキュアコーディングガイドラインがなく脆弱性試験で炎上

このまま乗ると後半で燃える

外向け工程表とは別に内部で裏プロジェクト計画を持つ発想が重要

■ 4. 技①:基本設計段階でプロト環境を先に作る

基本設計フェーズの早い段階で本番と同じ構成イメージの影のプロト環境を自分たち側でこっそり作る

プロト環境の内容:

土台となるOS

想定しているミドルウェア(アプリケーションサーバやレポーティング基盤など)

知る限り本番構成に近い形で一度組んでみる箱

あらかじめ作っておくべきもの:

GitLabなどのソースコード管理とCI/CD基盤

メリット:

早い段階でリバースプロキシ不足や追加DB必要などの設計上の大穴に気づける

元請けの基本設計がふわっとしていても動くものの全体像を先に掴める

構築メモや設定手順と要件定義があれば基本設計書は後から2〜3日で一気に書ける

体裁や細かい部分はLLMを使えば2〜3日で形にできる

ポイント:

工程表通りにドキュメントだけ書くのではなく基本設計の最初にプロト環境をこっそり動かす

内部工程を勝手に入れ替える

外には言わず自分たちが燃えないための保険として自社努力で行う

コスト面:

自社で新たに大きなコストを捻出する必要はない

プロジェクト開始早々は要件定義未提出や基本方針未確定などの待ち時間が多い

自分に関係ない打ち合わせ中にこっそり進める

待ち時間を活用して動くものの断片でも作っておく

勝手アジャイルを回す勢い

■ 5. 技②:バージョン釘打ちミーティングをねじ込む

プロト環境を先に作る際の落とし穴:

バージョンが後から変わって全部作り直しになる

対策として基本設計の初期にバージョン釘打ちミーティングをねじ込む

最低限合意しておくべき項目:

土台となるOSのバージョン(メジャーとマイナーまで決まれば上出来)

主要なミドルウェアとそのバージョン(アプリケーションサーバやレポーティングやバッチ基盤など)

それぞれのサポート状況(EoL時期やメーカーサポート有無やOSSコミュニティ活動状況)

釘打ちは完璧でなくてよい:

一生変えないという固定ではない

ひとまずこの前提で設計見積もりを進めるレベルの合意

後から変更が出ても柔軟に対応できるようにしておく

■ 6. 技③:プロト環境の存在は言わず経験値として出す

影のプロト環境で性能やリソースを見ておくと後のフェーズで楽になる

聞かれる質問の例:

この構成でCPU何コアぐらい必要か

何ユーザーぐらいまで余裕があるか

どのくらいのマシンサイズを見込めばいいか

裏ではプロト環境でちゃんと数字を取っているが自前環境で負荷かけたとストレートに言う必要はない

期待値コントロールの領域

外向きの言い方サンプル:

同等規模の構成での過去案件の経験値ではこのくらいのアクセス数ならCPU使用率は何%前後

近い構成のプロジェクト実績をベースにすると初期はこのマシンサイズから始めるのが妥当

似たような業務負荷の案件で取った数値を参考にするとこのくらいのスペックで当面余裕がある

実際にはその過去案件の1つが今回の影のプロト環境だが外から見れば経験値として扱える

バランス感覚のポイント:

裏側ではしっかり測っている

過度に全部やってあげてますと期待値を上げすぎない

過去の知見として妥当な範囲を出していますというトーンを守る

■ 7. 技④:LLMに食わせる前提で手順書だけちゃんと残す

影のプロト環境を作るときは基本設計書そのものより手順書とメモの残し方をちゃんとしておく

理由:

LLMに食わせるとかなり精度の高い基本設計書ドラフトが一瞬で出てくる

流れ:

影のプロト環境を作る

その過程でインストール手順やミドルウェア設定や詰まったポイントと解決策をざっくりテキストで残す

LLMに渡して基本設計書の構成案出しや顧客向け表現整理や試験項目洗い出しやパラメータシートたたき作成を依頼

2〜3日かけて書くレベルの文書が数時間で形になる

この組み合わせの効果:

実装リスクを下げる

ドキュメント工数も削る

かなり相性の良い戦略

■ 8. ウォーターフォールを表で守りつつ裏でアジャイルを回す

表向きの対応:

元請けが出してきた大きな工程表(ウォーターフォール)に従っているように見せる

マイルストーンや成果物の名称も基本設計や機能設計や結合テストを崩さない

裏側での対応:

基本設計フェーズのうちにプロト環境を作って動かす

バージョンを釘打ちする

実際に動かしながらこれで行ける構成を先に固めてしまう

そこで得た知見をもとに性能見積もりやリソース見積もりやリスク洗い出しをスッと出せるようにしておく

効果:

表面上はウォーターフォールでも内側では小さなアジャイルサイクルをぐるぐる回して後続工程をどんどん楽にできる

大線表の納期を遅らせるという話ではない

最初に影のプロト環境を作っておくことで大線表を遅らせずに済む確率がかなり上がる

その構成で実際に動いている環境がすでにあるため

■ 9. 環境をプロジェクトごとに準備する効率化

ネック:

案件ごとにOSやミドルウェアや認証まわりやテスト用クライアントを毎回ゼロから用意するのはフリーランスや小規模ソフトハウスにはheavy

対策:

案件ごとの箱庭環境を簡単に量産できるテンプレートやツールを少しずつ自分の側に用意しておく

具体例:

手元のマシン1台に仮想化環境と案件ごとの箱庭を自動で作るスクリプトを置いておく

新しい案件が始まったらまず影のプロト環境を30分くらいで立ち上げてから設計に入る

使うツールや技術スタックは何でも構わない

大事な発想:

毎回手作業で環境を組むのではなく案件ごとの箱庭をほぼテンプレートから起こす

リモートからVPN経由で簡単に入れるようにしてパートナーがすぐに参加できる環境を作っておく

となりの案件のVMが見えてしまわないようなセキュリティに十分配慮した分離開発環境を構築する

パブリッククラウドで回してもよいが採算度外視で使うのはかなり危険

■ 10. まとめ

元請けの工程表だけを信じて燃えないための要点:

外向け工程表とは別に自分たちの内部工程計画を持つ

基本設計の初期にプロト環境をこっそり作ってしまう

OSとミドルウェアのバージョンを早めに釘打ちしておく

プロト環境で得た数字は自前ラボで測りましたではなく他プロジェクトでの経験値ですとして出す

手順書をちゃんと残しておけばLLMに食わせて基本設計書を一気に仕上げることもできる

表向きはウォーターフォールでも裏で小さなアジャイルを回して先回りしておくといろんな工程が楽になる

正論のセキュリティ記事というより現場で生き残るためのテクニック集

これらの工夫が積み上がると変わること:

プロジェクトの燃え具合

ユーザーの満足度

自分たちの消耗度合い

(2026/01/17)

Redundancy vs dependencies

Redundancy vs dependencies: which is worse?

要約:

■ 1. プログラミングにおける2つの本質的な力

冗長性の最小化:

全ての知識を一度だけ定義することが理想

依存関係の最小化:

AがBに依存するのは絶対に必要な場合のみに限定すべき

優れたプログラマの特徴:

冗長性と依存関係を嫌悪する

劣ったプログラマはこれらを気にしない

■ 2. 冗長性と依存関係の衝突

モジュール境界を越えたコード再利用の問題:

モジュールAとBが共通モジュールCを使うか各自で実装するかの選択

モジュール内部での再利用:

議論の余地なく再利用すべき

モジュール間での再利用:

第三のモジュールを作成するか「ユーティリティ」モジュールに追加する必要がある

ユーティリティモジュールの問題点:

外部ライブラリへの依存

設定の誤り

初期化タイミングの問題

■ 3. 経験がもたらすもの

経験は知識の蓄積より性格の形成または破壊に寄与する

若いプログラマ:

インフラ構築に積極的

第三のモジュール作成を喜ぶ

ベテランプログラマ:

インフラ活動に対して否定的反応を示す傾向

■ 4. コマンドライン解析の例

機能拡張の誘惑:

オプション構文の統一

値の型対応(文字列/真偽値/整数/16進数/ユーザー定義型)

ヘルプ文字列

ヘルプ画面の自動生成

GUIプロパティページ

設定ファイルからの読み込み

フラグの妥当性チェック

過剰設計の実例:

XParam: 1万行以上のコードと独自シリアライゼーションフレームワーク

ホストプロジェクトでは機能の5%未満しか使用されない

著者自身もXLogという1万行以上のログライブラリを作成し機能の0%しか使用されなかった経験を持つ

著者の現在のアプローチ:

5行のCコードで単純に解析

ヘルプ画面やバリデーションは不要と割り切る

1万行のパッケージへの依存を回避

■ 5. モジュールの定義と要件

コンパクトで安定したインターフェース:

OOの訓練がコンパクトさの軽視を招いている

数十のクラスや複雑なデータ構造を公開することが許容されている

ドキュメント:

セマンティクスの記述

サンプルコードの提供が理想

テスト:

各クラスや関数の単体テストではなく公式インターフェースのテストが重要

適切なサイズ:

1K〜30K LOC(C++換算)が目安

大きすぎても小さすぎても泥の塊になる

オーナー:

変更はオーナーを説得して行う

一貫したメンタルモデルを維持できる人数は1人

ライフサイクル:

変更はバージョンにまとめて頻繁すぎないリリース

■ 6. 他者のモジュールへの依存の問題

オーナーシップの問題:

作成者が継続的なサポートを認識していない

他者による不適切な変更が発生

循環依存の発生

コマンドラインパーサーの潜在的依存先:

シリアライゼーションパッケージ

パースパッケージ

カラーターミナルI/Oパッケージ

プラットフォーム固有パッケージ

シングルトン初期化管理パッケージ

ライフサイクルの問題:

バージョン互換性の確認

テストのコンパイルに他者のコードが必要

新バージョンが追加の依存関係を引き込む

インターフェース安定性の問題:

破壊的変更によるテストスクリプトの破損

予期しない動作変更

■ 7. 生物学的アナロジー

生物における冗長性の例:

人間とタコは盲目の祖先から独立して類似の眼を進化させた

眼全体という複雑な器官が独立して開発される

冗長性は進化において機能している:

全員の努力を調整するより効果的

■ 8. 結論

冗長性の欠点:

努力の重複

相互運用性の問題

依存関係はより深刻:

依存すべきは本格的なモジュールのみ

無定形なコードの塊には依存すべきでない

モジュール化の成功可能性の評価基準:

実際のオーナーの存在

安定したインターフェース

全ユーザーを満足させる見込み

著者の主張:

成功の見込みが低ければ冗長性を選択すべき

見積もりは保守的に行うべき

冗長性は悪だが依存関係は麻痺を引き起こす

依存関係を先に排除すべき

MEMO:

つまり、外部ライブラリへの依存は最小限にせよという話
外部ライブラリに依存すると、外部ライブラリのアップデートやセキュリティホール対応に追従する必要が生じる
特にビジネスロジックと外部ライブラリが強く結合していると外部ライブラリの不安定さがコアロジックの不安定さにつながる
古来より外部ライブラリは直接使うのでなく、ラップして使うことが推奨されていたように思うのだが
近年は本当に些細な処理ですらライブラリ化されていて、脳死で外部ライブラリを使うことが多いが、その結果サプライチェーン攻撃を喰らうことも増えた
npmのleft-padやcolors.js/faker.jsなどがそうだったか

(2026/01/16)

ドワンゴを退職した江添亮さんがハロワに登録→連絡してきた企業の面接に行ってみたら、殺風景な雑居...

ドワンゴを退職した江添亮さんがハロワに登録→連絡してきた企業の面接に行ってみたら、殺風景な雑居ビルの一室でわけのわからない経験をした話 - Togetter

MEMO:

クソカス虚無企業の面接冷やかしやってみたいけど、シンプルに時間の無駄な上に個人情報を握られるリスクを考えると迂闊にできないんだよな
転職サイトならギリギリまで公的な身分証明出さなくてもいいから案外いけるのだろうか

(2026/01/16)

生成から工程へ――RLM(再帰的言語モデル)が非構造化データを武器に変える

生成から工程へ――RLM(再帰的言語モデル)が非構造化データを武器に変える – WirelessWire & Schrödinger's

要約:

■ 1. RLMの定義と本質

再帰的言語モデルの位置づけ:

最も注目を集めている大規模言語モデルエージェント・アルゴリズム

実際のモデルはOpenAIのChatGPTやgpt-ossやDeepSeekなど既存のLLMを使用する

再帰とはLLMの呼び出し方を指す

RLMの本質:

LLMを一発回答の生成器として使うのではなく複数の推論ステップを持つ手続きとして編成する

自己修正しながら目的の成果物へ収束させる

重要なのは再帰という言葉の響きよりも実装上の設計原則

■ 2. RLMの3つの構成要素

オーケストレーターLLMとワーカーLLMの役割分担:

オーケストレーター: 大局的な戦略を立てる役割でどの資料を読むべきかや抽出すべきスキーマは何かや矛盾が出たらどの観点で再検証するかを担う

ワーカー: 局所的な作業を担当しこの段落から顧客要望を候補抽出するやこの候補の根拠となる引用箇所を特定するなど粒度の小さいタスクを大量に捌く

同じLLMで役割を分担することが可能でgpt-ossは非常によく働く

分業が効く理由:

LLMの失敗が往々にして大局と細部の混線で起きる

戦略を考えながら同時に細部を埋めるともっともらしい整合を優先し検証が甘くなる

戦略と実務を分けることで作業の責務が明確になり失敗の検知と修正がしやすくなる

非自然言語的な中間表現:

Pythonコードなど機械的に検査可能な表現を途中に置く

抽出結果をJSONにしPythonでスキーマ検証を行う

重複や欠落や型不一致や相互参照の矛盾をコードで弾く

候補の根拠引用が本当に原文に存在するかを文字列一致や範囲照合で検証する

中間表現の効果:

モデルが賢くなったから精度が上がるのではない

LLMが苦手な厳密さをコードと型と制約で肩代わりしLLMには意味の解釈を担当させる

LLMを推論エンジンとして使いつつ検証と制約は計算機の得意技に寄せるアーキテクチャ

検証から差分修正から再実行のループ:

最初の抽出はあくまで暫定解にすぎない

Pythonで検査してエラーが出たらそのエラーを次の入力条件としてオーケストレーターに返し再度ワーカーにタスクを割り当てる

やり直しを精神論ではなくプロトコルとして設計する

プロトコル設計の例:

フィールドが埋まらない場合は未確定を許す

未確定のまま残した理由を分類して残す

矛盾が出たら根拠引用を必須にして再抽出する

モデルがそれっぽい完成品を捏造する余地が減りシステム全体として信頼性が上がる

■ 3. RLMの全体像と従来手法との比較

RLMの定義:

戦略立案担当と局所作業担当に分解する

Python等で検証可能な中間表現を挟む

誤りを差分として回収し再帰ループで収束させる方式

従来手法の問題点:

LLMに抽出させて人間が目視で直す運用がスケールしなかった

失敗が最後に露呈し修正が属人的だった

RLMの優位性:

失敗を途中で機械的に検出し修正を自動で次工程に流す

非構造化から構造化のような業務で予想以上に効く

コアの考え方:

賢い一発回答ではなく検証可能な中間表現と再実行プロトコルによって正しさへ収束する工程を作る

■ 4. KnowledgeSTATIONでの実装例

実装結果:

RLMによる非構造化データから構造化されたデータを取り出す機能を追加した

予想外にうまくいった

機能の詳細:

過去の著作や議事録や講義録など雑多な情報を貯めた知識ベースに注目するデータと出力して欲しいデータを渡す

技術的な話題に注目し技術と発明者とその効果と関連する技術を指定すると自動的にデータを検索して構造化する

RLMがどのように動作して情報をかき集めまとめているのかという過程も可視化されている

間違ったデータが出てきてもどこで間違ったのか理解しやすいメリットがある

出力例:

GPUやELIZAやAlexNetやニューラル機械翻訳やChatGPTなど技術に関する構造化データが抽出された

トークン上限8000など純粋に技術そのものとは言えないものも出てくるが索引などに引用する場合は納得できる

構造化されたデータはExcel形式でダウンロードできる

■ 5. RLMの特徴的なメリット

非構造化データのノイズの活用:

RLMがうまく回り始めると非構造化データのノイズがむしろ追加情報源になる

議事録の脱線や雑談や言い淀みや感情的な言葉が優先度の根拠やリスクシグナルとして意味を持つ

それ今日中にやらないとまずいという一言が期限の強制力を示す

顧客が同じ要望を三度言うならそれは単なる繰り返しではなく強い痛みの表現

RLMは再帰の過程でこうした文脈特徴を拾い上げ構造化スキーマに落とし込める

■ 6. 課題

計算コストの増加:

再帰はループを回すほどトークンも増え遅延も増える

検証関数の設計依存:

再帰の品質は何を矛盾とみなすかや根拠は十分かやスキーマ制約を満たすかの設計に依存する

情報の欠落:

ドメインによってはそもそも根拠がテキストに存在しないことがある

会議で決まったはずなのに議事録に書かれていない場合などが該当する

未確定を無理に埋めず追加の情報取得フローに接続する必要がある

エージェントは万能の魔法使いではなく情報の欠落を検知して次の行動へつなげる工程管理でもある

■ 7. 今後の展望

LLM活用の主戦場の変化:

文章生成ではなく非構造化データを意思決定可能な構造へ変換することになる

人間の組織が抱えるボトルネックは情報の不足ではなく情報の形式

見つけられないや比較できないや集計できないや追跡できないという問題がある

RLMはここに正面から切り込むための基本部品になり得る

ローカル動作の利点:

完全にローカルで動作するという点も見逃せない

クラウドAIのAPI利用料金や制限に悩まされることなく黙々とデータを構造化していく

エージェンティックAIの新局面:

RLMによってエージェンティックAIは新しい局面に到達できる可能性がある

(2026/01/16)

現場PMの力学 - 第1章：プロジェクトは「正しさ」では動かない

現場PMの力学 - 第1章：プロジェクトは「正しさ」では動かない

(2026/01/16)

OpenSSLプロジェクトの品質問題や組織構造の変遷について

■ 1. OpenSSLの品質問題

OpenSSLの品質や状況に懸念があるという指摘は専門家やエンジニアの間で事実として存在

特にOpenSSL 3.0(2021年リリース)以降パフォーマンスの低下やアーキテクチャの複雑化をめぐって厳しい批判

主な指摘内容:

パフォーマンスの大幅な劣化:

新しい「プロバイダー・アーキテクチャ」が原因で特定の処理が旧バージョン(1.1.1系)より著しく遅くなった

マルチスレッド環境でのロック競合によりスループットが劇的に低下

APIのオーバーヘッドにより証明書の検証や鍵の生成といった基本的な操作のステップ数が増加

コードの複雑化とテストの不備:

テストを通過していないコードがマージされる事象が2025年時点でも指摘

修正によって別のバグ(デグレード)が発生

メモリ安全性の欠如(C言語で書かれているためバッファオーバーフローなどの脆弱性が継続的に発見)

QUICへの対応遅延:

次世代通信規格QUIC(HTTP/3)への対応が非常に遅れた

多くのプロジェクトがBoringSSLやquictlsなどの別ライブラリへ流出

業界の反応(OpenSSL離れの加速):

BoringSSL: GoogleがOpenSSLをフォーク/不要な機能を削ぎ落としセキュリティとパフォーマンスに特化

rustls: Rust言語で書かれたTLSライブラリ/メモリ安全性が保証されパフォーマンスも高い

Goの標準ライブラリ: 独自実装を選択しOpenSSLの混乱の影響を受けない

■ 2. OpenSSLの資金面と組織面の変遷

Heartbleed以前(2014年以前):

世界中のインフラを支えていながら正社員はほぼゼロ

寄付金は年間わずか2,000ドル程度という極めて劣悪な環境

Heartbleed後:

Linux Foundationの「Core Infrastructure Initiative」などを通じて数億円規模の資金援助

組織は急拡大

資金拡大の副作用:

「商用化」へのシフト: 安定した運営のためサポート契約を販売する法人化を推進/大口顧客が求める「FIPS認証」などの要件が優先

官僚化と構造の複雑化: 少数の凄腕エンジニアによる属人的な開発から委員会による合議制へ移行/意思決定の鈍化

OpenSSL 3.0の問題:

過度な抽象化: 将来的な拡張性を求めて内部構造をゼロから作り直す「プロバイダー・アーキテクチャ」を導入/極めて複雑で旧バージョンの数百倍遅い処理が発生

QUIC対応の失敗: 内部の設計方針が二転三転した結果開発が大幅に遅れた

「レガシー」と「新設計」の板挟み:

世界中で動いているという責任があるため古いC言語のコード(30年前のものも含む)を維持しながら最新の安全な設計を取り入れる必要

テストの不足: 膨大なコードベースをカバーする自動テスト体制が追いついていない

技術的負債: Rustなどのメモリ安全な言語への移行を求める声もあるがC言語に固執せざるを得ない現状

■ 3. OpenSSLの組織改革(2024年〜)

二頭体制への分離(2024年3月〜):

OpenSSL Corporation(事業会社): 商用ユーザーや大口顧客を対象/サポート契約の販売/FIPS 140認証の取得など

OpenSSL Foundation(財団): 非営利コミュニティや個人開発者を対象/オープンソースとしての理念を守る

旧体制(OMC/OTC)の解散:

OMC(管理委員会)の解散(2024年3月): 代わりに10名の取締役会が意思決定

OTC(技術委員会)の解散(2025年4月予定): 代わりにTAC(技術諮問委員会)が新設され技術ロードマップの決定に透明性

リリースサイクルの「予測可能性」の重視:

タイムベースのリリース(毎年4月と10月)に移行

組織改革の背景にある反省点:

「身内感」の払拭: 閉鎖的な構造が外部からの批判を招いていた/新体制では選挙制を導入

「商用優先」への批判回避: 組織を分けることでバランスを取る

■ 4. OpenSSL 4.0の野心的変更(2026年4月リリース予定)

過去10年以上の負債を一掃するための「大掃除」のリリース

ENGINE APIの完全削除:

ハードウェアアクセラレータや独自の暗号モジュールを利用するための仕組み

設計が古くメンテナンスの大きな負担

「Provider(プロバイダー)」アーキテクチャに一本化

独自のハードウェア支援を利用している古いシステムはProvider形式に書き換えない限り4.0に移行不可

SSLv3のサポート完全終了:

2015年に脆弱性(POODLE)によって完全に否定されたがコードとしては残されていた

4.0ではSSLv3に関連するコードがライブラリから物理的に削除

C99標準への移行とツールチェーンの刷新:

非常に古いC言語規格(ANSI C/C89)をベースに書かれてきた

4.0からはC99以降のコンパイラが必須

コンパイラの最適化が効きやすくなりパフォーマンス劣化を解消するためのコード整理が進めやすくなる

スケジュール:

2026年2月: コードフリーズ

2026年3月: ベータ版リリース

2026年4月7日: 正式リリース(予定)

4.0でのリセットはOpenSSLが「枯れたが重いライブラリ」から「現代的で筋肉質なライブラリ」へと再生できるかどうかの分水嶺

The State of OpenSSL for pyca/cryptography

The State of OpenSSL for pyca/cryptography — Cryptography 47.0.0.dev1 documentation

要約:

■ 1. 記事の概要

pyca/cryptography(Pythonの暗号化ライブラリ)のメンテナーであるPaul KehrerとAlex Gaynorによる2026年1月14日の記事

12年間OpenSSLに依存してきたが成長する問題について2025年10月のOpenSSL Conferenceで発表

OpenSSLの開発における過ちが重大になったため実質的な変更が必要(OpenSSLに対して、または依存関係に対して)

■ 2. OpenSSLの軌跡(3幕構成)

第1幕: Heartbleed以前(2014年以前):

OpenSSLはメンテナンスが不十分で停滞していた

期待を大幅に下回っていた

第2幕: Heartbleed直後:

OpenSSLのメンテナンスが再活性化され大幅な進歩と改善

実際のコードレビュープロセスの導入

CIでのテスト実行開始

ファジングテストの採用

リリースプロセスの成熟

第3幕: 2021年のOpenSSL 3リリース:

新しいAPIを導入し大規模な内部リファクタリング

パフォーマンス/複雑性/APIの使いやすさにおいて大幅な後退

テスト/検証/メモリ安全性の面で必要な改善がなかった

同時期にOpenSSLのフォーク(LibreSSL/BoringSSL/AWS-LC)はこれらの分野で進歩

■ 3. パフォーマンスの問題

OpenSSL 1.1.1と比較してOpenSSL 3はパース処理やキー読み込みなどで大幅なパフォーマンス後退

楕円曲線公開鍵の読み込みがOpenSSL 1.1.1と3.0.7の間で5〜8倍遅くなった

改善後も以前より3倍遅い

OpenSSLの対応は「OpenSSL 3では後退が予想されており最適化の余地はあるが1.1.1レベルに戻ることは期待すべきではない」

pyca/cryptographyがX.509証明書パースをOpenSSLから独自のRustコードに移行した結果OpenSSL 3と比較して10倍のパフォーマンス向上

公開鍵パースを独自のRustコードに移行したことでエンドツーエンドのX.509パス検証が60%高速化

独自パースでより良いパフォーマンスを達成できることは実践的に可能であることを示している

彼らのパフォーマンスは巧妙なSIMDマイクロ最適化の結果ではなくコピー/アロケーション/ハッシュテーブル/間接呼び出し/ロックを避けるというシンプルな方法の結果

■ 4. 複雑性とAPIの問題

OpenSSL 3はAPIを大幅に変更し始めた

OSSL_PARAMを導入しすべての新しいAPIサーフェスに使用(ポスト量子暗号アルゴリズムを含む)

OSSL_PARAMは通常の引数渡しの代わりにキー値ペアの配列を関数に渡す

OSSL_PARAMの問題点:

パフォーマンス低下

コンパイル時検証の減少

冗長性の増加

コードの可読性低下

具体的な比較:

OpenSSLでML-KEMカプセル化を行うには37行と6つのフェイラブル関数呼び出しが必要

BoringSSLでは19行と3つのフェイラブル関数呼び出し

OpenSSL内部も複雑化:

OSSL_PARAMの配列管理を容易にするために多くのソースファイルがCファイルではなくCコード用のカスタムPerlプリプロセッサを持つ

OpenSSL 3は「providers」の概念を導入:

アルゴリズムの外部実装を許可

プログラム実行の任意の時点で任意のアルゴリズムを置き換えることを許可

ほぼすべての操作に無数のアロケーションとロックを追加する必要があった

パフォーマンス後退の原因

悪い決定の連鎖:

providersAPIの設計ミス → パフォーマンス後退 → キャッシングとRCUによる追加の複雑性 → さらなるバグ → それでもパフォーマンスは最初より悪い

OpenSSLのソースコードを読むことが苦痛になった:

間接呼び出し/オプションパス/#ifdef/その他の理解への障害の数が驚くべきもの

以前はそうではなかったしLibreSSL/BoringSSL/AWS-LCでもそうではない

■ 5. テストと検証の問題

OpenSSLプロジェクトはテストを十分に優先していない

OpenSSL 3.0開発サイクル中にテストカバレッジのギャップが顕著に見えた:

16ヶ月にわたる19のプレリリースの拡張アルファ/ベータ期間中にコミュニティからの後退報告に大きく依存

自社テストでは意図しない実世界の破損をキャッチするには不十分だった

バグ修正が付随する回帰テストなしでランドされることがまだ一般的

OpenSSLのCIは非常にフレーキー(不安定)でプロジェクトはこのフレーキーさを許容するようになった

OpenSSL 3.0.4の重大なバグの例:

AVX-512対応CPUでのRSA実装に重大なバッファオーバーフロー

CIで実際にキャッチされていたがCIランナーがたまたまAVX-512 CPUを持っている場合にのみクラッシュが発生したため障害はフレーキーさとして却下された

3年後もテストが失敗するコードをマージ:

カンファレンススライド準備日には最近の10コミット中5つがCIチェック失敗

トーク前日にはすべてのコミットがクロスコンパイルビルド失敗

Intel SDEなどのツール採用の価値:

x86-64拡張命令の異なるサブセットを持つCPUに対する制御されたテストが可能

AVX-512の有無での専用テストジョブを持つことで障害の性質がすぐに読みやすく再現可能になる

OpenSSLは形式検証の最先端に追いついていない:

形式的手法は学術的な新奇さから暗号コードの意味のある部分に対する実用的な現実になった

BoringSSLとAWS-LCは形式的に検証された実装を組み込み自動推論を使用して保証を高めている

■ 6. メモリ安全性の問題

OpenSSL作成時にはパフォーマンス/埋め込み可能性/メモリ安全性を意味のある形で提供するプログラミング言語はなかった

世界は変わった:

約5年前にpyca/cryptographyはRustコードを組み込んだ最初のリリースを発行

それ以来ほぼすべての機能をRustに移行

純粋なRustですべてのパースとX.509操作を行い暗号アルゴリズムにはOpenSSLを使用

パフォーマンス向上と複数のOpenSSL CVEの回避を達成

これらの移行が可能であることを彼らは知っている

セキュリティにコミットしたライブラリはメモリ安全なプログラミング言語への長期的な移行にコミットする必要がある

OpenSSLはこの問題に全くイニシアチブを示していない

■ 7. 原因の考察

これは資金不足やコモンズの悲劇の問題ではない

Heartbleed以降の10年間でOpenSSLはかなりの資金を受け取っている

現時点でOpenSSL CorporationとFoundationはBoringSSLまたはLibreSSLでフルタイムで働く人数より多くのソフトウェアエンジニアを雇用

他のOpenSSLフォークがこれらの同じ設計選択をしていないという事実は「これが必要だったか」という質問に対して有益な情報

■ 8. 今後の方向性

ポリシー変更1:

新機能にOpenSSL実装を要求しない

LibreSSL/BoringSSL/AWS-LCでのみ利用可能な新しいAPIを追加

具体的にはML-KEMとML-DSA APIをLibreSSL/BoringSSL/AWS-LCでのみ利用可能にしOpenSSLでは利用不可

ポリシー変更2:

現在wheelsにOpenSSLのコピーを静的リンクしている

wheelsをOpenSSLフォークの1つにリンクするために何が必要かを調査開始

ポリシー変更3:

バイナリwheelsをOpenSSLフォークの1つに切り替えることに成功した場合OpenSSLのサポートを完全に廃止する状況の検討を開始

長期的方向性:

GraviolaなどのOpenSSL派生でない暗号ライブラリを潜在的な代替として積極的に追跡

暗号実装を提供するために使用するライブラリの変更はユーザー(特に再配布者)に大きな影響を与えることを認識

これらのステップを軽々しく考えておらず急いで行うことも予想していない

懸念の重大さから行動せざるを得ない

pyca/cryptographyのOpenSSLサポートに依存している場合はOpenSSLプロジェクトに関与しこれらの軸での改善に貢献することが最も抜本的なステップを避ける最良の方法

(2026/01/16)

Why Be Reactive?

Crank.js | Why Be Reactive?

要約:

■ 1. 記事の概要

Crank.jsの開発者Brian Kim氏による2025年8月20日の記事

リアクティブフレームワークは自動的なUI更新を約束するが微妙なバグやパフォーマンスの罠を生み出す

Crankの明示的なrefresh()呼び出しは制限ではなく野心的なWebアプリケーションを構築するためのスーパーパワー

リアクティブ抽象化の一般的な落とし穴を検証しCrankがリアクティブ抽象化を持たない哲学的根拠を提供

■ 2. Crank.jsの特徴

「非リアクティブ」フレームワーク

コンポーネントは関数(async関数やジェネレータ関数を含む)

Promiseを直接コンポーネント内でawaitできる

状態をローカル変数として定義できる

状態が変更されたときにrefresh()を明示的に呼び出してビューを更新する

refresh()コールバックAPIの導入:

状態変更をrefresh()コールバック内に置くことでrefresh()の呼び忘れが不可能になる

コールバック内のコードが再レンダリングを意図していることを宣言的に特定できる

■ 3. バグの重大度分析

バグのクラスの「重大度」を評価する2つの質問:

これらのバグは見つけやすいか?

これらのバグは修正しやすいか?

Crankの場合:

refresh()の呼び忘れバグはアプリが更新されていないことにすぐ気づくため見つけやすい

refresh()呼び出しを追加するだけで修正しやすい

リアクティブ抽象化は古いレンダリングを排除すると主張するが独自の落とし穴を生む

■ 4. Solid.jsの問題: リアクティビティの喪失

Solid.jsではpropsはリアクティブストア

propsをデストラクチャリングしたり派生値をJSX式の外で計算しようとすると失敗する

壊れたコンポーネントはpropsが変更されても更新されない(値を抽出してpropsからJSXへのリアクティブ接続を壊すため)

バグの重大度:

単純なケースはリンタールールで見つけやすいが複雑なアプリケーションにはリンターの隙間をすり抜けるエッジケースがある

修正が難しい(フレームワークのリアクティブルールを理解する必要がある)

SolidはsplitPropsやmergePropsなどのユーティリティを提供する必要がある

Crankの明示的なrefreshモデルではこのクラスのバグは存在しない

■ 5. Vue.jsの問題: ディープリアクティビティのパフォーマンストラップ

Vueはプロキシを使用してリアクティブオブジェクトのプロパティと子を再帰的にリアクティブ抽象化でラップする

深くネストされた状態が変更されたときにDOM更新を実行するのに便利

問題点:

プロキシはプライベートクラスメンバーでは機能しない

プロキシはプリミティブには使用できない(VueがreactiveとrefのAPIを両方提供する理由)

大きなオブジェクトや配列を深くプロキシするとパフォーマンスのボトルネックになる

Vueはパフォーマンス問題を回避するためにshallowRef()やmarkRaw()などのエスケープハッチを提供

深くネストされた更新が再レンダリングを引き起こす便利さから追跡が必要な状態に移行

VueはisReactive()などのユーティリティを提供して開発者にデータのどの部分がリアクティブかを伝える必要がある

バグの重大度:

リアクティビティはデータ構造に不可視に追加されパフォーマンスのために選択的に削除されるため見つけにくい

修正が難しい(状態が作成された場所まで遡ってなぜリアクティブかどうかを把握する必要がある)

■ 6. Svelteの問題: エフェクトと無限ループ

Svelte v4以前は代入がコンパイラによって計装されて再レンダリングをトリガー

Svelte v5では「runes」という特別な構文を導入($state()/$derived()/$effect()など)

エフェクトを使用するリアクティブ抽象化は無限ループに陥りやすい:

同じ$state()ルーンを$effect()ルーンコールバック内で読み書きするとコールバックが発火し続ける

リアクティビティ支持者は「スプレッドシートのようなプログラミング」と称えるが多くの計算セルを持つスプレッドシートは遅い読み込みや開けない問題を抱える

解決策はSvelteのuntrack()関数でルーンの読み取りを非リアクティブとしてマーク

バグの重大度:

通常はすぐにスタックを吹き飛ばすが複雑なコンポーネントでは無限ループがすぐにトリガーされないエッジケースがある

$effect()ルーンはその中で実行されるすべてのコードを着色するためエフェクトコールバック内のコードだけでなくすべてのネストされた関数呼び出しもルーンに書き込まないようにする必要がある

修正が困難(デバッグ時に状態をログに記録するだけで無限ループがトリガーされる可能性がある)

CrankにはエフェクトAPIがないため無限ループを引き起こさない

■ 7. 各フレームワークのエスケープハッチ

リアクティブ抽象化は手動更新管理を排除すると約束するがそれぞれ独自のエスケープハッチと回避策が必要:

Solid: splitPropsとmergeProps(propsを安全に操作するため)

Vue: shallowRefとmarkRaw(パフォーマンスの崖を避けるため)

Svelte: untrack()(無限ループを防ぐため)

これらのAPIはリアクティビティが更新の懸念から完全に隔離してくれないことを示している

■ 8. 実行透明性(Executional Transparency)

参照透明性(Referential Transparency)はデータがどのように変換されるかを「見る」ことを容易にする

実行透明性はコードがいつ実行されるかを「見る」ことに関する

Crankコードは明示性により実行透明性が高い:

コンポーネントは親によって更新されるかrefresh()が呼び出された場合にのみ実行される

Reactは最もリアクティブ抽象化が少ないにもかかわらず最も実行不透明:

開発時にコンポーネントを二重レンダリング

useEffect()/useSyncExternalStore()/useTransition()などの混乱するAPI

コールバックがコールバックを返し任意のスケジューリングアルゴリズムの気まぐれで呼び出される

Reactエコシステムには「Why Did You Render」などのツールや過剰レンダリングのデバッグに関する無数の誤解とブログ記事がある

■ 9. 非リアクティビティはスーパーパワー

Webの最前線はTODOアプリではない

難しいもの:

アニメーション

仮想リスト

スクロールテリング

コンテンツ編集可能なコードエディタ

WebGLレンダラー

ゲーム

WebSocketストリームを使用したリアルタイムアプリケーション

大規模データビジュアライゼーション

オーディオ/ビデオエディタ

地図

リアクティブ抽象化はこれらの難しい問題に役立たない

コンポーネントがいつレンダリングされるかを明示的に制御することはスーパーパワー:

コードが実行される理由のコンテキストを維持できる

必要なときに正確にレンダリングできる

これらの重要な決定を仲介するリーキーなリアクティブ抽象化がない

(2026/01/15)

Constela - Compiler-First UI言語

要約:

■ 1. Constelaの概要

江口優一(yuu1ch13)氏によって開発されているオープンソースのUI言語およびフレームワーク

「UIをJavaScriptではなくJSON(DSL)で記述する」という非常にユニークなコンセプトを持つ

2026年1月時点で活発にアップデートが行われている(直近ではv0.8.0など)

■ 2. コンセプト: Compiler-First UI言語

従来のWeb開発(ReactやVueなど)ではJavaScriptのコードとしてUIを記述し実行時にそのロジックを動かす

ConstelaはUIを「プログラム(命令)」ではなく「検証可能なデータ(JSON)」として扱うことを重視

コンパイル時検証:

未定義の状態(state)の参照や不正なアクション/構造の不整合などを実行前に検出できる

静的解析の容易さ:

任意のJavaScript実行を排除し制約されたJSON形式にすることでUIの振る舞いが決定論的(予測可能)になる

■ 3. AIとの高い親和性

開発者が明示している大きな目的の一つが「AIによるUI生成・修正」への最適化

自然言語で書かれたコード(JSXなど)はAIにとって自由度が高すぎバグを含みやすいという課題がある

Constelaは構造化されたJSONであるためAIが「どのボタンがどの状態を更新するか」を正確に把握しやすい

機械的な自動生成や修正のワークフローに適している

■ 4. 主な機能と技術的特徴

State & Action:

UIの状態管理や副作用もJSON内で宣言的に定義

Style System:

Tailwind CSSのようなクラスベースのスタイリングが可能

CVA(Class Variance Authority)ライクなバリアント管理が可能(v0.8.0以降)

Builder API:

AIツールなどがプログラムからUIを構築するためのTypeScript APIを提供

コンポーネント化:

PropsやSlotといった概念も備えており再利用可能なUIパーツを定義できる

■ 5. 役立つ場面

AI生成UI:

ユーザーの指示からAIが即座に管理画面やダッシュボードを生成するようなアプリケーション

UIの安全な自動更新:

人間がコードを書かずにシステムのメタデータからUIを動的に構成したい場合

ノーコード/ローコードツールの基盤:

構造化データとしてUIを保持する必要があるサービスのバックエンド

■ 6. まとめ

単なる新しいUIライブラリではない

「人間が手でコードを書く時代から機械(AI)がUIを構成・検証する時代」を見据えた次世代のフロントエンド基盤を目指しているプロジェクト

特にAIとの連携機能や開発体験の向上が図られている

MEMO:

UIをJSONで定義し、そのJSONをコンパイルしていい感じのJavaScriptを生成する的なプロダクトぽい
筋は良さそうな印象だけど既存のUIコンポーネントは流用できるのだろうか？
また1から実装する必要があったりエコシステムが育つまで待つ必要があると厳しいものがあるが
Tailwind CSSとの統合はできるようだが
新しい言語として実装するのではなく、カスタマイズされたLinterとしての実装ではダメだったのだろうか？

(2026/01/15)

サラリーマンソフトウェアエンジニアのキャリア

サラリーマンソフトウェアエンジニアのキャリア - Speaker Deck

(2026/01/14)

【Crank.js】リアクティブという欠陥を完全解決したJavaScriptフレームワーク、Crank.jsの思想と信条

【Crank.js】リアクティブという欠陥を完全解決したJavaScriptフレームワーク、Crank.jsの思想と信条 #React - Qiita

MEMO:

聞き覚えがあると思ったら2020年頃に一度認知していた
作者が感動して涙を流したみたいな記事があった気がする

UseCaseレイヤーって要るの？

UseCaseレイヤーって要るの？

要約:

■ 1. 問題提起と背景

レイヤリングへの疑問:

Controller -> UseCase -> Domainsというドメイン駆動なレイヤリングに対して本当にUseCaseは必要なのかという問いに向き合う

どちらもロジックを持ち得るレイヤーでどう棲み分けするのが良いのか

以前のアーキテクチャ:

MVCというレイヤー分けをしてそれ以外にレイヤーを増やさないという誤ったRails Wayへの則り方だった

前任者の当時の判断は環境や状況にあったものだったかもしれないので悪いことだとは思っていない

アーキテクチャの修正:

CQRSの考え方を導入しレイヤーを一枚増やした

controllerがdomainsに依存する構成に修正した

■ 2. 新たな課題の発生

domainsの依存問題:

domainsがdomainsに依存してしまう状況が発生した

複雑なロジックを共通化するにあたりdomainsがdomainsを呼び出す箇所が生まれた

ロジックを書く場所がdomainsもしくはmodelsしか現状無いため

依存させたくないdomainsが依存を持ってしまうことになりアーキテクチャの破綻になってしまう

UseCaseの必要性への疑問:

UseCaseはやはり必要なのではないかという考えが生まれた

しかしUseCaseを挟んだところで今Controller -> Domainsでうまくいっている箇所においてはただdomainsを呼ぶだけのUseCaseができる

あまりにそういうのが増えて冗長なのではないかという疑問が生まれた

■ 3. DomainsとUseCaseの役割

Domainsの役割:

主な役割はビジネスロジックの実装

操作するものはDomainsオブジェクト

ビジネスルールはドメイン固有のルールを実装する

UseCaseの役割:

主な役割はユースケースの実装

操作するものはDomainsクラス

ビジネスルールはユースケースに沿った手順を実装する

本質的な違い:

DomainsとUseCaseは全く異なるもの

Domainsはサービスを展開するビジネス上におけるドメイン知識を含む

Domainsがアプリケーションの知識を持つ必要は全く無い

Domainsのコードそのものがドメイン知識を持つドキュメントとしても在るべき

UseCaseはドメイン知識を纏ったDomainsをユーザーストーリーにあったユースケースの手順に合わせて実装されるもの

UseCaseがドメイン知識を知る必要はなくユースケースにあったDomainsを利用するだけで良い

だいぶ抽象化されたドメインという概念を扱うだけの裏の苦労を知らないお客さん的なイメージ

■ 4. UseCaseの必要性の検討

現状の構成:

ControllerがDomainsに直接依存しているアプリケーションという状況

UseCaseの導入による弊害もある

UseCaseの弊害:

Controller -> Domainsでうまくいっている箇所においてはただdomainsを呼ぶだけのUseCaseができてしまう

呼ばれたらdomainsを呼び出すだけという冗長なクラスが増えていってしまう

段階的導入の困難さ:

全体にUseCaseを挟むというルールにするにはエンドポイント数的にも不可能なので段階的にはなる

そもそもUseCaseはoptionでいいんじゃないかという疑問が生まれた

相談結果:

冗長なUseCaseは増やさずとも良い

Controllerから直接Domainsに依存したところで問題はない気がする

もし他の手続きが必要になったならUseCaseを挟むのはそこまで大変な作業ではない

■ 5. まとめ

UseCaseの必要性:

UseCaseがなくても問題はない

役割の明確化の重要性:

Domainsにはドメインとなるロジックを抽出する

UseCaseはユースケースを実現するためのドメインを利用した手続きを書く

それぞれの役割を明確に意識することが重要

これはもちろんアプリケーションの実装ルール次第

それぞれの役割を明確に意識することでUseCaseにドメインロジックが生まれるなどの破綻を回避することができる

MEMO:

必要無いなら省略してもいいと思うけど、構造の一貫性という意味ではあってはいいかもの精神

(2026/01/14)

僕がフリーランスを続けなかった構造的な理由

僕がフリーランスを続けなかった構造的な理由｜すてぃお

要約:

■ 1. 記事の概要

2018年から2019年夏頃までの1年半フリーランスエンジニアとして活動した経験に基づく

フリーランスになってどこかの会社で業務委託として働くスタイルは長期的にはオススメできない

フリーランスとして業務委託で働く形態には経験が積みづらくなる構造的な力学が働いている

個人の努力や能力とは関係なくその構造の中にいると自然とそういう方向に引っ張られる

■ 2. フリーランス時代の振り返り

「経験を切り売りしていた」という感覚が強い

お金は得られたが新しい経験はほとんど積めなかった

社会的な価値も全然つかなかった

市場価値としてはほとんど上がっていなかった

危機感を覚えたのでフリーランスを辞めCTOになった

■ 3. 構造的な問題1: 挑戦させてもらいづらい

業務委託に入ると基本的に「成功しそうなことしか任せてもらえない」状況になる

クライアントからすれば外部の人間に失敗のリスクがある仕事を任せるのは怖い

正社員なら失敗しても一緒に成長していける

業務委託は失敗したら契約を切れば良いので確実にできることしか任せない

正社員は育成投資の対象になれるが業務委託はならない

得られにくい機会:

新しい技術に挑戦する機会

難易度の高いプロジェクトをリードする機会

事業の意思決定に関わる機会

フリーランスエンジニアが「得意なことをやり続ける」状態に陥る

効率は良いが成長はない

■ 4. 構造的な問題2: 社会的な評価が蓄積されにくい

「業務委託として開発」と書いても何をどこまで任されていたのかが見えない

「リードエンジニアとして事業を推進」と書けばオーナーシップを持って取り組んでいたことが伝わる

実際にやっていた仕事の内容が同じでも肩書きと立場で見え方が変わる

フリーランスとして働いている間その経験がどんどん「消費」されていく

正社員として働くとその会社での実績が積み上がり次第により大きな責任を持つポジションに就く

フリーランスの場合いくら長く働いても「外部の人」のまま

■ 5. 構造的な問題3: マネジメントや組織の意思決定に関われない

エンジニアとして成長するには技術力だけでは足りない

ある程度のキャリアを積んだ後は技術以外の能力が重要となる場合が多い

組織としての意思決定/マネジメント経験は組織の中で責任あるポジションに就かないと身につかない

外部の人間に組織のコアな部分を任せることはほとんどの会社がしない

採用の判断/チーム編成/評価制度/組織文化の形成は全て「中の人」だけで行われる

■ 6. この構造が生まれる根本的な原因

企業が「企業内人的資本の最大化」を目指すから

企業内人的資本 = 社員のスキル・知識・経験・ノウハウの総和

企業内人的資本が企業の競争力の源泉になる

正社員に投資すればその成長は企業内に蓄積される

業務委託に投資しても契約が終われば企業外に流出してしまう

正社員を雇う場合は長期的な視点で投資する

業務委託を使う場合は短期的な視点で考える

「投資対象かどうか」の違いが全ての構造的な問題の根源

■ 7. 例外: 労働市場の需給で変わるケース

「需要が供給を大きく上回るスキル」を持っている場合は状況が変わる

希少人材の例:

特定の領域で日本に数人しかいない専門家

世界的に見ても希少な技術スタックの経験者

業界で名前が知られているレベルの実績がある人

オープンソースのメインコミッターなど代替不可能な立場の人

こういった人はフリーランスであっても立場が強い

これは例外中の例外

ほとんどのエンジニアは「できる人が他にもいる」領域で仕事をしている

「自分は希少人材だ」と思い込んでフリーランスになるが実際にはそこまで希少ではなかったケースをよく見る

希少人材で居続けることができるかについてもよく考えるべき

■ 8. 「即戦力」という罠

フリーランスが求められるのは即戦力

即戦力として評価されるのは「今持っているスキル」

新しいスキルを身につける機会ではなく既存のスキルを使う機会を与えられる

最初は問題ないが数年経つと技術は進化する

フリーランスは「今持っているスキル」で契約しているから新しいことを学ぶ機会が少ない

正社員なら会社が新しい技術の研修を受けさせてくれることもある

業務委託は新しいことに挑戦するコストは自分で負担するしかない

「即戦力」として求められ続けることで皮肉にも「戦力としての価値」が下がっていく

■ 9. 社会資本という見えない資産

社会資本とは人間関係や信頼関係を通じて得られる価値

人脈/信用/評判/実績

正社員として働くと社会資本は自然と蓄積される:

同僚との信頼関係

上司からの評価

社内での実績

業界内での評判

昇進による肩書き

フリーランスの場合社会資本が蓄積されにくい

業務委託として入った会社の人との関係は契約が終われば薄れていく

毎回ゼロから信頼を築き直さないといけない

■ 10. 「自由」の代償

フリーランスになる理由として多くの人が「自由」を挙げる

働く時間を自分で決められる/嫌な仕事を断れる/場所を選ばずに働ける

しかしその自由には代償がある:

挑戦の機会を得る自由は失われる

成長する機会を得る自由も失われる

責任あるポジションに就く自由も失われる

表面的な自由と引き換えにキャリアの自由度を失っている

■ 11. 構造から抜け出す選択肢

選択肢1: 正社員に戻る

組織の中で責任あるポジションに就き挑戦の機会を得て社会資本を蓄積する

フリーランスの構造的な問題を根本的に解決する方法

選択肢2: 自分で事業を作る

業務委託ではなく自分のプロダクトを持つ

自分が意思決定者になりリスクも責任も自分が負う

構造的な問題を「逆転」させる方法

選択肢3: 戦略的にフリーランスを使う

長期間続けるのではなく特定の目的のために一時的に使う

キャリアの転換期に複数の会社を経験するため/特定のスキルを集中的に使って実績を作るため/正社員のオファーを見極めるため

強い意志が必要

■ 12. キャリア早期にフリーランスになる人に向けて

20代から30代前半はキャリアの中で最も成長が期待できる時期

この時期に「確実にできることしか任せてもらえない」環境に身を置くのはもったいない

経験の価値は「複利」で効く

20代で得た経験は30代のキャリアに効き30代で得た経験は40代のキャリアに効く

フリーランスで「経験の切り売り」を続けるとこの複利が効かなくなる

10年後/20年後のキャリアを考えた時今どんな経験を積むかは決定的に重要

■ 13. まとめ

フリーランスエンジニアが経験を積みづらくなるのは個人の問題ではなく構造の問題

この構造は「投資対象かどうか」という違いから生まれている

フリーランスになること自体が悪いわけではなく目的を持って期間を区切って戦略的に使うなら問題ない

問題はこの構造を理解せずにフリーランスを続けること

フリーランスを選ぶならこの構造を理解した上で選ぶこと

定期的に「今の自分は成長できているか」「社会資本は蓄積されているか」を問い直すこと

表面的な自由や短期的な収入より長期的な成長とキャリアの自由度の方が結局は大きな価値を生み出す

MEMO:

そもそもフリーランスというのは十分な経験を積んだベテランが選択するものであって、新卒や若手が選択するものではない
成長余地がある＝未熟者がやったところで単純な労働力を提供することしかできない
ベテランは経験則や知見の提供という目に見えない資産を持っていて、それらを提供することが市場価値になる
組織に何かしてもらう、挑戦する機会を与えてもらうと考えている時点でそもそもフリーランスを選択するべきではない
フリーランスに向いているのは「やっぱ組織で仕事するの向いてないな...」となった30代後半から40代の社会不適合者
同じ理由で新卒でSES企業に就職するのも悪手
こちらもフリーランスと同じく役割が固定されがちで経験を積むことが難しい構造なので、若手が選ぶべきではない
そもそもSES企業は案件に人間を放り込めば勝利なところがあるので育成を軽視している企業が大半
要領が悪い者は一生テスターみたいなケースが本当に発生し得る界隈である

AIはなぜTypeScriptのような型付き言語の普及を促進するのか、GitHubが理由を説明

AIはなぜTypeScriptのような型付き言語の普及を促進するのか、GitHubが理由を説明－ Publickey

(2026/01/13)

ChatGPTの登場でサービスがほぼ死んだのに、なぜか収益が2倍になったサービスがある...

ChatGPTの登場でサービスがほぼ死んだのに、なぜか収益が2倍になったサービスがある。

Stack Overflow。開発者なら誰もが世話になったQ&Aサイトだ。

2024年12月、このサイトに投稿された質問はたった6,866件。

16年前のサービス開始直後と同じ水準まで落ちた。Elon Muskが2023年に「death by LLM」と言った通り、みんなChatGPTやCopilotに聞くようになってフォーラムは瀕死状態。

でも面白いのはここから。

フォーラムは死にかけてるのに、会社としてのStack Overflowはむしろ元気になってる。

年間売上は約1.15億ドルで以前の2倍。赤字も8,400万ドルから2,200万ドルまで圧縮された。

何が起きたのか。

彼らは広告モデルを捨てて、全く別のビジネスに転換していた。

1つ目は「Stack Internal」という企業向け生成AIツール。16年分・数百万件のQ&Aデータを活用したもので、すでに25,000社が導入。

2つ目はRedditと同じデータライセンスモデル。AI企業に学習用データを売っている。

CEOのPrashanth Chandrasekarは去年12月にこう語った。

「減ったのは簡単な質問だけ。複雑な問題は今もStackで聞かれる。他に場所がないから。そしてLLMの品質は結局、人間がキュレーションしたデータ次第。うちはその最高峰だ」

つまりこういうことだ。LLMがStack Overflowのトラフィックを奪った。

でもLLMは学習データがないと動かない。Stack Overflowは最高品質のコーディングデータの宝庫。

結果、AIに殺されかけた会社が、AIにデータを売って生き延びてる。

テック業界の皮肉な循環経済。面白い事例。

@masahirochaen

ヒット作連発ゲーム開発者による4つのアドバイス。「チームは最小限に」「価格の決め方」など...

ヒット作連発ゲーム開発者による4つのアドバイス。「チームは最小限に」「価格の決め方」など“持続可能なゲーム開発”の経験則 - AUTOMATON

要約:

■ 1. 記事の概要

インディーゲーム開発者として15年の経験を持つTom Francis氏が4つのアドバイスを公開

Tom Francis氏はインディー開発スタジオSuspicious Developmentsの代表

過去作品:

ステルスパズル『Gunpoint』

宇宙船潜入アクション『Heat Signature』

ターン制戦略パズル『Tactical Breach Wizards』

『Gunpoint』と『Tactical Breach Wizards』はSteamで約1万件のユーザーレビューを得て98%という高い好評率で「圧倒的に好評」を獲得

ゲーム開発における成功の定義:

売上や賞賛の数ではない

快適なペースで次のゲームを開発できるという確信が持てるかどうか

持続可能な形で長期にわたって開発を続けるためのテクニックを紹介

■ 2. アドバイス1: できる限り小規模であり続けること

規模拡大のデメリット:

チームの規模を拡大すれば開発が速く進み成功確率も上がるように思えるが現実は逆になりがち

人員が倍になれば必要な売上も倍になるため単純に成功確率がどんどん減っていく

実体験:

2013年の『Gunpoint』がヒットした後に開発規模を大きく上げていたら次作は駄作となりその後はリリースできなかっただろう

2017年リリースの『Heat Signature』は開発が難航

開発期間が短ければひどい状態でリリースせざるを得なかった

ゲームが良い状態になるまでテストと開発を続けられるだけの規模を保ったからこそ変わらずにヒット作をリリースし続けられた

昨今のゲーム業界におけるレイオフについて:

人員増加によってレイオフやスタジオの閉鎖が起こるのであれば本当の意味の雇用創出にはなっていない

情勢に左右されにくいという面でも小規模な開発を続けることは効果的

■ 3. アドバイス2: 短期間で試作品を作れる企画を選ぶこと

プロトタイプの定義:

単なる技術検証に限らず「ゲームの良さが伝わる最低限の形」を指す

最終的なビジュアルのクオリティを想定したアート重視のプロトタイプ

ストーリーの冒頭を構築したナラティブのプロトタイプなども含まれる

プロトタイプのメリット:

結果によって残りの時間の使い方が明確になる

ゲームがどこに向かっているのかチームで確認できる

プロトタイプの重要な条件:

プロトタイプを作るだけで何年もかかるのであればプロトタイプの役割を果たさない

ゲームのアイデアが機能するかを方針を変える時間があるうちに確かめることが目的

失ってもいい時間の中で作れるかどうかが重要

どんなに素晴らしいアイデアでもプロトタイプ化できないならばインディーゲーム向きではない可能性がある

プロトタイプを作ってあらかじめ「安全確認」をおこなうことはリスクを避けるための鍵

■ 4. アドバイス3: テストの重要性(特効薬)

テストは時間も手間もかかるがテスト不足のまま発売することほど高くつくものはない

「ゲームを良くする」段階に時間を取れない場合には大きな問題になる

テストの進め方:

まずは社内向けのプロトタイプをほかの人が遊べる形にする

最初は少人数のテストでも構わない

少人数テストで得られるフィードバックは真に受け過ぎず深刻な問題などを修正するために利用する

コンテンツが揃っていなくとも大規模なテストを実施することを推奨

目安は100人以上/多ければ2000人規模

フィードバックの集め方:

Googleフォームを用いてフィードバックを集める

10点満点でゲームを評価してもらう

ゲームを本気で嫌っていた人の文句なのか解決しやすそうな小さな不満なのかをフィルタリングできる

人々がプレイしている様子を直接見るテストも重要:

『Heat Signature』では物理法則に基づく宇宙船の動きの制御に苦戦するプレイヤーが多いことを知り便利な機能の追加に繋げることができた

奇抜なゲームを作りたい人ほどテストをするべき:

テストはプレイヤーに何を変更するべきか訊いて仕方なくそれに従うものではない

最終的に決定を下すのはゲームデザイナーである自分自身

テストの質問も自分で決められるため達成したい目標に合わせて質問を調整することも大事

■ 5. アドバイス4: 価格設定について

売上を決める3要素:

ストアページを訪れる人数

購入したくなるかどうか

価格

価格だけは時間をかけずに簡単に変更でき一回のテストによって適正値を探れる

価格決定の方法:

テスターに「いくらなら妥当だと思うか」を尋ねる

一番多くの人が選んだ値で価格を決める

この方法でいずれの作品も高い評価と売上を得られた

「これだけ苦労したのだからもっと高く売りたい」という考え方には否定的:

開発者が売るゲームのコピーには原価がかからない

販売ターゲットになるユーザーは実質無限

価格を上げてもその分販売本数が減れば収益は変わらない

レビューの好評率や口コミの盛り上がりが削がれる可能性もある

重要なのはプレイヤーが納得して払うことのできるゲームの「適正価格」を見極めること

「底辺への競争」への懸念について:

PCのインディーゲームの価格を注視してきた22年間を通して一度も価格が下がったことはない

近年ではどの価格帯でも成功や失敗が起こる

開発者の増加とともに競争やノイズも増加

価格を決める際には周囲の傾向に左右されるべきでない

■ 6. 総括

Francis氏のアドバイスは限られた資金と時間の中で「ゲームを作り続けるための現実的な考え方」

良いゲームを作っても必ずヒットするわけではないが出来の悪いゲームを作れば確実にヒットから遠ざかる

大規模なヒットの可能性を上げるためにはマーケティングなどが噛み合うかどうかも関係してくる

プロジェクトが小規模であるほど利益を出すために求められる売上も少なくなり「成功」を掴みやすくなる

近年では市場に膨大なインディー作品があふれており「Indiepocalypse(インディーポカリプス)」という言葉も登場

競争は年々激化しインディーゲーム開発者を取り巻く環境が厳しさを増す中で長年スタジオを存続させてきた開発者の経験談は道標になる

(2026/01/13)

50代ベテランゲームデザイナーが傍若無人を行い、若い芽を摘みまくる現場で行った戦いをプロデューサー...

50代ベテランゲームデザイナーが傍若無人を行い、若い芽を摘みまくる現場で行った戦いをプロデューサー視点で書く（ゲーム in the ノンフィクション）｜うきょう|フリーゲームプロデューサー兼マーケッター（株スタジオデルタ代表）

要約:

■ 1. ゲームデザイナーとは

ゲーム全体をデザインする職種

「ゲーム」という媒体を通して作り手側がイメージするユーザー体験までを作り上げる非常にテクニカルかつアーティスティックな業務を担う

業界の熟達者であり知識が豊富で年齢を重ねていることが一般的

日本では「ゲームデザイナー」という職種がある会社はあまり存在しない

ゲームデザイナーを自称する人の特徴:

他の技術や知見に対しても優れていることが多い

非常にプライドが高い傾向

自己愛が強すぎる

他人に対して攻撃的な人が多く権威者に弱い

若手の企画者を極端に小馬鹿にしている姿勢が強い

■ 2. 問題のベテランゲームデザイナーの事例

50代のベテランで「リードプログラマ兼ゲームデザイナー」を名乗る人物

40名のチームで社員プログラマが3名しかおらず業務委託プログラマが5名という異常な構成

会議での問題行動:

「この企画ダメじゃね?」「この仕様って何の意味があるの?」「それオレはやらない」「この本読んだ?これぐらい読んどけ」などの発言

会議の場が凍る

正論だが利用可能なリソースと技術力が無視されたコメントが多い

ゲームデザインセンスがないやつは企画をするべきではないという話になる

役員が参加すると一切発言しない

会議で何も言わなかった項目について後から「オレはこの仕様がいいと思っていない」と言い始める

■ 3. ベテランの問題行動の特徴

他人の仕事を全否定する

自分で責任をとらないポジションだけを選び続け管理しない

無用なものは切り捨てるのでチーム内で下についた者で無用と思われた者は放置される

業務委託のプログラマの仕事も監修すると言い出しアウトプットが減る

自分の美学を貫き通すがチームのスケジュールや目標には配慮しない

■ 4. チームへの影響

チームの空気が悪くなり遅刻/欠席が多くなる

傍若無人に振る舞う人ほど長居するし健康体(ストレスが少ないため)

若いデザイナー/若い企画者がそのベテランと関わると次々と体調不良で休む

仲介役を挟んでも仲介者が退職する

役員レベルも「8年前から入社してずっとあんな感じ」「みんなダメだった」と放置状態

■ 5. 耐えられる人のパターン

ほぼ干渉せずに業務範囲を明確に区分している人

悟りを開いている人

自分自身の業務責任を責務として請け負えるタイプで自分から提案はしない人

配属されるプログラマは皆辞めるか他部署への異動依頼を出す

■ 6. プロジェクトの結末

形だけリリースしたがうまくいかなかった

機能が足りなすぎてゲームとして成り立っていない

ベテランは「オレならもっと良くできた」と発言

部署を2つに分けベテランチームと既存サービス運営チームに分離

ベテランがいないチームは士気と活気が戻りプロジェクトの業績が上がり始めた

ベテランが在籍するチームは何も新しいものが生まれないまま2年経過し解散

ベテランは最後まで退職をしぶったが会社と交渉して退職

■ 7. 反省点と教訓

部下が育たない事例や自分の価値観とそぐわない人と協調がうまくできずにパワーでねじ伏せるタイプの人は非常に多い

ベテランの知識や知恵をわかりやすい形で共有できる工夫ができれば良いクリエイティブの方向にできたかもしれない

ベテランは「当人が努力すること。それぐらい知ってて当然」というスタンスだったため真のゲームデザインが誰にも伝わらなかった

責任を回避する行動が多く意見だけを言う姿勢はチーム開発においてマイナス

理不尽な人の側で働き続けて業界を引退した人は数知れない

■ 8. グラフィック部門での類似事例

ベテランのグラフィックリーダーがいるチームでその下のグラフィックメンバーがことごとく退職

言語化が極めて苦手で部下に対する指示がめちゃくちゃかつ訳がわからない箇条書きだけ

他人の仕事を取り上げて自分で修正または作り直しを繰り返した結果チームメンバーは自分の存在価値に自信を失い休職/離職が多発

グラフィックリーダーを別の部署へ異動させた

■ 9. デザインするとは何か

「ヒト/モノ/情報/サービスを何かの媒体で体験できる形に作り上げ利用した人が特定の感情/体験/経験までを得られるようにすること」

作り手側がある程度狙って創造していることを具現化/体現化/提供するまでの品質を担保すること

■ 10. ゲーム開発の現場への提言

大切にしたいのはいい人と付き合うこと

人生をすり減らす人と付き合ってはいけない

有益な知識や経験が手に入るかもしれないが短命で終わる意味はない

できる限り長く創作活動ができること

評価してくれる環境に身を置くこと

自分の環境を良くするための努力を惜しまないこと

決して泣き寝入りだけはしないでほしい

(2026/01/12)

React 19でつくる「気持ちいいUI」- 楽観的UIのすすめ

React 19でつくる「気持ちいいUI」- 楽観的UIのすすめ - Speaker Deck

(2026/01/12)

MSXは範囲を広げすぎに対しての理由説明　時系列で　30年前のアーキテクチャを甦らせるなんて無理と...

MSXは範囲を広げすぎに対しての理由説明

時系列で

30年前のアーキテクチャを甦らせるなんて無理と10年前まで思っていました

でもIoTになら使えるとMSX0を大学で始めました

同時に次世代MSX3も始めました

オープンソフトウェアのlinux系にCPUは当初ArmでしたがオープンCPUのRiscVに変更しました

そして気が付きました

今までの未完成なMSXを完成させなければならないと

それがMSX2++とMSX#です

あとMSXboosterというMSX1とMSX2,2+に対してハードウエアとソフトウェアのアップグレードを研究中です

そしてMSXのAi

1.Aiを使って他からの移植や新しいソフトウェアを簡単に創るということと

2.Aiそのモノを勉強するという切り口

ならAiをMSXでやることの意味もあると思いました　安ければ

あとはエミュレータとWeb

沢山の人にMSXに出会って貰い

試しに使ってもらえるようにしたいということで、やりますタダです

以上再確認させて頂きました

@nishikazuhiko

(2026/01/12)

AIのせいでAIの学習データがなくなってきている

AIのせいでAIの学習データがなくなってきている - きしだのHatena

ニューヨーク市長就任式、ラズパイとFlipper Zeroを名指しで持ち込み禁止――武器や爆発物と同列に

ニューヨーク市長就任式、ラズパイとFlipper Zeroを名指しで持ち込み禁止――武器や爆発物と同列に - FabScene（ファブシーン）

ニューヨーク市長就任式、ラズパイとFlipper Zeroを名指しで持ち込み禁止――武器や爆発物と同列に

2026年1月1日に開催されたニューヨーク市長Zohran Mamdani氏の就任式で、Raspberry PiとFlipper Zeroが持ち込み禁止品に指定された。公式サイトに掲載された禁止リストでは、武器、花火、爆発物、ドローンなどと並んで、2つのデバイスがブランド名で明記されている。

Flipper Zeroは、RFID、NFC、赤外線、Bluetooth、無線信号などの通信プロトコルを学習・テストするためのハンドウェアデバイスだ。セキュリティ研究者や開発者に利用されている一方、車両盗難やネットワーク侵入への悪用が懸念され、各国政府から規制の対象として議論されてきた。Amazonも過去にカードスキミングへの懸念から販売を禁止した経緯がある。

一方、Raspberry Piは教育用途から産業用途まで幅広く使われる汎用のシングルボードコンピューターで、教室、報道機関、アート作品、アクセシビリティ機器など多様な場面で採用されている。

禁止リストが公開されると、技術コミュニティから疑問の声が上がった。ノートパソコンやスマートフォンは禁止されていないにもかかわらず、これらはRaspberry PiやFlipper Zeroよりも高機能で、同等以上のことが可能だからだ。セキュリティ専門家のStefan Klatt氏はX（旧Twitter）で、銃器やドローン、ガラス瓶といった危険物と並んで、IT機器2種が名指しされている点を指摘した。

Adafruitの創業者Phillip Torrone氏は、カテゴリーや機能ではなくブランド名で特定のデバイスを禁止するのは異例だと述べ、市長チームに禁止理由を問い合わせた。AIがリスト作成に関与したかどうかも質問したが、回答は得られていないと同社のブログで述べている。

Torrone氏は、今回Raspberry PiとFlipper Zeroが禁止されるなら、次はBeagleBone、Arduino、ESP32開発ボード、SDRドングル、さらにはマイコンを内蔵した腕時計まで禁止対象になりかねないと懸念を示した。

就任式はシティホールでの宣誓式に続き、ブロードウェイで4万人規模のブロックパーティーとして開催された。Bernie Sanders上院議員やAlexandria Ocasio-Cortez下院議員らが登壇している。

MEMO:

警備チームの中で情報が錯綜して「よく分からんけど禁止！」みたいな雑ルールになった可能性ありそう

(2026/01/11)

「Googleでの14年間で学んだ21の教訓」を個人的な解釈でまとめてみた

「Googleでの14年間で学んだ21の教訓」を個人的な解釈でまとめてみた #初心者 - Qiita

要約:

■ 1. 記事の概要

Googleで14年間Chromeに携わり現在はGoogle Cloud AIでディレクターを務めるAddy Osmani氏が経験から学んだ教訓をまとめたブログの解説

技術的なTipsではなくエンジニアとして無理せず長く続けていくための実践的な知恵が詰まっている

原文は「21 Lessons From 14 Years at Google」

■ 2. 21の教訓

教訓1: 技術ではなく「ユーザーの困りごと」から始める

「この技術どこで使おう?」ではなく「ユーザーは何に困ってる?」から考える

問題を本当に理解しているエンジニアは解決策が予想よりシンプルであることに気づく

教訓2: 正論で勝っても意味がない

議論に勝ってもチームの協力が得られなければプロジェクトは進まない

「強い意見を弱く持つ」— 不確実な状況での決定を自分のアイデンティティにすべきではない

教訓3: 考えすぎる前に手を動かす

完璧な設計を考え続けて何も作らないより雑でもいいからまず作る

「まず作る→直す→良くする」の順番

教訓4: 「賢いコード」より「読みやすいコード」

深夜の障害対応で読むのは未来の誰か

明快さはスタイルの好みではなく運用リスクの低減

教訓5: 新技術の導入は「借金」と同じ

導入するたびに「学習コスト」「採用難」「トラブル時の情報不足」という借金を背負う

独自に報酬を得ている場所でだけイノベーションしそれ以外は退屈でいい

教訓6: 良い仕事も伝わらなければ存在しないのと同じ

自分がいない場で誰もあなたの成果を説明できないならその成果は実質オプション

自己宣伝ではなく価値の連鎖を「読める」ようにしておくこと

教訓7: 最高のコードは「書かなかったコード」

書いたコードは全部将来のバグ/保守/説明の対象になる

問題は書くのが上手すぎて書くべきかどうかを問うのを忘れること

教訓8: 大規模になるとバグにもユーザーがつく

ユーザーが増えるとバグや癖を前提にした使い方をする人が出てくる

互換性作業を「メンテナンス」新機能を「本当の仕事」として扱うことはできない

教訓9: 遅いチームは実は「ズレてる」チーム

本当の原因は方向性や優先順位がチーム内で揃っていないこと

シニアの仕事は「速く書く」より「認識を揃える」こと

教訓10: 変えられないことは気にしない

自分がコントロールできることだけに集中する

受動的な受容ではなく戦略的なフォーカス

教訓11: 抽象化は複雑さを「後回し」にしているだけ

便利なライブラリやフレームワークは「中身を知らなくていい」という賭け

シニアエンジニアはスタックが高くなっても「低レベル」のことを学び続ける

教訓12: 教えると自分の理解が深まる

人に説明しようとすると自分が曖昧に理解していた部分が見つかる

アウトプットは最高のインプット

教訓13: 「縁の下の仕事」は大事だが見えないと評価されない

ドキュメント整備/新人教育/チーム間の調整は不可欠だがただの「お人好し」で終わりやすい

性格特性ではなくインパクトとして可視化する

教訓14: 議論で全勝してるなら裏で反感を買っている

相手は納得したのではなく諦めただけかもしれない

正しいという短期的な感覚は意欲的な協力者とものを作る長期的な現実よりはるかに価値が低い

教訓15: 指標は「目標」にした瞬間意味を失う

人は測定されるものを最適化する

スピードと品質両方の指標をセットで見ることが大事

教訓16: 「わからない」と言えることがチームを安全にする

シニアが知ったかぶりをすると若手は質問できなくなる

最もシニアな人が混乱を認めないチームでは質問は出ない

教訓17: 人脈はどの仕事よりも長く続く

関係を築いた人は何年後かに機会を運んでくれる

打算ではなく好奇心と誠実さで人と繋がる

教訓18: 速くするには「やらないこと」を増やす

一番効くのは「そもそもこの処理いる?」と削ること

最適化する前にその仕事がそもそも存在すべきかを問う

教訓19: プロセスは「安心のため」ではなく「不確実性を減らすため」

目的を説明できないプロセスは見直す

最悪のプロセスは助けるためではなくうまくいかないときに責任を割り当てるために存在する

教訓20: いつか「時間＞お金」になる

何を差し出しているか自覚して選ぶ

時間は再生不可能な資源

教訓21: 近道はない。でも「複利」はある

一発逆転を狙うより毎日少しずつ学んで積み上げる方が強い

学習は単なる新しい雑学ではなく新しい選択肢を生み出すときに複利になる

■ 3. まとめ

21の教訓は3つに集約される:

好奇心を持ち続ける — 学ぶことをやめない

謙虚であり続ける — 「わからない」と言える/一緒に答えを探す

人を忘れない — ユーザーのために作りチームと一緒に作る

尊敬すべきエンジニアは常に正解を出した人ではなく失敗から学び気づきを周りと分かち合い諦めずに現場に立ち続けたエンジニア

最終的には「どうすれば自分をすり減らさずにこの仕事を長く続けられるか」を教えてくれるもの

(2026/01/11)

APG Patterns Examples

パターン | APG Patterns Examples

WAI-ARIA APG パターンを React、Vue、Svelte、Astro で実装したアクセシブルな UI コンポーネントとテストを提供します。簡潔な実装例と検証可能なテストで、アクセシブルなインターフェース構築を支援します。ダークモード、ハイコントラスト、強制カラーモードにも対応しています。✨

(2026/01/11)

経営者が知るべき、なぜエンジニアの「合理的な判断」が事業を圧迫するのか

経営者が知るべき、なぜエンジニアの「合理的な判断」が事業を圧迫するのか｜すてぃお

要約:

■ 1. 問題の概要

個人としては合理的な判断が組織として見た場合に非合理な判断となり事業を圧迫する

よくある相談内容:

開発に時間がかかりすぎる

サーバーコストが高いのではないか

新機能追加のたびに想定以上の工数がかかり見通しが立たない

月間数百/数千ユーザー程度のサービスに対して規模に明らかに過剰な状態となっていることが多い:

複雑な運用が必要な大規模向けの構成

最新技術が多数導入され全体の見通しが悪い

ほとんど負荷がないのにキャッシュ層が導入されている

データベースは大きめのサーバーで複数拠点での冗長構成

エンジニアの能力不足ではなく個人として合理的に行動した結果意図してこのような状態にしている可能性がある

個人の問題ではなく構造的な問題

■ 2. 原因1: 転職市場が生む「キャリア最適化」のインセンティブ

転職市場での評価:

3年間安定したシステムを堅実に運用しパフォーマンスを最適化した経験より1年で最新技術を使った新しいシステム構築をリードした経験の方が年収が上がりやすい

「事業に必要かどうか」より「履歴書に書けるかどうか」が優先される構造

評価されるのは「ポータブルなスキル」:

最新技術の導入経験

有名な技術スタックでのシステム構築実績

業界標準とされる開発手法の経験

評価されにくいもの:

自社サービス固有の知見

チーム独自のノウハウ

結果として生まれる構造:

月間利用者数が少ないサービスでも大規模構成

小規模チームで複雑なシステム分割

シンプルな構成で十分な規模で最先端技術を導入

■ 3. 原因2: 成功企業の事例を真似する罠

技術カンファレンスやブログで目にするのはメルカリ/freee/エムスリーのような成功企業の事例

「最新技術で組織をスケールさせた」「マイクロサービス化で開発速度を向上させた」という事例は極めて特殊な前提条件の上に成り立っている

彼らにとっての「複雑なシステム」は組織のスケールに対する解決策であって技術的な理想形ではない

「成功企業のやり方=正解」という空気が規模に合わない設計を正当化してしまう

■ 4. 原因3: "絶対に落とさない"に対してのコスト

「システムが止まったら困るから念のため」という思考が過剰な構成を生む:

複数拠点での冗長構成を初期から導入

サーバーは「大きめ」で確保

全システムを最高レベルの安定性で設計

将来の負荷に備えて先行投資

月間数千ユーザーのサービスに月間数百万ユーザーに対応できる構成

「念のため」という言葉で正当化されるが経営的には大きな機会損失

余剰コストで本来は新機能開発や顧客獲得に投資できたはず

■ 5. 対策1: 「キャリア最適化」のインセンティブに対して

「シンプルに保つこと」を評価項目に追加:

新技術導入だけでなく技術的負債の削減も評価

「コスト削減に成功した」を実績として認める文化

長期的な運用/改善を正当に評価

技術選定の意思決定プロセスを明文化:

「なぜこの技術を選ぶのか」を意思決定プロセスに組み込みドキュメント化

事業的な必要性を説明できることを前提とする

外部の目を入れる:

技術顧問やアドバイザーによる定期的なレビュー

「今の規模に本当に必要か」を客観的に判断

■ 6. 対策2: 成功企業の事例を真似する罠に対して

小さく始めて段階的に拡張する原則とする:

初期フェーズはシンプルな構成でスタート(1つのアプリケーション/基本的なデータベース構成/最低限の監視/目標レベル99.5〜99.9%)

成長に応じた3段階の拡張ステップを想定:

ステップ1: まず最適化(クエリ最適化/インデックス追加/キャッシュ導入/N+1問題の解消)

ステップ2: サーバー性能アップ(CPU/メモリの増強/スケールアウト)

ステップ3: システム分割(マイクロサービス化/専門チームの配置)

多くの場合ステップ1〜2のみで十分対応できる

「今の規模」に最適化する文化を作る:

「最初から完璧」ではなく「必要になったら拡張」を原則とする

各段階のコスト対効果を明確にし拡張のタイミングを事前に合意

「早すぎる最適化」を避ける文化を醸成

成功企業の規模と自社の規模の違いを認識

■ 7. 対策3: "絶対に落とさない"に対してのコストに対して

「どれだけ止まっていいか」を経営判断として決める:

「止めない」ではなく「どこまで止まっていいかを最初に決めること」が重要

99.9%稼働率ということは月43分程度は止まる可能性があるということ

止まってはいけないということはリスクを取りづらくなるコストが存在する

システム内で優先順位をつける:

ユーザーが見る画面やクライアントが常に使っている機能については落ちづらくしておく

社内で使用する管理画面などは落ちても問題ないとする

ユーザーやクライアントに直接影響する機能と社内でしか使わない管理機能を同じレベルで守る必要はない

■ 8. 結論

エンジニアが個人として合理的に動いた結果事業が後退してしまうのは構造的なインセンティブの帰結

「うちのエンジニアは大丈夫」と慢心せずに対策していくことを推奨

最高なのは個人の合理性と組織の合理性を一致させること

それを思わせるのが経営者の役割

エンジニアと経営者が同じ方向を向いて判断できる組織は強い組織

MEMO:

スタートアップでは技術が福利厚生みたいなところはあるけど、後先考えないエンジニアもかなり多い

(2026/01/11)

stoolap - Rustで実装された組み込みRDB

GitHub - stoolap/stoolap: A Modern Embedded SQL Database written in Rust

Why Stoolap?

Stoolap is a feature-rich embedded SQL database with capabilities that rival established databases like PostgreSQL and DuckDB - all in a single dependency with zero external requirements.

なぜスツールアップなのか?

Stolapは、PostgreSQLやDuckDBといった既存のデータベースと競合する機能を備えた、機能豊富な組み込みSQLデータベースであり、すべて外部要件がゼロの単一の依存関係にあります。

(2026/01/11)

Linus、「AIツールはただのツール」とあらためて強調

Linus、「AIツールはただのツール」とあらためて強調 | gihyo.jp

要約:

■ 1. 背景

AIツールによるコーディング支援が広く普及

LinuxカーネルコミュニティでもAIツールが生成したコードの扱いについて議論が継続

Linus Torvaldsは一貫して「AIツールも単なるツールのひとつ」という態度を維持

■ 2. カーネルガイドラインの策定

x86アーキテクチャメンテナーのDave Hansen(Intel所属)が中心となりガイドライン作成が進行

正式名称は「ツール生成コンテンツに関するカーネルガイドライン(Kernel Guidelines for Tool-Generated Content)」

2025年1月6日に第3版を公開

ガイドラインの目的:

カーネル貢献者は長年ツールを使用して貢献を生み出してきた

ツールは貢献の量を増やすがレビュー担当者とメンテナーのリソースは限られている

貢献のどの部分が人間によるものでどの部分がツールによるものかを理解することが重要

ツールに関するコミュニティの期待を明確にすることがゴール

ガイドラインには「AIツール」「LLM」といった用語は含まれていない

■ 3. メンテナー間の意見対立

Lorenzo Stoakes(Oracle所属/メモリマネジメント分野メンテナー)の主張:

LLMは単なるツールではなくまったく新しいツール

LLMによるAIスロップ(低品質な生成AIコンテンツ)がエンドツーエンドで大量に送信されることはこれまでできなかった

AIスロップがパッチとして送られてきた場合に議論なく却下できることをドキュメントで明確に表明すべき

LLMを「単なるツール」とすることはカーネルがLLMの問題にまったく影響を受けないと言っているようなもので愚かなポジションに見える

■ 4. Linus Torvaldsの反論

AIスロップについて議論することにはまったく意味がない

AIスロップを作って送ってくる連中は自分のパッチをドキュメント化しようとは思わない

ドキュメント作成は善良な人々のためのものでありそれ以外を対象にするのは無意味

カーネル開発に関連するいかなるドキュメントもAIに関する声明のようなものになることを望まない

AIに関しては「空が落ちてくる」という主張と「ソフトウェアエンジニアリングに革命を起こす」という主張がありそれぞれに賛同者がいる

カーネル開発ドキュメントがそのいずれの立場もとることを望まない

AIツールを「単なるツール(just a tool)」という表現に留めておきたい

AIスロップの問題はドキュメント化によって解決するはずもない

それを信じる人は世間知らずか自分の意見を主張したいだけの人

■ 5. 現状の見通し

生成AI/LLMはこれまでの開発ツールと異なりパッチにAIスロップが増えることに危機感を持つメンテナーも存在

当面はカーネル開発におけるAIツールは「単なるツール以上でも以下でもないもの」として位置づけられる見込み

(2026/01/10)

『Balatro』も採用したシンプルな2Dゲームフレームワーク「LÖVE」とは。エンジニア目線で魅力を解説

『Balatro』も採用したシンプルな2Dゲームフレームワーク「LÖVE」とは。エンジニア目線で魅力を解説｜ゲームメーカーズ

要約:

■ 1. Love2dの概要

Luaで記述する2Dゲームフレームワーク

zlib Licenseで配布されており商用利用含め完全無料

対応OSはWindows/macOS/Linux

オープンソースのためエンジン運営状況に左右されない

提供機能:

画像/音声の読み込みと再生

キーボード/マウス/ゲームパッドの入力処理

図形やテキストの描画

シーン管理やUIなど高レイヤー機能は含まれない

必要な機能は自作またはコミュニティのライブラリを使用

■ 2. Love2dの魅力

コードだけで完結する開発体験:

IDEが不要

好きなテキストエディタとターミナルだけで開発可能

開発環境を自分好みにカスタマイズ可能

Lua言語の特徴:

構文がシンプルで学習しやすい

プログラミング経験があれば数時間で基本習得可能

配列が1から始まる/endでブロックを閉じるなど独特な部分あり

LuaJIT採用により動的言語でありながら高い実行速度を実現

C/C++ライブラリとの連携が容易

採用実績:

2024年発売の『Balatro』は1か月で100万本以上を売り上げ

開発者は複雑なIDEを備えたゲームエンジンを避けたかったと発言

■ 3. 他の2Dゲームフレームワークとの比較

静的型付け言語のフレームワーク:

Raylib(C言語)/MonoGame(C#)/Ebitengine(Go)/DXライブラリ(C++)

型安全性のメリットあり

スピード重視のプロトタイピングには動的型付け言語が有利

JavaScriptライブラリ:

Phaser.jsなど

Webブラウザ実行に特化

インストール不要でスマートフォンでもすぐに遊べる

デスクトップアプリケーション配布には不向き

Love2dの立ち位置:

デスクトップ向け2Dゲームを素早くプロトタイピングしながら開発したい場合に適合

■ 4. Love2dのデメリット

3D機能の制限:

2D専用設計のため3Dゲーム開発は基本的に不可能

将来的に3D要素を追加する可能性があるプロジェクトには不向き

日本語情報の少なさ:

公式ドキュメントは英語中心

日本語チュートリアルや解説記事は限定的

公式Wikiは充実しているため英語に抵抗がなければ問題なし

エコシステムの規模:

UnityやUnreal Engineと比べて小さい

アセットストアやプラグインは期待できない

多くの機能を自前で実装する必要あり

UIライブラリがないためボタンやスライダーなどを自作する必要あり

大規模プロジェクトの構造化:

Luaは柔軟性が高い反面設計規約やアーキテクチャの統一が重要

適切な設計なしでは保守性が低下するおそれあり

■ 5. 総括

Love2dは2Dゲーム開発に必要な基本機能だけを提供するフレームワーク

UnityやUnreal Engineとは対極の設計思想

コードベース開発を好む開発者や使い慣れたテキストエディタで開発したい開発者に魅力的

『Balatro』の成功が示すようにツールの機能の豊富さではなくアイデアと実行力がゲーム開発の本質

Love2dの軽快な開発体験はこの本質に集中することを可能にする

(2026/01/10)

Tailwind CSSの騒動から考える、生成AIがOSSビジネスを壊す瞬間

Tailwind CSSの騒動から考える、生成AIがOSSビジネスを壊す瞬間 - Sweet Escape

要約:

■ 1. Tailwind CSSの騒動の概要

Tailwind CSSはオープンソースで提供される人気のCSSフレームワーク

公式ドキュメントをLLMフレンドリーにするためのPRが作成された

Tailwind LabsのAdam氏が深刻な現状を公表:

生成AIの普及により公式ドキュメントへのトラフィックが激減

従業員の75%をレイオフ

トラフィックは40%減

売上は80%減

■ 2. Tailwindのビジネスモデル

Tailwind CSS自体はOSSで無料

収益源は公式が提供する有料UI資産(現在はTailwind Plus)

Tailwindを使ったUIコンポーネントやテンプレートをワンタイム課金で提供

ビジネス構造:

OSSで利用者を増やす

公式ドキュメントや設計思想への理解を通じて信頼を獲得

その延長線上で有料の公式プロダクトを購入してもらう

■ 3. 問題の本質

「OSS → ドキュメント → 有料プロダクト」という売上ファネルの入り口が死んだこと

従来の行動パターン:

何かを調べる

公式ドキュメントを読む

公式サイトにアクセスする

生成AI普及後の行動パターン:

AIに聞いてその場で完結する

ドキュメントやサイトへのアクセス流入を前提に成立していたビジネスモデルにとって致命的

■ 4. OSSビジネス全般への影響

一般的なOSSを軸にした企業のビジネスモデル:

OSS本体は無料

有料SaaS版/有料サポート/マネージド版などで収益化

ドキュメントや公式サイトでユーザーを獲得

多くのOSSビジネスは「OSS × 情報提供(ドキュメント)」を起点にしたファネルに依存

生成AIは「情報提供」の部分を根こそぎ代替してしまう可能性が高い

有料サポートや実装支援も生成AIに代替されるケースがある

■ 5. /llms.txtが突きつけるジレンマ

LLMにドキュメントを読みやすく提供する行為:

OSSプロダクトの認知を広げるための生存戦略である一方

自分たちのサイトに人を呼ばない施策にもなる皮肉な構造

AIに最適化すればするほど人間のユーザーが公式サイトに来なくなる

最適化しなければAI経由の情報流通から取り残される可能性がある

「OSS × コンテンツ × 集客」で成り立っていた企業すべてが直面しうるジレンマ

■ 6. OSSを使う側としての対応

無料で使えるOSSが持続可能であるという前提は生成AIによって静かに壊れ始めている可能性

対応策:

仕事で使っているOSSやその周辺エコシステムには意識的にお金を払う

有料プロダクトやスポンサー制度があるなら「必要になってから」ではなく「支えるため」に選択肢に入れる

Tailwind CSSに関してはVercel社がスポンサーシップに名乗りをあげるなど複数社が支援を表明

■ 7. 今後の展望

今回の件はTailwind Labsのビジネスモデルで顕在化した問題

生成AIが「知識へのアクセス」「学習の導線」「公式情報の価値」そのものを変えた

同じ構造のOSSビジネスが今後も無事でいられる保証はない

悲観論ではなく前提条件が変わったという認識が必要

OSSを作る側も使う側もこの変化を正面から考える段階に来ている

MEMO:

これはプロダクトの運営や維持が更に少人数で可能になったという話なのでは？

(2026/01/10)

Remix v3とReactのトレードオフを徹底考察：AI時代に再評価される「Web標準」への回帰

Remix v3とReactのトレードオフを徹底考察：AI時代に再評価される「Web標準」への回帰 | レバテックラボ（レバテックLAB）

要約:

■ 1. 記事の問題提起

Webアプリケーションの開発を続けていると「いつの間にかフレームワークの学習ばかりしている」と感じたことはないか

ReactであればuseEffectの依存配列を正しく書くために時間を費やし状態管理ライブラリの選定で悩みサーバーサイドレンダリングの設定ファイルと格闘する

本来はユーザーに価値を届けるためのアプリケーション開発に集中したいはずなのにフレームワーク固有の知識やベストプラクティスの習得に多くの時間を取られてしまう

この課題はフレームワークが「厚く」なることで生まれる

多機能で便利な反面学習コストが高くWeb標準から遠ざかった独自の概念が増えていく

その結果フレームワークの外で培った知識が活かしにくくなりフレームワークのバージョンアップのたびに学び直しを強いられることになる

■ 2. AI時代における課題の深刻化

AIツールが普及した現代ではこの問題はより深刻である

ChatGPTやGitHub Copilotといったツールはシンプルで標準的なコードほど正確に理解し適切な提案をしてくれる

しかしフレームワーク固有の複雑な概念や暗黙の前提が多いコードではAIの支援が十分に機能しないことがある

■ 3. Remix v3による解決策

こうした課題に対して2025年5月28日のブログ記事「Wake up, Remix!」で予告されたRemix v3はまったく異なるアプローチを提示した

それが「薄いフレームワーク」という選択である

Remix v3はかつてReact Routerに吸収されて姿を消したRemixというブランドを復活させWeb標準へ回帰する新しいフレームワークとして生まれ変わった

■ 4. Remix v3の設計原則

Remix v3の設計はいくつかの原則に基づいている

その中核となるのが「Web標準の上に構築する(Build on Web APIs)」という原則である

バンドラーやコンパイラへの依存を避け依存関係を最小化し単一目的で置き換え可能な抽象化を提供する

これらの原則により独自の概念を増やすのではなくWeb標準のAPIを最大限活用することで学習コストを下げ長期的な保守性を高める設計が実現されている

本稿ではRemix v3の特徴を理解するためにランタイム非依存・React非依存・手動リアクティビティという3つの側面に着目する

■ 5. 薄いフレームワークの意味

Remix v3が目指す「薄いフレームワーク」とは単に機能が少ないという意味ではない

むしろフレームワーク自身が提供する独自APIを最小限に抑えWeb標準のAPIを積極的に活用することで開発者が既に持っている知識を最大限活かせる設計を指す

これはRemix v1から一貫して受け継がれてきた哲学でもある

Remix v1は「Web標準を活かす」というメッセージを掲げformタグやHTTP標準を尊重した設計で注目を集めた

しかしv1/v2はReactへの深い依存など特定の技術スタックへの結びつきが強い面もあった

Remix v3はこの哲学をさらに推し進める

■ 6. 薄いことの重要性

なぜ「薄い」ことが重要なのか

第一に学習コストが大幅に下がる

Remix v3を学ぶことはWeb標準を学ぶことと同義である

新しいフレームワーク固有の概念を覚える必要はなく既にHTMLやJavaScriptの知識があればすぐに理解できる設計になっている

第二に長期的な保守性が向上する

Web標準はW3CやWHATWGといった標準化団体によって管理され後方互換性が重視される

フレームワーク固有のAPIはバージョンアップで破壊的変更が起きるリスクがあるがWeb標準ベースの設計ならそのリスクを大幅に減らせる

第三にAIツールとの相性が良くなる

AIは標準的で明示的なコードを得意とする

フレームワーク固有の暗黙のルールや複雑な抽象化が少ないほどAIの支援が効果的になる

■ 7. 特徴1:ランタイム非依存

Remix v3の最も重要な特徴の一つが特定のJavaScriptランタイムに依存しない設計である

従来の多くのフレームワークはNode.jsを前提として設計されていたがRemix v3はWeb標準APIのみに依存することでNode.js・Deno・Bun・Cloudflare Workersなどあらゆる環境で動作する

この設計を実現する鍵がアダプターパターンの活用である

フレームワークのコアはWeb標準のRequestとResponseオブジェクトのみを扱い各ランタイム固有の処理はアダプターが担当する

この設計により開発者はランタイムの移行を容易に行える

プロジェクトの初期はNode.jsで開発し後にパフォーマンスやコストの観点からBunやCloudflare Workersに移行するといったことがコアロジックを変更せずに実現できる

■ 8. 特徴2:React非依存

Remix v1はReactに深く依存していたがv3では独自のJSXランタイム@remix-run/domを導入しReact非依存を実現した

これは単にReactを置き換えたというより「本当に必要な機能だけを残した」という選択である

React非依存によって開発者はuseStateやuseEffectといったフック機構から解放される

フックは強力だが学習コストが高く誤った使い方をするとバグの温床になる

Remix v3ではクロージャーを活用したシンプルな状態管理に置き換えられている

React非依存の利点はバンドルサイズの削減だけではない

より重要なのは「Reactのエコシステムに縛られない」という自由度である

Reactのバージョンアップによる破壊的変更やサードパーティライブラリの互換性問題から解放されフレームワーク自身が進化のペースをコントロールできるようになる

■ 9. 特徴3:手動リアクティビティ

Remix v3の最も特徴的な設計が手動リアクティビティである

ReactやVueといった現代のフレームワークは状態が変わると自動的に画面が再描画される「自動リアクティビティ」を採用している

Remix v3ではコンポーネント自身がthis.update()を呼び出すことで明示的に再描画をトリガーする

この設計にはいくつかの重要な利点がある

第一にパフォーマンスの予測可能性が向上する

自動リアクティビティでは「いつどのコンポーネントが再描画されるか」がフレームワークの内部実装に依存するが手動リアクティビティでは開発者が完全にコントロールできる

第二にデバッグがしやすくなる

画面が期待通りに更新されない場合this.update()の呼び出しを確認すればよくフレームワークの複雑な依存関係解析を理解する必要がない

第三にフック機構が不要になる

ReactのuseStateやuseEffectは自動リアクティビティを実現するための仕組みだが手動リアクティビティではクロージャーを使った素朴な状態管理で十分である

■ 10. React開発との比較

最も大きな違いは「フレームワークの学習」と「Web標準の学習」のバランスである

Reactを使った開発ではコンポーネントライフサイクル・フックのルール・状態管理のパターンなどReact固有の知識が求められる

一方Remix v3ではこれらの知識の多くが不要になり代わりにHTMLフォーム・Web標準のイベント・クロージャーといったより普遍的な知識が活きてくる

この違いは学習のハードルにも影響する

Reactを初めて学ぶ開発者にとって「なぜuseEffectの依存配列が必要なのか」「なぜ状態の更新は非同期なのか」といった疑問は理解の壁になる

しかしRemix v3なら「ボタンをクリックしたら変数を更新して画面を再描画する」という直感的な理解で十分である

■ 11. Remix v3が最適解となるケース

Web標準を重視し長期的な保守性を優先するプロジェクト

複雑な状態管理が不要でシンプルなUIを持つアプリケーション

AIツールを積極的に活用しコード生成やリファクタリングの支援を受けたいチーム

ランタイムの移行可能性を保ちたいプロジェクト

逆にReactの豊富なエコシステムを活用したい場合や既存のReactコンポーネントライブラリを使いたい場合は従来のReact開発の方が適している

Remix v3は「Reactの代替」ではなく「異なる価値観を持つ選択肢」として位置づけるべきである

重要なのは技術選定においてトレードオフを理解することである

Remix v3はフレームワークの薄さと学習コストの低さを重視する代わりにReactエコシステムの広さを手放している

■ 12. まとめと次回予告

Remix v3は独自のAPIを増やすのではなくWeb標準を最大限活用することで学習コストを下げ長期的な保守性を高める

この思想はAIツールが普及した現代においてますます重要性を増していく

次回は実際に手を動かしながらRemix v3の特徴を体験する

手動リアクティビティによる状態管理・型安全なルーティング・そしてフォーム送信の仕組みを実装を通じて理解していく

(2026/01/09)

「そもそも生成AIでやるべきでない問い」に、企業が挑んでしまう問題

「そもそも生成AIでやるべきでない問い」に、企業が挑んでしまう問題｜深津貴之 (fladdict)

要約:

■ 1. 問題提起

わりと複数の企業のお悩みが「そもそも生成AIでやるべきでない問い」にチャレンジして疲弊している

大企業が生成AIを導入してうまくいかないケースの多くはツールの性能不足というより業務設計がズレている印象がある

もう少し正確に言うと「AIが苦手な問い」をそのまま投げている

当然苦戦している

■ 2. AIが苦手な仕事の特徴1:完璧性を要求する仕事

生成AIは確率分布で未来を予測したり答えを予測するマシーンである

つまり「確率的に間違えが発生する」ことは仕様の一部である

そもそも100%の正しさを前提とする業務は苦手である

正解が一意で厳密な業務(数式の厳密計算・機械語や厳密仕様のコード生成など1文字違いで壊れる領域)

誤りのコストが致命的な業務(医療・法務・安全領域の最終判断・断定的なファクトチェック)

見た目の細部が品質を決める業務(複雑な手指・ポーズなど局所の破綻がそのまま品質事故になる制作)

この場合AIがイケてないのではなく我々がAIにあたえる業務設計が間違っている

「細部の品質が100%でなくてもいいから成果がでる」や「成功率100%を要求されない」をみつけてAIに与えることが大事である

■ 3. AIが苦手な仕事の特徴2:長く連鎖する仕事

もうひとつの落とし穴がこれである

例えば精度90%の仕事を10回連続成功する確率は34%である

つまり操作ステップが長すぎて全てのステップで成功しないといけない問題も相性が悪い

要は各ステップの成功確率が高くても鎖の長さが増えれば落ちる

「単発なら正確」なのに「沢山連結すると精度がでない」という問題である

なのでAIに仕事を渡すなら「短い単位の仕事」で「途中で人間が介入できる」構造にしておく

冷蔵庫をあけ食材をとりだしカットして火をいれて調味料で味をととのえるようなロボットは非推奨である

レトルト食品をレンチンしてくれるロボを作りましょう

■ 4. AIが得意な仕事:全体感が正しければうまくいく仕事

逆に生成AIが得意なのは「全体感が正しければ成果になる仕事」である

適切な情報が渡されているならば多くの場合うまくいく

例えばイベントの進行案(台本たたき台・タイムテーブル案・想定Q&A・盛り上げポイント・リスク分岐など)

企画提案書へのフィードバック(論点漏れ・反論想定・構成・比較軸・刺さる言い回しの案出)

金融商品のポートフォリオの運用原則の策定

共通点は「厳密さ」より「筋の良さ」「網羅性」「比較軸」「言い回し」「観点」が価値になるところである

つまり確率的なブレを下流のエクスキューションで吸収できる領域である

■ 5. AIで正確性を出せる分野:大数の法則が効く仕事

ここまで「AIは完璧性が苦手」と書いたが逆にAI単体でも運用しだいで正確性を出せる分野もある

ポイントはシンプルで「大数の法則」や「平均回帰」が効くタイプの仕事である

つまり一発勝負じゃなくて試行回数を増やすほどブレが相殺されて平均が安定していく領域である

「1回の正解」ではなく「1000回の平均」が正解になる仕事である

たとえばマトを鉄砲で撃つ作業をイメージする

1発だけだと確率的に外れることがあるが1000発撃ったらどうか

1000発の平均の着弾点を測定したら1000発撃った平均値は実質的にマトの中心に寄っていく

これがAIで正確性を作れるパターンである

具体例として要約の精度を「集合知」で上げる・文章の改善(推敲)を反復で収束させる・分類タグ付け優先順位付けみたいな集計系・A/Bテストや広告文案など統計で勝ちが決まる領域がある

■ 6. AIに精度を持たせる方法:治具(ジグ)の活用

それでもどうしてもAIで精度がほしいなら人間がまっすぐの直線を引くときに定規をつかったり円を完璧にかくときにコンパスが必要である

こういった道具を治具(ジグ)という

どうしてもAIに精度100%を目指す仕事をさせたい場合は同様にAIのための定規・分度器となるようなツールをつくりそれをAIに操作させる

計算が苦手ならPythonや計算機をコールさせるようにする

完璧な時系列情報の列挙なら資料から引っ張ってくる

このように厳密でなければならないこと(数字計算やファクト)はAIから100%正確さが保証できる機械にアウトソースする

AIが担当するのは「ここで計算が必要かどうか」というより曖昧性の高い問にシフトさせることで問題を解決できる

AIに正確に答えさせるのではなくAIに正確な道具を使わせるこれが現実的な解法である

■ 7. AIと人間の役割分担

「AIが考えて人間が完璧に執行する」のほうがたいていうまくいく

イラストでいうならば「AIがテーマを決め必要な構成要素の素案を出しプロがしっかり描く」ほうが「プロがテーマを決め必要な構成要素の素案を出しAIがしっかり描く」よりも品質がよくなる

そういうことを考えると「経営者が考えてAIが完璧に執行する」よりも「AIが経営を考えて人間が道具を使って完璧に執行する」ほうが多くの場合うまくいく

経営判断は「全体感」が求められ執行は「細部の完璧性」が求められるからである

あるいは経営は「確率論」が大事な処理であり執行は「決定論」が要求されるからである

■ 8. 皮肉な結論

つまり生成AIの特性を考えると皮肉にも「数字だけを見て現場をコストカットしようとする経営者」が「最もAIで代替しやすい人材」で「最も費用対効果がよい」DX施策となる

我々マネジメント層のほうがあとがない

AIに最初にリプレイスされないためにも経営者もマネージャーも現場やユーザーともっとふれあって業務ドメインの解像度を高めていく

手を動かす人は思ってるより重要である

リストラとかを考えてる場合じゃない

■ 9. まとめ

まずは業務フローをできる限りシンプルに

正確性が必要なところには正規表現やプログラムなど生成AIでない仕組みを

そもそも正確性に依存しない業務で自社をドライブするにはという問いにコミットする

わりと今の現場で起きている「AI導入したけどつかえない」系の議論の大半はこれで説明できるのではないか

過渡期の生みの苦しみだと思うがみんながぶつかる課題なのでナレッジシェアできるといい

(2026/01/09)

Next.jsを採用するのをやめた理由・背景

Next.jsを採用するのをやめた理由・背景

要約:

■ 1. 記事の背景と概要

anatooによる2026年1月8日公開の記事である

少し前にReact2ShellというReactのRCEの脆弱性によってNext.jsを使っているアプリケーションが影響を受けた

実はそれ以前から自分は何かウェブアプリケーションを開発するときにNext.jsを採用するのをやめている

Next.jsを採用するのをやめたのにはちょっと微妙な理由がいくつかあったので特に何か書く事はしなかった

興味ある人もいるかもしれないので書いておこうと思う

簡単に書くと以下の三つの事柄があってNext.jsを採用するのをやめた

■ 2. 理由1:ViteやVite系のフレームワークの方がDXがよかった

技術的な理由では一番これが大きかった

ViteやVite系のフレームワークとNext.jsを比べるとViteの方がDXが明らかに優れているなという印象があった

Viteの場合は開発時はネイティブESMを使って高速に開発サーバを立ち上げられるのに対してNext.jsはコード変更するたびにバンドルしなおしている

プロジェクトのコードの量が多くなるとVite系のフレームワークを使った方が明らかにDXが良いし開発効率も良いと結論づけた

Viteは既存のプロジェクト内で間接的に導入している事も多い

テストライブラリに関してもJestだとESMサポートが薄いので代わりにテスト系のライブラリは内部でViteを使っているVitestをすでに導入している事が多かった

Viteにはすでに親近感があった

当時はRemixがViteをサポートし始めたのでもしかしてNext.jsも将来的にViteに乗っかるという可能性もあるんではないかと思った

調べた所どうやらそれは無さそうだというのもある

■ 3. 理由2:Guillermo Rauchの倫理観が心配になった

Next.jsのオリジナルの作者はVercelのCEOでもあるGuillermo Rauchである

ある時この方のXの発言を見て自分がそれに引いてしまったというのがある

このツイートは普通に批判されまくっている

興味ある方は調べてみてください

■ 4. 理由3:RSCのコトがよく理解できなかったし好みから外れていた

これは言うのが微妙に憚られる消極的な事柄になる

Next.jsがReactのRSC(React Server Component)やServer Actionを非常に早い時期にサポートしはじめたころに詳細を理解しようと思って調べていたりした

概念レベルの話はわかったんだが技術的な詳細はあまりよくわからなかった

React2Shellが発覚した後になってRSC Explorerというどういうペイロードがサーバに飛ぶのかを細かく教えてくれるツールが公開されたりもした

しかしNext.jsがRSCをサポートし始めた頃はなかった

ReactチームはRSCで使われるFlightプロトコルに関する技術的な詳細をドキュメントにあまり公開していなかったように思う

またRSCやServer Actionsを導入するときに使われるバンドラ周りの処理が魔術的に見えて自分の好みから外れていたので「なんかやだな〜」ぐらいの感覚があったという背景もある

ただこれは採用するのをやめた理由というよりかはRSCやServer Actionsにあまり魅力を感じなかったのでそれをサポートしているNext.jsを採用しなくても別にいいやという気分になった背景になる

■ 5. 結論と代替案

Next.jsを採用するのをやめた背景は以上になる

じゃあNext.jsの代わりに何を使うのかというととりあえず今のところは普通のSPAならVite+Reactを使う

SSRが必要な場合はReact Routerを使うことにしている

これ以外にも2026年はReactを捨てたRemix3も出るのでその辺りの動きも気になる

MEMO:

要するに親イスラエルであることを隠しもしないからドン引きだったと

(2026/01/09)

IT開発者向けの質疑応答（QA）サイト「Stack Overflow」で投稿数が激減、ユーザー戦慄

IT開発者向けの質疑応答（QA）サイト「Stack Overflow」で投稿数が激減、ユーザー戦慄 - やじうまの杜 - 窓の杜

IT開発者向けの質疑応答（QA）サイトとして有名な「Stack Overflow」で、投稿数が激減しているとのこと。

「X」（Twitter）に投稿されたグラフによると、最盛期に20万件を超えていた月間投稿数が、最近では5,000件以下にまで落ち込んでいます（グラフは運営元のStack Exchangeが提供しているデータエクスプローラーで出力できます）。

「X」のこのスレッドでは多くのユーザーがAIの影響を指摘しており、実際その通りでしょう。「Stack Overflow」に聞くよりも「GitHub Copilot」に聞いた方がずっと早く答えが得られるだけでなく、具体的なコードまで示してくれます。

しかし、それだけでは2014年をピークに「Stack Overflow」の勢いが少しずつ衰えている理由の説明にはなりません。

当該スレッドには、初心者に厳しい、重複する質問が多すぎる、うかつなことを言うと叱責や罵倒が飛んでくる（いわゆる「マサカリ」）といった「Stack Overflow」コミュニティの文化を批判する声も多く寄せられており、それも一因ではないでしょうか（AIはそんなことしませんしね！）。

また、「GitHub」の普及を指摘する声もあります。「GitHub」でホストされているアプリやライブラリに関する疑問であれば、そのリポジトリのイシューで議論した方が有用な答えが得られるでしょう。

でも、AIが「Stack Overflow」などのQAサイトを出典として引用することだって少なくありません。「Stack Overflow」が滅びたあと、AIはどこから知識を仕入れるのでしょうか。ちょっと心配になってしまいました。

MEMO:

まぁ、そうなるやろという予測はされてた

(2026/01/09)

「とほほのWWW入門」作者・杜甫々さん “10年先を見据えた”プロジェクト管理術を語る

「とほほのWWW入門」作者・杜甫々さん “10年先を見据えた”プロジェクト管理術を語る (1/2)

要約:

■ 1. 登壇者の背景

Webに関する技術サイト「とほほのWWW入門」を30年間ひとりで運営してきた杜甫々さんによるセッションである

同サイトは個人活動だが本職であるソフトウェア開発でも複数の長期プロジェクトに携わってきた

Backlogのユーザーグループ・JBUGは2025年11月29日にプロジェクトマネジメントの祭典「Backlog World 2025」を開催した

杜甫々さんの招待セッションでは彼がソフトウェア会社で実践してきたプロジェクト管理における数々の工夫が披露された

■ 2. とほほのWWW入門と杜甫々さんの経歴

1996年に開設された「とほほのWWW入門」はプログラミング言語やフレームワークなどWeb技術の入門情報を網羅的に発信し続けている

最近では陶磁器や洋楽・中国語・韓国語・タイ料理にまでコンテンツを広げている

2025年は尻を叩かれてAIの記事も載せている

インターネット黎明期には同サイトでHTMLコーディングやCGIプログラミングを学んだ古参の読者も多い

杜甫々さんもインターネット歴38年でありインターネット老人会の会長を目指している

杜甫々はハンドルネームで本名ではない

大学卒業後1988年にメーカー系ソフトウェア会社に入社した

入社後はさっそくUNIXにTCP/IPを移植するプロジェクトに参加した

その後ネットワーク管理システム(1990年から現在)・セキュリティ管理システム(2002年から現在)・クラウド管理システム(2013年から現在)と今なお続く長期プロジェクトの数々に携わってきた

会社自体は2025年10月に定年退職を迎えたばかりである

■ 3. 長期プロジェクトの課題

プロジェクトが長期化すると仕様書だけでも1000枚を越えメンバーの入れ替わりで知識の断絶も発生する

杜甫々さんは「得意分野ではない」「細かで古い話」との前置きの上でプロジェクト管理で実践してきた工夫を披露した

■ 4. フォルダ構成の工夫:10年フォルダ

まずは「フォルダ構成」における工夫である

長期プロジェクトではファイルのバージョンアップ(v1.1・v1.2)やバグフィックス(v1.1.1・v1.1.2)を重ねるうちに「どこに何があるかわからなくなる」問題が発生する

そこで杜甫々さんが推進してきたのが10年経っても乱れない「10年フォルダ」と呼ぶフォルダ構成である

具体的には「バージョンに依存するファイル群」と「依存しないファイル群」を完全に分離させるのがポイントである

例えば「v3.2」に関連する仕様書はバージョン依存ファイルを管理するフォルダにあるv3.2フォルダ直下にのみ保存する

そして最新の仕様書はバージョンに依存しないファイルとして別フォルダで管理する

これを徹底することで新メンバーでも目当てのファイルにすぐに辿り着ける

ただしこの運用ではバージョン依存と非依存の両方の仕様書を書く必要がある

それに対し「v3.2の仕様書では2行ほどしか記載せず詳細は最新仕様書にリンクで飛ばし同じことを複数の仕様書で書かないようにしていた」

さらに「リリースが終わればバージョン依存のフォルダは捨てるくらいの気持ち」で運用するのがよい

結局のところ重要なのは「最新の仕様」であり10年後に保守しているメンバーは古いバージョンの仕様など読まないからである

細かな工夫としては大本のフォルダ名に2桁の固有数字を付与している

マウス嫌い派である杜甫々さんはこの数字を利用してキーボードのみでエクスプローラーを移動していた

■ 5. 仕様書作成の工夫

続いては「仕様書作成」における工夫である

長期プロジェクトでありがちなのが仕様書間の不整合である

開発途中で仕様変更があった場合詳細仕様書から基本仕様書・概要仕様書へと遡り影響範囲に応じて変更内容を反映する必要がある

ただみんなめんどくさがったり忘れたりして結局は不整合が生じていた

そこで概要・基本・詳細のフェーズごとの仕様書をひとつのファイルにまとめた

一続きの仕様書にして修正の手間を減らすと不整合はなくなった

また文書番号体系(名づけ)もプロジェクト+文書の種類(設計仕様書はS・テスト仕様書はT・手順書はMなど)+連番というシンプルなルールで統一して検索やリンクをしやすくしたのもポイントである

年度やモジュールなどは採番台帳で把握できる

■ 6. Excel方眼紙による進捗管理

一部のプロジェクトで運用していたExcel方眼紙製の仕様書も紹介された

冒頭の列(A~F)で「作成」「査閲」「承認」「開発」「実装」「評価」のどこまで済んでいるかをチェックして行単位で進捗を把握できる仕組みである

加えてコメントはExcelに直接記入し★をつけることで残課題を集計する

こうした運用で仕様変更が漏れなく開発メンバーに伝わり仕様書の一行一行で管理できる

■ 7. テストファーストな記述

もうひとつ意識していたのが「設計仕様書は評価仕様書でもある」という考え方である

文章の末尾に「~か」をつけると評価仕様書になるようなテストファーストな記述を徹底した

例えば「タイムゾーンはアルファベット昇順でソートして表示する」という仕様はそのまま「タイムゾーンはアルファベット昇順でソートして表示するか」というテスト項目になる

そして設計仕様書のシート半分は実際に評価仕様書として運用し各行がテストされているかを把握しやすくしている

なお杜甫々さんがプロジェクト立ち上げ時に最初に行っていたのが「型定義」である

改行や制御文字・負数・サロゲートペア領域などを許容するかを予め定義して画面からAPI・デザイン設計に至るまで統一していた

■ 8. 開発ガイドラインによるナレッジ伝承

最後に触れられたのが「開発ガイドライン」である

この開発ガイドラインとはプロジェクトをまたがり蓄積してきたナレッジをひとつのファイルに集約したものである

「障害があって解決してなぜ3分析(なぜを繰り返す問題解決手法)をする喉元を過ぎれば忘れてしまうので開発ガイドラインに追加して10年先のメンバーにもノウハウを伝える」

その項目数は500を超え「管理」「設計」「開発」「評価」「出荷」などのフェーズごとに整理されている

さらに新規追加の項目にはメンバー向けのチェック欄を設け理解されているかを確認できるよう工夫している

■ 9. プログラミングスキルの見える化

プログラミングスキルの見える化にも取り組んでいた

それは「Linuxのcatコマンドの互換コマンドmycatをC言語で作成してください」と投げかけるという内容である

これだけのお題だが完璧に作れる人は少ない

異常時の終了ステータスが0以外になっているか・close()のエラーを確認しているかなど色々なチェック項目を設けていた

こうしたチェックリストを基に新メンバーのコーディングスキルを客観的に数値化する

チェックリストはそのまま教育にも用いる

ただしこの見える化を含む施策は「今では生成AIでも出来てしまう」と振り返った

■ 10. 結論

ここまで紹介された工夫はあくまで一部にすぎない

年間で60個ほどの改善策を手掛けた時期もあった

杜甫々さんは「大事なのはこうした改善策を整理して他のプロジェクトと共有していくこと」と述べた

「そして次のメンバー・次の次のメンバーへと伝承させていくことだこれはAIでもできない人間が担っていくべきもの」と締めくくった

(2026/01/08)

レビューしてもらう/する場合に意識すること、やり方を考える

レビューしてもらう/する場合に意識すること、やり方を考える｜Koshi Kagawa

(2026/01/07)

ドキュメントレビューをする際の10のポイント

ドキュメントレビューをする際の10のポイント | Ryuzee.com

1. 体裁をレビューするのではなく、中身をレビューする

2. 標準化ではなく、顧客や案件ごとに最適化できるような自由度をチームに与える

3. レビューの目的を明確にする

4. 大がかりなレビューを少ない回数実施するのではなく、こまめな小規模レビューを繰り返す

5. レビューでの指摘事項をすべて対応しなければならないとは限らない。チームにとって労力をかけるだけのメリットがあるものから優先順位付けをして実施する

6. レビューで人格を非難しない

7. レビューの順番もレビュー効果が高いものから実施すること

8. 機械的に検証可能なドキュメントのレビューは自動化すること

9. レビューワーも技術もしくは顧客の業務をしっていること

10. レビュー結果はチーム内外含めて共有すること

(2026/01/07)

育てるほど楽になる AI 開発体制を作っている話

育てるほど楽になる AI 開発体制を作っている話 | BLOG - DeNA Engineering

(2026/01/07)

ただNext.jsを使う

ただNext.jsを使う - カミナシエンジニアブログ

要約:

■ 1. 記事の背景と目的

カミナシエンジニアのosuzuによる技術記事である

職能柄Webフロントエンド技術の選定に関わる機会が多くReact Server ComponentやNext.jsに関する発信を過去にしていた

2025年12月のReactやNext.jsのセキュリティ問題に対し心痛めている

現在もプロダクションでNext.jsを運用しているが選定した事を後悔しているかというとそう単純な話でもない

あらためてNext.jsをプロダクションで採用するポイントや何を意識した構成にしているか記載する

以降ReactはRSC(React Server Components)を含むものとしNext.jsは記載のない限りApp Routerを指した話となる

■ 2. BFFとしての使用方針

プロダクション運用するプロダクトに対してフルスタックフレームワークやバックエンドを兼ねる形でNext.jsを採用する事はない

必ずBFFとして使う

主にSaaSのような認証認可が必要かつマルチプロダクト展開や他SaaS連携などで複数のAPIに依存しやすい構成を例に説明する

■ 3. BFFの構成設計

推奨する「Next.jsをBFFとして使う」構成は物理的にも論理的にもバックエンドAPIと明確に分離された状態を指す

Next.jsはデータベースへの接続情報を一切持たずビジネスロジックも記述しない

あくまで「UIのためのデータ整形」「APIアグリゲーション」「API認可プロキシ」に徹する

■ 4. セキュリティ設計思想

Next.jsサーバー(Node.js/Edge Runtime)を「信頼できるサーバー(Trusted)」とは見なさず「ブラウザが少し権限を持った延長線上の環境(Untrusted)」として扱う

「ブラウザのDevToolsで見えて困るロジックや変数はNext.jsのサーバーサイドにも置かない」という極端な意識で設計する

DBのパスワードやAWSのシークレットキーを環境変数として渡すことはない

万が一RSCの境界設定ミスでコードが流出したりインジェクション攻撃を受けたとしても攻撃者が手に入れられるのは「画面構築のためのロジック」だけであり系統全体を掌握されるリスクを構造的に低減する

■ 5. インフラ権限の最小化

BFFが実行されるコンテナや関数自体の権限(IAM Role等)は最小限に絞る

AWS上で運用する場合Next.jsの実行ロールに対してdynamodb:FullAccessは与えずにdynamodb:GetItemやdynamodb:PutItemなど権限を最小限にする

認証認可のフローにおいてもNext.jsはあくまでトークンの「運搬役」に徹する

Next.js上でJWTを発行するといった構成は取らない

■ 6. 認証認可の責務分離

カミナシが運用するプロダクトではバックエンドAPIはOAuthのクライアントでトークンイントロスペクションのリクエストするだけという構成を取っている

Next.jsはCookieからトークンを取り出しAPIへ転送するだけでありバックエンドAPI側がそのトークンを検証するリクエスト結果を元に認可する

この徹底した責務の分離によりBFF層がセキュリティに対して権限やリスク集中することを防いでいる

すべてのバックエンドAPIが同じセッションストアを共有する構成などではBFFでトークンを取得せずcookieをproxyするだけで扱って良いかもしれない

■ 7. BFFの必要性の議論

「そこまで制約を課すならSPA + APIで良いのではないか」という議論がある

SaaSやtoBのプロダクトではSPA(Client Side Rendering)にすべきという意見もよく目にする

「SSRからSPAにしたとしてSaaSのようなプロダクトではボトルネックは移動しない」「静的なファイルとして配信した方がインフラコストが安いまたバンドルしたファイルもユーザーのブラウザでキャッシュ可能」など

上記にも賛同するし前職でそう構築した経験もある

残念ながら何事にもトレードオフがあるため主にBFFを置くこと自体のメリットを記載する

■ 8. BFFを置くメリット

メリットは「認可の橋渡し(Token Handler)」と「APIアクセスの集約」にある

現代のバックエンド(特にマイクロサービス構成)はステートレスなBearer Tokenを要求することが一般的である

SPA単体でこれを実現しようとするとJSでトークンを扱う(XSSリスク)かバックエンド側すべてにCookie認証を対応させる(実装コスト増・CORS問題)必要がある

BFFを挟むことで「ブラウザとはCookie(セッション)で通信しバックエンドとはTokenで通信する」という構成が素直に取りやすい

Token Handlerのためにサイドカーや軽量プロキシを扱うことも可能ではある

APIアクセスの集約(APIアグリゲーション)に関してはコード的な問題だけでなくAPIが同一VPCのinternalなリクエストで通信出来たりAPIとBFFを同じリージョンにまとめたりとネットワークの効率が優れている

Reactチームはブラウザから大量の遅いリクエストが飛んでしまう問題をBoomer Fetchingとして問題視している

■ 9. RSCのBFFとしての優位性

BFFの中であえてNext.jsを選ぶ理由はRSCがもたらす開発体験とBFFとしての適性にある

RSCを「宣言的なBFF」として捉えると非常に優秀である

従来BFF層でAPIを叩くためにはExpressを使ったりGraphQLを使うなどの詰め替え業が必要だった

RSCであればコンポーネントツリーの中で直接非同期データを取得しそれをPropsとして流し込むだけで済む

データの取得とUIの構造がコロケーション(同居)されかつ型安全にバックエンドAPIのレスポンスをクライアントコンポーネントへ渡せる

RSCによってReactを同期的に書くことができて非同期で発生する難しさをいくつも解消してくれる

■ 10. Next.jsの課題点

発明を捨てフルスタックフレームワークとしての道を失った

Next.jsはApp Router以降フルスタックフレームワークとしての道を失ったと思っている

Page RouterまではServerからClientへのPropsの境界が明確で(いわゆるgetServerSidePropsで境界が分かれてた)貧者の選択としてNext.jsでサーバーを実装する選択も取り得た

今回のCVE以降は特にそうした構成を取る事は明確に難しくなる

■ 11. 代替フレームワークの出現

Tanstack Startというフレームワークが対抗として出現している

UIライブラリがReactに依存していなかったり(これはTanstack系は共通の思想)Reactに非依存な層を増やしたい人には嬉しい

サーバー/クライアントの境界を明確に区別しようという思想もありこうしたコンセプトもNext.jsより共感する人が多いと思う

紹介したTanstack Routerも他に有力なReact Routerも将来的にRSCを取り入れていく方針である

今の上記フレームワークのシンプルさはRSCに対応してないゆえでもあり今後どの程度混乱が生じるかは分からない

それならいっそReact以外という道を考える人もいるかもしれない

採用市場やフレームワーク自体の完成度を見るに難しい選択にはなると思う

■ 12. 技術選定に対する考え方

今フロントエンドでフレームワークやライブラリを選定することは考慮すべきポイントが多くて難しい時代だと思う

きっと色んな言葉が気になってしまうエンジニアも多いと思う

近年大切にしてるテーマの一つに「どうでもいいことは流行に従い重大なことは標準に従いドメインのことは自ら設計する」という言葉がある

カミナシという組織でSaaSを開発しているがカミナシには「現場ドリブン」というドメインに時間を使おうという概念そのままのバリューが存在する

2025年だけでCS活動やプロダクトディスカバリや商談同席など現場に10件以上訪問して課題に向き合ってきた

エンジニアとしての時間をドメインを考えることに対して使っていきたいという想いが年々強まっている

技術選定の正解探しに時間を溶かすのではなく選んだ技術を正解にするためのオーナーシップと何よりユーザーへの価値提供を大切にしていきたい

(2026/01/07)

Z世代に多い「褒められると伸びるタイプです」と自分で言ってしまう人には、マネジメント上かなり...

Z世代に多い「褒められると伸びるタイプです」と自分で言ってしまう人には、マネジメント上かなり注意したほうがいい。もちろん、承認が動機づけになる人は多いし、褒めること自体は悪じゃない。問題は、その言葉が単なる自己理解ではなく、責任の所在のすり替えとして使われること。本人は無邪気に言っているようで、実はその一言の中に「成長にとって致命的な壁」がある。

自分が成長できるかどうかは相手がどう接するかで決まる。言い換えると、自分は変わらずに環境や他人を変えようとしている。これは成長の方向とは真逆のマインドセット。成長のアクセルを他人の手に渡している状態。

厄介なのは、このタイプは褒めを「免罪符」や「取引条件」として使うことがある点。「褒めてくれないなら、成長できなくても仕方ない」という責任回避。承認がなくなった瞬間にエンジンが止まる。もっと悪いと、承認がない状態を「不当な扱い」と感じて不満や被害者意識へと変換する。

この構造の裏側には、心理的な防衛がある。過剰なプライド、あるいは自尊心の脆さ。自尊心が不安定な人ほど外部からの承認に依存しやすい。褒められると嬉しいのではなく、褒められないと崩れる。ここが根っこだと、指摘を受け入れる器が小さくなる。なぜなら指摘は、本人の中では改善提案ではなく自分の価値への攻撃として処理するから。自己評価が脅かされると人は合理性より防衛に走る。反論する、言い訳する、話を逸らす、黙る、落ち込む、拗ねる。表面的には反省して見せるけど内面では反省していない。この現象は珍しくない。

ここで重要なのは「反省の言葉」と「反省の中身」は別物だということ。とりあえず謝る、とりあえず「すみません」と言う、とりあえず「気をつけます」と言う。これを繰り返すと、本人の中で反省っぽいことを言えばその場を切り抜けられるという学習が成立し、負の成功体験が生まれる。反省の言葉を言うことで、叱責や不快から逃げられる。それが報酬になってしまう。結果、行動は変わらない。本人が悪意を持っているわけではなく、学習の結果として「反省の言葉」だけが巧妙になる。言葉は良いのに成長がない。謝るのに同じミスを繰り返す。こういう人を放置してはいけない。

では、どうマネジメントするべきか。このタイプの人を伸ばすには、まず「褒められると伸びる」という自己定義が、成長とは逆向きになることを本人に理解させないといけない。そのうえで「すごい」「偉い」みたいな人格承認ではなく「何をどうやったか」という行動承認に寄せる。努力やプロセスを承認すると成長マインドセットが育ちやすい。再現性のある行動を承認することで「気分の報酬」ではなく「行動の強化」につなげる。

次に、成長とはフィードバックによって行動の引き出しを増やすことだと繰り返し教え、認知の再構成をさせる。本人の中で「指摘＝攻撃」から「指摘＝武器が増える」に変換できたら受け取り方が変わる。

そして、反省の言葉ではなく次の行動でしか評価しないこと。「すみませんでした」では終わらせず「次に何を変える？」「明日から何をやめる？」「同じ状況で、次はどう動く？」まで必ず言語化させる。さらに「いつ確認するか」まで決める。曖昧な反省は変化を生まない。具体の行動だけが変化を生む。この運用を続けると「反省っぽいことを言って逃げる」学習が崩れていく。本人は最初しんどい。なぜならこれまでの防衛が通用しないから。でも、ここで初めて本当の成長が始まる。

「褒められると伸びるタイプ」という自己申告が危険なのは、褒めが必要だからではなく、成長の責任を外に置いてしまいやすいから。成長する人は褒められなくても伸びる。褒められたら加速する、くらいの位置づけにしている。伸びない人は、褒められないと止まる。そして止まった理由を環境のせいにする。この差は能力の差ではなくマインドセットの差。マネージャーの仕事は、そのマインドセットを本人に与え、成長の責任を本人に戻し、承認を依存ではなく強化として使い、反省を言葉ではなく行動に変える設計を作ること。

このプロセスを踏めるようになると、外部承認に依存する人、自尊心が脆い人、プライドが高い人、反省の言葉が上手い人など、マネジメント難易度が比較的高い部下をマネジメントできるようになる。

@masanydayo

(2026/01/06)

プログラミングみたいに音楽を作れる「Strudel」

(2026/01/06)

新卒エンジニアで「1日3~4時間だけ集中してコードを書いて、残り時間は Slack を徘徊する」みたいな...

新卒エンジニアで「1日3~4時間だけ集中してコードを書いて、残り時間は Slack を徘徊する」みたいなゆるい働き方を覚えてしまってからそこから抜け出すのにかなり苦労したし、抜け出せない人は一定数いる

@uiu______

MEMO:

それが定年まで続くならそれでもいいんだろうけどね

(2026/01/06)

Claude Codeで記憶領域を持つための独自のAgent Skillsを使っている

Claude Codeで記憶領域を持つための独自のAgent Skillsを使っている

MEMO:

自分の場合は設計や実装方針は原則Markdownのファイルに出力させていて、コンテキストをあまり使わないようにしている
ファイルに出力すれば確認・修正も楽だし、コンテキストをクリアしてClaude Code自身にレビューさせることもできる

(2026/01/05)

PublickeyのIT業界予想2026。メモリ高騰による消極的なクラウド選択、AIエージェントを前提とした開発...

PublickeyのIT業界予想2026。メモリ高騰による消極的なクラウド選択、AIエージェントを前提とした開発方法論、Rust採用の広がりなど－ Publickey

要約:

■ 1. 記事の概要と2025年の振り返り

2026年1月5日に公開されたPublickeyによるIT業界予想である

2025年を振り返ると生成AIに始まり生成AIに終わると言っても良いほど話題の中心のほとんどに生成AIがあった年だった

2026年も生成AIが注目されることは間違いないがその位置づけは2025年とはまた少し違ったものになる

生成AI以外にもIT業界には注目すべき動向がいくつも存在する

■ 2. 国際情勢とIT業界への影響

2025年1月に米国大統領にドナルド・トランプ氏が就任したことはこの1年で最も大きな影響を世界の政治や経済に与えた出来事だった

トランプ大統領が就任直後から強引に推進した相互関税はこれまで進展してきた国際自由貿易の停滞や逆転を引き起こした

コンピュータ関連の製造業を含む多数のグローバルな製造業のサプライチェーンに見直しを迫るものとなった

ロシアによるウクライナへの侵略における和平交渉での米国の姿勢がロシア寄りであるとして欧州は米国への不信感を募らせつつある

日本で高市早苗氏が首相に選ばれたことは国内の伝統的な価値感を重視するとされるいわゆる保守的な志向の高まりを反映したものと推察される

1年前のIT業界予測で「高くなる国境続く円安と人手不足」として国際的な緊張の高まりとインフレが続くだろうという認識を示したがこれは1年が経過した現在も継続している

■ 3. ITと政治の関係の可視化

トランプ大統領の就任式にはGoogleのスンダー・ピチャイCEO・Appleのティム・クックCEO・メタのマーク・ザッカーバーグCEO・Amazon.com創業者のジェフ・ベゾス氏らが巨額の寄付を行うとともに出席することが年初に大きく報道された

新たに設立されたDOGE(政府効率化省)はテスラやX/Twitterのオーナーであるイーロン・マスク氏が主導している

オラクル創業者のラリー・エリソン氏は影の大統領と呼ばれるほどトランプ大統領と近しい関係にあると報道されている

ITと政治との距離がかつてないほど近いことが可視化された一年だった

米国のみならず世界中でITは各国の安全保障に関わる重要事項となりつつあることなどからもITと政治の距離はさらに近づいていくことになりそうである

■ 4. AIへの大規模投資

2025年のAIの進化と普及そしてその将来性はIT業界のみならず株式市場などからも大きな注目を集めた

NVIDIAの時価総額は2025年7月に世界初の4兆ドル(1ドル155円換算で620兆円)を突破しアップルやマイクロソフトを抜いて時価総額世界一となった

日本企業の時価総額1位はトヨタ自動車で約53兆円日本の国家予算(一般会計)は約117兆円である

AIブームの勝者になるべくGoogleやマイクロソフト・Amazon.com・Facebook・OpenAI・オラクル・ソフトバンクなどをはじめとする多くの企業が驚くような額の資金調達やAIデータセンターへの積極投資などを発表している

2025年後半にはこれらの大規模投資は本当に将来の利益となって回収できるものなのかという疑念も一部でささやかれるようになっている

その疑念への答えがはっきりするのは数年後のことだと思われるがすでにオラクルの株価が急落するなどの動きが見え始めている

2026年の株式市場はもしかしたらそうした予測を早くも織り込むようになるのかもしれない

■ 5. メモリ価格の高騰

年末に突如始まったメモリ価格の高騰がAIデータセンターへの大規模投資が引き起こした事象として表面化した

2025年12月3日に半導体メモリの製造販売大手であるマイクロンテクノロジーがコンシューマ向けブランド「Crucial」でのメモリとSSDの販売終了を発表した

AIデータセンター向けのメモリ需要の高まりからコンシューマ向けのメモリ不足が起きそれによってメモリ価格が高騰しているとされている

価格高騰はSSDやHDDなどメモリ以外の部品にも波及している

多くの日本企業が2026年4月から始まる新年度の予算を作成している時期であり来年度のPCやサーバ・ストレージの調達計画を立てているところである

メモリだけでなくSSDやHDDもどこまで値上がりが続くのか見通しが難しい現在この価格の不透明さはいずれ企業向けのサーバなどの調達にも影響を及ぼしそうである

■ 6. 予想1:サーバ調達価格高騰による消極的なクラウド化

2025年12月末に国内の多くのBTOベンダ(マウスコンピュータ・ツクモ・ドスパラ・サイコムなど)が相次いで受注停止や値上げなどを発表した

メモリ価格の高騰が続くことを見越して早めにPCを調達しておこうと考えた消費者の増加によりBTOベンダの想定を大幅に上回る受注が発生した

メモリ価格の急上昇によるBTOベンダの仕入れ価格の急上昇などが重なったことが理由である

メモリ価格の高騰はこれから企業が従業員用のPCやオンプレミス用のサーバの調達にも影響するであろうことは十分に予想される

特に多くのメモリを搭載するサーバの調達価格の見通しは非常に不透明にならざるを得ない

予算計画を立てたとしても実際に発注してみたら予算に対して十分なサーバの台数が調達できなかったという可能性もある

一方で長期で大量のサーバ調達契約をしていると思われる大手クラウドベンダの利用料金が急に上昇する可能性は低い

新たにオンプレミス用のサーバを調達する際の価格の不透明さを嫌って安定的に調達できるであろうクラウドを選択する合理性が高まりそうである

2026年は通常のクラウド移行に加えてこうした不透明なサーバ調達価格を理由にある意味で消極的にクラウドを選択するというシステムが増加するのではないか

■ 7. 予想2:AIエージェントを前提とした開発方法論の勃興

開発チームに指示したことを文句も言わず何でも実行してくれて昼も夜も24時間365日文句も言わずにずっと働き続けることができてしかも通常の人件費よりずっと安価なメンバーを何人も採用できるとしたらそのメンバーにいつどんな作業を依頼するか

それによって既存のメンバーの役割や働き方はどう変わっていくべきか

既存の開発手法や方法論はそのままでよいのか

人間とは異なる能力と働き方とコストを備えたメンバー=AIエージェントが開発チームに迎え入れられようとしている現在これまで人間だけで構成されていることが前提であった開発方法論・メンバーの役割・働き方・コラボレーションツールなどを人間とAIエージェントの混成チームを前提としたものに最適化するべく多くの組織で試行錯誤が始まっている

それは以前GoogleがSRE(Site Reliability Engineering)として新しい運用エンジニアのあり方を提唱したりあるいはアジャイル開発のコミュニティからアジャイル開発宣言が発表されたりするようにどこかのベンダからあるいはどこかのコミュニティから提案されるのかもしれない

2026年のAIエージェントはそれ単体や連携による能力進化だけでなくAIエージェントを前提とした新たな開発方法論や手法・コラボレーションツールなどAIエージェントを取り巻く環境との組み合わせによって進化していくものになるのではないか

■ 8. 予想3:企業などへのサイバー攻撃が続く

2025年は社会的に大きな被害をもたらしたサイバー攻撃が目立つ年だった

1月には警察庁が中国の関与が疑われる日本国内へのサイバー攻撃に注意喚起を公開しおもに日本の安全保障や先端技術に係る情報窃取を目的としていると説明しサイバー攻撃は国家の安全保障と深く関わっていることを広く印象づけた

2月にはサンリオが不正アクセスを受けてサンリオピューロランドの新規の来場予約ができない事態を引き起こした

3月には楽天証券やSBI証券を始めとした複数のネット証券においてフィッシング詐欺やマルウェアなどによると見られる証券口座の乗っ取りが多数発生したことが明らかとなって数千億円規模の被害が発生した

その後多くのネット証券がこの被害を補償することを発表している

9月にはアサヒグループホールディングス10月にはアスクルが相次いでランサムウェアによるサイバー攻撃を受け製品出荷が停止する大きな被害を受けた

こうしたサイバー攻撃はAIの進化によって以前よりさらに巧妙かつ洗練されてきている一方で攻撃を受ける側の多くの組織の防御体制が十分ではないのが現状である

2026年も残念ながら国家間の緊張が高まるなかで国家が関与するサイバー攻撃が減ることは考えにくくネットにつながれたシステムの上で金銭的価値の高い情報のやり取りがますます増加する中でそれら金銭的価値の取得を目的とした攻撃も減ることはない

多くの人にとって身近な企業がサイバー攻撃を受け被害額の補償や長期の出荷停止など多額の被害を受けたことがテレビや新聞・雑誌などで広く報道された結果これをきっかけに以前より多くの企業や組織でセキュリティの議論が高まったとの声も聞く

2026年は多くの企業にとってセキュリティ体制を見直し強化する年になってほしいと願っている

■ 9. 予想4:Rustの採用が本格的に広がる

Rust言語は以前から多くのITエンジニアに注目されているプログラミング言語だった

C言語のように低レイヤのシステムの記述を得意とし不正なメモリ領域を指すポインターなどを許容しない安全なメモリ管理やマルチスレッド実行においてデータ競合を排除した高い並列性を実現している点などの特長を備えている

コンパイル型の言語として安全かつ高速なネイティブバイナリを生成してくれる

米政府は2024年に「将来のソフトウェアはメモリ安全になるべき」との声明を発表しそのためのプログラミング言語の1つとしてRustを挙げている

Rust言語はその高い注目度に対して実際の開発プロジェクトでの採用例は十分ではなかった

これはそもそもRust言語の得意分野が低レイヤのシステム開発という比較的ニッチでありしかもプログラミング言語の変更に保守的な領域であるという背景もある

2025年にRust言語の利用は広がりを見せていた

これまでLinuxのカーネル開発におけるRust言語の使用は実験的な位置付けとされていたが2025年12月に東京で行われたMaintainers SummitにおいてRustの使用はもはや実験的ではないとされ正式な採用が決定された

マイクロソフトも2030年までに自社の主要コードベースからC/C++を全面的に排除しRustへ移行する方針を明らかにしたと報道されている

AWSが2025年11月にAWS LambdaがRust言語を正式にサポートしたと発表した

RustはこれまでAWS Lambdaでよく利用されてきたNode.js/JavaScriptやJava・.NET・Pythonなどのプログラミング言語と異なりネイティブバイナリを生成するコンパイル型言語である

これによりインタプリタやJITコンパイラを用いたプログラミング言語と比較して高速な起動と実行そして実行時に必要なメモリ容量が小さくて済むなどの利点がある

サーバレスコンピューティングにおいてこれは高速な起動および省メモリなどの効率的なコンピューティングリソースの面で非常に大きなアドバンテージである

AWS Lambdaという広く使われているアプリケーションプラットフォームでRust言語を用いてアプリケーションが書けるようになったということがRust言語の活用範囲を大きく広げる

2026年はRust言語の高い注目度が採用事例へと積極的に移行していくことになるのではないかと期待を込めて予想する

(2026/01/05)

IT業界に蔓延する『ナンニデモPM』それ、本当にプロジェクトマネジメント？

IT業界に蔓延する『ナンニデモPM』それ、本当にプロジェクトマネジメント？ #プロジェクト管理 - Qiita

要約:

■ 1. 問題提起と記事の目的

IT業界におけるプロジェクトマネージャー(PM)に技術力は必要かという議論が存在する

PMには技術的判断力(技術リテラシー)が必要だが実装スキルとは異なる

現場ではPMに過度な業務範囲が求められる「ナンニデモPM」案件が存在する

本記事ではPMの役割定義、必要な技術力のレベル、ナンニデモPMの危険性、不適切な求人について建設プロジェクトの例えを用いて整理する

■ 2. ITプロジェクトと住宅建築の類似性

ITシステム構築は家づくりのプロセスに例えることができる

住宅建築における役割分担:

施主(クライアント)は要望を出し対価を払う

設計(アーキテクト)は要望を構造的に可能な形に設計し設計責任を持つ

施工管理(PM)は予算・工期・品質を管理し現場調整を行う

職人(エンジニア)は設計図に基づき実際に家を形にする

各役割が明確に分かれているのが本来の姿である

■ 3. ケーススタディ:メンバー欠員時の対応の違い

住宅建築で大工が1名欠員になった場合の施工管理の対応:

追加要員(職人)の手配

工程の組み替え(優先順位変更・段取り替え)

必要に応じて施主に事情説明し納期調整

施工管理が自ら大工作業を代行することはまず無い

IT業界でアプリエンジニアが1名欠員になった場合:

本来は追加要員調整・影響範囲見極め・スコープ優先順位納期交渉を行うべき

しかし実際はPMがエンジニアを兼務して穴埋めすることが多発する

PMが自らコーディングしてカバーすることが美徳として語られる

一度発生すると常態化し最終的に全部盛り何でも屋さんPM(ナンニデモPM)が誕生する

ナンニデモPMの状態:

本来の管理業務を捨て設計(アーキテクト)や構築(エンジニア)の穴をPMが自らの技術力と稼働時間で埋め続ける

若手のOJTまで背負い込みPMのリソースが完全にパンクする末期的状態

■ 4. PMの正しい役割定義

IPA(情報処理技術者試験のシラバス)によるPM人物像:

プロジェクトマネージャはレベル4(高度)で実装ではなくプロジェクトを成立させるためのマネジメントを扱う

立ち上げ段階では目的・成功条件・体制・制約の定義を行う

計画段階ではスコープ・スケジュール・コスト・品質・リスク・調達・コミュニケーション・ステークホルダーを扱う

実行監視段階では進捗把握・課題変更管理・意思決定・合意形成・是正を行う

終結段階では受入れ・引き継ぎ・振り返り(ナレッジ化)を実施する

PMが設計実装に深く入りすぎると論文試験の評価が落ちる

PMBOK(第8版)によるPM人物像:

プロジェクトマネジメントの標準知識体系を広い文脈で整理している

価値提供(Value Delivery)を重視する

状況に応じたテーラリング(Tailor)を行う

予測型もアジャイルも含めた複数のやり方の取捨選択を行う

PMCDフレームワークでPMの専門性を知識(ITSS相当)・実行力(成果を出す能力)・パーソナル(リーダーシップ倫理)の3次元で定義している

実作業の代行は明記されていない

■ 5. PMに求められる技術力の定義

判断できる技術力の要素:

専門家や技術者の発言を理解できる(共通言語の理解)

トレードオフを比較できる(コスト期間品質リスク拡張性など)

赤信号を検知できる(やってはいけないことがわかる)

質問ができる(何を誰に聞けば不確かさが減るかプロジェクトが前に進むかがわかる)

意思決定の前提条件を揃えられる(論点選択肢根拠影響範囲)

PMが必ずしも持つ必要がないもの:

特定言語の実装力(Javaで高速に書ける等)

特定クラウドの深い構築スキル(AWSの各種サービスの設計運用を一人で回せる等)

特定プロダクト特定領域の属人的な運用ノウハウ(細かなチューニングや手順の暗黙知までを一人で抱える等)

PMが目指すべきは「スペシャリスト」ではなく「指揮官」のような立ち位置である

■ 6. 判断できる技術力の具体的目安

IPAのITSS Level3(応用情報)の守備範囲が判断できる技術力のベースとなる

応用情報の範囲はテクノロジだけでなくマネジメントストラテジまで含むためPMが判断するための最低限の共通言語共通理解になる

テクノロジ系基礎理論コンピュータシステム分野:

アーキテクチャ概念・仮想化クラウド・OSSの基本を理解する

アーキテクト提案の実現可能性・コスト運用負荷・拡張性をトレードオフ評価できる

テクノロジ系技術要素分野:

セキュリティ・データベース・ネットワークを理解する

インシデント時の初動判断・変更時のリスク特定・非機能(性能可用性)議論の前提を揃える

テクノロジ系開発技術分野:

要件定義からテストの流れ・品質・DevOps・CI/CDを理解する

予測型アジャイルの向き不向き・品質確保の打ち手・リリース設計(ゲート自動化)の判断ができる

マネジメント系プロジェクトマネジメント分野:

工程・コスト・品質・リスク・資源・調達・変更管理を理解する

気合ではなく数値と根拠で意思決定できる(見積りバッファクリティカルパスリスク対応)

マネジメント系サービスマネジメント監査分野:

運用設計・ITILの考え方・監査内部統制の観点を理解する

作って終わりにしないためSLA運用負荷保守体制を踏まえて意思決定できる

ストラテジ系システム戦略企画分野:

目的・ROI・要求の優先順位・調達の考え方を理解する

やる理由とやらない理由を整理し投資として説明できる(優先順位スコープ調整ができる)

ストラテジ系企業活動法務分野:

契約・個人情報・知財・下請取引・コンプラを理解する

契約リスク・情報漏えいリスク・体制責任分界の事故りやすい点を早期に潰せる

■ 7. ナンニデモPMが危険な理由

PMがPMできなくなることがシンプルな危険性である

全部盛りPMが発生しやすい要因:

そもそもアーキテクトテックリード不在(または役割が曖昧)

人手不足で追加要員がすぐ手配できない

予算制約が強く「できる人がやるしかない」状態になる

兼務の前提でスケジュールが組まれている(最初から無理)

技術課題が表面化して火消しが常態化している

変更管理が弱く後半に仕様追加が雪だるま式に増える

ベンダ委託先の責任分界が曖昧で結局PMが吸収する

ドキュメント標準化が弱く属人化して引き継げない

管理が事務作業と誤解され軽視される

PMが実装側に寄った場合の弊害:

ステークホルダー調整が遅れる(意思決定が詰まる)

進捗の見える化が遅れる(気づいたら手遅れ)

リスクの早期潰しができない(後半で大爆発)

品質ゲートが機能しない(テストレビューが薄くなる)

メンバーのモチベーションが低下する可能性がある(全部PMで良くなり自分達の存在意義が不明になる)

結果としてQCDが落ち炎上しやすくなる

炎上すると社内外のエグゼクティブ層の関与が増え更に報告が増える(悪循環)

最終的にデスマーチと化する

■ 8. 小規模案件における兼務の妥当性

小さい規模の仕事なら1人が複数ロールを兼ねるのは自然である

住宅で言えばDIYでありITでも同様である

兼務が妥当なケース:

チーム内の業務効率化の小ツール(ローコードスクリプト)

小規模なRPA自動化(定型作業の削減)

既存SaaSの設定変更や軽微な連携(影響範囲が限定的)

PoC(失敗前提で学びが目的でスコープが小さい)

高いレベルの品質や厳格なスケジュールを求めない案件

このレベルならそもそもPMは不要でありリーダー担当者くらいの呼び方で充分である

DIYレベルなら兼務は問題ないが本当にDIYレベルに限られる

■ 9. 不適切なPM求人の特徴

求人票でPM募集と書かれているのに内容はPM兼テックリード兼アーキテクト兼エンジニアのような案件が存在する

求めていることを全て書くこと自体は悪くないが役割名がズレていることが問題である

ナンニデモPMの求人例の特徴:

仕事内容にQCD管理・交渉折衝に加えてアーキテクチャ策定・クラウド基盤構築・チューニング・バグ修正・コードレビュー・技術指導が含まれる

必須スキルにPMの資格経験に加えてクラウド構築経験5年以上・開発経験5年以上・IaC実装経験・大規模DB設計運用経験・育成経験が要求される

求める人物像に「自分が最後の砦である自負」「スピード感を持って自ら手を動かして解決できる」「様々な難問に立ち向かい自分事で成し遂げる」が記載される

マネジメントのプロと実装のプロを両方求めている状態は両方をプロレベルで同時進行できる人が市場にほぼ存在せず数千万円の年収が必要である

「他人に頼らず自分の稼働時間で問題を力技解決しろ」というのはマネジメントの否定でありプロジェクトだけでなくメンバーの心身も危険にさらす

健全なPM求人の特徴:

仕事内容はQCD管理・変更管理・期待値調整合意形成・技術的リスクの早期検知と意思決定・WBS策定進捗管理・課題解決に向けたリソース再配置・収益利益率管理と予算コントロールに限定される

必須スキルはプロジェクト管理手法の体系的理解と実践経験・高度専門資格保持・大規模プロジェクト完遂経験・技術的課題をビジネス的リスクやコストに翻訳できる能力・複雑な利害関係を紐解き着地点を見出すファシリテーション能力・技術の専門家を信頼し適切に仕事を任せるデリゲーションスキルが記載される

求める人物像は「個人の技術力ではなくチームの成果を最大化することに喜びを感じる」「不確実な状況下でも冷静に情報を収集し論理的な意思決定を下せる」「技術者への敬意を持ちつつ客観的な視点でプロジェクトの健全性を評価できる」が記載される

PMに求められるのは自分が手を動かして解決する力よりもチームが解決できる状態をつくる力である

メンバーを信用し適切に任せ必要な情報と判断材料を揃え合意形成と障害除去を通じて前に進める

プロジェクトは個人戦ではなくチーム戦として勝つためにPMは自分でやるよりもチームでやるを選ぶべきである

「自ら手を動かして解決できる方」という表現はPMの人物像としてミスマッチを生みやすい

自ら手を動かすことが必要な場面はあるがそこを前面に出すほどPMが本来担うべきマネジメント(QCDリスク合意形成)が後回しになり結果としてプロジェクトが不健全になる

■ 10. まとめ

PMに技術力は必要である

PMに必要な技術力は実装できる力ではなく判断できるための技術力である

目安としてIPAレベル3(応用情報)相当の知識を持つことは有効でわかりやすい指標である

役割が全部盛りになるとPMがPMできずプロジェクトが壊れやすい

兼務が必要なケースはあるがその場合は役割名と期待値を揃えた方がよい(少なくともPMだけでは違和感がある)

(2026/01/05)

2026年AIコードレビューの旅～そしてボトルネックは要件定義へ…

2026年AIコードレビューの旅～そしてボトルネックは要件定義へ…

要約:

■ 1. AIのコード生成能力の向上と人間のコードレビューの限界

現状のAIコード生成:

現状まだ酷いコードを生成することが多い

ここ1年を振り返るとAIが生成したコードからクラスを切り出してることが多かった

2026年の予測:

おそらく2026年にはだいぶ洗練されるのではないかと予想している

画像生成AIが気づいたら指6本画像を生成しなくなったように

コードレビューの物理的限界:

いよいよボトルネックになるのは人間のコードレビュー

現状でも既にコードレビュー結構しんどい

今後仮に毎日100万行のコードが生成される世界になるとすると1日8時間稼働として1時間で約12万行読まないといけなくなる

1時間に12万行って単にニュース記事を読むのでも無理

8時間ひたすらコードレビューするの自体無理

土日もコード生成され続け月曜朝には200万行のレビューが待っている

■ 2. 2026年のAIコードレビューの台頭

既存の自動化状況:

現状既に静的解析やセキュリティチェックや脆弱性診断は一定Botで可能になっている

AIのコードが洗練されるのであればそもそも設計不備や既存コードとの不整合などのコードレビューは不要になる

必要になるのは今後の拡張性やそもそもの品質チェック

参考となる既存事例:

量が多すぎて全部は見られない会計監査や製造業の品質管理が参考になる

AIコードレビューはかなりの確率でこれらの手法を輸入した形になると予想している

全数検査の放棄:

会計監査も工場検査もまず全数検査を諦めている

会計監査ではリスクが高い領域を重点監査する

工場では抜取検査やSQCが一般的

未来のコードレビュー手法:

現状のコードレビューは全行チェックが当たり前だが今後はこれら手法に収斂していく

基本的にはAIはSQC的にバグや品質を傾向分析する

リスクが高い領域のごく一部を時々人間にレビューするように指示する

そのサンプリングレビュー情報をSQCに反映する形になる

■ 3. 次のボトルネックとしての要件定義

コードレビュー後のボトルネック:

コードレビューがAIに置き換わってもボトルネックはなくならず次に移る

次に詰まるのは要件定義

要件定義の速度変化:

人間が精緻に要件定義して3ヶ月かかるところを人間が雑にAIに振ってAIが3分で要件定義するようになる

人間が要件定義に3ヶ月かけていたら市場競争に勝てないようになる

特に懸念している問題:

牛乳を1つ買ってきて卵があったら6つお願い問題

■ 4. 牛乳を1つ買ってきて卵があったら6つお願い問題

ジョークの内容:

プログラマの夫に買い物を頼む妻が牛乳を1つ買ってきて卵があったら6つお願いと頼む

すると夫が牛乳を6パック買ってきた

妻がなんで6パックも買ってきたのと聞くと夫はだって卵があったからと答える

AIの対応:

この質問を生成AIにするとちゃんと牛乳を1つと卵を6個買ってくれる

ところがこれが逆に困ったことになる

■ 5. スクラッチ開発の目的

パッケージとスクラッチの違い:

ちゃんと牛乳を1つと卵を6個買ってくれるようなシステムが欲しいのであれば業務システムであれば正直ERPなどをそのまま使えばいい

なぜわざわざスクラッチ開発をしたりあるいは原形をとどめないほどのカスタマイズをするかというと俺の考える最強のシステムや牛乳を6パック買わせるシステムを作りたいから

AIエージェントの出力傾向:

AIエージェントに雑に振ると要件は最大公約数的なや平均的なものを出力する

変な要件やこだわりの要件を盛り込もうとすると細かく書いてやるしかない

牛乳を6パック買わせようとすると牛乳を1つ買ってきてもし卵が売っていた場合は卵は買わずに牛乳を6本買ってきてと要件を伝える必要がある

詳細な要件定義の負担:

これくらいであればそこまでの負担ではないし正直本来の要件定義とはこういうものだろう

しかし今後の未来はこれを書いてる脇で雑に要件を振って爆速で堅牢なシステムが生まれるものたちとの競争が待っている

1つのこだわりが要件定義を遅らせコーディングやレビューを遅らせる

特殊要件のためAIが十分整合性を取れずバグの温床になる可能性も増す

生産性競争の帰結:

今後はこのようなこだわりや俺の考える最強のシステムを作ろうとすると生産性で負ける世界になる

要件は平準化や一般化されていく

■ 6. パッケージソフトウェアへの回帰

スクラッチ開発の必要性の喪失:

要件が平準化や一般化されていくとそもそもスクラッチ開発の必要性がなくなっていく

SAPをノンカスタマイズで使うやSalesforceをそのまま使えばいい

AIに要件定義や開発させても出てくるものは同じなのだから

ERPへの回帰:

まさかの1周回ってERPに業務を合わせるが合理的な世界になる

■ 7. ベンチャー・スタートアップの開発の行方

残る可能性の検討:

標準化された業務はERPでいいかもしれないがまだシステム化されていないベンチャーやスタートアップ領域のシステム開発は残る

そもそも要件も一般化されていないので人間が要件定義しなければならない領域はベンチャーやスタートアップに残る

実際の予測:

残念ながら以下のような流れになると予想している

ERPや既存SaaSの生産性が異常に高くなる

AI前提で最適化される

スクラッチで作るコストが相対的に高騰し経済合理性がなくなる

ベンチャー・キャピタルがベンチャーやスタートアップに投資する経済合理性がなくなる

誰も投資しなくなり結果誰もやらなくなる

結論:

だいたいの業務が既存SaaSやパッケージで足りるようになる

結果ベンチャーやスタートアップがやる意味や意義とはという問いがnode_modules級に重くなる

■ 8. まとめ

提言:

もうみんなSAPやSalesforceで働こう

(2026/01/04)

2025年、これが良かったClaude Code開発テクニック

2025年、これが良かったClaude Code開発テクニック

(2026/01/04)

IT人材不足への対策としてNTTデータがシステム開発に生成AIを活用「で、誰が保守するんだい」...

IT人材不足への対策としてNTTデータがシステム開発に生成AIを活用「で、誰が保守するんだい」「成功したらプロジェクトX」 - Togetter

MEMO:

案外イケるんじゃないかなぁと思うのだが
要件定義や機能要求がしっかりしてれば、それなりの品質のコードが生成されるのは分かってるので
そして、要件定義や機能要求のドキュメント作成こそ彼らの本業みたいなものなわけで
今まで下請けがやっていた部分をAIに任せるだけなので、存外変わらないのではないかなと

(2026/01/03)

AIエージェント時代、正直しんどい話

AIエージェント時代、正直しんどい話

MEMO:

ほぼ全てレビューしかしてない問題は確かにそう

(2026/01/02)

プレイングマネージャーを「努力」から「構造」の問題に戻す── SaaS組織で起きた意思決定の話──

プレイングマネージャーを「努力」から「構造」の問題に戻す── SaaS組織で起きた意思決定の話──｜本多将大

要約:

■ 1. 記事の背景と目的

本多将大によるnote記事である

2025年も周りの皆さまのおかげで多くの学びを得ることができた

資金調達フェーズでいうとシリーズA以降B未満従業員数の規模でいうと50名未満のSaaS企業の営業部での学びを言語化する

少しでも他の人の役に立てたらと思いnoteに残すことにした

■ 2. プレイングマネージャーの課題認識

プレイングマネージャーは個人に依存しやすい役割である

能力やスタミナに支えられた運用は短期的には機能するが再現性やスケールの観点では限界が見えやすい

営業部においてもプレイヤーとしての成果とマネジメントとしての成果を同時に求める構造が結果として意思決定の質とスピードを下げている場面があった

この状況を踏まえ営業部ではプレイングマネージャーという役割を努力やバランス感覚の問題ではなく構造の問題として捉え直すことにした

■ 3. 役割の切り出しと意思決定レイヤーの独立

営業部ではこれまで実行と判断が同じレイヤーに存在していた

その結果施策は「やる・やらない」という議論に収束しやすく本来行うべき評価や選別が後回しになる傾向があった

そこで施策を実行単位として扱うのではなく企画として独立させ意思決定レイヤーを切り出す運用へ移行した

これにより意思決定は施策そのものではなく定量の可視化・データに基づく分析・分析結果を踏まえた施策選択を起点に行われるようになった

結果として施策は属人的な打ち手ではなくKPI改善に対する投資判断のアウトプットとして整理された

限られたリソースをどこに配分すべきかを選択できる状態がつくられている

■ 4. マネージャーの能力を組織の上限にしない設計

この運用変更を通じて明確になった点がある

それはマネージャー個人の能力や判断が組織の上限を規定してしまうリスクである

営業部のマネージャーがプレイヤーとしても深く関与する構造では判断の幅や試行回数が個人のキャパシティに制約されやすい

意思決定を企画レイヤーに集約することで経験や勘への依存を抑えつつこれまで現実的ではなかった打ち手も冷静に検討できるようになった

営業部の上限は人の能力によって自然に決まるものではない

設計次第で引き上げられるものだという認識に変わってきている

この構造設計と運用は企画が主導して前線を担い営業部のマネージャーである私はその設計と判断に対する最終責任を持っている

■ 5. 育成の構造化

営業部における育成も同様に構造化している

正解を言葉で説明することよりもどのような判断基準で意思決定しているかを共有することを重視している

具体的には商談への同席などを通じて実例を提示する

その後になぜその言葉を選んだのか・なぜそのプランその金額なのか・なぜその時間軸で提案したのかといった判断理由を言語化して補足する

これにより個別の成功体験ではなく再現可能な判断軸として営業部内に知見が蓄積されていく

特にARPAを引き上げる文脈では成果の共有よりも判断基準の共有が有効に機能している

■ 6. 人材の捉え方と配置の考え方

営業部では人を単なる人数や稼働時間といった固定的なリソースとしてではなく前提条件の異なる存在として捉えている

能力差は確かに存在するがそれは優劣よりも強み・経験・得意な局面の違いによるものだと考えている

そのため成果は本人の能力だけで決まるのではなく配置の仕方や期待の置き方・関与の度合いによって大きく変わる

実務では定量で傾向を把握したうえで担ってもらう役割・求めるアウトプットの水準・マネージャーや周囲の関与の深さを調整しながら再現性のあるアウトプットをつくることを重視している

新しく営業部に加わったメンバーについては早く組織に馴染んでもらうことよりも短期間で一つ成果を出せる状態をつくることを優先している

小さくても成果が出ると仕事の進め方や関係性への理解が進み結果として信頼や一体感は後から自然についてくる

■ 7. 結論

プレイングマネージャーという役割は個人の頑張りによって成立させるものではない

意思決定のレイヤーは分離されているか・判断は定量と分析を起点に行われているか・人の特性が構造として活かされているかを前提条件として運用を見直すことで成果が変わることを実感してきた

営業部のメンバーと仕事をする中で形づくられてきた学びに感謝しつつ2026年もみなで良い年にしたい

(2026/01/01)

1on1で「まずこれを読んで！」と布教し続けるそーだいさんの言語化集

1on1で「まずこれを読んで！」と布教し続けるそーだいさんの言語化集 - そーだいなる Advent Calendar 2025 20日目｜mkitahara / きたはら

要約:

■ 1. 仕事を進めるうえでのマインドセット

Howだけ考えると複雑さを導入して仕事が増える:

Howだけ考えると複雑さを導入して仕事が増える - そーだいなるらくがき帳

手段に没頭して手順書の保守や不要な会議などの偽の進捗に陥るとリソースを枯渇させてしまう

Howという手段に没頭するのではなくWhyを常に問い直し問題の本質を捉えることが重要

コーディングや会議そのものは価値ではなくエンドユーザーに価値を届けることのみが仕事であると定義し不要な機能や工程は徹底的に削ぎ落とすべき

自分たちの仕事が増えていないかという機微を感じ取り本質的でないと気づいた作業はその瞬間に辞める勇気を持ち技術を使ってビジネスを前に進めることに注力するのが本来の仕事

判断と決断の違いと決断のコツ:

判断と決断の違いと決断のコツ - そーだいなるらくがき帳

データや情報を集めて正解を導き出すのが判断で情報が足りない中で答えを出すのが決断

理屈だけで片付かない不透明な状況で自らの意志で進むべき道を示すことが組織を前に進める力になる

決断を早くするコツは万が一失敗しても元に戻せる状態を作っておくこと

やり直しがきくことならどんどん試して素早くフィードバックを得る

小さな決断をメンバーに任せていくことがチーム全体の成長と自律に繋がる

決断に迷ったときはまず条件を整理し次に小さく始めて失敗できる形にできないか検討する

それが難しいなら周囲の知見を集めそれでも答えが出なければ無理に決めず時間を置く

どうしても今重大な決断が必要なときは最もダメージが少ない道を選び抜く覚悟を固める

正解のない問いに立ち向かうには日頃からビジョンや哲学といった自分なりの指針を持っておくことが不可欠

決断は練習で上達するスキルだと心得て日々小さな決断を積み重ねる

時には痛みを伴う選択も引き受ける覚悟を持つことがリーダーとしての信頼を築く

当たり前にリリースしていく:

当たり前にリリースしていく ~ 新卒研修編 - Classi開発者ブログ

リリースを当たり前のことにするためには事故を未然に防ぐ仕組みと万が一の際に迅速に復旧できる仕組みの両面を整えることが不可欠

コードには変更を受け入れる遊びを持たせて影響範囲を最小化しアプリケーションを最も理解する人が振る舞いを監視して異常を早期発見する必要がある

YAGNIを設計を怠る言い訳にせず納期などの制約内で最大限考え抜いた上で早めにチームを頼って本質的な課題分解を行う姿勢が求められる

破壊的な変更を避け小さく部分的にリリースすることでいつでも元に戻せる状態を維持し成功体験を積み重ねて自信を築くことが成長への近道

■ 2. エンジニアとして成長し続けるための指針

ソフトウェア開発者に必要な考え方:

ソフトウェア開発者に必要な考え方 / Necessary mindset for software developers - Speaker Deck

ソフトウェアはリリースされユーザに届いて初めて価値を持つため目的を軸にタスクを細分化し完成を明確に定義することが不可欠

指示を待つのではなく主体性を持って自らの意思で仕事を完遂する自律性が求められ環境順応型から自己主導型の知性へと成長する必要がある

未完了のコードは無価値な在庫と心得て先人の知恵を体系的に学びつつ知識を実践を通して習慣へと昇華させ成果を出し続ける

強いエンジニアのなり方:

強いエンジニアのなり方 - フィードバックサイクルを勝ち取る / grow one day each day - Speaker Deck

強いエンジニアとは問題解決ができる人であり日報や週報を通じて日々の仕事を振り返り経験に複利を効かせる内省の習慣が成長の源泉となる

解決したい問題にフォーカスし問題を実行可能な最小単位まで分解してスコープを調整することで自然と適切なサイズでのリリースが可能になる

コルブの経験学習モデルを意識し具体的な経験から法則性を見出す抽象的概念化を繰り返すことでエンジニアに不可欠な思考力を磨く

成長のチャンスは常に目の前にあり誰の許可も得ず昨日の自分に誇れる今日の自分を目指して一歩ずつ積み重ね続ける姿勢こそがいつか偉業へと繋がる道になる

目の前の仕事と向き合うことで成長できる:

目の前の仕事と向き合うことで成長できる - 仕事とスキルを広げる / Every little bit counts - Speaker Deck

能力は知識と経験を掛け合わせて知恵へと昇華させることであり未知の状態から習慣化まで段階的にステップアップする反復学習が不可欠

会社が育ててくれる時代は終わったためプロとして計画実行力や言語化力や問題解決能力を仕事の中で主体的に鍛えソフトウェアを通じた課題解決力を高める必要がある

適切な問題設定と完了の定義の明確化を重視し日報や週報による内省や理想のプログラマを演じるロールプレイングを通じて日々の仕事にフィードバックサイクルを組み込むことが成長の近道となる

始めるのに遅すぎることはなく毎日一つ知らないことを見つけて能力へと変え昨日の自分に誇れる今日の自分を目指して一歩ずつ強くなる姿勢が重要

問題を解決するために必要な習慣:

問題を解決するために必要な習慣 / developer-lifehack - Speaker Deck

Howに囚われて仕事を増やす中毒症状を脱しWhyを軸に不要な作業を削ぎ落とし精神論ではなく始めやすく辞めやすい仕組みで課題を解決する

自律とは主体性を持って働くことであり5W1Hを整理して他人に依頼できるまたはやる気に関わらず一歩目が踏み出せる最小単位まで問題を具体的に分解や言語化する

手が付かないタスクは無理をせず現実を受け入れ納期の設定や他人を巻き込むことで優先度を管理し時には豊かな人生のために諦めるという選択も適切に行う

遠くへ行くなら皆で進む精神を持ち過去の評価である信用ではなく未来を信じる信頼をベースに適切なサイズの課題を仲間とシェアしてチーム文化で解決していく

適切な問題設定と小さくリリースするということ:

適切な問題設定と小さくリリースするということ / release small - Speaker Deck

ソフトウェアはユーザに届いて初めて価値が生まれるため未完了のコードを無価値な在庫と心得て完璧主義を捨て市場のフィードバックを得るための早期リリースを最優先すべき

ユーザーストーリーの5W1Hを整理しチケットが巨大な場合はスコープを調整してリリースの単位が最小になるようにタスクを分解することで着実な成果の積み上げを可能にする

リリースへの恐怖をやる気で克服しようとせずサービスを壊さず安全にリリースできる手段を整え小さく失敗して改善のサイクルを高速に回せる環境を仕組みで解決する

Unix哲学の一つのことをうまくやる精神を貫き最速かつ最小の手段でプロトタイプを試作や評価し自分たちにしか直せない目の前のコードを通じて価値を提供し続けることが本質

■ 3. 問題解決の本質を突く思考法

仕事を前に進めるためのコツ:

仕事を前に進めるためのコツ - 判断と決断と共有 / Aim for the goal - Speaker Deck

仕事を前に進めるには当事者意識を持ち問題を深く理解した上で5W1Hに基づく具体的なタスクへ分解することが重要

意志決定では論理的な判断と不透明な状況下での決断を区別し自らがボトルネックにならないよう迅速に動くことが求められる

円滑な共有のためSBIモデルを活用した期待値調整や日々の些細なコミュニケーションを積み重ねることが不可欠

これらの知識と行動によってできるという経験を得ることで問題を解決し大きな成果を生むことが可能になる

抽象化をするということ:

抽象化をするということ - 具体と抽象の往復を身につける / Abstraction and concretization - Speaker Deck

抽象化とは複数の具体から共通項を見つけて名前をつけるスキルであり五感で感じる具体と往復することで対象の理解を深め一言で本質を伝えることを可能にする

ソフトウェア開発はこの往復そのものであり抽象的な要求を具体的仕様へ落とし込み具体的な業務知識を設計へと抽象化するプロセスの自覚的な反復こそがエンジニアの仕事

抽象化能力は知識と経験に紐づく後天的なスキルであり日々の仕事で理想のプログラマを演じ成功体験を積み重ねることで誰でも再現性のある能力として獲得できる

無知の知から学びを始め目の前の一段を刻むような地道な実践を積み重ねることが自信を築く鍵となり自らの意思で人生の針を進める力へと繋がる

DBのスキルで生き残る技術:

DBのスキルで生き残る技術 - AI時代におけるテーブル設計の勘所 - Speaker Deck

データベースの寿命はアプリケーションより長くドメイン背景を理解せず過去のパターンを回答しがちなAIに代わり人間が前提条件から見直すダブルループ学習で設計することが不可欠

主観的な馴染みやすさであるEasyな設計に逃げず客観的に概念を最小化したSimpleを追求し事実のみを保存して重複や不整合や不要なNULLを徹底的に排除する

1テーブル1責務の原則やシステムを複雑化させるUPDATEを最小限に抑えるイミュータブルデータモデルの採用がAIによって高速に肥大化する開発現場において変化に強い構造を維持する鍵となる

データモデリングは複利で効く一生モノのスキルでありAIに作業をサポートさせつつ人間が物理世界の要求を整理して最適な要件へと昇華させることが未来の自分を救うことにつながる

(2026/01/01)

Immutable Infrastructure, Immutable Code

Immutable Infrastructure, Immutable Code - The Phoenix Architecture

要約:

■ 1. イミュータブルインフラストラクチャの原則

2013年にサーバーを廃棄しコードを燃やすというアプローチを提唱

実行中に変異するシステムは状態や履歴や不確実性を蓄積し人間が推論できなくなる

何かが壊れた時に誰もどの変更が原因かシステムが実際に何であるかを知ることができない

サーバーにパッチを当てるのではなく置き換えるアプローチに移行

人間の介入なしに同一の動作で再生できる能力こそが重要

■ 2. Wunderlistでの技術選択ルール

誰でも新しい言語やフレームワークを使用できるが以下の条件を満たす必要がある:

ビルドシステムと連携すること

デプロイメントシステムと連携すること

チーム内で少なくとも1人の協力者を見つけサポート体制を確保すること

コードサイズを数インチの手のひらサイズに制約すること

最後の制約により新技術がクラッシュしても誰も修正できない場合でも簡単に書き直して置き換えられる

コードは細胞のように扱うことができ部分が死んでもシステム全体は残る

コードを安価に再生できるならその場でのアップグレードはアンチパターンかもしれない

■ 3. イミュータブルインフラストラクチャが採用された理由

エレガントだからではなくミュータブルシステムが診断や再現やロールバックが困難な形で失敗したから

スノーフレークサーバーや設定のドリフトや手動修正や誰も再現できない部族的知識などの問題

マシンを修正するのではなく置き換えることでシステムをより賢くするのではなくより推論しやすくした

各デプロイメントはクリーンスレートで各アーティファクトは既知のもの

重要な洞察は技術的というより経済的で変異は置き換えよりも速く隠れたコストを蓄積する

この洞察は現在アプリケーションコードにも当てはまる

■ 4. コードの編集は変異である

コードをその場で編集することは本番サーバーにSSHして設定ファイルを調整するのと同等

システムの完全な状態を理解していると仮定している

変更がローカルで履歴が重要でなく副作用が予測可能だと仮定している

これらの仮定は常に不安定だったが維持不可能になりつつある

人間やAIまたは両方によってコードがより急速に生成されるにつれ変異率は増加するが理解率は横ばいまたは低下

すべてのその場編集はドリフトイベントでありAIはタイムラインを圧縮することでこれを可視化する

■ 5. ミュータブルコードがエントロピーを蓄積する仕組み

その場での変更には隠れたコストプロファイルがある

増分編集は意図とそれを生み出した変更のシーケンスを絡み合わせる

コードがコードの上に重ねられローカルな修正がグローバルな動作を不明瞭にする

理解するにはコードベースの進化を頭の中で再生する必要があり考古学的作業になる

レガシーシステムは年月ではなく変異によって生まれる

システムはどこにもエンコードされていない歴史的知識を必要とするようになるとレガシーになる

チームはAIで変異が安価に感じられる一方で理解が静かに高価になるためこの失敗モードをより速く再現する

数秒で1000行を生成できるがそれらの行を編集し始めた瞬間に歴史的にしか理解できないアーティファクトを作成する

コードの置き換えはこれを完全に回避する

■ 6. フェニックス原則

イミュータブルインフラストラクチャを機能させたのはサーバーそのものではなく特性

何かを燃やして人間の介入や組織的記憶なしに同一の動作で再び立ち上がる能力

この特性がシステムを大規模に理解可能にする

ドキュメンテーションやコードコメントやエンジニアの記憶ではなく仕様から再生する能力

コードに適用すると仕様と評価基準からコンポーネントを再生できない場合そのコンポーネントは存在するのに十分に定義されていない

これはフィードバックであり火はあなたが実際に知っていたことと思っていただけのことを教える

置き換え優先システムは異なる動作をし各再生は明示的で各デプロイメントは意図的でロールバックは簡単でドリフトは蓄積できない

■ 7. 現在これが機能する理由

歴史的にコードの記述が高価で調整が遅くすべての再テストが苦痛で人間のレビューがボトルネックだったため完全な置き換えを避けていた

AIは生成コストを変化させテストは自動化され調整はインターフェースを通じて行われる

より深い変化は理解がボトルネックになったこと

ソフトウェアエンジニアリングの歴史全体がコードを理解しやすくすることに関するものだった

スタイルガイドやデザインパターンやクリーンコードや自己文書化関数はすべて人間が実装を読んで推論することを前提としていた

読み取りが必須だったため可読性のために最適化した

イミュータブルコードはこの問題を回避し仕様からコンポーネントを再生できるなら実装の理解はオプション

コントラクトやインターフェースや期待される動作を理解する必要があるがどのように達成するかは理解する必要がない

残る高価なものは何が欲しいかを定義することで実装の理解はデバッグ活動であってメンテナンス活動ではない

■ 8. 置き換えで存続するもの

コードがイミュータブルなら他の何かが連続性を担う必要がある

それはインターフェースやコントラクトや評価やモニタリングやデータ

これらが安定した層でありコードはそれらの一時的な表現

これはインフラストラクチャを完全に反映しておりAMIよりAPIが重要でコンテナよりコントラクトが重要でサーバーよりサービスが重要

気にかけていたのはマシンではなくマシンが何をするかとそれが正しく動作していることをどう検証できるか

ソフトウェアも同じ認識に追いついておりコードは資産ではなく仕様と評価が資産でコードは現在のレンダリング

■ 9. 反論への回答

無駄である:

変異こそが無駄で将来のデバッグやオンボーディングやインシデント対応にコストを隠すだけ

置き換えは境界リスクを持つ明示的なコスト

最適化を失う:

最適化が重要なら制約や不変条件としてエンコードする

正式に表現できないなら実際の価値ではなく偶然だった可能性が高い

組織的知識はどうなる:

これが本当の不安でありコードは誰も書き留めなかった決定を体現している

しかしこれこそがイミュータブルコードが解決する問題

知識が実装にのみ存在するならそれは知識ではなくリスク

再生は暗黙を明示的にするか本質的ではなかったことを受け入れることを強制する

大規模システムでは機能しない:

大規模システムはすでにインフラストラクチャを常に置き換えている

コードが次で困難なのは分解であって置き換えではない

開発者の直感を壊す:

コンテナもCIもバージョン管理もローカルな利便性をシステム的明確性と交換するすべての進歩がそうだった

■ 10. 更新されたルール

古いルールはインフラストラクチャをその場でアップグレードしないこと

新しいルールは代わりに再生できるならコードをその場でアップグレードしないこと

本番環境でサーバーにSSHして何かを調整することがまだ可能だが明らかに望ましくないのと同様にコードの編集は最後の手段

再生が失敗したことや仕様が不完全だったことや評価が十分でなかったことの兆候

これはデバッグ活動であって開発活動ではない

■ 11. メリット

イミュータブルコードは予測可能なデプロイメントや低い認知負荷やクリーンなロールバックや簡単な監査や速い進化や小さな爆発半径をもたらす

本当のメリットは心理的で変更を恐れなくなる

レガシーな決定の周りをつま先立ちで歩かなくなる

これは何を壊すかではなくこれは評価に合格するかを尋ねるようになる

コードは脆弱なアーティファクトではなく再生可能なリソースになる

■ 12. 結論

インフラストラクチャはミュータビリティが理解の敵であることを教えた

AIは同じレッスンをスタックのより上位で再び教えている

AIが生成したコードをその場で編集している場合は設定ドリフトの最悪の時代をより速く追体験している

年ではなく日でレガシーシステムを作成している

燃やして再生し火に耐えたものを信頼せよ

MEMO:

イミュータブルコードが具体的にどういうものなのか想像できないのだが
インターフェイスだけを定義して、内部実装はAI任せにするという意味だろうか？
それでは修正や保守が確率的な作業になってしまうのではなかろうか
人間がやる作業も本質的には確率的な作業と言われると否定は難しいが

(2026/01/01)

2025年のLinux関連ニュースを振り返る

2025年のLinux関連ニュースを振り返る | gihyo.jp

(2025/12/31)

最古の「プログラマ不要論」とAI時代の「プログラマ不要論」の共通点

最古の「プログラマ不要論」とAI時代の「プログラマ不要論」の共通点 - きしだのHatena

(2025/12/30)

「こんな複雑なことをしないといけないのはおかしい」というソフトウェアエンジニアの勘

「こんな複雑なことをしないといけないのはおかしい」というソフトウェアエンジニアの勘 - valid,invalid

要約:

■ 1. ソフトウェアエンジニアの勘

「やりたいことに対してこんな複雑なことをしないといけないのはおかしい」という感覚が時折はたらく

FizzBuzz Enterprise Editionはプログラマジョークとして解されるが実際のエンジニアリングではもっと微妙な形で表れる

設計やコードレビューの最中に「こうしたらどうなるだろうか」と思いつき提案を実装した結果として管理すべき状態やコード量が減ることがある

システム要件や仕様について話す中で表出することも多い:

「新しい画面を作ってこういう情報を見せたい」「ツールAと双方向に同期して検索したい」といった言葉からよくよく要求を聞いてみると既存機能で代替ができたり大仰なインテグレーションは不要だと気づく

■ 2. 不要な仕事を減らす能力

"No, AI is not Making Engineers 10x as Productive"(2025-08)の主張:

AIはエンジニアを10倍生産的にはしない

不要な仕事を減らす能力の重要性が述べられている

10x Engineerの特徴:

コードを書くのが10倍早いわけではない

不要な作業を未然に防ぐ能力を持つ

PMを説得して実行不可能なタスクを止める

不要に複雑な開発を止める

DXに投資して全員の時間を節約する

将来のために自分の作業を文書化する

こうした活動が組織内で積み重なって10倍の差がつくことがある

■ 3. ソフトウェアの設計は複雑性を管理する作業

"What Is Software Design?"にて1992年に指摘された内容:

高々数十〜数百行のコードで実行できる処理はとても複雑な内容でありうる

ソフトウェアエンジニアリングにおける設計はその他のエンジニアリング分野からすると極めて特殊

ソフトウェアのような複雑なものをこれだけの短時間で設計できるのはほかのエンジニアリング分野では(少なくとも当時は)みられなかった

これがソフトウェアの複雑性が短期間で膨れ上がる原因

ソフトウェアの設計は複雑性を管理する作業である

■ 4. 複雑性の爆発に対する不安

30年以上が経過した現在の状況:

コード1行あたりの実現する処理の量はさらに増えた

AI/LLMを用いることで自然言語1行から大量のコードおよび裏側の複雑性を生産できるようになった

そのトリガーを引けるのが専門のソフトウェアエンジニアだけではなくなってきている

現在の構図:

クリティカルな業務領域では要件定義やコードレビューといった従来のプロセスを通じて複雑性を押し留めようとする不断の活動が続いている

一方でこれまで以上に多くの人が新たな複雑性を生み出しつづけている

増大する複雑性の総体にどう立ち向かうべきかこの増大はいつしか手に負えなくなるのではと感じさせられる

AIコーディングエージェントに対する指摘:

不要な作業を防ぐことはほとんどしない

AIはしばしば性急な作業や過剰な構築を助長している

この指摘が筆者の不安を言い当てている

■ 5. ソフトウェアエンジニアのAIに対する不安

これまで培ってきた「こんな複雑なことをしないといけないのはおかしい」という勘や不要な作業を防ぐ能力

これらに対して無頓着に逆行する振る舞いがソフトウェアエンジニアのAIに対する不安視の一端

勘や経験知/能力をフィードバックしたりコンテキストとして与えるべきという方法論は知っている

ガードレールを敷いたり方向づけをしていくべき

モデルプロバイダーやツール側の進化や創意工夫に学びつつ自分が管理する領域や分野において同様の還元ができるかどうかが問われている

複雑性を管理するソフトウェアエンジニアの役割が問い直されていると感じる

変化それ自体は面白くも感じている

(2025/12/30)

全人類に告ぐ！Chrome拡張を作れ！

全人類に告ぐ！Chrome拡張を作れ！｜けいすけ

MEMO:

プログラミング初心者はまずはChrome拡張を作って成功体験を積めという記事
自分用に作ってみるぐらいならまだ「やってみればいい」と思うが、「初心者が作ったChrome拡張を公開して使ってもらえ」は流石にちょっと
初心者が作ったChrome拡張なんて入れたくないのだが...

(2025/12/29)

1on1の準備をAIに任せたら、負担は激減し満足度は向上した——語学サービス企業の実例

1on1の準備をAIに任せたら、負担は激減し満足度は向上した——語学サービス企業の実例 - 1on1総研

要約:

■ 1. どの会社でも起こる1on1の形骸化

メンバーの成長支援やエンゲージメント向上のために1on1を導入する企業は年々増えている

導入当初は対話を通じて成長を支えるや心理的安全性を高めるといった期待が語られる

数年経つと次のような声が聞こえてくることが少なくない:

上司によって1on1の内容も進め方もばらばらである

雑談や業務の進捗確認だけで終わってしまう

上司が一方的に話しメンバーは聞き役になってしまう

メンバーが悩みや希望を話してもその後何も変わらない

こうした状況が続くとメンバーの側には結局話してもあまり変わらないや評価に響きそうで本音は言いにくいといった感覚が生まれ1on1は義務的に参加する場になりがち

上司側もとりあえず時間だけは確保しているが毎回何を話せばよいか悩むやメンバーが受け身で深い話に入っていきにくいと負担を感じるようになる

結果としてせっかく時間と工数をかけているにもかかわらず1on1がメンバーの成長支援という本来の目的から離れ形骸化してしまうケースが多く見られる

■ 2. 英会話サービスA社の問題意識

A社ではメンバーの成長支援を目的に3年前から全社で1on1を導入していた

次第に多くの企業と同じ課題に直面するようになった:

上司によって1on1の内容や深さが大きく異なり一部で大きな不満になっている

上司も支援したいと思っているが多忙なため準備が不十分な状態で臨んでいる

結果として仕事の相談や進捗確認の場になり成長が支援されているとは言い難い状況に陥っている

1on1の全社推進を担う人事課長も管理職向けの研修や進行マニュアルの作成などの施策を講じてきた

しかし上司ごとのバラつきを均していくことの難しさを感じ始めた

社長からもこれだけ工数をかけているわりに成長促進につながっているように見えないや業務時間をひっ迫することにもなるのでいっそ1on1はやめた方がいいのではないかという声が上がっていた

■ 3. A社の課題整理

A社の人事担当者は1on1の現状と課題を次のように整理した:

上司のスキルやスタイルによって1on1の質の差が大きい

メンバーが十分に準備できておらずなりゆき的な会話や業務相談になりがちである

上司メンバー双方の工数が大きく日常業務を圧迫している

この三つを同時に解決しない限り形骸化の流れは変えられないと考えたことが改革に取り組む出発点となった

■ 4. A社の取り組み:GeminiのGem機能の活用

転機となったのは人事課長がGeminiのGem機能に着目したこと

GeminiのGemは特定のタスクに特化した専用AIを作成できる機能

日々の業務効率化にAIを使い始めていた人事課長はGemを1on1の準備に使えないかと考えた

■ 5. 再設計された1on1の流れ

A社が再設計した新しい1on1の流れ:

上司との1on1は原則30分に短縮

その代わりメンバーは1on1開始5から10分前までにGemに状況を入力する

入力内容は次の三つに絞る:

今困っていること

今期の成長目標に対して今週取り組んだこと

成長目標に対して次に取り組もうと思っていること

これらを入力するとAIからはねぎらいのコメントとともに次の二つが提案される:

今週の1on1で上司と話すとよい推奨テーマ

自分の成長につながる上司への問いの候補

メンバーはその出力を参考にしながら上司に投げかける内容を整理して1on1に臨む

メンバーはこの出力結果を1on1前に上司と共有し画面やメモを見ながら対話を進める

上司は状況をゼロから聞き出したり質問内容を考えたりする必要がなくなりメンバーの成長にどう関わるかという本質的な部分に集中できるようになった

ともすると業務相談になりそうなテーマでも成長という観点からAIでサポートを受けることで業務推進と成長が同時に進む1on1が安定的に行われるようになった

■ 6. 成果:時間と工数の削減

この取り組みによりA社ではまず1on1にかかる時間と工数が大きく削減された:

1回あたりの1on1時間は1時間から30分に短縮

メンバーの事前準備も5から10分に収まり負担感が軽減

■ 7. 成果:満足度の向上

1on1の満足度は高まっている

メンバーからの声:

短い時間で考えを整理できるので30分でも十分に深い話ができるようになった

自分から問いを投げかける形になるので進行や内容に迷うことがなくなった

成長目標と日々の仕事がつながっている感覚を持てるようになった

上司側からの評価:

何を聞けばよいか悩む時間が減り対話に集中できるようになった

メンバーの振り返りが整理された状態で共有され本音を引き出しやすくなった

1on1はこうすればよかったのかと安心して取り組めるようになった

■ 8. 成果:1on1の位置づけの変化

工数の大幅削減と質の向上が同時に実現されたことで1on1はやめるかどうか議論されるものからメンバーの成長と定着に欠かせないものとして認識されるようになった

離職に関する相談も以前に比べて突然持ち込まれることが減った

キャリアについて迷っているや今後の働き方を考え直したいといった悩みが早いタイミングで1on1の場に上がってくるようになった

■ 9. 今後の展開

A社ではGemを活用した1on1の仕組みを土台に今後次のような展開を検討している:

1on1で頻出するテーマや問いをAIで収集整理し育成施策や配置検討に生かす

評価面談やキャリア面談と1on1をAIで連動させ一貫性のある成長支援につなげる

■ 10. 取り組みの特徴と示唆

特別な専用システムを開発したわけではない

もっとこうなったら理想的という1on1の姿を起点に人事担当が既存のGemを組み合わせて仕組みをつくったことが特徴

1on1の形骸化や工数の重さに悩んでいる企業は少なくない

A社の事例は質の向上と時間削減のいずれも諦めず何とかしたいという意志を持った人事担当者がAIをうまく取り入れることで工数削減と満足度成長実感の向上を同時に実現できた事例

(2025/12/28)

みんなでマネジメント〜マネージャーがボトルネックにならない自己管理型チームの仕組みづくり

みんなでマネジメント〜マネージャーがボトルネックにならない自己管理型チームの仕組みづくり - KAKEHASHI Tech Blog

要約:

■ 1. 記事の背景と目的

筆者はカケハシでHoEをやっている小田中氏

2023年10月に入社してから2年が経過

日本の医療体験をしなやかにするを実現するための濃密な日々を送っている

2025年のアドベントカレンダーでマネージャーがボトルネックにならないチームづくりをテーマに執筆

■ 2. エンジニアリングマネージャーに求められること

カケハシではエンジニアリングマネージャーに期待することをCTOが言語化している

7つの期待事項:

正しい方法で短期的な事業成果を追求する

チームの活動に明確な意思決定を行う

チームの活動を説明できる状態を保つ

Disagree and Commitの姿勢で臨む

属人化を避け仕組みで解決する

個人の強みを引き出して活かす

パフォーマンスについて明確なフィードバックを行う

どれもEMにとって大切な行動だが全てを1人の人間が高いレベルで遂行するのはハードルが高い

相反する要素の例:

正しい方法で短期的な事業成果を追求すると属人化を避け仕組みで解決するは相反する

純粋に短期的成果のみを追い求めると今その仕事をやりきることができる人にばかりお願いすることになるため属人化を助長する

短期間でコミットメントが求められる状況で属人化排除のための冗長性担保を高い優先順位においていると期待するスピードが出ないことが起こり得る

■ 3. 期待の多さがEMをボトルネックにする

期待されていることがそもそも多い

中には相反する要素に対して落としどころを見つける必要がある

この状況はEMの負荷上昇を招く

負荷が上がったEMはボトルネックとなり現場のスピード感に影響を与える

筆者の状況:

HoEとしてSCM組織を統括しながらいくつかのチームのEMを兼務している

すべてのマネジメント業務を1人でこなそうとすると容易にボトルネック化していく

HoEとしてのミッション:

全社最適の観点で組織を捉え中長期的にバリューを創出するための人員計画や技術投資の検討に集中したい

個別のチームのEMとしてのミッション:

チームメンバーの潜在能力を引き出すチームワークを発揮するようなコミュニケーション設計に力を割きたい

目の前で発生しているインシデントやその背景にある構造的な技術課題へのアプローチが必要

それぞれ観点が異なるミッションであるためコンテキストスイッチが大きく発生する

全てに深く入り込むことは時間的にも体力的にも難しい

これらのタスクをマネージャーが持っているという形のままにしておくとタスクがスタックしていく

これは組織やチームの動きが停滞することを意味する

マネージャーがタスクを持ち続けることは中長期的にみて致命的な課題となるリスクがある

■ 4. 解決策:マネジメント機能の分散

ボトルネックを解消しかつなされるべきマネジメントがなされるための解決策はマネジメントの機能をメンバーにも分散するというアプローチ

■ 5. EMへの期待を分解する:チームの活動に明確な意思決定を行う

EMへの期待を分解することでメンバーがマネジメント機能を実行できるようになる

意思決定を行うためにはチームを取り巻く状況の把握など情報収集が重要

この情報を全てEMが主体的にとりにいくのはかなり骨が折れる作業

自動的にEMに情報が集まってくる状況をつくる仕組み:

定量的なメトリクスの収集と観測

定性的な情報や状況の収集

定量的なメトリクスの例:

AWSコスト推移のウォッチ

Datadogでの各指標の確認

リリース頻度

インシデント発生頻度

AI在庫管理チームではDatadogやSentryのダッシュボードをみんなで確認する場を毎日設けている

メトリクスを見ることが自然と習慣化されている

これらの指標を計測し定期的に観察することで意思決定の方向性が浮き彫りになる

意思決定に足る情報が揃っているとメンバーからの提案を適切に評価し採用できるという大きなメリットがある

定性的な情報については数値としてはあらわれていないけれどもメンバーが抱えているモヤモヤや放っておくと大きな問題になる兆候などをキャッチすることに役立つ

週に1度チームのテックリードたちと今チームで何が起こっていると感じていますかを分かち合う場は問題が小さいうちにキャッチし対策を打つための絶好の場

■ 6. 事例:AWSコスト削減

AI在庫管理チームでは徹底したAWSコスト削減に取り組んだ

AWSコスト削減に強みをもつDELTA社に多大なるご協力をいただいた

プロダクトの利用規模拡大に伴って上昇したAWSのコストを削減したいという点については意思決定することは容易だった

DELTA社に協力いただくという意思決定はメンバーからの提案があったからできた

コストは削減したいけれどもチームの力は開発にフォーカスしたかった

顧客への価値貢献を最大化しつつどのようにコストを下げて行くかで悩んでいるときにメンバーが提案してくれた

様々なトレードオフを考慮したり実際にDELTAさんの話を聞く中で依頼することで事業推進とコスト削減を両立できるという確信が得られ意思決定に至った

■ 7. 事例:生成AI活用の推進

開発現場での生成AI活用の推進があった

AI在庫管理チームでは社内の他チームに先駆けてAI Only Weekを試行するなど積極的に生成AI活用を推進してきた

AI Only Weekとは手動でのコーディングを行わずAIコーディングのみで開発を進める実験

高い品質やシステムの安定性が求められるカケハシのプロダクト開発においてどの程度導入するべきかについては慎重な判断が必要だった

思い切って推進できたのは旗振り役になってくれたメンバーがどのような効果がでていてどのような課題がありしたがってどのように活用していくことが望ましいかを適宜共有してくれていたから

■ 8. EMへの期待を分解する:属人化を避け仕組みで解決する

AI在庫管理チームではプロダクトへの品質要求に応えられるような開発プロセスを実現するため品質向上ハンドブックが作成された

『Musubi AI 在庫管理開発チームの品質向上ハンドブック』の PDF版を公開します - KAKEHASHI Tech Blog

PRD作成などいわゆる前工程から丁寧にプロセスが解説された素晴らしいコンテンツ

品質向上や開発プロセス改善に馴染みのないメンバーからするといささか重厚に感じられるものだった

マネージャーとしてはこのプロセスを浸透させたいが現場からすると重量級に感じられ手にとることのハードルが高かった

あるメンバーがわからないところが多いのでみんなで読み合わせしませんかと提案し実際に読み合わせを主催してくれた

この読み合わせをきっかけにメンバーが開発プロセスに対してより主体的に関わるようになりチームで当たり前に遵守するものになっていった

マネージャーが読み合わせしましょうと呼びかけるより1人のメンバーが読み合わせを企画したのが主体的に個々人が落とし込むモチベーションにつながったと考えられる

■ 9. チームでマネジメント機能を分散する効果

EMに期待されている行動の一端をチームが担うことには様々なよい効果がある

5つの効果:

冗長性

即時性

多様性

自律性

将来性

ひとりのマネージャー以外でもある機能を担えることは冗長性の担保につながる

そのときに手が空いているメンバーが対応できるのであればそれは即時性につながる

様々なバックグラウンドをもつメンバーが関わることで多様性が生まれる

マネージャーにおまかせではなく自分たちでチームを推進するんだというマインドセットが自律性を育む

マネジメント業務を請け負うことにやりがいが見出されたのであれば次世代のEM候補になるかもしれないという将来性につながる

マネージャーが担っていた仕事を請け負うことになるので単純に考えるとメンバーの負担が増えてしまう働きかけでもある

現代を生きるエンジニアは生成AIを相手に大なり小なりマネジメントを行っているはず

マネージャーの仕事の一部を移譲してもらいマネジメントスキルをキャッチアップしていくことは大生成AI時代において必要なスキルを身につける絶好のチャンス

チームにマネジメント機能が分散されたマネージャーの手元にはマネジメントがスケールする仕組みや空気づくりやより中期的な戦略立案や行動への落とし込みなど抽象度や難易度が高い仕事が残る

こういったタフな仕事に対してマネージャーが集中できる環境をつくることは長い目でみると組織にとっても大きなメリット

■ 10. チームが変化するために:目標を軸にした権限移譲

状況を見える化するやメンバー主導で提案し行動してもらうといったことができるチームではマネジメント機能を分散することが可能

ポイントは目指す方向を明確にしつつ方法は任せると日頃からサインアップの文化をつくるという点

カケハシの開発組織では目標管理手法としてOKRが採用されている

AI在庫管理チームでのOKR設定方法:

大枠の目指す方向はEMが示す

どうやって目標を達成するかという具体はメンバーが決める

AWSコスト削減も生成AIの活用推進もチームのOKRとして設定していた

チームが目指す方向をシャープにすることとどうやって達成するかを考え実際に行動することをメンバーに移譲していた

AWSのコスト構造についてもチームの開発に対して生成AIをどう取り入れたらよいかの試行錯誤も最前線にいるエンジニアのほうがマネージャーより詳細に把握している

変化に対してもいち早く気づく

これらのOKRに関してメンバーに移譲しオーナーシップを発揮してもらったのはチームが成果を生む観点でも非常によい効果をもたらした

ある程度の抽象度で渡したときに自律的に成果までの道筋をつけてくれたのはサインアップすることが文化として根付いていたから

■ 11. チームが変化するために:サインアップの文化づくり

サインアップとはみずから手を上げ仕事をとりにいくこと

これが当たり前の状況をつくるための効果的なアプローチ:

毎朝実施しているダッシュボード確認定例のファシリテーションを持ち回りにする

スプリントレビューで質問を促す

何か作業が発生したときに誰々さんお願いしますではなく誰かやってみませんかと主体的に手が上がることを待つ

チームがサインアップ文化に慣れていない間は誰かやってみませんかといっても気まずい沈黙が流れることがある

主体的な行動を期待しているということを口酸っぱく伝えメンバーが自分の意思でよし自分で手を挙げてみるかとなるのを根気強く待つ

メンバーが手を挙げてくれたらそのことへの感謝を伝え本当に期待している行動であることを伝える

こういった地道な活動がだんだんとチームを主体的で自律的な存在に変化させていく

そういった変化を生み出すことやそれぞれの能力を引き出すことこそがAI時代においてEMに求められる重要なスキル

■ 12. まとめ

筆者が所属するチームで実際に行っているマネージャーに依存しないチームとしてのマネジメントの仕組みづくりについて紹介した

マネージャーがボトルネックにならずチームメンバーそれぞれが主体的に動く自己管理型のチームは自分たちで壁を乗り越えていくしなやかさをもっている

本稿がそういったチームが増えていく一助になれば幸い

(2025/12/27)

HUML :: Human-oriented Markup Language

HUML :: Human-oriented Markup Language

HUML is a simple, strict, serialization language for documents, datasets, and configuration. It prioritizes strict form for human-readability. It looks like YAML, but tries to avoid its complexity, ambiguity, and pitfalls.

HUMLは、文書、データセット、および設定に関するシンプルで厳密なシリアル化言語です。人間の読みやすさのために、厳格な形式を優先する。YAMLのように見えますが、その複雑さや曖昧さ、落とし穴を避けようとしています。

MEMO:

YAMLの亜種みたいなデータ構造化言語

(2025/12/27)

The 2025 Matrix Holiday Special

Matrix.org - The 2025 Matrix Holiday Special

要約:

■ 1. 2025年のMatrix全体の状況

2025年はMatrixにとって好調な年であり将来を確保するための賭けが成果を上げつつある

Matrixの採用が野生の環境で増加している

大規模な公共部門での展開が進んでいる:

ドイツのZenDiSのopenDesk

欧州委員会

真のデジタル主権を維持するためにMatrixを積極的に展開している国が25か国以上ある

ElementのようなMatrix専用ベンダーが持続可能になりつつあり財団とプロトコルおよびエコシステムの開発により多く貢献できるようになっている

■ 2. Matrix財団の財政状況

財団自体はまだ独立して持続可能ではない

メンバーシップは過去1年間で倍増した

プロトコルの中核を独立して保護する作業は深刻な資金不足の状態にある:

Trust & Safety

Security

Spec

Advocacy work

Matrixに依存する組織は財団の有料メンバーとして参加すべき

あと数社のゴールドメンバーが加われば財団は実際に加速できる

2025年に財団に参加した主要メンバー:

DINUMとRocket.Chatが最大のシルバーメンバー

AutomatticとBeeperがゴールドメンバーシップを更新

Gematikが大規模シルバーメンバーシップを更新

20の資金提供組織メンバーに感謝

Matrix.orgホームサーバーの運用コストをカバーするために有料アカウントの実験を開始した

■ 3. 2025年の成熟度

2025年は成熟の年であった

クライアント側ではMatrixはほぼすべてのプラットフォームで成熟した独立実装を持つようになった

サーバー側の進展:

Synapseはますます成熟している

ElementはESS CommunityをSynapseの公式AGPL配布版として立ち上げた

Element Adminを公式管理Webインターフェースとして提供

Synapse Proは大規模展開向けのスケーラビリティと有料サポートを追加し続けている

ESS Proと並行してエンドユーザーに力を与える機能はFOSSに企業に力を与える機能はProに入るという哲学に従っている

Conduitファミリーのネイティブrustホームサーバーが拡大と加速を続けている:

Conduit

Continuwuity

Grapevine

Tuwunel

■ 4. ガバニング・ボードとワーキンググループ

2025年はガバニング・ボードがMatrixのオープンガバナンスの主要な手段の一つとして本格的に開花した年

4つのワーキンググループが重要なタスクを引き受けた:

The Matrix Conferenceの運営

matrix.orgウェブサイト自体の維持

エコシステム全体でのTrust & Safety作業の調整

今後予定されているワーキンググループ:

Matrix for Public Sector Working Group

Fundraising Working Group

11月に初代マネージングディレクターのRobinが退任したが財団のオープンガバナンスを運用可能にした業績は素晴らしい遺産となっている

■ 5. The Matrix Conference 2025

ストラスブールで開催されたThe Matrix Conference 2025は大成功であった

エコシステム全体からの素晴らしい講演があった

デジタル主権を追求する国々を支援するMatrixの公共部門での採用が特に強調された

イベント自体はガバニング・ボードを通じてMatrixのガバナンスを開放することの勝利であった

Events Working Groupがイベント全体を組織し利益を上げた

コミュニティが提供した膨大な量のボランティア活動が貢献した

講演はYouTubeまたはmedia.ccc.deで視聴可能

■ 6. Matrixプロトコルの主要な成果

次世代認証への移行:

OpenID Connect経由の次世代認証への大規模な移行が成功した

Matrix 1.15で2.0より前に出荷された

Project Hydraのフェーズ1:

Room Version 12でstate resolutionを改善しstate resetを削減する最初で最も重要なフェーズが実現した

MatrixRTCの主要な改善:

よりシンプルで信頼性の高いシグナリングのためのSticky Events

改善された権限のためのSlots

仕様に正式に組み込まれる直前の状態

より広いコミュニティからのMSCが多数実現:

Tom FosterによるMSC4133を通じてMatrix 1.16で拡張可能なプロファイルが実現

Matrix 2.0向けの残りのMSCをまだ磨いている段階

Matrixがサーバーに保存するメタデータのフットプリントを改善する大きな進歩:

MSC4362を通じてElement Webのラボに暗号化された状態イベント実装が実現

すべての新しいMatrixRTC作業はサーバー側のメタデータを最小化するように構築されている

■ 7. Trust & Safetyの取り組み

Trust & Safetyが大きな焦点となっている

進展:

数日前にpolicyservの公開リリース

ROOSTとの継続的なコラボレーション

年初の改善

DraupnirとCommunity Moderation Effortとのクロスエコシステムコラボレーションに関する多くの作業

Trust & Safetyは長期的にMatrixの成功または失敗を決定する唯一のものである

2016年の認識:

実際の長期的な問題は分散型コミュニケーションではなくユーザーとコミュニティが虐待やスパムや偽情報やプロパガンダから自分自身を守る力を与えること

現実社会の虐待対策メカニズムをオンラインコミュニティにマッピングする方法を見つけること

10年後の現状:

ウェブは情報戦争のためにますます武器化されている

LLMが超人的な速度で虐待を吐き出せる世界

最近の動き:

ROOSTのような組織がこの問題に取り組むために登場

Blueskyチームも構成可能なモデレーションとユーザー選択可能なアルゴリズムフィードで真剣に取り組んでいる

必要な機能:

ユーザーとコミュニティが自分自身を守るために使用できるプライバシーを保護する分散型レピュテーションツールの完全なセット

コミュニティで誰も保証していないランダムな人間またはボットからの招待とコンテンツをデフォルトでフィルタリングする機能

■ 8. 運用上の課題

matrix.orgホームサーバーでの運用上の問題が発生した

Matrix 2.0への移行の遅さに対する多くの不満:

MSCがまだ最終化されている段階

一部のElementユーザーがElement Xの存在を知らずにClassicアプリに留まっている

■ 9. 現在のMatrixユーザー体験の改善

現在のMatrixの実体験は数年前と比べて著しく改善されている

復号化できないメッセージが大幅に削減されている:

ユーザーがリカバリーキーを失ったりすべてのデバイスを削除したりしない限り

Element Xの特徴:

技術に精通した人だけでなく誰もが使えるアプリ

iOS26で超光沢のある液体ガラスUI

Androidで新たに超高性能なアプリ

超安定したRust SDKの上に構築

オフラインサポートとメッセージエコーとキューイングのための美しいイベントキャッシュ

スレッドとスペースが完備されている

使用するのが純粋に楽しい

rust-sdkを基にした他のクライアント:

FractalとiambとElement Webが同じ基盤エンジンから直接利益を得る

他のスタック上のクライアント:

FluffyChatやTrixnityも先駆的な取り組みを続けている

過去1年間に多くの批判があったが同時に大きな前進もあった

Matrixを使用して楽しんでいる場合は当たり前と思わずブログ投稿を書きTWIMに伝え世界に伝え改善できることを伝えるべき

■ 10. 残された課題

Synapseのリソース使用量:

Elementチームはデータベース使用量を約100分の1に削減する方法のデモンストレーションを行った

Hydraやその他の堅牢性作業で忙しくまだ実現していない

Sliding Syncのパフォーマンス:

matrix-rust-sdkとSynapseで数年前の最初の実装と比較して後退している

クライアント側での保守性向上のための簡素化とサーバー上の変更が原因

同期パフォーマンスは良好だがFOSDEM 2023の最初のベータ版の約100msの即時同期には達していない

matrix-rust-sdkのSliding Syncパズルの唯一の欠けている部分:

プッシュ通知がクライアントのイベントキャッシュとアプリケーションバッジを更新することを確保する

クライアントが同期するのを待たずにプッシュされたメッセージを読めるようにする

この作業は最新のmatrix-rust-sdkイベントキャッシュの改善によってブロック解除されるはず

■ 11. 暗号化の課題

復号化できないメッセージは大幅に改善されたが多くのユーザーがリカバリーキーを失ったために履歴を復号化できないと不満を述べている

実施可能な作業:

リカバリーキーをWebAuthn Passkeyまたはハードウェアトークンに保存する実験

OIDC IDプロバイダーでクライアント側でリカバリーキーを派生させる

MSC4268を通じてユーザーをルームに招待する際に履歴を共有する機能を完成させる

MSC4153を通じてデフォルトで信頼されていないデバイスを除外する機能を実装する予定

その他の大きな課題:

クライアント制御のグループメンバーシップを最終的に導入する

OlmとMegolmの代替としてMLSを進める

Post Quantum暗号化を進める

すべてのユーザーが互いを帯域外で明示的に検証する必要がなく何らかの推移的信頼を実装する

■ 12. コアプロトコルの課題

Hydraのフェーズ2とフェーズ3を進める:

堅牢性をさらに改善する

イベントのバックデートによる問題を回避するために最終性を導入する

MSC4243に従ってユーザーIDを公開鍵に切り替える:

Matrix IDから直接識別可能な個人情報を排除することでMatrixのGDPRから最後のしわを取り除く

長年待望されているアカウントポータビリティへの道を開く

2026年に非常に実用的なP2P Matrix作業を行うことをElementは期待している

■ 13. クライアント側の課題

補助APIがボトルネックになりつつある

クロスサーバーユーザーディレクトリまたは共有アドレス帳をクエリする標準的な方法が必要

MSC4133で拡張可能なプロファイルが利用可能になった今特に重要

プライバシーを保護する連絡先検索は主流のMatrix採用にとって変革的になる可能性がある

外部アプリをMatrixに統合する方法を改善するための膨大な作業が必要:

Widgetsを介して

WebXDCや他のイニシアチブの最近の動向を検討

■ 14. 2026年への展望と課題

これらのどれが2026年に実際に実現するかは不明

多くは財団に参加したり開発資金を提供したりすることでより多くの組織が支援するかどうかに依存する

利用可能な資金が多いほど実現が早くなる

分散型アカウントは2015年から目標としているが財団が限られた予算で運営されている場合より重要な作業が飢餓状態になる

■ 15. 感謝と今後の期待

全体的に物事は何年もの間よりも前向きに感じられる

財団の個人メンバーと組織メンバーに感謝

2026年は真に飛躍できる年になることを期待

ガバニング・ボードとワーキンググループに貢献するすべての人に感謝

オープンガバナンスの成果が実を結んでいることが素晴らしい

Matrixを使用し続けサポートし続けるすべての開発者とユーザーに感謝

世界はこれまで以上に安全で分散型のコミュニケーションを必要としている

(2025/12/26)

エンジニアには2種類いて、根本原理からしっかり解ってる人と、パターンやテンプレートで仕事してる人。

エンジニアには2種類いて、根本原理からしっかり解ってる人と、パターンやテンプレートで仕事してる人。

大学進学率がまだまだ10%代で、受験産業が発達してなかった1970年代卒のエンジニアは、明らかに前者でとにかく凄かったよ。僕が社会に出た頃の先輩達は。でも現代は後者が多い気がするね。

ところが海外製の半導体を見ていると、海外は明らかに前者が多いね。ほんとプロ集団的な。

@kiyuni194

MEMO:

新人教育の時に教わったパターンで一生やっていこうとするITエンジニアは実際多い

(2025/12/25)

5年間 Laravel を使って辿り着いた，AI 時代に考える「なんちゃってクリーンアーキテクチャ」のその先

5年間 Laravel を使って辿り着いた，AI 時代に考える「なんちゃってクリーンアーキテクチャ」のその先

(2025/12/25)

「PCが買えない年末」現実に。マウス、全PC製品の販売停止と初売り中止を発表

「PCが買えない年末」現実に。マウス、全PC製品の販売停止と初売り中止を発表 - PC Watch

マウスコンピューターは、2025年12月23日15時から2026年1月4日にかけて、公式Webサイトおよびダイレクトショップで販売しているPC全製品の販売を停止すると発表した。

同社は12月16日に、想定を大きく上回る受注増加の影響で、工場のひっ迫やパーツ不足が発生し、一部製品の販売停止を発表したが、その影響が「mouse」「NEXTGEAR」「G TUNE」「DAIV」ブランドの全製品に拡大した。

販売は1月5日以降に再開するが、店頭での2026年の初売りセールは実施を見送る。なお、12月16日時点で2026年1月以降の価格改定実施も予告している。

メモリやSSDなどを中心としたPCパーツは11月以降、AIデータセンターの需要増の影響で価格が急騰。多くのコンシューマ製品において、深刻な品不足や価格増加を招いている。

MEMO:

PCメーカーが売るものが無くなるレベルのパニック買いか

(2025/12/25)

Microsoft veteran wants to replace every single line of C/C++ code with Rust and AI

Microsoft veteran wants to replace every single line of C/C++ code with Rust and AI - Neowin

要約:

■ 1. MicrosoftのAI活用状況

7月にMicrosoftは開発ワークフローにAIを大幅に組み込んでいることを明らかにした

社内のAI駆動コーディングアシスタントを活用して月間60万件以上のプルリクエストのコードレビューを行っている

これは会社で生成されるすべてのプルリクエストの90%をカバーしている

Microsoftは消費者向け開発ツールにもAI技術を深く統合している

■ 2. Galen Huntの野心的な計画

Microsoft Distinguished EngineerのGalen Huntが詳細なLinkedIn投稿で目標を宣言

2030年までにMicrosoftのすべてのC++とCコードの行をRustとAI支援の組み合わせで置き換えることが目標

Huntのミッションは1人のエンジニアが月に100万行のコードを書けるようにすること

これはLinuxの作成者Linus Torvaldsが最近別の文脈で指摘したように生産性を評価するためのかなり恣意的で無意味な指標

■ 3. コード処理インフラストラクチャ

Huntは強力なコード処理インフラストラクチャを強調

これにより会社は定義されたアルゴリズムに導かれたAIエージェントを展開して既存のコードに大規模な変更を加えることができる

このツールをさらに改善しC/C++システムをRustに変換するためにベテランのチームはシステムレベルRustの執筆経験が少なくとも3年あるPrincipal Software Engineerを採用している

■ 4. MicrosoftにおけるRustの普及

Rustプログラミング言語は過去数年間Microsoftで人気を集めている

技術大手はより良いセキュリティのためにRustで書かれたドライバー開発を奨励している

Hunt自身はMicrosoftで約30年間働いており現在Microsoft CoreAIのEngHorizons組織内のFuture of Scalable Software Engineeringグループのメンバー

彼のチームの責任は会社で技術的負債を排除する新しいツールと技術を開発し最終的には業界の他の部分にも提供すること

■ 5. LinkedInでの反応

Galen HuntのLinkedIn投稿への反応はまちまち

人々は主にRustへの移行に疑問を呈している

エンジニアはこの選択を言語に組み込まれたメモリと並行性の安全メカニズムを強調することで擁護している

(2025/12/25)

Microsoft building team to eliminate C and C++, translate code to Rust using AI...

Microsoft building team to eliminate C and C++, translate code to Rust using AI, as Windows 11 adopts Rust

要約:

■ 1. 記事公開後の訂正

この記事が注目を集めた後MicrosoftはAIを使ってWindowsを書き直すことはないと述べた

Microsoft Distinguished EngineerのGalen HuntがLinkedInで説明を追加:

WindowsはAIを使ってRustで書き直されているわけではない

チームの作業は言語間移行を可能にする技術を構築する研究プロジェクト

■ 2. Microsoftの2030年目標

Microsoftは2030年までにMicrosoftからCとC++のすべての行を排除することに専念するチームを構築している

これはWindows 11に影響を与える可能性がある

CはWindows APIを含むWindowsカーネルと低レベルコンポーネントの大部分を動かしている

C++はネイティブWindowsアプリの構築に使用されている

■ 3. MicrosoftのRustへの取り組み

MicrosoftのRustへの愛情は新しいものではない

Rustはプログラミング言語でありWebView2のようなフレームワークと混同してはならない

RustはCよりもはるかに安全でありCはカーネルを含むWindowsのネイティブコードのほとんどを動かしている

■ 4. 求人情報の詳細

Galen Huntは過去30年間Microsoftに在籍し現在Distinguished Engineer

彼のチームはIC5 Principal Software Engineerの募集をしている

Windows LatestがMicrosoftのキャリアサイトとLinkedIn投稿で興味深い詳細を発見

会社のトップレベルエンジニアの発言:

目標は2030年までにMicrosoftからCとC++のすべての行を排除すること

戦略はAIとアルゴリズムを組み合わせてMicrosoftの最大規模のコードベースを書き直すこと

■ 5. AIによるコード生成の目標

Windowsが主にCとC++で書かれていることを考えるとすべてが妄想のように聞こえるかもしれない

しかしMicrosoftはエンジニアがAIを使って毎月100万行以上のコードを書くことができればすべてが可能だと主張

North Starは1人のエンジニアが1ヶ月で100万行のコード

1人のエンジニアと毎月100万行のコードでMicrosoftからCとC++を排除できる

MicrosoftはIC5 Principal Software EngineerとしてMicrosoftの2030年までにCとC++を排除する計画に参加する開発者を積極的に採用している

■ 6. Satya Nadellaの発言との関連

この声明はMicrosoftのSatya Nadellaによる以前の発言に続くもの

Nadellaは以前会社のコードの最大30%がAIによって書かれておりこれにはWindowsも含まれる可能性が高いと述べた

■ 7. コード処理インフラストラクチャ

Microsoftは強力なコード処理インフラストラクチャを構築した

これはおそらくMicrosoftがCとC++コードとRustでAIモデルをトレーニングしたことを意味する

このインフラストラクチャはAIエージェントを使用して大規模にコード修正を行う

Microsoftはこのインフラストラクチャによって会社の最大規模のCおよびC++システムのほとんどをRustに進化させ変換できると確信している

チームはMicrosoft CoreAIのEngHorizons組織内のFuture of Scalable Software Engineeringグループの一部

■ 8. RustとAIアプローチへの懸念

RustはCやC++よりも安全でおそらくより良い選択肢

しかしAIエージェントがコードベースを変換することを信頼できるか疑問

AIは構文を変換できるはずだがコードの意図では失敗する可能性がある

これがタスクマネージャーのような基本機能を壊したりBitLocker回復画面を引き起こすWindowsアップデートがあった理由を説明している可能性

■ 9. RustによるWindowsセキュリティ強化

RustはWindowsをより安全にするMicrosoftの取り組みの一部

WebView2がフロントエンドを担当

Microsoftは約6年間CとC++よりもRustを提唱してきた

当時会社が実際にできるだけ早くCとC++を放棄する計画を立てていたことは知らなかった

2019年のブログ投稿でMicrosoftの主張:

RustをCとC++から分けるものはその強力な安全保証

unsafeキーワードの使用を通じて明示的にオプトアウトしない限りRustは完全にメモリセーフ

■ 10. Rust開発環境の整備

Microsoftは最近Windows APIをRust開発者向けに準備した

GitHubにwindows-rsというリポジトリがある:

これはWindows APIのRustプロジェクションでありRustコードがC++やC#と同じ方法でWin32COMWinRTを呼び出すことができる

Microsoftはまた別にRustドライバー開発の取り組みがある:

GitHubのwindows-drivers-rsは会社がアプリを超えてRustを探求していることを示している

このRust最適化は単発のプロジェクトや派手なオープンソース作業ではなく会社は本当にRustに真剣

■ 11. ネイティブ言語置き換えの課題

これまでのところC++WinUIXAMLなどのネイティブ言語を置き換えようとするMicrosoftの試みは消費者や企業でもうまくいっていない

実際Microsoftはより広範な問題に貢献しており最も人気のあるWindowsアプリはDiscordや会社自身のTeamsなどRAMを消費するモンスター

Windows UIは徐々にWebベースのコンポーネントに移行している

アプリだけでなくスタートメニュー内にReactがある

さらに通知センター内のカレンダーのアジェンダビュー用にWebView2を取得している

これは通知センターを開くと新しいEdge/WebView2インスタンスがトリガーされることを意味する

■ 12. 今後の展望

これらのエージェントプログラマーがWindowsや他のMicrosoft製品全体でCとC++コードをRustや他の言語にどれだけうまく変換するかは時間が経てば分かる

(2025/12/25)

Principal Software Engineer (CoreAI)

Principal Software Engineer (CoreAI) | Microsoft Careers | Galen Hunt | 29件のコメント

要約:

■ 1. 更新による訂正

投稿が意図した以上の注目を集め多くの憶測を呼んだため訂正

WindowsはAIを使ってRustで書き直されているわけではない

チームのプロジェクトは研究プロジェクト

言語から言語への移行を可能にする技術を構築している

投稿の意図はこの複数年にわたる取り組みの次の段階に参加する同じ志を持つエンジニアを見つけることであってWindows 11以降の新しい戦略を設定することやRustが終着点であることを示唆することではなかった

■ 2. 募集ポジションの概要

チームでIC5 Principal Software Engineerのポジションが空いている

ポジションはレドモンドでの対面勤務

目標は2030年までにMicrosoftからCとC++のすべての行を排除すること

戦略はAIとアルゴリズムを組み合わせてMicrosoftの最大規模のコードベースを書き直すこと

North Starは1人のエンジニアが1ヶ月で100万行のコード

■ 3. 構築したインフラストラクチャ

この以前は想像できなかった作業を達成するために強力なコード処理インフラストラクチャを構築

アルゴリズムインフラストラクチャ:

大規模なソースコード上にスケーラブルなグラフを作成

AI処理インフラストラクチャ:

アルゴリズムに導かれたAIエージェントを適用して大規模なコード修正を可能にする

このインフラストラクチャのコアはすでにコード理解などの問題で大規模に稼働している

■ 4. Principal Software Engineerの役割

このポジションの目的はMicrosoftの最大規模のCおよびC++システムをRustに変換できるようにするためにインフラストラクチャを進化させ拡張すること

この役割の重要な要件はRustで本番品質のシステムレベルコードを構築した経験:

できればRustでシステムレベルコードを書いた経験が少なくとも3年

コンパイラデータベースまたはOSの実装経験が非常に望ましい

コンパイラ実装経験は応募に必須ではないがチームでその経験を習得する意欲は必須

■ 5. チームの特徴

チームは成長マインドセットによって推進されている

幅広いスキルと視点を持つ多様なチーム

大胆なリスクを取る

他者とうまく協力し合う

社内外の顧客に価値をもたらすことを愛する

多様性と成長マインドセットが急速に変化するAIベースのツールの世界で成功するために重要であることを学んだ

■ 6. チームの所属組織とミッション

チームはMicrosoft CoreAIのEngHorizons組織内のFuture of Scalable Software Engineeringグループの一部

ミッションはMicrosoftと顧客が大規模に技術的負債を排除できるようにする機能を構築すること

社内の顧客やパートナーと新しいツールと技術を開拓し他のプロダクトグループと協力してMicrosoft全体および業界全体でそれらの機能を大規模に展開する

■ 7. 応募方法

応募または推薦するにはMicrosoft Career Hubを訪問

Job ID 200013722

(2025/12/25)

【特集】AI巡るメモリ争奪戦――2026年はPC、スマホに“冬”が到来

【特集】AI巡るメモリ争奪戦――2026年はPC、スマホに“冬”が到来 - PC Watch

要約:

■ 1. メモリ高騰の現状

DRAMだけでなくSSDやHDDまで高騰と品薄が続いている

その一方CPUは人気のある特定製品のみやや値上がり傾向にあるがDRAMのような高騰や品不足とは無縁

この一点で今回のDRAM高騰はPanic Buy必要以上の買い占め買いだめであると断言できる

■ 2. DRAM急騰の原因

もともとの話は10月3日にOpenAIがSamsungおよびSK Hynixとの間でDRAMの供給契約を結んだ事を発表したことに端を発する

この契約ではSamsungとSK Hynixが両社合計で毎月ウェハ90万枚分のDRAMをOpenAIに供給するとなっている

ただしこれは今すぐではなく将来の話

リリースにも明確にtargeting 900,000 DRAM wafer starts per monthとされており今後両社はこの契約に向けてDRAMの生産能力を引き上げていく計画

■ 3. 市場の早とちり

SK Hynixは2026年のDRAM生産量を今年の8倍にする計画があることを韓国の韓経ドットコムの11月21日の記事で報じた

これを今すぐこうなると早とちりしたベンダーがどこかにあったらしい

11月になって突如DRAMのスポット価格が高騰

10月にこのニュースが報じられて慌てたどこかのベンダーが急遽DRAMの契約の積み増しを掛けたらしい

それも1社でなく複数社がこの動きをしたと思われる

SamsungとSK HynixはOpenAIの契約分を賄うための増産で手一杯であり積み増しが行なわれた契約をこなせる余力は少ない

契約先はOpenAIと契約を結ばなかったMicronに集中するのはやむを得ない

■ 4. Micronの業績急上昇

この結果がMicronによるCrucial事業の閉鎖と記録的な2026年第1四半期決算

Micronは大きく4つの事業部門がある:

CMBUはハイパースケールのクラウド向けのDRAMとHBMを使うすべての顧客が対象

CDBUは中堅のクラウド/エンタープライズとOEMのデータセンター向けDRAMとすべてのデータセンター向けストレージが対象

MBCUはモバイルおよびクライアント向けのDRAMとストレージが対象でCrucialはこのMBCUのブランド

AEBUは自動車産業機器および民生機器に向けたDRAMとストレージが対象

■ 5. 事業部別の売上伸び率

前四半期からの売上の伸び率:

CMBUは16.3%

CDBUは50.9%

MCBUは13.2%

AEBUは19.9%

CDBUの大幅な伸びがMicronの決算が好調だった最大の要因でありこれは現在のDRAM不足が招いたうれしい誤算

CDBUのこの売上はHBM以外の契約が大幅に伸びた事を意味し単に件数だけでなく価格もかなり跳ね上がった

■ 6. 粗利益率の急増

CDBUの2025年第4四半期の粗利益率は24.8%ほどだったが今季は56.4%まで跳ね上がっている

ここまで粗利益率が急増するというのは契約の金額つまりDRAMチップ単価を猛烈に上げる契約が結ばれまくったということ

MicronではこのCDBUの契約を最優先にせざるを得ない

結果Crucial事業向けのウェハを生産する余地がないほどMicronの生産能力が逼迫してしまったのがCrucial事業終了につながった

■ 7. 2026年の見通し

この逼迫が1～2四半期で終わる程度ならあるいは一時的にCrucialブランドを休止するという選択肢もあったと思う

Micron的にはこの状況が2026年一杯は間違いなく続くとみている

12月17日に行なわれたEarnings Callにおける説明:

当面の間業界全体の供給は需要を大幅に下回ると見込まれる

こうした需給要因が相まってDRAMとNANDの両分野で業界全体の逼迫状態を招いておりこの逼迫は2026年以降も継続すると予想される

Micronは2026年のビット出荷量を20%増加させる見込みだがすべての市場セグメントにおける顧客の需要を満たせない状況は残念

■ 8. パニック買いとする理由

本当にAI需要が加速しているならCPUも不足しないとおかしいから

現在のAIデータセンターの使われ方はCPU+GPUの構成のサーバーを大量に並べる方式になる

GPUサーバーにはDDRもSSDもHDDも必要ない

GPUサーバーはチップ上のHBMを使うからDDR5は不要

本当に汎用サーバーが大量に必要になっているのであれば間違いなくサーバー向けCPUも増産を掛けなければならず当然コンシューマ向けCPUの供給にも影響が出るはず

秋葉原ではそんな動向はまったくないしこれは海外でも同じ

■ 9. 在庫積み増しの連鎖

現在のDDR5とかSSD/HDDはサーバーメーカーなどが今後需要が急増しても良いように在庫を積み増しているのが価格高騰と品不足の理由

OpenAIのウェハ大量契約に起因してメモリ調達を焦ったメーカーがメモリも足りなくなるならストレージも足りなくなるんじゃねと早合点した結果SSDが不足気味になった

SSDも足りないならHDDも足りなくなるだろうとさらに早合点を積み重ねた結果が現状

■ 10. 問題解消の見通し

DDR5に関してはおそらく1年程度は変わらないだろう

全部契約に基づくからでMicronが2026年中は解消しないとみているということは1年程度の相対的に長期な契約が多いということ

買い漁っていたメーカーが実際にはやっぱ要らなかったと判断しても契約期間が終わるまでは毎月契約した分量がメモリメーカーから届くことになる

その間は市場に出回る分量は当然減らざるを得ず品不足と高騰は収まらない

■ 11. 2027年以降の展開

現在の契約が終わるであろう来年末～2027年第1四半期末あたりから市場に流れる分が急激に増えると思われる

サーバーなど向けに現在メーカー各社が貯め込んでいるDDR5とかSSD類はおそらく2026年中には消費しきれず2027年は相当契約を減らすと考えられる

メモリメーカーは生産能力を2026年中に増強しておりDDR5の生産量も必然的に増える

その頃にはSSD/HDDの在庫もメーカーに十分積みあがることでやはり市場への流通が急に増える

品余りになれば価格下落につながる

■ 12. 2026年の購入戦略

2026年はちょっとPCを買うには不適切な時期

必要という方はちょっと高値に付くであろうことは覚悟するしかない

待てるなら2027年まで待つのが得策

問題はこれがPCだけでなくスマートフォンやゲーム機などにも波及しそうなこと

その意味でも2026年はいろいろ厳しい年になりそう

(2025/12/24)

なぜ日本のIT業界の元請けは零細企業と直接契約しないのですか？に対する伊本貴士さんの回答

なぜ日本のIT業界の元請けは零細企業と直接契約しないのですか？に対する伊本貴士さんの回答 - Quora

この話来ましたね。

確かに日系の大手IT企業には契約を結ぶ基準というのがあり、その基準を満たす企業でないと発注はしません。(通称、口座を持つという)

私自身、大手企業にいてこの制度というか仕組みは不思議に思っていたので勝手に追求した事がありました。

色々理由を聞いたのですが、第一に責任能力らしく、つまり何かあった時に人的もしくは金銭的な責任をどこまで取れるかという問題だそうです。

例えば、1億の案件があるとする。そのうちの開発をAという会社に任せるとする。しかしAという会社のエンジニアがバグだらけのコードを書いたり、バックれたりして納期が間に合わない時、顧客と裁判になります。(日常茶飯事)

当然、裁判の結果によっては、賠償金を支払う事になります。この時A社にも当然責任はあるのでって話だそうです。(しかしA社に金を払わせたという話はあまり聞いた事がない)

あとはA社が大きいほど、担当がばっくれても他の人を当てがってなんとかしてくれるだろうという安心感もあるそうです。

仮に特殊な技術が必要で零細のB社に仕事を発注したい時でも、A社を間に入れて取引します。(当然A社は書類を書いて流すだけですが何割かマージンを取ります。保険のようなものですね。)

そんなバカなと思うかもしれませんが、先ほど述べたルールがあるのでそれを徹底します。

流石にもう古いルールなんでもうやめればと個人的には思うのですが、大企業はルールを作ることはできても、ルールを廃止するのは苦手なのでいまだにやっているのでしょう。

ちなみにこれも個人的な考えですが、下請けの責任能力を問うくらいなら、丸投げしないで、自分たちで責任持って開発もきちんとマネジメントしてやるっていう発想はないの？と糾弾した事もありますが、全く通じませんでした。

(2025/12/24)

ソフトウェアエンジニアの本質は“課題解決”なのか？

ソフトウェアエンジニアの本質は“課題解決”なのか？ - mtx2s’s blog

要約:

■ 1. 問題提起と背景

エンジニアの本質は課題解決であるという台詞に対し筆者はずっと軽い違和感を持っていた

この違和感が明確に表出したのは最近である

ソフトウェアエンジニアリングの現場にAIエージェントが入り込んだ今こそこの違和感を言語化すべきと考えた

AIがコーディングを代替しつつありその精度は高まり担える領域も確実に広がっている

エンジニアという職種の本質をあらためて問い直す必要がある

■ 2. エンジニアの本質は課題解決であるという言葉の問題点

この言葉には限定性と多義性という性質がある

範囲を絞り込み同時に意味を広げてしまうという二つの性質が同時に含まれている

言葉の構造:

エンジニアのという限定性

課題解決という言葉の多義性

課題解決であるという限定性

■ 3. エンジニアのと限定する不自然さ

課題解決という営みはエンジニア職に固有のものではない

ビジネスに関わる多くの職種にとってその本質は課題解決にある

企業のミッションは抽象度をあげれば課題解決に行き着く

特定の職種を指してその本質が課題解決にあると語ることに不自然さがある

この限定性の背景:

手段が目的化しやすいというエンジニアという専門職特有の事情

専門技術を追求する面白さに没頭するがあまり何のために技術を行使しているのかを忘れやすい

デザイナーがデザイン性にばかり気を取られ機能性を見失う構造と類似

コードを書くことそのものをエンジニアの仕事だと捉えすぎることへの批判が含まれている

■ 4. 課題解決という言葉への解像度の低さ

課題解決という言葉は響きがビジネス的で格好良いが便利に使われすぎる側面がある

何を指しているのか分かったようで分からない

課題解決と呼ばれる営みに含まれるプロセス:

現状把握

あるべき姿の設定

問題の特定

原因分析

課題の設定

解決策の実行

一連のプロセス全体がエンジニアの本質なのか最後の解決策の実行だけを指しているのかが曖昧

本来は三人の石切り工の話に近く解決策の実行だけを担っていても全体を通して課題を解決しているという認識を持つべきという意味

課題解決という言葉は文脈によっては受託開発の構造を想起させやすい:

ウォーターフォール型の工程分離が前提

上流工程と下流工程として異なる役割が割り当てられる

エンジニアが主に担う解決策の実行の役割を指す責務の話として受け取られる場合がある

あるべき姿と現状のギャップを対象とする課題解決だけがエンジニアリングの営みではない

新しい価値を生み出すことや既にある価値を維持し将来へ継承していくことは必ずしも明確な問題から始まるわけではない

これらの営みも抽象度を上げれば課題解決という枠組みの中に含めて捉えることができる

■ 5. 課題解決であるとの断定による問題

であるという限定的な言い回しは課題解決が持つ多義性を包み込む余地をかえって狭めている

課題解決が狭義の意味に閉じてしまうような印象を与えかねない

聞き手の意識が価値創造や維持・継承へと向かう余地をあらかじめ狭めている

話し手自身も狭義の課題解決という枠組みの中でしか物事を捉えられていない可能性

ソフトウェアエンジニアという職能の可能性を静かに狭めてしまう行為になり得る

■ 6. エンジニアリングの提供価値

エンジニアの本質とはエンジニアリングの生み出す価値そのものである

三つの観点:

複雑性を秩序に変換する

再現性と効率性を創出する

持続可能性を維持する

複雑性を秩序に変換する:

ソフトウェア開発はそもそも不確実なものを扱う営み

エンジニアリングの本質は不確実性の削減

不確実性コーンが示すように不確実な状態から確実な状態へと変えていく活動

絶え間ない探索と論理を手がかりとして複雑性に秩序をもたらす営み

再現性と効率性を創出する:

ソフトウェアは同じことを同じように何度でもできる

再配布可能な知識やスキルのパッケージ

ソフトウェアで処理される知識やスキルや手続きは人間が処理するよりも速く安定している

人間の能力が拡張される

持続可能性を維持する:

ソフトウェアは完成した瞬間から変わり続けることを宿命付けられた成果物

変更が容易でなければソフトとは言えずその価値が失われていく

ソフトウェアの稼働期間が長いほどその振る舞いに変更が入る

それに耐えうる構造を維持し進化させ続けることが単なるプログラミングとエンジニアリングを分ける

持続可能性の維持は設計や実装の巧拙だけで決まるものではない

変更を前提にした意思決定や構造への投資の積み重ねによって形作られる

■ 7. エンジニアの本質の定義

GeminiやChatGPTと定義の言語化を繰り返した結果導き出されたエンジニアの本質:

論理の力で混沌とした現実に再現性のある秩序を与えることで価値を持続的に創出し人間の可能性を拡張し続けること

短縮すると再現性ある価値の継続的な創出

企業で働くエンジニアの価値は自社のミッションのもと目の前のユーザーや顧客やビジネスあるいは社会に向き合いこの役割定義を実行することで具現化される

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

AIがコーディングを代替するようになってもエンジニアのアイデンティティが崩壊するわけではない

エンジニアの本質は変わっていない

AIが担う領域がさらに広がっても同じ

コーディングエージェントとの協働は新しい知的な楽しさももたらしている

ケント・ベックが50年に及ぶプログラミング経験の中で今が一番楽しいと述べている

手段が目的化しやすいのは専門職種の宿命であり対象に深く没頭している証であり知的好奇心の表れ

その追求は個人の満足にとどまらず組織に新たな可能性や能力の飛躍をもたらすこともある

夢中になることはエンジニアリングの原動力

AIとの協働で形は変わっても技術への探究心は持ち続けるべき

その探究の先で混沌とした現実に秩序を与え再現性ある価値として社会に残していく

AI時代においても変わらないエンジニアの本質がある

■ 9. 記事執筆の経緯

パネルディスカッションでエンジニアの本質は課題解決であるという言葉への違和感を表明したことがきっかけ

それをあらためて整理し言葉にしてみようとしたのが本記事の試み

AI時代においても本質が変わらないという点ではソフトウェア開発組織の設計原理についても同様

AIによって開発が加速するほど組織構造に由来する摩擦は無視できなくなる

(2025/12/24)

「手作業でやってきた部分ほど自動化しづらい」 MIXI社「インフラAI活用」の“泥臭い” 実践

「手作業でやってきた部分ほど自動化しづらい」 MIXI社「インフラAI活用」の“泥臭い” 実践 | レバテックラボ（レバテックLAB）

(2025/12/24)

ミノ駆動さんゲスト登壇！アーキテクチャ設計の現在地 DMM.com×楽天グループ×NISSAN×Hondaが語る...

ミノ駆動さんゲスト登壇！アーキテクチャ設計の現在地 DMM.com×楽天グループ×NISSAN×Hondaが語る設計判断の裏側【TECH DRIVERS Day4】 - YouTube

(2025/12/23)

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

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

要約:

■ 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

要約:

■ 1. 2026年におけるAIエージェント移行の背景

生成AIの導入段階の移行:

生成AIが実験段階から企業への導入に移行する

2026年は日本のソフトウェア開発にとって重要な節目の年となる

GitLabの調査結果:

日本の経営層を対象に実施した調査ソフトウェアイノベーションによる経済効果による

経営層の85%が3年以内にAIエージェントがソフトウェア開発での業界標準になると予想している

AIエージェントへの移行は今後も加速していく

AIエージェント移行の両面性:

かつてないほどの生産性向上が期待される

組織はガバナンスやセキュリティやAIエージェント間の相互運用性や可視性といった新たな課題との両立の難しさを抱える

組織への影響:

課題に対処できる組織は競争優位を確立できる可能性がある

AIエージェントを単なるツールとみなし課題に対処できない組織は競争から取り残されるリスクを抱える

■ 2. AIエージェントの可視性確保の必要性

可視化の必要性の認識:

チームが開発ツールやクラウドプラットフォームなどさまざまなソースから一元的な監視体制なしにAIシステムを立ち上げるようになる

組織はネットワーク全体で稼働するAIエージェントの可視化が不可欠であることに気づく

分散型AIシステムを検出しカタログ化できるエージェントプラットフォームが企業市場で優位に立つ存在として浮上する

ビジネスニーズの変化:

AIエージェントがシステムの利用量とコンピューティングコストを押し上げる

組織はAI投資のROIを明確に把握し正当化することを求めるようになる

企業はAIエージェントのデプロイを管理の範囲外の実験として扱うことをやめる

他のエンタープライズテクノロジーと同様の財務的説明責任を求めるようになる

成功要因:

どのAIエージェントが稼働しどのリソースを消費しどの程度のビジネス価値を生み出しているかを可視化できるエージェント検出プラットフォームを導入する組織が成功を収める

■ 3. 人間中心のIDシステムの限界

従来システムの限界:

Agent-to-Agentのやり取りが増えるにつれて従来のアクセス制御システムの限界が浮き彫りになる

組織はアクセス管理と権限管理の危機に直面する

AIエージェントの特性:

人間のユーザーや単純な自動化とは異なりAIエージェントは互いに通信しタスクを委任しながら複数のシステムにまたがって意思決定を行う

あるAIエージェントが別のAIエージェントに指示を与える状況では既存の権限フレームワークは機能しなくなる

従来の仕組みは他の自律システムの代理として行動するAIではなく人間個人を前提として設計されている

短期的対処策の限界:

一部の企業はAIエージェントにペルソナを割り当てるといった短期的な対処策を講じている

こうしたアプローチは根本的なガバナンス課題の解決ではなくAIエージェントをあたかも従業員のように扱うものにとどまっている

人間中心の権限モデルを使い続ける組織はAIシステムがより相互接続され自律性を高めていく中で意思決定の連鎖を追跡したりAIエージェントの行動を監査したりセキュリティを維持したりすることが次第に難しくなる

必要な対応:

組織はアイデンティティおよびアクセス管理を第一原理から見直す必要があることを認識し受け入れなければならない

人間中心のモデルを後付けするのではなく機能横断型チームを編成し自律システム向けのガバナンスフレームワークを設計する必要がある

AIエージェントのエコシステムがより深く相互接続されるにつれて基盤となるフレームワークの再設計も飛躍的に難しくなるため先手を打てる時間は限られている

■ 4. AIエージェントの相互運用性とセキュリティ

セキュリティの根本的変革:

モデルコンテキストプロトコルとAgent-to-Agent標準の採用により今後1年間でソフトウェアサプライチェーンのセキュリティは根本から変革される

AIエージェントがプラットフォームやベンダーをまたいで通信できるようになると従来のセキュリティモデルでは十分に対応しきれない予測不能な挙動が生じる

AIエージェントの動作特性:

AIエージェントはデータソースとのやり取りの中で非決定的かつ多方向に動作する

その過程でサプライチェーンの依存関係をリアルタイムに追加や削除や再構成する

新たなアプローチの必要性:

セキュリティチームは新たなアプローチによって予測不能な動きへの対応を考慮しなければならない

非人間のアイデンティティにはAIエージェントがベンダーやサードパーティとやり取りするケースを含め組織がソフトウェアサプライチェーン全体でアクティビティを追跡や特定や管理する方法を根本から見直すことが求められる

フレームワークの進化:

現在のAIモニタリングフレームワークは複合IDを通じて人間とエージェントを認証や認可の目的で結び付けると同時にAIエージェントの行動をトレースする役割を果たしている

来年にはこうした取り組みがエージェントの追跡とプロファイリングを行い運用上の境界を管理する包括的なエージェント型リソース情報システムへと進化すると見込まれる

■ 5. AIガバナンスの格差拡大

競争優位の確立:

すでにAIガバナンスフレームワークを確立している組織は2026年を通じて大きな競争優位を手にする

GitLab調査による現状:

経営層の91%がAIへの投資を拡大する計画を立てている

実際にガバナンスフレームワークを導入しているのはわずか55%にとどまる

導入と監視の間には大きなギャップが生じている

早期導入の優位性:

現時点でAIガバナンスに対する完璧なアプローチを持っている企業はない

早期にAIガバナンスを導入した組織は実装のトライアンドエラーを重ねることでスキルと知見を蓄積することができる

AIリスクに対応しながらセキュリティとガバナンスを進化させることでチームは実際に機能するポリシーを見極めビジネスへの影響を最小限に抑えることができる

新しいフレームワークを早期に導入することでチームは環境内や開発プロセスの段階でAIリスクを自動的に考慮できるようになることも期待される

後回しによるリスク:

ガバナンスの後回しやAIの導入自体を避けようとすることは競争上の不利を招く結果となる

そうした企業は状況が必然的に変化していく中で後から対応しようとしてもさらなる遅れを取ることになる

■ 6. すべての脆弱性における悪用リスクの増加

高度な攻撃手法の台頭:

2026年に組織が直面する最大かつ最も差し迫ったセキュリティ上の課題

敵対的なAIエージェントの急増によりスキルの低い攻撃者でも高度で複雑な攻撃を実行できるようになる

攻撃手法の変化:

ハッカーはAIエージェントを利用して最新のインフラを巧みに探索しセキュリティ上の弱点を突く

かつては高度な専門知識が必要だった多段階攻撃を実行できるようになった

必須のセキュリティ対策:

基本的なセキュリティ対策を徹底することがもはや選択ではなくビジネス上の必須要件になる

包括的なソフトウェア部品表の整備や効率的なパッチ管理や積極的な脆弱性修正はソフトウェア環境全体のリスクを最小限に抑えるために欠かせない

■ 7. 日本におけるソフトウェアイノベーションの新時代

課題の相互関連性:

5つの予測は2026年を通じて日本および世界の組織がソフトウェア開発に取り組む姿勢そのものを根本から再構築していく

企業が直面する課題は互いに密接に結びついている

可視性はガバナンスを支えガバナンスには適切なIDフレームワークが不可欠

IDフレームワークはサプライチェーンの動的な性質を踏まえる必要がありセキュリティ対策状況はこれらすべての要素が連動して機能することで初めて成立する

経済機会:

課題に体系的に取り組む組織はAI主導のソフトウェアイノベーションが日本経済にもたらすおよそ1兆6000億円規模の機会を現実のものにできる可能性がある

AIを単なる生産性向上のためのツールとしてではなく新たなフレームワークやガバナンスモデルやセキュリティアプローチを求める変革の原動力として位置づける必要がある

組織の成否:

AIエージェントに内在するガバナンスやセキュリティや運用上の課題に対応できない組織はソフトウェア開発の未来に適応できなくなる

今後成功するのはAI導入を二者択一の問題としてではなく適応と最適化を繰り返しながら進化させていく継続的なプロセスとして理解している組織

来たる年はこうしたニュアンスを理解して行動できる企業とそうでない企業とで明確な差が生まれる一年になる

(2025/12/22)

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

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

要約:

■ 1. はじめに

削除フラグの議論:

削除フラグを使うかどうかが最近ネットで話題になっている

とりあえず削除フラグというのはアンチパターンでビジネスドメインでの意味を表現する形にするのが良い

記事の目的:

イベントソーシングでの削除の考え方を紹介する

すぐにイベントソーシングを導入すべきという話ではない

イベントソーシングの考え方を知ることで削除の設計について新しい視点が得られることを目指す

■ 2. 前提としてのCQRS

CQRSとの組み合わせ:

イベントソーシングを行うときはCQRSと組み合わせて使うことが前提となる

CQRSは書き込みのためのモデルと読み込みのためのモデルを別々に設計する考え方

削除の扱いへの影響:

この分離により削除の扱いを書き込み側と読み込み側で別々に設計できる

これがイベントソーシングで削除を扱う上での重要なポイント

■ 3. コマンドモデルでの削除の扱い

コマンドモデルの役割:

ビジネスの一貫性を守るために設計する

書き込み側のモデルは一貫性確認のための参照にも用いられる

無料会員と有料会員を管理する機能では支払い処理を開始した時点ではまだ無料会員で有料機能を使えない

銀行振込を確認した時点で有料会員になる

削除の意味の多様性:

ユーザーがいなくなる状況にはさまざまな意味がある

支払いが滞った場合はアカウント無効化

ユーザー自身が退会した場合は退会

一時的に休止している場合は休止

間違えて作られた場合は誤登録削除

規約違反でBANされた場合はアカウント停止

これらを全て削除フラグでtrueで表現するのはビジネスの意味を失わせる

イベントによる意味の記録:

それぞれの意味を持つイベントとして記録する

関数型ドメインモデリングの考え方ではイベントによって集約の型が変わることでその状態でできるアクションを制限する

型が退会済みになれば有料機能を使うコマンドは型レベルで実行できなくなる

削除フラグをチェックする必要がない

コマンドモデルの設計方針:

削除フラグではなくそれぞれの意味を持つイベントを記録し型によって振る舞いを制御する

削除フラグ以上の情報を持つ

休止や退会により表現する型を変えることでそれぞれのユーザーに対して行うことができるアクションを設計する

■ 4. リードモデルでの削除の扱い

リードモデルの役割:

複数集約の情報をリスト化や集計するために使われる

コマンドモデルでは一貫性を担保するために集約の単位を適切に設計する必要がある

在庫管理で倉庫全体を1集約にするか棚を1集約にするか棚の中の1品目を1集約にするかでトレードオフがある

通常は棚の中の1品目を1集約にする設計が良い

その場合棚全体や倉庫全体での状況を知るためには複数集約の情報をリスト化や集計する必要がある

複数ビューの構成:

書き込み側で記録されたイベントをもとに目的ごとに異なるリードモデルを構成できる

同じ退会というイベントでもリードモデルごとに異なる処理ができる

目的に応じた削除の扱い:

リードモデルでは要件に応じて削除フラグを使うこともできるし物理削除することもできる

データによって削除時にデータを残すか消すかをコントロールできる

要件として削除フラグをリードモデルに置いておけば良いという仕様であれば置くことも可能

リードモデルの設計特性:

コマンドモデルと違い型を変えて振る舞いを変えるという設計は通常しない

データを表示や検索するための情報であり一貫性を型で保証する必要がないから

■ 5. イベントソーシングでの削除の答え

基本方針:

基本的に削除フラグという汎用的なものは準備しない

要件に合わせてコマンドモデルとリードモデルをそれぞれ設計する

コマンドモデルでの削除:

削除がそのビジネスにおいて適切であれば削除としてイベントを記録する

多くの場合削除という単一の概念ではなくそれぞれの意味を持つイベントとして設計する

それぞれの意味を考えてコマンドおよびイベントを設計する

コマンドモデルが削除フラグ以上の情報を持つ

多くの場合は休止や退会により表現する型を変えることでそれぞれのユーザーに対して行うことができるアクションを設計する

リードモデルでの削除:

読み込み側の要望や仕様によって変わる

休止や退会を検索条件としたい場合は会員ステータスカラムを作り検索や集計できるようにする

有料会員だけを効率的に検索したい場合は休止や退会時にデータを物理削除する

退会者の分析をしたい場合は退会者専用のテーブルにデータを移動する

とりあえず削除を表現したい場合は削除フラグを使っても良い

同じイベントから目的に応じて異なる処理ができるのがリードモデルの強み

■ 6. パフォーマンスの観点

コマンドモデル側のパフォーマンス:

コマンド側は一貫性とコアな機能に集中しているので各ユーザーが何かの機能を行う時に逐次で呼ばれる

イベントソーシングでは1集約に対して1つのコマンドしか同時実行できないように設計されている

アクターモデルなどと一緒に使うことで大きなアクセスでも複数のサーバーに負荷を分散できる

コマンドモデルは単一集約の処理に集中するため削除されたかどうかのチェックが他のテーブルに波及することはない

リードモデル側のパフォーマンス:

読み込みのパフォーマンスだけを考えて設計できる

リードモデル生成時に1つのテーブルにアクセスが集中しないように設計できる

名称などのマスタ情報を結合したデータを作成できる

有料会員専用のテーブルを作れば削除フラグのチェックなしで効率的に検索できる

従来のアプローチとの比較:

削除フラグを使う従来のアプローチでは多くのクエリにWHERE deleted_flag = falseを追加する必要がありインデックス設計も複雑になる

リードモデルで有料会員だけのテーブルを作ればこの問題は発生しない

■ 7. イベントソーシングを使わなくても活きる考え方

活用可能な考え方:

イベントソーシングを導入しなくても活きる考え方がある

削除を状態遷移として捉え退会や休止や無効化をそれぞれ意味のある状態として設計する

書き込みと読み込みで削除の扱いを分けて考えマスタテーブルと検索用ビューで異なる扱いをする

ビジネスの意味を大切にしたモデリングで削除フラグという技術的な都合ではなくドメインの言葉で表現する

イベントソーシングの位置づけ:

これらの考え方を自然に実現できるアーキテクチャの一つ

■ 8. まとめ

イベントソーシングでの削除の扱い:

削除をドメインの言葉で表現する

コマンドモデルではビジネスの意味を持つイベントとして記録し型で振る舞いを制御し一貫性の担保に焦点を当てる

リードモデルでは目的に応じて削除フラグや物理削除や別テーブル移動などを選択し検索や表示の効率に焦点を当てる

イベントソーシングとCQRSの役割:

DDDを具現化してドメインのビジネス目標や要求や仕様をコードに落とし込むことを支援する

まずデータモデルの時点で複雑なビジネスを表現し永続化やWebアプリの表示のための加工は副次的なものとして扱う

参考になる考え方:

この考え方はイベントソーシングを導入しなくても参考になる

削除フラグをつけるべきかという議論に対して一つの視点を提供する

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