はじめに
クラシル株式会社でPMをしている岩崎です。
Claude Codeなどを活用して日々のアクティビティを自動で収集し、振り返りなどに活かしている方は多いと思いますが、今回その取り組みのなかで自身の思考や認知のクセをレビューしてもらうという仕組みを作ってみたので紹介します。
動機
自身の思考や認知のプロセスをもう一人の自分が客観的に観察し、問い直すことで自身の言動・行動をコントロールしようとすることは、メタ認知を用いた内省プロセスとして自己成長に欠かせない要素だと思います。このメタ認知が不足すると、PMやエンジニアとして高度なスキル・知識を持っていても、今の状況に対して誤ったプラクティスを適用してしまう、ということが起きます。
例えば、以下のようなシチュエーションです。
| 観点 | 説明 |
|---|---|
| 役割 | エンジニア |
| 状況 | 実装がうまく進んでいて集中できている |
| 思考 | 今いい感じに乗っているから、この勢いで書き切ってしまいたい |
| 結果 | 設計方針のズレに気づかないまま進み、後で手戻りが発生する |
ありがちな状況だと思いますが、メタ認知が働いている場合、「この集中は心地よいが、方向性が合っているか確認せずに走り続けていないか？」と自問できます。これにより、ステークホルダーに対してレビューポイントを適切に設置するなど、行動を制御できます。
ただし、メタ認知自体が認知リソースを消費する作業であるため、目の前のタスクに追われているときなど、本当に必要なタイミングで機能しにくいという構造的な問題があります。
そのため、メタ認知のきっかけを外部から供給する仕組みに価値があります。本人の認知負荷に依存せず、いま立ち止まって問い直すべき点を投げかけてくれる仕組みがあれば、メタ認知の起動コストを大幅に下げられます。
実装
今回はその仕組みをClaude Codeに自身の思考・認知のクセをレビューしてもらうという手段で作ってみました。
上図はClaude Codeのエコシステムで構築しているデイリーレポートの生成パイプラインで、主に下記のレイヤーに分解されます。
- 各データソースから自身のアクティビティを収集し統合するレイヤー
- 最新のファクトからコンテキストを最新化するレイヤー
- 各観点でファクトをレビューし解釈を生成するレイヤー
- レビュー結果を統合しレポートとして出力するレイヤー
この3つ目のレイヤーにメタ認知の観点でファクト分析するMeta ReviewerというAgentを追加する形にしました。このAgentはファクトを読み込んで行動パターンを抽出し、そこに内在する思考・認知プロセスを仮説として持った上で、ユーザーに対してメタ認知による内省を促す問いを生成します。
例えば、実際のある日のレポートでは、以下のような出力になっていました。
| 行動パターン | 認知プロセス（仮説） | 問い |
|---|---|---|
| マネジメントロール本来のアウトプットよりも、メンバーに委譲できたはずの技術サポートや即レス対応に自ら手を動かす時間が多く割かれている。 | すぐ返した方がチームのブロッカーが外れて全体が速く進むという思考回路がデフォルトで起動し、その都度これは自分がやるべきかの判断ステップをスキップしている可能性。 | マネージャーとしての自分とプレーヤーとしての自分のどちらの声に、より多く従って動いていたか？ |
Meta Reviewerの工夫
1. 問いで終わらせる
Role Reviewer（役割とのギャップ分析）やAlignment Reviewer（目標とのギャップ分析）が何をすべきかの提案を出すのに対し、Meta Reviewerの出力は必ず疑問符で終わる問いだけにして、アクションや推奨事項を含めないようプロンプトで強制しています。解決案まで書いてしまうと、ユーザーの思考が提示された案を取捨選択して実行するモードになってしまい、メタ認知の内省トリガーとしての役割を果たせないからです。
2. 認知の仮説を挟む
出力フォーマットは行動パターン → 認知プロセスの仮説 → 問いの3列テーブルにしています。問いだけではなく、その問いの背景にある認知バイアスの仮説も同時に提示する形です。客観的な事実からこういう認知のクセが働いている可能性があるという仮説を挟むことで、自身の思考パターンを客観視しやすく、問いが内省のトリガーとして機能しやすくなるためです。
3. 問いの角度を変える
Meta Reviewerには以下の5つのルールを持たせ、その中から選択して問いの生成に適用する形にしています。同じ問い方を続けるとユーザーが慣れて流すようになり、一つの視点では見えない領域が盲点として残り続けます。ルールを切り替えて違う角度から問うことで、形骸化を防止しています。
| ルール | 内容 |
|---|---|
| A. 対立仮説 | 現在の判断の前提に対して、もっともらしい反対仮説を立てる |
| B. 視座移動 | 同じ行動ログを第三者が見たらどう評価するか |
| C. 反事実思考 | もし過去の分岐が別だったら、今の優先順位はどう変わるか |
| D. 時間的割引無効化 | 目先の達成感で後回しにされている長期タスクを顕在化 |
| E. 感情ラベリング | 特定領域への忌避・過剰集中の感情的動機を言語化 |
結果
Meta Reviewerを組み込んだことで、レポートの受け取り方が構造的に変わりました。
従来のフローでは、Role Reviewerが出す提案を実行するかどうかの判断で完結しがちで、提案の精度が高いほど自分自身の思考を省略させてしまいやすい構造でした。Meta Reviewerによるレポートが入ったことで、提案を受け取る前に自分の認知にどんなクセが働いているかを問われるステップが強制的に差し込まれるため、一度立ち止まって自分の判断プロセス自体を振り返る機会が仕組みとして担保されました。
直近の実際に生成されたレポートでも下記のような問いが生成されており、ハッと考え直す機会になっています。
| 行動パターン | 認知プロセス（仮説） | 問い |
|---|---|---|
| Lightdash埋め込みのアーキテクチャ検討に一日を通じて関与した。この間、メンバーへの指示・確認を自ら主導し、技術的な意思決定にも深く関与している | 「アーキテクチャの方向性を自分が握らないと後で手戻りになる」という合理的な判断が働いていた可能性がある。しかし同時に、技術的な議論の深さと展開の速さに没入する心地よさが、関与の深さと時間の長さを無意識に正当化していた可能性がある | この技術議論への関与は、PMとして方向性を合意するための必要十分な関与でしたか、それとも途中からエンジニアとして技術的に正しい設計を自分で確かめたいという思考回路に切り替わっていた瞬間はありませんでしたか？ |
おわり
AIによる振り返りレポートは便利ですが、提案の質が上がるほどユーザー自身の思考が省略されやすくなる側面があります。Meta Reviewerはその構造に対して、問いを強制的に挟むことで自分の頭で考える機会を担保する仕組みです。
AIをうまく活用するためには、AIの出力をそのまま受け取るのではなく、自分の思考や認知のクセを自覚した上で判断するという関係性を設計レベルで組み込むことが大事だと感じています。
Discussion