Ryuzee.com

アジャイルって受託開発との相性が最悪な気がするより。釣りっぽい記事な気もするんだけど。

SIerから見たアジャイル

工程の分断が絶対許されないから、上流工程と下流工程を別会社が担当する今の日本の受託開発業との相性は最悪だね。自分たちで全部やれる人材が揃ってないといけない上に、コミュニケーションを綿密にとらないと成果物がグダグダになりそうだから、人月との相性も悪い。

要件まとめてぽーんと丸投げしたほうがSIerとしては美味しいわけだから、なんでこんな苦労を別にしなくちゃならないの的な話になってる所がいっぱいいそうなんだけど、どうだろう。アジャイル導入って自己否定なんじゃないのかしら。だからやりたくても出来ないんだね、これ。

今の日本のSIerのモデルは”まだ”建設業みたいな多重階層の構造であることは間違いない。
収益性については、一次受けのSIerは少ない要員で沢山のプロジェクトを外注使って回すことでレバレッジかけて、一人あたりの売上と利益を高くしている。
でも、もう気付いている会社も沢山あるんだろうけど、このビジネスモデルって、名前で仕事が取れる時にしか有効じゃないんだよね。

大手のSIerに発注した際によくあるのが、打ち合わせに一次請けの社員は1人くらいしか来なくて、残りは全部外注がやっているパターン。お客さんからすれば、マージン一杯抜かれて高い金払うくらいなら外注さんと直接契約した方が安くて良いよね。
残念ながらレバレッジかけまくってる会社からは技術力はどんどん無くなっていって、そのうち見捨てられてしまうんじゃないの？

そう考えると、分業のモデルは、工程ごとの分業ではなくて、チームの中に何人外注さんを混ぜるか？って方向が正しいのだと思う。
自社の要員で全部開発できるけれども、平均単価を下げるために外注さんを混ぜるのと、開発できないので外注さんに任せるのでは、自社の経営におけるリスク度合いが全く違うよね？

顧客から見たアジャイル

アジャイルが上述のやり方だと仮定すると、僕が顧客側にいたらこういう質問をすると思う。
* 最終的なリリース日はいつになるの？
o 意思決定を延ばすってどういうことなの？
o ウチはこの予算でいつまでにやって欲しいんだけど、それ守れるの？
* イテレーションって毎回納期もスケジュールも違うの？
o そのやり方でウチにメリットあるの？上に説明しにくいよそれ。
* ある機能の開発中、別の機能に要件漏れがあったらどうなるの？
o Aという機能を要件→テストまで回してOKだとする。
o でもBという機能の実装中にAの変更が必要なのが発覚した。
o これどうすんの？手戻りして直してくれるの？

若干アジャイルに関して誤解があるような気がする。
アジャイルだからリリース日を決めない、ってことは無い。
Scrumであればスプリント毎にレビューして、場合によっては本番にリリースするし、XPだって数イテレーションごとにリリースする。
XPなんかは最初にリリース計画もするし。
意思決定を延ばすのは、実装する機能の優先度に関わっていて、重要なものから意思決定していけば良いということ。逆にあってもなくても良い機能を今意思決定しても仕方ない。ビジネス上の価値の実現がシステム構築の目的だから、その価値の実現に大きく寄与するものについては、ギリギリまで判断を待ちたいと思うよね。
あと、イテレーションやスプリントと呼ばれる時間は、原則として一度プロジェクトを始めたら固定にするので、今回のスプリントは2週間だけど、次は1か月ということは無い。よく「でもこの機能の開発はスプリントに収まらないし？」とか聞かれることがあるが、そういう場合はストーリーの分割をすれば良い。大きすぎる項目は見積れていないのと同じだし。
手戻りについては、そもそもアジャイルって変化が起こることを想定しているので、機能や要件の漏れがあれば、重要度と照らし合わせて次のスプリントで実施するだけだ。
そのコストはどうするのよ？というのは契約次第だけど。（契約の話は以前書いたので、http://www.ryuzee.com/contents/blog/2932 を参照）

で本当に相性悪いの？

ケースバイケースなんだと思う。

顧客が、システムを「作ること」に価値を置くのか、「作ったものから得られるもの」に価値を置くのか、なんだと思う。
予算主義、丸投げ主義な顧客にはアジャイルは向いていない。あとは意思決定が苦手な組織や縦割り組織にまたがる案件とかもダメ。
こういう顧客の場合、意思決定のロジックがビジネス上の価値と関係が少なく、決めた通りにやることが評価の対象になってしまったりする。
一方で自分達で投資対効果を検討できたり、リリース時期によるビジネス機会の拡大/損失が理解できる顧客の場合は、アジャイルは向いている。

なお残念ながら、「作ること」に価値を置くタイプの顧客の案件をアジャイルでやって失敗したこともある。

参考文献

“[Agile]Agileなプロセスと受託開発は本当に相性が悪いのか？”へ10件のコメントがあります。

• やみびかり 2010/02/13

  [Agile]Agileなプロセスと受託開発は本当に相性が悪いのか？ | Ryuzee.com: http://bit.ly/boVpN9

• NOT 2010/02/13

  と、これを読みながら思った。 Watching: [Agile]Agileなプロセスと受託開発は本当に相性が悪いのか？ | Ryuzee.com http://www.ryuzee.com/contents/blog/3082

• akio yoshikawa 2010/02/13

  [Agile]Agileなプロセスと受託開発は本当に相性が悪いのか？ | Ryuzee.com http://ff.im/-fQTEG

• 1470.netちょっと気になるURL 2010/02/13

  http://bit.ly/dj9yrZ [Agile]Agileなプロセスと受託開発は本当に相性が悪いのか? | Ryuzee.com アジャイル,Trac,オープンソースなどの話。認定スクラムマスター。Twitterは@ryuzee アジャイルって受託開発との相性が最..

• かおるんフィード 2010/02/13

  [B!] [Agile]Agileなプロセスと受託開発は本当に相性が悪いのか？ | Ryuzee.com http://www.ryuzee.com/contents/blog/3082

• carnation 2010/02/13

  [Agile]Agileなプロセスと受託開発は本当に相性が悪いのか？ | Ryuzee.com: Categories Agile・生産性向上 (59)Ajax/Web2.0 (7)apache (14)CMS (3)Delph… http://bit.ly/b1PysZ

• NANBA Toshiaki 2010/02/14

  [Agile]Agileなプロセスと受託開発は本当に相性が悪いのか？ | Ryuzee.com: [Agile]Agileなプロセスと受託開発は本当に相性が悪いのか？ | Ryuzee.comCategories Agile・生… http://bit.ly/dzAg89

• Hirokazu Oyama 2010/02/14

  Now Browsing: [Agile]Agileなプロセスと受託開発は本当に相性が悪いのか？ | Ryuzee.com – http://j.mp/axS2QI

• Mitsuru Takeuchi 2010/02/18

  後で読もう。http://bit.ly/9fZOSF はじめは人がいないからと思ってても、気付いた時には手を動かす力なくなってんじゃないかな。その時にはもう遅いと思うけど。

• あくあーら 2010/02/20

  "予算主義、丸投げ主義な顧客にはアジャイルは向いていない。あとは意思決定が苦手な組織や縦割り組織にまたがる案件とかもダメ。" とか言ったら、日本の中堅以上の企業はほぼ全てアウトな気がするのですが…。 http://bit.ly/bu4qE0

コメントする

Name (required)

Mail (will not be published) (required)

Website

XHTML: 以下のタグが利用可能です: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Trackback