仕様書とか定義書とかなんだかんだ

        2007年12月14日 01:50:17 (Fri)

今、開発をしようとしてるところでは仕様書とか設計書とかなんだかんだ、とにかくドキュメントは必ず作って、それから開発を進めようという感じ。いわゆるウォーターホール型なんだけど、これまでの開発がほぼスパイラルで、とりあえずデータベースにしてもプログラムのロジックにしても作ってなんぼっていう感じだったから、ロジックのドキュメントを書くとか、データベースの定義書を書く事が正直しんどい。

まぁそういうのはあるに越した事はないとは思うんだけどね。
ただ、全部がそういうやり方だったらやってらんないってのが自分の意見。
ドキュメント類を作成するべきなのはこんな時。

・組みこみ系システム
→どっかの会社専用のシステムとか
・開発する構成自体が、がっちりドキュメント作っておかないと痛い目に遭いそうな場合
→例えばOracleとJavaの組み合わせでサーバー100台規模で運用する場合とか
・そのシステム内で金銭的なやり取りが多く発生する場合
→金融システムとか、ECサイトとか

逆にドキュメントは後回しでいいんでない？的な時。
・PHPとかRuby、Pythonみたいなインタプリタ系での開発
→実行してすぐ結果が分かる
→その後に仕様を変えるのも難しくない（フレームワークを使うかどうかとか、使う場合はそのフレームワークに依存するけど）
・上記みたいな言語の場合、要求の変更があった場合に結構楽に対応出来る
→この機能を追加してくれとか、色々と。
→これがJavaとかだと、カッチリ作られちゃってるから手直しがしづらい。
・時間がない時
→物が作れなくてドキュメントだけ出来ましたーなんて事で金は貰えないし。
→そもそもそんな状態で仕事を引き受けるなと。

特に、Railsライクでの開発なんてのは生産スピードを上げるものだし、言語自体が比較的柔軟だから、最初からカッチリやってたら良いものは作れないと思うんだよな。

良いものの捉え方ってのは人それぞれ違って、人によっては「相手の要求した仕様を完全に満たす事が良いもの」という捉え方もあるし、「相手の当初の要求とは違っても、相手が納得するものが良いもの」という捉え方もある。

カッチリ作る人ってのはどちらかというと前者の捉え方をするんじゃないかな。
俺はどちらかというと後者。
相手が要求していなくても、「ここはこうじゃなくてこうしてみたらどうですか？」って言うしね。
相手の要求なんてのは所詮、相手のアイデア上でしかないわけで、そこに俺のアイデアを上乗せすればもっと良いものが作れるかもしれないって思うわけ。

まぁなんでもかんでもそんな事をしてたらキリがないのは分かってるけどね。
特に相手の要求が国レベルとかだったら、それにはなかなか太刀打ち出来ないし。

Tags: Development 

前の記事： またiPodか・・・

次の記事： Smartyのデリミタ設定を「{{」「}}」にしても「{」「}」を扱えるようにする

ｔｙ said
2chのプログラマー板見てると「仕様書はSEの脳内にあります」とか「そもそも仕様書って何？食えるの？」な書き込みが結構ありますが、あれはどの辺りまで信用していいんでしょうか・・・
巷のプログラマーさんのブログを見ていると仕様がどうだとか、設計についてとかの記事を割合、まあまあ、よく見るので、「仕様書がSEの脳内にある」という状況ばかりではないということは分かるんですがなんだか脅されているような気分になりますｗ

仕事となると単にプログラムを書くだけでは済まないのですね＞＜

2007-12-15 02:34:32

keiji said
自分の作ったプログラムを自分で使って、運用も全部自分でするなら、「仕様書は自分の脳内の中」でもいいと思うけど、仕事となると、自分のプログラムの（に限らずDBとか全部）の設計とかを完全に相手に理解してもらわないといけないんです。

というか理解してくれなくても、少なくとも仕様書を作って、相手に承認を得ないと、「ここがおかしい」と言われた時に「あー、それは仕様通りじゃないからバグですね、修正します」とも言えるし、「それは仕様書通りに動いてるからバグじゃないです」とも言えるんです。

だから仕様書って大事ではあるんだけど、ウェブアプリってあれもこれも追加してっていうのが次々出てくるもんだから、仕様書がどんどん変わっていくし、こっちは新しい仕様書を見てるけど相手は古い仕様書を見てるとかでトラブルも起きたりするのね。

だからそういうアプリだったら、仕様書は後回しでいいんでないって事を言いたいのがこの記事なんです。

2007-12-15 19:05:17

お名前（必須）

メールアドレス

URL

本文（必須）