会員数3,900万人を超える総合エンタメサイト「DMM.com」を運営し、60以上のサービスを展開する、合同会社DMM.com。エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Team+」を活用いただいています。

今回は、DMMブックスアプリを手掛けるebook-native-androidチームのエンジニア、佐藤さんと柴田さんにインタビュー。開発チームにおける課題と取り組みについて、「Findy Team+」のデータを踏まえながらお話を伺っていきます。

DMMブックスアプリを通じて、快適な読書体験を提供する

――まず最初に、お二人の自己紹介をお願いします。

佐藤：DMMの佐藤です。ebook-native-androidというチームで、Androidエンジニアをしています。「Findy Team+」をチームで使い始める際に、見るべきデータや目標数値の検討を行うなど、導入に携わりました。

柴田：同じくebook-native-androidチーム所属の柴田です。今年3月にジョインしており、時期的には「Findy Team+」が導入された後から参画しています。役割としては、Androidアプリエンジニアとして既存機能の改修などを行いつつ、最近は並行して採用活動も行っています。

――事業部やチームのミッションを教えていただけますか？

柴田：組織体制としては、二次元事業本部という事業部のなかに、ebook-native-androidチームが属しています。事業部のミッションは、「最高の読書体験をつくる」こと。チームとしては、「DMMブックスアプリを通じて、快適な読書体験を提供する」ことをミッションに掲げています。

――ebook-native-androidチームの体制について教えてください。

佐藤：現在はプロパーが4名の体制で開発しています。これにプラスしてマネージャーがいますが、実際の開発に携わるエンジニアとしては4名。また、スクラム開発を行っているので、プロダクトオーナーもいます。

今後、既存メンバーの入れ替わりが予定されていることに加えて、アプリの機能追加や古い機能の改修などを行っていくため、人が足りていません。なので、開発と並行して採用の時間を設けて、積極的に面談や面接を行っています。

――チームでは現在、主にどのような開発を行われていますか？

柴田：電子書籍のビューア機能をはじめとする、主機能のリプレイスですね。最近は、新規機能の開発はあまり行っておらず、今ある機能の品質をより上げていくことに注力しています。

Androidアプリの開発では、言語をJavaとKotlinから選ぶことができますが、ブックスアプリは歴史のあるアプリなのでJavaのコードが多岐に渡っています。ただ、今後の開発のしやすさや保守性を考えると、Kotlinに置き換えていきたい。なので、既存の不具合をつぶしつつ、いま提供している機能と価値を毀損させずに開発しやすくしていく、といったことに取り組んでいます。

「Findy Team+」導入で、プルリクのサイズに指標ができた

――「Findy Team+」を導入される前は、チームでどういった課題を感じられていましたか？

佐藤：プルリクのサイズが大きく、レビューの負荷が高くなっていました。そのため、レビュー時間が長くなったり、差し戻しが発生したり、実装意図の確認に時間がかかったりしていたんです。

加えて、本来であればレビューで弾くべき細かなミスや、今後不具合として出てくる可能性のある部分を見落としやすくなっていた部分もありました。ただ、プルリクはもともと大きく作られることが多かったので、みんなあまり意識せずに作っていた状況でした。

――「Findy Team+」の導入を決めたポイントはありましたか？

佐藤：DMMとしてはすでに「Findy Team+」を導入していて、他のチームが先行して使っていたという背景があります。Androidチームとしては、プルリクが大きいことを徐々に意識し始めていたのですが、どのくらいなら適切なのかという基準がわからなかったんですね。

でも、他のチームが「Findy Team+」を使っていたので、変更行数やプルリク作成からアプルーブまでの時間などの数値を見れることがわかっていました。なので、それを参考にAndroidチームの数値目標を作ろう、という話になったことが導入のきっかけです。

――現状どのような形で「Findy Team+」を活用いただいていますか？

佐藤：2週間のスプリントでスクラム開発を行っているので、現在は「Findy Team+」での振り返りも1スプリントごとに行っています。内容としては、サイクルタイム分析でどこに時間がかかっているか、変更行数でプルリクが大きくなりすぎていないかをチェックしています。その他に見ているのは、マージ数やプルリク作成数などですね。

ただ、「Findy Team+」の運用に関しては、今後少し変更しようとしています。というのも、メンバーによって1スプリントで行う作業に差異があり、数値目標を掲げたものの、うまく集計できないケースが出てきてしまったからです。

そのため、今後は2スプリント合わせて、1ヶ月単位で「Findy Team+」を確認していこうとしています。そうすることで、1スプリントは設計、1スプリントは開発という形で進めた場合などでも、全体を通しての振り返りができると考えています。

――「Findy Team+」を活用して、どんなところが良かったと感じられますか？

佐藤：プルリクの具体的な行数の数値目標ができたので、プルリクが小さく見やすくなり、チームで上手くまわせるようになりました。ここは良かったところの1つだと思います。

柴田：新たにチームにジョインした側の目線でお話すると、1つのプルリクにどこまでを含めるか・どれくらいのサイズにするかといった粒度は、「Findy Team+」がなかったら、おそらく過去のプルリクを参考にしていたと思います。とはいえ、過去のすべてのプルリクが参考にできるものになっているかと言われると、きっとそうではないでしょう。

もし指標が決まっていなかったら、レビューのときにも「ちょっとサイズが大きいですね」といった抽象的なコメントになってしまいます。でも、「Findy Team+」を使って指標が決められているので、指標と比較して適しているかどうかが、チームにジョインしたばかりの人でもわかる。そこはすごくやりやすかったなと感じますね。

上流の設計レビューに時間を割き、プルリクを200行以内に

――実際に「Findy Team+」で導入前の半年のデータを見てみると、総合的なスピードはそれほど遅くありません。ただ、相対的に見ると、たしかにオープンからレビューまでの時間や、レビューからアプルーブまでの時間が少し長いことがわかります。

佐藤：そうですね。やはりプルリクのサイズが大きすぎて、レビューで差し戻しがあったり、レビュアーの負荷が高すぎてなかなか見れなかったり、見ているけれども時間がかかりすぎてしまったり、といったことが多かったので。そのあたりが「Findy Team+」を導入したことで、わかりやすくなりました。

導入半年前〜取り組み開始（2022年7月～2023年1月）のサイクルタイム推移

――プルリクのサイズは、どれくらいを目標に設定されたのでしょうか？

佐藤：導入当初は、1人1スプリントあたりのプルリク作成数を8個、変更行数を200行を目標としました。ただ、これはちょうど案件が重なっていた時期だったので、プルリク数については設計フェーズなどを考慮せず、フルで開発に入ることを想定した数字です。

――過去1年の変更行数のデータを見ると、年明けごろは200行くらい。2月の終わりごろからは30～40行台になり、直近は100行以内で安定しています。取り組みを開始した時期はいつごろでしたか？ 導入半年前〜直近（2022年7月～2023年5月）の平均変更行数の推移

佐藤：DMMとしては、昨年7月に「Findy Team+」が導入されていたのですが、Androidチームが使い始めたのは12月ごろでした。そのころから徐々に、先に「Findy Team+」を使っていた他チームのデータを確認するなどして、実際に取り組みを始めたのは年明けからでした。なので、「Findy Team+」導入から取り組み開始まで、準備期間が1ヶ月ほどあったイメージです。

――先行して使っていたチームがあったことで、目標を決めやすかった部分はありましたか？

佐藤：ありました。他のチームの変更行数がだいたい300～400行くらいだったので、うちのチームでは、それよりも小さい200行を目標にしましょうと。参考にする数値がなかったら、目標が漠然としたものになっていた可能性もあるので、先行しているチームの存在は大きかったですね。

――プルリクを小さくするために、具体的にどのような取り組みをされましたか？

佐藤：一言で言えば、レビュワーがレビューしやすいプルリクを作るように心がけたことですね。以前までは、例えばAPIを改修したら、APIを利用する部分にも変更をかけたり、レスポンスデータの部分も入れたりしていたのですが、それを1クラス1プルリクくらいの意識に変えていきましょうという話をしました。

加えて、それだけではなかなか難しいので、プルリクを出す前にまず設計とレビューをしっかりと行って、その設計をそのままコード化する方針にしました。そうすることでレビュアーも事前にプルリクの意図がわかり、レビューしやすくなりますし、プルリクが大きすぎる場合も分解の余地がわかりやすくなり、指摘もしやすくなります。

それに、小さな部分だけのチェックになれば、余計なことを考えなくて済みますから、細かなミスも見つけやすくなって品質が上がります。クラスをまたいで確認することも減ったので、お互いにとってより見やすくなりました。

柴田：レビュー工数を、コードレビューだけでなく、設計レビューにもまわすようにしたところが大きいですね。僕がチームに入ったときには、すでにそうした流れがあって、その施策が良かったから継続されているのだと思います。

朝会や夕会の後に適宜、必要に応じて設計レビューの時間を取ったりもしています。これはプルリクを小さくするための取り組みの一環で、設計レビューの時間を短ければ20分、長ければ1時間くらい取っています。

――より上流の工程に時間を割くようにされたということですね。

佐藤：そうですね。上流で見つけられれば、影響範囲が少なく済む不具合が往々にしてあります。それから、設計書レビューなどは、たいていZoom等で通話をつなぎながら行うので、ちょっとした疑問にも触れやすい。実際に、そうした疑問から調べてみたら、考慮されていない内容が見つかったりすることもありました。

サイクルタイムの合計は、取り組み前の半分以下に短縮

――導入前から直近までのサイクルタイム推移を見ると、1月を過ぎてから、オープンからレビューまでの時間と、レビューからアプルーブまでの時間が圧倒的に短くなっていますね。2月から現在までの期間と比べてみると、それぞれ5時間ずつ短くなっています。合計値を見ると半分以下になっており、素晴らしい結果と言えます。 導入半年前〜直近（2022年7月～2023年5月）のサイクルタイム推移

【Before】 導入半年前〜取り組み開始（2022年7月～2023年1月）のサイクルタイム平均値

【After】 取り組み開始〜直近（2023年2月～2023年5月）のサイクルタイム平均値

――こうした結果を出すまでに、取り組みにおいて苦労したことはありましたか？

佐藤：導入した当時は、開発体制がSES1～2名、プロパー2名と小規模だったので、取り組みの浸透にはあまり苦労しませんでした。人数が少ないなか、レビューに工数をかけていると開発がまわらなくなってしまうため、みんながレビューの負荷に問題意識を持っていたことが大きかったです。

――プルリクが小さくなり、レビューが早くなったことで、どのようなメリットがあったと感じますか？

佐藤：以前と比べて品質が良くなり、QAで発生する差し戻しが減りました。レビューが見やすくなったことで、小さな疑問も確認しやすくなって、その段階でつぶせるバグが増えたと思います。自分がレビュワーになった時にも、他メンバーが作成したプルリクのサイズが小さいことでレビューしやすく、メリットを体感できていました。 また、一つ一つのプルリクが小さく、フットワークを軽くできたことによって、意識として修正が必要なことを前提にマージしていき、問題が起きた場合は次のプルリクで修正することを許容する姿勢を取れ、さらにマージまでのスピードを上げることができました。

柴田：ネイティブアプリは審査もあって社内だけで完結しないことから、アプリリリース頻度はあまり変えていないですが、リリースの内容量は増えていると感じています。やるべきことは常にたくさんありますから、差し戻しが減っている分、次の開発に取り掛かることができます。なので結果的に、開発スピードが上がっているのではないかと思いますね。

――その他にも、良い変化を感じた部分があれば教えてください。

佐藤：過去のプルリクをさかのぼって、「ここのソースどうだったっけ？」と確認してみると、取り組み以前の内容は自分のものでもすごく見にくいんですね。そういった過去のものをさかのぼるときも、内容が見やすくなったと思います。

それから、プルリクを分ける関係で、テストコードはテストコードだけを書くようになったので、書きやすくなりました。いろいろ細かく分けるようになったおかげで、自分のなかでの整理がつきやすくなった感覚があります。

柴田：チームにジョインした側の目線としては、定量的に日々の開発を分析しているので、数字をもとに、無茶ではない現実的な計画が立てられているんだなと。僕は自社サービス開発の会社に転職したのが初めてなのですが、そこがすごく良いなと感じました。

佐藤：あとは、「Findy Team+」の数値を見ることで、各自の作業や工程の判断がつきやすくなりました。これによって作業の偏りがわかりやすくなり、業務の分担やマネジメントもしやすくなったと思います。１スプリントあたりこのくらい消化できるという判断ができ、忙しい期間などに、どのくらい捌けるかジャッジしやすくなりました。

また、「Findy Team+」を用いてスプリントごとに振り返ってフィードバックを共有できたことで、自分たちの改善活動のメリットを享受できていることが自覚でき、取り組みを加速させることができました。改善活動を促進するには、こういったチャレンジ結果を実体感できることが重要だったと思います。チームメンバーからも、定量化したことで根拠をもって改善に取り組めていることが良いという声が上がっています。

量・スピード・質を最大化し、改善と並行した新規開発へ

――今後、チームとして目指していきたいことを教えてください。

佐藤：目指しているのは、量・スピード・質の3面の最大化です。どれか1つを徹底していけば、おのずと残りの2つも伸びていくものだと思いますが、一人ひとりがそれを意識しつつ、日々開発に携わっていけるようにしたいと思っています。

また、DMMブックスアプリは歴史が長く、古いコードがたくさん残っていますが、そうした部分の改善と並行して、新規開発も行っていきたいです。今はマンパワーが足りず、改善が中心になっていますが、「1スプリントでこれくらいの開発ができる」という実績がつくれれば、新規機能の開発にも工数を割り振っていけると考えています。

柴田：「Findy Team+」の数字は、ディレクターサイドへの交渉にも使えると思っているんです。負債を返済している状況だと、なかなか新機能の提案がしづらいですが、両方を並行してできることが示せれば、新機能の提案もできるようになってくる。なので、そういった力をつけていきたいと考えています。

今よりさらに「Findy Team+」を活用していく方法も、これまでの成功体験を踏まえたうえで、いろいろと考えていきたいですね。「Findy Team+」を使った振り返りの頻度の見直しもそうですし、まだまだ活用していける機能がたくさんあると感じているので、項目の見直しもしていきたいと思っています。

――それでは最後に、採用に向けたアピールをお願いします。

柴田：アプリをこれからどんどんグロースしていきたいので、積極的な採用を行っています。DMMには、理念にもある通り、稼ぐことを念頭に自ら行動する人、新しいことにチャレンジしたい人が集まっています。

また、僕らはDMMブックスアプリを扱うチームですが、DMMは電子書籍だけでなく、総合的なエンタメプラットフォームを目指しています。なので、どこかしら輝ける場所があるところが、組織のアピールポイントです。

――一緒に働きたいと考えているエンジニア像はありますか？

柴田：会社の規模がそれなりに大きいので、DMMブックスアプリのチームにジョインしたとしても、その開発だけをやっていればいいわけではありません。プロダクト開発を進めていくうえで、必ず別の部署やチームの方々との連携が必要になってきます。

そうした部分は、コミュニケーションコストが高く時間がかかりがちですが、スピード感を持って自発的に動き、まわりを巻き込んで進めていけることが重要です。そういった自走できるエンジニアを、常に求めています。

――佐藤さん、柴田さん、ありがとうございました！

※DMMの採用ページでは組織の開発効率を改善したいエンジニアを募集しています。 Androidエンジニア(オープンポジション) iOSエンジニア(オープンポジション)

※「Findy Team+」のサービス詳細は、以下よりご覧いただけます。 https://findy-team.io/service_introduction