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に出会って貰い
試しに使ってもらえるようにしたいということで、やります タダです
以上再確認させて頂きました
ニューヨーク市長就任式、ラズパイと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下院議員らが登壇している。
■ 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つに集約される:
- 好奇心を持ち続ける — 学ぶことをやめない
- 謙虚であり続ける — 「わからない」と言える/一緒に答えを探す
- 人を忘れない — ユーザーのために作りチームと一緒に作る
- 尊敬すべきエンジニアは常に正解を出した人ではなく失敗から学び気づきを周りと分かち合い諦めずに現場に立ち続けたエンジニア
- 最終的には「どうすれば自分をすり減らさずにこの仕事を長く続けられるか」を教えてくれるもの
WAI-ARIA APG パターンを React、Vue、Svelte、Astro で実装したアクセシブルな UI コンポーネントとテストを提供します。 簡潔な実装例と検証可能なテストで、アクセシブルなインターフェース構築を支援します。 ダークモード、ハイコントラスト、強制カラーモードにも対応しています。✨
■ 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. 結論
- エンジニアが個人として合理的に動いた結果事業が後退してしまうのは構造的なインセンティブの帰結
- 「うちのエンジニアは大丈夫」と慢心せずに対策していくことを推奨
- 最高なのは個人の合理性と組織の合理性を一致させること
- それを思わせるのが経営者の役割
- エンジニアと経営者が同じ方向を向いて判断できる組織は強い組織
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データベースであり、すべて外部要件がゼロの単一の依存関係にあります。
■ 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ツールは「単なるツール以上でも以下でもないもの」として位置づけられる見込み
■ 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の軽快な開発体験はこの本質に集中することを可能にする
■ 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を作る側も使う側もこの変化を正面から考える段階に来ている
■ 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の特徴を体験する
- 手動リアクティビティによる状態管理・型安全なルーティング・そしてフォーム送信の仕組みを実装を通じて理解していく
■ 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導入したけどつかえない」系の議論の大半はこれで説明できるのではないか
- 過渡期の生みの苦しみだと思うがみんながぶつかる課題なのでナレッジシェアできるといい
■ 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も出るのでその辺りの動きも気になる
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はどこから知識を仕入れるのでしょうか。ちょっと心配になってしまいました。
■ 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でもできない人間が担っていくべきもの」と締めくくった
- 1. 体裁をレビューするのではなく、中身をレビューする
- 2. 標準化ではなく、顧客や案件ごとに最適化できるような自由度をチームに与える
- 3. レビューの目的を明確にする
- 4. 大がかりなレビューを少ない回数実施するのではなく、こまめな小規模レビューを繰り返す
- 5. レビューでの指摘事項をすべて対応しなければならないとは限らない。チームにとって労力をかけるだけのメリットがあるものから優先順位付けをして実施する
- 6. レビューで人格を非難しない
- 7. レビューの順番もレビュー効果が高いものから実施すること
- 8. 機械的に検証可能なドキュメントのレビューは自動化すること
- 9. レビューワーも技術もしくは顧客の業務をしっていること
- 10. レビュー結果はチーム内外含めて共有すること
■ 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件以上訪問して課題に向き合ってきた
- エンジニアとしての時間をドメインを考えることに対して使っていきたいという想いが年々強まっている
- 技術選定の正解探しに時間を溶かすのではなく選んだ技術を正解にするためのオーナーシップと何よりユーザーへの価値提供を大切にしていきたい
Z世代に多い「褒められると伸びるタイプです」と自分で言ってしまう人には、マネジメント上かなり注意したほうがいい。もちろん、承認が動機づけになる人は多いし、褒めること自体は悪じゃない。問題は、その言葉が単なる自己理解ではなく、責任の所在のすり替えとして使われること。本人は無邪気に言っているようで、実はその一言の中に「成長にとって致命的な壁」がある。
自分が成長できるかどうかは相手がどう接するかで決まる。言い換えると、自分は変わらずに環境や他人を変えようとしている。これは成長の方向とは真逆のマインドセット。成長のアクセルを他人の手に渡している状態。
厄介なのは、このタイプは褒めを「免罪符」や「取引条件」として使うことがある点。「褒めてくれないなら、成長できなくても仕方ない」という責任回避。承認がなくなった瞬間にエンジンが止まる。もっと悪いと、承認がない状態を「不当な扱い」と感じて不満や被害者意識へと変換する。
この構造の裏側には、心理的な防衛がある。過剰なプライド、あるいは自尊心の脆さ。自尊心が不安定な人ほど外部からの承認に依存しやすい。褒められると嬉しいのではなく、褒められないと崩れる。ここが根っこだと、指摘を受け入れる器が小さくなる。なぜなら指摘は、本人の中では改善提案ではなく自分の価値への攻撃として処理するから。自己評価が脅かされると人は合理性より防衛に走る。反論する、言い訳する、話を逸らす、黙る、落ち込む、拗ねる。表面的には反省して見せるけど内面では反省していない。この現象は珍しくない。
ここで重要なのは「反省の言葉」と「反省の中身」は別物だということ。とりあえず謝る、とりあえず「すみません」と言う、とりあえず「気をつけます」と言う。これを繰り返すと、本人の中で反省っぽいことを言えばその場を切り抜けられるという学習が成立し、負の成功体験が生まれる。反省の言葉を言うことで、叱責や不快から逃げられる。それが報酬になってしまう。結果、行動は変わらない。本人が悪意を持っているわけではなく、学習の結果として「反省の言葉」だけが巧妙になる。言葉は良いのに成長がない。謝るのに同じミスを繰り返す。こういう人を放置してはいけない。
では、どうマネジメントするべきか。このタイプの人を伸ばすには、まず「褒められると伸びる」という自己定義が、成長とは逆向きになることを本人に理解させないといけない。そのうえで「すごい」「偉い」みたいな人格承認ではなく「何をどうやったか」という行動承認に寄せる。努力やプロセスを承認すると成長マインドセットが育ちやすい。再現性のある行動を承認することで「気分の報酬」ではなく「行動の強化」につなげる。
次に、成長とはフィードバックによって行動の引き出しを増やすことだと繰り返し教え、認知の再構成をさせる。本人の中で「指摘＝攻撃」から「指摘＝武器が増える」に変換できたら受け取り方が変わる。
そして、反省の言葉ではなく次の行動でしか評価しないこと。「すみませんでした」では終わらせず「次に何を変える？」「明日から何をやめる？」「同じ状況で、次はどう動く？」まで必ず言語化させる。さらに「いつ確認するか」まで決める。曖昧な反省は変化を生まない。具体の行動だけが変化を生む。この運用を続けると「反省っぽいことを言って逃げる」学習が崩れていく。本人は最初しんどい。なぜならこれまでの防衛が通用しないから。でも、ここで初めて本当の成長が始まる。
「褒められると伸びるタイプ」という自己申告が危険なのは、褒めが必要だからではなく、成長の責任を外に置いてしまいやすいから。成長する人は褒められなくても伸びる。褒められたら加速する、くらいの位置づけにしている。伸びない人は、褒められないと止まる。そして止まった理由を環境のせいにする。この差は能力の差ではなくマインドセットの差。マネージャーの仕事は、そのマインドセットを本人に与え、成長の責任を本人に戻し、承認を依存ではなく強化として使い、反省を言葉ではなく行動に変える設計を作ること。
このプロセスを踏めるようになると、外部承認に依存する人、自尊心が脆い人、プライドが高い人、反省の言葉が上手い人など、マネジメント難易度が比較的高い部下をマネジメントできるようになる。
新卒エンジニアで「1日3~4時間だけ集中してコードを書いて、残り時間は Slack を徘徊する」みたいなゆるい働き方を覚えてしまってからそこから抜け出すのにかなり苦労したし、抜け出せない人は一定数いる
■ 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言語の高い注目度が採用事例へと積極的に移行していくことになるのではないかと期待を込めて予想する
■ 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だけでは違和感がある)
■ 1. 記事の背景と目的
- 本多将大によるnote記事である
- 2025年も周りの皆さまのおかげで多くの学びを得ることができた
- 資金調達フェーズでいうとシリーズA以降B未満従業員数の規模でいうと50名未満のSaaS企業の営業部での学びを言語化する
- 少しでも他の人の役に立てたらと思いnoteに残すことにした
■ 2. プレイングマネージャーの課題認識
- プレイングマネージャーは個人に依存しやすい役割である
- 能力やスタミナに支えられた運用は短期的には機能するが再現性やスケールの観点では限界が見えやすい
- 営業部においてもプレイヤーとしての成果とマネジメントとしての成果を同時に求める構造が結果として意思決定の質とスピードを下げている場面があった
- この状況を踏まえ営業部ではプレイングマネージャーという役割を努力やバランス感覚の問題ではなく構造の問題として捉え直すことにした
■ 3. 役割の切り出しと意思決定レイヤーの独立
- 営業部ではこれまで実行と判断が同じレイヤーに存在していた
- その結果施策は「やる・やらない」という議論に収束しやすく本来行うべき評価や選別が後回しになる傾向があった
- そこで施策を実行単位として扱うのではなく企画として独立させ意思決定レイヤーを切り出す運用へ移行した
- これにより意思決定は施策そのものではなく定量の可視化・データに基づく分析・分析結果を踏まえた施策選択を起点に行われるようになった
- 結果として施策は属人的な打ち手ではなくKPI改善に対する投資判断のアウトプットとして整理された
- 限られたリソースをどこに配分すべきかを選択できる状態がつくられている
■ 4. マネージャーの能力を組織の上限にしない設計
- この運用変更を通じて明確になった点がある
- それはマネージャー個人の能力や判断が組織の上限を規定してしまうリスクである
- 営業部のマネージャーがプレイヤーとしても深く関与する構造では判断の幅や試行回数が個人のキャパシティに制約されやすい
- 意思決定を企画レイヤーに集約することで経験や勘への依存を抑えつつこれまで現実的ではなかった打ち手も冷静に検討できるようになった
- 営業部の上限は人の能力によって自然に決まるものではない
- 設計次第で引き上げられるものだという認識に変わってきている
- この構造設計と運用は企画が主導して前線を担い営業部のマネージャーである私はその設計と判断に対する最終責任を持っている
■ 5. 育成の構造化
- 営業部における育成も同様に構造化している
- 正解を言葉で説明することよりもどのような判断基準で意思決定しているかを共有することを重視している
- 具体的には商談への同席などを通じて実例を提示する
- その後になぜその言葉を選んだのか・なぜそのプランその金額なのか・なぜその時間軸で提案したのかといった判断理由を言語化して補足する
- これにより個別の成功体験ではなく再現可能な判断軸として営業部内に知見が蓄積されていく
- 特にARPAを引き上げる文脈では成果の共有よりも判断基準の共有が有効に機能している
■ 6. 人材の捉え方と配置の考え方
- 営業部では人を単なる人数や稼働時間といった固定的なリソースとしてではなく前提条件の異なる存在として捉えている
- 能力差は確かに存在するがそれは優劣よりも強み・経験・得意な局面の違いによるものだと考えている
- そのため成果は本人の能力だけで決まるのではなく配置の仕方や期待の置き方・関与の度合いによって大きく変わる
- 実務では定量で傾向を把握したうえで担ってもらう役割・求めるアウトプットの水準・マネージャーや周囲の関与の深さを調整しながら再現性のあるアウトプットをつくることを重視している
- 新しく営業部に加わったメンバーについては早く組織に馴染んでもらうことよりも短期間で一つ成果を出せる状態をつくることを優先している
- 小さくても成果が出ると仕事の進め方や関係性への理解が進み結果として信頼や一体感は後から自然についてくる
■ 7. 結論
- プレイングマネージャーという役割は個人の頑張りによって成立させるものではない
- 意思決定のレイヤーは分離されているか・判断は定量と分析を起点に行われているか・人の特性が構造として活かされているかを前提条件として運用を見直すことで成果が変わることを実感してきた
- 営業部のメンバーと仕事をする中で形づくられてきた学びに感謝しつつ2026年もみなで良い年にしたい
■ 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が生成したコードをその場で編集している場合は設定ドリフトの最悪の時代をより速く追体験している
- 年ではなく日でレガシーシステムを作成している
- 燃やして再生し火に耐えたものを信頼せよ
■ 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をうまく取り入れることで工数削減と満足度成長実感の向上を同時に実現できた事例
■ 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. まとめ
- 筆者が所属するチームで実際に行っているマネージャーに依存しないチームとしてのマネジメントの仕組みづくりについて紹介した
- マネージャーがボトルネックにならずチームメンバーそれぞれが主体的に動く自己管理型のチームは自分たちで壁を乗り越えていくしなやかさをもっている
- 本稿がそういったチームが増えていく一助になれば幸い
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のように見えますが、その複雑さや曖昧さ、落とし穴を避けようとしています。
■ 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を使用し続けサポートし続けるすべての開発者とユーザーに感謝
- 世界はこれまで以上に安全で分散型のコミュニケーションを必要としている
エンジニアには2種類いて、根本原理からしっかり解ってる人と、パターンやテンプレートで仕事してる人。
大学進学率がまだまだ10%代で、受験産業が発達してなかった1970年代卒のエンジニアは、明らかに前者でとにかく凄かったよ。僕が社会に出た頃の先輩達は。でも現代は後者が多い気がするね。
ところが海外製の半導体を見ていると、海外は明らかに前者が多いね。ほんとプロ集団的な。
マウスコンピューターは、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データセンターの需要増の影響で価格が急騰。多くのコンシューマ製品において、深刻な品不足や価格増加を招いている。
■ 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への移行に疑問を呈している
- エンジニアはこの選択を言語に組み込まれたメモリと並行性の安全メカニズムを強調することで擁護している
■ 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や他の言語にどれだけうまく変換するかは時間が経てば分かる
■ 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
■ 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年はいろいろ厳しい年になりそう
この話来ましたね。
確かに日系の大手IT企業には契約を結ぶ基準というのがあり、その基準を満たす企業でないと発注はしません。(通称、口座を持つという)
私自身、大手企業にいてこの制度というか仕組みは不思議に思っていたので勝手に追求した事がありました。
色々理由を聞いたのですが、第一に責任能力らしく、つまり何かあった時に人的もしくは金銭的な責任をどこまで取れるかという問題だそうです。
例えば、1億の案件があるとする。そのうちの開発をAという会社に任せるとする。しかしAという会社のエンジニアがバグだらけのコードを書いたり、バックれたりして納期が間に合わない時、顧客と裁判になります。(日常茶飯事)
当然、裁判の結果によっては、賠償金を支払う事になります。この時A社にも当然責任はあるのでって話だそうです。(しかしA社に金を払わせたという話はあまり聞いた事がない)
あとはA社が大きいほど、担当がばっくれても他の人を当てがってなんとかしてくれるだろうという安心感もあるそうです。
仮に特殊な技術が必要で零細のB社に仕事を発注したい時でも、A社を間に入れて取引します。(当然A社は書類を書いて流すだけですが何割かマージンを取ります。保険のようなものですね。)
そんなバカなと思うかもしれませんが、先ほど述べたルールがあるのでそれを徹底します。
流石にもう古いルールなんでもうやめればと個人的には思うのですが、大企業はルールを作ることはできても、ルールを廃止するのは苦手なのでいまだにやっているのでしょう。
ちなみにこれも個人的な考えですが、下請けの責任能力を問うくらいなら、丸投げしないで、自分たちで責任持って開発もきちんとマネジメントしてやるっていう発想はないの？と糾弾した事もありますが、全く通じませんでした。
■ 1. 問題提起と背景
- エンジニアの本質は課題解決であるという台詞に対し筆者はずっと軽い違和感を持っていた
- この違和感が明確に表出したのは最近である
- ソフトウェアエンジニアリングの現場にAIエージェントが入り込んだ今こそこの違和感を言語化すべきと考えた
- AIがコーディングを代替しつつありその精度は高まり担える領域も確実に広がっている
- エンジニアという職種の本質をあらためて問い直す必要がある
■ 2. エンジニアの本質は課題解決であるという言葉の問題点
- この言葉には限定性と多義性という性質がある
- 範囲を絞り込み同時に意味を広げてしまうという二つの性質が同時に含まれている
- 言葉の構造:
- エンジニアのという限定性
- 課題解決という言葉の多義性
- 課題解決であるという限定性
■ 3. エンジニアのと限定する不自然さ
- 課題解決という営みはエンジニア職に固有のものではない
- ビジネスに関わる多くの職種にとってその本質は課題解決にある
- 企業のミッションは抽象度をあげれば課題解決に行き着く
- 特定の職種を指してその本質が課題解決にあると語ることに不自然さがある
- この限定性の背景:
- 手段が目的化しやすいというエンジニアという専門職特有の事情
- 専門技術を追求する面白さに没頭するがあまり何のために技術を行使しているのかを忘れやすい
- デザイナーがデザイン性にばかり気を取られ機能性を見失う構造と類似
- コードを書くことそのものをエンジニアの仕事だと捉えすぎることへの批判が含まれている
■ 4. 課題解決という言葉への解像度の低さ
- 課題解決という言葉は響きがビジネス的で格好良いが便利に使われすぎる側面がある
- 何を指しているのか分かったようで分からない
- 課題解決と呼ばれる営みに含まれるプロセス:
- 現状把握
- あるべき姿の設定
- 問題の特定
- 原因分析
- 課題の設定
- 解決策の実行
- 一連のプロセス全体がエンジニアの本質なのか最後の解決策の実行だけを指しているのかが曖昧
- 本来は三人の石切り工の話に近く解決策の実行だけを担っていても全体を通して課題を解決しているという認識を持つべきという意味
- 課題解決という言葉は文脈によっては受託開発の構造を想起させやすい:
- ウォーターフォール型の工程分離が前提
- 上流工程と下流工程として異なる役割が割り当てられる
- エンジニアが主に担う解決策の実行の役割を指す責務の話として受け取られる場合がある
- あるべき姿と現状のギャップを対象とする課題解決だけがエンジニアリングの営みではない
- 新しい価値を生み出すことや既にある価値を維持し将来へ継承していくことは必ずしも明確な問題から始まるわけではない
- これらの営みも抽象度を上げれば課題解決という枠組みの中に含めて捉えることができる
■ 5. 課題解決であるとの断定による問題
- であるという限定的な言い回しは課題解決が持つ多義性を包み込む余地をかえって狭めている
- 課題解決が狭義の意味に閉じてしまうような印象を与えかねない
- 聞き手の意識が価値創造や維持・継承へと向かう余地をあらかじめ狭めている
- 話し手自身も狭義の課題解決という枠組みの中でしか物事を捉えられていない可能性
- ソフトウェアエンジニアという職能の可能性を静かに狭めてしまう行為になり得る
■ 6. エンジニアリングの提供価値
- エンジニアの本質とはエンジニアリングの生み出す価値そのものである
- 三つの観点:
- 複雑性を秩序に変換する
- 再現性と効率性を創出する
- 持続可能性を維持する
- 複雑性を秩序に変換する:
- ソフトウェア開発はそもそも不確実なものを扱う営み
- エンジニアリングの本質は不確実性の削減
- 不確実性コーンが示すように不確実な状態から確実な状態へと変えていく活動
- 絶え間ない探索と論理を手がかりとして複雑性に秩序をもたらす営み
- 再現性と効率性を創出する:
- ソフトウェアは同じことを同じように何度でもできる
- 再配布可能な知識やスキルのパッケージ
- ソフトウェアで処理される知識やスキルや手続きは人間が処理するよりも速く安定している
- 人間の能力が拡張される
- 持続可能性を維持する:
- ソフトウェアは完成した瞬間から変わり続けることを宿命付けられた成果物
- 変更が容易でなければソフトとは言えずその価値が失われていく
- ソフトウェアの稼働期間が長いほどその振る舞いに変更が入る
- それに耐えうる構造を維持し進化させ続けることが単なるプログラミングとエンジニアリングを分ける
- 持続可能性の維持は設計や実装の巧拙だけで決まるものではない
- 変更を前提にした意思決定や構造への投資の積み重ねによって形作られる
■ 7. エンジニアの本質の定義
- GeminiやChatGPTと定義の言語化を繰り返した結果導き出されたエンジニアの本質:
- 論理の力で混沌とした現実に再現性のある秩序を与えることで価値を持続的に創出し人間の可能性を拡張し続けること
- 短縮すると再現性ある価値の継続的な創出
- 企業で働くエンジニアの価値は自社のミッションのもと目の前のユーザーや顧客やビジネスあるいは社会に向き合いこの役割定義を実行することで具現化される
■ 8. AI時代におけるエンジニアの本質
- AIがコーディングを代替するようになってもエンジニアのアイデンティティが崩壊するわけではない
- エンジニアの本質は変わっていない
- AIが担う領域がさらに広がっても同じ
- コーディングエージェントとの協働は新しい知的な楽しさももたらしている
- ケント・ベックが50年に及ぶプログラミング経験の中で今が一番楽しいと述べている
- 手段が目的化しやすいのは専門職種の宿命であり対象に深く没頭している証であり知的好奇心の表れ
- その追求は個人の満足にとどまらず組織に新たな可能性や能力の飛躍をもたらすこともある
- 夢中になることはエンジニアリングの原動力
- AIとの協働で形は変わっても技術への探究心は持ち続けるべき
- その探究の先で混沌とした現実に秩序を与え再現性ある価値として社会に残していく
- AI時代においても変わらないエンジニアの本質がある
■ 9. 記事執筆の経緯
- パネルディスカッションでエンジニアの本質は課題解決であるという言葉への違和感を表明したことがきっかけ
- それをあらためて整理し言葉にしてみようとしたのが本記事の試み
- AI時代においても本質が変わらないという点ではソフトウェア開発組織の設計原理についても同様
- AIによって開発が加速するほど組織構造に由来する摩擦は無視できなくなる
■ 1. 壊れやすいコードの共通点
- 実務でコードを書いているとこの処理どこから手をつければいいんだろうと立ち止まる瞬間に何度も出会う
- 少し仕様が変わっただけで影響範囲が読めなくなる
- 1つ修正すると思わぬ別の場所が壊れる
- 自分では丁寧に書いているつもりなのにどんどん扱いづらくなっていく
- 壊れやすいコードの共通点はデータ構造が曖昧なまま実装に入っていること
- 優秀なエンジニアほどコードを書く前にまず扱うデータをどう設計するかに時間を使う
- これはセンスではなく壊れにくいシステムを作るうえでの再現性のあるプロセス
■ 2. データから考えると壊れにくくなる理由
- コードが壊れる原因は処理が複雑だからではない
- 多くの場合扱うデータが曖昧なまま実装が進んでしまっていることが本質的な原因
- 処理から考え始めると次のような問題が起きやすくなる:
- 想定外の値が混ざる
- null/undefinedが途中で暴れる
- 状態管理がif文に散らばる
- これは本来コードを書く前に決めておくべき前提条件がコードの外に残ったままになっている状態
- この前提の漏れが仕様変更のたびに壊れる構造を生む
■ 3. データを先に設計する利点
- データを先に設計しておくと以下が明確になる:
- 何が入力なのか
- 何が正常な状態なのか
- 何が起きると不整合になるのか
- 実装に一貫した軸が生まれる
■ 4. 情報ではなく状態をデータとみなす
- 多くの人はデータ=文字や数値と捉えるが実務で重要なのは状態
- 状態の例:
- ログイン前/ログイン後
- 未読/既読
- 有効/無効
- 下書き/公開
- これらはUIのラベルではなくアプリケーションが保証すべき前提そのもの
- 状態が曖昧なまま実装するとif文が散らばり仕様変更のたびに壊れる
■ 5. 値だけでなく関係もデータ構造に含める
- データ設計で見落とされがちなのは関係性
- 関係性の例:
- ユーザーと組織
- 記事とコメント
- 予約枠と担当者
- 商品と在庫
- 関係性が曖昧なまま実装するとこのデータどれと紐づいてるんだっけという混乱が必ず発生
- 関係はおまけではなくデータ構造そのものの中心
■ 6. 仕様に書かれていない前提をデータ化する
- 実務には仕様書に書かれていない重要な前提が必ず存在
- 前提の例:
- ユーザーは1つの組織にしか所属できない
- 予約は担当者×サービス×日時で一意になる
- メッセージの編集履歴は削除後も保持する
- こうした暗黙にされているかもしれない前提をデータに落とし込まないと機能がその前提に依存していたときに壊れるという事故が起きる
- 優秀なエンジニアほど仕様に書かれていない前提を発掘してデータとして扱うという工程を怠らない
■ 7. 自然言語で書ける重要性
- 最初からER図やクラス図を書く必要はない
- まずやるべきなのは扱う状態や前提を自然言語で説明できるようにすること
- 例:
- ユーザーは複数組織に所属できるがデフォルト組織は1つ
- 予約は日時・担当者・サービスの3つが揃って成立する
- メッセージ編集は可能だが履歴は別レコードで保持する
- 自然言語で曖昧ならコードではもっと曖昧になる
■ 8. Step1 自然言語で状態関係前提を列挙する
- まずはコードから離れて自然言語で現在の仕様を洗い出すところから始める
- 例:
- 予約は日時×担当者×サービスで構成される
- ユーザーは複数組織に所属できるがデフォルト組織は1つ
- メッセージ編集は可能だが履歴は残す
- 曖昧な表現でも構わない
- 最初は全体像を漏れなく書き出すことが大事
■ 9. Step2 同じ概念をまとめ不要な状態を削る
- 洗い出した状態や関係を見直し以下を判断して整理:
- 本当にアプリが管理すべき状態はどれか
- UIの名前ではなく構造として必要な状態はどれか
- 状態は多ければ多いほど壊れやすくなるため削る工程こそ設計の核心
■ 10. Step3 変化する状態と変化しない状態を分ける
- どの値が変化しどの値が不変かを明確にする
- 例:
- 予約の作成日時は不変
- 予約のステータスは可変
- ユーザーIDは不変
- メールアドレスは可変
- この境界線を引くだけで更新ロジックのバグが激減
■ 11. Step4 状態遷移を書く
- 状態が整理できたらどの状態からどの状態に遷移できるかを明文化
- 例:
- draft → reserved → completed
- draft → canceled
- reserved → canceled
- これにより以下がすぐに可視化される:
- 到達しない状態
- 不正遷移
- 不整合の原因
■ 12. Step5 データ構造として定義する
- 整理した情報を型・スキーマ・ER図に落とし込む
- 具体的な手段:
- TypeScriptの型
- Prisma schema
- Rustのstruct + enum
- Swiftのstruct/enum
- DBのテーブル定義
- 状態・前提・関係が整理されているのでここから先の実装は驚くほどスムーズ
■ 13. データ構造設計の重要性
- データ構造の設計は実装の前作業ではなく実装を壊れにくくするための中心工程
- 重要なポイント:
- 曖昧なまま書き始めるほど壊れやすくなる
- データが明確なら処理は自然とシンプルになる
- 状態・関係・前提が揃えば仕様変更に強くなる
- 優秀なエンジニアがデータ構造を先に決めるのはセンスではなく後の開発すべてを安定させる最もコスパの良い投資だから
■ 1. マネジメント経験と違和感
- 筆者は数年間チームマネジメントを経験しどうすれば良いマネージャーになれるか模索した
- サーバントリーダーシップについて多くを読んだがしっくりこなかった
- サーバントリーダーシップはカーリングペアレンティングに似ている
- リーダーや親が問題を予測し直属の部下や子供のために道を掃き清める
■ 2. サーバントリーダーシップの問題点
- 直属の部下や子供にとっては最初は非常に良い感じがする
- サーバントリーダーやカーリングペアレントはすぐに過重労働の単一障害点になる
- リーダーが去ると誰もリーダーが取り除いた障害への対処方法を知らない
- 最悪のケースでは組織の他の部分から完全に隔離された人々のグループを残す
- 彼らは自分たちの目的が何であるか世界の他の部分とどう適合するかの概念を持たない
■ 3. トランスペアレントリーダーシップの提唱
- 筆者は独自の造語としてトランスペアレントリーダーシップを提案
- 良いリーダーの行動:
- 人々をコーチする
- 人々を繋げる
- 人々に体系的な問題解決を教える
- 組織が受け入れている価値観と原則を説明し自分で整合性のある意思決定ができるよう支援する
- 需要と供給の間に直接的なリンクを作る
- 直属の部下にリーダーシップの責任を徐々に引き継がせることでキャリア成長を可能にする
- 継続的に自分の後継者を訓練する
- 一般的に自分自身を不要にする
■ 4. 中間管理職の理想像
- 有用な仕事を何も行わない中間管理職は面白いステレオタイプだが良い目標でもある
- 違いは自分を不要にした後に何をするかにある
- よくある反応は新しい仕事を発明しステータスレポートを要求し官僚主義を追加すること
- より良い反応は技術的な問題に取り組む作業に戻ること
- これによりマネージャーのスキルが新鮮に保たれ部下からより多くの尊敬を得られる
- マネージャーは書類整理係ではなく高性能な予備作業員になるべき
■ 5. サーバントリーダーシップへの批判に対する反論
- この記事はサーバントリーダーシップを誤って表現していると批判を受けた
- 批判者は真のサーバントリーダーはサーバントに期待されることをせず代わりにトランスペアレントリーダーのように行動すると主張
- サーバントリーダーシップという言葉の起源であるグリーンリーフはリーダーに仕える人々が以下のようになるべきだと強調:
- より健康的により賢明により自由により自律的により自分自身がサーバントになる可能性が高くなる
- 筆者は真のサーバントリーダーシップには反対していない
■ 6. 実践におけるサーバントリーダーシップの問題
- 筆者が反対しているのは実践で起こっているように見えるサーバントリーダーシップ
- マネージャーが退屈で難しい部分を行うことで部下が自分の仕事に集中できるようにする
- これはテイラー主義的な方法で狭く定義されている
- 真のサーバントリーダーシップは実質的にトランスペアレントリーダーシップと同じ
- 真のサーバントリーダーシップを勉強しない人々はサーバントリーダーがサーバントのように行動すべきだという誤った考えを持つ
Update from Microsoft.
Teams is down.
Messages are delayed.
Some aren't arriving at all.
We're investigating.
Investigating means the AI is investigating.
The AI that wrote the code.
That broke the code.
That is now debugging the code.
It's a closed loop.
Very efficient.
A user asked why their message didn't send.
I said "we're observing recovery in our telemetry."
They asked what that means.
I don't know what that means.
But the dashboard is green now.
Green means fixed.
Fixed means we changed the threshold for green.
The messages are still delayed.
But the dashboard doesn't know that.
Dashboards don't use Teams.
Someone on the infrastructure team tried to escalate.
Via Teams.
The escalation is still pending.
Somewhere in the queue.
With everyone else's messages.
The irony wasn't lost on them.
But the message was.
We have a backup communication channel.
It's email.
Email is also having issues.
Unrelated, obviously.
The root cause is under analysis.
Analysis means we asked the AI.
The AI said "no issues detected."
The AI wrote the detection system.
It detects what it wants to detect.
Very self-aware.
Not in the good way.
Last quarter I said 30% of our code is AI-written.
Teams is closer to 45%.
We were proud of that.
Past tense.
The AI optimized the message queue.
It optimized it to zero.
Zero messages. Zero latency.
Technically correct.
The best kind of correct.
Enterprise customers are asking for an RCA.
RCA means Root Cause Analysis.
The root cause is velocity.
We shipped faster than we understood.
Understanding isn't in the OKRs.
Shipping is.
We shipped.
Someone asked when Teams will be fixed.
I said "we're continuing our analysis."
Continuing means we started.
Analysis means looking.
Looking means hoping it fixes itself.
It usually does.
If you refresh enough.
Refresh is the user's responsibility.
We provide the experience.
They provide the resilience.
That's partnership.
The outage started at 2:30 PM ET.
Right before the holidays.
Millions of workers couldn't message their teams.
Some called it a disaster.
I called it "an unplanned wellness moment."
Productivity is a spectrum.
We're exploring the lower end.
The AI has proposed a fix.
The fix requires a deployment.
The deployment system uses Teams for notifications.
The notifications are delayed.
We're in a loop.
The loop is also AI-designed.
Very elegant.
From a certain angle.
Satya asked for a status update.
I sent it via Teams.
He hasn't responded.
I assume he's thinking about it.
The stock is up 2% today.
Outages don't move markets.
Narratives do.
The narrative is "AI efficiency."
The reality is "Teams is down."
But reality isn't in the earnings call.
The narrative is.
We're committed to reliability.
Reliability means it worked yesterday.
Yesterday is our SLA.
Thank you for your patience.
Patience means you have no choice.
We're in your enterprise agreement.
For three more years.
The circle of innovation continues.
マイクロソフトからのアップデート。
チームがダウンしています。
メッセージが遅れています。
まったく到着していない人もいます。
調査中です。
調査中とは、AI が調査していることを意味します。
コードを書いたAI。
それはコードを壊しました。
これでコードがデバッグされます。
それは閉ループです。
非常に効率的です。
ユーザーはメッセージが送信されなかった理由を尋ねました。
私は「テレメトリーで回復を観察しています」と言いました。
彼らはそれが何を意味するのか尋ねました。
それが何を意味するのか分かりません。
しかし、ダッシュボードは緑色になりました。
緑色は固定を意味します。
固定とは、緑のしきい値を変更したことを意味します。
メッセージはまだ遅れています。
しかし、ダッシュボードはそれを知りません。
ダッシュボードは Teams を使用しません。
インフラストラクチャ チームの誰かがエスカレーションしようとしました。
チーム経由。
エスカレーションはまだ保留中です。
行列のどこかに。
他の皆さんのメッセージも添えて。
皮肉は彼らにも負けていなかった。
しかし、メッセージはそうでした。
当社にはバックアップ通信チャネルがあります。
電子メールです。
電子メールにも問題があります。
明らかに無関係です。
根本原因は分析中です。
分析とはAIに聞いたということです。
AIは「問題は検出されなかった」と言いました。
AI が検出システムを書きました。
検出したいものを検出します。
とても自意識が強い。
良い意味ではありません。
前四半期、私はコードの 30% が AI によって書かれていると言いました。
Teams は 45% に近いです。
私たちはそれを誇りに思っていました。
過去形。
AI はメッセージ キューを最適化しました。
それをゼロに最適化しました。
メッセージゼロ。遅延ゼロ。
技術的には正しい。
最高の正解。
企業顧客は RCA を求めています。
RCAとは根本原因分析を意味します。
根本的な原因は速度にあります。
思っていたよりも早く発送していただきました。
OKR には理解が含まれていません。
送料はです。
発送しました。
Teams はいつ修正されるのかと尋ねた人がいます。
私は「分析を続けている」と言いました。
継続するということは、始めたことを意味します。
分析とは、調べることを意味します。
探すということは、自然に直ることを期待することを意味します。
通常はそうなります。
十分にリフレッシュできれば。
更新はユーザーの責任です。
私たちは体験を提供します。
それらは回復力を提供します。
それがパートナーシップです。
停電は東部時間午後２時３０分に始まった。
お盆休みの直前。
何百万人もの従業員がチームにメッセージを送信できませんでした。
ある者はそれを災害と呼んだ。
私はそれを「予期せぬ健康の瞬間」と呼びました。
生産性はスペクトルです。
私たちは下位端を探索しています。
AI が修正を提案しました。
修正には展開が必要です。
展開システムは通知に Teams を使用します。
お知らせが遅れております。
私たちはループ状態に陥っています。
このループも AI によって設計されています。
とてもエレガントです。
ある角度から。
サティアは状況の最新情報を求めました。
Teams経由で送信しました。
彼は返事をしていません。
彼はそれについて考えていると思います。
今日の株価は２％上昇した。
停電では市場は動かない。
物語はそうなります。
物語は「AIの効率化」です。
現実は「Teams はダウンしている」です。
しかし、現実は決算発表には反映されていない。
物語は。
私たちは信頼性を重視しています。
信頼性とは、昨日も機能したことを意味します。
昨日は SLA でした。
ご理解いただきありがとうございます。
忍耐とは、選択の余地がないことを意味します。
私たちは企業契約を結んでいます。
あと3年も。
イノベーションの輪は続きます。
エンジニアの“サラリーマン化”というか、最近の転職事情を見ていると、どの組織でも普通にサラリーマンとして優秀なシゴでき人材が、技術力も持っているケースが転職ではウケがいい、という話になっている。昔からある「典型的なエンジニア像」みたいなものは、だんだん薄れてきてますね
これは俺の経験則なんですが「モノ作りたいだけで人の上に立ちたくない」みたいな社会不適合者が作るモノってこういうモノが多いんだよね
一部は素晴らしいが歯抜けがあって全体としては機能しないモノ。そしてそういうモノを作る社会不適合者にチャンスを与えるのが世間知らずの金持ちで（続く
それが芸術作品とかなら別にどうもならんのだけど、工業機械とか建築とかになると話変わって来るんだよな
あの手の「モノ作りだけしたい」系の人間は、モノを作る人間として信用に値しないんだけど、一般人だけじゃなくて業界にもあの手の社不に夢見てるアホが多いんだよな
社会不適合者がなんで社会と不適合を起こすのかというと、物事の幾つかを極端に軽んじているからですよ、人付き合いとか、礼儀作法とか、報連相とかな
そういう人間が作るモノは、作者の性質から要素の幾つかが抜け落ちて欠陥品になるんだよ「作るモノだけは完璧」なんて事は現実的にありえない
■ 1. PMのキャリアにおける視点の転換
- Jr/Middle/Seniorの議論は自分の立ち位置を確認したいフェーズの自然な問い
- 意思決定や失敗を経て視座が変わると「自分はどこに立っているか」から「この判断を引き受けるのは誰か」へ関心が移行
- PMのキャリアには関心の向きが切り替わる明確な分岐点が存在
■ 2. 経営的語彙の習得段階
- PMを続けると事業視点/PL意識/長期価値/投資対効果などの語彙を使い始める
- プロダクトの外側を見る視点が身についた証拠であり成長の表れ
- このフェーズは最も楽しい段階である
- まだ痛みを伴わない段階
■ 3. 経営者が引き受ける現実
- 経営者が本当に引き受けているもの:
- 誰にも相談せずに決める瞬間
- 後から間違いに気づいても戻れない現実
- その判断で人や生活を変えてしまう感覚
- この話題になると抽象論に逃げるPMが多い
- 能力や意識の問題ではなく引き受けた経験がないだけ
■ 4. レベル論争に留まる理由
- レベル論争が好まれる理由は責任を曖昧にしたまま賢く振る舞えるから
- 言い訳の構造:
- そこまでは求められていない
- 権限がない
- 役割的に違う
- フェイクなPMはこの場所に長く留まる
- リアルなPMはある日ここから降りる
■ 5. 経営に片足を突っ込んだPMの特徴
- 共通点:
- レベル論争がどうでもよくなる
- 業務範囲の話を一段上から見るようになる
- 正解がない判断を無言で引き取る
- 「まあやるしかないよね」という言葉が出る
- この言葉は投げやりな諦めではなく覚悟が決まった人の決意表明
- この段階に達したPMはもうPMごっこには戻れない
■ 6. PMの最終進化系
- 肩書きは重要ではない
- 経営をやってしまっている人であり逃げないことを選んだ人
- 逃げない姿勢の内容:
- 数字から逃げない
- 人の感情からも逃げない
- 判断の結果を全部自分の名前で引き受ける
- 自分の仕事かどうかではなく自分がやらないと誰がやるのかで決める
■ 7. 分岐の認識
- 選別や優劣をつけることが目的ではない
- 分岐があるという事実をちゃんと認識することが重要
- レベル論争や業務範囲の線引きが大事に思えるフェーズも間違いではない
- そのフェーズがあるから次に進める
■ 8. 次のステージへの移行
- あるタイミングで議論が空虚に感じ始める契機:
- 正解が用意されていない判断が増える
- 誰かに委ねると歪む感覚が出てくる
- これは誰かに預ける話じゃないと思う瞬間が来る
- このときPMは次のステージに入る
■ 9. 経営との関係性
- 全員がCEOや事業責任者になる必要はない
- PMを続ける限り経営的な判断から完全に逃げ切ることはできない
- 肩書きに関係なく必ず現れる判断:
- どこに賭けるか
- 何を捨てるか
- どの未来を選ばないか
■ 10. 「まあやるしかないよね」の意味
- 諦めでも開き直りでもない前向きな言葉
- 前提条件:
- 完璧な情報は揃っていない
- 正解があるわけでもない
- でも決めないと前に進めない
- 現実を受け入れた人が前を向いたときに出てくる言葉
- 不確実の中での前進の合図
■ 11. PMの仕事の本質
- 役割定義で縛るには大きすぎる仕事
- 二面性:
- やると決めたらやってしまえる自由がある
- 引き受けた瞬間に重さがのしかかる
- レベル論争や業務範囲論争に違和感を覚え始めるのは視座が一段上がったサイン
■ 12. 変化の兆候
- 自分はいまどこに立っているんだろうから判断は誰が引き受けるべきなんだろうへ考える時間が移行
- その変化に気づいた時点でもう以前と同じフェーズにはいない
- 確認すべきポイント:
- どの現実が気づけば自分の手元に集まってきているか
- どの判断がいつの間にか自分の名前で残るようになったか
- PMという仕事は気づかないうちに経営という営みに近づいている
- 気づいてしまった人はもう少しだけ前に進めばいい
エンジニアの会話で重要なのが
「知識マウントを抑えて黙る」能力なんだよな。
“会話が下手なエンジニア”は、
・相手のコードレビューでマウントする
・技術知識を披露したくて割り込む
・聞かれてないのに設計思想を語り出す
こういった“瞬間的な快楽”で、
長期的な信用を失う。
結局、優秀なエンジニアは
必要なときに、必要な分だけ話すことができる。
雄弁は銀、沈黙は金。
コードも会話も“引き算”が大事なのである。
■ 1. AI時代におけるマネジメントスキルの重要性
- AI時代はプロジェクトマネジメントやチームマネジメントの重要性が上がるという話について考えたことを書く
- AI時代プロジェクトマネジメントとかチームマネジメントのスキルがめちゃくちゃ重要性上がるよねーという話をしまくっているがあまり理解されていない気がする
- 確信があるが重要性をうまく説明できていない
■ 2. AIによる個人のエンハンスとその限界
- 生成AIは個人をエンハンス(高める・強化)する力が強い
- 個人がエンハンスされた作業範囲に注目すればほんとうに信じられないくらいの品質向上・速度の向上が見られる
- AIが得意な作業の例:
- コーディングエージェント
- Deep Research
- 言語化・要約
- 図表化
- 画像化
- エージェントによる自動化
- これらは間違いなく多くの人にとって仕事の速度向上と品質の変化をもたらしている
- 2022年11月以来業務でもプライベートでも生成AIはないと困るレベルの存在になっている
- AIが得意な作業はとんでもない飛躍的な変化をしている
- 一方で事業の成果が飛躍的に伸びているわけではない
- 生成AI様のおかげで利益が出るようになり多くの会社で効率化が進み景気が良くなるという感じはしない
- 個人がエンハンスされるインパクトは凄いがそれは局所的である
- それが組織や事業全体にも効いているように錯覚している人が多いように感じている
■ 3. 経験したことがない強烈な局所最適の問題
- 生成AIは個人をエンハンスする力が強いので作業の変化に注目されている
- システム開発ならコーディング企画職ならリサーチやドキュメント化や図式化
- それを全体の成果につなげるのは簡単なことではない
- 局所的エンハンスが経験したことない強烈な局所最適である
- 数年前と比較したら魔法に見えるような局所最適である
- あまりの衝撃に仕事全体にも効いているように感じてしまうのではないか
- プロジェクトマネジメントとかチームマネジメントのスキルがある人が多数いないと全体でその効能を得ることはできないと伝えても重要性がちゃんと伝えられていない
- プロジェクトマネジメントとかチームマネジメントのスキルがある人が多数いないと全体でその効能を得ることはできないということ自体は納得されるものの個人のエンハンスが強烈すぎてその重要性・必要性は軽く見られてるんじゃないかと思っている
- その人たちがなにをすれば成果になるのかを示せてない
■ 4. 局所最適をアウトカムに変換する必要性
- ヤバいレベルの局所最適が起きても利益が爆増したり売上が上がったりしない
- 作業5000時間を削減ってやつを見るたびに怪しい数字だなと思う
- AIの活用だけに注目していてはいけなくてヤバいレベルの局所最適をどうアウトカムに変換できるかを問われているって強く意識する必要がある
- アウトカムに向かって動けるチームマネジメントだとかプロジェクトマネジメントやプロダクトマネジメントの力を持った人の価値がより高まるだろう
- ただAIを使うのが上手いとかAIを使いこなす知識を持っているだけじゃ成果には繋がらない
- AIをこう使えば良いという業務改善的な型なんかではなく個別具体の動きからしか成果は生まれない
- だからからこそチームマネジメントだとかプロジェクトマネジメントのスキルがある人たちがアウトカムに向かって動けるようにしていく必要がある
- それって当たり前の話じゃないのと思われるかもしれないが必要性は理解されていたと思うが生成AIによってより難しくなってるんじゃないの複雑な世界がより複雑になっていてそれを紐解く能力が必要になってるんじゃないのという問題提起を強くしていく必要がある
- こんなに業務改善されたよとか機能開発が爆速になったよってのはアウトカムを得るプロセスでしかない
- AIによってそのプロセスは驚くほど変化が起きてるが利益や売上だとか事業価値を上げるところまでもっていくところまで変化を及ぼさなくてはならない
- AIを使いこなすPMがいるって話でもないしマネジメントできる人はAIを制御するプロンプト書けるって話でもないし業務自動化とか複数人が関わるワークフローをAIでつなげる業務設計できる人が必要って話でもないがなんかそういう話になりがちである
- もっとうまくこれを説明できるようにならないとなあ
■ 1. 背景とProcess Manager導入前のアーキテクチャ
- イベント駆動のシステムで処理の流れが複雑化してピタゴラスイッチ状態になることがある
- あるイベントが発生してそれをトリガーに別の処理が動いてさらにその結果を受けて次の処理が連鎖していくうちに全体のフローを把握するのが困難になる
- どこで何が処理されるのかを追うのに複数のハンドラを行ったり来たりしながら読み解かなければならない
- エネルギー取引のドメインを扱うプロダクトを開発している
- 公平な取引が行われていたことを証明するため官公庁への取引ログ提出を求められる場合があり任意の時点でのシステム状態を復元できる必要があるためCQRS+Event Sourcingパターンを採用してシステムを構築している
- ある業務の完了をトリガーに別の業務を実行するというパターンは非常に多く見られる
- 注文が作成されたら履歴を作成する約定したら通知を送るといった後続業務が多数存在している
- Event Sourcingではイベントが一級市民であるため自然とイベントをトリガーとして非同期で後続処理を実行するパターンを採用することとなった
- 一連の業務処理を一つのトランザクションで実行するのではなくイベントを介して非同期に連携させることによって異なる業務同士を疎結合に実装できたりユーザーリクエストに対するレスポンス時間の短縮にもつながるなどイベント駆動の利点を得られている
■ 2. 直面した課題
- イベント駆動な業務プロセスの自動化を実現するため最初はイベントに対するハンドラを個別に定義するシンプルなアプローチを取っていた
- このパターンはイベントを受けて1つの処理を行うという単純なケースには適している
- 履歴作成や通知送信など多くの後続処理はこのパターンで実装している
- しかし業務プロセスが複雑になるとこのパターンでは対応しきれなくなった
- 2つの業務があり業務の開始位置が異なる場合:
- 業務①はイベントAから始まり処理1→イベントB→処理2-1の順に進む
- 業務②はイベントBから始まり処理2-2と進む
- どちらの場合も途中でイベントBを受け取るが特定のイベントに対応して後続の処理を実行するだけの単純なイベントハンドラではイベントBを受けたときにこれがどの業務プロセスに属するイベントなのかを判別できないため次にどの処理に進んでいいのかが判断できない
- この問題はイベントハンドラが前のステップのコンテキストを持たないことによって生じている
- 対応策として業務プロセスに関するコンテキスト情報をイベントに含める方法が考えられる
- しかしこれにはいくつかの課題がある:
- 業務プロセスの制御に関する情報までイベントに含めてしまうとイベントが本来持つ業務で起こった事実を記録するという責務から逸脱してしまう
- 異なる業務がお互いの存在を意識しなければならなくなり疎結合性が損なわれる
- 業務プロセスが増えるたびにイベント定義が肥大化し保守が困難になる
- 外部システムを経由する業務プロセスではそもそも自システムのコンテキスト情報をすべてイベントに含めてもらうこと自体が難しい場合もある
- 一連の業務プロセスを独立したイベントハンドラの組み合わせで実装すると全体のフローを把握しづらくなる
- どのイベントがどこで処理されるのかを追うために複数のハンドラを行き来しながら読み解く必要がありコードの可読性と保守性が低下する
■ 3. Process Managerパターンの概要
- Process Managerパターンを導入することで課題の解決を図った
- Process Managerはイベント駆動の処理フローの中に複数の集約間のメッセージ交換を仲介・調整する役割を追加するパターンである
- 業務フローにおける現在のステップやコンテキスト情報を保持し受け取ったイベントに基づいて次に実行すべきアクションを決定して発行する
- Process Managerは複数のステップからなる業務の流れを管理するステートマシンのように振る舞う
- Process Managerの動作:
- イベントを受け取る
- 現在の状態を確認する
- 次に行うべきアクションを決定して送信する
- 状態を更新する
- 実装時に意識したいのはProcess Managerはイベントを受け取りコマンドを発行するという責務に徹すること
- 業務ロジック自体はコマンドハンドラ側に実装しProcess Managerはあくまでどのコマンドを発行するかを決めるルーティング役に専念する
- こうすることでコマンドハンドラとProcess Managerにロジックが分散することを防ぎコードの見通しが良くなる
- 単純なイベントハンドラとProcess Managerの違い:
- イベントハンドラ:
- 状態を持たない
- 判断基準はイベントの内容のみ
- 適する用途は1イベント→1処理
- Process Manager:
- 状態を持つ
- 判断基準はイベント+現在の状態
- 適する用途は複数ステップの業務プロセス
■ 4. 実装例における要件
- エネルギー取引を扱うシステムにおいて注文を作成するプロセスを考える
- 自システムは業務効率化のために注文をクローズドに管理するシステムである
- それとは別に外部公開されている取引所システムが存在しユーザーはそちらにも注文を掲載したい場合がある
- 2つの市場:
- InternalMarket:自システムが管理する市場
- ExternalExchange:外部システムで管理される外部取引所
- ユーザーは自システムが管理する市場にのみ注文を掲載することもできるし外部システムの取引所またはその両方に掲載することもできる
- 両市場を選択した場合の注文作成の流れ:
- 自システムで注文を作成
- 外部システムに注文作成をリクエスト
- 外部システムからの作成完了通知を待つ
- 外部取引所への掲載を反映
- 自市場への掲載を反映
- 作成完了を通知
- ユーザーの画面に注文が反映される
- どちらか片方の市場のみを選択した場合は上記のフローから不要なステップが省略される
- 注文作成プロセスは上記のようにユーザー起点で始まる場合もあれば外部システムの取引所で注文が作成されたことをきっかけに自システムに注文を取り込む場合もある
■ 5. ProcessManagerインターフェースと呼び出し構造
- ProcessManagerの核となるインターフェース:
- CanHandle:このProcess Managerが処理すべきイベントかを判定
- Execute:イベントを受け取り状態に応じてコマンドを発行
- ExecFunc:コマンドバスへの委譲関数でこれを通じてコマンドを実行し他の集約を操作する
- Workerは複数のProcessManagerを保持しておりイベントを受け取ると対応するProcessManagerを探して実行する
- commandBusはコマンドをコマンドハンドラにルーティングするコンポーネントである
■ 6. 状態遷移の設計
- Process Managerの設計ではまずは業務プロセスを構成するステップとその状態遷移を整理することから始める
- 業務のステップ:
- NotStarted:プロセス未開始
- AwaitingExternalCreation:外部システムでの作成待ち
- AwaitingExternalListing:外部取引所へ掲載されたことをマークする処理待ち
- AwaitingInternalListing:自市場への掲載されたことをマークする処理待ち
- Completed:プロセス完了
- イベント:
- OrderCreated:自システムで注文が作成された
- ExternalOrderCreated:外部システムで注文が作成された
- ExternalOrderRejected:外部システムでの注文作成が拒否された
- ListedOnExternal:外部取引所への掲載が完了した
- ListedOnInternal:自市場への掲載が完了した
- もともとのリクエストの内容によって同じステップ・イベントでも次のステップが変わったり同じイベントが異なるステップで発生したりする
- 業務のコンテキストや現在のステップに応じて処理を分岐させる必要があるため単純なイベントハンドラの組み合わせでは処理の流れを把握することはかなり難しくなる
- Process Managerのメソッドとして各イベントのハンドラを実装していくため状態遷移を表形式でまとめると実装時に役立った
- 業務プロセスの状態を保持する構造体:
- ProcessID:業務プロセスを一意に識別するID
- Step:現在のステップ
- OrderID:対象の注文ID
- MarketDest:掲載先
- ProcessIDがポイントである
- 業務プロセスの開始時に例えば注文作成時にProcessIDを生成し後続のイベントにはこのProcessIDのみを含める
- イベント定義にプロセスのコンテキスト情報を含める代わりにProcessIDを使って複数のイベントにまたがるプロセスを識別し必要なコンテキストはStateから取得する
- 外部システムを経由したコンテキストの受け渡しについては今回のケースにおいては外部システムがリクエストIDを受け取り結果通知時に同じIDを返す仕組みであったためProcessIDをリクエストIDに含めることによって実現した
- 自システムに必要なコンテキスト情報をすべて外部システムに引き回してもらうのは現実的でない場合が多いがリクエストIDのような一般的な仕組みを活用することで実現できるところもこのパターンの利点である
■ 7. Executeメソッドとイベントハンドラの実装
- Executeメソッドではイベントの種類に応じたハンドラを呼び出し次の状態を保存する
- イベントハンドラは内部的にコマンドハンドラを呼び出しコマンドを実行する
- このとき新たにイベントが発生するため即座にコミットしてしまうと次の処理が現在の処理の完了を待たずに始まってしまい古い状態を参照して処理されてしまう可能性がある
- これを防止するためにコマンドの実行と状態の保存を同一トランザクション内で行うようにしている
- イベントハンドラでは現在のProcess Managerの状態に応じて処理を分岐させる
- ExternalOrderCreatedイベントを処理するハンドラでは現在のステップによって注文作成が自システム起点なのか外部システムなのかを判別し適切なコマンドを発行している
- ListedOnExternalイベントを処理するハンドラではもともとの注文作成時に指定された掲載先に応じて次のステップを分岐させている
- 以上のようにして複雑な業務プロセスをイベント駆動の利点を損なうことなく見通しよく実装することができた
■ 8. まとめ
- Process Managerが解決する課題:
- 単純なイベントハンドラでは複数ステップにまたがる業務プロセスでどの文脈のイベントかを判別できない
- 処理が複数のハンドラに分散し全体のフローを把握するのが困難になる
- Process Managerに業務プロセスに関する知識を集約し現在のステップやコンテキストを状態として保持することでイベント駆動の利点を損なうことなく複雑な業務プロセスを見通しよく実装できる
- 設計するときのポイント:
- まず業務プロセスをステップと状態遷移で整理すると実装しやすい
- 業務ロジックはコマンドハンドラ側に実装しProcess Managerはルーティングに徹する
- Process Managerは強力なパターンだが単純なケースには過剰な抽象化になり得るため使いどころを見極める必要がある
- 履歴作成や通知送信といった単純な後続処理はシンプルなイベントハンドラで実装している
- イベント駆動のシステムで業務プロセスが複雑化してきたときはProcess Managerパターンの導入を検討する
日本のソフトウェアエンジニアの求人を見ると、いまだにEC、広告、SaaS事業が中心な求人が多い
もちろんこれらも重要な分野だけど、安定していて伸びしろが読みやすい領域ばかりに人材と資金が集まっている印象が強い
一方で、アメリカの求人を見ていると、
AI/GPU、仮想通貨、自動運転、バイオテック、eVTOL、ドローンなど、次の10年をつくるような領域に挑戦できるポジションが本当に多くて羨ましいよね
単なる給与水準の差ではなく、どんな未来を作るかという選択肢の広さにギャップを感じる
SCSKは業務用大型コンピューターで用いるプログラミング言語「COBOL（コボル）」利用企業の支援事業を本格的に始めたと発表した。金融機関システムなどで取り入れられてきたものの、利用が縮小傾向にあるコボルを使ったシステム刷新や開発、運用を後押ししていく。
「COBOL PARK（コボルパーク、東京・江東）」を6月に設立した。SCSKが株式の66.7%を保有し、残りをベトナムIT大手FPTの日本法人、FPTジャパンホールディングス（HD、東京・港）が出資する。
コボルは業務用大型コンピューター「メインフレーム」で動作するソフトウエアの開発に使われてきた。ただクラウド化が進む中で、メインフレーム市場が縮小。コボルを扱える技術者が減少し、システムの刷新が難しくなっている。
■ 1. スタートアップの失敗率と主要因
- スタートアップの失敗率は推定で10社中9社
- 大半のスタートアップは巨大な競合による「他殺」ではなく内部問題による「自殺」で終わる
- YC創設者Paul Grahamは「スタートアップは他殺よりも自殺で死ぬ可能性が高い」と指摘
- 最大の脅威は通常会社の外部ではなく内部から来る
■ 2. 自殺vs他殺の概念
- Silicon Valleyの格言「スタートアップは死なず自殺する」
- 起業家Justin Kanは多くの若い企業が選択肢を使い果たすずっと前に崩壊することを観察
- スタートアップはまだ十分に存続可能な状態で自らを諦める
- 創業者が燃え尽きるか心が折れチームが終了を宣言
- 創業者はスタートアップが困難で大規模な疲弊を引き起こすことに気づき別の仕事に就くか学校に戻るか単に離れていく
- Y CombinatorのHarj Taggarは多くの企業が単に創業者が努力を止めるために失敗することに気づいた
- 成功するスタートアップは継続し続けるもの
- 勝つ方法は死なないこと
- 早すぎる諦めがしばしば真の殺し屋
- 内部問題の蓄積(明確な牽引力なし・絶え間ない障害・チームの意見の相違・ストレス)が絶望につながる
- YCの段階では企業は諦めるか創業者が仲良くできないために失敗する
- もう一つの大きな理由は企業が人々が本当に望むものを作っていないこと
- プロダクトマーケットフィットに到達していないか共同創業者と毎週戦っている場合創業者が継続する意志を失う理由は明白
- 外部競争だけが直接スタートアップを殺すことは稀
- 優れた製品と堅実なチームがあれば競合は簡単に破壊できない
- はるかに頻繁にスタートアップは不作為・対立・焦点の喪失によって自らを打ち負かし競争は単に見ているだけ
■ 3. 資金不足という最終症状
- 資金不足はスタートアップが死ぬ最も目に見える方法の一つ
- 100以上のスタートアップの事後分析で資金不足は失敗の第2位の理由
- しばしばスタートアップは次の資金調達ラウンドを間に合わせられないか初期資金が枯渇する前に収益が実現しない
- 資金不足は通常症状であり根本原因ではない
- より深い問題はなぜスタートアップが最初に資金不足になったのか
- 多くの場合プロダクトマーケットフィットを達成できなかったため
- 真に望む人がほとんどいないものを作っていたため収益と投資家の関心が低いまま
- ベンチャーキャピタリストMarc Andreessenは「第1の企業殺しは市場の欠如」と述べる
- 誰も必要としない製品を構築すればシード資金がいくらあっても最終的に現金は何も示さずに燃え尽き資金調達は不可能
- スタートアップはプロダクトマーケットフィットに決して到達しないときに失敗する
- プロダクトマーケットフィット以外に財務管理の誤りが終焉を加速させる可能性
- 一部のチームはビジネスを検証する前にあまりにも積極的に支出(多くの人を雇用・豪華なマーケティング)しキャッシュクランチを引き起こす
- 他のチームはマネタイズや資金調達が遅すぎ単に時間切れ
- 資金不足になった多くの創業者は実際には成功の瀬戸際にいたが早すぎる諦め
- Justin Kanは指標が急上昇しているときに創業チームが諦めるのを見ることは稀だと指摘
- 大半は成長が横ばいで資金が少ないときに諦める
- それはまさに忍耐と反復が必要な瞬間
- 一夜にして成功は実際には一夜にして起こらない
- 忍耐し滑走路を延ばす方法を見つける人(燃焼を削減・ピボット・ブリッジラウンドの確保)は事態を好転させる機会を得る
■ 4. 創業者の対立とチームの崩壊
- 資金不足が棺桶の最後の釘ならば共同創業者の対立はしばしば最初に棺桶を構築したもの
- Harvard研究者Noam Wassermanの統計では高い潜在性を持つスタートアップの65%が共同創業者間の対立により失敗
- 初期段階では創業チームが会社そのもの
- チームが崩壊すれば会社も一緒に崩壊することが多い
- 共同創業者の内輪もめは投資家を遠ざけ意思決定の麻痺を引き起こし社内から企業文化を毒する
- 間違った共同創業者を選ぶことは間違ったアイデアを選ぶことと同じくらい致命的
- スタートアップの伝承は共同創業者を結婚したカップルに頻繁に例える
- 関係が悪化すれば面倒な離婚が製品が有望であってもスタートアップを殺す可能性
- 大きな質問での不一致(急速に拡大すべきかペースを調整すべきか・会社を売却すべきかIPOを目指すべきか・成功をどう定義するか)は最終的に和解できない相違につながる
- 一人の創業者が10億ドルのユニコーンを構築することを想像し別の創業者が小規模で安定したビジネスで満足なら戦略と目標で衝突
- 明白な対立を超えて重要な創業者や初期チームメンバーが去るシナリオもある
- 共同創業者が辞めると若いスタートアップの士気と運営に信じられないほど厳しい
- 残りのチームは「単一創業者」問題を抱える
- すべての負担が一人の肩にかかる
- Paul Grahamは最初から単一創業者を持つことについて実際に警告
- 複数の創業者を持つスタートアップには優位性がある
- スタートアップを始めるのは一人には難しすぎる
- ブレインストーミングをする同僚が必要でありうまくいかないときに元気づけてくれる人が必要
- その仲間意識を失うとスタートアップの低い時期が耐えられなくなる可能性
- 創業チームメンバーが去った後すぐに会社が崩壊するのを見てきた
- 失われたスキルのためだけでなく感情的な接着剤がなくなったため
- 場合によっては残りの創業者が自信と勢いを失いゆっくりと消えていく
- 創業者間またはチーム間の不適合は良いアイデアでさえ沈める可能性
- 創業チームが整合し一緒にうまく機能することを確実にすることはスタートアップの生存に絶対的に重要
■ 5. 焦点の喪失と創業者の燃え尽き
- もう一つの一般的な自傷行為は創業者が焦点や動機を失うとき
- スタートアップは一途な献身を要求する
- リーダーが気を取られ始めると悪い兆候
- CB Insightsの分析では焦点を失うことはスタートアップが失敗する上位20の理由の第11位
- 時には創業者が新しいサイドプロジェクトを追い始める(別のスタートアップアイデアをいじる・コンサルティングギグを引き受ける・新しい趣味に手を出す)
- 他の時にはより微妙でチームが一つの戦略にコミットせずに新しい方向にピボットし続けるか一度にあまりにも多くの機能を追求して自分自身を薄く広げる
- いずれにせよスタートアップはリーダーが一つの明確なビジョンに全力投球していないため勢いを失う
- 焦点の喪失はしばしば情熱の喪失と結びついている
- 初期の頃には避けられない課題を乗り越えるために膨大な量の熱意が必要
- 創業者の心がもうそこにないなら進歩は停止する
- 成長が停滞したときに創業者が精神的にチェックアウトするのを見てきた
- 倍増する代わりに他の機会について空想を始める
- Justin Kanは辞めたい誘惑がJustin.tv中に何度も彼を襲ったと説明
- 物事が暗く見えたときに諦めて先に進む寸前に来る
- 苦痛な労苦から逃れたいと思うのは人間の本性でありスタートアップを運営することは確かに労苦になる可能性
- 創業者は極度のストレスと燃え尽きにも直面しモチベーションを奪う可能性
- 長時間・生き残るためのプレッシャー・感情的なジェットコースターが疲弊につながる可能性
- 創業者が燃え尽きると先延ばしを始めたり厳しい問題を避けたり重要な決定を委任したりする可能性
- これらはすべて腹の中の火が消えかけているサイン
- 最終的に情熱が再燃しなければスタートアップは放置からゆっくりと枯れる
- スタートアップは通常餓死しない・すべての機会と気晴らしに溺れる
- ミッションに焦点を合わせ続けることは聞こえるよりも難しいが自己誘発的な死を避けるために絶対に必要
■ 6. スタートアップの自殺を避ける方法
- 共同創業者を賢く選びビジョンで整合する:
- 共同創業者を選ぶことはアイデアを選ぶことと同じくらい重要
- 価値観と長期目標を共有することを確認
- 不一致の願望(一人の創業者は迅速な売却を望み別の創業者は永遠に構築したい)は対立につながる
- スタートアップの65%が共同創業者の対立により失敗することを覚えておく
- 共同創業者関係を注意深く扱いオープンにコミュニケーション
- 期待(株式分割・役割・出口戦略)を後で戦うよりも早期に整理する方が良い
- 人々が望むものを作る(プロダクトマーケットフィットを達成する):
- これはYCからの黄金律でユーザーが望むものを作らないことが究極の殺し屋
- ターゲットユーザーと絶え間なく話し実際の問題を解決していることを検証し神経に触れるまで反復する意志を持つ
- 顧客が本当に製品を愛しているなら死ぬ可能性ははるかに低い
- 牽引力は多くの問題を解決する・投資家を引き付けチームの士気を高め滑走路を延長する収益を提供
- Harj Taggarが言ったように多くのスタートアップは企業が人々が本当に望むものを作っていないために失敗
- 技術自体に恋をしない・人々にとって本当に重要な痛点を解決
- 滑走路と財務を慎重に管理する:
- 資金不足は多くの場合予防可能な失敗
- 常に滑走路(残りの現金の月数)を知り空になるずっと前に資金調達または収益マイルストーンを計画
- コストを管理下に保つ・ゆっくり雇用し針を動かすものに支出し虚栄心には支出しない
- 多くのスタートアップはあると良いものに資金を燃やし後で後悔
- 経験則として次の主要なマイルストーン(製品の立ち上げ・ユーザーターゲット・収益目標)に到達するのに十分なお金にバッファを加えて調達するよう試みる
- 物事が長くかかる場合は費用を削減するか延長ラウンドを調達する準備をする
- 魅力的ではないが生存はしばしば慎重な現金管理に帰着
- 投資家は「時間内に調達できない場合何をしますか」と尋ねる・答えを持つ(燃焼を減らす・戦略的パートナーを見つけるなど)ので危機に陥らない
- 本質的に機能するものを見つけるための時間を買う
- 焦点を保ち完全にコミットする:
- 一度に2つの会社を運営しようとしないしスタートアップをサイドハッスルのように扱わない
- 繁栄するスタートアップは通常創業者が両足で飛び込むもの
- 輝く新しいアイデアは常に誘惑する・すべてのウサギを追いかけることに抵抗
- Paul Grahamの「13文でのスタートアップ」のアドバイスは単に焦点
- チームは四半期ごとの最優先事項を知り気晴らしにノーと言う
- これは厳しい時期を耐え抜くことも意味
- 小さな勝利であっても進歩を続けていれば諦める多くの人々を生き延びる
- 格言にあるように失敗を保証する唯一の方法は試みるのをやめること
- ほぼすべての成功したスタートアップは物事が厳しく見えた段階を経たが創業者は継続した
- 決意と回復力をコアチームの価値観として育成
- 健全な共同創業者関係とチーム文化を育成する:
- 内部不和がスタートアップの殺し屋であるためチームを整合させ続けることに投資
- 共同創業者と絶えずコミュニケーション・パフォーマンス・株式・方向性についての厳しい会話を後ではなく早く行う
- 役割や報酬を調整する必要がある場合は対処
- 意見の相違を解決するメカニズムを設定(信頼できるメンターまたは仲介できる取締役会メンバー)
- 多くの対立は明確なコミュニケーションと共感によって和らげることができる・スタートアップを勝たせようとしている同じ側にいることを覚えておく
- また全員が懸念を声に出せ燃え尽きが認識される文化を構築
- 完全な疲弊を避けるために必要なときに休憩を取るよう人々(創業者自身を含む)に奨励
- 支援的でミッション駆動型の文化は欲求不満と不一致を防ぐのに役立ちしばしばスタートアップの自殺につながる
- 成功(と失敗)を一緒に計画する:
- 悲観的に聞こえるかもしれないが物事が南に行く場合に何が起こるかを事前に議論
- 一人の創業者が出たい場合はどのように処理するか
- 買収オファーが来た場合は両方とも売却にオープンか
- これらのシナリオで整合することは後で多くの心痛を節約できる
- 反対側で成功のための共有計画を作成・すべてがうまくいけば私たちのビジョンは何か
- 共通のビジョンを持つことは暗い日々の間皆のモチベーションを維持
- 共同創業者が同じ最終ゲームとなぜそれが戦う価値があるかを見るときにコミットし続けることが容易
■ 7. 結論
- ほとんどのスタートアップは市場の捕食者のために終わりを迎えない
- 内部の失策・壊れた関係・意志の喪失のために終わりを迎える
- 経験豊富な創業者からの事後分析とエッセイはすべてこの真実を反映・スタートアップの運命は主に自分の手の中
- 反対側は力を与える・古典的な落とし穴を避けチームの世話をすれば生存の確率を大幅に高める
- 人々が望むものを構築しチームを団結させ賢く支出し決して早すぎる諦めはしない
- そうすれば自分のスタートアップが単に自殺を避けるだけでなく実際に繁栄しビジョンが生き返るのを見る機会を劇的に高める
- Paul Grahamが有名に暗示したように勝つ方法は死なないこと
- 生き続ければ最終的に成功する機会を自分に与える
■ 1. 技術概要
- SPhotonixが5Dメモリクリスタルの商用化に向けて450万ドルの資金調達を完了
- 2025年12月に英国とスイスに拠点を置くディープテック・スタートアップが発表
- 溶融シリカガラスを用いた事実上の恒久保存を実現するデータストレージ技術
- 宇宙の年齢に匹敵する138億年の耐久性を誇る
- 既存ストレージ(HDD・SSD・磁気テープ)は数十年から100年程度で限界を迎えるのに対し圧倒的な優位性を持つ
■ 2. 5次元記録のメカニズム
- フェムト秒レーザーによるナノ構造化技術:
- サウサンプトン大学Peter Kazansky教授が20年以上研究
- 1000兆分の1秒という極めて短いパルス幅を持つレーザーを使用
- 5つのパラメータでデータをエンコード:
- X座標(空間的位置)
- Y座標(空間的位置)
- Z座標(空間深さ)
- 配向(ナノ構造の向き)
- 強度(光の遅相軸の強さ)
- 溶融シリカガラス内部に微細なボクセル(3次元ピクセル)を刻み込む
- ボクセルは複屈折特性を持ち入射する光の偏光や方向によって異なる屈折特性を示す
- 偏光させた光を照射しその変化を光学的に検出することでデータを復元
- 5インチのガラスディスク1枚に最大360TBのデータを格納可能
- 一般的な大容量HDD(30TB級)の10倍以上の密度を実現
■ 3. 耐久性と安全性
- 190℃の高温環境下で138億年のデータ保持が可能
- 耐熱性・耐環境性:
- 石英ガラスは化学的に極めて安定
- 磁気の影響を受けない
- 放射線・水・湿度による劣化がほぼ皆無
- データ保持に電力を一切必要としないエアギャップなメディア
- ランサムウェア攻撃に対する究極の防御策として機能
■ 4. 市場背景とエネルギー問題
- コールドデータの定義と分類:
- 世界中に保存されているデータの60〜80%がコールドデータ
- ホットデータは5ミリ秒未満でのアクセスが必要(SSDの領域)
- ウォーム/クールデータは数秒以内のアクセスで十分
- コールドデータはアーカイブ・法的記録・科学データなどアクセス頻度は低いが長期保存が義務付けられ取り出しに10秒以上かかっても問題ない
- 現状の問題点:
- 慣性により人々はコールドデータ保存にも寿命が短くエネルギーを大量に消費するHDDやSSDを使い続けている
- AIの台頭によりデータ生成量は指数関数的に増加
- IDC予測によれば2028年までに年間生成データ量は天文学的な数値に達する
- 持続可能性の観点:
- 全データを回転するHDDや通電が必要なSSDで保存し続けることは電力消費と廃棄物の観点から持続不可能
- HDDは数年ごとのリプレイスが必要でそのたびに莫大なコストと廃棄物が発生
- SPhotonixのガラスメディアは一度書き込めばリフレッシュや空調による厳密な温度管理なしに永久にデータを保持可能
- データセンターのTCO(総所有コスト)とカーボンフットプリントを劇的に削減する可能性
■ 5. ビジネス戦略
- 資金調達:
- 2025年11月25日にCreator FundとXTX Venturesが主導するプレシードラウンドで450万ドルを調達
- 技術成熟度レベルをTRL5(技術検証段階)からTRL6(プロトタイプ実証段階)へ引き上げるために投資
- Arm/NVIDIAモデルの採用:
- 製造会社になるつもりはないとIlya Kazansky CEOが明言
- 自社で大規模なガラスディスク量産工場を建設せず核心となるイネーブリング・テクノロジーを開発しライセンス供与するモデル
- ハイパースケーラーやストレージベンダーとコンソーシアムを組みデータセンターにプロトタイプを展開する計画
- コストとパフォーマンス:
- 書き込み装置は約30,000ドル(約450万円)
- 読み取り装置は約6,000ドル(約90万円)
- 現在の転送速度は書き込み4MB/s・読み取り30MB/s
- 3〜4年以内に読み書き共に500MB/sまで引き上げる計画
- 実現すれば現在のアーカイブ用磁気テープシステム(LTOなど)と競合可能な水準
■ 6. 競合分析
- Microsoft Project Silica:
- 同様にフェムト秒レーザーと石英ガラスを用いたストレージを開発
- Azureクラウド向けのアーカイブソリューションとして実証実験を進行中
- 自社のAzureインフラへの垂直統合を主眼に置く
- Cerabyte:
- セラミック素材を用いたストレージを開発するスタートアップ
- SPhotonixの優位性:
- オープンなエコシステム志向
- ライセンスモデルを通じて多様なデータセンター事業者やハードウェアメーカーが技術を利用できるプラットフォームを提供
- 元Project Silicaの研究者を採用する計画を明かし技術的な知見の集約を図る
■ 7. 文化的意義と実績
- 技術の象徴的なデモンストレーション:
- 全ヒトゲノムデータを結晶に保存
- Eon Ark Time Capsuleとして2024年〜2025年の会話記録をアーカイブ
- 名作ゲーム『Heroes of Might & Magic 3』を保存
- 映画『ミッション:インポッシブル/ファイナル・レコニング』において技術がフィーチャー
- 人類の知識と文化を文明の存亡を超えて保存する究極のバックアップとしての役割
■ 8. 技術的意義と展望
- 磁気や電荷という不安定な現象への依存から脱却し結晶構造という物理的な恒久性を手に入れる転換点
- ハイパースケーラー各社が直面するエネルギー問題とデータ爆発の圧力が今後数年で技術の実用化を強力に後押し
- 読み書き速度の向上とコストダウンという課題は残存
- TRL6への移行とライセンスモデルの採用により技術が実験室を出てデジタル社会の基盤となる日が近い
- 数千年後の未来において現代の文明を伝えるのはSPhotonixのクリスタルに刻まれた光の記憶である可能性
■ 1. 背景と課題
- DBコストが毎月徐々に上昇する問題に直面
- 予約管理システムで薬剤師が最新の予約情報をリアルタイムで確認できることが重要な要件
- フロントエンドから30秒間隔でAPIをポーリングする実装を採用
- システムの成長とともに問題が顕在化
- ポーリング間隔は30秒で1回あたりのAPIコール数は9回
- 予約検索APIの秒間リクエスト数は約2,000リクエスト/秒
- 予約一覧・予約詳細・ステータス情報など画面表示に必要な情報を複数のエンドポイントから取得していたため1回のポーリングで9回のAPIを呼び出し
- 多数の薬局クライアントが同時にポーリングを実行するためリクエスト数が膨大化
- 予約データは日々構造が複雑になりデータベースのテーブルにインデックスを張っても大きな負荷がかかる状況
- ポーリング方式の根本的な問題はデータに変更があってもなくても定期的にリクエストが発生する点
- 予約データに変更が発生する頻度はポーリング頻度と比較してかなり低い
- 大半のリクエストは「変更なし」という結果を返すだけで実質的な価値を生み出していない
- 無駄なリクエストが継続的にデータベースへ負荷をかけインフラコストを押し上げる要因
- プロジェクトで導入店舗数が倍増し月次のインフラコストレビューでDBコストの上昇トレンドが明確化したことが転機
■ 2. 解決策の設計思想
- 変更があったときだけ通知を受け取る方式への転換を決断
- 従来のプル型(ポーリング)からプッシュ型(イベント駆動)への転換により不要なリクエストを根本的に排除することを目指す
- 処理フロー:
- 予約データに変更が発生(イベント発火)
- イベント伝播用マイクロサービスがサブスクライブ
- マイクロサービスがFirestoreの薬局別ドキュメントを更新
- フロントエンドがFirestoreの変更を検知
- 必要な予約データをAPIから取得
■ 3. アーキテクチャコンポーネント
- 予約サービス(イベント発行元):
- 予約の作成・更新・キャンセルなどの変更を検知しイベントを発行
- 既存の予約システムに最小限の変更を加える形で実装
- Cloud Pub/Sub:
- Google Cloudが提供するフルマネージドなメッセージングサービス
- イベントの非同期配信を担いシステム間の疎結合を実現
- イベント伝播サービス:
- GKE上で稼働する軽量なマイクロサービス
- Pub/Subからイベントを購読しFirestoreの更新を行う
- 独立させることで関心の分離と保守性の向上を図る
- Firestore:
- 薬局ごとのイベント状態を管理するリアルタイムデータベース
- 各薬局に対応するドキュメントを用意しイベント発生時にタイムスタンプを更新
- フロントエンドクライアント:
- Firestoreのリアルタイムリスナー機能を使用して自身に関係するドキュメントの変更を監視
- 変更を検知したら必要なデータをAPIから取得
■ 4. 技術選定の根拠
- Firestoreを選んだ理由:
- リアルタイム同期機能が標準装備でSDKを使うだけで面倒な接続管理なしにリアルタイム同期が実現可能
- Google Cloudのマネージドサービスとして自動的にスケールしクライアント数の増加に対してインフラ側での対応が不要
- 薬局ごとのドキュメント分離により各薬局が自身に関係するドキュメントのみを購読するため不要なデータを受信しない
- 既にGKEやPub/Subを使用していたため同じエコシステム内で完結できる
- Pub/Subを介在させる理由:
- システム間の疎結合化により予約システムはFirestoreの存在を知る必要がなく「イベントを発行する」という責務のみを持つ
- 信頼性の向上でPub/Subはメッセージの永続化と再送機能を持つため一時的な障害が発生してもイベントが失われない
- Pub/Subのメトリクス(未処理メッセージ数・処理時間など)を監視することでシステムの健全性を把握しやすい
- 将来的には分析基盤への連携・通知サービスへの連携などイベントの配信先を追加する可能性があり拡張が容易
- Cloud Tasksを選んだ理由:
- 動的なタスクスケジュールに最適でフルマネージド
- 指定した時刻に1回だけHTTPリクエストを送信するというシンプルな機能を提供
- キューの管理やスケーリングを意識する必要がない
■ 5. スロットリング機構の実装
- 課題:
- 予約の登録や更新・キャンセルなどが短時間の間に行われた場合に多数のイベントが発生
- 同じ薬局に対して数秒間で何十回もFirestoreが更新される
- フロントエンドが変更を検知するたびにAPIを呼び出し結局大量のリクエストが発生
- スパイク時の負荷が改善されない
- 解決策:
- Cloud Tasksを使ったスロットリング機構を導入
- 一定時間内に発生した複数のイベントを1回の通知にまとめる
- Cloud Tasksで遅延実行を行い指定時刻にHTTPリクエストを送信
- スロットリング間隔の調整:
- 10秒という値を採用
- 通常の予約操作ではユーザーが10秒以内に複数回更新することは稀
- 複数イベント発生時のイベント集約効果が十分に得られる
- ユーザーが体感する遅延として許容範囲内
- モニタリングの結果を見ながら調整を継続
■ 6. テスト戦略
- イベント発生ケースの網羅:
- イベントが正しく発火されることがシステム全体の動作に直結
- イベントの発火漏れがあればフロントエンドに変更が伝わらずユーザーは古い情報を見続ける
- イベントが発生するすべてのケースを洗い出し網羅的にテストを実施
- ケースの洗い出し:
- 予約作成(処方箋事前送信予約・オンライン服薬指導予約・店頭受付)
- 予約更新(日時変更・ステータス変更・患者情報変更・メモ追記)
- 予約キャンセル(ユーザー操作・自動キャンセル・管理者操作)
- 動作確認の観点:
- イベントが正しく発火されるか(Pub/Subにメッセージがパブリッシュされることを確認)
- イベント内容が正しいか(薬局ID・予約ID・イベントタイプが正確に設定されていることを確認)
- Firestoreが更新されるか(該当薬局のドキュメントが更新されることを確認)
- フロントエンドが検知するか(画面上で変更が反映されることを確認)
- リグレッションテストとの擦り合わせ:
- 既存のリグレッションテストで今回洗い出したイベント発生ケースがカバーされているか確認
- カバーされていないケースがあれば新たにテストケースを追加
- イベント発火の確認をリグレッションテストの検証項目に追加
- 本番リリース後のイベント発火漏れはゼロを達成
■ 7. 導入結果
- 定量的効果:
- 予約検索APIの秒間リクエスト数は約2,000/秒から約1,000/秒へ50%削減
- DBコストは30%削減
- ネットワークトラフィックは大幅削減
- 定性的効果:
- リアルタイム性の向上で従来は最大30秒の遅延があったが予約の変更がほぼリアルタイムで画面に反映
- システム安定性の向上でポーリングによる定期的な負荷スパイクがなくなりデータベースへの負荷が平準化
- 開発者体験の改善で各コンポーネントの責務が明確でデバッグや機能追加がしやすくなった
■ 8. 運用上の考慮事項
- 成功要因:
- 段階的なリリースでまずは一部の薬局から段階的に展開し想定外の問題があった場合の影響範囲を限定
- 監視体制の整備でPub/Subの未処理メッセージ数・Cloud Tasksの実行遅延・Firestoreの読み取り/書き込み数・フロントエンドからのAPI呼び出し数を監視
- チーム内での知識共有で新しいアーキテクチャについて設計の意図や運用方法をドキュメント化し属人化を回避
- 留意すべき事項:
- イベント欠損への対策としてPub/Subの再送機能を活用(デッドレターキューの設定)
- 順序保証の考慮で分散システムにおいてはイベントの到着順序が発生順序と一致するとは限らない
- Firestoreコストの試算で導入前に試算を行いトータルでコストメリットがあることを確認
■ 9. 今後の展望
- スロットリング間隔の動的調整で時間帯やイベント発生頻度に応じて動的に調整することでさらなる最適化が可能
- 他システムへの水平展開で今回得られた知見を他のポーリング処理を行っているシステムにも展開予定
■ 1. 記事の背景と概要
- 履歴というデータを取り扱うことのために考えていること・戦い方について整理した内容である
- 履歴のデータはとても重要になる場合があり履歴管理や監査証跡・時点復元・法令対応などで「過去の状態を正確に残したい」という要件が発生することがある
- この記事の概要:
- 「状態」の保存は一見シンプルだが履歴要件が入ると破綻しやすい
- Bi-temporalは強力な設計手法だがクエリ・運用の複雑さが課題になりやすい
- Event Sourcingは「変化」を中心に据えることで履歴が自然に残すことができる
- ただしRead ModelやVersioningなど別の複雑さとのトレードオフがある
■ 2. 一般的なRDB設計の問題点
- ほとんどのRDBで管理されているデータは「現在の状態」だけを保存するように設計されている
- このテーブルで「注文をキャンセルした」という履歴を残そうとすると以下の方法が考えられる:
- 方式A:変更前スナップショット方式
- 方式B:ステータス更新＋別途「変更履歴テーブル」にINSERT
- 方式C:有効期間を持たせるテンポラルテーブル方式
■ 3. 方式A:変更前スナップショット方式の問題点
- 変更前の状態だけを履歴テーブルに保存する方式である
- 悩みポイント:
- 「何に変わったか」が分からない:変更前の状態しか保存していないため履歴テーブルだけを見ても「何に変わったのか」が分からない
- 時点復元が困難:valid_toがないのでどの履歴レコードがいつまで有効だったか分からない
- 変更理由・操作内容が残らない:なぜ変更したのかどんな業務操作だったのかこれらのコンテキストが失われるため監査証跡としては不十分になる
- 連続した変更の追跡が複雑:A→B→Cと3回変更された場合履歴から「2025-01-02時点の状態」を導くには推論する必要がある
■ 4. 方式B:ステータス更新＋変更履歴テーブルの問題点
- ステータス更新と同時に変更履歴テーブルにINSERTする方式である
- 悩みポイント:
- ステータス以外の属性変更が追跡できない:この方式はstatusの変更だけを追跡しておりtotal_amountが変更された場合その履歴は残らない
- 元テーブルと履歴テーブルの整合性が保証されない:2つのテーブルを別々に更新するためアプリケーションコードで「必ず両方更新する」ルールを徹底する必要がある
- 履歴の正しさを検証できない:元テーブルの現在のstatusと履歴テーブルの最新to_statusが一致している保証もなく履歴の連続性も保証されない
- 「作成」と「削除」の表現が曖昧:注文が最初に作成されたときのfrom_statusや注文が削除されたときのto_statusをどうするかが曖昧になる
- 時点復元は改善されるが完全ではない:status以外の属性の時点復元はできない
■ 5. 方式C:テンポラルテーブル方式の問題点
- 有効期間を持たせるテンポラルテーブル方式である
- 悩みポイント:
- 「現在の状態」を取得するクエリが複雑になる:シンプルだったSELECTが毎回時間条件付きになる
- 関連テーブルもテンポラルにすると「ある時点での注文とその明細」を取得するクエリがより複雑になる
- 更新では「終了+INSERT」の2ステップが必要:必ずトランザクションで実行しないと不整合が起きてしまいアプリケーションコードも煩雑になる
- 誤入力の訂正で監査証跡が失われる:過去の行を直接UPDATEすることになり「元々何が記録されていたか」が消えてしまう
- Valid Timeだけでは「いつシステムがその情報を認識していたか」が分からない:これを解決するにはSystem Timeも必要になりBi-temporalへの対応が求められる
- 「同時点で複数有効」を防ぐ制約が難しい:標準的なUNIQUE制約では表現できない
■ 6. Bi-temporalの構造と利点
- Bi-temporalテーブルの各行は通常4つのタイムスタンプを持つ:
- Valid From/To:現実世界でその事実が有効な期間
- System From/To:データベースがその事実を知っていた期間
- この構造により「現在の知識に基づくと先月の価格は10000円であるしかし先週時点の知識では先月の価格は9800円であると認識していた」という複雑な問いに答えることができる
■ 7. Bi-temporalの複雑さと問題点
- 誤入力訂正が入ると「過去のSystem Timeを書き換える」必要がある
- 1つの訂正で複数行の更新・追加が必要になる:「金額10000円→9800円」という1つの訂正で既存の2行を終了し新しく2行をINSERTし合計4行の操作が必要になる
- 「何が訂正されたか」の追跡が困難:system_toで終了した行と新しくINSERTした行の関連付けは暗黙的であり訂正理由も記録されない
- クエリもさらに複雑になる:「2025-01-03時点で業務上もシステム上も有効だった注文一覧」を取得するだけで複雑なクエリになる
- Bi-temporalにテーブルを紐づけるとさらに複雑になる:紐づく先のテーブルもBi-temporalにしないと整合性が取れなくなる
■ 8. 状態中心の設計が難しくしている理由
- ここまで見てきた方式やBi-temporalなどすべてに共通するのは「状態」を保存しようとしていることである
- 状態とは「ある時点での結果」である
- 状態を保存するということは結果だけを切り取って保存することになる
- そのため以下の情報が失われる:
- なぜその状態になったのか
- どうやってその状態になったのか
- 誰がその変化を引き起こしたのか
- 履歴を残そうとすると失われた情報を補うために追加のカラムやテーブルが必要になり結果として設計が複雑化していく
■ 9. 変化を中心に考えるイベント中心の発想
- 「状態中心」の発想を変える:
- イベント中心の発想では「何が起きたか?」を記録する
- 状態を知りたい場合はイベントを順番に適用して現在の状態を導出する
- イベントは「起きた事実」そのものである
- 状態とイベントの比較:
- 状態は結果でありイベントは原因である
- 状態は変わりうるがイベントは変わらない
- 状態は「今どうなっているか」でありイベントは「何が起きたか」である
- 状態はスナップショットでありイベントは事実の記録である
■ 10. 状態中心とイベント中心の具体的比較
- 状態中心の場合:
- 「各時点での状態のスナップショット」を保存する
- どの行がどう関連しているか何が起きたのかこのデータだけでは分かりにくい
- イベント中心の場合:
- 「何が起きたか」をそのまま保存する
- 何が起きたかなぜ起きたか誰が起こしたかすべて明示的に残すことができる
- occurred_atは業務上発生した時刻でsystem_fromはシステムが記録した時刻である
■ 11. 現在有効なデータの取得方法
- 状態中心の場合はWHERE句で時間条件を指定するクエリを実行する
- イベント中心の場合は2つの方法がある:
- 方法1:イベントをリプレイして導出する:イベントが少なければ十分だがイベントが膨大になるとリプレイのコストが高くなる
- 方法2:Read Modelを使う:現在の状態を別テーブルに保持しておきイベント発生時に更新する
- Read Modelはイベントから導出された状態のキャッシュでありいつでもイベントから再構築できるため要件に応じて自由に設計できるのが特徴である
■ 12. Event Sourcingの課題1:最新状態の取得
- イベントをリプレイして状態を導出する方式はイベント数が少なければ問題ないが数万〜数十万件になると現実的ではなくなる
- 解決策としてSnapshotとRead Modelを導入することが考えられる:
- Snapshot:定期的に「ある時点での状態」を保存しておきそこからリプレイを開始する
- Read Model:現在の状態を別テーブルに保持しイベント発生時に更新する
- ただしSnapshotやRead Modelを導入するとシステムの複雑性は増していく
■ 13. Event Sourcingの課題2:有効期間の表現
- Event Sourcingは「何が起きたか」を記録するが「いつからいつまで有効だったか」という期間情報は直接表現しない
- 単純に「最新の状態」を持つRead Modelだけでは不十分で期間情報を持った別のRead Modelが必要になる
- Bi-temporalが必要だった理由は「訂正時に過去の認識を残すため」だったがEvent Sourcingではイベントは不変で追記のみであり訂正もイベントとして記録される
- つまりイベントストアがシステム時間の役割を担っているのでRead Modelは業務上の有効期間だけを持てば十分である
■ 14. Event Sourcingの課題3:イベントスキーマのVersioning
- イベントは不変なので一度保存したイベントのスキーマを変更することはできない
- しかしビジネス要件はフェーズが進むにつれて変化していく
- 過去のイベントを読み込むとき新しいコードで正しく処理するにはv1からv3に変換するロジックであるUpcasterパターンを用意する必要がある
- Upcasterパターンとは主にEvent Sourcingで使われる設計パターンで過去に保存された古い形式のイベントを現在の最新のイベント形式に変換するための仕組みである
- 上記以外に「過去のイベントを物理的に新しいスキーマに書き換える」アプローチもあるがEvent Sourcingの原則を破ることになり監査証跡としての価値が下がる可能性がある
■ 15. Event Sourcingの課題4:取り消しと訂正
- イベントは不変だが「このイベントは間違いだった」というケースは現実に発生する
- この問題に対応するためにCompensating Event補償イベントというものを導入する必要がある
- 「取り消し」や「訂正」も新しいイベントとして記録する
- ただし「どこまで遡って訂正するか」「関連するイベントへの影響をどう扱うか」は慎重に設計しないと破綻してしまう
■ 16. Event Sourcingの課題5:結果整合性とその他
- イベント発行からRead Modelの更新は同期的に行われるわけではないためタイムラグがある
- そのためユーザーが「保存したのに反映されていない」と感じるStale Read問題が発生する
- UI側で楽観的更新を行ったり同期的な読み取りが必要なケースではイベントストアから直接リプレイすることで対応する
- 他にも「イベント設計」「Read Modelの設計と更新ロジック」「Snapshot戦略」「エラーハンドリング」など考えないといけないことはたくさんある
■ 17. Event Sourcingを採用すべきかの判断
- Event Sourcingは「履歴」という要件にはとても強力だがトレードオフは必ず発生する
- メリット:
- 完全な履歴が自動的に残る
- 任意の時点の状態を復元できる
- 「何が起きたか」が明示的
- 監査証跡として価値がある
- デメリット:
- 最新状態の取得に工夫が必要
- Read Modelの設計は難しい
- イベントスキーマのVersioningへの対応が必要
- 結果整合性への対応が必要
- Bi-temporalのようなテンポラルデータモデルで運用し続けるのも難しい
- 少なくとも「履歴」という要件が厳しいときにはEvent Sourcingを1つの選択肢として検討してみると良いかもしれない
- Event Sourcingを導入するときに一番大切なのは「やり切ると決めたら最後までやり切る」という気持ちである
■ 1. 楽観的同時実行制御の普及と盲信への警鐘
- ADO.NETを使うと楽観的同時実行制御を容易に実装できる
- 超有名な「楽観的ロックでいいじゃん!」のお陰で楽観的同時実行制御は特にWebアプリケーション開発では広く使われている
- 大概のアプリケーションでは楽観的同時実行制御で十分なのかもしれない
- しかし「楽観的同時実行制御こそが正義だ」と盲信されかねない空気に警鐘を鳴らす必要がある
■ 2. 悲観的ロックと楽観的ロックの定義
- 大西彰さんの記事「楽観的ロックでいいじゃん!」による定義:
- 悲観的ロック:ステートフルなロックで更新したい対象のリソースを照会して取得した直後から更新が終わるまでロックを維持することでロック時間は長時間でロックは独占的
- 楽観的ロック:ほぼステートレスなロックで更新したい対象のリソースを照会してもロックはかけず本当に更新が必要になった段階でその対象リソースをロックすることでロック時間は短時間でロックは非独占的
■ 3. 同時実行制御の概念による整理
- 悲観的同時実行制御:
- 衝突が頻繁に発生する事が前提の同時実行制御
- 楽観的同時実行制御:
- 衝突が殆ど起こらない事が前提の同時実行制御
- 楽観的同時実行制御は「競合・衝突が全くあるいは殆ど起こらないために衝突に関しては楽観的に考えてよい」ものである
- 悲観的同時実行制御は「競合・衝突が殆どにおいて発生しトランザクション量も多いため衝突に関しては悲観的に考えなければならない」ものである
■ 4. よくある勘違いとその弊害
- 肝要でありよく勘違いされるのが「DBMSのロックメカニズムを使うことが悲観的同時実行制御である」という事である
- そのせいか長時間ロックを回避する為にWebアプリケーション開発では楽観的同時実行制御を大前提に設計をしてしまう事が多々ある
- しかしトランザクション量が多く競合・衝突が頻発するにも関わらず楽観的同時実行制御を行ってしまうと極端に使い勝手の悪いアプリケーションになってしまう
- 予約システムのように仮予約されたチケットがいざ購入の段になって「他の人に獲られました」ではクレームの嵐である
- 仮予約チケットは他の人が見れないようにロックする必要がある
- かといって長時間トランザクションにDBMSのロックメカニズムを使う訳にはいかない
■ 5. 業務排他制御という解決策
- 独力で同時実行制御を作り込む事が考えられる
- 「.NETエンタープライズWebアプリケーション開発技術大全Vol.5トランザクション設計編」では「業務排他制御」と表現されている
- 「悲観的ロックを使わないで悲観的同時実行制御を行う」とでも表現できる
- テーブルに排他制御専用の列を2つ3つ追加し編集ステータスや編集開始日時などをチェックすれば良いだけで実装自体は比較的容易である
- ただし実装は容易でも業務フローの難易度は高くなる
■ 6. Webアプリケーションと楽観的同時実行制御の適性
- クライアントユーザー数が多いであろうWebアプリケーションの方が楽観的同時実行制御には向いていないとさえ言える
- ただしユーザー数が多くても大半のユーザーが参照アクションしか行わないのであればその限りではない
- 楽観的同時実行制御が向いているのはマスタデータメンテナンス等を行うクライアントユーザー数の限られたWindowsアプリケーション等ではないか
- もちろんWebアプリケーションでもあり得る
- 「Webアプリケーションでは悲観ロックはあり得ない楽観同時実行制御こそが正」と決めつける前によくよく仕様を揉んでみるべきである
- その要件は楽観的に考えられるかを検討する必要がある
■ 1. 排他制御の2つの方法と歴史的背景
- データベースのトランザクション処理を実行する場合対象となる行の排他制御が必要である
- 排他制御は同時実行処理において必要不可欠だが使い方を誤ると簡単なはずの処理が難しくなる可能性がある
- リソースをロックする方法は2種類ある:
- 悲観的ロック
- 楽観的ロック
- スタンドアロンでプログラムが動いていた時代は1ユーザ・1プログラム・1データのみが存在するため排他制御を考えなくてもアプリケーションの開発は行えた
- コンピュータがネットワークでつながるようになってデータが複数のユーザからアクセスされるようになると排他制御を無視してプログラムを書くことはできなくなった
- DBMSが利用できるようになってファイルレベルでの同時実行制御からデータベースレベル・テーブルレベル・ページレベル・行レベルといったロックのメカニズムが提供された
- 現在はHTTPという不安定なプロトコルの上でのトランザクションが求められている
■ 2. 悲観的ロックと楽観的ロックの定義
- 悲観的ロック:
- ステートフルなロック
- 更新したい対象のリソースを照会して取得した直後から更新が終わるまでロックを維持する
- ロック時間は長時間でロックは独占的
- 楽観的ロック:
- ほぼステートレスなロック
- 更新したい対象のリソースを照会してもロックはかけず本当に更新が必要になった段階でその対象リソースをロックする
- ロック時間は短時間でロックは非独占的
■ 3. 悲観的ロックのメリットとデメリット
- 悲観的ロックは「俺様が更新するリソースは全部俺様のものだ他人にはアクセスさせないぞ」というものである
- DBMS上でロックを実行したユーザアカウントのコンテキストでロックが解放されるまで排他制御が実行され続ける
- メリット:
- ロックを取得したユーザが見ているリソースが他者から変更されないことを保障する
- デメリット:
- ロックが維持されている間他のユーザはそのリソースにアクセスできない
- ロックを維持することによりデッドロックを引き起こしやすくなる可能性が高い
- この記事で提示したいのは「そのロック本当に悲観的じゃなきゃいけないの?」という疑問である
■ 4. 楽観的ロックで十分な理由1:認証と認可
- ユーザの認証と認可をきちんと処理していれば更新の競合はほとんどありえない
- データベースを設計する際に考えなければならないのは「ユーザの認証」と「ユーザの権限」である
- 悪い例は何でもできる特権を持ったユーザアカウントですべてのデータベースオブジェクトを作りアプリケーションからのアクセスもそのアカウントで実行してしまうこと
- 権限レベルの段階:
- Level0:アクセス許可なし
- Level1:読み取り専用
- Level2:読み取り・書き込み可能
- Level3:特定データベースの変更・構成可能
- Level4:全権限の所有
- 理想的にはデータベース設計者がデータベースを完成させたら権限をDBAに委譲してデータベース設計者からすべての権限を奪うのが望ましい
- Level0からLevel2までの範囲で権限を設定していれば無駄なトランザクションの発生を抑えられる
■ 5. 楽観的ロックで十分な理由2:業務プロセスとワークフロー
- 業務上同一行を複数人で同時に更新するプロセスはほとんど考えられない
- 業務システムにおいて情報が更新されるためには何らかのビジネスプロセスと対応している必要がある
- 例えば人事情報の変更を考えた場合人事部に変更届を提出するのが普通である
- 何らかの届けが提出されそれが認知されて処理されるにあたっては「審査」というワークフローを通る必要がある
- 審査が通るまではトランザクション処理は実行されることがない
- このような「変更」－「審査」といった業務フローの場合同じ行が複数の人から同時に更新されることは起こりえない
- 業務における「変更」には必ず権限を持つ人の「承認・審査」が伴うはずである
- この制約がある限り「変更」は即座には実行されず「変更要求」－「承認・審査」－「変更実行あるいは変更の却下」の流れになる
■ 6. 楽観的ロックで十分な理由3:対照表による履歴管理
- 動的に変化するデータを対照表の形で作成してしまえば追加のみなのでロックは必要ない
- 例えば小売店における商品の売価を考える
- 商品というエンティティに売価を入力して更新するやり方は後に営業分析する際に売価の動きを追跡することが難しくなる
- 売価を対照表で管理すると商品ID・店舗ID・発生日時・イベント・売価などで管理できる
- このモデルに従うと商品の売価においては変更が生じてもデータベース側では「行の追加」しか発生しない
- 変更イベントが発生しても商品の売価という対照表の行を更新するということは起こりえない
- したがって楽観的ロックすら必要がない
■ 7. 楽観的ロックで十分な理由4:データの所有権管理
- データの所有権を管理すれば更新の競合はほとんどありえない
- アプリケーションによって行に所有権を設定し所有権のある行だけを処理の対象とすることを考える
- 所有者IDをUPDATEステートメントのWHERE句に含めることで他の所有者の行を更新することがなくなる
- 行の所有者を明確にしているので悲観的ロックにすることなく楽観的ロックで十分になる
- しかし所有者の変更を追跡しようとすると多対多のモデルになるので結局は対照表の構造に帰着する
- したがって理由3の繰り返しになり行を更新するという話がなくなる
■ 8. アーキテクチャの変遷とトランザクション軽量化の重要性
- 時代はメインフレームによる集中処理からクライアントサーバの分散型・Webシステムにおける集中処理型・スマートクライアントによる分散型と集中・分散を繰り返している
- どのようなアーキテクチャが採用されるにせよコンピュータのメモリは有限でありデータをどこかの2次記憶装置に永続化する必要がある
- 工夫次第でトランザクションを軽量なものにすることができる
- 最終的に一番負荷がかかるのはデータベースが稼動しているサーバである
- スケーラビリティやパフォーマンスを求めるのであればいかにサーバリソースを消費しないで同時実行性を高めるかということにつきる
■ 9. 実体験に基づく楽観的ロックの優位性
- 12-13年前にCA-ClipperというXbaseのシステムで悲観的ロックモデルによりアプリケーションを作成した際にこのロックモデルの欠点がよくわかった
- ネットワークのトラフィックの増大・アプリケーションパフォーマンスの低下を招くことが低性能のPCで証明された
- 結局楽観的ロックに切り替えられるようクライアントでトランザクション用のキューを作りサーバ側にバッチアップデート要求を出すような作りにした
- MS-DOSのファイルシステムレベルでの排他制御も経験したがロック時間が長くなればパフォーマンスが低下することがわかった
- ロック時間は短いほうがいい
- SQLを利用するDBMSにおいても結局理屈は変わらない
- ユーザのロールモデル・業務上のワークフロー・データベースの設計方法を工夫するだけでも「悲観的ロック」から逃れることができる
- SOAのアプローチになってサービスとの疎結合が求められると「楽観的ロック」中心のアプローチでないとサービスの開発ができない
- 永続化処理を軽量にすることが今後も求められる
■ 1. 背景と用語定義
- 一休.comの宿泊予約のシステムで予約部分のリニューアルを進めている
- リニューアルの中で取り組んだ予約処理の結果整合を実現するための実装について説明する
- 用語の定義:
- トランザクション:予約処理全体を指す
- ローカルトランザクション:カード決済や在庫引当と言った個々の処理を指す
- ロールバック:DBトランザクションのロールバックに限らずローカルトランザクションを補償トランザクションにより論理的にロールバックすることも指す
- 補償トランザクション:ロールバックを実現するための手段として利用する
■ 2. 要件
- 宿泊予約トランザクションの中で発行される主なローカルトランザクション:
- 在庫引当
- カード決済
- 一休ポイント登録
- サイトコントローラーへの通知
- ユーザーへのメール通知
- これに加えて予約データの永続化がある
- 少なくともこのようなローカルトランザクションを予約全体として結果整合させる必要がある
■ 3. Sagaパターンの概要
- 複数のローカルトランザクションを結果整合させるためのパターンとして有名なものにSagaパターンがある
- Sagaパターンは補償トランザクションを利用してローカルトランザクションをロールバックすることそしてそのローカルトランザクションの実行やロールバックを全体で結果整合させるための設計パターンである
- Sagaパターンにはいくつか種類がある:
- コレオグラフィパターン:ローカルトランザクション同士が相互に協調しあって全体をコントロールする
- オーケストレーションパターン:中央集権的なオーケストレータが全体のローカルトランザクションの実行やロールバックをコントロールする
- 更に詳しく各ローカルトランザクションの通信の同期や非同期整合性が結果整合かアトミックかを加えた分類もある
- 一方でその具体的な実装に踏み込んだ説明は多くない
- この記事では具体的なパターンを網羅的に説明したりパターンの中で何に該当するのかと言った体系的な説明というよりは実際自分たちがどのような実装をしているのかというところを説明する
■ 4. リニューアルの実際
- 予約リニューアルに伴いドメインモデルを捉えなおし合わせて技術的な詳細についても見直せる部分は見直してきた
- 今回紹介する実装パターンについても既存のシステムで大きな問題なくここまで運用されてきたものであるため抜本的に設計しなおしたというものではない
- 既存のシステムをあらためて解釈し整理できる部分は整理していき改善できる部分は改善したところこのような形に落ち着いたというのが実際のところである
■ 5. ピボットトランザクションの決定とローカルトランザクションの分類
- トランザクションの成否を決定するローカルトランザクションのことをピボットトランザクションと呼ぶ
- ピボットトランザクションが失敗した場合そのトランザクション全体も失敗として扱われる
- その場合ピボットトランザクション以前に実行したローカルトランザクションも失敗として扱う必要がある
- これを決定し各ローカルトランザクションはピボットトランザクションよりも前に実行されるのか後に実行されるのかを明確にすることで全体の設計が見通しやすくなる
- ピボットトランザクションは予約データの永続化と捉えた
- ローカルトランザクションの性格:
- カード決済や在庫引当はそれが失敗したら予約も失敗として欲しい
- ユーザーへの予約通知メール送信やサイトコントローラーへの予約通知についてはそもそも予約が失敗していたら実行して欲しくない
- ピボットトランザクションよりも前に実行するローカルトランザクションは予約の成否に応じて補償トランザクションでロールバックする
- ピボットトランザクションよりも後に実行するローカルトランザクションはピボットトランザクションが成功している以上は最終的に成功として扱いたいものになる
- 後者の最終的に成功として扱いたいを実現するパターンとしてはTransactional Outboxパターンなどがある
- このoutboxはいわゆるメールの送信トレイを意味していて送信時にはoutboxのみを作っておいてoutboxをもとにしてリトライするなどで最終的に送信されることを目指すというものである
- サイトコントローラーへの送信などはこのTransactional Outboxパターンを利用している
- 具体的にはピボットトランザクションとなる予約データの永続化のトランザクションの中でサイトコントローラー用のoutboxのデータを作成している
- どうしようもないものは人手での運用にまわしているものもある
■ 6. 補償トランザクションの実装パターンと補償ログの導入
- トランザクションが失敗として定義された場合実行されたローカルトランザクションに対し補償トランザクションを実行していくことになる
- この際ローカルトランザクションが実行済みであるということを把握する必要が出てくる
- そのために実際のローカルトランザクションを実行する前に補償ログというデータを登録する
- 補償ログというのは一般用語ではなく造語である
- 概念としてはデータベースのUNDOログに近い
- ローカルトランザクションが成功した後にピボットトランザクションが失敗したケースを考える
- この場合補償ログがあればそれに対応する補償トランザクションを実行するということになる
- 補償ログ・補償トランザクションを実装する際に重要なポイント:
- ポイント1:補償ログはローカルトランザクションの実行前に登録する:
- 補償ログはローカルトランザクションの実行前に登録する必要がある
- 仮にローカルトランザクションの実行の後に補償ログを登録するという実装にしていた場合ローカルトランザクションの実行には成功したが補償ログの登録には失敗したというシチュエーションを考える必要が出てきてしまう
- これは基本的にローカルトランザクションのロールバックが不可能になってしまう
- したがってローカルトランザクションの実行前である必要がある
- UNDOログを例に出したが実行前に登録する必要があるというのもデータベースのWrite-Ahead Loggingに似た考え方である
- 補償ログの登録に失敗した場合そのローカルトランザクションは実行せず失敗として扱う必要がある
- ポイント2:ローカルトランザクション実行前に補償トランザクション実行に必要な情報がそろっている必要がある:
- 補償ログには補償トランザクション実行に必要なIDなどの情報を登録しておく
- したがってローカルトランザクション実行前に補償ログを登録するということはローカルトランザクション実行前に補償トランザクション実行に必要な情報がそろっている必要があるということになる
- 例えばローカルトランザクションの実行結果としてあるリソースのIDが手に入りそのIDが補償トランザクションのリクエストパラメータとして要求されるようなAPIではこの要件を満たすことが出来ない
- 補償ログには補償トランザクション実行に必要十分なIDなどの保存にとどめ逆に個人情報等は保存しないようにする
- ポイント3:補償ログはピボットトランザクションの成功後に削除する:
- 補償トランザクションを実行する場合補償ログは補償トランザクションの実行後に削除する必要がある
- 補償ログの登録の話と同じく仮に補償ログを削除してから補償トランザクションを実行するようにした場合補償トランザクション実行に失敗した場合に補償トランザクションを再度実行できなくなってしまう
- さらに補償ログの削除はピボットトランザクションの成功後に削除する必要がある
- ピボットトランザクションがトランザクション全体の成否を決定するためピボットトランザクションが成功するまではローカルトランザクションをロールバックする必要がある可能性があるため
- したがってピボットトランザクションが成功するまでは補償ログを削除することは出来ない
- ポイント4:補償トランザクションは冪等にする:
- 補償トランザクションは冪等である必要がある
- これは補償トランザクション実行に失敗した場合や補償トランザクションに成功した後補償ログの削除に失敗した場合などで再度補償トランザクションが実行されうる状態になるためである
■ 7. ピボットトランザクションとピボットマーカーの導入
- ローカルトランザクションの補償ログとそれを利用した補償トランザクションの実行のための実装パターンを説明した
- ピボットトランザクションとローカルトランザクションを関係づけることでトランザクション全体の結果整合性を実現することが出来るようになる
- ピボットトランザクションに対してもローカルトランザクションと同様それが進行中であることを示す必要がある
- ピボットトランザクションに対する補償トランザクションは存在しないため補償ログではなくピボットマーカーと呼ぶことにする
- このピボットマーカーも一般用語ではなく今回導入した造語である
- このピボットマーカーをローカルトランザクションの開始前にまず作成しそしてピボットトランザクションとアトミックに削除することで全体としての結果整合性が実現できることになる
- 重要な点:
- ポイント1:ピボットマーカーはピボットトランザクションとアトミックに削除する:
- トランザクション全体で結果整合性を担保する上でこれが最も重要である
- ピボットマーカーはピボットトランザクションとアトミックに削除する必要がある
- これによりピボットマーカーが存在している=ピボットトランザクションが完了していないピボットマーカーが存在しない=ピボットトランザクションが成功したと解釈出来るようになる
- ピボットマーカーを予約データ永続化先と同じDBに保存し予約データ永続化と同じDBトランザクションでピボットマーカーを削除することでこの要件を満たしている
- ポイント2:補償ログとピボットマーカーに親子関係を設ける:
- 補償ログとピボットマーカーに親子関係を設けることでローカルトランザクションの補償トランザクションの実行要否とピボットトランザクション成否を結びつけることが出来る
- これによりトランザクション全体の結果整合性を担保することが出来る
- ピボットマーカーが存在していれば実行済みのローカルトランザクションが存在する可能性がありロールバックする場合はローカルトランザクションに対して補償トランザクションを実行する必要がある
- ピボットマーカーが存在しなければトランザクション全体を成功とみなすためローカルトランザクションに対して補償トランザクションを実行する必要はないと解釈することが出来る
- ポイント3:補償トランザクションを実行する際は常にピボットマーカーを起点に実行する:
- 常にピボットマーカーから補償ログを辿って補償トランザクションを実行するようにする
- こうすることでピボットマーカーが存在している場合にのみ補償トランザクションが実行されるようになる
- つまりピボットトランザクションが成功した場合は絶対に補償トランザクションが実行されることはないとすることが出来る
■ 8. トランザクション全体のロールバックの例
- ここまでの実装でトランザクション全体としてロールバックを冪等に実行することが出来るようになる
- ローカルトランザクションの一部が失敗した場合を考える
- ロールバックの流れ:
- ピボットマーカーが作成され
- その後のローカルトランザクション1と2と3と実行されるがローカルトランザクション3が失敗し
- ローカルトランザクション1と2に対して補償トランザクションを実行してロールバック
- 補償ログ削除
- 最後にピボットマーカーを削除
- このようにしてトランザクション全体をロールバックすることが出来た
- このプロセスは冪等に実行することが可能である
- ロールバック処理では複数ある補償トランザクションのうちのひとつの実行に失敗したりすることがあり得る
- そのほかサーバーのプロセスごと落ちたなどでロールバック全体が完了しなかった場合にも実行する必要のある補償トランザクションを確実に実行する必要がある
- そのため一連のロールバック処理を予約の失敗時にサーバーから同期的に実行することに加えて定期的に残っているピボットマーカーを見てサーバーから実行したものと同じロールバック処理を再実行するジョブをCloud Run Jobsで用意している
- ロールバック処理を冪等に実行出来るようにすることでこのように確実にロールバックが完了するように実装することが出来る
■ 9. 制約
- ここまで説明してきた実装パターンが適用出来る前提:
- ローカルトランザクションが同期的に実行できること:
- ここでいう同期的とはローカルトランザクションの成否がピボットトランザクション実行までに確定していることを指す
- ローカルトランザクション同士が強く結合していないこと:
- 順序制約はあってもよいが補償トランザクションに必要な情報が前段の実行結果に依存しないこと
- 実行前に補償ログへ必要情報を確定できること
- トランザクション全体としての一貫性は結果整合で良いこと:
- 予約失敗の場合には一時的にでも在庫が引当されてはいけないと言った制約がある場合はこの実装パターンには向かない
- これよりも厳しい要件が必要な場合この実装パターンそのままは適用できない
■ 10. この実装パターンの特徴と利点
- 紹介した実装パターンの特徴や利点:
- Sagaパターンなどを意識せずドメインロジックの実装が可能:
- アプリケーションロジックを実装する際はこのようなことを気にせずに進められるならそれに越したことはない
- ここまで説明してきた実装パターンは主にI/Oを実行するレイヤでのみ気にすれば良いものになっている
- したがってドメインロジックとI/Oを適切に分離できていればここまでの補償トランザクション周りの実装についてもドメインロジックを実装する際に意識する必要はなくなる
- ローカルトランザクションの追加が容易:
- ローカルトランザクション毎に補償ログ・補償トランザクションの実装を用意すればローカルトランザクションを追加することは比較的容易である
- 実際に予約リニューアルプロジェクトを進める中で段階的にローカルトランザクションを大きな労力なく追加していくことが出来た
- ローカルトランザクションの変更が容易:
- ローカルトランザクションそれぞれの独立性が高いためローカルトランザクションの実行タイミングや順序などが変更しやすくなる
- 例えば在庫引当はもっと早いタイミングに実行してしまいたいと言った変更である
■ 1. SQLiteの再評価とDB Proでの活用
- DB ProではSQLiteを愛用している
- SQLiteには制限があるが弱点ではなく適切にデプロイされ慎重にチューニングされればプロダクションで使用できる
- SQLiteは過去数年で復活を遂げている
- libSQLやTursoへのフォークやPocketBaseのような人気バックエンドフレームワークでの採用などが見られる
- DB Pro自体のローカルデータベースもSQLiteで動作している
- DB Proのユースケースにはこれ以上の代替手段は存在しない
- 過去3ヶ月間SQLiteを本格的に使用してきた結果多くのことを学んだ
- SQLiteのより興味深い機能とニュアンスを扱う短いブログ投稿シリーズを計画している
■ 2. SQLiteのJSON機能の発見
- SQLiteにはJSON関数と演算子があることを最近まで知らなかった
- Hacker Newsのコメントでbambaxという人物がSQLiteのJSON演算子について述べた内容を発見した
- bambaxのコメントの要点:
- 各JSONドキュメントをそのまま1つのカラムに保存する
- json_extractの組み合わせを使用してクエリしたい特定の情報を保存する仮想カラムを作成する
- これらのカラムにインデックスを作成する
- これにより超高速検索が可能になる
- 挿入時にインデックス対象を選択する必要がなく必要なときにいつでも仮想カラムを追加できる
- インデックスされていない生のJSONも検索できるが大規模コレクションでは時間がかかる可能性がある
■ 3. bambaxの提案する4つのステップ
- bambaxの提案を実際に試してみることにした
- DB Proのブログには埋め込みSQLite-in-the-browserコンポーネントがあるため動作例を作成した
- bambaxが述べている内容の分解:
- JSONドキュメントを生のまま保存する
- json_extractを使用して仮想生成カラムを作成する
- これらの生成カラムにインデックスを追加する
- 完全なB-treeインデックス速度でJSONをクエリする
- これによりインデックス戦略を事前に選択する必要がなくなる
- 後で新しいJSONフィールドでクエリする必要があることに気づいた場合は生成カラムを追加してインデックスを追加するだけで完了する
- データ移行もスキーマの書き換えもETLも不要で純粋な柔軟性が得られる
■ 4. 実装手順1:生JSONの保存
- まずJSONカラムを持つシンプルなテーブルを作成する
- JSONドキュメントは到着したそのままに自然に保存される
- スキーマの複雑な操作も不要である
■ 5. 実装手順2:仮想生成カラムの追加
- bambaxが魔法が起こると言っている箇所である
- 仮想生成カラムを追加する
- 生成カラムはオンデマンドで値を計算する
- これらは実際にはデータを保存しない
- 書き込みは発生しないと考えられる
- バックフィルも不要で即座に実行される
- 仮想カラムはクエリするたびにJSONデータからオンザフライで計算される
■ 6. 実装手順3:パフォーマンスのためのインデックス追加
- これがケーキのアイシングである
- インデックスを追加してこれらの仮想カラムを超高速にする
- 突然JSONが完全なインデックスサポートを持つ通常のリレーショナルカラムのように動作する
■ 7. 実装手順4:フルスピードでのクエリ
- クエリが非常に高速になる
- いくつかの例でそれを試すことができる
■ 8. 後からの新しいクエリパターンへの対応
- このパターンの最も強力な点の1つであると考えられる
- 後日JSONの形状が変わった場合でも別のカラムを追加して別のインデックスを作成するだけでよい
- 例えばuser_idでクエリする必要があることに気づいた場合:
- ALTER TABLEで新しい仮想カラムを追加する
- CREATE INDEXでインデックスを作成する
- 既存の行に触れることなく最適化される
■ 9. このパターンが強力な理由
- このパターンはSQLiteでJSONを扱う方法についての考え方を完全に変えた
- スキーマレスデータの柔軟性とリレーショナルデータベースのパフォーマンスとエルゴノミクスを組み合わせることができる
- 早期にコミットしすぎたり自分自身を追い込んだりすることなくこれを実現できる
- これらの小さなSQLiteスーパーパワーは他にもたくさん隠れている
- これは共有したい最初のものにすぎない
Architecture Decision Records(ADRs)は、アーキテクチャ上の意思決定をドキュメントとして残す方法の1つです。Release It!の著者であるMichael Nygardのブログによって広まり、ThoughtWorks社の[Technology Rader https://www.thoughtworks.com/radar/techniques/lightweight-architecture-decision-records]でも「adopt」になっています。
■ 1. マネジメントスキルの学びにくさ
- 多くの専門職ではロールモデル・スキルアップのロードマップ・キャリアが会社の仕組みとして整えられ社内の話題にもよく登る
- マネジメントを主たる業務にしている人にとってこの土台は薄く感じる
- 技術的な専門職の仕事は客観的な良し悪しで判断される
- 質の良い仕事とまずい仕事は自分も周囲も同じように認識できる
- 技術的な仕事は結果からの明確なフィードバックを得られやすい
- プログラミングなら間違っていればエラーが返ってくることによって間違いがはっきりする
- 人によって意見が分かれる高度な技術テーマであってもこれは人によって認識が異なるテーマであることは同意されやすい
- マネジメントは良し悪しで判断しにくい理由:
- マネージャー同士が働く機会が限られている
- マネージャーは少数者
- 未経験者からの評価という非対称性
- 好き嫌いや人間関係の相性
- マネジメントとリーダーシップの混同
- 多くの専門職は同じ専門職と働く機会があるがマネージャーはマネージャーと一緒に働く機会は多くない
- 同じ職能から学びにくいという働き方の性質がある
- 職能組織はあっても職位組織はなかなかない
- マネジメントそのものが理解される機会が限られマネジメントとして素晴らしい仕事/悪い仕事は何かという判断の質は育ちにくい
- マネージャーは組織構造上少数者で少数者というだけでも悩みは深くなる
- 現場のメンバーから評価される際はマネジメント未経験者から評価されるという非対称性がある
- 好き嫌いや人間関係の相性もマネジメントへの理解を難しくする
- 本来異なるスキルであるマネジメントとリーダーシップがマネージャーという一つの役職にまとめられていることもよくある
- ある人にとっては良いマネージャーと評価されても別の人にとっては悪いマネージャーと評価される
- マネージャー本人にとってもどのようにすればよりよいマネージャーになれるのか分からなくなる
■ 2. 1950年代の職場環境
- 戦後復興のさなか中学校や高校卒業したばかりの若い人達は金の卵と呼ばれ企業はこぞって採用
- 人口動態において若者が多く若手が果敢にチャレンジする機会があった
- がんばれば昇格できる時代
■ 3. 1980年代の状況
- 戦後復興を乗り越えて高度成長期の栄華を極めた1980年代では1950年代の人材がベテランとなり企業組織の中核を担う
- 企業の成熟と共に組織の人数に対してキャリアアップの受け入れ先となる課長や部長といった職位が足りなくなる
- ポスト詰まりが常態化
- 組織階層を増やしてもポストが足りなくなり当時の若い人達にとってキャリアを積み上げる難易度が高くなる
■ 4. 1990年代の変化
- 企業規模の拡大の停滞が始まりポスト詰まりは更に悪化
- 第二次ベビーブーム世代が就職するタイミングでバブル崩壊が重なる
- 就職を希望する若い人が多いにもかかわらず企業は人を受け入れることができない状況
- 多くの若い人が正規雇用に付くことが難しくなる
- 正規雇用を得たとしてもライバルが多く昇進を手にする人は一握り
- 企業間競争よりも組織内の出世競争が激しくなる
- 人事施策は育成から選抜へと変化:
- わざわざ育成するコストを掛けるのではなく過酷な状況でも勝手に自分で育つ人を引き上げる
- リーダー・マネージャーは損をするなのにやりきる責任感のある人を登用
- 台風でも出社するような人が忠誠心として認められ評価される
- 生存者バイアスが人事育成の方針になる
- 企業にとって労力のかかるキャリアの用意や育成を当事者に押しつけることによって低コストで実施
- 成果主義を導入した大企業の中には自分の評価を上げるために部下の育成よりもプレーヤーに徹したマネージャーも増加
- 若手の育成は自分のライバルを増やすことにもなりかねない
- 停滞は数年で終わること無く長く続くことによって人材育成の組織的な機構が空洞化
- 人材育成を負担に感じていた中堅企業や新興IT企業では顕著
- 当時20代で今の40〜50代にマネジメント育成を会社からしてもらった経験を聞けばその手薄さに驚く
■ 5. 2000年代のフラット化の悪影響
- バブル崩壊の影響は少なくなるが就職氷河期は続く
- 職位のヒエラルキーへの嫌悪が強くなり組織ヒエラルキーのフラット化が進む
- フラット化によって段階的な中間管理職(係長/課長代理/課長/部長代理/部長)やそこでの段階的な経験機会が失われる
- 戦略レベルの意志決定者と現場リーダーの二極化が進む
- 職位が減るものの評価グレードは残り続ける
- 組織はフラットだが昇格ポストはさらに狭くなり若者から見たポスト詰まりは悪化
- フラット化は多くの場合でポジティブのように語られる
- 新人にとって職位の3つ4つ先が突然社長という構造の有効性への疑問
- 風通しが良いと形容されるが本当に風通し良く話せているのか
- 職位の境界を担う中間職位に負担が押し込められているケースが多々ある
- 1980年代後半からマネジメントの経験機会の細さが長く続く
- 会社組織としてのマネジメント層育成の動機の欠如と現場にとってのマネジメントへの関心の薄さが常態化
■ 6. 2010年代後半から2020年代の転換
- 2010年代に入り若い人の就職状況において数十年ぶりに安定した売り手市場になる
- 働き方改革によって無理な働き方をさせることはしてはならないこととなる
- 高い職位からの厳しさや率直さの指摘はひとまとめに加害と被害の関係として解釈されやすくなる
- 部下への干渉はリスクと見なされるようになる
- 職場の人間関係の距離が遠くなるかと思えば分業化した個人主義的な働き方からチームとして頻度の高いコミュニケーションを通して仕事をするように変化
- プロダクト開発でも人材においても新しい働き方に合わせたマネジメントへの関心が高くなる
■ 7. 現在のマネージャーをとりまく混乱
- 2025年において依然として40-50代のマネジメントの知識・経験にはバラツキが大きい
- 多くの40-50代にとって自分のロールモデルはいないし教育投資も限られている
- 現在の40-50代のマネジメント層にとって自分のキャリアをふりかえるとまるでサバイバル
- それを若手に繰り返させることは許されない
- 20-30代の次世代のマネージャーにはマネジメントのあり方を示さなければならない
- 解消しなければならない状況:
- 技術と比べて標準的な学習の機会が乏しい
- 教育を受けたこともないのに教育を提供しなければならない
- 人格の評価と専門職としての評価が混同される
- 職能経験の非対称性から専門スキルとして評価されることが難しい
- なのにふるまいとして見本を見せなければならない
- 職能表に基づいてマネジメントスキルを伸ばそうと思っても実際には人格者としてのふるまいを期待されることが多い
- 高い言語化能力や情緒的な求心力まで求められている
- プレイングマネージャーはよくないことだと合意はありつつも実態としては包括的なリーダーシップが求められている
- 職能表に書かれるマネジメントばかりしていてはマネージャーとして失格と見なされる
- マネージャーなのに実態はリーダーと混ざっていたり様々な期待が足かかっている状況
- 自己犠牲は避ける時代になったはずなのに依然としてリーダー・マネージャーは損をする状況が続いているケースを多く見る
■ 8. マネジメントスキルの明確化と学習環境の整備
- ここ数年で状況は変わりつつある
- 学習可能な一般技術としてのマネジメントの萌芽は始まっている
- 環境整備の兆候:
- 現場経験の状況に寄り添ったマネジメントに関する書籍が増加
- 戦略的意志決定者と現場リーダーの間を埋める職位の定義や任命も進行
- 会社を超えて交流できるようなイベントも増加(Regional Scrum Gathering Tokyo・emconf・pmconf)
- マネージャーの横の繋がりというテーマで豊富に語られる活動が増加
- よりマネージャーという職能を学びやすく評価されやすくなる
- 一度プロダクトマネージャーになってから現場の職能に戻る人やエンジニアリングマネージャーを経験した後にエンジニアに戻る人もぽつぽつ増加
- メンバーからマネージャーへは一方通行なキャリアでは無く自分の仕事の幅を広げる通過点として双方向に開いているケースが増加
- 有識者の間で整理が進みつつある具体テーマ:
- マネジメントスキルの明確化(リーダーシップや人格との区別)
- 対象の明確化(プロダクトのためのマネジメント・メンバーのためのマネジメント・プロセスのためのマネジメント)
- 負荷とスキルの平準化(マネージャーとマネジメントの区別・マネージャーだからこそのマネジメント・メンバーも習得する共通スキルとしてのマネジメント)
- 習得方法(産業や業界として知見共有・組織における一般的な教育投資・職位同士のピアコーチングや相互メンタリング)
- 2026年はマネジメントにとってもマネージャーにとっても働きやすくなる年になる
MoZuku は、MeCab・CaboCha を活用した日本語文章の解析・校正を行う LSP サーバーです。
特徴
- 形態素解析: MeCab による高精度な日本語トークン化
- 文法チェック: 二重助詞、助詞連続、動詞-助詞不整合の検出
- セマンティックハイライト: 品詞ごとの色分け表示
- コメント内解析: C/C++/Python/JavaScript/TypeScript/Rust のコメント内日本語を解析
- HTML/LaTeX サポート: ドキュメント本文も解析
- ホバー情報: 単語の原形、読み、品詞情報、Wikipedia のサマリーを表示
■ 1. CSV処理における課題
- 業務アプリケーション開発においてCSVインポート機能は避けて通れない
- 仕様が複雑になるにつれて以下の課題に直面する:
- バリデーションとパース処理が混在しエラーの発生箇所が追いづらい
- Shift_JISなど多様なエンコーディングへの対応でビジネスロジックが複雑になる
- パースやバリデーションエラーを即座にリターンするとユーザーは「モグラ叩き」のような修正サイクルを繰り返すことになる
- データが正しい状態か保証されないまま後続の処理に渡されてしまう
■ 2. Parse don't validateの考え方
- 「Parse don't validate」という考え方を参考にCSV処理のライブラリを実装した
- これは入力を単に検証して終わるのではなく型のあるデータ構造に変換することでその後の安全性を型システムで保証するという考え方である
- 処理を以下の3つのフェーズに分割した:
- Reader:エンコーディングの詳細を隠蔽
- Parser:CSV行→構造体への変換
- Validator:中間型→検証済みの型への昇格
■ 3. Reader層の実装
- 日本の業務システムではExcelから出力したCSVが頻繁に使われShift_JISやBOM付きの場合がある
- ビジネスロジックの段階ではエンコーディングの違いを意識せずに済むようにしたい
- 読み込み時にエンコーディングを自動判定・変換し常にUTF-8のReaderを返すように実装した
- エンコーディング処理の順序:
- BOM付きUTF-8のCSVファイルをサポート
- BOMなしUTF-8をサポート
- Shift_JISをUTF-8へ変換してサポート
- この層が腐敗防止層として機能することで後続の処理はファイルがどのような形式で保存されていたかを知る必要がなくなる
■ 4. Parser層の実装と中間型の定義
- 読み込んだ行をGoの構造体にマッピングする
- ここでは型変換とマッピングのみを行いビジネス的なバリデーションは行わない
- 中間型Parsed[T]の定義:
- ColumnCountStatus:カラム数の過不足状態を表す
- ParsedRecord[T]:1行ごとのパース結果
- Parsed[T]:パース処理全体の結果
- カラム数が合わないといった構造的な問題も即座にエラーにするのではなくステータスとして記録する
- これはエラーの集約を実現するためである
- パース段階で見つかった不備で即座にエラーを返すとユーザーは修正とアップロードを何度も繰り返すことになる
- Parserは起きたことの記録に徹し後続のValidatorで他の入力ミスと合わせてファイル内の全エラーをまとめて報告できるようにしてユーザー体験を損なわない設計としている
■ 5. Validator層の設計思想
- ライブラリには汎用的な検証フローだけを持たせ具体的なビジネスルールは外部から注入する形をとった
- 型定義:
- Valid[T]:バリデーション後の安全なデータ
- ValidateRecordFunc[T]:外部から注入するバリデーション関数の型定義
- Validate関数の処理フロー:
- ヘッダー構造の検証
- レコードごとの検証で注入された関数を実行
- エラーがなければ有効なレコードとしてリストに追加
- エラーがあればValid[T]は返さない
- 全て合格して初めてValid[T]を返す
- Parsed[T]からValid[T]への変換が成功すればデータは整合性が取れていることが保証される
■ 6. 利用例の実装
- このライブラリを使う側のコードは非常に宣言的になる
- 利用手順:
- 取り込みたいCSVの構造を定義する
- パースを実行して読み込みと構造化を行う
- バリデーションルールの定義でドメイン固有のロジックを記述する
- バリデーション実行でルールの注入を行う
- エラーがあれば何行目の何がおかしいかをまとめて返却できる
- 後続処理に来る時点でvalidDataは*Valid[UserCSV]型でありすべてデータがルールに適合していることが保証されている
■ 7. 設計のメリット
- CSV処理は外部からの入力を扱うため複雑になりがちだが責務を分けることでメンテナビリティを向上させることができた
- Reader層の利点:
- エンコーディングの詳細を隠蔽し腐敗防止層として機能
- Parser層の利点:
- CSV行を中間型へ変換しエラーは即時リターンせず状態として記録してUX向上に貢献
- Validator層の利点:
- 中間型を検証済みの型へ昇格し汎用的な検証フローを提供して具体的なルールは外部から注入する
- バリデーションロジックを関数として注入する設計にしたことでライブラリ自体を変更することなく様々なCSVに柔軟に対応できる構成となった
■ 1. 航空宇宙ソフトウェアの歴史的背景
- 1996年6月4日、Ariane 5ロケットが打ち上げ36秒後に爆発した。原因は64ビット浮動小数点数を16ビット整数に変換する際の未処理例外であり、5億ドルが一瞬で失われた。
- F-35の設計者はこの教訓から、JSF C++標準のAVルール208で「例外を使用してはならない」と規定した。
- 1970年代初期、F-4 Phantomには実質的にソフトウェアが存在せず、爆撃コンピュータは歯車とカムの箱であった。
- F-14 Tomcatプロジェクトで、Garrett AI Researchが世界初のマイクロプロセッサを開発した。これはIntel 4004より数年早く、かつ高速であったが、1998年まで機密扱いであった。
- F-14の可変翼設計には手動操縦では対応できず、約2500行のマイクロコードで多項式方程式を処理した。これが航空機における最初の本格的なソフトウェアとなった。
■ 2. 軍用ソフトウェアの言語戦争
- 初期のソフトウェア時代、米陸軍、空軍、海軍はそれぞれ異なるコーディング標準を持っていた。
- 空軍はJovial(Jules's Own Version of the International Algorithmic Language)を使用していた。
- 海軍はF-18でCMS2という独自言語を採用し、互換性は皆無であった。
- 機上ソフトウェアの量は指数関数的に増加した:
- F-16Aで12万5000行
- B-1で100万行
- F-35で900万行
- 当時450以上の異なるプログラミング言語が使用されており、適切な標準が存在しなかった。
- 国防総省は全ての言語を置き換える高級言語としてAdaを開発した。
- Adaの使用は約15年間義務付けられ、使用しない場合は不可能であることを証明する必要があった。
■ 3. C++への移行とJSF標準の誕生
- 1990年代、航空宇宙分野ではAdaが主流であったが、同時期にインターネット、Windows 95が登場し、多くのゲームがC++で動作していた。
- 当時、コンパイラは有料で数千ドルもしたが、C++とGCCは無料であり、学生はC++を学習した。
- Lockheed MartinはF-35プロジェクトでAdaの代わりにC++の使用を国防総省に提案した。
- 提案者は「法律を破ることを承認してください」という内容を提示したことになる。
- Lockheed Martinは純粋なC++ではなく、言語を制限する計画を用意していた。
- C++の作成者Bjarne Stroustrup自身がJSF規則の策定に関与したことを認めている。
- JSF標準は特定の機能を外科的に除去することで、強力な言語を認証可能なコードに変換する。
- JSF標準は完全に公開されており、オンラインで閲覧可能である。
- Joint Strike Fighterという名称は、Lockheed Martinだけでなく、多数の防衛企業、政府、複数の国が協力して開発したことを示している。
■ 4. JSF C++標準の主要な制約事項
- 例外処理の禁止(AVルール208):
- 例外は予測不可能な制御フローを生成する
- Ariane 5の事故は値のオーバーフローではなく、未処理例外が問題であった
- Bjarne Stroustrup自身は現代のC++例外処理を支持しているが、当時のツールの成熟度では応答時間を保証できなかった
- JSF標準では例外の代わりにリターンコードを使用する
- リターンコードは呼び出し元関数に処理を委ねる
- 再帰の禁止(AVルール119):
- 関数は直接的または間接的に自身を呼び出してはならない
- 再帰はスタックオーバーフローの可能性を生む
- 各再帰呼び出しは新しいスタックフレームを作成する
- 再帰の最大深度が不明な場合、メモリ使用量の上限を知ることができない
- 反復的アプローチで置き換える必要がある
- メモリ割り当ての制限(AVルール206):
- 初期化後のメモリ割り当てと解放を禁止する
- 動的メモリ割り当てはコードに予測不可能性をもたらす
- メモリマネージャーが利用可能なメモリを見つけるのにかかる時間が不明である
- 十分なメモリが利用可能かどうかも不明である
- ヒープ上の割り当てはフラグメンテーションを引き起こす
- 解決策として最大データサイズをハードコードし、事前割り当てを行う
- 循環的複雑度の制限(AVルール3):
- 関数の循環的複雑度は20を超えてはならない
- 循環的複雑度は関数内の決定パスの数を示す
- if文、whileループ、forループ、論理演算子(andやor)、switch文などがカウントされる
■ 5. 実装例とシミュレーション
- XPlane 12フライトシミュレータとF-35Bを使用したデモンストレーションが実施された。
- マルチファンクションディスプレイ(MFD)がF-16スタイルで構築され、リアルタイムの飛行データに接続された。
- XPlaneのWeb APIを通じてライブ飛行データが配信される。
- フロントエンドはPython、バックエンドはC++で実装された。
- JSF標準に準拠したC++コードで密度高度計算、飛行データ、旋回計算、V-NAVデータ、風計算などが実行される。
- 非準拠コードでは未処理例外が発生し、プログラムがクラッシュするシナリオが示された。
- 準拠コードではリターンコードを使用し、呼び出し元関数がエラーを適切に処理する。
- 初期のF-35はMotorola G4 Power PCプロセッサベースのミッションコンピュータを使用していた。これは2003年のAviation Todayの記事で公開された情報である。
■ 6. JSF標準の影響と現代への継承
- F-35 C++標準の原則は他の分野や標準にも広がった。
- NASAのF-Prime標準は2017年に公開され、メモリ割り当て禁止、例外処理禁止、再帰禁止という同様の制約を持つ。
- 自動車業界にもコーディング標準が存在する:
- MISRAとAutoSAR(Automotive Open System Architecture)
- AutoSARはC++14標準の影響の一つとしてJSFを名指しで参照している
- AutoSARではスマートポインタが許可されるなど、より現代的なC++の機能が利用可能である
- 自動車は車輪付きコンピュータと言える存在になっている。
- BMW、Ford、Toyotaなど主要な自動車メーカー全てがAutoSARに依存している。
- これらの言語安全性は数十年前に国防総省が下した決定に基づいている。
■ 7. 結論と提言
- Bjarne Stroustrup自身、JSF標準の策定委員会の一員であったが、現在はC++ Core Guidelinesの使用を推奨している。
- 現代のC++は過去20年間で進化し続けており、JSF標準は当時の素晴らしいエンジニアリング成果であったが、より新しく安全な現代的C++を使用すべきである。
- JSF標準は歴史的に重要かつ興味深い部分であり、一見の価値がある。
- JSF標準はC++のような複雑な言語を、重要なインフラストラクチャに安全な予測可能なものに変換することに成功した。
- 最も賢いプログラマーであることが重要なのではなく、どの要素を「飛行前に取り除く」かを知る規律を持つことが重要である。
アメリカ空軍や航空自衛隊が運用する戦闘機「F-35」はC++でコーディングされたソフトウェアを搭載しています。このC++コードは「Joint Strike Fighter Air Vehicle C++ Coding Standards(JSF AV C++)」と呼ばれるコーディング規則に沿って記されているとのことで、Googleの研究者で航空機関連プログラミングにも詳しいLaurieWired(Laurie Kirk)氏がJSF AV C++の特長を解説しています。
F-35よりも前に開発された戦闘機にはアメリカ国務省が開発を主導した「Ada」というプログラミング言語が採用されていました。しかし、F-35の開発当時はすでにAdaが陳腐化しており、代わりにC++を採用することとなりました。C++を採用しつつアリアン5型ロケットのような失敗を防ぐために策定されたコーディング規格がJSF AV C++というわけです。
Dewyは各ホストに常駐し、CIによって作られたアプリケーションやデータ、コンテナを、ホスト上のプロセスとして常に最新となるようにします。いわゆる継続的なデプロイメントを可能にします。継続的なデプロイメントは、Kubernetesを使っているとエコシステムであるArgo CDのようなGitOps ソフトウェアによって、当然のこととして実現できますが、Kubernetesが使えない環境だと既存のデプロイツールで頑張るしかありません。ひょっとすると、SSHで手動デプロイだったり、SCPやSFTPを使った趣のあるshellの実行になるかもしれません。あまり考えたくないですね…