- - PR -
仕様書の書き方
| 投稿者 | 投稿内容 |
|---|---|
|
投稿日時: 2003-11-17 14:15
なるほど〜m.kuさんの
「なぜそのコード(アルゴリズム)が選択されたのかはコードには書かれないので そういう意味でのドキュメントは必要でしょう。」 っていうのは納得ですねぇ。でも、多くのものは、そういう必要な情報よりも ただ、そのコードがやってることを日本語にしてるだけのものが多いですよね。(反省) どういうドキュメントを書くべきかを考えてない人って多いと思う。 そして、それは顧客に書けって言われたから仕方なくっていうスタンスだから なんだと思います。僕が今いるプロジェクトも顧客に言われたことをその通り やってるだけで、仕事のやり方について何一つ提案していません。昔からの 付き合いで仕事をもらってるようなので競争相手がいないせいだと思います。 でも、これからの時代ってベンダーは選ばれていくんだと思うので競争力を 持たなければいけないんじゃないですかね？ってなことを打ち合わせの時に 言ったんですけど、「でかい組織はそんなに簡単に変わらないから」と 言われました。明日も何も変わらずに夢見ているだけなのでしょうか…？(詩的) raccoonさんのおっしゃってるアプリケーションの仕様を書いた仕様書が必要っていう のは勿論賛成です。それで、 「また，いくら設計内とはいえ，メモだけで合意を済ませるのはキケンです。 打ち合わせのたびに変更が入りますし，あとで改ざんもできてしまいます。」 という所で、えっと多分、raccoonさんの言ってる意図と違うんですけど、 あえて言わせていただくと(話したい事があるので）、 「変化を抱擁せよ！！」 マーチン･フォウラーの「新しいソフトウェア開発手法」って論文の中で ”問題のあるプロジェクトはみんなこんなことを言う「仕様変更が多すぎるんだよー」 でも、ビジネスの世界は常に動いてて、そのビジネスをサポートするソフトウェア なら要求仕様が変わって当然だと。開発に入る前に要求の全体像を文書化して 顧客のハンコもらって、ハンコもらった限りはちょっとやそっとで変更すんなよ っていうやり方自体がへぼいんだ”と言ってます。 これ読んだ時、正直笑っちゃいました「仕様変更が多すぎるんだよー」 って言ってた人ほんと多かったので、彼らはへぼかったのね！？ それで、この「変化を抱擁」する為には変更のコストを押さえようということで XPでは、まずテストを自動化することによって時間を削減してるんですよね。 でも、このテストを自動化する、具体的に言えば「JUnitを書く、 実行時のDBの状態なんかを整える」これらをただ一回流すだけなら、 簡単なんですけど、 毎日100%テストをパスさせるっていう「継続的インテグレーション」を やるには、自動的にDBの状態なんかを整えるスクリプトやJUnitのコードだって 時間がたつにつれ修正を加えていかなければならないわけで、それらを やるのに時間をかけて、必要のないドキュメントは書きません(勿論必要なのは書く) でも、そうすれば、顧客は思い通りのソフトウェアを手に入れられまっせ！ っていう考えで、とても理にかなってて良いとおもうんですけどねぇ。 ちなみに僕が今参加してるプロジェクトは設計書に1年以上かけまーす。 これから一年間プログラム書きませーん(仕事では） Are you programer ? I don't know. なんちて。 長くなりましてすみませんでした。 [ メッセージ編集済み 編集者: やまろう 編集日時 2003-11-17 14:16 ] |
|
投稿日時: 2003-11-17 19:34
XP本を読んだ後にアジャイルモデリング(ISBN4-7981-0263-6)を読んでみてください。そのあたりを少し補完してくれています。
XPはウォータフォールに対するアンチテーゼのようでかなり過激なことを言っています。 最近は「XP(アジャイル)はわかったんだけど、実際にどう持ち込んでいいものか・・・」という視点の本が増え始めました。認められつつある雰囲気ですが、現実的なところまで落とし込まないとまだ普及はしそうにないですね。。。 XPはデキルチームが面倒を見てくれるという安心感を与えないとなかなか契約として認めてもらいにくいでしょうね。成果物(たとえ役に立たなくとも)のたくさんあるウォータフォールではその辺をうまく丸め込んでいるような気がします。成果物によって顧客は形のあるものを手に入れた気になれますから。 |
|
投稿日時: 2003-11-18 07:47
私が担当しているプロジェクトでは、仕様書が開発中に自動的にできていきます。仕様書は概要、タスクシートとその他ドキュメントの３つで構成されています。
最初のは簡単な全体図です。これはでっかい紙にぱっと見てシステムが何をしているのかが分かるような図と説明が書いてあります。これはプログラマでない人でも分かるような内容にされています。 次のはタスクシートです。システムで実装しないといけないものを小さく細かくしたTaskと呼びます。Taskの一つは1〜２週間ぐらいで作れるような物を基準にします。タスクシートにはそのTaskの概要説明、実装指針、注意事項がかかれます。これはプログラマでない人でも多少は分かるようになっています。 最後に、実際に実装した人、もしくは設計した人が書くUMLやその他のドキュメント類がコーディング中か前後に書かれ、タスクシートに追加していきます。これはほとんどテクニカルな内容（UMLダイアグラムやXMLのDTDなど）ような物が多くなります。 もし、大きな仕様変更があった場合、全体図はすぐにアップデートされます。既存のタスクシートはそのままにされて、仕様変更のための新しいTaskが追加されます。新しいタスクシートには既存のどれどれのTaskを変更するか書かれているので、更新記録がすぐに分かるようになっています。 これは以前研修をしていた所で使われていたのを自分で改造したプロセスです。 利点としては、
欠点としては、
|
|
投稿日時: 2003-11-18 09:50
仕様書とかのドキュメントに関しては、どんな手法であれいつも問題提起されますね。
「そもそも必要なのか」とか。（ちょっと極端ですが） ただ、XPであれUMLであれ、旧来のウォータフォール型であれ、ドキュメントの意味する ところや、必要とするところはほぼ同じでしょう。 例えば、XPでもURLでも通常見かけるドキュメントはほとんどが実装部分のドキュメント がほとんどです。この部分は意見が出ているように、「ソースで代用」もある局面では 可能です。が、実はもっともドキュメントが必要なのは、論理や理論の部分で、その部分 を前提にソースを見ないとわかるものもわかりにくくなります。 ここは、ドキュメント以外に表現のしようがないところなので必要になりますね。 じゃ、「実装部分はどこまで書くか」というのも私はケースバイケースだと思っています。 XP、UML等で挙げられているドキュメントについては不要（無意味）なものはありません。 が、必要かどうかは、開発プロジェクトの規模、内容、要員のスキル、構成、ユーザーの 要望等で変わってくると思いますよ。 例えば、５人〜１０人ぐらいのプロジェクトだったら、会話等のコミュニケーションで 大抵は何とかなります。（むしろそのほうが効率が良い場合もあります。） でも、１００人規模で、その１００人が複数の会社で構成されて、極端な場合 東京、大阪、ニューヨーク、ロンドンというような拠点で作業を行うと、なかなか コミュニケーションと言っても難しくなります。（言葉も違うしね。）こんなときは かなり細かいところまで、図で表せるようなドキュメントを作成すれば誤解無く伝わり やすいということになりますね。 それと、ユーザーの要求というのがなかなか厄介で．．．まず、 ・社内規定で決まっている（ISOとかの関係） ・改造や別システムとの連携時に他社に発注（説明）しやすい ・ユーザー側でも勉強したい というような理由が考えられますが、一番の理由は「安心感」だと思いますよ。 とりあえず中身はわからなくても、納品物件に書かれているドキュメントと いうものがボーンと納品されるとなんとなく安心感があるということが多いですね。 余談ですが、昔のPCにはDOSやBASICのリファレンスマニュアル等たくさん付いて いたのですが、価格がグ〜ンと下がったとき、一斉にマニュアル類が添付されなく なりましたよね。（最近またインターネット関係の初心者向添付マニュアルが増えて るのかな？）そのときものすご〜く不安なというか、損をしたような思いをしたので すが、同じような感覚でしょうね。 |
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。