アジャイルは魔法の杖ではないことを経営層や非IT部門にQCD+Sを図示して説明する

アジャイルという言葉が急速に浸透してきている。ソフトウェア開発とは全く関係のない業務の担当や経営者までもがアジャイルが重要だと語るケースも増えてきている。

しかし、アジャイルを魔法の杖と誤解しているケースも散見される。

生産性の向上の魔法の杖

仕様を確定しないまま開発できる魔法の杖

五月雨式に要求を出しても対応できる魔法の杖

コスト削減の魔法の杖

これらのようにアジャイルに過大な期待をされてしまい困った経験がある人は少なくないだろう。

そこで、ソフトウェア開発とは全く関係のない業務の担当や経営者にも、アジャイルが魔法の杖ではないことをわかってもらうために、

Q：Quality
C：Cost
D：Delivery
S：Scope

を図示することでアジャイルを説明してみたい。

まず、従来からの開発手法であるウォーターフォールのQCDSを見てみよう。

縦軸が開発する機能である。Scopeが広ければ機能が増える。Qualityを要求すれば機能要件（と非機能要件）が増える。機能が増えれば Costが増える。このようにQCSが縦軸に集約されている。そして、本稼働の予定が定められる Delivery である。

ウォーターフォールでは、計画策定時にQDSを元にCostを見積もる。不確定要素があるので見積もりにはバッファを積み増しして Cost を決める。この見積もりの時点でQCDS全てが固定された状態となりプロジェクトをスタートさせる。ところが、プロジェクトの途中で、Scopeや機能やQualityに対する追加や変更が必要となることが少なくない。

本稼働予定日（Delivery）を変更せずにこれらの追加・変更に対応するために、プロジェクト要員の増員などを行うこととなり、結果としてCostが増える。あらかじめ積み増ししていたバッファを食い潰し、追加Costが必要となることも少なくない。
さらに、開発の進捗遅れなどからDeliveryが間に合わなくなり本稼働予定を延期するケースもある。

このようにQCDSを固定してスタートしたにもかかわらず、QDSが変更となり結果としてCostが増えた経験は誰にでもあるのではないだろうか？
ウォーターフォールの場合でもQCDS全てを事前にコミットすることは非常に難しいということをお分かりいただけるだろう。そして、これはソフトウェア開発に限ったことではない。東京五輪などは良い例（悪い事例）ではないだろうか？

そこで、プロジェクトのスタート後にも追加・変更があり得ることを前提とし、スタート時にはC（Cost）とD（Delivery）のみを固定し、QS（Quality, Scope）に柔軟性を持たせて計画しているというのが私のアジャイルに対する認識である。

上の図の例では、QとSについてまずは最低限必要なMVP（Minimum Viable Product）と最低限必要な非機能要件（必ず必要なQS）を開発するための見積もりを行い、C Dを決めている。横軸に沿ったCostの矢印は開発要員数と期間によってCostが決まることを表している。
そしてMVPや非機能要件もプロジェクト途中で変更があることを前提としてプロジェクトをスタートさせる。

スタート時点の見積もりどおりにプロジェクトが進捗すれば、上の図のように途中の進捗に揺らぎはあっても本稼働に当初に想定したものが完成する。

そして、多くのアジャイルによるプロジェクトでは、短期間にイテレーションを回すため手戻りの発生を最小限とすることができる。そのために、ウォーターフォールの場合に見られた「使わない機能」を作ってしまうムダを抑止できることから、当初想定よりも前倒しで開発が完了することがあるだろう。その場合、本稼働（D）を前倒しするか、追加機能（S）を前倒しすることができる。

アジャイルを魔法の杖と誤解している人たちは、必ずこうなると幻想を抱いているのではないだろうか？

しかし、世の中、そんなに甘くはないことは、誰でも冷静に考えればわかるだろう。

当初の見積もりの甘さ、プロジェクトの途中での追加・変更の多発、開発内容が想定を超える難易度であった等によって、下の図のようになることも当然あり得る。

この場合、本稼働を延期するか、開発未完のまま本稼働を開始するか、どちらかの選択肢を迫られることとなる。

こう説明された、アジャイルが魔法の杖と思っていた人たちがどう感じるだろうか？

逆にアジャイルは当てにならん、ウォーターフォールで開発すべし、となるかもしれない。

しかし、ウォーターフォールにおいても、開発遅延のために追加コストが必要となったり、本稼働を延期したりするケースがあり得ることを想い出してほしい。

そう、どちらもリスクはあるのだ。

プロジェクト毎にアジャイルとするか、ウォーターフォールとするかを判断する必要があるのである。

さてさて、どうでしょう？　これまでの説明で、みなさん、アジャイルが魔法の杖ではないことを理解いただけただろうか？