サービス設計 / 2026/9/27 / 約3分

思考力トレーニングを「才能」ではなく、問う練習の反復に絞った

今回やったこと

思考力トレーニングツールの位置づけを、「地頭を鍛える」から「恥のコストゼロで問う練習の回数を稼ぐ場所」へ変更した。経験の代替や、広い領域への遠転移まで主張すると、効果を測れないサービスになりやすい。そこで対象をAWS運用の判断練習に限定し、まずはPhase 0で設計だけを検証した。

この記事の実装ステータスはPoCである。コードを完成させた話ではなく、シナリオ、進行、監査、記録を小さく組み、演習として成立するかを確かめた記録だ。

「思考力を鍛える」という表現は便利だが、何が伸びたのかを測りにくい。学習者が難しい問題を解けるようになったとしても、それが実務の判断力に移ったのか、単に出題形式に慣れたのかを分けるには別の評価が必要になる。

そこで看板を小さくした。対象はAWS運用の判断練習、価値は質問をためらわずに繰り返す場所、評価対象は演習の中でどんな問いを出し、どの判断を記録したか、とした。広い能力を約束せず、観察できる行動に絞ることで、Phase 0の結果を次の改善に使えるようにした。

phase: 0
scope: AWS運用の判断練習
scenarios: 3
validated_scenario: SCENARIO-01
play_time: 10分
turns: 6

Phase 0ではコードを書かなかった。用意したのはシナリオ3件、ゲームマスター役と監査役のプロンプト、そしてプレイ結果を残す記録票である。演習を自動化することよりも、問いを出し、回答し、後から監査できる最小単位を先に固定した。

SCENARIO-01では、プレイと監査を10分、6ターンで完了した。その結果、参加者の能力を評価する以前に、演習側の設計不備5件が見つかった。つまり、最初の検証で得られた価値は「思考力が伸びた」という証明ではなく、どこを直さないと練習として成立しないかの発見だった。

次のシナリオは封印した。先に現在のプレイを終えるまで内容を要約しないという運用制約も置いた。これは演習を難しく見せるためではなく、答えや論点を先に知ってしまうと、プレイ中の判断を評価できなくなるためだ。

また、Phase 0の結果から「AWS運用が上達した」「一般的な思考力が伸びた」とは言わない。現時点で確定しているのは、限定したシナリオを短時間でプレイ・監査でき、設計上の不備を5件見つけたことだけである。効果測定をしないまま教育サービスの看板を大きくすると、測れない約束だけが残る。

この設計で解決できるのは、実務判断を安全に試し、質問を記録し、監査の観点から演習自体を見直すことだ。失敗しても本番環境を壊さず、質問をためらうコストも下げられる。

一方、これだけでは実務経験の代替にはならない。AWS以外の領域へ移ったときの効果も確定していない。遠転移を主張するには、別のシナリオと測定が必要になる。Phase 0の検証範囲をここまでに留めたのは、この限界を曖昧にしないためである。

思考力トレーニングを成立させる最初の仕事は、難しい問題を増やすことではなかった。何を練習し、何を記録し、どこまでを効果として言ってよいかを狭く決めることだった。今回のPoCでは、10分・6ターンの小さな演習から5件の設計不備が見つかった。

この結果から言えるのは、問いの反復を設計対象にできるということまでである。才能や汎用的な思考力を約束する前に、対象領域を限定し、演習の中で観察できる事実を積み上げる必要がある。