はじめに
こんにちは。入社4年目のバッキーです。
今回は、私が経験した開発手法の大転換についてお話しします。
これまで担当していたスマホアプリ開発では、1週間単位で進めるアジャイル（スクラム）開発が中心でした。
しかし、3年目の夏から主力製品である「ecbeing」の開発チームに異動し、全く異なるウォーターフォール開発の現場に飛び込むことになりました。
このブログでは、私が感じたこの環境変化のリアルをお届けします。
1. アジャイル（スクラム）開発とは
アジャイル開発は、変化し続ける要求を前提に小さな単位で計画・実装・検証を繰り返す手法です。
私がいたチームでは 1週間のスプリントを回しながら、プロダクトバックログを常に更新し、デモとレビューで製品価値を高めていました。
2. ウォーターフォール開発とは
対するウォーターフォールは、「要件定義→設計→実装→テスト→リリース」が一方向に流れる開発モデルです。
上流で要件と設計を完璧に固めることがコスト最小化の鍵で、工程間をまたぐ変更は許容度が低い分、ドキュメントとレビューが重要です。
3. 二つの手法を経験して感じた4つのギャップ
| 気づき | スクラム | ウォーターフォール |
|---|---|---|
| 設計フェーズの解像度 | 動くものを早く見せるため軽量設計 | 設計書1行のミスが致命傷。設計レビュー重視 |
| 時間軸マネジメント | スプリントは最長10営業日で目標が明確 | 3〜6か月先のマイルストーン。中間ゴールを自分で刻む必要 |
| ドメイン知識の壁 | 作りながら覚えるアプローチが許容されやすい | 事前理解不足が設計ミスに直結。キャッチアップ必須 |
| 共通して大切だったこと | デイリースクラムで早期相談 | 設計レビューで早期相談 |
● 設計の重みが桁違い
スクラムでは「とにかく動くものを見せる」が正義でしたが、ウォーターフォールでは“最初の設計ミスは最後まで尾を引く”という空気が張りつめています。
設計書に散りばめた一語一句が実装とテストの羅針盤であり、レビュー指摘1行で翌月の手戻りを防ぐこともあります。
● 時間軸との向き合い方が真逆
短期スプリントは達成感が細切れに積み上がります。一方、長期マイルストーンでは大局観を持ってタスクを分割しないと“現在地”を見失いがちです。 自分で KPI や中間レビューを設定し、進捗を可視化することが不可欠になってきます。
● 異動直後の“学習モード”
スマホアプリから スイッチしたことで、業務フローを覚えるところからスタートしました。 スクラムなら「作りながら覚える」で何とかなる場面でも、ウォーターフォールでは事前理解不足が設計ミスに直結するため早く製品について詳細を知る必要がありました。
● 共通して大切だった「早期のコミュニケーション」
開発手法が異なっても、共通して非常に重要だと感じたのは「早期のコミュニケーション」でした。
小さな疑問や懸念も放置せず、すぐにチーム内で共有することで、問題が大きくなる前に芽を摘むことを可能にします。
4. まとめ
短サイクルで顧客価値を磨くスクラムと、
上流設計に全振りしプロジェクト全体最適を狙うウォーターフォール。
対照的な2つの開発手法を経験して痛感したのは、
「プロセスは目的ではなく、価値提供のための道具」という当たり前でした。
今後はスクラムで培った“変化に強いマインド”と、ウォーターフォールで学んだ“設計力”を掛け合わせ、状況に応じてプロセスをデザインできるエンジニアを目指します。
