マネジメントの現場 ――良いチームを作るために必要なこと

最終回 マネージャーの心理

この記事を読むのに必要な時間:およそ 2.5 分

マネージャーの苦悩

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

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

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

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

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

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

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

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

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

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

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

注1)
Product Market Fitの略で,プロダクトやサービスがマーケットにフィットした状態のことです。

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

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

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

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

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

注2)
岸見一郎/古賀史健著『嫌われる勇気 ─⁠─自己啓発の源流「アドラー」の教え』ダイヤモンド社,2013年

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

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

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

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

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

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

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

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

最後に

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

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

天が人に大いなる任を降そうとする時,必ずまず,その心志を苦しめ,その筋骨を疲れさせ,その体を飢えさせ,その身を窮乏させ,行う事為す事に幾多の障害を与える

困難を乗り越えた先には確かな成長と大きな成果が待っていると信じて。

WEB+DB PRESS

本誌最新号をチェック!
WEB+DB PRESS Vol.125

2021年10月23日発売
B5判/168ページ
定価1,628円
(本体1,480円+税10%)
ISBN978-4-297-12435-9

  • 特集1
    作って学ぶプログラミング言語のしくみ
    インタプリタ,構文解析器,文法
  • 特集2
    GraphQL完全ガイド
    RESTの先へ! フロントエンドに最適化されたAPI
  • 特集3
    速習DynamoDB
    AWSフルマネージドNoSQLの探求

著者プロフィール

是澤太志(これさわふとし)

幼少時代からゲーム開発に興味を持ち,中学から『マイコンBASICマガジン』に触れプログラミングを学びはじめ,高校では授業でCOBOLを学び趣味でC言語を学びはじめる。高校卒業後は東京で新聞奨学生としてゲームプログラミングの専門学校へ通う傍ら,Webチャットサイトを運営などを行いインターネットとWebエンジニアリングにハマる。2000年に愛媛のITベンチャーで働いたのをきっかけにITエンジニアとなり,株式会社トーセ・株式会社シーエーモバイル・株式会社ALBERT・株式会社Speee・株式会社メルカリなど12社でテックリードやCTO,VP of Engineeringというエンジニアキャリアを経て,2020年にサイカにジョイン。またその傍ら,8年ほど続けてきた個人事業主を2018年8月に法人化し,合同会社クロスガレージのCEOとして複数社の技術・組織・プロダクトの顧問なども務める。

合同会社クロスガレージ:https://x-garage.jp/