はじめに
手ぶら登園開発課 のかわばたです！
私はウォーターフォールの開発を約5年経験した後、2025年7月にBABY JOBへ転職しました。
本記事では、ウォーターフォール経験者がスクラムチームにジョインしてからの4ヶ月で感じたことや学んだことについて書きます！
※ウォーターフォールは以降「WF」と表記します。
想定読者
以下を想定読者とします。
- WFやスクラムの基礎知識がある人
- WF経験者でスクラムに興味がある人
- スクラムに適応しようとしているWF経験者のリアルを知りたい人
書かないこと
以下の内容は書きません。
- WFやスクラムの説明
- BABY JOBのスクラム運用の詳細説明 [1]
転職前後の環境の変化
背景情報として「転職前後でどのように環境が変化したか」を記載します。
| 業種 | 事業形態 | 開発 サイクル |
チーム数 | チーム人数 | 定例MTG | |
|---|---|---|---|---|---|---|
| 前職 | 勤怠管理 | 自社開発 | 4ヶ月 | 4つ | 7人 | ・朝会 ・振り返り(四半期毎) |
| 現在 | 保育 | 自社開発 | 1週間 | 2つ | 4人 | ・デイリースクラム ・バックログリファインメント ・スプリントプランニング ・スプリントレビュー ・ふりかえり |
WFで感じた悩み 😕
1. 考慮事項や潜在ニーズを把握する難しさ
設計完了後に考慮漏れに気づいたり、実装しながら「この仕様の方が良かったな」と思うことがありました。WFは要件定義が全工程の要ですが、この段階では考慮事項やユーザーの潜在ニーズを漏れなく把握することが難しかったです。自分の能力不足もありますが、開発手法に起因する側面を感じていました。
2. 手戻りコストの高さ
WFは開発サイクルが長い分、開発の規模も大きく、手戻り発生時のコストが高いです。手戻りの発生タイミングが後半になるほど、前工程のやり直しが増えます。以下のような作業が発生します。
- 関係者とMTGを組んで合意形成し直す
- ドキュメントを作成し直す
- 実装をやり直す...etc
3. 経験を積める速度が緩やか
前職は開発サイクルが4ヶ月でした。1サイクルで1～2案件を担当するため、年間の担当数は最大6つでした。1つずつ丁寧に対応できる反面、新規開発で経験を積める速度が緩やかで、自分の成長速度に焦りを感じていました。
アジャイルの実践と転職の決心 🔄
手戻りを経験して悩んでいた頃、以下の書籍でアジャイル開発のFWであるスクラムの存在を知り、部分的に開発手法に取り入れてみました。
具体的には仕様検討を短いサイクルに区切り、プロトタイプベースで関係者に適宜フィードバックをもらいながら、進めました。結果としてこの取り組みが成功体験となり、組織としてアジャイルに取り組む会社で開発がしたいと考え、転職をしました。
スクラムの良いところ ✨
WFで感じていた悩みは、大幅に軽減されたように感じます。以下のような良さを感じました。
1. 対応スコープが絞られている
短いスプリント単位で開発を進めるため、対応スコープが小さく、細部までの理解や検討がしやすいと感じます。もちろん、複数のスプリントをまたぐ開発もありますが、WFの悩みの種であった考慮漏れのリスクは低減できていると感じます。
2. ビジネス側との接点が持てる
スプリントレビューの場で、PO(プロダクトオーナー)とCS(カスタマーサクセス)からフィードバックをもらうことができます。POは社内アプリのユーザーであるCSの業務を熟知しており、CSは社外アプリのユーザーである保育施設の課題や具体的なユースケースを把握しています。この異なる視点からのフィードバックがあることによって、考慮漏れを防ぎUXの改善に活かすことができます。
3. 短期間で多くの業務経験を積める
開発の担当件数に関して、WFでは年間6件だったのに対し、スクラムでの3ヶ月間では週平均2件前後、対応しています。開発の規模が異なるので、数を比較することに意味はありませんが、様々な開発を経験でき、技術的にも新しいことに触れる機会が増えました。短期間で多くの業務経験ができることで、成長実感も得やすいと感じます。
4. チームで協力して進められる
定例のスクラムイベントがあるため、WFよりもチームメンバーとコミュニケーションを取る回数は増えたと感じます。もちろん、個人で作業を進める側面は存在しますが、スプリントゴールを達成するために、お互いの作業をフォローしたり、モブワークやペアプロ等も実施します。そのため、チームプレイを感じる部分が強くなりました。
WFとスクラムで変わらないところ ⚖️
1. リリースまでの開発工程
要件定義 → 設計 → 実装 → テスト → リリース という一連の開発工程は、WFと大きく変わりません。開発サイクルが早いだけなので、WFで行っていた作業を焦らずに着実に進める意識が重要だと感じています。
2. 確認をサボったり、ミスれば手戻りは起きる
当たり前ですが、スクラムの開発であっても要件や受け入れ条件の確認を怠ったり、関係者間で認識齟齬が発生した場合は、手戻りが発生します。スクラムは手戻りを完全に排除する手法ではなく、その可能性を低くする手法だと理解しています。
スクラムの頑張りどころ ✊🏻
スクラムという開発手法は、WFの課題を構造的に軽減してくれます。しかし、WFで身についた習慣を辞めて、適応していくことの難しさを感じています。以下は自分がこれから頑張っていきたいことであり、直面している課題です。
1. 瞬発的なアウトプット
この文脈における「アウトプット」は、以下のようなスクラムイベントにおける意見の表明を指しています。
- スプリントレビューでの成果物の説明と質疑応答
- バックログリファインメントやスプリントプランニングでの要件や実装に関する意見出し
- ふりかえりでのファシリテーション、改善提案...etc
WFでは、十分な事前準備をしてからMTGに臨むことが通常でした。検討事項を十分に洗い出し、自分の意見を整理してから発言する進め方です。一方、スクラムではその時間の確保が難しいと感じます。
そのため、不完全な理解でもスクラムイベントの中で意見や質問をすることで、徐々に明確にしていくことが求められます。完璧な説明ではなくても、思考の過程を共有したり、その場で議論をすることでチーム全体の共通認識が作られていくので、アウトプットをして参加していく事が重要です。
2. 「やってみる」 に慣れる
弊社ではスプリントを管理・推進するスプリントマネージャーという役割があります。この役割を初めて担当した際に、スクラムイベントのファシリテーションが全くできませんでした。知識としては各イベントの定義や目的を理解していたつもりで多少はできると思っていましたが、実際は異なりました。ふりかえりの際にスクラムマスターのたかしろさんが「今は『知る』から『やってみる』に移っている段階ですよ」と助言をしてくれました。
たかしろさん自身も、日々より良いスクラムを追求されている中で、各チームのカイゼンに向けて情報をインプットし、メンバーに働きかけています。そんな様子からも「不確実な状態でも実践してみて、段階的に改善していくこと」がスクラムの根幹となる考え方だと、実感できました。
3. 自分の行動を定点観測する
毎スプリント終了後にFigJamボードを使用してふりかえりを行っていますが、漫然と実施するだけでは意味がありません。個人的にスプリント内で気づきがあった時に、ボードを見返しながらメモをしていますが、継続することが難しいです。毎回ふりかえった内容が似ていたり、深掘りも不十分だと感じています。少しずつでも、ふりかえりの方法や観点を学び、効果測定ができるよう、最低限、自分の行動は記録しておく必要があると感じています。[2]
4. 優先度の調整を頑張る
スクラムでは、チームとしてスプリントゴール達成に向けて、常に優先度の調整を行う必要があります。また、ビジネス側から緊急性を伴う作業依頼も多くあり、その度に調整を行います。短いサイクルの中で、より多くの課題に対応するため、時間をかけるべき部分とそうでない部分のトレードオフを意識したメリハリある対応が求められます。
おわりに
WFで身についた「十分な準備の後に発言する」という習慣は辞めようと思っても、性格的な部分もあるので、すぐに実践は難しいです。なので、試行錯誤を重ねて少しずつ改善しようと思っています。弊社の開発部には「失敗を許容し、失敗から学ぶ」というValueがあります。[3] 適度な緊張感は持ちつつ、不必要に焦らず、挑戦しながら改善していこうと思います。
-
開発部メンバーにも個人の振り返りに取り組んでいるメンバーがいるので参考にしたいです！
👉 圧倒的成長促進！ 4 行日記と ORID を組み合わせたエンジニアの毎日個人ふりかえり ↩︎ -
開発部の組織文化については、マネージャー大河原さんの記事をご覧ください
👉 なぜBABY JOBのスクラムは「活きている」と感じられたのか ↩︎
私たち BABY JOB は、子育てを取り巻く社会のあり方を変え、「すべての人が子育てを楽しいと思える社会」の実現を目指すスタートアップ企業です。圧倒的なぬくもりと当事者意識をもって、子どもと向き合う時間、そして心のゆとりが生まれるサービスを創出します。baby-job.co.jp/
Discussion