最終回マネージャーの心理：マネジメントの現場 ――良いチームを作るために必要なこと｜gihyo.jp … 技術評論社 - Gihyo Jp

マネージャーの苦悩

マネージャーが抱えがちな悩みについて，本連載で以下のことについて書いてきました。

1on1とコーチングについて
目標設定と評価について
採用と広報活動について

これらに関するマネジメントとしての考え方のヒントは得られた方もいるかもしれませんが，ただ読んだり学習して深堀りしたりするだけで完全に悩みを解消できることはないでしょう。知識として得たこと，学習したことをベースに実践として取り入れ経験値としていくことが必要です。

その際に重要になってくるのが，「⁠マネジメントに失敗は許されない」という考えを捨て去ることです。開発の現場ではバグやエラーなどといった比較的課題としてとらえやすい問題が多いせいか，あいまいな問題が多いマネジメントの課題に対して取り組むことに慣れていない方も多いでしょう。そんな状況で，いきなり一人前のマネージャーとしての成果を期待されたとしても100点満点の完璧な成果を出すことが難しいのは目に見えています。

上司からは成果を求められ，メンバーからは支援を求められる。そんな環境で，自身がそれらの要求に対する逃げ場がなく，双方への説明や説得に多大な時間を費やしてしまう。場合によってはメンバーに対してプレッシャーをかけすぎて，大きくパフォーマンスを落とさせてしまう。そういうネガティブな体験をしてしまうと，二度とマネージャーなんかやりたくない，という気持ちにもなってしまいます。

マネージャーはメンバーに比べ多方面からの期待のプレッシャーに耐え抜く精神力が必要になることは否めません。でも失敗することもあると割り切り，すべてを完璧にこなすことはできないことを自覚することからはじめてください。周囲との期待値を調整し，失敗をしたことがあっても学びに変え，積極的な改善を繰り返していければよいのです。

自らの成果ではなく，チームの成果のために

エンジニアがマネージャーになったときに一番耳にするのが，現場でコードを書けなくなることで「自身の技術力が劣っていくのではないか」「⁠メンバーに技術で追い抜かれてしまうのではないか」「⁠自分がコードを書いたほうがプロダクトの品質も開発スピードも速くなるのではないか」などといった不安の声です。マネージャーになるエンジニアの多くはエンジニアとして成果を挙げてきた人たちのため，現時点では自らがコードを書いたほうが成果を残せる状態からはじまることが多いので，これは事実ではあるでしょう。

マネージャーの判断として，現場に入ってテックリード的役割も持ち，コードを書き続けることも成果を残すための手段の一つではあります。しかし，いつまでも自らが現場に入って技術的意思決定をしたりコードを書きつづけたりするということは，マネージャーの成果としてはワーストです。自身が率いた場合，チームは強い状態を維持し続けますが，自身がいなくなった場合，その状態を維持し続けることは難しくなるからです。このようなチーム状態では，マネージャーとしてベストな成果を残しているとは言えません。逆に自身が現場にいることで，メンバーの成長のチャンスを奪っていることを自覚しないといけません。たとえ自らが現場から抜けることで一時的にチームの力は衰えたとしても，自らがエンジニアとしてやってきたことをメンバーが代わりにできるようになる支援をしてください。メンバーの成果向上に努めることで成長を促すことが，マネージャーとして求められている役割であり成果です。

端的に言うと，マネージャー自身が現場の主役になることは避けたほうがよく，一番の手柄はメンバーに立てさせるべきです。マネジメント観点での悪い例として，スタートアップでCTO（Chief Technology Officer，最高技術責任者）に属人化した組織を見かけることがありますが，それはこのようなことができていないことが原因となっています。事業がまだPMF（注1）にいたっていない段階ではしかたがない問題でもありますが，事業が軌道に乗りはじめ，組織をスケールする段階ではこのような状況を打破し，チームのメンバーに成果を残させることに注力していくことが大切なのです。

一方で，「⁠現場でコードが書けなくて，世の中の技術トレンドに付いていけなくなることが怖い」という恐怖とは，ずっと戦っていかなくてはいけないかもしれません。しかし，自分が過去にエンジニアとして成果が残せたのであれば，いざ時間をかけて技術を学習すれば，すぐにキャッチアップできるという自信を持ってもよいのではないでしょうか。また不安が大きいようなら，個人で学習をするなどして，定期的に現場でコードを書いてみる期間をしくみとして作るのもありかもしれません。

誰かの期待に応えるのはほどほどでよい

マネージャーの中には「マネージャーだからこそ，組織やメンバーからの期待に応えなきゃ！」という思いに駆られがちになる人がいます。しかし必要以上に上司からの期待に応えようとしたり，メンバーから嫌われることを恐れるあまりメンバーの言っていることをすべてかなえるような行動に安易に走ったりするのは，マネージャーとして危険な行動です。

アドラー心理学の入門書と呼ばれる『嫌われる勇気』（⁠注2）という書籍の中に，「⁠『⁠あの人』の期待を満たすために生きてはいけない」という話があります。ここでは「ゴミ拾いしていて誰からも褒められなくてもあなたはそれを続けますか？」という問いがあり，それに対して「褒められなかったら続けないだろう」と答えています。このように答えるのは，行動の源泉が承認欲求によって成り立っているから起こることです。この承認欲求にとらわれてしまうと，物事に対しての本質的な課題を見失い，自身の成果が「誰かの期待に応えること」になり，周囲の顔色をうかがって日々の仕事をすることになってしまいます。これは他者からの評価や評判を気にしすぎると真のゴールを見失い，成果の定義を間違ってしまうという典型的な例です。

そうならないようにこの承認欲求をコントロールすることが，マネージャーにとって必要不可欠な基礎能力です。それを持ったうえでマネージャーとして自身に託されているチームのミッションを把握して，その成果を阻む課題に対してのアクションを支援できているかを念頭に置き，取り組むことが重要です。自身の承認欲求をコントロールし，マネージャーとしての成果が出せたときにメンバーはより成長し，結果として組織に大きな成果をもたらし，自らには期待以上の評価と信頼が得られるでしょう。

ですので誰かの期待に応えたいという思いはほどほどでよいのです。

フィードバック得て，マネジメントスタイルを振り返る

期待に応えるのはほどほどでよいとは言いましたが，かといってマネージャーが自分の要求や考えを一方的に伝えるのみだったり一方的な評価やフィードバックをしていたりするような状況では，メンバーからの信頼が得られず，チームとしてのパフォーマンスも発揮できません。

そんな状況に陥らないように，メンバーからマネージャーとしての振る舞いについてフィードバックを定期的にもらい，自身のマネジメントスタイルを振り返るしくみがあると理想的です。1on1で直接聞いていくという形もありだとは思いますが，直接は伝えにくいこともあると思うので，Google re:Workの「マネージャーにフィードバックを提供する」の項目にもあるようなアンケートを使った方法で集めるしくみを作ってしまうのがお勧めです。

できれば人事とも連携して，組織全体のマネジメント力を向上させる施策としてしくみ化してしまうのがよいでしょう。ここで得たフィードバックからの改善点をマネージャー自身のOKR（Objectives and Key Result）にも加えるプロセスが構築できるとベストです。

いつかは自分をクビにすること

マネージャーという役割をしていると，ずっと自身が支援しているチームのマネージャーであり続けたいという思いが出てくるのは必然です。ですが，組織に対してさらなる成果貢献をしていくことやメンバーのキャリアや成長を考えたとき，メンバーをマネージャーのキャリアに導いてあげ，次のマネージャーとして育成していくこともマネジメントに携わる者の重要な役割です。ですが，自分の役割を渡していくことへの不安に打ち勝てない，という方に出会うことも少なくないです。

でも安心してよいのは，マネジメントの重要性を理解している経営者であれば自身の役割を誰かに渡せる人を信頼し，その行動を高く評価して重用してくれるはずです。仮にもし会社がその価値を理解しなかったとしても，世の中の多くの会社が必要としてくれるでしょう。もしそんな状況の方がいたら筆者がCTOを務めるサイカでも採用したいぐらいですし，僕が顧問としてお手伝いしている会社にもいくらでも紹介したいです（笑⁠）⁠。

自分自身をクビにできる人というのは，自分の役割を誰かに渡すことができ，新しい役割を自分で作り出せるマネージャーとしてのロールモデルとなれる方です。一人でも多くのエンジニアリングマネージャーのみなさんが，そのような姿を目指してほしいと思います。

最後に

約1年に渡って，マネジメントのコラムを連載させていただきましたが，今回で最後となりました。次号からは，少し趣向を変えたコラムを開始します。

ITがビジネスや組織運営において必須となっている現在，エンジニアを集め，集まったエンジニアたちが成長して活躍しチームとしての成果を出すことに，使命を持って尽力するエンジニアリングマネージャーの必要性と重要性は日々増しています。マネージャーの仕事は，抽象的であいまいな課題が多く，ときには経営と現場の矛盾した難題も抱えることがあります。それでも「どうにかしてうまくやる」ことが求められます。それが「Manage」という言葉の意味であり，マネージャーの役割です。そんな日々困難に立ち向かっているエンジニアリングマネージャーのみなさんに孟子の名言を贈って，本連載の最後を締めくくります。