最近携わってきた、幾つかのプロジェクトの状況から微妙な焦りというか、危機感みたいなものを感じています。言語仕様が進化して、開発工数は大幅に削減される筈なのに、なぜみんなﾋｰｺﾗ言いながら仕事してるんだろう？
思うに、多くのシステム屋さんでは、設計の進め方、もっと言えば、要件定義、はたまた営業あたりまで遡ってしまうかもなんですが、兎に角製造の前段階で破綻しちゃってるケースが目に余る、耳に余るという印象です。
というわけで、理想の設計を目指したスタディメモみたいなことをしばらく続けてみようかと思います。

今回は、前振り。

まず、究極の設計とは・・・

１．仕様書なんか書くな！
２．システム開発業者は、「仕様書の厚さ＝受注額」の既成概念を打ち捨てよ！

以上。


そもそも仕様書、設計書とは、以下の目的で作られるものだと考えます。
・製造着手前に、ユーザーに仕様確認をとる。
・プログラマーにプログラミングの仕方を導く、チームの意思統一を図る。
・後のメンテナンスや仕様変更時のために現状の仕様をドキュメントで保存しておく。

前回の記事へのコメントで、OGiさんが、「良い仕様書を作成すればプログラム作成は本当に楽ですし、バグも減ると思います。」と書かれてましたが、それはその通りです。
技術者一人だけでシコシコと作り上げるケースならまだ良いのですが、数人～数十人がそのプロジェクトに係わるようになると、各々が勝手に自分のやり方で作るわけにはいきませんから、ある程度のドキュメントは必要になってきます。

加えて、多くのシステム屋さんは「仕様書1枚あたり幾ら」という感覚が染み付いたまま、その伝統からなかなか抜け切っていないので、仕様書は要求定義書、外部設計書、詳細設計書・・と数種類、それぞれかなり丁寧に書かれ、分厚くなります。

丁寧に書かれるのは良いことですし、優秀な技術者が書いた仕様書があれば、プログラマーはその仕様書に書かれた通りにプログラミングするだけでOK。
仕様書に書かれている日本語の文章が、完璧なプログラミングそのものって感じですから。

ただ、当たり前のことですが、仕様書を書く技術者一人一人に癖があるし、必ずしも良い仕様書を書ける人ばかりではない。
技術的にも人物的にも優秀であっても、書くのは苦手という人も多くいます。
つまり、仕様書の品質が均一化できないのです。会社という組織であればあるほど、均一化は不可能に近づきます。

あまり、よろしくない仕様書は、製造工程でプログラミングを行う技術者たちに誤った情報を伝えるし、迷いも生じさせてしまう。
製造工程に携わる技術者の中には、自分のプライドを強く持った人もいますから、「こんなプログラミング、できるかいっ！！」とへそを曲げて、チームのモチベーションが下がってしまうケースもあります。
また、製造が終わってテスト段階になると尚更です。テストを行う人たちが、その製造物が仕様書通りなのか間違っているのかの判断に困り、プロジェクトの遅れは益々増大していきます・・・

仕様書なんて、そんな程度のものでしかないのです。


だったら、初めからなくしてしまえ！！


じゃあ一体、どうするの？

その疑問を解決するために、この記事のシリーズでは皆さんと一緒にあーだこーだと勉強しながら、究極の設計について考えていきたいと思います。

どれだけ読まれているのか判りませんが、技術者さんたちからのコメント大歓迎いたします。

コメントがなくても、細々と続けていきますが・・・

コメント追加

このエントリーのトラックバックURLを表示