Big Sky

仕様決定、設計、開発、と開発工程を順に落として行くのを一般的にトップダウンと言う。

逆に実装を優先し、仕様を後付けする形をボトムアップと言う。

20代前半は「何故世の中にはトップダウンなんかあるんだ！ボトムアップで十分だろ！」と考え、自分を信じ、トップダウンの意味を知ろうなんて、みじんにも思おうとしなかった。

20代中頃、見積もり、スケジュールまで任されるようになった私は、客先の要求仕様に対して少しばかりの実装調査を実施し、フレームワークを使った短期的な工数、金額、要員を見積もった。

が、それは実際にはフレームワークごときが出来得る処理ではなく、デバイスドライバ、それもかなり低水準な処理が必要となる開発だった。

実際の工程は見積もりとは大きく反れ、予算をオーバーする結果となった。
見積もりの前提事項として、「フレームワークを使用した開発」と書いていた事で、結果、受注先と赤字を折半する事になった。

この失敗は、私にとって今でもトラウマで、その時一緒に客先に謝りに行って貰った事業部長の顔が申し訳なくて見れなかったのもハッキリ覚えています。客先も「仕方ない」とは言ってくれたものの、あれから7～8年経った今でも、消してしまいたい過去だったりします。

ちょうど技術的にも自信が付き、失敗なんか有り得ないと思っていた絶頂の頃合を、思いっきりへし折られた感じですかね。

今から思えば、せめて開発詳細が決定するまでは、客先に足を運び、煮詰め、懸念点も洗い出し、納得してからスケジュールを立てるべきだったと思っています。

「仕様書を書く事」だけが設計じゃない。どれだけイリーガルケースを想定し、客先と話し合うかも「設計」なんだと、この失敗で学びました。

自分の失敗談を、自分のブログに書く事に意味があるのか、と言われれば無いのかもしれないですが、これから上流工程を踏んで行かれる方の脳裏に、少しでもこね記事が記憶として残り、失敗を繰り替えす事が無くなれば…と早朝5時半に目が覚め、携帯を手に取って書き始めました。

別にボトムアップがイケないと言ってる訳ではないのです。開発詳細が要件とマッチしていれば期間短縮やコスト削減も望めます。

楽しいプログラミングを先行してやりたい気持ちも十分に分かります。

この業界は日々刻々と新しい開発手法が登場し、先人の忠告や、過去の経験というものが幾分、重要視されない傾向があります。会議にテレビ会議を使ったりもします。

しかし何年経っても変わらないだろうと言えるのは、客先に足を運び、煮詰める事は、自分にとって、客先にとって、プロジェクトにとってプラスだと言うこと。

特に初期工程では、客先が吐き出し切れていない隠れた仕様が眠っている事が多々あるんです。


交通費は経費で落ちるんです。気分転換に、客先に足を運んでみませんか。