私は、受託バカでありたい。
第4回

開発に形式的な仕様書なんていらない!大事なのは愛のあるドキュメントだ!

仕様書の種類にはどのようなものがあるだろうか?

  • 要求仕様書
  • 要件定義書
  • 基本設計書
  • システム概要仕様書
  • 業務フロー設計書
  • ネットワーク構成図
  • 画面設計書
  • 帳票仕様書
  • ER図
  • インターフェース仕様書
  • 詳細仕様書
  • DB定義書
  • API仕様書
  • アルゴリズム仕様書
  • クラス設計書
  • 状態遷移図
  • テスト仕様書
  • 単体テスト仕様書
  • 結合テスト仕様書
  • システムテスト仕様書

会社によって多少バラつきはあるものの、作る会社はこれくらいのものを作っている。お客様が始めてこれらを見るとその量に圧倒されてしまう。

しかし、少し考えていただきたい。これらは何のために作られているのだろうか?

同業界からの批判を恐れず言えば、これらのドキュメントの目的の大部分はお客様からの「言質」である。

あるいはゼネコン的な多重下請け構造を持つ開発会社間で伝達齟齬が起きないようにするための契約書の一部である。

お客様の費用で、言質の資料や仕様伝達のための資料を作成する、、、それはおかしくないだろうか?

またこれらの資料が、よりよいシステムへの変更の足枷になることがある。

「作ってみたらもっといいアイディアが見つかった。しかし仕様書を直すと丸1週間かかり、作業者の手も止る。だからこのまま行こう。」

このようなことは、古い体質の開発会社ではよくあることだ。

ということで、プラムザではこのような仕様書は極力作らないようにしている。紙よりも動くものだ。それによって、より柔軟でリーズナブルな開発が可能になる。

しかしながら、なんでもかんでもドキュメントを批判するわけではない。

後世に渡って残しておかなければならない仕様はきっちりドキュメントとして残し、引き継いでいかなければならない。

要は、お客様のため、システムの永続利用のために必要な情報はちゃんと残す。

もちろん、紙ではなくクラウド上に残すことがほとんどなので、メンテの費用は小さく管理も楽ではあるが、それでもどうしても費用はかかる。その費用はお客様に丁寧にご説明し、ご納得いただいて頂戴している。

第1回

技術的にすごくても、お客様のうれしいに結びつかなければ価値ゼロだ!

第2回

開発者が長く居つかない会社では、大事なシステムを作れない!

第3回

プロジェクト成功のカギは初期のヒアリングフェーズにあり

第4回

開発に形式的な仕様書なんていらない!大事なのは愛のあるドキュメントだ…