いい無駄わるい無駄、いい失敗わるい失敗

ソフトウェア開発、特に受託して開発するような場合は、無駄の連続である。無駄を排除して効率よくしようとすると、なぜか無駄が多くなるという矛盾がある。なぜだろうか。

机上でソフトウェア開発を考える人（要するにあまり実経験のない人）は、顧客のニーズを最初に「ちゃんと」引き出して、「ちゃんと」確定できれば、作る際に無駄はないし、非常に効率的だと考えるのである。まさに理想論なのだが、根本的な問題として、顧客は見たこともないものを「ちゃんと」決めるのは無理なのである。

ハードウェアはまずモックアップを作って、ぱっと見を検証する。原寸大の大きさが無理な場合は、ミニチュアモデルを作る。これを無駄という人はあまりいないと思う。実物を作る事が確立されているからという理由もあるが、実際に作り始めてからイメージと違った場合のコストを考えるとよっぽど安いのである。いい無駄と言えるだろう。

それに引き換えソフトウェア開発では、試行錯誤のプロセスを無駄と考えて、とにかく早く後の工程に進みたがる傾向にあるように思う。仕様が確定しようがしまいが、顧客に不満があれば最後にどんでん返しが待っている。無駄を排除して効率よく進んだ先には、最大の無駄があるかもしれない。

たしかに一度動かしてから直すというのは、ある意味コストが２倍、３倍とかかるようにも思えるが、落ち着いて考えると、コスト＝時間なのであり、仕様を決めるのにぐだぐだ長い時間をかけるのであれば、その分さくっと仕様を決めて２回、３回やり直した方が、同じ実時間で完成度は数倍高くなることは間違いない。

最初に無駄な過程を踏んで、顧客と開発側がお互いに仕様確定のやり取りの中で失敗を繰り返すことにより、両者が今回のプロジェクトについて精通し、最終的な成功へ繋がるのが本当の理想系の開発モデルかなという気がする。XPを始めアジャイル開発も、無駄と失敗を積み上げながら進める開発モデルのようである。

失敗を繰り返すことについて、設計者の発言－「As-is先行」か「To-be先行」か のコメント欄から引用
---
最終的に相手に気に入ってもらった「描かれた目」と相手の「目に関する発言」の間にある「因果関係」は相手にしかわかりません。気に入ってもらうまで、山ほど失敗を繰り返さねばなりませんが、そのときに必要なのが「似てないならアカラサマに似てないとわかるような図法」で、ＤＦＤやＥＲＤやパネルイメージはそのために適しています。高速に、サルのように失敗を繰り返す。これがカギです。
---
とあるが、いい無駄、いい失敗をうまく表現されている。顧客が決めるまで動かないではなくて、顧客が反応するまで動きつづけることで、真のニーズを探るというような形容がピッタリ来る気がする。

まとめると、無駄や失敗を繰り返す事で、ソフトウェア開発が成功に導かれる確率が高まる。それはいい無駄でありいい失敗である。逆に、最初に無駄や失敗を極力避けようとすると、ソフトウェア開発が失敗する確率が高まる。それはプロジェクトそのものが悪い無駄になり悪い失敗になる。最初が順調なプロジェクトほど疑ってかかった方がいいのかもしれないですね。