愛を込めてソフトウェア開発を語ってみる

Rintaさんからトラックバックをいただいたので、愛を込めて（笑）自分の考え等を書いてみる。

この辺を読んで、まあ、印象なんだけど、愛がないなと。上流工程の担当者と下流工程の担当者でそれぞれ相手の事を憎みあっているというか、「おまえのせいだ！」って言い合っているというか。もっと分かり合おうという発想はないんだろうか？

自分の主張概要

仕事でやる以上、愛などというものに期待してはいけない
上流と下流を分けるから仕事が楽しくなくなる
上流と下流を分けないAgileは解決策の一つ

仕事でやる以上、愛などというものに期待してはいけない

愛とか思いやりとかで解決するような世界なら、アウトソースやオフショアに仕事を出すようなことはしないっての。そこにあるのはとても打算的な投資対効果の判断。取れる所から金は取る。絞るべき所は絞る。優秀な人材は儲かる所に投入し、そうじゃない人材はそれなりの所に突っ込む。企業の目的が利益の最大化である以上、この判断基準を覆すのは困難でしょ。

上流と下流を分けるから仕事が楽しくなくなる

当然、ソフトウェア開発でも利益の最大化のための工夫が成されてきたわけだ。真っ先に「儲からない可能性が高い部分」が特定された。それはバグ探しとバグ対策。そしてバグ対策は実装工程とは切っても切れないから、実装〜単体テスト・デバッグあたりが「儲からない可能性が高い部分」とされた。

１０行のコードの中にあるバグを探すのは（おそらく）比較的簡単で、それに必要な作業量も（たぶん）見積もりやすい。でも、何千行、何万行という単位になると、いくつバグがあるのかもわからなければ、それらを特定して対策するのにどれくらいの時間がかかるのかもわからなくなってくる。そんな工程に高い人件費を投入するのは利益を減らす可能性を高めるだけだから「下流工程」という名の下で、安い人件費を投入できるようにする必要があった。

また、下流工程は作業量の増減が激しいから、配置人員を流動的にする必要があった。正社員配置ではそんなことは無理だから、必然的に下流工程は外注に任せるようになった。

その下流工程に任せる仕事を特定するのが上流工程。「設計書」なるもので下流工程に仕事を指示するわけね。

内的な要素については、外的な要素が満足されていてなおかつ、上流の設計書に特別な指示がない限り、プログラマの裁量に任せられると思う。そここそがプログラマの仕事で、仕様化することの難しい効率性や応答性といった品質要件をクリアしていく為にテクニックを駆使していくところだと思う（RDBの表の構造とかはもう一個上ぐらいできめちゃうけど）。
でも、外的な要素。業務要件に直結するような内容だけど「細かいところ」は、自分で決めちゃいけないんだ。そこが「これは設計者に確認しないといけない事なのか、自分の裁量で決めていいのか。」という判定を下す能力が問われているんだと思う。

お客さんの財布のひもが緩いプロジェクトなら、Rintaさんがいうような判断能力を持っている開発者を押さえることは可能だろうけど、「早く」「安く」と牛丼を頼むがごときのお客さんの場合は「とんでもない」開発者を配置することも覚悟しなければならない。「設計者に確認しないといけない事なのか、自分の裁量で決めていいのか」もわからないレベルね。

そして上流設計者は神じゃないから、設計ミスや漏れは当然あるわけ[*1]。Rintaさんがいうようなレベルの開発者ならそこにミスや抜けがあるのはわかるだろうけど、そうじゃない開発者にはミスや抜けの発見は期待できない。自分が言ってる「細かいところ」ってのは、そういう部分も含んでいて、

下流工程の人件費をケチるほど、作業指示（設計書）は細かくする必要がある→「間違ってますよ」「抜けてますよ」「わかりません」という反応すらできない開発者を相手にするから。
作業指示（設計書）を細かくするほど、設計段階でのミスや抜けが入る可能性は高くなる→設計書は動かない。動かないから机上検証には限界がある。要は作らないとわからない。
それらのミスや抜けが発覚するのは、下流工程から納品されたものを検証する総合テスト以降である
その頃になると、対象のコード量は増えているので問題特定と対策にまたまた時間がかかる→デスマーチ

と、楽しくない仕事場の典型になってしまう。

上流と下流を分けないAgileは解決策の一つ

Agileの場合、バグ探しとバグ対策は「儲からない工程」とはならない。

一度に開発する対象を絞り込む（自分たちはフィーチャ単位でやってる）
必ずテストベンチを作る（RailsだとUnit, Functional, そしてIntegration)
設計書はなし。コードをもとに議論。

テストベンチを作り込むという手間はかかるが、年がら年中テストを回すようにすることでバグが埋め込まれる可能性を軽減できるし、仮にバグが埋め込まれても早期に発見できるようになる。バグ発見・特定・対策にかかる時間が読めなくなる可能性が減るので、下流工程を分離して安い労働力を投入する意味はなくなる。上流・下流という壁がなくなるから、開発チーム全体で要件（フィーチャ）を吟味し、設計＝実装を進めていくことが可能になる。設計書としてどこまで記述するべきか、などというくだらない議論からも解放される。

もっと分かり合おうという発想はないんだろうか？

上流と下流とで工程を分ければ、その責任境界線を挟んで互いがいがみあう事態になるのは必然ではないかと。Agileは、そうならないための下地を提供してくれている。

参考リンク

http://d.hatena.ne.jp/masayang/20070402/1175584867
http://d.hatena.ne.jp/masayang/20070328/1175114317

*1:自分で実装できないものをどうやって設計しているのかという大問題もあるしね