先日、今はやりのオンライン飲み会で笑えない話を聞いたので、私自身のアジャイルの理解をまとめておくことにしました。私は、事業会社の内製開発チームでスクラムマスターを務め、Scrum Alliance®の認定スクラムマスター（CSM®）を取得しました。現在はITコンサルタントとしてクライアントのアジャイル適応の支援をしています。開発チームでのスクラムマスターでの経験、コンサルティングファームでのアジャイル理論の整理で腹落ちできたことをご紹介したいと思います。

#笑えない話とは
知人がプロジェクトで、IT部門のクライアントから真顔で言われた一言。いや、二言ですが（笑）
「アジャイルって、設計書とかドキュメント作らないんでしょ」
「計画を立てるのはアジャイルじゃないよね」

さすがに最近はこのような誤解はなくなって、都市伝説だと思っていました。ソフトウェア開発の現場でもこう言った誤解をされている方がまだまだいるのかと思い愕然としました。
　追記：最近、私自身も応援に入ったプロジェクトでそのような場面に直面してしまいました(苦笑)
なぜ、こういったアジャイルの誤解があるのでしょうか？

”アジャイル”という言葉は2001年のアジャイルソフトウェア開発宣言に始まりました。日本でも2000年代にアジャイルが紹介されてバズりましたが、うまくいかなかったプロジェクトも多くありました。
でも、今またアジャイルが脚光をあびています。VUCAともいわれている変化の激しいビジネス環境の中で、企業はこれまでにない変化のスピードを求められています。従来のウォーターフォール型の開発で時間をかけてサービス、プロダクトやITシステムをリリースをするのではビジネス機会を失ってしまいます。それに対して、アジャイルが変化に迅速・柔軟に対応でき、現在の市場で生き残るために進む道であることは事実です。

###なぜ2000年代の第１次アジャイルブーム(？)が廃れたか
当時、開発者もユーザーも大きく誤解したままアジャイルがもてはやされてしまったことがありました。開発者側では、"ドキュメント不要"、"あらかじめ計画を立てない"、"設計工程が必要ない"といった誤解。発注側であるユーザ側も、"とにかく早くモノができる"、"安くできる"、"いつでも仕様変更できて無理が通せる"といった誤解がはびこってしまったのです。

なぜでしょうか？ーアジャイル自体は”価値観”であるにも関わらず、多くの場合でウォーターフォール型開発方法論をリプレースする**”アジャイルもどき開発方法論”**になってしまったことが大きいと思います。要するに、本来のアジャイルの原理原則が理解されず、やり方を形式的に適用するだけで本質を理解していないために失敗してしまったプロジェクトが多数あったことです。
また、SIerの開発請負契約の契約モデルとの相性が良くなかったことも理由の一つであるかと思います。(実際には工夫することでアジャイルに十分な契約を交わすことが可能です。今年(2020年)、IPAや情報処理学会からガイドラインが出ています。)

#いままでの開発手法(ウォーターフォール)の限界
なぜアジャイルがこれほど注目されているのでしょうか？ウォーターフォールのような計画駆動の開発スタイルでは昨今のビジネス環境での開発がうまくいかないからです。
VUCAとよばれるようにマーケットの変化は非常に速くなっています。また、ITシステムは企業活動を支援するものではなく、ビジネスそのものになっています。以下にウォーターフォールの欠点をいくつか列挙しました。

時間をかけて計画し、開発しているうちにビジネス機会を失う
顧客・ユーザが要件をイメージできないので最初にすべてを要件定義できない
開発した機能のうち60%以上は、まったく使われないかほとんど使われていない

なぜフォーターフォールが変化に弱いのか？ーウォーターフォールでは最初にすべてを計画するので、変更はリスクとして扱われます。そのためのバッファを積んで対処しようとしています。変化はネガティブに捉えられています。しかし、実際のプロジェクトが計画通りでまったく変更無く完了した経験はありますか？私にはありません。残念ながらそのようなプロジェクトは皆無でしょう。

###ロイス論文(ウォーターフォールの元と言われている論文)の悲劇
話がそれますが、実はウォーターフォールモデルの原点といわれているロイス博士の論文には、ウォーターフォールという言葉が使われていないばかりか、そのような開発プロセスでは失敗すると語られていることをご存じないでしょうか。

Royce論文の内容を紹介したが，図の流れを中心に簡単にまとめると以下の内容であった。
分析とコーディングだけでは大規模ソフトウェア開発はできず，上図左の工程が必要になること，そしてそれは上から下へ流れるだけでなく，前工程の修正のために後戻りが有効であること。さらに開発リスクを排除するためには，Step 1:分析やコーディングの前に事前のプログラム設計を終わらせ，Step 2:ドキュメントを最新かつ完璧にし，Step 3:納入されるバージョンが２番目になるように作業を２度やり，Step 4:テストを計画，管理，モニタし，Step 5:顧客を巻き込むという５つの追加項目がいる。これらを要約し図にしたのが上図右である。
(出典<一部改変>：ウォーターフォールモデルの起源に関する考察 : ウォーターフォールに関する誤解を解く)

#アジャイルの価値観とは
###アジャイルソフトウェア開発宣言に立ち返る
先ほど、アジャイルは価値観だと書きました。アジャイルの価値観について説明していきたいと思います。まずなんといっても、アジャイルソフトウェア開発宣言を理解することから始めましょう。

アジャイルソフトウェア開発宣言は、2001年に17名の軽量開発手法などの有識者が集めって宣言されたものです。これは、よりよい開発方法を見つけ出そうとする人々が、開発の実践を通して到達した価値観です。読み解くにあたって重要なことが２つあります。
1．**青字の左側よりも赤字の右側に価値を置く：**ウォーターフォールでは、方法論に従いガバナンスを重視するあまり過度に形式的となったことで失敗したプロジェクトが多くあります。右側に挙げられたポイントは、自然な営みが忘れ去られていたことへの警鐘です。
2．**とはいえ、青字の左側をいらないとは言っていません。**この宣言では、プロセスやツール、ドキュメント、契約、計画に従うことも必要だと認めています。

###アジャイルの価値観とは、リスクを低減するための知恵
アジャイルとは、プロジェクトや開発のリスクを低減するためのアプローチ、価値観であると考えています。その実践が、スクラムやXPといったアジャイルのフレームワークやプラクティスで実現されるのです。なので、スクラムの”スクラムマスター”や”プロダクトオーナー”といった役割を割り振って、”デイリースタンドアップ”や”スプリントレビュー”といったスクラムのイベントを機械的に導入したところでアジャイルのメリットを享受することはできません。同様に、DevOpsだったりCI/CDのツールの導入からはじめてはうまくいきません。

抽象的な表現になってしまいますが、**”計画どおりにいかないことに対してどう対応していくかを考えること”からスタートすればよいと思っています。それは、”現実的な計画を積み重ねる”ことと、手戻りを抑え”ムダを省く”**ことだと思います。
1．最初から、”計画通りにいかないこと”ことを織り込む
2．やったことないことは見積もれないから、部分的に試して精度を高める

###結局、アジャイルなプロジェクトとは
アジャイルソフトウェア開発宣言の４つの価値観がチーム、ステークホルダーと共有され、アジャイル宣言の背後にある原則の多くを実践できているプロジェクトではないでしょうか。
と言われても、正直イメージがわかないと思います。次の記事で私の経験をもとに具体的な事例を紹介したいと思います。

#参考

IPA: アジャイルソフトウェア開発宣言の読みとき方
TechPlay: [アビームコンサルティングが明かす「ビジネス改革をアジャイル活用で失敗しないための方法」とは？]
(https://techplay.jp/column/406)