文系プログラマによるTIPSブログ

文系プログラマ脳の私が開発現場で学んだ事やプログラミングのTIPSをまとめています。

仕事が遅い人とどう向き合うか

会社に仕事が遅い人がいる場合、いろいろ戸惑う事や困る事がありますね。今回は仕事が遅い人とどう向き合っていくか、考えてみたいと思います。


f:id:treeapps:20180418122452p:plain

こんな記事があったので、自分が実際仕事が遅い人と対峙して、どう思って、どうしたらいいか、色々思うことがあるので思いを連ねてみようと思います。

※ 実話+フィクションの混合です

どのように遅いか

喋るのが遅い

仕事が遅いAさんという人がいるとします。

Aさんはまず、喋るスピードが遅い。とにかく遅い。

普通の人の半分くらいのペースで喋ります。多分年齢は関係無く、元々こういう喋り方なのだろうと思います。

話の内容が定まっていない

仕事以外の会話ならいいのですが、Aさんはスローな会話で、話の内容が的を得ていないうえ、噛み噛み。

話が長い

もうとにかく話が長く、必ず脇道にそれてしまいます。

話の切り時が解っていない

スローペースで会話を初めるが、話の切り時が解っていないAさん。周りの空気が「そろそろ雑談を終わらせて仕事はじめようぜ」となっているのに気づかず、スローペースで延々話し続けてしまい、周りの空気が悪化してしまう。

全て自分でやろうとして時間切れ

仕事をしていてある部分に嵌ってしまい、中々進まなくなってしまう事ってありますよね。しかしAさんは周りに聞こうとせず、自分の力だけで解決しようとし、結局時間切れで全然進める事ができず、怒られてしまう。

コーディングが遅い

Aさんは驚くほどコーディングが遅い。私が「これなら2時間くらいで終わるかな〜」と予想してタスクをふっても、軽く3倍はかかってしまううえ、結局作りきれずに終わる。

物忘れが激しい

「このタスクは大体◯時間程度のタスクなので、それを目標にお願いします」と言っても、仕事に集中するとそれを忘れてしまい、時間切れに気づいていない。

自分は何故Aさんの仕事が遅いと思うのか

私はAさんと接して、何故遅いと感じてしまうのか。

自分の作業スピードと比較してしまう

自分は仕事に慣れているから速い。一方Aさんは今回初めて来る派遣さん。遅いのは当然なのです。

他の派遣さんの作業スピードと比較してしまう

プロパーにかぎらず、派遣社員もピンキリです。

自分と仕事の仕方が違う

私は日中はギリギリまで集中し、雑談も程々にして生産性を重視し、なるべくチーム全員定時に帰宅できるよう努力するタイプです。そして「残業する人は仕事の仕方に問題があるからしている」と考えるタイプの人間です。

しかしAさんはそういう考えではなく、和気あいあいと残業しながらのんびり仕事がしたいのかもしれない。

経歴に対して過剰な期待を寄せてしまう

履歴書を見て、「お、中々いい感じじゃないか。これなら結構いけそうだ!」と、期待し過ぎてしまう。この期待が少しでも裏切られると、期待がありえない程地に落ちてしまう。期待が大きいと反動も大きいのですよね。

Aさんとどう向き合うか

自分が今どういう状況なのかを認識させる

JIRAやredmine等でタスクを設定し、期限やタスク量を把握させます。現実を目の当たりにすると、自分がどういう状況なのかが把握できる筈。

もの忘れが激しい事への対応

JIRAやredmine等で記録して、そもそも覚えておく必要がない状態を作る事が好ましいですね。

例えば、「窓を開けた人は、開けた人が帰宅時に閉めて帰りましょう」というルールがあった場合、結構忘れる人がいます。redmineに書こうが、毎日自動でメールを送ろうが、忘れてしまう事は絶対にあるので、面倒ですが根気よく伝えていって習慣づけさせるしかないかな、と私は思っています。

はっきり「話長いよ」と伝える

真顔で言ってしまうと心証が悪くなる事必至なので、「話長いですよ〜♪」と茶化すように笑顔をみせつつ伝える。もしかしたら誰も話が長い事を指摘してくれないから、気づいていないのかもしれませんね。

叱っても意味はない

私は遅い事に対して叱っても、何の意味もないと思っています。それどころか悪化する事すらあるのではないでしょうか。

これはバグを発生させてしまった人に対しても同様で、バグを出した人を叱っても、怒られただけで終わってしまう。

叱るのではなく、どうすれば改善できるかを一緒に考え、改善策を実施していくべきでしょう。

力加減を最初に伝えておく

例えば不明点があってプロパーに質問する場合、「チッ!そんな事自分で考えろよ!」と言われる事を恐れている可能性があり、中々質問できない可能性があります。他にも、加減を探ろうとして話が長くなってしまったり、なんだか話の趣旨が不明な話題になってしまっている可能性があります。

なので、最初に「この会社は全然そんな感じじゃないですよ〜むしろ何も聞いてくれない方が困ります〜」という感じに伝えておけば、安心できるでしょう。

私もどこまで質問していいか等の加減を知るのに時間がかかるタイプなので、最初に加減を教えるのは有効かと思います。

孤立させない

空気が悪くなると、自然とその人を孤立させて退場させようとする力が働きがちです。

しかしこうなってしまうともう手が付けれなくなる可能性があるので、孤立させないよう、なるべくチームで協力させるよう導く必要がありそうです。

色々なタイプの人がいる事を認識する

全員が全員、テンポよく要領よく喋るわけではありませんね。

皆が仕事が速い訳ではなく、向き不向きもあります。

これが、頭では解っているつもりでも、いざ当人を目の当たりにすると、耐えられないかもしれません。

それに対して不平不満を言っても何も解決しないので、「そういう人もいる」という前提で考えておくと、自分がイライラしたり強くあたってしまう事も少なくなるでしょう。

本当ならそういう人を含まない最強チームを構築する事が好ましいですが、世の中そう上手くはいかないもので、スキルの高い人・低い人混在で仕事を成し遂げなくてはいけません。

雑感

例えば「ここが駄目!」と言うよりも「こうしたら楽ですよ」と言った方が明らかに場の空気がよくなります。如何にしてマイナスの言葉を避けてプラスの方向に持っていけるかが重要ですね。しかし解っていても「ぐぬぬぬ・・・!」とイラッとしてしまう事が多いです。こうなってしまうのは私がまだまだ子供だからでしょう・・・所謂「器が小さい」とかそういう事ですね。。。

今まで色々な派遣さんを見てきましたが、力加減が把握できていないが故、能力を発揮できていないケースが結構有った気がします。どこまで言ってしまっていいんだろう?この人にこういう事聞いていいのかな?等の加減が解り始めると、急に力を発揮しだす人が結構いたので、その辺が重要だなあと個人的に思っています。なので、新規参入者には序盤はその辺の加減を覚えて貰う事に徹した方がいいかもしれません。

あと、履歴書に書いてる事って結構当てにならないなあ、と思いました。経歴を見て「おお、いいね!」と思っても、「あれ?マジでこれ知らない(解らない)の?経験あるよね???」と思う事も多々有ります。そういう事が結構あるもんだから、面談時に実際にコードを書かせるのって重要だなあ、と思いました。

しかし面談を通過していざ一緒に仕事をしてみると、リファレンス通りの書き方、定番の書き方を知らない人が以外な程多く、「何そのフリーダムな書き方は!?」とびっくりするようなコードを描く人もいます。リファレンスに書いてるサンプルコードと自分のコードが全然違う事に対してなんとも思わないのかなあ。そういう人って、どうしてそんな風になってしまったのか、経緯が気になります。