2025年1月27日
株式会社ログラス 開発本部長/事業執行役員VPoE
飯田 意己
2015年に株式会社クラウドワークスに入社。エンジニア、スクラムマスター、プロダクトオーナーを経て、2019年から執行役員として開発部門の統括を行う。
2020年に株式会社ログラスにソフトウェアエンジニアとして入社。プロダクト開発に携わったのち、1人目のエンジニアリングマネージャーとして組織設計、マネジメント体制の構築、エンジニア採用、採用広報・ブランディングの推進を行う。シニアエンジニアリングマネージャー、プロダクト開発部長を経て、2024年11月より開発本部長/事業執行役員VPoEに就任。
メンバーの課題を指摘しても深刻に受け取ってもらえない、フィードバックしたことが別の意味で解釈されてしまう……。開発チームやプロジェクトのリーダーを任された際に直面する、こうした悩みにはどう向き合えばよいのでしょうか。
約7年間、マネジメント畑を走ってきたログラスの飯田意己さんは、多くのリーダーが抱えるこれらの課題は、実は「合意形成」すなわち「握り」がうまくできていないことから生まれると指摘します。
「握り」とはどういうことなのか。具体的に、何をどうやって握ればよいのでしょうか。フィードバックを齟齬なく効果的に伝えるための「握り」の技術について、詳しく聞きました。
飯田:ほとんどの場合、そもそも「関係性ができていない」のではないかと思います。リーダーもメンバーも、相手がどういう考えを持っているのか理解できていないから、言葉を表面的に受け取ってしまう、というように。
飯田:様々な手段がありますが、私は「目標を握ること」を徹底しています。
「目標を握る」とは、メンバーとリーダーが、一緒に目指すべきチームや組織、プロダクトの目標や、メンバー個人が達成すべき目標について共通認識を持ち、合意を形成すること。ここで「目標」を用いるのは、リーダーとメンバーが、お互いが何を目指して働くのかというイメージを一致させながら成果を出すために、最も身近で効果的な指標だからです。
目標をしっかりと握れていなくて曖昧になっていると、リーダーからメンバーへの期待がブレます。するとフィードバックの基準もブレて、メンバーは戸惑ってしまいます。また、メンバーにとっては、自分が何を、なぜ期待されているのかがよくわからないまま働くことになります。だから、リーダーの意図とメンバーの解釈に齟齬が生まれるのです。リーダーが「よくできている!」と思って褒めても、「いや、まだまだ不出来だ」と自分を過度に追い込んでしまったり、もう一歩の努力を期待して「いいね」と声をかけたのに「褒められたから今のままでいいんだ」と安心し停滞してしまったり……。
こうした悩みの多くは、「目標」をうまく使えると、案外スムーズに解決できるものですよ。
飯田:「目標の握り」には3つのステップがあります。
ステップ1は「リーダーとメンバーが、お互いが考えていることや思考のクセを伝えあうこと」。これにより、相手の言葉を正しく解釈できるような土台をつくります。
ステップ2は「リーダーが、人事評価のグレードの定義とメンバーの状態を照らし合わせ、チームのためにメンバーにしてほしいこととメンバーのWILLをすり合わせること」。メンバーが進むべき道を、メンバーと一緒に定義するのです。
ステップ3は「定期的に状態を確認し合うこと」。すり合わせた目標に近づいているかを一緒に確認しながら、必要であれば、プロダクトやチームの状況の変化に応じて、目標の優先順位を変えたりもします。
飯田:最初に1on1で、リーダーが自分の考えを共有することから始めるのが良いと思います。
「目標のすり合わせをしよう」とリーダーから誘っても、メンバーにとってはその意義が理解できなかったり、唐突さを感じて戸惑ったりして「いったん大丈夫です」など深い議論にならないことも多いです。そのため、1on1など定期的に設けられた場で、リーダーから率先して、自分の考えていることを伝えましょう。
このとき伝えるべき内容は「リーダーとしての視座を持っているからこそわかること」と「リーダーを務める自分が持っている不安」です。
前者としては、チームの目標やその解釈、また、チームの課題、リーダーとしての自分に感じる課題、この先どうしたいと思っているか、を伝えます。このとき「自分はこう思っているが、認識は同じか」と聞いてみるといいですよ。メンバーに「あなたはどう捉えていた?」と質問することで、メンバーも意見をフラットに言いやすくなります。このやりとりから、メンバーの考え方や思考のクセを掴むことができます。
後者の「不安」は、なぜメンバーに伝えるべきか、すぐにはピンとこないかもしれません。しかしこれは、メンバーの主体性を引き出すうえで非常に重要です。たいていの場合、メンバーにとっての「リーダー」は、1人の人間というより、もっと無機質な「自分の評価や報酬を左右する存在、従うべき上位者」というように見えている部分があります。この認識のままでは、メンバーは「リーダーの指示通り動けばよい」と解釈し、受動的になってしまいます。
メンバーが主体的に、チームや自身の課題の改善に取り組めるようになってもらうために、「リーダーである自分ひとりじゃできないから、あなたの力を借りたい」というスタンスをとる。するとメンバーに責任感や効力感が生まれ、「リーダーの不安を解消するために自分は何ができるのか?」という視点で考えやすくなります。
こうして、リーダーが自らの考えを正直に伝えると、メンバーも本音を話してくれやすくなっていきます。
そのあと今度は、メンバーが抱えている課題感や、メンバー自身のWILLを改めて確認します。ここで得た情報は、次のステップで使います。
飯田:このステップの目的は「何ができたら成果なのか」を明確にして、メンバーと認識を合わせることです。
まずは、会社それぞれにあるグレード(等級)の基準と、メンバーの現状を照らし合わせて整理していきます。メンバーが今いるグレードの中で求められる要件とは何か。それを今の業務に当てはめると、どういう成果を出すことだと言えるのかを、まずはリーダーが理解しておくのです。
この観点はマネージャーが担保するべきと考える人もいると思いますし、それが間違っているとも思っていません。ただ、現場のチームの成果に向き合う上で、この観点をリーダーが認識しておけると、非常にやりやすくなると考えています。
飯田:たしかにそうですね。
考えやすい方法としては、リーダーである自分と比較してみるとよいと思います。リーダーとして、メンバーの成長を支援する際の観点のひとつに「次のリーダーを育てること」、要は「自分ができていることを、どうやってできるようになってもらうか」があるでしょう。自分がメンバーのグレードだったら、そのグレードのどんな要素が、実務でどのようにできているのかを整理するのです。そのあと同じようにメンバーの状態を整理して、差分を明確にしていきます。この差分が「メンバーにしてほしいこと」となります。
ただ、この方法では、グレードの解釈や、「メンバーにしてほしいこと」の定義に、リーダーの主観が絡んでしまいます。そのため、こうして考えてみる前に、マネージャーと話してみるのも有効です。
会社によって違う部分もありますが、一般的にはメンバーそれぞれにかける期待値は、最終的にはマネージャーが責任を持っている場合が多いでしょう。つまり「マネージャーが、メンバー育成の一部分を、リーダーに権限委譲している」という構造になっている。
リーダーの主観に偏らず「チームのためにメンバーにしてほしいこと」を定義できるように、マネージャーとリーダーですり合わせながら決めていくとよいでしょう。例えば「この人はこの強みを伸ばしてほしい」とか「この人はここが課題だから、次はここを頑張ってもらおう」など。マネージャーと一緒に考えていくと、リーダー自身の視座も上がっていきますよ。
そのあとに、メンバーのWILLと、マネージャーやリーダーが考えた「チームのためにメンバーにしてほしいこと」をすり合わせていきます。
飯田:メンバーが、自身の課題を前向きに改善してくれるようになるために、このすり合わせは必要不可欠です。
課題の改善が順調に進むかどうかは、内発的動機に紐付けられるかがカギとなります。「これは自分の課題ではない」「この課題の改善は、自分の未来にはプラスにならない」と思っているときって、モチベーションが下がってしまいますよね。
メンバーが持っているWILL、つまり「なりたい姿」と、リーダーやマネージャーが「メンバーに期待していること」が一致していれば、課題の改善はメンバーの未来にプラスになると示すことができます。メンバーに「これはやっぱり自分が向き合うべき課題なんだ」と腹落ちしてもらうことで、内発的動機を感じてもらえるようになるのです。
また、このWILLとのすり合わせは、ステップ1の中で出てきた「リーダーがメンバーに、不安を伝えること」ととの相互作用で、さらに強く内発的動機を感じてもらえるようにもなります。「あなた(メンバー)の変化によって、チームは、プロダクトはこうなっていく」といった道筋を見せ、その上で「あなた(メンバー)にこうなってもらうことによってしか、このチームは前に進めない」と頼る。これらがメンバーの中でつながると「自分の努力によって、チームやリーダーにどんな良い影響が起こるのか」をイメージできるようになり、責任感も生まれてくるのです。
飯田:まずは、これまで目標を握れず、あいまいなまま進めてきたことを謝ります。その上で「目標を握り直したいこと」と、その意図や、これからの話し合いの流れを伝え、ステップ1から取り組んでいきます。
その際、メンバーが、そもそも今期は何を課題として、どんなことに取り組んできたのかを聞いてみましょう。もし、チームが期待していることと、メンバーが努力していることの方向性がずれた場合は、客観的な視点から軌道修正を促します。また、今までメンバーが取り組んできたものの中に、今後の示唆となるものがあれば、それはポジティブな要素として伝えられるとよいですね。
飯田:チームや事業の状況の変化によって、チームの意向やメンバーが注力すべき課題が変わることもありますから、定期的な1on1などでのすり合わせは不可欠です。
1on1の中でのすり合わせには、状況にあわせてフォーマットをカスタマイズするのがおすすめです。例えば「メンバーの先週の良かったポイント」を出し合うとか、1on1の冒頭5分間でその週のKPT(Keep,Problem,Try)を出して話すなど、チームや事業の状況に応じて話すべき事項を出しやすくするためのフォーマットをつくるとよいでしょう。フォーマットにすることで習慣化できますし、お互い心の準備ができるようになり、ポジティブ/ネガティブ問わずフィードバックを伝えやすくなります。
ただ、フォーマットによる定型化は形骸化しやすい側面もあるので、状況が変化したら都度カスタマイズしなおすこともできるとよいと思います。
こうしたフィードバックの場では、「今週どうだったか」に加えて、例えば「今クォーターが終わったとき、どういうバリューを発揮できるようになってほしいか」など、少し長い時間軸でも伝えておくとよいでしょう。「未来」にどうなっていてほしいかを定期的に伝えることで、課題の改善について、短期だけでなく中長期的な視点を持ってもらえるようになっていきます。
飯田:強いステークホルダーの影響で、本来目標ではないものが目標に見えてしまうことがあります。たとえば権限のある人がジャストアイデアで「◯月までにXXという状態を目指しましょう!」と発言したときに、それがあたかも確定事項のように解釈されて、メンバーが誤った目標認識を持ってしまうようなケースです。その結果、手戻りやコミュニケーションエラーが発生することも考えられます。
リーダーはチーム内にこうした間違った目標認識が広がっていないかも、常に確認する必要があります。
飯田:そう思います。ただ、これができていると、リーダー業務は格段にやりやすくなりますよ。
飯田:まずコミュニケーションがうまくいきますね。メンバーへのフィードバックや声かけの意図を、誤解なく汲み取ってもらえるようになっていきます。
リーダーにとっては「こういうつもりで言ったのに、違う解釈をされてしまった」といった事態が、メンバーにとっても「思いもよらないことをリーダーに言われた」と戸惑うことが減っていきます。
また、「あと一歩のがんばり」を促しやすくもなります。80%で満足しているメンバーに対して「現在地点はここで、最初に決めた目標はここ。まだギャップがありますね」と客観的に指摘できますし、「ここに留まらず、さらに高い成果を目指してほしい」という期待も伝えやすくなります。
こうしてコミュニケーションに齟齬がなくなり、リーダーとメンバーの心理的安全性が高まっていくことで、リーダーにとってもつらい「ネガティブなフィードバック」のときの躊躇も、少しずつ減っていくでしょう。
さらに、リーダーもメンバーも視座が上がっていき「事業のためには」「チームのためには」と、より広いスコープで、自分の課題を捉えて改善できるようになっていくでしょう。共通の目標に合意できていることで、チームの一体感が醸成され、チームワークも向上します。リーダーが1人でがんばるのではなく、メンバーに支えてもらいながら成長するチームづくりができますよ。
飯田:高いスキルを持つエンジニアの場合、リーダーになりたての頃は、すべての課題を自分だけで解決しようとする人も少なくありません。人を頼ることに慣れていないからです。
メンバーに頼ることは、すなわち「自分の力だけでは解決できない」という、自分の限界や弱さを認めることでもあります。痛みを伴いますが、これはリーダーとして乗り越えなくてはならない壁のひとつです。
飯田:いや…おそらく大抵は、実際の経験を通じてしか、できるようにならないだろうと思います。
飯田:リーダーがメンバーを頼れないことで、タスクをさばききれなくなるのは、大抵、リーダーのタスク量のキャパシティを超えた時です。こうした状況に陥るのを予期して未然に防ぐことはできますが、具体的な課題が顕在化しないと、リーダーがどう動き方を変えればよいのかを議論しにくいときもあります。
そのため、頼ることが苦手なリーダーに、メンバーを頼れるようになってほしい場合、ときには私がマネージャーとして、あえてこういう状況をつくって成長を促すこともあります。もちろんフォローはしっかり行います。
このような状況ではどうしても、瞬間的にはメンバーから不満も出ます。しかしそれでも、やる意義はあると思います。リーダーが一度この状況を経験できれば、「自分ひとりでは無理だ」と痛感し周囲に頼れるようになっていきますから。
飯田:まずはマネージャーと、「リーダーとしてどこまでやれるか、あるいはやりたくないか」について、あらかじめ合意を形成しておくことが大事だと思います。
開発組織のマネジメントには大きく分けて「ピープルマネジメント」「プロジェクトマネジメント」「テクノロジーマネジメント」「プロダクトマネジメント」という4つの観点があります。リーダーがこの4つの中で、今の状況においては何を注力すべきだと思っているか、あるいは自身のスキルや経験が足りないのかなどを明確にして、その認識をマネージャーと合わせておくのです。
例えば「レビューを的確にできるように、設計に関する知識を身につけたい」「チームビルディングのスキルを身につけたい」など具体的に伝えられると、マネージャーからの支援を受けやすくなります。逆に、話し合いの中でリーダーが「今はやらない」と手放したものは、マネージャーが拾える体制が整っているとよいですね。
これは、リーダーとマネージャーの間での「目標の握り」とも言えます。
「目標」と聞くと「人事評価」を連想して気が乗らない人もいるかもしれませんが、こうしてうまく使うと、チームにも事業にも、自分のキャリアにも大きなプラスを与えてくれます。目標を上手に使うのは、マネジメントの第一歩。簡単にできることではありませんが、まずは目標についてマネージャーとディスカッションしてみるところから、はじめてみてほしいです。
取材:古屋 江美子、光松 瞳
執筆:古屋 江美子
編集:光松 瞳
撮影:曽川 拓哉
関連記事
人気記事