[#TiDD] アジャイル開発が注目される理由

最近、大手ベンダーのアジャイル開発への取り組みがニュースになっています。アジャイル開発がいよいよ普及期に入ってきたという印象を受けました。それと共に、それがこれまでのアジャイルコミュニティの言っていたアジャイルと同じものなのか、あるいは別のものなのか、とても気になるところです。それはそれで大切ですが、ここでは、なぜ大手ベンダーがアジャイル開発に取り組もうとしているかを考えてみたいと思います。

従来の開発法

いわゆるウォーターフォール開発では、あらかじめ要件となる仕様を確定して、そのシステムの実現を請け負う方法です。「不確実コーン」(リンク先はAct as Professional)で考えていただければわかりますが、これはリスクの高い方法です。

リスクの高い場合には、保険のビジネスが成り立ちます。大きな問題の起きる可能性のある場合には、個別のリスクを抱える顧客に対して平均的なリスク(発生確率×被害)よりも高い金額でサービスを提供できれば、サービス提供側はその差額を利益とすることができますし、顧客はその差額で安心を買うことができます。

ソフトウェア開発で考えれば、見積もりの総額は以下のように表せます。

　　見積もり総額＝開発見積もり＋リスク見積もり(Σ(各リスク発生確率×被害))

この式から考えると、開発側は利益を得る2つの方法があります。

1) 顧客の許容する開発見積もりよりも少ない開発費用で開発する
2) 顧客の許容するリスク見積もりよりも低いリスク費用(発生した問題の対策費)で開発する

近年、この2つの方法の実現が困難になっているのではないかと考えています。

単価の低下

上の式にある見積もり総額は、発注(顧客)側、受注(開発)側それぞれで見積もりますが、見積金額がそれで決まるわけではありません。開発側はより高く受注したいと思いますが、発注側はより安く発注しようとするからです。その結果、需要と供給で見積もり総額は決まります。

不景気な状況や競争が激しい場合、見積もり総額の低下によって開発の単価が下がってしまいます。場合によっては不確実コーンの中央値、あるいはそれ以下で受注せざるを得なくなります。そうなると、様々な努力をしてもなかなか利益は出ませんし、想定外の問題の発生や、統計的に扱えるだけの数量の開発案件がなければ、短期的に赤字になってしまいます。これは、株主の利益が重視される中では、許容できなくなってしまいます。

リスクの増加

ソフトウェア開発におけるリスクは増加し続けています。規模の増大による複雑化のほか、業務要件の変動、実装しないと確認できないほど多様化した実現方法、オープン化による開発基盤の組み合わせ、など多くのリスクが存在します。そして、それらはソフトウェアの開発技術の発展と適用範囲の広がりによって、日々リスクは増えています。

リスクが増加すると見積もりは困難になりますし、利益を得ることは難しくなります。たとえば、安定した株や証券であれば、バブル崩壊のような暴落がなければある程度の利益を継続的に得ることは可能でしょう。しかし、投機的な株や証券を取引では、高度なコントロールが必要ですし、よほどの規模で取引をしなければ安定した利益を得ることは困難でしょう。

プロセス改善によって開発費用を抑えることができても、リスク費用(発生した問題の対策費)が増加すれば、利益が得られなくなってしまいます。

技術のオープン化

競争が激しく、利益を得ることが困難になっても、技術力を向上して生産性を高めたり、リスクを低減することができれば、他社以上に利益を確保することができます。

しかし、近年の技術はオープン化が進んでいます。すべてを独自技術で実現することはできませんので、少なからずオープンな技術に引きずられます。また、類似のオープンな技術が出てくれば、それに合わせる必要が出てしまいので、逆効果になってしまいます。自社の開発に役立つ新しい技術があるならば、囲い込まずに公開技術として業界に貢献する方がその技術に詳しい分だけ、ほんの少しだけ他社よりも有利になります。

結局、技術がオープン化してしまっている限り、独自技術で大きな利益を得ることは困難だと言えます。

リスクの低減が求められる

アジャイルが注目されるのは、ここに挙げた理由で従来型の開発が困難になっているからだと思います。

まず、アジャイル開発は繰り返し型開発です。予測可能な短期間の開発とリリースの繰り返しによって段階的に開発できるので、発生した問題への適応力が増します。

また、プロジェクトファシリテーションの活動に見られるように、メンバーの能力を最大限に生かします。コマンドコントロールではないので、メンバの気付いたリスクや問題を共有することで、プロジェクトのリスクを低減できます。

しかし、アジャイル開発では変更を受け入れる反面、開発のスコープを変更しますので、一括請負とは相性が悪く、準委任契約が多いようです。開発側は利益率が低いもののリスクを取らなくて済みますので、(額は少ないかもしれませんが)安定した利益を確保できます。それ以外にも、繰り返しの単位であるイテレーションごとに請負契約をするという方法もあります。その場合には契約が煩雑になりますが、不確実コーンの狭い範囲で開発できますので、発注・受注双方のリスクを下げることができます。

チケット駆動開発への期待

チケット駆動開発で使われるチケットはアジャイル開発のタスクとみなすことができ、
「アジャイル開発の親和性が高いらしい」(まちゅダイアリー)と言われています。また、リスク管理を考えると前の記事にあるような特長があります。

- 細かなリスクの管理が可能
- リアルタイムな通知
- 過去の問題のトレースが可能
- 複数イテレーションの管理ができる(決定をできるだけ遅らせることを支援)

これらを生かすことでアジャイル開発＋αの効果を期待しています。

おまけ(勝手な予想)

大手ベンダーの動向を見ていて、最も気になったのは契約でした。準委任契約だと利益は安定しますが、リスクをとらない分だけうまみが減るからです。だからといってイテレーションごとに契約をやり直すのは、大手ベンダーにとっては面倒でしょう。

私が大手ベンダーの経営者なら、発注側がリスクを取ることで得られる利益を狙います。よく言われる方法は、顧客の得た利益に対して成功報酬を受け取る方法です。これまでは、納品後は保守と運用を除いては、瑕疵対応でお金が出るばかりでしたが、顧客の利益の中から一定額の報酬が得られれば、大きなメリットです。

しかし、顧客の利益を確認することは必ずしも容易ではないので、利用期間に対して一定の報酬を得るようになるかもしれません(そう考えると、アジャイルで有名な某社の契約となんとなく似てきますね)。

それ以外にありそうなのが、資本参加です。発注元である顧客の情報システム子会社に資本参加する、あるいは顧客と共同で情報システム子会社を設立するのです。安定した受注が得られるほか、リスクを取った情報システム子会社の利益を折半できるようになります。資本参加はこれはお金だけかもしれませんし、出向という形かもしれません。

いずれにしろ、これまでの業界の構図が大きく変わるきっかけになる様な気がします。そのような中で、チケット駆動開発は重要な技術として、きっと大きな役割を果たしてくれると思っています。