前の記事で気になるところがあるとほんの少し触れましたが、令和元年版 情報通信白書の 第2章3節「Society 5.0が真価を発揮するためにはどのような改革が必要か」で気になる図（引用下図）を見かけました。アジャイルとウォーターフォールの比較です。

アジャイルでは、イテレーションやスプリントと称して「ミニウォーターフォール」をやってしまうことが悪い実践(Bad Practice)として槍玉に上下られるのを知っており、ウォーターフォール的工程がイテレーションされているような印象も受けるこの図の言わんとすることが気になったのです。

[この図に書いてあるもの]
『プロダクト・イノベーションのためのICTにおいてはウォーターフォール開発ではなくアジャイル開発できる人材が必要だが足りない｡ 』という文脈で、ウォーターフォールとアジャイルの違いを説明しようとしたものと思われます。 

アジャイルというのは、さまざまな技法ややり方を包括的に呼んでいる名前なので、
　・プロジェクト管理のフレームワーク：スクラム
　・テスト手法の技法、開発工程の組み方：テスト駆動開発
　・プログラミング、スキル共有等の手法：ペアプログラミング
など、開発のいろいろやシーンのものが包括されています。

スクラムはプロジェクト管理のフレームワークとして有名ですが、エクストリーム・プログラミングでもプログラミングの実践だけでなく管理面の要素があったりします。

対して、ウォーターフォールというと、大手メーカなどでも体系化していたりしましたので、企業などでもだいたい共通の認識を持たれています。
会社によって名前の付け方が違ったりなどはありますが、おおむねこのようなものです。

・最初にすべてを計画する。作ると契約したものは計画通り全部作る。
・開発を、要件定義→設計→製作→テストと工程に分けて管理する。
  ビジネスから実装への流れを上流から下流への流れとして工程化したもの　になる
・次の工程に移るときは明確な区切りがあり、レビューなどで先へ進むこと
  を確認する。本来の考え方では、先に進んだら戻らない。
・先行工程のドキュメントに書いていることを正として後続工程で開発する
・後続工程で先行工程の間違いを発見した場合、後続工程の判断でいきなり 
  その工程から修正してはいけない。上流工程での分析・設計に戻る
 （手戻り）

先ほどの図に描かれた「要件定義　設計　開発　テスト」。これはウォーターフォール的発想だと「要件定義→　設計→開発→テスト」という印象を受けます。

日本のアジャイルの多くがスクラムを採用していると聞いたことがありますが、スクラムガイドには

スプリントは、スプリントプランニング・デイリースクラム・開発作業・スプリントレビュー・スプリントレトロスペクティブで構成される。

とのみあります。スプリントというのはこの図のイテレーションと同じです。

スプリントを計画して、毎日15分ぐらいで状況や課題や対応を共有して、開発して、スプリントの終わりにはレビューをして、そして得た経験を振り返って次への糧にしよう、
ということなのですが、このスプリントの計画の中身は「開発できそうな機能と、それをどうやって作るかの作業の、設計を行う」ことです。

開発チームは、自分たちの作業を構成・管理するために、組織から体制と権限を与えられている

とあり、開発チーム以外の誰かが決めた作業の構成に従って、その枠内でどうするかの作業組み立てを要求するものではありません。
スクラムガイドが要求しているのはスクラムの枠内から出ずに、開発チームが自分の責任で決めることです。

[同じ言葉なのに違う受け止め]
アジャイルとウォーターフォールでは、価値感や指向・実践内容が異なるので、同じ言葉だから同じ意味・概念だと理解してはいけないこともあると感じています。
この図の中の言葉だと「テスト」が象徴的です。

ウォーターフォールでのテストは、V字モデルのように、
 プログラム設計書レベルのことを検証する単体テスト
 総合設計・外部設計書レベルのことを検証する統合テスト
 要件定義書レベルのことを検証するシステムテスト 
 業務が問題なくできることを検証する受け入れ・運用テスト
というように、段階的に各工程で定義・設定した内容が実現されているかという視点から検証されることが多いです。

業務が問題なくできるか、受け入れ条件を満たしているかは、最終段階のテストでないとわかりません。
システム開発を植林に例えるなら、
プログラム設計書＝１本の木をどう植えて仕立てたいか書いた物
要件定義書＝どういう森にしたいのかの思想やグランドデザイン。
1本の木をみるだけでは、森がどういう目的のものでその木が森全体の中でどう見えるかはわかりません。

一方アジャイルですが、テスト駆動開発を採用した場合、工程の最初はテストです。要件定義ではなくテストが最初に見えるような図のほうが自然という意味です。
最初にテストのプログラムを書きますが、それがそのテストされるプログラムの仕様でもあります。

先ほどのスクラムガイドのところで「開発できそうな機能（中略）の、設計を行う」と所を読んで、最初に設計書を書く、と思った方もいるかもしれませんが、そうとは限りません。
昨今の高速リリースの実現に繋げていくには、テスト駆動開発を採用し、「まずテスト」を徹底するのがここしばらくの潮流かと思います。

具体的には、AをインプットとしてBをアウトプットするプログラムを書く「前に」、作ろうとするプログラムにAを与え、アウトプットがBかどうかを判定するプログラムを書く、とイメージしていただいていいかと思います。

非常にざっくり極まりない例ですが、pgm が作りたいプログラムだとして、
最初に書くのはこんな感じでしょうか。この時点で、作りたいpgmはダミーでよいです。

a = "インプット"  　 //プログラムに与える値を"インプット"にする
b = pgm(a)        //テスト。プログラムにそれを与えて結果をbに入れる
if b == "アウトプット"  //結果は"アウトプット"？
   print("OK!")          //  そうならOK
else  　　　　　　　　　 //そうでない？
   print("NG!")　　　　   //  ならNG

これでテストプログラムにより、pgmというプログラムがどんな動作をすべきかが明示されました。
これは、「包括的なドキュメントよりも動くソフトウェア」により価値を置くアジャイルの精神の一つの現れでもあるかと思っています。
アジャイル的には、様々なメリットがあります。
・早く動くものが出来上がる
・現物を早く見せられるので、早くユーザの判定や要望を取り入れられる。
・要件変更があっても常に先にテストを修正することで、テストすれば仕様を満たすかどうかが常に確認できる状態を維持できるようになる
・動くテストコードが常にあれば、テストを自動化できる

また、『このプログラムを顧客はOKといった』というより『このテスト＝仕様を満たすものを顧客はOKといった』と考えられるのは、自動リリースや、インプット･アウトプットを変えずに保守性や品質向上のために再設計を行うリファクタリングというプラクティスにもなじむと思えます。

こんな感じで、テストといっても、ウォーターフォールしか知らない人と、アジャイルしか知らない人とでは、思いうかべるもがのが違うと思った方がよい印象を持っています。

[ミニウォーターフォール]
冒頭の図に戻ります。
白書の意図がどうあれ、ウォーターフォールしか知らない人がこれを見ると、ウォーターフォールを短い期間でやれるよう分割して小さくすればよい。と思うことも多いでしょう。

その発想だと、まず計画して、スケジュールを大きく4つにわけるでしょう。1スプリント（イテレーション）2週間とすると、
3日で要件定義で作るものを決めて、
それがプログラムとして動く姿を3日で設計して、
2日で作って、
設計と要件を満たすかどうか2日でテストする
ことになります。（ウォーターフォール式だと、それだけでなく工程の区切り事で、1イテレーション内に4回レビューしたくなるでしょうしレビューできるものを作るのでしょう）

そんな視線でこの図を見ていると、素朴な疑問がいくつかあります。

・変更要求は次のイテレーションでないと要件定義に取り込めない想定？
・手戻りを許さないのなら、顧客との会話は要件定義の工程でしかしない？
・手戻りを許すなら、イテレーションの期間が不定になるが、どんな管理フレームワークを想定している？　(スクラムではイテレーション期間を固定にするので）

「計画に従うことよりも変化への対応」は？「顧客との協調」は？
アジャイルとウォーターフォールってイテレーションする以外何が違うの？

そこで、手がかりがあればと思い、もともとどういう図だったのか、引用元にあたってみました。

白書：
（出典）総務省（2019）「デジタル経済の将来像に関する調査研究」ITmedia エンタープライズ記事を基に作成
（上図）
↓
デジタル経済の将来像に関する調査研究
出所）IT Mediaエンタープライズ記事を基に三菱総合研究所作成

↓
即席！3分で分かるITトレンド：コレ1枚で分かる「アジャイル開発」

調査研究のPDF内に引用元の記載がみあたらないのですが、今Webで参照可能なところではこれが近いです。また、ITメディアには、複数の記事で類似の図がありますが、古さや出典の記載を参考に、当記事ではこれを引用しました。かなり近くいけれどこれが原図と思ってよい？という意味で以下「原図？」と記載します。

図中の文字が違うところがあります。

違い１
白書・調査研究：矩形に要件定義、設計、開発、テスト、と書かれている
原図？：工程を想起させる矩形はあるが、工程名は書かれていない

違い２
白書・調査研究：「イテレーションによるテスト結果を踏まえ、仕様などを変更・改善」
原図？：「ビジネス上の重要度で要件の優先順位を決め、これに従って必要機能を順次開発」

白書が出典としている報告書には

「アジャイル型」は、ウォータフォール型と異なり、リリースしたアウトプットに対するテスト結果をイテレーションを通じて収集することで、最適なサービスやアプリケーションを開発する

というアジャイルの説明に対応して図示されています。アジャイルについて言及した目的は、次の文に示される通りかと思います。

ICTの進化、サービスや顧客ニーズの多様化のスピードが速く、次々に新しいサービス・製品が求められる市場においては、要件定義からリリースまでの短い開発期間の反復（イテレーション）を重ねながら、よりよいシステムの開発を目指す「アジャイル型」の開発が近年注目されている

この報告書は、という文脈での図違いの説明と思われます。

一方、原図？の文章は、『アジャイル開発の本質は、「全部つくらない」』とあるように、プロダクトバックログを念頭においたものと思われます。つまり、
「プロダクトに必要だと把握しているもの」である要求を「すべて順番に並べた一覧」がプロダクトバックログであり、作らなくてよいものは作らない
ということを、ウォーターフォールの最初にすべて計画すると対比させて説明したものです。
原図？の記事の言いたいことはこれに集約されると読んでいます。

アジャイル開発の狙いを整理すると、次の3つになるでしょう。
・予測できない未来を推測で決めさせず、本当に使うシステムだけをつくることでムダな開発投資をさせない。
・変更要求に柔軟に対応し、納得して使えるシステムを実現する。
・納得できる予算と期間の中で最善の機能と品質を実現する。

【雑感】
今回は本文が雑感寄りでした、

ウォーターフォールの延長で読まれた場合、この図を掲載・引用した方々の意図は伝わったのでしょうか。

今回、ウォーターフォールとアジャイルの価値感や概念の違いに触れましたが、アジャイルのためには組織文化を変えるのが重要といわれており、また、アジア圏ではアジャイルは機能しない（原文）、普及しないのではないかという指摘もあります。実のところ、ウォーターフォールも「あらかじめ計画してきちんとやる」というIT文化を形成するものの一つになっていると思います。

かつて和魂洋才を選んだ日本ですが、目的がビジネスに勝つことであれば、アジャイルやDevOps以外のやり方・別の文化で勝てれば、別に問題ないです。現状はというと、リリースが年や月当たり数回の特別なイベントとして残っていることがまだまだある所と、2012年時点で1時間1000回デプロイの日常、それからさらに高速化しているだろう所とでは、差がどんどん開いていくので危機感を感じます。

「アジャイルで、テスト駆動開発を採用した場合」と書いた部分でなぜテスト駆動開発なのかを補足すると、欧米のスピード感を見てDXのスピード感というのであれば、それはDevOpsのスピード感でもあります。
　DevOpsとは、開発だけでアジャイルしても早くならないからOps（稼働中のプログラムの面倒を見たり、開発環境から業務で使う環境に展開したりする役割）も一緒にアジャイル的にやろうよ、というムーブメントです。
　そのためにはテスト駆動開発が重要といわれます。

【小ネタ】
・AGSG期間比
「3日で要件定義で作るものを決めて…」の箇所ですが、AGSG（日本IBM適用業務標準化ガイド）だと、要件定義は期間比で、正確な数字が手元にないので確か20%前後だったかなという記憶に頼って強引に20%と置いた数字です。そのノリで、1週間のスプリントを組むと、1日から1.5日で各工程が続くわけです。
AGSGは読んでみたかったものの、まだ叶っておりません。

・ミニウォーターフォールであっても、関係者全員が自覚してやっているのなら必ずしも間違いとは言えないというコメントもあります。
http://www.mogital.com/agile/Is-your-team-really-Agile-or-mini-Waterfall

・結局仕様って要るの？
という記載にある文章が要件定義を考える上で示唆深いです。

Historically, specifications have been used to communicate to the customer (be it an internal or external customer) what will be built. Agile is built on the principle that this is actually not in the best interest of the customer.

『歴史的には、仕様というものは、何が出来上がるのか社内外の顧客と共有するためにかつて使われていた。アジャイルは、そのやり方では実際には顧客の最善の利益にならないという本質に基づいて構築された』

具体的に何をするかというと、顧客の利益になるかを仕様ではなく「うごくもの」で見せて、顧客からのフィードバックを得、イテレーションで（過去に計画したものではなく、今現在の）顧客の最善の利益に貢献していくものを作ってくということだそうです。

今回はここまで
(2020/2/2)