入社1年でPocochaの開発者体験を改善していっています

こんにちは。PocochaのAndroidエンジニアをしている水谷です。入社して約1年が経ちましたので振り返りを兼ねて最近行なっている改善の話をします

Pocochaとは

Pocochaは配信者 (ライバー) と視聴者 (リスナー) がライブ配信を通じてコミュニケーションするアプリです

Pocochaについて詳しくはこちら:

エンジニア視点でシステム全体を考えると、配信基盤やライバー事務所のためのプラットフォーム、イベント開催のための機能などがあります。アプリケーションエンジニア的には配信画面・視聴画面でカメラや動画プレイヤーの技術を使い、そのほかに配信一覧・ユーザープロフィール・ランキングなどの一般的な画面があります。さまざまな機能があり、それぞれでいろんな技術を使っているのでサービス規模・組織規模のどちらも比較的大きめかなと思います

Pocochaの開発体制

Pocochaの開発組織は鋭意拡大中で組織変更が頻繁にあるのですが、概ね以下のようなチーム構成になっています

配信画面・視聴画面などのコア機能を担当する技術基盤チーム
ビジネス価値にフォーカスした機能開発を担当するアジャイルチーム

アジャイルチームは名前の通りアジャイル開発を行なっていて、複数のチームがあります。自分もこのアジャイルチームの一つに所属しています

アジャイル開発について詳しくはこちら:

これらのチーム構成とは別に職種ごとのグループもあります。たとえばAndroidにはAndroidギルドがあり、Androidギルドは各チームに所属しているAndroidエンジニアの集まりとなっています

具体的な働き方

DeNAではハイブリッドワークを導入していて、フルリモートで働くこともできれば出社して働くこともできます (部署や担当領域によって一部例外があります) 。フルリモートで働けるということは遠方に住むこともできます (こちらも一部例外があります) 。また、最近コアタイムなしのフルフレックスが始まりました

PocochaでもDeNAの方針通りな働き方を採用していて、自分は主にリモートワークを中心に働いています。出社するのは用事がある日に用事のある時間帯だけというスタイルを取っていて、最近はチームの新しいメンバーの歓迎やランチのお誘いなどで平均すると月2回ぐらいの出社ペースでした。出社に意味を見出せてるので個人的にはこの働き方が気に入っています

普段の開発ではアジャイルチームのタスクを中心に行なっています。アジャイルチームではペアプログラミングを採用していて、ペアプログラミングをすることでより小さなフィードバックループで開発を行えたり、コード設計の議論をしながらコーディングができたり、新しいメンバーの育成も同時にできたりします

Androidギルドの活動としては週1回定例があるのと、定例の後にモブプログラミングを行なっています。比較的ギルド活動の時間は少ないですが、ギルドタスクがあり、アサインされた人は空いた時間を見つけてギルドタスクもこなしています

アジャイルチームでの改善

アジャイルチームにはそれぞれのプラットフォームのエンジニアとQAとProductOwner (PO) が所属しています。その上でエンジニアリングマネージャーの役割があり、チームの誰かがその役割を担っていました

POはアジャイルチーム内で施策に対してユーザーに価値を届けることに責任があり、そのため業務範囲が広くなっていました。そこで、POの業務からアジャイルチーム内でのパフォーマンス向上についての責任や定常的に行なっているイベント (朝会やレトロスペクティブなど) の運営業務を分離することになりました。分離した役割をここではスクラムマスターと呼称しています

そこで自分がスクラムマスターの役割を担うことになり、いくつか改善に取り組んでいます。この記事では取り組んでいる改善について紹介します。ただし、8月の初めにこの話が出たこともあり、改善の結果がわかっている部分が多くないため、何をしているかという部分を中心にお伝えします

タスク管理の改善

今までタスク管理はエンジニアとQAの作業を1つにまとめたチケットに対してエンジニアの実装の相対難易度によって1, 2, 3のいずれかの数値を見積もっていました

相対難易度見積もり

1: 簡単・すぐ終わるタスク
2: 通常の開発タスク
3: 難しい・調査が必要なタスク

相対難易度のため、見積もったポイントが同じでもかかる時間が大きく異なることもありました。そのため、難易度はわかるけど、見積もった数値を見てそれが何かに繋がるわけでもないという状態になっていました

そこで、タスク管理および見積もりに意味を持たせるためにスケジュールの逆算を目的とした変更を加えることにしました。スケジュールの逆算という観点では、以下の3点が問題になりました

スケジュールにはエンジニアの作業と同等にQAの作業も影響するが、QAの作業部分に関しては見積もりにいれてなかった
相対難易度見積もりだったため、チケット間の工数比較ができない
チケット間の工数比較できないので、チケット消化のスピードと残りチケットからスケジュールが逆算できない

これらの問題に対し大きく2つの変更を行いました

エンジニアとQAの作業をそれぞれ別のチケットにし、それぞれ見積もる
相対工数見積もりにし、ポイントはフィボナッチ数 (1, 2, 3, 5, 8, …) でつける

相対工数見積もり

1: 半日以内で終わりそうなタスク
2: 実装時間が取れれば1日で終わるタスク
3以上: 2を基準とした相対見積もり

相対工数見積もりの基準をいずれかのチケットにしてしまうと、職種間での粒度の差を生んでしまったり基準が想像つかなそうだったので、解像度の高くよりやることが明確な短めのタスクについて具体的な時間に連動するように基準を設けました
これで、理論上はスケジュールの逆算ができるようになりました。実際にはQAの作業をチケット化したり見積もったりすることを今までしてこなかったので運用に慣れてもらう必要があります

今のところは大きな問題もなく運用できており、スケジュールの逆算もある程度できている感触があるのでこの運用でタスク管理を行なっていきたいと考えています

実質的なコアタイムの削減

先ほど、最近DeNAでコアタイムなしのフルフレックスが始まりましたと言いました。しかし、実際にはチームとして働く上で定常的なミーティングがあり、それが実質的なコアタイムになってしまいます
仕事をする上でチームワークが重要なことは理解しつつも、フルフレックスなのに実質的なコアタイムができてしまうのはなんか微妙ですよね

自分が所属しているアジャイルチームでは伝統的に10時6分から朝会を実施していました。ある時、チームメンバーの多くが夜型であることが発覚し、みんな眠たい中で朝会に参加していたことがわかりました (笑)
みんな眠い中、朝会をすることに意味はないのでいったん時間の都合がそろった11時に朝会をずらすことにしました。体感的には寝坊して朝会を遅刻・欠席する人は減ったんじゃないかなと思います

このことをきっかけにチームメンバーに実質的なコアタイム減らしていきたいよねと話をしたところ、金曜日の夕方に行なっていたレトロスペクティブももう少し早く終わらせて華金しやすくしたいという声があがりました
当然、レトロスペクティブも早めたのですが、どうしてこうしているのかの背景を共有することによってみんなで改善のアイデアを持ち寄れるようになる良い事例になったと思います

今後の展望

タスク管理や朝会の運営など、いろんな業務フローをなぜそうしているのか目的の分解を行なっています。至上命題として"ユーザーに価値を届ける"があると考え、そこから目的の分解を行い、分解された目的に合う業務フローにしていっているのですが、現在のところ品質やUX、施策の検証・事前調査に関する業務フローがあまり整備されてないことが浮かび上がりました

そのため、今後はまず品質やUXにより注力するような業務フローを整備するところに着目したいと考えています。具体的にはお触り会とペアデザインを考えています

お触り会はチームみんなで開発途中のアプリの率直な触りごこちを見ていけたらなと考えてます

ペアデザインはペアプログラミングと同様にデザインに関してもより小さなフィードバックループで開発できるとよりよいUI/UXになるのではないかなと想像しています。また、ペアデザインはデザイナー同士ではなくデザイナー+エンジニアで行なっていくといいんじゃないかなと考えてます。iOS/Androidでそれぞれできる/できないは違いますし、それをデザイナーさんが完全に理解するのってやっぱり厳しいですよね。なのでUI/UXエンジニアの役割を作りiOS/Androidエンジニアの誰かにその役割をやっていただこうかなと考えています

ここまで、自分が所属しているアジャイルチームでの改善の話をしてきましたが、アジャイルチームごとにいろんな改善施策を回していたりします。最終的にはそれぞれのアジャイルチームの良いところを持ち寄っていきたいですね

Androidギルドでの改善

アジャイルチームにおける改善だけではなくAndroidギルドにおける改善も行なっているので、それについても紹介します

ドキュメントの整備

Pocochaでは組織拡大を行なっていて、Androidエンジニアの人数も日に日に増えていっています。その中でスケーラビリティの問題が浮上してきました

その中で真っ先に改善できるものとして、ドキュメントの整備があったので

オンボーディングフロー
PRレビュー観点
現時点でわかってる設計

などについてドキュメントを用意しました

ドキュメントを用意しただけで終わりというわけにはいきませんが、Pocochaでは入社時にオンボーディングパートナーをつけ、業務のサポートをするようにしています。また、アジャイルチームではペアプログラミングを行なっているので、ドキュメントを読んでもわからないことはすぐに他のエンジニアに聞くことができます。ドキュメントと他のエンジニアにすぐ聞くことができる環境を活用して、各自オンボーディングを順調に進めてもらえればなと思っています

detektの導入

自分が入社した当初はコードフォーマットは各自が実施し、CIでのコードフォーマットの確認は行われていませんでした。その後すぐにktlintが導入され、一定程度コードフォーマットが揃うようになりました

現在のKotlin界隈ではktlintもしくはdetektが使われていることが多いかと思います。detektはktlintのルールも収録されているので個人的には上位互換だと思っています。また、Android Studioに detektのPlugin を入れるとIDE上でWarningを確認することができます。そのため半年ほどktlintを運用したのち、detektへの移行を行いました

IDE上でdetektのwarningが出ている画像 — IDE上でマウスでホバーしdetektのwarningを表示している画像

メリットとしては、CIに怒られるより前にコードフォーマットのWarningを確認できるので、修正の手間が削減できることですね。デメリットとしてはktlintよりかなり多くのルールが収録されてるので、既存リポジトリーに新たにdetektを導入するとかなりのWarningが出てきてしまいやすいことだと思います。この点においてPocochaではktlint互換のルールのみを有効化し、今後新しいモジュールには他のルールも解放していくという方針を立て、回避することにしました

リアーキテクチャー

現在のPococha Androidアプリは複数の設計が入り乱れたコードになっています。そのため、レイヤーごとの責務が曖昧でなんとなくこのクラスはこうしたほうがいいなという感じでコーディングする状態でした。ここでもスケーラビリティの問題に直面したので新しく設計を考え、リアーキテクチャーをしていくことになりました

今の所、大まかな設計は完了していて、あとは基盤部分の作り込みと既存画面のリファクタリングという状況です。方針としては配信画面と視聴画面のような複雑な画面の設計は一旦考えないようにして、それ以外の画面を効率的に開発できるようにという感じで設計しています。特徴としては構造化したマルチモジュール・Jetpack Compose・Kotlin Coroutine・One-shot API・Composable function側でのUI State計算という感じになっています

リアーキテクチャーに関しては今後記事にしていきたいと考えているので、お待ちいただければと思います (1年以内を目処に書きたいという気持ちがあることは宣言しておきます)

今後の展望

今後としてはしっかりとリアーキテクチャーを進めていきたいと考えています

また、最近直面した問題としてPRレビューやAndroidエンジニアへの問い合わせに対応する人が偏っており、普段対応している人のタスクの状況次第では対応に時間がかかるという状況に陥っていました。Androidギルドでアンケートをとったところマインドセット的な側面で解決できそうだったので現在解決に向けてアクションの実行中です