第6回 初めてのアジャイル開発 －その１－「ウォーターフォールは何故炎上するのか」

本書との出会い

こんにちは。スクラムマスターの伊藤です。

「健康とは、できる限りゆっくりとした速度で死に向かうことでしかない。」 - 作者不明

Joel on Softwareから変わって、今回はCraig Larman（クレーグ・ラーマン）の『初めてのアジャイル開発 スクラム、XP、UP、Evoで学ぶ反復開発の進め方』を紹介します。（Joelも引き続き書きますよ。）何故か、各章の最初に名言が表示されていて、こちらは冒頭の名言は第3章 アジャイルからの引用になります。本書は2004年9月発売となっています。

当時、筆者はまだまだ若輩者のエンジニアでしたが、いくつかのプロジェクト開発を経験し、規模の差はありますが、必ずといっていいほど炎上していました。原因は開発終盤で仕様変更が入ったり、追加漏れがあったり大きな障害が見つかったりと様々でした。何とか納期に間に合っても開発陣はボロボロ、顧客も望んでいたシステムとはズレがあるようですが、これでヨシとする風潮が当時の（ひょっとして、今も!?）ソフトウェア業界でした。
なんとかならないものかと考えアジャイル開発や、テスト駆動開発等に興味を持ち独学で勉強し始めます。

当時、「＠IT ITアーキテクト塾 テストファーストの実践」でパネラーから紹介されていた書籍の１つが本書で、色々と疑問に思っていたことがスッキリしたことを覚えています。
（探したら、該当記事がありました。懐かしいですが本質は変わっていないですね。アジャイルは黎明期でスクラムとXPを組み合わせるのが流行っていました。ペアプログラミング以外は今でも使うべきかと。また、テスターが必要とも書かれています。）
https://www.itmedia.co.jp/im/articles/0602/24/news137.html

《よもやま話》

@ITの記事は、なかなか見つからなかったのですが理由は記事内の書籍名が「はじめてのアジャイル開発」になっていたからでした。
小ネタですが、Google検索はツール ＞ 期間指定でいつ書かれたWebか指定できるので、期間と書名で検索したところ見つかりました。

ウォーターフォールでも問題ない？

はじめに、ウォーターフォールで何事も問題なくプロジェクトが進んでいるのであればアジャイル開発に移行する必要はありません。開発手法はあくまで手段であり、お客様が満足する製品を健全な形でお届けすることが目的です。「あぁ、じゃあウチは問題ない。いつも納期に間に合っているし、お客様も満足しているようだ。」という方、少しだけお待ちを。以下の2点も確認してみてください。

1. 開発現場が疲弊していないか
2. 実際に納品されたシステムを利用している人は満足しているか

1に関しては、PMにヒアリングしても無事に終わりましたと回答される可能性が高いので、プロジェクト終了後または実施中に体調不良、休職、退職者が出ていないか一部のメンバーや特定の工程で稼働時間が多くなっていないかといった点に注目しPMだけでなくメンバー一人ひとりにヒアリングするといいでしょう。

2に関しても、発注担当者に聞いても、そのシステムは触ったことがないということも珍しくないので、今後のために実際に使っている人にヒアリングやアンケートという形で協力してもらうのがベストでしょう。満足度や使いやすさだけでなく、どの機能を使っているのか、また使っていないのかについて聞くと、使っていない機能の多さにびっくりするかも知れません。

はい。75%ぐらいのプロジェクトで問題があったのではないでしょうか。米国防総省のプロジェクトでウォーターフォールを採用した場合の失敗率が75%だそうです。（P. 91）
ちなみに、初期の仕様で作成された機能の45%はまったく使われることはなく、19%はほとんど使われていないことがわかっているそうです。(P. 90)

ウォーターフォールの問題点

ここまで読まれているということはウォーターフォールに問題があったのでしょうか。それでは、具体的な問題点を挙げていきましょう。
何故、ウォーターフォールは炎上するのでしょうか？

事前に承認まで済んだ「完全な」仕様の作成

ウォーターフォールは、事前に仕様を作成する必要があり、承認済みの仕様は凍結され変更できません。ただ、現実は顧客に途中で気付かれてしまい、アサリ蒸し器(第３回 参照)を追加させられるか、前述のように使われない機能が盛りだくさんのシステムが完成してしまいます。

プロジェクト後半での統合とテスト

ウォーターフォールでは前半は設計書作成といったドキュメント作業で、問題があっても特に誰も気付かずスケジュール上は「順調です」と進んでいってしまいます。しかしながら後半のプログラミングで一悶着あり、なんとか単体テストも終わり結合テスト、統合テストに入ると実は基本的なところでの思い違いや設計的な誤りが発覚し手に負えない状態になる。設計書が誤っていることに気づくのが統合テスト実行時に発生するということが日常茶飯事という問題を抱えています。

「信頼性の高い」事前のスケジュールと見積の作成

ウォーターフォールは、「後で失敗する」ライフサイクルと呼ばれ、アジャイルは「先に失敗する」ライフサイクルと呼ばれています。初期の簡単なフェーズでは、スケジュールどおりだという幻想を抱くことが出来ますが、これは、困難でリスクの高い要素（プログラミングやテスト）が最後まで先送りされているからです。そして、スケジュールが半分ほど進んだところで、本当に複雑なところや困難な要素が現れドカーンと爆発炎上してしまうのです。

この話の後で本書では崖から落ちた男の話を引用しています（P. 75）
勢いよく落ちているときに誰かがどなった。
「大丈夫か？」
男が答えて言うには
「今のところ大丈夫だ！」

《よもやま話》

崖から落ちる男の話はひょっとすると、ウォーターフォールとフリーフォール（自由落下）とかけている？アメリカンジョークなのかと、ふと考えるようになったのは年のせいでしょうか。ちなみに、アメリカで一番よく聞くジョークはSee you later, alligator（シーユーレーター、アリゲーター）です。

何故ウォーターフォールが普及したのか

ソフトウェア開発の歴史を遡ると黎明期の1960年代（もう60年前だと…?!）はコーディングしては修正するという場当たり的なものでしたが、1970年代にウォーターフォールが理想的な開発手法だと広まり、多数の書籍、コンサルティング会社、教育者がこの手法は理想的だと吹聴したそうです。 (P.70)
そして1980年代 米国防総省はウォーターフォールのライフサイクルを推奨する公文書を発行します。日本では、ソフトウェア開発はOSも言語も全てアメリカ産なので開発手法もそのままウォーターフォールが推奨されたと考えられます。

しかしながら、米国防総省はウォーターフォールが失敗することが多かったため1987年に反復型・進化型手法を推奨するという勧告を出しています。他のアメリカの団体も同じような経緯を辿っています。
※諸説あります

ウォーターフォールが推奨されつづけていることには、他にも理由があるようです。
■ 1度で終わるウォーターフォールは説明するのが簡単（要求を分析して、設計し、それから実装する）アジャイルは複雑で説明は未だに難しい。
■製造業からの流れでソフトウェア開発も予測可能であると考えられていた。（今でも思っている方が多いですが…）
■ 経営者がウォーターフォールを好んだ。これは、秩序正しく、予測が可能で、説明がつきやすく測定可能なプロセスであり、文章を中心とした単純なマイルストーン（要求が完了など）が存在するという幻想をウォーターフォールが与えたからである。
■プロジェクトマネジメント協会（PMI）はプロジェクトマネジメントのための知識体系（PMBOK）には現在はアジャイル開発を認めているが初期のPMBOKには予測型計画といった色合いが含まれており、ウォーターフォールと相性が良かった。
※諸説あります

《よもやま話》

読まれることのないオリジナルの「ウォーターフォール論文」"Managing the Development of Large Software Systems" (Proceedings of IEEE Wetson, 1970) は問題がありそうな新規開発プログラムはバージョン2を納品するようにと実は反復型が推奨されています。(P.125)
ちなみに、スクラムのルーツは日本の革新的な10企業に共通するベストプラクティスについてまとめた” 　The New New Product Development Game” (Harvard Business Review, Jan 1986 by Hirotaka Takeuchi and Ikujiro Nonaka) の中に出てくる自律的チームプラクティスの名前から。アジャイルのことはサシミ(刺身）と呼んでいるがこちらは普及しなかった模様。(P.165)

アジャイルなら幸せになれるのか？

本書が書かれた時代背景もあり、アジャイルを導入するには既存の開発手法であるウォーターフォールという高い壁を崩す必要がありました。「ウォーターフォールじゃダメなの？」「じゃあ、なんで皆ウォーターフォール使っているの？」といった質問に、いかに論理的に説明するかというハードルがあったのです。本書は様々な事例や数値、歴史などを紐解き論理的に説明しているため今回紹介した範囲が役に立ちました。

さらに、痒いところに手が届くように巻末のFAQでは「アジャイルと一括請負」「請負文化を持つ組織にアジャイルを採用するには」「アジャイルを採用するよう顧客を（あるいは経営陣を）説得するにはどうしたらいいか」「QA部門の役割はどうなるのか」といった、正にソレが知りたいという質問が満載です（後日、紹介予定です）

1つ目のハードルを超え、「じゃあ、アジャイルにはどんなメリットがあるの？」と聞かれた時の回答を次回紹介したいと思います。ただし、アジャイルも銀の弾丸ではありません。

《よもやま話》

釈迦に説法かも知れませんが、「銀の弾丸」とはドラキュラや狼男をも倒せる必殺の武器ですが、ソフトウェア開発において、いかなる状況も打開できる魔法のような武器は無いという戒めです。Joel on Software その3でも紹介したソフトウェアマネジメントの古典である『人月の神話』に出て以来、様々な場面に登場します。

――――――――――――――――――――――――――――――――――

お問合せはお気軽に
https://service.shiftinc.jp/contact/

SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/

SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/

SHIFTの導入事例
https://service.shiftinc.jp/case/

お役立ち資料はこちら
https://service.shiftinc.jp/resources/

SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/