アジャイル開発（スクラム）を行なったときの振り返り

書いた背景

半年以上前のことになりますが、一時期プログラミングスクールに通っていたことがあり、その時にアジャイル開発をした経験を思い出しながらまとめたいと思います。
これからアジャイル開発を行う方や初学者の方の参考になれば幸いです！
アジャイル開発についてわからない方がいらっしゃいましたら私が書いた記事がありますので読んでいただけると励みになります！よろしくお願いいたします！！
アジャイル開発についてのまとめ

某プログラミングスクールにて

半年ほど前になりますが、某有名プログラミングスクールに通っておりました。
未経験からエンジニアへがテーマのスクールでよく知っている方も多いと思います。
そのカリキュラムの最後にチーム開発があるのですが、そこでの開発手法がスクラム開発でした。なぜスクラム開発を取り入れているかはわかりませんが、おそらくターゲットがスタートアップやモダンな企業を押していたのでそのためかと思います。

開発メンバーについて

私たちのチームは5人チームでした。私を含めてほぼ30近い方が3人と20代前半の若い子たちが2人という構成でした。みんな様々なバックグラウンドを持ちとても個性的なメンバーが集まったなという印象でした。

チーム開発初日

まずグループごとに集められ話し合いが行われます。
ここでは自己紹介とスクラムマスターを誰にするかが話し合われました。メンターの方から言われていたのはスクラムマスターは決してリーダーではないのでそのあたりも考慮して選出してくださいとのことでした。
とはいえスクラムマスターという言葉を初めて聞いた私たちはリーダーとの違いが判らず、リーダーを選出する気持ちで話し合いをしました。
挙手制になったため、真っ先に手を挙げました。理由は昔からリーダーをする経験が多かったことや、せっかくやるのなら負担が人より大きくて自分が成長できそうなことをやろうと昔から決めていたからです。ほかに挙手する方がいなかったのでここはすんなり決まりました。他にやりたい人がいたらどうしていたんだろうとたまに考えます（笑）
初日はスクラムマスターだけが集められ、今後のスケジュールの流れを確認し、その後、開発メンバーにミーティングの内容を伝え、少し話し合いを行い終了となりました。
この話し合いの中でチームの目標として掲げたのが全員がスキルアップをするということでした。
そのため、どのようにすれば個人のスキルアップにつながるかを家に帰ってから考えていました。
その中で思いついたのがアクティブラーニングです。

アクティブラーニング

こちらの画像にあるように他の人に教えることで学習の定着度は格段に上がります。
そのため、デイリースクラムの際に各自が開発中に学んだことを発表するような時間を設けてはどうかと考えました。
翌日、開発メンバーにアクティブラーニングのことを話すと、快く受け入れてもらえ、翌日のデイリースクラムから学んだことを発表することになりました。
また、開発にはコミュニケーションが重要であり、特に初学者だった私たちはエラー一つに詰まってしまい時間を無駄にしてしまうのは致命的になると考えたため、相談する機会を多く設けようと考え、イレギュラーではありますが、デイリースクラムを朝、昼、晩と3回行うことにしました。

2日目

早速作業に取り掛かります。
まずスプリントプランニングミーティングを行い、プロダクトオーナー（メンターさん）が作ったバックログの確認や作業の割り振りを決めていきました。私たちのチームはフロント側希望が2人、サーバー側希望が3人ときれいに分かれたのでこの辺りの作業分担はすんなりいきました。プロダクトについてはECサイトでサーバーサイドはRuby on Rails、フロントエンドはjQuery、Haml、scssを使いテストはRspecで書きました。DBはMySQL、本番環境のサーバーにはAWSという構成でした。タスクについてはTrelloで管理していました。
仕様の確認と作業分担が終わったら早速開発に取り組みました。

3日目から1週間(初回スプリントレビューまで)

はじめのタスクはDBの設計とデプロイに取り掛かりました。
私はDB設計を主に担当しました。DB設計はER図を用いて設計を行いました。作ったサイトはDBが12,3個ほどだったと記憶しています。それまでは多くても5個ほどのテーブル設計しかしたことがなかったためこのDB設計には苦労した思い出があります（笑）
DB設計が終わってからはサーバーサイドのタスクに取り掛かりました。

朝のデイリースクラムでは前日の作業内容とその日のタスクについてslackで共有してもらい、それを発表してもらうという方法をとっていました。また個人個人開発で学んだことを発表してもらいました。また、昼休憩後に1回、夕礼後に1回デイリースクラムを行いました。

各自作業を進めていき1週間後のスプリントレビューを迎えました。

第1回スプリントレビュー

ついに初めてのスプリントレビューです。
1週目は順調に進んでいたのでスプリントレビューを楽しみにしていました。しかし事件はここで起こります。
スプリントレビュー当日の朝デプロイ担当の方からslackでこんなメッセージが
「本番環境でエラー発生して画面見られなくなりました。」
なにー！！
色々とslackでメッセージをやり取りして解決しようと試みたもののエラーを直したらまたエラーといったことの繰り返しで結局その時は解決できませんでした。その当時はGitの使い方にもあまり慣れておらず、きれいに動いていた時に戻そうにも戻せず結局第1回スプリントレビューは本番環境で画面を見せることができませんでした。画面は見せられなかったので現状の進捗を報告し終了となりました。

スプリントレトロスペクティブ

こういった形で第1回スプリントレビューが終わりました。
レビュー後はレトロスペクティブの時間を取り、各々が1週間の振り返りを行いました。
この中ではKPT方式を採用していました。
その時話し合ったことがまだ残っていましたので振り返りもかねて見ていきたいと思います。

KEEP(継続)
コミュニケーションが図れていてよかったので継続する。

PROBLEM(課題)
タスクの振り分けをしたもう少し明確にした方が良い。
一つの作業に数人で取り掛かり過ぎている。
手持ち無沙汰になってしまっていることがある。

TRY(挑戦)
タスクの振り分けを行う。
苦手分野に挑戦する。
相談の回数を増やす。

振り返ってみるとコミュニケーションは図れているが、タスク管理にうまくいっていないことがわかりました。
最初はどうしてもデプロイやDB設計など重めだったためタスクの振り分けがうまくできていませんでした。

こうした課題を振り返り、スプリントプランニングミーティングでタスクに割く時間や担当の変更などを話し合いました。

2週目

レトロスペクティブ、プランニングミーティングの結果を踏まえ、2週目に入っていきます。
この週も私は引き続きサーバーサイドのタスクに取り掛かりました。
デイリースクラムでのアウトプットも継続して行い、ところどころ詰まりながらも周りの方と相談しながら開発を進めていきました。
前回した失敗を活かすべくGitの操作やデプロイについても改めて勉強しなおしました。

第2回スプリントレビュー

そして第2回スプリントレビューの日がやってきました。
今回はしっかりと本番環境で動作をさせることができ、一安心でした。
進捗的には可もなく不可もなくといった感じで進んでいたので、現状報告と翌週の展望を話し終了となりました。

スプリントレトロスペクティブ

スプリントレビューが終わったので、レトロスペクティブを行います。

KEEP(継続)
コミュニケーションは継続して行う。
アウトプットの時間も継続する。

PROBLEM(課題)
進捗の共有はしているが、それをあまり把握できていない。

TRY(挑戦)
各自が行っているタスクをトレロでしっかりと共有する。
こまめにプッシュを行い、本番環境で確認する。
エラーに詰まったら早めに聞く、解決しなければメンターさんへ

第2回目では課題として進捗管理の方法があげられました。
この時はバックログの進捗管理がうまくできておらず、未記入のまま次のタスクを進めていたりすることがあり、こちらの記入を徹底することを改善策として掲げました。
今思うと、もう少し私が気を配らなければならなかったことだと反省しております。

3週目

レトロスペクティブの結果を受け3週目に入ります。
いよいよ佳境に差し掛かってきており、重いタスクも増えてきました。特にうちのチームにはjQueryを理解しているメンバーがおらず、もう一度ここの勉強からスタートになりました。
現代のアプリではJSは必須の知識となっているので使わないわけにはいきません。
後半になるとフロントとサーバーという分け方ではなく各々タスクの重さに応じて柔軟にタスクをこなすようになりました。
また、チーム開発特有なのですが、自分が書いていないコードに新たに手を加えていくので、他人のコードを読む力がこの辺りでついたかなと思います。また、自分がコードを書く時も相手が読みやすいかを意識して書くようになりました。

第3回スプリントレビュー

ついに最後のスプリントレビューを迎えました。
3週目は、開発メンバー全員が苦手なjQueryが足を引っ張り、少し作業に遅れが出てしまいました。また、開発メンバーの方の1人が奥さんの出産のためそちらにつきっきりになり、作業ができなくなってしまったのですが、そこは家庭を優先してもらいメンバーみんなでカバーしようとさらに結束力が高まりました。（みんな優しかった）
プロダクトオーナーからはスプリントレビューは今回で最後なのであとは最終報告会でよいものが見せられるように頑張ってくださいとエールをいただきました。

スプリントレトロスペクティブ

遅れを取り戻すためにどのようにしたらよいかを話し合いました。
この振り返りの中で出たのがコミットの粒度についてでした。
コミットの粒度が今までは大きかったため、すぐに戻れないといった問題が発生していました。そのためこまめにコミット、プッシュして細かく作っていくように心がけました。
最後のKPTは以下のような形でした。

KEEP(継続)
コミュニケーション、タスク管理、エラーの共有

PROBLEM(課題)
マージまでが長くなってしまう

TRY(挑戦)
細かくマージをして本番環境でみられるようにする。

4週目

ついに最終週です。
遅れを取り戻すため、とにかく作業に没頭しました。jQueryでの実装にも少しずつ慣れてきて作業が進むようになっていきました。重い作業も細かくコミットすることを心がけ、小さく機能を作っていきました。

最終報告発表会

ついに最終報告会です。
果たして間に合ったのでしょうか？結果は
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

間に合いました！！

最終報告前日にメンターさんからOKをいただき、何とか間に合わせることができました。
最終報告会ではアプリの説明、各々が担当した機能、苦労した点などを発表し終了となりました。

チーム開発を振り返って

チーム開発で得られたものとしては特にGitの使い方や他人のコードを読む力、わかりやすいコードを書く力だと思います。
なかなか経験できることではないと思うので初学者の時にこういった経験が積めたのはとても大きなことだと思います。
また、チームのメンバーとは今でもたまに連絡を取ったりするような仲にもなったのでそういったものも貴重な財産となりました。
これはスクラム開発で密にコミュニケーションをとれたことが大きかったと思います。
また、アウトプットを積極的に行ったことで知識が定着し、当初の目的であった個々のスキルアップを目指すといった目標は間違いなく全員が達成できたと思います。

最後に

半年以上前のことなので忘れていることも多々ありましたが、今では考えられないようなミスもしていたなと振り返って思います。
昔のことを振り返るのは恥ずかしいことも振り返らなくてはならないのですが、過去の失敗を恥ずかしいと思えるということは日々成長している証だと思うので、定期的に前のコードとか見直してみると成長を実感できて面白いかもしれないですね（笑）