開発にドキュメントなんていらない(2/2)
»
前回のお話の続きです。
■ドキュメントは悪の元凶
そもそもこのドキュメント類は、作るのが本当に大変なのです。
真面目に作ると、ざっと実際のプログラムの2～3倍の工数(作業時間)がかかります。もっとかも知れません。プログラマもデザイナーもやることは分かっているのに、SE が作るドキュメントが追いつかず、作業に取りかかれないということも間々あります。
そしてこのドキュメントはメンテナンスするのが大変です。いや、ドキュメントのメンテナンスこそが工数のブラックホール、対顧客のトラブルメーカーと言ってもいいと思います。
たとえば、システムの開発も終盤になり、β版でシステムの最終評価をしていただいているときにお客さんからこんなことを言われたとします。
｢この画面ですけど、ちょっと1項目言い漏れてたんですよ。で、このあたりに適当に差し込んでもらって、、、そうするとスペースが足りなくなっちゃうから以下の項目を順繰りに、これをここ、これをここって感じでずらしてくださいよ｣
これを業界の言葉では、「軽微な仕様変更」と言いますが、プログラムだけなら15分で終わるところが、きちんとした仕様書を作っているとそのメンテが必要になり半日作業になります。
紙に印刷してたりすると、しかるべきページを差し替えたり、最悪の場合ページ番号がずれたりして、目次を変えたり引用ページの影響を調べたり、1日作業になることもあり得ます。
こうなるとタダでは受けられません。
タダでは出来ないと、上司を巻き込んで見積もりを書くことになります。
見積もりを書くと、お客さんの方も担当者レベルでは判断できず、上司に相談することになります。
数万円の見積もりを出したがために、会議に呼び出され、先方の上司が出てきてこう言います。
｢ここに来て何言ってんのよ？この項目ないと業務が回らないでしょ。これを聞き逃したのはそもそもお宅のミスでしょう。｣
と。
｢なんだか、お宅、サービス悪いなあ。これくらいの作業で万単位で追加がかかるってってどういうことよ。次の仕事は別のところに頼もうかなー。｣
とか言われてはやらざるを得ません。
担当営業が半べそで会社に帰って報告すると、上司から｢まあいいさ。今回軽くパンチ入れてやったから、お客さんも仕様変更ってのは大変だって言うことを思い知ったろう｣などと言われてとりあえず｢そうかー、いいのかー｣なんて溜飲を下げたりします。
■開発会社がしっかりドキュメントを作る理由
しかしなんでしょう。
仕様書さえなければ15分作業で、タダで対応できたことが、仕様書を作ったからこそタダでは出来ず、顧客満足度を大きく下げ、見積もり作成工数、打ち合わせ工数を余計に消費し、で、結局やることになる、と。
いったい、こういった間抜けなドキュメントを、開発会社は何のために書いているのでしょうか？
その目的は３つあります。
一つは、社内での引継ぎのためです。
中規模以上の開発会社では、開発人員というのは、プロジェクト毎にアサインされ(呼び集められ)、プロジェクトが終了すると解散してしまいます。保守は別の保守専門のプログラマが担当しますし、追加の開発があったりした際には別のメンバーがアサインされます。外注の開発会社や派遣社員がアサインされることもあります。
こんなとき必要なのが｢ドキュメント｣なのです。
確かにここで詳細な資料が残っていると、安心です。社内資料ですからね。フォーマットも統一されていれば内部的には毎度のことで読みやすいのかもしれません。
しかし開発会社社内の引継ぎをしやすくするための資料をお客さんのお金で作るというのも、なんだかおかしな話だと私は思います。
二つ目は訴訟対策です。
これまた、プレーヤーが多く、入れ替わりも激しい大きな開発会社では、お客さんと話し合った内容は逐一ドキュメントに残してハンコをもらっておく必要があります。そうしないとすぐに｢あの担当者に言った｣｢そんな話は聞いてない｣とトラブルになってしまいます。お客さんの担当者はたいてい一人か二人で、入れ替わらないので強いのです。
もし、現場レベルの言い争いで収まらなくなったら、そこで登場するのが、これまで作成してきた膨大なドキュメントです。
そこにはお客さんがとても理解できないような言葉で書かれた｢仕様書｣と、お客さんの｢めくら判｣が押されています。
お客さんのお金で作った仕様書が、お客さんを責め立てる。これまたまったくもって不合理なお話です。これは、私はもう何度もそういう局面に遭遇しました。(ウチがやってるんではなく、前の開発会社がそうやって逃げたとか、本当によく聞きます。)
最後はカッコつけです。
なんとなくドキュメントを作っておくとちゃんとした開発会社のような気分になるのです。
開発会社は、どこも始めはいい加減です。しかし社歴を増すにしたがって段々と｢ちゃんとする｣ようになってきて、こういったドキュメントもきちんと作るようになってきます。これは、備品は備品台帳を作って管理しようとか、そろそろ就業規則をつくろうとか、そういう発想に近いような気がします。
そして、次第にドキュメントを作ることに何の疑いも持たなくなり、一つの企業文化になり、その必要性をお客さんに納得させるのがうまくなり、営業マンが会社のブランド(信用力)とセットで語り始めます。
そうすると、ドキュメント作成費用でお金も儲かるのです。
ただ、こんな押し売りをやってると、長くは続かないと思いますね。若き技術者のモチベーションも下がります。
■必要な仕様書とは何か？
さて、では、どんな仕様書もまったく不要なのでしょうか？
いや、そんなことはありません。一人で営業をやって一人で設計して、一人でコーディングするのであれば、まあいらないかも知れませんが、チームで開発するようになると、どうしても仕様書は必要な局面があります。
しかし、それは絶対にプロジェクトの成功のため、お客さんの運用に支障を来さないため、というベクトルでなければならないと思います。
社内の引継ぎのためであったり、訴訟のための言質集めであったり、カッコつけであったりというのはあってはなりません。
そうするとたぶん本当に必要なのは
・DB定義書
・画面設計書
・コードナンバーの定義やバッチ処理のフローなどを書いたプログラム仕様書
・ネットワーク構成図
このあたりです。
そして大事なのは、これら仕様書は印刷してファイリングして納品する、というためのものではなく、開発者同士で情報を共有するためのものであるべきです。なので、決して網羅する必要はなく、大事な画面、大事な処理だけで十分です。
優秀な技術者は基本的に完璧主義なので、作るとなったら完璧に作りがちです。しかし完璧を求めてもコストを無駄にアップする以外、なんの意味もないです。お客さんのお金で余計なものを作ってはいけないと思います。というか、コスト増になって、いずれ廃業です。
｢そんなことを言えるのは、お宅が運良く潰れなかったからだ。もし潰れたら、お客さんはなんのドキュメントも無くて、後釜の開発会社を探すのに苦労することになる。｣
などと言われそうですが、そんなこともないと思いますね。
弊社ではよく、開発会社と音信不通になってしまったシステムを引き継いで、システムの修正やリプレースを受けるのですが、その際に前の会社が残していった詳細仕様書などほとんど見ません。大抵メンテされていなくて信頼出来ませんし。
DB定義書と画面遷移図(画面一覧)はあった方がいいですが、それが無くてもソースと画面上の動き、DBの中身から仕様を解析していきます。
開発に、仰々しいドキュメントは、本当にいらないです。