全3回シリーズ｜ 読了目安：10分
前回、685ページの名著をAIとの壁打ちで3層構造のフレームワークに変えるまでの過程を追った。共通基盤、プロファイル、人材育成環境。プライバシーアーキテクチャまで設計した。
正直に言えば、この時点でかなり満足していた。
そして、フレームワーク自身が推奨する「この設計自体をAIと壁打ちせよ」を実行した。自分の設計の最大の弱点は何か。 その問いが、さらに2つの構造的盲点を明らかにした。
盲点① ：目標のない育成は「弱点克服ゲーム」に過ぎない
第1回で紹介した5次元評価——構造化の深さ、視点の網羅性、批判的思考、メタ認知、プロファイル適合——を使って、仮想的な18名の組織の分析レポートを作ってみた。
レポートは見事に完成した。各チームのスコアを集計し、同質化アラートを発行し、相補的なペアリングを提案し、育成施策の優先順位をつけた。「網羅性が3.2だから3.6に上げよう」「メタ認知が3.1だから3.4を目指そう」と。
そこに、決定的な問いが来た。
「このレポートには目標が考慮されていない。会社の中長期計画や、個人の1年後、5年後、10年後の目標も考慮し、目標から逆算するWorking Backwardsで計画・評価すべきではないか？」
その通りだった。
全ての施策が「現在のスコアの弱点を埋める」という改善ベースの思考で設計されていた。網羅性が低い→上げよう。メタ認知が弱い→鍛えよう。
しかし「何のために」が完全に欠落していた。
会社が来年、決済事業に参入するなら、セキュリティ思考の強化が最優先だ。AI駆動の新プロダクトを大量に立ち上げる戦略なら、プロファイルAでの高速壁打ち能力が最重要だ。エンジニアが5年後にCTOを目指しているなら、全次元をまんべんなく上げるより、メタ認知と視点の網羅性に集中投資すべきかもしれない。
目標がなければ、育成はただの「弱点克服ゲーム」になる。
Working Backwards：弱点克服 vs 目標逆算
Working Backwardsの視点を入れると、同じスコアでも優先順位が変わる。
弱点克服ベース（改善前）：
- 壁打ちテンプレート導入（網羅性の底上げ）
- メタ認知同質化対策
- 知識の地図ワークショップ
目標逆算ベース（改善後）：
- プロファイルB昇格の加速（Q3の大型クライアント導入から逆算→Q2期限）
- セキュリティ体制構築（決済機能ローンチから逆算→Q3期限）
- 壁打ちテンプレート導入（上記2つに即効性のある形でカスタマイズ）
同じ「メタ認知の底上げ」でも、目標逆算では優先度が下がる場合がある。外部API公開の期限が2027年Q1と余裕があるなら、その次元の強化は後回しでいい。
個人の育成計画も変わる
入社6ヶ月のメンバーJの例を考える。全次元2.0〜2.8でスコアは低い。
弱点克服の計画： 全次元を底上げする。プロファイルAのチームで基礎を鍛える。
Working Backwardsの計画： Jの5年後の目標が「セキュリティエンジニア」だとわかっている。であれば、1年目はプロファイルAで基礎を鍛えつつ、壁打ちでは今からセキュリティ視点を意識的に含める。2年目にプロファイルCのチームに異動する計画を立てる。
同じ「基礎を鍛える」でも、目標からの逆算があるだけで日々の壁打ちの焦点が変わる。
目標の階層構造
Working Backwardsを機能させるために、目標は4層で階層的に接続する。
会社の中長期計画（3〜5年のビジョン）
└→ 年度のOKRまたは事業目標
└→ 各プロジェクトの四半期目標
└→ 個人の短期（1年）・中期（5年）・長期（10年）のキャリア目標
上位から下位への逆算で、「このチームは来四半期、何を最優先で鍛えるべきか」が決まる。プロファイルの昇格時期も、受動的な「そろそろ必要だから」ではなく、「事業計画で決まっているから」で能動的に計画する。
Working Backwardsの弱点
ただし、目標逆算万能ではない。3つの弱点がある。
目標の質への依存。 「5年後にCTOになりたい」が建前なのか本心なのかで計画が変わる。目標設定自体の壁打ちが必要になる。
目標は変わる。 大規模システムの面白さに目覚めてセキュリティからアーキテクトに目標変更——よくある話だ。変更を歓迎する柔軟性が必要。
会社の目標と個人の目標は衝突しうる。 会社がセキュリティ人材を求めているが本人はフロントエンドに進みたい場合、AIでは解決できない。マネージャーと本人の対話で折り合いをつけるしかない。
それでも、「目標がない状態で弱点克服だけ行う」よりは明確に優れている。
盲点②：合理性の徹底は、合理性では生まれないものを殺す
Working Backwardsを統合してフレームワークv2が完成した——と思った矢先に、もう一つの根本的な問いが来た。
「開発者の創造性・モチベーション・チームの一体感・遊び心などは、イノベーションの源泉。Googleの『20%ルール』がGmailやAdSenseを生んだように、『合理的でない』実験の余白を残すことも、長期的には組織の持続可能性に貢献するのではないか？」
ここまでの議論を振り返ると、全てが「合理的に設計し、合理的に測定し、合理的に改善する」という思想で貫かれていた。
共通基盤は合理的。プロファイルは合理的。評価は合理的。プライバシーアーキテクチャも合理的。Working Backwardsで目標逆算まで入れた。
全てが合理的。そして、その完璧な合理性こそが盲点だった。
GmailはGoogleの20%ルールから生まれた。AdSenseもGoogle Newsもそうだ。これらは「会社の中長期計画から逆算した育成投資」からは絶対に出てこない。計画に存在しないものは逆算の対象にならないからだ。
本フレームワークが『Googleのソフトウェアエンジニアリング』を出発点としながら、Googleの最も重要な文化的特徴の一つを取りこぼしていた。
第6次元：開放性
5次元評価——構造化、網羅性、批判的思考、メタ認知、プロファイル適合——は全て「既知の問題をいかに上手く扱うか」を測っている。
しかしイノベーションの源泉は、「まだ誰も問題だと認識していないことに気づく力」にある。これはビッグファイブの「開放性（Openness to Experience）」と深く結びつく。
そこで第6次元として「開放性」を追加した。ただし、他の5次元とは根本的に扱いが違う。
| 設計上の問い | 回答 |
|---|---|
| 評価スコアに含めるか？ | 含めない。 開放性は性格特性であり、スキルではない。低い開放性を「弱点」と位置づけるのは不適切 |
| では何のために測るのか？ | 観察と奨励。 本人の自己認識のためと、チーム全体の多様性を見るため |
| チーム構成にどう活かすか？ | 全員が開放性5のチームは刺激的だが実装が終わらない。全員が1のチームは堅実だがイノベーションが起きない。多様性のバランスを見る |
探索の余白：制度設計
開放性を「測る」だけでは不十分だ。探索が組織に歓迎されている状態を制度として作る必要がある。
20%探索的壁打ちルール（推奨）。 壁打ちの全体量のうち、少なくとも20%は担当プロジェクトと直接関係のないテーマで行うことを推奨する。ただし、「推奨であって強制ではない」が極めて重要。強制した瞬間に、これは「20%の義務的な探索」に変質し、創造性の源泉としての意味を失う。
探索的壁打ちショーケース（月1回）。 希望者が「こんな面白いことをAIと議論した」を共有する場。発表の質やビジネスへの貢献は問わない。「面白かった」で十分。参加も発表も任意。評価に一切反映しないと明言する。
ハッカソン壁打ちデー（四半期1回）。 全員が通常業務を離れ、自由なテーマでAIと壁打ちし何かを作る日。Working Backwardsの目標逆算とは意図的に断絶させ、この日だけは「合理的でない」ことを公式に許可する。
「管理しない」という設計判断
ここに最も繊細な設計ポイントがある。
遊び心は制度化した瞬間に遊びでなくなる。
「ハッカソン壁打ちデー」を制度化した時点で、それは「組織が許可した遊び」であり、本来の自発的な遊び心とは異なる。しかし制度がなければ「遊んでいいのかわからない」という心理的障壁が残る。
この矛盾に対する回答は、制度は「許可」を与えるだけにとどめ、中身は一切管理しないこと。何をするか、何を作るか、成果を出すかどうかは完全に自由。「管理しない」という設計判断自体が、遊び心を守る最も重要なメカニズムだ。
プロファイル別の探索推奨度
探索の余白も、プロファイルごとに温度差を持たせる。
| プロファイル | 探索推奨度 | 理由 |
|---|---|---|
| A：小規模・高速型 | ★★★ 最大限推奨 | 実験と発見がプロダクトの方向性を決める段階 |
| B：大規模システム型 | ★★ 推奨 | 既存の枠を超える改善アイデアの源泉として |
| C：セキュリティ厳格型 | ★ 許容 | 創造的攻撃思考は必要だが本業優先 |
| D：ミッションクリティカル型 | ☆ 控えめに許容 | 安定性が最優先 |
最終アーキテクチャ：3層＋2軸
2つの盲点を統合して、フレームワークの最終形が完成した。
┌─────────────────────────────────────────┐
│ 横軸①：Working Backwards │
│ 会社 → 部門 → PJ → 個人の目標逆算 │
├─────────────────────────────────────────┤
│ │
│ 第1層：共通基盤 │
│ モノリポ / トランクベース / AI駆動CI/CD │
│ 文化原則 / 目標の階層構造 / 探索の余白 │
│ │
│ 第2層：プロファイル（A / B / C / D） │
│ AI依存度 / テスト基準 / レビュー体制 │
│ 探索推奨度をプロファイルごとに設定 │
│ │
│ 第3層：人材育成環境 │
│ 6次元評価（5次元 + 開放性） │
│ 3段階フィードバック │
│ プライバシーアーキテクチャ（3データ層） │
│ │
├─────────────────────────────────────────┤
│ 横軸②：探索の余白 │
│ 20%探索 / ショーケース / ハッカソン │
└─────────────────────────────────────────┘
2つの設計原則
このフレームワーク全体を貫く原則は2つ。
原則①：ポリシーではなくメカニズムで守る。 「CEOでもログを見ない」ではなく「CEOが見ようとしてもアクセス権が存在しない」。「評価に使わない」ではなく「評価に使える形でデータが存在しない」。
原則②：合理性の外の価値を、合理的に守る。 Working Backwardsの目標逆算は完全に合理的だ。しかし、計画にないイノベーションは合理性から生まれない。だから、探索の余白を「合理的に設計して」「合理的に制度化して」「合理的に守る」。
合理性と非合理性の共存。一見矛盾しているが、これこそがフレームワークの最後のピースだった。
次回予告
第2回では、2つの構造的盲点（Working Backwardsと探索の余白）の発見と、最終フレームワーク（v2）の全体像を解説した。
第3回では、このフレームワークを明日から使える形に落とし込む。Claude CodeのCLAUDE.mdファイルとして実装したプロファイルA〜Dの具体的な運用ルール、AI分析レポート生成プロンプトの設計、そしてこの記事自体が「壁打ちの実例」であることの振り返りを行う。
第3回「明日から使える——CLAUDE.mdとAI分析プロンプトの実装」に続く →