仕様を増やすばかりのえらい人は火種を抱えていることに気づいていない

Software Desine 2005/3 「Pacific Connection Firefoxの教訓」より
---
「僕たちは基本的に、やんわりと断ることにしていた。『オーケー、君のインプットは尊重したいと思うけれど、製品については今日中にトップの5人が結論を出すから』というわけだ。旧来のモデルでは、アイデアと技術的なノウハウがある人なら誰でも、抵抗を受けずに実装できた。けれども、それではソフトウェアは膨らんでいき、上級ユーザでも理解できないような込み入ったインターフェースになってしまう。
他のオープンソース開発チームに僕が示せるベストなアドバイスは－というのも、他の多くのプロジェクトを同じ問題に苛まれているからだけれど－、決定は厳しく下すべしということだ。方針を変更すれば、コミュニティからは最初は反発も出るだろう。けれども、すぐに厚い皮膜ができるし、製品もより良いものになる。」
---

もう１つ、梅田望夫・英語で読むITトレンド Macromediaはいかにしてインターネットに対応したかより
---
詰め込むべき機能のアイデアに対して、テクノロジストのJon Gayがただひちすら「ノー」と言い続けたことがカギだったという話。共感される方も多いのではないかと思う。
---

ソフトウェアというものは、放置していると必ず機能が増えていく。プログラムの中に入れておいても問題ないのに、メンテナンスが楽だからという理由で、データをデータベースから読み込んだり、固定サイズでいいのに、可変長に対応したりする。

また、サービス精神旺盛なプログラマは、より便利になるからという理由で、機能を追加したりすることもあるかもしれない。顧客が便利になるのはいいことである、ということに疑う余地はないが、自分のリソースを注ぎ込んでまでやるべきかどうかのトレードオフについては考慮していない。

責任者は本来であれば、どれだけプログラマのモチベーションが高くても、機能を実装する優先順位を決めて、とにかくソフトウェアをシンプルに保つべきである。責任者自らが率先して機能を追加しようとするのはもっての外だ。

これは、アジャイル開発でいうところのYAGNI（You Aren't Gonna Need It!）なのだが、プログラムレベルの細かい話と思われているのか、あまり重要視されていないような気がする。

ソフトウェアをシンプルに保てるかどうか、というのはそのまま品質に直結する。仕様を決めるのが責任者の仕事なら、仕様を減らすのも責任者の仕事である。どうやったら機能を減らしつつ、アプリケーションの価値を保てるか、ということに力を注がなければならない。

シンプルに保つことに頭を使わずに、便利だから追加する、顧客に言われたから追加する、後で必要になるかもしれないから追加する（最悪！）という責任者の下では、ソフトウェアはいつまでたっても完成しないしバグだらけになるだろう。

この問題は作業しているプログラマでは解決できない問題である。そこに仕様があるから作る、となってしまう。逆に仕様を削る責任者の方が、自分のやりたいことをさせてくれない嫌な上司となってしまうかもしれない。

プログラマに好き勝手にさせる丸投げ責任者では、ソフトウェアは完成に向かっているようで破綻に向かっていてもわからない。かといって、がちがちに仕様を固めて厳格に守らせるような責任者でも駄目である。

大まかに仕様を守りつつ、途中でも必要なところは追加し、必要ないところは切り落としていく、というプロジェクトをドライブする能力が責任者には必要なのである。

なぜ完成まで至らずに終わるプロジェクトが多いのか、貴重な時間を何に費やしているのか、本当に大事なものはなんなのか、もう少し真剣に考えてもいいかもしれない。