/note/tech

データモデルのイベントの期間の設計のコツ

• データモデルのイベントの期間の設計のコツ - そーだいなるらくがき帳

要約:

■ 1. 一般的なイベント期間のテーブル設計

• アプリケーション開発で期間を表すデータを扱うことは珍しくない
• イベントの開催時間やタスクの予定時間などが該当する
• 一般的なテーブル設計は開始時間と終了時間をそれぞれstart_atとend_atカラムで保存する
• この設計はAIが一発で提案するほど一般的である

■ 2. 一つのテーブルに期間を持つ場合の適用範囲

• 一つのテーブルに開始時間と終了時間の両方を持つ設計は期間が明確に定義されている場合には有効である
• 開始時間と終了時間がともに必ず存在し必ず終了することが保証されている場合に適している
• イベントの開催時間は必ず開始時間と終了時間が存在しイベントが終了することが保証されている
• イベントの属性として期間を持つことは自然である

■ 3. 終了時間が不明確な場合の問題

• 終了時間が開始時に決まっていない場合や終了しない場合もある:
  • タスクの予定時間はタスクが完了するまでの時間が開始時に決まっていないことが多い
  • 有効期間のようなもので終了時間を決めずに無期限にする場合もある
• このような場合はend_atをNULLとして登録する設計になる:
  • taskにデータを登録するタイミングではend_atにはNULLが登録される
  • 終了時間が確定したタイミングでend_atにUPDATEで値を設定する
  • 無期限の場合はNULLをそのまま設定する
• この設計は一見問題なさそうに見えるが実際にはいくつかの問題がある

■ 4. キャンセル仕様追加時の設計問題

• タスクのキャンセルを表現させたい場合の課題:
  • end_atにキャンセル日時を設定すると理由がわからない
  • キャンセルを表現するためにstatusカラムを追加することが考えられる
  • status='canceled'のときはキャンセルでありstatus='closed'のときは正常終了である
• 最もやってはいけない設計:
  • canceled_atカラムを追加すること
  • end_atとcanceled_atの両方に値が入る可能性がある
  • 逆にどちらかにしかデータが無い場合が発生する
  • 集計クエリが破綻しどちらが正しい終了時間なのかがわからなくなる

■ 5. statusカラムの制限事項

• statusカラムは最新のデータしか持てない
• 失敗から学ぶRDBの正しい歩き方の「失われた事実」で説明されている
• キャンセル後の再オープンの問題:
  • キャンセルしたがリオープンしたい場合はステータスをcanceledからopenにUPDATEしend_atをNULLに戻す
  • 過去にキャンセルされた事実が失われてしまう
• statusカラムがなくても一回クローズしたタスクを再度オープンする場合も同様である
• このユースケースはGithubのIssueやPull Requestでもよくあり想定する必要がある
• 解決策:
  • ステータスのhistoryテーブルを別に持つ必要がある
  • statusカラムは履歴の最新の状態を非正規化で持っていることと同義になる
  • 更新漏れや不整合が起きるリスクを常に抱える
  • historyテーブルの最新行を現在のステータスとして参照する設計に変えることもできる
  • status_historyテーブルにステータス変更の日時をもたせた方が良い

■ 6. イベントテーブル分割による設計改善

• start_atとend_atを持たせて期間として扱うという前提自体を疑う必要がある
• テーブルのステータスに依存関係がある場合:
  • 下書き→承認→公開のようなワークフローがある場合
  • ステータスの順番に制約を持たせたい場合もある
• イベントごとのテーブル分割設計:
  • tasksテーブル（基本情報）
  • task_draft_eventsテーブル（下書きイベント）
  • task_approve_eventsテーブル（承認イベント。draft_event_idを参照しtask_idで必ずユニークになるように制約）
  • task_close_eventsテーブル（クローズイベント。statusでclosedまたはcanceledを区別）
• この設計の利点:
  • 特定のステータスの順番に制約を持たせることができる
  • taskテーブルにstart_atとend_atを持たせる設計だとステータスの順番に制約を持たせることが出来ない
  • データの整合性が保てなくなる

■ 7. 設計の推奨アプローチ

• 期間を表すデータをテーブルに持たせる場合の注意点:
  • 開始時間と終了時間の両方を持たせる設計は一般的である
  • 終了時間が不明確な場合や状態遷移がある場合には注意が必要である
• 終了時間カラムや範囲をもたせるときにNULLを許容する場合:
  • まず一度立ち止まる
  • そもそも期間として設計することが適切かどうかを検討する
• 多くの場合の最適解:
  • 深ぼるとテーブルを分割した方が良いケースが多い
  • 結果としてデータの整合性が保たれる
  • クエリもシンプルになることが多い
• テーブル分割の検討方法:
  • 期間の対象となるイベントやリソースに対してどのような状態があるのかを洗い出す
  • 状態ごとにイベントテーブルを分割することを検討する
  • まずは細かく分けて設計する
  • その後に必要に応じて物理設計の際にパフォーマンスなどと比較しながら統合を検討する

■ 8. 時間枠の集計の難しさ

• テーブルを分割してもしなくても時間枠の集計は難しい
• ある期間に重複しないタスクを登録したい場合の課題:
  • 時間枠の扱いはSQLに限らずプログラミングの題材として難易度が高い
  • 特に重複と含有が複数のパターンの場合ロジックが複雑になりバグの温床になりやすい
  • リーダブルコードでも「8.5 例:複雑なロジックと格闘する」でこの問題が取り上げられている
• end_atにNULLがある場合の処理:
  • NULLは無期限のタスクとして扱う
  • NULLは比較演算子で扱えないためWHEREの範囲で絞ることはできない
  • NULLを特定の未来日時に変換する必要がある（例:9999-12-31 23:59:59）
  • MySQLではIFNULL関数を使用しPostgreSQLではCOALESCE関数を使用する
• 実務での複雑性:
  • アサインされた担当別やプロジェクト別やステータス別など条件が増える
  • より難易度が高くなる
• PostgreSQLの範囲型:
  • この問題を解決してくれるため強力な選択肢である
  • 全てのDBMSでサポートされているわけではない
  • 別の考え方が必要になる

■ 9. start/endの命名に関する考察

• ClaudeもChatGPTも全てstart_atとend_atで設計することを提案する
• 本来の適切な命名:
  • 期間を表す場合はfromとtoの方が適切である
  • beginとendの方が自然である
  • startならstopの方が対になる
  • 期間を表すならfrom-toやbegin-endの方が意味が通りやすい
• 著者は毎回レビューなどで指摘しがちである
• あまりにもstartとendが浸透している
• 本来は誤用だったが慣用化したと言えるかもしれない

(2026/01/28)

ソフトウェアがいずれ「使い捨てすら可能になる」は自分も賛成だけど、ここで反対論を出してる人の...

ソフトウェアがいずれ「使い捨てすら可能になる」は自分も賛成だけど、ここで反対論を出してる人の多くは例によって「今の性能の生成AIが続いたら」という仮定で話してるので議論として噛み合っていない。

この話いっつも同じパターンになるんですよね。横軸が時間で縦軸が性能だとして（ざっくり近似）、遠くない内に使い捨て可能なソフトウェアが作れるくらいAIの性能が上がるんじゃないの、てのが元の問題提起であって、それに反論するなら「そこまで生成AIの性能は到底上がりそうにない」を持ってこないといけないわけだ。

もっとざっくり言えば「そのうち～なる」という主張に対して「今は～でない」は反論になってないって話。時相論理的な主張なんだけど、反論者がそこを読み取れていない。この話なら元の話題は数年～10年スパンくらいの話に見えるので、反論として性能がサチりそうな気配とかそういうの出せばいいんじゃないかな。

@kmizu

MEMO:

• ネットの議論ですぐ頭に血を上らせて全否定してくる人は基本的に文章読めてないので仕方がない

(2026/01/27)

糸井重里さん「今全国のSEが、食品のみ消費税0％が現実になったらという問題について涙目になりながら...

• 糸井重里さん「今全国のSEが、食品のみ消費税0％が現実になったらという問題について涙目になりながら考えていると思う」→本職の方々「8を0に変えるでよくて」 - Togetter

MEMO:

• 素人がわかったような事を言うな案件

(2026/01/27)

Is There a WordPress Replacement in 2026? I Went Looking

• Is There a WordPress Replacement in 2026? I Went Looking | Jean Galea

要約:

■ 1. 調査の背景と動機

• WordPressエコシステムで20年以上活動してきた著者が代替案を探索した
• 7歳の息子がウェブサイトを作りたいという要望がきっかけとなった
• 2025年のAutomatticとWP Engine間のガバナンス問題が緊急性を高めた:
  • Matt MullenwegがAutomatticとWordPress.org基盤の両方をコントロールしている
  • WP Engineのプラグインアップデートアクセスをブロックした
  • WordPressエコシステムには単一障害点が存在することが明らかになった
  • 一人の決定が数百万のサイトが依存するプラグインアップデートメカニズムを混乱させ得る
• WordPressは全ウェブサイトの約43%を占める

■ 2. 静的サイトジェネレーター（Astro、Hugo、Eleventy）

• 開発者コミュニティで人気がある
• Astroは特に勢いがありCloudflareが2026年1月にチームを買収した
• MarkdownまたはHTMLでコンテンツを作成し静的ファイルを生成する
• Cloudflare Pages、Netlify、Vercelに無料でデプロイ可能である
• 利点:
  • 出力が非常に高速である
  • データベース不要である
  • PHP不要である
  • セキュリティパッチ不要である
• 問題点:
  • 管理パネルがない
  • ビジュアルエディタがない
  • コードエディタでファイルを編集しGitにプッシュする必要がある
  • クライアントがコンテンツを更新する場合は不適切である
  • トレーニング時間がサイト構築時間を超える
• WordPress代替ではなくウェブサイトを生成する開発者ツールである

■ 3. モダンPHP CMS（Statamic、Craft、October）

• Statamic:
  • Laravelで構築されている
  • クリーンなコードベースである
  • 美しいコントロールパネルを持つ
  • フラットファイルストレージオプションでGitでバージョン管理可能である
  • ソロおよびホビープロジェクトは無料である
  • 商用利用にはライセンスが必要である（サイトあたり275ドル以上）
  • モダンなアーキテクチャでWordPressを再構築したものである
  • 商業的に売り込みが難しい
• Craft CMS:
  • 優れた開発者体験を持つ
  • 優れたコンテンツモデリング機能を持つ
  • エコシステムが小さい
• October CMS:
  • Laravel-WordPressハイブリッドを目指したが牽引力を得られなかった
• ClassicPress:
  • Gutenbergを削除したWordPressのフォークである
  • より伝統的で安定したWordPress体験の維持を目指す
  • ブロックエディタの方向性が主な不満である場合に対処する
  • より小さなエコシステムという同じ根本的な制限を持つ
  • Gutenberg専用に構築されたプラグインは動作しない
  • 開発者コミュニティはWordPressのごく一部である
• いずれもニッチを超えて成長しない
• ネットワーク効果が存在せず今後も存在しない可能性が高い
• LaravelはAI駆動のルネサンスを経験している:
  • AIアシスタンスでプラグインや拡張機能を構築することが容易になっている
  • Laravel ベースのCMS代替案が増加すると予想される
  • マーケットプレイスが急速に充実すると予想される
  • 堀が1年前の予測よりも早く崩壊する可能性がある

■ 4. ヘッドレスCMSオプション（Strapi、Directus、Sanity、Contentful）

• コンテンツ管理とフロントエンドを分離するアプローチである
• CMSにAPIでコンテンツを保存しフロントエンドを自由に構築する（React、Vue、静的HTMLなど）
• エンタープライズおよび複雑なアプリケーション構築開発者に人気がある
• 典型的なウェブサイトやブログには過剰設計である
• 2つのものを構築および維持する必要がある
• 使用量ベースの価格設定（ContentfulやSanity）またはセルフホスティングに大きな技術的オーバーヘッド（StrapiやDirectus）が必要である
• WordPress代替ではなく異なる問題のための異なるツールである

■ 5. ホスティングウェブサイトビルダー（Squarespace、Wix、Webflow）

• シンプルなウェブサイトを求める層をWordPressから奪った
• WordPressで苦労したであろう人々にとっては良い選択肢である
• サブスクリプションサービスであり柔軟性が制限されている
• 所有ではなくレンタルである
• プラットフォームがサポートしないことを実行したい場合に行き詰まる
• 月額料金を永久に支払う必要がある
• 異なる市場であり代替ではない

■ 6. 唯一の例外:Shopify

• WordPressから大きな領域を奪った唯一の例である
• 特にWooCommerceから領域を奪った
• 主張的でホスティングされているという特徴で成功した
• サーバー、アップデート、セキュリティ、プラグインの競合について考える必要がない
• 単に商品を販売できる
• テクノロジースタックよりも製品に集中したい商人にとって利便性プレミアムが価値があることが判明した
• 開発者でない場合はeコマースサイトにShopifyが正しい答えであることが多い
• 10年前は真実ではなかった

■ 7. WordPressが勝つ理由

• WordPressの堀はテクノロジーではない
• テクノロジーは最も弱い点である:
  • レガシーコードベース
  • 時として不器用なプラグインアーキテクチャ
  • コミュニティを分断したGutenbergの方向性
• 堀はエコシステムでありその中心はプラグインディレクトリである
• 公式WordPressリポジトリには60000以上のプラグインがある
• 商業的に販売されているプラグインが数千追加で存在する
• SEOツール、eコマース（WooCommerceとその数百の拡張機能）、Instagram表示（Spotlight）、RSSフィード集約（WP RSS Aggregator）、メンバーシップ機能、予約システム、フォームビルダー、多言語サポート、バックアップソリューション、セキュリティ強化、パフォーマンス最適化、アフィリエイト管理、メールマーケティング統合などあらゆる機能のプラグインが存在する
• この部分は新しいプラットフォームが近道できない
• 技術的に優れたCMSは1〜2年で構築できるが20年以上かけて開発された数万のプラグインのエコシステムは構築できない
• WordPressの代替案を評価する際に必要な機能が新しいプラットフォームに存在しないかカスタム開発が必要になる瞬間が訪れる
• その瞬間に戻ってくる
• プラグイン以外の要素:
  • WordPressを知っている数百万の開発者
  • ワンクリックインストールを提供するホスティング会社
  • 20年分のStack Overflowの回答
  • 非技術者が実際に理解できるメンタルモデル
  • 教育エコシステム（WP Mayor、WPBeginnerなどの数百のブログ、YouTubeチャンネル、コミュニティが無料でWordPressを教えている）
  • チュートリアル、レビュー、ガイドの深さが代替案には存在しない
  • 午前2時にサイトが壊れた理由を解明しようとする時ほぼ確実にどこかに答えが既に書かれている
• プラグインエコシステムがキラー機能である
• 非開発者がコードを書かずに真に複雑なサイトを構築できる
• WordPressを置き換えるにはすべてを複製する必要がある
• より良いCMSを構築するだけでなくその周りに完全なエコシステムを構築する必要がある
• それには10年と多くの運が必要である

■ 8. AIの影響

• プラグインエコシステムの利点はカスタム開発が高価で遅いために部分的に存在する
• プラグインとして存在しない機能が必要な場合は開発者に支払うか自分でコーディングを学ぶ必要がある
• その摩擦が既存のソリューションを持つプラットフォームに人々を押しやる
• AIがカスタム開発をより速くより安価にしている
• ClaudeやCursorのようなツールで開発者は数日かかっていた機能を数時間で構築できる
• 非開発者がAIアシスタンスで簡単なツールを自分で構築し始めている
• この傾向が続けば「プラグインを使うだけ」という利点は侵食される可能性がある
• WordPressが負けるとは限らない:
  • WordPressのオープンで拡張可能なアーキテクチャはAIがオンデマンドでカスタムプラグインを生成できる時にさらに価値が高まる可能性がある
  • より新しくクリーンなプラットフォームが不足機能を構築するコストが劇的に低下するためより実行可能になる可能性がある
• 境界線はすでに曖昧になっている
• 確立されたWordPressプラグイン（WP RSS Aggregatorなど）は既存の製品にAI機能を大幅に実装している
• 問題は「WordPressか他のものか」だけでなく「AIを備えたWordPress、カスタムAI駆動アプリ、またはまだ完全に定義されていないハイブリッド」になっている
• 著者はAgentVaniaを通じて中小企業のAIソリューション実装を積極的に支援している:
  • 最終的にスタンドアロンアプリになる可能性のあるカスタム統合
  • AIをコアに持つWordPressプラグイン
  • その他完全に異なるもの
• 今後10年間の技術選択を考える際に完全に予測できない方法で計算が変わる可能性があることを考慮する価値がある
• WordPressとAIの両方に近い位置にいることは合理的なヘッジである

■ 9. 用途別の推奨

• SaaSマーケティングサイト（ランディングページ、価格設定、ドキュメント）:
  • WordPressは機能するが過剰である
  • AstroまたはHugo等の静的ジェネレーターが理想的である（高速、安全、ホスティングが安価、開発チームが製品コードと一緒にGitで管理可能）
  • 多くのSaaS企業がこの方向に移行している
  • 非技術的なマーケティング担当者が定期的にコンテンツを編集する必要がある場合はWordPressまたはWebflowが適切である
• SaaSアプリケーション自体（顧客がログインする実際の製品）:
  • カスタムアプリケーション領域である
  • WordPressでもCMSでもない
  • Laravel、Next.js、Railsなどチームに合うもので構築する
  • ダッシュボード、ユーザー管理、コア機能はすべてカスタムコードである
• ブログ（個人または企業）:
  • WordPressが合理的なデフォルトである
  • 使いやすい
  • SEOプラグインエコシステム（Yoast、Rank Mathなど）が他の場所で複製するには大きな努力が必要な機能を提供する
  • 技術的でミニマルなものが必要な場合はAstroが適している
  • メンバーシップとニュースレターが組み込まれている場合はGhostが検討に値する（ただしホスティングはサブスクリプション価格に戻る）
• パンフレットサイト（5〜10ページの典型的な中小企業）:
  • クライアントが自分で編集する必要がある場合はWordPress
  • 真に静的でクライアントが触れない場合はCloudflare PagesまたはNetlifyにデプロイされた静的ジェネレーターがシンプルでホスティングコストがかからない
  • 継続的なメンテナンス責任を負いたくない場合はSquarespaceも良い
• アグリゲーターサイト（ディレクトリ、リスティング、求人掲示板、コンテンツキュレーション）:
  • WordPressのプラグインエコシステムが真に輝く場所である
  • カスタム投稿タイプ、Advanced Custom Fields、WP RSS Aggregatorのようなプラグインでゼロから構築せずに複雑なコンテンツ関係をモデル化し外部フィードを取り込むことができる
  • 新しいプラットフォームでそれを行おうとするとカスタムコードを書くか機能が単に存在しないことを発見する
  • プラグインが提供する以上の重いカスタム機能が必要な場合はLaravelがより良い基盤になるがすべてを自分で構築および維持することにコミットする
• ダッシュボードまたは内部管理パネル:
  • 決してWordPressではない
  • カスタムアプリケーション領域である
  • FilamentまたはLivewireを使用したLaravelが適している
  • APIと通信するReact/Vueフロントエンドも適している
  • ローコードアプローチが必要な場合はRetoolまたはBudibaseのようなツールが存在する
• eコマース:
  • 特定の理由（複雑なカスタマイズ要件、月額料金回避、Shopifyのモデルに合わないB2B使用例）がない限りShopify
  • WooCommerceは完全な制御が必要で継続的なメンテナンス負担を処理できる場合に実行可能である
  • WooCommerce拡張エコシステムは巨大である
  • これが他のWordPressベースのソリューションよりもShopifyに対して優位性を保っている理由の一部である
• メンバーシップまたはオンラインコースサイト:
  • LearnDash、MemberPress、Restrict Content ProなどのプラグインとWordPressが確立されたルートである
  • 代替案（Teachable、Kajabi、Thinkific）は適しているがサブスクリプションベースでプラットフォームにロックインされる
  • 所有権、柔軟性、他のプラグインで機能を拡張する能力が必要な場合はWordPressが勝つ
  • メンバーシッププラグインとWordPressエコシステムの残りの部分との統合によりすべてがサイロ化されることなくコースをWooCommerce、メールマーケティングプラグイン、アフィリエイト追跡などと組み合わせることができる
• フォーラムまたはコミュニティサイト:
  • BuddyPressまたはbbPressとWordPressは機能するが専用ソリューションと比較して不器用に感じる可能性がある
  • Discourseは伝統的なフォーラムに真に優れているが別のホスティングと管理が必要である
  • CircleやBBPressおよび同様のプラットフォームはサブスクリプションベースである
  • ほとんどの使用例ではプライベートSlack、Discord、TelegramグループがWPでの伝統的なフォーラムの必要性に取って代わった
  • フォーマットが流行遅れになった
• ポートフォリオサイト（写真家、デザイナー、作品を紹介するクリエイティブ）:
  • WordPressまたはSquarespaceの両方が適している
  • Squarespaceテンプレートはビジュアルポートフォリオ用に箱から出してより良くデザインされていることが多い
  • ポイント全体が美学である場合に重要である
  • 技術的な人の場合は優れたギャラリー設定を持つ静的サイトがよりクリーンで高速である
  • Instagram中心のポートフォリオの場合はSpotlightのようなプラグインで手動更新なしにフィードを美しく表示することが容易である
• ニュースまたはメディアサイト:
  • WordPressが支配的であり僅差ではない
  • 公開ワークフロー、編集役割、リビジョン履歴、スケジューリング、広告、分析、ペイウォール、ニュースレター統合用のプラグインエコシステムは一致させるのが難しい
  • ほとんどの主要なオンライン出版物はWordPressまたははるかに大きな予算で構築されたカスタムのものを実行している
  • 今日メディア会社を始める場合はWordPressを使用しない説得力のある理由が必要である
• 多言語サイト:
  • WPMLまたはPolylangとWordPress
  • プラグインエコシステムが明確な利点を持つ分野の1つである
  • 多言語コンテンツ管理は真に複雑である
  • これらの専用プラグインは予想もしないエッジケースを解決するために何年も費やしてきた
  • カスタムサイトに多言語サポートを構築するか成熟した多言語プラグインのないプラットフォームを使用することはこれらすべてのエッジケースを自分で再発見することを意味する
• ランディングページまたは単一キャンペーンページ:
  • CMSがまったく必要ない場合がある
  • Cloudflare PagesまたはNetlifyにデプロイされた単一のHTMLファイルまたはWebflowやCarrdで迅速に構築されたものが正しい答えであることが多い
  • AIツールが今や数分で完全なランディングページを生成できる
  • 結果は真に良好である
  • 3か月間実行されてからアーカイブされるワンページキャンペーンにはWordPressは過剰である
• パターンの出現:
  • 非技術者が編集するコンテンツ管理ウェブサイトが必要な場合特に基本的なコンテンツ管理を超える機能が必要な場合にWordPressが勝つ
  • プラグインエコシステムによりゼロから始めることはほとんどない
  • 独自の要件を持つアプリケーションを構築する場合はカスタムコードが勝つ
  • 開発者が管理しパフォーマンスが最重要である場合は静的ジェネレーターが勝つ
  • 消費者にオンラインで製品を販売する場合はShopifyが勝つ

■ 10. 著者の息子への選択

• 純粋主義者としては静的サイトジェネレーターを検討した:
  • 最初から本物のHTML、CSS、JavaScriptを教える
  • 抽象化なし管理パネルなしコードとテキストエディタだけ
  • 他のすべての基礎となる基礎を学ぶ
• しかしサッカーについて書いたり旅行の写真を共有したりしたい子供には現実的ではない
• アイデアからインターネット上での公開までの摩擦をできるだけ小さくする必要がある
• そうでなければ最初の投稿を公開する前に興奮が死ぬ
• ホスティングビルダー（Squarespace、Wixなど）も検討した:
  • 真に簡単である
  • しかしサブスクリプションサービスであり移転可能なものを何も教えない
  • それらを超えて成長した場合は最初からやり直す
  • 初日からコンテンツを所有してほしい
• より技術的なアプローチも検討に値する:
  • Localを使用してWordPressをローカルで実行し静的HTMLに変換しGitHub経由でCloudflare Pagesに公開する
  • 利点は年間10ドルのドメイン更新料を支払い続ける限り数十年後もブログが存在する
  • 継続的なホスティング料金なしサーバーメンテナンスなしセキュリティ更新なし
• AI生成も現在最速の方法である:
  • Claudeのアーティファクトのようなツールが数分で完全で洗練されたウェブサイトを生成できる
  • GitHubに保存しCloudflare PagesまたはNetlifyで公開して完了
  • 結果は正直素晴らしい
• 両方のアプローチへの躊躇:
  • あまり学ばない
  • Local-to-staticワークフローはエレガントだが不透明である
  • 何が起こっているか理解せずにボタンを押すことになる
  • AI生成サイトは自分で何かを構築するプロセス全体をスキップする
  • 正直な答えが「AIがこれを作り私はデプロイをクリックした」である場合「私がこれを作った」という魔法が失われる
• 著者はWordPressを選択した:
  • 完璧だからではなく若い初心者に適切なバランスを取っているから
  • すぐに書いて公開できる
  • 何か言いたいことがあることと公に言うことの間のギャップはわずか数クリックである
  • その即座の満足感は7歳の時に非常に重要である
  • 準備ができたら深さがある
  • 投稿を書くことから始めてテーマに興味を持ちその下のコードを覗くことができる
  • 天井は何年も超えないほど十分に高い
  • スキルが移転可能である
  • WordPressの仕組みを理解することはどこでも適用される概念（コンテンツ管理、データベース、ホスティング、ドメイン）を教える
  • 最終的に何か他のものに移行してもメンタルモデルは引き継がれる
  • 著者がそれを知っている
  • 行き詰まったときに助けることができトリックを見せることができなぜ物事がそのように機能するかを説明できる
  • 親が教えることができるものを学ぶことには技術的知識を超えた価値がある
• 20年後著者が学んだのと同じプラットフォームを教えている
• それはWordPressの持続力または代替案の欠如またはその両方について何かを語っている

■ 11. 結論と提言

• 開発者またはエージェンシーが移行を検討している場合の正直な答えは移行先がまだ存在しないということである
• WordPressガバナンスについて不安がある場合（合理的である）の実用的な対応はスキルを移植可能に保つことである:
  • モダンなPHPとJavaScriptを学ぶ
  • WordPress固有の実装だけでなく原則を理解する
  • 何かが最終的に出現した場合に準備ができている
• 今日新しいサイトを構築し非技術者が使用できる管理パネルを持つCMSが必要な場合はWordPressが依然として答えである
• もっとエキサイティングなことを伝えたいができない
• 市場のギャップは現実である
• WordPressレベルの使いやすさと成長するエコシステムを持つモダンなオープンソースCMSは真に価値がある
• しかし誰もまだそれを構築していない
• それが機会かもしれない

MEMO:

• 7歳の息子が初めてWEBサイトを作りたい → よし、WPだ！ はちょっと意味がわからない
• 素直にHTML + CSSを手書きで書かせてアップロードだけ手伝ってやればいいような
• 子供は時間なんて幾らでもあるんだし、ローカルで弄り回せた方がいいだろうに
• AIに手伝ってもらうなら尚更ローカルで触れた方がよいような
• クライアントワークでサクッと納品したいとかならまだ理解できるのだが

(2026/01/26)

AIエージェントにお金を払えば、誰でもゲームを作れてしまうという衝撃の事実　開発者の仕事はどうなる？

• ASCII.jp：AIエージェントにお金を払えば、誰でもゲームを作れてしまうという衝撃の事実　開発者の仕事はどうなる？ (1/5)

(2026/01/26)

まつもとゆきひろが危惧する、ジュニア不要論の先に広がるIT業界「焼け野原」：「コードを書かない」未来...

• まつもとゆきひろが危惧する、ジュニア不要論の先に広がるIT業界「焼け野原」：「コードを書かない」未来、エンジニアは何者になるのか（1/2 ページ） - ＠IT

(2026/01/26)

ソフトウェア開発で「なぜなぜ分析」はアンチパターン

• ソフトウェア開発で「なぜなぜ分析」はアンチパターン - 勘と経験と読経

要約:

■ 1. なぜなぜ分析がソフトウェア開発に不適切な理由

• なぜなぜ分析（根本原因分析・RCA・5 Why手法）はソフトウェア開発においてアンチパターンである
• ソフトウェアは平均的に複雑系である
• 複雑系は複雑な方法で故障する
• インシデントや問題に対する単一の因果関係を持つ単一の根本原因はそもそも存在しない
• なぜなぜ分析は単一な根本原因に焦点を当てるために過度または誤った抽象化を行いやすい
• 適用すべきではないというより有害である
• なぜなぜ分析はその特性上人的ミスに帰結しやすい点も問題である
• 超シンプルで小さなソフトウェアには有効かもしれないが現代ではそのようなソフトウェアは存在しない

■ 2. なぜなぜ分析がなくならない理由

• 会社のルールだから:
  • 古い会社のルールを見直さず放置している
• 偉い人が言うから:
  • 偉い人が学習を怠り過去の自分の成功体験を繰り返している
• 他の方法を勉強していない
• なぜなぜ分析の結果は対外的に説明しやすい:
  • シンプルな因果関係やストーリーはわかりやすい
  • しかし選択したシンプルな因果関係やストーリーはすぐに破綻する
  • また別の理由で次のインシデントが発生する
  • 再発防止策がさらに増える
  • チェックリストが拡充される
  • 無駄な作業ばかりが増え生産性は落ちていく

■ 3. なぜなぜ分析のダメな例（SREをはじめようより）

• システムダウンの事例:
  • システムがダウンした
  • →サーバーが停止した
  • →ディスクがいっぱいになった
  • →ログが肥大した
  • →ログローテしてなかった
  • →設定ファイルが漏れていた（根本原因）→すべての設定ファイルにログローテーションの設定があることを確認という分析
• 問題点:
  • 観察した1つの事柄を深く掘り下げる際に他の要因を無視している
  • なぜを繰り返す前に何が起こったのかの質問にすべて答える必要がある
  • 単一の根本原因に焦点を当てることが失敗から学ぶ上で不利になる
  • 明確な因果の連鎖を1つ特定できたと思った時点でインシデントを深く観察することをやめてしまう

■ 4. 根本原因という正解の不在

• インシデントの原因は無数にある
• 複合要因をちゃんと分析すべきである
• 根本原因という用語はすべての背後に1つの真の原因があるように見えてしまう点でダメである
• 現代は唯一解のない正解がいくつもある時代である
• 問題を分析しその問題の正解を外から持ってくるという思考法だけでは通用しない
• 少し前の教育を受けていた世代は優等生主義や正解主義のきらいがある

MEMO:

• なぜなぜ分析は線形な分析になるので本質的な問題が抜け落ちがちという話はある
• なのでシステム思考でシステム（系）全体の把握をするのだという事になるのだが、システム思考はかなり面倒
• システム思考までやっている時間・気力は無いので、とりあえずなぜなぜ分析でお茶を濁すという場面のあるのではなかろうか

(2026/01/25)

複雑な要件を1クエリで完結させる、PostgreSQL活用術

• 複雑な要件を1クエリで完結させる、PostgreSQL活用術 - SmartHR Tech Blog

要約:

■ 1. 記事の概要

• SmartHRのプロダクトエンジニアが実装した巨大なSQLにおいて活用したPostgreSQLの機能を紹介
• 一般的な構文の影に隠れがちだが非常に助けになった機能をピックアップ
• ORMだけでは解決できない課題やパフォーマンスチューニングをする際の一助となることを目的とする

■ 2. 複雑なクエリを保守しやすくするための基本

• WITH句とウィンドウ関数の知識:
  • CTEとウィンドウ関数は現代的なSQLを書く上で必須
  • SQLの自由度は理解度で劇的に変わる
• WITH句CTE:
  • SQL内で一時的なテーブルに名前をつけて定義できる機能
  • 古いスタイルのSQLではサブクエリをネストして書くことが一般的だったがネストが深くなると内側から外側へ読み解く必要があり脳のメモリを消費する
  • WITH句を使うと処理を上から下へ流れるように記述できる
  • アプリケーションコードでいう変数や関数に切り出して名前をつける感覚に近い
  • ロジックをステップごとに分解して記述できる
• ウィンドウ関数:
  • SUMやRANKなどの関数にOVER句を組み合わせることで実現する機能の総称
  • 通常のGROUP BYとともに集約関数を使うと行がグループごとに1行に圧縮される
  • 個別の明細行は残したいが全体の集計値も横に添えたい場合にウィンドウ関数を使用
  • OVER句が出てきたらその手前にある関数がウィンドウ関数というグループに属していると理解すればよい
  • 明細行を残したまま集計結果をすべての行に持たせることができる
  • SUMは通常は集約関数だがOVERをつけるとウィンドウ関数として振る舞う
  • DENSE_RANKなどウィンドウ関数としてのみ振る舞う関数も存在
  • 行を集約しない特性がアプリケーションが必要とする複雑なデータ構造を1回のクエリで作る上で非常に重要

■ 3. 任意のIDリスト順にソートする方法

• unnest関数とARRAYとWITH ORDINALITYとCTEのWITH句を組み合わせて使用
• WITH ORDINALITYのWITHはCTEのWITH句とは全く別物
• すでにあるIDのリスト順の通りに検索結果を返したい要件が発生することがある
• WHERE id INのように検索すると返却されるレコードの順序はバラバラになる
• リストが並び替えでしか使われていない場合はarray_position関数を使う選択肢がある:
  • array_positionは並び替え済みの値の配列と今の行の値という形式でその値が配列の何番目にあるかを返す関数
  • ORDER BYを書くことが可能
  • シンプルだがクエリの複数箇所でそのIDリストを使いたい場合は共通化した方が良い
• IDリストが数百から数千件と長大な場合:
  • 配列リテラルをクエリのあちこちに埋め込むとSQL全体のサイズが肥大化
  • 人間にとって読みにくいだけでなくDBのパーサーに無駄な負荷をかけ通信量も増大
  • パフォーマンスの観点でも好ましくない
• unnest関数とARRAYとWITH ORDINALITYを使うとCTEのWITHと組み合わせて記述可能:
  • 長大なリストの登場は一回だけで済む
  • 長いリストはCTEで一度だけ定義しテーブルとして使い回す
• WITH ORDINALITYを使うと元のデータの横に連番が自動的に付与される
• AS t関数とカラム名でテーブルの別名とカラムの別名を同時に定義する構文を使用

■ 4. JOINで増えた行へマークするDENSE_RANK

• ランキング関数は売上ランキングのような用途が真っ先に思い浮かぶが実務特に履歴管理を含む複雑なデータを扱う場面では違った用途で活躍
• 1対多の1:NのJOINを含む履歴データから最新の1件N行すべてを取得したいケースで使用
• DENSE_RANKは同率順位があった場合番号を飛ばさずに詰めて採番
• 評価完了日が同じであればJOINによって行が増えていてもそれらは全て同率1位として扱われる
• 自分で名付けたrank_numで絞り込みをすれば各社員の最新のプロジェクトを取得可能
• 絞り込みはウィンドウ関数と同じ階層ではWHEREに書けず別のCTEなどで書かなくてはいけない
• DENSE_RANKに類似した関数としてROW_NUMBERやRANKがあるがいずれも採番のルールが違うため今回のケースでは適さない

■ 5. BOOL_ORウィンドウ関数

• グループ内のデータ全体を見渡してどれか一つでも条件を満たせばフラグを立てたい場合やどれか一つでも条件を満たしているグループのみ絞り込みたいケースでよく使用
• PostgreSQLならBOOL_ORをウィンドウ関数として使うことで自然言語に近い形で記述可能
• BOOL_OR論理和という名前の通りパーティション内のどれか一つでもtrueであれば結果はtrueになる
• グループ内のすべてがtrueのときだけtrueを返したい場合はBOOL_AND標準SQLだとEVERYが使用可能

■ 6. ウィンドウ関数に空のOVER関数を使って全体集計

• 通常ウィンドウ関数といえばPARTITION BYで区切って使うものだが何も指定しないことで実現できる便利な挙動がある
• 空のOVER関数とその使い道:
  • Webアプリケーションで一覧画面を作る際に必ずと言っていいほど実装するのがページネーション
  • 現在のページの20件と全ヒット件数1530件などの両方が必要
  • 通常これを実装するには2回のクエリを発行するのが定石
  • ウィンドウ関数を使えば1回のクエリで完結可能
  • OVERの中にPARTITION BYを書かずに空っぽにすると検索結果全体を一つの大きなグループとして扱える
• パフォーマンス上の注意点:
  • クエリの回数を減らせるというメリットがあるが常に最適解とは限らず最適解となることは少ない
  • 単純なCOUNTであればインデックススキャンのみで高速に完了するケースでもウィンドウ関数COUNT OVERを使うとテーブル本体へのアクセスが必要になりパフォーマンスが落ちる可能性
  • インデックスが効く単純な検索の場合はクエリを2回に分けたほうが速い場合が多い
  • 複雑な検索でフルスキャンが避けられない場合は1回で済ませるこのテクニックが有効なことがある
  • COUNT OVERはJOINで膨れ上がった重複レコードもすべてカウントしてしまう
  • JOINで生まれた重複を除いた純粋な母数が知りたい場合には次に紹介する方法が有効
• ページネーション用にDENSE_RANKの値を使っていたときついでにJOINで膨れる前の件数を出す応用:
  • ページネーションの判断基準を作るために既にDENSE_RANKの数値を利用していた場合その数値から全体の件数も出す
  • 1人のユーザーが複数の行履歴を持っているデータにおいて全行数ではなく全ユーザー数をベースに1ページあたり10ユーザーのページネーションを実装したい場合
  • 単にCOUNT OVERをすると行数分が返ってきてしまう
  • LIMIT 10をかけると10行おそらくユーザーが重複し10ユーザー未満の数しか含まれないしか取れない
  • DENSE_RANKで振った番号を活用しMAXを使うことでJOIN済みの結果セットが返ってくる状態でも実質のページネーションとともにその母数がいくつかを導出可能
  • COUNT DISTINCT user_id OVERでも全ユーザー数は出せるがページネーションの絞り込み用として既にDENSE_RANKを計算していたためその計算結果を再利用するほうがクエリとして無駄がないと判断

■ 7. JOIN済みの結果をJSONにするjsonb_agg

• やむをえずアプリケーション層でほぼ生SQLを書く時にあるあるなのが1対多のテーブルをJOINしてデータを取得した結果行の増幅が発生してアプリ側での再整形が必要になること
• アプリケーション層で必要になる処理:
  • DBから大量の行を取得
  • forやeachでループを回す
  • 1つ前のIDと今のIDをチェックし値が違ったら新しいユーザーオブジェクトを作る
  • 値が同じならタグ配列に値をpushする
• IDが変わったかチェックして何かしらを行う処理はコードが複雑になりがち
• 素朴な一対多が一つだけあるならまだ大丈夫だが二重三重に一対多の関係がありJOINされたレコードを頭に入れて再構築するのは大変
• アプリケーションサーバーよりもDBサーバーの方がスケールしにくいためこの手法を嫌う人もいるがDB側でJSONに集約してから値を返してもらうのも一つの手
• json型とjsonb型:
  • PostgreSQLにはJSONを扱うためのデータ型としてjson型とjsonb型の2種類が存在
  • json型は入力されたテキストをそのまま文字列として扱う型で書き込みは速いが検索や加工のたびに構文解析が必要なため参照は遅い
  • jsonb型は入力されたテキストをバイナリ形式に分解変換した型でjsonbのbはbinaryのb
  • jsonb型は書き込みは少し遅いが参照や検索が非常に高速でカラムとして追加する場合はインデックスGINを貼ることも可能
  • json型を使うのはレアなケースで基本的にはjsonb型を使うと覚えておけば大丈夫
• jsonb_agg集約関数で行を配列に畳み込む:
  • 増幅された行を畳み込むのにはjsonb_aggを利用
  • GROUP BYで集約された複数の行を一つのjsonb型の配列の値に変換する集約関数
  • 集約関数内のORDER BYが重要なテクニック
  • これを書かないと生成されるjsonb型の配列の値の中身の順序はランダムになる
  • 配列内の順序を保証したい場合関数の中でソート指定を行う必要がある
  • アプリケーション側でIDが変わったかどうかを判定するループ処理を書く必要はなくなる
  • DBから返ってきたJSONをそのまま利用するだけになりロジックが劇的にシンプルになる
  • jsonb_aggは集約結果をすべてメモリ上で構築してから返却するため数万から数十万行といった大量データを1つの値にまとめようとするとDBサーバーのメモリを急激に圧迫する恐れがある
• jsonb_build_arrayでjsonbの配列を作る:
  • jsonb_aggが複数行をまとめてjsonb型の配列の値にするのに対しjsonb_build_arrayは指定したカラムや値をその場でjsonb型の配列の値にする関数
  • 型合わせのために利用
  • ある配列jsonb型と別のID単一の数値をUNION ALLで結合したかったが型が違うとエラーになる
  • 単一のIDもjsonb_build_arrayで配列に変換することで強引に型を揃えてUNION ALLした
  • データの形式を揃えたい時などに利用可能
• 生成したjsonb型の値に対する検索:
  • 生成したjsonb型の値に対して後から検索をかけることも可能
  • PostgreSQLのjsonb型は非常に優秀で包含演算子などを使用することで生成後の値に対しても検索可能
  • パフォーマンスには注意が必要
  • UNIONされた結果やCTEで動的に生成されたJSONデータに対してはインデックスを効かせることができない
  • すでに対象件数が十分絞り込まれているコンテキストだったため許容したが大量データに対して無邪気にインデックスの効かない検索処理を行うと事故につながるリスクがある

■ 8. おわりに

• 紹介したテクニックはすべて実際のプロダクト開発におけるとある1つの巨大クエリに詰め込まれたエッセンス
• 無闇に複雑で巨大なSQLを書くことが正義ではない
• ミッションクリティカルな機能や多くの人が頻繁に触れる箇所であれば要件の再検討テーブルの非正規化アプリ側での処理分割などを選んでいた
• プロダクトの開発背景パフォーマンス要件開発速度それらを天秤にかけあえてDB側で完結させることが最適解となる瞬間は存在
• PostgreSQLには強力な機能が備わっていることを知っていただければ幸い
• 最終的に9つのCTEが連なることとなった

(2026/01/24)

Stop using MySQL in 2026, it is not true open source

• Stop using MySQL in 2026, it is not true open source

要約:

■ 1. MySQLのオープンソース性の問題

• 2026年においてMySQLを使用している場合はMariaDBへの移行を検討すべき
• github.com/mysql/mysql-serverへのgitコミット数が2025年に大幅に減少
• MySQLはライセンス上はオープンソースだがプロジェクトとしてはオープンソースではない

■ 2. Oracleによる管理の問題点

• 2009年にOracleがSun MicrosystemsとともにMySQLを買収
• 欧州委員会は競争を抑制する目的があると懸念し買収を阻止しようとした
• OracleはMySQLを維持する約束をしたが良いオープンソースプロジェクトの管理者ではなかった
• コミュニティは長年にわたり衰退
• 開発の問題点:
  • すべての開発は非公開で行われる
  • 公開されているバグトラッカーはOracle担当者が実際にMySQL開発に使用している本物ではない
  • MySQLへの貢献を試みる人々のプルリクエストやパッチ提出は受領としてマークされるがフィードバックはほとんどない
  • 変更が次のMySQLリリースに含まれるかどうかは不明で多くの場合書き直される
  • gitのauthor/committerフィールドにはOracle担当者のみが記載される
  • 実際の著者はブログ投稿で小さく言及されるのみ
• Amazon Web ServicesのRDS MySQLとRDS MariaDBのコアチームのエンジニアリングマネージャーだった際にエンジニアの両方への貢献を監督したがOracleによる貢献の受け入れが悪いためMySQL側への提出を嫌がった

■ 3. MariaDBとの比較

• MariaDBはMySQLの元の作者Michael Wideniusによるフォーク
• すべての開発がgithub.com/mariadb/serverでリアルタイムに行われる
• 誰でもプルリクエストを提出しレビューを受けることができる
• すべてのバグがjira.mariadb.orgで公開討論される
• 真のオープンソースプロジェクトに期待される通りの運営

■ 4. MySQLの技術的衰退

• Oracleは買収後10年以上にわたりMySQL組織を存続させ比較的独立して新バージョンを開発リリースすることを許可した
• MySQL事業は財務的に有用だったと推測されるが少なくともOracleの主要データベース事業を脅かすほど多くの機能を獲得しない限り
• 2022年以降技術的観点から明らかに劣化し始めた
• MySQL 8.0.29の問題:
  • デフォルトのALTER TABLEメソッドがin-placeに切り替えられた
  • 多くのコーナーケースが機能せずデータベースがクラッシュしデータが破損
  • 問題は1年後のMySQL 8.0.32まで完全には修正されなかった
  • Oracleが8.0シリーズをevergreenと発表しマイナーリリースで機能と変更を導入した
  • ユーザーは歴史的にx.y.Zメンテナンスリリースからバグ修正とセキュリティ修正のみを期待していたため不満
• 新しいメジャーバージョンのリリースが6年間なかった:
  • 2018年のMySQL 8.0の後2023年にMySQL 8.1がリリースされたが短期プレビューリリースのみ
  • 最初の実際の新しいメジャーリリースMySQL 8.4 LTSは2024年にリリース
  • 新しいメジャーリリースにもかかわらずほとんど新機能がなく多くのユーザーが失望
• パフォーマンスの低下:
  • 新しいMySQLバージョンでパフォーマンスが低下したという報告が多数
  • MySQL性能専門家Mark Callaghanのベンチマークによると書き込み重視のワークロードでMySQL 9.5のスループットは通常8.0より15%少ない
• アップグレードの問題:
  • 新しいMySQLバージョンが多くの機能を非推奨にしたため多くのユーザーがMySQL 5.7から8.0および8.0から8.4へのアップグレードで大きな苦労を報告
  • 新機能がほとんどなくコードベースのクリーンアップと機能の非推奨に重点が置かれたためOracleがMySQLをかろうじて生かしておくだけと決定したことが明らかになった
  • すべての新しい関連機能はOracleのクローズドソースでクラウド専用のMySQL顧客向けサービスHeatwaveに投入
• OracleがMySQLに投資していないことが明らかになりPerconaのPeter Zaitsevが2024年6月にIs Oracle Finally Killing MySQLと執筆
• DB-Enginesによるランク付けでMySQLの人気が急落し始め2026年にはその傾向が加速する可能性
• 2025年9月にOracleが労働力を削減しMySQL担当者が大幅に削減されたとニュースで報道
• MySQLの将来に良い兆候ではなくPeter Zaitsevが11月に最新のMySQLメンテナンスリリースに含まれるバグ修正が以前より少ないことを示す統計を投稿

■ 5. オープンソースの重要性

• オープンソースはイデオロギー以上のものでありソフトウェアのセキュリティと主権に実際の影響を与える
• MySQLが真にオープンソースであるかどうか気にしない人や今後数年間の将来があるかどうか気にしない人がいるが大きなリスクを取っている
• データベースはソフトウェアアプリケーションスタックの最も重要な部分であり運用上の欠陥や問題特にセキュリティ問題は即座に結果をもたらす
• オープンソースでは問題が公開討論され問題が大きいほど多くの人々や企業が修正に貢献する
• オープンソース開発手法は科学的方法に似ており自由なアイデアの流れが常に争われ最も説得力のある証拠を持つものだけが勝つ
• オープンではないことはより多くの不透明性より多くのリスクより多くの信頼してくれという態度を意味する

■ 6. セキュリティ問題の取り扱い

• 2025年だけでMySQLは123件のセキュリティ問題に関するCVEを公開しMariaDBは8件
• 2025年にMySQLのみに影響しMariaDBには影響しなかったCVEは117件
• CVEにはほとんど実際の詳細が含まれていない
• 最新のCVE-2025-53067の例:
  • 容易に悪用可能な脆弱性により高権限の攻撃者が複数のプロトコルを介したネットワークアクセスでMySQL Serverを侵害できると記載
  • セキュリティ研究者や監査人が元の問題が実際に存在したか修正されたか修正が十分で問題を完全に軽減したかどうかを検証するために使用できる情報がない
  • MySQLユーザーはOracleの言葉を信じるしかない
• このようなセキュリティ問題の取り扱いは他のオープンソースプロジェクトとは対照的
• 他のオープンソースプロジェクトでは最初のエンバーゴが終了しCVEが公開された後すべてのセキュリティ問題とそのコード修正が完全な精査のために公開される

■ 7. エンシッティフィケーション

• 真のオープンソースプロジェクトでは見られない様々な形態のエンシッティフィケーションが進行中
• MySQLのソフトウェアドキュメントウェブサイトのすべてがユーザーにオープンソース版の使用を停止しクローズドMySQLバージョン特にHeatwaveへの移行を促している
• Heatwaveはクローズドソースであるだけでなく顧客のデータベースコンテンツをOracleが完全に管理する結果となる
• Redditなどでの話によるとOracleは残りのMySQL顧客から搾り取っており顧客はますます少ないものに対してますます多く支払うことを余儀なくされている

■ 8. 移行の選択肢

• MySQLユーザーの大部分は2010年代半ばに既にMariaDBに切り替えた
• データベースソフトウェアが真にオープンソースであり続けることを深く気にかけた人々が含まれる
• 大規模インストールの例:
  • Wikipedia
  • FedoraやDebianなどのLinuxディストリビューション
• オープンソースであり統計を収集する中央集権的な機械がないため正確な市場シェアは不明
• アプリケーション固有の統計:
  • 世界中のWordPressサイトの57%がMariaDBを実行
  • MySQLのシェアは42%

■ 9. 移行方法

• WordPressDrupalMediawikiNextcloudMagentoなどの古典的なLAMPスタックアプリケーションを実行している場合:
  • 古いMySQLデータベースをMariaDBに切り替えるのは簡単
  • MariaDBはMySQLのフォークでありほとんど後方互換性がある
  • MySQLをMariaDBに交換しても既存のコネクタやデータベースクライアントを変更する必要がない
  • それらはMariaDBがMySQLであるかのように動作し続ける
• カスタムアプリケーションを実行しデータベースの使用方法と内容を変更する自由がある場合:
  • 成熟した十分に機能するオープンソースデータベースが数十ある
  • PostgreSQLが最も人気のある一般的なデータベース
  • アプリケーションが最初からMySQL用に構築されている場合PostgreSQLへの切り替えには多くの作業が必要な可能性
  • MySQL/MariaDBアーキテクチャとストレージエンジンInnoDBは高性能スケーラビリティ堅実なレプリケーション機能が最優先であるオンラインサービスなどで優位性を提供する可能性
  • 迅速で簡単な移行にはMariaDBがおそらく最良の選択肢
• Percona Serverへの切り替えも非常に簡単:
  • MySQLのすべての変更を密接に追跡しPerconaによる少数の改善によってのみ逸脱
  • 基本的にMySQLサーバーのカスタマイズバージョンであるためOracleへの依存を完全に捨てようとする人々にとっては長期的に実行可能なソリューションではない
• MySQLと共通の祖先を持たないがMySQL互換を目指すオープンソースデータベースも複数存在:
  • MySQL用に構築されたほとんどのアプリはSQL文を書き直す必要なく単純に切り替え可能
  • TiDBの例:
  • 非常にスケーラブルで大規模なシステム専用にゼロから設計
    • Amazonの最新データベースソリューションDSQLはTiDBから多くのアイデアを借りて構築されるほど優れている
    • TiDBは大規模な分散セットアップで真価を発揮するため現在MySQLを使用している大多数の通常の小中規模アプリケーションにとって最も実用的なソリューションはMariaDBへの切り替え
    • ほとんどのLinuxディストリビューションでapt/dnf/brew install mariadb-serverを実行するだけでインストール可能
• Oracle以外を選択すれば何を選んでもより良い状況になる

(2026/01/23)

Node.js作者の発言「人間がコードを書く時代は終わった」について思うこと

• Node.js作者の発言「人間がコードを書く時代は終わった」について思うこと | maguro​.dev

要約:

■ 1. Ryan Dahlの発言と背景

• 2026年1月20日にNode.js作者Ryan Dahlが「人間がコードを書く時代は終わった」とXに投稿
• ソフトウェアエンジニアの仕事がなくなるという意味ではなくプログラムのシンタックスを直接書くことがエンジニアの仕事ではなくなったという主張
• Ryan DahlはDeno Land Inc.の共同創業者でありNode.jsに代わる新しいJavaScript/TypeScriptランタイムDenoを開発中
• 投稿は24時間で約300万ビュー2300以上のリポスト11000以上のいいねを獲得

■ 2. 筆者の働き方の変化

• 数ヶ月前まで:
  • 自分がコードを書きAIはたまに相談する相手
• 現在:
  • AIが運転席に座り自分は助手席でナビゲーションする感覚
  • AIは「分身」に近い存在として機能
  • 適切な頼み方で十分なコンテキストを与えることで疲労知らずで作業を実行
  • 時間をかけてもたどり着けなさそうなバグの原因を一撃で発見することもある
• Opus 4.5の登場が転機となり頼れる相棒分身となった

■ 3. プログラミングのシンタックスを書く必要性の減少

• AIがコードを書くため自分でコードを打ち込む機会が明らかに減少
• 実装プロセス:
  • 実装したい機能や修正したいバグについてプランを練らせる
  • レビューする
  • 実装する
  • レビューする
• 同僚の書いたコードをレビューする程度の感覚で信頼できるレベルに到達

■ 4. ソフトウェアエンジニアの役割の変化

• 比重が下がった要素:
  • コードを書く部分
• 比重が強まった要素:
  • あるべきアーキテクチャの指針を決める
  • コードベースからは読み取れないコンテキストを整理し与える
  • 期待する挙動を自動的継続的に検証できる枠組みを整える

■ 5. 現在のプログラミングスタイル

• ある機能を実装したい場合の初手で自分からコードを書くことはほぼなくなった
• 作業フロー:
  • まずAIにやってもらう
  • 自分で手直ししたほうが速いと思ったらエディタを開いて自分で直す
  • 変更量が多そうだったらAIにまたお願いして直してもらう
• エディタを開いて自分で直す作業もAIにお願いすることに置き換え可能
• 置き換えた場合人間はもはやコードを書いていないことになる

■ 6. 筆者の認識の変化

• 半年前なら反発したかもしれない発言だが現在の働き方を照らし合わせるとその通りだと認識
• 頭の中にある漠然としたアイデアを信頼できて疲れ知らずの相棒と相談して形にできる状況を楽しんでいる
• 本記事もAIに書いてもらったドラフトを修正加筆して完成

(2026/01/23)

Microsoft CEO warns that we must 'do something useful' with AI or they'll lose...

• Microsoft CEO warns that we must 'do something useful' with AI or they'll lose 'social permission' to burn electricity on it | PC Gamer

要約:

■ 1. Nadella CEOの基本的主張

• 世界経済フォーラムでMicrosoft CEOサティア・ナデラがAIの社会的許可について警告
• AIが人々やコミュニティや国や産業の成果を変える有用なことに使われなければ公共の支持を失うと発言
• エネルギーは希少資源であり健康や教育や公共部門の効率や民間部門の競争力を改善しなければトークン生成にエネルギーを使う社会的許可を失うと指摘

■ 2. 供給側と需要側の課題

• 供給側の課題:
  • AI企業と政策立案者はエネルギーとトークンの遍在的グリッドを構築する必要がある
  • この作業が現在RAM価格の高騰を引き起こしている
• 需要側の課題:
  • 全ての企業がAIを使い始める必要がある
  • ナデラはAIを「認知増幅器」や「無限の知性へのアクセス」と表現
  • 求職者はExcelのスキル習得と同様にAIスキルを習得する必要がある
  • 人々がAIスキルを習得することで実体経済における製品やサービスの提供者として向上すべき

■ 3. 具体例と医療分野での応用

• 医師が患者との時間を増やせる例:
  • AIが文字起こしを実行
  • 電子医療記録システムへの記録入力を担当
  • 適切な請求コードを入力し医療業界全体（支払者と提供者と患者）により良いサービスを提供
• 医療専門家による研究ではAIスクライブ使用で「多大な利益」が報告されているがさらなる研究が必要

■ 4. 懸念と批判的視点

• AIによる盗聴の懸念:
  • 予防的ケア訪問をより高価な診断訪問に再分類する理由を探すAI盗聴者の存在
  • 米国医療システムの再設計の必要性
• LLMの限定的な応用:
  • 汎用LLMがパソコンやインターネットと同程度に革命的であると期待する場合多くのアプリケーションが音声文字起こしやテキスト要約やコードスニペット取得に集約されることは懸念材料
• LLMのエラー傾向:
  • 英国警察署長がMicrosoft Copilotのエラーで辞任
  • これらの機能を中心に社会を再編成するという考えに懐疑的な理由が存在
• MIT Media Lab研究者による報告:
  • 数十億ドルの投資にもかかわらず組織の95%がAI採用からゼロリターンを得ている

■ 5. バブル論への反論と将来展望

• ナデラのバブル論への見解:
  • テクノロジー企業のパートナーシップとインフラ支出だけならバブル
  • AIが生産性曲線を曲げ資本支出だけでなく世界中で経済成長をもたらすと確信
• 筆者の皮肉的コメント:
  • RAM価格が正常化する時期を知りたいという指摘

(2026/01/22)

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

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

要約:

■ 1. プロジェクト概要

• astroz は最速の汎用SGP4実装でネイティブZigで1秒あたり1100万〜1300万回の伝播計算を実現
• Python経由では約700万回毎秒でpip install astrozのみで利用可能
• GPUを使用せずCPUのSIMD命令のみで高速化を達成
• 汎用実装の定義:
  • heyoka.pyは複数衛星の同時バッチ処理で高速だが一般的なODE積分器でLLVMのJITコンパイルとC++依存関係が必要
  • astrozは時間バッチ伝播で2倍高速で単一衛星の複数時刻計算に特化
  • GPU加速SGP4実装は大規模バッチワークロードで高速だがCUDA/OpenCLセットアップが必要で汎用的ではない

■ 2. SGP4最適化の動機

• SGP4は1980年代からTLEデータから衛星位置を予測する標準アルゴリズム
• 既存実装は元のリファレンスコードの移植版で機能するが高密度時間解像度では遅い
• 実用的な課題:
  • 1ヶ月のエフェメリスデータを1秒間隔で生成すると衛星1個あたり260万回の伝播計算が必要
  • 地上局ネットワークでの通過予測は数週間にわたりサブ秒精度が必要
  • 接近スクリーニングの軌道解析は近接アプローチを捕捉するため細かい時間ステップが必要
• 典型的な良い実装で200万〜300万回毎秒だと衛星1個あたり数秒かかり反復解析やインタラクティブツール構築では遅い

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

• SIMD導入前のスカラー実装で既にRust sgp4クレート（最速のオープンソース実装）と同等以上の性能
• 主要な設計選択:
  • 分岐のないホットパス:
    • SGP4アルゴリズムには多数の条件分岐が存在
    • 深宇宙対近地球や異なる摂動モデルやケプラーソルバーの収束チェックなど
    • 可能な限り分岐なし表現として記述
    • 当初はパフォーマンス目的ではなくコードの理解しやすさのため
    • 偶然にも現代CPUが予測可能な命令ストリームを好むため高速化
  • コンパイル時事前計算:
    • Zigのcomptimeで任意のコードをコンパイル時に実行可能
    • SGP4のセットアップ作業の多く（重力定数や多項式係数や派生パラメータ）を一度計算してバイナリに焼き込む
    • ランタイム初期化や繰り返し計算が不要
    • constでマークした変数は自動的にcomptimeとして扱われる
• スカラー実装で520万回毎秒を達成しRustの500万回毎秒を若干上回る

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

• SGP4は状態に依存せず各衛星と各時点が独立しているためSIMDに適している
• ZigがSIMDを第一級市民として扱う設計:
  • シンプルな型宣言のみで開始可能
  • const Vec4 = @Vector(4, f64)で4つの64ビット浮動小数点数のベクトルを定義
  • イントリンシクスやプラットフォーム検出や条件付きコンパイルが不要
  • LLVMバックエンドがコード実行環境に適した命令セットを自動的にターゲット
• 組み込み演算:
  • スカラーを全レーンにブロードキャストする@splat
  • LLVMイントリンシクスを通じた自動ベクトル化された超越関数
  • @sinと@cosはLinux x86_64でのlibmvecなどプラットフォーム最適実装を使用
• レーン単位の思考への転換:
  • スカラーコードではif文で一方のパスを実行
  • SIMDでは全4レーンが同時に実行されるため両方の結果を計算してレーン毎に選択
  • 両方のパスを計算することは無駄に見えるが分岐予測ミスより高速な場合が多い
  • SGP4では大半の衛星が同じパスを取るため無駄な計算は少ない
• 収束ループの処理:
  • SGP4のケプラーソルバーは各結果が収束するまで反復
  • スカラーでは許容誤差以下になるまでループ
  • SIMDでは異なるレーンが異なる速度で収束
  • 解決策はレーン毎に収束をマスクで追跡し@reduceで全員完了を確認
• パターン理解後はスカラー実装を一行ずつ変換し元のコードをテストスイートで比較できるよう保持

■ 5. 3つの伝播モード

• 時間バッチ propagateV4:
  • 最も一般的なワークロードに対応
  • 単一衛星の複数時点を同時に4時点処理
  • エフェメリスデータ生成や通過予測や軌道解析や接近スクリーニングに使用
  • 衛星の軌道要素がレジスタに留まり4つの出力を計算するため最もキャッシュフレンドリー
  • 最大の初期高速化を実現
• 衛星バッチ propagateSatellitesV4:
  • 多数の衛星を1つの特定時点で処理
  • 衝突スクリーニングスナップショットやカタログ全体の可視性チェックに使用
  • 4つの異なる衛星を同一時点で同時処理
  • ElementsV4という異なるデータレイアウトが必要
  • 各フィールドがVec4で4つの異なる衛星の値を保持
• コンステレーションモード propagateConstellationV4:
  • 多数の衛星を多数の時点で伝播
  • ライブデモでは13000個の衛星を1440時点で処理
  • キャッシュを意識したタイリング戦略:
    • 各衛星の全時点を計算する素朴なアプローチはキャッシュをスラッシング
    • 64時点を全衛星で処理してから次の64時点を処理
    • 時間値がL1キャッシュにホットな状態で衛星バッチをスイープ
    • タイルサイズ64はL1サイズを作業データサイズで割りSIMDフレンドリーな数に丸めたもの
  • 大規模カタログでは素朴なループより15〜20%高速

■ 6. atan2問題と解決策

• SGP4のケプラーソルバーはatan2を必要とするがLLVMはベクトル化されたビルトインを提供していない
• スカラー関数を呼び出すとSIMD実装が壊れる
• 多項式近似による解決:
  • SGP4の精度要件（モデルに固有の制限がある）では完全な精度は不要
  • 引数を[0,1]の範囲に保ち多項式精度を向上
  • ホーナー法で計算
  • @selectを使用した分岐なしの象限補正
• 多項式近似は約1e-7ラジアンの精度でLEO距離で約10mmの位置誤差に相当
• これはSGP4の固有精度限界内で数日間の伝播では数キロメートルの不確実性がある
• この数学は複雑でAIの支援を受けて実装

■ 7. Struct of Arraysデータ構造

• 複数衛星処理のためStruct of Arraysレイアウトを使用
• ElementsV4構造体:
  • 各フィールドがVec4で4つの衛星の値を保持
  • 重力モデルや離心率や傾斜角や昇交点赤経などの軌道要素
  • 事前スプラット済み定数をinit時に一度計算
• 事前スプラット最適化:
  • ホットパスでの繰り返し@splat呼び出しを排除
  • 毎秒数百万回実行されるコードでは小さな最適化も重要

■ 8. ベンチマーク結果

• ネイティブ実装比較（Zig vs Rust）:
  • 1日（分間隔）でastroz 0.27ms対Rust 0.31msで1.16倍高速
  • 1週間（分間隔）でastroz 1.99ms対Rust 2.04msで1.03倍高速
  • 2週間（分間隔）でastroz 3.87ms対Rust 4.03msで1.04倍高速
  • 2週間（秒間隔）でastroz 222ms対Rust 234msで1.05倍高速
  • 1ヶ月（分間隔）でastroz 8.37ms対Rust 8.94msで1.07倍高速
  • 両実装ともスカラー処理で約500万回毎秒を達成
  • Zig実装がRustを若干上回るのはホットパス最適化とcomptimeの積極的な事前計算による
• ネイティブSIMDスループット:
  • astroz Zig SIMD実装で1200万回毎秒
  • astroz Zigスカラー実装で520万回毎秒
  • Rust sgp4で510万回毎秒
  • @Vector(4, f64)を使用した複数衛星または時点の並列処理でスループットがスカラー実装の2倍以上に向上
• Pythonバインディング性能:
  • 2週間（秒間隔）でastroz 160ms対python-sgp4 464msで2.9倍高速
  • 1ヶ月（分間隔）でastroz 5.9ms対python-sgp4 16.1msで2.7倍高速
• Pythonバインディングスループット:
  • astroz Python 700万回毎秒
  • satkit（Rust）370万回毎秒
  • python-sgp4 220万回毎秒
• heyoka.pyとの比較:
  • 8衛星×1440時点でheyoka.py 1620万回毎秒対astroz 750万回毎秒
  • 1衛星×1440時点でheyoka.py 380万回毎秒対astroz 850万回毎秒
  • 100衛星×100時点でheyoka.py 1550万回毎秒対astroz 840万回毎秒
  • heyoka.pyは複数衛星バッチで勝利しastrozは時間バッチワークロードで勝利
  • ユースケースによる選択:
    • 数百の衛星を同時に同一時点で伝播する場合はheyoka.pyが有利
    • 個別衛星のエフェメリス生成や通過予測や軌道解析の場合はastrozが2倍高速
    • 簡単なデプロイメントが必要な場合はastrozがpip installのみでNumPyのみ依存しheyoka.pyはLLVMとC++スタックが必要

■ 9. 実用的なデモ

• インタラクティブCesiumビジュアライゼーション:
  • CelesTrakの全アクティブカタログ約13000個の衛星を処理
  • 1440時点（1日を分解像度）で約1900万回の伝播計算
  • Pythonバインディング経由で約2.7秒で完了（約700万回毎秒）
  • TEME→ECEF座標変換に約0.6秒追加で合計約3.3秒
  • ネイティブZigでは1100万〜1300万回毎秒に到達
• 高速化により計算のバッチ処理やスケジューリングを考える必要がなくなり必要な時に必要な計算を実行可能

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

• 今後の開発:
  • SDP4実装で深宇宙天体に対応（現在は軌道周期225分未満の近地球衛星のみ）
  • マルチスレッド化でコア全体にスケール
  • SIMD作業は単一スレッドで実行されており別の倍率が待機中
• 利用方法:
  • PyPIで利用可能でpip install astroz
  • Zigプロジェクトへの追加はzig fetch --save
  • GitHubでオープンソースとして公開
  • examplesを参照して統合可能
  • ライブデモで動作確認可能

(2026/01/22)

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

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

(2026/01/21)

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

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

要約:

■ 1. 結論と前提

• フリーランスは社員ほどではないが取り組み方次第で今後生き残るためのスキルを獲得するチャンスはある
• 早いうちにフリーランスとして色んな現場に参画することは長期的な視点でメリットがある
• 筆者の報酬は年齢と過去の経歴を加味すると同年代より高くエージェント紹介の単価水準でも高単価の部類
• 9年ほどフリーランスエンジニアとして培った案件選びや面談のスタンスやチームコミュニケーション改善のナレッジを共有

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

• チャンスをもらえないのは選んだ現場とあなたの評価の問題
• 筆者は技術力が高いわけではなく30代に入ってアルゴリズムを勉強し直している最中
• 独立当時はウォーターフォール開発で詳細設計から実装を半年ほどのベビーエンジニアステータス
• しかし現在や前の会社で多数のチャレンジ機会を獲得:
  • ゼロイチのプロダクトの初期メンバーに抜擢
  • 未経験言語の実装を任される
  • エンジニアの採用面談に同席し合否に関わる立場
  • 完全未経験なrustの開発に単価を下げず参画
  • プロダクトの要になるデータパイプラインの新規構築
  • 顧客管理システムリプレイスの技術選定からリリース前までの実装をリードエンジニアとして推進
• 「経験が積みづらくなる構造的な力学」があるなら9年間業務委託のエンジニアOnlyな筆者はもっと厳しいスキルで今を迎えているはず
• フリーランスなら先に鍛えるべき力が不足していたために「チャンスを与えてくれる現場に出会う能力や見せ方ができなかった」
• 「フリーランスとして魅力的なマインドを持っていたわけではない」

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

• ITエージェントという存在のせいでその力を培わずともなんちゃってフリーランスになれてしまう
• 「あなたの年齢とスキルで紹介できる案件がない」と言われた瞬間に自分で案件を開拓することをしなかったエンジニアは窮地に追い込まれる
• 動物園で飼育員がご飯を挙げなかったらどんなに屈強なライオンだって餓死する
• Findy関係者の意見:
  • 売り手市場ではなくなってきている状況
  • エンジニアが企業のニーズを汲み取りアピールできるかが鍵
  • エージェント視点でも売り手市場の陰りとエンジニアが受け身で居続けることの懸念

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

• 正社員は待ってても来る可能性があるが望んでなくても来る
• フリーランスは手を上げ続けなきゃ来ないが望んでないなら来ない
• フリーランスが正社員より優れているという主張ではない
• 100%の責任を追う経験や意思決定の場に参列するのは多くは正社員
• 賃貸やローン等の社会的信用は企業のエンジニアには到底叶わない
• 生存戦略的視点で言えば正社員の70から80%程度の役割や権限ならフリーランスにもチャンスはある
• 案件探しや業務への向き合い方次第
• 正社員だろうともあっさり辞める時代
• チームメンバーだし業務委託だろうともっと良いコード書けるようになってほしいなとコストをかけてもいいと思わせる当時のパーソナリティと案件の目利き力がなかっただけ
• 業務委託だって強くなって良いコードが書ければそれがコードとして資産になる
• ノウハウがそのままプロダクションコードとして残るのがエンジニアという職業の良いところ

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

• 成長の3要素:
  • 案件レベルに直結する技術的成長
  • 案件の獲得率につながる営業的成長
  • 案件の継続に関わるコミュニケーション的成長
• 営業的なコミュニケーション力とチーム開発で必要とされるコミュニケーション力は別
• ロースキルでまず一番先に身につけるべき優先順位:
  • 1: 営業的成長
  • 2: コミュニケーション的成長
  • 3: 技術的成長
• 営業力の定義:
  • お客さんに押し売るゴリゴリなパワーではない
  • 日常生活においても役立つコミュニケーションのテクニック的な部分
  • 繰り返し実践することで徐々に自分の身体に染み付く

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

• 理由1:質の高い案件に入り込めれば他の成長は付随する
  • 営業力が上がると高単価の案件に参画できる
  • 期待値と能力があっていないので自己研鑽せざるを得ない
  • シニアエンジニアの端的なコミュニケーションを理解するために言葉の言い回しや質問の質を上げざるを得ない
  • 質の高い案件獲得を目指すことが一番連動して効率よく成長できる環境を手に入れられる
• 理由2:面談が「加点評価の場」になるか「減点評価の場」になるかは営業力次第
  • 面談は文字列でわからない人格や雰囲気やコミュニケーションスタイルを把握する大事な場
  • 正社員だろうがフリーランスだろうが対面の会話は最も重視すべき
  • 技術力が突出していないエンジニアが1時間の面談の中でまず探るべきはセールスでいうところの潜在的ニーズ
  • 自分の経歴を語る前にこれを引き出せるかが特に大事
  • 採用の目的(求人票)だけでなくブラインドされたチームの課題を引き出せるかで「相手の事を考える回数」がかなり増える
  • 限られた数十分のあなたのターンで引き出す必要がある
  • 面談が面倒な見極めの場ではなく相手の欠けたピース探しと気持ちよくそのパズルをはめるゲーム感覚で臨める

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

• スキルの切り売りになる原因:
  • 自分がある意味一番技術力あるチームにいる
  • 新しい知識を入れるチーム文化がない
  • 背伸びして入った現場じゃない
• 営業行為とは「付加価値」をつける行為
• 営業力がない人は自分を時給4000円で案件を探し実力に見合う仕事しか紹介されず出会えない
• 営業に自信があれば時給5000円や6000円で案件を探すまたは決裁前に値上げ交渉をする
• 今の実力に見合わない仕事を手に入れるチャンスが出てくる
• 上振れであなたに見合わない仕事はつまり伸びしろを与えてくれる仕事
• ダイナミックなスキルチェンジに関わる案件以外は最低時給500円以上は単価アップするような案件を選び続ければ単価が成長の具体値として示してくれる

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

• 権限について:
  • 一部の企業は与えないが意欲のある人でも絶対与えられないなんて事はない
  • 高い単価をもらっているとやれるかは別として依頼される確率は高い
  • 高い金払ってるんだからやってよ的な思想
• マネジメントについて:
  • 別に関われるし人次第
  • まとめるのが上手な人なら業務委託がサブリーダー的に使えない正社員の代わりにマネジメントすることはよくある
  • 相性悪い人のマネジメントをしたくない
  • 「マネジメント経験しました」と語れる実績より優秀な人と働ければその人をマネジメントする必要がない
  • 最も良いマネジメントはマネジメントしないこと
  • いかに仲間を上手に指揮して動かすかではなくいかにマネジメントしなくていい環境を作るかに注力すべき

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

• 意思決定について:
  • 関わりにくく社員の人ほど重要な人が集まるMTGには突っ込まれない
  • 心血注ぎたいプロダクトに出会ったときに社員になればいい
  • 意思決定に関わりたいなら個人開発すればいい
  • 個人開発をした経験は案件で関わったプロダクトより自身を持って技術選定やこだわりポイントを語れる
  • ある種の営業力強化になる
• 契約継続について:
  • すぐ切られるかは人による
  • 6年以上同じ現場にいる人もいれば1ヶ月持たず即契約終了される人もいる
  • 雇用形態的に切りやすいのは事実だが働きやすくチームにプラスになるメンバーを予算の都合がない限り簡単には切らない
  • 切られてしまうならそれはあなたの目利きが悪かった
  • この世は等価交換でギブとテイクがマッチする会社を探すべき

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

• 20代から30代前半にこそフリーランスを一度くらいは経験するべき
• 早期に複数社の現場経験ができることで多種多様な現場のコードを見ることができる
• コードリーディングがエンジニアにとって一番大事で自分のコードや設計の多様性を広げることに繋がる
• 「3年で1社」と「3社を1年ずつ」では後者の方がエンジニアとしての成長を実感するという経験則
• 労働基準法に守られない立場で数年ワーカホリックに働くという経験をしたからこそ同年代よりは少しいい生活ができている
• スキルフルになってからでないとフリーランスになるのは怖いでは既に今のAIトレンドの時代では遅いこともある
• 雇用形態にかかわらず自分のやりたいプロダクト単位で仕事を選べる力をつければ雇用形態は二の次
• フリーランスになったらできればエージェントを使わずに直契約できる会社を探すという経験もしたほうがいい
• エージェントの問題点:
  • 企業の手数料が35%からと高額
  • フロントの営業マンの技術理解力はエンジニアほど高くない
  • 要望を言ってもマッチする案件が来る可能性は自分で探すより低い
  • エージェントガチャもある
• エージェントのフォローがなくても案件を獲得できるという成功体験はAIによるジュニアからミドルエンジニア供給過多問題を乗り越えるために必要かもしれない
• 中間マージンも減ってお互いWin-Win

■ 11. まとめ

• チャンスはあり参画する案件とあなたの能力次第
• フリーランスは本来先行して身につけるべき能力は営業力
• あなたの単価は任されるチャンスの範囲
• 雇用形態関係なく「人としての相性」がまず大事
• エージェント使わずに直契約取れるかチャレンジ

MEMO:

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

(2026/01/21)

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

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

要約:

■ 1. 議論の構造

• IT業界においてWeb系とSIerを比較する議論は長年繰り返されている
• 多くは技術的優劣という形で語られている
• 議論の中心は技術そのものではなく認知の歪み
• ITのにわか層においてWeb系は技術的に優位でSIerは劣位であるという単純化された幻想が強固に信じられている
• 議論の対象は技術文化ではなく人事文化とマネジメント構造そしてそれを誤認する人間側の認知メカニズム

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

• 技術は組織や業界に自動的に蓄積されるものではない
• 個人の思考と試行錯誤の結果として身につくもの
• この前提が抜け落ちた瞬間「場所に行けば技術が身につく」という誤解が発生
• Web系というラベルがあたかも技術力を付与する魔法の環境であるかのように語られる
• 実際には考え続けた人だけが技術を獲得し考えない人はどこにいても何も残らない
• 技術は人に宿る
• 環境は確率を変えるだけ
• 自動付与は存在しない
• この三点を無視した議論はすべて幻想

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

• Web系とSIerの違いは技術文化ではなく人事評価の軸とマネジメントの設計思想
• Web系の特徴:
  • アウトプットが短い周期で可視化される
  • 個人の成果が評価に直結しやすい構造
• SIerの特徴:
  • 分業と調整が前提
  • 説明責任や役割遂行が評価の中心
• にわか層の誤認:
  • 評価軸の違いをそのまま技術力の差と誤認
  • 評価構造、役割設計、責任分散というマネジメント上の差異が技術文化の差として誤変換されている

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

• Web系の可視性:
  • 成果物が外部に公開されやすい
  • GitHubや技術ブログなどを通じて技術的アウトプットが目に入りやすい環境
  • 可視性の高さが「Web系には優秀な技術者が多い」という印象を強化
• 実態との乖離:
  • 単なる観測可能性の問題であり実態の分布とは一致しない
  • 技術的に尖った人が目立ちやすくそうでない人が視界から消えやすいという偏り
• 認知バイアスの構造:
  • 可視性、選択的観測、生存者偏重という認知バイアスが幻想を補強

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

• 人材分布の決定要因:
  • 人材の分布は理想論ではなく経済条件によって決定
  • 高い給与、安定した雇用、大規模な採用母集団を維持できるのは大企業
• 日本の現実:
  • 大企業の多くがSIer側に存在
  • 優秀な人材の絶対数はSIerに多く集まる
• Web系の限界:
  • 密度では優れて見えても人数と資金力の差を覆すことはできない
• 現実要因:
  • 給料水準、会社規模、知名度、母集団サイズが最終的な人材分布を規定

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

• SIerの構造的問題:
  • SIerという組織が多くの人をだめにしてしまうのは事実
  • 技術文化が劣っているからではない
  • 技術を深く考えなくても生存できるレーンを大量に用意しているから
• 構造の特徴:
  • 人を選別しない代わりに人を鍛えもしない
  • 成長しない人が大量に残る
  • 外部からは「技術的に弱い集団」に見える
• 誤解の構造:
  • 構造的温存、非選別性、成長不要ルートという特徴が文化論として誤って語られている

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

• 心理的動機:
  • 裏技への期待と自己正当化の欲求
  • 努力や思考を積み重ねるよりも正しい場所に行けば解決するという物語は非常に魅力的
  • 自身の立場を誇るあるいは嘆くためのポジショントークとして文化論は便利
• 議論の性質:
  • 真偽は重要ではなく感情の整合性が優先される
• 幻想を必要とする動機:
  • 裏技願望、責任転嫁、自己物語化

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

• 本来の意味:
  • 技術文化という言葉は本来思考の深さや問題解決姿勢を指すはず
• 現実の使われ方:
  • 単なる業界ラベルや雰囲気の話に矮小化されている
  • Web系という言葉に付与される先進性のイメージが技術文化と短絡的に結びつけられる
• 問題点:
  • 概念の乱用であり議論の精度を著しく下げる
  • 概念混同、ラベル依存、定義不在が誤った理解を固定化させている

■ 9. まとめ

• ITのにわか者がWeb系をSIerより技術的に優位だと信じる理由は技術の問題ではない
• 原因の構造:
  • 個人要因を無視
  • 評価構造を誤認
  • 認知バイアスに流される
  • 経済合理性を見落とした結果
• SIerの実態:
  • 多くの人をだめにする構造を持っている
  • それは所属する人間の技術の低さを意味しない
• Web系の実態:
  • 強く見えるのは密度と可視性の問題
  • 分布全体を見ればどっこいどっこいに収束
• 根本的な真実:
  • 技術は個人に宿る
  • 人は金と規模に集まる
  • この二点を直視しない限りこの幻想は繰り返され続ける

論評:

■ 1. 根本的な自己矛盾

• セクション2では「技術は個人にしか宿らない」「環境は確率を変えるだけ」と主張
• セクション6では「SIerという組織が多くの人をだめにしてしまうのは事実」と主張
• 環境が人をだめにするほどの決定的影響力を持つなら技術は個人に宿るという主張は崩壊する
• 著者は自分で設定した前提を自分で否定している

■ 2. 証拠の完全な欠如

• 記事全体が著者の印象と推測のみで構成されている
• 証拠が欠如している要素:
  • にわか層が実在するという証拠
  • その幻想が広く存在するという調査データ
  • Web系とSIerの技術力分布に関する実証的データ
• すべてが断定形で書かれているが根拠は示されていない

■ 3. 藁人形論法

• にわか層という架空の敵を設定しその愚かさを論じる構造
• 問題点:
  • 誰が実際にそのような主張をしているのか不明
  • その主張がどの程度広まっているのか不明
  • 批判対象が具体性を欠き著者の想像上の存在である可能性が高い

■ 4. 論理的飛躍

• セクション5の論理は大企業はSIer側に多いため優秀な人材の絶対数はSIerに多いというもの
• 成立しない理由:
  • GoogleやMetaやAmazonなどの巨大Web系企業の存在を無視
  • 給与だけで人材分布が決まるという単純化
  • 優秀の定義が不明確
  • 大企業の数と採用規模の関係が検証されていない

■ 5. 定義の曖昧さ

• 批判的検討に耐える定義が一切存在しない
• 曖昧な用語:
  • にわか層とは誰か
  • Web系とSIerの境界はどこか
  • 技術力をどう測定するのか
  • 優秀な人材の基準は何か

■ 6. 可視性バイアスの誤用

• 著者自身が可視性バイアスを指摘しながら自分の主張も可視性バイアスに基づいている
• SIerが人をだめにするという認識自体が問題のある事例が目立ちやすいという可視性バイアスの産物である可能性
• 自分が批判する認知の歪みを自分自身が犯している

■ 7. 結論の不在

• タイトルはなぜ幻想を抱くのかだが記事は以下に答えていない:
  • その幻想が本当に存在するのか
  • 存在するとしてそれが問題なのか
  • 著者の主張であるどっこいどっこいが正しいという根拠
• 技術は個人に宿るや人は金と規模に集まるという結論は最初の問いとは無関係

■ 8. 総評

• 記事は議論の体をなしていない
• 著者はにわか層を批判しているが自身の主張こそが根拠のない思い込み論理的矛盾藁人形論法に満ちている
• 真剣に論じるために必要な要素:
  • 実証的データの提示
  • 用語の厳密な定義
  • 論理的一貫性の確保
  • 自己矛盾の解消
• 現状では主張したいことを先に決めてそれらしい理屈を後付けした印象論に過ぎない

(2026/01/21)

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

I/Oの負荷分散の話。

書き込み側の負荷分散。

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

読み込み側の負荷分散。

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

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

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

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

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

@j5ik2o

(2026/01/21)

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

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

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

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

MEMO:

• 長生きだ

(2026/01/20)

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

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

@ubugeeei

MEMO:

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

(2026/01/20)

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

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

要約:

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

• AIがプロダクトを大きく変えると感じ従来と何が違うのかが気になってきた
• 投資家として海外を含むスタートアップやプロダクトを見る機会が増える中でAIを前提に設計されたプロダクトには従来とは明らかに異なる成功パターンがあるように感じている
• AIが中心となるプロダクトの設計には完璧な仕様を追い求める従来の手法とは異なる新しい姿勢が求められている
• プロダクトを完成させるのではなく変化し続ける前提で設計するという姿勢が必要である

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

• AIコードエディタとして登場したCursorはVS Codeという巨大な既存プロダクトが存在する市場においてまたたく間に支持を集めた
• VS CodeにもGitHub CopilotをはじめとするAIサービスのアドオンを追加することはできAI機能そのものは利用可能だったにもかかわらずである
• Cursor以前のアプローチ:
  • 既存のエディタにAIアシスタントを追加するというものだった
  • これは従来のプロダクト開発の延長線上にある発想である
  • すでに完成されたプロダクトが存在しそこに新しい機能を付け加えるという考え方である
• Cursorのアプローチ:
  • AIがコアにあることを前提としてゼロからエディタを再設計した
  • AIは追加された機能ではなくプロダクトの中心的な存在である
  • リポジトリ全体をセマンティックにインデックス化し複数ファイルにまたがる変更を生成し開発者の意図を理解して自律的に行動する
  • これはAIが完璧に機能するという前提に立ちワークフロー全体を再構築した結果である
• このCursorのアプローチが有効であることはその後GoogleがAntigravityという形で追従したことからも明らかである

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

• AIネイティブプロダクトでは従来の仕様設計が限界を迎える理由の整理が必要である
• AIを機能として追加するのではなくプロダクトの中心に据えるという設計への転換が起きている
• この変化を一言で言えば設計対象が変わったということである
• ソフトウェアが決定論的な存在から確率論的な存在へと変わったことによって起きている
• 従来のプロダクト設計:
  • 振る舞いを固定した完成物を設計する仕事だった
  • 入力と出力の関係を定義し想定される状態やユーザーフローを網羅し意図した通りに動作することを保証する
  • その前提にあるのはソフトウェアは設計者の意図通りに振る舞うべきだという考え方である
• 生成AIを中核に据えたプロダクト:
  • 設計する対象は完成物ではなく学習し続ける存在になる
  • プロダクトはリリースされた時点で完成するのではなく利用される中で振る舞いを変え進化し続けることが前提となる
  • 学習し続ける存在とはどのデータを集めどの文脈でAIに渡しどのフィードバックを次の振る舞いに反映させるかという一連の仕組みを指す
• 設計対象の変化は単なる機能や実装の差ではない
• Cursorが示したのはプロダクト設計における根本的なパラダイムシフトである
• 従来のプロダクトは完成させて出荷するものだった
• 生成AIを組み込んだプロダクトはリリース後に学習し続ける生態系として設計される

■ 4. 変わる人間の役割

• テックリードやプロダクトマネージャーが何をすればよいのかという問いがある
• 答えは完璧な仕様を書くことではない
• 良い方向に学習する構造を設計することそしてプロダクトを進化させる仕組みを整えることである
• プロダクトはもはや完成させて出荷するものではない
• プロダクトはリリース後に学習し続ける存在である
• 人間の仕事はこの生態系が健全に進化するための構造を設計することである
• プロダクトマネージャーの役割の変化:
  • 従来のプロダクトマネージャーは機能の門番だった
  • どの機能を作るかどの順番で作るかどのように作るかを決める存在だった
  • AIネイティブプロダクトを担当するプロダクトマネージャーは学習システムの設計運用責任者である
  • 具体的にはAIモデルそのものを鍛えるのではなくどのデータや文脈を与えるかどのフィードバックを取り込みどの振る舞いを強化抑制するかといった学習が回る構造そのものを設計運用する役割を担う
• ここでの学習はモデルの再学習を意味しない
• 多くのAIネイティブプロダクトは自らモデルを開発していない
• モデルを持っている場合でも有料プランの利用ユーザーデータを直接モデル学習に使わないことがほとんどである
• それでもプロダクトは使われるほどに振る舞いを変えていく
• その違いを生むのはモデルの外側に設計されたデータ文脈履歴フィードバックの構造である
• つまりプロンプトなどのAIへの指示方法でありAIに参照させるデータとしてのコンテキストである
• 技術的にはRAGであったりMCPであったりする
• AIネイティブプロダクトでは前提条件が変わる
• 振る舞いを完全に制御できない以上問われるのは個々の機能ではなく学習がどう回りどう修正されるかという構造そのものである
• 人間に求められるのは何を作るかを細かく決めることではない
• AIがどのように振る舞いを変えていくのかその前提となる構造を設計し方向を調整し続けることである

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

• 人間が設計すべき構造が実際のプロダクトの中でどのように形になっているのかを見る必要がある
• AIネイティブなプロダクトにおいて人間がどこに介在し何を設計しているのかという問いがある
• AIネイティブエディタの例:
  • リポジトリ全体がセマンティックにインデックス化されコードは単なるテキストの集合ではなく意味を持つ構造として扱われる
  • 開発者がどのような編集を行ったかどの提案を受け入れどの提案を拒否したかといった利用の痕跡が継続的に蓄積される
  • 重要なのはこれらが単なるログではなく次にAIを使う際の入力文脈として再利用される点である
  • どの情報を参照させるかどの履歴を重ねるかといった判断は人間が設計した前提に基づいて行われる
• ここで起きているのはAIの中身が変わることではない
• 固定されたモデルはそのままにどの情報を参照させどの履歴を重ねどのフィードバックを次に活かすか
• その積み重ねによってプロダクト全体の振る舞いが変わっていく
• AIネイティブプロダクトは学習し続ける存在として設計されている
• 利用のたびに得られるデータが次の振る舞いに影響を与える
• モデルを自ら開発しないプロダクトであっても学習する構造を内包することは可能である
• この構造をどう設計しどう運用するかこそが人間に委ねられた最も重要な仕事である
• 超ざっくりとした設計イメージの例:
  • AIが出した修正提案に対して開発者が採用したか拒否したかをログとして残す
  • そのログを用いて次回以降の提案時に採用されやすい修正パターンを優先的に提示する
  • 繰り返し拒否される提案パターンについてはルールやプロンプトを調整し出力されにくくする
• 重要なのは精度の高いアルゴリズムではない
• 提案から選択から次の提案に反映という学習のループが意図した方向に回るよう設計されているかどうかである

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

• 学習し続ける存在をどのように作り上げていけばよいのかという問いがある
• 鍵となるのはデータである
• ただし生成AI時代において問われているのはデータの量ではない
• 従来のデータの価値:
  • 蓄積にあった
  • どれだけ多くのデータを集めたかどれだけ詳細な情報を記録したか
  • データウェアハウスに大量のデータを保存し分析ツールで可視化する
  • これがいわゆるデータ駆動型の意思決定だった
• 生成AI時代におけるデータの価値:
  • 循環にある
  • データは集めただけでは価値を生まない
  • 利用され学習に回されAIの振る舞いを変えその結果として新たなデータが生まれる
  • この循環が回って初めてデータは資産になる
• フィードバックループの設計こそがAIネイティブプロダクトの成否を分ける
• AIを導入してもフィードバックを回収せず学習に活かさなければプロダクトは賢くならない
• その結果プロダクトは学習する生態系ではなく固定されたツールのままにとどまる
• この循環が回り始めたときそれは強力な競争優位性となる
• 他社が容易に模倣できない独自のデータと学習ループがいわばデータモートとして機能する
• 生成AI時代においてはソフトウェアそのものの差別化は急速に難しくなっている
• AIがコードを書き機能実装の大部分を肩代わりしてくれるようになったことでソフトウェア開発の再現性は飛躍的に高まった
• オープンソースモデルや汎用APIの普及も相まって技術的な障壁は大きく下がっている
• 誰でも一定水準のAI機能を備えたプロダクトを作ることができるようになった
• だからこそ差別化の源泉はデータに移る
• ただし重要なのは独自のデータを持っているかではない
• そのデータを学習に回し改善のループを回し続けられているかどうかである
• 多くの企業はすでに独自のドメイン知識とデータを持っている
• 日本企業も例外ではない
• 問題はそれらが十分に循環していないことである
• 生成AIを既存業務に部分的に導入するだけではこの循環は生まれない
• プロダクトそのものをAIネイティブな前提で再設計する必要がある
• 新興企業の戦略:
  • フィードバックループをできるだけ早く回すことである
  • データの量が少なくても利用と改善の循環を高速に回すことができればAIは急速に賢くなる
  • AIが賢くなればユーザー体験が向上しユーザーが増える
  • ユーザーが増えればデータが増える
  • この好循環がやがてデータモートを形成する
  • Cursorの成長はそのことを端的に示している
• 独自データをすでに持っている企業にとってもフィードバックループを早く回すという考え方は同様に重要である
• 派手な先行事例が出そろうのを待っていては競争優位性は築けない
• 自社の事業にAIを組み込みAIネイティブなプロダクトへと転換していく
• そのための第一歩がデータを蓄積ではなく循環として設計し直すことである
• 重要なのはフィードバックの量ではなく向きである
• 誤ったシグナルを回せばプロダクトは高速に劣化する
• 人間は学習が向かう方向に最低限のガードレールを引く必要がある
• フィードバック設計の例:
  • どの提案を評価対象とするのかどの操作を良いシグナルと見なすのかを最初からすべて自動化しようとしない
  • 初期段階では人間が明示的にこれは良いこれは悪いと判断するポイントを絞り込む
  • 学習が誤った方向に進まないよう制御する
  • フィードバック設計とはそのための最小限の安全装置である

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

• この話は技術の話だけではない
• 学習システムは個人の工夫や一部のチームの努力だけでは成立しない
• AIネイティブなプロダクトはAIネイティブな人と組織でなければ作れない
• 見た聞いた調べた範囲ではプロダクトに関わる人間がAIを理解していない組織でAIネイティブなプロダクトがうまくいった例はない
• AIネイティブ組織の特徴:
  • 会議の中でこの挙動はモデルの限界なのかそれともコンテキストやデータ設計の問題なのかを議論できるかどうか
  • KPIについても機能が予定通り完成したかではなく学習のループが回り振る舞いが改善したかを問う指標に置き換えられているか
  • こうした具体的な問いが日常的に交わされているかどうかがAIネイティブ組織かどうかの分かれ目になる
• 論文を読めという話ではない
• 実際に使い自分の手で試し失敗し挙動の癖を体感しているかどうかが重要である
• AIをブラックボックスとして扱ったままでは学習する構造を設計することはできない
• 作る経験も欠かせない
• モデルを自作する必要はないがプロンプトやコンテキストデータの与え方ひとつで振る舞いが大きく変わることを身体感覚として理解している必要がある
• AIネイティブプロダクトとはAIを前提に思考し設計し試行錯誤できる人間によってのみ生み出される
• 意思決定の速さが何より重要である:
  • 生成AIの進化は極めて速い
  • 半年待てば状況は一変する
  • このスピードに追いつくためには完璧な検討や合意形成を待っている余裕はない
  • 試し学び修正するそのサイクルを回し続けられるアジリティの高い人と組織でなければAIネイティブな競争には参加できない
• これは組織の規模の問題ではない
• 大企業であろうとスタートアップであろうと条件は同じである
• AIネイティブプロダクトを作れるかどうかはAIネイティブな人と組織になれているかどうかで決まる

■ 8. 結論

• プロダクト設計とはもはや機能や画面を設計する仕事ではない
• 変化し続ける前提に立ち学習が回り続ける構造とそれを回し続けられる人と組織を設計する仕事である
• あなたのチームはどこまで機能の設計から学習する構造と組織の設計へと軸足を移せているだろうかという問いかけがある

(2026/01/20)

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

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

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

@alfredplpl

@EzoeRyou

MEMO:

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

関連:

• シン読解力

(2026/01/20)

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

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

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

うほうほ！（鳴き声）

@labelmake

MEMO:

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

(2026/01/19)

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

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

要約:

■ 1. 問題提起と背景

• コードレビューにおいて素通しでApproveしてしまう状況が多く発生している
• 思考停止でのApprove実施はレビュープロセスの形骸化を招く
• 主な要因として理解不足・権威への盲従・時間不足の3つが存在する

■ 2. ケース別対処法

• 正直理解できない場合:
  • スキルセット不足による理解不能:
    • 素直に質問コメントを残す
    • 勉強不足を恥じる必要はない
    • 質問により自身の知識増加と実装者の見直し機会創出という2つのメリットが得られる
    • シニアエンジニアのコメントを観察し新たな視点を取り入れる
  • PRの目的理解不能:
    • 実装者の説明不足である可能性が高い
    • チケットリンクや背景説明の追記を依頼し差し戻す
  • 変更量過多による本質的変更の理解不能:
    • PR分割を指摘することで適切なレビューを実現する
    • 無理に全部読まずPR粒度の改善を求める
• 自分より知識がある人が実装している場合:
  • 権威バイアスは即座に捨てるべきである
  • 凄腕エンジニアでもタイポや削除漏れは発生する
  • 高度すぎる複雑さは運用負債となる可能性がある
  • 難しいと感じた場合は可読性向上を提案する
• レビュー時間を取ることができない場合:
  • コードレビューは品質担保のための正式な業務である
  • コンテキストスイッチコスト削減のためレビュー時間を固定化する
  • 急ぎでなければ朝一番での実施が効果的である

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

• タスク・実装の細分化:
  • PR変更行数の最小化がレビュアーの心理的ハードル低下につながる
  • 小さなPR複数回の方がトータルマージ時間は短縮される
  • 機能追加とリファクタリングの分離など工夫が重要である
• 自己レビューの徹底:
  • Files changedタブでの変更内容確認によりデバッグコード残存等を発見できる
  • 実装時の判断理由をコメントとして事前記載する
  • レビュアーの納得感向上と前提勘違いの早期発見につながる
  • Descriptionに背景・目的・テスト結果等の証跡を明記する
• 実装者としての責任意識:
  • 一番理解しているのは実装している自分であるという矜持を持つ
  • レビュアー頼みではなく自信を持ってPRを出す
  • 実装の端々に責任感の有無が現れる

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

• ツール活用による負担軽減:
  • LinterのCI実行による文法チェック自動化
  • PolicyAgentによる組織ルール遵守の自動化
  • AIレビュー導入によるコスト削減
  • ツールでコスト低減可能だが人間レビューで担保できる品質は必ず存在する
• AI進歩に伴う課題:
  • 大規模PR増加による確認負荷上昇
  • 意図不明のままPR提出されるケース発生
  • AI盲信による品質低下リスク
  • 人間レビュー対象と自動チェック対象の分離が必要
  • 実装前の設計・方針レビューの重要性増大
  • 思考履歴の言語化と記録が重要

■ 5. 結論

• わからないことを質問するのは恥ではない
• 間違いを指摘するのは失礼ではない
• 思考停止Approveを止め一言でもコメントを入れることから開始する
• 小さな一歩が自身とチームの成長につながる

(2026/01/19)

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

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

要約:

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

• 疑問の提起:
  • シングルテーブル設計はスケールが容易なDynamoDBなどのNoSQLで定番な方法でRDBであるPostgreSQLで耐えられるのだろうか
  • マスタが巨大化すると詰むのではという疑問
• 結論:
  • 特に問題はない
• 理由:
  • RDBはスケールしないと言っても数十万件くらいなら余裕で捌ける
  • 前編で説明した全マスタをまとめて取得するのはどこかで限界が来るけど取得時にMetadataによるフィルタリングをすれば適切に絞り込みが可能
  • 運用が続いて規模が大きくなったら無理が出るのは仕方がない問題が出たときにリファクタすれば良い
  • そもそも肥大化するデータはもはやマスタとして扱うのは正しくなくトランザクションとして扱うべき
  • 大抵なんとかなるしなんとかならなかったらトランザクションに寄せればいいよね

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

• 通常のアプローチ:
  • トランザクション用のテーブルを作る
  • マスタのcodeを外部キーに持たせる
  • JOINしてトランザクションと紐づくマスタをセットで取得する
• 問題点:
  • マスタがトランザクションに拘束されることになる
  • 前編で実現した柔軟なマスタの変更が封印されてしまう
  • 考え直す必要がある

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

• 問題の本質:
  • マスタが変更されると古いマスタ情報が消えてしまうのが問題
• 解決策:
  • トランザクションの中に必要なマスタの情報をコピーしてまとめて保存する
  • この単純で分かりやすい力技はとても効果的
  • マスタがどれだけ破壊的に変更や削除されてもトランザクションデータは当時の姿のままで生き残り続ける
• 手法の名称:
  • こういった手法は一般的にスナップショット・パターンと呼ばれている

■ 4. DynamoDBの採用理由

• PostgreSQLでの限界:
  • PoCなどの大きくスケールしないケースであればトランザクションもマスタと同じようにJSONBでPostgreSQLの1つのテーブルに保存しても問題ないかもしれない
  • 仮にもトランザクションなので一般的なアプリであれば使っているうちにデータは増え続ける
  • しかもマスタのデータをトランザクションにコピーするのでデータ量も増える
  • スケールできるように考えるべき
• DynamoDB採用の利点:
  • スケーラビリティ: トランザクションデータは増え続けPostgreSQLでも数十万件程度なら問題ないが数百万件や数千万件となるとシンプルに扱うことが困難でDynamoDBなら自動的にスケールするためこの心配がない
  • 書き込みパフォーマンス: トランザクションは頻繁に書き込まれDynamoDBであればキーバリューストアとして高速な書き込みに最適化されている
  • アクセスパターンが明確: トランザクションは通常特定のキーで検索されDynamoDBはアクセスパターンが事前に定義できる場合に最高のパフォーマンスを発揮しマスタのような自由な検索は不要
• 使い分け:
  • 検索性が必要なマスタ管理ではPostgreSQLを採用
  • スケーラビリティが重要なトランザクションではDynamoDBがよさそう

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

• PostgreSQLでのマスタ:
  • スキーマレスなJSONBで何でも受け入れる
  • 構造の変更が自由
  • 整合性チェックはアプリ側に任せる
  • ルーズで柔軟
• DynamoDBでのトランザクション:
  • スナップショット・パターンで当時の状態を厳格に保存
  • 一度書き込んだら変更しないでイミュータブル
  • データの整合性は書き込み時点で確定
  • 厳格で不変
• 設計思想:
  • マスタは変わるものだから変更に強い柔軟な設計にする
  • トランザクションは変わらないものだから厳格に保存して整合性を保つ
  • 一見しただけだとRDBとNoSQLに求めるものが逆転しているように見えるかもしれないがデータの性質に合わせてDBの使い方を考えればこの設計も自然に見えてくる

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

• 正規化を避けてきた理由:
  • 正規化や非正規化に囚われずにゼロベースで考えデータをありのままに扱いたかった為
• 正規化の目的の歴史:
  • 正規化理論が確立された50年前の状況を振り返る
  • ストレージが高価だったためコストの観点からデータの冗長性排除が必須だった
  • 更新処理が重かったため更新回数を最小限にする設計が必須だった
  • トランザクション処理が複雑だったため更新箇所を1箇所に集約する必要があった
  • つまり正規化の目的はデータの冗長性排除や不整合の防止というよりも限られたリソースの中で更新処理を効率的に行うことにあった
• 現代の環境:
  • ストレージコストが劇的に低下したためコスト観点では冗長性はある程度許容できる
  • 読み取り速度が物理的に向上したためJOINによる複雑な結合よりも冗長でもシンプルな構造の方が速い
  • クラウドを活用すればスケールアウトも容易になったため正規化による更新箇所の集約よりもスケーラビリティで対応できる
  • ビジネスのスピードが加速したため厳密性よりも柔軟性が重要
• 制約の変化:
  • 2026年現在のDB設計は50年前と比べて制約の性質が根本的に変わった
  • 正規化が前提としていた1970年代の制約から解放され新たな制約である開発スピードが支配的になった現代ではデータの性質に応じて正規化しない選択肢も合理的
• 重要な考え方:
  • 新規システム開発では正規化しないほうがいいという単純な話ではない
  • RDBだから正規化でもモダンだから正規しないでもなくデータの性質や規模や更新頻度や一貫性の要件や変更速度の要求やチームの状況を考えたとき何が最適かを考えることがモダンな設計の本質

■ 7. まとめ

• エクセルでマスタ管理をできる程度のアプリのDB設計のポイント:
  • マスタ管理はPostgreSQLとシングルテーブルとJSONBで小規模で変更が多いデータで検索の柔軟性が必要でスキーマレスで構造の変更に強い
  • トランザクションはDynamoDBとスナップショット・パターンで大規模で書き込みが多いデータでアクセスパターンが明確でマスタのデータを含めることで整合性を保証
• 設計の特徴:
  • DBが原因でアプリの拡張性が損なわれるということを避けるDB設計をGeminiくんに考えてもらった
  • その結果マスタは柔軟に作る為にPostgreSQLを使いトランザクションは整合性を確保する為にDynamoDBを使うという直感とは異なる考え方でありながらマスタはPostgresqlでトランザクションはDynamoDBというとても普通なDB使い分けというちょっと面白い設計になった

(2026/01/19)

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

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

要約:

■ 1. はじめにと背景

• DB設計への姿勢:
  • 個人的にDBというものに対してあまり興味がない
  • 基本的にDB設計は詳しい人に任せたいと思っている
• PoCやスモールスタートでの課題:
  • ある程度以上の大きめのシステムならそれで良いがPoCやスモールスタートの場合だとDBだけを切り離せるほど人的リソースを割けないことも多い
  • 外部にDBを丸投げしたことにより知見がなくなりDB起因でアプリの機能追加や変更が困難になるといった事態も避けたい
• 記事の目的:
  • なるべくアプリ開発の邪魔にならないDB設計を考えておきたいとGeminiくん相手に壁打ちしてみた
  • 硬い設計をするのが一般的なマスタ管理に柔軟性の高いシングルテーブル設計を採用しNoSQLの定石であるシングルテーブル設計をPostgreSQLのJSONB機能で実現するアプローチが登場した

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

• 対象システムの特徴:
  • 柔軟でモダンなシステムで規模は大きくないがモダンなシステムをなるべく柔軟に作ることを考える
  • 取り敢えずマスタを対象に考えDB設計ではよくマスタとトランザクションに分けて考えるのでまずはマスタについて考える
  • シンプルな構造を扱うユーザーの意見を素早く取り入れたいのでエクセルで作ったマスタ管理台帳を簡単に取り込めることを前提にする
  • 人間が全体を管理できる程度にシンプルなマスタということ
  • 自由度は高く項目の増減や変更の自由度は高くしたいモダンなアプリは変更に強いことが求められる
• 従来のDB設計との違い:
  • 従来は多くのシステムのデータベースには巨大なデータを扱える堅牢な設計を求められること多かった
  • 今は誰にでも気軽にアプリを開発してデプロイして公開できる時代
  • モダンな開発では規模は小さいけど柔軟性が求められる事が多く従来のDB設計では上手くいかない事もある
• アプローチ:
  • 従来のDB設計は一旦横においてエクセルで実施したマスタ定義をなるべくそのままシステム化することを考えた

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

• 設計の概要:
  • マスタの定義をすべて一つのテーブルに集約する
  • 1つのテーブルに全ての項目を放り込むという大胆な設計を提案してきた
  • よく考えると実際にこれが理にかなっている
• テーブル構成:
  • master_type: カテゴリやステータスなどの区分でエクセルのシート名に相当
  • code: 一意のキー
  • name: 表示名で実質的なValue
  • category_path: 文字列による階層表現で例は/家電/冷蔵庫
  • metadata: エクセルの残りの列をすべてここに放り込む

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

• 従来設計の問題点:
  • PoCやスモールスタートにおいて従来の1エンティティ＝1テーブルという硬い設計は柔軟な開発の足枷になる
  • エクセルの管理台帳に1つ列を足したいだけなのにDBのマイグレーションに怯え影響調査に時間を費やすことになる
• シングルテーブル設計の利点:
  • テーブルを細かく分けずあらゆるマスタを一つの大きな器に放り込むシングルテーブル設計を選択肢に加える
  • これにより構造を固定せずビジネスの変化をそのまま受け止める構成を考えることが出来る
• 比喩:
  • 正規化重視の設計は川の流れをガチガチに固める堤防を作るのに対してシングルテーブル設計は広い遊水地を用意するといったところ

■ 5. PostgreSQLでの実装

• NoSQLとの比較:
  • シングルテーブルと聞くとDynamoDBのようなNoSQLを連想する方が多い
  • 実際クエリの効率化のためにデータを1つのテーブルに集約する手法はNoSQLの定石
  • DynamoDBではパーティションキーやソートキーを抽象的に定義することで後からアプリ側でデータを解釈する柔軟性を持たせることが一般的
• DynamoDBの課題:
  • 直面するのは検索の壁
  • DynamoDBは一部の項目にしかインデックスを作れないしそれを補うGSIなどの機能はとても複雑
  • 今回は対象がマスタ管理なので検索の柔軟性はとても重要
• PostgreSQL採用の理由:
  • シングルテーブル設計によるマスタ管理を検索能力が高いPostgreSQLで実施することを考える
• PostgreSQLの優位性:
  • アドホックな検索への対応力: NoSQLは事前に定義したアクセスパターンには強いが想定外の条件での検索や集計は苦手でPostgreSQLはSQLの強力な表現力でいつでも自由な切り口でデータを抽出できる
  • JSONBと高度なインデックス: PostgreSQLのJSONB型はスキーマレスな柔軟性を提供し内部フィールドに対してGINやB-Treeインデックスを後から自由に追加可能
  • 複雑な階層やパス検索: /食品/生鮮/野菜のようなパスに基づく検索はPostgreSQLのLIKE検索やltree型を使えばインデックスを効かせつつ爆速実行可能でNoSQLのキー設計で解決するよりも遥かに直感的で強力
• PostgreSQLの位置づけ:
  • PostgreSQLをただのRDBではなく強力な検索エンジンを備えたドキュメント・ストアとして使うことでスマートなマスタ定義の管理が実現できる

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

• 懸念への対応:
  • テーブルが1つでリレーションもないならアプリ側で扱うときに不便じゃないかという懸念がある
  • 実はそんなことはない
• アプローチ:
  • DB側でJOINして整えるのではなくDB側で構造化して1発で返すというアプローチを取る
• PostgreSQLの関数活用:
  • PostgreSQLにはjson_aggやjsonb_build_objectといった抽出結果をまるごと構造化する強力な関数がある
  • これらを使えば複数テーブルを何度も叩く代わりに必要なマスタを1つのJSONオブジェクトとしてアプリに返すことができる
  • アプリ側はそれを受け取り起動時や定期的なリフレッシュのタイミングでメモリ上に展開してしまえばいい
• メリット:
  • アプリ起動時に全ロード
  • メモリ上で高速検索
  • DB通信のオーバーヘッドなし
• データ量への懸念の解消:
  • マスターのデータを全て渡すのは無駄じゃないのかという懸念がある
  • しかし今回はあくまでエクセルで人間が管理できるマスタであることが前提
  • 今時のコンピューターやネットワークなら数千件や数万件程度のデータは一瞬で処理出来る
  • むしろ通信が1回で完結するので効率よくデータを処理することが可能
• 設計思想:
  • DBに知能を持たせるのをやめアプリが使いやすい塊としてデータを扱う
  • こうすることでリレーションに頼らないスマートなマスタ取得が実現できる

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

• 従来のアプリ開発の問題:
  • 特にマスタに関しては整合性を徹底するためにDBの型や制約をガチガチに固めることが多い
  • しかし素早い開発や柔軟な仕様変更を求められるモダンな開発ではこの設計が足枷になってしまうことが多々ある
• DBの位置づけの変更:
  • DBは器であってフィルターではない
  • JSONBで何でも受け入れる柔軟な土台に徹しデータの解釈や不整合の吸収は変更が容易なアプリ側で対応することも考えるべき
• 健全な関係性:
  • アプリが賢く立ち回ることで土台であるDBを自由にする
  • この関係性こそがモダンな開発における健全なアプリとDBの関係

■ 8. おわりと次回予告

• 提案の効果:
  • PostgreSQLを使ってマスタ定義を自由にすることで柔軟なアプリ開発を爆速で実現出来る
• 残された課題:
  • そんなルーズなマスタではトランザクションの整合性が取れないのではという疑問が出るのは当然
  • 小規模アプリと言っているけど将来的にマスタが巨大化すると詰むよねという懸念がある
• 次回予告:
  • 後編ではこのルーズなPostgresqlを支える整合性を担保するDynamoDBについて語る

(2026/01/19)

Dockhand

• Dockhand - Modern Docker Management
• GitHub - Finsys/dockhand: Dockhand - Docker management you will like.

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

機能:

• コンテナ管理：コンテナをリアルタイムで起動、停止、再起動、監視
• Compose スタック：Docker Compose デプロイメント用のビジュアルエディター
• Git 統合：Webhook と自動同期を使用して、Git リポジトリからスタックをデプロイ
• マルチ環境：ローカルおよびリモートの Docker ホストを管理
• ターミナルとログ：インタラクティブなシェルアクセスとリアルタイムのログストリーミング
• ファイルブラウザ：コンテナからのファイルの参照、アップロード、ダウンロード
• 認証：OIDC 経由の SSO、ローカルユーザー、およびオプションの RBAC（エンタープライズ）

MEMO:

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

(2026/01/18)

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

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

要約:

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

• コミュニケーションが苦手な人材にとっての楽園的環境:
  • 論理的に仕様を詰め正確なコードを書けば多少無愛想でも職人として尊重された
  • 饒舌さや気の利いたお世辞は不要であった
  • 技術力だけで周囲を驚かせることが可能であった
• プログラミング愛好家のアイデンティティ:
  • 自分の指先から生まれるロジックで問題を解決することが誇りであった
  • 得意なことで収入を得られる環境が存在していた

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

• コーディング作業の減少:
  • エディタに向かってコードを書く時間が激減した
  • AIが生成した80点のコードの検品係が主な役割となった
  • 創造する喜びが失われた
• プログラミング能力の価値暴落:
  • プログラミング未経験の業務担当者がChatGPTを使い簡単なツールを自作できるようになった
  • 現場のドメイン知識を持つ人材がAIを手足として使えるようになった
  • プログラマーという通訳の役割が不要となった

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

• コーディングからコミュニケーションへの転換:
  • 要件定義や業務整理やステークホルダーとの調整が増加した
  • 何を作るべきかやなぜ作るのかを言語化し整理する能力が求められるようになった
• 評価軸の変化:
  • 美しいコードを書く能力から生成AIを使いこなし素早くアウトプットを出す能力へ変化した
  • 技術力一本での評価という爽快感が消失した

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

• 推奨しない動機:
  • プログラミングが好きで人と話すのが苦手という理由だけでは生き残れない
  • プログラミングそのものはAIがより上手に実行するようになる
• 推奨する動機:
  • 作りたいサービスがある人材
  • 解決したい社会課題がある人材
  • アイデアで世界を良くしたい人材
• 技術の民主化:
  • 高度なコーディングスキルという壁が消失した
  • 情熱とアイデアとAIへの指示力があれば誰でもクリエイターになれる
  • 静寂とコードの職人芸の世界から誰もがアイデアを形にできる創造的な世界への移行

MEMO:

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

(2026/01/18)

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

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

要約:

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

• 集約の重要性:
  • 関連するエンティティと値オブジェクトを1つの単位として扱う概念
  • ビジネスルールの整合性を保つための境界を定義する
  • データの一貫性を保証する役割を果たす
• ファットリポジトリ化の問題:
  • 1つのリポジトリに多くのメソッドが集約される
  • 変更影響範囲の拡大により他メソッドへの影響考慮が必要になる
  • テストの複雑化が発生する
  • 責務の曖昧化が生じる
  • チーム開発での競合が増加する
• アクション単位設計の設計思想:
  • 各アクションに対して専用のプレゼンターとユースケースとリポジトリを用意する
  • 各アクションが独立し変更影響が局所化される
  • DDDの層構造とADRパターンを組み合わせる

■ 2. ADRパターンの概要

• ADRパターンの定義:
  • Paul M. Jonesによって提唱されたMVCパターンの代替アーキテクチャ
  • HTTPリクエストの処理を3つの明確なコンポーネントに分離する
• 3つのコンポーネント:
  • Action: HTTPリクエストを処理するエントリーポイント
  • Domain: ビジネスロジックとドメインモデル
  • Responder: レスポンスデータの構築とHTTPレスポンスの生成
• MVCパターンとの違い:
  • MVCではControllerがModelとViewの両方に依存し責務が曖昧になる
  • ADRではActionとDomainとResponderの役割が明確に分離される
• メリット:
  • 各コンポーネントの責務が明確になる
  • 各コンポーネントを独立してテストできる
  • ビジネスロジックがフレームワークから独立する
  • Domain層がプレゼンテーション層に依存しない
• DDDとの組み合わせ:
  • ActionをPresentation層のControllerにマッピングする
  • DomainをDomain層にマッピングする
  • ResponderをPresentation層のPresenterにマッピングする

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

• 集約にこだわった設計の特徴:
  • 1つのリポジトリに複数の操作を集約する
  • OrderRepositoryにcreateやupdateやcancelなど多数のメソッドが存在する
• 問題点の詳細:
  • 変更影響範囲の拡大: 1つのメソッド変更時に他メソッドへの影響考慮が必要
  • テストの複雑化: 各メソッドのテスト時に他メソッドとの相互作用を考慮する必要がある
  • 責務の曖昧化: データアクセスだけでなくビジネスロジックも含まれる可能性がある
  • チーム開発での競合: Gitのマージコンフリクトが発生しやすくなる

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

• アクション単位設計の構成:
  • 1プレゼンター: 各アクション専用のプレゼンター
  • 1ユースケース: 各アクション専用のユースケース
  • 1リポジトリ: 各アクション専用のリポジトリ
  • 各アクションをパーティションで区切るイメージ
• 依存性逆転の法則:
  • Application層にインターフェース定義を配置する
  • Presentation層とInfrastructure層はApplication層のインターフェースに依存する
  • Application層が外部層に依存しない構造を実現する
• ADRパターンとの対応:
  • Action: OrderControllerとしてHTTPリクエストの受付とルーティングを担当
  • Domain: Domain/Entities/Orderとしてビジネスルールとエンティティを担当
  • Responder: CreateOrderPresenterとしてレスポンスデータの構築を担当
• ARC パターン:
  • DDDの構造設計とADRパターンを融合させた設計
  • Action-Responder Cleanパターンと呼称する

■ 5. Laravel実装例

• ディレクトリ構造:
  • Application層: インターフェース定義とユースケース
  • Domain層: エンティティ
  • Infrastructure層: リポジトリ実装
  • Presentation層: プレゼンターとリクエストとレスポンス
  • Http層: コントローラー
• 各レイヤーの役割:
  • リクエストDTO: リクエストデータを保持する
  • レスポンスDTO: レスポンスデータを保持する
  • プレゼンターインターフェース: アクション単位で独立したインターフェースを定義
  • プレゼンター実装: リクエストとレスポンスの保持と取得
  • リポジトリインターフェース: データアクセスの抽象化
  • リポジトリ実装: Eloquentを使用したデータアクセス
  • ユースケース: ビジネスロジックの実装
  • コントローラー: HTTPリクエストの受付とバリデーション
• 依存性逆転の法則のメリット:
  • ビジネスロジックの独立性により外部の実装詳細に依存しない
  • 実装の交換が容易でインターフェースが変わらない限り影響がない
  • モックやスタブを使ったテストが可能
  • フレームワークからの独立性により移行時もビジネスロジックを再利用可能
• Responderの責務に関する設計選択:
  • 現在のアプローチ: PresenterがCreateOrderResponseを返しコントローラーがJsonResponseを構築する
  • 代替アプローチ: Presenterが直接JsonResponseを返す
  • 現在のアプローチはフレームワークからの独立性を重視する
  • 代替アプローチはADRパターンの徹底を重視する

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

• 独立性:
  • 各アクションが独立し変更影響が局所化される
  • 注文作成のロジック変更時に注文キャンセルのロジックに影響を与えない
• テスタビリティ:
  • モックが容易で単体テストが書きやすい
  • 各コンポーネントを独立してテストできる
• 保守性:
  • 機能追加や変更時の影響範囲が明確になる
  • 新機能追加時に既存コードへの影響を最小限に抑える
• 可読性:
  • 各クラスの責務が明確でコードの理解が容易
  • 1クラスのステップ数が200から300程度に収まる
  • 新しいメンバーのプロジェクト理解が速やかに進む
• スケーラビリティ:
  • チーム開発での競合が減り並行開発が容易になる
  • 複数の開発者が異なるアクションを並行して開発できる
• 依存性の明確化:
  • 依存関係が明確で変更に強い設計になる
  • インターフェースを変更しない限り実装変更が他層に影響を与えない
• ADRパターンの利点:
  • ActionとDomainとResponderの分離により責務が明確になる
  • ビジネスロジックがフレームワークから独立しフレームワーク変更への耐性が向上する

■ 7. 実践的なTips

• Laravelサービスコンテナ活用のベストプラクティス:
  • 各機能ごとにサービスプロバイダーを作成し依存関係を明確に管理する
  • インターフェースに依存することでモック化が容易になる
  • プレゼンターは都度生成しリポジトリはシングルトンなど適切なライフサイクルを選択する
• テストコードの書き方:
  • 依存関係が明確で必要なモックを特定しやすい
  • 1つのアクションに焦点を当てたテストが書きやすい
  • インターフェースに依存しているためモックの作成が簡単
  • データベースや外部APIに依存せず単体テストが高速に実行できる
• ユースケースのテスト例:
  • リポジトリをモック化してテストする
  • 在庫不足時の例外スローを確認する
• コントローラーのテスト例:
  • プレゼンターとユースケースをモック化する
  • レスポンスのステータスコードとデータを確認する
• リポジトリのユニットテスト:
  • DBファサードとEloquentモデルをモック化する
  • データベースに依存せずテストが高速に実行される
  • エッジケースのテストが容易になる
• 拡張時の注意点:
  • 新しいアクションには新しいコンポーネントを作成する
  • 既存コンポーネントの変更を避け影響範囲を最小化する
  • 共通処理はドメインサービスやアプリケーションサービスとして抽出する
• 共通処理の抽出例:
  • ドメインサービス: 価格計算や配送料計算などビジネスロジック
  • アプリケーションサービス: 在庫チェックなど複数アクションで共通する処理
• パフォーマンス対策:
  • リポジトリの最適化により必要なデータのみを取得する
  • 頻繁にアクセスされるデータはキャッシュを実装する
  • Eloquentのwithメソッドを活用しN+1問題を回避する
• ADRパターンとDDDの組み合わせガイドライン:
  • Action層の薄さを保ちビジネスロジックを含めない
  • Domain層の純粋性を保ち外部層に依存しない
  • Responder層の独立性を保ちビジネスロジックを含めない

■ 8. まとめ

• 設計の重要性:
  • 集約にこだわりすぎることでファットリポジトリ化し保守性が低下する
  • アクション単位設計により各アクションが独立し変更影響が局所化される
  • DDDとADRパターンの組み合わせによりクリーンアーキテクチャの原則を実現する
  • 依存性逆転の法則により外部層がApplication層に依存する構造を実現する
• 長期的なサービスへの適用:
  • 数年から数十年と長く運用し続けるサービスにこそ価値がある
  • 機能の追加や変更が頻繁に発生する環境に適している
  • チームメンバーの入れ替わりに対応しやすい
  • 技術スタックの進化に柔軟に対応できる
  • 複数の開発者の並行作業で競合が発生しにくい
• 長期運用における優位性:
  • 機能追加時の影響範囲が明確で既存コードへの影響が最小限
  • コードの理解が容易で新メンバーも特定機能に焦点を当てて理解できる
  • フレームワークからの独立性により技術スタック変更に柔軟に対応できる
  • 並行開発の促進により複数開発者が同時開発しても競合が発生しにくい
• 実践的な設計指針:
  • アクション単位設計に従い各アクションに専用コンポーネントを作成する
  • 依存性逆転の法則に従いApplication層にインターフェースを配置する
  • ADRパターンとDDDの層構造を組み合わせる
  • テスト容易性と保守性を重視する

MEMO:

• ちょっと違和感があるが

(2026/01/18)

巨大SQLに対する解読術

• 巨大SQLに対する解読術

(2026/01/18)

Kiroみたいな「仕様書駆動開発」をClaude Code・Opus 4でやるまでの手順を整理した！！！

• Kiroみたいな「仕様書駆動開発」をClaude Code・Opus 4でやるまでの手順を整理した！！！ #LLM - Qiita

(2026/01/18)

僕の観測範囲で喋ってしまうけど、AI コーディングエージェントが登場してきて、プログラマが...

僕の観測範囲で喋ってしまうけど、AI コーディングエージェントが登場してきて、プログラマがやってた事を AI が肩代わりするだろう、そして人間に時間の余裕ができるだろう、と思われていたにも関わらず、多くのプログラマはそれどころか 2 倍や3倍の作業量になってしまっており「おいおい君ら倒れるで」という状況をチラホラ目にしている。

@mattn_jp

MEMO:

• 実装というかコード出力はすぐ完了するので、出力されたコードをレビューする → 意図通りに修正 or 再出力を指示みたいなサイクルが早すぎて人間側が疲弊している
• 単位時間あたりの労働負荷が大変なことになっている上、AI前提の生産性が求められるのでサボることもできないという

(2026/01/18)

Raspberry Pi AI HAT+ 2

• Buy a Raspberry Pi AI HAT+ 2 – Raspberry Pi

要約:

■ 1. Raspberry Pi AI HAT+ 2の概要

• Hailo-10H AIアクセラレータを搭載
• 8GBのオンボードRAMを搭載
• Raspberry Pi 5に生成AI機能を追加するHAT
• 価格は130ドル
• 現在販売中

■ 2. オンボードRAMの利点

• 8GBの専用オンボードRAMを搭載
• 大規模言語モデル(LLM)やビジョン言語モデル(VLM)をローカルかつセキュアに実行可能
• ホストのRaspberry Pi 5を他のタスク処理に解放できる
• AIモデルのスムーズな動作を保証

■ 3. プライバシーとセキュリティ

• エッジでの信頼性が高く低遅延なAI処理を実現
• ネットワーク接続なしで動作可能
• データセキュリティを簡素化
• インフラ要件を最小化
• クラウドAPIコストを削減

■ 4. モデルの提供

• Hailoがサンプルモデルを提供
• ユーザーによるカスタマイズ:
  • カスタムビジョンモデルのトレーニング
  • 生成AIモデルのファインチューニング
• 対応アプリケーションの例:
  • 音声からテキストへの変換
  • 翻訳
  • 視覚シーン分析
• 互換性のある生成AIモデル用ソフトウェアはHailoのGitHubリポジトリで入手可能

■ 5. 主な仕様

• Hailo-10H AIアクセラレータ搭載
• 40 TOPS(INT4)の推論性能
• コンピュータビジョンモデルの性能はRaspberry Pi AI HAT+(26 TOPS)と同等
• 8GBオンボードRAMにより生成AIモデルを効率的に実行
• Raspberry Piのカメラソフトウェアスタックに完全統合
• Raspberry Pi HAT+仕様に準拠

■ 6. 付属品

• オプションのヒートシンク付属
• 16mmスタッキングヘッダー付属
• スペーサーとネジ付属
• Raspberry Pi Active Cooler装着済みのRaspberry Pi 5への取り付けが可能

MEMO:

• 40TOPSというと最近発表されたASUSのAIアクセラレータと同等のスペックなのか
• ASUS、最大40TOPSのAI性能を持つ外付けAIアクセラレータ - PC Watch

(2026/01/18)

loss32: let's build a Win32/Linux

• loss32: let's build a Win32/Linux

要約:

■ 1. loss32プロジェクトの概要

• コンセプト:
  • デスクトップ環境全体がWINE上で動作するWin32ソフトウェアで構成されるLinuxディストリビューション
  • 完全にフリーかつオープンソースのOS
  • exeファイルをダウンロードしてそのまま実行できる
• 想定ユーザー:
  • 必ずしもUnix愛好家ではないパワーユーザー
  • このコンセプトを面白いと思う人

■ 2. ReactOSとの違い

• ReactOSの問題点:
  • Windows NTカーネルの再実装を試みている
  • これがアキレス腱となりハードウェア互換性と安定性の面で足を引っ張っている
• loss32のアプローチ:
  • ReactOSと似た最終結果を目指す
  • より使いやすい基盤の上に構築
  • 動作実績のあるコンポーネントを使用:
    • Linuxカーネル
    • WINE
    • それらを結合する各種ツール
    • ReactOSユーザーランドの便利な機能
• loss32の利点:
  • 技術的にはLinuxディストリビューションのため必要に応じてLinuxソフトウェアも実行可能
  • ReactOSではLinuxソフトウェアを実行できない

■ 3. プロジェクトの目標

• ユーザーランド全体を可能な限りWINEで置き換える

■ 4. プロジェクトを構築する理由

• 90年代後半から2010年代初頭のPCデスクトップ体験はパワーユーザー特にクリエイティブユーザーにとって素晴らしかった
  • その夢を維持したい
• WINEには残念な荒削りな部分が多くユーザーは最後の手段としてのみWINEを使用するため許容している
  • 全てがWINE上で動作するデスクトップ環境はWINEの改善を促進する
  • このプロジェクトを使うかどうかに関わらず全員にとって有益
• Win32は安定したLinux ABIである
• 技術的に可能だから

■ 5. Win32が安定したLinux ABIである理由

• exeファイルをダウンロードしてWINEで実行できることで何度も助けられた経験がある
• クリエイティブプロジェクトでは以下のようなソフトウェアが必要になることが多い:
  • 自分で再ビルドするのが不可能または非現実的
  • LinuxやmacOS版が動作しないまたは存在しない
• Win32ソフトウェアには30年以上の歴史がある
  • WINEまたはWindows上で実行可能
  • 他のABIにはこれほどの互換性実績がない
  • WINEはWin16のソフトウェアも実行可能
• Win32は世界の安定したABIでもある:
  • GNU/LinuxやPOSIX系の選択肢が限られており品質が低い分野が多い
  • 例としてクリエイティブソフトウェアやゲーム
  • Win32により人類の文化遺産のより大きな部分にアクセス可能

■ 6. 現在の状態

• スクリーンショットは実際のもの
• Debian 13上で安定版WINEを実行している状態
• スクリーンショットには映らない多くの荒削りな部分があり現時点では使用が快適ではない
• プロジェクトの目標:
  • 多くの荒削りな部分を修正
  • この環境を簡単にインストールできる形でパッケージ化

■ 7. 協力者の募集

• 特に求めている知識や協力:
  • デスクトップ環境を強制しないWaylandコンポジター
    • 現在はスタンドアロン版のmutterを使用
    • WINEとの連携改善
  • WINE関連:
    • explorer.exe
    • shell32.dll関連
    • HiDPIスケーリング
    • パッケージング
  • ReactOS関連:
    • explorer.exe
    • shell32.dll関連
    • ReactOSユーザーランドとWINEの非互換性
  • GNU/Linuxデスクトップスタックの複雑な詳細全般

■ 8. リリース予定

• ビジョンの完全な実現時期:
  • 不明
• 2026年1月中に初期の概念実証版をリリース予定:
  • /etc/apt/sources.listに追加してsudo apt installで導入可能
  • 欠落や不具合の長いリストが付属
  • そこから反復的に改善していく

(2026/01/17)

無茶なスケジュール案件でも燃えにくくする「開発環境」と内部工程計画の考え方

• 無茶なスケジュール案件でも燃えにくくする「開発環境」と内部工程計画の考え方 #アジャイル - Qiita

要約:

■ 1. フリーランス・小規模ソフトハウスが直面する構図

• 元請けが穴だらけの立派な工程表を出してくる
• 大半の人はその穴を見抜けるレベルのレビュー実戦経験がない
• プライムにケチを付けられない立場のため従うしかない
• 末端側はウォーターフォール型工程に従い各工程のみを担当する
• 作るものの全体像が曖昧なまま設計が進む
• 実際に環境を組み上げたタイミングでようやく現実が見える
• 結果として発生する問題:
  • 仕様漏れ
  • 追加作業と追加料金交渉
  • 納期ギリギリ
  • ユーザー満足度の低下

■ 2. プロジェクト計画の理想と現実

• 理想:
  • プロジェクト計画書がパートナーにも展開される
  • 双方でコンセンサスを取りながら進める
  • リスク想定とヘッジ案の説明や議論がある
• 現実:
  • 小さな会社の社長やフリーランスはプロジェクトキックオフの儀式としてしか見ていない
  • 様々な事情からリスク議論が実践できない

■ 3. 元請けの工程表の実態

• PMの願望が強く出たドキュメントと認識すべき
• 通常書かれていないもの:
  • 商用環境の構成が固まるタイミング
  • 試験環境でどこまで再現するか
  • どの段階で何を試すか
  • 現場の安全マージンやリスクヘッジ
• 極端な工程表の例:
  • 要件定義工程がない
  • 各工程での成果物が決まっていない
  • 設計工程なしにいきなりパラメータ設計書
  • PoCでやったから設計なしでいけるという幻想でいきなり環境構築
  • ステージングをそのまま本番にするノリで商用後の保守イメージがない
  • 実装期間が妙に短く3週間に環境構築から報告書作成まで全部入り
  • セキュリティ設計やセキュアコーディングガイドラインがなく脆弱性試験で炎上
• このまま乗ると後半で燃える
• 外向け工程表とは別に内部で裏プロジェクト計画を持つ発想が重要

■ 4. 技①:基本設計段階でプロト環境を先に作る

• 基本設計フェーズの早い段階で本番と同じ構成イメージの影のプロト環境を自分たち側でこっそり作る
• プロト環境の内容:
  • 土台となるOS
  • 想定しているミドルウェア(アプリケーションサーバやレポーティング基盤など)
  • 知る限り本番構成に近い形で一度組んでみる箱
• あらかじめ作っておくべきもの:
  • GitLabなどのソースコード管理とCI/CD基盤
• メリット:
  • 早い段階でリバースプロキシ不足や追加DB必要などの設計上の大穴に気づける
  • 元請けの基本設計がふわっとしていても動くものの全体像を先に掴める
  • 構築メモや設定手順と要件定義があれば基本設計書は後から2〜3日で一気に書ける
  • 体裁や細かい部分はLLMを使えば2〜3日で形にできる
• ポイント:
  • 工程表通りにドキュメントだけ書くのではなく基本設計の最初にプロト環境をこっそり動かす
  • 内部工程を勝手に入れ替える
  • 外には言わず自分たちが燃えないための保険として自社努力で行う
• コスト面:
  • 自社で新たに大きなコストを捻出する必要はない
  • プロジェクト開始早々は要件定義未提出や基本方針未確定などの待ち時間が多い
  • 自分に関係ない打ち合わせ中にこっそり進める
  • 待ち時間を活用して動くものの断片でも作っておく
  • 勝手アジャイルを回す勢い

■ 5. 技②:バージョン釘打ちミーティングをねじ込む

• プロト環境を先に作る際の落とし穴:
  • バージョンが後から変わって全部作り直しになる
• 対策として基本設計の初期にバージョン釘打ちミーティングをねじ込む
• 最低限合意しておくべき項目:
  • 土台となるOSのバージョン(メジャーとマイナーまで決まれば上出来)
  • 主要なミドルウェアとそのバージョン(アプリケーションサーバやレポーティングやバッチ基盤など)
  • それぞれのサポート状況(EoL時期やメーカーサポート有無やOSSコミュニティ活動状況)
• 釘打ちは完璧でなくてよい:
  • 一生変えないという固定ではない
  • ひとまずこの前提で設計見積もりを進めるレベルの合意
  • 後から変更が出ても柔軟に対応できるようにしておく

■ 6. 技③:プロト環境の存在は言わず経験値として出す

• 影のプロト環境で性能やリソースを見ておくと後のフェーズで楽になる
• 聞かれる質問の例:
  • この構成でCPU何コアぐらい必要か
  • 何ユーザーぐらいまで余裕があるか
  • どのくらいのマシンサイズを見込めばいいか
• 裏ではプロト環境でちゃんと数字を取っているが自前環境で負荷かけたとストレートに言う必要はない
• 期待値コントロールの領域
• 外向きの言い方サンプル:
  • 同等規模の構成での過去案件の経験値ではこのくらいのアクセス数ならCPU使用率は何%前後
  • 近い構成のプロジェクト実績をベースにすると初期はこのマシンサイズから始めるのが妥当
  • 似たような業務負荷の案件で取った数値を参考にするとこのくらいのスペックで当面余裕がある
• 実際にはその過去案件の1つが今回の影のプロト環境だが外から見れば経験値として扱える
• バランス感覚のポイント:
  • 裏側ではしっかり測っている
  • 過度に全部やってあげてますと期待値を上げすぎない
  • 過去の知見として妥当な範囲を出していますというトーンを守る

■ 7. 技④:LLMに食わせる前提で手順書だけちゃんと残す

• 影のプロト環境を作るときは基本設計書そのものより手順書とメモの残し方をちゃんとしておく
• 理由:
  • LLMに食わせるとかなり精度の高い基本設計書ドラフトが一瞬で出てくる
• 流れ:
  • 影のプロト環境を作る
  • その過程でインストール手順やミドルウェア設定や詰まったポイントと解決策をざっくりテキストで残す
  • LLMに渡して基本設計書の構成案出しや顧客向け表現整理や試験項目洗い出しやパラメータシートたたき作成を依頼
  • 2〜3日かけて書くレベルの文書が数時間で形になる
• この組み合わせの効果:
  • 実装リスクを下げる
  • ドキュメント工数も削る
  • かなり相性の良い戦略

■ 8. ウォーターフォールを表で守りつつ裏でアジャイルを回す

• 表向きの対応:
  • 元請けが出してきた大きな工程表(ウォーターフォール)に従っているように見せる
  • マイルストーンや成果物の名称も基本設計や機能設計や結合テストを崩さない
• 裏側での対応:
  • 基本設計フェーズのうちにプロト環境を作って動かす
  • バージョンを釘打ちする
  • 実際に動かしながらこれで行ける構成を先に固めてしまう
  • そこで得た知見をもとに性能見積もりやリソース見積もりやリスク洗い出しをスッと出せるようにしておく
• 効果:
  • 表面上はウォーターフォールでも内側では小さなアジャイルサイクルをぐるぐる回して後続工程をどんどん楽にできる
  • 大線表の納期を遅らせるという話ではない
  • 最初に影のプロト環境を作っておくことで大線表を遅らせずに済む確率がかなり上がる
  • その構成で実際に動いている環境がすでにあるため

■ 9. 環境をプロジェクトごとに準備する効率化

• ネック:
  • 案件ごとにOSやミドルウェアや認証まわりやテスト用クライアントを毎回ゼロから用意するのはフリーランスや小規模ソフトハウスにはheavy
• 対策:
  • 案件ごとの箱庭環境を簡単に量産できるテンプレートやツールを少しずつ自分の側に用意しておく
• 具体例:
  • 手元のマシン1台に仮想化環境と案件ごとの箱庭を自動で作るスクリプトを置いておく
  • 新しい案件が始まったらまず影のプロト環境を30分くらいで立ち上げてから設計に入る
• 使うツールや技術スタックは何でも構わない
• 大事な発想:
  • 毎回手作業で環境を組むのではなく案件ごとの箱庭をほぼテンプレートから起こす
  • リモートからVPN経由で簡単に入れるようにしてパートナーがすぐに参加できる環境を作っておく
  • となりの案件のVMが見えてしまわないようなセキュリティに十分配慮した分離開発環境を構築する
• パブリッククラウドで回してもよいが採算度外視で使うのはかなり危険

■ 10. まとめ

• 元請けの工程表だけを信じて燃えないための要点:
  • 外向け工程表とは別に自分たちの内部工程計画を持つ
  • 基本設計の初期にプロト環境をこっそり作ってしまう
  • OSとミドルウェアのバージョンを早めに釘打ちしておく
  • プロト環境で得た数字は自前ラボで測りましたではなく他プロジェクトでの経験値ですとして出す
  • 手順書をちゃんと残しておけばLLMに食わせて基本設計書を一気に仕上げることもできる
  • 表向きはウォーターフォールでも裏で小さなアジャイルを回して先回りしておくといろんな工程が楽になる
• 正論のセキュリティ記事というより現場で生き残るためのテクニック集
• これらの工夫が積み上がると変わること:
  • プロジェクトの燃え具合
  • ユーザーの満足度
  • 自分たちの消耗度合い

(2026/01/17)

Redundancy vs dependencies

• Redundancy vs dependencies: which is worse?

要約:

■ 1. プログラミングにおける2つの本質的な力

• 冗長性の最小化:
  • 全ての知識を一度だけ定義することが理想
• 依存関係の最小化:
  • AがBに依存するのは絶対に必要な場合のみに限定すべき
• 優れたプログラマの特徴:
  • 冗長性と依存関係を嫌悪する
  • 劣ったプログラマはこれらを気にしない

■ 2. 冗長性と依存関係の衝突

• モジュール境界を越えたコード再利用の問題:
  • モジュールAとBが共通モジュールCを使うか各自で実装するかの選択
• モジュール内部での再利用:
  • 議論の余地なく再利用すべき
• モジュール間での再利用:
  • 第三のモジュールを作成するか「ユーティリティ」モジュールに追加する必要がある
  • ユーティリティモジュールの問題点:
  • 外部ライブラリへの依存
  • 設定の誤り
  • 初期化タイミングの問題

■ 3. 経験がもたらすもの

• 経験は知識の蓄積より性格の形成または破壊に寄与する
• 若いプログラマ:
  • インフラ構築に積極的
  • 第三のモジュール作成を喜ぶ
• ベテランプログラマ:
  • インフラ活動に対して否定的反応を示す傾向

■ 4. コマンドライン解析の例

• 機能拡張の誘惑:
  • オプション構文の統一
  • 値の型対応(文字列/真偽値/整数/16進数/ユーザー定義型)
  • ヘルプ文字列
  • ヘルプ画面の自動生成
  • GUIプロパティページ
  • 設定ファイルからの読み込み
  • フラグの妥当性チェック
• 過剰設計の実例:
  • XParam: 1万行以上のコードと独自シリアライゼーションフレームワーク
  • ホストプロジェクトでは機能の5%未満しか使用されない
  • 著者自身もXLogという1万行以上のログライブラリを作成し機能の0%しか使用されなかった経験を持つ
• 著者の現在のアプローチ:
  • 5行のCコードで単純に解析
  • ヘルプ画面やバリデーションは不要と割り切る
  • 1万行のパッケージへの依存を回避

■ 5. モジュールの定義と要件

• コンパクトで安定したインターフェース:
  • OOの訓練がコンパクトさの軽視を招いている
  • 数十のクラスや複雑なデータ構造を公開することが許容されている
• ドキュメント:
  • セマンティクスの記述
  • サンプルコードの提供が理想
• テスト:
  • 各クラスや関数の単体テストではなく公式インターフェースのテストが重要
• 適切なサイズ:
  • 1K〜30K LOC(C++換算)が目安
  • 大きすぎても小さすぎても泥の塊になる
• オーナー:
  • 変更はオーナーを説得して行う
  • 一貫したメンタルモデルを維持できる人数は1人
• ライフサイクル:
  • 変更はバージョンにまとめて頻繁すぎないリリース

■ 6. 他者のモジュールへの依存の問題

• オーナーシップの問題:
  • 作成者が継続的なサポートを認識していない
  • 他者による不適切な変更が発生
  • 循環依存の発生
• コマンドラインパーサーの潜在的依存先:
  • シリアライゼーションパッケージ
  • パースパッケージ
  • カラーターミナルI/Oパッケージ
  • プラットフォーム固有パッケージ
  • シングルトン初期化管理パッケージ
• ライフサイクルの問題:
  • バージョン互換性の確認
  • テストのコンパイルに他者のコードが必要
  • 新バージョンが追加の依存関係を引き込む
• インターフェース安定性の問題:
  • 破壊的変更によるテストスクリプトの破損
  • 予期しない動作変更

■ 7. 生物学的アナロジー

• 生物における冗長性の例:
  • 人間とタコは盲目の祖先から独立して類似の眼を進化させた
  • 眼全体という複雑な器官が独立して開発される
• 冗長性は進化において機能している:
  • 全員の努力を調整するより効果的

■ 8. 結論

• 冗長性の欠点:
  • 努力の重複
  • 相互運用性の問題
• 依存関係はより深刻:
  • 依存すべきは本格的なモジュールのみ
  • 無定形なコードの塊には依存すべきでない
• モジュール化の成功可能性の評価基準:
  • 実際のオーナーの存在
  • 安定したインターフェース
  • 全ユーザーを満足させる見込み
• 著者の主張:
  • 成功の見込みが低ければ冗長性を選択すべき
  • 見積もりは保守的に行うべき
  • 冗長性は悪だが依存関係は麻痺を引き起こす
  • 依存関係を先に排除すべき

MEMO:

• つまり、外部ライブラリへの依存は最小限にせよという話
• 外部ライブラリに依存すると、外部ライブラリのアップデートやセキュリティホール対応に追従する必要が生じる
• 特にビジネスロジックと外部ライブラリが強く結合していると外部ライブラリの不安定さがコアロジックの不安定さにつながる
• 古来より外部ライブラリは直接使うのでなく、ラップして使うことが推奨されていたように思うのだが
• 近年は本当に些細な処理ですらライブラリ化されていて、脳死で外部ライブラリを使うことが多いが、その結果サプライチェーン攻撃を喰らうことも増えた
• npmのleft-padやcolors.js/faker.jsなどがそうだったか

(2026/01/16)

ドワンゴを退職した江添亮さんがハロワに登録→連絡してきた企業の面接に行ってみたら、殺風景な雑居...

• ドワンゴを退職した江添亮さんがハロワに登録→連絡してきた企業の面接に行ってみたら、殺風景な雑居ビルの一室でわけのわからない経験をした話 - Togetter

MEMO:

• クソカス虚無企業の面接冷やかしやってみたいけど、シンプルに時間の無駄な上に個人情報を握られるリスクを考えると迂闊にできないんだよな
• 転職サイトならギリギリまで公的な身分証明出さなくてもいいから案外いけるのだろうか

(2026/01/16)

生成から工程へ――RLM(再帰的言語モデル)が非構造化データを武器に変える

• 生成から工程へ――RLM(再帰的言語モデル)が非構造化データを武器に変える – WirelessWire & Schrödinger's

要約:

■ 1. RLMの定義と本質

• 再帰的言語モデルの位置づけ:
  • 最も注目を集めている大規模言語モデルエージェント・アルゴリズム
  • 実際のモデルはOpenAIのChatGPTやgpt-ossやDeepSeekなど既存のLLMを使用する
  • 再帰とはLLMの呼び出し方を指す
• RLMの本質:
  • LLMを一発回答の生成器として使うのではなく複数の推論ステップを持つ手続きとして編成する
  • 自己修正しながら目的の成果物へ収束させる
  • 重要なのは再帰という言葉の響きよりも実装上の設計原則

■ 2. RLMの3つの構成要素

• オーケストレーターLLMとワーカーLLMの役割分担:
  • オーケストレーター: 大局的な戦略を立てる役割でどの資料を読むべきかや抽出すべきスキーマは何かや矛盾が出たらどの観点で再検証するかを担う
  • ワーカー: 局所的な作業を担当しこの段落から顧客要望を候補抽出するやこの候補の根拠となる引用箇所を特定するなど粒度の小さいタスクを大量に捌く
  • 同じLLMで役割を分担することが可能でgpt-ossは非常によく働く
• 分業が効く理由:
  • LLMの失敗が往々にして大局と細部の混線で起きる
  • 戦略を考えながら同時に細部を埋めるともっともらしい整合を優先し検証が甘くなる
  • 戦略と実務を分けることで作業の責務が明確になり失敗の検知と修正がしやすくなる
• 非自然言語的な中間表現:
  • Pythonコードなど機械的に検査可能な表現を途中に置く
  • 抽出結果をJSONにしPythonでスキーマ検証を行う
  • 重複や欠落や型不一致や相互参照の矛盾をコードで弾く
  • 候補の根拠引用が本当に原文に存在するかを文字列一致や範囲照合で検証する
• 中間表現の効果:
  • モデルが賢くなったから精度が上がるのではない
  • LLMが苦手な厳密さをコードと型と制約で肩代わりしLLMには意味の解釈を担当させる
  • LLMを推論エンジンとして使いつつ検証と制約は計算機の得意技に寄せるアーキテクチャ
• 検証から差分修正から再実行のループ:
  • 最初の抽出はあくまで暫定解にすぎない
  • Pythonで検査してエラーが出たらそのエラーを次の入力条件としてオーケストレーターに返し再度ワーカーにタスクを割り当てる
  • やり直しを精神論ではなくプロトコルとして設計する
• プロトコル設計の例:
  • フィールドが埋まらない場合は未確定を許す
  • 未確定のまま残した理由を分類して残す
  • 矛盾が出たら根拠引用を必須にして再抽出する
  • モデルがそれっぽい完成品を捏造する余地が減りシステム全体として信頼性が上がる

■ 3. RLMの全体像と従来手法との比較

• RLMの定義:
  • 戦略立案担当と局所作業担当に分解する
  • Python等で検証可能な中間表現を挟む
  • 誤りを差分として回収し再帰ループで収束させる方式
• 従来手法の問題点:
  • LLMに抽出させて人間が目視で直す運用がスケールしなかった
  • 失敗が最後に露呈し修正が属人的だった
• RLMの優位性:
  • 失敗を途中で機械的に検出し修正を自動で次工程に流す
  • 非構造化から構造化のような業務で予想以上に効く
• コアの考え方:
  • 賢い一発回答ではなく検証可能な中間表現と再実行プロトコルによって正しさへ収束する工程を作る

■ 4. KnowledgeSTATIONでの実装例

• 実装結果:
  • RLMによる非構造化データから構造化されたデータを取り出す機能を追加した
  • 予想外にうまくいった
• 機能の詳細:
  • 過去の著作や議事録や講義録など雑多な情報を貯めた知識ベースに注目するデータと出力して欲しいデータを渡す
  • 技術的な話題に注目し技術と発明者とその効果と関連する技術を指定すると自動的にデータを検索して構造化する
  • RLMがどのように動作して情報をかき集めまとめているのかという過程も可視化されている
  • 間違ったデータが出てきてもどこで間違ったのか理解しやすいメリットがある
• 出力例:
  • GPUやELIZAやAlexNetやニューラル機械翻訳やChatGPTなど技術に関する構造化データが抽出された
  • トークン上限8000など純粋に技術そのものとは言えないものも出てくるが索引などに引用する場合は納得できる
  • 構造化されたデータはExcel形式でダウンロードできる

■ 5. RLMの特徴的なメリット

• 非構造化データのノイズの活用:
  • RLMがうまく回り始めると非構造化データのノイズがむしろ追加情報源になる
  • 議事録の脱線や雑談や言い淀みや感情的な言葉が優先度の根拠やリスクシグナルとして意味を持つ
  • それ今日中にやらないとまずいという一言が期限の強制力を示す
  • 顧客が同じ要望を三度言うならそれは単なる繰り返しではなく強い痛みの表現
  • RLMは再帰の過程でこうした文脈特徴を拾い上げ構造化スキーマに落とし込める

■ 6. 課題

• 計算コストの増加:
  • 再帰はループを回すほどトークンも増え遅延も増える
• 検証関数の設計依存:
  • 再帰の品質は何を矛盾とみなすかや根拠は十分かやスキーマ制約を満たすかの設計に依存する
• 情報の欠落:
  • ドメインによってはそもそも根拠がテキストに存在しないことがある
  • 会議で決まったはずなのに議事録に書かれていない場合などが該当する
  • 未確定を無理に埋めず追加の情報取得フローに接続する必要がある
  • エージェントは万能の魔法使いではなく情報の欠落を検知して次の行動へつなげる工程管理でもある

■ 7. 今後の展望

• LLM活用の主戦場の変化:
  • 文章生成ではなく非構造化データを意思決定可能な構造へ変換することになる
  • 人間の組織が抱えるボトルネックは情報の不足ではなく情報の形式
  • 見つけられないや比較できないや集計できないや追跡できないという問題がある
  • RLMはここに正面から切り込むための基本部品になり得る
• ローカル動作の利点:
  • 完全にローカルで動作するという点も見逃せない
  • クラウドAIのAPI利用料金や制限に悩まされることなく黙々とデータを構造化していく
• エージェンティックAIの新局面:
  • RLMによってエージェンティックAIは新しい局面に到達できる可能性がある

(2026/01/16)

現場PMの力学 - 第1章：プロジェクトは「正しさ」では動かない

• 現場PMの力学 - 第1章：プロジェクトは「正しさ」では動かない

(2026/01/16)

OpenSSLプロジェクトの品質問題や組織構造の変遷について

■ 1. OpenSSLの品質問題

• OpenSSLの品質や状況に懸念があるという指摘は専門家やエンジニアの間で事実として存在
• 特にOpenSSL 3.0(2021年リリース)以降パフォーマンスの低下やアーキテクチャの複雑化をめぐって厳しい批判
• 主な指摘内容:
  • パフォーマンスの大幅な劣化:
    • 新しい「プロバイダー・アーキテクチャ」が原因で特定の処理が旧バージョン(1.1.1系)より著しく遅くなった
    • マルチスレッド環境でのロック競合によりスループットが劇的に低下
    • APIのオーバーヘッドにより証明書の検証や鍵の生成といった基本的な操作のステップ数が増加
  • コードの複雑化とテストの不備:
    • テストを通過していないコードがマージされる事象が2025年時点でも指摘
    • 修正によって別のバグ(デグレード)が発生
    • メモリ安全性の欠如(C言語で書かれているためバッファオーバーフローなどの脆弱性が継続的に発見)
  • QUICへの対応遅延:
    • 次世代通信規格QUIC(HTTP/3)への対応が非常に遅れた
    • 多くのプロジェクトがBoringSSLやquictlsなどの別ライブラリへ流出
• 業界の反応(OpenSSL離れの加速):
  • BoringSSL: GoogleがOpenSSLをフォーク/不要な機能を削ぎ落としセキュリティとパフォーマンスに特化
  • rustls: Rust言語で書かれたTLSライブラリ/メモリ安全性が保証されパフォーマンスも高い
  • Goの標準ライブラリ: 独自実装を選択しOpenSSLの混乱の影響を受けない

■ 2. OpenSSLの資金面と組織面の変遷

• Heartbleed以前(2014年以前):
  • 世界中のインフラを支えていながら正社員はほぼゼロ
  • 寄付金は年間わずか2,000ドル程度という極めて劣悪な環境
• Heartbleed後:
  • Linux Foundationの「Core Infrastructure Initiative」などを通じて数億円規模の資金援助
  • 組織は急拡大
• 資金拡大の副作用:
  • 「商用化」へのシフト: 安定した運営のためサポート契約を販売する法人化を推進/大口顧客が求める「FIPS認証」などの要件が優先
  • 官僚化と構造の複雑化: 少数の凄腕エンジニアによる属人的な開発から委員会による合議制へ移行/意思決定の鈍化
• OpenSSL 3.0の問題:
  • 過度な抽象化: 将来的な拡張性を求めて内部構造をゼロから作り直す「プロバイダー・アーキテクチャ」を導入/極めて複雑で旧バージョンの数百倍遅い処理が発生
  • QUIC対応の失敗: 内部の設計方針が二転三転した結果開発が大幅に遅れた
• 「レガシー」と「新設計」の板挟み:
  • 世界中で動いているという責任があるため古いC言語のコード(30年前のものも含む)を維持しながら最新の安全な設計を取り入れる必要
  • テストの不足: 膨大なコードベースをカバーする自動テスト体制が追いついていない
  • 技術的負債: Rustなどのメモリ安全な言語への移行を求める声もあるがC言語に固執せざるを得ない現状

■ 3. OpenSSLの組織改革(2024年〜)

• 二頭体制への分離(2024年3月〜):
  • OpenSSL Corporation(事業会社): 商用ユーザーや大口顧客を対象/サポート契約の販売/FIPS 140認証の取得など
  • OpenSSL Foundation(財団): 非営利コミュニティや個人開発者を対象/オープンソースとしての理念を守る
• 旧体制(OMC/OTC)の解散:
  • OMC(管理委員会)の解散(2024年3月): 代わりに10名の取締役会が意思決定
  • OTC(技術委員会)の解散(2025年4月予定): 代わりにTAC(技術諮問委員会)が新設され技術ロードマップの決定に透明性
• リリースサイクルの「予測可能性」の重視:
  • タイムベースのリリース(毎年4月と10月)に移行
• 組織改革の背景にある反省点:
  • 「身内感」の払拭: 閉鎖的な構造が外部からの批判を招いていた/新体制では選挙制を導入
  • 「商用優先」への批判回避: 組織を分けることでバランスを取る

■ 4. OpenSSL 4.0の野心的変更(2026年4月リリース予定)

• 過去10年以上の負債を一掃するための「大掃除」のリリース
• ENGINE APIの完全削除:
  • ハードウェアアクセラレータや独自の暗号モジュールを利用するための仕組み
  • 設計が古くメンテナンスの大きな負担
  • 「Provider(プロバイダー)」アーキテクチャに一本化
  • 独自のハードウェア支援を利用している古いシステムはProvider形式に書き換えない限り4.0に移行不可
• SSLv3のサポート完全終了:
  • 2015年に脆弱性(POODLE)によって完全に否定されたがコードとしては残されていた
  • 4.0ではSSLv3に関連するコードがライブラリから物理的に削除
• C99標準への移行とツールチェーンの刷新:
  • 非常に古いC言語規格(ANSI C/C89)をベースに書かれてきた
  • 4.0からはC99以降のコンパイラが必須
  • コンパイラの最適化が効きやすくなりパフォーマンス劣化を解消するためのコード整理が進めやすくなる
• スケジュール:
  • 2026年2月: コードフリーズ
  • 2026年3月: ベータ版リリース
  • 2026年4月7日: 正式リリース(予定)
• 4.0でのリセットはOpenSSLが「枯れたが重いライブラリ」から「現代的で筋肉質なライブラリ」へと再生できるかどうかの分水嶺

関連:

• The State of OpenSSL for pyca/cryptography

(2026/01/16)

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言語

• GitHub - yuuichieguchi/constela
• constela-dev.vercel.app/
• Constela: JSONでWebページが作れる不思議なプログラミング言語 #React - Qiita

要約:

■ 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年頃に一度認知していた
• 作者が感動して涙を流したみたいな記事があった気がする

関連:

• Crank.js

(2026/01/14)

UseCaseレイヤーって要るの？

• UseCaseレイヤーって要るの？

要約:

■ 1. 問題提起と背景

• レイヤリングへの疑問:
  • Controller -> UseCase -> Domainsというドメイン駆動なレイヤリングに対して本当にUseCaseは必要なのかという問いに向き合う
  • どちらもロジックを持ち得るレイヤーでどう棲み分けするのが良いのか
• 以前のアーキテクチャ:
  • MVCというレイヤー分けをしてそれ以外にレイヤーを増やさないという誤ったRails Wayへの則り方だった
  • 前任者の当時の判断は環境や状況にあったものだったかもしれないので悪いことだとは思っていない
• アーキテクチャの修正:
  • CQRSの考え方を導入しレイヤーを一枚増やした
  • controllerがdomainsに依存する構成に修正した

■ 2. 新たな課題の発生

• domainsの依存問題:
  • domainsがdomainsに依存してしまう状況が発生した
  • 複雑なロジックを共通化するにあたりdomainsがdomainsを呼び出す箇所が生まれた
  • ロジックを書く場所がdomainsもしくはmodelsしか現状無いため
  • 依存させたくないdomainsが依存を持ってしまうことになりアーキテクチャの破綻になってしまう
• UseCaseの必要性への疑問:
  • UseCaseはやはり必要なのではないかという考えが生まれた
  • しかしUseCaseを挟んだところで今Controller -> Domainsでうまくいっている箇所においてはただdomainsを呼ぶだけのUseCaseができる
  • あまりにそういうのが増えて冗長なのではないかという疑問が生まれた

■ 3. DomainsとUseCaseの役割

• Domainsの役割:
  • 主な役割はビジネスロジックの実装
  • 操作するものはDomainsオブジェクト
  • ビジネスルールはドメイン固有のルールを実装する
• UseCaseの役割:
  • 主な役割はユースケースの実装
  • 操作するものはDomainsクラス
  • ビジネスルールはユースケースに沿った手順を実装する
• 本質的な違い:
  • DomainsとUseCaseは全く異なるもの
  • Domainsはサービスを展開するビジネス上におけるドメイン知識を含む
  • Domainsがアプリケーションの知識を持つ必要は全く無い
  • Domainsのコードそのものがドメイン知識を持つドキュメントとしても在るべき
  • UseCaseはドメイン知識を纏ったDomainsをユーザーストーリーにあったユースケースの手順に合わせて実装されるもの
  • UseCaseがドメイン知識を知る必要はなくユースケースにあったDomainsを利用するだけで良い
  • だいぶ抽象化されたドメインという概念を扱うだけの裏の苦労を知らないお客さん的なイメージ

■ 4. UseCaseの必要性の検討

• 現状の構成:
  • ControllerがDomainsに直接依存しているアプリケーションという状況
  • UseCaseの導入による弊害もある
• UseCaseの弊害:
  • Controller -> Domainsでうまくいっている箇所においてはただdomainsを呼ぶだけのUseCaseができてしまう
  • 呼ばれたらdomainsを呼び出すだけという冗長なクラスが増えていってしまう
• 段階的導入の困難さ:
  • 全体にUseCaseを挟むというルールにするにはエンドポイント数的にも不可能なので段階的にはなる
  • そもそもUseCaseはoptionでいいんじゃないかという疑問が生まれた
• 相談結果:
  • 冗長なUseCaseは増やさずとも良い
  • Controllerから直接Domainsに依存したところで問題はない気がする
  • もし他の手続きが必要になったならUseCaseを挟むのはそこまで大変な作業ではない

■ 5. まとめ

• UseCaseの必要性:
  • UseCaseがなくても問題はない
• 役割の明確化の重要性:
  • Domainsにはドメインとなるロジックを抽出する
  • UseCaseはユースケースを実現するためのドメインを利用した手続きを書く
  • それぞれの役割を明確に意識することが重要
  • これはもちろんアプリケーションの実装ルール次第
  • それぞれの役割を明確に意識することでUseCaseにドメインロジックが生まれるなどの破綻を回避することができる

MEMO:

• 必要無いなら省略してもいいと思うけど、構造の一貫性という意味ではあってはいいかもの精神

(2026/01/14)

僕がフリーランスを続けなかった構造的な理由

• 僕がフリーランスを続けなかった構造的な理由｜すてぃお

要約:

■ 1. 記事の概要

• 2018年から2019年夏頃までの1年半フリーランスエンジニアとして活動した経験に基づく
• フリーランスになってどこかの会社で業務委託として働くスタイルは長期的にはオススメできない
• フリーランスとして業務委託で働く形態には経験が積みづらくなる構造的な力学が働いている
• 個人の努力や能力とは関係なくその構造の中にいると自然とそういう方向に引っ張られる

■ 2. フリーランス時代の振り返り

• 「経験を切り売りしていた」という感覚が強い
• お金は得られたが新しい経験はほとんど積めなかった
• 社会的な価値も全然つかなかった
• 市場価値としてはほとんど上がっていなかった
• 危機感を覚えたのでフリーランスを辞めCTOになった

■ 3. 構造的な問題1: 挑戦させてもらいづらい

• 業務委託に入ると基本的に「成功しそうなことしか任せてもらえない」状況になる
• クライアントからすれば外部の人間に失敗のリスクがある仕事を任せるのは怖い
• 正社員なら失敗しても一緒に成長していける
• 業務委託は失敗したら契約を切れば良いので確実にできることしか任せない
• 正社員は育成投資の対象になれるが業務委託はならない
• 得られにくい機会:
  • 新しい技術に挑戦する機会
  • 難易度の高いプロジェクトをリードする機会
  • 事業の意思決定に関わる機会
• フリーランスエンジニアが「得意なことをやり続ける」状態に陥る
• 効率は良いが成長はない

■ 4. 構造的な問題2: 社会的な評価が蓄積されにくい

• 「業務委託として開発」と書いても何をどこまで任されていたのかが見えない
• 「リードエンジニアとして事業を推進」と書けばオーナーシップを持って取り組んでいたことが伝わる
• 実際にやっていた仕事の内容が同じでも肩書きと立場で見え方が変わる
• フリーランスとして働いている間その経験がどんどん「消費」されていく
• 正社員として働くとその会社での実績が積み上がり次第により大きな責任を持つポジションに就く
• フリーランスの場合いくら長く働いても「外部の人」のまま

■ 5. 構造的な問題3: マネジメントや組織の意思決定に関われない

• エンジニアとして成長するには技術力だけでは足りない
• ある程度のキャリアを積んだ後は技術以外の能力が重要となる場合が多い
• 組織としての意思決定/マネジメント経験は組織の中で責任あるポジションに就かないと身につかない
• 外部の人間に組織のコアな部分を任せることはほとんどの会社がしない
• 採用の判断/チーム編成/評価制度/組織文化の形成は全て「中の人」だけで行われる

■ 6. この構造が生まれる根本的な原因

• 企業が「企業内人的資本の最大化」を目指すから
• 企業内人的資本 = 社員のスキル・知識・経験・ノウハウの総和
• 企業内人的資本が企業の競争力の源泉になる
• 正社員に投資すればその成長は企業内に蓄積される
• 業務委託に投資しても契約が終われば企業外に流出してしまう
• 正社員を雇う場合は長期的な視点で投資する
• 業務委託を使う場合は短期的な視点で考える
• 「投資対象かどうか」の違いが全ての構造的な問題の根源

■ 7. 例外: 労働市場の需給で変わるケース

• 「需要が供給を大きく上回るスキル」を持っている場合は状況が変わる
• 希少人材の例:
  • 特定の領域で日本に数人しかいない専門家
  • 世界的に見ても希少な技術スタックの経験者
  • 業界で名前が知られているレベルの実績がある人
  • オープンソースのメインコミッターなど代替不可能な立場の人
• こういった人はフリーランスであっても立場が強い
• これは例外中の例外
• ほとんどのエンジニアは「できる人が他にもいる」領域で仕事をしている
• 「自分は希少人材だ」と思い込んでフリーランスになるが実際にはそこまで希少ではなかったケースをよく見る
• 希少人材で居続けることができるかについてもよく考えるべき

■ 8. 「即戦力」という罠

• フリーランスが求められるのは即戦力
• 即戦力として評価されるのは「今持っているスキル」
• 新しいスキルを身につける機会ではなく既存のスキルを使う機会を与えられる
• 最初は問題ないが数年経つと技術は進化する
• フリーランスは「今持っているスキル」で契約しているから新しいことを学ぶ機会が少ない
• 正社員なら会社が新しい技術の研修を受けさせてくれることもある
• 業務委託は新しいことに挑戦するコストは自分で負担するしかない
• 「即戦力」として求められ続けることで皮肉にも「戦力としての価値」が下がっていく

■ 9. 社会資本という見えない資産

• 社会資本とは人間関係や信頼関係を通じて得られる価値
• 人脈/信用/評判/実績
• 正社員として働くと社会資本は自然と蓄積される:
  • 同僚との信頼関係
  • 上司からの評価
  • 社内での実績
  • 業界内での評判
  • 昇進による肩書き
• フリーランスの場合社会資本が蓄積されにくい
• 業務委託として入った会社の人との関係は契約が終われば薄れていく
• 毎回ゼロから信頼を築き直さないといけない

■ 10. 「自由」の代償

• フリーランスになる理由として多くの人が「自由」を挙げる
• 働く時間を自分で決められる/嫌な仕事を断れる/場所を選ばずに働ける
• しかしその自由には代償がある:
  • 挑戦の機会を得る自由は失われる
  • 成長する機会を得る自由も失われる
  • 責任あるポジションに就く自由も失われる
• 表面的な自由と引き換えにキャリアの自由度を失っている

■ 11. 構造から抜け出す選択肢

• 選択肢1: 正社員に戻る
  • 組織の中で責任あるポジションに就き挑戦の機会を得て社会資本を蓄積する
  • フリーランスの構造的な問題を根本的に解決する方法
• 選択肢2: 自分で事業を作る
  • 業務委託ではなく自分のプロダクトを持つ
  • 自分が意思決定者になりリスクも責任も自分が負う
  • 構造的な問題を「逆転」させる方法
• 選択肢3: 戦略的にフリーランスを使う
  • 長期間続けるのではなく特定の目的のために一時的に使う
  • キャリアの転換期に複数の会社を経験するため/特定のスキルを集中的に使って実績を作るため/正社員のオファーを見極めるため
  • 強い意志が必要

■ 12. キャリア早期にフリーランスになる人に向けて

• 20代から30代前半はキャリアの中で最も成長が期待できる時期
• この時期に「確実にできることしか任せてもらえない」環境に身を置くのはもったいない
• 経験の価値は「複利」で効く
• 20代で得た経験は30代のキャリアに効き30代で得た経験は40代のキャリアに効く
• フリーランスで「経験の切り売り」を続けるとこの複利が効かなくなる
• 10年後/20年後のキャリアを考えた時今どんな経験を積むかは決定的に重要

■ 13. まとめ

• フリーランスエンジニアが経験を積みづらくなるのは個人の問題ではなく構造の問題
• この構造は「投資対象かどうか」という違いから生まれている
• フリーランスになること自体が悪いわけではなく目的を持って期間を区切って戦略的に使うなら問題ない
• 問題はこの構造を理解せずにフリーランスを続けること
• フリーランスを選ぶならこの構造を理解した上で選ぶこと
• 定期的に「今の自分は成長できているか」「社会資本は蓄積されているか」を問い直すこと
• 表面的な自由や短期的な収入より長期的な成長とキャリアの自由度の方が結局は大きな価値を生み出す

MEMO:

• そもそもフリーランスというのは十分な経験を積んだベテランが選択するものであって、新卒や若手が選択するものではない
• 成長余地がある＝未熟者がやったところで単純な労働力を提供することしかできない
• ベテランは経験則や知見の提供という目に見えない資産を持っていて、それらを提供することが市場価値になる
• 組織に何かしてもらう、挑戦する機会を与えてもらうと考えている時点でそもそもフリーランスを選択するべきではない
• フリーランスに向いているのは「やっぱ組織で仕事するの向いてないな...」となった30代後半から40代の社会不適合者
• 同じ理由で新卒でSES企業に就職するのも悪手
• こちらもフリーランスと同じく役割が固定されがちで経験を積むことが難しい構造なので、若手が選ぶべきではない
• そもそもSES企業は案件に人間を放り込めば勝利なところがあるので育成を軽視している企業が大半
• 要領が悪い者は一生テスターみたいなケースが本当に発生し得る界隈である

関連:

• 誰も教えてくれなかった「フリーランスは厳しい」ではなく「甘い」という真実。

(2026/01/14)

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

関連:

• IT開発者向けの質疑応答（QA）サイト「Stack Overflow」で投稿数が激減、ユーザー戦慄

(2026/01/13)

ヒット作連発ゲーム開発者による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

関連:

• 「読者はAIだけ」ライターの新たな仕事と”2026年問題”とは | 新聞紙学的

(2026/01/11)

ニューヨーク市長就任式、ラズパイと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」

• プログラミングみたいに音楽を作れる「Strudel」 - GIGAZINE
• Strudel REPL

(2026/01/06)

新卒エンジニアで「1日3~4時間だけ集中してコードを書いて、残り時間は Slack を徘徊する」みたいな...

新卒エンジニアで「1日3~4時間だけ集中してコードを書いて、残り時間は Slack を徘徊する」みたいなゆるい働き方を覚えてしまってからそこから抜け出すのにかなり苦労したし、抜け出せない人は一定数いる

@uiu______

MEMO:

• それが定年まで続くならそれでもいいんだろうけどね

(2026/01/06)

Claude Codeで記憶領域を持つための独自のAgent Skillsを使っている

• Claude Codeで記憶領域を持つための独自のAgent Skillsを使っている

MEMO:

• 自分の場合は設計や実装方針は原則Markdownのファイルに出力させていて、コンテキストをあまり使わないようにしている
• ファイルに出力すれば確認・修正も楽だし、コンテキストをクリアしてClaude Code自身にレビューさせることもできる

(2026/01/05)

PublickeyのIT業界予想2026。メモリ高騰による消極的なクラウド選択、AIエージェントを前提とした開発...

• PublickeyのIT業界予想2026。メモリ高騰による消極的なクラウド選択、AIエージェントを前提とした開発方法論、Rust採用の広がりなど － Publickey

要約:

■ 1. 記事の概要と2025年の振り返り

• 2026年1月5日に公開されたPublickeyによるIT業界予想である
• 2025年を振り返ると生成AIに始まり生成AIに終わると言っても良いほど話題の中心のほとんどに生成AIがあった年だった
• 2026年も生成AIが注目されることは間違いないがその位置づけは2025年とはまた少し違ったものになる
• 生成AI以外にもIT業界には注目すべき動向がいくつも存在する

■ 2. 国際情勢とIT業界への影響

• 2025年1月に米国大統領にドナルド・トランプ氏が就任したことはこの1年で最も大きな影響を世界の政治や経済に与えた出来事だった
• トランプ大統領が就任直後から強引に推進した相互関税はこれまで進展してきた国際自由貿易の停滞や逆転を引き起こした
• コンピュータ関連の製造業を含む多数のグローバルな製造業のサプライチェーンに見直しを迫るものとなった
• ロシアによるウクライナへの侵略における和平交渉での米国の姿勢がロシア寄りであるとして欧州は米国への不信感を募らせつつある
• 日本で高市早苗氏が首相に選ばれたことは国内の伝統的な価値感を重視するとされるいわゆる保守的な志向の高まりを反映したものと推察される
• 1年前のIT業界予測で「高くなる国境続く円安と人手不足」として国際的な緊張の高まりとインフレが続くだろうという認識を示したがこれは1年が経過した現在も継続している

■ 3. ITと政治の関係の可視化

• トランプ大統領の就任式にはGoogleのスンダー・ピチャイCEO・Appleのティム・クックCEO・メタのマーク・ザッカーバーグCEO・Amazon.com創業者のジェフ・ベゾス氏らが巨額の寄付を行うとともに出席することが年初に大きく報道された
• 新たに設立されたDOGE(政府効率化省)はテスラやX/Twitterのオーナーであるイーロン・マスク氏が主導している
• オラクル創業者のラリー・エリソン氏は影の大統領と呼ばれるほどトランプ大統領と近しい関係にあると報道されている
• ITと政治との距離がかつてないほど近いことが可視化された一年だった
• 米国のみならず世界中でITは各国の安全保障に関わる重要事項となりつつあることなどからもITと政治の距離はさらに近づいていくことになりそうである

■ 4. AIへの大規模投資

• 2025年のAIの進化と普及そしてその将来性はIT業界のみならず株式市場などからも大きな注目を集めた
• NVIDIAの時価総額は2025年7月に世界初の4兆ドル(1ドル155円換算で620兆円)を突破しアップルやマイクロソフトを抜いて時価総額世界一となった
• 日本企業の時価総額1位はトヨタ自動車で約53兆円日本の国家予算(一般会計)は約117兆円である
• AIブームの勝者になるべくGoogleやマイクロソフト・Amazon.com・Facebook・OpenAI・オラクル・ソフトバンクなどをはじめとする多くの企業が驚くような額の資金調達やAIデータセンターへの積極投資などを発表している
• 2025年後半にはこれらの大規模投資は本当に将来の利益となって回収できるものなのかという疑念も一部でささやかれるようになっている
• その疑念への答えがはっきりするのは数年後のことだと思われるがすでにオラクルの株価が急落するなどの動きが見え始めている
• 2026年の株式市場はもしかしたらそうした予測を早くも織り込むようになるのかもしれない

■ 5. メモリ価格の高騰

• 年末に突如始まったメモリ価格の高騰がAIデータセンターへの大規模投資が引き起こした事象として表面化した
• 2025年12月3日に半導体メモリの製造販売大手であるマイクロンテクノロジーがコンシューマ向けブランド「Crucial」でのメモリとSSDの販売終了を発表した
• AIデータセンター向けのメモリ需要の高まりからコンシューマ向けのメモリ不足が起きそれによってメモリ価格が高騰しているとされている
• 価格高騰はSSDやHDDなどメモリ以外の部品にも波及している
• 多くの日本企業が2026年4月から始まる新年度の予算を作成している時期であり来年度のPCやサーバ・ストレージの調達計画を立てているところである
• メモリだけでなくSSDやHDDもどこまで値上がりが続くのか見通しが難しい現在この価格の不透明さはいずれ企業向けのサーバなどの調達にも影響を及ぼしそうである

■ 6. 予想1:サーバ調達価格高騰による消極的なクラウド化

• 2025年12月末に国内の多くのBTOベンダ(マウスコンピュータ・ツクモ・ドスパラ・サイコムなど)が相次いで受注停止や値上げなどを発表した
• メモリ価格の高騰が続くことを見越して早めにPCを調達しておこうと考えた消費者の増加によりBTOベンダの想定を大幅に上回る受注が発生した
• メモリ価格の急上昇によるBTOベンダの仕入れ価格の急上昇などが重なったことが理由である
• メモリ価格の高騰はこれから企業が従業員用のPCやオンプレミス用のサーバの調達にも影響するであろうことは十分に予想される
• 特に多くのメモリを搭載するサーバの調達価格の見通しは非常に不透明にならざるを得ない
• 予算計画を立てたとしても実際に発注してみたら予算に対して十分なサーバの台数が調達できなかったという可能性もある
• 一方で長期で大量のサーバ調達契約をしていると思われる大手クラウドベンダの利用料金が急に上昇する可能性は低い
• 新たにオンプレミス用のサーバを調達する際の価格の不透明さを嫌って安定的に調達できるであろうクラウドを選択する合理性が高まりそうである
• 2026年は通常のクラウド移行に加えてこうした不透明なサーバ調達価格を理由にある意味で消極的にクラウドを選択するというシステムが増加するのではないか

■ 7. 予想2:AIエージェントを前提とした開発方法論の勃興

• 開発チームに指示したことを文句も言わず何でも実行してくれて昼も夜も24時間365日文句も言わずにずっと働き続けることができてしかも通常の人件費よりずっと安価なメンバーを何人も採用できるとしたらそのメンバーにいつどんな作業を依頼するか
• それによって既存のメンバーの役割や働き方はどう変わっていくべきか
• 既存の開発手法や方法論はそのままでよいのか
• 人間とは異なる能力と働き方とコストを備えたメンバー=AIエージェントが開発チームに迎え入れられようとしている現在これまで人間だけで構成されていることが前提であった開発方法論・メンバーの役割・働き方・コラボレーションツールなどを人間とAIエージェントの混成チームを前提としたものに最適化するべく多くの組織で試行錯誤が始まっている
• それは以前GoogleがSRE(Site Reliability Engineering)として新しい運用エンジニアのあり方を提唱したりあるいはアジャイル開発のコミュニティからアジャイル開発宣言が発表されたりするようにどこかのベンダからあるいはどこかのコミュニティから提案されるのかもしれない
• 2026年のAIエージェントはそれ単体や連携による能力進化だけでなくAIエージェントを前提とした新たな開発方法論や手法・コラボレーションツールなどAIエージェントを取り巻く環境との組み合わせによって進化していくものになるのではないか

■ 8. 予想3:企業などへのサイバー攻撃が続く

• 2025年は社会的に大きな被害をもたらしたサイバー攻撃が目立つ年だった
• 1月には警察庁が中国の関与が疑われる日本国内へのサイバー攻撃に注意喚起を公開しおもに日本の安全保障や先端技術に係る情報窃取を目的としていると説明しサイバー攻撃は国家の安全保障と深く関わっていることを広く印象づけた
• 2月にはサンリオが不正アクセスを受けてサンリオピューロランドの新規の来場予約ができない事態を引き起こした
• 3月には楽天証券やSBI証券を始めとした複数のネット証券においてフィッシング詐欺やマルウェアなどによると見られる証券口座の乗っ取りが多数発生したことが明らかとなって数千億円規模の被害が発生した
• その後多くのネット証券がこの被害を補償することを発表している
• 9月にはアサヒグループホールディングス10月にはアスクルが相次いでランサムウェアによるサイバー攻撃を受け製品出荷が停止する大きな被害を受けた
• こうしたサイバー攻撃はAIの進化によって以前よりさらに巧妙かつ洗練されてきている一方で攻撃を受ける側の多くの組織の防御体制が十分ではないのが現状である
• 2026年も残念ながら国家間の緊張が高まるなかで国家が関与するサイバー攻撃が減ることは考えにくくネットにつながれたシステムの上で金銭的価値の高い情報のやり取りがますます増加する中でそれら金銭的価値の取得を目的とした攻撃も減ることはない
• 多くの人にとって身近な企業がサイバー攻撃を受け被害額の補償や長期の出荷停止など多額の被害を受けたことがテレビや新聞・雑誌などで広く報道された結果これをきっかけに以前より多くの企業や組織でセキュリティの議論が高まったとの声も聞く
• 2026年は多くの企業にとってセキュリティ体制を見直し強化する年になってほしいと願っている

■ 9. 予想4:Rustの採用が本格的に広がる

• Rust言語は以前から多くのITエンジニアに注目されているプログラミング言語だった
• C言語のように低レイヤのシステムの記述を得意とし不正なメモリ領域を指すポインターなどを許容しない安全なメモリ管理やマルチスレッド実行においてデータ競合を排除した高い並列性を実現している点などの特長を備えている
• コンパイル型の言語として安全かつ高速なネイティブバイナリを生成してくれる
• 米政府は2024年に「将来のソフトウェアはメモリ安全になるべき」との声明を発表しそのためのプログラミング言語の1つとしてRustを挙げている
• Rust言語はその高い注目度に対して実際の開発プロジェクトでの採用例は十分ではなかった
• これはそもそもRust言語の得意分野が低レイヤのシステム開発という比較的ニッチでありしかもプログラミング言語の変更に保守的な領域であるという背景もある
• 2025年にRust言語の利用は広がりを見せていた
• これまでLinuxのカーネル開発におけるRust言語の使用は実験的な位置付けとされていたが2025年12月に東京で行われたMaintainers SummitにおいてRustの使用はもはや実験的ではないとされ正式な採用が決定された
• マイクロソフトも2030年までに自社の主要コードベースからC/C++を全面的に排除しRustへ移行する方針を明らかにしたと報道されている
• AWSが2025年11月にAWS LambdaがRust言語を正式にサポートしたと発表した
• RustはこれまでAWS Lambdaでよく利用されてきたNode.js/JavaScriptやJava・.NET・Pythonなどのプログラミング言語と異なりネイティブバイナリを生成するコンパイル型言語である
• これによりインタプリタやJITコンパイラを用いたプログラミング言語と比較して高速な起動と実行そして実行時に必要なメモリ容量が小さくて済むなどの利点がある
• サーバレスコンピューティングにおいてこれは高速な起動および省メモリなどの効率的なコンピューティングリソースの面で非常に大きなアドバンテージである
• AWS Lambdaという広く使われているアプリケーションプラットフォームでRust言語を用いてアプリケーションが書けるようになったということがRust言語の活用範囲を大きく広げる
• 2026年はRust言語の高い注目度が採用事例へと積極的に移行していくことになるのではないかと期待を込めて予想する

(2026/01/05)

IT業界に蔓延する『ナンニデモPM』 それ、本当にプロジェクトマネジメント？

• IT業界に蔓延する『ナンニデモPM』 それ、本当にプロジェクトマネジメント？ #プロジェクト管理 - Qiita

要約:

■ 1. 問題提起と記事の目的

• IT業界におけるプロジェクトマネージャー(PM)に技術力は必要かという議論が存在する
• PMには技術的判断力(技術リテラシー)が必要だが実装スキルとは異なる
• 現場ではPMに過度な業務範囲が求められる「ナンニデモPM」案件が存在する
• 本記事ではPMの役割定義、必要な技術力のレベル、ナンニデモPMの危険性、不適切な求人について建設プロジェクトの例えを用いて整理する

■ 2. ITプロジェクトと住宅建築の類似性

• ITシステム構築は家づくりのプロセスに例えることができる
• 住宅建築における役割分担:
  • 施主(クライアント)は要望を出し対価を払う
  • 設計(アーキテクト)は要望を構造的に可能な形に設計し設計責任を持つ
  • 施工管理(PM)は予算・工期・品質を管理し現場調整を行う
  • 職人(エンジニア)は設計図に基づき実際に家を形にする
• 各役割が明確に分かれているのが本来の姿である

■ 3. ケーススタディ:メンバー欠員時の対応の違い

• 住宅建築で大工が1名欠員になった場合の施工管理の対応:
  • 追加要員(職人)の手配
  • 工程の組み替え(優先順位変更・段取り替え)
  • 必要に応じて施主に事情説明し納期調整
  • 施工管理が自ら大工作業を代行することはまず無い
• IT業界でアプリエンジニアが1名欠員になった場合:
  • 本来は追加要員調整・影響範囲見極め・スコープ優先順位納期交渉を行うべき
  • しかし実際はPMがエンジニアを兼務して穴埋めすることが多発する
  • PMが自らコーディングしてカバーすることが美徳として語られる
  • 一度発生すると常態化し最終的に全部盛り何でも屋さんPM(ナンニデモPM)が誕生する
• ナンニデモPMの状態:
  • 本来の管理業務を捨て設計(アーキテクト)や構築(エンジニア)の穴をPMが自らの技術力と稼働時間で埋め続ける
  • 若手のOJTまで背負い込みPMのリソースが完全にパンクする末期的状態

■ 4. PMの正しい役割定義

• IPA(情報処理技術者試験のシラバス)によるPM人物像:
  • プロジェクトマネージャはレベル4(高度)で実装ではなくプロジェクトを成立させるためのマネジメントを扱う
  • 立ち上げ段階では目的・成功条件・体制・制約の定義を行う
  • 計画段階ではスコープ・スケジュール・コスト・品質・リスク・調達・コミュニケーション・ステークホルダーを扱う
  • 実行監視段階では進捗把握・課題変更管理・意思決定・合意形成・是正を行う
  • 終結段階では受入れ・引き継ぎ・振り返り(ナレッジ化)を実施する
  • PMが設計実装に深く入りすぎると論文試験の評価が落ちる
• PMBOK(第8版)によるPM人物像:
  • プロジェクトマネジメントの標準知識体系を広い文脈で整理している
  • 価値提供(Value Delivery)を重視する
  • 状況に応じたテーラリング(Tailor)を行う
  • 予測型もアジャイルも含めた複数のやり方の取捨選択を行う
  • PMCDフレームワークでPMの専門性を知識(ITSS相当)・実行力(成果を出す能力)・パーソナル(リーダーシップ倫理)の3次元で定義している
  • 実作業の代行は明記されていない

■ 5. PMに求められる技術力の定義

• 判断できる技術力の要素:
  • 専門家や技術者の発言を理解できる(共通言語の理解)
  • トレードオフを比較できる(コスト期間品質リスク拡張性など)
  • 赤信号を検知できる(やってはいけないことがわかる)
  • 質問ができる(何を誰に聞けば不確かさが減るかプロジェクトが前に進むかがわかる)
  • 意思決定の前提条件を揃えられる(論点選択肢根拠影響範囲)
• PMが必ずしも持つ必要がないもの:
  • 特定言語の実装力(Javaで高速に書ける等)
  • 特定クラウドの深い構築スキル(AWSの各種サービスの設計運用を一人で回せる等)
  • 特定プロダクト特定領域の属人的な運用ノウハウ(細かなチューニングや手順の暗黙知までを一人で抱える等)
• PMが目指すべきは「スペシャリスト」ではなく「指揮官」のような立ち位置である

■ 6. 判断できる技術力の具体的目安

• IPAのITSS Level3(応用情報)の守備範囲が判断できる技術力のベースとなる
• 応用情報の範囲はテクノロジだけでなくマネジメントストラテジまで含むためPMが判断するための最低限の共通言語共通理解になる
• テクノロジ系基礎理論コンピュータシステム分野:
  • アーキテクチャ概念・仮想化クラウド・OSSの基本を理解する
  • アーキテクト提案の実現可能性・コスト運用負荷・拡張性をトレードオフ評価できる
• テクノロジ系技術要素分野:
  • セキュリティ・データベース・ネットワークを理解する
  • インシデント時の初動判断・変更時のリスク特定・非機能(性能可用性)議論の前提を揃える
• テクノロジ系開発技術分野:
  • 要件定義からテストの流れ・品質・DevOps・CI/CDを理解する
  • 予測型アジャイルの向き不向き・品質確保の打ち手・リリース設計(ゲート自動化)の判断ができる
• マネジメント系プロジェクトマネジメント分野:
  • 工程・コスト・品質・リスク・資源・調達・変更管理を理解する
  • 気合ではなく数値と根拠で意思決定できる(見積りバッファクリティカルパスリスク対応)
• マネジメント系サービスマネジメント監査分野:
  • 運用設計・ITILの考え方・監査内部統制の観点を理解する
  • 作って終わりにしないためSLA運用負荷保守体制を踏まえて意思決定できる
• ストラテジ系システム戦略企画分野:
  • 目的・ROI・要求の優先順位・調達の考え方を理解する
  • やる理由とやらない理由を整理し投資として説明できる(優先順位スコープ調整ができる)
• ストラテジ系企業活動法務分野:
  • 契約・個人情報・知財・下請取引・コンプラを理解する
  • 契約リスク・情報漏えいリスク・体制責任分界の事故りやすい点を早期に潰せる

■ 7. ナンニデモPMが危険な理由

• PMがPMできなくなることがシンプルな危険性である
• 全部盛りPMが発生しやすい要因:
  • そもそもアーキテクトテックリード不在(または役割が曖昧)
  • 人手不足で追加要員がすぐ手配できない
  • 予算制約が強く「できる人がやるしかない」状態になる
  • 兼務の前提でスケジュールが組まれている(最初から無理)
  • 技術課題が表面化して火消しが常態化している
  • 変更管理が弱く後半に仕様追加が雪だるま式に増える
  • ベンダ委託先の責任分界が曖昧で結局PMが吸収する
  • ドキュメント標準化が弱く属人化して引き継げない
  • 管理が事務作業と誤解され軽視される
• PMが実装側に寄った場合の弊害:
  • ステークホルダー調整が遅れる(意思決定が詰まる)
  • 進捗の見える化が遅れる(気づいたら手遅れ)
  • リスクの早期潰しができない(後半で大爆発)
  • 品質ゲートが機能しない(テストレビューが薄くなる)
  • メンバーのモチベーションが低下する可能性がある(全部PMで良くなり自分達の存在意義が不明になる)
  • 結果としてQCDが落ち炎上しやすくなる
  • 炎上すると社内外のエグゼクティブ層の関与が増え更に報告が増える(悪循環)
  • 最終的にデスマーチと化する

■ 8. 小規模案件における兼務の妥当性

• 小さい規模の仕事なら1人が複数ロールを兼ねるのは自然である
• 住宅で言えばDIYでありITでも同様である
• 兼務が妥当なケース:
  • チーム内の業務効率化の小ツール(ローコードスクリプト)
  • 小規模なRPA自動化(定型作業の削減)
  • 既存SaaSの設定変更や軽微な連携(影響範囲が限定的)
  • PoC(失敗前提で学びが目的でスコープが小さい)
  • 高いレベルの品質や厳格なスケジュールを求めない案件
• このレベルならそもそもPMは不要でありリーダー担当者くらいの呼び方で充分である
• DIYレベルなら兼務は問題ないが本当にDIYレベルに限られる

■ 9. 不適切なPM求人の特徴

• 求人票でPM募集と書かれているのに内容はPM兼テックリード兼アーキテクト兼エンジニアのような案件が存在する
• 求めていることを全て書くこと自体は悪くないが役割名がズレていることが問題である
• ナンニデモPMの求人例の特徴:
  • 仕事内容にQCD管理・交渉折衝に加えてアーキテクチャ策定・クラウド基盤構築・チューニング・バグ修正・コードレビュー・技術指導が含まれる
  • 必須スキルにPMの資格経験に加えてクラウド構築経験5年以上・開発経験5年以上・IaC実装経験・大規模DB設計運用経験・育成経験が要求される
  • 求める人物像に「自分が最後の砦である自負」「スピード感を持って自ら手を動かして解決できる」「様々な難問に立ち向かい自分事で成し遂げる」が記載される
• マネジメントのプロと実装のプロを両方求めている状態は両方をプロレベルで同時進行できる人が市場にほぼ存在せず数千万円の年収が必要である
• 「他人に頼らず自分の稼働時間で問題を力技解決しろ」というのはマネジメントの否定でありプロジェクトだけでなくメンバーの心身も危険にさらす
• 健全なPM求人の特徴:
  • 仕事内容はQCD管理・変更管理・期待値調整合意形成・技術的リスクの早期検知と意思決定・WBS策定進捗管理・課題解決に向けたリソース再配置・収益利益率管理と予算コントロールに限定される
  • 必須スキルはプロジェクト管理手法の体系的理解と実践経験・高度専門資格保持・大規模プロジェクト完遂経験・技術的課題をビジネス的リスクやコストに翻訳できる能力・複雑な利害関係を紐解き着地点を見出すファシリテーション能力・技術の専門家を信頼し適切に仕事を任せるデリゲーションスキルが記載される
  • 求める人物像は「個人の技術力ではなくチームの成果を最大化することに喜びを感じる」「不確実な状況下でも冷静に情報を収集し論理的な意思決定を下せる」「技術者への敬意を持ちつつ客観的な視点でプロジェクトの健全性を評価できる」が記載される
• PMに求められるのは自分が手を動かして解決する力よりもチームが解決できる状態をつくる力である
• メンバーを信用し適切に任せ必要な情報と判断材料を揃え合意形成と障害除去を通じて前に進める
• プロジェクトは個人戦ではなくチーム戦として勝つためにPMは自分でやるよりもチームでやるを選ぶべきである
• 「自ら手を動かして解決できる方」という表現はPMの人物像としてミスマッチを生みやすい
• 自ら手を動かすことが必要な場面はあるがそこを前面に出すほどPMが本来担うべきマネジメント(QCDリスク合意形成)が後回しになり結果としてプロジェクトが不健全になる

■ 10. まとめ

• PMに技術力は必要である
• PMに必要な技術力は実装できる力ではなく判断できるための技術力である
• 目安としてIPAレベル3(応用情報)相当の知識を持つことは有効でわかりやすい指標である
• 役割が全部盛りになるとPMがPMできずプロジェクトが壊れやすい
• 兼務が必要なケースはあるがその場合は役割名と期待値を揃えた方がよい(少なくともPMだけでは違和感がある)

(2026/01/05)

2026年AIコードレビューの旅 ～そしてボトルネックは要件定義へ…

• 2026年AIコードレビューの旅 ～そしてボトルネックは要件定義へ…

要約:

■ 1. AIのコード生成能力の向上と人間のコードレビューの限界

• 現状のAIコード生成:
  • 現状まだ酷いコードを生成することが多い
  • ここ1年を振り返るとAIが生成したコードからクラスを切り出してることが多かった
• 2026年の予測:
  • おそらく2026年にはだいぶ洗練されるのではないかと予想している
  • 画像生成AIが気づいたら指6本画像を生成しなくなったように
• コードレビューの物理的限界:
  • いよいよボトルネックになるのは人間のコードレビュー
  • 現状でも既にコードレビュー結構しんどい
  • 今後仮に毎日100万行のコードが生成される世界になるとすると1日8時間稼働として1時間で約12万行読まないといけなくなる
  • 1時間に12万行って単にニュース記事を読むのでも無理
  • 8時間ひたすらコードレビューするの自体無理
  • 土日もコード生成され続け月曜朝には200万行のレビューが待っている

■ 2. 2026年のAIコードレビューの台頭

• 既存の自動化状況:
  • 現状既に静的解析やセキュリティチェックや脆弱性診断は一定Botで可能になっている
  • AIのコードが洗練されるのであればそもそも設計不備や既存コードとの不整合などのコードレビューは不要になる
  • 必要になるのは今後の拡張性やそもそもの品質チェック
• 参考となる既存事例:
  • 量が多すぎて全部は見られない会計監査や製造業の品質管理が参考になる
  • AIコードレビューはかなりの確率でこれらの手法を輸入した形になると予想している
• 全数検査の放棄:
  • 会計監査も工場検査もまず全数検査を諦めている
  • 会計監査ではリスクが高い領域を重点監査する
  • 工場では抜取検査やSQCが一般的
• 未来のコードレビュー手法:
  • 現状のコードレビューは全行チェックが当たり前だが今後はこれら手法に収斂していく
  • 基本的にはAIはSQC的にバグや品質を傾向分析する
  • リスクが高い領域のごく一部を時々人間にレビューするように指示する
  • そのサンプリングレビュー情報をSQCに反映する形になる

■ 3. 次のボトルネックとしての要件定義

• コードレビュー後のボトルネック:
  • コードレビューがAIに置き換わってもボトルネックはなくならず次に移る
  • 次に詰まるのは要件定義
• 要件定義の速度変化:
  • 人間が精緻に要件定義して3ヶ月かかるところを人間が雑にAIに振ってAIが3分で要件定義するようになる
  • 人間が要件定義に3ヶ月かけていたら市場競争に勝てないようになる
• 特に懸念している問題:
  • 牛乳を1つ買ってきて卵があったら6つお願い問題

■ 4. 牛乳を1つ買ってきて卵があったら6つお願い問題

• ジョークの内容:
  • プログラマの夫に買い物を頼む妻が牛乳を1つ買ってきて卵があったら6つお願いと頼む
  • すると夫が牛乳を6パック買ってきた
  • 妻がなんで6パックも買ってきたのと聞くと夫はだって卵があったからと答える
• AIの対応:
  • この質問を生成AIにするとちゃんと牛乳を1つと卵を6個買ってくれる
  • ところがこれが逆に困ったことになる

■ 5. スクラッチ開発の目的

• パッケージとスクラッチの違い:
  • ちゃんと牛乳を1つと卵を6個買ってくれるようなシステムが欲しいのであれば業務システムであれば正直ERPなどをそのまま使えばいい
  • なぜわざわざスクラッチ開発をしたりあるいは原形をとどめないほどのカスタマイズをするかというと俺の考える最強のシステムや牛乳を6パック買わせるシステムを作りたいから
• AIエージェントの出力傾向:
  • AIエージェントに雑に振ると要件は最大公約数的なや平均的なものを出力する
  • 変な要件やこだわりの要件を盛り込もうとすると細かく書いてやるしかない
  • 牛乳を6パック買わせようとすると牛乳を1つ買ってきてもし卵が売っていた場合は卵は買わずに牛乳を6本買ってきてと要件を伝える必要がある
• 詳細な要件定義の負担:
  • これくらいであればそこまでの負担ではないし正直本来の要件定義とはこういうものだろう
  • しかし今後の未来はこれを書いてる脇で雑に要件を振って爆速で堅牢なシステムが生まれるものたちとの競争が待っている
  • 1つのこだわりが要件定義を遅らせコーディングやレビューを遅らせる
  • 特殊要件のためAIが十分整合性を取れずバグの温床になる可能性も増す
• 生産性競争の帰結:
  • 今後はこのようなこだわりや俺の考える最強のシステムを作ろうとすると生産性で負ける世界になる
  • 要件は平準化や一般化されていく

■ 6. パッケージソフトウェアへの回帰

• スクラッチ開発の必要性の喪失:
  • 要件が平準化や一般化されていくとそもそもスクラッチ開発の必要性がなくなっていく
  • SAPをノンカスタマイズで使うやSalesforceをそのまま使えばいい
  • AIに要件定義や開発させても出てくるものは同じなのだから
• ERPへの回帰:
  • まさかの1周回ってERPに業務を合わせるが合理的な世界になる

■ 7. ベンチャー・スタートアップの開発の行方

• 残る可能性の検討:
  • 標準化された業務はERPでいいかもしれないがまだシステム化されていないベンチャーやスタートアップ領域のシステム開発は残る
  • そもそも要件も一般化されていないので人間が要件定義しなければならない領域はベンチャーやスタートアップに残る
• 実際の予測:
  • 残念ながら以下のような流れになると予想している
  • ERPや既存SaaSの生産性が異常に高くなる
  • AI前提で最適化される
  • スクラッチで作るコストが相対的に高騰し経済合理性がなくなる
  • ベンチャー・キャピタルがベンチャーやスタートアップに投資する経済合理性がなくなる
  • 誰も投資しなくなり結果誰もやらなくなる
• 結論:
  • だいたいの業務が既存SaaSやパッケージで足りるようになる
  • 結果ベンチャーやスタートアップがやる意味や意義とはという問いがnode_modules級に重くなる

■ 8. まとめ

• 提言:
  • もうみんなSAPやSalesforceで働こう

(2026/01/04)

2025年、これが良かったClaude Code開発テクニック

• 2025年、これが良かったClaude Code開発テクニック

(2026/01/04)

IT人材不足への対策としてNTTデータがシステム開発に生成AIを活用「で、誰が保守するんだい」...

• IT人材不足への対策としてNTTデータがシステム開発に生成AIを活用「で、誰が保守するんだい」「成功したらプロジェクトX」 - Togetter

MEMO:

• 案外イケるんじゃないかなぁと思うのだが
• 要件定義や機能要求がしっかりしてれば、それなりの品質のコードが生成されるのは分かってるので
• そして、要件定義や機能要求のドキュメント作成こそ彼らの本業みたいなものなわけで
• 今まで下請けがやっていた部分をAIに任せるだけなので、存外変わらないのではないかなと

(2026/01/03)

AIエージェント時代、正直しんどい話

• AIエージェント時代、正直しんどい話

MEMO:

• ほぼ全てレビューしかしてない問題は確かにそう

(2026/01/02)

プレイングマネージャーを「努力」から「構造」の問題に戻す── SaaS組織で起きた意思決定の話──

• プレイングマネージャーを「努力」から「構造」の問題に戻す── SaaS組織で起きた意思決定の話──｜本多 将大

要約:

■ 1. 記事の背景と目的

• 本多将大によるnote記事である
• 2025年も周りの皆さまのおかげで多くの学びを得ることができた
• 資金調達フェーズでいうとシリーズA以降B未満従業員数の規模でいうと50名未満のSaaS企業の営業部での学びを言語化する
• 少しでも他の人の役に立てたらと思いnoteに残すことにした

■ 2. プレイングマネージャーの課題認識

• プレイングマネージャーは個人に依存しやすい役割である
• 能力やスタミナに支えられた運用は短期的には機能するが再現性やスケールの観点では限界が見えやすい
• 営業部においてもプレイヤーとしての成果とマネジメントとしての成果を同時に求める構造が結果として意思決定の質とスピードを下げている場面があった
• この状況を踏まえ営業部ではプレイングマネージャーという役割を努力やバランス感覚の問題ではなく構造の問題として捉え直すことにした

■ 3. 役割の切り出しと意思決定レイヤーの独立

• 営業部ではこれまで実行と判断が同じレイヤーに存在していた
• その結果施策は「やる・やらない」という議論に収束しやすく本来行うべき評価や選別が後回しになる傾向があった
• そこで施策を実行単位として扱うのではなく企画として独立させ意思決定レイヤーを切り出す運用へ移行した
• これにより意思決定は施策そのものではなく定量の可視化・データに基づく分析・分析結果を踏まえた施策選択を起点に行われるようになった
• 結果として施策は属人的な打ち手ではなくKPI改善に対する投資判断のアウトプットとして整理された
• 限られたリソースをどこに配分すべきかを選択できる状態がつくられている

■ 4. マネージャーの能力を組織の上限にしない設計

• この運用変更を通じて明確になった点がある
• それはマネージャー個人の能力や判断が組織の上限を規定してしまうリスクである
• 営業部のマネージャーがプレイヤーとしても深く関与する構造では判断の幅や試行回数が個人のキャパシティに制約されやすい
• 意思決定を企画レイヤーに集約することで経験や勘への依存を抑えつつこれまで現実的ではなかった打ち手も冷静に検討できるようになった
• 営業部の上限は人の能力によって自然に決まるものではない
• 設計次第で引き上げられるものだという認識に変わってきている
• この構造設計と運用は企画が主導して前線を担い営業部のマネージャーである私はその設計と判断に対する最終責任を持っている

■ 5. 育成の構造化

• 営業部における育成も同様に構造化している
• 正解を言葉で説明することよりもどのような判断基準で意思決定しているかを共有することを重視している
• 具体的には商談への同席などを通じて実例を提示する
• その後になぜその言葉を選んだのか・なぜそのプランその金額なのか・なぜその時間軸で提案したのかといった判断理由を言語化して補足する
• これにより個別の成功体験ではなく再現可能な判断軸として営業部内に知見が蓄積されていく
• 特にARPAを引き上げる文脈では成果の共有よりも判断基準の共有が有効に機能している

■ 6. 人材の捉え方と配置の考え方

• 営業部では人を単なる人数や稼働時間といった固定的なリソースとしてではなく前提条件の異なる存在として捉えている
• 能力差は確かに存在するがそれは優劣よりも強み・経験・得意な局面の違いによるものだと考えている
• そのため成果は本人の能力だけで決まるのではなく配置の仕方や期待の置き方・関与の度合いによって大きく変わる
• 実務では定量で傾向を把握したうえで担ってもらう役割・求めるアウトプットの水準・マネージャーや周囲の関与の深さを調整しながら再現性のあるアウトプットをつくることを重視している
• 新しく営業部に加わったメンバーについては早く組織に馴染んでもらうことよりも短期間で一つ成果を出せる状態をつくることを優先している
• 小さくても成果が出ると仕事の進め方や関係性への理解が進み結果として信頼や一体感は後から自然についてくる

■ 7. 結論

• プレイングマネージャーという役割は個人の頑張りによって成立させるものではない
• 意思決定のレイヤーは分離されているか・判断は定量と分析を起点に行われているか・人の特性が構造として活かされているかを前提条件として運用を見直すことで成果が変わることを実感してきた
• 営業部のメンバーと仕事をする中で形づくられてきた学びに感謝しつつ2026年もみなで良い年にしたい

(2026/01/01)

1on1で「まずこれを読んで！」と布教し続けるそーだいさんの言語化集

• 1on1で「まずこれを読んで！」と布教し続けるそーだいさんの言語化集 - そーだいなる Advent Calendar 2025 20日目｜mkitahara / きたはら

要約:

■ 1. 仕事を進めるうえでのマインドセット

• Howだけ考えると複雑さを導入して仕事が増える:
  • Howだけ考えると複雑さを導入して仕事が増える - そーだいなるらくがき帳
  • 手段に没頭して手順書の保守や不要な会議などの偽の進捗に陥るとリソースを枯渇させてしまう
  • Howという手段に没頭するのではなくWhyを常に問い直し問題の本質を捉えることが重要
  • コーディングや会議そのものは価値ではなくエンドユーザーに価値を届けることのみが仕事であると定義し不要な機能や工程は徹底的に削ぎ落とすべき
  • 自分たちの仕事が増えていないかという機微を感じ取り本質的でないと気づいた作業はその瞬間に辞める勇気を持ち技術を使ってビジネスを前に進めることに注力するのが本来の仕事
• 判断と決断の違いと決断のコツ:
  • 判断と決断の違いと決断のコツ - そーだいなるらくがき帳
  • データや情報を集めて正解を導き出すのが判断で情報が足りない中で答えを出すのが決断
  • 理屈だけで片付かない不透明な状況で自らの意志で進むべき道を示すことが組織を前に進める力になる
  • 決断を早くするコツは万が一失敗しても元に戻せる状態を作っておくこと
  • やり直しがきくことならどんどん試して素早くフィードバックを得る
  • 小さな決断をメンバーに任せていくことがチーム全体の成長と自律に繋がる
  • 決断に迷ったときはまず条件を整理し次に小さく始めて失敗できる形にできないか検討する
  • それが難しいなら周囲の知見を集めそれでも答えが出なければ無理に決めず時間を置く
  • どうしても今重大な決断が必要なときは最もダメージが少ない道を選び抜く覚悟を固める
  • 正解のない問いに立ち向かうには日頃からビジョンや哲学といった自分なりの指針を持っておくことが不可欠
  • 決断は練習で上達するスキルだと心得て日々小さな決断を積み重ねる
  • 時には痛みを伴う選択も引き受ける覚悟を持つことがリーダーとしての信頼を築く
• 当たり前にリリースしていく:
  • 当たり前にリリースしていく ~ 新卒研修編 - Classi開発者ブログ
  • リリースを当たり前のことにするためには事故を未然に防ぐ仕組みと万が一の際に迅速に復旧できる仕組みの両面を整えることが不可欠
  • コードには変更を受け入れる遊びを持たせて影響範囲を最小化しアプリケーションを最も理解する人が振る舞いを監視して異常を早期発見する必要がある
  • YAGNIを設計を怠る言い訳にせず納期などの制約内で最大限考え抜いた上で早めにチームを頼って本質的な課題分解を行う姿勢が求められる
  • 破壊的な変更を避け小さく部分的にリリースすることでいつでも元に戻せる状態を維持し成功体験を積み重ねて自信を築くことが成長への近道

■ 2. エンジニアとして成長し続けるための指針

• ソフトウェア開発者に必要な考え方:
  • ソフトウェア開発者に必要な考え方 / Necessary mindset for software developers - Speaker Deck
  • ソフトウェアはリリースされユーザに届いて初めて価値を持つため目的を軸にタスクを細分化し完成を明確に定義することが不可欠
  • 指示を待つのではなく主体性を持って自らの意思で仕事を完遂する自律性が求められ環境順応型から自己主導型の知性へと成長する必要がある
  • 未完了のコードは無価値な在庫と心得て先人の知恵を体系的に学びつつ知識を実践を通して習慣へと昇華させ成果を出し続ける
• 強いエンジニアのなり方:
  • 強いエンジニアのなり方 - フィードバックサイクルを勝ち取る / grow one day each day - Speaker Deck
  • 強いエンジニアとは問題解決ができる人であり日報や週報を通じて日々の仕事を振り返り経験に複利を効かせる内省の習慣が成長の源泉となる
  • 解決したい問題にフォーカスし問題を実行可能な最小単位まで分解してスコープを調整することで自然と適切なサイズでのリリースが可能になる
  • コルブの経験学習モデルを意識し具体的な経験から法則性を見出す抽象的概念化を繰り返すことでエンジニアに不可欠な思考力を磨く
  • 成長のチャンスは常に目の前にあり誰の許可も得ず昨日の自分に誇れる今日の自分を目指して一歩ずつ積み重ね続ける姿勢こそがいつか偉業へと繋がる道になる
• 目の前の仕事と向き合うことで成長できる:
  • 目の前の仕事と向き合うことで成長できる - 仕事とスキルを広げる / Every little bit counts - Speaker Deck
  • 能力は知識と経験を掛け合わせて知恵へと昇華させることであり未知の状態から習慣化まで段階的にステップアップする反復学習が不可欠
  • 会社が育ててくれる時代は終わったためプロとして計画実行力や言語化力や問題解決能力を仕事の中で主体的に鍛えソフトウェアを通じた課題解決力を高める必要がある
  • 適切な問題設定と完了の定義の明確化を重視し日報や週報による内省や理想のプログラマを演じるロールプレイングを通じて日々の仕事にフィードバックサイクルを組み込むことが成長の近道となる
  • 始めるのに遅すぎることはなく毎日一つ知らないことを見つけて能力へと変え昨日の自分に誇れる今日の自分を目指して一歩ずつ強くなる姿勢が重要
• 問題を解決するために必要な習慣:
  • 問題を解決するために必要な習慣 / developer-lifehack - Speaker Deck
  • Howに囚われて仕事を増やす中毒症状を脱しWhyを軸に不要な作業を削ぎ落とし精神論ではなく始めやすく辞めやすい仕組みで課題を解決する
  • 自律とは主体性を持って働くことであり5W1Hを整理して他人に依頼できるまたはやる気に関わらず一歩目が踏み出せる最小単位まで問題を具体的に分解や言語化する
  • 手が付かないタスクは無理をせず現実を受け入れ納期の設定や他人を巻き込むことで優先度を管理し時には豊かな人生のために諦めるという選択も適切に行う
  • 遠くへ行くなら皆で進む精神を持ち過去の評価である信用ではなく未来を信じる信頼をベースに適切なサイズの課題を仲間とシェアしてチーム文化で解決していく
• 適切な問題設定と小さくリリースするということ:
  • 適切な問題設定と小さくリリースするということ / release small - Speaker Deck
  • ソフトウェアはユーザに届いて初めて価値が生まれるため未完了のコードを無価値な在庫と心得て完璧主義を捨て市場のフィードバックを得るための早期リリースを最優先すべき
  • ユーザーストーリーの5W1Hを整理しチケットが巨大な場合はスコープを調整してリリースの単位が最小になるようにタスクを分解することで着実な成果の積み上げを可能にする
  • リリースへの恐怖をやる気で克服しようとせずサービスを壊さず安全にリリースできる手段を整え小さく失敗して改善のサイクルを高速に回せる環境を仕組みで解決する
  • Unix哲学の一つのことをうまくやる精神を貫き最速かつ最小の手段でプロトタイプを試作や評価し自分たちにしか直せない目の前のコードを通じて価値を提供し続けることが本質

■ 3. 問題解決の本質を突く思考法

• 仕事を前に進めるためのコツ:
  • 仕事を前に進めるためのコツ - 判断と決断と共有 / Aim for the goal - Speaker Deck
  • 仕事を前に進めるには当事者意識を持ち問題を深く理解した上で5W1Hに基づく具体的なタスクへ分解することが重要
  • 意志決定では論理的な判断と不透明な状況下での決断を区別し自らがボトルネックにならないよう迅速に動くことが求められる
  • 円滑な共有のためSBIモデルを活用した期待値調整や日々の些細なコミュニケーションを積み重ねることが不可欠
  • これらの知識と行動によってできるという経験を得ることで問題を解決し大きな成果を生むことが可能になる
• 抽象化をするということ:
  • 抽象化をするということ - 具体と抽象の往復を身につける / Abstraction and concretization - Speaker Deck
  • 抽象化とは複数の具体から共通項を見つけて名前をつけるスキルであり五感で感じる具体と往復することで対象の理解を深め一言で本質を伝えることを可能にする
  • ソフトウェア開発はこの往復そのものであり抽象的な要求を具体的仕様へ落とし込み具体的な業務知識を設計へと抽象化するプロセスの自覚的な反復こそがエンジニアの仕事
  • 抽象化能力は知識と経験に紐づく後天的なスキルであり日々の仕事で理想のプログラマを演じ成功体験を積み重ねることで誰でも再現性のある能力として獲得できる
  • 無知の知から学びを始め目の前の一段を刻むような地道な実践を積み重ねることが自信を築く鍵となり自らの意思で人生の針を進める力へと繋がる
• DBのスキルで生き残る技術:
  • DBのスキルで生き残る技術 - AI時代におけるテーブル設計の勘所 - Speaker Deck
  • データベースの寿命はアプリケーションより長くドメイン背景を理解せず過去のパターンを回答しがちなAIに代わり人間が前提条件から見直すダブルループ学習で設計することが不可欠
  • 主観的な馴染みやすさであるEasyな設計に逃げず客観的に概念を最小化したSimpleを追求し事実のみを保存して重複や不整合や不要なNULLを徹底的に排除する
  • 1テーブル1責務の原則やシステムを複雑化させるUPDATEを最小限に抑えるイミュータブルデータモデルの採用がAIによって高速に肥大化する開発現場において変化に強い構造を維持する鍵となる
  • データモデリングは複利で効く一生モノのスキルでありAIに作業をサポートさせつつ人間が物理世界の要求を整理して最適な要件へと昇華させることが未来の自分を救うことにつながる

(2026/01/01)

Immutable Infrastructure, Immutable Code

• Immutable Infrastructure, Immutable Code - The Phoenix Architecture

要約:

■ 1. イミュータブルインフラストラクチャの原則

• 2013年にサーバーを廃棄しコードを燃やすというアプローチを提唱
• 実行中に変異するシステムは状態や履歴や不確実性を蓄積し人間が推論できなくなる
• 何かが壊れた時に誰もどの変更が原因かシステムが実際に何であるかを知ることができない
• サーバーにパッチを当てるのではなく置き換えるアプローチに移行
• 人間の介入なしに同一の動作で再生できる能力こそが重要

■ 2. Wunderlistでの技術選択ルール

• 誰でも新しい言語やフレームワークを使用できるが以下の条件を満たす必要がある:
  • ビルドシステムと連携すること
  • デプロイメントシステムと連携すること
  • チーム内で少なくとも1人の協力者を見つけサポート体制を確保すること
  • コードサイズを数インチの手のひらサイズに制約すること
• 最後の制約により新技術がクラッシュしても誰も修正できない場合でも簡単に書き直して置き換えられる
• コードは細胞のように扱うことができ部分が死んでもシステム全体は残る
• コードを安価に再生できるならその場でのアップグレードはアンチパターンかもしれない

■ 3. イミュータブルインフラストラクチャが採用された理由

• エレガントだからではなくミュータブルシステムが診断や再現やロールバックが困難な形で失敗したから
• スノーフレークサーバーや設定のドリフトや手動修正や誰も再現できない部族的知識などの問題
• マシンを修正するのではなく置き換えることでシステムをより賢くするのではなくより推論しやすくした
• 各デプロイメントはクリーンスレートで各アーティファクトは既知のもの
• 重要な洞察は技術的というより経済的で変異は置き換えよりも速く隠れたコストを蓄積する
• この洞察は現在アプリケーションコードにも当てはまる

■ 4. コードの編集は変異である

• コードをその場で編集することは本番サーバーにSSHして設定ファイルを調整するのと同等
• システムの完全な状態を理解していると仮定している
• 変更がローカルで履歴が重要でなく副作用が予測可能だと仮定している
• これらの仮定は常に不安定だったが維持不可能になりつつある
• 人間やAIまたは両方によってコードがより急速に生成されるにつれ変異率は増加するが理解率は横ばいまたは低下
• すべてのその場編集はドリフトイベントでありAIはタイムラインを圧縮することでこれを可視化する

■ 5. ミュータブルコードがエントロピーを蓄積する仕組み

• その場での変更には隠れたコストプロファイルがある
• 増分編集は意図とそれを生み出した変更のシーケンスを絡み合わせる
• コードがコードの上に重ねられローカルな修正がグローバルな動作を不明瞭にする
• 理解するにはコードベースの進化を頭の中で再生する必要があり考古学的作業になる
• レガシーシステムは年月ではなく変異によって生まれる
• システムはどこにもエンコードされていない歴史的知識を必要とするようになるとレガシーになる
• チームはAIで変異が安価に感じられる一方で理解が静かに高価になるためこの失敗モードをより速く再現する
• 数秒で1000行を生成できるがそれらの行を編集し始めた瞬間に歴史的にしか理解できないアーティファクトを作成する
• コードの置き換えはこれを完全に回避する

■ 6. フェニックス原則

• イミュータブルインフラストラクチャを機能させたのはサーバーそのものではなく特性
• 何かを燃やして人間の介入や組織的記憶なしに同一の動作で再び立ち上がる能力
• この特性がシステムを大規模に理解可能にする
• ドキュメンテーションやコードコメントやエンジニアの記憶ではなく仕様から再生する能力
• コードに適用すると仕様と評価基準からコンポーネントを再生できない場合そのコンポーネントは存在するのに十分に定義されていない
• これはフィードバックであり火はあなたが実際に知っていたことと思っていただけのことを教える
• 置き換え優先システムは異なる動作をし各再生は明示的で各デプロイメントは意図的でロールバックは簡単でドリフトは蓄積できない

■ 7. 現在これが機能する理由

• 歴史的にコードの記述が高価で調整が遅くすべての再テストが苦痛で人間のレビューがボトルネックだったため完全な置き換えを避けていた
• AIは生成コストを変化させテストは自動化され調整はインターフェースを通じて行われる
• より深い変化は理解がボトルネックになったこと
• ソフトウェアエンジニアリングの歴史全体がコードを理解しやすくすることに関するものだった
• スタイルガイドやデザインパターンやクリーンコードや自己文書化関数はすべて人間が実装を読んで推論することを前提としていた
• 読み取りが必須だったため可読性のために最適化した
• イミュータブルコードはこの問題を回避し仕様からコンポーネントを再生できるなら実装の理解はオプション
• コントラクトやインターフェースや期待される動作を理解する必要があるがどのように達成するかは理解する必要がない
• 残る高価なものは何が欲しいかを定義することで実装の理解はデバッグ活動であってメンテナンス活動ではない

■ 8. 置き換えで存続するもの

• コードがイミュータブルなら他の何かが連続性を担う必要がある
• それはインターフェースやコントラクトや評価やモニタリングやデータ
• これらが安定した層でありコードはそれらの一時的な表現
• これはインフラストラクチャを完全に反映しておりAMIよりAPIが重要でコンテナよりコントラクトが重要でサーバーよりサービスが重要
• 気にかけていたのはマシンではなくマシンが何をするかとそれが正しく動作していることをどう検証できるか
• ソフトウェアも同じ認識に追いついておりコードは資産ではなく仕様と評価が資産でコードは現在のレンダリング

■ 9. 反論への回答

• 無駄である:
  • 変異こそが無駄で将来のデバッグやオンボーディングやインシデント対応にコストを隠すだけ
  • 置き換えは境界リスクを持つ明示的なコスト
• 最適化を失う:
  • 最適化が重要なら制約や不変条件としてエンコードする
  • 正式に表現できないなら実際の価値ではなく偶然だった可能性が高い
• 組織的知識はどうなる:
  • これが本当の不安でありコードは誰も書き留めなかった決定を体現している
  • しかしこれこそがイミュータブルコードが解決する問題
  • 知識が実装にのみ存在するならそれは知識ではなくリスク
  • 再生は暗黙を明示的にするか本質的ではなかったことを受け入れることを強制する
• 大規模システムでは機能しない:
  • 大規模システムはすでにインフラストラクチャを常に置き換えている
  • コードが次で困難なのは分解であって置き換えではない
• 開発者の直感を壊す:
  • コンテナもCIもバージョン管理もローカルな利便性をシステム的明確性と交換するすべての進歩がそうだった

■ 10. 更新されたルール

• 古いルールはインフラストラクチャをその場でアップグレードしないこと
• 新しいルールは代わりに再生できるならコードをその場でアップグレードしないこと
• 本番環境でサーバーにSSHして何かを調整することがまだ可能だが明らかに望ましくないのと同様にコードの編集は最後の手段
• 再生が失敗したことや仕様が不完全だったことや評価が十分でなかったことの兆候
• これはデバッグ活動であって開発活動ではない

■ 11. メリット

• イミュータブルコードは予測可能なデプロイメントや低い認知負荷やクリーンなロールバックや簡単な監査や速い進化や小さな爆発半径をもたらす
• 本当のメリットは心理的で変更を恐れなくなる
• レガシーな決定の周りをつま先立ちで歩かなくなる
• これは何を壊すかではなくこれは評価に合格するかを尋ねるようになる
• コードは脆弱なアーティファクトではなく再生可能なリソースになる

■ 12. 結論

• インフラストラクチャはミュータビリティが理解の敵であることを教えた
• AIは同じレッスンをスタックのより上位で再び教えている
• AIが生成したコードをその場で編集している場合は設定ドリフトの最悪の時代をより速く追体験している
• 年ではなく日でレガシーシステムを作成している
• 燃やして再生し火に耐えたものを信頼せよ

MEMO:

• イミュータブルコードが具体的にどういうものなのか想像できないのだが
• インターフェイスだけを定義して、内部実装はAI任せにするという意味だろうか？
• それでは修正や保守が確率的な作業になってしまうのではなかろうか
• 人間がやる作業も本質的には確率的な作業と言われると否定は難しいが

(2026/01/01)

2025年のLinux関連ニュースを振り返る

• 2025年のLinux関連ニュースを振り返る | gihyo.jp

(2025/12/31)

最古の「プログラマ不要論」とAI時代の「プログラマ不要論」の共通点

• 最古の「プログラマ不要論」とAI時代の「プログラマ不要論」の共通点 - きしだのHatena

(2025/12/30)

「こんな複雑なことをしないといけないのはおかしい」というソフトウェアエンジニアの勘

• 「こんな複雑なことをしないといけないのはおかしい」というソフトウェアエンジニアの勘 - valid,invalid

要約:

■ 1. ソフトウェアエンジニアの勘

• 「やりたいことに対してこんな複雑なことをしないといけないのはおかしい」という感覚が時折はたらく
• FizzBuzz Enterprise Editionはプログラマジョークとして解されるが実際のエンジニアリングではもっと微妙な形で表れる
• 設計やコードレビューの最中に「こうしたらどうなるだろうか」と思いつき提案を実装した結果として管理すべき状態やコード量が減ることがある
• システム要件や仕様について話す中で表出することも多い:
  • 「新しい画面を作ってこういう情報を見せたい」「ツールAと双方向に同期して検索したい」といった言葉からよくよく要求を聞いてみると既存機能で代替ができたり大仰なインテグレーションは不要だと気づく

■ 2. 不要な仕事を減らす能力

• "No, AI is not Making Engineers 10x as Productive"(2025-08)の主張:
  • AIはエンジニアを10倍生産的にはしない
  • 不要な仕事を減らす能力の重要性が述べられている
• 10x Engineerの特徴:
  • コードを書くのが10倍早いわけではない
  • 不要な作業を未然に防ぐ能力を持つ
  • PMを説得して実行不可能なタスクを止める
  • 不要に複雑な開発を止める
  • DXに投資して全員の時間を節約する
  • 将来のために自分の作業を文書化する
• こうした活動が組織内で積み重なって10倍の差がつくことがある

■ 3. ソフトウェアの設計は複雑性を管理する作業

• "What Is Software Design?"にて1992年に指摘された内容:
  • 高々数十〜数百行のコードで実行できる処理はとても複雑な内容でありうる
  • ソフトウェアエンジニアリングにおける設計はその他のエンジニアリング分野からすると極めて特殊
  • ソフトウェアのような複雑なものをこれだけの短時間で設計できるのはほかのエンジニアリング分野では(少なくとも当時は)みられなかった
  • これがソフトウェアの複雑性が短期間で膨れ上がる原因
  • ソフトウェアの設計は複雑性を管理する作業である

■ 4. 複雑性の爆発に対する不安

• 30年以上が経過した現在の状況:
  • コード1行あたりの実現する処理の量はさらに増えた
  • AI/LLMを用いることで自然言語1行から大量のコードおよび裏側の複雑性を生産できるようになった
  • そのトリガーを引けるのが専門のソフトウェアエンジニアだけではなくなってきている
• 現在の構図:
  • クリティカルな業務領域では要件定義やコードレビューといった従来のプロセスを通じて複雑性を押し留めようとする不断の活動が続いている
  • 一方でこれまで以上に多くの人が新たな複雑性を生み出しつづけている
  • 増大する複雑性の総体にどう立ち向かうべきかこの増大はいつしか手に負えなくなるのではと感じさせられる
• AIコーディングエージェントに対する指摘:
  • 不要な作業を防ぐことはほとんどしない
  • AIはしばしば性急な作業や過剰な構築を助長している
  • この指摘が筆者の不安を言い当てている

■ 5. ソフトウェアエンジニアのAIに対する不安

• これまで培ってきた「こんな複雑なことをしないといけないのはおかしい」という勘や不要な作業を防ぐ能力
• これらに対して無頓着に逆行する振る舞いがソフトウェアエンジニアのAIに対する不安視の一端
• 勘や経験知/能力をフィードバックしたりコンテキストとして与えるべきという方法論は知っている
• ガードレールを敷いたり方向づけをしていくべき
• モデルプロバイダーやツール側の進化や創意工夫に学びつつ自分が管理する領域や分野において同様の還元ができるかどうかが問われている
• 複雑性を管理するソフトウェアエンジニアの役割が問い直されていると感じる
• 変化それ自体は面白くも感じている

(2025/12/30)

全人類に告ぐ！Chrome拡張を作れ！

• 全人類に告ぐ！Chrome拡張を作れ！｜けいすけ

MEMO:

• プログラミング初心者はまずはChrome拡張を作って成功体験を積めという記事
• 自分用に作ってみるぐらいならまだ「やってみればいい」と思うが、「初心者が作ったChrome拡張を公開して使ってもらえ」は流石にちょっと
• 初心者が作ったChrome拡張なんて入れたくないのだが...

(2025/12/29)

1on1の準備をAIに任せたら、負担は激減し満足度は向上した——語学サービス企業の実例

• 1on1の準備をAIに任せたら、負担は激減し満足度は向上した——語学サービス企業の実例 - 1on1総研

要約:

■ 1. どの会社でも起こる1on1の形骸化

• メンバーの成長支援やエンゲージメント向上のために1on1を導入する企業は年々増えている
• 導入当初は対話を通じて成長を支えるや心理的安全性を高めるといった期待が語られる
• 数年経つと次のような声が聞こえてくることが少なくない:
  • 上司によって1on1の内容も進め方もばらばらである
  • 雑談や業務の進捗確認だけで終わってしまう
  • 上司が一方的に話しメンバーは聞き役になってしまう
  • メンバーが悩みや希望を話してもその後何も変わらない
• こうした状況が続くとメンバーの側には結局話してもあまり変わらないや評価に響きそうで本音は言いにくいといった感覚が生まれ1on1は義務的に参加する場になりがち
• 上司側もとりあえず時間だけは確保しているが毎回何を話せばよいか悩むやメンバーが受け身で深い話に入っていきにくいと負担を感じるようになる
• 結果としてせっかく時間と工数をかけているにもかかわらず1on1がメンバーの成長支援という本来の目的から離れ形骸化してしまうケースが多く見られる

■ 2. 英会話サービスA社の問題意識

• A社ではメンバーの成長支援を目的に3年前から全社で1on1を導入していた
• 次第に多くの企業と同じ課題に直面するようになった:
  • 上司によって1on1の内容や深さが大きく異なり一部で大きな不満になっている
  • 上司も支援したいと思っているが多忙なため準備が不十分な状態で臨んでいる
  • 結果として仕事の相談や進捗確認の場になり成長が支援されているとは言い難い状況に陥っている
• 1on1の全社推進を担う人事課長も管理職向けの研修や進行マニュアルの作成などの施策を講じてきた
• しかし上司ごとのバラつきを均していくことの難しさを感じ始めた
• 社長からもこれだけ工数をかけているわりに成長促進につながっているように見えないや業務時間をひっ迫することにもなるのでいっそ1on1はやめた方がいいのではないかという声が上がっていた

■ 3. A社の課題整理

• A社の人事担当者は1on1の現状と課題を次のように整理した:
  • 上司のスキルやスタイルによって1on1の質の差が大きい
  • メンバーが十分に準備できておらずなりゆき的な会話や業務相談になりがちである
  • 上司メンバー双方の工数が大きく日常業務を圧迫している
• この三つを同時に解決しない限り形骸化の流れは変えられないと考えたことが改革に取り組む出発点となった

■ 4. A社の取り組み:GeminiのGem機能の活用

• 転機となったのは人事課長がGeminiのGem機能に着目したこと
• GeminiのGemは特定のタスクに特化した専用AIを作成できる機能
• 日々の業務効率化にAIを使い始めていた人事課長はGemを1on1の準備に使えないかと考えた

■ 5. 再設計された1on1の流れ

• A社が再設計した新しい1on1の流れ:
  • 上司との1on1は原則30分に短縮
  • その代わりメンバーは1on1開始5から10分前までにGemに状況を入力する
  • 入力内容は次の三つに絞る:
    • 今困っていること
    • 今期の成長目標に対して今週取り組んだこと
    • 成長目標に対して次に取り組もうと思っていること
• これらを入力するとAIからはねぎらいのコメントとともに次の二つが提案される:
  • 今週の1on1で上司と話すとよい推奨テーマ
  • 自分の成長につながる上司への問いの候補
• メンバーはその出力を参考にしながら上司に投げかける内容を整理して1on1に臨む
• メンバーはこの出力結果を1on1前に上司と共有し画面やメモを見ながら対話を進める
• 上司は状況をゼロから聞き出したり質問内容を考えたりする必要がなくなりメンバーの成長にどう関わるかという本質的な部分に集中できるようになった
• ともすると業務相談になりそうなテーマでも成長という観点からAIでサポートを受けることで業務推進と成長が同時に進む1on1が安定的に行われるようになった

■ 6. 成果:時間と工数の削減

• この取り組みによりA社ではまず1on1にかかる時間と工数が大きく削減された:
  • 1回あたりの1on1時間は1時間から30分に短縮
  • メンバーの事前準備も5から10分に収まり負担感が軽減

■ 7. 成果:満足度の向上

• 1on1の満足度は高まっている
• メンバーからの声:
  • 短い時間で考えを整理できるので30分でも十分に深い話ができるようになった
  • 自分から問いを投げかける形になるので進行や内容に迷うことがなくなった
  • 成長目標と日々の仕事がつながっている感覚を持てるようになった
• 上司側からの評価:
  • 何を聞けばよいか悩む時間が減り対話に集中できるようになった
  • メンバーの振り返りが整理された状態で共有され本音を引き出しやすくなった
  • 1on1はこうすればよかったのかと安心して取り組めるようになった

■ 8. 成果:1on1の位置づけの変化

• 工数の大幅削減と質の向上が同時に実現されたことで1on1はやめるかどうか議論されるものからメンバーの成長と定着に欠かせないものとして認識されるようになった
• 離職に関する相談も以前に比べて突然持ち込まれることが減った
• キャリアについて迷っているや今後の働き方を考え直したいといった悩みが早いタイミングで1on1の場に上がってくるようになった

■ 9. 今後の展開

• A社ではGemを活用した1on1の仕組みを土台に今後次のような展開を検討している:
  • 1on1で頻出するテーマや問いをAIで収集整理し育成施策や配置検討に生かす
  • 評価面談やキャリア面談と1on1をAIで連動させ一貫性のある成長支援につなげる

■ 10. 取り組みの特徴と示唆

• 特別な専用システムを開発したわけではない
• もっとこうなったら理想的という1on1の姿を起点に人事担当が既存のGemを組み合わせて仕組みをつくったことが特徴
• 1on1の形骸化や工数の重さに悩んでいる企業は少なくない
• A社の事例は質の向上と時間削減のいずれも諦めず何とかしたいという意志を持った人事担当者がAIをうまく取り入れることで工数削減と満足度成長実感の向上を同時に実現できた事例

(2025/12/28)

みんなでマネジメント〜マネージャーがボトルネックにならない自己管理型チームの仕組みづくり

• みんなでマネジメント〜マネージャーがボトルネックにならない自己管理型チームの仕組みづくり - KAKEHASHI Tech Blog

要約:

■ 1. 記事の背景と目的

• 筆者はカケハシでHoEをやっている小田中氏
• 2023年10月に入社してから2年が経過
• 日本の医療体験をしなやかにするを実現するための濃密な日々を送っている
• 2025年のアドベントカレンダーでマネージャーがボトルネックにならないチームづくりをテーマに執筆

■ 2. エンジニアリングマネージャーに求められること

• カケハシではエンジニアリングマネージャーに期待することをCTOが言語化している
• 7つの期待事項:
  • 正しい方法で短期的な事業成果を追求する
  • チームの活動に明確な意思決定を行う
  • チームの活動を説明できる状態を保つ
  • Disagree and Commitの姿勢で臨む
  • 属人化を避け仕組みで解決する
  • 個人の強みを引き出して活かす
  • パフォーマンスについて明確なフィードバックを行う
• どれもEMにとって大切な行動だが全てを1人の人間が高いレベルで遂行するのはハードルが高い
• 相反する要素の例:
  • 正しい方法で短期的な事業成果を追求すると属人化を避け仕組みで解決するは相反する
  • 純粋に短期的成果のみを追い求めると今その仕事をやりきることができる人にばかりお願いすることになるため属人化を助長する
  • 短期間でコミットメントが求められる状況で属人化排除のための冗長性担保を高い優先順位においていると期待するスピードが出ないことが起こり得る

■ 3. 期待の多さがEMをボトルネックにする

• 期待されていることがそもそも多い
• 中には相反する要素に対して落としどころを見つける必要がある
• この状況はEMの負荷上昇を招く
• 負荷が上がったEMはボトルネックとなり現場のスピード感に影響を与える
• 筆者の状況:
  • HoEとしてSCM組織を統括しながらいくつかのチームのEMを兼務している
  • すべてのマネジメント業務を1人でこなそうとすると容易にボトルネック化していく
• HoEとしてのミッション:
  • 全社最適の観点で組織を捉え中長期的にバリューを創出するための人員計画や技術投資の検討に集中したい
• 個別のチームのEMとしてのミッション:
  • チームメンバーの潜在能力を引き出すチームワークを発揮するようなコミュニケーション設計に力を割きたい
• 目の前で発生しているインシデントやその背景にある構造的な技術課題へのアプローチが必要
• それぞれ観点が異なるミッションであるためコンテキストスイッチが大きく発生する
• 全てに深く入り込むことは時間的にも体力的にも難しい
• これらのタスクをマネージャーが持っているという形のままにしておくとタスクがスタックしていく
• これは組織やチームの動きが停滞することを意味する
• マネージャーがタスクを持ち続けることは中長期的にみて致命的な課題となるリスクがある

■ 4. 解決策:マネジメント機能の分散

• ボトルネックを解消しかつなされるべきマネジメントがなされるための解決策はマネジメントの機能をメンバーにも分散するというアプローチ

■ 5. EMへの期待を分解する:チームの活動に明確な意思決定を行う

• EMへの期待を分解することでメンバーがマネジメント機能を実行できるようになる
• 意思決定を行うためにはチームを取り巻く状況の把握など情報収集が重要
• この情報を全てEMが主体的にとりにいくのはかなり骨が折れる作業
• 自動的にEMに情報が集まってくる状況をつくる仕組み:
  • 定量的なメトリクスの収集と観測
  • 定性的な情報や状況の収集
• 定量的なメトリクスの例:
  • AWSコスト推移のウォッチ
  • Datadogでの各指標の確認
  • リリース頻度
  • インシデント発生頻度
• AI在庫管理チームではDatadogやSentryのダッシュボードをみんなで確認する場を毎日設けている
• メトリクスを見ることが自然と習慣化されている
• これらの指標を計測し定期的に観察することで意思決定の方向性が浮き彫りになる
• 意思決定に足る情報が揃っているとメンバーからの提案を適切に評価し採用できるという大きなメリットがある
• 定性的な情報については数値としてはあらわれていないけれどもメンバーが抱えているモヤモヤや放っておくと大きな問題になる兆候などをキャッチすることに役立つ
• 週に1度チームのテックリードたちと今チームで何が起こっていると感じていますかを分かち合う場は問題が小さいうちにキャッチし対策を打つための絶好の場

■ 6. 事例:AWSコスト削減

• AI在庫管理チームでは徹底したAWSコスト削減に取り組んだ
• AWSコスト削減に強みをもつDELTA社に多大なるご協力をいただいた
• プロダクトの利用規模拡大に伴って上昇したAWSのコストを削減したいという点については意思決定することは容易だった
• DELTA社に協力いただくという意思決定はメンバーからの提案があったからできた
• コストは削減したいけれどもチームの力は開発にフォーカスしたかった
• 顧客への価値貢献を最大化しつつどのようにコストを下げて行くかで悩んでいるときにメンバーが提案してくれた
• 様々なトレードオフを考慮したり実際にDELTAさんの話を聞く中で依頼することで事業推進とコスト削減を両立できるという確信が得られ意思決定に至った

■ 7. 事例:生成AI活用の推進

• 開発現場での生成AI活用の推進があった
• AI在庫管理チームでは社内の他チームに先駆けてAI Only Weekを試行するなど積極的に生成AI活用を推進してきた
• AI Only Weekとは手動でのコーディングを行わずAIコーディングのみで開発を進める実験
• 高い品質やシステムの安定性が求められるカケハシのプロダクト開発においてどの程度導入するべきかについては慎重な判断が必要だった
• 思い切って推進できたのは旗振り役になってくれたメンバーがどのような効果がでていてどのような課題がありしたがってどのように活用していくことが望ましいかを適宜共有してくれていたから

■ 8. EMへの期待を分解する:属人化を避け仕組みで解決する

• AI在庫管理チームではプロダクトへの品質要求に応えられるような開発プロセスを実現するため品質向上ハンドブックが作成された
• 『Musubi AI 在庫管理開発チームの品質向上ハンドブック』の PDF版を公開します - KAKEHASHI Tech Blog
• PRD作成などいわゆる前工程から丁寧にプロセスが解説された素晴らしいコンテンツ
• 品質向上や開発プロセス改善に馴染みのないメンバーからするといささか重厚に感じられるものだった
• マネージャーとしてはこのプロセスを浸透させたいが現場からすると重量級に感じられ手にとることのハードルが高かった
• あるメンバーがわからないところが多いのでみんなで読み合わせしませんかと提案し実際に読み合わせを主催してくれた
• この読み合わせをきっかけにメンバーが開発プロセスに対してより主体的に関わるようになりチームで当たり前に遵守するものになっていった
• マネージャーが読み合わせしましょうと呼びかけるより1人のメンバーが読み合わせを企画したのが主体的に個々人が落とし込むモチベーションにつながったと考えられる

■ 9. チームでマネジメント機能を分散する効果

• EMに期待されている行動の一端をチームが担うことには様々なよい効果がある
• 5つの効果:
  • 冗長性
  • 即時性
  • 多様性
  • 自律性
  • 将来性
• ひとりのマネージャー以外でもある機能を担えることは冗長性の担保につながる
• そのときに手が空いているメンバーが対応できるのであればそれは即時性につながる
• 様々なバックグラウンドをもつメンバーが関わることで多様性が生まれる
• マネージャーにおまかせではなく自分たちでチームを推進するんだというマインドセットが自律性を育む
• マネジメント業務を請け負うことにやりがいが見出されたのであれば次世代のEM候補になるかもしれないという将来性につながる
• マネージャーが担っていた仕事を請け負うことになるので単純に考えるとメンバーの負担が増えてしまう働きかけでもある
• 現代を生きるエンジニアは生成AIを相手に大なり小なりマネジメントを行っているはず
• マネージャーの仕事の一部を移譲してもらいマネジメントスキルをキャッチアップしていくことは大生成AI時代において必要なスキルを身につける絶好のチャンス
• チームにマネジメント機能が分散されたマネージャーの手元にはマネジメントがスケールする仕組みや空気づくりやより中期的な戦略立案や行動への落とし込みなど抽象度や難易度が高い仕事が残る
• こういったタフな仕事に対してマネージャーが集中できる環境をつくることは長い目でみると組織にとっても大きなメリット

■ 10. チームが変化するために:目標を軸にした権限移譲

• 状況を見える化するやメンバー主導で提案し行動してもらうといったことができるチームではマネジメント機能を分散することが可能
• ポイントは目指す方向を明確にしつつ方法は任せると日頃からサインアップの文化をつくるという点
• カケハシの開発組織では目標管理手法としてOKRが採用されている
• AI在庫管理チームでのOKR設定方法:
  • 大枠の目指す方向はEMが示す
  • どうやって目標を達成するかという具体はメンバーが決める
• AWSコスト削減も生成AIの活用推進もチームのOKRとして設定していた
• チームが目指す方向をシャープにすることとどうやって達成するかを考え実際に行動することをメンバーに移譲していた
• AWSのコスト構造についてもチームの開発に対して生成AIをどう取り入れたらよいかの試行錯誤も最前線にいるエンジニアのほうがマネージャーより詳細に把握している
• 変化に対してもいち早く気づく
• これらのOKRに関してメンバーに移譲しオーナーシップを発揮してもらったのはチームが成果を生む観点でも非常によい効果をもたらした
• ある程度の抽象度で渡したときに自律的に成果までの道筋をつけてくれたのはサインアップすることが文化として根付いていたから

■ 11. チームが変化するために:サインアップの文化づくり

• サインアップとはみずから手を上げ仕事をとりにいくこと
• これが当たり前の状況をつくるための効果的なアプローチ:
  • 毎朝実施しているダッシュボード確認定例のファシリテーションを持ち回りにする
  • スプリントレビューで質問を促す
  • 何か作業が発生したときに誰々さんお願いしますではなく誰かやってみませんかと主体的に手が上がることを待つ
• チームがサインアップ文化に慣れていない間は誰かやってみませんかといっても気まずい沈黙が流れることがある
• 主体的な行動を期待しているということを口酸っぱく伝えメンバーが自分の意思でよし自分で手を挙げてみるかとなるのを根気強く待つ
• メンバーが手を挙げてくれたらそのことへの感謝を伝え本当に期待している行動であることを伝える
• こういった地道な活動がだんだんとチームを主体的で自律的な存在に変化させていく
• そういった変化を生み出すことやそれぞれの能力を引き出すことこそがAI時代においてEMに求められる重要なスキル

■ 12. まとめ

• 筆者が所属するチームで実際に行っているマネージャーに依存しないチームとしてのマネジメントの仕組みづくりについて紹介した
• マネージャーがボトルネックにならずチームメンバーそれぞれが主体的に動く自己管理型のチームは自分たちで壁を乗り越えていくしなやかさをもっている
• 本稿がそういったチームが増えていく一助になれば幸い

(2025/12/27)

HUML :: Human-oriented Markup Language

• HUML :: Human-oriented Markup Language

HUML is a simple, strict, serialization language for documents, datasets, and configuration. It prioritizes strict form for human-readability. It looks like YAML, but tries to avoid its complexity, ambiguity, and pitfalls.

HUMLは、文書、データセット、および設定に関するシンプルで厳密なシリアル化言語です。人間の読みやすさのために、厳格な形式を優先する。YAMLのように見えますが、その複雑さや曖昧さ、落とし穴を避けようとしています。

MEMO:

• YAMLの亜種みたいなデータ構造化言語

(2025/12/27)

The 2025 Matrix Holiday Special

• Matrix.org - The 2025 Matrix Holiday Special

要約:

■ 1. 2025年のMatrix全体の状況

• 2025年はMatrixにとって好調な年であり将来を確保するための賭けが成果を上げつつある
• Matrixの採用が野生の環境で増加している
• 大規模な公共部門での展開が進んでいる:
  • ドイツのZenDiSのopenDesk
  • 欧州委員会
• 真のデジタル主権を維持するためにMatrixを積極的に展開している国が25か国以上ある
• ElementのようなMatrix専用ベンダーが持続可能になりつつあり財団とプロトコルおよびエコシステムの開発により多く貢献できるようになっている

■ 2. Matrix財団の財政状況

• 財団自体はまだ独立して持続可能ではない
• メンバーシップは過去1年間で倍増した
• プロトコルの中核を独立して保護する作業は深刻な資金不足の状態にある:
  • Trust & Safety
  • Security
  • Spec
  • Advocacy work
• Matrixに依存する組織は財団の有料メンバーとして参加すべき
• あと数社のゴールドメンバーが加われば財団は実際に加速できる
• 2025年に財団に参加した主要メンバー:
  • DINUMとRocket.Chatが最大のシルバーメンバー
  • AutomatticとBeeperがゴールドメンバーシップを更新
  • Gematikが大規模シルバーメンバーシップを更新
• 20の資金提供組織メンバーに感謝
• Matrix.orgホームサーバーの運用コストをカバーするために有料アカウントの実験を開始した

■ 3. 2025年の成熟度

• 2025年は成熟の年であった
• クライアント側ではMatrixはほぼすべてのプラットフォームで成熟した独立実装を持つようになった
• サーバー側の進展:
  • Synapseはますます成熟している
  • ElementはESS CommunityをSynapseの公式AGPL配布版として立ち上げた
  • Element Adminを公式管理Webインターフェースとして提供
  • Synapse Proは大規模展開向けのスケーラビリティと有料サポートを追加し続けている
  • ESS Proと並行してエンドユーザーに力を与える機能はFOSSに企業に力を与える機能はProに入るという哲学に従っている
• Conduitファミリーのネイティブrustホームサーバーが拡大と加速を続けている:
  • Conduit
  • Continuwuity
  • Grapevine
  • Tuwunel

■ 4. ガバニング・ボードとワーキンググループ

• 2025年はガバニング・ボードがMatrixのオープンガバナンスの主要な手段の一つとして本格的に開花した年
• 4つのワーキンググループが重要なタスクを引き受けた:
  • The Matrix Conferenceの運営
  • matrix.orgウェブサイト自体の維持
  • エコシステム全体でのTrust & Safety作業の調整
• 今後予定されているワーキンググループ:
  • Matrix for Public Sector Working Group
  • Fundraising Working Group
• 11月に初代マネージングディレクターのRobinが退任したが財団のオープンガバナンスを運用可能にした業績は素晴らしい遺産となっている

■ 5. The Matrix Conference 2025

• ストラスブールで開催されたThe Matrix Conference 2025は大成功であった
• エコシステム全体からの素晴らしい講演があった
• デジタル主権を追求する国々を支援するMatrixの公共部門での採用が特に強調された
• イベント自体はガバニング・ボードを通じてMatrixのガバナンスを開放することの勝利であった
• Events Working Groupがイベント全体を組織し利益を上げた
• コミュニティが提供した膨大な量のボランティア活動が貢献した
• 講演はYouTubeまたはmedia.ccc.deで視聴可能

■ 6. Matrixプロトコルの主要な成果

• 次世代認証への移行:
  • OpenID Connect経由の次世代認証への大規模な移行が成功した
  • Matrix 1.15で2.0より前に出荷された
• Project Hydraのフェーズ1:
  • Room Version 12でstate resolutionを改善しstate resetを削減する最初で最も重要なフェーズが実現した
• MatrixRTCの主要な改善:
  • よりシンプルで信頼性の高いシグナリングのためのSticky Events
  • 改善された権限のためのSlots
  • 仕様に正式に組み込まれる直前の状態
• より広いコミュニティからのMSCが多数実現:
  • Tom FosterによるMSC4133を通じてMatrix 1.16で拡張可能なプロファイルが実現
• Matrix 2.0向けの残りのMSCをまだ磨いている段階
• Matrixがサーバーに保存するメタデータのフットプリントを改善する大きな進歩:
  • MSC4362を通じてElement Webのラボに暗号化された状態イベント実装が実現
  • すべての新しいMatrixRTC作業はサーバー側のメタデータを最小化するように構築されている

■ 7. Trust & Safetyの取り組み

• Trust & Safetyが大きな焦点となっている
• 進展:
  • 数日前にpolicyservの公開リリース
  • ROOSTとの継続的なコラボレーション
  • 年初の改善
  • DraupnirとCommunity Moderation Effortとのクロスエコシステムコラボレーションに関する多くの作業
• Trust & Safetyは長期的にMatrixの成功または失敗を決定する唯一のものである
• 2016年の認識:
  • 実際の長期的な問題は分散型コミュニケーションではなくユーザーとコミュニティが虐待やスパムや偽情報やプロパガンダから自分自身を守る力を与えること
  • 現実社会の虐待対策メカニズムをオンラインコミュニティにマッピングする方法を見つけること
• 10年後の現状:
  • ウェブは情報戦争のためにますます武器化されている
  • LLMが超人的な速度で虐待を吐き出せる世界
• 最近の動き:
  • ROOSTのような組織がこの問題に取り組むために登場
  • Blueskyチームも構成可能なモデレーションとユーザー選択可能なアルゴリズムフィードで真剣に取り組んでいる
• 必要な機能:
  • ユーザーとコミュニティが自分自身を守るために使用できるプライバシーを保護する分散型レピュテーションツールの完全なセット
  • コミュニティで誰も保証していないランダムな人間またはボットからの招待とコンテンツをデフォルトでフィルタリングする機能

■ 8. 運用上の課題

• matrix.orgホームサーバーでの運用上の問題が発生した
• Matrix 2.0への移行の遅さに対する多くの不満:
  • MSCがまだ最終化されている段階
  • 一部のElementユーザーがElement Xの存在を知らずにClassicアプリに留まっている

■ 9. 現在のMatrixユーザー体験の改善

• 現在のMatrixの実体験は数年前と比べて著しく改善されている
• 復号化できないメッセージが大幅に削減されている:
  • ユーザーがリカバリーキーを失ったりすべてのデバイスを削除したりしない限り
• Element Xの特徴:
  • 技術に精通した人だけでなく誰もが使えるアプリ
  • iOS26で超光沢のある液体ガラスUI
  • Androidで新たに超高性能なアプリ
  • 超安定したRust SDKの上に構築
  • オフラインサポートとメッセージエコーとキューイングのための美しいイベントキャッシュ
  • スレッドとスペースが完備されている
  • 使用するのが純粋に楽しい
• rust-sdkを基にした他のクライアント:
  • FractalとiambとElement Webが同じ基盤エンジンから直接利益を得る
• 他のスタック上のクライアント:
  • FluffyChatやTrixnityも先駆的な取り組みを続けている
• 過去1年間に多くの批判があったが同時に大きな前進もあった
• Matrixを使用して楽しんでいる場合は当たり前と思わずブログ投稿を書きTWIMに伝え世界に伝え改善できることを伝えるべき

■ 10. 残された課題

• Synapseのリソース使用量:
  • Elementチームはデータベース使用量を約100分の1に削減する方法のデモンストレーションを行った
  • Hydraやその他の堅牢性作業で忙しくまだ実現していない
• Sliding Syncのパフォーマンス:
  • matrix-rust-sdkとSynapseで数年前の最初の実装と比較して後退している
  • クライアント側での保守性向上のための簡素化とサーバー上の変更が原因
  • 同期パフォーマンスは良好だがFOSDEM 2023の最初のベータ版の約100msの即時同期には達していない
• matrix-rust-sdkのSliding Syncパズルの唯一の欠けている部分:
  • プッシュ通知がクライアントのイベントキャッシュとアプリケーションバッジを更新することを確保する
  • クライアントが同期するのを待たずにプッシュされたメッセージを読めるようにする
  • この作業は最新のmatrix-rust-sdkイベントキャッシュの改善によってブロック解除されるはず

■ 11. 暗号化の課題

• 復号化できないメッセージは大幅に改善されたが多くのユーザーがリカバリーキーを失ったために履歴を復号化できないと不満を述べている
• 実施可能な作業:
  • リカバリーキーをWebAuthn Passkeyまたはハードウェアトークンに保存する実験
  • OIDC IDプロバイダーでクライアント側でリカバリーキーを派生させる
  • MSC4268を通じてユーザーをルームに招待する際に履歴を共有する機能を完成させる
  • MSC4153を通じてデフォルトで信頼されていないデバイスを除外する機能を実装する予定
• その他の大きな課題:
  • クライアント制御のグループメンバーシップを最終的に導入する
  • OlmとMegolmの代替としてMLSを進める
  • Post Quantum暗号化を進める
  • すべてのユーザーが互いを帯域外で明示的に検証する必要がなく何らかの推移的信頼を実装する

■ 12. コアプロトコルの課題

• Hydraのフェーズ2とフェーズ3を進める:
  • 堅牢性をさらに改善する
  • イベントのバックデートによる問題を回避するために最終性を導入する
• MSC4243に従ってユーザーIDを公開鍵に切り替える:
  • Matrix IDから直接識別可能な個人情報を排除することでMatrixのGDPRから最後のしわを取り除く
  • 長年待望されているアカウントポータビリティへの道を開く
• 2026年に非常に実用的なP2P Matrix作業を行うことをElementは期待している

■ 13. クライアント側の課題

• 補助APIがボトルネックになりつつある
• クロスサーバーユーザーディレクトリまたは共有アドレス帳をクエリする標準的な方法が必要
• MSC4133で拡張可能なプロファイルが利用可能になった今特に重要
• プライバシーを保護する連絡先検索は主流のMatrix採用にとって変革的になる可能性がある
• 外部アプリをMatrixに統合する方法を改善するための膨大な作業が必要:
  • Widgetsを介して
  • WebXDCや他のイニシアチブの最近の動向を検討

■ 14. 2026年への展望と課題

• これらのどれが2026年に実際に実現するかは不明
• 多くは財団に参加したり開発資金を提供したりすることでより多くの組織が支援するかどうかに依存する
• 利用可能な資金が多いほど実現が早くなる
• 分散型アカウントは2015年から目標としているが財団が限られた予算で運営されている場合より重要な作業が飢餓状態になる

■ 15. 感謝と今後の期待

• 全体的に物事は何年もの間よりも前向きに感じられる
• 財団の個人メンバーと組織メンバーに感謝
• 2026年は真に飛躍できる年になることを期待
• ガバニング・ボードとワーキンググループに貢献するすべての人に感謝
• オープンガバナンスの成果が実を結んでいることが素晴らしい
• Matrixを使用し続けサポートし続けるすべての開発者とユーザーに感謝
• 世界はこれまで以上に安全で分散型のコミュニケーションを必要としている

(2025/12/26)

エンジニアには2種類いて、根本原理からしっかり解ってる人と、パターンやテンプレートで仕事してる人。

エンジニアには2種類いて、根本原理からしっかり解ってる人と、パターンやテンプレートで仕事してる人。

大学進学率がまだまだ10%代で、受験産業が発達してなかった1970年代卒のエンジニアは、明らかに前者でとにかく凄かったよ。僕が社会に出た頃の先輩達は。でも現代は後者が多い気がするね。

ところが海外製の半導体を見ていると、海外は明らかに前者が多いね。ほんとプロ集団的な。

@kiyuni194

MEMO:

• 新人教育の時に教わったパターンで一生やっていこうとするITエンジニアは実際多い

(2025/12/25)

5年間 Laravel を使って辿り着いた，AI 時代に考える「なんちゃってクリーンアーキテクチャ」のその先

• 5年間 Laravel を使って辿り着いた，AI 時代に考える「なんちゃってクリーンアーキテクチャ」のその先

(2025/12/25)

「PCが買えない年末」現実に。マウス、全PC製品の販売停止と初売り中止を発表

• 「PCが買えない年末」現実に。マウス、全PC製品の販売停止と初売り中止を発表 - PC Watch

マウスコンピューターは、2025年12月23日15時から2026年1月4日にかけて、公式Webサイトおよびダイレクトショップで販売しているPC全製品の販売を停止すると発表した。

同社は12月16日に、想定を大きく上回る受注増加の影響で、工場のひっ迫やパーツ不足が発生し、一部製品の販売停止を発表したが、その影響が「mouse」「NEXTGEAR」「G TUNE」「DAIV」ブランドの全製品に拡大した。

販売は1月5日以降に再開するが、店頭での2026年の初売りセールは実施を見送る。なお、12月16日時点で2026年1月以降の価格改定実施も予告している。

メモリやSSDなどを中心としたPCパーツは11月以降、AIデータセンターの需要増の影響で価格が急騰。多くのコンシューマ製品において、深刻な品不足や価格増加を招いている。

MEMO:

• PCメーカーが売るものが無くなるレベルのパニック買いか

(2025/12/25)

Microsoft veteran wants to replace every single line of C/C++ code with Rust and AI

• Microsoft veteran wants to replace every single line of C/C++ code with Rust and AI - Neowin

要約:

■ 1. MicrosoftのAI活用状況

• 7月にMicrosoftは開発ワークフローにAIを大幅に組み込んでいることを明らかにした
• 社内のAI駆動コーディングアシスタントを活用して月間60万件以上のプルリクエストのコードレビューを行っている
• これは会社で生成されるすべてのプルリクエストの90%をカバーしている
• Microsoftは消費者向け開発ツールにもAI技術を深く統合している

■ 2. Galen Huntの野心的な計画

• Microsoft Distinguished EngineerのGalen Huntが詳細なLinkedIn投稿で目標を宣言
• 2030年までにMicrosoftのすべてのC++とCコードの行をRustとAI支援の組み合わせで置き換えることが目標
• Huntのミッションは1人のエンジニアが月に100万行のコードを書けるようにすること
• これはLinuxの作成者Linus Torvaldsが最近別の文脈で指摘したように生産性を評価するためのかなり恣意的で無意味な指標

■ 3. コード処理インフラストラクチャ

• Huntは強力なコード処理インフラストラクチャを強調
• これにより会社は定義されたアルゴリズムに導かれたAIエージェントを展開して既存のコードに大規模な変更を加えることができる
• このツールをさらに改善しC/C++システムをRustに変換するためにベテランのチームはシステムレベルRustの執筆経験が少なくとも3年あるPrincipal Software Engineerを採用している

■ 4. MicrosoftにおけるRustの普及

• Rustプログラミング言語は過去数年間Microsoftで人気を集めている
• 技術大手はより良いセキュリティのためにRustで書かれたドライバー開発を奨励している
• Hunt自身はMicrosoftで約30年間働いており現在Microsoft CoreAIのEngHorizons組織内のFuture of Scalable Software Engineeringグループのメンバー
• 彼のチームの責任は会社で技術的負債を排除する新しいツールと技術を開発し最終的には業界の他の部分にも提供すること

■ 5. LinkedInでの反応

• Galen HuntのLinkedIn投稿への反応はまちまち
• 人々は主にRustへの移行に疑問を呈している
• エンジニアはこの選択を言語に組み込まれたメモリと並行性の安全メカニズムを強調することで擁護している

(2025/12/25)

Microsoft building team to eliminate C and C++, translate code to Rust using AI...

• Microsoft building team to eliminate C and C++, translate code to Rust using AI, as Windows 11 adopts Rust

要約:

■ 1. 記事公開後の訂正

• この記事が注目を集めた後MicrosoftはAIを使ってWindowsを書き直すことはないと述べた
• Microsoft Distinguished EngineerのGalen HuntがLinkedInで説明を追加:
  • WindowsはAIを使ってRustで書き直されているわけではない
  • チームの作業は言語間移行を可能にする技術を構築する研究プロジェクト

■ 2. Microsoftの2030年目標

• Microsoftは2030年までにMicrosoftからCとC++のすべての行を排除することに専念するチームを構築している
• これはWindows 11に影響を与える可能性がある
• CはWindows APIを含むWindowsカーネルと低レベルコンポーネントの大部分を動かしている
• C++はネイティブWindowsアプリの構築に使用されている

■ 3. MicrosoftのRustへの取り組み

• MicrosoftのRustへの愛情は新しいものではない
• Rustはプログラミング言語でありWebView2のようなフレームワークと混同してはならない
• RustはCよりもはるかに安全でありCはカーネルを含むWindowsのネイティブコードのほとんどを動かしている

■ 4. 求人情報の詳細

• Galen Huntは過去30年間Microsoftに在籍し現在Distinguished Engineer
• 彼のチームはIC5 Principal Software Engineerの募集をしている
• Windows LatestがMicrosoftのキャリアサイトとLinkedIn投稿で興味深い詳細を発見
• 会社のトップレベルエンジニアの発言:
  • 目標は2030年までにMicrosoftからCとC++のすべての行を排除すること
  • 戦略はAIとアルゴリズムを組み合わせてMicrosoftの最大規模のコードベースを書き直すこと

■ 5. AIによるコード生成の目標

• Windowsが主にCとC++で書かれていることを考えるとすべてが妄想のように聞こえるかもしれない
• しかしMicrosoftはエンジニアがAIを使って毎月100万行以上のコードを書くことができればすべてが可能だと主張
• North Starは1人のエンジニアが1ヶ月で100万行のコード
• 1人のエンジニアと毎月100万行のコードでMicrosoftからCとC++を排除できる
• MicrosoftはIC5 Principal Software EngineerとしてMicrosoftの2030年までにCとC++を排除する計画に参加する開発者を積極的に採用している

■ 6. Satya Nadellaの発言との関連

• この声明はMicrosoftのSatya Nadellaによる以前の発言に続くもの
• Nadellaは以前会社のコードの最大30%がAIによって書かれておりこれにはWindowsも含まれる可能性が高いと述べた

■ 7. コード処理インフラストラクチャ

• Microsoftは強力なコード処理インフラストラクチャを構築した
• これはおそらくMicrosoftがCとC++コードとRustでAIモデルをトレーニングしたことを意味する
• このインフラストラクチャはAIエージェントを使用して大規模にコード修正を行う
• Microsoftはこのインフラストラクチャによって会社の最大規模のCおよびC++システムのほとんどをRustに進化させ変換できると確信している
• チームはMicrosoft CoreAIのEngHorizons組織内のFuture of Scalable Software Engineeringグループの一部

■ 8. RustとAIアプローチへの懸念

• RustはCやC++よりも安全でおそらくより良い選択肢
• しかしAIエージェントがコードベースを変換することを信頼できるか疑問
• AIは構文を変換できるはずだがコードの意図では失敗する可能性がある
• これがタスクマネージャーのような基本機能を壊したりBitLocker回復画面を引き起こすWindowsアップデートがあった理由を説明している可能性

■ 9. RustによるWindowsセキュリティ強化

• RustはWindowsをより安全にするMicrosoftの取り組みの一部
• WebView2がフロントエンドを担当
• Microsoftは約6年間CとC++よりもRustを提唱してきた
• 当時会社が実際にできるだけ早くCとC++を放棄する計画を立てていたことは知らなかった
• 2019年のブログ投稿でMicrosoftの主張:
  • RustをCとC++から分けるものはその強力な安全保証
  • unsafeキーワードの使用を通じて明示的にオプトアウトしない限りRustは完全にメモリセーフ

■ 10. Rust開発環境の整備

• Microsoftは最近Windows APIをRust開発者向けに準備した
• GitHubにwindows-rsというリポジトリがある:
  • これはWindows APIのRustプロジェクションでありRustコードがC++やC#と同じ方法でWin32COMWinRTを呼び出すことができる
• Microsoftはまた別にRustドライバー開発の取り組みがある:
  • GitHubのwindows-drivers-rsは会社がアプリを超えてRustを探求していることを示している
• このRust最適化は単発のプロジェクトや派手なオープンソース作業ではなく会社は本当にRustに真剣

■ 11. ネイティブ言語置き換えの課題

• これまでのところC++WinUIXAMLなどのネイティブ言語を置き換えようとするMicrosoftの試みは消費者や企業でもうまくいっていない
• 実際Microsoftはより広範な問題に貢献しており最も人気のあるWindowsアプリはDiscordや会社自身のTeamsなどRAMを消費するモンスター
• Windows UIは徐々にWebベースのコンポーネントに移行している
• アプリだけでなくスタートメニュー内にReactがある
• さらに通知センター内のカレンダーのアジェンダビュー用にWebView2を取得している
• これは通知センターを開くと新しいEdge/WebView2インスタンスがトリガーされることを意味する

■ 12. 今後の展望

• これらのエージェントプログラマーがWindowsや他のMicrosoft製品全体でCとC++コードをRustや他の言語にどれだけうまく変換するかは時間が経てば分かる

(2025/12/25)

Principal Software Engineer (CoreAI)

• Principal Software Engineer (CoreAI) | Microsoft Careers | Galen Hunt | 29件のコメント

要約:

■ 1. 更新による訂正

• 投稿が意図した以上の注目を集め多くの憶測を呼んだため訂正
• WindowsはAIを使ってRustで書き直されているわけではない
• チームのプロジェクトは研究プロジェクト
• 言語から言語への移行を可能にする技術を構築している
• 投稿の意図はこの複数年にわたる取り組みの次の段階に参加する同じ志を持つエンジニアを見つけることであってWindows 11以降の新しい戦略を設定することやRustが終着点であることを示唆することではなかった

■ 2. 募集ポジションの概要

• チームでIC5 Principal Software Engineerのポジションが空いている
• ポジションはレドモンドでの対面勤務
• 目標は2030年までにMicrosoftからCとC++のすべての行を排除すること
• 戦略はAIとアルゴリズムを組み合わせてMicrosoftの最大規模のコードベースを書き直すこと
• North Starは1人のエンジニアが1ヶ月で100万行のコード

■ 3. 構築したインフラストラクチャ

• この以前は想像できなかった作業を達成するために強力なコード処理インフラストラクチャを構築
• アルゴリズムインフラストラクチャ:
  • 大規模なソースコード上にスケーラブルなグラフを作成
• AI処理インフラストラクチャ:
  • アルゴリズムに導かれたAIエージェントを適用して大規模なコード修正を可能にする
• このインフラストラクチャのコアはすでにコード理解などの問題で大規模に稼働している

■ 4. Principal Software Engineerの役割

• このポジションの目的はMicrosoftの最大規模のCおよびC++システムをRustに変換できるようにするためにインフラストラクチャを進化させ拡張すること
• この役割の重要な要件はRustで本番品質のシステムレベルコードを構築した経験:
  • できればRustでシステムレベルコードを書いた経験が少なくとも3年
  • コンパイラデータベースまたはOSの実装経験が非常に望ましい
  • コンパイラ実装経験は応募に必須ではないがチームでその経験を習得する意欲は必須

■ 5. チームの特徴

• チームは成長マインドセットによって推進されている
• 幅広いスキルと視点を持つ多様なチーム
• 大胆なリスクを取る
• 他者とうまく協力し合う
• 社内外の顧客に価値をもたらすことを愛する
• 多様性と成長マインドセットが急速に変化するAIベースのツールの世界で成功するために重要であることを学んだ

■ 6. チームの所属組織とミッション

• チームはMicrosoft CoreAIのEngHorizons組織内のFuture of Scalable Software Engineeringグループの一部
• ミッションはMicrosoftと顧客が大規模に技術的負債を排除できるようにする機能を構築すること
• 社内の顧客やパートナーと新しいツールと技術を開拓し他のプロダクトグループと協力してMicrosoft全体および業界全体でそれらの機能を大規模に展開する

■ 7. 応募方法

• 応募または推薦するにはMicrosoft Career Hubを訪問
• Job ID 200013722

(2025/12/25)

【特集】AI巡るメモリ争奪戦――2026年はPC、スマホに“冬”が到来

• 【特集】AI巡るメモリ争奪戦――2026年はPC、スマホに“冬”が到来 - PC Watch

要約:

■ 1. メモリ高騰の現状

• DRAMだけでなくSSDやHDDまで高騰と品薄が続いている
• その一方CPUは人気のある特定製品のみやや値上がり傾向にあるがDRAMのような高騰や品不足とは無縁
• この一点で今回のDRAM高騰はPanic Buy必要以上の買い占め買いだめであると断言できる

■ 2. DRAM急騰の原因

• もともとの話は10月3日にOpenAIがSamsungおよびSK Hynixとの間でDRAMの供給契約を結んだ事を発表したことに端を発する
• この契約ではSamsungとSK Hynixが両社合計で毎月ウェハ90万枚分のDRAMをOpenAIに供給するとなっている
• ただしこれは今すぐではなく将来の話
• リリースにも明確にtargeting 900,000 DRAM wafer starts per monthとされており今後両社はこの契約に向けてDRAMの生産能力を引き上げていく計画

■ 3. 市場の早とちり

• SK Hynixは2026年のDRAM生産量を今年の8倍にする計画があることを韓国の韓経ドットコムの11月21日の記事で報じた
• これを今すぐこうなると早とちりしたベンダーがどこかにあったらしい
• 11月になって突如DRAMのスポット価格が高騰
• 10月にこのニュースが報じられて慌てたどこかのベンダーが急遽DRAMの契約の積み増しを掛けたらしい
• それも1社でなく複数社がこの動きをしたと思われる
• SamsungとSK HynixはOpenAIの契約分を賄うための増産で手一杯であり積み増しが行なわれた契約をこなせる余力は少ない
• 契約先はOpenAIと契約を結ばなかったMicronに集中するのはやむを得ない

■ 4. Micronの業績急上昇

• この結果がMicronによるCrucial事業の閉鎖と記録的な2026年第1四半期決算
• Micronは大きく4つの事業部門がある:
  • CMBUはハイパースケールのクラウド向けのDRAMとHBMを使うすべての顧客が対象
  • CDBUは中堅のクラウド/エンタープライズとOEMのデータセンター向けDRAMとすべてのデータセンター向けストレージが対象
  • MBCUはモバイルおよびクライアント向けのDRAMとストレージが対象でCrucialはこのMBCUのブランド
  • AEBUは自動車産業機器および民生機器に向けたDRAMとストレージが対象

■ 5. 事業部別の売上伸び率

• 前四半期からの売上の伸び率:
  • CMBUは16.3%
  • CDBUは50.9%
  • MCBUは13.2%
  • AEBUは19.9%
• CDBUの大幅な伸びがMicronの決算が好調だった最大の要因でありこれは現在のDRAM不足が招いたうれしい誤算
• CDBUのこの売上はHBM以外の契約が大幅に伸びた事を意味し単に件数だけでなく価格もかなり跳ね上がった

■ 6. 粗利益率の急増

• CDBUの2025年第4四半期の粗利益率は24.8%ほどだったが今季は56.4%まで跳ね上がっている
• ここまで粗利益率が急増するというのは契約の金額つまりDRAMチップ単価を猛烈に上げる契約が結ばれまくったということ
• MicronではこのCDBUの契約を最優先にせざるを得ない
• 結果Crucial事業向けのウェハを生産する余地がないほどMicronの生産能力が逼迫してしまったのがCrucial事業終了につながった

■ 7. 2026年の見通し

• この逼迫が1～2四半期で終わる程度ならあるいは一時的にCrucialブランドを休止するという選択肢もあったと思う
• Micron的にはこの状況が2026年一杯は間違いなく続くとみている
• 12月17日に行なわれたEarnings Callにおける説明:
  • 当面の間業界全体の供給は需要を大幅に下回ると見込まれる
  • こうした需給要因が相まってDRAMとNANDの両分野で業界全体の逼迫状態を招いておりこの逼迫は2026年以降も継続すると予想される
  • Micronは2026年のビット出荷量を20%増加させる見込みだがすべての市場セグメントにおける顧客の需要を満たせない状況は残念

■ 8. パニック買いとする理由

• 本当にAI需要が加速しているならCPUも不足しないとおかしいから
• 現在のAIデータセンターの使われ方はCPU+GPUの構成のサーバーを大量に並べる方式になる
• GPUサーバーにはDDRもSSDもHDDも必要ない
• GPUサーバーはチップ上のHBMを使うからDDR5は不要
• 本当に汎用サーバーが大量に必要になっているのであれば間違いなくサーバー向けCPUも増産を掛けなければならず当然コンシューマ向けCPUの供給にも影響が出るはず
• 秋葉原ではそんな動向はまったくないしこれは海外でも同じ

■ 9. 在庫積み増しの連鎖

• 現在のDDR5とかSSD/HDDはサーバーメーカーなどが今後需要が急増しても良いように在庫を積み増しているのが価格高騰と品不足の理由
• OpenAIのウェハ大量契約に起因してメモリ調達を焦ったメーカーがメモリも足りなくなるならストレージも足りなくなるんじゃねと早合点した結果SSDが不足気味になった
• SSDも足りないならHDDも足りなくなるだろうとさらに早合点を積み重ねた結果が現状

■ 10. 問題解消の見通し

• DDR5に関してはおそらく1年程度は変わらないだろう
• 全部契約に基づくからでMicronが2026年中は解消しないとみているということは1年程度の相対的に長期な契約が多いということ
• 買い漁っていたメーカーが実際にはやっぱ要らなかったと判断しても契約期間が終わるまでは毎月契約した分量がメモリメーカーから届くことになる
• その間は市場に出回る分量は当然減らざるを得ず品不足と高騰は収まらない

■ 11. 2027年以降の展開

• 現在の契約が終わるであろう来年末～2027年第1四半期末あたりから市場に流れる分が急激に増えると思われる
• サーバーなど向けに現在メーカー各社が貯め込んでいるDDR5とかSSD類はおそらく2026年中には消費しきれず2027年は相当契約を減らすと考えられる
• メモリメーカーは生産能力を2026年中に増強しておりDDR5の生産量も必然的に増える
• その頃にはSSD/HDDの在庫もメーカーに十分積みあがることでやはり市場への流通が急に増える
• 品余りになれば価格下落につながる

■ 12. 2026年の購入戦略

• 2026年はちょっとPCを買うには不適切な時期
• 必要という方はちょっと高値に付くであろうことは覚悟するしかない
• 待てるなら2027年まで待つのが得策
• 問題はこれがPCだけでなくスマートフォンやゲーム機などにも波及しそうなこと
• その意味でも2026年はいろいろ厳しい年になりそう

(2025/12/24)

なぜ日本のIT業界の元請けは零細企業と直接契約しないのですか？に対する伊本貴士さんの回答

• なぜ日本のIT業界の元請けは零細企業と直接契約しないのですか？に対する伊本貴士さんの回答 - Quora

この話来ましたね。

確かに日系の大手IT企業には契約を結ぶ基準というのがあり、その基準を満たす企業でないと発注はしません。(通称、口座を持つという)

私自身、大手企業にいてこの制度というか仕組みは不思議に思っていたので勝手に追求した事がありました。

色々理由を聞いたのですが、第一に責任能力らしく、つまり何かあった時に人的もしくは金銭的な責任をどこまで取れるかという問題だそうです。

例えば、1億の案件があるとする。そのうちの開発をAという会社に任せるとする。しかしAという会社のエンジニアがバグだらけのコードを書いたり、バックれたりして納期が間に合わない時、顧客と裁判になります。(日常茶飯事)

当然、裁判の結果によっては、賠償金を支払う事になります。この時A社にも当然責任はあるのでって話だそうです。(しかしA社に金を払わせたという話はあまり聞いた事がない)

あとはA社が大きいほど、担当がばっくれても他の人を当てがってなんとかしてくれるだろうという安心感もあるそうです。

仮に特殊な技術が必要で零細のB社に仕事を発注したい時でも、A社を間に入れて取引します。(当然A社は書類を書いて流すだけですが何割かマージンを取ります。保険のようなものですね。)

そんなバカなと思うかもしれませんが、先ほど述べたルールがあるのでそれを徹底します。

流石にもう古いルールなんでもうやめればと個人的には思うのですが、大企業はルールを作ることはできても、ルールを廃止するのは苦手なのでいまだにやっているのでしょう。

ちなみにこれも個人的な考えですが、下請けの責任能力を問うくらいなら、丸投げしないで、自分たちで責任持って開発もきちんとマネジメントしてやるっていう発想はないの？と糾弾した事もありますが、全く通じませんでした。

(2025/12/24)

ソフトウェアエンジニアの本質は“課題解決”なのか？

• ソフトウェアエンジニアの本質は“課題解決”なのか？ - mtx2s’s blog

要約:

■ 1. 問題提起と背景

• エンジニアの本質は課題解決であるという台詞に対し筆者はずっと軽い違和感を持っていた
• この違和感が明確に表出したのは最近である
• ソフトウェアエンジニアリングの現場にAIエージェントが入り込んだ今こそこの違和感を言語化すべきと考えた
• AIがコーディングを代替しつつありその精度は高まり担える領域も確実に広がっている
• エンジニアという職種の本質をあらためて問い直す必要がある

■ 2. エンジニアの本質は課題解決であるという言葉の問題点

• この言葉には限定性と多義性という性質がある
• 範囲を絞り込み同時に意味を広げてしまうという二つの性質が同時に含まれている
• 言葉の構造:
  • エンジニアのという限定性
  • 課題解決という言葉の多義性
  • 課題解決であるという限定性

■ 3. エンジニアのと限定する不自然さ

• 課題解決という営みはエンジニア職に固有のものではない
• ビジネスに関わる多くの職種にとってその本質は課題解決にある
• 企業のミッションは抽象度をあげれば課題解決に行き着く
• 特定の職種を指してその本質が課題解決にあると語ることに不自然さがある
• この限定性の背景:
  • 手段が目的化しやすいというエンジニアという専門職特有の事情
  • 専門技術を追求する面白さに没頭するがあまり何のために技術を行使しているのかを忘れやすい
  • デザイナーがデザイン性にばかり気を取られ機能性を見失う構造と類似
• コードを書くことそのものをエンジニアの仕事だと捉えすぎることへの批判が含まれている

■ 4. 課題解決という言葉への解像度の低さ

• 課題解決という言葉は響きがビジネス的で格好良いが便利に使われすぎる側面がある
• 何を指しているのか分かったようで分からない
• 課題解決と呼ばれる営みに含まれるプロセス:
  • 現状把握
  • あるべき姿の設定
  • 問題の特定
  • 原因分析
  • 課題の設定
  • 解決策の実行
• 一連のプロセス全体がエンジニアの本質なのか最後の解決策の実行だけを指しているのかが曖昧
• 本来は三人の石切り工の話に近く解決策の実行だけを担っていても全体を通して課題を解決しているという認識を持つべきという意味
• 課題解決という言葉は文脈によっては受託開発の構造を想起させやすい:
  • ウォーターフォール型の工程分離が前提
  • 上流工程と下流工程として異なる役割が割り当てられる
  • エンジニアが主に担う解決策の実行の役割を指す責務の話として受け取られる場合がある
• あるべき姿と現状のギャップを対象とする課題解決だけがエンジニアリングの営みではない
• 新しい価値を生み出すことや既にある価値を維持し将来へ継承していくことは必ずしも明確な問題から始まるわけではない
• これらの営みも抽象度を上げれば課題解決という枠組みの中に含めて捉えることができる

■ 5. 課題解決であるとの断定による問題

• であるという限定的な言い回しは課題解決が持つ多義性を包み込む余地をかえって狭めている
• 課題解決が狭義の意味に閉じてしまうような印象を与えかねない
• 聞き手の意識が価値創造や維持・継承へと向かう余地をあらかじめ狭めている
• 話し手自身も狭義の課題解決という枠組みの中でしか物事を捉えられていない可能性
• ソフトウェアエンジニアという職能の可能性を静かに狭めてしまう行為になり得る

■ 6. エンジニアリングの提供価値

• エンジニアの本質とはエンジニアリングの生み出す価値そのものである
• 三つの観点:
  • 複雑性を秩序に変換する
  • 再現性と効率性を創出する
  • 持続可能性を維持する
• 複雑性を秩序に変換する:
  • ソフトウェア開発はそもそも不確実なものを扱う営み
  • エンジニアリングの本質は不確実性の削減
  • 不確実性コーンが示すように不確実な状態から確実な状態へと変えていく活動
  • 絶え間ない探索と論理を手がかりとして複雑性に秩序をもたらす営み
• 再現性と効率性を創出する:
  • ソフトウェアは同じことを同じように何度でもできる
  • 再配布可能な知識やスキルのパッケージ
  • ソフトウェアで処理される知識やスキルや手続きは人間が処理するよりも速く安定している
  • 人間の能力が拡張される
• 持続可能性を維持する:
  • ソフトウェアは完成した瞬間から変わり続けることを宿命付けられた成果物
  • 変更が容易でなければソフトとは言えずその価値が失われていく
  • ソフトウェアの稼働期間が長いほどその振る舞いに変更が入る
  • それに耐えうる構造を維持し進化させ続けることが単なるプログラミングとエンジニアリングを分ける
  • 持続可能性の維持は設計や実装の巧拙だけで決まるものではない
  • 変更を前提にした意思決定や構造への投資の積み重ねによって形作られる

■ 7. エンジニアの本質の定義

• GeminiやChatGPTと定義の言語化を繰り返した結果導き出されたエンジニアの本質:
  • 論理の力で混沌とした現実に再現性のある秩序を与えることで価値を持続的に創出し人間の可能性を拡張し続けること
• 短縮すると再現性ある価値の継続的な創出
• 企業で働くエンジニアの価値は自社のミッションのもと目の前のユーザーや顧客やビジネスあるいは社会に向き合いこの役割定義を実行することで具現化される

■ 8. AI時代におけるエンジニアの本質

• AIがコーディングを代替するようになってもエンジニアのアイデンティティが崩壊するわけではない
• エンジニアの本質は変わっていない
• AIが担う領域がさらに広がっても同じ
• コーディングエージェントとの協働は新しい知的な楽しさももたらしている
• ケント・ベックが50年に及ぶプログラミング経験の中で今が一番楽しいと述べている
• 手段が目的化しやすいのは専門職種の宿命であり対象に深く没頭している証であり知的好奇心の表れ
• その追求は個人の満足にとどまらず組織に新たな可能性や能力の飛躍をもたらすこともある
• 夢中になることはエンジニアリングの原動力
• AIとの協働で形は変わっても技術への探究心は持ち続けるべき
• その探究の先で混沌とした現実に秩序を与え再現性ある価値として社会に残していく
• AI時代においても変わらないエンジニアの本質がある

■ 9. 記事執筆の経緯

• パネルディスカッションでエンジニアの本質は課題解決であるという言葉への違和感を表明したことがきっかけ
• それをあらためて整理し言葉にしてみようとしたのが本記事の試み
• AI時代においても本質が変わらないという点ではソフトウェア開発組織の設計原理についても同様
• AIによって開発が加速するほど組織構造に由来する摩擦は無視できなくなる

(2025/12/24)

「手作業でやってきた部分ほど自動化しづらい」 MIXI社「インフラAI活用」の“泥臭い” 実践

• 「手作業でやってきた部分ほど自動化しづらい」 MIXI社「インフラAI活用」の“泥臭い” 実践 | レバテックラボ（レバテックLAB）

(2025/12/24)