はじめに

私はWebエンジニアとして１０年目になります。
前職の会社がSIerで、約８年ほどWebシステムの開発ENとして従事していました。
ウォータフォールで開発が主流で、規模にもよりますが１案件３名くらいがアサインしていました。
こちらの人員の内訳としては窓口兼PM的なベテランENが１名、実装をするEN（自分）が１名〜２名、両者を取り持つENが１名、みたいな開発体型でした。
現在は転職を経て、スクラムで開発している現場で業務をして１年ほどになるので、フォータフォールと比べて、個人的な感想ベースでそれぞれの開発手法の良し悪しをまとめたいと思います。
後述はあくまで上記の経歴で、 それぞれの開発手法を体験してどのように感じたかという、主観混みのただの感想である旨をご了承ください。

ウォータフォール開発

良かったところ

要件定義の時点で、注文した顧客が望むシステムや、機能単位でのゴールの解像度が高くなるため下流でどのような技術、サーバスペック、開発コストが大体想像ができる（見積もりがしやすい）
- 要件定義をきちんとしないとむしろ見積もりが高すぎる or　低すぎるといった理由で結局のところ値段交渉で時間を取られてしまう。
（本来は）細かいマイルストンで顧客と合意をとるため、仕様の追加、変更、漏れがあった場合は注文者であるお客さんに追加の機能であるためという理由で、追加請求しやすい。

悪かったところ

お客さんの窓口がENじゃないと上流での成果物をこちらが説明して理解してもらうのに時間がかかる。
仕様の変更、追加が発生した時にドキュメントの修正→お客さんに確認と合意が都度発生するため、上流のコミュニケーションコストが初期の見積もり（時間的な見積もり）ができない。
- Zoom,Meetを使わないでお客さん先で説明する回数が増えると尚きつい。
設計までの工程で宙ぶらりんの仕様があると、実装段階で気が付き手戻りが発生する可能性がある。
納期がタイトな時は、先行して設計まで完了している、仕様がほぼ固まっている機能を先に実装することが多く、他機能の仕様変更で巻き添えをくらうことがある。

スクラム開発

良かったところ

開発のスコープが小さいため、スコープ内の考慮すべき点に集中して要件定義から開発ができる。
- スコープ内がはっきりすると関連する機能への影響そのものも解像度上がる。
- 大きすぎる場合は分けることができる。
スプリント完了時に振り返りを行うことでPDCAを回す仕組みが備わっている。
- スクラムイベントを通して、個人プレーではなくチームとして改善していくため、１ヶ月、２ヶ月の短いスパンでもチームクオリティがが上がっているのを感じる。
開発EN、QA　EN、POのチーム全員がリファインメントに参加し、各ポジションで意見が出てくるため、様々な角度からスコープとなる機能の要件、仕様について揉むことができる。
SECIモデル（※1）による共通認識が浸透しやすく、現場の違いによる細かい認識の齟齬がしやすくなる。
- PRレビューの指摘傾向、リファインメントでのスコープの調整等
上流から参加することができるため、各工程のメインとなる作業者へのリスペクトを考慮した、コミュニケーション能力を得ることができる。

悪かったところ

向上心がないと、スクラムのチームとして成長していくスピードについていけない可能性がある。
- 多分これが一番重要
要件定義、仕様決めをチームで行うため、１つの工程だけやってきたENだと（開発しかしない、テストしかしない）、アウトカムの妥当性が判断するのに苦労しそう。
チームメンバーの意見を尊重した上で言動できないと、チームの雰囲気が悪くなる。
チームメンバーの入れ替わりが激しいとSECIモデルで築いた共通認識がリセットされる。
ある程度大きいエピックをメンバー揃って中期的に回さないとスクラムの成長に時間がかかりそう。
ルール化しすぎるとスクラムとしての柔軟性がなくなってしまう側面がある。
実装後のスプリントレビューで「もう少し◯◯にした方が...」といった細かい調整があるため、場合によっては手戻りが発生しやすい。

おわりに

冒頭でお伝えした通り、ウォータフォール開発、スクラム開発を用いた各現場での業務経験を経て自分が感じた内容を良し悪しでまとめただけなので、扱うプロダクト、現場、メンバーの数、といった要素でまた別の感じ方があると思います。
ウォーターフォールの方が、各工程の担当の責任が大きく、前の成果物をきちんと読み取りクオリティを担保した上で自工程で作った成果物を次工程へパスすることが重要で、スクラム開発は、メインの工程を担当とするメンバーはあれど、チーム一丸となって開発を進めている感じがしました。
実装するENだからと言って、お上から降りてくるエピックを淡々とこなしていくだけではダメで、アウトカムをきちんと考えることも能力として必要のため、ある程度上流も下流もできるENでないとスクラム開発についていくのは難しいと感じました。

補遺

※1・・（参考）SECIモデル