記事の目的

スクラムのメリットデメリットを整理し、適切なプロジェクトの運用形式の選択に役立てるため

スクラムのメリット：発注者側

・プロジェクト開始時に、大規模で不透明な要件定義の対応コストを避けやすい。
・上記に伴って取りがちな開発終盤の不透明なバッファ期間を入れなくて良い
・プロジェクト開始が比較的容易かつ迅速に開始可能
・プロジェクト進行中に、問題点を見つやすい（エンジニアのレベルや仕様の詰めもれ、仕様の認識ずれなど）
・仕様の方向転換も比較的容易
・ユーザーの動向を確認しつつ、実際のレスポンスを用いて方向転換が容易なので、完全な前もった理論作成は必要ない（往々にしてこの理論は実際の市場と乖離するケースはよくある）
・失敗につながるミス（仕様の確定漏れ、メンバーの技術不足、実装工数の大きな見積漏れ）を早い段階で特定できるので、プロジェクト費用の大規模な損失は起こりづらく、コストの早期修正が比較的容易
・開発者のスキルアップが比較的容易
・受注者に実装の約束を取り付けづらい
・工数の予想と現実のずれが比較的起きづらい

## スクラムのデメリット：発注者側
・仕様を走りながら決めたり変更したりするので、ビジネス要件を決めるメンバー（発注者の場合もある）は開発メンバーと同じくらいの負担がかかることがよくある。
・ウォーターフォールのように中盤での暇だったりプレッシャーがない期間は比較的発生しづらい
・予算どりの難易度はウォーターフォールとは大きく異なり、スクラム独自の予算どりの方法を模索、対応する必要がある

スクラムのメリット：受注者側

・仕様の認識ずれに伴う、プロジェクト終盤でのエスカレーションが発生しづらい
・リリース手前の炎上が比較的起こりづらい
・持続可能な速度を目標としているので、比較的に、有給を定期的に取りやすい
・プロジェクト開始前などの仕様決めという予算どりが難しい作業が比較的発生しづらい
・問題点の早期洗い出しができる
・変化に柔軟に対応できる
・問題点を早期に、明確に特定しやすいので、エンジニアのスキルアップスピードは比較的高い

スクラムのデメリット：受注者側

・エンジニアはお客さんの要望に対して、自身のスキルアップや、開発ルールの適用など、常に進化を行う必要があるので、それはいいところでもあるが、苦労やプレッシャーは確実に存在する
　技術的な進化
　設計力の進化
　仕様把握能力の進化
　コミュニケーション能力の進化
・暇な期間は比較的発生しづらい
・開発者とお客さんとのコミュニケーションはより入念かつ頻繁に行う必要がある
・人の入れ替えや、進化はウォーターフォールよりも望まれる、許容されやすいので、プロジェクト進行中の手間はよりかかる。
・開発状況の透明性を高めるために、状況の報告は明確かつ、より高い透明性を要求される。

まとめ：

スクラムはウォーターフォールより完全に優れている、スクラムは楽という認識のたいがいは間違っている。
スクラム独自の苦労を積み重ねて、開発進捗や成果物の透明性を維持し続けることで、初めてスクラム開発の価値がもたらされる。
開発中の成長を行う必要があったり、透明化された問題に対する対応の必要性はむしろスクラムの方が大きい。
（ウォーターフォールは開発中は問題が見えないことが多いので、それがリリース前に発覚し押し寄せやすい）
理不尽に苦労が重なることはスクラムの方が少ないが、苦労がない訳ではなく、毎スプリント、何かしらの苦労と成長のないスクラムチームは、スクラムをしている意味がない。
都度苦労、工夫、成長を重ねなければ、スクラムの価値を体感する間も無く成功しないまま終わる。

苦労が一気に押し寄せず、平たくならされ、常に一定の耐えられるプレッシャーの中走るのが理想的なスクラムチームだと思う