「負の感情」に敏感になり過ぎて見落としていたマネジャーの役割

マネージメントについてインタビューを受けました。

「負の感情」に敏感になり過ぎて見落としていたマネジャーの役割
――奥脇さんは、これまでの仕事人生の中で大きな失敗をした経験はありますか？
前提として僕は完璧主義な傾向があって。何をするにも失敗しないように、用意周到に生きているので、エンジニアとして「大きな失敗」を経験したことはないんですよね。

――確かに奥脇さんには、これまでの取材でもストイック過ぎるエピソードをいくつも伺ってきました。なぜ、完璧にこだわり続けていられるんでしょう？
僕は、「唯我独尊」になりたいと思っているんですよ。

どういうことかというと、自分の視界の中に入っている人たちに少しも「負の感情」を抱いてほしくないんです。誰かが悲しんでいたり怒っていたりすると、それ自体が僕のストレスになるので。だから、僕の見える範囲にいる人が幸せな気持ちでいられるためにできることを全力でする。そのためには、僕自身が完璧でいなきゃいけないと思うんですよね。

そして、毎日「今日の自分もかっこよかったな」と思って１日を終わりたい。「今日の自分は完璧とは程遠かった」と思うようなことがあった日にはもう、悔しさやふがいなさで寝付けなくなってしまうんです。

――やはり、奥脇さんは突き抜けていますね（笑）。実際に、ふがいなさから寝付けない時期もあったんですか？
hp、日立、東進ハイスクールで開発部長のポジションに就いた時は、しばらく寝付けない日々が続きましたね。

当時20人くらいのエンジニアのマネジメントを任されていたのですが、今思うとマネジメントの本質を理解するまでにすごく時間を費やしてしまっていたなと。これがある種、僕にとっての「しくじり」と言えるかもしれません。

――具体的に教えてください。
例えばメンバーに何かのタスクを任せるとき、マネジャーならば本来はその人に任せる理由を、起こり得るリスクまで踏まえて論理的に上層部に説明できなければなりません。でも当時の自分は、「こいつのことは信じてるし、もし何かミスをしたとしても自分がケツを持つぞ」と思っているだけで、任せる理由を論理的に説明することはできていなかった。

また、周りの人の誰にも「負の感情」を抱いてほしくないので、何かトラブルが置きそうなときに先回りしてフォローをする、といったことも多くて。「AさんとBさんがもめそうだ」と思ったら、怒りのスイッチが入る前に何らかの形で介入して障害を取り除くとか。そういうことをよくやっていたんですよ。

「そうやって人と熱心に向き合うことだけがマネジャーの仕事ではない」と漠然と分かってはいたものの、メンバーの感情を常に読んで寄り添い過ぎてしまっていた。

しかも、当然メンバーだけではなく、上司や経営陣にも負の感情を抱いてほしくないので、任された事はできるだけ完璧にこなしたいじゃないですか。そうすると朝から現場のフォローと上司や経営層から降ってくるいろんな要望やタスクに対応するだけで夜10時になって、そこから自分の仕事をして、あっという間に終電……。そんな毎日でした。

マネジャーとは本来、人や組織、自分の権限などの持てるものを組み合わせて、「１+１」を４にも５にもスケールさせるポジションなはずです。それがこの時の僕は、目の前に降ってくる質問や課題に応えるだけで精いっぱい。１年後にこの組織をどうしようとか、このメンバーにどう成長してもらおうといった、長期的な戦略を練る時間を取ることができていませんでした。

今思えば、あの頃の僕にはマネジャーとしての存在価値は全くなかったでしょうね。

奥脇さん
１年がかりで見つけた奥脇流マネジメントのフレームワーク
――その状況から、どうやって抜け出したんですか？
自分なりのマネジメントの「勝ちパターン」を見つけ、独自のフレームワークをつくったことで抜け出すことができました。

現場からアラートが上がってきたり、他の部署から差し込みが入って自分の仕事が全くできなかったり、職場では毎日何かしらのトラブルや課題が出てきますよね。それを、１日の終わりに「なぜあれが起こったのか」「前もってどういう手を打っておけばそもそも起こらなかったのか」と毎日振り返ったんです。

これを１年くらい繰り返した結果、「『六つのこと』を押さえておけば、トラブルは起こらない」という答えにたどり着きました。

――「六つのこと」？
「組織」「業務」「人」という三つのリソースについて、現状と１年後にありたい姿を設定するんです。

奥脇さん
すると、それぞれの「今の課題」と、「１年後の姿にたどり着くためにやらねばならないこと」が見えてくる。あとはそれをやる、っていうシンプルなことなんですけど。

このフレームワークにたどり着いた結果「現在の人に向き合う時間は、全体の６分の１でいいんだ」ということに気付き、自分のスタンスを見直すことにもつながりました。やっていくうちに実際にトラブルなどもだんだん減って、１年ほどで、きた球を打ち返すだけの時間を１日あたり５分の１くらいまで削減できるようになりましたね。

以前はできていなかった「この組織をどうしていくべきか」といった将来のことを考える時間や、その時抱えているプロジェクトにどう向き合うか、という本質的なことを考える時間も取れるようになり、徐々にマネジャーとしての価値を発揮できるようになったと思います。

――このフレームワークがあれば、初めてマネジャーになった人も組織の課題をクリアにできそうですね。
ええ。実際、この考えを取り入れてから、最初は20人だったメンバーが120人くらいまで増えても、中間マネジャーを置かずに何とかやっていけていましたね。

――120人全員を奥脇さんが見ていたってことですか！？
ええ。

――す、すごい……。日々の業務はメンバーが自走していれば何とかなりそうな気もしますが、評価なんかは全員分対応するのはすごく大変そうです。
評価もマネジャーとして重要な仕事ですし、やはり給料なども決める立場なので、自分の目で見た評価を大事にしていました。

さすがに100人くらいになると１on１ができる時間は限られてしまいますが、全員のソースコードやGitHubのコメントを毎日チェックしていましたね。誰の書くコードのレベルが上がってきているとか、他のメンバーへのコメントは適切かとか。評価で「こういうところがダメ」という指摘をする時はソースがないといけませんからね。

また、そういう評価をするときは、特に伝え方にも気を付けていました。被評価者にも負の感情を持ってほしくないので（笑）

――どんなふうにフィードバックをしていたんですか？
初めに、「キミのことを絶対的に信用している」と伝えることを心掛けていました。もちろんメンバーのことは言葉だけでなく心の底から信頼しているのですが、言葉に出して伝えることが大事だと思っていて。

仕事をする上でも双方向の信頼関係がないと気持ちよくできないですし、「ダメな点を指摘するのは批判ではなく助言である」ということを理解してもらうためにも、僕のことを信頼してほしいわけです。

その上で、どんなに歴が浅くても「キミのことを信頼している」と恥ずかしげもなく言う上司のことは、おそらく嫌いにはなれないじゃないですか。しかも、３カ月に１回の評価面談で毎回「信頼している」と言われたらそれなりに理解してくれるはず。これはどんなメンバーにも共通して心掛けていました。

奥脇さん
それから、評価が満たなかった人に対しては特に、その人に何を期待していて、具体的に何ができたら「期待を満たされた」という評価にするか、何ができていないとダメなのかといったことをできるだけ具体的に伝えていました。

「キミには次のステップに上がってほしい。そのためにもこの部分を改善してほしい。例えば以前こういうシーンでこういう行動を取っていたよね。でも、半年後には同じシーンで、こういう振る舞いをしてほしい。それにはこういう考え方や知識を取り入れるといいよ」と。

こんなふうに信頼と方法まで伝えれば、メンバーはどうすればいいか迷わずに、ポジティブに成長に向き合うことができる。

それに、僕自身もそういうストーリーをつくりたいんですよ。メンバーの成長は組織から求められている私の責務でもあるわけだから、ちゃんと成長しなければ今度は私が上司から怒られてしまいます。何度も言いますが上司にも負の感情を持ってほしくないので（笑）。ある意味八方美人なんですよね。

――中途半端な八方美人だと「あちらを立てればこちらが立たず」みたいなことにもなりそうですが、強い信頼関係や伝え方の工夫によって、メンバー、上司の双方に「負の感情」を抱かせずにいられたんですね。
ただ、フレームワークやメンバーとの向き合い方も、あくまで僕がいた現場にとっては良かったというだけで。ある程度の汎用性はあれど、現場ごとに抱える課題は当然違うので、最終的なマネジメントの正解は、結局自分で見つけ出すしかないと思うんですよね。

これはマネジメントの本なんかにも同じことが言えて、例えば僕はピーター・ドラッカーの本がすごい好きなんです。でもああいう本って、まだ経験が浅いうちは話が抽象的過ぎて活用できないんですよ。

だからもう、現場に合わせて自分で最適な打ち手を模索するしかない。日々きた球をひたすら打ち返すだけじゃなくて、組織のあり方そのものや、フレームワークについてしっかり考える時間を取るべきだと思いますね。

自分の成果を「手触り感」のある言葉で語れるか？
――他にエンジニアがマネジャーになったら意識しておいた方がいいことはありますか？
常に「自分のマネジャーとしての役割や成果は何なのか」を、他者に語れるように言語化しておくことが大事だと思います。

マネジャーの成果って、エンジニアリング組織を何人規模にスケールさせましたとか、事業規模を拡大させましたとか。あるいはCTOをやっていました、みたいな話になりがちじゃないですか。

でもこれらは景気や経営状況にも左右されることなので、本当にその人本人の成果なのかというとそうとは言い切れない。

僕、すごく優秀な幼なじみがいるんですよ。20代で事業部長をやるような。で、彼が自分の後を任せられる次期部長を探している時に、「たくさん面接をしているけど全然いい人が見つからない」と言うんです。「部長経験者に、『あなたは何ができますか？』と聞いても、『部長ができます』としか言わない」って。

奥脇さん
その時の僕はまだいちエンジニアだったので「へぇ……」って聞いていたんですけど、自分がマネジャーになってみて、彼の言っていることがよく分かりました。

自分の成果や能力を示す上では、自分がマネジャーとして何をしたのかについて、「どんな課題があって」「それを自分がどう解決したのか」「そのとき、その課題を解決するために、どのような体制の中で誰を・どのように巻き込んだのか」を、言語化して語れること。これが大事なんですよね。

だから僕自身も、「マネジャーとしてどんな成果を生み出しましたか？」と聞かれたら、５分バージョン、15分バージョン、30分バージョンで語れるようにしています。今のところ、転職予定はないですが（笑）

――これはマネジャーに限らず、どんなエンジニアにも必要な考え方ですね。
もちろんです。スペシャリストの道を歩むにしても、スキルが上がれば任される責任範囲は広くなっていくわけで。自分の関わったプロダクトについて、どのようなアプローチで、どのように課題を解決したのかを説明する必要があるのは同じです。

――何だか奥脇さんのお話を聞いていると、たとえうまくいかないことがあったとしても、全ての事に解決策があるんだ、という気がしてきました。
最初に「僕自身は失敗しないように入念に生きている」という話をしましたが、チームのメンバーなど、僕以外の人は失敗したっていいと思っているんですよね。他者にまで完璧は求めません。

hpのメンバーに限った話で言えば、僕がリカバーできる範囲だったら大歓迎。だって、助けてあげたらドヤれるじゃないですか（笑）。助けてドヤれたら僕もうれしいし、助けられたメンバーもうれしい。みんなハッピーなので、むしろどんどん失敗して、いろんな経験を積んでほしいですね。