見出し画像

noteモバイルチームの開発フローのカイゼンの変遷

モバイルメンバーが増えた2020年5月からチームとアプリのリリースフローを少しずつカイゼンしてきました。

そんな中で最近はモバイルチームにPdMもジョインしてもらい開発フローのカイゼンも進みました。この記事ではモバイルチームのカイゼンやアプリのリリースフローのカイゼンの変遷を書いていきます。

モバイルチーム突然の増加期

2020年5月までiOSアプリの開発者1名、Androidアプリの開発者1名の2名体制でした。そこからiOSアプリの開発者が2名増えました。当初は元々在籍していた人にタスクを用意してもらってそれを新たに入社したメンバーが対応するような流れで開発していました。

画像1

しかし、それだとタスクを管理する人とタスクを実行する人と分かれてしまうのでタスクを管理する人にどうしても仕事が集まってしまいます。とはいえSlackを巡回していると必要なタスクも転がっているのでそういうタスクを見つけては自分でIssue化して対応したりしていました。

ZenHub利用期

チームとして動き始めて少しずつチームの中でも課題が出てきました。課題の例としては
・そもそもリリースをどうするか明確に決まってなかった
・タスクの優先度が曖昧だった
・どういうタスクをいつ対応したのか管理ができていなかった
などがありました。

そこでまずスプリントという概念を取り入れて、それに伴いアプリのリリースを定期的に実施するようにしました。(スプリントもアプリのリリース頻度も共に2週間に設定)スクラムを参考にして定期イベントを実施するようになりました。

・月曜日: 午前中に雑談タイムを設置(スプリントプランニング的な感じでどういうタスクをするかを相談)
・毎日: 前営業日やったこと/今日やること/困ってることをSlackに投稿(デイリースクラム)
・金曜日: Weekly定例(レトロスペクティブ的な感じで振り返りを実施)

タスクの管理ツールは見出しにもあるZenHubを利用していました。ZenHubではRoadmapを作成し、大きめのタスクをEpicとして、ガントチャートを作成するような運用をしていました。

リリース内容共有会

これまではアプリをリリースする際には社内Wikiに情報をまとめて、Slackにこういう機能がリリースされたよと知らせる程度でした。しかし、人数が増えて定期的にアプリをリリースするようになったことで、割と大きめのタスクや細かい改修が沢山入ることになり、社内WikiにまとめてSlackで通知する程度だと中身を見る人がいたりいなかったりするという問題がありました。特に、CSの人が内容を知らないと問い合わせの際に困ることもあるので、CS・PR・ディレクターの予定を定期的に確保して次回リリースするものがどういうものかを共有する会を実施することにしました。(スクラムでいうスプリントレビューに近いです)当初はビルドしたアプリを動かすのみでしたが、件数が多くなることで操作にもたつきが発生したりしたので、before/afterの動画を撮影して動画で紹介するような方法に変更しました。
リリース内容共有会を実施してよかったことの一つに、これまではあまり業務でもコミュニケーションを取る頻度が少なかった部署の人とコミュニケーションができるようになりました。基本的にみんな在宅ワークをしているのでこういう機会は必要だなと感じました。

PdMジョイン

ZenHubを利用している間はタスクも潤沢にあり、どの課題をいつリリースするかが管理できればよかったので運用としては回っていました。しかし、ある程度大型のタスクの対応が済んでしまうことで新たな課題が浮き上がってきました。ぼんやりとタスクは沢山あるけど明確な仕様だったりタスクの優先度が定まらないという問題です。これまではiPadのサポートに向けて必要な対応だったり、ウェブ側で先行している機能をアプリでもサポートするための開発を行ってきました。しかし、これらの対応がある程度済んでしまうと今度はアプリをどう伸ばしていくのかというモバイル独自の課題に直面しました。元々開発者とデザイナーしかいないチームだったので、既にあるタスクを対処することはできるけど、タスクを考える・優先度をつけるということが得意な人がいないことが問題になりました。そこで、知り合いでPdMをやっている人に話して業務委託という形でモバイルチームのPdMにジョインしてもらうことになりました。

PdMが入ってから変わったこと

これまではタスクがiOS/AndroidそれぞれのGitHub Issuesに並んでおり、まとめてどのようなタスクがあるのか分かりづらいという問題がありました。そこでGoogleのスプレッドシートにタスクを全て並べ、iOS/Android/デザイン/バックエンドのどこに対応が必要なのか、仕様が不明確な場合はDesign Docを貼って仕様を揉みながら明確化する活動ができるようになりました。

画像2

また、既存のIssueの棚卸しも行い、本当に必要なタスクだけを残して優先度の並び替えを行いました。これまではSlackリアクションを貼るだけでGitHub Issueを作成するワークフローがありましたが、これは生かしつつ、スプレッドシートにも行を追加するようにすることでなるべくタスクの作成がSlack上だけで完結するようになっています。

また、金曜日の定例の時間を利用して、曖昧なタスクの仕様を明確化する活動が行われたり、みんなでアイデアを捻り出すワークショップが行われたりとこれまでになかった活動も実施されるようになりました。社内のSlackやZoomの会議を巡回してキャッチアップはみんなしていますが、深いところまで理解が及んでいないことがあります。そういうタスクのキャッチアップをしてくれたりもして助かっています。

まとめ

入社してからチームでの活動に焦点を当てて振り返ってみました。先日リリースしたiPad対応はチームとしても大きな節目になり、今後はよりアプリ独自のカイゼンが進んでいくことになると思います。そういった場合でも迷わず進んでいけるようにするために、PdMに入ってもらってフォーマットを作ってもらいました。また、先日PdMの募集も始まったのでnoteのPdMに興味のある方は是非覗いてみてください。


この記事が参加している募集

オープン社内報

この記事が気に入ったらサポートをしてみませんか?