STORES Product Blog

こだわりを持ったお商売を支える「STORES」のテクノロジー部門のメンバーによるブログです。

育休前に振り返る、私がEMとして大切にしている考え方

はじめに

こんにちは、テクノロジー部門プロダクト基盤本部基盤グループでEM(エンジニアリングマネージャー)をやっている松本 (@upinetree) です。普段はID基盤などを作ってます。この度子供が生まれ、6ヶ月間の育休を取得させてもらうことになりました*1。育休に入るにあたって、ありがたくもチームメンバーの池田さん (@yusuiked) が私の育休中のEM業務の代打を引き受けてくれました。大感謝です。ここ数ヶ月かけて引き継ぎを進めてきて、無事バトンタッチできました。

引き継ぎは職種問わず難しい仕事のひとつですが、EMの引き継ぎは関わっている人や仕事、抱えている情報が多い点において難しく、悩みながらやってきました。最初はざっと業務内容を洗い出し、池田さんと一緒にEM業務を行いながら引き継ぎを進めるプランを考えましたが、それだけでは表面上の引き継ぎに留まってしまいます。また、上司の大橋さん (@nal_6295) からも「松本ism」を残してほしいというリクエストをもらっていました。

そのため、業務内容だけでなく、物事の進め方や決め方について、背後にある私の価値観とともに渡せるとよいなあと考えていました。しかしあらためて考えると、これらを言語化するのは難しいことに気付きました。私はEMとして無意識に突っ走ってきてしまっていたのです。

そこで育休に入る前に、私がEMとしてどう考えていて、何を大事にしているのか、一度立ち止まって振り返りました。この記事は、社内向けに書いたいくつかの記事をプロダクトブログ向けに調整して公開したものです。「こうするのが良い」というノウハウではなく、「現時点ではこう考えているよ」という個人的な棚卸しになります。長い記事になってしまったので、興味のあるところから読んでいただければと思います。

仕事が進む構造を作る

まず念頭に置いているのは、物事を構造で見ることです。これは私がEMとして働く前から意識していたことなのですが、EMとして経験を積むにつれて、より大事だと考えるようになりました。

構造を作るとは

「構造」にはいろいろありますが、私自身は正確に定義しておらず、文脈によって変化する流動的な存在として捉えています。それだと説明に困りそうなので、一旦ここでは以下のようなものとしておきます。

  • 要素
  • 関係性
  • プロセス

EMとして意識していることは、これらの要素をどう構造を組み立てたら物事がうまくいくだろう、と考えるようにすることです。

なにか問題が発生したり、ものごとに違和感があるときも、最初に構造を疑います。つまり、「Aさんが〜だから」とか、「Bチームが〜だから」のように特定の人や集団を理由にしません。生産性や、意思決定のうまさや速さ、情報伝達の正確さや浸透具合、人と人の間のトラブルも、まずは構造で考えます。

構造をエンジニアリングする

エンジニア職なら共感が得られるかもしれませんが、構造を考えること自体にエンジニアリング要素があると考えています。発生したバグの原因を実装者個人の問題だと考えずにその背後の構造や経緯に目を向けるように、組織やチームの構造に対しても同様に考える感じです。

その他、おなじみのモジュール化、抽象化、インターフェース設計、責務分割、状態管理、システム特性などなど、多くの領域の考え方が似ているなと感じることがあります。また、私は制御工学出身なので、ブロック線図をイメージすることもあります。

といっても、そのまま使えるノウハウがあるというわけでもないのが難しいところですし、無理に共通項があるとして扱うのも違和感があります。エンジニアリングと比較して感じるのは、より不確実性が高くてふわっとした、予測も測定も評価もしづらい課題領域だということです。

構造に伴う納得感

ここで個人的に注意しているのが、どんな構造に対しても、納得感を大事にするということです。納得感を欠いた構造のうえではチームは生産的・継続的に働けないと考えています。

納得感は人や状況それぞれに発生するため特に流動的です。皆で目線を合わせて進めていくために、適切なタイミングでの適切な説明や問いかけを大事にしたいと考えています。なぜその構造でやっていくのかが腑に落ちて、初めてチームはうまく地面を蹴ることができるようになるのだと思います。

一方で、たとえ説得力のある理由や説明があったとしても、ちゃんとした構造が伴っていないと納得感も得られないものでもあり、両輪の存在が大事なのだろうなと思っています。ちゃんとした構造を考えるのにも技術が要求されますが、必ずしもひとりで考えなければならないものばかりではなく、皆で構造を考えるプロセスを設ける形で両輪をちょっとずつ働かせていく方法もあると思います。

会議体の設計

EMにとって身近な構造といえば、会議体です。会議体自体が「ある目的を達成するための構造の一部である」とも言えますね。

会議体の構造を考える上で、個人的によくあげるのは次の要素です。

  • ゴール
  • メンバー
  • プロセス

ゴールに対して、どんなメンバーでどういうプロセスを経ると、効率よくスムーズに納得感のある確からしい解に到達できるだろう、といったことを考えて設計します。

プロセス

このなかで、プロセスには様々な選択肢がありますが、個人的に気にしているのは以下のあたりです。

  • 目線や認識を揃える
    • 目的、用語、課題理解、前提議論など
  • 情報の流れを組み立てる
    • 基本、認知負荷を下げる方向
    • インプット→議論→アウトプット
    • 前提議論→応用議論
    • 抽象→具象(発散させたいならその逆も)
  • 決定事項への合意を取る
  • ネクストアクションを定義する

これらはある程度やってくると自分の中で型のようなものができてくると思います。ほぼリモートワークになってからは miro でやることが多いので、それを自分なりのフォーマットのように蓄積して、状況によって合いそうなものを引っ張り出したり応用したりしています。

ファシリテーション

プロセスを狙い通りに進行させるためのファシリテーションも主な仕事の一つです。これはいつまでたってもうまくできている実感がありませんが、だいたい次のようなことを意識しています。

  • どんな質問を投げかけたら議論が捗りそうか
  • どこに時間をかけて議論して、どこを省略するか(共有のみにする、あらかじめ情報を埋めてくるなど)
  • 場の流れに任せながら、タイムキープしつつ発散と収束を管理する
    • 場の流れを大事にする
    • 盛り上がったら省略できるポイントを作っておく
    • 盛り上がっても逸脱せずに着地できるようにする

情報の扱い方

チーム内外の多種多様な情報と触れ合う機会が生じるなかで、情報との付き合い方が自分自身やチームの仕事の質と働きやすさに関係すると思っています。

個人的には、前述のとおり構造(この場合は組織間を行き交う情報)を制御系のブロック線図としてイメージすることがあります。要するに入出力、伝達関数、外乱、フィードバックなどをブロックと線で表現した図です。

情報の流れについて適当に書いたイメージ図

あくまでイメージであり厳密な理論ではありませんが*2、私は情報に対しても系をイメージしているようです。信号処理の分野でもブロック線図で表現するので、そこそこ親和性はありそうかなと思っています。

入力情報のエフェクターとして動く

私は趣味がギターということもあって、EMがエフェクターとして動く感じをイメージしています。たとえばチームの外からの情報に対して、その内容に応じて、フィルター・リミッター・ブースターとして切り替えて作用します。次のような感じです。

  • 温度感の圧がかかりすぎていたときリミッターで制限
  • 情報量が具体的すぎたり多すぎたらフィルターで絞るとか抽象化
  • プロダクトやメンバーの状況にあわせてブースターで補足や色付け

チームの外への情報出力についても同様に、適切な形で提供できると良いなと思っています。

情報の性質によっては、入出力チャネルを増やすのも有用です。

  • オープンに見えるところで情報を放流する
  • 一部の人にはすでに伝えたことでも改めて広く伝える(認識を揃え、裏で進んでいることの不安を払拭する)
  • 必要に応じて頭出しや裏取りを行う

遅延を取り除く

EMが情報をブロックしてしまっては全体の遅延になるので、速やかに伝えるとか、意思決定するとか、そういう動きをしなきゃなーと考えています。自分だけが抱えている状況は自分にとっても良いものではないですしね。

別のチャネルで伝わるような情報であれば、シンプルにエフェクターとして働きます。コンテキストが伝わりづらいものだったら補足したり、気にしなくていい内容は影響ないよねと確認し合ったりします。*3

意思決定については、その場で決められそうなことは決めるような促しや場の流れを作ることがあります。考えてみて根深かったらまたあらためて、という諦めの良さも持ち合わせるようにしています。メンバー全員がすばやく意思決定できるようなメンタルモデルをチームに作ることもある種の構造づくりかなと思っています。

なお、同種の情報をまとめたい、確度を高めたいなどの理由であえて遅延させて伝えることもありますが、用法用量を守りたいところです。

情報を能動的に集める

広く情報を集めるようにしています。このとき、すぐに役立つ情報というのは期待せず、とにかく頭のインデックスに入れておくイメージです。色々な出来事に備えて考えておいたり、ふとした時に点と点がつながって動き出せるようになるのが目的です。忘れてしまうこともありますが、あまり気にしないことにしています。

情報のリアルタイム性はそこまで重視しておらず、デイリー、ウィークリーくらいで把握できていれば良いとしています。即時対応が必要な情報は向こうからやってくるという楽観的な考え方です。組織を信頼した考え方とも言えます。理想的なのは、そうなるような構造を組むことでしょう。

相談事を快く引き受けるとか、答えられそうな内容だったらその場で答えるとかしていると、情報が集まりやすくなる気がします。

なお、まとまった情報だけ見るようにして、あえて遠ざけている場合もあります(slack ch から抜ける、入らないなど)。自分の能力に限界があるので、パンクしないように制限するためです。

システムの構造とチームのメンタルモデル

組織構造に対してコンウェイの法則・逆コンウェイ戦略といった考え方がありますが、チーム単体とそこで開発するシステムの特性についても相互作用があると思っています。

プロダクト基盤で開発している IdP は、システムの特性として安心安全が求められ、止まると連携サービスすべてに影響が出てしまうので、品質に関しては慎重な姿勢をとっています。この方針はシステムの品質特性として明文化してチームで認識を合わせていることです。

同時に、それだけだと硬直的になりすぎるという懸念も感じています。リスクや手戻りが小さいような場面では、ガンガン進めたり、既定路線からはみ出した技術的挑戦があっても良いと思うのです。そのため意識的にあえて勢いづけるような言動をすることがあります。プロダクト基盤のメンバーは経験豊富で、本当にまずいところでは指摘してもらえるという信頼感があります。自分がうかつな発言をして、たとえそれはだめだねという結論になったとしても、暗黙的に「だめかもね」と思っている状態から、明示的に「やっぱりだめだったね」という認識が共有される状態に持っていけるとよいなと思います。

生産的な環境づくり

生産性には、チームの働きやすさやモチベーションが大きく関与すると考えます。前述した納得感はそれらに作用する要素のうちの一つです。私はEMとして働くうえで、チームメンバーそれぞれが働きやすく、モチベーションが湧くような環境を作れたらいいなあと思ってやっています。その中でも意識している価値観をパラパラ紹介してみます。

メンバーの好みやモチベーションを尊重する

内発的な動機を重視し、支援、後押しします。

我々は会社で働いているわけなので、会社の方向性に沿って成果を出せるよう努めますし、組織目標や個人目標もそれを反映した階層構造になっています。一方で、各メンバーが一番実力を発揮、あるいは蓄積できるのは内発的な動機付けがある部分だと考えているので、可能な限り実現できるようにしたいと思っています。そのために、そもそもどこにその動機があるのかを一緒に考え、どんな機会を作れたらそれが満たせるのかを考えるようにします。

チームの組織内の立ち位置によっては、全体方針の影響を受けやすく、自分たちで持てるレバーが少ない場合もあります。そんなときでも関係者と連携しながら、一定自由にできる余地を継続的に確保していくよう努めます。

また、基本的には細かなマネジメントはせず、大きい単位で裁量を持ってもらって、リードしながら課題をやっつけてもらうことを大切にします。なので、メンバーのキャリアラダーへの関わり方としては、成長支援というよりは背中を押すような形を意識しています。個別の課題への関わり方としても、アドバイスよりは別の観点を提供するとか、質問により考えを引き出すようにすることを目指しています。同様に、チームへのトップダウンな決定も基本的にしません。

もちろん、動機のベースラインとして、報酬・報奨による外発的な動機付けも得られるよう、目標設定・評価を適切に成果と紐付けるようがんばりもします。

感謝を伝える、ポジティブフィードバックを意識する

モチベーションの話にもつながるのですが、ポジティブフィードバックは最もカジュアルに行える成果への報奨だと思っています。私自身、改善点を指摘されるよりも良いところを褒められたほうがやる気になりますし、これが得意なんだなと気づくことができれば、じゃあ得意なことをどう活かして貢献しようかと前向きな気持になります。

一方でネガティブフィードバックについても、なるべくポジティブに取り組めるような形で伝えるようにしています。サプライズを少なく、なるべく早い段階で伝える、といった教科書通りなことも意識していますが、難しさを実感する日々です。フィードバック全般が難しい仕事だと思ってます。

普段は難しくても、評価面談のような場は落ち着いて相手のことを考えられます。それだけに準備に時間はかかってしまうのですが、良い機会だと思います。

文化を尊重しながら、変化を受け入れる

私自身は今のチームの立ち上げには関わっておらず、途中からチームに参入した経緯があります。そのため、チームがもともと持っていた文化やプロダクトの経緯などへの理解が及ばない部分があることを自覚し、文化の理解に努め、尊重しながら必要な変化を起こすように気をつけているつもりです。

必要な変化とは、課題解決に適した構造に向けてチームの仕事のやり方を変えることを指しています。そのためには、課題を適切に理解したうえで、適切な構造と、そこへの持っていき方を設計する必要があります。とはいえ、いつまでもウンウン悩んでいても物事は進まないので、ある程度の仮設を立てたら試してみるようにしています。失敗しても学びがあれば良しとします。

変化を起こすときは、突然やらないように気をつけます。なぜやるのか、どうやるのかを説明し、認識を揃えていきます。あらかじめ「こういうことで悩んでいるんだよね」という話ができていると、課題への目線を揃えやすくなると思います。同時に意見を求め、よりよい方法をチームで模索できるようにします。よくやるのは、たたき台となる具体案のドキュメントを作成し、オープンに意見を求める形です。たたき台により議論が促進され、その過程で納得感が醸成されることを期待してやっています。

このとき、一度の変更で大きく変えすぎないことが重要だと思います。やり方を変えるのは物理的・心理的にもコストがかかりますし、振り返る際は変数が少ないほうが検証しやすいためです。

また、新しいことを試そうとしているときは、やるための理由を補強するような材料を探そうとするバイアスがかかりがちです。目的と手段が入れ替わってしまわないか、注意しながら進めていきます。

話しやすい状態を作る

昨今では心理的安全性という言葉に馴染みがあると思いますが、よりシンプルに考えて、発言するハードルを下げることを意識しています。言いたいことが言いやすくなる*4ほど働きやすくなり、情報が行き交いやすくなるほど良いものをすばやく作りやすくなると考えているためです。新メンバーを受け入れたり他のチームと仕事をしたりする際にも立ち上がりやすくなりますしね。

また、我々のチームはほぼリモートで働いているので、その環境の特性上、自然にハードルが上がっていってしまうことから、意識的に状態を作るようにしている側面もあります*5

チームでは、コミュニケーションの接点を適切に設けることを意識しています。特に、リモートワークでは雑談も自然発生しませんから、不自然にでも場を設けることは大事かなと思います。チャット上での非同期的な雑談も発生しますが、同期的なやりとりの中でしか生まれない空気感や相手への理解というものを大事にしています。また、その際にはなるべくやり取りがスムーズに行われるように、雰囲気を和らげるような発言や、相づち、リアクション等を行うようにします。

EMから対メンバーでは、素直に、自然体で接するようにしています。そのほうが自分自身が楽であるということもありますが、何でも話してもらいたいためでもあります。また、自分としても弱音があったときに吐き出すこともよくあります。ただ、弱音の扱いは難しくて、ネガティブに作用しすぎないよう気をつけています。

納得感を得やすくするためにも、話しやすい状態は重要だと思います。明示的に意見できるようなタイミングを設けたり、いつでも発言してよいというメッセージを、冗長でもあえて伝えます。

他組織への情報提供や巻き込まれを行う

巻き込まれは一見チームのタスクが増えてしまうようにも思えますが、シフトレフトの考え方と同様に、早期に絡んでいったほうが問題が小さいうちに対応できます。結果、チームが働きやすくなると考えています。

そのためには他組織で何が起こっているか広く情報を集めることが大切だと思っています。逆に、他組織からの情報提供や巻き込みがあった場合は大いに感謝したいところです。

また、他組織の文化や背景への理解にも努めたいと思っています。これは構造の話と通じる部分があり、適切に連携するためには相互の構造を知る必要があるという考えからです。適切に理解できた結果、実は自分たちではなく他のチームや人に直接つないだほうが良い場合もあったりします。

1 on 1

1 on 1 は基本的には相手のための時間と考えています。なので、最初に話したいテーマを聞くようにしています。もし話題がなければフリーテーマの雑談タイムにすることが多いのですが、話している途中で「そういえば」と話題を思いつくこともあるので、雑談も侮れません。逆に、程々に話しても何もなければサクッと解散してしまうこともあります。

話す中で出てきた課題は、この場で解決したほうがよいもの、チームでオープンにやったほうが良いものに分けて考えます。後者は、メンバー自身にやってもらったほうがよいもの、EMがやったほうがよいものをその都度判断して、アクションとしてメモします。

1 on 1 は相手のための時間である一方で、EMが気付きをもらう時間でもあると思っています。情報収集や課題の相談チャネルのひとつとして、環境を整える足がかりになる機会として捉えています。

個人的な原則として、次の会議までのインターバルを挟むようにしていて、必要に応じて延長や次の準備ができるようにしています。これは最適化の観点では一見無駄なようにも思えるのですが、話題が盛り上がったときに無理に切ってしまうのはもったいないのと、自分がそこまで器用でないことから心の余裕をもたせて頭を切り替えられるよう設けるようにしています。このバッファで吸収できたことも実際に多く経験しています。

1 on 1 は割と個人的な本音で話すことが多いと思います。相手にも本音で話してもらいたいのです。もちろん、個人的な内容をエスカレーションする場合は了承を得て進めます。

心の持ち方構え方

最後に、EMとして安定的・継続的に働いていくための、自分なりの心の持ち方と構え方について振り返っていきます。先に申し上げておきますと、実務で経験したり、本を読んだり上司と話したりするなかで自分なりに合う方法をチューニングしてきた内容になるので、誰にでも適用できるものではないかもしれません。これはまあ前述の他の項目も同じなのですが、より属人性が高い内容になっていると思います。これからも悩みながらどんどん変化していくものではありますが、一例ということで参考になれば幸いです。

マネジメントスタイル

EMはロール

EMはマネジメントという専門性を持ったロールであり、権力や権威、階層とは独立したものだと考えています。組織上の上司部下のような関係性が機会的に紐付くことはありますが、仕事内容の多くはその関係性とは独立していると認識しています。さまざまな専門性を持つメンバーを大いに頼る形で仕事を進めることになりますし、一緒にものづくりをやっていくチームとして私はフラットに働きたいのです。逆に言えば、専制的なEMとして振る舞うことを私は苦手としています。

フラットに働くという意味では、チーム内外の誰を優遇するとか、誰の意見だけを重宝することもしないようにしています。何かの対立があったとしても、仲介者*6として振る舞い、味方にも敵にもならないようにします。これは良い悪いと言うか、そういうスタイルなのです。

とはいえ、弊社では組織上の管理職としても紐づくことが多く、現在私もそうなっています。最終的な意思決定者としてリーダーシップを持った振る舞いを期待されますし、成果責任も負っています。また、マネージャーというラベルでまわりから認識されることも気に留めておきます。

自分でやらない

実務上のタスクを取りすぎない、自分を戦力に入れない、ということに気をつけています。マネジメントの仕事をやる上では突発的なことはいつでも起こりえるので、手を空けられる状態にしておくのは大事だと思います。手を動かすときも突然割り込みが入っても良いように、なるべくブロッカーにならないタスクを選びます。目の前のタスクに気を取られて、全体の大事なことを見落としてしまってはEMとして本末転倒です。なるべく俯瞰でチームやプロダクトを見るようにします。なんなら、ちょっと暇なくらいがちょうどよいと思っています。なかなかそうはできないのが難しいところですが…。

似た話として、委譲も大事なテーマのひとつです。基盤チームでは、意図的に大きな単位でタスクやプロジェクトを個々のメンバーに任せるようにしています。委譲しきれずに仕事を巻き取ってしまうと、メンバーの挑戦の自由度を奪ってしまうことになりますし、自分の手も塞がってしまうので良いことがありません。また、今はまだうまくできていないのですが、このとき明示的な形で委譲の範囲を表現して渡していけるとよいなと思っています。デリゲーションポーカーみたいなツールを使っても良さそうです。

とはいえ、やれば進むがやれる人がいない、というときはサクッとやってしまうことも大事だと考えます。自分がワイルドカードになれるような心意気で構えておきます。

プレイヤーとしてバリバリやってきた方がEMになったとき、これはストレスでもあると思います。私は逆に保守的になってしまいタスクを取らなすぎたりと、うまくいかなかったこともありました。いまはマインドとして、個人のアウトプットにこだわらない、自分ができてないことを気にしすぎない、チームが前に進んでいればよし、といった感じで気楽にいようと思っています。

あえてやる

あえて質問する、あえて説明する、あえてやらなかった理由を話す、など、自分が不要かもと思ったことでもやるようにしています。人間、意外と前提認識が揃っていなかったり、伝えたことが正しく伝わってなかったりすることが多くあります。自分だけではなく、チームや関係者の認識を揃えたり不安を取り除くためにあえてやります。

これをやるのは単純に面倒だし、様々な不安もつきまといます。ウザいと思われるかも、無能と思われるかも、みんなに無駄な時間を取らせてしまうかも、みたいな不安が頭によぎりますが、あえてやります。情報の格差や認識に差があるまま進んで、大きな問題に発展したときに後悔するより良いためです。

この行動自体がポジティブな結果を引き起こすこともあります。他の人が新しい観点でアイデアを出してくれたりと、議論を促進する流れになったりもします。

私はまだ修行中でうまくできている実感はありませんし、疲れていたりすると全くできないときも多くあります。自分なりのコツとして、鈍感な人間になりきって不安のバランスを取っていることが多い気がします。あとは「気軽に聞いちゃうのですが」「〜さんは知っているとは思いますが」といった枕詞をつけて話すこともあります。

メンタルコントロール

モチベーション維持

EMは最初からEMとしてキャリアを開始するのではなく、プレイヤーから転向してEMになることが多いと思います。プレイヤーからEMに切り替わるときは、EMの仕事内容と一緒に、プレイヤーとは違うモチベーションの保ち方も身につける必要があると思います。

個人的には、プレイヤー時代から手を動かす比率が変わったことから、あまり手を動かせなかったとか、短期的なアウトプットが減ったという理由で、成果を出せていないとネガティブに考える時期がありました。

また、私は別の組織から異動して現在のチームのEMとして任用されたことから、自分の技術的な得意領域や今まで蓄積してきた業務知識から遠くなったことへのモチベーション維持が課題でした。状況としても外発的な責任による動機付けの割合が大きかったため、継続的にうまくやっていくためには内発的な動機の芽生えや自覚が重要でした。

意図的に内発的な動機を見つけるのは難しいのですが、自分にとってどんな仕事が楽しいのかを掘り下げ、共通項を見つけられたのが良かったと思います。私はプレイヤーだったとしても、色々なことを気にして交通整理したり、自チームやお隣さんの意思決定に関わる情報を提供したりすることはもともと好きな性格でした。そしてその背景には、自分ひとりではできないことをチームとしてやるとか、自分にない専門性を持っている人に良いアウトプットを出してもらうとか、チームのアウトプットの最大化をどうするかを考えていくといった、もともと感じていた潜在的な楽しみがあることに気付きました。

また、やっていると分かってきたこともあります。構造編で話したような、系に落とし込むといった自分なりの経験が考え方に活きているのを実感するタイミングもあり、モチベーションの糧にできそうだと分かってきました。

とはいえ、それでも苦手な仕事というのもあります。これは仕方がない。自分にとってはピープルマネジメントの領域がそうでした。実際いまも苦戦しているので、次項ではこれについて述べてみたいと思います。

ピープルマネジメント

自分には荷が重いと常々感じているのがピープルマネジメントです。特に目標・評価・査定についてはまだまだ悩みながらやっています。

そもそも人が人を評価することは難しいし、ストレスのかかる行為だと考えています。正解はなく、どうがんばっても一定の不条理が伴うなかで、納得感をいかに持てるところに着地させるかが大事な仕事でもあると思います。

それでもEMはこの責務を全うしなければなりません。そのためには、個人的な感情を脇に追いやって、人が人を評価するのではなく、システムが人を評価するのだと考えるようにしていました。チームメンバーの働きがシステムに適合し、成果を高く評価させるように補助するのが自分というわけです。そして、チームメンバーの良い成果を引き出せるよう努めることも大事ですが、評価・査定結果を悪い方向に考えすぎないことも大事です。

自分という個を排除するのは、自分を棚上げして第三者としてメンバーに高い期待を設定するためでもあります。私はつい自分自身の発言に対して「偉そうに何言ってるんだろう」と思ってしまうことがあります。それぞれ専門性や技術力は違うのは当然のことであり、いちロールに過ぎないEMが全能を司るわけにはいきません。個を排除し、課題に対する期待をシステム的に設計するようにしてなんとか克服しています。

また、メンバーにモチベーション高く働ける機会を提供できているか心配になることもあります。もちろん杞憂であるとよいのですが、もしそうでなかったとしても、EM単独で機会を作るために動けることはかなり限定されます。またこれに限らず、EM単独ではどうにもならないことは多くあります。そんなときは自分のコントロール外にあることを自覚した上で、上司とともに話していきます。そして機が熟すのを待ちつつ、一時的に忘れます。

無責任のようにも見えますが、「忘れる」は継続的にEMとして働くための一つのテーマのように思います。メンバーや組織の秘密を抱えることもあります。すべてを常に抱えていると簡単にメンタルをやっちゃいそうです。もちろん何でもかんでも忘れていたら仕事になりませんので、どうやったら道理にかないながら忘れていけるのかを考える仕事になるのだろうなと思います。

一息つく

1 on 1 や各種面談、その他ミーティング前に、なるべく一息つく時間を設けるようにしています。バタバタしてできないことも多くありますが、ちょっとでも一息つけるようにします。業務上どうしてもスイッチングが多くなりがちで、それにより一日のなかでどんどん疲労が溜まってくると、会話を集中して聞くことや、適切な思考ができなくなるためです。これにより自分の状態をニュートラルに戻すことができる気がします。特に前日の疲れが持ち越しているときなんかは、なおさら意識しています。

このとき自分にとってリフレッシュできる方法があるとよいと思います。私は観葉植物に霧吹きしたり、ちょっと長めに時間がとれるときは趣味のコーヒーを淹れたりしています。

似たような話で一日のルーティーンを作ると良いというのも聞きますが、私にとってはまだうまくいきません。習慣化することはどうにも苦手なのです。それもあって、イベント駆動で細かくルーティーン的な動作を入れる感じにしています。

定量指標に一喜一憂しない

プロダクト開発にはベロシティやデプロイ数といった様々な指標があります。この指標は案外厄介で、目的化してはいけないと頭ではわかっていても、にらめっこしているうちにいつの間にか心理的にそうなりがちです。指標は複雑な現実を一つの方向で切ったものに過ぎず、いつもすべての物事を正しく反映しているとは限りません。それが下がっても上がっても惑わされずに、着実に必要なことはやるのだ、といった具合で繰り返し自分に認識させています。

一方で、指標は役に立つツールでもあります。こういうときにこの指標を見る、というパターンは蓄積したいし、一定のタイミングで振り返る際にも有用です。まだ満足にできてませんが、これから充実させていきたいツールだと思っています。指標を遠ざけず、かといって依存もせずに、チームの状況や課題に有効な指標を探し、使いたいときに使える状態にしておきたいものです。

板挟みになったとき

EMというか中間管理職の話題ですが、まあまああります。構造上なんらかの活動の中間にいる人間はどうしても存在します。しかたない。これは割り切りです。

板挟みという言葉は主観的な言葉で、かつネガティブな響きがあります。板挟みになった本人にとって大変であることに間違いはありませんが、解消できればポジティブに作用するものもあります。板挟みとまではいかなくとも、仲介者として話を整理するようなこともあります。反対に、タフな話題もあるにはあります。どうするのがよいかはケースバイケースで、振り返っても何が良かったのかもわかりませんが、あまり考えすぎるとやられちゃうので、正解はまずないと思っておきます。

ありがちなのが、現場と上位レイヤーとの情報格差の問題です。これは構造の話でもありましたが、自分がエフェクターとしてうまく働くことになります。エフェクターとして働くために必要な入力が流れてこないときは、がんばって流してもらいます。流れてこないのは構造の問題なので、上流側にかけあったり、上司に相談したりします。

多くの場合、関係者の話を聞いてその都度解釈をしなおして伝えてということを繰り返して着地点を探ることになるのかなと思います。それぞれの目線で見えているものが違うので、目線合わせをして見える範囲を広げつつ納得感を作っていく感じです。

個人的にはフラットに考えるタイプだと思いますが、レイヤーが上の関係者に対しては、現場の言葉を反映できるのは自分だと考えて意図的に現場の味方として発言をすることがあります。むろん相手のレイヤーにしかない合理的な言い分があるのを理解した上でぶつけてみる感じです。そのうえで妥当性の判断は上のレイヤーに任せるようにしています。粘ることもありますが、一時的にでも手放すことができると、自分の心の安寧に繋がります。

不安と付き合う

大体の人がそうだと思いますが、同様に私も不安とともにEMをやってきました。笑顔を装いつつ緊張しながら脇汗かいているなんてときもあります。そんな状況では効率的に仕事を進められないので、うまく不安と付き合っていく必要があります。メンタルコントロールに内包されうる話題ですが、大きなテーマなので切り出してみました。

こんなことに時間をかけていて大丈夫だろうかという不安

まさにこの記事を書いている瞬間がそうでもあるのですが、自分がかけた時間に対して自信がもてなくなることがあります。これはロールによらない話ではありますが、特にEMは成果が目に見えづらいことに取り組むことも多いので、そういった不安を感じる瞬間が多いように思います。

書籍「HIGH OUTPUT MANAGEMENT」の言葉を借りると、いかに「テコ作用」のはたらく仕事をやるかということになると思っています。チームやその外のアウトプットを効果的に上げると信じられる仕事に、時間をかけて取り組みます。

たとえばキックオフなどの多人数が参加する会議の準備は、ちゃんと設計すれば参加する人の時間を節約できるばかりか、得られる成果もより大きくできる余地があります。時間をかけたときとかけなかったときの差を比較できるものではないので、振り返って評価は難しいのですが、少なくともグダグダになってしまい多くの人の時間を無駄にするようなことを防げただけでも効果はあると思います。

そしてこの記事は、池田さんやその他の社内のEM/マネージャー、または復職後の未来の私にとって高いテコ作用があることを期待して書いていると言えるでしょう。かけた時間に見合った良い作用があるといいなあと切に願っています。

リモートワークに伴う不安

リモートワークの良さを活かすには、リモートワークに適応して働き方を変えていく必要があります。我々のチームはここ数年でだいぶ適応できてきて、それぞれの在宅環境も整ってきたこともあり、今ではオンサイトで働くよりも効率的に働けていると感じます。リモートワーク特有の課題としてコミュニケーションの取りづらさがありますが、これも適応したコミュニケーションの取り方に変えていくなかで、それなりに上手くやれているのではと思っています。

ただし同期的なコミュニケーションにおいては、通信に使うビデオチャットツールの制約に縛られることはやむを得ません。特に、聴覚・視覚的フィードバックの乏しさやそれに伴う話しづらさから、ちゃんとコミュニケーションできているのだろうか、という不安を私はたびたび感じてきました。

他に不安に遭遇する場面は、なにか発言したり質問したりしたときに期待した反応が得られず、無言で気まずい時間が続いてしまったときです。そうしたとき、何か良くないことを言ってしまったのだろうか、あまり関心を得られなかったのだろうかと、私は無用な不安にかられてきました。

これはビデオチャットツールの制約をあらためて認識し、考え方を変えることで受け入れることができました。皆が好んで無言の気まずい雰囲気を作っているわけがないのです。オンサイトでは相手が悩んでいるとか頷いているといった細かなフィードバックが得られますが、リモートワークではそれが十分に得られません。また、自分がファシリテーションをしていると気付きづらいのですが、ビデオチャットでの発言にはオンサイトでの発言よりも高い心理的ハードルが存在し、思うことがあっても発言に至らないことがあります。特に、肯定の意をわざわざ伝えるためには強い意志と自信が必要です。

これを理解した上で、無言は異論なし、と割り切ってしまい、過度に不安を感じないようにします。もちろんジュニアなメンバーがいて発言をうまくできない様子なら、それを促すようなフォローをしたほうが良いのですが、弊チームにはベテランが多いため、何か問題があれば適切に表明してもらうことを期待できます。

一方で、リモートワークに限らず、質問の方法が不適切だと回答自体の難易度が上がってしまうことがあります。「問いかけの作法」という書籍では、問いかけは未知数を照らすライトという比喩が用いられていて、膝を打った覚えがあります。チームの反応を見て「ライトを当てたところには何もなかったんだな」とか「ぼやけたライトを当ててしまったな」と解釈して、それではこう聞いたらどうだろう、と別の質問を試してみるのです。私はなかなか冷静にできないことも多いのですが、質問方法を変えるというオプションを持っていると楽になる場面があります。

自分の不安とチームの不安

スタートアップではガチャガチャ組織やプロダクトが変わっていくものですが、カオスの中にいる状況ゆえに、なかなか情報が入ってこなかったり、投げたボールの状況がわからなくなったりすることがあります。

こうしたとき、先行きに対する不安や、計画が立てづらいことへの不安が募っていきます。加えて、EMである自分に比べてチームメンバーは情報を得づらい状況で、もっと不安に感じているのではないかと考えることがあります。私にとってのこの不安は厄介で、チームメンバーが不安に感じているかもしれないという不安を受けて、自己強化的に不安を増幅させてしまう傾向があります。

もしかしたら過剰な心配で実際そんなことはないのかもしれませんし、自分が情報を多く持っているからこそ感じる不安なのかもしれません。しかし、チームに情報を持っていく、もしくは持っていくことを促せる立ち位置にいる以上、自分の不安をセンサーにして、チームメンバーにとってどうなのかを考えることは大事です。

こうしたときは、地に足をつけてチームの不安を測っていくと、落ち着いて判断できるのではないかと考えています。ミーティングや 1 on 1 等で認識を合わせつつ、チームにも不安が生じていそうなら、解消するように動けると理想的です。

孤独感

塩谷さん (@kwappa) の記事によく言語化されているのでそちらを読んでもらうのが良いと思いますが、孤独を感じる瞬間があります。

エンジニアリングマネージャーが手懐けるべき荒ぶる四天王 - STORES Product Blog

構造上EMというロールは少なくなりがちで、置かれている状況次第で仕事内容も変わるため、自分の働き方や課題感を相談できる人は多くありません。また、メンバーの個人的な悩みや、組織上の未公表の情報などを抱えたり、秘めておくべき本音もあるので、誰にも言えないモヤモヤが募ります。

私はこれを悪化させると、自分の居場所がないとさえ感じるようになります。実際に居場所がないわけではないのですが、不安からそのように感じてしまうようになるのです。ゆえに、なるべく一人でモヤモヤを抱えないことが肝心だと思います。

レポートライン上の上司であれば言えることも多いため、まずは上司に共有するようにします。メンバー個人のことには上司に言わないようにしている内容もありますが、ひとりで抱えるものを減らしていくことで心の重荷を下ろしていきます。

また、前述したような「うまく忘れる」ことも有用だと思います。上司に渡したり、TODOに書き出したりして、必要なときに思考を再開できるようにしつつ、忘れてしまえるようにします。

おわりに

構造を作ること、環境を作ること、そしてEMとしての心持ちについて書きました。私自身がいつもうまくできているわけではなく、大切に思っていることについて整理した内容になります。

育休にあたってようやくまとめたため、掘り下げや裏付けが十分でない部分もあるかと思いますが、自分なりの考え方を整理する機会となってよかったと思います。また、その過程で自分の奥底にあった価値観を引っ張り出し、新鮮な気づきも得られました。

長期間職場を離れることに加え、子供を育てることに対する不安もありますが、仕事に関しては頼もしいチームのみんなに任せられて感謝しています。しっかり復職できるよう家庭の体制を整えて来ます。そして、復職後にパワーアップしたチームおよびプロダクトと働けることを楽しみにしていますし、そのとき自分がこの記事を読んでどう思うのかも楽しみです。

以上、長くなりましたが、この記事を読んでくれた方にとって、なにか得るものが一つでもあればうれしく思います。

*1:この記事は育休突入後に投稿してもらうようお願いしています

*2:私はどちらかというと感覚的な人間なので…

*3:適当な思いつきを言いますが、なんとなくサウンドエフェクトみたいにディレイかけてフィードバックさせた結果印象的な音が出るみたいなこともある気がしますね。繰り返し表現を変えて伝えるみたいな感じで

*4:当然のことですが、利己的な発言を歓迎するのではなく、むしろ全体が発言しやすくなるようなアサーティブな表現を歓迎します

*5:もちろん、別のメリットを選択してリモートワークをしているという前提です

*6:そういえば、16Personalities で私は毎回仲介者だったことを思い出しました。今やってみたらまた同じ結果でした