Hatena::ブログ(Diary)

GoTheDistance このページをアンテナに追加

2010-02-12

アジャイルって受託開発との相性が最悪な気がする

全くもって、その通りだなぁと思った。

初期段階ですべての意志決定をしても、問題はコードを書き始めてから表れるのです。そして終わりに近い時点で判断する方が、より正しい判断ができるはずです。ですから、できるだけ意志決定は先延ばしにして、正しい意志決定をしようとするのがアジャイルのやり方です。

「有能な人がコードを書くべき」「意志決定はできるだけ先延ばし」「契約を変えるのは難しい」アジャイルの専門家の答え ? Publickey

「ウオーターフォールとは」のラベル貼りの議論になるとめんどくさいから、とりあえず「初期段階ですべての意志決定をしようとするシステム開発の進め方」という定義で話を進めたいと思います。

「要件定義」→「設計」→「実装」→「テスト」という一連の流れがあって、ウオーターフォールなるものは前工程が100になるまでひたすらそこでPDCAを回します。100になると言う意味は、ソフトウェアで担保する機能が確認でき、抜け漏れがないと双方が合意できたことを意味します。この段階で問題になるのはフォントの大きさと罫線のズレとカッコよく見える絵とスペル間違いと日本語が正しいかどうかです。行間が空いていると要件漏れになりますからね。

「仕様変更」の4文字に大変弱く、ひとたびそれが発生すると(以下略

アジャイル

「要件定義」→「設計」→「実装」→「テスト」という一連の流れを100になるまでやるのではなく、分割できる単位に落として、要件からテストまで一気に進めてしまい最終的に100になるというやり方だと認識しています。ソフトウェア開発は「初期段階ですべての意志決定をしても、問題はコードを書き始めてから表れる」のが真理なので、コードを早い段階で書いてしまって問題点を早期に潰していくほうがいいに決まってるのは完全に同意。最初は小さな芽でも、時間の蓄積によって大木になりますからねぇ・・・。仕様変更があっても俊敏だから大丈夫、と。この仮定がだいたい正しいとすると、ソフトの作り方としてアジャイル開発のほうが合理的なのは間違いないでしょう。

でもアジャイルって

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

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

滝には色々問題があるけれど、滝は契約体系としてはわかりやすいし、お金の積み方が合理的に説明しやすいという点はあると思う。リスクマネーが利益の源泉になることが多いしリスク取るからおカネを請求できるわけで、そこが不明瞭で不確かだろうが「○○円でいつまでにやります」とコミットするから契約を結ぶ価値が出てくるわけなんだけど、アジャイル開発のやり方だとどう説明するの?

受託開発との相性が悪そうな理由

アジャイルが上述のやり方だと仮定すると、僕が顧客側にいたらこういう質問をすると思う。

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

何を作るのか見えていないものに対して、「意志決定は先延ばしにして、正しい意志決定をしましょう」っていう哲学を、顧客にどう説明して納得して頂くのだろう。先延ばしにするリスクはウチが負いますからもっとカネくれ、じゃ話にならない・・・。

これってヒトを選ぶ難しいやり方のわりに、だったら初めから納期と予算が決まってる滝のほうが顧客にとってはいいって言う話になるんじゃないだろうか?そうだとすれば、要件定義が一番のコストなんだからその手法を高度化して滝のままで精度を高めましょうという方向を向くことになるし、「要件が決まれば実装は自動生成で可能な限り効率化」ということになりそう。リクツの上ではね。

ただ僕が顧客ならば動くソフトウェアを確認しながらウチの業務プロセスにフィットするかを確かめながら進めたいと強く思うので、そのメリットを価値に変えるストーリーがあればいいと思うんだけど、自分たちの手でシステムを進化させる文化が根付いていない所には「なにそれ?おいしいの?」という響かない提案になると非常に思うので、やっぱ内製だろって思ってしまう今日この頃です。

aa 2010/02/12 17:43 通りすがりです。

アメリカで生まれた文化が何でも日本に合うわけではないという典型のような気がしました。
アメリカには SIer なんて無いんだって話のソースを探して検索したらこちらでしたねw
http://d.hatena.ne.jp/gothedistance/20070920/1190219844

laclefdorlaclefdor 2010/02/13 03:43 そもそも論を言えば、上流工程と下流工程で会社が違うことがおかしいわけだしね。それを是正するには良いんでないの。

a 2010/02/13 11:39 通りすがりその2ですが。
要するに「人を選ぶ」のではなく、「選ばれるレベル未満を対象として含めない」開発モデルだと思っています。
で、日本のユーザが変わらなければ今後もウォーターフォールでしょう。
なぜって、ユーザーが学んでいった結果、企画者たちの思考速度に近い速度で開発ができるスタイルとしてユーザ側の要望に対応すべく出てきたのがアジャイルの開発スタイルです。

つまり、日本のユーザがアジャイルを要望しない限り、アジャイルが流れになるのはASP系やパッケージ開発のスケジュールが自社主導のモノだけになるんじゃないかなと思います。

要するにSIerにまとめ出しするというプロセス自体がネットの速度に対応すべく進化した顧客から否定された結果出てきたのがアジャイル、というだけの話で、儲かるからアジャイルにしたわけではありませんので、そりゃ既存のやり方とマッチするわけはないです。

shivashantishivashanti 2010/02/13 12:48 外部からアジャイル開発する場合は「人月」以外での契約は難しいです。

bb 2010/02/13 15:08 アジャイル開発をアジャイル的に成熟させていくしかないんだと思いますねぇ

katzchangkatzchang 2010/02/14 16:41 書籍「アジャイルな見積りと計画づくり」がお勧めです。

MMMMMM 2011/08/03 17:28 私たちは人月ベースであえて契約しました。そして大変うまくいきましたよ。日本のやり方には合わないといえば、確かにそうですが、それを変えなければ、いつまでたってもうまくいかない気がします。

投稿したコメントは管理者が承認するまで公開されません。

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証