ちょっとだけモバイルチームの未来について話してみようか

こんにちは、YOUTRUSTのWebチームでエンジニアをしている中村です。

1年ほどモバイルチームに在籍していたのですが、2022年9月からWebチームに戻りました。久々にReact書いたりRails触ったりと、新鮮な気持ちで開発に向き合えている今日この頃です。

というわけでWeb開発やWebチームのお話かと思うかもしれませんが、再びモバイルチームのお話です。前回のお話はこちら。

tech.youtrust.co.jp

モバイルチームではクォーターに1回くらいの頻度で「今後のモバイルチームについて話しませんか？」というMTGを実施していました。

背景

YOUTRUSTはクォーター毎に目標・やる事を決めて開発を進めています。

私はモバイルチームで、リリース管理やエンジニアメンバーのタスクのアサイン、PdMなど上流工程との窓口などをメインでやっていたのですが、クォーター始めはまだやることが決まっておらず、エンジニアが手持ち無沙汰になるような状況がありました。

クォーターでやることが決まると、機能開発や数値目標のための開発が必然的に優先度が上がるので、落ち着いている時間にモバイルチームとして複利で効いてくるような改善を進めたり、開発の進め方などをアップデートしたいと思ったのがきっかけです。

MTGで発散ルール

このMTGで改善点の発散をしていくのですがルールは以下です。

緊急じゃないけど重要だなと思うことを発散する
会社の状況やプロダクトの今後を感じた上でやってみることを検討する
あくまで個人ではなく、会社やチームとして会社に貢献・ユーザーさんに提供できる価値を大きくするという点で思考・発散する

緊急じゃないけど重要だなと思うことを発散する

緊急で重要なこととして、クォーター目標達成の機能開発や機能改修がメインかなと思います。ただし、メインをこなす上でやっておいた方がスムーズにいくこともたくさんあります。特に技術的負債の改善やテストの自動化など技術面の改善は後回しにされがちですので、エンジニア視点で後回しにされがちだけど、これはやっておいた方が良いよねっていうものを発散しました。

技術面以外でもスクラムを導入したりリリースサイクルを見直したり、ペアプロの機会がほしいなど、チーム面での改善も対象です。

会社の状況やプロダクトの今後を感じた上でやってみることを検討する

やることの詳細は決まっていなくても、今後実装するであろう機能や何を伸ばしていくのかというのは日々のSlackやMTGなどのコミュニケーションから分かります。いざ方針ややることが決まっても、リファクタが必要だったり、既存のコードだと実現するのが難しいという可能性もあります。少々未来を見据えた上で、改善点を出していく方が建設的なのでルールに追加しました。

あくまで個人ではなく、会社やチームとして会社に貢献・ユーザーさんに提供できる価値を大きくするという点で思考・発散する

割とこのルールが大切かなと思っているのですが、「ここのコードの書き方が...」とか「ここの設計が...」とかエンジニアなら誰しも気持ち悪さや違和感のようなものを感じる部分はあると思います。ただその部分を解消しても、ユーザーさんに提供できる価値が大きくならない、やってもやらなくてもプロダクトに影響がないものもあります。（もちろんやらないという訳でなく優先度が低いという意味）

あくまで技術的観点およびエンジニア観点から、会社やユーザーさんに良い影響を与える改善を考えようというのを軸にしています。

どんな意見がでたのか

これまでに2回このMTGを行いました。 2回目で出た技術的課題とチームの課題をそれぞれ載せたいと思います。

実行

タスクのアサインやPdMとコミュニケーションをとっていた私が良い感じにやれば良いだけなのですが、優先度やどのタイミングでやるかなどはある程度チームで認識を合わせました。認識を合わせた後はPdMとコミュニケーションをとり、スプリントに組み込む、副業メンバーにアサインして進めてもらう、KAIZEN DAYで取り組むなど、具体的な行動とスケジュールに落としていきました。

KAIZEN DAYについてはこちら

tech.youtrust.co.jp