プレイングマネージャーで「俺TUEEEEEE」となっていた　メルカリEMが陥った2つの失敗と、その失敗の活かし方

失敗例1　プレイングマネージャータイプで「俺TUEEEEEE」となっていた

大野晋氏（以下、大野）：次に失敗の話です。最初にダーッと失敗の話をします。私はメタ認知という概念が好きなので、そのあとにその失敗をメタ認知の概念で話をしたいと思っています。

失敗でよくあるのは、プレイングマネージャーですね。私はもともとプレイングマネージャータイプでした。今はマネージャーの仕事の量を増やしていて、9対1ぐらいです。ただ以前は7対7という感じで、10割とは？　という感じがしますが、要はメチャクチャ仕事をしていました。マネージャー7割で、プレイヤー的にも7割ぐらいやっちゃう。

そうするとすごく疲れます。オーバーワークしてしまうことはよくありました。さらに良くないのが、マネージャーとしてやるべきことが中途半端になって、時間の判断をミスってしまったことです。さらにプレイングマネージャーだと、「俺TUEEEEEE」になりがちなんですよね。

技術的にもこなせて、何を優先順位でやらなきゃいけないかも、それなりにわかるけれども、やはりそれでも仕事は手放せなくて、自分がボトルネックになってしまっていました。また、マイクロマネジメントをしがちというのもありました。つまり自分がプレイヤーで、自分のやり方を持っているので「たぶんこれが良いに違いない」と勝手に思っちゃうんですよね。

他のメンバーが自分たちで考えたやり方でやると、「いや、こっちのほうがいいんじゃないか」と持って行っちゃうんですよね。まだこれから入りたてでこれからがよくわからない、新しいメンバーにはアリだったなという感じはしています。ただ、自分でできる人に対してはもう任せたら介入しない。

先ほど言ったように唯一解がないので、もちろん私の解が正しいわけではまったくないのですが、そこがちょっと失敗だったなと思っています。

失敗例2　リーダーシップに対する意識が欠けていた

大野：あとはリーダーシップですね。これはちょっとICの感覚が抜けていなかったのかなという感じがあります。

EMはやはり現場にいるので、現場の問題にはだいぶ気づくのですが、経営層は現場にいないので現場の課題がわからないんですよね。そこはくっつけなきゃいけません。そうじゃないと互いに何をやっているんだという話になります。先ほども言ったように、EMは中間管理職なので、ここをリンクさせる役割になります。経営的には大事なこと、これをやっていこうということを解釈して、自分たちのチームはこれをやっていこうと持っていく必要もあるし、現場の課題感を一番理解しています。

マネージャーがこんなリーダーシップではどうなんだ？　というのはありますが、私はけっこう大事だと思うので、これをやっていこうと思っています。EMでこれが問題であるというところを持っていく。そういうリーダーシップを発揮できる良い場所だなと思っています。

やはり今までは「上が決めてくれない」と思うこともありましたが、「本当は決めるように持っていくのがお前だよね」という話なんですよね。それを「選択肢だけ用意しました。どれがいいですか？」ではなく、「どれがいいですか？」ではあるけれど、「自分はこれでいきたいと思います。異論はありますか？」というふうに、ある時に変わったんです。

それまでは「やり方はいくつかあるし選んで」みたいな感じで、自分事じゃなかったのですが、ここを自分事にしたというのが1つあります。

メタ認知的に自分の失敗を振り返ってみる

大野：（スライドを示して）これはストーリーを話したのですが、ちょっと枠組みを考えて、メタ認知的に自分の活動はどうだったんだろうというのを考えてみます。

「メタ認知的に考えるとは？」みたいな話です。これは学生時代、社会文化心理学的なことをやった時に出てきたのですが、ブレイクダウンするんですね。（メタ認知は）メタ認知的知識とメタ認知的活動という2つに分かれています。

例えばソクラテスの「無知の知」。自分は知らないということを知っているかとか、自分はどういうことに強みがあるかとか、自分はこれがダメだとか。もしくは自分のロールはマネージャーなのかICなのか。そういう知識があるわけです。ナレッジです。それとは別に活動というのがあります。知っているだけでは何も発展がないんですよね。要は活動しないといけません。

活動していく時にまた、モニタリングとコントロールに分かれます。モニタリングで現在の自分をモニターしていく感じですね。自分が改善したいと思うところや、苦手でもよいと思うところ。もしくは別にネガティブじゃなくてもよくて「うまくできたな」みたいなポジティブなこともモニタリングしていきます。

コントロールは「改善したいならどうするの？」という話ですね。苦手なのでどうするか。このモニタリングとコントロールのサイクルを回していきます。

それを先ほどの自分の失敗にちょっと重ね合わせます。例えばメタ認知的知識だと、自分はエンジニアリング的なバックグラウンドを持っていて、何が起きているかだいたいわかっている。何が必要かもエンジニアリング的にはわかる。さらにマネージャーとしてやるべきタスクも知っている。そこまでわかっている。

では、その活動として何をしたらいいか。モニタリングとコントロールをどうしたらいいか。例えば、自分の状態として開発タスクを抱えすぎだったり、「これはダメだな」ということをモニタリングをして、重要性をチームメンバーと共有してメンバーが拾うようにする。それをコントロールで変えようとするわけです。

別にこのコントロールも1つの方法じゃないんですよ。開発タスクを抱えすぎだったら、もっとやってやる、もっとそっちにつぎ込む。そういう選択肢もありますが、あまり選ばないかな。やはり「メンバーみんなでやろうね」という話になると思います。他にも似たようなところで、タスクをメンバーにお願いしにくい、「ちょっとこれはつまらなさそうだしな」というタスクがあった時は、ちょっとできていなかったなというのはありますね。

あとは先ほど、自分が考えた方法と違った際に、人の仕事に介入してしまっていたというマイクロマネジメントの話がありましたが、モニタリングをして、そのあたりを「なるほど」と認知するという話です。

プレイングマネージャーは自分の良くなかったところですが、新しいメンバーには、それがけっこうありがたいわけです。新しいメンバーは、やり方の最初の型さえわかれば、そこからは自分に任せられてほしいと思いますが、そのバランスを自分で考えるのはなかなか難しいです。新しいメンバーには、任せるより詰め込んだほうが良さそうだったので、次回もそれを試そうと思って、また次のモニタリングに回してうまくいったという、そのサイクルを回すというのが、プレイングマネージャーの自分がメタ認知を考えた時にやっていたことだと思っています。

リーダーシップにおける失敗をメタ認知の視点から振り返る

大野：リーダーシップの時もそうで、例えば現場でみんなが困っている問題がある。自分はICではなくマネージャーという立場でこの現場に関わっている。例えば、問題と思っていても誰もそれに対応しようとしないということはよくあります。

もしくは結果的にリーダーシップを発揮して解決できたという、うまくできた時のモニタリングで、次のコントロールにも活かそうというサイクルですね。

例えば「対応しないなら自分がやりますか」という課題を出すかという話ですね。自分がやらなくてもいいんだけど、自分がまずは課題を出します。それでプロポーザルを書いたり、問題だと思っている仲間から聞き取りをしよう。プロポーザルもDesign Docとかドキュメントを書かなければいけないので、EMはけっこうドキュメントを書く能力が求められます。ICがそこを知っていたらメチャクチャ強いですよね。そういう意味ではコントロールで、問題があるんだったら、どうしようということでリーダーシップを発揮したら、うまくいって、このモニタリングでさらに課題を解決できたと。こういうことから今は私はけっこうリーダーシップを重要視しています。

というのが、メタ認知と私がふだん考えている頭の中を整理したところですね。自分の失敗と本当に成長しているのかというのもありますが、自分はそう思っていて、EMをやりながらけっこう楽しいと感じています。

この成長が楽しい。それで物事がけっこう回り始めてきています。

失敗を恐れて挑戦をしないのはNG　失敗から学び改善していく

大野：（スライドを示して）少し話がまた飛びますが、これは最後のページで、マネージャーとして意識していることですね。失敗はやはり大事で、失敗を許容する文化がないとダメだなと思います。失敗から学んで修正して改善します。

そしてまた失敗するのですが、その失敗は問題ではないとチームメンバーで共有します。なので逆に失敗すると「よっしゃ！」という感じでちょっと喜んだりします。「しまったな」と思った時に、本当は（自分が）介入していたら失敗にはならなかったかもしれませんが、そうするとその人の成長を止めてしまうことになるので、ここがなかなか、勘所が本当に難しいです。

メルカリだけではないとは思うのですが、メルカリの大事な指標の1つに「Fail Fast」があります。要は早く失敗しろという話ですね。本当は「小さく早く（失敗しろ）」ですね。よくわからないビッグバンリリースで失敗するんじゃなくて、小さいリリースで早く失敗すればリカバリーも早くできるんですね。

メルカリにはバリューが3つあるのですが、その1つで、私の好きなもので「Go Bold」、大胆にやれというのがあります。失敗を恐れて挑戦をしないのはNG。そこで失敗しちゃってもいいんですよ。ただ、挑戦はちゃんとしていこうという話ですね。

これは私の好きな言葉です。「ナイーブ」は、和製英語だと良い意味で、英語にすると本当は悪い感じですが、実は英語でも良い意味でのナイーブというのがあります。何が言いたいかというと、ナイーブは垢抜けないとか純粋すぎると訳されたりしますよね。

つまり、チャレンジできるぐらい純粋でいてほしいわけですよ。ある程度知りすぎて「これはメチャクチャ難しい」「これをやるのは大変なので、あまり出たくないな」というのではなくて、「なんかわからないけど、やってみようかな」というナイーブ性はすごく大事な要素だと思っていて、それをチームメンバーに話しています。

人事評価をする上で工夫をしていることは？

大野：なんか早口でいろいろと言ってしまったんですけど、時間的にちょうどいいですか？

司会者：ぜんぜん早いです。

大野：ぜんぜん早かった!?　早口だったので、ちょっと質問も受けましょうかね。

質問者1：すばらしいお話をありがとうございます。Markin' QualityのMarkと申します。今のお話を非常に興味深くうかがっていたんですが、僕自身があまりEMについて詳しくない状態で、ナイーブ性を発揮して質問させていただきます。

人事評価でメンバーの評価をけっこう嫌がってマネージャーになりたくないと思う方がいると思いますが、実際に人事評価をされていますか？　もしされていたら、どうしているか。その工夫などをうかがえたらと思います。

大野：工夫と人事評価をしているか、ですね。回答としては、人事評価はしています。自分のチームのチームメンバーの人事評価。そこがピープルマネジメントの仕事の1つですね。工夫は実はないんですよ。もう決まっているんですよね。もちろんある程度主観が入るのですが、メルカリの場合だとバリューに一致したところと、アウトプット・パフォーマンスの2つで評価します。

各グレードに応じて「ここまでできたよね」というところが一応わかっているので、主観が入りにくいかたちで評価の軸に合わせてどれにフィットしたのかなと見ています。評価したあとに他のマネージャー群と、本当にその評価が妥当であるかという話をします。

なのでけっこう大変なんですよね。だから「やりたくない」という人の気持ちがわからなくもないです。なかなか苦しい作業ではあります。ですが、フィードバックを与える良い機会であるとも捉えられるので、そういう面では良いところもあります。

質問者1：ありがとうございました。

EMのポイントは人に興味があるかないか

質問者2：今の話は、評価に対してハードルを感じている方にすごく良い、背中を押すようなコメントだったかなと思います。引き続いて、今エンジニアリングマネージャーをやっているけれども、やはりICがいいんだよねという人がいると思います。今の話はICからEMになってうまくいったパターンですが、そういう人ばかりじゃないと思うんですよ。今EMをやっていて悩んでいる方にどんなアドバイスをされますか？

大野：先ほどあったように、EMになりたいのは、要は人や組織にも興味があるのか・ないのかということですね。ある方であれば、EMとしてどういうことをやりたかったのかという話は聞きたいですね。そもそもない方だった場合は、別のキャリア、EMじゃないキャリアを選んだほうがたぶん幸せになるんだろうという話はちょっとするかもしれませんね。

だから人に興味があるかないかというところが、EMのポイントだろうなと思います。そういう話もしますが、これも回答がないので、話を聞く、出してもらうかたちにしたいと思いますね。

質問者2：わかりました。ありがとうございます。

マネージャーとして自分のモチベーションをどうキープするか

質問者3：私はCOOをやりながらEMみたいなこともよくやっています。EMはプレイングマネージャー寄りのところだったのですが、途中でまったくコードを書かなくなりました。その「俺TUEEEEEE」状態って最高に気持ちいいですか？

大野：はい。気持ちいいです。

質問者3：EMをやっていると「俺TUEEEEEE」状態というその脳汁が出るタイミングがなくて、組織がじんわり育って「大きくなったね」となるだけで、モチベーションがそうなるタイミングがありません。そこはマネージャーとして、どう自分のモチベーションをキープしているんですか？

大野：その時は、私はマネージャーとは分けますね。開発をしたい時は、例えば業務改善系のプログラムを書いたりします。私の持っているところは特に監査が入らなきゃいけないので、その監査のログと突き合わせるプログラムやスクリプトを書くのはけっこう自分でやったりします。そういうプログラムを開発することに分けるのが1つです。

もう1つは、これはハックというか働きすぎになるのですが、プログラマーとしてメルカリではないところで副業をしています。完全に分けて、そこではマネジメントはまったくしません。開発の分野をある程度のキャッチアップもしながらやっています。開発は自分の中では趣味みたいな気持ちがある程度あるので、土曜日や日曜日にやっても苦にはならず、さらにお金ももらえてラッキー！　という感じですね。

質問者3：ありがとうございます。

技術はどうキャッチアップしているか

質問者3：続けてもう1つ、今もちょっと思ったことです。課題に対して向き合った時、エンジニアやICはそれを等身大で見られると思うんですけど、EMになるとそうではないから技術に対して追っていくというスピードが担保できないことがあります。

それが正しいかどうかを判断しないといけない時に、経験がなくてわからないということが発生してしまった失敗があるのですが、どう技術を追っていましたか？

大野：今やっている場所では、そこまで（キャッチアップする必要が）ないのが1つです。現状はそうなっています。それが必要だった時に、たぶんまた壁に当たると思います。どちらかというと、こんがらがってしまった場所をなんとかするというチームの場所にいるので、今のところはないというか、私は最新の場所を見ているわけではありません。

新しい技術をキャッチアップしなきゃいけない時は、どうするのかな（笑）？　でも真摯にチームメンバーとやりとりしていると、EMのほうがテックリードに聞きやすいんですよね。ちょっとせこい話ですけれど、自分でがんばって勉強して調べればいいことを、ちょっとショートカットしてテックリードに直接いろいろ教えてもらうとか、そういうことはできるかなという感じはします。

質問者3：ありがとうございます。

失敗を次に活かすための枠組み

司会者：YouTubeのチャットの質問です。「失敗は奨励されるとのことですが、失敗を報告するやり方が何かあるのでしょうか？　自分の失敗を申告することに心理的な抵抗が多少なりともあると思います」。

大野：そうですね。奨励するというのは、私のキャリアの1個前の話をしないとわからないかもしれません。実は私はメルカリに入る前フリーランスだったのですが、ゆめみという会社にずっといました。ゆめみが「Bad News Fast」、つまり悪いニュースは先に出すということをすごく徹底している会社で、それが私は大好きでその概念をけっこう持ってきています。

逆に、隠したほうがバツであるということで話は進めている感じですね。失敗は確かに怖いというのはありますが、まずは「ありがとう」と。ゆめみがまさにそうだったのですが、失敗を共有したらまずCEOが出てきて「ありがとう」と言ってくれる環境で一緒にやっていたので、私もその文化をけっこうもらったなと、今のチームメンバーには話しています。

障害が起きると障害レポートを書くのですが、障害レポートも淡々とやって、次にそうなったらどうやって改善できるかという視点です。例えば障害で失敗した時によくあるのが、MTTAというMean Time To Acknowledgeと、あとはMTTRでMean Time To Repairで、その間隔をどうやって短くできるかということがレポートの中にもあるので、失敗は次の改善であるという枠組みが一応できています。

司会者：ありがとうございます。

エンジニアリングマネージャーに技術力は必要か？

質問者5：僕もあまりエンジニアリングマネージャーに詳しくない人間なのですが、エンジニアリングマネージャーに技術力は必要ですか？

大野：（スライドを示して）そこは難しいところで、まさにここなんですけど、私はある程度は知っていてほしいです。先ほどの話にもあったのですが、（技術力がまったくないと）決定しなきゃいけない時がある時に判断ができないんですよね。結局EMは、ある程度のところで判断する場所にいるんです。

その時にチームメンバーに聞き回るのはいいけれど、最終的な判断は自分がやって、それを上や他のステークホルダーに説明しなければいけない時に、ある程度の技術は必要かなと思っています。

質問者5：僕はけっこうスクラムを入れているんですが、スクラムマスターでも似たようなことがあって、どこまで開発に介入していくかで兼任のスクラムマスターが良いのか・悪いのかみたいな議論があると思います。

例えば人材がいなくて、技術はわからないけどエンジニアリングマネジメントみたいな人がいた時は、それはやったほうがいいんですか？　

大野：EMのキャリアも、もちろんありはありですね。曖昧なことを言ってしまいますが、これはスタイルやチームによるのかなと思います。ただ先ほどお話しした「私はリーダーシップも大事にしている」という話もあって、やはりしたいとか、この方向に行くよという考えを持って出したい時には、ある程度技術的な背景がわかっていないと出せないんですよね。

マネージャーで技術をわかっていないとなかなかそこがいけないので、私はあったほうがいいなとは思っています。

質問者5：ありがとうございます。

司会者： ではいったんここで休憩したいと思います。みなさんもう一度大野さんに拍手をお願いします。ありがとうございます。

大野：ありがとうございました。