吉岡さんのblogより。
件のblogでは、「別々に担当してはいけない」と言っているだけで、「上流工程不要」と言ってるわけではないので注意。また、「ウォーターフォール」の「対抗」としてアジャイルを挙げているわけでもない。ただし、ここに書いてあることを肯定すると、結果的に「上流工程軽視」になるのではいかという危惧がある。
ここでは件の文章をネタにして、非ウォータフォールの代表であるアジャイル開発についての話。
難しいことを抜きにして、「アジャイル開発」の時の設計は柔軟である。つーか、設計の硬直化をいかに避けるかというための手法が、アジャイル開発だと言ってもいいだろう。「だいたい」のところでプロタイプ的に実装し、利用者と検討し、「だいたい」の部分を明確化して行く。そうすれば、「ウォータフォールモデル」のように、なかなか明確化出来ない「要求仕様」を、「えいやっ！」と決めてしまって、結果的に使えない仕様にしてしまうという問題を回避出来る。
「これから作るもの」については、開発者も利用者も未知なのだから、そこを無理やり明確化してポイントを外したものを作るくらいなら、「どうせそんなもんだ」という前提に立ち、程々のところですりあわせする。手戻りとか収束点をどうするんだという問題は発生するが、たいていはこの方が速く収束する。数値解析で言うところの、「直接法」と「反復法」の違い… と言うと、よけいにわからないか^^;
そんなわけで、アジャイル開発をする場合の仕様というのは、確定的ではない。とは言え、「柔軟」ではあるが「流動的」では困る。ちょうど、ジョイントに使う「ゴム」みたいな柔軟さを求めるものだ。
アジャイル開発では、実装から設計へのフィードバックがある。それがアジャイル開発のメリットの源泉だと言っても良い。ところが、これは両刃の剣だ。
設計の変更は、手戻りの元である。「手戻り」とは簡単に言えば「やり直し」だ。やり直しの範囲が限定されている場合、その限定された範囲でやれば良いのだから、「担当者が頑張る」で済む。また、そういった時の工数の増え方は限定的だから、「アジャイルしろ」を最初から作っておくことにすれば、無茶な工数にもならない。
ただし、これは手戻りの範囲が限定的な場合だけだ。手戻りの範囲が大きくなればなる程、工数の増え方は大きくなる。また、全部が一人でやられているわけではなく、他の開発者もいるわけだから、小さい領域での手戻りで終わらなくなった時点で、そういった変更のすりあわせが必要になってしまう。いきなり問題が大きくなってしまうわけだ。
そうなると、カタストロフィ的にアジャイル開発のメリットが失なわれ、デリットが表面化してしまう。「上流設計をどうするか」という会議を開くことになってしまい、利用者から離れたところで「開発会議」を開くことになってしまう。あるいは、今まで調子良く問題なく進んでいた、他の部分を外的要因で設計変更を要求してしまうことも起きかねない。
そういったデメリットを表面化させないためには、
フィードバック範囲の局所化
をせざるをえない。つまり、担当者レベルでの設計変更が、他の担当者に影響が及ばないような設計が必要になる。
これは当然のことながら、やり過ぎると「タテワリにより弊害」を起こす危険がある。硬直化した開発体制になってしまったら、アジャイルにする意味がない。だから、そうならないための方策–たとえば横方向の連携–等が必須である。ただ、それだけにしてしまえば、「いつの間にか全体像まで変わってしまった」ということが起きてしまう。あるいは、「素晴らしい仕様」のために工数が爆発してしまう危険もある。だから、「どこまで動かして良いか」ということは、明確化しておかないといけない。
柔軟な素材を使う場合、骨格がしっかりしていなければ全体が崩れてしまう。クラゲのようなことにならないためには、骨格はしっかり作らなければならない。システム開発における「骨格作り」とは、上流工程に他ならない。
そういったわけで、アジャイル開発における上流工程では、
- しっかりした全体設計(アーキテクチャ)
- アジャイルする範囲の明確化
- 「アジャイルしろ」についての見積り
が必須となる。ここをしっかりさせておかないと、「いつまでたっても仕様(開発)が収束しない」とか「素晴しい仕様だけど予算オーバー」「局所最適化ばかりで全体最適化のされていないシステム」なんてことが起きてしまう。
そうならないためには、結局のところ「上流工程をしっかりやる」ということになる。
ついでに言えば、
下流にいけばいくほど単価のたたきあいになるので経験豊富なベテランを配置することが難しくなり、若年層エンジニアを使いすてることにならざるをえない。いわゆる35歳停年説である。
とかあるのだけど、これは「上流工程」と「下流工程」では、エンジニアに求められることが違うのだからしょうがない。また、上流工程の仕事の一つとして、「下流工程のスキルの差を表面化させないこと」があるわけで、スキルの差が見えなくなってしまえば、単価の叩きあいになるのはしょうがない。それがシステム開発というものである。
「エンジニア使い捨て」とか「35歳定年」とかというのは、本来はそれとは別のことである。また、「上流工程」の上流は「川の上流」の「上流」であって、「上流階級」の「上流」ではない。その辺をごっちゃにして議論を展開するべきではないように思う。