スマホとイラストさえあれば、いつでも・だれでも「キャラクターのライブ配信」を楽しめるアプリ『IRIAM』。
DeNAグループに参加して1年が経ち、組織規模は当時の約2倍となりました。2022年3月期の売上高も前期比4倍近くになるなど(※)、力強く成長中です。
そんな『IRIAM』メンバーの中でもっとも多い職種はエンジニアで、「技術のための技術」ではなく、ユーザーさんにとって真に価値ある技術利用を最重視しています。
『IRIAM』のエンジニア組織をどうしていきたいのか?どんな思いでチームに向き合っているのか?エンジニアチームのマネジメントを行うエンジニアリングマネージャーの溝田 直也(みぞた なおや)に聞きました。
※2021年8月の連結子会社化以前の期間を含む単体ベースでの対比
メンバーが自走できる環境を最大限に整える
ーーまず溝田さんについて教えてください。
2020年1月より株式会社ZIZAIに入社し、『IRIAM』の開発にエンジニアリングマネージャーとして携わっていました。2021年8月に『IRIAM』がDeNAグループの子会社となり、同9月に株式会社IRIAMへ転籍。引き続きエンジニアリングマネージャーとして、組織の拡大やサービスの成長に向けてさまざまな取り組みを行っています。
ーーエンジニアリングマネージャーとは、具体的にどんな業務になるのでしょうか?
企業によって求められる業務領域や重視されるポイントが異なりますが、エンジニア組織のパフォーマンスを最大化させるための環境づくりを行うポジションになります。
マネジメントの対象領域として、採用、育成、アサイン調整などのピープルマネジメントや技術的な意思決定を行うテクノロジーマネジメントがイメージされるかと思います。
『IRIAM』では、後者はエンジニア内で相談しながら技術を決めていく方針のため、エンジニアリングマネージャーは、ピープルマネジメントを軸に、PM業務や技術牽引などエンジニアリングマネージャー個人個人の強みを活かした業務を行っています。
ーー『IRIAM』のエンジニア組織構成・組織状況について教えてください。
現在エンジニアメンバーは、2022年10月1日時点で業務委託等も併せて35名で、『IRIAM』全体でもっとも多い比率となっています。
アプリ側のサーバーサイド(Go)、クライアントサイド(Unity)、管理画面(React+TypeScript、Go)、インフラ(GCP)で大きく4つに分け、エンジニアリングマネージャーは私含めて4人いる状態です。
前提として、プロダクトの成長スピードが速い今の『IRIAM』チームにおいては、各メンバーが自律的に動いていけることがとても大切だと考えています。いいアウトプットを各自で考えてつくり出していくこと、レベルの高いエンジニア同士で共に動いていける組織である必要があります。
ーー『IRIAM』のエンジニアリングマネージャーにとって大切なことは何でしょうか?
『IRIAM』は、エンジニアが自律的に動ける組織だからこそ、彼らが全力でパフォーマンスできる環境づくりやそのサポートがもっとも重要です。そのための個別フォローやメンタリングは丁寧に行うようにしています。また、今年度より新卒メンバーの受け入れも始めました。新卒の方々は中途の方に比べると社会経験が少ないこともあるため、基礎的な部分のサポート体制もメンター社員と共に構築しています。
また、マネージャーという役職柄、さまざまな情報が入ってきやすい立場であるものの、それらの情報をどのように人に渡していくかが大切です。うまく情報共有ができないと、情報がマネージャーのみに偏ってメンバーが動けなくなり、他メンバーの自律性をなくしてしまいます。だからこそ全員に対する情報共有という視座を持つことが大事なのですが、この情報共有の塩梅は簡単ではないと私自身感じています。
バリュー体現、個人の活躍を全員で賞賛する
ーー『IRIAM』では組織力を高めるため、ミッション、ビジョン、バリュー(以下、MVV)の浸透に力を入れていると聞きました。
はい、『IRIAM』に込められた想いやアイデンティティを、2022年2月にMVVという形に言語化しました。
・ミッション「心でつながる魔法をかける」
・ビジョン「心のつながりが集い合う新たな文化の共創」
・バリュー「コミュニティファースト」「プルス・ウルトラ」「ブループリント」
詳しくは、プロダクトオーナーの真辺 昂(まなべ こう)のこちらの取材記事「「キャラ」になってライブ配信。自己表現を民主化する『IRIAM』の魔法の意義」をお読みいただければと思いますが、このMVVを『IRIAM』全体として大事にしていて、浸透の役割はエンジニアリングマネージャーの責務としています。
ーーMVVについて、どのように考えてエンジニアチームとコミュニケーションを取っていますか?
目の前の業務に取り組んでいると、なかなかこのようなMVVを意識する機会は少ないかもしれません。それゆえ、エンジニアリングマネージャーとして、MVVがポジティブな使われ方になるよう意識しています。
たとえば、MVVの中でも、日々の行動の中で個人が意識する必要があるのがバリューと考えています。
バリューは、「コミュニティファースト」「プルス・ウルトラ」「ブループリント」の3つになりますが、これらのバリューは、すべて『IRIAM』内で培ってきた「コミュニティ論」をもとにつくられました。
「コミュニティファースト」は「コミュニティを出発点にする」という意味。「プルス・ウルトラ」はスペインの国旗のシンボルにもなっているラテン語の合言葉から拝借したもので、「全員が一丸となってチームの期待を超え合う相乗効果によって、チームというコミュニティの熱量をあげていこう」という意味を持ちます。
最後の「ブループリント」は未来の設計図のことを意味し、「長期的な青写真をきちんと描いて、たとえ一時的にネガティブがあったとしても、よりコミュニティにとっていい未来に向けて変化させていこう」という想いを込めたバリューになります。
ーーこのバリューを日々の業務の中でどのように意識させていくのでしょうか?
取り組みの具体例として、エンジニアのwin session(ウィン・セッション)があります。
エンジニアメンバーのwin=よいアクションを賞賛する機会としてwin sessionを毎週開催しています。winの中でもバリューを象徴するものに対しては、バリューを交えて讃え合うようにしています。
バリューに対してどういう動きをしていたからwin、としっかりバリューとメンバーの行動が結びつけられ、よい事例としてエンジニア内で共通認識を持てるように工夫しています。アクションがバリューに適っているのかどうかという明確な指標づくりをするのではなく、メンバーにそれぞれにMVVを解釈しながら期待を伝えて、チームにいい作用がもたらされるような動きが理想的だと思っています。
新しい技術を活かして、ユーザーにとってよりよい体験をつくる
ーー成長中のプロダクトだからこそ、リスクマネジメントも徹底しなければならないと思います。どのようにリスク管理について考えられていますか?
各自が自律的に動く以上、裁量を持ってもらう必要があります。裁量を持って動いてもらうためには、何がリスクなのかをメンバー同士もお互い気にしておかなくてはなりません。
メンバーそれぞれが伸び伸びと動くためには、リスクもある程度踏んでいくしかありません。挑戦にはリスクが伴うからです。リスクを懸念して動けなくなってしまうのではなく、みんなが失敗を恐れすぎずに前向きに物事に向かえること、サービスをいい方向に持っていけるという思いが大事だと思います。
たとえば、C#からGoへの言語移行を行った際は対象となるAPI数が非常に多かったため、サービスへの影響を抑えるために反映するタイミングの設定や切り戻しができる体制は構築しつつも、一定の不具合が出ることは許容してAPIをどんどん切り替えていき、移行を推進する動きを取っていたりしました。
高いリスクを察知したら止めることがエンジニアリングマネージャーの役割です。万が一メンバーがリスクを犯してしまったとしても、エンジニアリングマネージャーの自分がケアできる範囲であれば、自律的に動けることを優先したいと思っています。もちろん、メンバー同士で気付き合えること、それがお互いに言い合える関係値づくりも大切ですね。
ーーメンバーのモチベーションやアサインのコントロールはどうされていますか?
前提として、MVVへの共感、『IRIAM』というサービスに期待できるかどうかはモチベーションに関わっていると思います。
仕事である以上、自分の好きなことばかりできるわけではありません。だからこそ、サービスに期待を持って「サービスをよくするために何をしたらいいのか」を自ら考えられると、モチベーションが下がってしまう領域が減ると考えています。
『IRIAM』のエンジニアメンバーに、モチベーションに関してヒアリングをしてみたところ、「誰かの居場所をつくることができていてうれしい」「トレンドに左右されず、自分たちのつくりたい世界があるからこそ、チーム一丸になれる」「ふとした時に、『IRIAM』上のライバーさんやリスナーさんの顔が浮かび、大変な業務でも“自分が最高のモノをつくるぞ!”という気持ちになれる」というような声が返ってきました。
採用時点でも『IRIAM』というプロダクトに想いを持てるかどうかは確認するようにしていますし、既存のメンバーも前述の通り「サービスに期待を持てている」「サービスをよくしていきたい」というメンバーばかりで、全体としてモチベーションが保ちやすい状況だと思っています。
しかし、他にモチベーションが下がってしまう例として「自分がやらなくてもいいのではないか」と思うような業務を振られてしまう事があると考えています。できるだけこのような状況に陥るメンバーを減らせるようにエンジニアリングマネージャーが対応し、他のメンバーにアサイン調整をして、その方が業務に納得できて、気持ちよく取り組めるように個別で話をするようにしています。
また、アサインは基本的に希望を取りながら調整するスタイルを取っています。
ーー目標設定、評価について意識されていることはありますか?
目標設定の1番の作用はモチベーションが上がることで、形式上のものはしたくないと考えています。エンジニアは「実装したかどうか」は0-1で、その過程は数値化が難しいため、目標設定の上で大切なことは、綺麗な目標を立てることではありません。
そのため、目標を立てる段階で、動きのイメージが本人から具体的に出てくるまで、丁寧にすり合わせを行うようにしています。「どういう動きを取る」「どのレベルまでやる」という具体的なことまで話ができていれば、お互いに同じイメージで期待値と評価をすり合わせることができると考えています。
私が技術的にシニアではない分、その人の領域に対する評価を行うためにはその人自身を知り、向き合う必要があると考えています。決めつけず、変に忖度せず、相手が納得していない時も時間をかけてすり合わせていくようにしています。本心で思っていないと自分の発した言葉でも何かあった時に答えられなくなってしまうので、自分で納得したものを伝えるようにしています。
ーーメンバーの技術向上やサービスにとってよりよい技術選定を行うために、何を考えていますか?
『IRIAM』は技術が好きなエンジニアばかりなので、働きやすく技術向上しやすい環境をつくることができたら、それぞれが好きなように頑張ってくれると考えています。最近だと参加希望のあるメンバーに、CEDECに参加してもらいました。また勉強会に1-2日参加してもらうことで組織として何かが回らなくなるフェーズではなくなってきたので、まとめて行ってもらうことができるようになりました。
技術選定においては、「新しい技術だから入れる!」ではなく、『IRIAM』に取って入れるべきかどうかという軸で常に考えています。サービスに思いのあるメンバーばかりなので、共通認識を持って技術に向き合うことができていると思います。新しい技術はリスクもあるので、リスク管理の観点はもちろん考慮しますが、エンジニアメンバーのモチベーションを考慮することも重要です。「AよりBの方がみんなが使いたい!」というときには、Bを取ることも多くあります。
技術的な魅力としては、『IRIAM』ではリアルタイム配信というサービスの新規性とそれに求められる技術力や、ユーザー数が増え続けているといった背景から、新しい技術を活かせるシーンが多いと思います。
サービスに向き合う人が報われる組織で
ーーどんな人が『IRIAM』のエンジニアリングマネージャーに向いているとお考えでしょうか?
3つあると考えています。
1つ目は、「メンバーを成長させたい、よくしたいと思う。そこに信じる気持ちとモチベーションを持てること」です。
2つ目は、「サービスがどうなったらよくなるか、俯瞰しながらも一歩深く考えられる人」です。自分のチームのメンバーを気にするあまり、他メンバーを気にかけなくなってしまうことは全体にとってはよくない状態で、俯瞰して全体を見て動く必要があります。またエンジニアリングマネージャーとして、リスクマネジメントをする場面や、背中を預けてもらう立場である中で、自分で腹落ちできるかは大切です。誰かの言葉を鵜呑みにしてしまうのではなく、自分なりに深く考えてどうあるべきかというスタンスを持てる必要があります。
3つ目は、「サービスに向き合う人が報われる組織にいたいと思う人」です。さまざまな組織がある中で、人のエゴに引っ張られてしまう組織は多いと思う。忖度があって、本当はこれがよいと思ってもやりづらかったり、他者から「なぜ頑張っているの?」と言われてしまって気落ちしてしまうこともあるかもしれません。しかし、『IRIAM』は正しい方向に進めていけば報われる組織だと思っています。なぜなら全社としてリスペクトの文化があり、職種間だけではなく職種を超えたリスペクトがあるからです。
ーー溝田さん自身は『IRIAM』のエンジニアリングマネージャーをやっていて、どんなやりがいを感じていますか?
私は先ほど話した1つ目に、特にやりがいとモチベーションを感じています。
自分がどう動くか次第で、自分より優秀なエンジニアのサポートができることってすごいですよね。自分が一人で技術力を上げてもその人の100%にはなれませんが、私がサポートに回った結果、その人が100%の力を発揮できるなら、この上ないと感じています。
私自身、最初はエンジニアとして能力を伸ばしたいと考えていましたが、仕事としてやっていく時に「技術を伸ばす」ではなく「どうしたらうまく仕事ができるのか」と考えるようになりました。「どうしてこんなにやりづらいんだろう?」「もっとこうしたらいい感じにワークするのでは?」と考えて開発に取り組んでいたら、気づいたらPM側に回っているような形だったんですよね。
自分自身、開発で手を動かす以上に仕組みや環境は気になってしまうのかもしれません。PM的な立ち回りを続けていると、チームで開発する以上、それぞれがパワーを発揮するには、自分がしている立ち回りが重要かもしれないと思うようになりました。また、この立ち回りが自分にとっても自然で、他エンジニアメンバーよりハードルを感じなかったという感覚もありました。エンジニアとして何かをつくりたいだけなら、個人開発をやりたくなったタイミングでやればいいなと思っていて、個人開発で開発意欲は満たせています。
ーー『IRIAM』では現在、一緒に働くメンバーを募集中と聞きましたが……。
はい、エンジニアリングマネージャーも含めて、『IRIAM』では全職種で積極採用中です!
『IRIAM』のサービスを共に成長させていきたい方、新しい文化の未来を一緒につくりたい方、お待ちしております!
※本記事掲載の情報は、公開日時点のものです。
※本インタビュー・撮影は、政府公表のガイドラインに基づいた新型コロナウイルス感染予防対策ガイドラインに沿って実施しています。
編集:フルスイング編集部 撮影:小堀 将生