Re: アジャイルって受託開発との相性が最悪な気がする
前書き
現役アジャイラー（？）を自称する立場として釣られてみるぜっ。
http://d.hatena.ne.jp/gothedistance/20100212/1265907956
「アジャイル」について
多分id:gothedistanceもわかっていると思うんですが、アジャイルはマニフェストなんであって具体的な手法ではないです。
代表的なアジャイルとしてeXtreme Programmingモデルを例にとると、イテレーションプランニングって項目があります。
簡単に言うと開発側は2週間ごとに形にしよう、顧客は次の2週間でほしい機能を決めようってやつ。
XPは改訂が多すぎてこの手の文書の参考にしにくいんですが、細かい事はこの辺見てください。
http://www.objectclub.jp/community/XP-jp/xp_relate/whatisxp-j/
今回の記事による「アジャイル」の定義付けは、主にイテレーションモデルに対して行われているように見えますが、イテレーション自体は非アジャイルのRUPなんかでもあるモデルで、アジャイルに限った話じゃないです。いわゆる「反復型開発手法」と呼ばれるもの全般にあります。
ウォーターフォール使いの人にとっては、スパイラルの方が理解しやすいと思うんで、イテレーションをスパイラルに読み替えてくれてもいいです。
もう一度言いますが、イテレーション = アジャイルじゃないです。
アジャイルは「ソフトウェアを早く開発しようぜ」というマニフェストです。
※マニフェストってわかりにくいすよね。アジャイルについては「宣言」という訳が適切な気がするけど。
マイ・アジャイル
先に言っとくとうちはオフショア屋です。
人月10万でやってます。
ベトナムの技術者の力量は正直大分低いんですが、気が向いたら使ってみてください（笑）
そんなのはどうでもよくて、何が言いたいかというと、オフショア特有の事情がありますんでご留意を、ということです。
うち、うちというか今会社ないから俺になるのか、は本当は完全なイテレーションやりたいんですが、イテレーションで予算まで区切ると仰る通り日本の会社との相性がすっごい悪いです。
相性が悪いのは日本の会社だけじゃなくて、入札型の案件全てと相性が悪いです。
予算をはじめに決める案件との相性が悪いということですね。
で、実際にこちらで運用しているアジャイルはどういうのかっていうと、イテレーション使ってないです。
単純に最低2週間に1回成果物をリリースするというもの。テスト中とか、切羽詰っているものだともっと短い間隔でリリースしますけどね。
ウォーターフォールの分割リリースモデルって呼んでます。
この話で予想される反論は「それってアジャイルじゃないんじゃないの？」って話なんですが、ウォーターフォールってのがなんで設計工程とかで大量の時間を割かないといけないかっていうと、中間リリースが無いからなんですよ。
ソフトウェアの成果物が最後の最後まで見えない。
だからこそ設計書はしっかり書く必要があるし、そのレビューもちゃんとやって「設計工程」を100％にする必要があるんです。
うちのやり方はそこを省くから設計工程は全体の10％程度で終わるようにしてます。
最低2週間に1回リリースがあるから現場は毎週緊張感があります。
ウォーターフォールはリリースが無いから、リリース直前の追い込みなるものが発生して、つまり最後に追い込まないといけないほどタスクの先延ばしをしがちなんですが、このモデルは実際に現在の進捗をプログラムレベルでお客さんに見られてしまうので、まあさぼれません。
プログラム主体の開発、開発に集中するための開発、て事でアジャイルに入ってるつもりです。
アジャイル宣言についてはこのあたり見てください。
http://www.ogis-ri.co.jp/otc/hiroba/technical/IntroASDooSquare/chapter1/IntroASDooSquareApr2005.html
下記を重視した上で、日本向けにカスタマイズしたアジャイルモデルて事です。
- 分かりやすいドキュメントよりも動くソフトウェア
- 契約上の駆け引きよりも顧客とのコラボレーション
先に言ったように本当はお客さんにももっとイテレーションを理解してもらって、まあせめて1ヶ月に1回くらい予算検討や要件の見直しをしてほしいんですが、現状の日本では無理。
それは当たってます。
あ、ついでなんで予算についてのメリット説明しときます。
ウォーターフォールでの受託開発の見積もりって、妥当な金額の1.5倍で見積もるのがセオリーだと言われてると思いますが、その50％分は何かっていうとバッファです。
このバッファがあるから受託開発の見積もりは高くなるので、偽装請負がはびこるんです。
イテレーションは細かい単位で予算を組むからバッファ不要です。トータルでは安くなると思うんですけどね。
でも今はご推察の通り無理です。
皆様そんなに何度も発注書切れないというか、切りたくないというか、発注書一枚じゃないと危険だと思われているというか。
あと上流・下流の分断が難しいって話。これは予算の概念を除けば出来ます。全体スケジュールで、基本設計書リリースとかが決まってるとどうしようもないですけどね。
要は予算決定をアジャイルと捉えるかどうか次第です。
id:gothedistanceの言うアジャイルが、イテレーションで予算も決めるって事だけ指してるならすいません。
反論とか
今までは前振りで、俺が気になったのはここなんですよね。
え、俺聞かれてるんじゃない？とか勘違いしてみた。
- 最終的なリリース日はいつになるの？
- 意思決定を延ばすってどういうことなの？
- ウチはこの予算でいつまでにやって欲しいんだけど、それ守れるの？
- イテレーションって毎回納期もスケジュールも違うの？
- そのやり方でウチにメリットあるの？上に説明しにくいよそれ。
- ある機能の開発中、別の機能に要件漏れがあったらどうなるの？
- Aという機能を要件→テストまで回してOKだとする。
- でもBという機能の実装中にAの変更が必要なのが発覚した。
- これどうすんの？手戻りして直してくれるの？
一個ずつ行こうか。
最終的なリリース日はいつになるの？
イテレーション使わないなら最終的なリリース日は固定です。
意思決定を延ばすってどういうことなの？
すいません、これは質問がわかんないです。
ウチはこの予算でいつまでにやって欲しいんだけど、それ守れるの？
予算は動的にしてほしいんですが、予算固定 + アジャイルなら全体はウォーターフォールにしつつ、リリースを分割にして設計工程減レビュー工程増の分割リリースモデルなんてどうでしょう。
イテレーションって毎回納期もスケジュールも違うの？
分割リリースの場合は一応、はじめにリリース計画は出します。
状況によって今週と来週のリリースを入れ替えたい等相談はさせていただきますが、最終的なマイルストーンに変化はありません。
そのやり方でウチにメリットあるの？上に説明しにくいよそれ。
プログラムが見れます。
設計書ベースでの完璧な仕様策定と、テスト仕様書ベースで完璧なテストを期待するなら他所様使った方がいいと思います。
うちはオフショア屋なので、怪しい日本語の設計書しか出せないって事情もありますので。。
ある機能の開発中、別の機能に要件漏れがあったらどうなるの？
要件漏れならウォーターフォールでも別予算では。
とはいえ多分ここで聞きたいのってそうではなく設計書を直すだけなら簡単だけど、実装までしちゃって直すのだとコストが嵩むんでないかという話ですかね。
Aという機能を要件→テストまで回してOKだとする。
でもBという機能の実装中にAの変更が必要なのが発覚した。
これどうすんの？手戻りして直してくれるの？
えっと、はっきり言ってテスト駆動開発とか採用してないと、手戻り出るのはきついです。
じゃあテスト駆動でやればいいじゃんという話もあるかと思うのですが、テスト駆動でやるにはメンバーの力量が全員詳細設計まで出来るレベルじゃないと無理です。
やりたいんですが、現状のベトナム人エンジニアの技術レベルから言って通常工数では無理で、じゃあその分の工数上乗せしようとするとウォーターフォールのバッファ50％上乗せ、て話と同じ感じになって意味が無いのでやってません。
ということでテスト駆動とかやってないと工数嵩みます。
オフショア特有の問題があって、設計書を直す = 日本人工数、プログラムを直す = ベトナム人工数なんで、うちの場合は工数嵩むけどコスト安くなるんですが。
とはいえ日本の会社さんでアジャイル導入してるところってテスト駆動出来ると思うんで、テスト駆動ならデグレ防止がある程度しやすいから設計書直すよりコスト安いかっていうと正直微妙なんですが、気になるほど高くはならないんじゃないですかね。
うちの事情
うちはオフショア屋なんで、単一民族でやれる日本国内の開発と違い、日本で作られる外部設計書程度じゃ認識の相違を埋められないって問題があったりします。
ということでうちはアジャイル推奨なんですが、日本国内なら別にウォーターフォールでやってもいいんじゃないの、とは思いますね。
設計書で認識統一できるし、顧客のレビュー漏れを「設計書にこう書いてありますので仕様です」って言えて防壁にもなりますしね*1。
とはいえこの前、たかがログ集計ツールで設計だけ延々3週間くらいやらされた時は発狂しそうになったなぁ。
C#でテストプログラム書いたら1日で終わったレベルのソフト。
どうでもいいけど簡単なんだから早く作ろうぜ、とか思っちゃう。
やってもいいとは思うけど、俺は日本国内でもアジャイル型のが好きです。ドキュメント嫌い。
20100213追記、はてぶコメントへのレス
いまいち慣れてないけど一応反応します。
けど、スコープ、納期、予算が固定ってこと？
分割リリースですよね。納期と予算は固定です。スコープは正しく理解できているか自信ないので控えます。
要はアジャイル特有の仕変への柔軟性を放棄してるんじゃないのという指摘ですよね？
基本的には仰る通りで、前述2点が固定である以上、出来るのはせいぜい微調整に限られます。
後は顧客の判断で、○○の機能を作るより○○を良くしよう、等リリース内容を見て判断するかどうかに依存します。
ペアプロの失敗談を聞きたいな
日本の実用例じゃないと意味がないと思うので当面書かないです。
結果だけいえば構築速度が遅いしナビゲータが飽きてさぼる上、コードの共同所有が出来てませんでした。
駄目駄目だったという事です。
そ、それは…もしや…３次オンの昔からどこのSIerでも定石だった多段階リリースでは…。
すいません、知らないです。類似手法はおそらくたくさんあると思います。
設計工程を全体の10％に減らしてリリースとレビュー増やしているだけなんで。
この記事への追記はこの辺でやめておきます。
Hot entryへの便乗の形で失礼しました。
