エムスリーテックブログ

エムスリー(m3)のエンジニア・開発メンバーによる技術ブログです

令和最新版エンジニアのリーダーシップ論

組織 AdventCalendar

エムスリーエンジニアリンググループ製薬企業向けプラットフォームチーム（「Unit1」）の三浦 (@yuba)です。乗り物大好き男の子ですので好きなテレビ番組は銀河鉄道999とナイトライダーです。

さて「フラットな組織」だとよく言われるエムスリー、特にわがエンジニアリンググループなのですが、そのフラットってどういう感じなんでしょう？　上意下達の体制でない中では、人々はどう組織としての目標を共有して一緒に動いているんでしょう？
この疑問への、（管理職でない）一般エンジニアとして5年半やってきた私なりに得た答えをご紹介したいというのが今回のお題になります。これは エムスリー Advent Calendar 2022 の5日目の記事です。前日は id:hsasakawa による グローバルサービスの開発における技術的な意思決定 - エムスリーテックブログ でした。

そしていきなり最初に結論から言ってしまいますと、チームでの仕事で人々はみな、相互にリーダーシップを及ぼしあっているのだと理解できます。
はい、わかるようなわからないような答えですね。そこで、リーダーシップをその「及ぼしあう」ってどういうことか？　掘っていってみましょう。それは、実際に私がやってチームを前に進めた手応えがあった、つまりリーダーシップを及ぼすことができたぜ今と感じた言動をご紹介することで説明を試みようと思います。

令和の幕開けとともにリモートワークの急激な普及で非同期コミュニケーションはSlackなどチャット、同期コミュニケーションはZoomなどTV会議が一般的になってきました。そういう新しい環境でのチームコミュニケーションの参考にもなれば幸いです。

ボールを浮かさない

Slackで何か課題について話し合っていて、スレッドが止まってしまった経験、ありませんか？
「そういえばああいう問題もありませんでしたっけ？」「ああ、そういえば⋯⋯」を最後に発言がストップ。そのまま忘れ去られ、数カ月後に実問題発生、この件ってどういう経緯になっていたっけ!? とログを掘ってみたら、ああ、そうかスレッドが止まって宙に浮いたままだったんだ⋯⋯　これ、考え得る限り一番残念なルートです。

何度か経験していれば、スレッドの会話が止まりそうな雰囲気はわかると思います。もしくは本当に止まってしまったら、そうしたら、ボールをとにかく誰かに持たす。
自分が持つならシンプルに「この件、私が宿題にしますね」（ここでSlackのブックマークボタン打つの忘れずに！）
誰かに持ってもらうなら「私や開発チームでは今できることはなさそうです。〇〇さん、ご調整をお願いできますでしょうか。」

誰に持ってもらうかも決めづらければ「どなたか本件を持てませんか？」でも100点です。
ボールが浮いていることの認識を人々が共有できただけで有益ですし、次のステップは適切な担当者を決めることだとはっきりしました。大収穫です。チームは一歩進みました。

自分が全然ボールを取らないでもいいんです、人々にとってストレスなのは何をしていいかわからない、手を出していいのかどうかよくわからないみたいな状況です。その不安な状態を解消してくれただけで大満足、大感謝ですよね。

解散の目安をはっきりさせる

深夜の急なトラブルで眠い目をこすりながらZoomに集まった担当エンジニアたち、もちろんトラブル解決のために懸命ですが、一方でみんなこう思っています。
「いつこれ終わって眠れるんだろう⋯⋯？」

みんな懸命だからこそ言い出しにくいこの疑問、はっきりさせられる時にはっきりさせるのもチームを動かす一言だと思います。
「今夜のところは〇〇して出血を止めるところまでして、ログを確保したらあとは明日ってことでいいですかね？」
いやもっとシンプルにこれだけでいいですね、
「今夜中にどこまでやります？」

これは緊急対応でなくても、Zoom会議の終わりが見えなくなったときにも有益な一手でしょう。
「〇〇決めるところまで同期でできたら、あとは非同期で続けます？」
「今どこまで決めます？」
会議の終わりが全員に見えます。対応作業でも会議でも、見えているゴールがあってこそ有効な手を考えられる局面は多いです。チーム、動かせています。

関連部署に伝達する、ただ騒ぐ

システムトラブルが発生したとき、担当者もチームも、発生したトラブルの原因や復旧方法に意識が集中します。
それでまず状況を伝えるべき関係者、営業部門やカスタマーサポート部門への連絡が後回しになってしまったことはないでしょうか？　怒られるんですよね。あれだけ懸命に対応してシステムの危機を救ったのに。でも連絡が漏れていたのは事実だから反論もできない。このトリプルパンチの辛さ、わかる人はわかるはず。

トラブル対応に誰かがとりかかったら、すかさず
「営業とCSとPdMに連絡しますね」
そして、こんなメッセージを投げましたとSlackリンクをこちらにペタッ。

これだけで対応担当者は心置きなくシステムに集中できます。その後も進捗を随時流すのを引き受ければ、対応担当者はわかったことややったことをエンジニアの言語でつぶやき続けるだけでいいので負担はかなり減らせますね。

連絡先がわからなくたって、詳細がまだ全然まとまっていなくたって、事業部門全体チャンネルとかエンジニア全体チャンネルとかで
「数時間前から〇〇のエラーが上がっています。会員影響出ている可能性ありです。わかる方応援願います。また連絡先に心当たりの方も教えて下さい。 #XXXX チャンネルで会話しています。」
と識者探しも連絡先探しも出来てしまえますね。なるべく広く騒いでトラブル対応の責任を担当者一人に抱え込ませない、これで担当者は相当心が楽になります。もっと適任な担当者に交代できるかもしれない。チーム、動かせています。

絶賛する＆なぐさめる

大手柄や大発見、ナイスキャッチや労作、そうでなくても何かチームのための一手を放ってくれた人にはすかさず
「すごい」「仕事早い」「神」「やはり天才か」「さすが〇〇さん」「圧倒的感謝」「🎉」
大絶賛を浴びせます。Slackなら絵文字リアクションの山にして差し上げます。
ちなみに「さすが〇〇さん」絵文字はチーム全員分すでに作って登録済みですよもちろん。

反対に失敗してしまった人には⋯⋯？
「ドンマイ」「無問題」「仕事たくさんしてる証拠！」
とにかく落ち込まないようになぐさめて励ましてあげますよね。嘘でなく本当に、失敗するのは仕事してる証拠ですし。

気分が良くなるような声掛けをしてチームの雰囲気を良くするのは間違いなくチームを動かしていることですし、しかもそれって上長ひとりがやるようなことではなくてメンバー全員ができることですよね。しかもやってみればわかりますが、声をかけた本人も気分が良くなるんです。

ドキュメントを書く

職場で誰かに何かを説明したなら、それはすでにドキュメント化不足だということです。説明しないでも読んでおいてもらえばいいドキュメントが本来必要だったということです。だったらそれを書く、今書く。それは単なる作業ではなくて非同期のチーム内コミュニケーションでしょう。

ドキュメントを書くにあたって私が心がけているのは、「2方向から書く」ことです。2方向とは⋯⋯

  • それが何物なのかを理解するための体系的な解説。概要から始まり詳細へ進む解説。whatだけでなく、それができた背景にあたるwhyやwhy notも重要です。
  • いまどうしていいかわからなくて困っている人のためのハウツー。正常系の操作手順、あとはよくある対応のケーススタディを。

どちらが動機で読む人にも役立つように、また、2方向から読むことで立体的にイメージを持てるようにです。全体を理解しようとするときに概要・詳細説明だけでなく実操作やケーススタディを見ると具体的なイメージが湧きますし、対応方法を知ろうというときにその操作が何をしていることなのかも併記してあれば自信を持って操作できます。

チームはもはやこの件で「説明」を必要としなくなりました。ドキュメントのURLを渡すだけ。それは単なる時間節約だけではありません。皆がどこまで知識を持っているはずかという水準まで共有できるようになりました。

チケットを立てる

会話の中で「あれ、問題ですよね」「はい、本当に」となることがあります。
それをシュッとチケットにします。

いまチケットにしなければ、秒速で揮発してその問題認識は忘れ去られていました。そしてもう何回か同じ会話をしてそのたびにデジャヴュを感じることを繰り返しているだけでした。
チケットにしたことでチームはループを抜け出しました。おめでとうございます。

全然わからないと言う

相談したいけど誰に聞いていいかわからず困っている人、質問しているけど誰からも回答がつかず困っている人がいる。
しかし、自分もその件は全然わからないし適切な相談先もよく知らないんですよ⋯⋯　ってことは、自分には手助けしようがないでしょうか⋯⋯？

「全然わかりません。気になりますね」
とお返事するだけで相談者にとっては全然意味があります。無視されているのではなく、少なくとも一人は同様にわからない、それだけで重要な情報です。
Slackヘビーユーザーなのでもちろん「全然わからない」「気になる」絵文字は登録済み、まあ毎日のように打ってます。

「わかりません」という回答が複数付き始めれば、チーム全体にとっての困りごと、調査タスクへと変わっていきます。
そうしたらボールを誰かに渡すの術が使えますね。「調べて、わかったら教えていただけませんか？」と質問者本人にボールを渡すのでもいいんです。「わからないことがあるのに誰も教えてくれない」のと「誰もわからないことを自分が調査する」のではもう質的に全然状況が違いますよね。はっきりと前へ進めています。

コードレビュー、しにくいことを伝える

エンジニアならではの仕事上のハマり方、それが、期限のある仕事なのにコードレビューを誰もしてくれなくて先へ進めないというのがあります。
それがわかっているから、自分もなるべく同僚の開発をコードレビューするように心がけるわけですが、複雑だったり難解だったり量が多かったりするやつはどうしても後回しになりますね。そして、他のメンバーも皆そうします。そして、開発を書いた同僚はコードレビュー進まない地獄につかまります。

後回しにするのは一回ぐらいしてもいいですが、もう一回見たとき後回しにしたくなったら、言いづらいけれど勇気を持ってコード書いた人に
「難しすぎて読解できずにいます」
とお伝えすべきでしょう。本人だって、コードレビュー依頼を無視されているのと、してもらえているけど難渋中なのとでは状況がぜんぜん違うので、それがわかるだけで大いに有益です。

レビューしたくても難しくて詰まっているということなら、Zoomで解説会をやるとか、改修をスモールステップにわけてレビューしやすくするとか、いくらでも方法がとれるようになるのです。そう、チーム、動かせました。

他には？

他にもいくらでももちろんありますとも⋯⋯！　いざ文章にまとめ始めると浮かばないだけで。
ただ、チームの人の足が止まらないように、手が止まらないように、困ってしまわないように、孤立してしまわないように、というのを意識すれば局面局面で生きてくる一言、一手が無限のバリエーションで導き出せると思います。あなたの打った最高の一手、教えてください。ブクマコメントでも、アンサー記事をどこかで書いていただいたりでも。

We are hiring

さてここで自分語りさせていただいてよろしいですか。
私、元々はリーダーとか管理職とかになるのがイヤで、何十歳までもいちプログラマとして仕事していたくて、それで「フラット」なエムスリーを選んで入社したという経緯があります。しかしそのフラットな中で仕事をしているうちに「仕事してる人は全員最初からリーダーなのだ」ということに気付いてしまい、それでむしろリーダーという働き方に興味を持つことになってしまったのでした*1。

本稿をお読みの方にも、いろんな環境の職場の方がいらっしゃると思います。しかしどんな環境かにかかわらず、それこそ上意下達こそ第一のところだとしても、依然として「仕事する人は誰もがリーダー」なのは普遍的な真実だと思います。自分のミッションを達成するために組織に何らかの働きかけ——それこそ質問でも報告でも、「根回し」でも——をしているんですからね。

それでも、本格的にフラットな組織で水平方向のリーダーシップを発揮し放題というお仕事環境というものにももし興味が少しでもあったら、私達とちょっとお話ししてみませんか。
いきなり応募するのを前提にしない、そういう興味があるところについてだけ聞いてみたいってお話ができるカジュアル面談、やっています。こちらのページからどうぞ。

jobs.m3.com

*1:こうした心境の変化もあって、先頃「チームリーダー」の職をついに拝命しました。この原稿自体はそれより前、一般エンジニアだった時点で書き上げたものですけどね！