みなさんこんにちは！
学生サーバサイドエンジニアのくろちゃん(@TakumaKurosawa)です。
この記事はOthloTech Advent Calendar 2019の12日目の記事になります。
前日の @satto_sann さんの「Tremaの環境構築とハローワールド(Ubuntu18.04LT)
」からバトンを引き継ぎました！
まだ読んでないよ〜という方は、是非こちら読んでくださいね！
今日はチーム開発をする上で取り入れた運用ルールなどをご紹介できたらと思っています。
是非最後まで読んでいただき、「その運用はもっと〇〇した方がいいよ」、「これおすすめ〜」みたいなアドバイスをいただけますと大変嬉しいです！
目次
⑴ 新チームでの開発が始動した
⑵ ①メンバーへの理解
⑶ ②GitHub運用ルールを定義した
⑷ ③スプリントミーティングのやり方を工夫した
⑸ おわりに
新チームでの開発が始動した
私は先月から新チームを結成して、Trelloのクローンアプリ開発を始めました。
個人としての技術力を上げることはもちろん、チームとして開発する上でどの様にしたらより開発しやすくなるのかという視点での学びも得たいなと考え一緒に開発してくれるメンバーを募りました。
現在はTrelloのクローンアプリケーションを作成していますが、ゆくゆくは自分たちのオリジナルのアプリケーションを作ったり、ハッカソンに挑戦したりしていきたいなと考えています。
チーム開発は個人開発とは異なり、1つのプロダクトに多様な人が関わります。スキルセットはもちろん、プロジェクトに参加している動機すら異なるメンバーが1つのチームとして開発を進めていく先には必ずと言って良いほど「チーム開発の壁」が立ちはだかります。
チーム開発の壁と一口に言っても、人間関係やコードの品質の問題、Gitの運用ルールの崩壊など様々な壁が考えられます。
今回の記事では開発する上で直面する問題に絞り、より良い開発経験を得られる様に私たちが導入した具体的な方策についてご紹介したいと思います。
①メンバーへの理解
開発を始める上で理解しておかなければならない前提として、メンバー全員が一人一人別々モチベーションでプロジェクトに参加しているという点です。
会社の作るプロダクトであれば、「作っているサービスで売り上げを出す」という単純明快な目標を立てるだけである程度全員が同じ方向に向かって進める様になるかもしれません。
ただし、私たちがやっているプロジェクトの向かう先に前述した様な明快なゴールはなく、一人一人違った価値観、目標を持って進んでいきます。
一人一人の向いている方向をメンバーが把握していない状態でプロジェクトが進むことに不安を感じた私は、ミーティングにて全員のプロジェクトに対する念いを打ち明ける時間を作りました。
この時間を設けたことは思ったよりも大きな効果を発揮しました。
「プロジェクトへの念い」ミーティングを通して得られた効果
- 他者の持つ良いマインドセットを自分に取り入れることができる
- メンバーがどんなことに興味があり、プロジェクトを通してどんなことを成し遂げたいと思っているのか把握しておくことで、割り振るチケットの種類などに融通が利く
- 自分自身がプロジェクトを通してなりたい姿を言語化することで、曖昧だったプロジェクトへの念いが明確化される
- 質問という形で他者からフィードバックをもらうことで、自分の立っている位置と目標との差分を確認できる
以上の様なメリットを享受できたと私は感じています。
特に、メンバー全員が各々の目標を理解していることで、タスク割り振りの際に適切な人員に適切な量のタスクが振れるという体験を得られたことが何よりも大きいメリットだなと感じました。
②GitHub運用ルールを定義した
チーム開発で要となるバージョン管理ツール（GitHub）をきちんと使いこなせているかで、プロジェクトの質が大き変わると私は思います。
そこで、私たちのチームではまずGitHubの運用ルールについて定義しました。
※私たちのチームでは、スクラム開発を採択しているため、プロジェクトの進捗管理をGitHubのProjectsを使って行っています。
GitHubを初めて使うチームメンバーもいたため、使い方も含めて下記の様なREADMEを作成してメンバーに共有しました！👇
--- READMEここから ---
GitHub運用ルール
- masterへの直接Push＝NG
- ブランチは下記のルールに則って作成する
feat/[issue番号]/[やること]
例）feat/1/createLoginPage
- 作業を始める時には必ずPullすること！
- プルリクは最低1レビュー以上無いとマージできない
GitHubの運用の流れ
1. 本スプリントで自分がアサインされているものの中から今から作業するissueを決める
2. そのissue番号を確認し、カードをIn progressへ移動しておく
3. masterブランチでPullしてくる
git pull origin master
4. 作業ブランチを切り替える
git checkout -b feat/14/writeDownREADME
5. 1コミットあたりの作業量を意識しながら作業をする
6. 作業が完了したら、変更したファイルが正しいか確認する
git status
7. 自分の変更した内容が正しいか確認する
git diff
8. 自分の変更分が正しいことを確認したらリモートへプッシュする
git add .
git commit
もしくは、
git commit -m 'hoge'
git push
※初めてプッシュする場合は、訳の分からん英文が出てくるが、落ち着いて、下記のような1行をコピー＆ペーストしよう！
git push --set-upstream origin feat/14/writeDownREADME
9. Pull Requestを作成する
10. descriptionに close #[issue番号] と入力
これをやっておくことで、マージされたタイミングに自動でissueがcloseになるのでおすすめ！
11. レビューしてもらいたい人をアサインする
12. ProjectsのカードをIn progressからレビューへ変更する
13. アサインしたレビュワーに対してレビュー依頼を送る（Slackの#reviewチャンネルで！）
▼定型文
@緋村剣心
お疲れ様です。
下記プルリクのレビュー＆マージをお願いします。
https://github.com/Takumaron/Orenotorero/pull/15
--- READMEここまで ---
READMEに記述しているルールは断片的なものばかりですが、基本的にはアサインされたチケット（issue）を1Pull Requestとして開発→レビュー→マージの流れを守る様に設計しました。
③スプリントミーティングのやり方を工夫した
前述した通り、私たちのプロジェクトはスクラム開発で行なっています。
そのため、スプリント（1週間）とスプリントの間で行うスプリントミーティングというものを取り入れています。
このスプリントミーティングでは、スプリント間での気づきや反省をチーム内で共有し、それらを踏まえて次のスプリントのタスク割り振りと目標を定義したりしています。
通常だとスクラムマスターと言われるポジションの人がこのスプリントミーティングのファシリテートをするのですが、チームメンバーの経験のため交代制でスクラムマスターのポジションをローテートしています。（まだ2回しかスプリントを終えていないですが。。。w）
スクラムマスターをローテーションすることで下記の様なメリットが得られたのは私たちにとって大きな収穫となりました。
- チームメンバー一人一人がファシリテーションという立場を経験できる
- 他の人のファシリテーションを見ることで、自分のやり方でより良いミーティングにしようと工夫しようとする姿勢が見られた
- ファシリテーターの視点を手に入れることで、ただの参加者の立ち位置でも積極的に場を盛り上げようと努力する姿勢が見られた
ただ集まってグダッて終わってしまいがちなミーティングも、スクラムマスター交代制を取り入れるだけで、非常に有意義で濃い時間にすることができました。
対面で人と人が会するかなり高コストな場であるため、有益でない時間は出来るだけ排除したいですよね。
おわりに
いかがだったでしょうか。
ここまでチーム開発を始める上でやって良かった運用をみなさんにご紹介してきました。
私たちのプロジェクトはまだまだ始まったばかりで運用面についても未熟なところが多いなと日々痛感しています。
より良いチーム開発を実現するために、みなさんのチームではどの様な工夫をされていますか？
是非コメントやTwitterで教えてください！
OthloTech Advent Calendar 2019の明日の記事は、 @kenshin1025 さんがJsonについての記事を書いて下さいます！
明日の記事も是非ご覧ください！