IGINブルネイ/syasudaの日記(MT版)

これがデフォルトです、と説明する資料が必要です。

例えば、いくら設計レビューの重要性を説いても、レビューをまともにやっていない組織では馬耳東風です。

どれだけ丁寧に説明しても、

それってお前の個人的な意見じゃないの？

と眉につばをつけられておしまいです。

そんなときに、こんな本を見せればよいと思います。

計画から実施、後始末まで書いてあります。詳細部分の記述は薄めです。この程度の分量ですべてを書ききれるわけがありません。

昔某F社内で使われていたという文書管理マニュアルのコピーを見たことがありますが、概要説明だけで10cmのパイプファイルでした。

帳票(画面)設計のマニュアルで1冊、ユーティリティ開発だけでまた1冊、という具合です。マニュアルのためのマニュアルもありました。

設計のためのマニュアルというのは、何を決めなければならないかを決めておくということです。

たとえば、画面設計であれば、表示される内容の配置だけでなく、データをどこから取ってくるかを決めなければなりません。すると別のデータ設計書の項目を引用することになるわけですが、そこにコードを振っておくルールにしておけば、

ある設計書ではユーザIDなのに、別の設計書ではユーザ名になっている。

これは別のデータなのか、同じものの言い換えなのか？

というユビキタスな悩みもなくなるわけです。

データベース設計ではすべての物事にコードを振るくせに、自分が使うデータ名称にはコードを振らないという皮肉への一回答であると当時の私は感慨にふけったものです。

さて、外部設計、内部設計、製造、テストという工程分割を目次で眺めて分かることは、

製造=実装って、4分の1しか占めないのな

ということです。実装が倍早い熟練者が居ても、全体の日程に対しては8分の1、つまり12.5%の短縮効果しかありません。

一方テスト工程が倍遅延すれば、25%の日程遅延です。4工程を4等分した場合の話ですが。

しかし、4分の1ずつというのはひとつの目安として意識した方が良いです。

1年間のプロジェクトなら、半年は外部設計、内部設計にかけるべきで、2ヶ月目くらいから実装をはじめると、「いつまでたっても完成しない」状態に陥ることは必須です。

もしプロトタイプが必要だといわれても、詳細な設計にかける工数をけずってはいけません。実装にかけられる工数は3ヶ月しかないのですから。

おそろしく詳細に設計してあれば、製造とテストは熟練者でなくてもこなせます。

いい加減な設計では最後の最後まで熟練者が必要、あるいは「だれだれさんに確認しないと仕様が分からない」で現場は混乱します。当然のことです。

統率が取れた製造現場では、実装の楽しみも、面白みも半減です。設計書に書かれた通りに実装し、設計書に穴があっても自由裁量はほとんどなく、設計者への無味乾燥な問い合わせの羅列を書き下すだけの作業ですから。

工業的に製造するということはそういうことなのです。

大昔の職人芸のように、腕に頼ったものづくり(家内的手工業あるいは工芸)では、納期短縮も大量生産もできません。

今風に言えば、開発力のスケーラビリティがないのです。

個人的な感想ですが、この本に書いてあることは、世の中のソフト屋の過半数が普段やっていることです。*1つまり人間を3,4人連れてきたら、半分はそのやり方を知っているか慣れているということです。それを生かすべきか、無視するべきかどちらが良いかは各自で判断していただくしかありません。

ちょっと古いこちらの本には、各種文書のテンプレートが巻末についています。

流用できない場合は参考にできるでしょう。