スタートアップにおける開発のアンチパターン:仕様ガッチガチに決める

受託開発を仕様書ベースで外部に発注する場合は、一番最初に仕様をガッチガチに決めて発注することが多い。これは発注側から見ると、必要な要件を満たしているものを作るためで、受ける側から見ると、あとからあれもこれもにならないためである。

翻って内部で開発する場合は、この限りではない。

外注パターンからの推論というか、このパターンが染み付いていて、最初に仕様をガッチガチに決めなければ気が済まないステークホルダーがよくいるので、やめとけっていうメモ。

 

理由①:プログラマーが仕様の意図を理解しないので、実装レベルの改善とかいいアイデアがでなくなる

プログラマー機械語しかよめないと思っているのか、親切なのか、この画面の色は赤で、ボタンを押したらブワーッと下から次の画面が出てきて、とか事細かに仕様を決めちゃう人もよくいるんだけど、実装レベルこそ、意図と連動した実装方法の意思決定をたくさんしなければならないので、意思決定に必要な情報をより多く持っているプログラマーが、意思決定に参加できないという逆転現象が起こってしまう。

 

理由②:プログラマーがコミュニケーションをとらない口実を与えてしまう

プログラマーという職業は、基本的にコーディングしていればお金を稼げる職業であって、仕様書ベースで開発して、その向こう側にユーザの顔も見えないとなってくると、徐々に思考停止になって、改善だの保守性高める実装のいいアイデアだのは出すのが億劫になってくる。

 

まとめると、改善や問題解決の意思決定は実装現場でも(でこそ)行われるべきなので、仕様をガチガチに決めることによって垣根をつくらずに、チーム全体が連動できるようにすることが重要だと思うのである。