キーワードやフレームワークに頼らない!
こんにちは。ハカセです。
先日のセミナーに参加頂いた方、ありがとうございました。また残念ながらご参加いただけなかった方、ぜひ次回を楽しみにしております。
さて、今週のお題は「失敗の類型化」。
実は先日の第二回セミナーで ZonE が発表した内容でもあります。ZonE の発表内容で僕が白眉だと思ったのは「PDSのSを大事にしましょう」という件(くだり)。「なぜ点が取れなかったのか」という振り返りのみならず、「どうして点が取れたのか」を振り返りましょう、というもの。なるほど、そのとおりだよな、と。
今回、僕がお話しするのは、「なぜ点が取れなかったか」という方。これで悩んでいる方、特にストレート生で多いんじゃないでしょうか。
◇ 伸び悩みの人の典型パターン ◇
二次試験には必ず正解があります。これは受験生に「合」か「否」のマークを付けなければならない以上、そして、とても一人では採点できない規模である以上、やむを得ないし、ゼッタイに「模範解答」や「採点基準」があることは間違いありません。
多くの受験生は、「じゃあその採点基準となる単語や修飾句を探しに行こう!」と躍起になるわけです。点が伸び悩んでいる人、特にストレート生が特にこの傾向が顕著。確かに最終的にはそこに行きつくのですが、それがために、誤ったローリスクメソッド を行い、「何でもいいから材料やキーワードを盛り込め!」みたいな感じになってしまいます。
点数が伸び悩んだ受験生が次にすることは、「フレームワーク」や「型」と呼ばれるものを探し始めます。解答にはパターンがある。理由を聞かれたら「・・・ため」で閉じるとか。こういう簡単な「型」なら使いやすいし、型を使うこと自体は否定しないのですが、慣れずに使うと、そればかりが先行してしまい、肝心の「編集」の過程がおろそかになってしまい、後から読み返して意味不明な窮屈な文章になっている 恐れがあります。
偉そうに言っていますが、何を隠そう、昨年の今ごろ、僕自身がこのスパイラルに陥っていました。
模範解答や採点ポイントに近いことは思いついている
↓
でも、点にならない
↓
採点にならなかったことを
その演習特有のものとして放置する
↓
解決策を持たないまま、次の演習に臨む
↓
やっぱり点にならない
典型的な悪循環です。
◇ 大事なことは失敗の類型化 ◇
ZonEが言っていたように、大事なことは、Plan – Do – See の S です。
これをもう少し発展させ、僕は、「失敗の類型化」を提案します。つまり、「失敗を抽象的に説明すること」です。
具体的には、
「この問題は、『競合他社との差別化 』というキーワードを盛り込めなかったから点が取れなかった」 ではなく、
「この問題は、競合のポイントを含めることが出来なかった」
「それは3C のフレームワークで考えれば出てきたはず」
「つまり、フレームワークで漏れを探す作業を怠ったのが失点原因」
という説明です。
抽象的に説明する とは、事例本文を読んでいない人にも分かるようにする ことです。
色々な抽象化の方法があると思いますが、僕は最終的に、自分の失敗を下記の二つに類型化しました。
僕の失敗は、「ルール違反」、および「幅」か「深み」のどれかに集約されたのです。
例えば、先日行われた2010年TAC二次試験対策公開模試のとある問題。僕の再現答案はこちら。
【事例 I の第二問】
管理担当役員と業務分掌して事業計画策定や
資金調達・人事体制整備を委任したことで、
社長が企画・運営に専念でき豊富な情報発信
による他社と差別化と、社会的信用力の向上
による資金調達や人材確保を両立させたため。
自分では悪くない回答だと思うんですが(やや文章が分かりにくい? まぁそこはご容赦・・)、模範解答と比較すると、「不安定な急成長期を乗り越えた」という更なるもう一歩が足りない。
確かに、設問文の中に「ベンチャー企業として」とあるんだから、ほかのベンチャー企業が一般的にどうであるところを、A社はどうしたのか、という指摘が欲しかったところ。
これは「深みの不足」という類型になるでしょうね。とはいえ、その前に「両立させた」という一歩があるので、そこはよしとしなきゃいけないな、という気持ちもあるのですが。
——————
このように、得点出来ない原因を、その演習特有の問題として片付けずに、なるべく抽象化してとらえることが重要だと思います。
自分が出来なかった問題の解説を読むのは苦痛なものです。でも、解答解説には(上記の例でいえば)、「なぜそこまで踏み込んで書かなければいけないのか」を説明してくれています。
それらを一つ一つ積み重ねていけば、自然と「フレームワーク」が出来てくるようになるのです。この「自然と」というのが、僕は大事だと思います。輸入したフレームワークは、どうも窮屈で使いにくいのが実情です。
フレームワークについては、また次の機会に。まずは解答解説をしっかり読み、失敗を類型化してみましょう。新しい何かが見えてくるかも知れません。
by ハカセ @ 解答解説を読まない派 でした