いつもお世話になっているFBCというプログラミングスクールで実際に運用されているWebアプリの開発にチーム開発メンバーの一員として参加しました。 入会・休会・退会に関する処理、日報の作成や提出、質問の投稿や回答、イベントのお知らせや申し込みなど、様々な機能がある中でフロントエンドからバックエンドまで割と幅広く関わらせていただきました。
こちらの記事にもあるとおり（【新人プログラマ応援】学習用のプログラムと仕事で書くプログラムは何が違うか）、実際にアジャイル開発を採用している会社で働いたことはありませんが、実際のお仕事と同じ様な形式でした。
特に印象的だったのは、GitHubでもお馴染みの草（=コントリビューション）に似た機能などをVue.jsからReactへ移行するissueです。
FBCのチーム開発の前提
- 1スプリントの長さ = 1週間
- 見積もりの基準になるストーリー = Wikiにページネーションを実装する
スプリントの流れ
毎週水曜日には今週行った作業を画面共有してみんなに向けてデモをしました。自分が何をやったかを報告するだけでなく、やれなかったこと、できなかったこと、困っていることを報告しました。続いて、今週の作業のふりかえりを行い、苦労したこと、上手くいかなかったこと、上手くいったこと、相談したいことを話しました。最後に次の一週間で各自がやることを決め、そのやること（Issue）にどれくらいの労力がかかるかのポイント付けをされる形でした。
チーム開発ではrebase方式を採用（以下のような理由から、OSS の場合は特に rebase 方式を取ることが多い）
メリット
- 第三者の目からコミットログを見たときにはどのように機能が追加されていったかが目で追いやすくなる。
- コードを書いた本人にとってはあると嬉しい情報が消えてしまう代わりに、開発者全体や、直接の開発者以外の人から見たらわかりやすいコミットログになる。
- mergeコミットが作られない。
デメリット
- ある意味歴史の改ざんのため、過去にもらったレビューの指摘箇所が消えてしまうということが起こる。
心がけていたこと
- issueに着手する前に自分が実装する上で考えていることだったり、不安や疑問に思うことをメンターをはじめチームメンバーとすぐに会話することを心がけていました。テキストコミュニケーションで伝えづらいところを解消すべく、ペアプロを実施いただけるよう積極的に声をかけていました。案の定、「聞いといてよかった〜」と感じる場面がとても多かったです。
- 作業前に洗い出しておく要件や実装前のメモ、作業中に疑問に感じたこと、作業後の振り返りなどは、Notionで管理し、週一回のMTGですぐに報告できるように管理してました。Discordもスクールで使用していましたが、日報にわからないことだったり苦労していることをまとめていました。実務ではチャットも頻繁に見ていただく機会が多いと思うので（会社によりますが）、チャットツールに合わせて作業ログとして呟いていきたいと考えています。
- 当たり前ですが、主体性を持って取り組むということも心がけていました。基本的に、「自分は〇〇だと考えるのですが...」から会話がスタートするように自分の意見を盛り込んでました。
- プルリクエストのdescriptionには、issueに対するプルリクエストの目的や確認観点などを詳細かつ簡潔に伝えられるように記載していました。
まとめ
チームメンバーやメンターの方とのペアプロはプログラムを書くこと以外にも開発効率を上げる小技や実装する上での考え方を学べたりと、とにかく学びだらけでした。
途中で仕様の変更があったり、プラスで考えなきゃいけないことが出てきたりと、苦しい局面もありましたが、 総じてやっぱり開発は楽しいと感じることができてよかったです✨
いわゆるウォーターフォールモデルを経験してきた自分としてはアジャイルな開発手法の一つであるスクラムを経験できたのはとても新鮮でした。 （ウォーターフォール開発については定説な定義が定まっていないようです。 参考：「ウォーターフォールモデルの起源に関する考察 ウォーターフォールに関する誤解を解く」）
アジャイル開発を学ぶ上で、より価値があると宣言されている以下の4つの価値観にはとても感銘を受けました。
- プロセスやツールよりも個人と対話を
- ドキュメントよりも動くソフトウェアを
- 契約交渉よりも顧客との協調を
- 計画に従うことよりも変化への対応を
※ プロセスやツール、ドキュメントなどをおろそかにしてよい。ということではなく、価値のある必要なドキュメントは作成するということです。
最後に、このチーム開発は1つのプラクティスでしたので、終了条件である「issueに割り振られたポイント20ポイント分のプルリクエストが全てマージ」が満たされたので、取り組んだ内容をここにまとめておきます。
Pull Request
| Point | Issue | PR |
|---|---|---|
| 1 | Q&Aの削除確認メッセージが受講生向けになっている | #6932 |
| 1 | 「8時間後に5日経過」よりも「8時間以内に5日経過」の方がよいかも | #6943 |
| 1 | 研修生の相談部屋個別ページに企業ロゴを表示したい。 | #6959 |
| 1 | 【メンター向け】「はじめての日報です！」の通知メールのリンクがおかしい | #6974 |
| 2 | 相談部屋の連絡通知がメールをオフにしても管理者にメールで届く。 | #6981 |
| 1 | slim-lint 対応-5（いくつかのコードに対してスタイル違反を報告していたため５ファイル分修正） | #7000 |
| 2 | 定期イベントの主催者が退会、休会などして主催者がいなくなってしまった場合は、管理者が主催者になるようにしたい。 | #7031 |
| 3 | grass.vueをreactに対応させる | #7092 |
| 5 | generation-users.vueをreactに対応させる | #7170 |
| 3 | 分報チャンネルを自動で作成する際にユーザーの分報URLも自動で登録されてほしい | #7564 |
| 1 | 他のユーザーがWIPの提出物を閲覧したときのページタイトルの不一致 | #7147 |
Review
| Point | Issue | PR |
|---|---|---|
| 2 | 提出物が更新された際に、どの提出物が更新されたかがわかる通知に変更した | #6933 |
| 1 | User の discord_account 属性 と DiscordProfile の ccount_name 属性 が混在しているので、discord_account 属性 を削除したい。 | #6945 |
| usersテーブルから不要になったDiscord関連のカラムを削除する | #6945 | |
| 1 | プラクティスのページの title タグは、最初にプラクティスと表示したい。 | #7004 |
| 1 | Q&A個別ページのtitleタグは、最初に Q&Aと表示したい。 | #7044 |
| 1 | Talksテーブルのunrepliedカラムを削除する | #7064 |
| 1 | 日報の学習日入力部分に範囲バリデーションを追加する | #7119 |
| 3 | コースごとの参考書籍一覧が欲しい | #7152 |
| 5 | imagemagickからlibvpsに移行したい | #7330 |
| 3 | 相談部屋一覧を非vue化したい | #7447 |
| 2 | [退会]休会から三ヶ月後に自動で退会されるようにしてほしい。 | #7515 |
| 2 | [退会]休会中に三ヶ月後に退会にしないフラグが欲しい。 | #7515 |
| 3 | [分報]退会したら自動で分報が削除されてほしい | #7515 |
| 3 | view_componentを導入する | #7674 |
