アジャイル開発をコストやスピードで語るのではなく、不確実性の管理という視点で論じる
アジャイル開発をコストやスピードだけで語るのではなく、不確実性の管理という視点で論じるのは重要だ。アジャイル開発で安く早くプロダクトをリリースとか言う人がいるが、ソフトウェア開発はそんなに甘くない。魔法じゃないのだから早く安く作れたのは機能を限定して非機能を無視したりしてリリースするからだ。その後に重要な必要機能に気付いたり障害でデータを失ったり、サービスが停止したり、そんな問題を発見した都度直していくことで必要な手間だけをかけていくことになる。結果としてコスト効率は良いと思うが完成までの時間や総額コストが劇的に下がるわけじゃない。改善の文化なくアジャイルという手法に頼ると、安く作れたなら次も安くという粗製乱造の連鎖が始まり、開発コストの下振れと品質の低下に足をすくわれることになる。ついでに、コストだけで判断する経営陣にかっこうの餌を与えることにもなる。
チームを小さくして継続的にサービスを担当してもらうことでサービスのコンテクストを継続的に維持することができる。しかし、小さく始めたサービスがたくさんの要求を組み込んで大きく成長すると、ある時点からアーキテクチャが必要になる。そこで一旦全面作り直しになるわけだが、細切れなアジャイル成果物の粗製乱造を避けてサービスコンテクストを維持するには、そんな判断も必要だ。また、優先的に手をつける非機能要件を判断するのはステージによって違う。MVPでは機能設計しかしない傾向もあるが、少し成長したらSREを取り入れた方がよくなる。そこの判断をチームにどのように権限移譲するかも課題だ。いづれにしてもこれまでのような可用性SLAやセキュリティ対策のような固定的な非機能要件をあげつらっても効果的とは限らない。analytics.jsみたいなサービス品質の計測手段を確立してどの非機能要件を次のリリースで改善するか決めるのがよい。例えば、サイトのコンバージェンスとかのサイトそのもののビジネス品質に相関のある傾向を掴む必要がある。表示速度とバウンス傾向とか単位時間当たりの機会損失とか。
アジャイルは適切なコストをかけていれば不確実性に適切に対応したものができるが、ウォーターフォールでは設計時に多くの非機能要件を決めてしまう。そうすると不確実性を広めにカバーせざるを得ず、無駄なコストやコンテンジェンシーが発生し、的外れなことも多い。大規模なプロジェクトにもなりやすく管理コストものしかかって来る。それでも事前に投資額を確定しないとプロジェクトがスタートできないのは、意思決定者が投資回収の保障を求めるからだ。事前に回収できるとわかった投資しかできないのは意思決定者の決定的な能力の不足なのだが。
