システム開発って苦行ですか？

アジャイルスクラムが個人的に気に入っているのは、早期に失敗することで改善を促すところ。この失敗を安全な領域で発生させるよう、自己組織化された環境で改善を進めるよう、うまく出来ていると思う。書籍の発行や記事も近頃は盛況で、いいものが沢山出てきた。私も復習だったり再発見だったりで、とても楽しんでる。

ただ気になってるのは、ウォーターフォールと対比して、「(自分たちが)最後に失敗しないために」、「現場を改善するために」というスタンスの解説をみかける。これって「開発現場は辛いところ」とか「プロジェクトは上手くいかない」って前提に立ってるんじゃないだろうか。実際のところ、大変なプロジェクトが大半だろうし、悲惨なもの多い。だから、こういうものに興味を持つ開発側の人にとっては、導入根拠として大切なところ。でも、中には"指示されたものを隷属的に作るつらい仕事"という前提を持ってしまってる人はいませんか？

システム開発というのは、本来は、ユーザーにとっての利便性とか、顧客にとってのビジネスを改善したり、何らかの形で顧客がより儲かるとかいった目的のためのはず。だから顧客は予算をかける．．．はず。

でも、身の回りで見かける開発は「欲張った分だけお金はかかります」とか「次世代のフィーチャー、パフォーマンスのために予算をかけましょう」という感じ。顧客にとっての価値が見えなくて、金をかけるための提案を優先してる感じがする。顧客もそういうものだと思ってしまってる。たぶん仕方なく納得してる。なかには「仕様の内訳と1対1の見積もりをくれ」と言う顧客もいる。仕様と納期に追われるプロジェクトが多いのは、業界全体が自分たちで首を絞めてきたんじゃないだろうか。

目指すべきは、"現場の改善"だけでなく、それ以上に"顧客の改善"のためでないといけないと思う。 アジャイルもそのためのはず。プロジェクトの最初に仕様を決めるというのは、顧客や製品企画にかなりの難題を押し付けてる。開発のほうがITは得意なんだからニーズに応える適切な答えを見つけていかないと。そして、顧客が知ってる業務や製品サービスの情報をすり合わせるために、顧客と共に過ごす時間がたっぷり必要で、開発初期の限られた時間で仕様を決めるよりも、開発期間をそのために費やしたい。そのひとつの答えとして、アジャイルな手法の必要性があるんだと思う。

開発側がもたついたりスペックに固執したりしていてはいけないので、スクラムなどのフレームワークを利用して現場を改善していく必要はあると思う。同時に、顧客にとっての価値を漸進的に高めるために、プロダクトオーナーシップも強化していかなければならないのではないか。