読者です 読者をやめる 読者になる 読者になる

give IT a try

プログラミング、リモートワーク、田舎暮らし、音楽、etc.

芸能人の27時間100kmマラソンとソフトウェア見積り

よもやま話

昨日の晩、ふとテレビをつけると、ちょうどナインティナインの矢部さんが27時間100kmマラソンでゴールする場面が映っていました。
いや〜、すごいですね〜。


何がすごいって、きちんと放送終了直前に100kmを完走できたことです。
ついでにいうと、視聴者を感動させるという演出も見事に成功しています。


これはソフトウェア開発で言うと、事前に定められた仕様(=100km走ること)を、要求通りの納期(=27時間)で納品したようなものですよね。
さらに、品質要求(=視聴者に感動を与えること)までばっちり充たしている感じです。


ソフトウェア開発でここまでうまくいくことって、滅多にない気がします。
たとえば、


『27時間以内に(というかむしろ27時間ぴったりで)フルスクラッチでテトリスを開発せよ。もちろん、バグもなく、パフォーマンスも十分で、さらに美麗なグラフィックも実装した上で。』


みたいなリクエストを100点満点で実現できるプログラマはいったいどれくらいいるでしょうか?


見積り通り、スケジュール通りにプロジェクトを進めるための条件として、「不確実な要素が少ないこと」「制御可能であること」がよく挙げられます。*1


大半のソフトウェア開発は前例のない一発モノなので、不確実なことは多いですし、制御できない問題も頻繁に発生します。
よって、見積り通り、スケジュール通りにプロジェクトを進めるのはかなり困難なことです。


一方、芸能人の27時間100kmマラソンも一見すると「ええっ、本当にできるの??」と不確実で制御不能な印象を受けます。
しかし、あれだけ見積り通り、スケジュール通りな結末を迎えられたということは、おいらたちの想像に反して、かなり確実性が高く、制御可能なプロジェクトであるということが推測されます。


そんなこんなで、普段あまり見ないテレビを見ながら「すげえな〜。ソフトウェア開発も毎回こううまくいけばいいのにな〜。」と一人感心していたおいらなのでした。


P.S.
不確実で制御不能なのがソフトウェア開発の性質であるがゆえに、ウォーターフォール開発は失敗しやすいわけですね。
アジャイル開発の見積りやスケジュール作りは無理に確実性を上げたり、プロジェクトを制御可能にしようとしていないのが興味深いところです。

*1:コンテキスト的にまとまらなかったのでここでは挙げていませんが、製造業なんかでは「繰り返し可能であること」も条件に加えられたりします。