突然ですが、みなさんはほめられていますでしょうか？
また、周りの人をほめていますでしょうか？
仕事上では、指摘をすることが多くなっていないでしょうか？
そして、良くするための改善点のみを口にするようになっていませんか？

いきなり質問ばかりですみません。今回お話したいのは、議論や課題解決には直結しないものの、プロジェクトを進めるうえでは欠かせない「ほめる」ことについてです。

モチベーションを上げるため、人材を育てるために「ほめる」ということが重要なのはわかっている。ほめるテクニックのようなビジネス本を読んで知識も得ている。しかし、自分がうまくほめることができているのかわからない。

そんな方にはぜひ読んでいただきたい内容です。

プロジェクトはどこまで行っても人間同士で仕事を進めます。
そのため、仕事上の人間関係はとても重要になります。
評価されるとうれしい、認められると次も動きたくなる。
一方で、ズレると関係性も成果も同時に削られます。
これは、機械には発生し得ないパフォーマンスの上振れと下振れともいえるでしょう。

変動があることは悪いことととらえがちですが、上振れる分にこしたことはありません。プロジェクトメンバー皆がモチベーション高く、自分の仕事のパフォーマンスを最大限に発揮できるのであればこれほど嬉しいことはありませんよね。

もし、「自分は効率を重視して、仕事を進めるうえで意味がないから、ほめても何もかわらない」と考えているようならば、ドライに「ほめる＝プロジェクトを前に進めるための燃料」と考えてみてください。

どんなふうにほめて、指摘をすればよいかのヒントになれば嬉しいです。

株式会社office Root（オフィスルート）
代表取締役社長
甲州　潤（こうしゅうじゅん）

国立高専卒業後、ソフトウェア開発企業でSEとして一連の開発業務を経験し、フリーランスに転身。国内大手SI企業の大規模プロジェクトに多数参画し、優秀な人材がいても開発が失敗することに疑問を抱く。PMOとして活動を開始し、多数プロジェクトを成功へ導く。企業との協業も増加し、2020年に法人化。さまざまな企業課題と向き合う日々。著書『DX時代の最強PMOになる方法』（‎ビジネス教育出版社）

「ほめられているのにムカッとする」現場

こんな会話、聞いたことはありませんか。

「マニュアル通りにリリース作業ができてて偉いですね」
「Jiraのチケット、ちゃんと更新しててすごいですね」

これがもし、配属されたばかりの新人研修中のメンバーにかけられる言葉であれば良いと思います。

しかし、数々の修羅場をくぐってきたシニアエンジニアにかけられた言葉だったらどうでしょう？
言われた側の頭の中は、大抵こうです。

「いや、それは当たり前にやってきたことだし……」
「今さらそれをほめるって、私をどのレベルで見てるの？」

これは、言われた側は
　「歯磨きできて偉いですね」
　「朝起きて出社して偉いですね」
くらいのほめ言葉に聞こえています。

ほめている側は、皮肉ではなく本気でほめているつもりでも、環境や状況を考慮せずにほめられると「バカにされてるのでは」と深読みされてしまうのです。

別のパターンもあります。「依頼していた内容を確認しました。いつもありがとうございます。」

この文だけを見ると何も問題ないように見えます。
そして、この文には何も問題はありません。

しかし、この文＜だけ＞がいつも必ず一字一句同じ文章が送られてくる状況だとしたらどうでしょう？

「ショートカットで呼び出して定型文送ってるな」
「中身ホントは見てないんじゃない？」

と感じてしまいます。

「成果を確認し、感謝を伝える」文章にすると簡単なことですが、何か月も一緒に仕事をする関係性では、これを継続することが難しかったりします。ただただ定型文でほめるだけでは、むしろ逆効果で終わることが多いのです。

相手を見ていないからほめ言葉がズレる

ほめる言葉がテンプレに寄っている。 「この言葉を言っておけば動くだろう」と、相手のスキルや仕事の難易度や文脈を見ずに並べている。

私が鍵だと感じているのは、ここです。相手を観察し、その人なりの信念や意図まで拾えていないと、ほめのポイントは必ずズレます。

例えば「いつも挨拶が元気ですね」だけだと、何となく雑に聞こえがちです。でも、続けてこう聞くことができたらどうでしょう？

「会議で話しかけやすくするために、意識してやってるんですか？」
「そういうふうにするようになったきっかけはありますか？」

ここまで行くと、相手は質問してきた人の文脈に沿って話し始めます。相手のことをしっかり見て、会話のキャッチボールの末に「その行動はすごいと思います」と言えたとき、初めてほめ言葉として届くのです。

ルールで「ありがとう」が増えると、なおさら空っぽに

崩壊していると感じるチームには、もう一段ひどいパターンがあります。例えばサンキューカードのように、社内で感謝を伝え合う制度が「月に何枚出す」などノルマ化されている場合です。

はじめのうちは楽しくやっていても、しばらくすると気づくはずです。「これは本当に私への感謝ではなく、枚数合戦のためのカードだ」と。

文句だらけの現場で、強制的に感謝の言葉を交わし合うのは一定の意味はあるかもしれません。ただ、心にもない「ありがとう」を続けるルールほど、長くは持たないことが多いです。ほめることを押し付けると、チームには重圧だけが残ってしまうのです。

ただはじめは、社内に浸透させるためにノルマ的に進めるのもよいでしょう。ですが、当たり前にそれができるようになったら、ノルマをやめて中身にフォーカスして質を高めるようにしていくのが良いと思います。

より具体的に、何に感謝しているのかを見ることができるようになるとより効果が出てきます。

指摘が刺さらないのは、自分のやり方を相手に押し付けているだけだから

良い点をほめることは重要ですが、ほめてばかりではプロジェクトは前に進みません。その一方で、改善が必要な点への指摘は、プロジェクトをスムーズに進めるために欠かせないプロセスです。

しかし、指摘は、ほんの少し使い方を間違えただけでハラスメントのリスクに直結します。私が現場で実践している指摘の提示順序は以下の通りです。

「ここが間違っている」「こうすべきだ」を先に提示すると、相手は自分のやり方ごと否定されたと受け取りやすくなります。仕事の一部に対する指摘が、その人の人格への攻撃として認識される可能性さえあるのです。

ここで、極めて重要となるのが、メンバーの動機付けが個々人で異なるということです。キャリアアップのために経験を積みたいと考えるメンバーと、割り当てられたタスクを忠実に完了させることを重視するメンバーとでは、同じ言葉でもその有効性が変わってきます。

「一緒に頑張ろう」「これは成長のチャンスだ」といったメッセージを投げる前に、そのメンバーが何に興味があり、何をトリガーポイントとして動くのかを把握できているかが勝負です。この「事前調査」をスキップすると、たとえ正論であっても、現場では期待通りの効果を得られず、空振りに終わります。

緊張した対立をどうほどくかがPMOとして入った時の腕のみせどころ

「ここ、全然できてませんよね」
「すみませんでした。すぐに作業します。」
「こっちはどうするんですか？」
「それは終わったあとにやります。」
「それじゃぁ間に合いませんよね？」
「・・・・」

会議で空気が凍る場面は、どの現場にもあります。周りは見ているだけ、聞いているだけでどのようにしたらよいかわからず、さらに場が凍りつくなんてことを経験したことは無いでしょうか？

こんな場面でいきなり口出しするのは容易なことではありませんが、私の場合、意見が言えそうだなと思ったときは、まず火種を人に固定しないことから入ります。

「優先して片づけていたことがこちらにありましたよね」
「ここまではできているので、言うほどダメではないような気がします。」
「できていない部分は、その人の怠慢というより、仕組みが説明不足なのではないですかね？」

事実ベースで「人に対する指摘ではなくそもそもの認識ズレ、仕組みができていない」というように切り出すと、対話の幅が戻ります。正しさで殴るのではなく、一緒に協力して仕事に取り組めるよう次の一歩にエネルギーを向け直すように促すのが重要です。

見えない作業に目を向けて成長を促す方法

テンプレート的にほめても意味がない。ストレートに指摘するとパワハラになる。
じゃぁどうしたら良いんだ？
そう思ったあなたは、ここからの内容を参考にしてみてください。

ほめの解像度を上げる最短ルートは、気づく訓練です。

たとえば、機能実装のプルリクエスト（PR）を確認する場面。

単に「実装お疲れ様です、早くて助かります」と定型文を返すだけでは、相手には響きません。そうではなく、エンジニアが「見えないところでひと手間かけた工夫」に気づけるかどうかが勝負です。

「今回のチケット（要件）には入っていなかったけど、 後続のメンバーが迷わないように、型定義や移行ドキュメントまで丁寧に書き残してくれてありがとうございます。おかげで来週からの開発がめちゃくちゃスムーズになります」

これが、相手のスキルセットと、成果物の「裏側にある意図」を観察した上での、解像度の高いほめ方です。

プロジェクトメンバのスキルセットを把握し、ひと手間かけたことに気づくことから始めましょう。気づくためにはまず自分からやってみることが重要です。

やったことがないと大変さが理解できず、気づけないのです。だから大変さや大切さが理解できないと「すごいですね」の一言しか出てこないのです。

そして、経験がなくても手順は想像できます。海外旅行に一度も行ったことがなくても、家を出てスーツケースを引き、保安検査に並ぶ、といった流れは言葉にできますし、想像できますよね？

仕事も同じで、たとえやったことがない仕事や作業でも、ある程度は想像できるはずです。そのうえで、成果物や作業結果を見ると相手の努力が理解できるようになります。

そして、実は指摘も同じなのです。「まったくやったことのない仕事だから指摘なんてできない」と思わずに、できる限り解像度を上げて想像してみてください。

そうすればより深い会話ができるはずです。そして、あなたが指摘しないといけないと思っていたことは、実は、相手は既に考えていて、説明するほどでもないし、当たり前のことだからと勝手に思い込んでいる内容の場合もあります。そんなときは、指摘ではなく、ほめに変わるのです。

「そんなことまで考えいただいてありがとうございます。大変助かりました」
「いいえ、当たり前のことですので」

こんなやりとりがでるように問いかけができるようになるとプロジェクトメンバが徐々に活き活きしてくると思います。

まとめ

ほめ方と指摘の仕方は、コミュニケーションを円滑にするプロジェクトの推進装置だと考えてください。

「コミュニケーションを円滑にする」というと抽象的ですが、今回紹介したほめ方、指摘の仕方を参考にすることで具体的にどのようにプロジェクトメンバーと接すればよいのか、具体的にわかっていただけたらうれしいです。

ズレたほめ方は関係を壊し、順序を間違えた指摘は学習を止めます。

今回紹介した内容に関しては、毎回毎回確認していたら大変なので、1か月に1回の振り返りやプロジェクトの節目などで活用してみてください。

また、全文を読み返すのが大変な方のために、以下のチェックリストなども活用ください。

プロジェクトメンバーの皆さんが良い関係を構築しながら仕事ができれば大変嬉しいです。

書籍紹介

『DX時代の最強PMOになる方法』
著：甲州潤

▼こんなエンジニアはぜひお読みください。
・今の仕事に不満を持っていて、現状を変えたいと思っている
・給料をアップしたい
・エンジニアとしての将来が不安だ
・キャリアアップをしたいが、何をしたらいいかわからない
・PMOに興味がある
・PMOとして仕事をしたい

【目次】
第1章　一番稼げるIT人材は誰か
第2章　これからはPMOが1プロジェクトに1人必要
第3章　SEとPMOの仕事は何が違うか
第4章　稼ぐPMOになる７つのステップ
第5章　優秀なPMOとダメなPMOの見抜き方
第6章　PMOが最低限押さえておきたいシステム知識とスキル
第7章　システムは言われた通りに作ってはいけない
第8章　どんな時代でも生き残れる実力をつけよう

>>>詳細はこちら

【ご意見・ご要望はこちら】感想やご質問、今後取り上げてほしいテーマのリクエストなどをお待ちしています