気合の入った返事をどーもありがと！ すいませんねぇ･･･
霧そのうち晴れるでしょ - サンフランシスコ出羽守手記(masayangの日記
図とか入っててすげえええええええええ！ 気合の入ったエントリをありがとうございます。ちょー感謝。
で、またエントリを起こすわけですが、このエントリUPするにあたって、おとついのエントリでネタにした本*1をもう少し読んでいるので、その本に書いてあることが、アジャイルの特徴の一部という理解に基づいて書いてます。「ソレはアジャイルじゃない！」という所もあるかと思うけど、まあ、そこはケント・ベックに免じて許してください。
Agileはプロジェクト管理の失敗をケアできるものなの？
次の質問への答が参考になるはず。失敗とはなにか？も参照のこと。
だめだ、言いたい事が全然わからなかったｗ
自分なりの解釈では、アジャイルをちゃんとやろうとするなら役務契約でやるしかないから、受注企業側にはコストオーバーランが構造的に発生しない。なので、受注側にとってはリスクがすごく少なくなってハッピーになれる仕組みだと思う。ただ、いまどき流行りの社内の人間をどんどん単価の高い仕事に振り向けて、外注つかってイケイケドンドンの成長戦略というのは取れない。それは会社の経営レベルの戦略ってことになるのかな。一括でやるリスクはとらないぜと。
でも、発注側企業の視点では、予定の予算で思っていた成果がでなかった！っていう事は起こりうるよね。それはアジャイルチームがうまく機能しなかった時にはそうなる。下の方でウォーターフォールがけちょんけちょんにやられてるけど、アジャイルだって成功が担保されてるわけないじゃないｗ うまくいかないチームは結局うまくいかないんだ。それは開発プロセスの問題じゃないよ。
少人数のイタレーションでプロジェクトをまわしてくAgileでは大規模に対応できないのでは？
アジャイルが優れているのは、不要不急の機能の実装をぎりぎりまで後回しにすることで、効率を高める点にあるということは、その通りだと思う。でも、ウォーターフォールとの比較で、そこの優位性を主張する為に次の前提を置いている。
* 全く使われない要件（フィーチャ）
* ほとんど使われない要件（フィーチャ）
* 使われるのは確かだけど、納期時点では不要な要件（フィーチャ）
* それらを網羅して膨れ上がった文書類（要件定義、各種設計書）
* 重複冗長だらけのコード
* その重複冗長だらけのコードをテストするための文書類やコード
* 上記一式の値段と納期を決める契約までの儀式
ウォーターフォールプロジェクトがこれらの間違いを犯しているという前提があってはじめてアジャイルが優れているというなら、なんだか脆弱な仮定の上に築かれた説明だなと、おもっちゃう。失敗したプロジェクトには、これらの間違いが一杯含まれていたのは確かだと思うけど、すべてのウォーターフォールプロジェクトがすべからくこれらの間違いを犯すというのは、仮定でしかないじゃない。「ウォーターフォールがこれらの間違いを起こした時、アジャイルの方が有利だ」なんて、ウォーターフォールを否定することでしか、アジャイルのよさを説明できないの？ それに、５項目目と最後の項目を除いたすべてが、最初の項目に依存していたり言い換えただけじゃない。７項目あるように見えるけど、実質３項目しかない。
最初の項目についてだけど、ウォーターフォールは長年使われてきた手法だからそれを使う組織にもノウハウが蓄積しているので(後記入)、「全く使われない要件」なんかはそうそう入ったりしないもんだよ。経験値の少ない人が誰のフォローも受けずに初めての業種で要件定義すれば、そりゃいっぱい間違うよ。だから、プロジェクトの立ち上げ・最上流の部分はベテランをあてがうじゃない。それができないとすれば、それはウォーターフォールの問題じゃなくて、人のアサインを間違ったプロジェクト管理の問題だと思うな。同じ不幸がアジャイルチームにも起こったらやっぱり同じ事になるんじゃない？ 「使えない人」が顧客側の代表としてチームに配属されて、その人が書いたテストコードが役に立たなかったら、やっぱりそれは「全く使われない要件」になっちゃうんだよ。
５番目の項目、「重複冗長だらけのコード」だけど、これはアジャイルがリファクタリングと回帰テストを仕組みとして持っているから、何回か開発サイクルが回れば、いずれコードは最適化されるという点で優れていると思う。ウォーターフォールでは単体テストが終わっちゃうとリファクタリングはやれないからな･･･
最後の項目は受託から役務に契約形態を変えることでよりシンプルな契約形態になるよ、という点では納得。でも役務は発注側企業にとって成果が約束されない契約だから、そのリスクを受け入れないといけない。一方的に役務○、受託×とは言い切れない。一長一短ってところじゃない？
私が感じたアジャイルがウォーターフォールより優れている肝の部分っていうのは、顧客と一体になった役務型の仕事のやり方にあると思う。アジャイルを実践するには一定の成果と対価としての金額を最初に合意する一括受託型ではだめで、一定の人を一定の期間雇って出てきた成果を受け入れる役務型にするしかない。そして、役務で働くチームに、顧客（利用者）の何人かを置く（んだよね？XPの本にはそう書いてあったけど。）ことで、常に受入検収（インテグレーションテスト）ができる体制にする。これで週なり月なり、その時点での最良の成果を検収・リリースしていくってスタイルで、このサイクルを契約期間でやっていく。これは役務だからできる働き方で、ここがアジャイルとウォーターフォールを分ける肝の所なんじゃないのかな。
アジャイルにはいろいろいい所もあるけど、顧客を選ぶよね。顧客（利用者）に検収の為のテストコードを書く人が必要になるし、小さく組み立てて大きくしていくっていう成果の上がり方を受け入れないといけない。一括受託契約の代わりに役務契約を結ばないといけない。でも、これらの事を受け入れられるなら、高い労働生産性（これはウォーターフォールが失敗するから、ではなくて、工数の投入速度が緩やかになること＋時間の経過とともに習熟度も上がって労働生産性があがるから。）や、少ないシステム投資リスク（一括でボンと出すより、毎月いくらで精算する役務の方が財務的に安定。チームも小規模なので毎月の負担も少ない。）っていう恩恵が受けられる。受注する側にとっても、一括ってすごくリスキーで恐ろしい契約形態だから、そこを役務でいいってなれば、受注側の経営も安定するしメリットがあるね。
アジャイルが適用できる場面では、アジャイルでやった方が開発者も顧客もハッピーになれると思う。でも、一番の難関は顧客がアジャイルを受け入れられるかどうかだと思うな。そこは少しづつ実績を積んで、啓蒙活動をしていくしかないんだと思う。あとは、会社組織として、アジャイルチームをどう編成するかとかも、細かい所では揉めるんじゃないかな。発注企業に受注企業から出向扱いにするとか、共同出資で別会社立てるとか、スキームは色々あるけど、まあ、試行錯誤していくしかないのかな。１００％利用者企業の自社の人間で固めるのが、一番ハッピーだと思うけどね！ いわゆる内製。
で、結局大規模はやれんのか？って疑問については、実績としてロッキードのやつが上がっていたけど、ちょっと読むのに時間かかりそう；； これは少しづつ実績があがっていって、いつかは大規模も普通の人でやれますよっていう事になるんだと思う（ロッキードのアジャイルチームは天才の集団でしょ？ これを一般化するのは、難しいんじゃない？）。まあ、今後に期待。実際問題、少なくとも今後２−３年以内に立ち上がる都銀や証券、官公庁なんかの大規模プロジェクトはウォーターフォールのお世話になるしかないと思うな。んー、あと法制度関連の制度対応なんかは、一括（ウォーターフォール）の方が向いていると思う。「住民税変えます。平成２０年４月１日施行！」とか、完璧に日限切られたら、成果約束してくれないと発注できないもの。一括型でもアジャイルで回す工夫が、いづれ発明されるんだろうな。
テストベンチはAgileだけの特徴ではないよね？
もちろん、ウォーターフォールでもテストベンチは使える。ただし、上にも書いたけど使いもしない機能や冗長重複だらけのコードにテストベンチをあてがうのは苦痛以外のなにものでもないはずだ。それを苦痛を思わないのならテスト漏れがあると思ってよい。[*2]
これもウォーターフォールがいろいろの失敗をした時っていう仮定の上に乗っかった話だよね。「はずだ」だし。
アジャイルとウォーターフォールの２つの開発プロセスでテストベンチに違いがでるとしたら、インテグレーションテストのテストコードを顧客が作るという点じゃないかな。個人的にはここにすごく期待していて、開発の現場としてはありがたい所だと思う。顧客の要望とかいろいろ漏れがないようにしても、結局ダメ出し食らってあれこれ直すしかないなんて、普通にある*2。でも、最初にインテグレーションテストのコードが出来上がっていれば、開発者で実行して確認することができる。そのテストコードの実行結果をもって検収してくれるなら、本当に助かると思う。
悲しいのは、ちゃんとしたインテグレーションテストを書けない人が顧客（利用者）サイドとして着任した場合かな。「テストコードがミスっていたよ。やっぱりこうして！」って言われたら、やるしかないしね。これは人のスキルに依存するところで、どんな開発プロセスをやってみても、いつまでも悩み続ける所なんじゃない？ｗ
設計書なしで保守をどうするの？
苦労は感じてない。特にRails使うようになってからはドキュメントの必要性を本当に感じなくなった。
* フレームワークが強力なので、保守要件を聞けばどこをいじればよいのか直ちに見当がつく。これは後からプロジェクトに参加した人がいても同じ。もちろん、Railsに詳しい必要はあるけど...
* とりあえずいじくってテストをかければ、影響が波及する部分を特定できるむしろ、コード＋テストベンチ＋設計書の３つの同期をとって保守するほうが大変だと思うんだけど？
Rails･･･ そのフレームワークが何をしてくれるのかが分からないので、なんともいえない(´･ω･｀)
保守が大変なのはその通りで、その努力を何のためにするのかというと、システム保守のノウハウを俗属人化させない為です。これはきっとペアプログラミングを通じて、常に複数の人に保守のノウハウが蓄積されるようにすることで「俗属組織化」するのがアジャイルなんだろうと思う。その代償として、組織はシステムが生きている間生き続けないといけない。でもまあ、これはウォーターフォールで開発したシステムについても同じか。
保守を延々と同じチームでやり続けていく前提で、あんまりプログラム寄りの設計書はなくても回るというのはわかる。チームが死に絶えた時は、システムも運命をともにすることになると思うけど、まあ、滅多にそんなことは起こらないんだろうねｗ
結局のところ、ドキュメントが残っていても、保守部門に「生き字引」みたいな人がいないと、保守が難しいっていう現実があるし、人が仕様を覚えているっていう仕組みは、ドキュメントを書いていても、実際には人の記憶を元に動いているのが現実かな。
あと、ドキュメントを残す理由は、コード以外で表現されている仕組みがあるから、かな。たとえば、同じ機能のサーバを５台用意して、水平分散するような仕組みがあったとして、そこで動くコードには「システム全体としては水平分散されていて、サーバを増やす事でスケーラビリティを確保しているよ」という事は表現されないじゃない。全体のスケーラビリティをどうやって確保しているのかとか、障害時は縮退するとかそーゆー全体の部分はドキュメントとして表現するしかないんじゃない？
今の時点でのアジャイル
強力だけど、制約のある開発プロセス*3。最上流の所から「アジャイルで」っていう決定がされていないと、アジャイルを使うことはできない。顧客企業の経営層にその有用性を理解させる、エヴァンジェリストみたいな人がいないと、なかなか浸透していかない、のかな。
で、愛は
私はやっぱり有用だな、と思います！ 結局は人なんだから、チームがうまく回るには思いやりが必要だよｗ
*1:XPエクストリーム・プログラミング入門―ソフトウェア開発の究極の手法
*2:ここのリスクは、プロジェクト管理上リスク費を顧客毎に営業、PM等が経験見積もりで計上することでヘッジするのが、うちの社内では一般的。時々オーバーラン、時々ショート。全体的にはトントンってとこかな。以上後記入。
*3:契約の仕方にまで跳ねるんだから、ビジネススキームと呼んだ方が適切かもしれない。以上後記入。
