「急がば回れ」 ができないソフトウェア開発
「これが、急がば回れ ということか！？」
私は駅に向かう道を歩いていた。T字路にさしかかったら、横断歩道の手前で信号が赤に変わってしまった。すると私の後ろを歩いていた二人の中学生が、青信号になった左方向の歩道にわたり、その先でもう一度信号をわたって、私が待っている前の歩道に着いて先を進んで行った。なるほど。これが急がば回れか！（ちょっと違う？(^_^;）
■急ぐから回れません
納期が迫っているソフトウェア開発でバグが収束しそうにない。根本的に作り直したほうがいいんじゃないの？ 急がば回れだよ、と内心誰もが思っている。でも言えない。納期を守れないことを前提としたリスケジュールなんて認められないから。
とりあえず納める。その後正式版を出すもののすぐに致命的なバグが発覚。修正してはバグが見つかるというサイクルを繰り返して、結局使えるようになったのはずっと後だった。こんなことなら、あのときに見直して作り直しておけばよかったのに。急がば回れすればよかったのに。そんな経験ってないだろうか。
■ハードウェアの現場とソフトウェアの現場
製品工場や建設現場では、設計が間違っていた、となればリスケとなることが多いだろう。部品がちゃんとできてこないと作れないから。
ソフトウェア開発の現場では、根本的な設計に問題が見つかってもそのまま突っ走ることが多い。最上層のアプリケーションで不具合を吸収することも可能だから。徹夜でがんばればなんとかなったりするから。しかし、無理に突っ走った結果はろくなことにはならないものだ。急がば回れは大切だ。
製品工場や建設現場でも、そのうちに3Dプリンターが普及して小さな部品ならちょこちょこっと作れてしまうようになるかもしれない。もしそうなったとしても、急がば回らないソフトウェア開発の悪しき手法を真似しないでほしいと思う。
ところで、ソリスト・システムもオペレーションMM作戦の開始の当日の朝になってからリビジョンアップされた。急がば回らずに一夜漬けでバグを修正したのだろう。何ごともなければいいが。
いや、何ごともなかったら話が面白くないな！
abekkanでした。