"コロナ禍以降に新卒入社した社員のコミュニケーション力" に愚痴をこぼすミドルクラスのITエンジニアへ
たしかに新卒エンジニアにも改善点はある
2020年4月入社の新卒社会人をコロナ禍第一世代と定義しよう。
2020年入社の新卒については、在学中はまだコロナの影響をほぼ受けずに過ごすことができたこともあってか、 "コロナ禍ゆえのコミュニケーション不足" という話はあまり聞かない。 一方で、2021年入社、2022年入社……と年を経るごとに、 "コロナ禍でコミュニケーション能力が低くなってしまったのではないか" と評される人が増えてきた印象がある。
たしかに、コロナの流行により、コミュニケーション能力を鍛える機会は減ってしまった。 これは、オンライン中心のコミュニケーションを余儀なくされたことで、良くも悪くも、コミュニケーション形態が大きく変わったことが原因だ。
まずはテキストのみの非同期コミュニケーションから始まり、テキストのみでは厳しい場合に音声を使った同期コミュニケーションを行う。 そして、最終手段として、映像を使う（＝顔出しする）コミュニケーションの選択肢があがってくる。
このような変化により、コミュニケーション時に受け取ることができたり、伝える必要があったりする情報量が激減してしまった。 さらに、そもそもコミュニケーション頻度も激減した。 そのため、コロナ禍以前よりコミュニケーション能力が衰えてしまうのは致し方ない。
筋力と同じく、コミュニケーション能力も一定の負荷をかけなければ（＝同時に処理する情報量を増やしたり頻度を増やしたりしないと）、鍛えることはできない。
コロナ禍以降の新卒エンジニアには申し訳ないが、"コロナ禍でコミュニケーション能力が低くなってしまった" という主張は少なからず正だと考える。
他責思考になってはいけない
しかし、本記事は新卒エンジニアに問題があるということを主張したいわけではないし、そもそも対象読者はミドルクラスのエンジニアである。
もしかしたら、ジュニアクラスのエンジニアも対象に含まれるかもしれないが…… 本記事を2025年に執筆したことを加味すると、表題のような愚痴をこぼす人はコロナ禍以前入社であるため、少なくとも5年以上の実務経験を持っているはずである。 5年も経てばジュニアクラスは卒業し、ミドルクラスまで辿り着いている人が大半だろう。 一部、優秀な人はシニアクラスまで辿りついていると思うが、シニアクラスの人の口からはこういった愚痴を聞かない。 （編集注記: 唐突に強い偏見で失礼）
本題に戻り、なぜ "他責思考" が関係してくるのだろう。 このような愚痴をこぼす背景には、次のような主張が垣間見えるからだ。 "新卒エンジニアのコミュニケーション能力が低い。それは、彼ら彼女らがコロナ禍でコミュニケーション能力を鍛える場が少なかったことが要因である。"
先に述べた通り、この主張自体は正論だと考えている。 しかし、 "そのせいで、新卒エンジニアとはコミュニケーションが取りにくい" と結論付けてしまう人の存在が問題である。
これは教育を放棄した人の思考だ。 そもそも、新卒エンジニアは "新卒" という修飾がつく通り、社会人としては未経験である。 それなりの社会人経験年数を持つミドルエンジニアが求める "コミュニケーション能力" をはじめから持っているのは、百人に一人くらいだろう。 （編集注記: これは過小評価かも）
"社会人として、エンジニアとして、仕事を進めるうえでこういったコミュニケーション能力が必要です" ということをミドルエンジニア側から伝えてあげる必要がある。 期待値を提示してあげることで、あなたの会社に新卒入社できるレベルの人間であれば、大なり小なり応える姿勢は見せるだろう。
それでも、はじめはどうしても期待値とズレてしまう。 そういった際には、ミドルエンジニア側から積極的にフィードバックしてあげることが大切だ。 "社会人／エンジニアとして必要なコミュニケーション能力" が十分に備わっていない段階なので、新卒エンジニア側からフィードバックを求められることを待っていてはいけない。 彼ら彼女らは、まだ "自らフィードバックをもらいにいく" ことに慣れていないのだから。
ジュニアクラスとミドルクラス間の大きなギャップのひとつに、主体性がある。
ジュニアクラスには "与えられた仕事を、サポートを受けながらこなす" ことが第一に求められる。 初期段階は "仕事は与えられるもので、サポートは受けられるもの" と考えているだろう。 その段階から徐々に "仕事は自ら取りに行くもので、サポートは積極的にもらいにいくもの" という思考になってもらう必要がある。
さらにその次の段階として "求められたら、他人のサポートをする" 場面が出てくる。 ここまでくれば、もうミドルクラス目前だ。
ミドルクラスの視点に戻ると、つまるところ "自ら、他人のサポートをする" ことが求めらている。
念のため "なぜ私がそこまで面倒を見なければならないのか" と考える人向けに。
一般的に、ミドルクラスのエンジニアには小規模なプロジェクトを率いる能力を求められる。 プロジェクトを動かすためには、多かれ少なかれメンバーの手助けが必要であり、メンバーを持つということは後輩教育の必要性に直面することを意味する。
また、小規模プロジェクトとはいえ、事業影響のある成果を創出する必要がある。 成果を出す（＝リターンを得る）ためには、一定の責任（＝リスク）を追う必要があり、これは他責思考の下では実現できない。 いわゆる自責思考が必要となってくる。
これらを理解せず、社会人経験年数のおかげで、自然とジュニアからミドルになってしまった人には、こういった能力が欠けていることが多い。 そうなると、表題のような愚痴を自然と口にしてしまうのであろう。
他人の問題点を "当人のせいである" というところで思考を止めずに、 "問題があるならば、どうやって解決しようか" と一緒に考えていきたい。
そもそもコロナ禍に限らない問題なのでは
（繰り返しにはなるが、） たしかにコロナ禍によって、新卒入社時点の "社会人／エンジニアとして必要なコミュニケーション能力" が不足していることは事実であろう。 それが故に、今までは不要だった、従来では "常識" と考えられていたレベルのコミュニケーションについて、ミドルエンジニアが教える必要性が生じていることもまた事実かと。
とはいえ、これは "コロナ禍が諸悪の根源" とはいえないのではないだろうか？
これまでも、時代の変遷とともに教育方法は随時更新されてきたはずだ。 例えば、昔は教育係が大声で怒鳴ったりぶん殴ったりすることが（なぜか）許されていた時代があった。 しかし、世の中がパワハラやセクハラに厳しくなり、このような "指導" 方法は消えていった。 その時代の変わり目では、 "今の若者は根性がない" と愚痴をこぼす人も散見された。
（編集注記: まあ、筆者はその時代の社会人ではないため、想像で書いているだけなのだが……）
つまり、何を述べたいかというと、 "自分の頃はこうだった。だから、お前たちもこうあるべきだ" という思考は成り立たない。 もちろん、先例に習うことも大切だが、時代に合わせて改善していく必要性がある。 現状維持は停滞だ。
あとがき
自分で考えた改善案を実践し、失敗するかもしれない。 失敗したら、自分の責任になってしまう。 そうなるとツラい……
それは、そう。
失敗しないために、失敗する確率を減らすために、成功する可能性を高めるために、日々粛々と学び続けることが大切だなあと。
あとがきのあとがき
こういう記事、いわゆるポエムを書いていると、 "そういうお前はどうなんだ" というセルフマサカリ？ブーメラン？がぶっ刺さる…… 精神を削りながらポエムを書き連ねている……
「言い方がキツイ人」にならないために
「言い方がキツイ人」は、いったい何を考えているのか。 | Books&Apps
を読んだ。
"言い方がキツイ人" を "言葉選びが下手な人" とオブラートに包む表現から優しさを感じた。
さらに、 "相手の受け取り方が悪いだけで自分に非はないという考え方をしている人" という言語化も言い得て妙である。
このような人はコミュニケーション相手から悪い印象を持たれる場面がどうしても多くなってしまうため、 "自分の意図が正しく伝わるように言葉を選ぶ意識を持つ" のが良いとの提案もしている。
共感を呼ぶような良い記事である。
"言い方がキツイ人" の属性をもう少し深堀りしてみよう
該当記事を読み「うわ。こういう人いるわ……」という感想を抱いた人は多いのではないだろうか？
そして同時に、無意識的に「自分は "言い方がキツイ人" ではないな」とも。
もし、記事を読んで感じたこと・考えたことが以上なのであれば、少し注意が必要だ。 なぜなら、ここで思考をやめてしまう人は "言い方がキツイ人" 予備軍 であるからだ。
もし、 "言い方がキツイ人" ＝ "「自分は正しい。相手が悪い」と考えている人" という理解をしているならば、もう一歩踏み込んで考えたほうが良い。
そもそも、（意識的・無意識的に限らず）「自分は正しい。相手が悪い」 と考えながらコミュニケーションをとっている人はかなり少数派だろう。
しかし、 "言い方がキツイ人" はそれなりの頻度で見かける。
なぜか？
それは、以下のどちらか一方でも当てはまれば、 "言い方がキツイ人" になり得るからだ。
- 「正しい／正しくない」「間違っている／間違っていない」という白黒つけたがりタイプ
- 「悪い／悪くない」「誰それの責任だ」という他責思考型タイプ
"白黒つけたがりタイプ" かつ "他責思考型タイプ" の人だけが "言い方がキツイ人" なのではない。
"白黒つけたがりタイプ" もしくは "他責思考型タイプ" のどちらか一方であっても、 "言い方がキツイ人" となるリスクが高いのである。
具体例があると伝わりやすいので、元記事の例を引用する。 （読みやすさのために話者を明記しています）
Bさん「Aさんって、沖縄出身だったよね？」
Aさん「いや、ちがうけど」
B「あれ、沖縄って言ってたと思ったんだけどな」
A「いやいや、沖縄出身なんて一切言ってないし」
B「あー、ごめん。言ってたと思ったんだけど、だれかと勘違いしたのかも」
A「思い込みじゃない？ 俺は絶対に言ってない」
B「あ、はい」
この会話におけるAさんは、たしかに「自分の言い分は正しい。自分は間違っていない」と考えているだろう。
（自身の出身地なので、正しいのはそれはそう）
しかし、ここでAさんは「相手が悪い」とまでわざわざ思考を巡らせるだろうか？ （「相手が悪い」とまで感じるだろうか？）
このケースにおけるAさんは、 "白黒つけたがりタイプ" であるが、 "他責思考型タイプ" ではないだろう。 それでも、 "言い方がキツイ人" とみられてしまっている。
……別の例をみてみる。 （こちらも元記事を少し読みやすくして引用しています）
（世間）「ヘルプマークをつけているのに席を譲ってくれなかった」というツイートがバズり、SNSでヘルプマークを浸透させようという動きが活発化していた
記者「（いくつかの理由から、）ヘルプマークなんかなくとも、コミュニケーションを取れば席の譲り合いはいくらでもできるじゃないか。」
読者A「精神疾患で自分から他人に話しかけられない人もいるのにひどい」
読者B「病状をオープンにしたくない人の気持ちがわからないのか」
記者「いやだから、あなたにそういう事情があるのと同じように、席に座ってる人だって席を譲りたくない事情があるかもしれないって言ってんじゃん！ でもそんなの会話しないとわかんないよねって話をしてるの！ ちゃんと読めよ！」
このケースでは記者が "言い方がキツイ人" である。
この記者は「正しい。正しくない。間違っている」という "白黒つけたがりタイプ" の思考をしているようには思えない。
どちらかというと「こういう可能性もあるよ。こういう考え方もあるよね」という主張をしているので、 "白黒つけたがりタイプ" とは言いにくい。
（記者の意図とかけ離れてたら申し訳ない。読解力が低すぎたことにしてくれ）
しかし、ここで記者は「批判されたけど私は悪くない。批判してきた人が悪い。しっかり記事を理解できない人が悪い」という、 まさに "他責思考型タイプ" の考え方をしている。
つまり……？
"自分の意図が正しく伝わるように言葉を選ぶ意識を持つ" ことは、 "言い方がキツイ人" にならないための必要条件であっても十分条件ではない。
「正しい」「間違っている」とすぐに結論づけたがる "白黒つけたがりタイプ" の思考に陥らないよう気をつける。
「自分は悪くない」「相手の責任だ」とすぐに責任の所在を明らかにしたがる、 "他責思考型タイプ" の思考に陥らないよう気をつける。
こういった意識も持って日々生きていくことが大切なんだろうなあ
「UIの色を変えただけで大量のクレームを頂戴してしまった話」とその炎上から学べること
なぜ炎上してしまったのか・炎上しないために必要だったこと
話題の記事は ユーザを批判している ように読み取れる文章となってしまっていたため、広範囲に火が燃え上がってしまった。
炎上商法なのであれば完成度の高い記事ではあるが、おそらく違うだろう。
該当記事が炎上しないために必要だったことは、 「褒めるときは "ヒト" を。叱るときは "モノ" を。」 の精神。
（本記事も該当記事の作者を批判しているのでは？というツッコミはさておき。）
ユーザを悪者にしていなければ、もう少し火の勢いを抑えることができただろう。
また、 想定読者（誰が読むのか、誰に読んでほしいのか）を捉え違えた のも炎上の一因であろう。
正直なところ、記事中のSaaSプロダクトを開発していた社内に閉じた文章であれば、そこまで悪くないものである。
記事内で触れられているように、（正しかったかはさておき）しっかり段取りした上でリリースしたものの、ちゃぶ台返しされてしまう事態が発生したようだ。
そのような状況下にあるPdMやエンジニアのメンタルを加味すると、該当記事は「自分たちがやっていたことは間違っていなかったんだ！」と背中を押してくれる内容になっており、彼らの精神を回復してくれる良い材料だ。
……そういった意味では、該当記事の作者も諸々の開発やユーザ対応が落ち着き、冷静に振り返れる状態になってから記事を公開すべきだったのかもしれない。
（すでに冷静な状態で執筆・公開したのかもしれないが）
炎上したからこそ得られた学び
ここから先は（ここから先も）個人の感想強め。
今回はエンジニア界隈、デザイナー界隈ないしはIT界隈で燃え上がったということもあり、感情的な批判だけではなく有益情報を添えたコメントが多く見受けられた。
- クレームとフィードバックの違い
- 健全なユーザ向き合いとは何か
- 色に関するデザインの知識
- ドメイン知識の大切さ
こういった学びが得られたのは傍観者として良かった。
（本記事を書いている時点でもはや傍観者ではないが）
クレームとフィードバックの違い
健全なユーザ向き合いとは何か
極論、ユーザ様からの問い合わせは基本的にプロダクトへのフィードバック、つまり価値向上に繋がる可能性の塊と捉えて良いのでは！？
to Cはわからないけど、to Bであればそもそもクレーム割合少なそう。（偏見）
少なくとも、ユーザには真摯に向き合いましょう。
というか、ユーザ以外にもPdMに対してもエンジニアに対しても、それこそデザイナーに対しても、みんな仲良くしよう！
（求む！平和な世界！）
あと、「時間が解決してくれるさ」の精神は問題に向き合っていないだけ、というド正論パンチが飛んでくることを知ったので、ビジネス場面では気をつけたい。
（私生活の問題は時間が解決してくれ）
色に関するデザインの知識
色覚特性や色、コントラストについて学ぼうぜ！というコメントがあり、なるほどとなった。
そもそも件の仕様変更のモチベーションが「見やすくしようぜ！」で、それに必要な知識が色々なコメントから得られたのは良かった。
なお、何が正しいのかわからないのでここではまとめない。
（本音：本記事書くの飽きてきた）
ドメイン知識の大切さ
該当記事では「Googleカレンダーで採用されているからこのプロダクトでも同様の仕様が正しい」と主張していますが、ユースケースもしくはプロダクトの利用環境を想定しきれていないように感じる。
ユーザはデスクワーカーではなく、物流センターで働く人。
物流センターについてもっと詳しければ、その環境下で使いやすいプロダクト作りにより貢献できただろう。
今回の事例でいうと、オフィス内ではなく自然光が入り込む場所での使用を想定した色合い、を初めから考えることができた……かもしれない。
と思ったけど、事前のユーザヒアリングでもドメイン知識は蓄えられているので、今回の事態を防ぐならば実際に現場に赴くしかなかったのかな。
この辺は予算や時間の都合もあるから理想論。
参考情報
"話題の記事" はこちら。
上記記事を分析した記事もおもしろかったので。
Slackに既読機能は存在しない
SlackにはLINEのような既読機能は存在しない。
「自分」はメッセージを読んだかどうか把握することができる。
しかし、「相手」は送ったメッセージを読んでくれたかどうか把握する術がない。
正確には、返信をもらうか、送ってくれたメッセージに絵文字スタンプでのリアクションをもらえば既読されたことを把握できる。
つまり、メッセージの受信者が能動的に「既読」をアピールしない限り、送信者は送ったメッセージが読まれたのかどうかわからない状態に陥る。
状況が不明というのはしばしば生産性の悪化に繋がる。
「自分が確認依頼を投げたメッセージを相手がしっかり確認してくれているかどうか不安である」状態で作業をしても、そのことが常に頭をよぎって十分に集中できない。
一方、返信したり絵文字リアクションをつけたりすると、そのことに満足してメッセージで依頼された内容の対応を忘れてしまう、という受信者の主張もあるだろう。
そういったタイプの人は、Slackの機能を活用してほしいものだ。
オススメなのはブックマーク機能だ。
とりあえず、Slackで何かしらの依頼が飛んできたら、全てブックマーク登録してしまえば良い。
ブックマークしたものを一覧で確認したり対応完了状態にしたりと、TODOリストのようなノリで使うことができる。
もしくは、いっそのこと未読状態に戻してしまうのもひとつの作戦だ。
こちらは、アプリの通知バッチでも未読数が把握できるので、対応必要なメッセージが何件残っているのかがよりわかりやすい。
他にも自分自身のDMにメッセージのURLを貼って管理したり、Slack外部のTODOアプリで管理したりと、色々な対策が考えられる。
メッセージ送信者のためを想い、Slackでメッセージを受信した際には何かしらのリアクションをしよう。
技術ブログにおける「ポエム」もしくは「自分語り」のリスクを理解しておこうという話
前略
ITエンジニアによる「ポエム」「自分語り」記事は度々ネットの世界で話題になる。
良くも悪くも。だ。
一時期、Qiitaにおけるポエム記事投稿の是非を問う論争があった。
「ポエム」という名の「自分の考えを主張する文章」を技術ブログに公開すると、様々なマサカリが飛んでくる。
ポエムではない正統派の技術ブログに対してもマサカリがわんさか飛んでくる界隈だから仕方ないのかもしれない。
一方、ポエム記事はバズりやすい傾向にある。
第一に、読者目線では読んでいて面白いし、共感できる内容があると尚のこと他人に勧めたり、ポエム記事を引用してさらに自分語りに繋げたりできてしまう。
執筆者目線では、実体験ベースの話だったり、自分の考えだったりを書くため、ネタに困らなく書きやすい。
しかも、先に述べた通りバズりやすいので、書いていて気持ち良い。
ただし、ポエム記事には相応のリスクがあることを念頭に置きたい。
自分の考えを語る記事であるため、それはつまり本人の性格、人柄が記事から把握しやすいということを意味する。
そもそも「エンジニアは技術ブログで記事を書こう」という風潮の発端は、就職活動のアピール題材に使えることや、セルフブランディングのためである。
……聖人君主的思考の持ち主はそんなことないかもしれないが。
例えば、ポエム記事が載っている技術ブログを就職先にアピール題材として提出した際、その人がどのような人物なのか採用企業は把握できてしまう。
このこと事態は全く以て問題ではないし、むしろ想定の範疇である。
しかし、バズることしか目的としないポエム記事がそのブログ内に含まれていたらどうだろうか？
感情のままに書いた記事が含まれていたらどうだろうか？
採用企業に良い印象を与えるとは考えにくい。
如何せん、世の中に溢れているポエム記事にはネガティブな内容を含むものが多くて仕方ない。
そういった記事を出すのは一向に構わないし、そういった記事から学べることも多い。
ただ、執筆時のリスクを考慮すると、匿名性の低いアカウントでの公開はもっと慎重になったほうが良いのではないだろうか。
……と、このように考えているため、わたしはこのブログでポエム記事や自分語りをしていこうと思う。
果たしてこのアカウントの匿名性が高いといえるのかどうかは不明だが。
初投稿なのでさくっとブログの方針を書くだけに留める予定が、早速まとまりのない怪文書を生み出してしまった。
早々
