モチベーションは幻想である：『ハイ・アウトプット・マネジメント』の5つの動機づけ理論
(stdy.blog)従業員の成果が低調な理由は2つある。能力不足と動機不足だ。
どちらが不足しているかを見分ける方法は単純だ。命が懸かっていてもできないなら前者である。
マネージャーの成果物は、その人が管理したり影響力を及ぼしたりするチームの成果物と同じだ。チームが良い成果物、すなわち良い成果を出すには、チームとしてのシナジーも重要だが、個々の従業員の成果も重要である。高い能力を備え、動機に満ちて高い成果を出す従業員がどれだけ存在するかによって、チームの成果は大きく左右されるからだ。
したがって、マネージャーの最も重要な仕事は、従業員が最高の成果を出せるように、つまり従業員の能力と動機が高まるよう支援することである。そのためにマネージャーが取れる行動は大きく3つある。
- 教育と訓練を通じて従業員の能力を向上させる。
- 従業員の欲求を自己実現の段階まで引き上げ、自ら動機づけできるようにする。
- 動機に満ちた従業員たちがうまく活動できる環境を整える。
アンディ・グローブは、動機は内面から生まれるものなので、他人が動機づけることは不可能だと考えていた。そのため、従業員が自ら動機づけられるよう欲求を刺激し、その欲求が維持されるよう支援することが、マネージャーにとって最善だと信じていた。
マネージャーが従業員の欲求を自己実現の段階へ効果的に引き上げ、それを維持する方法は何だろうか。本には明確には書かれていなかったが、本の内容と自分の頭の中の考えを組み合わせて5つにまとめてみた。
1. 教育と訓練
自己実現欲求は、能力を高めたいという欲求と、達成を高めたいという欲求に分けられる。つまり教育と訓練は能力向上の手段であると同時に、自己実現欲求を高める手段にもなりうる。
2. 形として見える成果物を重視し、認める環境
教育を通じて知識が蓄積されても、それだけではまだ成果が出たとは言えない。向上した能力を成果につなげるには、単に知識欲を満たしたり試してみたりするだけで終わらせず、成果物を生み出す雰囲気をつくる必要がある。
3. 挑戦的な目標の提示
現在の能力で全力を尽くせば達成可能性が70%程度になる水準に合わせ、達成欲を刺激しつつも自己効力感を下げないようにしよう。
4. 自分自身を測る指標の策定
自己実現欲求の段階に達した人には、自分の達成を測定する方法が必要であり、最も良い測定方法は本人の成果に対するフィードバックである。マネージャーがチームの重要業務に関わる成果指標を設定し、それに基づいて適切なフィードバックを残せば、従業員はそれを自分の達成を測るガイドラインとして活用できる。
5. 実験と失敗を奨励する環境
自己実現欲求を脅かす最大の敵は、失敗に対する恐れ、あるいは失敗による能力の後退や達成低下への恐れである。長期的により良い成果物を生み出すうえで、実験と失敗が不可欠であることをマネージャーが周知すれば、このような恐れによって従業員が過度に保守的に行動してしまうことは減るだろう。
8件のコメント
最初の段落に命の話が出てくるのを見ると、
人間を道具扱いしているみたいで、
悲しくなります…
ああ、そのように感じられたのですね。私は実のところ、この本はかなり温かく人間味のある本だと思っています。最初の段落は、私が少し要約しすぎたのかもしれません。
この文章は、「命が懸かっていてもできないことなんてあるか？ とにかくやれ」のようなものではまったくないと私は思います。たとえば著者は、「私にいきなりバイオリンを演奏しろと言われても、命が懸かっていてもできない」という話をしていました。
なので私は、管理者が能力に見合った仕事を与えているかを、きちんと判断しなければならないという意味として受け取りました。
達成可能性が70%程度であることを、どうやって判断できるのでしょうか。測定できなければ目標は立てられないはずですが、ソフトウェア開発でそれは可能なのでしょうか？
いくつか前提が必要だと思います。
当然ながら、新人やこうしたプロセスが初めての社員にとっては、適切な目標設定は難しいです。
マネージャーにとっても、初めて見る社員であればある程度は勘に頼るしかなく、簡単にはいきません。
スプリントを導入し、スプリント単位で目標達成率を確認して振り返りを行ったり、月次・四半期ごとに目標を立てて達成指標を継続的に観察したうえで、
結果に応じて次の目標をさらに引き上げるか、引き下げるかを決めるプロセスを繰り返すことで、平均的な数値を見つけていきます。
（こうしたデータが非常に多い会社であれば、このようなプロセスは最小限で済むでしょう）
もちろん、下方修正にも適切な線引きは必要です。誰が見ても最低限にも達していない人には問題があるので、叱るなり何なりの対応は必要でしょう。
こうした目標設定そのものにも多くの訓練や教育が必要だと思いますが、現実には大半の会社はこういう部分にコストをかけたがらないですよね。
私が経験した会社の中では、こうした管理がうまくできていた会社は1社くらいで、残りは口ではOKRだとか何とかいう管理手法を語るものの、実際には各自で目標を立て、各自で指標も決め、各自で評価もしていたように思います...
自分でも恥ずかしい話ですが、実務を理解し、仕事を分解し、それに応じて意思決定できる技術マネージャーは、私の経験ではほとんど見たことがありません。たいていは経歴や年次のためにマネジメントを任され、技術的なバックグラウンドがまったくない人が開発者全体を管理しているケースが多いです。バックエンド開発者出身のマネージャーが、あるプロジェクトではフロントエンド開発者まで管理することになり、ほどよく具体的なレベルの設計や指示事項もないまま、ただ実務担当者に（たいていは経験の浅い開発者に）機械的にイシューを作成して機能名だけを投げる……
韓国の開発組織文化は変わるのだろうか、今では疑問だけが残ります。
もちろん、定量的に測るのは難しいと思います。
管理者ごとにやり方は違うと思いますが、私なら参加者の自信をもとに定性的に測定すると思います。
たとえば、参加者自身に自分の作業に対する自信を評価してもらい、
2番と自己評価した作業を任せ、
1番ならより難しくし（時間制限を追加する、制約条件を追加するなど）、
3番ならより易しくし（コーチを追加する、ツールを追加する、仕様を減らすなど）、
こんな感じでやると思いますね。
素晴らしい文章に、素晴らしいコメントまで……ありがとうございます。
強くおすすめします。 :)