一昔前は、「職能横断チームさえできれば、アジャイル開発もスクラムもうまくやれるのではないか?」と思っていた。でも最近は、職能横断チームも当たり前になってきたので、課題が次のステージに進んだように思う。この次の課題として感じているのが「ビジネスと開発に壁があること」。この壁について考えを整理してみようと思う。
壁1: 期待値が違う
多くの現場において、ビジネスは「速く開発してほしい」と願っている。しかし、開発は「長期を見据えてきちんと作りたい」と思っている。
ビジネスは、顧客にはやく価値を提供したいし、契約を取るために機能リリース等の確約を提供したい。
開発ももちろんアジリティを上げて開発をしたいが、「とりあえず動くコード」の質は、時間が経過するについれて落ちていくことを理解している。
壁2: お互いの理解が少ない
お互いの理解はある程度はあるけれど、その理解の量が少ない。お互いに理解したいとは思っている。だが、それができない。多くの原因に以下のようなものがある。
- 理解する時間がない
- 理解したいと思っていない(理解の重要性がわかっていない)
- どうせわかりあえないと思っている
時間がないだけなら時間を確保すれば前に進む。しかし、それ以外の原因だと根が深い。
2の場合、理解する気がない人に理解を求めるのはとても勇気がいるし、「やる」という行動に向けてのコストがかかる。コストとは時間やお金だけでなく、モチベーションも含まれる。
3の場合はどうだろう? わかりあうために時間を使うなら、もっとユーザ価値に直結する活動に時間を使ったほうがいいのだろうか?
壁3: 誰もが効率性を求めすぎている
効率を求めるのは間違いではない。ただ、効率によって、必要経費を削ってしまうと、将来的に痛い目を見る。代表的な経費が「育成」や「教育」だ。もっというなら「技術負債解消」も入るだろう。
効率によって、俊敏性が高まる。だれもがすぐにリリースしたいし、すぐに結果を知りたい。フィードバックサイクルを重要視するアジャイル開発において、この価値観はとても強い。
しかし、チームには個人がいて、個人には人生がある。彼らが成長を求めるのは当然で、これにどう答えていくかは、企業や開発組織の命題だろう。
これに答えずに効率性だけ高めればどうなるか? スクラムだとスプリントで使える時間をすべてプロダクトに費やすことになる。あれ? これ普通のスクラムだよね?
まとまらないまとめ
2000年前後に、ビジネスと開発の壁を感じ、それを打破するためにXPが開発され、アジャイル開発が生まれるきっかけのひとつになっていった。
あれから20年以上たつのに、ビジネスと開発がうまくいっていない現場がまだたくさんあるのはなぜなのだろうか?