最近はGMATやTOEFL関連検索ワードが多い気がします。
そういう時期なんですかね？

英語系はちょっと前に書いたので今回はGMAT編パート2として
アプリカントの方とGMATについて雑談するときに話してることを書いてみます。

よくボクはGMATはラッキーでしたという話をするのですが、
そういうときは、ラッキーなことに選んだ選択肢が
たまたまたくさん正解だったということを言っているわけではなく、笑

1)Career Phase
2)職種

この2個の要素が両方ともたまたまGMAT向きでラッキーだった
ということを言っています。

Career Phase

MBAの卒業生の方々とお話すると
よく「GMATは全く役に立たないぜー」みたいな話を聞きます。
特にOver-Achievement系の成果を持って
それでMBA受験を突破されている方々に顕著な気がします。

僕は、これは主にその人のいるキャリアステージによって
仕事における成果の出し方に違いがあるからだと思っています。

キャリアの浅い方々は
仕事を進めていく上で判断の拠り所となる経験が乏しく、
その経験をカバーするためにクリティカルシンキングという
よくわかんないことに出くわした時に合理的に決断するのに必要な思考だったり
そういう状況下で効率的にコミュニケーションを行うのに必要な思考だったり
を使う必要性があるわけですが、
ミッドキャリア以上の方々は
これまで培われてきた経験を元にすることで、
クリティカルシンキングを使うよりも
圧倒的に速く精度も結構高い判断ができてしまいます。

きっとGMATは、クリティカルシンキング能力を測るのものなので、
そもそもこれまでのリッチな成功体験を成果の源泉にされている人たちには
あまり通用しないと思います。

逆にバックグラウンド皆無で無知の仕事を始めたりしている
まだキャリアの浅い人たちにとっては
SurviveするためのスキルがGMATにそのまま通用する気がします。

職種

システムエンジニアはバックグラウンド的に
MBA受験に不利なことが多いのですが、
仕事柄よくわかんないことに出くわすことだらけなので
GMATに関してだけは唯一有利に働いた気がします。

以下に各テーマについて
ボクのバックグラウンドがどう役に立ったか記載してみます。

Critical Reasoning

超簡単に言うと、
「自分や相手の無意識においている前提を明確にして
コミュニケーションロスを防ぎましょう。」
というのがCritical Reasoningだと思うのですが、
前提そのものを答える問題があったり、
前提を利用して議論、主張を強めたり弱めたりします。

システムエンジニアの仕事で言うと保守フェイズがそのままこれにあたります。
基本的に登場人物はお客さん、コンサルさん、開発(システムエンジニア)で
だいたい、お客さんが製品を使っていると問題が起きます。
そしてだいたいお客さんやお客さんから連絡を受けたコンサルさんが言うのは
「何もしてないのに何かが起こった。」とか
「今までと全く同じ操作をしているのに変なデータが出来た」とか
「こういう操作をしたらこういうエラーが起きたから
この操作をするとバグる」とか。
お客さん、コンサルさんはシステムの表面しか見れないので
表面上の操作と起こった結果から因果関係を類推します。
その因果関係の類推が無意識に行われていたり、
類推であることを伝え忘れたりすると
GMATで出題されるCritical Reasoning問題の完成です 笑

彼らのおいている前提を検証して
もし間違っていた場合は自分で新たな仮説を作って検証のサイクルを
正解にたどり着くまでまわします。
2番目の例でいうと、操作以外の認識していないところ
(設定を誰かが変えてたとか)に変更はなかったのか？とか
3番目の例でいうと「こういう操作」以外に行った操作に
エラーを起こす原因はないのかとか

Sentence Correction

これは「コミュニケーションを効率よくとりましょう」
という感じのやつだと思います。
まどろっこしい言い回しとか不明瞭な言い回しとかが選択肢にあって
それらの中から一番わかりやすい言い回しを選んだりするのですが、
プログラミングが正に同じ思考回路を使用します。

プログラミングでは、一つの処理を実現する方法は何通りもあって、
かつ自分の作った製品を未来永劫自分で保守するわけではないので、
いつ新しい人が担当に代わってもいいように
初めて見る人にもその処理の意図がパッとわかるように
書くべきだと言われています。
これは結構難しいことなので、
毎回毎回どうやって書いたらわかりやすいか結構考えますし、
一見どう書いたらベストか答えがないようなものにも
チーム内にコーディング規約というルールを設けて
書き方を統一したりします。
このへんから効率的な文の感覚がついたり、
俗にいうGMAT文法という概念も
コーディング規約みたいなもんだと思えて、
先入観なく取り組めた気がします。

Reading Comprehension

「よくわかんないことがぶわーっと書いてある中から
わかんないなりに必要な情報を素早く見つけて
答えを出しましょう！」
という感じのやつだと思いますが、
これも保守での経験が役に立ちました。

朝寝ぼけ眼で出社すると電話がなって、
とるとコンサルさんが相当テンパった感じで
「超緊急でこのトラブルの原因究明とリカバリをしてくれ」
と声を震わせながら言ってきて、
そっかーじゃあ担当の人につなごっかなーと思ったら
担当の人今日休みみたいなことが
たまにあります。
そういうときに、じゃあ自分が解決するしかないかー、と
全く見たことのない数万行のコードの中から
原因となる処理を見つけてそこから影響範囲を探って
リカバリをする。っていうのがそのまま、
膨大な情報の中のどこに自分が知りたいものがあるかあたりをつけて、
それぞれのパーツが全体の処理に対してどういう意図なのかを考えるっていう
Reading Comprehensionでした。笑

僕は今の仕事以外の仕事をしたことがないので、
他の仕事でも同じようにGMATで問われる能力が使えるのかはわかりませんが、
今までやったことのないタスクにチャレンジする機会に
クリティカルシンキングを意識したり、
今の自分の仕事についてGMAT的要素を考えてみたりすると
GMATもしくはGMAT勉強中の仕事のモチベーションが
ちょっぴり上がるかもしれませんね！
ということを伝えてみようと思いました。笑