モチベーションの低い若者に仕事をさせる方法は？

質問

モチベーションの低い若者に仕事をさせる方法は？

システム開発の現場で働いています。
同じチームの他会社の後輩で
簡単な仕事は安請け合いでサクっとやってくれるんですが、
頭を使わないと出来ないような仕事を頼むと
「時間が掛かるからすぐはできない」、「ここまでならできる」などと言って
楽しようとする人なんです。
仕様もこちらが提示しているものが難解だと簡単に変えようとするし
いいプログラムを作る気がない。と思えます。
ネットが繋がらない環境なので調査もしにくいのも原因かとは思いますが、
動作検証中にエラーが出たことを伝えると
「ネットに繋がらないので調べようがない」と言って頑張ろうとしません。
年寄りくさいかもしれませんが、その適当な感じが頭にきます。

彼はこちらが提示したザックリした仕様書をもとに
コーディングしているのですが、どうしてこういう値を出力したいのか？
とか根本的なことを考えていないようです。

彼は新人でもないので、ただのレベルの低い人！と割り切って考えればよいものでしょうか？
簡単なコーディングでしたらメイン作業の合間に自分でもできるのですが、
今の自分の作業は開発そのものではない為、ちょっと本業に支障をきたす恐れがありますが、
その人にブツブツ言われながら作業を依頼するのが我慢できません！
加えてモチベーションの低い適当な人と関わりたくない気持ちです。

何かよい対応方法や気持ちの持ち方についてアドバイスをお願いしますm(＿)m

回答No.1

matumotok · ベストアンサー

こんにちは。

「実力」「限界」といったキーワードをちりばめつつ、「今の条件のもとで、貴方が仕事をした場合にはどこが限界なのかな？」と言って刺激してやると良いかもしれません。もちろんそれで不貞腐れて「やる気をなくした」などというバカもいることでしょうけど、そうゆうバカはもとからそこが限界ですのであきらめましょう。

仕事の出来云々にかかわらず（←ここがとても難しい）、少しでも努力したようならば「ああ、こうゆうやり方があるんだな、すげーわ、面白い、へええ」「おお、君に相談して良かったよ、前向きじゃん、これ、突破口になるかもね、いいよ」と持ち上げましょう、必ず。ダメな出来ならば、決して頭ごなしに叱らずに、「ああ、ご苦労さん」「頑張ったね」と“とても短い言葉で”微笑みかけて終わりましょう。説教されないぶんだけ、“分かる奴には最凶の屈辱として”伝わります。

ポイントは、出来の良い奴を褒める場合には、その若者が発言しだした場合には誰もが口を閉ざしてその若者の発言に注視し、その若者の発言が終了するまでは誰も口を挟まないこと。逆に出来が悪い奴を遠回しに批判する場合には、その若者が発言しだした瞬間に別の話題に切り替えるように即座に割り込みましょう。

お礼

アドバイスありがとうございます。

>もちろんそれで不貞腐れて「やる気をなくした」などというバカもいることでしょうけど、
>そうゆうバカはもとからそこが限界ですのであきらめましょう。
まさしくコレです！
なのでこの人に関しては諦めて関わらないようにすることにしました。

>その若者の発言が終了するまでは誰も口を挟まないこと。
>逆に出来が悪い奴を遠回しに批判する場合には、その若者が発言しだした瞬間に別の話題に
>切り替えるように即座に割り込みましょう。
今後に向けて上記、大変参考になりました。
ありがとうございました。

回答No.3

10ken16

作業指示にあたって、
１．作業の目的
２．工程内における作業の位置づけ
３．何をしたら作業を完了したと見なすか
これを明確にして指示を出せば良いでしょう。

とくに３の項目は、例えば「お客さんがＯＫと言ったら」ではなく、
そのためにはどのような項目をどこまで満足するかを定量的に示す必要があります。

>「時間が掛かるからすぐはできない」、「ここまでならできる」などと言って
これは自分が責任を持って期限内に出来る作業範囲を明確にしているだけかも知れません。
> 楽しようとする人なんです。
これは受け手側の解釈です。

ここで「なぜ出来ないか」を訊いても、相手は批判と受けとるだけでしょう。
何がボトルネックになっていて、どうしたら出来るのかを明確にする。
これは作業指示をするにあたって、常に意識しておくべきことです。

また、発言内容でより発言者で評価や判断を変えるべきではありません。
ガテン系や逆に営業の分野では、内容よりも発言者や言い方が重要になる場合もありますが、
モノづくり、特に質量が存在しないモノを作る仕事にあっては、
まず内容を評価の対象とする姿勢が求められます。

お礼

アドバイスありがとうございます。
以下、１と２については明確でしたが、
３については今回、不明確でした。

　１．作業の目的
　２．工程内における作業の位置づけ
　３．何をしたら作業を完了したと見なすか

単体テストの検証結果を納品する必要があることを明確に伝えていませんでした。
自分がツール作成を依頼されたら検証結果を残すのが当然だと考えていますので
あえて伝えていませんでした。
そこが今回の問題点だったと思います。
人によって認識レベルが違うということを痛感しました。
こういう人が何年もシステム開発の現場で仕事をしている現実が悲しくなります。

結局、その人はＰＧでしかなかったということです。
ＳＥではないので設計ができなくて当然。
ＰＧに多くを求めた自分のミスだと痛感しています。

チーム内でツールを作成できる人は今のところ
この人だけなので困ったものですが
ＳＥになる気が無い人に指導する気にはなれませんので・・
出来る範囲で自分でやっていこうと思います。

回答No.2

gyrocompas

基本的には、相手のやる気とか能力とかは、問題外ですね。
プロの技術屋なら議論すべき問題ではありません。
重要なことは、こちらの要求したことが期限内にできているかどうかです。
そのために仕様書は、「何を」やるかを明確にわかりやすく記述することが大切です。
大まかすぎてもいけませんし、細かすぎてもいけません。
この点はセンスと技術が必要です。
また、テスト仕様書というものも必要です。
どういう事項をテストしてどういう結果にならなければならないかを
明記しなければなりません。（箇条書きの羅列でも結構）
テスト仕様書はプログラムを検収する場合
検収するか否かの論拠になるので、必ず作成する必要があります。
また。テスト環境ですが、どちらが構築するのか、その費用はどうするか、きめなければいけません。
ソフトのみの発注の場合、通常、テスト環境は発注側で構築します。
ネットテスト環境が使えない状態で、ネット通信のプログラムを発注するのは非常識です。
以上のようなことが最低限できない限り、ソフトウェアの開発を外部に依頼すべきでは
ありません。

友達感覚で仕事を頼んで、できなかったからと言って、
あいつはやる気がないと発言するのは、そもそもの仕事に対する真摯さや、責任感、
を疑います。
ただ、単に、他人を便利使いしたいだけなのかと思われまっせ。

お礼

アドバイスありがとうございます。

記載不足でしたが、この問題児はチーム内で「ツール担当」のような役回りになっています。
つまりチーム内でのザックリした要望を元にツールを作ってテストするのが仕事です。
なので通常の発注とは訳が違います。

製造していく中で当然、仕様に関して不明点も出てくると思います。
それは確認しながら作業を進めるのが普通です。
この「普通」の認識が不足していたようです。
注意を促してもやらない(できない)ようなので
それがこの人の限界なのだと判断しました。