re:愛を込めてソフトウェア開発を語ってみる
愛を込めてソフトウェア開発を語ってみる - サンフランシスコ出羽守手記(masayangの日記
愛ありがとｗ また疑問があったので、ずらずらと書いてみました。
愛とか思いやりとかで解決するような世界なら、アウトソースやオフショアに仕事を出すようなことはしないっての。そこにあるのはとても打算的な投資対効果の判断。取れる所から金は取る。絞るべき所は絞る。優秀な人材は儲かる所に投入し、そうじゃない人材はそれなりの所に突っ込む。企業の目的が利益の最大化である以上、この判断基準を覆すのは困難でしょ。
指摘しているのは上位マネジメントが経営資源をより効率のいい方向に振り向けるということで、成果物を通じて伝える努力を尽くす＝愛、思いやり（もう少し補うと、その「努力を尽くす」原動力、動機、パッションが「愛」であるよ）という事を否定する理由にはなりえないと思う。伝える努力を尽くす事が無意味であるとする根拠としては、納得がいかないな。上位マネジメントに愛を説いても無意味という意味であれば、それはその通りかもしれない。でも、前のエントリで「上位マネジメントは愛を持って会社を経営せよ！」と言っているわけじゃないよ*1。
あと指摘を要約しているところを見てみる。
1. 仕事でやる以上、愛などというものに期待してはいけない
2. 上流と下流を分けるから仕事が楽しくなくなる
3. 上流と下流を分けないAgileは解決策の一つ
２と３は、Agileって開発プロセスの話なので、愛論としては特に言いたい事はないです。Agileプロセスは私も興味あるし、これから浸透してく技法なんだと思うので、そこはがんばってほしいなと。
で、１なんだけど、ちょっと伝わっていないのかな、という感じを受けるんですよ。成果物を通じて伝える努力を尽くす＝愛、思いやりと、前のエントリで書いた。これがAgileだから不要！っていうワケではないと思うんだけどな。逆にAgileプロセスって実践した経験ないので、教えて欲しいぐらい。ということで、Agileプロセスについてきいてみようと思う。
上流と下流を分けるから仕事が楽しくなくなる
中略
お客さんの財布のひもが緩いプロジェクトなら、Rintaさんがいうような判断能力を持っている開発者を押さえることは可能だろうけど、「早く」「安く」と牛丼を頼むがごときのお客さんの場合は「とんでもない」開発者を配置することも覚悟しなければならない。「設計者に確認しないといけない事なのか、自分の裁量で決めていいのか」もわからないレベルね。そして上流設計者は神じゃないから、設計ミスや漏れは当然あるわけ[*1]。Rintaさんがいうようなレベルの開発者ならそこにミスや抜けがあるのはわかるだろうけど、そうじゃない開発者にはミスや抜けの発見は期待できない。自分が言ってる「細かいところ」ってのは、そういう部分も含んでいて、
* 下流工程の人件費をケチるほど、作業指示（設計書）は細かくする必要がある→「間違ってますよ」「抜けてますよ」「わかりません」という反応すらできない開発者を相手にするから。
* 作業指示（設計書）を細かくするほど、設計段階でのミスや抜けが入る可能性は高くなる→設計書は動かない。動かないから机上検証には限界がある。要は作らないとわからない。
* それらのミスや抜けが発覚するのは、下流工程から納品されたものを検証する総合テスト以降である
* その頃になると、対象のコード量は増えているので問題特定と対策にまたまた時間がかかる→デスマーチ
これは私の立てている前提が、今の開発現場では通用しないという指摘だけど、これはプロジェクト管理（財布のヒモという観点では、経営判断とも言える）の失敗のように思える。結局安い人を調達してきても、設計やテストの時の仕事が増えたなら、コスト的に見合わないんじゃないのかな。外工減っても内工が増えるし（下流＝外工、上流＝内工という前提で）、最後はデスマーチに突入するなら、外工の（もちろん内工も）コストも際限なく出て行くわけだし。Agileプロセスがこの解決策だって言っているけど（という事だよね？）、ちょっとそこに疑問がある。Agileプロセスっていうのはプロジェクト管理の失敗（予算過小、人員過小、外注管理粗悪、品質管理粗悪等が上の４点の指摘から読み取れるかな）をケアできるものなの？
* 一度に開発する対象を絞り込む（自分たちはフィーチャ単位でやってる）
* 必ずテストベンチを作る（RailsだとUnit, Functional, そしてIntegration)
* 設計書はなし。コードをもとに議論。
これはAgileが実践している事だけど･･･ うーん、これはウォーターフォールを選択するという事が間違いで、上で書いたような生産性の低い人がいても、この３つのプラクティス（っていうんだっけ？？）を実践すれば部分的にでも解決できるということ？
最初に挙げられている「開発対象の絞込み」は、規模を小さくすることで、多少技術力に難のある人でも大丈夫だよね！という事かな。それホント？ ･･･ああ！
バグ発見・特定・対策にかかる時間が読めなくなる可能性が減るので、下流工程を分離して安い労働力を投入する意味はなくなる。
ああ、なるほど。技術的にしょぼい人達にお願いするまでもなく、元請けでやれます！という事か。
でもね
開発プロジェクトには目標とする納期があって、全体の規模（工数）と納期から、必要な人員を割り出して調達するわけじゃない？ 下流を切って人を減らしちゃうわけだから、目標とする納期は達成できないよね？ 規模（工数）を分解して小さいチームでやるんだ！と言った所で、全体で集めなきゃいけない人の量は減らせないし、開発規模も減らないよ。小回りの効くチームの方が生産性が高いから人が減るという論はあるけど、小回りの効くチームでやれる仕事とやれない仕事があるし、その削減効果に意味のある規模、意味のない規模がある。
もし、それでも「開発プロセスにAgileを選択する」という決断をするなら、「開発対象のシステムをドカンと開発してえいやっと一気に本番にいく方式をやめて、長い期間をかけて少しづつ太らせる方式をとる」というように経営判断を変える必要がある。これはもう開発プロセスの話じゃないじゃない。
Agileがやれるのは、比較的小さい規模（平均で２０〜３０人月５人で半年、最大でも１００人月ぐらいじゃない？）で、ここでなら小回りの効くチームで生産性を上げることで、使えない外注を切っても回るだろうし、期間への影響も比較的少ないと思う。ウォーターフォールの悪い点を指摘して、Agileのいい点ばかりを挙げるのは実は規模のマジックがあると思う。上で書いたような小規模プロジェクトならウォーターフォールでも回るんだよ（回してました）。失敗が報じられるのは１０００人月超とかの大規模プロジェクトで、その規模をやれるのは良くも悪くもウォーターフォールだけだと思う。IBMでもRUPで大規模やったって実績、まだないよね？*2少ないよね？ Agileプロセスが「小規模プロジェクト用」という位置づけから「業界の標準」になっていく為には、もうひとがんばり、IBMにしてもらわないとだめかもね。
ちょっと愛論に戻るけど、愛や思いやりがいらないっていうのは、邪推すると、短期の仕事で付き合いもこれっきりだから、信頼関係とか築いていく精神的投資をする意味なんてないね！というのもあるのかな。似たような事を会社の若手（というか若年寄というか）からもきいたことがある。「せっかく外注の人とも信頼関係築いて、ツーカーまで行っても、上のほうでその人切られたら今まで使った時間は何なの？」と。これはね、そうなる事を理解したうえで仕事をお願いして、技術的ケアをして、人間として好ましい付き合い（たまには飲みに行ってぶっちゃけ話を聞いてあげるとかさ）をしていくしかないんだよ。自分属しているプロジェクトから人が巣立つなら、「よかったね、次もがんばってね。」って言って送り出した方がいいじゃない。えーと、愛論補足終了。
２点目のテストベンチを作るって話だけど、ウォーターフォールでも作るよね（ウォーターフォールでは全部手動でテストをやっている、と思っているならそれは誤解だ。回帰テストも普通にやっている。）。Agileだけの特徴だとは思えないんだけど、これはどう？
３点目の設計書なしは、開発したシステムの保守はどうするの？ 作った後に、直接の担当者がいなくなる事は普通だし、システムを収めた会社が切られて他の会社を入れるなんて事もあるよね。Agileプロセスで作ったものは保守の継続性はいらないって考えているの？ 保守の継続性を一旦棚に上げて考えてみると、ドキュメントを作らないなら「成果物（今は狭義にドキュメントとする）を通じて伝える努力を尽くす」は確かに意味がないね。成果物がないんだから。
上流と下流とで工程を分ければ、その責任境界線を挟んで互いがいがみあう事態になるのは必然ではないかと。Agileは、そうならないための下地を提供してくれている。
諦めるの早すぎるよｗ 前TBしたエントリでも「あまり期待できない。」って切られちゃってるけどさー。そこの諦めが早かったら何やったってうまくいかないと思うけどな。あと、「いがみあう事態は必然」なんだろうか？ ここは「俺のところでは毎日お互いにいがみ合っているよ！」というなら、君のところはそうかもしれない。でも、私のところではそんな日常はなかった。みんなの職場ってそんなに殺伐とした職場なの？
*1:そんなパッションのない経営なんてクソだね！とは思うけどｗ
*2:ごめん、実績あるみたい。The Rational Edge （28）：大規模プロジェクトにアジャイルを適用する方法−1 (3/4) - ITmedia エンタープライズ
