ちわさんぽ at Malaysia Kuala Lumpur

マレーシアでSIMPLE RICHな生活

ウォーターフォールとアジャイル。どっちもやってみたけど、やっぱり現場による、としか言いようがない。

最近のはてなブログで話題のトピック。

blog.hatena.ne.jp

 

久しぶりのIT女子らしい話題ですね。笑

 

私は、今までながいこと開発現場で仕事をしてきて、アジャイルもウォーターフォールもどちらも経験しています。

 

この、アジャイルか、ウォーターフォールか、というのは、もう何年も前から話題になっていて、いろんなフレームワークやツールがアジャイル開発をするなら使いやすい、って感じになっているのに、依然として、私が携わっている開発現場はウォーターフォールのまんまなところが大半です。

f:id:chocolatecoffee:20160623164810j:plain

アジャイルはサービスを展開している企業内部で使うとうまくいく

両方やってみて思うのは、やっぱりアジャイルで、請負契約って、うまくいかない、っていうこと。

例えば、はてなみたいにサービスを展開していて、はてなの中に開発チームがあって、このサービスを向上させていこう、という場合。

アジャイルって最高のツールです。

スクラムがあって、みんなでスプリントミーティングして、工数を割り振って、リリース判断して・・・というように。

 

アジャイルは、ユーザーの意見を反映しやすく、ウォーターフォールに比べて、思い描くシステムに近いものを作れると思います。

特に上層部のお偉いさんの方々は、なかなか、紙芝居でシステムを見せられても、それを動かしてみるまで、システムのイメージがつかみにくく、とりあえず動くものができて、あーだこーだ言えるアジャイルは、そういう方々には、いいものです。

 

ただ、細かい変更をしては、デプロイを繰り返すので、私が参画していた案件では、変更を加えたときに負荷テストまではし切れておらず、のちにデータのオーバーフローでレスポンスが返ってこなくなり、システムをしばらく停止せざるを得ないような大きな事故を起こしてしまいました。

デプロイしてすぐに発生した事故はすぐに戻せばいいのだけれど、こういう時間をおいて発生したトラブルはどうやって、システム停止をしないで修正するのか、こういうのは、もうちょっとアジャイルを極めないとわからないのかもしれません。。

 

私のアジャイル経験は数年しかないので、まだまだ分からないところだらけだけど、ちょっとやってみた感想は、「請負ではつらいな」というところでしょうか。

 

ちなみに私がアジャイル開発をしていたときは、この本を参考にしていました。 

SCRUM BOOT CAMP THE BOOK

SCRUM BOOT CAMP THE BOOK

 

 

請負契約はやっぱりウォーターフォール?

で、ここからが本題で。

私は開発会社で働いているので、基本的には請負契約でシステム開発をしています。

そういう時に、アジャイルで契約って、なかなか難しいというか、客先にメリットがあるのはわかるんだけど、開発会社側のメリットが浮かんでこなくて、アジャイルにしたいといわれても二の足を踏む傾向にあります。

客先も、納品されたものが、リリース判断が甘くなることを恐れて、よっぽどはやりものが好き、とか先進的なものにトライしたいという感じでなければ、アジャイルはちょっと・・っと言われることが多いと思っています。

 

開発会社と客先のあいだに、SIerが入っている場合、アジャイル開発はほとんど、無理、といってもいいのではないでしょうか。

とにかく、大手であればあるほど、客先というか客先担当者も、SIerも、開発会社も、リスクは負いたくない。

だから、最初に仕様を決めて、WBSをひいて、お金をはじいて、発注、テスト、納品をする。

決められた契約外のことはしない、ということになるんだと思います。

 

SIerとして仕事をしていたときは、周りに開発ができない人が多いのに驚きました。

それゆえに、客先の求める仕様変更が、工数的にどれくらいの影響度があるのかがさっとわからないのです。

テーブル構成すら把握してないから、ここを変えると、何画面修正が入って、テストがここまで終わっているから、個々はやり直し、・・・とかがわからなくて、確認しますのオンパレード。

これで、アジャイルをしろ、というのは無理がありますよね。

開発会社も大手のところだったので、PMに聞いても、PMが他の開発案件も掛け持ちだったりして、そこまで細かいことを把握してない。

担当者に確認します・・となって・・・。

もっと言えば、開発途中に、客先の担当が転勤で変わってしまったり、SIerの担当が変更になったりすることもあります。

 

まあ、こんな感じだから、ウォーターフォールでもトラブるんですが、もっと風通しのいい、開発元のキーマンと開発者が直接話せるような現場だったら、受発注の問題さえ解決できれば、アジャイルもありなのでは。と思います。

 

今はアジャイル開発をしても、意思疎通がしやすかったり、スプリントの進捗が見やすかったり、バグを一元管理したり、単体や結合テストが自動化できたりする時代なので、それぞれのITリテラシーが高ければ、フレームワークやGitやRedmineみたいなツールを上手に使って、いろんな情報がすぐにわかるようになっています。

 

アジャイルができる環境なら、するに越したことはないし、お金さえ、惜しまないのであれば、ウォーターフォールでも、細分化して、アジャイルっぽくするのが、理想のシステムを作るコツなのかなあ、と思います。

家と一緒で、システムも何回も作って、やっと思い通りのものに近づくといいますしね。

 

まあ、でも開発者としては、できれば一つ終わって、ほっとしておいしいビールが飲みたいので、 ウォーターフォールで開発したいなーーーと思います。なんてw