今月、弊社の投資先より、急成長中のSaaSスタートアップ3社から各社の開発チームにお集まりいただき、その3社のデベロッパー・エクスペリエンス「DevEx」についてのウェビナーを開催しました。3社それぞれにエンジニアさんの働きやすさと開発効率をよく考えた施策や取り組みが語られた充実のセッションとなりました。

今回は、前半のセッション「DevEX x フルリモート」の様子を一部ご紹介します。

DNX Ventures 稲田（モデレーター）：弊社もエンジニアはフルリモートですし、みなさんもフルリモートという会社さんが多いのではないかと思います。しかしながら、リモートワーク、言うが易し。メリット・デメリットを様々にお感じではないでしょうか。まずは、なぜフルリモートを解禁したかについて伺っていきましょう。

テックタッチ 日比野さん：フルリモートを解禁したのはコロナになってからです。2020年3月ごろでした。一番大きな理由は「エンジニア採用」です。リモートワークの考え方は部門間で違っており、エンジニアだけフルリモートを許可しています。ビジネスチームと、プロダクトチームでもPdMやカスタマーサクセスエンジニアなどの部署はフルリモートを解禁してません。一つの会社で二つのルールがあります。エンジニアだけなぜ許可したかというと、「採用」です。二つ考えがあって、リモートワークを許可している企業が、採用において一定のアドバンテージをもっていると感じました。また、今後フルリモートで移住している方が東京に戻ってオフィス回帰するとは考えにくいと思い、採用のパイが今後ますます少なくなることも見込み、エンジニアに限り解禁しました。

コミューン 宮本さん：フルリモートを解禁した時は、実はコミューンに入社していなかったのですが、同じく「採用」がひとつありました。エンジニアの仕事って、そもそもリモートで可能な時代になっており、わざわざ出社する必要もないと考え、これを機に解禁しています。開発効率でいうと、もともとコミューンは創業者含めプロダクトオーナーが考えたもので、業務委託の方にお願いすることが多かったと聞いています。それによって、もともとリモートを活用していたので、開発効率が著しく落ちるようなことはありませんでした。しっかり要件を固めた上で開発のチームが動くプロセスが固くできていたこともあり、割と効率を落とさずにフルリモートへの以降ができました。
一方で、開発組織が成長するに従って、作り切った要件にしたがって作るというところに抵抗が出てきているので、開発するものをよりよいものにするために、エンジニアがどう開発に関わり進化させていくか、それをフルリモートでどう実現するかがこれからのテーマです。

UPWARD 剣持さん：私たちも似ていますが、大きく３つの観点がありました。一つ目は「採用」です。フルリモート自体がエンジニアにとって魅力的な環境に見えること、そして地方在住の方にリーチできることがメリットです。エンジニアの採用は結構大変で、東京にパイを縛ってしまうと苦しくなる。一方で地方に在住したい方に対してリモートで働けることは魅力に感じてもらえます。二つ目に、「今の従業員満足度向上」もあります。出社したい人とリモートで働きたい人の両方の期待に応えることができています。三つ目は「開発効率」です。移動時間がない分、開発に集中できます。開発業務のほとんどはリモートでできます。圧倒的に効率が良いです。補足しますと、UPWARDは実はコロナの1年くらい前からフルリモートに移行していました。当然コロナになってからもフルリモートを継続しています。

稲田：エンジニアサイドでは「採用」と「都市部以外の人にリーチできる」の２点、そして開発効率が上がる点と、メリットしかないようにも思われます。その反面、ビジネスサイドとのコミュニケーションの課題はあるのではないかと思います。ここを解決するために、円滑なコミュニケーションをどのように実現しているか伺いたいと思います。

剣持さん：おっしゃる通りで、リモートだけでやっていると疎遠になりコミュニケーションしづらいため、工夫をしています。業務時間中に顔を合わせることはほとんどありません。年に一度といったレベルです。そこで効果的だったのは、飲み会やイベントです。一番コミュニケーションを阻害するのは、相手の顔がわからないこと。一度飲み会で顔を合わせているとコミュニケーションがしやすくなる。ビジネスサイドとテックサイドで交流し知り合える環境を２〜３回つくってあげるのは効果がありました。四半期に一度くらい会っているのではないかと思います。他にも、リモートワークしやすい環境の整備も合わせてしています。ビジネスサイドとSlackでオープンコミュニケーションできたり、いつでもHuddle（Slackの通話機能）を繋げられるよう工夫しています。

宮本さん：コミューンは、社内のコミュニケーションがSlackですべてオープンで行われています。相談事があればいつ誰にでもコミュニケーションが取れ、非同期で連携が取れます。必要に応じてHuddleで集まるなど、円滑にコミュニケーションを取れる方法が用意されています。本質的なところでいくと、一度顔を合わせたり、一度ならず会って話をすることで心理的安全性を築くことは大事だと思っています。僕も大阪からフルリモートで働いています。エンジニアリングマネージャーで突然ポンと入社しても、マネジメントはフルリモートで簡単にできるものではないということを前職で身に染みてわかっていました。そのため、コミューンが設定している月に1度の「出社要請日」（現在は週に一度「出社推奨日」という施策に変更）に合わせて足繁く東京のオフィスに通い、コミュニケーションをとりました。僕の人となりを伝え、心理的安全や話しやすさを作っていきました。僕だけでなくメンバーもビジネスサイドの方々と飲みに行ったりもします。これがあってSlackでのフルオープンのコミュニケーションも取りやすくなっています。

日比野さん：切り口を変えて、カルチャー面・マインド面で取り組んでいることを紹介したいと思います。テックタッチでは「Co-developers」という社内標語があります。プロダクトチームとビジネスチーム間でコラボレーションできないという点は、リモートワーク云々という以前から、SaaSでは起こりやすいと言われてきました。これを踏まえて、「全員がプロダクト開発に携わるんだ」ということをコロナ前から考えていました。そうして言語化したのが「Co-developers」です。社員からも愛され、「バリューにも付け加えたい」と言われています。「Co-developers」はエンジニアサイドからすると、エンジニアもCSも関係なく一緒にものをつくっていくんだという考えもありますし、ビジネスサイドの採用をする際に「こういう会社ですよ」と「Co-developers」の考え方を伝えています。たとえCSであっても、顧客からの言葉をプロダクトに落とし込めることや一緒にプロダクトを作っていけるのが面白みだと明確に伝え、これに共感してくれる人を採用しています。「営業も開発もCSも一緒にプロダクトをつくる」という根本のマインドが強いので、コラボレーティブに開発ができるようなカルチャーがつくられているのではないかと思います。

稲田：ルールや制度の前に、カルチャー・バリューが揃っていないとルールが形骸化してしまう。

日比野さん：そうですね。それをきちんとわかりやすい言葉にするのが大事だと思います。

稲田：オーディエンスからのご質問です。地方在住で育児中の方は、飲みニケーションが難しい。工夫されていることはありますか？

剣持さん：おっしゃる通りです。オフラインで接点が取れる人は、比較的コミュニケーションは取りやすい。一方地方在住の方や、都合があって会えない方とどうやっていくか日々考え試行錯誤をしています。オープンコミュニケーションで担保するというところは心がけています。たとえば、エンジニアはプロジェクトチーム毎に常にHuddleを繋げていて、いつでもコミュニケーションがとれるようにしたり、マネージャーとの1on1をウィークリーで設定したり。私ともマンスリーで1on1を設定し、何か悩みがあったらコミュニケーションが取れるよう工夫しています。

宮本さん：常にコミュニケーションがとれるよう、以前はGATHERも使っていました。頻繁ではありませんが、経営者が地方在住の方のもとに伺って、地方在住のメンバーと直接話をしたこともありした。

稲田：新卒の方や中途の方が入ってきた時、どのようにオンボーディングしていますか。

日比野さん：オンボーディングプロセスはしっかり組み立てました。最初は何もなかったのですが、現在は入社後5営業日をつかってオンボーディングをしています。様々なテーマで20セッションほどあります。テーマとしては、事業理解やプロダクト理解、組織カルチャー、なのですがそれぞれ担当者を変えて実施しています。さらにその後、約10人のメンバーと15分コミニュケーションする「1on1スタンプラリー」も実施しています。まずはいろいろな方と話して頂いたうえで、さらに必要なことはきちんと伝えるようにしています。
他にも、営業メンバーがお客さんにどのように営業しているか、自分たちのプロダクトをお客さんにどうアピールしているかをエンジニアが聞くという、風変わりなオンボーディングセッションを設けています。

宮本さん：弊社は全社のオンボーディングは1日で事業やプロダクトの概要について説明します。その後、開発者として作業を始めるための基本的なオンボーディングは、全てコンテンツができあがっているので、それにしたがって進めていけば、1日で開発環境が整うような仕組みを作っています。変更が必要なものは加筆・修正し、オンボーディングコンテンツを新鮮な状態に保てるようボーイスカウトルールも実践しています。
次に、「バディ制度」があります。チームの中に相談ができる社歴の長い先輩を付けて、日々相談が受けられるサポート体制を整えています。入社後チーム内のメンバーとは、1時間の「心理的安全性プログラム」を用意し、コミュニケーションを取りやすくする施策も行っています。

剣持さん：会社のオンボーディングがあるのは一緒です。その後エンジニアのオンボーディングがあります。特徴としては、早めに手を動かして、開発案件に携わりキャッチアップしてもらうようにしています。その人のレベル感に合わせて手を動かし、やりながらプロダクトの理解を深めてもらうというやり方です。手を動かすのが一番覚えると思い、あえて重視しています。また、継続的にスキルアップ・知識向上ができるような仕組みは気をつかってやっています。一つ紹介させていただくと、毎週開催されるCSの定例会に必ずテックチームも参加しています。CSのための勉強会として位置付けられ、顧客の成功事例やユースケースを発表してもらっています。顧客のユースケースを理解したり、自分達が提供するプロダクトでお客さんが成功していることを知ってもらうことで、モチベーションが上がり知識が深まっております。

稲田：非常に勉強になりましたし、参加者の方はなにかエッセンスを持って帰って頂ければと思います。日比野さん、宮本さん、剣持さんありがとうございました。

（文・上野なつみ）