全3回シリーズ｜ 読了目安：10分

ある日、685ページの本をAIに読み込ませて「使えるようにして」と頼んだ。

『Googleのソフトウェアエンジニアリング——持続可能なプログラミングを支える技術・文化・プロセス』。Google社内で数万人のエンジニアが、20億行以上のコードを数十年にわたって運用してきた知見をまとめた名著だ。

この本のエッセンスを抽出し、レバレッジメモとアクションマトリクスを作るところまでは、AIの得意分野だった。しかし、本当に面白かったのはここからだ。AIに問いをぶつけ続けることで、書籍の枠組みを超えた独自のフレームワークが生まれた。

この記事では、その過程——AIとの「壁打ち」を通じてフレームワークがどう進化していったかを追う。

出発点：名著の「落とし穴」

『Googleのソフトウェアエンジニアリング』は素晴らしい本だ。だが、いくつかの前提がある。

エンジニア数万人規模であること。コード2億行以上であること。数十年稼働するシステムであること。つまり、この本が想定しているスケールは極端に大きい。

スタートアップや少人数のチームが、この本のルールをそのまま適用しようとすると、過剰なプロセスに押しつぶされる。かといって「うちはGoogleじゃないから関係ない」と切り捨てるには、あまりにもったいない知見が詰まっている。

さらに、2026年現在、本書が出版された2020年とは大きく異なる前提がある。AI駆動開発の普及だ。コードレビュー、テスト生成、リファクタリング——本書の第3部・第4部で扱う多くの実践が、AIの台頭で根本的に変わりつつある。

そこで、AIに最初の問いを投げた。

「AI駆動開発が普及してくれば、本書の内容（特に3部と4部）は大きく変わってくるのではないか？」

第一の転回：「プロファイル」という発想

AIの回答は、予想通り「変わる領域」と「変わらない領域」を整理してきた。コードレビューはAIが一次を担い、テスト生成はAIが得意で、ドキュメントは自動生成される——しかし、アーキテクチャの判断、倫理的配慮、チーム間の交渉はAIにはまだ難しい、と。

悪くない分析だ。でも、まだ本の枠の中で考えている。そこで次の問いを投げた。

「本書はエンジニア数万人規模が前提だが、AI駆動開発も前提にした場合、小さな組織の『まず動くものを速く出す』開発を、モノリポやトランクベース開発でできるのではないか？」

AIは「できる」と答えた上で、小規模チームでもモノリポ+トランクベース開発は有効だと展開した。だが、ここで気づいた。全てのシステムに同じルールを当てはめようとしている。MVPのプロトタイプと、決済システムに同じテストカバレッジを要求するのはおかしい。

「実行計画を1つにするのではなく、全体に適用するもの、セキュリティが厳しいシステムに適用するもの、大規模システムに適用するもの、小規模システムに適用するものなどを用意し、AIが苦手な分野をカバーできるような人材育成環境ができれば、落とし穴もほとんど解決できるのではないか？」

この問いから、3層構造が生まれた。

3層構造：フレームワークの骨格

第1層：共通基盤（全システム共通・非交渉事項）

少なく、しかし絶対に。

モノリポ、トランクベース開発、AI駆動CI/CDなど、システムの種類を問わず適用する技術基盤と文化基盤。ここに含まれるルールは「守るかどうか」ではなく「最初から組み込まれている」もの。

第2層：プロファイル（システム特性別の運用）

「万能の解は存在しない」を制度化する。

プロファイル 最優先事項 AI依存度 テストカバレッジ
A：小規模・高速型 速度 最大 60%
B：大規模システム型 一貫性 中 80%
C：セキュリティ厳格型 安全性 制限 80%+ペネトレーション
D：ミッションクリティカル型 保守性 最小 80%+複数人レビュー

MVPを作っているチームはプロファイルAで高速に動き、決済システムを扱うチームはプロファイルCでセキュリティ専任レビュアーを必須にする。同じ組織の中で、異なるプロファイルが共存する設計だ。

第3層：人材育成環境

AIが苦手な5つの領域——アーキテクチャの判断、未知の脅威の発見、トレードオフの価値判断、チーム間交渉、障害時の即時判断——を、人間が鍛え続けるための仕組み。

ただし、この第3層の設計が、壁打ちを通じて最も大きく進化することになる。

第二の転回：「壁打ち」の再発見

第3層の人材育成環境を議論している中で、AIは「人間だけが担う5つの領域」を提示してきた。この分類自体は正しい。しかし、暗黙の前提に気づいた。

「AIが苦手 = 人間が単独で担う」という二分法になっている。

「AIが苦手な分野でも、人間が全て行うのではなく、AIと壁打ちして思考を拡張することも有効ではないか？」

この問いが、フレームワーク全体の方向性を変えた。

壁打ちとは何か。AIにコードを書かせることでも、答えを教えてもらうことでもない。自分の思考を構造化し、反論を生成し、見落としている視点を発見するために、AIを対話相手として使うことだ。

たとえば、アーキテクチャの設計判断で迷っている時に「この案を選ぶべきでない最も強力な反論を3つ構築して」と頼む。脅威モデリングで「私の攻撃手法Xを発展させた変種を3つ考えて」と壁打ちする。障害対応のプレモーテムで「午前3時にこのシステムが壊れる最も可能性の高いシナリオを5つ」と列挙させる。

AIに答えを求めるのではなく、AIに問いを拡張してもらう。

この発想を取り込むと、第3層は「人間が単独で鍛える場」から「人間がAIとの壁打ちを通じて思考を拡張する場」に変わった。

第三の転回：壁打ちログという「資産」

壁打ちが有効なら、そのログは分析できるはずだ。ここでさらに踏み込んだ。

「壁打ちログの提出を必須にし、フィードバックするのなら、メンターは人間だけでなくAIも含めたほうが良くないか？ さらにAIがログから性格診断や適性、相性なども分析し、人材育成計画の改善やチーム構成の最適化も行うようにすればどうか？」

AIは慎重に答えた。有効だが倫理的な境界線が必要だ、と。性格分析は差別に繋がりかねない、プライバシーが侵害されるリスクがある、壁打ちが「監視されている」感覚になれば心理的安全性が崩れる——。

正論だ。しかし、ここでもう一歩踏み込んだ。

「評価への直接利用の禁止を原則としているが、壁打ちの問いの質は、人材育成環境の肝として最重要評価項目としていいのではないか？」

AIの前提をひっくり返す問いだった。「壁打ちログは評価に使わない」という安全策を、「壁打ちの問いの質こそ最も重要な評価項目だ」に転換する。

「最も重要なものを測らないのは、測る技術がないからではなく、測る勇気がないだけではないか。」

第四の転回：プライバシーを「構造」で守る

壁打ちの問いの質を評価に使う。しかし心理的安全性も守る。この一見矛盾する要件を同時に満たすにはどうすればいいか。

「壁打ちログについては、メンターがフィードバックする対象以外はAIのみが見れるようにし、人間は最上位者でもログは見れず、AI分析レポートだけ見れる構造にすれば、運用する組織がこの倫理的境界線を本気で守り続けられる仕組みにできないか？」

この問いから、3つのデータ層のプライバシーアーキテクチャが生まれた。

層 アクセス権 内容
第1層：生ログ 本人とAIのみ 壁打ちの全記録。CEO/CTOでも見れない
第2層：メンタリング対象 本人が選んだメンターのみ 時限付き。2週間で自動失効
第3層：AI分析レポート 本人→メンター→マネージャー スコアと傾向のみ。具体的な問いの内容は含まない

決定的に重要なのは、これが「ポリシー」ではなく「メカニズム」であること。「CEOでも生ログを見ない」というルールではなく、「CEOが見ようとしても暗号化されていてアクセス権自体が存在しない」という構造。

信頼ではなく、アーキテクチャで守る。

ここまでの問いの連鎖

最初の問いから、ここまでの流れを振り返ってみよう。

「AI駆動開発で本書の3部4部は変わるのでは？」
  ↓ AIの回答に対して
「小さな組織でもモノリポ+トランクベースでできるのでは？」
  ↓ AIの回答の前提を覆して
「全システム共通ではなく、プロファイルを分ければ落とし穴も解決できるのでは？」
  ↓ AIの「人間が単独で担う」という二分法を突いて
「AIが苦手な分野でも、壁打ちで思考を拡張できるのでは？」
  ↓ 壁打ちを仕組み化するなら
「メンターにAIも含め、ログを分析して育成に使えばどうか？」
  ↓ AIの「評価禁止」という前提を覆して
「問いの質こそ最重要評価項目にすべきでは？」
  ↓ 心理的安全性との両立のために
「生ログを構造で守れば、倫理的境界線を組織が守り続けられるのでは？」

各問いがAIの回答の「前提」を正確に突き、より優れた構造に導いている。これ自体が、壁打ちの実例だ。

次回予告

第1回では、書籍分析からフレームワークの骨格（3層構造+プライバシーアーキテクチャ）が生まれるまでの過程を追った。

しかし、このフレームワークにはまだ重大な欠陥が2つあった。

第2回では、Working Backwards（目標逆算）と探索の余白——AIとの壁打ちの中で発見された2つの「構造的盲点」と、それを統合した最終的なフレームワーク（v2）を解説する。

「合理性の徹底は、合理性では生まれないものを殺す。」

この言葉の意味が、第2回で明らかになる。

第2回「目標のない育成はゲームに過ぎない——Working Backwardsと探索の余白」に続く →