「プロジェクトで誰かから問題の解決策について質問を受けたらなんて答えますか？」という質問をされました。意図としてはすぐ答えを教えるべきか、それとも考えさせるべきかというようなこと。
これのフレームを考えてみるに以下のようになるかなと。
Aは問題を構造的に理解し、解決策が分かっている状態。これは既に問題はありません。理想的な状態です。
Bは問題を構造的に理解しているものの解決策が分かっていない状態。ここまでくればGoogleで調べて知識を補うなり、人に聞くなりして適切な解決策を見つけることが可能になります。
Cは問題を構造的に理解していないものの解決策が分かっている状態。これは特定に問題を解決することは可能ですが、応用や類似的な状態に対応することができません。
Dは問題も理解できず解決策も分かりません。
さて、誰かが質問をしてきたのであれば、その人はBかDの状態にあります。
特にDの場合には判断が必要になります。DからいきなりAに行くのは難しいので、BかCを経由させなくてはいけません。これはメンバーの資質によります。
Bは抽象的に問題を把握すること能力がある人に向きます。その後、実例として解決策を教えることでより強く構造を把握することができます。どういう人かというと、ばっくりした話が好きで、テストは適当ですがコツをつかんでいます。その割りに単純なミスをおかしがちです。
一方のCは実例がある中から分析的に構造を発見する能力がある人に向きます。実例を重ねていく中でサジェストをしてあげることで構造をばちっと理解し応用力を身につけます。どういう人かというと、緻密な話が好きで、テストはコツコツとクリアしていきます。ミスは少ないですが傍から見ていて無駄が多いように感じることもあります。
実は問題が多いのがCで留まっている場合です。一見、問題を解決していそうですが応用が利かないため現場では有効に機能しなくなってしまいます。本人のスキルがそもそも足りないわけでもなければ、ちゃんと構造的な理解を促す必要があります。構造を緻密に教えるというよりも現状の問題をゼロベースで再分析させてやるようなアプローチが有効です。
あとは自分の資質も理解しておいたほうがよいでしょう。僕はC->B->Aという理解が好きなので、それを他人にも強要しがちです。
自分と資質が合わない人の場合「なんで教えてくれないんだ」あるいは「なんで理由は考えるなとか言うんだ」というようなミスマッチが発生してしまいます。
というわけで「誰かから問題の解決策について質問を受けたらなんて答えますか？」というのは一概に答えられることではありません。相手の資質にもよりますし自分の資質にもよります。ちょっと意識するだけでも効果的に教えることができるようになります（って、自分もできてないけどｗ）。
