情シスのマネージャーにジョブチェンジしてソフトウェアエンジニアのもつ良い文化をチームに取り入れている話

この記事は hey アドベントカレンダー2020 の23日目の記事です。

hey の ITチーム（いわゆる情シス）のマネージャーをやっている @howdy39 です。
4月に STORES のフロントエンドエンジニアから hey の ITチームに社内異動して、7月にマネージャーになったばかりの新米マネージャーです。

もともと hey の ITチームは（人が少なかったというのもあり）マネージャー不在でチームとしてうまく機能していませんでした。なんとかしたいという気持ちでマネージャーを引き受けたものの、マネージャー経験ないし全然わからん、どうしたものかな…と当初は本当に頭を抱えていました笑

この半年間を総括するとチームをより良くするためにどうすればよいかを考えては実行してダメだったら修正して…のトライ＆エラーをずっと繰り返し続けた半年間だったと思います。

それがいまではITチームのボスであり hey の副社長でもある @naokos に「ITチームすごく良くなった」と言われるぐらいになりました。

もちろんチームが今の状態になるまでにはチームメンバーの多くの助けがあり、私自身まだまだ未熟なマネージャーではありますが、半年間マネージャーをやってきてマネージャーという役割に対する私の価値観がある程度固まってきた気がします。
その価値観を発信することで、これからマネージャーになる人や現在マネージャーとして何をすればいいのか悩んでいる人に向けてすこしでも助けになれれば幸いです。

チームの生産性をあげるにはまず心理的安全性をあげる

マネージャーの仕事でいちばん大切なのはなにかと言われたら、チーム（組織）の生産性をどれだけあげられるか だと思います。
言葉にすればたったそれだけ。しかしこれが難しい。本当に難しい。

そしてチームの生産性を上げるためには、高い心理的安全性と、高い目標の両方が必要だと私は考えています。

図にするとこんな感じです。

ほとんどのチームの場合、心理的安全性をまずあげて、楽しく仕事できる状態、雑になんでも話せる状態、否定的なことでも言いやすい状態を作っていくのがよいかなと思います。心理的安全性を高くすれば、いろいろな施策がやりやすくなりますし、なによりチームが良くなる実感がわきやすいためです。

そのため心理的安全性を上げた後にストレッチ目標を設定して適度にプレッシャーをかけていく感じのルートがいいと思います。

心理的安全性をあげるには

心理的安全性には大きく一対一と一対多があると思います。

主に次の関係です。
一対一： マネージャーと各メンバー
一対多：メンバーと他のメンバー

それぞれどのように心理的安全性をあげていくのかを考えていきます。

1on1 で心理的安全性をあげる

マネージャーと各メンバーの心理的安全性は 1on1 であげていきます。
で、これがめちゃくちゃ難しいんですよね。
そもそも 1on1 ってブラックボックスじゃないですか。
同じ会社だったとしても他のチームの 1on1 って見れないし公開もされないんですよ。
また、同じ会社であるがゆえに下手にマネージャー同士で話してしまうと誰の話をしているか推測できてしまうのでとても難しいです。

なので 1on1 に関する本 を読んだり、1on1のイベント に参加して他の人がどういう 1on1 をやっているのかを学んでいくことがおすすめです。

チームビルディングで心理的安全性をあげる

メンバー同士の心理的安全性は何らかの共同作業（チームビルディング）であげていきます。
チームビルディングはゲームやイベントやワークショップなどいろいろありますが、私のチームでは わいわい勉強会を週一ペースで行う ことを柱に据えています。

わいわい勉強会のお題は、普段の業務で触っているサービスについての解説だったり、ネットワークなどの技術的な知識だったり、業務フローだったりなんでもありです。「〇〇さんに〇〇を解説して欲しい！」「このサービスについて話したい！」のようにきっかけも自由にやっています。
情シスはやることの幅が広いためネタがつきないのも相性がいいですね。

スキルを身に着けつつ属人化をなくしてチームビルディングまでできるのでかなりおすすめです。

1on1で点から線へ、チームビルディングで線から面へ

心理的安全性を高めるのは、1on1 で点から線へ、チームビルディングで線から面にするようなイメージで行っています。
どちらも並行で行っていますが、どちらかといえば1on1を重視したほうがいいかなと思います。
1on1 で「〇〇についてよくわからないんですよね。」みたいな話を聞けたら、じゃあわいわい勉強会で〇〇さんに教えてもらいましょう、みたいな流れをつくれます。また、メンバーの性格や知識などをマネージャが把握していれば、チームビルディング時のファシリテーションがしやすくなります。

評価（フィードバック）はアジャイルで

私のチームでは次のように3種のフィードバックを行うようにしています。

・毎週の 1on1
・毎月のフィードバックをまとめたテキストの共有
・半期の評価面談

1on1 で先週分のよかったことやよくなかったことのフィードバックを細かくします。
月ごとのフィードバックのサマリーをテキストにがっとまとめてメンバーとITチームのボスである @naokos に共有しています。
そして評価面談時に月ごとのサマリーをみて参考にする感じです。

細かくフィードバックすることで、方向性の修正もしやすくなり評価者と被評価者の評価認識のズレも減らせます。

めちゃくちゃ頑張ったのに全然評価されなかったとか、何を期待されているのかがわからない…って人多いんじゃないかなと思いますが、そういうのなくしたいんですよね。

また評価（査定）は、給与が上がった下がった変わらなかった、だけじゃなくてお互いが納得感を持てるようにしたいのでフィードバックは丁寧にやってくとよいと思います。

※ こまかくフィードバックして軌道修正するのはソフトウェア開発の世界にあるアジャイル開発の概念を持ってきています。

ペア作業・モブ作業の導入

ソフトウェア開発の世界では通常1人でやるプログラミングをあえて複数人で行う文化があり、ペアプロ（2人でプログラミング）やモブプロ（3人以上でプログラミング）と呼ばれています。
これは後から他の人が確認するよりその場で確認もセットでしてしまうことで巻き戻りをすくなくするとか、他の人が知っているやりかたを学んでスキルアップに繋げるとかいろいろなメリットがあります。

この文化を今のチームにも適用しています。
例えば オンラインホワイトボードツールである Miro を使って今の業務フローを書き出すときにペアで作業したり、システムの重要な設定変更を全員（モブ）でおこなったり、みたいな感じです。
ペアやモブでやることで、効率がよくなったり、作業ミスを減らしたり、属人化を防いだりのメリットがあります。

これは1人でやるより複数人でやったほうが良さそうだなーと思ったときは積極的にペア作業・モブ作業をやるとよいんじゃないかなと思います。

マネージャーにしかできないことを優先してやる

ここからは心理的安全性をあげる以外にどのようなことをマネージャがやるべきなのか、私が思っていることを書いていきます。

私はプレイングマネージャーなので、マネジメントだけでなく実作業もします。
そのためマネージャー自身がやってしまう方が早い場合も多々あり、「あーそれ私の方でやっちゃいます」とかやりがちです。

ですがマネージャーじゃなくても出来ることは可能な限りメンバーに任せて、マネージャーにしかできないことを優先しなければいけません。

自戒の念も込めてマネージャーにしかできないことをいくつか書いていきます。

情報の整理と伝達をする

確定ではないけど検討中の情報などが、経営層や別チームからマネージャーに先に降りてきます。特に hey の場合はスピード感がすごいのでこれは本当に多いです。

降りてくる案件に対するやれるやれないのジャッジだったり、やるとしたらどのタイミングに差し込んで誰にやってもらうなどを考える必要があります。
依頼を受けた際に、「メンバーに確認します」とか言ってたら、自チームがスピードを落とすボトルネックになるのでこれは避けたいです。

そのため、今のチームのスケジュールやリソースの空き状況を常に把握し、あの案件があるからこのタイミングまでにはこれをやっとかないと、みたいなことを常に頭に入れといて、なるべく即答できるように情報を整理しています。

またこれらの情報を適切なタイミングで適切なメンバーに伝達するするのも大事かなと思います。確定でない情報をメンバー全員に伝えても混乱するだけですが、伝達しないのも問題です。

そのため情報の整理と伝達が大事かなと思います。

情報量の違いによる長期の目線と意思決定

長期の目線はメンバーでも持てるし持つべきではあるのですが、持っている情報の数も種類もマネージャーのほうが圧倒的に多いので、未来を見据える精度が違います。
なのでマネージャーがちゃんと長期の目線を持つ必要があるかなと思います。

また、メンバー自身が意思決定を行うのが難しいケースが多々あります。これは持っている情報量の違いや、チーム全体に影響するような場合に、自身でジャッジしていいか迷うためです。
そのため「〇〇にしましょう」のようなマネージャーによる素早い意思決定や「責任は私が取るので〇〇さんが決めちゃっていいです」のような意思決定の委譲をして、どんどん前に進めていく必要があるかなと思います。意思決定の遅さがボトルネックにならないようにしたいです。

否定をする

意思決定と被る部分もあるのですが、否定することが大事だと思ってます。

メンバーのやりたいことと、組織としてやらないといけないことが違うときってありますよね。メンバーのやりたいことがマネージャーである私自身も納得できたとしても、組織全体を考えると今やることじゃないよね。みたいな否定をしなければいけないことがあります。

他のチーム（組織）からの依頼や相談も同じで、「ごめん、今はチームにリソースないから無理！」と言わないといけないこともあります。なんでもかんでも引き受けているとチームが崩壊してしまいます。

前者は組織を守るための否定、後者はチームを守るための否定です。マネージャーは組織とチームのバランサーにならないといけません。どちらかに偏りすぎてはいけないし、肯定だけしていてもいけません。

マネージャーとしての仕事の中で私が嫌いなのはパッと思いつく限りこの否定をすることだけだったりします。すまない…という気持ちになっちゃうんですよね。
もちろん否定とその根拠はセットで伝えるようにしていて、多かれ少なかれ納得はしてもらっていると思いますが、相手も自分も happy にならないので嫌いです。

メンバーのキャリアとちゃんと向き合う

career の語源って 馬車の車輪の跡（わだち）から来ていて、そこから人が辿る足跡や経歴などを意味するようになったらしいです。
一般的にキャリアって仕事の経歴のことを指しますが、広義では人生そのものなんですよね。

マネジメントするメンバーって20代30代がほとんどになるだろうし、その時期って仕事もプライベートも人生で一番大切な時期だと思います。

仮に5年いたら人生で一番大切な時期の5年になるんですよね…
それを考えたら「メンバーのキャリア（人生）になんて興味ない。」と投げ捨てるのは私には無理です。

メンバーひとりひとりのキャリアとちゃんと向き合って将来どうしたいのか、どうなりたいのかを一緒に考えたいし、一緒に悩みたいし、応援したいです。

あとメンバー個人の生産性を考えたときに、プライベートって切り離せないんですよね。
家族関係だったり友人関係だったり生活習慣だったり健康状態だったり、仕事のパフォーマンスっていろんなプライベート要因で大きくかわるじゃないですか。
根掘り葉掘り聞くことはしないけど、話してもらえるだけの関係性の構築なしに本当の意味での仕事のパフォーマンスって出せないと思うんですよね。

だからメンバーのキャリア（人生）とちゃんと向き合う必要がマネージャーにはあるんじゃないかな。

マネージャーになる（なった）あなたへ

なんか伝えたかったことをささっと書きます。

マネジメントに型なんてあるようでないよ。
1on1 だけとってもどれぐらいの周期でやるかとか何分やるのかとか、チームメンバーの構成だったり、仕事内容だったり、職種だったり、とにかく変わると思います。
型にこだわらずに毎日1cmでも1mmでもいいからチームを良くする方向に進めよう。
型なんて気にせずにチームとしての正解を探し続けよう。

自分もチームメンバーも他の人もみんな違うよ。
あたり前といえばそうなんだけど、これ本当に忘れがちなので常に意識したいです。
スキルも違えば考え方も責任も何もかも違う。だからすぐ理解しあえないこともあるし、ときには衝突も起きると思う。
チームメンバーや周りの人が自分の分身だったら効率は良いかもしれないけど、そこにイノベーションは起きないよ。
チームメンバーが自分の予想を遥かに上回る良い動きをしたときの高揚感は最高だよ。

楽観的にいこう。
何やってもだめなときもあるし、自分自身じゃどうしようもできない外的要因だってときにはある。
問題や失敗が起きたときに、うつむいてても落ち込んでてもしょうがないよね。それは問題や失敗へのアクションを決めたあとにしよう。
マネージャーは「まーそんなときもあるよね！」「んー全然わからん。困った笑」みたいにポジティブに構えてるのがいいのかなって思います。

さいごに

ソフトウェアエンジニアとマネージャーは、やることはまるっきり違うんですが

・ソフトウェアエンジニアとして、より良いプロダクトをどう作っていくのかを考えること
・マネージャーとして、より良いチームをどう作っていくのかを考えること

は一緒なんじゃないかなって思ってます。プロダクトがチームになっただけです。

マネージャー経験がゼロで当初は何すればいいのかわからなかったけど、チームをプロダクトと見立てて、心理的安全性, 1on1, 勉強会, ペアプロ, モブプロ, アジャイル開発 などのソフトウェアエンジニアがもっている良い文化をチームに取り入れていったらチームがかなり良くなってきたよ、という話でした。

長文なのにここまで読んでくれてありがとうございます。

参考になるところがあったらぜひ試してもらって結果を教えてもらえると嬉しいです！

あと、私のチームでコーポレートエンジニアとITサポートメンバーを募集しているのでnoteを読んで興味を持ってもらえたらぜひ応募してください！
カジュアルにお話だけでも構わないのでー
また、興味を持ちそうなお知り合いの方が居たら教えてあげてください 🙏