井上 研一 アジャイルと受託開発は相性が悪い。GoTheDistanceさんが言うとそれっぽいんだけど、でも、それってSIerの中ではずっと言われてきたことだよね。少なくとも、私が3年前まで勤めていた会社ではそうだった。「今の時代、アジャイルが云々」と言うと、すかさず上司やら先輩に、「で、どういう契約をするの？」と突っ込まれる。こちらも、いやだから、イテレーション開発で云々とやり返すのだが、「うちのお客さんじゃなぁ」と話は平行線をだどる。
で、落ち着いたのはフレームワークを作るとか、アーキテクチャベースラインを作るといって、プロジェクトのかなり最初からプログラミングフェーズを入れて、要件が固まってきたら機能を一本一本、アーキテクチャベースラインの上に作り上げていくという方法。契約はそれまでのまま。
まぁ、それってイテレーション開発ではあるけど、アジャイルじゃないか・・・。
さすがGoTheDistanceさんだけあって、はてブが結構なことになっている。コメントを見てみると、「あとで読む」が多いんだけど、「アジャイルと受託開発の相性が悪いのではなくて、アジャイルと日本のSIの契約慣習の相性が悪いんだ」という人もいるし、「やっぱり内製だ」というGoTheDistanceさんと同じ結論を導き出している人もいる。
私自身としても、アジャイルをやるなら準委任、出来るだけ内製に近い方法でやるべきだと思ってます。はい。
ところで、私にとっては、下記の言及の方がドキッとした。その発想はなかった。
滝には色々問題があるけれど、滝は契約体系としてはわかりやすいし、お金の積み方が合理的に説明しやすいという点はあると思う。リスクマネーが利益の源泉になることが多いしリスク取るからおカネを請求できるわけで、そこが不明瞭で不確かだろうが｢○○円でいつまでにやります｣とコミットするから契約を結ぶ価値が出てくるわけなんだけど、アジャイル開発のやり方だとどう説明するの？
引用元: アジャイルって受託開発との相性が最悪な気がする – GoTheDistance.
受託開発の見積だと、工数をあらかたはじいた後に、リスクをどれくらい積むか考える。要件が決まらなさそうとか、この技術は使ったことないとか、いろいろなリスクを洗い出して、工数に乗せていく。まぁ、プロジェクトに携わる技術者にとっては、ほぼ使い切ることになるだろう保険。そう思っていた。
一方で、経済学とか財務で投資理論みたいなものを少しかじると、リスクをとってこそのリターンだということが分かる。
で、この2つの「リスク」という言葉と意味を知っていながら、それを結びつけることが出来なかった自分はダメだなぁと思ったのだけど、まぁ、それはいいとして、ここで言っている「リスク」というのは、同じ「リスク」なのだ。リスクとして積んでおいた工数を使い切るつもりなのは良くないのであって、いかにリスク工数を使わずにプロジェクトを乗り切れるか。それがエンジニアやプロジェクトマネジメントの能力なのであって、つまり利益率に直結することになる。
ん～、なんかすっきり。
でも、GoTheDistanceさんがこの記事で言いたいのは、そういうことじゃないし、正しいエンジニアスピリッツ及びビジネスの鉄則としては適正見積の適正利潤であるから、ちょっと悪どい考え方なのかなぁとは思う。