こんにちは。こしむです。
CA Tech Lounge 10日目の記事となります！今までの記事はこちらから。
スクラムを取り入れたチーム開発と個人開発の進め方の違い
早速本題です。私は2023年7月〜2024年1月までの約半年間、5人チームでスクラムを用いたアジャイル開発を行う授業を履修し、そこでほぼ初めてプログラミングに触れ、Webアプリの開発を経験しました。(この話はnoteにまとめているので、お時間ある方は併せてどうそ)
そしてそのチーム開発で あまりにも技術力に課題があるンゴ…特にバックエンド…何とかしたい、 と考えたのをきっかけに、2024年8月ごろからCA Tech Loungeに入会し、Ruby on Railsを1から勉強中です。
第一目標として立てていた5人チームで作ったアプリを1人で1から作ってみる、を体感7割くらい達成できた気がするので、チーム開発と個人開発のどちらも経験した上での気づきや知見を書き記そうと思います。
個人開発で甘えた点とその反省
言語化をサボる。
チームの時はコミットメッセージやプルリクのお作法を決めていたり、可読性向上のためコメント入れたり、リリースノートを丁寧につけていたりなどしていた。
というのも、大学では1スプリント150分=授業2コマ分で設定されており、授業ごとにスプリントレビューの時間が設けられていた。スプリントレビューは進捗報告の時間ではなく、今回のスプリントで完成したプロダクトバックログアイテムを説明しレビュワーに触ってもらう時間 なので、リリースノートを明示してレビュワーと双方向で対話ができるデモを行うように心がけていた。言語化する時間を嫌でも確保しないといけなかったのである。
例えばこんな文章をレビュー前に準備していた。
しかし今回の個人開発では、どんな機能をどのようにして実装したのかが上手く説明できないことが多かった。せっかく勉強したRailsの技術も 「何となくこんな原理」「多分こんな感じで動いてる」 と人に説明できるとはい言い難い、曖昧な理解で止めてしまっているのが 非常に勿体無い と思った。
デプロイをサボる。
個人開発云々よりも私の性格が原因だが、チーム開発の時は先述の通り前回と比べて改善された等の成果を発表しレビュワーに触ってもらう必要があった。150分の授業内に、という時間的制約があったのもあり、デプロイはかなり頻繁に行っていた。
一方で個人開発は(というよりレビューの機会が頻繁でない場合は)、気がついたらえらい変更量になっており、 ローカルでは動くのにデプロイ先では動かない、でも変更箇所が多すぎてどこか原因なのか洗い出せない という事件が発生した。
コミットメッセージを適当に書いた
あとで振り返る時いつどこをどう変えたのかパッと思い返せなくなった。
(チーム時代からまあまあ適当に共有してた、僕の悪い癖)
趣味の個人開発であっても人に見せるつもりで書いた方が後々自分の為になる。
コミットメッセージで参考にしたい記事
迷子になった
個人開発では「デイリースクラム」「スプリントレトロスペクティブ」など、メンバーで会話をする必要がある時間をカットし、ひたすら開発の手を動かせる！と思い、そのように進めていた。
が、 目の前のタスクは個人開発でも簡単に迷子になるので、終わったタスク・着手するタスク・今困っていることをdailyで言語化しておくのはやはり必要だと感じた。また例えば2週間区切りで何が上手くいって何が上手くいかなかったのか棚卸しする習慣をつければ、より良い時間の使い方ができたように思う。
スクラムの経験が生きた点
レビューをもらいに行く姿勢
これどうですか？と聞いてもレビューは返ってきません。
日常的に使う大手サービス(Amazonや食べログなど)でも、レビューをする人はほんの僅かです。
(中略)
相手からのリアクションを待つのではなく、とにかく自分からレビューしてもらいたい事項をあげて聞きに行くのが重要です。
これは冒頭に乗せた授業の感想文からの引用だが、私はメンターさんとの面談を2週間に1度必ず設定しているほか、知り合いのRails有識者にメッセージして壁打ちの相手やレビューをしてもらう機会を設けるよう努力していた。
スクラムの「スプリントレビュー」的な立ち位置は確保できていたと思う。プロダクトの価値は何か？という問いを意識しながら手を動かせたのは良かったと思う。
様々な挑戦とモチベーションの維持
アジャイルに開発をするということは、それすなわち必要最低限の機能からスタートし動くソフトウェアを作り続けることである。初学者にとって、「動くものを形にする」ということは、最初のうちは苦しいが、最初から最低限動かすための包括的な知識が身に着くので、様々な挑戦ができるという観点から悪くない方法だと思う。
あと単純に飽きがこないのでモチベーションの向上・維持に繋がる。
今後改善したい点
1人デイリースクラムをする。
作業を始める前に1人でもプロダクトバックログを整理して、できたこと・できなかったこと・困っていることを明確にし、作業可能時間も踏まえて今日の目標をしっかり設定するべき。だらだら作業することも防げる。
一応チーム開発時代に使用していたmiroを再利用して管理はしているが、個人であればGitHubのIssueで整理するのがコンパクトに収まって良いかも。(チームで付箋をペタペタする必要がないため)
なので、困ってなくてもメンターさんなりtimesなりに言語化してもっとメッセージを送るべき。
今はdailyではなくweeklyになっている状態なので、なんとかしたい。
ほどほどにデプロイする
私はデプロイツールにRenderを使用しているが、RenderはGitHubと連携するとRenderではデフォルトで、リポジトリのmainブランチに変更差分が生じた際に自動的に再デプロイをしてくれる。
もちろん任意のタイミングでマニュアルデプロイもできるので、上手く利用しながら致命的な不具合を起こさない・早期発見できる体制をつくっていきたい。
おわりに
本記事を執筆するにあたってSCRUM BOOT CAMP THE BOOKを参考にさせていただきました。黄金の本です。スクラムを学びたい人にとてもおすすめです。
もっとムキムキになったら、またチームでスクラム取り入れて開発したいですね。