まわりからの期待を見える化して、個人の力を引き出すエンジニア組織づくり

※この記事は 2024年05月21日に Medium で公開されたものを、ブログ移行に伴い再掲載したものです。内容は当時のままですので、一部情報が古くなっている可能性があります。

あなたが一生懸命手を動かしているその仕事、本当にいま皆から期待されていることですか…？

「職務記述書にそう書かれているんだから間違いない」「上司が賛成しているんだからそうでしょう」

…本当に？

わたしたちが職務設計について学んだこと

Tebiki株式会社エンジニアリングマネージャーの三宅と申します。私たち Tebiki社は、製造や物流などの現場での技能伝承を支援する動画マニュアルプラットフォーム「tebiki」を開発・運営しており、現場教育を行うことのできる人材の不足という社会問題に取り組んでいます。

Tebiki社の開発組織は「マネージャーが指示するよりも、役割を担う人が責任を果たすために創造的に活動するほうがうまくいく」という考え方のもと、「公式に定義された責任とそれを果たすための十分な権限」で職務設計をしています。

これに関して、最近、実践の中で学んだことがありました。具体的には、「責任とそれを果たすための十分な権限」による職務設計だけではなく、それにプラスして、『いま』『実際に』どのような活動が周囲の関係者から期待されているかという情報が、個人の能力を十分に引き出すために重要であるということでした。

この記事では、私たち Tebiki社が職務設計について経験した事例とともに、このときに役に立った「ロールマップ」という手法をご紹介したいと思います。

役割に対する周囲からの期待が不明瞭で、アイディアや能力を十分に活用できていなかった

Tebiki社の開発チーム内に存在する役割のひとつとして、テクニカルリーダーという役割があります。以前、この役割の責任は、以下の 2つの文で定義されていました。

・チームメンバーの技術力の向上に挑戦できる環境をつくること ・自身の技術力をもって難易度の高い技術的な課題の解決をリードすること

私は本人の能力やアイディアを存分に活かしてほしいと思っていたので、これらの責任を果たすための具体的な活動については、本人が良いと考えるアイディアをできるだけ尊重し、マネージャーである私は相談役に徹することにしていました。その人の知識や能力を信頼していたこともあり、この方針で十分うまくいくと考えていました。また、本人も、役割の責任を果たすことでプロダクトを成長させられることを面白いと感じていて、定義されている責任を果たすためにやってみたい活動をいくつも温めていました。

しかしその一方で、本人は「アイディアはあるが、それらの活動が本当に周囲からのニーズに沿ったものなのかはいまいち分からない。かといって手当たり次第やっていたら効率が悪いしなぁ…」ということで、自身のアイディアに思い切ってリソースを割くことができず、必要ではあるが無難なタスクをこなす日々を過ごしていました。

『いま』『実際に』何がこの役割に求められているのか調べてみよう！

そんなある日、本人から私に

「アイディアは沢山あるんですが、私たちの組織の実態に対して本当に効果のある活動をしたいと思っていて、どのアイディアに注力すべきか悩んでいます。」

「まずは、この役割に対して周囲から何を求められているのかを正確に把握して、戦略的に活動できるようにしたいです。」

という相談がありました。そこで、このテクニカルリーダーという役割に対して周囲のあらゆる関係者から『いま』『実際に』どのような活動がこの役割に期待されているのかを一緒に視覚化してみよう、ということになりました。

ここで使った手法が、「ロールマップ」という図を描く方法です。

Tebiki社テクニカルリーダーのロールマップ

ロールマップはとてもシンプルで、まず中心に分析したい役割を書き込み、その周囲にあらゆる周辺関係者を書き込みます。そして、関係者それぞれが中心の役割に対して日常的にどんな活動をすると想定・期待しているのかを書き込んでいきます。これは、本人の周囲に存在するすべての関係者にインタビューすることで実施しました。

この図から、『いま』『実際に』どんな活動が周囲から求められているかが明らかになり、本人が持っているテクニカルリーダーとしての活動のアイディアのうち、いまどれに取り組むべきかについて戦略的な会話ができるようになりました。

期待されている数々の活動を抽象化して、より創造的に活動できるような指針をつくろう！

さて、ここまででも、テクニカルリーダー本人が自信を持って活動できるようになり、終わりにしても良かったのですが、私たちはもう一歩踏み込んで、この役割に期待されているさまざまな活動を 4つのカテゴリに分類しました。さきほどの図の付箋についている 4色のマーキングが 4つのカテゴリに対応しています。

この 4つのカテゴリのうち 2つは、先述した 2つのテクニカルリーダーの責任に一致しました。そこで、残りの 2つも新たな責任として定義できないかと考え、結果として以下の 4つの責任が改めて定義されました。

・チームメンバーの技術力の向上に挑戦できる環境をつくること ・自身の技術力をもって難易度の高い技術的な課題の解決をリードすること ・技術的な観点からプロダクトの状況に対する説明責任を果たすこと ・開発プロセスの改善や設計のサポートにより品質を向上させること

責任の数は増えていますが、本人にとっては「むしろ自身のアイディアをどう活用できそうかが前よりも分かりやすくなって良かった！」とのことでした。

このことは、マネージャーが具体的な指示を出すよりも現場に近い人たちが創造的に活動するほうが圧倒的に良いだろうと考える私たちにとって、とても良い結果となりました。

あらためて、私たちが学んだこと

記事の冒頭でも述べましたが、この一件で私たちが学んだことは、「責任とそれを果たすための十分な権限」による職務設計だけではなく、それにプラスして、『いま』『実際に』どのような活動が周囲の関係者から期待されているかという情報が、個人の能力を十分に引き出すために重要であるということです。

「人材」と「責任とそれを果たすための十分な権限」を実際の職務を生み出すシステムと捉えるならば、「実際の周囲からの期待」という情報は、システムへの入力と捉えることができるかもしれません。

よく考えてみれば、私たちが取り組んでいる変化の激しい市場に対応する仕事は常に “オーダーメイド” であり、そのための職務設計においても、『いま』の情報の入力なくして最適な設計はできないということは明らかなように思えます。

今後も使えるロールマップ！

私たち Tebiki社を含め、自社サービスを開発・運用している企業の多くは、市場の複雑な課題に取り組んでいます。当然、そのような課題の解決に適した組織構成や職務設計が必要となります。

一方で、市場の課題は刻々と変化するわけですから、課題に対して最適化されている組織構成や職務設計も連動して刻々と変化するのが自然です。それゆえ、職務設計が『いま』（あるいは『近い将来』）の実態に基くように定期的に見直すことは、組織を最適な状態に保つために必須と言っても過言ではないでしょう。

ここでもロールマップはそのための強力なツールとして役立ちます。とてもシンプルなので、関係者たちにインタビューさえすれば、すぐに『いま』『実際に』何が期待されているかが可視化できるからです。

今後、私たちは、定期的にロールマップを作成し直し、役割ごとの責任をしっかりと状況の変化に追従させていきたいと考えています。

いろいろな目的に使えるロールマップ！

今回の事例では、私たちはマネージャーと本人のふたりで一緒にロールマップを作成しましたが、役割を担っている本人が自身の責務をもっとよく知るために、自ら関係者にインタビューしてロールマップを作成することもできます。そうすることで、周囲の期待に応えやすくなり、自身が望むキャリアをより形成しやすくなるでしょう。

もし、あなたがマネージャーなら、空きポジションの候補者を社内から募集したり、採用の面談をするときに、ロールマップを作成して、そのポジションに『いま』『実際に』求められている事と候補者のマッチングを図るといった使い方もできます。それによって、「入社してみたら、期待されることが職務記述書と実態で全然違っていた」というミスマッチを減らすことができます。