キーワードやフレームワークに頼らない！

こんにちは。ハカセです。

先日のセミナーに参加頂いた方、ありがとうございました。また残念ながらご参加いただけなかった方、ぜひ次回を楽しみにしております。

さて、今週のお題は「失敗の類型化」。

実は先日の第二回セミナーで ZonE が発表した内容でもあります。ZonE の発表内容で僕が白眉だと思ったのは「PDSのSを大事にしましょう」という件（くだり）。「なぜ点が取れなかったのか」という振り返りのみならず、「どうして点が取れたのか」を振り返りましょう、というもの。なるほど、そのとおりだよな、と。

今回、僕がお話しするのは、「なぜ点が取れなかったか」という方。これで悩んでいる方、特にストレート生で多いんじゃないでしょうか。

◇ 伸び悩みの人の典型パターン ◇

二次試験には必ず正解があります。これは受験生に「合」か「否」のマークを付けなければならない以上、そして、とても一人では採点できない規模である以上、やむを得ないし、ゼッタイに「模範解答」や「採点基準」があることは間違いありません。

多くの受験生は、「じゃあその採点基準となる単語や修飾句を探しに行こう！」と躍起になるわけです。点が伸び悩んでいる人、特にストレート生が特にこの傾向が顕著。確かに最終的にはそこに行きつくのですが、それがために、誤ったローリスクメソッド を行い、「何でもいいから材料やキーワードを盛り込め！」みたいな感じになってしまいます。

点数が伸び悩んだ受験生が次にすることは、「フレームワーク」や「型」と呼ばれるものを探し始めます。解答にはパターンがある。理由を聞かれたら「・・・ため」で閉じるとか。こういう簡単な「型」なら使いやすいし、型を使うこと自体は否定しないのですが、慣れずに使うと、そればかりが先行してしまい、肝心の「編集」の過程がおろそかになってしまい、後から読み返して意味不明な窮屈な文章になっている 恐れがあります。

偉そうに言っていますが、何を隠そう、昨年の今ごろ、僕自身がこのスパイラルに陥っていました。

　
模範解答や採点ポイントに近いことは思いついている
↓
でも、点にならない
↓
採点にならなかったことを
その演習特有のものとして放置する
↓
解決策を持たないまま、次の演習に臨む
↓
やっぱり点にならない
　

典型的な悪循環です。

◇ 大事なことは失敗の類型化 ◇

ZonEが言っていたように、大事なことは、Plan – Do – See の S です。

これをもう少し発展させ、僕は、「失敗の類型化」を提案します。つまり、「失敗を抽象的に説明すること」です。

具体的には、

「この問題は、『競合他社との差別化 』というキーワードを盛り込めなかったから点が取れなかった」 ではなく、

「この問題は、競合のポイントを含めることが出来なかった」
「それは3C のフレームワークで考えれば出てきたはず」
「つまり、フレームワークで漏れを探す作業を怠ったのが失点原因」

という説明です。

抽象的に説明する とは、事例本文を読んでいない人にも分かるようにする ことです。

色々な抽象化の方法があると思いますが、僕は最終的に、自分の失敗を下記の二つに類型化しました。

僕の失敗は、「ルール違反」、および「幅」か「深み」のどれかに集約されたのです。

例えば、先日行われた2010年TAC二次試験対策公開模試のとある問題。僕の再現答案はこちら。

【事例 I の第二問】
管理担当役員と業務分掌して事業計画策定や
資金調達・人事体制整備を委任したことで、
社長が企画・運営に専念でき豊富な情報発信
による他社と差別化と、社会的信用力の向上
による資金調達や人材確保を両立させたため。

自分では悪くない回答だと思うんですが（やや文章が分かりにくい？ まぁそこはご容赦・・）、模範解答と比較すると、「不安定な急成長期を乗り越えた」という更なるもう一歩が足りない。

確かに、設問文の中に「ベンチャー企業として」とあるんだから、ほかのベンチャー企業が一般的にどうであるところを、A社はどうしたのか、という指摘が欲しかったところ。

これは「深みの不足」という類型になるでしょうね。とはいえ、その前に「両立させた」という一歩があるので、そこはよしとしなきゃいけないな、という気持ちもあるのですが。

——————

このように、得点出来ない原因を、その演習特有の問題として片付けずに、なるべく抽象化してとらえることが重要だと思います。

自分が出来なかった問題の解説を読むのは苦痛なものです。でも、解答解説には（上記の例でいえば）、「なぜそこまで踏み込んで書かなければいけないのか」を説明してくれています。

それらを一つ一つ積み重ねていけば、自然と「フレームワーク」が出来てくるようになるのです。この「自然と」というのが、僕は大事だと思います。輸入したフレームワークは、どうも窮屈で使いにくいのが実情です。

フレームワークについては、また次の機会に。まずは解答解説をしっかり読み、失敗を類型化してみましょう。新しい何かが見えてくるかも知れません。

by ハカセ ＠ 解答解説を読まない派 でした