はじめに
2025年新卒のブランドソリューション開発本部ZOZOMO部OMOブロックの東谷です！ 私は筋トレが趣味なのですが、増量期（筋肉をつけるために体重を増やす時期）が終わろうとしています。早く痩せなきゃと思いつつ、つい揚げ物や甘いものを食べ、現実から逃げている今日この頃です。
早いもので入社からもう1年が経ちました。この1年を振り返って一番強く感じているのは、スクラムは「アジャイル開発の手法」であると同時に、新卒にとっての最高の学習環境だったということです。
配属直後の自分は、リファインメントの議論についていけず、実装中もどこから手をつけてよいか分からない状態でした。それでも1年後、チームの中でスクラムを一通り回せるようになりました。この変化は、研修や独学だけではなく、スクラムの各イベントそのものに大きく支えられました。
スクラムがよく語られるのは「ビジネス価値を最大化する仕組み」としての側面です。しかし新卒視点から見直してみると、これらはすべて先輩たちの思考プロセスを短時間で観察し、その場で質問できる場でもありました。書籍やドキュメントでは身につきにくい「思考の型」、つまり先輩がどんな問いを立て、何をよりどころに判断しているかという基準があります。これを学べる環境として、スクラムは新卒にとって非常に整った構造を持っていると感じています。
この記事では、「思考の型」を自分が新卒1年目に具体的にどう身につけたかを振り返ってみます。題材として取り上げるのは、プロダクトバックログリファインメント（以下、リファインメント）、スプリントプランニング（以下、プランニング）、モブプログラミングの3つです。前者2つはスクラムイベントで、モブプログラミングはチームで採用している開発プラクティスです。新卒エンジニアには「スクラムは新卒の最高の学習環境になりうる」という視点を、新卒受け入れを担う開発組織には育成設計のヒントを提供できればと思っています。
目次
配属直後の自分とチームの環境
配属前の自分にとって「開発」とは、仕様が決まったタスクを実装することとほぼ同じ意味でした。
学生時代に長期インターンとして参加していたのは、ITベンチャー企業のBtoBプロダクト開発チームでした。そのチームのバックログには仕様まで書かれたタスクが並んでおり、エンジニアはその中から自分でタスクを取って作業する開発サイクルでした。タスクはリーダーが起票していき、起票時点で何を作るかは決まっています。自分の仕事は、それをコードに落とす精度と速度を上げることだと思ってました。
そんな自分が配属先の今のチームに入ったとき、まず驚いたのは開発サイクルの「広さ」でした。
リファインメントでは、プロダクトバックログアイテム（PBI）の目的や受け入れ条件を整理し、チームで認識を揃えながら実装可能な粒度まで要件を具体化します。プランニングでは、スプリントゴールを踏まえてチーム全員で作業内容を確認し、相対見積もりをしながらスプリント内で達成する内容を決定します。開発中はモブプログラミングを通じてリアルタイムに知識共有と意思決定を行います。スプリントレビューでは完成したインクリメントをステークホルダーとともに確認し、次の方向性を議論します。
この1週間のスプリントを、新卒の自分も初日からチームの一員として回すことになります。それまでの開発経験と決定的に違ったのは、バックログにタスクが並ぶ前の段階から、自分も議論に参加するという点でした。
もう1つの驚きは、議論についていくために要求される知識の量です。リファインメントやプランニングでは、複数の前提知識を踏まえた議論が当たり前のように展開されます。例えば、自分の担当しているサービスが他のサービスとどう連携しているか、CQRSで構築されたデータの流れはどうか、認証基盤との関係はどうなっているのかなどです。配属直後の自分は、議論の中で出てくる用語の半分も追えていない状態でした。
「自分が貢献できるだろうか」。最初の数週間、率直に言ってそう感じていたのを覚えています。
ところが、振り返ってみるとこの環境が、自分にとってこれ以上ない学習機会になっていました。スクラムの各イベントが、まさに知識、経験が足りていない新卒にとって最適な学習装置になっていたからです。
スクラム開発で身についた3つの学び
ここからは、新卒1年目で身についた3つの学びを、具体的なエピソードとともに紹介します。
1. リファインメント：機能を「課題解決の手段」として見る視点が身についた
私が所属しているチームでは、ZOZOTOWN上でブランド様の店舗在庫を確認し、商品の取り置きができるサービス「ZOZOMO店舗在庫取り置き」を開発しています。複数のマイクロサービスが連携し、CQRSを採用しているため、イベントを通じたデータの流れを理解することが開発の前提になるプロダクトです。
配属されてしばらく経った頃、ブランド様の店舗情報をシステム上で更新できる機能を実装しました。それまでは開発チームが手動で対応しており、完了までに3営業日ほどかかっていました。ブランド様を待たせることになり、運用者の認知負荷や作業時間も大きいという課題がありました。
議論に参加する前、私の頭にあったイメージは簡単でした。「入力フォームを作って、POSTで更新するAPIを叩けば完了」。配属されたばかりの私は、機能を「実装するもの」として捉え、実装イメージが浮かんだ時点で完成像が見えたつもりになっていました。
ところが、実際のリファインメントの議論はまったく別の地点から始まりました。
先輩が立てる「問い」が、自分の視野を順に広げていった
最初に出てきたのは、システム構造に対する問いでした。認証基盤との関係、マイクロサービスごとの責務、そしてデータがどのサービス間をどのように流れるのか、といった内容です。私が「POSTを1つ作ればいい」と思っていた機能は、実際には複数のサービスにまたがってイベントを発行し、各サービスがそれぞれの責務でデータを更新していくものでした。CQRSやイベント駆動の設計は独学で吸収するには時間のかかる領域ですが、議論の場で出てくる用語や設計判断についてその場で質問できることで、認知負荷の高い情報を一気に吸収できました。
次に、システム設計が具体化してくると、想定していなかった論点が次々と出てきます。「店舗情報が更新されたことをどう確認するのか」「確認するためにはどのデータが必要か」。考えるべきことが膨らんでいくなかで、先輩から自然に出てきたのが「この機能はそもそも何を解決するものだったっけ？」という問いでした。
そこから議論は、機能を実装する話からユースケースを実演してみる話に切り替わります。実際の運用者の動きを想像し、ときには運用者に直接ヒアリングしながら、ユーザー体験ベースで仕様が具体化されていきました。
例えば、「店舗情報として更新できるデータは何があるのか」を全部洗い出すところから始まりました。さらに「運用者が更新ボタンを押す前に、入力ミスがないと安心できる状態は何か」「更新した後、本当に意図通りに反映されたかをどう確認するか」など、ユーザー体験の細部にまで問いが続いていきます。これらに応える形で、機能の中身が具体化されていきました。
さらに出てきたのが、「この機能を実装した後の恒久的な運用フローはどうなるか？」という問いです。「今回のケース以外にも対応できる汎用性って必要だっけ？」「逆に今回のユースケースに限定すれば不要となる実装ってないっけ？」のように汎用化を考える問いと、削ぎ落とすための問いが、同じ場で同時に飛び交っていたことが印象的でした。
象徴的だったのが、ブランド情報の鮮度をめぐる議論です。ZOZOMOのシステム構成上、店舗が所属するブランド様の情報が変わったとき、システム側は正常に更新されますが、その変更がリアルタイムで運用ツールに表示されない仕組みでした。そのため運用上、「正確なデータを変更しているかどうか確認したい」と運用者から開発側へ問い合わせを受けるケースの発生も予測されました。今回の店舗情報の更新機能を考えるうえで、この運用上の課題へ手を入れる余地があると判断し、ブランド情報を最新状態として取得し直す機能を同じ画面の中で組み込むことになりました。この機能を実装した結果、関連する問い合わせは発生していません。目の前の機能要求だけでなく、運用される将来の状態まで含めて考えることで、機能の質が変わっていく瞬間でした。
議論を経て、機能の質と学びが見えた
リファインメントの議論を経て、最終的な機能は、私が当初抱いていたイメージとは大きく違うものになりました。最終的にできたのは、店舗情報の更新作業だけでなく、その前後で必要になる作業まで1画面で完結できる機能でした。
1画面に統合したのは、更新前の確認（店舗IDから店舗名・ブランド名を表示）、更新後の確認（変更後データの表示）、そしてブランド情報の鮮度を保つための再取得機能の3つです。これにより、運用者は別ページに遷移したり、別件で開発側に問い合わせをしたりする必要がなくなりました。効率よく作業できる機能に仕上がっています。
この一件で体感したのは、機能の「核となる実装」は全体のごく一部にすぎないということでした。POSTのAPIとUIという核は確かにイメージできていましたが、それが実際のユーザーへ届きビジネス価値へとつながるまで、想像をはるかに超える議論と設計判断が積み重なっていました。
リファインメントに新卒のうちから参加できたことで、私は機能を「実装するもの」ではなく「課題を解決するもの」として見る視点を、議論の中で自然に身につけることができたと感じています。これは、先輩から受け取った最初の思考の型のひとつでした。
2. プランニング：Acceptance Criteriaで「実装の自由度」を制御することを学んだ
リファインメントで十分実装が可能だと判断されると、次はプランニングでスプリントの計画を立て、タスクの洗い出しやタスクの規模を見積もります。配属直後の私にとって、この時間はリファインメント以上に難しいものでした。
規模の見積もりには、チームごとに蓄積されるベロシティ（過去のスプリントでどれくらいの規模を消化できたかという感覚値）があります。「このくらいの規模の変更ならだいたい何ポイント」という相場が、過去の実装経験から自然と形成されていきます。配属されたばかりの自分にはそれがなく、対象機能の核となる変更部分の理解もまだ浅い状態で、規模を出すのは正直難しい作業でした。
では、先輩はどう見積もっているのかなと気になりました。観察して印象的だったのは、実装を頭の中で先取りして見積もるやり方でした。ZOZOMOではDDDやCQRSを採用しているため、これはコードベースを頭の中で走らせる形になります。例えば「Query側のStore集約のUsecaseでデータを整形して、Infra層に店舗集約をUpsertするクエリを書いて、UnitTestとE2Eを書いて…」といったイメージです。見積もりは「数字の当てっこ」ではなく、この工程をどれだけ正確に頭の中で走らせられるかなのだと理解しました。そして、その想像力を支えているのは、過去の実装を積み重ねてきた経験にほかなりませんでした。
Acceptance Criteriaで「実装の自由度」を制御する
想像力と経験がある程度身についた状態で、より規模を正確に見積もり、要件を満たすために考えるべき重要な指標があることに気づいたのは、1年経ってからでした。それがAcceptance Criteria（受け入れ基準、以下AC）の解像度です。
ACとは、その機能が「完成した」と判断するための条件を具体的に言語化したものです。重要なのは、ACの粒度が実装の自由度をコントロールするということでした。
象徴的だったのが、ブランド様と店舗の紐付けを除外する設定を確認する機能の実装です。これはリファインメントの結果、ブランド様ごとに検索ができ、絞り込んだ結果をExcelとして出力する機能も追加するスコープに広がりました。Excelはメールで該当ブランド様に送り、店舗とブランド様の紐付きが正しいかを確認してもらうためです。
このときのACの一例は、「検索後、Excel出力ボタンを実行したタイミングでポップアップが表示され、絞り込みした店舗の属するブランド一覧がポップアップに表示されること」と定義しました。
このACは、自由度の制限の仕方が絶妙でした。検索のクエリや検索ロジック、Excel生成の方法そのものには制限がかかっていません。より良い実装方法があれば実装時に改善できる余地が残されています。一方で、出力時にポップアップで対象データを一覧表示するという最終的な体験の部分は明確に固定されています。これは複数ブランドを指定して検索できる仕様上、運用者が「どのブランド様のExcelを送ろうとしているんだっけ？」を実行直前に視覚的に確認できる状態を保つことで、ヒューマンエラーを抑えるためです。
ACが「実装の細部までガチガチに固定する文書」になっていると、開発者は工夫の余地を失います。逆にACが曖昧すぎると、実装中に判断を迫られる回数が増え、規模が大きくブレます。ACは、考えてよい部分と考えなくてよい部分を明確に切り分け、実装の自由度を意図的にコントロールするための装置なのだと、この実装を通じて理解しました。
見積もり精度はAC定義の解像度の問題に集約される
ACの粒度をこの形でコントロールできていたから、実装中に時間をかけて考える部分と、考えずに型通り進めてよい部分の切り分けが明確でした。結果として、見積もった規模と要件の両方を、ある程度の確度で同時に守れる構造になります。
規模そのものを正確に当てに行くのではなく、ACの粒度をコントロールして実装中の判断回数を制御します。プランニングを1年続けた末に言語化できたのは、「見積もり精度の問題は、その手前のAC定義の抽象度に集約される」という知見でした。
数字を出すこと自体に意識を向けていた1年前の自分から、今は「ACで実装の自由度を制御することで、規模と要件の両立を狙う」ことに意識を向けるようになりました。プランニングの場の捉え方がこのように変わったことが、この1年で起きた最も大きな変化の1つです。ACの粒度を意図的に調整するという考え方も、私のなかに定着した思考の型のひとつです。
3. モブプログラミング：「事実ベースで実装する」という姿勢が身についた
リファインメントとプランニングを経て、いよいよ実装フェーズです。私のチームでは実装の多くをモブプログラミングで進めます。複数人が同じ画面を見ながら、ナビゲーター役とドライバー役を交代しつつコードを書いていく形式です。
モブプロから学んだことは数多くありますが、今の自分に最も大きく影響しているのは「事実ベースで実装する」という姿勢です。
先輩は事実から方針を決めていた
リファインメントやプランニングで要件をどれだけ詰めても、実装段階で「考慮しきれていなかったこと」は必ず出てきます。とくにマイクロサービス間でデータを連携している箇所では、外部要因も絡んで挙動が読みにくくなります。
ZOZOMOでも、他のマイクロサービスとイベントを通じたデータ連携をしています。しかし、さまざまな要因によりイベントの連携順序が入れ替わり、本来連携されるべきデータを正しく届けられないケースもありました。この問題に対処する仕組みを実装した際、モブプロで先輩のアプローチを間近で見たのが印象的でした。
先輩はまず、入れ替わりが起きたデータを全件出してくるところから始めました。一部ではなく全体を並べて共通項を探すと、どの経路の、どのタイミングで入れ替わりが起きているのかという事実が浮かび上がってきます。
そこから先輩が見出したのは、ZOZOMO側の開発基盤にデータが連携される箇所で、入れ替わりそのものを直すという根本的な解決策でした。全件のデータという事実から出発したからこそ見つけられた解決策です。
「事実から始める」という型を学んだ
このやり方の何がすごいかというと、実装の前に「何を解決すべきなのか」が事実として明らかになっていることです。事実から始めれば「この具体的なケースを直すには何が必要か」という明確な目的が手元にあります。結果として、不要な処理が混ざらず、シンプルでビジネス価値の高い実装にたどり着きやすくなります。
このとき自分が何より学んだのは、「とりあえず動かしてみる」のではなく、手元の事実をしっかり集めてから設計に入るという姿勢でした。新卒1年目で身につけた中でも、実装に向かう前の心構えとして特に役立っている型です。
事実ベースで判断するという姿勢も、モブプロを通じて自分のなかに残った思考の型のひとつです。
AI時代に、思考の型はどう活きるか
この1年は生成AIの普及によって「情報を知っていること」自体の価値が一気に下がった年でもありました。ドキュメントを読み込む、仕様を覚える、エラー文を検索する。こうした若手エンジニアの仕事の一部だった作業の多くを、AIがあっという間に肩代わりする時代です。
だからこそ、ここまで紹介してきた「思考の型」の価値が、以前より一段はっきり見えてきた気がしています。ACをAIに書かせることも、実装方針をAIに提案させることもできます。しかし出てきた出力が正しい方向に向かっているかを評価し、軌道修正の指示を出すには、自分の中に判断の物差しが必要です。
思考の型を自分の言葉で持っていれば、それはそのままAIへの的確な指示に変わります。たとえば、3つの学びはそれぞれ次のような指示につながります。
- リファインメントで身につけた「これは何を解決する機能か」という問いは、「この機能の目的はこうだから、それに沿った実装案を出して」という指示になる
- プランニングで身につけた「ACで自由度を制御する」思考は、「実装手段は任せるが、最終的な体験はこう固定したい」という指示になる
- モブプロで身につけた「事実ベースで判断する」姿勢は、「推測で進めず、まず該当データを全件出してから方針を決めて」という指示になる
AIに何を問いかけ、その答えをどう評価し、どこで意思決定するか。その一連の判断は、思考の型を自分の足場として持っている人間にしかできないと思います。
おわりに
1年を振り返って、スクラムは新卒にとって先輩の思考の型を最速で学べる装置として機能しました。リファインメントで問いの立て方を学び、プランニングでACの解像度を上げる感覚を掴み、モブプログラミングで事実ベースの実装の進め方を身につけました。一つひとつは技術書を読んでも身につかず、リアルタイムの観察と質問なしには手に入らないものでした。
スクラムは「アジャイルに開発するためのフレームワーク」として語られることが多いです。しかし新卒として配属された自分の視点からは、先輩たちの思考にアクセスする頻度を最大化する仕組みであり、かつAI時代に価値を持ち続ける能力を集中的に育てる仕組みでもありました。
これから配属を迎える新卒エンジニアの方には、配属先のチームがスクラムで動いているなら、それを「ただの開発手法」とは思わずに思考を盗む1年にしてほしいと伝えたいです。技術知識を吸収する場としてだけでなく、思考の型をコピーする場として向き合うと、得られるものの密度が大きく変わります。
新卒受け入れを担う開発組織の方には、スクラムを生産性の文脈だけで評価せず、新規メンバーの学習装置としての側面にも目を向けてもらえると嬉しいです。先輩の思考に高頻度で触れられる場が組織にあるかどうかは、人材の立ち上がりスピードに大きな差を生むはずです。
自分自身は、まだスクラムから学べることの入口に立ったところだと思っています。2年目以降は、観察する側だけでなく、自分の思考の型を他のメンバーに見せていく側にも回っていきたいです。
ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。
