新技術に寛容なDMMのカルチャー
「DMM TV」の開発プロジェクトでは、新しい技術を使ってアプリ開発を進めたと聞いています。
福岡：Android、iOS、TVアプリの3つに分かれていたアプリ開発チームに、Kotlin Multiplatform（KMP）を導入しました。
KMPの大きな特徴は、共通のコードで異なるOSのロジックを書けること。例えば、Androidチームが先にロジック部分の開発を終わらせていたら、iOSチームやTVアプリチームはそのコードを再利用するだけでいいんです。
馬場：それまでは同じロジックを構築するのに、それぞれのチームが別々のコードで書く必要がありましたからね。KMPのおかげで今回のアプリ開発はかなり効率化できたと思います。
堤下：「マルチデバイスあるある」を防げたのも良かったですよね。同じドキュメントに基づいて開発しても、出来上がったプロダクトを確認してみると、各アプリによって実装機能に差が出てしまっていることってけっこうあるんです。Androidアプリには機能Aがあるのに、iOSアプリには機能Aがないとか。でも、DMM TVアプリでは現状そういったことが起きていません。
福岡：プロジェクトが始まった当初は導入している企業がまだ少なくて「本当にこんな大きな開発で入れて大丈夫なのか？」という不安が少しあったんです。もちろん導入後はよくある「Beta版ならではのバグ」をきっちり踏みましたが、それでも結果的には全体の開発コストを下げることができました。間違いなくチャレンジした甲斐はありましたね。
社内のエンジニアに話を聞くと「DMMは新しい技術に寛容だ」とよく聞きます。みなさんも、そう感じていますか？
福岡：僕もそう思います。エンジニアが技術選定できる機会が少ない会社もあると思います。DMMでは、エンジニアが動作の検証をした上できちんとメリットを提示できれば、新しい技術を取り入れられることがほとんど。
堤下：これまで社内のいろいろなプロジェクトチームを見てきましたが、どこもエンジニアの裁量は大きかったですね。この規模の会社ではかなり珍しいと思います。
馬場：まさに今回のDMM TVのプロジェクトがそうですけど、DMMの魅力は何十万人、何百万人といったユーザーが利用するプロダクトの開発に携われることだと思います。加えて、新しい技術を積極的に活用できる環境が整っているというのも、我々エンジニアとしては大きなやりがいにつながっていますよね。
Android、iOS、TVアプリそれぞれのチームのチャレンジ
それぞれの開発チームで、技術面での挑戦や苦労があったんじゃないですか？
福岡：それで言うと、今回Androidチームでは「Jetpack Compose」というUI技術にもチャレンジしました。これもKMPと同じく世の中的には新しい技術だったんですけど、今後はこれがスタンダードになっていくというのが見えていたので導入することにしたんです。ユーザーのためになり、かつエンジニアの経験値にもつながる。そういった技術ならどんどん取り入れていくべきですからね。
堤下：iOSチームでは、KMPに関連してなかなかの苦労がありました。KMPは共通のコードをKotlinで書けるため便利ですが、iOSで利用する際はKMP特有の情報を持ったObjective-Cに変換されます。開発の際にどうしても扱いづらい部分が出てきてしまうのが少しネックでした。
ただ、KMPがアプリ開発全体に大きなメリットをもたらすのは間違いなかったので、チームメンバーとも議論を重ねて、最終的にはラッパーを作ることでその部分を解決しました。Objective-Cをさほど意識する必要のない開発体制を実現することができたので、そこからはさらにスムーズに開発が進んでいきました。
馬場：僕たちTVアプリのチームが一番苦労したのは、UIの開発ですね。今回はDMM史上最大のプロジェクトということで、少しでもリッチなUIを実装したプロダクトを開発したいと考えていました。
でもTVアプリはモバイルアプリと比較すると、開発されているテレビアプリの数が少ないので、比例してナレッジ、ドキュメントが少なくなっています。なので、とにかくUIのことを調べてはナレッジを共有する繰り返し。けっこうな工数をかけて、ようやく実現することができました。
チームの士気を保つためにリーダーがすべきこと
それぞれのチームで新しいチャレンジをされたんですね！DMM TVのような大きなプロジェクトでは、開発途中に変更が生じることも少なくなかったと思います。チームのリーダーとしてそこはどのように乗り越えていったんですか？
福岡：開発当初から「他社に負けない動画サービスを作る」というコンセプトを掲げていたので、リリースまでに何度か変更が出るだろうというのはある程度覚悟していたことでした。ただそうは言っても、変更のたびに大きく作り直していたら、メンバーのモチベーションがもちません。
だからAndroidチームでは、変更が生じる可能性が高い部分と低い部分を切り分けた上で、メリハリをつけて開発を進めていきました。リーダである僕はできるだけコードを書かかないようにして、その代わりにエンジニアが開発しやすい環境を整えることに全神経を注いでいましたね。とにかくメンバーをモヤモヤさせないように気をつけていました。
馬場：TVアプリチームの場合、何かしら動くものを作り続けることでメンバーのモチベーションを維持していましたね。細かい変更点はあまり気にせず、とにかく一旦形にする。ゴールに近づいているのを実感してもらうことを特に大事にしていました。
堤下：本来はメンバー全員がすべての変更を把握しながら開発を進めるのが理想なんですが、さすがにそういった情報が多過ぎるとストレスになってきますよね。だからiOSチームで意識していたのは、知っておくべき情報と対応すべき作業を絞ること。最初のフェーズでは、メンバーそれぞれに専門性を持たせることで、自分が関わる領域に注力できる形を取っていました。
DMMで活躍できるアプリケーションエンジニアとは？
現在、アプリケーションエンジニアを絶賛募集中だそうですね。どのような方を求めているんですか？
馬場：今回のプロジェクトを通して思ったのは、柔軟に動けるエンジニアの方だと助かるということですね。当然、開発時に自分のやり方はあっていいんですが、場合によっては大きな変更に対応しなければいけない場面も出てきます。そういう時でも、きちんと開発に取り組めるエンジニアはやっぱり心強い。
堤下：手段には固執せず、自分のやりたいことだったり、意思は持っておいてほしいなと思います。これからどういったプロダクトを作りたいのか、どういった機能を開発したいのか。エンジニアとしてそういった軸はすごく大切な部分ですからね。
福岡：僕はいろいろな人を巻き込みながら仕事ができる人と一緒に働きたいですね。自分がなにか困っていたらメンバーに共有して、逆にメンバーが困っているのに気づいたら自分ごととして協力する。良いプロダクトを開発するには、そうやってメンバー間の連携を高められるエンジニアの存在が必要不可欠だと思います。
今後アプリチームで実現したいことは？
福岡：アプリの品質を高めるという目標はそれぞれのチームが持っているんですが、同時にもっと多くのメンバーが様々なポジションを経験できるような体制にしていきたいなとも考えています。
例えば、リーダーを経験して初めて「向いている」「向いていない」が分かるわけじゃないですか。自分の適性に早めに気付ける機会は、エンジニアがキャリアの方向性を決める上ですごく貴重なもの。これからは積極的にポジションを割り振り、ひとりひとりのエンジニアの成長につなげていきたいですね。
(追記：2023/08/10)記事公開日にKotlin Multiplatform Mobile(KMM)がdeprecatedになり、Kotlin Multiplatform(KMP)に変わりました。https://blog.jetbrains.com/kotlin/2023/07/update-on-the-name-of-kotlin-multiplatform/
