/note/tech

集約にこだわりすぎない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への取り付けが可能

(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. 結論

冗長性の欠点:

努力の重複

相互運用性の問題

依存関係はより深刻:

依存すべきは本格的なモジュールのみ

無定形なコードの塊には依存すべきでない

モジュール化の成功可能性の評価基準:

実際のオーナーの存在

安定したインターフェース

全ユーザーを満足させる見込み

著者の主張:

成功の見込みが低ければ冗長性を選択すべき

見積もりは保守的に行うべき

冗長性は悪だが依存関係は麻痺を引き起こす

依存関係を先に排除すべき

(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レイヤーって要るの？

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コードレビューの旅～そしてボトルネックは要件定義へ…

(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 / きたはら

(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

(2025/12/22)

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

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

(2025/12/22)

Transparent Leadership Beats Servant Leadership

Transparent Leadership Beats Servant Leadership

要約:

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

筆者は数年間チームマネジメントを経験しどうすれば良いマネージャーになれるか模索した

サーバントリーダーシップについて多くを読んだがしっくりこなかった

サーバントリーダーシップはカーリングペアレンティングに似ている

リーダーや親が問題を予測し直属の部下や子供のために道を掃き清める

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

直属の部下や子供にとっては最初は非常に良い感じがする

サーバントリーダーやカーリングペアレントはすぐに過重労働の単一障害点になる

リーダーが去ると誰もリーダーが取り除いた障害への対処方法を知らない

最悪のケースでは組織の他の部分から完全に隔離された人々のグループを残す

彼らは自分たちの目的が何であるか世界の他の部分とどう適合するかの概念を持たない

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

筆者は独自の造語としてトランスペアレントリーダーシップを提案

良いリーダーの行動:

人々をコーチする

人々を繋げる

人々に体系的な問題解決を教える

組織が受け入れている価値観と原則を説明し自分で整合性のある意思決定ができるよう支援する

需要と供給の間に直接的なリンクを作る

直属の部下にリーダーシップの責任を徐々に引き継がせることでキャリア成長を可能にする

継続的に自分の後継者を訓練する

一般的に自分自身を不要にする

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

有用な仕事を何も行わない中間管理職は面白いステレオタイプだが良い目標でもある

違いは自分を不要にした後に何をするかにある

よくある反応は新しい仕事を発明しステータスレポートを要求し官僚主義を追加すること

より良い反応は技術的な問題に取り組む作業に戻ること

これによりマネージャーのスキルが新鮮に保たれ部下からより多くの尊敬を得られる

マネージャーは書類整理係ではなく高性能な予備作業員になるべき

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

この記事はサーバントリーダーシップを誤って表現していると批判を受けた

批判者は真のサーバントリーダーはサーバントに期待されることをせず代わりにトランスペアレントリーダーのように行動すると主張

サーバントリーダーシップという言葉の起源であるグリーンリーフはリーダーに仕える人々が以下のようになるべきだと強調:

より健康的により賢明により自由により自律的により自分自身がサーバントになる可能性が高くなる

筆者は真のサーバントリーダーシップには反対していない

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

筆者が反対しているのは実践で起こっているように見えるサーバントリーダーシップ

マネージャーが退屈で難しい部分を行うことで部下が自分の仕事に集中できるようにする

これはテイラー主義的な方法で狭く定義されている

真のサーバントリーダーシップは実質的にトランスペアレントリーダーシップと同じ

真のサーバントリーダーシップを勉強しない人々はサーバントリーダーがサーバントのように行動すべきだという誤った考えを持つ

(2025/12/21)

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

Update from Microsoft.

Teams is down.

Messages are delayed.

Some aren't arriving at all.

We're investigating.

Investigating means the AI is investigating.

The AI that wrote the code.

That broke the code.

That is now debugging the code.

It's a closed loop.

Very efficient.

A user asked why their message didn't send.

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

They asked what that means.

I don't know what that means.

But the dashboard is green now.

Green means fixed.

Fixed means we changed the threshold for green.

The messages are still delayed.

But the dashboard doesn't know that.

Dashboards don't use Teams.

Someone on the infrastructure team tried to escalate.

Via Teams.

The escalation is still pending.

Somewhere in the queue.

With everyone else's messages.

The irony wasn't lost on them.

But the message was.

We have a backup communication channel.

It's email.

Email is also having issues.

Unrelated, obviously.

The root cause is under analysis.

Analysis means we asked the AI.

The AI said "no issues detected."

The AI wrote the detection system.

It detects what it wants to detect.

Very self-aware.

Not in the good way.

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

Teams is closer to 45%.

We were proud of that.

Past tense.

The AI optimized the message queue.

It optimized it to zero.

Zero messages. Zero latency.

Technically correct.

The best kind of correct.

Enterprise customers are asking for an RCA.

RCA means Root Cause Analysis.

The root cause is velocity.

We shipped faster than we understood.

Understanding isn't in the OKRs.

Shipping is.

We shipped.

Someone asked when Teams will be fixed.

I said "we're continuing our analysis."

Continuing means we started.

Analysis means looking.

Looking means hoping it fixes itself.

It usually does.

If you refresh enough.

Refresh is the user's responsibility.

We provide the experience.

They provide the resilience.

That's partnership.

The outage started at 2:30 PM ET.

Right before the holidays.

Millions of workers couldn't message their teams.

Some called it a disaster.

I called it "an unplanned wellness moment."

Productivity is a spectrum.

We're exploring the lower end.

The AI has proposed a fix.

The fix requires a deployment.

The deployment system uses Teams for notifications.

The notifications are delayed.

We're in a loop.

The loop is also AI-designed.

Very elegant.

From a certain angle.

Satya asked for a status update.

I sent it via Teams.

He hasn't responded.

I assume he's thinking about it.

The stock is up 2% today.

Outages don't move markets.

Narratives do.

The narrative is "AI efficiency."

The reality is "Teams is down."

But reality isn't in the earnings call.

The narrative is.

We're committed to reliability.

Reliability means it worked yesterday.

Yesterday is our SLA.

Thank you for your patience.

Patience means you have no choice.

We're in your enterprise agreement.

For three more years.

The circle of innovation continues.

@gothburz

翻訳:

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

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

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

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

調査中です。

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

コードを書いたAI。

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

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

それは閉ループです。

非常に効率的です。

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

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

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

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

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

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

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

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

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

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

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

チーム経由。

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

行列のどこかに。

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

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

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

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

電子メールです。

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

明らかに無関係です。

根本原因は分析中です。

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

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

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

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

とても自意識が強い。

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

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

Teams は 45% に近いです。

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

過去形。

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

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

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

技術的には正しい。

最高の正解。

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

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

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

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

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

送料はです。

発送しました。

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

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

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

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

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

通常はそうなります。

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

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

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

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

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

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

お盆休みの直前。

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

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

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

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

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

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

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

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

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

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

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

とてもエレガントです。

ある角度から。

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

Teams経由で送信しました。

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

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

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

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

物語はそうなります。

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

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

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

物語は。

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

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

昨日は SLA でした。

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

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

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

あと3年も。

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

MEMO:

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

(2025/12/20)

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

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

@sakamoto_582

MEMO:

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

(2025/12/20)

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

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

MEMO:

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

(2025/12/20)

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

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

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

@satetu4401

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

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

@satetu4401

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

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

@satetu4401

MEMO:

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

(2025/12/19)

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

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

要約:

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

Jr/Middle/Seniorの議論は自分の立ち位置を確認したいフェーズの自然な問い

意思決定や失敗を経て視座が変わると「自分はどこに立っているか」から「この判断を引き受けるのは誰か」へ関心が移行

PMのキャリアには関心の向きが切り替わる明確な分岐点が存在

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

PMを続けると事業視点/PL意識/長期価値/投資対効果などの語彙を使い始める

プロダクトの外側を見る視点が身についた証拠であり成長の表れ

このフェーズは最も楽しい段階である

まだ痛みを伴わない段階

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

経営者が本当に引き受けているもの:

誰にも相談せずに決める瞬間

後から間違いに気づいても戻れない現実

その判断で人や生活を変えてしまう感覚

この話題になると抽象論に逃げるPMが多い

能力や意識の問題ではなく引き受けた経験がないだけ

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

レベル論争が好まれる理由は責任を曖昧にしたまま賢く振る舞えるから

言い訳の構造:

そこまでは求められていない

権限がない

役割的に違う

フェイクなPMはこの場所に長く留まる

リアルなPMはある日ここから降りる

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

共通点:

レベル論争がどうでもよくなる

業務範囲の話を一段上から見るようになる

正解がない判断を無言で引き取る

「まあやるしかないよね」という言葉が出る

この言葉は投げやりな諦めではなく覚悟が決まった人の決意表明

この段階に達したPMはもうPMごっこには戻れない

■ 6. PMの最終進化系

肩書きは重要ではない

経営をやってしまっている人であり逃げないことを選んだ人

逃げない姿勢の内容:

数字から逃げない

人の感情からも逃げない

判断の結果を全部自分の名前で引き受ける

自分の仕事かどうかではなく自分がやらないと誰がやるのかで決める

■ 7. 分岐の認識

選別や優劣をつけることが目的ではない

分岐があるという事実をちゃんと認識することが重要

レベル論争や業務範囲の線引きが大事に思えるフェーズも間違いではない

そのフェーズがあるから次に進める

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

あるタイミングで議論が空虚に感じ始める契機:

正解が用意されていない判断が増える

誰かに委ねると歪む感覚が出てくる

これは誰かに預ける話じゃないと思う瞬間が来る

このときPMは次のステージに入る

■ 9. 経営との関係性

全員がCEOや事業責任者になる必要はない

PMを続ける限り経営的な判断から完全に逃げ切ることはできない

肩書きに関係なく必ず現れる判断:

どこに賭けるか

何を捨てるか

どの未来を選ばないか

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

諦めでも開き直りでもない前向きな言葉

前提条件:

完璧な情報は揃っていない

正解があるわけでもない

でも決めないと前に進めない

現実を受け入れた人が前を向いたときに出てくる言葉

不確実の中での前進の合図

■ 11. PMの仕事の本質

役割定義で縛るには大きすぎる仕事

二面性:

やると決めたらやってしまえる自由がある

引き受けた瞬間に重さがのしかかる

レベル論争や業務範囲論争に違和感を覚え始めるのは視座が一段上がったサイン

■ 12. 変化の兆候

自分はいまどこに立っているんだろうから判断は誰が引き受けるべきなんだろうへ考える時間が移行

その変化に気づいた時点でもう以前と同じフェーズにはいない

確認すべきポイント:

どの現実が気づけば自分の手元に集まってきているか

どの判断がいつの間にか自分の名前で残るようになったか

PMという仕事は気づかないうちに経営という営みに近づいている

気づいてしまった人はもう少しだけ前に進めばいい

(2025/12/19)

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

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

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

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

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

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

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

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

長期的な信用を失う。

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

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

雄弁は銀、沈黙は金。

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

@bico9999

(2025/12/18)

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

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

要約:

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

AI時代はプロジェクトマネジメントやチームマネジメントの重要性が上がるという話について考えたことを書く

AI時代プロジェクトマネジメントとかチームマネジメントのスキルがめちゃくちゃ重要性上がるよねーという話をしまくっているがあまり理解されていない気がする

確信があるが重要性をうまく説明できていない

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

生成AIは個人をエンハンス(高める・強化)する力が強い

個人がエンハンスされた作業範囲に注目すればほんとうに信じられないくらいの品質向上・速度の向上が見られる

AIが得意な作業の例:

コーディングエージェント

Deep Research

言語化・要約

図表化

画像化

エージェントによる自動化

これらは間違いなく多くの人にとって仕事の速度向上と品質の変化をもたらしている

2022年11月以来業務でもプライベートでも生成AIはないと困るレベルの存在になっている

AIが得意な作業はとんでもない飛躍的な変化をしている

一方で事業の成果が飛躍的に伸びているわけではない

生成AI様のおかげで利益が出るようになり多くの会社で効率化が進み景気が良くなるという感じはしない

個人がエンハンスされるインパクトは凄いがそれは局所的である

それが組織や事業全体にも効いているように錯覚している人が多いように感じている

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

生成AIは個人をエンハンスする力が強いので作業の変化に注目されている

システム開発ならコーディング企画職ならリサーチやドキュメント化や図式化

それを全体の成果につなげるのは簡単なことではない

局所的エンハンスが経験したことない強烈な局所最適である

数年前と比較したら魔法に見えるような局所最適である

あまりの衝撃に仕事全体にも効いているように感じてしまうのではないか

プロジェクトマネジメントとかチームマネジメントのスキルがある人が多数いないと全体でその効能を得ることはできないと伝えても重要性がちゃんと伝えられていない

プロジェクトマネジメントとかチームマネジメントのスキルがある人が多数いないと全体でその効能を得ることはできないということ自体は納得されるものの個人のエンハンスが強烈すぎてその重要性・必要性は軽く見られてるんじゃないかと思っている

その人たちがなにをすれば成果になるのかを示せてない

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

ヤバいレベルの局所最適が起きても利益が爆増したり売上が上がったりしない

作業5000時間を削減ってやつを見るたびに怪しい数字だなと思う

AIの活用だけに注目していてはいけなくてヤバいレベルの局所最適をどうアウトカムに変換できるかを問われているって強く意識する必要がある

アウトカムに向かって動けるチームマネジメントだとかプロジェクトマネジメントやプロダクトマネジメントの力を持った人の価値がより高まるだろう

ただAIを使うのが上手いとかAIを使いこなす知識を持っているだけじゃ成果には繋がらない

AIをこう使えば良いという業務改善的な型なんかではなく個別具体の動きからしか成果は生まれない

だからからこそチームマネジメントだとかプロジェクトマネジメントのスキルがある人たちがアウトカムに向かって動けるようにしていく必要がある

それって当たり前の話じゃないのと思われるかもしれないが必要性は理解されていたと思うが生成AIによってより難しくなってるんじゃないの複雑な世界がより複雑になっていてそれを紐解く能力が必要になってるんじゃないのという問題提起を強くしていく必要がある

こんなに業務改善されたよとか機能開発が爆速になったよってのはアウトカムを得るプロセスでしかない

AIによってそのプロセスは驚くほど変化が起きてるが利益や売上だとか事業価値を上げるところまでもっていくところまで変化を及ぼさなくてはならない

AIを使いこなすPMがいるって話でもないしマネジメントできる人はAIを制御するプロンプト書けるって話でもないし業務自動化とか複数人が関わるワークフローをAIでつなげる業務設計できる人が必要って話でもないがなんかそういう話になりがちである

もっとうまくこれを説明できるようにならないとなあ

(2025/12/18)

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

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

(2025/12/18)

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

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

要約:

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

イベント駆動のシステムで処理の流れが複雑化してピタゴラスイッチ状態になることがある

あるイベントが発生してそれをトリガーに別の処理が動いてさらにその結果を受けて次の処理が連鎖していくうちに全体のフローを把握するのが困難になる

どこで何が処理されるのかを追うのに複数のハンドラを行ったり来たりしながら読み解かなければならない

エネルギー取引のドメインを扱うプロダクトを開発している

公平な取引が行われていたことを証明するため官公庁への取引ログ提出を求められる場合があり任意の時点でのシステム状態を復元できる必要があるためCQRS+Event Sourcingパターンを採用してシステムを構築している

ある業務の完了をトリガーに別の業務を実行するというパターンは非常に多く見られる

注文が作成されたら履歴を作成する約定したら通知を送るといった後続業務が多数存在している

Event Sourcingではイベントが一級市民であるため自然とイベントをトリガーとして非同期で後続処理を実行するパターンを採用することとなった

一連の業務処理を一つのトランザクションで実行するのではなくイベントを介して非同期に連携させることによって異なる業務同士を疎結合に実装できたりユーザーリクエストに対するレスポンス時間の短縮にもつながるなどイベント駆動の利点を得られている

■ 2. 直面した課題

イベント駆動な業務プロセスの自動化を実現するため最初はイベントに対するハンドラを個別に定義するシンプルなアプローチを取っていた

このパターンはイベントを受けて1つの処理を行うという単純なケースには適している

履歴作成や通知送信など多くの後続処理はこのパターンで実装している

しかし業務プロセスが複雑になるとこのパターンでは対応しきれなくなった

2つの業務があり業務の開始位置が異なる場合:

業務①はイベントAから始まり処理1→イベントB→処理2-1の順に進む

業務②はイベントBから始まり処理2-2と進む

どちらの場合も途中でイベントBを受け取るが特定のイベントに対応して後続の処理を実行するだけの単純なイベントハンドラではイベントBを受けたときにこれがどの業務プロセスに属するイベントなのかを判別できないため次にどの処理に進んでいいのかが判断できない

この問題はイベントハンドラが前のステップのコンテキストを持たないことによって生じている

対応策として業務プロセスに関するコンテキスト情報をイベントに含める方法が考えられる

しかしこれにはいくつかの課題がある:

業務プロセスの制御に関する情報までイベントに含めてしまうとイベントが本来持つ業務で起こった事実を記録するという責務から逸脱してしまう

異なる業務がお互いの存在を意識しなければならなくなり疎結合性が損なわれる

業務プロセスが増えるたびにイベント定義が肥大化し保守が困難になる

外部システムを経由する業務プロセスではそもそも自システムのコンテキスト情報をすべてイベントに含めてもらうこと自体が難しい場合もある

一連の業務プロセスを独立したイベントハンドラの組み合わせで実装すると全体のフローを把握しづらくなる

どのイベントがどこで処理されるのかを追うために複数のハンドラを行き来しながら読み解く必要がありコードの可読性と保守性が低下する

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

Process Managerパターンを導入することで課題の解決を図った

Process Managerはイベント駆動の処理フローの中に複数の集約間のメッセージ交換を仲介・調整する役割を追加するパターンである

業務フローにおける現在のステップやコンテキスト情報を保持し受け取ったイベントに基づいて次に実行すべきアクションを決定して発行する

Process Managerは複数のステップからなる業務の流れを管理するステートマシンのように振る舞う

Process Managerの動作:

イベントを受け取る

現在の状態を確認する

次に行うべきアクションを決定して送信する

状態を更新する

実装時に意識したいのはProcess Managerはイベントを受け取りコマンドを発行するという責務に徹すること

業務ロジック自体はコマンドハンドラ側に実装しProcess Managerはあくまでどのコマンドを発行するかを決めるルーティング役に専念する

こうすることでコマンドハンドラとProcess Managerにロジックが分散することを防ぎコードの見通しが良くなる

単純なイベントハンドラとProcess Managerの違い:

イベントハンドラ:

状態を持たない

判断基準はイベントの内容のみ

適する用途は1イベント→1処理

Process Manager:

状態を持つ

判断基準はイベント+現在の状態

適する用途は複数ステップの業務プロセス

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

エネルギー取引を扱うシステムにおいて注文を作成するプロセスを考える

自システムは業務効率化のために注文をクローズドに管理するシステムである

それとは別に外部公開されている取引所システムが存在しユーザーはそちらにも注文を掲載したい場合がある

2つの市場:

InternalMarket:自システムが管理する市場

ExternalExchange:外部システムで管理される外部取引所

ユーザーは自システムが管理する市場にのみ注文を掲載することもできるし外部システムの取引所またはその両方に掲載することもできる

両市場を選択した場合の注文作成の流れ:

自システムで注文を作成

外部システムに注文作成をリクエスト

外部システムからの作成完了通知を待つ

外部取引所への掲載を反映

自市場への掲載を反映

作成完了を通知

ユーザーの画面に注文が反映される

どちらか片方の市場のみを選択した場合は上記のフローから不要なステップが省略される

注文作成プロセスは上記のようにユーザー起点で始まる場合もあれば外部システムの取引所で注文が作成されたことをきっかけに自システムに注文を取り込む場合もある

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

ProcessManagerの核となるインターフェース:

CanHandle:このProcess Managerが処理すべきイベントかを判定

Execute:イベントを受け取り状態に応じてコマンドを発行

ExecFunc:コマンドバスへの委譲関数でこれを通じてコマンドを実行し他の集約を操作する

Workerは複数のProcessManagerを保持しておりイベントを受け取ると対応するProcessManagerを探して実行する

commandBusはコマンドをコマンドハンドラにルーティングするコンポーネントである

■ 6. 状態遷移の設計

Process Managerの設計ではまずは業務プロセスを構成するステップとその状態遷移を整理することから始める

業務のステップ:

NotStarted:プロセス未開始

AwaitingExternalCreation:外部システムでの作成待ち

AwaitingExternalListing:外部取引所へ掲載されたことをマークする処理待ち

AwaitingInternalListing:自市場への掲載されたことをマークする処理待ち

Completed:プロセス完了

イベント:

OrderCreated:自システムで注文が作成された

ExternalOrderCreated:外部システムで注文が作成された

ExternalOrderRejected:外部システムでの注文作成が拒否された

ListedOnExternal:外部取引所への掲載が完了した

ListedOnInternal:自市場への掲載が完了した

もともとのリクエストの内容によって同じステップ・イベントでも次のステップが変わったり同じイベントが異なるステップで発生したりする

業務のコンテキストや現在のステップに応じて処理を分岐させる必要があるため単純なイベントハンドラの組み合わせでは処理の流れを把握することはかなり難しくなる

Process Managerのメソッドとして各イベントのハンドラを実装していくため状態遷移を表形式でまとめると実装時に役立った

業務プロセスの状態を保持する構造体:

ProcessID:業務プロセスを一意に識別するID

Step:現在のステップ

OrderID:対象の注文ID

MarketDest:掲載先

ProcessIDがポイントである

業務プロセスの開始時に例えば注文作成時にProcessIDを生成し後続のイベントにはこのProcessIDのみを含める

イベント定義にプロセスのコンテキスト情報を含める代わりにProcessIDを使って複数のイベントにまたがるプロセスを識別し必要なコンテキストはStateから取得する

外部システムを経由したコンテキストの受け渡しについては今回のケースにおいては外部システムがリクエストIDを受け取り結果通知時に同じIDを返す仕組みであったためProcessIDをリクエストIDに含めることによって実現した

自システムに必要なコンテキスト情報をすべて外部システムに引き回してもらうのは現実的でない場合が多いがリクエストIDのような一般的な仕組みを活用することで実現できるところもこのパターンの利点である

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

Executeメソッドではイベントの種類に応じたハンドラを呼び出し次の状態を保存する

イベントハンドラは内部的にコマンドハンドラを呼び出しコマンドを実行する

このとき新たにイベントが発生するため即座にコミットしてしまうと次の処理が現在の処理の完了を待たずに始まってしまい古い状態を参照して処理されてしまう可能性がある

これを防止するためにコマンドの実行と状態の保存を同一トランザクション内で行うようにしている

イベントハンドラでは現在のProcess Managerの状態に応じて処理を分岐させる

ExternalOrderCreatedイベントを処理するハンドラでは現在のステップによって注文作成が自システム起点なのか外部システムなのかを判別し適切なコマンドを発行している

ListedOnExternalイベントを処理するハンドラではもともとの注文作成時に指定された掲載先に応じて次のステップを分岐させている

以上のようにして複雑な業務プロセスをイベント駆動の利点を損なうことなく見通しよく実装することができた

■ 8. まとめ

Process Managerが解決する課題:

単純なイベントハンドラでは複数ステップにまたがる業務プロセスでどの文脈のイベントかを判別できない

処理が複数のハンドラに分散し全体のフローを把握するのが困難になる

Process Managerに業務プロセスに関する知識を集約し現在のステップやコンテキストを状態として保持することでイベント駆動の利点を損なうことなく複雑な業務プロセスを見通しよく実装できる

設計するときのポイント:

まず業務プロセスをステップと状態遷移で整理すると実装しやすい

業務ロジックはコマンドハンドラ側に実装しProcess Managerはルーティングに徹する

Process Managerは強力なパターンだが単純なケースには過剰な抽象化になり得るため使いどころを見極める必要がある

履歴作成や通知送信といった単純な後続処理はシンプルなイベントハンドラで実装している

イベント駆動のシステムで業務プロセスが複雑化してきたときはProcess Managerパターンの導入を検討する

(2025/12/17)

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

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

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

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

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

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

@gaijineers

MEMO:

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

(2025/12/17)

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

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

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

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

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

(2025/12/17)

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

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

(2025/12/17)

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

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

(2025/12/17)

Why Startups Die

Why Startups Die - by Mathias Klenk - Tech Founder Stack

要約:

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

スタートアップの失敗率は推定で10社中9社

大半のスタートアップは巨大な競合による「他殺」ではなく内部問題による「自殺」で終わる

YC創設者Paul Grahamは「スタートアップは他殺よりも自殺で死ぬ可能性が高い」と指摘

最大の脅威は通常会社の外部ではなく内部から来る

■ 2. 自殺vs他殺の概念

Silicon Valleyの格言「スタートアップは死なず自殺する」

起業家Justin Kanは多くの若い企業が選択肢を使い果たすずっと前に崩壊することを観察

スタートアップはまだ十分に存続可能な状態で自らを諦める

創業者が燃え尽きるか心が折れチームが終了を宣言

創業者はスタートアップが困難で大規模な疲弊を引き起こすことに気づき別の仕事に就くか学校に戻るか単に離れていく

Y CombinatorのHarj Taggarは多くの企業が単に創業者が努力を止めるために失敗することに気づいた

成功するスタートアップは継続し続けるもの

勝つ方法は死なないこと

早すぎる諦めがしばしば真の殺し屋

内部問題の蓄積(明確な牽引力なし・絶え間ない障害・チームの意見の相違・ストレス)が絶望につながる

YCの段階では企業は諦めるか創業者が仲良くできないために失敗する

もう一つの大きな理由は企業が人々が本当に望むものを作っていないこと

プロダクトマーケットフィットに到達していないか共同創業者と毎週戦っている場合創業者が継続する意志を失う理由は明白

外部競争だけが直接スタートアップを殺すことは稀

優れた製品と堅実なチームがあれば競合は簡単に破壊できない

はるかに頻繁にスタートアップは不作為・対立・焦点の喪失によって自らを打ち負かし競争は単に見ているだけ

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

資金不足はスタートアップが死ぬ最も目に見える方法の一つ

100以上のスタートアップの事後分析で資金不足は失敗の第2位の理由

しばしばスタートアップは次の資金調達ラウンドを間に合わせられないか初期資金が枯渇する前に収益が実現しない

資金不足は通常症状であり根本原因ではない

より深い問題はなぜスタートアップが最初に資金不足になったのか

多くの場合プロダクトマーケットフィットを達成できなかったため

真に望む人がほとんどいないものを作っていたため収益と投資家の関心が低いまま

ベンチャーキャピタリストMarc Andreessenは「第1の企業殺しは市場の欠如」と述べる

誰も必要としない製品を構築すればシード資金がいくらあっても最終的に現金は何も示さずに燃え尽き資金調達は不可能

スタートアップはプロダクトマーケットフィットに決して到達しないときに失敗する

プロダクトマーケットフィット以外に財務管理の誤りが終焉を加速させる可能性

一部のチームはビジネスを検証する前にあまりにも積極的に支出(多くの人を雇用・豪華なマーケティング)しキャッシュクランチを引き起こす

他のチームはマネタイズや資金調達が遅すぎ単に時間切れ

資金不足になった多くの創業者は実際には成功の瀬戸際にいたが早すぎる諦め

Justin Kanは指標が急上昇しているときに創業チームが諦めるのを見ることは稀だと指摘

大半は成長が横ばいで資金が少ないときに諦める

それはまさに忍耐と反復が必要な瞬間

一夜にして成功は実際には一夜にして起こらない

忍耐し滑走路を延ばす方法を見つける人(燃焼を削減・ピボット・ブリッジラウンドの確保)は事態を好転させる機会を得る

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

資金不足が棺桶の最後の釘ならば共同創業者の対立はしばしば最初に棺桶を構築したもの

Harvard研究者Noam Wassermanの統計では高い潜在性を持つスタートアップの65%が共同創業者間の対立により失敗

初期段階では創業チームが会社そのもの

チームが崩壊すれば会社も一緒に崩壊することが多い

共同創業者の内輪もめは投資家を遠ざけ意思決定の麻痺を引き起こし社内から企業文化を毒する

間違った共同創業者を選ぶことは間違ったアイデアを選ぶことと同じくらい致命的

スタートアップの伝承は共同創業者を結婚したカップルに頻繁に例える

関係が悪化すれば面倒な離婚が製品が有望であってもスタートアップを殺す可能性

大きな質問での不一致(急速に拡大すべきかペースを調整すべきか・会社を売却すべきかIPOを目指すべきか・成功をどう定義するか)は最終的に和解できない相違につながる

一人の創業者が10億ドルのユニコーンを構築することを想像し別の創業者が小規模で安定したビジネスで満足なら戦略と目標で衝突

明白な対立を超えて重要な創業者や初期チームメンバーが去るシナリオもある

共同創業者が辞めると若いスタートアップの士気と運営に信じられないほど厳しい

残りのチームは「単一創業者」問題を抱える

すべての負担が一人の肩にかかる

Paul Grahamは最初から単一創業者を持つことについて実際に警告

複数の創業者を持つスタートアップには優位性がある

スタートアップを始めるのは一人には難しすぎる

ブレインストーミングをする同僚が必要でありうまくいかないときに元気づけてくれる人が必要

その仲間意識を失うとスタートアップの低い時期が耐えられなくなる可能性

創業チームメンバーが去った後すぐに会社が崩壊するのを見てきた

失われたスキルのためだけでなく感情的な接着剤がなくなったため

場合によっては残りの創業者が自信と勢いを失いゆっくりと消えていく

創業者間またはチーム間の不適合は良いアイデアでさえ沈める可能性

創業チームが整合し一緒にうまく機能することを確実にすることはスタートアップの生存に絶対的に重要

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

もう一つの一般的な自傷行為は創業者が焦点や動機を失うとき

スタートアップは一途な献身を要求する

リーダーが気を取られ始めると悪い兆候

CB Insightsの分析では焦点を失うことはスタートアップが失敗する上位20の理由の第11位

時には創業者が新しいサイドプロジェクトを追い始める(別のスタートアップアイデアをいじる・コンサルティングギグを引き受ける・新しい趣味に手を出す)

他の時にはより微妙でチームが一つの戦略にコミットせずに新しい方向にピボットし続けるか一度にあまりにも多くの機能を追求して自分自身を薄く広げる

いずれにせよスタートアップはリーダーが一つの明確なビジョンに全力投球していないため勢いを失う

焦点の喪失はしばしば情熱の喪失と結びついている

初期の頃には避けられない課題を乗り越えるために膨大な量の熱意が必要

創業者の心がもうそこにないなら進歩は停止する

成長が停滞したときに創業者が精神的にチェックアウトするのを見てきた

倍増する代わりに他の機会について空想を始める

Justin Kanは辞めたい誘惑がJustin.tv中に何度も彼を襲ったと説明

物事が暗く見えたときに諦めて先に進む寸前に来る

苦痛な労苦から逃れたいと思うのは人間の本性でありスタートアップを運営することは確かに労苦になる可能性

創業者は極度のストレスと燃え尽きにも直面しモチベーションを奪う可能性

長時間・生き残るためのプレッシャー・感情的なジェットコースターが疲弊につながる可能性

創業者が燃え尽きると先延ばしを始めたり厳しい問題を避けたり重要な決定を委任したりする可能性

これらはすべて腹の中の火が消えかけているサイン

最終的に情熱が再燃しなければスタートアップは放置からゆっくりと枯れる

スタートアップは通常餓死しない・すべての機会と気晴らしに溺れる

ミッションに焦点を合わせ続けることは聞こえるよりも難しいが自己誘発的な死を避けるために絶対に必要

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

共同創業者を賢く選びビジョンで整合する:

共同創業者を選ぶことはアイデアを選ぶことと同じくらい重要

価値観と長期目標を共有することを確認

不一致の願望(一人の創業者は迅速な売却を望み別の創業者は永遠に構築したい)は対立につながる

スタートアップの65%が共同創業者の対立により失敗することを覚えておく

共同創業者関係を注意深く扱いオープンにコミュニケーション

期待(株式分割・役割・出口戦略)を後で戦うよりも早期に整理する方が良い

人々が望むものを作る(プロダクトマーケットフィットを達成する):

これはYCからの黄金律でユーザーが望むものを作らないことが究極の殺し屋

ターゲットユーザーと絶え間なく話し実際の問題を解決していることを検証し神経に触れるまで反復する意志を持つ

顧客が本当に製品を愛しているなら死ぬ可能性ははるかに低い

牽引力は多くの問題を解決する・投資家を引き付けチームの士気を高め滑走路を延長する収益を提供

Harj Taggarが言ったように多くのスタートアップは企業が人々が本当に望むものを作っていないために失敗

技術自体に恋をしない・人々にとって本当に重要な痛点を解決

滑走路と財務を慎重に管理する:

資金不足は多くの場合予防可能な失敗

常に滑走路(残りの現金の月数)を知り空になるずっと前に資金調達または収益マイルストーンを計画

コストを管理下に保つ・ゆっくり雇用し針を動かすものに支出し虚栄心には支出しない

多くのスタートアップはあると良いものに資金を燃やし後で後悔

経験則として次の主要なマイルストーン(製品の立ち上げ・ユーザーターゲット・収益目標)に到達するのに十分なお金にバッファを加えて調達するよう試みる

物事が長くかかる場合は費用を削減するか延長ラウンドを調達する準備をする

魅力的ではないが生存はしばしば慎重な現金管理に帰着

投資家は「時間内に調達できない場合何をしますか」と尋ねる・答えを持つ(燃焼を減らす・戦略的パートナーを見つけるなど)ので危機に陥らない

本質的に機能するものを見つけるための時間を買う

焦点を保ち完全にコミットする:

一度に2つの会社を運営しようとしないしスタートアップをサイドハッスルのように扱わない

繁栄するスタートアップは通常創業者が両足で飛び込むもの

輝く新しいアイデアは常に誘惑する・すべてのウサギを追いかけることに抵抗

Paul Grahamの「13文でのスタートアップ」のアドバイスは単に焦点

チームは四半期ごとの最優先事項を知り気晴らしにノーと言う

これは厳しい時期を耐え抜くことも意味

小さな勝利であっても進歩を続けていれば諦める多くの人々を生き延びる

格言にあるように失敗を保証する唯一の方法は試みるのをやめること

ほぼすべての成功したスタートアップは物事が厳しく見えた段階を経たが創業者は継続した

決意と回復力をコアチームの価値観として育成

健全な共同創業者関係とチーム文化を育成する:

内部不和がスタートアップの殺し屋であるためチームを整合させ続けることに投資

共同創業者と絶えずコミュニケーション・パフォーマンス・株式・方向性についての厳しい会話を後ではなく早く行う

役割や報酬を調整する必要がある場合は対処

意見の相違を解決するメカニズムを設定(信頼できるメンターまたは仲介できる取締役会メンバー)

多くの対立は明確なコミュニケーションと共感によって和らげることができる・スタートアップを勝たせようとしている同じ側にいることを覚えておく

また全員が懸念を声に出せ燃え尽きが認識される文化を構築

完全な疲弊を避けるために必要なときに休憩を取るよう人々(創業者自身を含む)に奨励

支援的でミッション駆動型の文化は欲求不満と不一致を防ぐのに役立ちしばしばスタートアップの自殺につながる

成功(と失敗)を一緒に計画する:

悲観的に聞こえるかもしれないが物事が南に行く場合に何が起こるかを事前に議論

一人の創業者が出たい場合はどのように処理するか

買収オファーが来た場合は両方とも売却にオープンか

これらのシナリオで整合することは後で多くの心痛を節約できる

反対側で成功のための共有計画を作成・すべてがうまくいけば私たちのビジョンは何か

共通のビジョンを持つことは暗い日々の間皆のモチベーションを維持

共同創業者が同じ最終ゲームとなぜそれが戦う価値があるかを見るときにコミットし続けることが容易

■ 7. 結論

ほとんどのスタートアップは市場の捕食者のために終わりを迎えない

内部の失策・壊れた関係・意志の喪失のために終わりを迎える

経験豊富な創業者からの事後分析とエッセイはすべてこの真実を反映・スタートアップの運命は主に自分の手の中

反対側は力を与える・古典的な落とし穴を避けチームの世話をすれば生存の確率を大幅に高める

人々が望むものを構築しチームを団結させ賢く支出し決して早すぎる諦めはしない

そうすれば自分のスタートアップが単に自殺を避けるだけでなく実際に繁栄しビジョンが生き返るのを見る機会を劇的に高める

Paul Grahamが有名に暗示したように勝つ方法は死なないこと

生き続ければ最終的に成功する機会を自分に与える

(2025/12/16)

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

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

(2025/12/16)

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

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

要約:

■ 1. 技術概要

SPhotonixが5Dメモリクリスタルの商用化に向けて450万ドルの資金調達を完了

2025年12月に英国とスイスに拠点を置くディープテック・スタートアップが発表

溶融シリカガラスを用いた事実上の恒久保存を実現するデータストレージ技術

宇宙の年齢に匹敵する138億年の耐久性を誇る

既存ストレージ(HDD・SSD・磁気テープ)は数十年から100年程度で限界を迎えるのに対し圧倒的な優位性を持つ

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

フェムト秒レーザーによるナノ構造化技術:

サウサンプトン大学Peter Kazansky教授が20年以上研究

1000兆分の1秒という極めて短いパルス幅を持つレーザーを使用

5つのパラメータでデータをエンコード:

X座標(空間的位置)

Y座標(空間的位置)

Z座標(空間深さ)

配向(ナノ構造の向き)

強度(光の遅相軸の強さ)

溶融シリカガラス内部に微細なボクセル(3次元ピクセル)を刻み込む

ボクセルは複屈折特性を持ち入射する光の偏光や方向によって異なる屈折特性を示す

偏光させた光を照射しその変化を光学的に検出することでデータを復元

5インチのガラスディスク1枚に最大360TBのデータを格納可能

一般的な大容量HDD(30TB級)の10倍以上の密度を実現

■ 3. 耐久性と安全性

190℃の高温環境下で138億年のデータ保持が可能

耐熱性・耐環境性:

石英ガラスは化学的に極めて安定

磁気の影響を受けない

放射線・水・湿度による劣化がほぼ皆無

データ保持に電力を一切必要としないエアギャップなメディア

ランサムウェア攻撃に対する究極の防御策として機能

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

コールドデータの定義と分類:

世界中に保存されているデータの60〜80%がコールドデータ

ホットデータは5ミリ秒未満でのアクセスが必要(SSDの領域)

ウォーム/クールデータは数秒以内のアクセスで十分

コールドデータはアーカイブ・法的記録・科学データなどアクセス頻度は低いが長期保存が義務付けられ取り出しに10秒以上かかっても問題ない

現状の問題点:

慣性により人々はコールドデータ保存にも寿命が短くエネルギーを大量に消費するHDDやSSDを使い続けている

AIの台頭によりデータ生成量は指数関数的に増加

IDC予測によれば2028年までに年間生成データ量は天文学的な数値に達する

持続可能性の観点:

全データを回転するHDDや通電が必要なSSDで保存し続けることは電力消費と廃棄物の観点から持続不可能

HDDは数年ごとのリプレイスが必要でそのたびに莫大なコストと廃棄物が発生

SPhotonixのガラスメディアは一度書き込めばリフレッシュや空調による厳密な温度管理なしに永久にデータを保持可能

データセンターのTCO(総所有コスト)とカーボンフットプリントを劇的に削減する可能性

■ 5. ビジネス戦略

資金調達:

2025年11月25日にCreator FundとXTX Venturesが主導するプレシードラウンドで450万ドルを調達

技術成熟度レベルをTRL5(技術検証段階)からTRL6(プロトタイプ実証段階)へ引き上げるために投資

Arm/NVIDIAモデルの採用:

製造会社になるつもりはないとIlya Kazansky CEOが明言

自社で大規模なガラスディスク量産工場を建設せず核心となるイネーブリング・テクノロジーを開発しライセンス供与するモデル

ハイパースケーラーやストレージベンダーとコンソーシアムを組みデータセンターにプロトタイプを展開する計画

コストとパフォーマンス:

書き込み装置は約30,000ドル(約450万円)

読み取り装置は約6,000ドル(約90万円)

現在の転送速度は書き込み4MB/s・読み取り30MB/s

3〜4年以内に読み書き共に500MB/sまで引き上げる計画

実現すれば現在のアーカイブ用磁気テープシステム(LTOなど)と競合可能な水準

■ 6. 競合分析

Microsoft Project Silica:

同様にフェムト秒レーザーと石英ガラスを用いたストレージを開発

Azureクラウド向けのアーカイブソリューションとして実証実験を進行中

自社のAzureインフラへの垂直統合を主眼に置く

Cerabyte:

セラミック素材を用いたストレージを開発するスタートアップ

SPhotonixの優位性:

オープンなエコシステム志向

ライセンスモデルを通じて多様なデータセンター事業者やハードウェアメーカーが技術を利用できるプラットフォームを提供

元Project Silicaの研究者を採用する計画を明かし技術的な知見の集約を図る

■ 7. 文化的意義と実績

技術の象徴的なデモンストレーション:

全ヒトゲノムデータを結晶に保存

Eon Ark Time Capsuleとして2024年〜2025年の会話記録をアーカイブ

名作ゲーム『Heroes of Might & Magic 3』を保存

映画『ミッション:インポッシブル/ファイナル・レコニング』において技術がフィーチャー

人類の知識と文化を文明の存亡を超えて保存する究極のバックアップとしての役割

■ 8. 技術的意義と展望

磁気や電荷という不安定な現象への依存から脱却し結晶構造という物理的な恒久性を手に入れる転換点

ハイパースケーラー各社が直面するエネルギー問題とデータ爆発の圧力が今後数年で技術の実用化を強力に後押し

読み書き速度の向上とコストダウンという課題は残存

TRL6への移行とライセンスモデルの採用により技術が実験室を出てデジタル社会の基盤となる日が近い

数千年後の未来において現代の文明を伝えるのはSPhotonixのクリスタルに刻まれた光の記憶である可能性

(2025/12/16)

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

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

要約:

■ 1. 背景と課題

DBコストが毎月徐々に上昇する問題に直面

予約管理システムで薬剤師が最新の予約情報をリアルタイムで確認できることが重要な要件

フロントエンドから30秒間隔でAPIをポーリングする実装を採用

システムの成長とともに問題が顕在化

ポーリング間隔は30秒で1回あたりのAPIコール数は9回

予約検索APIの秒間リクエスト数は約2,000リクエスト/秒

予約一覧・予約詳細・ステータス情報など画面表示に必要な情報を複数のエンドポイントから取得していたため1回のポーリングで9回のAPIを呼び出し

多数の薬局クライアントが同時にポーリングを実行するためリクエスト数が膨大化

予約データは日々構造が複雑になりデータベースのテーブルにインデックスを張っても大きな負荷がかかる状況

ポーリング方式の根本的な問題はデータに変更があってもなくても定期的にリクエストが発生する点

予約データに変更が発生する頻度はポーリング頻度と比較してかなり低い

大半のリクエストは「変更なし」という結果を返すだけで実質的な価値を生み出していない

無駄なリクエストが継続的にデータベースへ負荷をかけインフラコストを押し上げる要因

プロジェクトで導入店舗数が倍増し月次のインフラコストレビューでDBコストの上昇トレンドが明確化したことが転機

■ 2. 解決策の設計思想

変更があったときだけ通知を受け取る方式への転換を決断

従来のプル型(ポーリング)からプッシュ型(イベント駆動)への転換により不要なリクエストを根本的に排除することを目指す

処理フロー:

予約データに変更が発生(イベント発火)

イベント伝播用マイクロサービスがサブスクライブ

マイクロサービスがFirestoreの薬局別ドキュメントを更新

フロントエンドがFirestoreの変更を検知

必要な予約データをAPIから取得

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

予約サービス(イベント発行元):

予約の作成・更新・キャンセルなどの変更を検知しイベントを発行

既存の予約システムに最小限の変更を加える形で実装

Cloud Pub/Sub:

Google Cloudが提供するフルマネージドなメッセージングサービス

イベントの非同期配信を担いシステム間の疎結合を実現

イベント伝播サービス:

GKE上で稼働する軽量なマイクロサービス

Pub/Subからイベントを購読しFirestoreの更新を行う

独立させることで関心の分離と保守性の向上を図る

Firestore:

薬局ごとのイベント状態を管理するリアルタイムデータベース

各薬局に対応するドキュメントを用意しイベント発生時にタイムスタンプを更新

フロントエンドクライアント:

Firestoreのリアルタイムリスナー機能を使用して自身に関係するドキュメントの変更を監視

変更を検知したら必要なデータをAPIから取得

■ 4. 技術選定の根拠

Firestoreを選んだ理由:

リアルタイム同期機能が標準装備でSDKを使うだけで面倒な接続管理なしにリアルタイム同期が実現可能

Google Cloudのマネージドサービスとして自動的にスケールしクライアント数の増加に対してインフラ側での対応が不要

薬局ごとのドキュメント分離により各薬局が自身に関係するドキュメントのみを購読するため不要なデータを受信しない

既にGKEやPub/Subを使用していたため同じエコシステム内で完結できる

Pub/Subを介在させる理由:

システム間の疎結合化により予約システムはFirestoreの存在を知る必要がなく「イベントを発行する」という責務のみを持つ

信頼性の向上でPub/Subはメッセージの永続化と再送機能を持つため一時的な障害が発生してもイベントが失われない

Pub/Subのメトリクス(未処理メッセージ数・処理時間など)を監視することでシステムの健全性を把握しやすい

将来的には分析基盤への連携・通知サービスへの連携などイベントの配信先を追加する可能性があり拡張が容易

Cloud Tasksを選んだ理由:

動的なタスクスケジュールに最適でフルマネージド

指定した時刻に1回だけHTTPリクエストを送信するというシンプルな機能を提供

キューの管理やスケーリングを意識する必要がない

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

課題:

予約の登録や更新・キャンセルなどが短時間の間に行われた場合に多数のイベントが発生

同じ薬局に対して数秒間で何十回もFirestoreが更新される

フロントエンドが変更を検知するたびにAPIを呼び出し結局大量のリクエストが発生

スパイク時の負荷が改善されない

解決策:

Cloud Tasksを使ったスロットリング機構を導入

一定時間内に発生した複数のイベントを1回の通知にまとめる

Cloud Tasksで遅延実行を行い指定時刻にHTTPリクエストを送信

スロットリング間隔の調整:

10秒という値を採用

通常の予約操作ではユーザーが10秒以内に複数回更新することは稀

複数イベント発生時のイベント集約効果が十分に得られる

ユーザーが体感する遅延として許容範囲内

モニタリングの結果を見ながら調整を継続

■ 6. テスト戦略

イベント発生ケースの網羅:

イベントが正しく発火されることがシステム全体の動作に直結

イベントの発火漏れがあればフロントエンドに変更が伝わらずユーザーは古い情報を見続ける

イベントが発生するすべてのケースを洗い出し網羅的にテストを実施

ケースの洗い出し:

予約作成(処方箋事前送信予約・オンライン服薬指導予約・店頭受付)

予約更新(日時変更・ステータス変更・患者情報変更・メモ追記)

予約キャンセル(ユーザー操作・自動キャンセル・管理者操作)

動作確認の観点:

イベントが正しく発火されるか(Pub/Subにメッセージがパブリッシュされることを確認)

イベント内容が正しいか(薬局ID・予約ID・イベントタイプが正確に設定されていることを確認)

Firestoreが更新されるか(該当薬局のドキュメントが更新されることを確認)

フロントエンドが検知するか(画面上で変更が反映されることを確認)

リグレッションテストとの擦り合わせ:

既存のリグレッションテストで今回洗い出したイベント発生ケースがカバーされているか確認

カバーされていないケースがあれば新たにテストケースを追加

イベント発火の確認をリグレッションテストの検証項目に追加

本番リリース後のイベント発火漏れはゼロを達成

■ 7. 導入結果

定量的効果:

予約検索APIの秒間リクエスト数は約2,000/秒から約1,000/秒へ50%削減

DBコストは30%削減

ネットワークトラフィックは大幅削減

定性的効果:

リアルタイム性の向上で従来は最大30秒の遅延があったが予約の変更がほぼリアルタイムで画面に反映

システム安定性の向上でポーリングによる定期的な負荷スパイクがなくなりデータベースへの負荷が平準化

開発者体験の改善で各コンポーネントの責務が明確でデバッグや機能追加がしやすくなった

■ 8. 運用上の考慮事項

成功要因:

段階的なリリースでまずは一部の薬局から段階的に展開し想定外の問題があった場合の影響範囲を限定

監視体制の整備でPub/Subの未処理メッセージ数・Cloud Tasksの実行遅延・Firestoreの読み取り/書き込み数・フロントエンドからのAPI呼び出し数を監視

チーム内での知識共有で新しいアーキテクチャについて設計の意図や運用方法をドキュメント化し属人化を回避

留意すべき事項:

イベント欠損への対策としてPub/Subの再送機能を活用(デッドレターキューの設定)

順序保証の考慮で分散システムにおいてはイベントの到着順序が発生順序と一致するとは限らない

Firestoreコストの試算で導入前に試算を行いトータルでコストメリットがあることを確認

■ 9. 今後の展望

スロットリング間隔の動的調整で時間帯やイベント発生頻度に応じて動的に調整することでさらなる最適化が可能

他システムへの水平展開で今回得られた知見を他のポーリング処理を行っているシステムにも展開予定

(2025/12/16)