※旧SEメンバーシップ会員の方は、同じ登録情報（メールアドレス＆パスワード）でログインいただけます
若手エンジニアだからこそできる！ リモートワーク時代の組織の課題解決
2020年のコロナ禍以降、リモートワークを標準的な勤務形態のひとつとして採用する企業が増えています。本格的にリモートワークを導入した企業では、実施後、さまざまな課題も見えてきているのではないでしょうか。コロナ禍によってリモートワークへのシフトが一気に進んだ中で「部門横断型の社内コミュニティ運営」に取り組んだヤフーの宇城毅犠さん、「リモートチームの課題解決」に取り組んだDeSCヘルスケアの赤木里騎さんに、若手だからこそできる組織への貢献方法について伺いました。
「データに関わりたい」という思いがコミュニティ設立の原動力に
宇城：ヤフーの宇城です。2019年4月に新卒入社でヤフーに入りました。現在は「Yahoo!知恵袋」で、Webアプリケーションのフロントエンドからバックエンドまでを担当しています。
宇城毅犠（うじろ・つよき）氏
淡路島出身の26歳。2019年4月に新卒でヤフーに入社。現在は主に「Yahoo!知恵袋」のWebアプリケーション開発に従事している。業務の傍ら、社内の部門横断型のデータコミュニティを設立し、イベントや勉強会の企画・運営を行っている。学生時代には、データサイエンス系の研究や電子工作を中心としたものづくりに関心があり、高齢者の発話から認知症のリスクを検知する研究論文は、音声系のトップカンファレンスである「INTERSPEECH」に採録された。
赤木：僕も宇城さんと同じく、2019年4月の新卒入社です。大学院に在籍していた当時から、いわゆる「ヘルスケア」領域に関心があり、DeNAで約半年の研修をした後、DeNAライフサイエンスを経て、現在は、DeNAと住友商事が合弁で設立した「DeSCヘルスケア」に所属しています。DeSCヘルスケアでは、「kencom×ほけん」という、保険会社と契約者が利用するアプリの設計、運用からコーディングまで、ひととおり携わっています。
赤木里騎（あかぎ・りき）氏
2019年4月に新卒でDeNAに入社。2019年9月から美容系の新規事業を約半年間経験した後、DeSCヘルスケア システム部に異動。現在は生命保険業界向けのサービスである「kencom×ほけん」のサーバーサイドエンジニアとして従事。Google Kubernetes EngineやGoの経験を積む。
宇城：まずは私のコミュニティ作りの取り組みを紹介します。現在の「Yahoo!知恵袋」の業務とは別に、2020年の4月から、ヤフー社内でデータコミュニティを設立し、運営を行っています。
もともと入社前からデータサイエンスに興味があり、データサイエンス系の研究論文を書いたこともあるのですが、ヤフー入社後の配属先はその領域と、あまり関係のないところでした。そうした環境で仕事をしていると、情報自体もあまり入ってこなくなります。
そのような背景もあり、自分としても、会社の中でデータに関わりたいと考えていました。そうした思いを、社内のDeveloper Relations担当者に率直に話したところ「コミュニティづくり」を提案されたというのが、きっかけです。
ヤフーも企業として「AIテックカンパニーを目指す」という方針を掲げており、所属や専門にこだわらず、さまざまな人がデータについての知識を共有し、それを自分の業務に取り入れていけるようなコミュニティがあれば、その方針に寄与するのではないかと考えました。
赤木：ヤフーのDeveloper Relationsは、そうした社内のコミュニティ活動についてもサポートをしてくれるのですか。
宇城：はい。そういう人が社内にいてくれたのは幸運でしたね。部署としては、いわゆる「技術広報」として、ヤフーの開発者やクリエイターたちの魅力を社外に伝えたり、「Hack Day」や「Bonfire」といったイベントを通じて、社内外を問わず、開発者やクリエイター間の交流を深めたりといった取り組みをしています。
赤木：そうした思いを組織的に後押ししてくれるというのは良いですね。コミュニティの立ち上げは、コロナ禍の時期とも重なって大変だったと思うのですが、どのように進められたのですか。
宇城：コロナ以前、社内のコミュニティやイベントの運営は、基本的にオフラインを前提として開催されていました。ノウハウが少ない中で、完全オンラインでどうイベントを開催し、コミュニティを盛り上げていくかは、文字どおり手探りで、今後の課題でもあります。
データコミュニティの活動が本格的に始まったのは2020年4月で、立ち上げ当初からオンラインのみで活動しています。オンラインでの開催が、結果的に東京以外の拠点からも参加できるコミュニティづくりにプラスになっています。
赤木：最初のイベントは、どのような内容だったのでしょうか。
宇城：LT（Lightning Talk）形式でやりました。私が企画した最初の内容は「データはどう生まれて、どう処理され、活用されるのか」という一連の流れを、聞いている人が追えるようなイメージで構成しました。全体で1時間半くらいのイベントになりました。
レベルとしては、データ領域にあまりなじみのない方でも理解できるようなものに設定したのですが、参加者からも「データがどういう感じで扱われているのかがよく分かった」というコメントをもらえ、ほぼ当初の狙いどおりの内容にできたと思います。
その後は、参加者へのアンケートを参考にしながら、運営メンバーと「次はどんなイベントをやる？」「どんな話が聞きたい？」などとやり取りしながら、今後のイメージ作りを続けています。
オンラインでコミュニティ活動を継続するための工夫
赤木：当社でも不定期に勉強会や輪読会などを開催していて、僕もその運営に携わることがあるのですが、内容の「レベル感」はいつも悩ましいですね。レベルを高くしてしまうと興味を持つ人が限られますし、継続していくのも難しくなる。一方で、あまりレベルを下げすぎてしまうと、内容が参加者の期待値を下回ってしまうリスクが高くなる。宇城さんは、データコミュニティのイベントを企画する際に、そのあたりをどう調整されているのでしょうか。
宇城：現状では、まず、データに関心を持つ人の裾野を広げることを意識して、レベルはなるべく上げすぎないようにしています。エンジニアだけではなく、デザイナーや、企画などビジネスサイドの人でも、ざっくりと全体像が把握できるくらいに設定していますね。イベントに参加してくれる人の割合を見ても、現状はエンジニアが6割、その他の人が4割といった感じです。
コミュニティでは「データの可視化」をテーマにした読書会も開催したのですが、その時には「グラフの作り方」のような内容も取り扱っていて、企画側の人たちからも「グラフを見たり作ったりする際に、何を意識すればいいかわかった」「仕事に生かせる内容だった」と反応がありました。当面は、なるべく多くの人に興味を持ってもらうために「とっつきやすく、業務に生かしやすいテーマ」というのを意識していきたいと思っています。
赤木：その読書会は、具体的にどのような形で進めたのですか。
宇城：「データの可視化」をテーマにしたときには、1冊の本をある程度のまとまりごとに、社内の有識者の人に解説者になってもらって、実例を交えながら概要をかみ砕いて説明してもらうという形式で進めました。部署横断での読書会は社内でも初めての試みだったのですが、「そもそも読書会ってどんなことをやるのだろう」というビギナーも含めて、100人くらいの聴講者が集まりました。
赤木：少人数で内容を深く読み込むような読書会とは違って裾野を広げたのですね。ちなみに、解説者の方は立候補ですか。それとも、運営側でどなたかにオファーするのですか。
宇城：「このテーマなら、この人に聞きたい」という感じで、運営側からお願いをしていますね。お願いをされた方も、自分の知識を社内で共有することについて、みなさん前向きに捉えて引き受けてくださっています。
赤木：読書会や輪読会形式のイベントは、少人数であまり深くやろうとすると、参加者の負担が重くなって、継続しづらいのが難点だと思っていました。
ちなみに継続性という観点で、僕がいいなと思った社内の取り組みに「なんとなくの社内勉強会」があります。本を決めておき、午前の30～45分を使って、チーム等は関係なく、その場にいる人たちで、一緒にそれを読んでいくという進め方なのですが、これだと参加のハードルが非常に下がります。「続けていくこと」や「いろんな人に参加してもらうこと」を軸に考えると、そうしたイベントの形式にも、工夫の余地がありそうですね。
宇城さんが、コミュニティ活動の「継続」という観点で、特に意識をされていることはありますか。
宇城：立ち上げ初期は、自分でいろいろ考えて動いていたのですが、今は「自発的に動いてくれる仲間を増やす」ことを意識するようになりました。イベントに参加してくれた人で「自分はこういうテーマでやりたい」と意思表示をしてくれるような人を大切にして、運営側に入ってきてもらうというのも、ひとつの方法だろうと思っています。
赤木：そうした「イベントを通じた交流」のようなことは、オンラインだと、オフラインほど自然にはいかないようにも感じるのですが、何か工夫をされていますか。
宇城：そこは一番の課題だと思っています。オンラインのイベントだと、聴講者は一方的に「聞くだけ」になってしまいがちです。ツールはZoomを使っているのですが、「ブレイクアウトルーム」のような機能を使っても、オフラインのように自然に交流するのは難しいですよね。現状はチャット機能をオープンにして、そこに自由に書き込んでもらうという形で、コミュニケーションを活性化できないか、試行錯誤中です。
赤木：たしかに、そこが一番難しいかもしれないですね。チャットであれば、例えば運営側で最初のコメントを書き込むとか、イベントの司会を若手がやるとかいった方法で、参加者の心理的なハードルを下げて、「思いついたことを発言していい雰囲気」を作る工夫を、実際にすることもありますね。
こうしたコミュニティ活動については、自発的に運営に携わってくれる人の存在がポイントであり、また難しいところでもあると思います。ヤフーのDeveloper Relationsのように、そうした社員の思いを後押しして、サポートしてくれるような存在はいいなと思いました。
ふりかえりでの書き込みがチームの改善を促すきっかけに
赤木：続いて、僕が感じたリモートワークでの課題と、それに対する取り組みをお話しします。
僕の業務は保険業界向けのアプリ開発とサービス運営が主なのですが、保険業界はコロナ禍の影響を受けやすいこともあって、昨年来、チーム内での人材の入れ替わりや、ビジネスプランの変更などが相次ぎました。すると、チームとしての目標がぶれやすくなるので、意識合わせのためのミーティングを頻繁に行うようになったのですが、あまりにもそれが増えすぎてしまい、エンジニアが自分の作業に集中できる時間がどんどん減っていきました。
自分がチームに入ったのは、ちょうどそうした問題が顕在化しつつあるタイミングでした。そもそも、まだ新卒2年目なので、当初は「会社での仕事ってこういうものなのか？」「これが、このチームの仕事の進め方なのか？」などと考えていたのですが、2カ月ほど経ったときに、ついに「これ以上は無理だ」と限界を迎えまして、そのことをチームに素直に伝えたのですね。
僕の所属する「kencom×ほけん」のチームでは、アジャイル開発を取り入れており、KPT（Keep／Problem／Try）のフレームワークを使用して、スプリントの最後に活動の振り返りをしています。オンラインでのKPTには「Google Jamboard」を使っていたのですが、そこにProblemとして「作業集中日は週3日ほしい」「一回も発言しないミーティングは資料共有ではダメなのか」といったことを、かなりストレートに書きました。
チームの反応がどうか不安ではあったのですが、それを見た他のエンジニアからも「そう思ってた！」という賛同があり、結果的にそのことが上長に伝わって、一気に「作業集中日」の確保や、不要なミーティングの削減といった環境改善が進んだという感じです。詳細な経緯や、改善の具体的な進め方などについては、DeNAのエンジニアブログにも書いています。
宇城：チームメンバーそれぞれにも問題意識はあったと思うのですが、若手の立場でそれを表明するのは、かなりハードルが高かったのではないかと思います。
赤木：直接のきっかけとしては、ある時、カレンダーを見て「作業に集中できる時間がない……」と思ったことですね。それまでに何となく感じていた焦りが、その時に「これは言わなければ変わらない」という思いに変わり、素直に言っていくことに決めました。
KPTでの振り返りでは、なかなか「Problem」は指摘しづらいものだと思うのですが、ちょうどリモートワークで「Jamboard」の活用が進み始めていたタイミングでもあり「ここでなら、対面では言いづらい意見も出しやすくなるのではないか」という期待もありました。
良かったのは、他のメンバーがそれに賛同してくれて、さらに上長を中心としてチームで「問題の深掘り」「改善策の検討」「担当者のアサイン」までを振り返りの一部として実施していく体制を作ってくれたことです。最初のタイミングで「あぁ、このチームでは思ったことを素直に口にして大丈夫なんだ」と安心できたことは大きかったですね。この体制は今でも続いていて、相変わらず僕は無邪気に発言をしつつ、チームを巻き込みながらの改善は続けられているという状況です。
宇城：すばらしいですね。私も、エンジニアリングに関わる中で、企画側とのすり合わせが増えて、作業に集中する時間が確保できないジレンマを感じることがあります。その部分を減らしていくというのは、難しかったのではないですか。
赤木：たしかに難しいのですが、今回の場合はエンジニア側のトップと、企画側のトップが直接「すり合わせを削る」ための申し合わせをしてくれたというのが大きかったですね。今、定例で残っているのは、両者でビジネス面の進捗確認を行う週30分程度のミーティングのみです。もちろん、仕様や機能開発のすり合わせなどは必要に応じて行うのですが、それぞれのエンジニアには「作業集中日」が設定されていて、ミーティングは、それ以外に入れるという共通認識ができています。僕としては、この「作業集中日」を確保できたというのが、今回の取り組みを通じて一番良かったと感じている成果です。
宇城：「無用なミーティングはやめるべき」という思いは、どんな組織にもあると思うのですが、それを「実際にやめる」のは非常に難しいですよね。
赤木：重要だと思われているミーティングを、若手が「やめるべきだ」と指摘するのは、普通に考えて難しいですよね。僕の場合は「意見」としては、なるべく率直に表明するようにして、チームとして実際にどうするかの判断や、やる場合の目線合わせについては、上長にお任せするというスタンスです。
自走する新卒メンバーのサポート方法とは
宇城：赤木さんのチームでは、その後も継続して改善に取り組まれていますが、特にリモートワーク環境下で課題と感じておられることや、具体的にされていることはありますか。
赤木：組織としての大きな課題に挙げられるのは、昨年以降に入社してきた新卒のための自走環境の整備でしょうか。初めてチームに配属されて働く上では、分からないことが山ほど出てきます。「こんなこと聞いていいのか」「これは言っていいのか」と不安になることもあると思いますし、実際に自分もそういう経験をしてきました。コロナ禍以降に、リモートワーク前提でチームに入ってくる新卒の人たちであれば、なおさらだと思います。
ここについては、チームのエンジニア巻き込みながら「そもそも自走とはどういう状態なのか」の定義を掘り下げて共有し、どうしたら自走できるか、そのためにどういう環境が必要で、具体的に何ができるかを考えながら取り組みを進めてきました。昨年度の新卒から適用しているのですが、これについては、新卒の人たちからも「リモートで不安だったが、思ったより働きやすかった」というフィードバックをもらえています。
宇城：新しく入ってくるメンバーに対して、非常に親身に接しておられる感じが分かります。目標が達成された状態をきちんと定義して、計画的にサポートすることの重要さは、特にリモートワークが標準の状況下では増していると思います。
自分のチームだと、新しい人が入ってきたときに、チームで独自に使っている技術や、新しい技術を教える、いわゆる教育のプロセスに難しさを感じています。リモートだと、対面と比べて、細かいところに気付くのがどうしても難しくなりますね。そのあたりをどうカバーしていこうかと、日々考えています。
赤木：たしかに、会社やチーム内での細かいルールの転移には、相手と会話する回数を増やすことでしか、拾いきれない部分がありますね。エンジニア職であれば、求められた仕様を実装する力は、これまでの経験の中である程度できていると思うのですが、業務としてそのスキルを発揮する上での「細かいすり合わせ」は別途、機会を作って行うしかないという部分に、僕も課題を感じています。
あと、自分も入社3年目になり、多少ですがメンターとしての役割も求められるようになっています。リモートで、どうすれば相手と十分な信頼関係が築けるかというのは、経験もなく、前例も少ないので難しいですね。
若手でも「思ったことを表明する」のをためらう必要はない
――リモートワーク環境でのコミュニティ運営や、チームビルディングに取り組まれた経験を通じて、どのような気付きがありましたか。
宇城：自分の場合、もともとデータに興味があって、ヤフーでもそれに関わる仕事がしたいと思っていたのですが、実際の配属は希望と異なる部署でした。ただ、希望と異なる配属だったからこそ、見えてきた組織の課題もあったように思います。
例えば、部署や拠点をまたいでのコミュニケーションがもっと活性化されたらいいのにとか、同じ組織の中で働いていても、データに関わる知識や活用度合いには、本当に広い幅があることだとか。こうしたことは、最初から希望どおりの部署に配属されて、そこで仕事をしていたら、見えていなかっただろうと思います。結果的に、その思いを社内で率直に話したことが、データコミュニティの設立につながったわけで、視野を広く持つことと、そこで感じたことを臆せずに表明することが、大事だと思いましたね。
あと、リモートワークに関しては、自分にとってはむしろプラスになっていると感じています。リモートのほうが、パフォーマンスを発揮できていると思いますし、社内の他のメンバーとのコミュニケーションも、リモートになってからのほうが活発になっていますね。
赤木：一般的に、リモートワークの課題は「コミュニケーションの不足」だと言われていますが、宇城さんの場合は逆だったわけですね。その理由は何だと思いますか。
宇城：自分の場合、人と対面することへの苦手意識があり、慣れていない人とのコミュニケーションは不得意だと勝手に思い込んでいた部分がありました。対面で話していると、相手の表情や会話の間といったものから「今、話しかけちゃいけなかったかな」とか「気に障ること言ったかな」などといったことが気になってしまい、言葉を詰まらせたり、いいレスポンスができなかったりしていたのです。
リモートワークだと、相手との会話はチャット越しが基本なので、まず表情が分かりません。それで、自分の発言に対して過度に気にすることがなくなりました。あと、ヤフーではリモートワークの課題について、社員に定期的にアンケートをとっているのですが、それを見ると「コミュニケーションが不足している」と感じている人が、圧倒的に多いのですね。それはつまり、相手も「コミュニケーションを求めている」ということであり、自分から声を掛けるハードルがすごく下がりました。また、チャットだとレスポンスのタイミングを相手に委ねることができるので、「忙しければスルーしてくれるだろう」と思えるようになったのも大きいですね。
赤木：よく分かります。僕も、どちらかといえばリモートワークで生産性が上がったタイプです。でも「相手の表情が分からないので、余計なことを考えずにコミュニケーションできるようになった」というのはすごいですね。
僕は、今のチームに慣れるまで、自分の意見を表明することに悩んだのですが、結果として「言って良かった」と思っています。これは、リモートワークに限った話ではないのでしょうが、社歴やチーム歴が浅かったとしても、仕事の中で、疑問や課題に感じていることがあれば「無邪気に言ってしまう」というのはアリだと思います。僕のチームには、それで怒ったり、気分を害したりするような上司や同僚はおらず、みんなが全力で、その課題を解決するために動いてくれました。
僕らのチームがやっていることは、誰かが課題に感じていることを表明したら、その本質を掘り下げ、解決策を一つ一つ地道に試して、うまくいかなければ別のやり方を考えるという、泥臭いことの積み重ねです。ただ、それが今、うちのチームがリモートでうまく仕事を進められていると感じている、大きな要因でもあります。誰かが不満を漏らしたり、失敗したりしたときに、それを責めるのではなく、状況を良くするための方法をチームで考えられるような雰囲気づくりが、組織には大切なのだなと感じています。
著：高橋美津
【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社