誠ブログは2015年4月6日に「オルタナティブ・ブログ」になりました。
各ブロガーの新規エントリーは「オルタナティブ・ブログ」でご覧ください。

開発にドキュメントなんていらない(1/2)

開発にドキュメントなんていらない(1/2)

島田 徹

株式会社プラムザ 代表取締役社長。システムコンサルタント。1998年に28歳で起業し、現在も現役のシステムエンジニア、コンサルトとして、ものづくりの第一線で活躍しつつ、開発現場のチームとそのリーダーのあり方を研究し続けている。

当ブログ「そろそろ脳内ビジネスの話をしようか」は、2015年4月6日から新しいURL「​http://blogs.itmedia.co.jp/noubiz/」 に移動しました。引き続きご愛読ください。


-------------------------[PR]-------------------------

こんど誠ブロガーの森川氏が、アットマークアイティの方で、私と弊社内藤取締役とのインタビュー記事を連載してくれるそうです。

テーマは「プラムザはオープンソースを使わず、フルスクラッチにこだわってるけど、それって将来あんの?」みたいな話で、6回とか8回とかの長い連載記事になるようです。

近日中に公開されるらしいですので、公開しましたらこちらのブログ内か、twitterの方でアナウンスいたしますので、どうぞよろしくお願いします。

(※)2012/4/19 記事公開されました!
-------------------------[PR]-------------------------

実はその記事の中に「開発にはドキュメントなんていらない」というくだりがありまして、下手をしますと「この会社は仕事できねえんじゃないか」と思われそうなので、ちょっと補足したいと思います。

ここで、「ドキュメントとは?」をちゃんと定義しておきたいと思います。

本来は「ドキュメント」とは、読んで字のごとくただの「書類」なのですが、開発屋が「今回、ドキュメントは何をお出しいたしましょう?」とか「前のシステムのドキュメントは残っていますか?」とか言う際に指しているのは、プログラムと一緒に納品される成果物としての書類です。

それは通常「仕様書」とほぼ同義で、同じ書類ではあっても「見積書」とか「納品書」とか「ハンパなメモ書き」とかは含まれません。

今回のブログ内で「ドキュメント」、「仕様書」とありましたら、「成果物として提出が求められる書類」という意味でお読み下さいませ。


■ドキュメントの作成を求められたことがない

15年ほど前、私が勝手にフリープログラマーと称して、AccessやらVBやらで業務システムを作り始めた時には、ドキュメントの「ド」の字も作っていませんでした。

どこかからパクってきた見積書に、1枚か2枚絵の画面イメージを添付して、

「こんな感じでやっていこうと思うんですよね。これ出来たらすごくないですか?いいですよねー、絶対いいですよねー!?」

とお客さんと一緒になって興奮していました

営業としてかなり最悪なんですが、忘れていた何かがここにある気もします。

お客さんが「こんなんで発注していいんだろうか」と思いつつも、ついハンコを押してしまったら、即実装開始です。テーブル定義などは画面を作りながら考えていきます。

そして次回の打ち合わせでは、動く画面を持っていき、レビューいただいた内容はノート(紙)にメモし、持ち帰って直して、再度持参する。

開発を進めながら、仕様に無理が生じると、お客さんに電話やメールで相談して、修正をかけていく。

最後まで、一切ドキュメントはありませんでした。

作る側がその存在を知らず、お客さんからも求めなければ、作らないのは当然ですよね。


世の中には仕様書というものがある

そのうち、何度かプロと呼ばれる方々からお仕事をいただいたり、一緒に仕事をするようになると、どうやら開発業界隈では「仕様書」というのがはびこっているようだと知るようになりました。

「仕様書...。なんだろう。それがあると、画期的にいいものが早く出来るのだろうか...?」

そう思って、他社の作った仕様書を見てみると、なんだか訳のわからない暗号がたくさん書いてあります。

すべての項目に番号が振ってあり、それが「1」「2」「3」「4」...ではなく「010」「020」「030」「040」みたいになってます。時には、「1.2」とか「1-2」とかの「枝番」が振られ、調子に乗って「1-2-2-15」などと、「これ、本当に便利なの?」と疑いたくなるような番号が振られてます。

また、図が多いです。業務フロー図では、あちこちで図が爆発していて目が釘付けになります。「オーダー発生」などが爆発してますが、そんなに大変なイベントなんでしょうか?ネットワーク図では、インターネットはなぜかモクモクしてます。クラウドでもないのに。

そして、なんと、まだ作ってもいないのにエクセル上で画面ができてます。データベースの定義も、想像の中ですべて作られています。ものすごい技術だなと感心してしまいました。

独立後3年目くらいに、中堅SIerさんから官公庁向けのシステムの開発をお手伝いを頼まれたとき、初めてかなり精緻な仕様書をいただきました。確かによく考えられてはいたのですが、その仕様があまりに古めかしくてイケてなかったので、勝手にいまどきのインターフェースに直したら全部やり直しさせられました。

「間違ってても、使いにくくても、その通りに作れ」

それが仕様書というもののようです。

さて、時が過ぎ、私も次第に経験を積み、一口で仕様書と言ってもたくさんの種類を目にするようになり、まあ書けと言われたら書けるまでになりました。

ざっと例を挙げてみます。

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

こんなところでしょうか?

テスト仕様書は一般に言う仕様書には入りませんかね?まあここでは、先に定義した通り、開発作業に付随して提出することが求められそうなドキュメントということで一緒にしておきます。

この中で時間をかければ書けるものは書けますし、書けないものは書ける人に頼むことでドキュメント作成費用を稼げてウマーではあります。


■開発にドキュメントなんていらない

しかし、常に心の奥底にしまっている一言がありまして、それはお客さん(特にSIerさん)にはあまり言えないのですが、読んでいらっしゃらないことを祈りつつ言ってしまいます。

こんなドキュメントは、作らなくてもシステムは動くし、お客さんともトラブルにもならない!

です。

私が、20代のプログラマだったら、「んなことは経験が無いからいえるんだ」「作っておいてよかったと思うことが必ずある」とお叱りを受けるでしょうが、今年で14年開発会社を潰さずにやってきているので、まあそろそろこれくらい言ってもいいかな、と思うわけです。

私の祖母は今年101歳でいまだ元気に生きてます。彼女は97歳くらいまでビールを毎日飲み、脂っこい肉も平気で食べ、野菜が大嫌いでしたが、彼女に「そんな食生活じゃ長生きできないよ」といってもしょうがないでしょう。それです。

このスタイルで会社は潰れず、デズマにもならず、ファンのお客様がつき、一度も訴訟になっていませんから、事実としてドキュメントなんていらないのです。


(次回は「ドキュメントがいかに悪の元凶か」について書きます)