はじめまして。2025年10月にSmartHRへ入社した、フロントエンドエンジニアのChris.Iです。専門分野は主にフロントエンド開発で、React、Vue.jsを中心に扱ってきました。エンジニア歴は約10年で、主にWebアプリケーション開発やライブストリーミング配信システムの開発に携わってきました。
前職では、いわゆるウォーターフォール型の開発を中心に経験してきました。数ヶ月先のリリースを見据えて、要件定義→基本設計→詳細設計→実装→単体テスト→結合テスト→総合テストという各工程を順序立てて進み、上流工程で決まった仕様の変更が困難な環境で、慎重に積み上げていくスタイルです。
そんな私が入社後に飛び込んだのが、「1週間スプリント」のスクラムです。正直、最初は戸惑いの連続でした。速いとは聞いていましたが、想像していた以上のスピード感でした。実装に使えるのは実質4日間。しかも、ただ速く回すだけでなく、チームとして学びながら改善し続ける前提がありました。
この記事では、これまで「数ヶ月先のリリース」を目指すウォーターフォール開発しか経験がなかった私が、高速の「1週間スプリント」に飛び込んで感じた戸惑いと、そこからの適応過程をまとめます。同じようにウォーターフォール出身でスクラムに移行される方や、これから移行を検討されている方の参考になれば幸いです。
目次
配属先は「履歴改善ユニット」
私の配属先は「履歴改善ユニット」でした。SmartHRの人事管理システムプロダクトの「履歴」ドメインという、複雑でありながら基盤として極めて重要な領域の改善を担うチームです。
履歴機能は従業員の「過去・現在・未来」の情報を取り扱うため、仕様が複雑になることはもちろん、アクセス権限やデータ整合性の管理も重要になります。開発を進めるほどに、表面的なUI実装だけでは完結しない複雑なドメインだと実感しました。
所属しているチームの体制は、プロダクトマネージャー（PM）が1名、エンジニアは計5名（バックエンドエンジニア4名、フロントエンドエンジニア1名）。
配属初日に強く印象に残ったのは、チームの文化でした。
プロダクトに関する議論やコミュニケーションは、フロントエンド／バックエンドエンジニアの職種で区切られず、基本的には全員が参加して意思決定をしていました。
フロントエンドエンジニアだから「この範囲まで」という制限があるのではなく、できることは職種の境界にとらわれず、チーム全体で価値を最大化していく文化がSmartHRには根付いているからです。
その雰囲気に、期待と同時に不安も感じながら圧倒されました。
もちろん、入社直後から何でもこなせるわけではありません。ただ、チームの前提として「職能で壁を作らず、価値を出すために必要なら踏み込む」という文化がある。そこで求められる自律性とスピード感は、入社してすぐに肌で感じることになりました。
未知のスピード感「1週間スプリント」の仕組み
このチームのスクラムは1週間スプリントです。週次のリズムはこんな感じです。
水曜日：スクラムイベントデー
- レトロスペクティブ
- 今回のスプリントのうまくいった点とうまくいかなかった点を洗い出し、改善策を考える
- PBR（Product Backlog Refinement）（プロダクトバックログの見直し）
- チケットに対して「見積もりポイント」を割り当てる（ポインティングポーカーを行い、チーム内で認識を合わせる）
- 例：xxxチケットは3ptといった形で、1チケットごとに作業規模をポイントで数値化する
- プランニング（スプリント計画）
- 「タイムボックス」や「ベロシティ」の情報を元にして、次のスプリントでどの作業に着手できるかを見積もる
- 着手するチケットに対して作業内容を具体化する
木曜日〜火曜日：開発期間
- 毎朝デイリースクラムを実施し、作業内容の共有や困っていることを話す場として活用
- 作業のズレや困りごとがあれば、この場でチーム内で話し合いズレを解消していく
- これを火曜日まで繰り返し、作業の精度向上と課題の早期解決を図る
翌週水曜日: スプリントの振り返り
- スプリント終了後にレトロスペクティブを行い、次のスプリントに向けた改善点を整理
「実質4日」がもたらした時間感覚の変化
ウォーターフォール開発に慣れ親しんだ私が最も驚いたのは、この時間的制約でした。
- 「1週間で何ができるの？」
- 「4日で成果って、どういう単位で切るの？」
- 「もし間に合わなかったらどうするの？」
長期スパンの開発に慣れていた私にとって、時間感覚がまったく異なるものでした。単に「1週間」という期間ではなく、「今週出せる価値は今週必ず出す」ことが求められる感覚でした。
私が直面した「スクラムの壁」
そんな私は、2つのスクラムの壁に直面しました。
見積もりの甘さと「4日間」の壁
最初につまずいたのは、タスクの見積もりでした。
履歴ドメインは仕様が複雑で、理解が困難です。しかし仕様理解が不十分なまま見積もると、実装に着手した段階で「想定していた仕様と異なる」ことが判明します。これにより、追加の調査や確認作業が発生します。
ウォーターフォールの頃は、調査に時間がかかっても、リリースまでの期間で吸収できることがありました。しかし1週間スプリントでは、調査が長引いた時点で「実装時間が不足する」という問題がすぐに顕在化します。
実質4日という短い期間。この制約が毎週容赦なく突きつけてくるプレッシャーは、想像以上に大きなものでした。
一人で抱える癖と「相談」の壁
もう一つ、私の中に根強く残っていたのが「一人で抱える癖」でした。
- 進捗が悪いのは自分の責任
- 自分でなんとかするべき
- 相談するのは、もう少し頑張ってから
ウォーターフォールの現場では、担当が明確で、工程も分かれていることが多く、「まずは自分の持ち場を完遂する」ことが正義になりやすい。そのマインドセットがなかなか変わらず、スクラムでも同様に一人で問題を解決しようとしてしまいました。
その結果、相談するタイミングが遅れてしまいます。相談が遅れると、チームが適切な対策を講じるタイミングも遅れることになります。この悪循環に、最初の数スプリントは何度か陥りました。
チームの仕組みに救われて生じた変化
ここからは、私自身のマインドセットがどのように変化していったのかをお話しします。正直なところ、スクラムに自然に馴染めたというよりは、チームの仕組みによって馴染んだというのが実情です。
「無理なら分割すればいい」と学んだPBR
PBR（Product Backlog Refinement）で印象的だったのは、「最初から完璧な粒度で持ってこなくていい」ことでした。
最初の頃、私は「正確に見積もりができる状態になってから議論すべき」と考えていました。しかし現実的には、履歴ドメインの仕様理解が浅い段階で、完璧な見積もりを行うことは困難でした。
そこでチームが自然にやっていたのが、不確実なところを先に洗い出し、わからない前提で小さく切り、終わらなさそうなら再見積もりして分割する、という動きでした。
「4日間で完了しないタスクを分割し、段階的に完成させる」
この柔軟さは、ウォーターフォール開発の感覚では最初は計画の敗北に見えます。しかし、スクラムにおいては、むしろそれが計画の精度を上げる重要な行為でした。
ペアプロは「甘え」ではなく「加速装置」
個人的に価値観が変わったのが、ペアプロです。
一人で1時間悩むより、ペアプログラミングの15分の方が効果的でした。これは実際に体験して実感したことです。
履歴ドメインのように背景知識が膨大な領域において、作業に詰まる原因の大半は、「実装が難しいから」ではなく「前提が理解できていないから」です。前提知識は、ドキュメントやコードを読んで獲得することもできますが、経験者と15分話す方が遥かに効率的でした。
そして何より、ペアプロは単に私が助かるだけではなく、知識が共有され、チームの生産性が上がっていきます。それを実感できた瞬間、「頼ること」に対する心理的ハードルが一段下がりました。
「早めのギブアップ」が最大の貢献
スクラムの現場では、「できません」を早く言うことが、最終的にチームへの貢献になります。これも、頭ではわかっていても、体に染み込むまで時間がかかりました。
早めに詰まりを可視化できれば、チケットを分割する、他の人に相談する、優先度を調整する、スプリントのスコープを調整する、という選択肢が取れます。
逆に、問題を一人で抱え込んだままスプリント終盤で顕在化させると、調整する時間的余裕がなくなります。「自分が頑張る」より、「チームが調整できる時間を確保する」方が価値が高い。この気づきは大きな転機でした。「一人で頑張らない方がいいんだ」とわかった瞬間、安心感を得られました。
数値による見積もり精度の向上
もう一つ安心感につながったのが、見積もりの精度を数値で実感できることでした。
チームでは、見積もり精度の向上に向けて具体的な指標を活用しています。
まずその週に作業できる時間を明確化します。具体的には、Googleカレンダーの会議予定を除いた実稼働時間を抽出して算出します。 次に、過去の実績から「1時間あたりに消化できるストーリーポイント数の平均値」を求めます。
これらの情報を組み合わせることで、スプリント内で現実的に着手できるチケットを具体的に選定できます。
スプリント完了後、予定していたチケットが終わらなかった場合は、レトロスペクティブで議論します。なぜ見積もり通りに完了できなかったかの根本原因を分析し、プロセス改善につなげます。このPDCAサイクルを毎週繰り返すことで、見積もり精度が継続的に向上していきます。
ウォーターフォールでは、遅れに気づくのが遅くなることがよくありました。スクラムでは、短いスプリントごとに調整ができるため遅れを早期に発見できます。遅れが頻発する場合は個人の問題ではなく、プロセスや仕組みに問題があると考えるのがスクラムの前提です。だからこそ、レトロスペクティブも「責める場」ではなく、「学びとして次に活かす場」になりやすいのです。
この文化が、私にとっては「失敗しても戻れる」感覚を作ってくれました。
おわりに
振り返ると、この記事全体は「Before」（変化前）から「After」（変化後）への成長の記録でした。
- Before
- 一人で抱え込み、見積もりが甘く、遅れを私の責任として消化しようとする
- After
- 不確実さを前提に分割し、早めに可視化し、チームの仕組みを使って前に進める
1週間スプリントを経験して強く感じるのは、フィードバックが早いからこそ、失敗を恐れず挑戦できるということです。小さく試して、小さく失敗して、次の週に修正できる。成長の実感が得られるスピードも、自然と上がっていきます。
ウォーターフォール経験者の方に伝えたいのは、スクラムは「個人で戦う」仕組みではなく、「チームで戦う」仕組みであるということです。チームでの戦い方に習熟するほど、スプリントの速さは怖さから武器に変わっていくと思います。
今後は、支えられる立場から、チームをリードするエンジニアへと成長していきたいと考えています。私もまだ道半ばですが、同じような変化の途中にいる方の参考になればうれしいです。
We Are Hiring!
SmartHR では一緒に SmartHR を作りあげていく仲間を募集中です！
現在、開発したいことに対しメンバーが不足しており、一緒に履歴の課題に取り組んでいただける仲間を募集しています。
少しでも興味を持っていただけたら、カジュアル面談でざっくばらんにお話ししましょう！
