はじめに
イナバくんの自己紹介
どうも、はじめまして。
私は株式会社ニジボックスでフロントエンドエンジニアをしているイナバくんです。
現在とある会社に常駐しており、いわゆるモダンな技術スタックでプロダクトを開発しています。(みんな大好きNext.js, GraphQLなど)
※ ちなみにプロダクトの説明はこちらの記事に記載しています(社外秘なのでザックリですが)
プロダクトにスクラム開発を導入
プロダクト開発界隈ではよくある事ですが、このプロダクトは当初ウォーターフォールで開発を進めていて、見事に大失敗したため「スクラム開発」を導入することになりました。
そして外部から有名なスクラムコーチの方を招き、ガッチリと教科書通りのスクラム開発が始まりました。
この記事で解説すること
この記事では、フロントエンドエンジニアがスクラム開発の「開発者」ロールになった時に、仕事のスタイルや内容がどのように変わるのかを実体験ベースで解説します。
スクラム開発とは何か？ を解説すると、それだけで本が一冊出来上がるのでスクラム開発自体の解説はしません！！
代わりに僕がスクラム開発を始める時に読んだ本を紹介しておきます。
- SCRUM BOOT CAMP: ストーリー形式でスクラム開発の流れを掴める優しい本。一冊目に読むべし。
- エッセンシャル スクラム: スクラム開発というフレームワークの起源・ルールが体系的に書かれた本。辞書的に使える。
ウォーターフォールだった時のフロントエンドエンジニアの業務内容
スクラム開発を導入する前はイナバくんは下記のような働き方をしていました。
タスクの種類
- 実装工数の見積もり / スケジュール作成
- 実装
- テスト
1週間の中身
- 毎日11:30~12:00 開発朝会
- 毎週水曜日14:00~15:00 開発定例
- それ以外は無限に実装・実装・実装
ウォーターフォール開発の時に思っていたこと
MTGは少なく、コードを書いている時間がほとんどでした。
ペアプロやPRレビューでモダン開発・チーム開発のいろはを先輩エンジニアに教えていただいたので、技術力の向上を自分で感じていました。
しかし、要件定義や仕様設計に疑問を感じることが多く、このプロダクトをリリースしたところで、本当にユーザーのニーズと一致しているのか確証が全くありませんでした。
まるで暗闇の中を懐中電灯無しでまっすぐ爆走している気分でした。
スクラム開発の開発者になったイナバくんの業務内容
タスクの種類
- ユーザーへのインタビュー / ヒアリング
- PBI(プロダクトバックログアイテム)の作成
- ドメイン知識のインプット
- WFの作成
- 要件定義
- 仕様設計
- SBI(スプリントバックログアイテム)の作成 / 見積もり
- 実装
- テスト
めちゃ増えた・・・
※ PBI: プロダクトゴール達成のために必要なアイテム。ユーザー価値が絶対的な判断基準。
※ SBI: PBIをスプリント内で完了させるために分解した具体的なタスク。
一週間の中身
- 毎日 17:00~17:30 デイリースクラム
- 毎日 17:30~18:00 デイリーリファインメント
- 毎週火/木曜 13:00~14:00 バックログリファインメント
- 毎週木曜 17:30~18:00 PO(プロダクトオーナー)レビュー
- 毎週金曜 13:00~17:00 セレモニーデー(スプリントレビュー + レトロスペクティブ + スプリントプランニング)
- 上記以外の時間でタスクを進める
※ このプロダクトは1スプリント = 1週間 です。
※ デイリースクラム: SBIの進捗 / 懸念点を開発者が毎日チームに共有する場
※ デイリーリファインメント: バックログリファインメントでPBIについて議論する前に、アイディアベースでユーザー価値の有無をPOに確認する場
※ バックログリファインメント: PBIのwhat, why, ACの深堀り / 見積もり / 優先度の設定をチームで行う場
※ AC(Acceptance Criteria): PBI, SBI の完了条件(仕様設計に近い)
※ POレビュー: 完了したPBIをPO(プロダクトオーナー)にレビューしてもらう場
※ スプリントレビュー: スプリントで完了したPBIをステークホルダーにプレゼンしてレビューをもらう場
※ レトロスペクティブ: スプリントの振り返りをチームで行う場
※ スプリントプランニング: PBIをSBIに分解して、ACを設定し、見積もりを決める場
MTGめちゃ多い・・・
開発者ロールに求められるスキル・資質
- 自立してタスクを行えること
- 幅広いスキルセット(フロントエンド / バックエンド / インフラ / UI・UX設計 / QA / テスト / 仕様設計 などなど)
プロダクトゴールの達成に際して、チーム外の部署などにタスクが依存していないのが理想形のスクラム開発となります。
(チーム内のリソースのみでゴールを達成できるべき)
JSやReactを極めてスキルの専門性を高めることも大事ですが、バックエンドやインフラなど他の領域も幅広くカバーして、対応できるタスクの種類を広げる姿勢がスクラム開発においては重要です。
なので、とりあえずPHPとAWSの本を買いました。(ハンターハンターで忙しいので読んでない)
スクラム開発に変わって感じたこと
まずMTGがめっちゃ増えた・・・
3時間 → 11時間 と、ほぼ4倍に増えました。
時間が増えただけでなく、MTGの密度も濃くなりました。
スクラム開発のイベントでは、ユーザー価値の有無について開発者とPOで活発に議論するため、ウォーターフォールの時より疲労感が段違いに高いです。
毎週実ユーザーからフィードバックを受けるので、PDCAサイクルが素早く回り続けています。
また、POレビューやスプリントレビューが毎週あるので、必然的に毎週プレゼンの機会があります。
イナバくんはプレゼンが苦手なので、なかなか骨が折れます。
コードを書く時間が少ない・・・
MTGだけでなく、タスクの種類も増えたことで、実装の時間が圧倒的に減りました。
イナバくんはコード書くのが大好き人間の部類なので、禁断症状が出ることが度々あります。
ですが、まだこのプロダクトでは、1スプリントに行うPBIの数が少ないので、各イベントが洗練されたり、スプリント期間を長くすることで改善されるかもしれません。
はじめて実ユーザーと交流できた
ウォーターフォールの時は実ユーザーのニーズを十分にヒアリングせずに仕様が決まり、実装を進めていましたが、スクラム開発になってから毎週実ユーザーのフィードバックを受けながら、少しずつスモールプロダクトをリリースしているので、ユーザー価値を感じながら開発ができています。
また、ユーザーインタビューやレビューを通して実ユーザーと交流する機会が増えたので、ユーザーの抱える課題を把握しやすくなりました。
上流っぽいタスクが増えた
今までは偉い人が決めた要件・仕様通りに実装する流れで仕事をしていましたが、スクラム開発になってからはエンジニアもユーザーヒアリングをして、要件を考えて、仕様を設計します。
自分で要件定義・仕様設計をしているので、実装している時の仕様に対する疑問点が圧倒的に減りました。
また、今まではこのような上流っぽいタスクを経験したことが無かったので、プロダクトマネジメントやUI・UX設計などの本を読むようになりました。
読んでいる本
まとめ
ウォーターフォールからスクラム開発に変わって、めちゃくちゃ忙しくなって、日々の勉強量も格段に増えました。
溜まったストレスを発散させるために夜な夜なSwitchを手に取り、スプラトゥーンでさらにストレスを蓄積する日々になりました。
ですが、スクラム開発はチームで協力してプロダクトゴールを目指しているので、まるで文化祭のような楽しさがあります。
幅広い領域を勉強し、未知のタスクを行うようになったので、ウォーターフォールの時よりもエンジニアとして成長している実感があります。
スクラム開発は痛みを伴うけど楽しいし成長できるよ。っていう話でした。おわり！