リモートワークが当たり前になった昨今において、仕事と直接関係のないコミュニケーションをとれる機会は貴重になりつつあります。

　そのような状況だからこそ、「オンライン飲み会」は接点作りにおいて重要視されるべきだと考えています。それぞれが何を考えているのかやどのような感情を抱いているのかを共有することは組織開発の観点からも大切です。

　そこで今回は、EM（エンジニアリングマネージャー）のオンライン飲み会に潜入し、ざっくばらんにお話を伺いました。

 

＜今回の登場人物＞

 

それぞれの入社理由

ー はじめにベルフェイスへの入社理由をお伺いしたいです

Iさん：

　もともと、ベルフェイスには副業として関わっていました。

　そこから、本業を辞めて別の企業に転職することになったのですが、転職先が副業NGだったので副業を継続できないと伝えたら、「正社員で働かないか？」とオファーをもらったのがきっかけです。笑

　ただ、自分の転職条件として地元で仕事をしたいという思いがあり、フルリモートで働けることが条件としてありました。

　当時はフルリモートで働いてるメンバーはいなかったのですが、フルリモートを認めてもらい、そこから地元に移住して働いています。

　ちなみに、来年には地元で家を建てる予定です。

Oさん：

　私は今年の1月に入社しましたが、リファラルでの採用でした。

　前職でSさんと一緒に働いていたこともあり、誘われたのがきっかけですね。

Bさん：

　私はSES企業で働いていたのですが、COVID-19の影響で案件が減ったことが転職を考えるきっかけでした。

　過去はエンジニアとして働きつつ新規事業をやっていたこともあり、経験を活かせると感じたのと条件面で副業OKだったことが自分にとっては良かったです。

Uさん：

　入社は2020年の6月で、前職ではニュースメディアサイトのバックエンド側やエンジニアリーダーをやっていました。

　私もIさんと同じように移住をしたいと考えており、フルリモートで働くことを考え始めた頃にベルフェイスの存在を知って、選考を受けてみたのが最初でしたね。

 

入社後のギャップ、変わり始めた組織

ー ちなみに、皆さんは入社前後でギャップはありましたか？

Sさん：

　私が入社したタイミングは組織のコンディションが悪化していたこともあり、入社してすぐはチーム全員と1on1をかなりやっていました。

Iさん：

　そうでしたね、懐かしい。

　チーム全体としてモチベーションはかなり下がっていましたし、それはエンゲージメントサーベイの結果を見ても明らかでした。

Uさん：

　色々ありましたよね。

　Sさんが入社されてから、しばらくは組織をどう改善していくかを考えられていた印象です。ちなみに、私はその時期に酒量がかなり増えました。笑

ー そこから組織はどのように変わっていったのでしょうか？

Iさん：

　数字的な側面でいくと、エンゲージメントサーベイの結果が大きく改善しています。平均的に10ptくらいは改善しているのではないでしょうか？

　僕個人のデータだと、より顕著に改善しています。グラフを見せることができればいいのですが、全体的に凄いV字回復してますよ！

ー 組織が変わった要因はどこにあるのでしょうか？

Nさん：

　一番は昨年の12月にzigorouさん（CTO山口の通称）が入社されたことです。zigorouさんの入社前後で、組織は大きく変わったと思います。

　zigorouさんは、自分を「CNO（Chief Nakajima Okasan）」と呼んでますが、経営の意思決定にエンジニアリング的な観点がかなり組み込まれるようになったなと感じます。

Iさん：

　今の組織の形になるには1年かかると思っていましたが、それが3ヶ月でここまで変わったので凄いなと。

　また、詳細は言えないですが、開発チームの前提となっていた聖域にも切り込んでいかれたのも驚きでした。

Tさん：

　それ、分かります。あれは凄いですよ。

　誰も切り込めなかった領域を入社してすぐに改善されていたのは、よっぽど強いオーナーシップがないとできないよなと感じます。

Sさん：

　あと、プロダクトグループが立ち上がったことも大きいですね。

　zigorouさんがCPOも兼任され始めたのは、開発チームとして大きな変化があったと思います。

Nさん：

　感覚的なプロダクトマネジメントや開発から、ちゃんとフレームワークに則って開発できるようになったのはエンジニアとして大きいと感じます。

ー ちなみに聞いてみたいのですが、代表の中島さんについては、どのように感じていますか？

Iさん：

　ついていきたくなるリーダーだなと思います。

　もちろん、エンジニアリングに関するバックグラウンドは薄いですが、適切な管轄区分ができれば、あとは自分たち次第なので。そこはあんまり関係ないと今は感じています。

Uさん：

　話にストーリーをもたせて、人を巻き込むのが上手いなと常々思います。

　あと、間違っていたことを謝れて、反省できる人だとも感じます。意外と素直ですよね。笑

Tさん：

　ちゃんと反省される方なので、ベンチャー企業の社長として凄いなと感じます。

　間違いを認められない社長も世の中にはいますけど、中島さんはそうではないですし。

Oさん：

　私は最終面接が中島さんだったのですが、ナチュラルボーンの人たらしだと感じましたね。笑

ーここから、ミーティング終わりのzigorouさんが突撃参戦ー

Sさん：

　良いタイミングで来ましたね。ちょうどさっきまでzigorouさんの話をしてましたよ。

　ちなみに、zigorouさんは、中島さんのことをどう思っているんですか？

zigorou：

　言いたいことはたくさんあるし、本人にも直接指摘したことも多々ありますが、それでも中島さんは責任感が先行していたんだなと思いますね。

　それまでは自分がリードしないと組織が動かないと思っていたのが、開発面だと僕がジョインしてから任せられると思ってもらえたんだと感じます。

　そういう意味では、中島さんは開発面において対等に言い合える人を求めていたのかもしれないですね。笑

 

心理的安全性を担保することで、組織は変わる

ー zigorouさんご自身は、開発組織がどのように変わったと感じていますか？

zigorou：

　具体的な話を出すと、最初の方は毎月行われるアップデート会でエンジニアメンバーがSlackに感想を書き込まないなと感じていました。

　そこから打って変わって、最近は投稿が増えてきたので、心理的安全性が少しずつ担保され始めたのかなと感じています。

　まあ、僕が率先してふざけてるってのもあるのでしょうが。笑

Tさん：

　言い方はあれですけど、お互いをいじりあえる文化になりつつありますよね。

　最近だと、EM定例を週2回行っていますが、けっこう盛り上がりますし。

Sさん：

　開発組織の交流でいけば、前は部署が分かれていたことから接点がないチームもありましたが、開発組織を統合してからは交流も増えましたね。

　開発組織全体として、良い感じになってきていると思います。

Nさん：

　もちろん、チームによって変化がまだ少ない部分もあります。例えば、自分が見ているチームはもっとエンゲージメントを高めたいですね。

　なので、組織全体としては、まだまだ伸びしろはあると思います。

ー 最近は、スクラムという単語もよく耳にするようになりましたね

Nさん：

　スクラムはこれから本格的に導入していく段階ですが、先行して私のチームとUさんのチームで推進しています。

Uさん：

　もともとスクラムでやっていたのですが、最近は社内で勉強会をやっていたり、スクラム経験のあるメンバーも増えてきたので、やり方をチューニングしながら進めています。

　そういえば、NさんがちょうどSlackに相談投げてましたね。

Nさん：

　各所にスクラムの経験がある方がいるし、相談しやすいので、わりとラフに相談してます。笑

（実際のSlack上での相談投稿）

 

Uさん：

　ですね。もちろん、開発内容によって、スクラムを導入しやすいチームとそうではないチームがあるのも事実です。

　なので、全社で展開できるかの試金石だと思ってスクラムに取り組んでいます。

zigorou：

　僕はスクラムの経験が薄いのですが、総じてスクラムを導入していければよいと今は考えています。

　もちろん、コミュニケーションコストはかかります。ただ、顧客の要望が変わる前提があるSaaS開発にはスクラムが馴染みます。

　また、スクラムを本格的に進めていくのであれば、全体のナレッジの平準化や標準化も進めていくことが大事だなとも思います。

Sさん：

　少し話を戻しますが、zigorouさんって率先して良いふざけ方をしますよね。

　さっきもアップデート会でのSlack投稿を率先してやっているみたいな話がありましたが、あれって組織の雰囲気をよくするために意図的にやられてたりされるんですか？

zigorou：

　それは、ただ素でやっているだけですね。笑

 

失敗しても、みんなで相談しながら前に進んでいく

zigorou：

　あと、酔い始めたから言っちゃうんですけど、個人的には失敗してはいけないミッションの組み方はあまり好きではありません。

　ここを変えるだけでも、チームの雰囲気は良くなると感じます。

　内心は、手戻りしても反省して前に進めれば良いじゃないかと思っています。

Nさん：

　いきなり切り込んだ話ですね。笑

　ただ、たしかにミッションの立て方がビルドトラップに陥っていたと感じます。

zigorou：

　ちなみにビルドトラップに陥っているKPI設計は変えようとしている最中なので、皆さん少しお待ちください。笑

　今後のイメージとしては、先行指標を追いかけることをミッションとするのが良いのではないかと考えています。例えば、電話商談の接続数を追うべきとか、そういう議論です。

　難しい側面として、プロダクトには指標化できない部分もあるので、そこをどう組み込むかは課題としてありますが。

Nさん：

　プロダクトグループはそれで良いとも思いますが、開発を行うエンジニアは先行指標だけ追うのも微妙じゃないですか？

zigorou：

　開発はもちろん先行指標だけを追ってはいけなくて、エンジニアリングの能力も評価すべきですね。

　成果の部分と能力をそれぞれ適切に評価できるようにしていきたいです。

Uさん：

　すみません、話を変えてしまうのですが、皆さんに今日聞いてみたいことが実はありまして。

　これはマネージャーとしての悩みなのですが、エンジニアメンバーにどのようなキャリアを歩んでもらうべきかを最近になって悩んでいます。

Tさん：

　分かります。僕も悩んでますし、マネジメントって難しいですよね。

Sさん：

　ですね。けど、今は相談できる人がいるのが心強いです。実際に、こうやって飲み会で相談できたりもしますし。

　みんなで相談しながら課題は改善していくべきだと思いますし、チームの雰囲気はみんなで作っていきたいです！

zigorou：

　さすがスーパーポジティブ、良い終わり方しますね。笑

（飲み会の最後に記念撮影を行いました）

 

＜あとがき＞

ベルフェイスにはもちろん課題は多く存在していますが、それぞれが前向きに改善を目指している環境です。もし、少しでも興味をお持ちいただけた方は、ぜひ以下のサイトもご覧ください。

※採用サイトはこちら

※エンジニア/プロダクト開発向けサイトはこちら