こんにちは、まっしゅです。
だいぶオカタイ題名で書き始めてしまいましたが、人との(特に仕事上の)コミュニケーションで苦労することの多くが、このことが原因だと感じています。
サラリーマン仕事をしている方で、
「どうも上司と考え方が合わない」
「部下が何を考えているかわからない」
「後輩が仕事を覚えるのが遅くてイラつく」
「先輩の教え方が悪くてイラつく」
といった、超あるあるなサラリーマンの愚痴を感じている方は、試しに少しお付き合いくださいませ。
最近の仕事でぶつかった壁
エンジニアへのキャリアチェンジ
今まっしゅは、システムエンジニアとして仕事をしているんですが、これまでのキャリアとしては、10年以上「営業職」として仕事をしてきました。
色々なきっかけが重なって、36歳でキャリアチェンジをして、営業からエンジニアに転向しました。
これって、かなりの変化ですよね。
業界に関わらず、「営業」と「技術」って、会社の中で一番仲が悪い関係でしょ笑
営業は
「おれが仕事を取ってこなかったら、
お前らは仕事自体がないんや！」
という自負があるし、
技術は
「モノを作っているのはおれら技術やし！
営業なんて人とうまいこと喋ってるだけやん！」
という自負があるし。
・・・想像で書いてたら、昭和のマンガみたいなセリフになっちゃいましたけど笑
でも、心の中の思いは、だいたいこんな感じですよね。
で、こんな二つの仕事をまたいだキャリアチェンジをしたので、かなり大きな変化です。
転職して一年くらいの間は、ユーザーの要望を聞きだして開発部隊に伝えるという、ビジネスアナリストという役割だったのですが、最近この案件が終わりまして、次の案件からガチの開発に入ることになりました。
システム開発とは
システム開発のプロジェクトは、
①要件定義
②基本設計
③詳細設計
④開発
⑤単体テスト
⑥結合テスト
という順番で進めるんですね。
で、それぞれのフェーズごとに「成果物」というドキュメント(書類)を作成します。
これを、実際に出来上がったシステムと合わせてお客様に「納品」することで、プロジェクトが完了します。
実際に作るモノは、④の開発で作るモノだけですが、それが「ちゃんと作られている」という証明のために、それぞれのフェーズをやって、その証拠となる書類を作るわけです。
初めての経験
で、これまで実際の開発経験がほとんどなかったまっしゅは、これらの段階を経てモノを作ることは初めてです。
(すでにできあがったシステムを理解するためにこれらの書類を読んだことはありましたが、自分で作るのは初めて)
書類に載せる情報は何なのか、それをどこから持ってくるのか、誰に聞くべきか、自分で考えるものか、どうやって考えるのか・・・。
もうわからないことだらけで、正直、相当戸惑いました。
思考パターンのズレ
前置きがだいぶ長くなりましたが、ここからが今日の本題です笑
まずここで登場人物のご紹介。
今の会社で一緒に仕事をしているAさん。
彼はまっしゅと同い年ですが、卒業してからずっとシステム開発の現場で仕事をしてきた、現場たたき上げのシステムエンジニアで、今回のプロジェクトリーダーです。並行で数件の案件を同時にこなす、かなりパワー型のエンジニアです。
前のプロジェクトから一緒に仕事をしていまして、まっしゅがユーザーからヒアリングしてきたことを、彼に伝えてシステムの形にする、という役割分担でやっていたので、とてもスムーズに仕事ができていました。
と同時に、自分とは違う思考パターンをしているなと、当時から薄々感じていました。
なぜか頭に入ってこない！
今のプロジェクトで、新しいソフトを使うことになり、彼からレクチャーを受けているのですが、
どうにもわかりにくいんです。。
情報が少ないわけではなく、また雑というわけでもないのですが、どうも頭に入ってこない。
「おれってこんなに理解力なかったか…？」
と不思議に思うほど。
(割りと人より理解力はある方だと自負してます。)
彼としても、前のプロジェクトでバリバリ仕事をしていたまっしゅが、なぜこんなところで躓いているのかが理解できていない様子。
結局スケジュールがどんどん押してしまい、プロジェクトはだんだんと険悪な雰囲気に。。
形としては、まっしゅが教わる立場なので、なんだかまっしゅが責められるような感じになってしまい、お互いに嫌な気分になっていきました。
帰り道での雑談で…
いよいよ開発に入らなければならない時期に入って、まっしゅも少しずつ理解でき始めてきたものの、まだ実用には耐えられないレベル。
夜遅い時間までレクチャーの時間を取りつつ、明日から彼が出張に行くこともあり、一旦切り上げることに。
オフィスを出て駅までの歩く道すがら、雑談をしている時に、以前に彼が「プログラマ脳」という言葉を使っていたことを思い出して、
「僕がプログラマ脳じゃないから理解しにくいんですかね～」
とぼやいたら、
「今回の案件でやっていただいてる部分は、
プログラマ脳は必要ない部分だと思ってますけどね～」
という答え。
え～そうかなぁ。。
ただ、ここに来て思い当たることがありました。
２種類の思考パターン
彼らプログラマたちを、仮に「理系」として、まっしゅ側の人を「文系」とします。
(実際には違う分け方なのですが、わかりやすくするためにこのまま行きますね笑)
彼ら理系の人たちは、物事を考えたり理解する時に、演繹的な考え方をして、
僕ら文系の人たちは、同じようなことをする時に、帰納的な頭の使い方をします。
ちょっと難しい言葉が出てきましたね。
ロジカルシンキング(論理的思考)の勉強をすると、
必ず出てくるこの「演繹」と「帰納」という言葉。
これだけで1冊本が書けるくらいの内容ですが、ざっくり言うと、
演繹…論理を一つ一つ組み立てて結論を導く考え方
帰納…結論を先に決めてそこから掘り下げていく考え方
という感じです。
算数と国語の勉強の違い
算数の勉強って、一つひとつはよく意味がわからない単純な計算を練習していって、ある時今まで勉強してきたことがつながって、「あー！そういうことね！」と、急に目の前が明るくなる瞬間ってありますよね。
これって、積み上げていく勉強法なので、演繹的と言えます。
対して、国語の勉強をする時は、まず題となる文章全体を読んで、後から部分ごとに問題を解いていきます。
まず全体像を理解するという意味で、これは帰納的な考え方です。
もちろん、算数にも先に結論を決めてから掘り下げていく証明問題があったり、国語にも積み上げて考えなければならないこともありますが、大きな傾向性としては、理解してもらえると思います。
「わかりやすさ」って？？
「わかりやすく説明して！」と言われた時に、その人がどっちの思考パターンが得意かによって、
わかりやすさが違うということなんです。
先ほどのまっしゅの仕事で言えば、まっしゅは帰納的な思考が得意なので、まず全体の概要を理解してから、細かいところを掘り下げていく形で説明してもらえれば理解しやすいのですが、全体が見えない状態で細かい話をされても、ちっとも頭に入って来ないんです。
逆に、演繹的な思考が得意な人に、先に概要から説明しても、多分細かいことがどうなっているのかの方が気になって、頭に入って来ないんだと思います。
その後…
今回、ここまで思い至ったので、仕事を円滑に進めるためにも、改めてまっしゅの特性をお伝えして、
「申し訳ないが、今回のプロジェクトは一度あなたがやるのを横で見させてもらって、
全体の流れを理解させてほしい。その上で細かい部分を理解していって、
次の案件から自分主導で進めさせてほしい。」
と、正直にお伝えしました。
やはりこの思考パターンのずれがあることを認識していなかったようで、今後やり方を改めてもらえることになりました。
自分が理解する時も、人に教える時も、この思考パターンの傾向性を意識するだけで、理解の速さが劇的に変わると思います。
職場のコミュニケーションで悩んでいるサラリーマンの皆さま、すれ違いをしている方と思考パターンがずれていないか、一度考えてみてはいかがでしょうか。
今日は、以上です。
