見出し画像
Photo by mericanadesico

ウォーターフォール開発とアジャイル開発を両方経験した自分が現場で実際に働いて感じた違い

CTC Buildサービスチーム

こんにちは。Buildサービスチームの鈴木です。
9月に入り秋に入ったからか猛暑も終わり徐々に涼しさを感じる今日この頃ですね。

自分は最初の投稿でも自己紹介した通り昨年の10月に転職でこのチームに参画し、それまでは自動車業界で働いていたのですが、前職ではご想像のつく通り、自動車みたいに数多くの部品が関わり、長期間のスケジュール（数年スパン）が組まれる開発なのでウォーターフォール開発のプロセスで動いていました。
一方で今のbuildチームではアジャイル開発のプロセスで動いているので、やっていることはあるプロダクトを作るという同じものですが、一気に働き方が変わりました。
そのため、自分は両方の開発プロセスを実際に経験することができたので、今回はタイトルにある通りウォーターフォール開発とアジャイル開発の違いについてよく指摘されている点を列挙しながら考えてみたいと思います。

あらかじめお断りしておきますと、本記事ではあくまでも筆者の経験ベースで考えさせていただくので、両開発ともその会社独自の多少のアレンジは入っております。ですので、もしかしたら自分の会社の開発プロセスとは違うみたいに感じられるかもしれません（例えばアジャイル開発のスプリント期間が2週間ではない etc.）が、そこに関しては特にどっちが間違っているというのはないので気にせず読んでいただければなと思います。

各観点において感じた違い

仕様変更のしやすさ

アジャイル開発のイメージとしては柔軟に仕様を変更できるですが、これはそうだなと感じますね。各スプリントでバックログの優先度を変えることで柔軟に対応できます。
これはアジャイル開発の成果物が修正しやすいソフトウェアだったりインフラもクラウドといった柔軟に拡張・縮小しやすいということがあると思います。これが例えば自動車になると仕様変更の結果、車両に新たな部品が必要ですといったハードウェアレベルの設計変更になると開発のフェーズによっては仕様変更が不可能になります。もちろんウォーターフォールも内容によっては仕様変更が可能なのですが、ウォーターフォールが適用される開発物の特性を考えるとやはり修正はしづらいです。
また、当たり前ですがいくらアジャイル開発が柔軟に修正できるからといって、その修正する分当然工数が必要でその分他の機能の開発は遅れます。

仕様の曖昧さ

前述の通りアジャイルは柔軟に仕様を変更できるのでスタート時点においては確かに最低限の決定事項から開発の開始が可能ですし、早い段階でプロトタイプの提示も可能なので、そういう意味では仕様は曖昧というのはあると思います。
ただ、実際に開発をする立場だと今自分が取り組んでいるバックログのタスクは仕様をきちんと当然明確化しないといけないですし、このタスクのチケットでどこまで作り込むか等のすり合わせも必要なので働いている目線だとあまりここの差はウォーターフォールと感じたことはないです。ウォーターファールはウォーターフォールでステークホルダーが多くなりやすいので仕様明確化のための合意形成に時間取られます。

進捗管理のしやすさ

これはやはりやることが最初の段階で明確化されており、過去の開発スケジュールを参考にしやすい、なおかつ各人のロールも固定的（後述）なウォーターフォールの方が進捗管理もスケジュールの予測もしやすいです。なので、ウォーターフォールは大幅に進捗が想定より改善されるということはまずないですね、一方で大幅に遅れるは基本的にはないのですが、大事な要件の抜け漏れ（特に法規関係）やあからさまにずさんな工数の見積もりをすれば大幅に遅れることはあります。
一方で、アジャイルは各スプリントがいわば一つの個別開発ですし、リアルタイムに仕様を柔軟に変えるので過去の開発例が参考にならなかったりするので、スケジュールの予測は難しいです。
また、スプリントを重ねれば重ねるほどスキルの上達やチーム内での共通認識の形成といった理由で開発スピードが上がっていくので、事前に想定していた進捗よりも大幅に良くなることもありますし、逆に成果物の方向性が曖昧だったり、チームの形成に失敗すると大幅に進捗がないということがありえます。

複数案件の同時並行

ウォーターフォールの場合だと、仕事のタスクが決まっているのと、自分のロールの持っている仕事がない（他者の仕事や何かしらの決定・合意待ち）という状況が生まれやすいので、複数案件に携わりやすいです。一方で、アジャイル開発の場合は、ロールがそこまで固定的でないので空いているタスクを肩代わりするということが起こりやすく、またスプリント自体は２週間と短く、その中で開発からテストまでを終わらせなきゃいけないということもあり基本特定の案件にフルコミットというスタンスになりやすいです。

ロール、責任範囲

ウォーターフォールは基本的に各ステークホルダー、役割というものがきっちりと決まっており、それに基づいて各自仕事をしていきます。なのでやることはけっこう明確化されている一方で、どうしてもいわゆる三遊間のタスクは生じやすく、その三遊間のタスクに気づかないと大変なことになります。一方で、アジャイルはタスクのチケットという粒度で言えば仕事は明確化されていますが、どのチケットをやるかという厳密な責任境界はなくチームで消化していくという感覚なので、けっこう仕事の範囲が流動的になるので、三遊間のタスクという感覚はあまり生じないです。

テスト

個人的に一番想定と違ったのはここですね。ウォーターフォールの場合、テストは開発スケジュールの後半から単体テスト、結合テスト、システムテストと順々にしっかりとやっていきます。もちろん開発者・設計者としてこれらのテストに携わることはありますが、設計フェーズからは時間が経ってから携わりますし、また組織によってはテスト部隊は別で、設計者はそこまでは関わらない（不具合が出た時の仕様確認のみ、一部のテストのみ）ということもあります。
一方でアジャイルの場合は、自分が開発したチケットのコードに関しては、少なくとも単体テストは書きますし、そこから結合テスト・システムテストも自分が主体的でなくても設計後すぐに動くのでかなりこれらのテストにも意識が向かうようになりました。
そして、それが毎スプリント起こるので、テストという工程が以前よりも身近に感じるようになりましたし、テストの量が多いのでテストの自動化戦略も重要になります。
よくアジャイル開発に対して、「品質は二の次でとにかく機能追加を短期間で！」みたいなとらえ方がありますが、それはまったくの誤解で、各スプリント内できちんと品質を担保してこそ、しっかりとしたアジャイル開発なんだなと感じました。
まぁよくよく考えれば、プロダクトでお客様に見せるものである以上品質の担保をするのは当然といえば当然ですよね。

おわりに

以上が両方経験した上での自分の感想・考察になります。
働き方という観点では大きく変わったなと感じます。ただ、とはいってもどっちが優れているとかいう話ではなくあっている方やお互いの良いところを取り入れていくみたいなプロセスにしていくのが大事かと思います。前職もアジャイル開発の良いところをとりいれようと、車本体とはあまり関わりのないアプリの機能やUIの部分でアジャイルを回し改善をするといった取り組みも行っていました。
まだ、自分もどちらの開発手法に関しても熟練というほどではないのであくまでも経験談をベースにした考察になります。なので、それこそ本記事を読んでいやいやこうは思わないということもあると思いますし、むしろ意見等コメントしていただけると学びになるので、ぜひコメントをいただけたりすると嬉しいです。

ではでは、読んでいただきありがとうございました。