チームKIOKUの開発体制 徹底解剖してみた
はじめに
こんにちは！
今回は私たち「KIOKU」開発チームの開発体制についてご説明したいと思います！ 私たちはメンバーが様々な場所に住んでいることもあり、開発を全てリモートで進めています。「チーム開発をやってみたいけどどうしたらいいかわからない……」という方には参考になるのではないかなと思います。
それでは早速、開発体制について紹介していきます。
開発体制
チームKIOKUでは、開発において大きく分けて、以下の2つのフェーズを設けています。
キックオフミーティング
開発フェーズ
キックオフミーティング
まず、各バージョンの開発を始める前に、開発チームでキックオフミーティングを行います。そこでは主に以下のことを行います。
アプリの課題点の洗い出し
今回のバージョンで取り組む課題の選択
タスクの切り分け
優先順位の選定
個人の割ける時間を申告
タスクの割り振り
このキックオフミーティングでは、notionのプロジェクト機能とタスク機能を用いてタスクの見える化を行っています。
これから、それぞれの過程について詳しくご説明します。
アプリの課題点の洗い出し
ここではアプリの中での課題点を洗い出します。
例えば、「ここが使いにくい」といったユーザビリティに関するものや、「ここの呼び出し方がよくない」といったコードの課題点などを思いつくだけ挙げて共有します。また、「こういう機能が欲しい」といった新機能に関してもここで提案します。
今回のバージョンで開発する点の選択
先ほどの課題点の洗い出しで出てきた課題や、以前に課題として挙げていたことの中から、今回のバージョンで取り組むものを選択します。
このとき、機能的にクリティカルな問題から優先的に選択するようにしています。
また、そのバージョンでテーマとしていること（例えば「今回のバージョンではデザイン修正を中心的にする」など）に従って選択することもあります。
タスクの切り分け
選択した課題を一つひとつをタスクとして切り分けます。
課題としては一つに見えても、工数や取り組む点においては複数に切り分けられることがあります。そのため、切り分けられる最小の単位でタスクとして区切ります。
優先順位の選定
切り分けたタスクに取り組む順番をつけます。絶対にこのバージョンで取り組まないといけないものは優先順位は高めに設定します。
個人の割ける時間を申告
期間内でメンバーがそれぞれどの程度、開発に時間を割けるかを申告します。
ここで全体の時間を見て、このバージョンで取り組むタスクの量が適切かどうかも確認します。
タスクの割り振り
各々の取り組んでみたい領域や先ほど申告した時間に合わせてタスクを割り振ります。ここの割り振りでスケジュールに無理があると判断した場合は、タスクを別バージョンに置いたりします。
開発フェーズ
次に開発フェーズについてご説明します。
キックオフミーティングをメンバーで行った後、各々が担当分のタスクに取り組みます。
開発フェーズでは、各タスクごとに以下の手順を行い、開発を進めます。
切り分けたタスクをgithubのissueとして登録
ブランチを切って開発を行う
開発ができたらプルリクエストを送る
テックリードからフィードバックをもらう
フィードバックを元に修正する
OKをもらったらテックリードがマージする
この開発フェーズでは、githubとgithub projectsを使用しています。
それでは、それぞれの過程について詳しくご説明します。
切り分けたタスクをgithubのissueとして登録
切り分けたタスクごとにgithubのissueとして登録します。
そこでは
・機能概要（どういう機能か）
・なぜその機能が欲しいか？
・どのように実装するか？
・参考URL
などの開発概要と開発の見通しを書き込みます。
ブランチを切って開発を行う
各issue（タスク）ごとにブランチを切って各々で各機能を実装します。その最中、適宜コミットします。
開発中にわからないことがあれば、slackや定例ミーティングの時に課題点や疑問点をメンバーに共有し、解決します。
開発ができたらプルリクエストを送る
機能の実装が完了したら、リモート環境にプッシュし、プルリクエストを送ります。
このとき、
・実装した目的
・実装した内容（関わるファイルで何をしたか）
・やり残した点・懸念点
・どのような動作確認をしたか
・その他（レビュワーへの参考情報など）
を記載して、レビュワーに何をやったのかの要点を伝えます。
フィードバックをもらう
プルリクエストを送ると、github actionでcode rabbitが動きます。そこで、code rabbitからのフィードバックをもらいます。
（このAI code reviewerについては過去に公開した記事『「KIOKU」開発チームのCI/CDをテックリードが紹介してみる』もご覧ください！）
さらに、テックリードがプルリクエストとcode rabbitからのフィードバックをみてコードをチェックし、フィードバックをコメントとして残します。
フィードバックに返信して修正する
エンジニアはcode rabbitとテックリードからのフィードバックを確認します。そして、フィードバックを元にコードを修正します。もしディスカッションが必要なら、テックリードとディスカッションをしてからコードを修正します。このフィードバックと修正をテックリードのOKが出るまで繰り返します。
マージする
問題ないコードであるとテックリードが判断すると、テックリードが該当ブランチを開発バージョンのブランチにマージします。
おわりに
いかがでしたでしょうか？
今回は私たちの開発体制について紹介しました。筆者は、このアプリを作成するまでグループでの開発をうまく行えなかったのですが、この方式で円滑に開発できるようになりました。また、タスクの整理を行ったり自分のコードの問題点に気づいたりする機会にもなりました。皆さんもぜひ参考にして見てください！
この記事を読んで私たちのアプリに興味を持った方は以下のリンクからぜひインストールをお願いします！
****************************************
iOSでのインストールはこちら！
AndroidOSでのインストールはこちら！
****************************************
この記事が気に入ったらサポートをしてみませんか？