1 はじめに
本日TECH CAMPでの最終課題が終了いたしました。
最後の課題はフリマサイトをアジャイル開発のスクラム手法で作成するものでした。
今回スクラムマスターを担当させていただき、至らない点もありましたが、チーム一丸となって一つの作品を作り上げることに貢献できたと思っております。
さて今日の内容は、今回チームメンバーと決めたルールについてです。実際のプロジェクトと違って、あくまでスクール内でのチーム開発ですので、自分たちのプログラマーとして成長できるようなルール設定になっているかと思います。
アジャイル開発だけでなく、またプログラマー以外の職種でのチーム作業でも有効ではないかと思いますので、よかったら参考にしてみてください。
2 アジャイル開発とは
今回の開発で行ったアジャイル開発とはなんなのか、説明していきます。
“アジャイル（agile）”という単語の意味は「素早い」「機敏な」。加えて、「頭の回転が早い」というニュアンスが含まれています。
「アジャイル開発」は現在主流になっている、システムやソフトウェアの開発手法の1つで、『要件定義→設計→開発→実装→テスト→運用』といった開発工程を機能単位の小さいサイクルで繰り返すのが最大の特徴。
https://monstar-lab.com/dp/blog/about-agile_methods/
MONSTARLABのホームページより抜粋
一つの案件を小さな複数の開発工程に分けて作業を行っていきます。
そのアジャイル開発中でもよく使われるスクラムという手法を用いて作業を行ました。
スクラム開発は最も有名なアジャイル開発の手法で、チームで効率的に開発を進めることができるフレームワークです。チーム一体となってプロジェクトを遂行して行くことに重点を置くことから、ラグビーのスクラムが語源になっています。
スクラム開発ではメンバー自身がイテレーションごとの計画を立案し、設計・実装を進行。イテレーション毎に開発の進捗状況や制作物の動作を検査するため、チーム内のコミュニケーションが非常に重要になります。
チーム内での対話が不足していると、リリースした機能が正常に動作しないなどの問題に繋がる可能性があります。
https://monstar-lab.com/dp/blog/about-agile_methods/
MONSTARLABのホームページより抜粋
ここにも書いてある通り、チーム内のコミュニケーションが非常に重要となりました。
誰がどのような作業をいつまでに終わらせるのか、つまづいているポイントは何か、スプリントレビューに間に合うか。などをスクラムマスターを中心に意見交換して進めていきます。
（スプリントレビューとは仕事の依頼者（プロダクトマスター）及び、担当上司にスプリントでの成果物や進捗状況を報告すること）
3 チームルールの遷移
ここで自分たちが決めたルールを紹介します。なおスプリント後のミーティング（レトロスペクティブ）のたびに取捨選択し、新しい物を追加していきます。
A チームビルディング時点でのルール
【十分な時間を確保するために】
1) デイリースクラムは10:30, 17:00の二回
2) コアタイムは10:30~13:00, 17:00~20:00
【良質なチーム開発体制】
3) スプリントレビューまでに自分のタスクが終了できなさそうなら(木)の段階で報告し、サポートできるように配慮する
4) 情報共有を細かくする（CAとの面談の日時や、雑談も含めて）
【技術的な成長】
5) メンバーのわからないポイントは手を止めて教える
6) 自分の作業に没頭しない
7) 検索の方法の共有
でした。
それぞれのタイトルはスクールから指定されているものです。ルールを決めるに当たっての指針のような物です。
デイリースクラムは毎日行うミーティングのようなもののことで、チームによって回数が違います。
→僕たちは朝と夕方に今までの作業内容と、これから取り掛かる作業内容を報告することにしました。
コアタイムは全員が顔を付き合わせて作業を行う時間のことで、必ず設定するように指示がありました。
わからないことやエラーについてすぐに質問できるので重要です。
→僕自身は、一人で作業することが好きなので上記のように時間を二つ作ってもらいましたが、結局一度も一人で作業することはありませんでした。
初めてのルール設定ではお互いのことがまだよくわかってない状況で行ったのでポイントとしては二つになったかと思います。
A)情報共有をする
B)わからない人には教える
このルールでおよそ一週間作業を進めました。
B 二度目のルール設定（初のレトロスペクティブ）
一回目のスプリントレビューが無事終わり、レトロスペクティブで以下の意見が出ました。
【よかった点】
- こまめに情報共有できたこと
- チームで決めたルールを守れたこと
【問題点】
- タスクの期日を細かく決めなかった
- タスクの割り振り方に偏りがあった
- エラーの時のルールがなかった。
- HTMLの命名ルールがないので名前が被りそう
以上の視点と問題点の改善点を考え、KTPという方法でまとめました。
「KPT」とは、「ふりかえり」によって、仕事やプロジェクトの改善を加速するフレームワークのひとつです。KEEP(継続)、PROBLEM(課題)、TRY(挑戦)の頭文字を取っています。
KTPを書く際は具体的かつ定量的に書くようにアドバイスをいただきました。
KEEP(継続)
・こまめに情報共有をする
・分からないことはすぐに聞く
・チームで決めたルールを守る
PROBLEM(課題)
1. タスクの期日を細かく決めなかった
2. タスクの割り振り方に偏りがあった
3. エラーの時のルールがなかった。
4. HTMLの命名ルールがないので名前が被りそう
TRY(挑戦)
1. 個人のタスクの期日を細かく設定する
朝と夕方の二回のデイリースクラムで次のデイリースクラムまでにどこまで終わらせるのかを共有する。
例１）夕方のデイリースクラムまでにトップページのヘッダーとフッターのマークアップを完成させる
例２）明日の朝のデイリースクラムまでに商品出品機能のデータベースを作成する
2. タスク分担をチーム単位、個人単位で細かく管理する
デイリースクラムで、進捗・今後の作業などを報告しあう
3. エラーが起きたとき、目安の時間を決める
自分で悩む
↓ （30分以上悩んでいるを気付いたら）
チームに相談して考える
↓ （1時間考えてだめ）
他のチーム・先輩に相談
↓ （解決策が見つからない）
メンターさんに聞く
4. 担当しているビューの名前をクラスのはじめにつける
例）.top-page＿body .buy-page＿listなど
このレトロスペクティブでポイントとなったのは以下の2点です
A) ただ情報共有するだけでなく、誰が、どのタスクをどこまで、いつまでに終わらせるのかを明確にする
B) 一人でいつまでも悩んでいても解決しないので、わからないところが出てきた時のフローを作成した方が良い
【TRY】の１はとても良い挑戦だったと思います。スクールから指定されたタスクをただ「やります」だけ報告するのではなく、そのタスクの中身を理解して、細分化する必要があります。細分化した作業の中から次のデイリースクラムまでにどこまで終わらせるのかを明確に宣言することで、自分のすることが明確になります。またメンバーもその人の作業内容が理解しやすいので、次のデイリースクラムでの報告の際に進捗具合がわかりやすいなどのメリットもあったのではないかと思います。
３も良い挑戦でした。このルールを決めてすぐに解決できない問題が起こりました。メンバーに共有したあと、解決できそうになかったので、ひとつ上の期の先輩に助けを求めました。結果としてメンターさんに聞く形となりましたが、エラー解決時の流れが明確にわかっていたので、非常にスムーズに行動にうつせました。
※先輩二人がかりで解決に当たってくださりました。先輩方の検索能力の高さや、次々と様々な解決方法を試していくテンポの速さはとても勉強になりました。
※今回はメンターさんに助けていただきました。（原因はJSを読み込む記述を２つ書いていたこと、というとても単純なことでしたが、レイアウトテンプレートを２つ使用していたため解決できなかったようです。）
※解決したあとはお礼と起こった問題、解決方法を伝えにいきましょう。
C 三度目のルール設定（二度目のレトロスペクティブ）
二回目のスプリントレビューが終わりまたレトロスペクティブを行ました。
出てきた意見は以下です
【よかった点】
- こまめに情報共有できたこと
- チームで決めたルールを守れたこと
- 個人のタスクを細かく設定することで作業の理解ができた
- エラーが起きたときのフローが役に立った
【問題点】
- アウトプットする機会が少なかった
- 一人で悩んでいる時間の長さがわからない
- デイリースクラムが冗長になっている
- マークアップの方法を共有できていないので理解するのに時間がかかる
以上の点をKTPにまとめました。
KEEP(継続)
・こまめに情報共有をする
・分からないことはすぐに聞く
・チームで決めたルールを守る
・個人のタスクの期日を細かく設定する
・エラーが起きたとき、目安の時間を決める
｜自分で悩む
｜ ↓ （30分以上悩んでいるを気付いたら）
｜チームに相談して考える
｜ ↓ （1時間考えてだめ）
｜他のチーム・先輩に相談
｜ ↓ （解決策が見つからない）
｜メンターさんに聞く
PROBLEM(課題)
1. 学んだことをアウトプットできてなかった
2. 一人で数時間悩んでいる
3. 作業報告とティーチングを区別できてない
4. メンバーが記入したコードの書き方を把握できていない
TRY(挑戦)
1. アウトプットする時間の確保
17時のデイリースクラムでアウトプットする時間を確保する（15分以内/人）
2. 困っていることを報告する機会を作る
15時、20時に全員が手を止めて、今悩んでいることを相談する
（15分以内/人）
3. デイリースクラムを３本立てにする
・今日の作業とこれから取り掛かる作業（5分）
・今日学んだことをアウトプットする（5分以内/人）
・実装でわからないところを聞く（15分/ 人）
今回のスプリントでは次のことがポイントになりました。
A) 学んだことをアウトプットして頭の整理をする。チームメンバー全員のレベルアップにつなげる
B) 一人で長時間悩むことをいかにして防ぐか
C) 今何について話しているのかを明確にする
どれもとても良い挑戦になったと思います。
1では、アウトプットする時間を確保することで、アウトプットすること前提で作業をすすめるようになるので、取り組み方が変わります。
2では、質問したい人、答える人がお互い邪魔しないようにと忖度してしまい悩む時間を増やしてしまうのを防ぐ効果がありました。タイマーがなったら、手を止めて今悩んでいることを報告できるので、その時間までは頑張ってみようとメリハリがついたように感じます。
3では、作業報告を聞いているはずなのに、私がそのメンバーのエラー解決を始めてしまうことが頻発していました。その間他のメンバーが各々作業を進め出してしまい、何の時間なのかわからない状態になっていました。まずは作業報告だけをさっとすます。そのあと、アウトプットをし合って、わからないところを教え合う。デイリースクラムに話すテーマを決めることで無駄な時間を減らす効果があったと実感しています。
4 反省点
二度目のスプリントレビューで実装が完了したので、もうレトロスペクティブは行いませんでした。
しかし、「もしまだ作業が続いていたなら、どうするか」という観点で考えて見ました。
【問題点】
タスクの細分化をしたが、工程数がわからない。実装の流れがきちんとわかっているのか不明瞭
話すだけのアウトプットだけでなく、書くアウトプットも取り入れる
デイリースクラムでは、テーマごとに話せていないことがあった。時間が超過することの方が多かった
などです。
KTPにするなら
KEEP(継続)
・こまめに情報共有をする
・分からないことはすぐに聞く
・チームで決めたルールを守る
・個人のタスクの期日を細かく設定する
・エラーが起きたとき、目安の時間を決める
｜自分で悩む
｜ ↓ （30分以上悩んでいるを気付いたら）
｜チームに相談して考える
｜ ↓ （1時間考えてだめ）
｜他のチーム・先輩に相談
｜ ↓ （解決策が見つからない）
｜メンターさんに聞く
・アウトプットする時間を確保する
・困っていることを報告する機会を作る（15時、20時）
・デイリースクラムを３本立てにする**
→今日の作業とこれから取り掛かる作業（5分）
→今日学んだことをアウトプットする（5分以内/人）
→実装でわからないところを聞く（15分/ 人）
PROBLEM(課題)
1. タスクの工程数がわからない。実装の流れがきちんとわかっているのか不明瞭
2. 話すだけのアウトプットだけでは定着仕切れない。見返せない
3. デイリースクラムでテーマごとに話せず時間が超過することの方が多い
TRY(挑戦)
1. 共有のGoogleスプレッドシートに自分のタスクを細分化して書き出す
フィードバックし合って現実的な作業工程に落とし込むことができるようになる
全員で共有することで、複数人で一つのタスクに取り掛かる際に役にたつ
2. 書くアウトプットのための時間を作る
記事を書かなくて良いので、書くための材料集め、構成を練る時間を確保する。
記録として残せばあとで見返すことができる
3. タイムキーパー役を決めて知らせてもらう
スクラムマスターとメンバーという関係だけでなく役割を持つことで、チームに貢献するタイミングが増える。
時間を意識したミーティングを行えるようになり、無駄な時間を削減できる
5 最後に
いかがだったでしょうか。
たった２週間ほどでしたが、とても濃い日々を過ごすことができました。見知らぬ人同士が集まるのでうまくいかないことがたくさんあるかもしれません。しかし、人と協力し合って何かを作り上げる、楽しさや、達成感は個人開発では味わえないものです。終わったらかなり寂しい気持ちになります。それくらいやりがいのあることなのでぜひ全力で取り組んで見て欲しいと思います。
まだまだ個人的な反省点はありますが、今回はチームルールに絞ってお話をさせていただきました。
最後まで見ていただきありがとうございました。