私は現場のコンサルタントではなく、コーポレート部門に所属しています。現場から「人と組織」の相談を受けて、それにオーダーメイドで応えていくのが私の仕事です。
今回は、現場からの相談としても多い「モチベーション」を題材にしてみました。メンバーのモチベーションを上げることに悩んでいる方へのヒントになればと思います。
はじめに
メンバーのモチベーションを上げたいと、日々考えているリーダーは多いのではないでしょうか。そんなとき、多くのリーダーが取るアプローチは「メンバーが”やりたい”と言ったタスクを渡す」です。
もう少し正確に言えば、「本人がやりたいこと（Will）」と「本人がやれること（Can）」と「プロジェクトとしてやらなければいけないこと（Must）」というWill/Can/Mustの3つができるだけ重なるタスクを渡す、ということになるのだと思いますが、今回はその中でも取り扱いの難しい「本人がやりたいこと（Will）」に着目してみます。
「メンバーが”やりたい”と言ったタスクを渡す」、これはこれで素晴らしいことに間違いはありません。しかし、このアプローチには実務上2つの難しさが伴います。
「『メンバーがやりたい』と言ったタスクがプロジェクト内にない」 「そもそもメンバーから『やりたいこと』が出てこない」という 2つの「ない」 です。
そこで今回は、「メンバーが”やりたい”と言ったタスクを渡す」とは異なる角度からのアプローチを紹介します。メンバーの「やりたいこと」という「目に見えない心情」だけに頼るのではなく、リーダー自身が 「タスクの渡し方」についての持論を持てるようになってほしいと思います。
メンバーの「やりたい」に頼りすぎないアプローチ
「やりたいタスクを渡す」というアプローチでは、メンバーの気持ちだけが判断軸になってしまいます。これだと、先ほど挙げた2つの「ない」によって、リーダーが八方塞がりに陥ってしまうことがあります。
そこで、メンバーのモチベーションを上げる方法を考えるときの問いを、ちょっとだけ変えてみます。「◯◯さんのモチベーションが上がるタスクは？」ではなく、「そもそも人はどんなタスクだとモチベーションが上がりやすいのか？」です。
目の前にいる特定の個人の、それでいて目に見えない心情ではなく、タスクの性質そのものに目を向けてみるのです。メンバーの側ではなく、タスクの側からモチベーションを捉える手立てを手に入れることで、リーダーが手綱を握れるようになります。
そもそも人はどんなタスクだとモチベーションが上がりやすいのか？
今回紹介するのは、「職務設計の中核的5次元」という（舌を噛みそうな）モチベーション理論です。「しょくむせっけいの ちゅうかくてき ごじげん」と読みます。職務設計の中核的5次元とは、リチャード・ハックマンとグレッグ・オルダムが1975年に提唱したモチベーション理論です。
彼らは、内発的動機づけが高まるタスクに共通する特徴（次元） として、次の5つを挙げました。
- 技能多様性（skill variety）
単純作業ではなく、様々なスキルを組み合わせる必要のあるタスク - タスク完結性（task identity）
細切れではなく、「始まり」から「終わり」まで一気通貫で取り組むタスク - タスク重要性（task significande）
他者や後続タスクに重要な影響を与える「なくてはならない」タスク、あるいは、社会や顧客や自社に対して重要な意味を持つタスク - 自律性（autonomy）
言われたままではなく、自分で進め方を考えて取り組むタスク - フィードバック（feedback）
成功も失敗も含めて、タスクの結果がどうだったのかについて実感を得られるタスク
そのタスクを実行するにあたり 「多様なスキルを活用」（技能多様性） する必要があり、 「最初から最後まで一連のもの」（タスク完結性） として任されており、そのタスクを 「重要だとメンバーが思って」（タスク重要性） います。さらに、 「メンバーに進め方を決める余地」（自律性） があり、 「成功／失敗によらずタスクの結果や影響が知らされる」（フィードバック） ような場合に、メンバーの内発的動機づけが高まるというわけです。
ここで逆のパターン、つまり、職務設計の中核的5次元が満たされていないケースを考えてみると、意味するところがさらにイメージしやすいと思います。
「誰でもできる単純な作業の繰り返し」（アンチ・技能多様性） を、 「全体から一部だけ切り出されて前後とのつながりがわからない状態」（アンチ・タスク完結性） で渡されます。さらに、そのタスクが 「他者や後続タスクにどういった意味を持つのかわからない」（アンチ・タスク重要性） なかで、 「言われた通りのやり方しか許されない」（アンチ・自律性） まま取り組んで、 「終わった後もタスクの良し悪しや周囲への影響を知らされない」（アンチ・フィードバック） としたら、モチベーションが下がるのも無理からぬことではないでしょうか。
職務設計の中核的5次元を意識すると、メンバーのモチベーションというものを、「メンバー」から一歩引いた場所から眺めることができるようになると思います。「◯◯さんはどんなことがしたいのかな？」という「やりたいこと」を一旦脇に置いて、「それはそれとして、そもそもこのタスクってモチベーションが上がるようになってるのだろうか？」というふうに、 「タスク」の側からモチベーションを考えることができます。
職務設計の中核的5次元を実際の現場で活用する際のポイントは、これら5要素を「メンバーがそう捉えているかどうか」が重要だという点です。「このタスクが5つの性質を有しているか？」という「事実」はもちろん大切ですが、それに加えて、「メンバーが『このタスクは5つの性質を持っている』と感じているか？」という、メンバー側の「認知」 がラストワンマイルとして効いてきます。
となると、メンバーにタスクを依頼する際にどのような声かけをするかが、非常に重要なポイントとなります。ということで次は、当社のリーダー陣が実際にやっている声かけの様子を紹介します。
「職務設計の中核的5次元」を活用したタスクの渡し方
この記事のドラフトを現場のリーダー陣に見てもらったうえで、「日頃どんなふうにタスクを渡していますか？」という実例を挙げてもらいました。リーダーからの声かけの中に、職務設計の中核的5次元が上手に織り込まれているのを感じてもらえたらと思います。
タスク重要性 ～プロジェクトの大義を語る～
まず、当社のリーダー陣の特徴として、「プロジェクトの大義を語る」というキーワードを通じて、タスク重要性を伝えている点があります。
プロジェクトの大義を語る、ということはいつも意識しています。
「◯◯サービスを構築することによって、業界で課題になっているドライバー不足に対する業務負荷の相当な軽減が期待でき、手取りを増やせるかもしれない。これは社会的にも意味がある。私もなんとか成功したいと思っている。今のタスクは地味かもしれないけど、それが欠けるとプロジェクト進行上のリスクになるので、誰かがやる必要がある」
タスク重要性は、「何のために重要なのか」という観点において、近くて小さなものから遠くて大きなものまで様々です。身近なところから順に並べると、「後続タスクのため」「同僚のため」「自社のため」「お客様のため」「社会のため」となります。
「プロジェクトの大義を語る」というのは、当社の社員が大切にしている考え方の1つです。これはまさに、最も遠くて大きな視点からタスク重要性を伝えていることになり、モチベーションを醸成する上で本質的なアプローチになっています。
フィードバック ～「褒める」のではなく「伝える」～
「フィードバック」という言葉は、その語感からイメージされるものと、実際に意味しているところの間にギャップが生まれやすく、誤解されがちな言葉だと感じています。
「フィードバック」を「（相手の間違いを）指摘する」ことだと思っている人も多いし、逆に、「ポジティブ・フィードバック」という言葉からの連想で「褒める」ことだと思っている人も多いです。でも、フィードバックはもっと無味無臭でニュートラルな意味合いで捉えたほうが、役に立つと思っています。「指摘する」も「褒める」も、ネガティブあるいはポジティブなニュアンスを強くまといすぎなのです。
フィードバックの本質は、「伝える」ということです。実際に起きたけど本人が知覚していない「事実」 や、こちらが感じたけどまだ言葉にしていない「気持ち」 を、ポジネガのフィルター抜きにして、言葉にして本人へ「伝える」。職務設計の中核的5次元における「フィードバック」の定義は「タスクの結果がどうだったのかについて実感を得られるタスク」でした。これを満たすのに必要なのが「伝える」という行為なのです。
「今日のミーティングでの説明、流れがとても良かったです。私も勉強になりました」
良いと思ったら素直に伝えるようにしています。
「先日の◯◯さんの記事が、Xやはてブでバズっています！こんなポジティブなコメントが出ていて、学びになっているようです！」
外部から反響があるものはこまめに伝えると、ノーリスクでモチベーションを高められるので、手を抜かないほうが吉。Slackの広めのチャンネルでやるのが良いと思います
「開発してもらってた画面の機能、昨日リリースしたけど◯◯さん（お客様）、喜んでましたよ！」
口頭でいうこともあれば、最近だとSlackも多いですね。全員で、🎉などのリアクションをとります。
当社のリーダー陣がどのように「伝える」ことをやっているかがよくわかるのではないでしょうか。
もし、リモートワークでのコミュニケーションが難しいと感じていたら、その要因の1つとして大きいのが「伝える」ことの減少／欠如です。オフィスで対面していれば自然と「伝わっていた」 いろいろなことが、リモートワークだとごっそり抜け落ちます。それは、職務設計の中核的5次元の「フィードバック」が足りなくなることを意味しているのです。「え、こんなことまで！？」と思えるところまでハードルを下げて、ちゃんと「伝える」だけで、モチベーションにプラスの効果が生まれます。
自律性⇒完結性⇒技能多様性 ～自分で仕事を面白くする～
今回、現場のリーダー陣に実例を挙げてもらったところ、職務設計の中核的5次元の観点で当社らしさが最もにじみ出ていたのが「自律性」「完結性」「技能多様性」の合わせ技です。
「実際に役立つ瞬間を想像してほしい」からタスクの説明を始めます。このシステムが具体的にいつ、どのように誰の役に立つのか。期待通りに動作すると、顧客業務の何がどう助かるのか。そこから遡るとテストはどうあるべきで、実装、詳細設計、基本設計、概要設計はどうあるべきか。5年利用することを考えると運用体制はどうあるのが最も望ましいのか。だとすると今この瞬間、（たとえば）要件定義では何を決めておくべきなのか、の関係性を示します。
メンバーには手元のタスクを「単なる技術仕様調査タスク」として片づけるのではなく、「2年後にあの人がこう使う未来」を正しく実現すべく自分は今このタスクをやっているのだ、を理解した上で取り組んでほしいと思っています。
「この課題は、こういう道筋で最後まで行けると私は考えた。でも自説に過ぎないので他の人にも考えてみて欲しい。間違っていても全然だいじょうぶ。君なりのベストプランを考えて教えてほしい」
どうしたらプロジェクト/課題/タスク全体を最適に着地させられるかについて自分の考えを開示しつつ、メンバー自身の案を広く募集します。自分の案が唯一絶対の正解ではなく仮説にすぎないことを伝え、合っているか間違っているかに関わらず、とにかくまずメンバー自身が案を出すことを奨励します。これによりメンバーは自分自身で案出しをしていいことを知り、自分の頭で考える楽しさを感じてほしいです。
「単に議事録を取るのであれば、AIでできる。そうじゃなくて、だれがどういう意図で発言したかと、その場のTODOや決定事項の質と数を追って欲しい。それをまとめることでプロジェクトが1歩でも推進する。数が少なければ、参加者に発破を書けても良い。議事録という役割に拘泥せず、プロジェクト成功のためにできることをすれば良い」
「役割はあくまで最低限の期待していることであって、そこに縛られる必要はない。というか、その役割を越境することを期待している。もちろん難しいのは分かっているので、まずは話の文脈や背景理解を優先して欲しい」
「何でこんなことを言うかって言うと、来年など思ったより近い将来にあなたが先輩の代わりにプロジェクトを前に進めるために推進したり、決定事項やらTODOを落とし込んでいく立場になるからだよ」
どの例も、「本人の『自律性』でもって、どの範囲まで取り組むかというタスクの 『完結性』を拡張することを求め、タスクの範囲が広がることで『技能多様性』も高まる」という構図になっていることが読み取れるでしょうか。
職務設計の中核的5次元の本来的な解釈では、「タスク完結性」や「技能多様性」は、「仕事を渡す側が最初から、全体が見える、かつ、いろいろなスキルが必要な仕事に仕立てておく」ものとして理解されています。それが当社の場合、「メンバーが自分で考えて、どこまでやるかを決める（自律性）」ことを起点にして、メンバー自身が「仕事の全体像を広げる（タスク完結性）」 ことや、その結果として「いろいろなスキルを身につける（技能多様性）」ことを、リーダー側が期待しているように読み取れます。
タスク重要性のところで紹介した「プロジェクトの大義を語る」と並んで、当社の社員がよく口にする言葉に「本質を見極める」「ないものはつくる」「難題を楽しむ」「初めてに挑戦する」といったものがあります。「自律性」「完結性」「技能多様性」の合わせ技は、まさにこれらの言葉を体現していると言えるでしょう。
おわりに
職務設計の中核的5次元というモチベーション理論を下敷きにして、「メンバーのモチベーションを上げるためには？」というリーダーが日々向き合っている問いについて考えてみました。
今回感じ取ってほしかったのは、「やりたいこと」という「メンバーの心情」は大切にしつつも、それだけに拘泥するのではなく、「タスクの性質」にも目を向けてみる大切さです。
（メンバー固有の心情ではなく）タスクの一般的性質という側面からモチベーションを捉えられると、仮にタスクそのものを変えることができなかったとしても、「どんな伝え方をすることでメンバーのモチベーションを高められるのか」というコミュニケーションの指針が得られます。これは、「メンバーが”やりたい”と言ったタスクがプロジェクト内にない」「そもそもメンバーから”やりたい”が出てこない」という2つの「ない」を迂回することにもつながるでしょう。
今回の内容をなるほどと感じた方にはさらに、今回の記事をメンバーに読んでもらうことで、職務設計の中核的5次元という考え方自体をメンバーと共有してみることをおすすめします。そうすると、メンバーと「モチベーション」について話すときの共通言語ができます。
メンバーから「なんだかモチベーションが上がりません…」と大雑把な悩みを吐露されても、そこから悩みの解像度を上げていくコミュニケーションは容易ではありません。なんなら、メンバー自身も実際のところ何に引っかかっているのかピンと来てないことだってあります。
そんなときに、職務設計の中核的5次元をチェックリストにして話し合ってみてほしいのです。いま抱えている仕事は、5つの特徴のうちどれが欠けているから、モチベーションにつながらないのか。リーダーとメンバーが共通言語を通じてモチベーションについて話せるようになってほしいなと思います。
]]>
