【設計書は】ドキュメント【ソース】

この仕事やってて、ぶち当たる壁。

外部I/F仕様書、外部仕様書、要件定義書、基本設計書、
詳細設計書、検査仕様書報告書 etc

誰も教えてくれないドキュメントを書く際の注意点など、語ってくれ。

　　　　　　　　　　　　　 ヽ ＼
少しは懲りろ！　　　.／　＼ ＼　　／￣￣￣￣￣￣
　 　　　　　∧＿∧／　　　　￣ 　＜　また貴様か！
　　　　　　（；´Д｀）　　　　 i i i　　　 ＼＿＿＿＿＿＿
　　　　　 /　　　 ヽ ＿　　　i i i--､
　　　　 ./|　|　　 | |　　￣￣￣ |:::::|.
　　　　/　＼ヽ／| | 　　　　　　ﾉ__ﾉ..
　　　/　　　＼＼| |
　　 /　/⌒＼ し(メ　　　　.i i i　.　.
　／ ／　　　 >　）　＼　　ﾉﾉﾉ
/　/ 　　　　/ ／　 　 .＼＿　　ｻﾞｯｸｻﾞｯｸ
し'　　　　　（＿つ　　　/:::::/::...　　 /ヽ
　　　　　　　　　　； "ノ・ ./∴: ／ ）i　iヽ-､＿へ　　　　,ﾍ
　　　　　　　　　　'',, : ：―― /　/　i　i　i iヽ .￣ ﾞ― ノ　/
　 　　n_　　　　＿／；　　　 i　　.ノ / /ノ-'￣ ﾞ ― ､__ノ
　　_ノ　二二二､_（ _Д_　;）-ヽ＿ノ-'>>1
　　ﾞー ''~　　　 　　∨￣∨

>>1
完璧を目指すな

ドキュメント？・・・はて、何の話でしたかの？

>>3
そんなもんかね。

那由他(nayuta:10^72)

ちなみに、

・受身形(受動態)で書かない。
・図番号は下、表番号は上。

は、常識？

普通は「だ・である調」と思うんだが、けっこう「です・ます調」の人がいるのに驚いた。

>>7
絶対受け身で書いちゃいけないの？
受け身で書かないと不自然な場合もあると思うんだけど…

＞・受身形(受動態)で書かない。

これって
　BがCをされた時、Dをする
は×で
　AがBにCをした時、BはDをする
みたいに主語と対象をはっきりかけ！って意味？

>>1
こういうのってプログラム設計書と、システム設計書の見分けが付かなくなっちゃうんだよね

プログラムによって、必要なドキュメントって決まるはずなのに
納品ドキュメントが、形式的に同じというケースはあるよナーーー
誰も読まないドキュメントを書くほどつまらない作業はない。

>>10
設計書を書くのは、これから自分の作るものだから、
受動態で書くのはおかしい、、という意味です。

×「この条件でBされる」
○「この条件でBする」

本当に必要なら、受動態でもOKだとおもう。

ドキュメントと書こうとして、
ドキュンと書いてしまいました。
似てるよね?

>13
何がおかしいんだか。

>>13
オブジェクト指向が出来ないヤシがまた１人・・・・(泣

>12
役所に納品するドキュソメントとかですな。

> 外部I/F仕様書、外部仕様書、要件定義書、基本設計書、
> 詳細設計書、検査仕様書報告書 etc
会社によって呼び方や書式が全く異なる。
よって、一概には何とも言えない。

年々納期が短くなり
年々単価がさがり
年々掛け持ち仕事が多くなり
年々技術が複雑になり
年々チェック項目が増える中で
誰も読まないと思うドキュメントを書けってか？

>>13
いらない　ﾌﾟﾛｸﾞﾗﾏ　ﾊｯｹｿ!

>>19
前書いたドキュメントを使いまわせ。

>>21
ドキュメントの再利用か．．．使えるかも知れない。

必要だとは解りきっているが、もうそれがまともにできない企業はほとんどだろ。
仕様書は、ソースから自動生成してくれるツールで済ませ、体裁だけは整える。
しかしソースだよりのドキュメントも、コメントがまともではないソースから
作られるという罠（ｗ

いいよもう
ドキュソメントはたくさんだ．．．

なんで見聞きしたりディスカッションした内容をドキュメントに残さないの？
たとえそれが「喫煙室での雑談から出た仕様」だとしても。
正式／非正式云々はともかく、ドキュメントに残して上に審判を問うぐらいの
ことをどうしてしないの？

d o x y g e n っ て ど う よ ？
http://pc.2ch.net/test/read.cgi/prog/1031676669/

>>26
相互リンクかよ！

リンクは頭の『ｈ』はずせよっ

>>28
2ch内だから関係ないだろ？

>>28
馬鹿ﾊｹｰﾝ

>>24
怒糞メントってのはどお？

>>15
すでにあるものが、そのように動作するならば、「される」だが、
これから作るものだから、「何々する」と書くべき・・・

と思っていたのだが、オブジェクト指向ではそう書くことがあるのか？？

実際一生懸命こだわって書いても読む人なんて少ないしなあ。
ソースさえきれいに書いてくれれば、文句言いません。

やっぱり、ドキュメントはワードで書いているんですか？

オートシェイプ使って図を書くとき
新しい図オブジェクトの挿入して
その中に書くのが普通だと思うのですが
文章中にいきなり線や図形を書く人って多いのはなぜ？
そのときレイアウトを揃えるために
改行をたくさん入れているドキュメント見ると泣きたくなります。
文が多いドキュメントはワード。
図が多いドキュメントはパワーポイント。
表が多いドキュメントはエクセル。
ばらばら。

ドキュメントはhtmlで書いてます。
WordやExcelで書くと移植性が下がりますので。

>33
プロジェクトで決めれ！
漏れは、基本はワード。
検討資料とか、別紙、添付資料では、Excelもあり。
オブジェクトの挿入は、昔やっていたけど、非常に重くなるので、

文中に直接図を描く。
↓
グループ化
↓
文章の回りこみ

を使ってるよ。

>>35
非常に重くなる上に不安定になるよね。
保存が出来なくなるときがたまにあって辛い。

なんかいいワープロないかねえ。
一太郎とか使ってる人いる？
あれなら代替OKなとこ結構あるし

Visio

>>37
やっぱり、Visioがいいよね。
だけど、いまの職場では「Visioって何？」って聞かれそうで怖いので
一言も口にしていません。
ほんとはVisioを使いたい場面とかケッコウあるんだけどなぁ。

UMLエディタなんか最近いろいろあるだろうに、
なぜよりによってVisioをつかわなにゃならんのよ･･･

お金持ちならお勧め：Together ControllCenter
ちょっと微妙：Rational Rose

VisioってMSDNの会員ならＣＤ貰えるよね。
swing使って書いてあるようなUMLエディタってやたら高いからイヤーン
申請できねぇー

アプリケーションに依存しちまう文書は使い物にならんです。
そんな事だから、昔のワープロでしか読めないフロッピーが
生き残ったり、別のアプリケーションに再入力しなければ
ならなかったりするんです。無駄な作業は、もう御免なのです。

Visioも、ｲｲﾈ!!
持っている人が少ないけど、ワードに貼りつければ、
見ることできるし。
慣れるまで辛かったけど、フローチャートとかシーケンス図を描くのは
とても便利。
やっぱり重くなるのが、タマに傷。

Visioは、HTMLでも出力できるしね、ベンリ。

プログラムは書けるけど、仕様書が書けないプログラマと
仕様書が書けるけど、プログラムが書けないプログラマはどっちがまし？

Visioいいね。
この前visioで書いて渡したら、相手が持ってなくて変更できないって言われて
wordで状態遷移図書き直した。

>>45
どっちもダメだと思うけど、
少なくとも後者はプログラマとしてはダメダメだと思われ。。。

プログラムの書けないプログラマなんて…
ギター無しのムッシュかまやつみたいなものよっ

仕様書は、プログラム書いた経験が無いと、まともなものは作れない。

仕様書をかけない奴は、プログラムはかけても、システムを作ることはできない。
これ事実！

>>48
そのココロは？

>>47
　仕様書書くのは上手なんだけど、プログラムが全然だめな先輩がいる。
　この前も、関数のポインタ質問されて俺に聞きにきたし。

>>7
　受身は読んだときに判りにくいからダメと聞いてる。
　

>45
> プログラムは書けるけど、仕様書が書けないプログラマ
→ただのフリーウェアプログラマ

> 仕様書が書けるけど、プログラムが書けないプログラマ
→無能なプロジェクトリーダ

仕様書(設計書などドキュメント含む)を書くのが、シェアウェアのプログラマと
SEとの違い！！

・・・と、昔言われました。

現実的に使える仕様書はまだ見たことが無い。
途中からプロジェクトに参加することが多いが
仕様はたいてい口頭で説明されたり、メール確認が多い。

>>54
でも、シェアウェアやフリーウェアのほうがよく出来てたり
するよね？

>>55
俺も、見たことない。
大抵「仕様書＝基本設計」になる。

>>56
確かに。
人の書いたコードとか見ると、ぞっとする。
金もらって、これかよ！！
・・・・昔の自分のコードだったりして。

>>55
　うん
　UMLを使ったリバースエンジニアリングとかに期待してるんだが。
　

やはり、仕様書が後付になるケースが多いからだろうな。

不具合管理はデータベースでやってると思うけど、
仕様変更データベース運用してるとこある？
イントラネットからWEBから書き込み・参照できるようにしてるとこがあって
やってみたいなと思ったんだけど。

>>60
漏れんとこ、Webアプリ化して運用してる。
ただ、使う人間に依存するんで、徹底するのが難しいよ。
入力されなきゃ、意味無いし。

ドキュメント？
後付、後付。
どーせ、納品したって誰も見ねーしな。

>>60
うちもグループウェアでやってる。
>>61と違って完全に社内に浸透してるんで、入力されてない→脳内妄想ってことで片付く。
かなりデスマーチが減ったよ(藁

コーディングした後じゃないとPCL書けないPGはいらん。

http://office.microsoft.com/japan/downloads/2002/vViewer.aspx
Visio Viewer 2002
ってどうよ？

>>63
　いいなぁ。
　グループウエアは自作？

>63
結局、どんな方法でも、定着すれば、それが神様になるから、
仕事はしやすいよなあ。
データベースでも、仕様変更管理票でも。

こっちは、プロジェクトが小さいからデータベースや
Webのグループウェアを使う・・という発想がないが。

別の話しだが、Visioで描いてあるフローチャートで
条件分岐が上を向いていた。

　　 　　　↑
↑　　　／＼　　　↑
│＿／　　　＼＿│
　　　＼　　　／
　　　　 ＼／
　　　　　↑

ｵｲｵｲ!

>>66
元は、とあるプロジェクトチームのリーダーが作った奴。
彼の上司が脳内妄想が大好きで、毎度毎度ヒドイ目に合わされてたらしい。
それが嫌で、自分がリーダーになった時にチーム内で自作のグループウェアを
導入したんだって。

現場の評判が良くて、今は社内で使ってる。
まぁ小さい会社だから浸透したんだろうなぁとは思うよ。


>>67
禿同。
ただし、変な方法がが定着した場合は…(((；ﾟДﾟ))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

仕様が無く、設計書を書く。
プラットフォームも決まらず、あっちこっち。

納期は決まっている憂鬱。

仕様も無く、設計書も無く、コードを書く。
全てはプロパーの口スペック。

納期はすでにオーバーしている死。

>>67
突込みどころはフローチャートを未だに利用してるとこか？

フローチャートも場合によっては有効だよ。
それとUMLツールは無料のものも色々あるよね。

完全に構造化しているプロセスはフローチャートが健在だよ。

うーん、フローチャートって読みにくくない？

自分の経験年数が少ないときに、
チームメンバが「ドキュメントとかCVSとか、そんなんやってる時間ないよ」と言うのを聞くと、
そんなもんかなあと思ってしまう。

違うと思ったときは違うと言うべき。
自分がちゃんとしたものを知っている自信があるなら、
ぜったい自分の思いを通すべきだ。

俺がそうだったよ。
最新ソースがどれかも分かってない。
リリース手順が存在しない。
WBSも決めずに「うーん、5割くらいですか」という言葉を鵜呑みにする進捗「管理」。
どれも大間違いなのに、みんな経験が長いからと引き気味になっていた。

いまは無理やりにでもWBSを自分だけでも付けてる。
CVS環境も入れたよ。ドキュメントのアウトプットもきっちり作ってるよ。
「決めないよりも、何かを決めたほうがマシ」なんだよ。

俺はマイペースだ。
納期がなんだと言わんばかりに、DQNメントを真面目に書いている。
納期過ぎてからコーディングに入った事をクライアントに知られや
しないかって、上司がハラハラしてたっけ。
でもあんまり長いプロジェクトだと、プログラミングまで忘れてしまう
罠がある。つーか、プログラミングがおっくうになってくる。

WBS
ワールドビジネスサテライト

>>71
禿同
　フローチャートは情報処理試験か顧客への説明程度にしか使えない。
　あんなもんで設計とかできないだろう。
　JISで決められた構造化フローチャートは無いのかな。
　

Hardware設計者の書く「ブロック図」と「タイミング図」は
ソフトの世界でも使えるぞ。
俺の部署、タイミング図作成用のCADをHard屋が作ってるし。

UML

基本は、状態遷移表か、UMLかなあ。

たまに、フローチャートが出てくるよ。環境が特殊なので、
今回はフローチャートを使ってます。

Javaのコードからフローチャート生成するツールに大喜びのお年寄りがいたなあ。

UMLも基本的にお絵かきツールだし、OOP理解してない香具師が書くと
メロメロのものができあがるからなぁ。。。

>>81
　同じく状態遷移図や状態遷移表がメイン。
　シーケンスフローも良く使う。

　UMLは使ってみたいな。

Ｔ芝よ、ＵＭＬ読めるようになってくれ。

>>78
構造化フローチャートっていうか、それに近いものだけど PAD はどう？
規格化されてるかどうかは知らないけど、制御構文(whileとか)に相当するものが
容易されてるフローチャートって感じかな。

今は UML があるから使ってないけど…。というか、これを機会に勉強してみたら？

>>86
　PAD使ってるよ。会社の標準だ。
　日立のTOPTALとか使ってる。
　
　UML使いたいな。UMLの図からCを生成してくれるツールがあるといいんだが。
　組み込み系でC++はメモリを使いすぎる。

フラッシュ
【サザエさん＋水戸黄門】
ttp://www1.odn.ne.jp/satoumizu/flash/sazae.htm

>>88
誤爆・・・鬱だ。

＜血液型A型の一般的な特徴＞（見せかけの優しさ（偽善）に騙されるな！）
●とにかく気が小さい(神経質、臆病、二言目には「世間」）
●他人に異常に干渉する（しかも好戦的・ファイト満々でキモイ）
●自尊心が異常に強く、自分が馬鹿にされると怒るくせに平気で他人を馬鹿にしようとする
（ただし、相手を表面的・形式的にしか判断できず(早合点・誤解の名人)、実際にはたいてい、内面的・実質的に負けている）
●「常識、常識」と口うるさいが、実はA型の常識はピントがズレまくっている（日本の常識は世界の非常識）
●権力、強者（警察、暴走族…ｅｔｃ）に弱く、弱者には威張り散らす（強い者に弱く、弱い者には強い）
●あら探しだけは名人級（例え10の長所があってもほめることをせず、たった１つの短所を見つけてはけなす）
●基本的に悲観主義でマイナス思考に支配されているため、性格がうっとうしい（根暗）
●一人では何もできない（群れでしか行動できないヘタレ）
●少数派の異質、異文化を排斥する(差別主義者）
●集団によるいじめのパイオニア＆天才(陰湿＆陰険）
●悪口、陰口が大好き（Ａ型が３人寄れば他人の悪口、裏表が激しい）
●他人からどう見られているか、体裁をいつも気にしている（「世間体命」、「〜みたい」とよく言う）
●自分の感情をうまく表現できず、コミュニケーション能力に乏しい（同じことを何度も言う、知障）
●表面上意気投合しているようでも、腹は各自バラバラで融通が利かず、頑固(本当は個性・アク強い）
●人を信じられず、疑い深い（自分自身裏表が激しいため、他人に対してもそう思う）
●自ら好んでストイックな生活をし、ストレスを溜めておきながら、他人に猛烈に嫉妬する（不合理な馬鹿）
●執念深く、粘着でしつこい（「一生恨みます」タイプ）
●自分に甘く他人に厳しい（自分のことは棚に上げてまず他人を責める。しかも冷酷）
●男は、女々しいあるいは女の腐ったみたいな考えのやつが多い(他人をけなして相対的に自分の立場を引き上げようとする等）

>>25
Knowledge Managementはじうやう

フローチャートから進化しているＵＭＬのアクティビティー図をいまんところ
フローチャートと呼びたい。
というのはオブジェクトごとにレーンを書いてもいいのでオブジェクトの動きが
明確になってよろしい。

ところで、VisioってXMI対応してるのか？

>>87
ＵＭＬの何の図からＣのスケルトンを吐けというんだ？
構造体か？

UML使ってるところ多いのだね

そういえば、転職して一番困ったのがドキュメントだったな。
書式が全然違うし、図も違う。

>>96
そんなん仕方ねーじゃん、標準化してるわけじゃねーんだから。

ということで誰か標準化運動起こしてくれないかと
他人任せなことをいってみるテスト

>>97　ｲｲ
ということで
【可能】マ板でドキュメント標準化の試案を作ろう【不可能】
スレという展開キボンヌ。

>>98
ｲｲ ｽｺﾞｸｲｲ
欲を言うと
帳票とか受注登録画面（DBからデータ取ってきて云々）とか
ファイルころがしとかベタなな業務アプリから
WEBアプリやらなんやらのモデルケースを前提に。

やっぱりみんなドキュメントの書き方に自信がないんだ。
ちょっとほっとした。

UMLが使える範囲も限られてるしな。
なんかいい文献ない？

少なくとも俺の会社は１０年前に誰かが作ったフォーマット内に
好き勝手に図やら表やら文章を書き足していく。
ひどいもんさ。

特に仕様書にロジックが書いてあると鬱になる。

>>100
要は内容をよく理解してもらえるように書く。大切なのはこれだけだろ？
そして、内容をよく理解してもらえるようなドキュメントを書くには、手法
だけでなく、言葉の使い方や相手のスキルに応じた書き方等々、一朝一夕に
身につけられるものじゃないよ。

>>102
＞内容をよく理解してもらえるように書く
ごもっとも。

ただ、スレの趣旨としては具体的にどんな書き方をするかだとおもうよ。

>>103
素人にUMLなんか持ち出しても「ﾊｧ？」ってな感じだろ。だから、具体的に
どんな書き方をするか？って聞かれたら、こう答えるしかないだろうな・・・
「状況に応じて書き分ける」

>>104
結局そこに行き着くのか。。。。。

建築とか機械とか図面の書き方にある程度の決まりがあるのに、
この業界はいい加減すぎ。。。。

>>105
この業界の進歩の速度は　>建築とか機械　とは比べ物にならんだろーが。

>>105
だって、歴史が浅いんだもん。

>>105
しかも、バーチャルな世界だし。

胴衣。
だから標準化作業進めつつ、いろんな問題点を具体的に洗い出したいなぁ

と思いつつも進まず

歴史が浅いのを言い訳にするなよ。
コーディングの標準化は喜んでやるくせにさ。

＞【可能】マ板でドキュメント標準化の試案を作ろう【不可能】
いい案だと思うがなー。

ｿﾌﾄの仕様書で重要なとこは、一般的な仕様書のはじめの説明の部分だな。
大抵の仕様書でここが抜けてるだろ？せいぜい数行。
ほんとはここが大きく膨らむべきだし、ここだけで十分ともいえる。

あとの部分はそれこそ他の業界じゃ実際に製造する作業の範疇だよ。

>>112
あなたはもしや、
http://pc.2ch.net/test/read.cgi/prog/1029302442/523
では？もしそうだとしたら、もう一度お願いします。弟子にして下さい！

ユニット・テストが完全な仕様書だ。

あぢゃぱー

>114
このスレでいう「仕様書」っていうのはどのドキュメントを指すの？
今までドキュメント関連のスレをいくつか見てきたけど、会社/個人によって「仕様書」の
定義があいまいで話がかみ合ってない例がけっこうあったんで、決めておいたほうが
話がスムースに進むと思う。

ちなみに、うにっとテストは(ウチ流に言うと)詳細設計書って気がするが・・・

どの工程でどういうドキュメントを作るのか、教えてほしいなぁ

>117
納品準備段階で全てのドキュメントを作成する。

.....とのたまう香具師が多くて困っている。

ドキュメントの無いウォーターフォールなんてXP以下ですね。

>>119
ん？

ソースにコメントがあるだけいいわな・・・

ソースにコメントがないとdoxygen使えないじゃないか。

ドキュメントにウソを書くのはやめて欲しい（ｗ
信じたばっかりに痛い目にあう奴が後を絶たず。

結果として、ドキュメントは参考程度。
まぁソフト屋なら日本語よりソースの方が簡潔に
意味がわかるわけだが。

>>123
そんなわけないでしょ。

ノーコメント

doxygen の出力を見せられ＆これが仕様書だと言われ萎え
理解不能と開き直る今日この頃

リリース後の保守において、開発中に書かれた仕様書って見ますか？
今まで、保守に役立つ仕様書って一度も見たことないんです・・・

そもそも、保守に役立つ仕様書を書ける技術者が少ないんだよ。

>>124
そんなわけあるだろう（ｗ
日本語でソフトを書くのは大変なんだぞ？　ｍｉｎｄとか。

>>129
>>123のどこを読むと、日本語でソフト(つか、コード)を書くって
話がでてくるのーん?

>>130
数学者の言語が数式であるように、プログラマなら
コードが言語であるべきだと言ってるわけだ（ｗ
自然言語は物事を正確に伝えるには不正確すぎる。
わかった？（ｗ

>>128
ですよねぇ？
だから、「保守の役に立たない物を仕様書と言ってしまっていいのか」
と常々思っている訳です。ﾍﾟｰﾍﾟｰの戯言ですが。

>>132
言わなきゃいいじゃん。
仕様書は未来の自分への贈り物だよ（ｗ

>>131
「おれは腹が減った。めしを食ったら寝る」
を好きなプログラミング言語で正確に伝えてみてくれ。（ｗ

>>134
sig_handler(Signal sig) {
if (sig.isHungry()) {
sig.man.eat();
sig.man.gotoBed();
}
//...
}

>>135のコード、>>134のニュアンスとは違うような気がするのは漏れだけですか?

つーか>>134も>>135も、暇人ですか?

>>134
ほーら、自然言語の不正確なこと（ｗ
腹が減ったの定量的定義が無い、めしを食ったらの終了条件が不正確
などまるで何をしたいのかわからんわ！

そんなこと言う奴はプログラマとは認められんね。
プログラマの会話なら、
「血液１０ｍｌ中の血糖値が４％を割った時点で、経口食料の摂取
または点滴の注入を開始し、血糖値が１０％に上昇した時点で、
ベッドに赴き副交感神経に制御を渡し、乳酸の血中濃度が
規定値以下に回復したのち交感神経をブートする」とすべきだ。

当然ながら、これは概略であって実際には食事には
スプーンを使うのか箸を使うのか、腕の制御をどうするのかなど
決めなければいけないことがテンコもりなわけだ。

腹が減ったら飯を食うなど要求ならんわ！修行がたらん！

>>138
＞要求ならんわ　−＞　要求仕様にもならんわ　の間違いでつ。
また、若干不適切な表現があったことをお詫びしまつ（ｗ

>>138　GOOD JOB 乙！
誰か仕様と実装の乖離の実例で、ひっくり返りそうなのをキボンヌ。

【設計書は】ＤＱＮメント【ソース】

>>140
ありがちなネタだが、うちの会社の『会社案内』とか、『事業計画計画書』
とか、笑えるぞ。笑えないけど。

あと>>134の問題をよく読むと、if文なんていらないんじゃ。
腹が減った時（後）の処理だろ。
say, eat, goToBed の実行だけでいいだろ。

メシがない → エラー時処理なし → 暴走もしくはフリーズが仕様
スパゲティを食べるのに箸しかない → 気にせず処理継続
寝る → 特に処理を記述しなくてもシステムダウンするハード仕様

仕様書はメンテしてないのでソースを見てください。

仕様書をメンテする工数を割り当ててください。

>>142 学生向け就職雑誌とかも笑えるかも。見たくないが。
いや、それより、>>134の回答がよくできている。
if文をつけると「サービス工数」となり生産管理面に支障が出るな。

プログラムの工数は削減できるけど、ドキュメント書く工数はなんともならない。

>>146
ある程度は自動化できるぞ。

ソースの場合、コメントも重要だけど、 const , private などちゃんと
つけてほしい。

>>147
例えば？

>>149
テキスト→MS-Word変換ツール作って体裁や用語を統一したり。
もっと良いものあると思うが、うちはそういう自作ツールでやりくりしてる。

上のほうで未だにフロ−チャート云々とあったけど、
HCPチャートなんかは既に過去の遺物でつか？

>148
ちゃんとつけてほしいって・・・つけないほうが異常でわ。
コーディング規約で縛ってでも付けないと保守で地獄を見る。

っつーか付けずに開発してる時点でDQNだろ・・・

>>144
だよな？　うちも仕様書メンテする時間もらえてないわ。
つーか、下手すると仕様書作成する時間ももらえない時がある。
腐ってる。

仕様書無しで開発できること自体が驚き。中小零細の極小規模プロジェクトか？

>>154
大きいプロジェクトも仕様書無しとほぼ同じ状態。
プロジェクトの進行に合わせて作られていくんだから。
参加人数は200人程度なので中規模くらいか。

>>155
それは仕様書無しとは言わんだろ。正式な文書化がされていないだけ。

ホワイトボードのコピーが廻ってくるだけ、とか？

ちゃんと章立てされて、ページが振られて、目次・索引がついてる物以外は
仕様書とは認めないと？

>157
よくある

>>154
未だにウォーターフォールモデルか？　おめでてーな（ｗ

>>160
仕様書==ウォーターフォールモデルか？　おめでてーな（ｗ

>>all
新年明けました？おめでてーな（w

分かりやすいマニュアルの書き方という本があったはず…

>>161
設変のたびにソースと仕様書の２重変更か？　工数倍かかっておめでてーな（ｗ

いやぁ、めでたい。めでたい！

>>164
>設変 ってなに？とりあえずおめでてーな（ｗ

>>166
設計変更ってやつだよ、おめでてーな（ｗ

>>167
ありがとん、おめでてーな（ｗ

（ｗ使うやつってホントおめでてーな。

いまごろ新年かおめでてーな。

この板で一番めでてースレじゃないのか？　それだけでおめでてーな（ｗ

ちょっと前に流行った(?)
「お前らおつかれさまです」
を思い出したよ。

殺伐とﾏﾀｰﾘの同居たぁ、これまたおめでてーな（ｗ

（＾＾）

うちの製品はいっつも納品した後に仕様書書いてるよ。
上司が思いつきで仕様変更した証拠を残さないために
議事録の記録も禁止してるしな。まったくおめでてーな。

自分は入社当時は「何でこの会社は仕様書もないんだろう」と途方にくれていた。
「仕様書はソースだ」って冗談交じりの言葉に「ハァ？」と内心声を上げたものだ。

仕様書がある場合もあったがそこには中途半端にロジックが盛り込まれており実装す
るにはあまりに...と感じるものが多かったので大意のみ読み取り、大半の情報は仕様
作成者との会話でまかなっていた。

数年たち、いくつか実績をあげて開発プロセスの見直しでいくつか意見を上げた。
文書の形式も徹底的に口を出した。
覚えたてのUMLを導入しいくつかのドキュメントのフォーマットも提示した。
周囲は概ねそれに賛同した。自分自身論理的なドキュメント体系に酔っていた。
そしてそれを引っさげて第一号プロジェクトに取り掛かった。

今度は自分がドキュメントを書く役割になった。
しかしそこにあったのはあまりに遠回りで役に立たないものに時間を割いているとい
う徒労感だった。直接コードを書けば10分のことを形式に当てはめ日本語化するのに
1時間以上の時間を要するのだ。時にはコードを書いて考えることもあった。
書き上げた仕様書は見た目には美しく立派だが大切なことの20％しか盛り込まれてい
ないという確信があった。もし自分がこれだけ渡されても会話を多くしなければ完成
させる自信はなかった。
日本語で書かれた文書はコンパイルすらできないし、ましてや動かしてテストをする
ことも動作ログを確認することもできない。

一式のドキュメントを渡されたプログラマの口には出さない苦悩が手に取るようにわ
かり心苦しかった。

2週間後プログラマは｢一応動作します」といってプログラムをもってくる。思ったと
おりの出来だ。意図はほとんど伝わっていない。しかしプログラマの責任ばかりでは
ない。どちらかといえばプログラマは実に忠実で優秀な人物といってもいい。最大の
問題はプログラマは外注であり過去の生意気な自分のように仕様作成者に意をとなえ
て来なかったことだ。
結局長い時間をかけコードをレビューし、改善点と仕様変更などを再びドキュメント
化してプログラマに渡す。第一版よりマシな仕様書になっただろうが、もし自分が直
接コードに手を加えたら残業をせずに毎日帰ることができただろう。
そしてまた不具合がみつかり仕様書をなおす。この時点でもうドキュメントの情報は
コードの挙動とは少しずつ違ってくる。ドキュメントが追いつかない。
もしプログラマのとなりに座っていることが許されるのなら手書きの図とともにコー
ディングをさせつつ説明して、時には自分で組めば3倍は早く進行している気がする。
システムが組みあがったころにはドキュメントは「最初はこういうつもりだった」程
度のものに成り下がるだろう。たっぷり時間を与えてもらってもその作業は勘弁して
欲しいが。。。寧ろ新しく要点を簡潔に書きたい。

しかし、もし全くドキュメントがなかったらどうなのだろう？
新規参入者は取っ掛かりがないだろう。しかし、あのドキュメントがあっても新規参
入者は長い時間かけて読みつかれて「実際はどうなっているんですか？」と聞くレベ
ルになれるだけだろう。

何が必要なんだ？　いつ必要なんだ？

まず開発中に必要だ。メンバー同士共通部分をそれぞれ開発する無駄を省きたい。
しかし、それは形式ばったドキュメントよりもサンプルコードと最初の数10分の指導
の方が効果的ではないだろうか？

システムの大まかなアーキテクチャを残したい。
これは残すべきだろう。何をするものでどんな構成をとり、何に基づいて。

プログラマに仕様を伝えたい。
それよりも前になぜプログラマを積極的にヒアリングに参加させないんだろう。
分析よりの人間は業務の流れを頭の中でまとめるだろうし、プログラマは断片的に実
装方法をその場で思いつくはずだ。

後の変更のために。
どっちみちコード理解しなくてはならない。わかりやすいコードをコメントのほうが
よっぽど役に立つ。

あー、これ前も議論したな。
この情報が一番重要だと思う。
オープンソースの連中は顔をつき合わせることのほうが少ないから、MLベースで話す
のでアーカイブされるが、同じ部屋の連中の会話をMLに制限するのはあまりにばかば
かしい。議論をカテゴリと全文検索が可能な形でアーカイブしたい。

以上、書きたくってやった。

以前、ＶＢで作る画面のプログラム仕様書の一項目として、
フローチャートを要求されて激しく困りました。

>178
>メンバー同士共通部分をそれぞれ開発する無駄を省きたい。

こんなことしちゃうチームってホントにあるの？

優秀なチームはするだろ。

いろんなやり方がある（ｗ　どっちもやり方次第。

１．ドキュメントなし。打ち合わせ中心。
２．ドキュメントが全て。　ＰＧは完成するまでどのような
　　ソフトが組みあがるかすらわからない。

どっちも成功したよ。　目標性能がでた。
ま、やり方次第。　どちらが正しいというものでもない。

　　 ∧,,∧　 　>>175-178
　　,ミ ﾟДﾟ彡
　 ﾐ　　∪　　　どこからのコピペですか？
　ﾐ〜,,　ﾐ
　 ∪ ∪

XPを読むと、一時発作的に楽になりそう。
プロジェクトをうまくいかせるヒントがいっぱい載っています。

XPの完全実現は難しいですが、
昔の自身より、おりこうさん、にはなれると思われ

　　　∧,,∧　 　　 ／漏れはXP的ﾄﾞｷｭ無し推奨派なんですが
　　 ミ；ﾟДﾟ彡　 ＜　上司(非技術)が、USO800とか
　　 ﾐU　 U　　　　＼意識し始めたみたいでし・・・・
　〜ﾐ　 　ﾐ 　
　　 ∪''∪　「SRS仕様書/SDS仕様書/V&V仕様書が、重要」
　　　　　　　とわけわかな事言ってます。

　　部署で誰もロクにプログラムが組めない状態で
　　1ヶ月でできると見積もられたものが
　　5ヶ月かけて、10倍の金つぎ込んでもまだ出来なくて
　　あげくに「外注が悪いから、外注変えよう。そうしよう」
　　という意見が平気にまかりとおる会社なので

　　仕様書とかより遥かに重要な何かが忘れられているのですが

　　とらあえず、ナンタラ仕様書っていうのはそれぞれ
　　どんなものなんでしょうか？

　　知ってたら、簡単に教えてくださればうれすぃす。

>>185
ドキュメントの種類や名前は会社によってかなり違うから一般的なことは
言えないけど、よくあるのはこんな感じ。

「要求定義書」
システムが満たすべき要求を定義したもの。通常機能要求と機能外要求(性能とか
ハードウェア、ソフトウェアの制約とか)を記述する。

「外部仕様書」
ユーザ側から見たシステムの仕様を記述したもの。要求定義書と一緒になっている
場合もある。Delフサギコ氏が大好きなXPのユーザストーリはこれに当る。
＃個人的には優れた「マニュアル」が一番よい外部仕様書だと思う

「基本設計書」
システム全体のアーキテクチャを記述する。コンポーネントの構成、配置、コンポ
ーネント間の関係の定義などがメイン。

「詳細設計書」
各コンポーネントの実装に必要な情報を定義する。中身はUMLだったりER図だったり
関数のインタフェース定義だったり使用する言語やソフトウェアによって様々。

>>184
XP本の小話みたいに実話を自作自演

>>「基本設計書」
その内容にその呼称はないと思う。

>>コンポーネントの構成、配置、コンポーネント間の関係の定義などがメイン。
なら内部設計書ではないのか。

仕様を満たす設計が書かれているものは設計書だが、
要件を満たす仕様を設計し、それを書いたものは
仕様書か設計書か・・・

>なら内部設計書ではないのか。

「内部設計(書)」っていいますか? 「内部仕様(書)」なら聞きますけど。
でもドキュメントとして「内部仕様書」といわれるものを作ったり見たりした
ことはちょっと記憶にないですね。

>要件を満たす仕様を設計し、それを書いたものは
仕様書か設計書か・・・

下流の担当者にとっては上流の成果物が「仕様」になりますから、上流から見れば
設計書、下流から見れば仕様書ではないかと。

>>189
例えば、情報処理技術者試験センター・スキル標準
ttp://www.jitec.jipdec.or.jp/1_17skill/skill_00.html
の「ソフトウェア開発技術者」の
項番1.4(1)を見てください。


上の方にある「ソフトウェア開発技術者」をクリックしても跳ばないブラウザもありますが、
そういう時は気にせず下にスクロールして下さい。

♪詳細設計なんて〜　基本設計と一緒さ〜♪
♪書類は厚さが勝負〜♪（これが大事〜！）
♪でもでも概要しか書けないよ〜ん
♪協力会社も同レベル〜
♪ぜんぜん違うのが出来ちゃった〜
♪徹夜残業休日出勤品質メチャクチャ〜バグだらけ〜
♪忙しいから〜異常系は省略さ〜
♪らららら〜〜500人月のシ〜ス〜テ〜ム〜〜〜♪

仕様書工房とかどうよ。

>>192
クソ。機能が中途半端。結局手作業の方が早かったりする。

それぞれ説明できる人

ED書
PD書
ID書

>>185
> 漏れはXP的ﾄﾞｷｭ無し推奨派なんですが
俺はXP的ドキュメント推奨派だな

小さなプロジェクトならドキュメントが無くても何とかなるかもしれないが、
中規模〜大規模になるとドキュメントは必要。
直接民主主義は小人数ならは成功するが、大人数になると破綻する
XPもそれと同じ。規模が大きくなると建築物に設計図が必要なように
プログラムにも仕様書が必要になる。
特に建築と違い仕様変更が頻繁に発生するソフトウェアには必要と感じる。

ただ、残念ながら必要なことはわかっているのだが、
何を書けばよいのかが試行錯誤の状態。>>175-178が俺の苦悩と一致する。

例えばCやJavaなどの言語仕様、あれは仕様書なのか？要求定義書なのか？
それに対し、ソフトウェア開発技術者の俺はコンパイラを実装するとしたら
何を書けばよいのだろう？
多分、ソース以外の何かが必要になる。それが設計書なのだろう。

もう少し書く
直接民主主義は大人数になると破綻する。
同様にXPも大人数になるとうまくいかないことを著者自身も言っている。

すると、中規模より大きいプロジェクトは間接民主主義性にならざるを得ない。
最終的にはSE、PG、テスタがそれぞれ仕様を作る、仕様を実装する、
仕様と実装が乖離していないか確かめるという役割を持つ
三権分立制であることが望ましいだろう。

また、それぞれの役割を果たすことのできるスキルがあることが
上記制度で成功させることの前提条件になる。

>>196
あなたにフレキシブルという言葉をプレゼントしよう。よく噛んで食すように。

効用：硬直化した思考、組織をふんにゃりさせます。

>>197
それだけで組織がうまく機能するようになるなら誰も苦労しないわな。

規模の大きいプロジェクトだとしても、あるセクションごと(例えばサブシステムごと)
等に分解すればXP適応できる規模まで落とし込めるんじゃねーかな、と思う今日この頃。
実際それでやった例を聞かないんでどうかとも思うけど。

あ、ドキュメントの話か。
XPは「紙の」ドキュメントが無い、っていう認識でいいんだよね？
なんかXPの話がでてくると「ドキュメント」の認識の違いで荒れちゃう傾向にあるようなので。
最初にﾊｷｰﾘさせたほうがいいと思う。

>195
>何を書けばよいのかが試行錯誤
たぶん何処もそうでしょうな。
だいたい、必要なドキュメントなんて読む人の立場(SE/PG/ユーザ･･･) でいくらでも変わってくる
モンだから、定型的なものに収まるっていう事自体がなんか違ってるような気がする。
もちろん、最低ライン必要な事項はどんなプロジェクトでも共通化できると思うけど。

ドキュメント大好きなコボラーが、社内標準のフォームを使って書いたドキュメントなんざ
ほとんどの場合、最初1回読んだだけで後は紙クズだもん。

>>197
> あなたにフレキシブルという言葉をプレゼントしよう。
じゃあ君には秩序という言葉をプレゼントしよう。
官僚のような杓子定規な組織と朝令暮改の無秩序な組織
俺の理想はその中間に存在する。

>>199
> XPは「紙の」ドキュメントが無い、っていう認識でいいんだよね？
XPのドキュメントはストーリカード、ソース、ユニットテストで
構成されていると俺は認識している。
その前提で小規模システムならともかく、中規模以上のシステム開発には
それ以上のドキュメントが必要と俺は主張する。

反論どうぞ。

>>199
> 規模の大きいプロジェクトだとしても、あるセクションごと(例えばサブシステムごと)
> 等に分解すればXP適応できる規模まで落とし込めるんじゃねーかな、と思う今日この頃。
システムをサブシステムに分解する役割をもつ人物は誰？
また、変更が発生した場合、そのサブシステムのPG達に
伝言ゲームのように情報を変形せずに伝える人は誰？
もし、その人をSEと呼ぶのなら現状の制度と何が違うの？

そして、上記の役割を果たすことのできるスキルがあるSEを
選択できるクライアントの眼力も必要だろうな。

ウェブ上で設計書とかのサンプルとかない？
ネタにしようかと思ったけど、ググっても無かった・・・

>201
XPでは「最低限これ(カードやテスト)は書こう」、そして「無駄なドキュメントを書くのをやめよう」
っていう事を定義しているだけで、「それ以上のドキュメント」に関しては特に触れていないん
じゃないかな。
必要であればどんどん取り入れる(XP外の方法でも)っていう考え方がXPだと思う。
だから、「今までvsXP」みたいな考え方をしていると不毛だと思う。

XPを深く勉強している訳じゃないんで想像です。スマソ。

>>204
> XPでは「最低限これ(カードやテスト)は書こう」、そして「無駄なドキュメントを書くのをやめよう」
> っていう事を定義しているだけで、「それ以上のドキュメント」に関しては特に触れていないん
> じゃないかな。
その通り、そして>>185は
> 漏れはXP的ﾄﾞｷｭ無し推奨派なんですが
ということに対して>>195で「俺はXP的ドキュメント推奨派だな」と言っている。

XP的には「無駄なドキュメントを書くのをやめよう」つまり、
「無駄でないドキュメント（設計書）は書こう」だと俺は思う。
そして俺は無知なので設計書が書けないことを告白し、君達に尋ねたい。

設計書って何？そしてそれはどうやったら書けるようになるの？

>>204
> 必要であればどんどん取り入れる(XP外の方法でも)っていう考え方がXPだと思う。
> だから、「今までvsXP」みたいな考え方をしていると不毛だと思う。
ん？そこは俺のXPに対する考えと違うし、少し俺の考えを誤解しているな。
XPは直接民主主義性みたく少人数だとうまくいく制度だが、大人数だといずれ破綻する制度。
今までの制度は君主制に近く、君主(SE)が有能だとうまく機能するが、
君主に多くの負担がかかりすぎ、君主(SE)が無能だとデスマーチになる。
そして、俺の提唱するのが>>196での「SE、PG、テスタによる三権分立制」だ
これだと各人に負担を分散できるのであまり有能でなくともうまく
機能する確率が高くなる。
ただし、この制度も各人が役割をこなせる一定以上のスキルがないと
まともに運用できないということを言っておこう。

大規模っていうのはどれくらいの規模のことをいうのだろう。

ドキュメントの不備を原因としてプロジェクトが破綻する規模。

>>194
工程の順番に並んでいないとするなら
External Design
Internal Design
Program Design

意味も書かないとだめなの？

>>208
それだと参加してるプログラマ・デバッガの人数が 2 桁で、すでにヤバいぞ。

♪デスデスデスデス　デスマ〜チ〜♪

ttp://village.infoweb.ne.jp/~fwgf2942/process/Proc.Dethmarch/Proc..Dethmarch0.html

おおざっぱだけど
仕様書は何を実現したいかを書き
設計書は実現したいことをどうやって実装するかを書く
と思っている

>>212
シンプルでいい！

>>207
> 大規模っていうのはどれくらいの規模のことをいうのだろう。
大規模は俺が体験していないので何とも言えないが、適当に定義してみると
小規模と中規模の違いは以下のように感じている。
　小規模：プロジェクトリーダがプロジェクト管理と設計を１人で行える規模
　　　　　XPの著者は10人くらいなことを言っていたが、俺のリーダスキルだと
　　　　　6人を超えると管理が難しくなる。
　　　　　おそらく俺がリーダの場合、10人だと破綻する。
　中規模：プロジェクトリーダがプロジェクト管理と設計を１人で行えなくなり
　　　　　プロジェクト管理と設計者の役割分担が発生する規模
　　　　　俺の場合、7人以上が相当する。
　大規模：（予想）プロジェクト管理者が１人で全員の進捗を把握できなくなり
　　　　　プロジェクト管理者の階層構造が発生する規模
　　　　　伝言ゲームが発生し、また生産に関わる以外の人員が多数発生する為、
　　　　　小規模と比べ、極端に生産性が落ちる。
　　　　　また、このプロジェクトのトップリーダにはかなりのリーダスキルを
　　　　　要求される。

一桁が小規模、それ以上が中、大規模と。

SE/PGからみた場合は開発だけの作業に必要な規模かもしれないね・・・

でも瑕疵責任範囲のリカバリーまで考えると、

小規模：ミスったときは最悪営業どんに謝ってもらえばなんとなっちゃうレベル

中規模：ミスったときは最悪社員総出でリカバリー作業をすればなんとかなっちゃうレベル
　　　　　（自動倉庫で制御ミスって倉庫への入れ方がめたくたになってしまった　等）

大規模：ミスったときは新聞沙汰になってしまってどうしようもないレベル
　　　　　とりあえず社長には相手先の社長さんクラスの人のところにいって謝ってもらう
　　　　　（発電所とか銀行オンラインとか）

>>216
あとは人数以外でも、参加者の構成もあるよな。

A) 一人管理者がいて、全員その指揮下に入ってる。（トップから現場まで 1hop)
B) 複数の部署に分かれていて、各部署に管理者がいる。(トップのお偉いさんか
　　ら現場まで 2hop)
C) 複数の企業に分かれていて、契約関係はあものの基本的には独立した組織
　　になっている。(トップと現場は分断されてる)

もちろん C は中規模だろうが、外注が一社はいるだけで発生するけど。同じ規模
の開発といっても、顔の見える範囲の人間で開発してるか、外注が関わってくるか
で、プロジェクト管理の難しさはかなり違う気がする。

♪「設計」できないエンジニア〜♪
ttp://village.infoweb.ne.jp/~fwgf2942/LectureSE/LecSE.NoDesign.html

ところで、おまいら、ソースコードレビューはやってますか？
やってたら以下について教えてください。
・レビューするときのメンバ構成
・閲覧メディア（紙、モニタ、プロジェクタ、…）
・手順とかチェックポイントとか
・その他

>>219
> ところで、おまいら、ソースコードレビューはやってますか？
やる場合とやらない場合がある。
少なくとも初めてチームに入る奴、複雑な処理を行うものについては絶対にやる。
おそらくそいつのスキルでは楽勝だと思われるものについてはやらない。

> ・レビューするときのメンバ構成
原則として全員、新人でも誤字脱字などの指摘をしてくれることもあるし、
また、他人のソースを読ませることは教育の一環になると思っている。

> ・閲覧メディア（紙、モニタ、プロジェクタ、…）
紙（ソース、設計書、コーディング規約）

> ・手順とかチェックポイントとか
頭から順番にソース作成者に設計書と照らし合わせて説明してもらう。
チェックポイントは
・コーディング規約に準拠しているか
・設計書通りに実装されているか
・説明できない変な処理／冗長な処理はしていないかどうか
・リソースのリークを起こしている箇所はないか

> ・その他
指摘箇所が多いと修正後再レビュー、あまりにも多すぎると途中中断、書き直し。

>>220
ありがと。参考になります。
来月からプロジェクト管理をまかされることになったので、
先達のやり方を聞きたいと思ったのでした。

ところで、
> 原則として全員
これはたしかに効果的だとは思うんだけど、時間がかからない?
一回あたり、どのくらいの時間をかけてますか。

レビューは確かに時間がかかりすぎるよな。その割に効果薄いし。疲れてくると結局見落とすこともある。

俺はUniTestさえしっかりやっていればソースレビューはほぼ必要ないと思う。マンパワーが余っているなら積極的にやるべきだけど。
紙に印字する手間も馬鹿にならないし。

まぁ自動化できない部分はどうしても残るし、そこはレビューするしかないんだけど。

最近は、NetMeetingでPCつないでやってますかねぇ。。。<レビュー関連

>>221
> これはたしかに効果的だとは思うんだけど、時間がかからない?
> 一回あたり、どのくらいの時間をかけてますか。
正直、午前中は全員作業ができない。午後に持ち越されることもある
2時間〜4時間ぐらいかかる。またチーム全体を見なければならないので
ほとんどの午前中はソースコードレビューに費やされた。
（6人以上は破綻すると言ったのはこれが理由の多くを占める）

>>222
> レビューは確かに時間がかかりすぎるよな。その割に効果薄いし。疲れてくると結局見落とすこともある。
それは言える、午前中に終えられないレビューは効果が薄いように思える。
多分、モジュールの分割が大きすぎるか、指摘事項が多すぎるかのどちららかが原因だろう。
そこはXPのペアプログラミングに期待しているのだが、それはチーム全員が
「綺麗なソースとは何か」を知っていないと機能しないと思っている。
そして俺の職場では残念ながら「綺麗なソースとは何か」を知っている奴は少ない。
なので、ソースコードレビューでまず意識を統一しておく必要がある。
それが達成できたらペアプログラミングを実行したい。

気がつかない間に
　ミ,,ﾟ∀ﾟ彡ｲｲスレに・・・

>225 もともと良スレかと・・・。

XP本を読み直してみた。
やはりXPは「チーム」が存在することを前提として書かれている。
チームとは、
・各人がリーダのやりたいことを正確に理解していること
・各人が忌憚なく意見を言える環境であること
・各人が一定のスキルを持っていること
だと思う（不足があったら指摘してくれ）

例えば、サッカーなどは4-4-2とか3-5-2などのシステムがある
このシステムを選手全員に理解させられないとチームとして機能しない。
また、選手同士の仲が悪かったり、逆に馴れ合ってなあなあで済ませてしまうと
強いチームにはなれない。
正確にパスが出せない選手や、あらぬ方向にシュートする選手、
１０分でバテてしまう選手は少なくとも「プロ」の選手ではない。

サッカーの場合、チームとして優れているか、劣っているかは
他のチームと試合をすることによって客観的に認識できるだろう。

だが、現在の俺のプロジェクトチームはシステムがいい加減だし、
プロジェクトが変わるたびに人員も変わってしまう為に１からチームを
教育しなおさないといけないし、何より普通のサッカー選手は「練習」
をしてるはずだが、普通のプログラマは「練習」などせず、
いきなり試合（プロジェクト）に放り出され、試合で学んでいかないといけない。

これではプロジェクトが成功する方がおかしい。
俺にはXPより先にやるべきことがある。「真のチーム」を作ることだ。
だが、どうやって「真のチーム」を作ればいいんだろう．．．

まずはプロジェクト毎に人員が変化しないように上に相談してみるか。
他に何かアドバイスがあったらよろしく。

>227
まあ、そうでしょうな。
XPって、短期契約/少数精鋭型・・・要はアメリカ的な雇用形態の中で生まれて来たものですから。

>チームとは
「結果を出せる集団」じゃないかな。
それぞれの項目は結果を出すための要素に過ぎないような気もする。
たとえ嫌なヤツとでもチームとして働き結果を出す事ができるヤシが「プロ」だと思う。
そういう意味で、「プロ」と呼べる人間がこの業界にどれくらいいるのかな・・・って考え
ると結構切なくなるな。(俺も含めて)

んで、
>・各人が一定のスキルを持っていること
そもそも、一定以下のスキルしかないヤシがプロジェクトに参加する事自体が異常なんだよね。
中には、まっさらな新人を工数にカウントしたりする会社もあるし・・・

一定という意味が違うような気がする。

「一低のスキル」
「一底のスキル」
「痛えのスキル」

>>229
> 「結果を出せる集団」じゃないかな。
うん、結果を出せる集団にするための条件としていくつか挙げてみた。

> たとえ嫌なヤツとでもチームとして働き結果を出す事ができるヤシが「プロ」だと思う。
うん、それはあまり好ましい状態では無いけれども、
チームとしてお互いに理解し合うことができれば「嫌なヤツ」と
思わなくなるかも知れないかなぁと希望を託してみる。

> そもそも、一定以下のスキルしかないヤシがプロジェクトに参加する事自体が異常なんだよね。
だよなぁ、医師みたいに一定の知識あり、かつ実務を何年か積まないと
プログラマ／SEと名乗れないようにするか。
サッカーみたいに１部リーグ、２部リーグと分けて、昇格しないと
１生プロジェクトを経験できないとか、そういうシステムになればいいのだが、

尻に火がついている俺の会社の状態じゃあ無理だろうな
会社じゃなくて大学に期待したいのだが、大学の情報工学も．．．
資格に期待したいのだが情報処理試験って名称が変わっただけで
内容は変化してない気がするしなぁ．．．。

ま、俺は俺がやれることをするだけだけどね。
取りあえず、俺は上司にチームの必要を訴え、チームを作る。
次に「本物のチーム」を作る。何年かかるかなぁ．．．。

差がありすぎるからねぇ。
平均レベルの人もレベル高いチームに入ったら、単なる役立たずに成り下がるし。

>>195-196
ちょっと面白かったのは、三権分立のたとえ。
立法＝SE
行政＝PG
司法＝テスタ
ってとこか？
で、国民＝顧客。

とすると、設計書は、法律ってことか？

>>212
わかりやすいですね。
仕様書＝What
設計書＝How
ですね。

>>228
うーん・・・
それは、会社の方針としてよくないです（よくあることは重々承知で）。
確かに、OJTという考え方もあるけど、
でも、それだけだとなりたたない。
試合（プロジェクト）の前には練習（トレーニング）をしないと。
XPトレーニングとかやれるといいっすね。

>>212,234

>>仕様書＝What　設計書＝How
は当然のこととして理解しているが、上位工程の設計書は下位工程の仕様書になりうる。
（例：要件定義書から外部仕様を設計する）

で、私的には
「顧客の情シス部門が技術的チェックを行えるドキュメント」
までが仕様書で
「顧客の情シス部門が体裁チェックぐらいしか行えないドキュメント」
からが設計書　とすべきだと思ってる。

つーか、他の産業の設計図とか仕様書は参考にならんのかのぉ？

小規模ならば、文句無くXP方式が最適（ドキュメント書く必要なし）なんだろうけど、
大規模の場合や、ライブラリ系（多くの人が使うようなもの）のドキュメントの書き方で参考になるのは
Eclipse Platform (http://www.eclipse.org) だね。JavaDoc の書き方も参考になるし、
他にもテーマ別に短いドキュメントが書かれてて、これは分かりやすいと思った。

用語の統一性のなさは結構ひどいなあと思います。
工程の名前も統一性がないが、文書の名前も統一性がない。

ITスキルスタンダードとかいう前に文書名を統一してほしい・・・。

>>235
了解。

>>237
さすがに、IBMが作っただけあって、その辺はしっかりしてそうだ・・・。

>>235
>は当然のこととして理解しているが、上位工程の設計書は下位工程の仕様書になりうる。
>（例：要件定義書から外部仕様を設計する）

要件定義書=設計書=How
外部仕様書=仕様書=What　ということ？

要件定義書=仕様書　だと思うんだけど
工程は要件定義→外部設計→内部設計で意識あってる？

>>238

工程の名称はJISだかで統一されているって噂を聞いた事があるけど…
知っている人います？

>>240
たぶんそれは「共通フレーム」だと思います。
98年版(SLCP-JCF98)が最新らしいです。
しかし、Webで公開せず書籍で販売しているところがお役所仕事。

ただし、そういうものがあっても、標準の遵守が強制的でないのが、
つらいところでしょうけど。

>>241
情報サンクス
ちょっと調べてみたら…　絶版なんだ、普及させる気がないのかなぁ
>http://www.esbooks.co.jp/product/keyword/keyword?accd=30465549

ないのでしょう

>>234
> とすると、設計書は、法律ってことか？
いや、要求仕様＝憲法、仕様書＝法律、設計書＝？（自分でも良くまとまってない）
「契約によるプログラミング」という考え方をもう一歩押し進めてみた。

> 試合（プロジェクト）の前には練習（トレーニング）をしないと。
> XPトレーニングとかやれるといいっすね。
例えば、２チームあるとして、１チームはプロジェクトを行い、１チームはトレーニングを行う。
これを交互に行ってチームスキルを高めてみたいと構想はしているのだが、
今の俺にはそんな権限はない。１平社員に過ぎない。

>>235
> で、私的には
> 「顧客の情シス部門が技術的チェックを行えるドキュメント」
> までが仕様書で
> 「顧客の情シス部門が体裁チェックぐらいしか行えないドキュメント」
> からが設計書　とすべきだと思ってる。
それだと顧客の情シス部門の技術スキルで仕様書と設計書の定義が
異なるんだよな。

もう少し客観的な定義が欲しいな。

>>239
ごめん。分かりにくかった。
「外部仕様を設計する」→「仕様を設計」→「設計して出来あがったものも仕様となる」
が言いたかった。
「外部設計→内部設計」の部分でやればよかった。

>>245
>>それだと顧客の情シス部門の技術スキルで仕様書と設計書の定義が
>>異なるんだよな。
「どの程度までを仕様とすべきかは、情シス部門のスキルに依存して良い」

もうすこし細かく説明します。
メーカーとしては、自社の基準、書式に従って
要件定義書→設計書→設計書→設計書→・・・
というように作成していき、情シス部門のスキルの範囲内のものを
(設計書兼)仕様書として「内容」レビュー有りで納品する。
＜＜＜仕様書に載っていないものは、設計品質をもって仕様として良い＞＞＞

今の顧客では、どこまでを仕様書とすれば良いか分かるのですが、
要件定義書(→仕様書群)→仕様書群→設計書群→設計書群→・・・
が完全にはできません。仕様書は形式が定められているため(メインフレーム万歳形式)
仕様書→設計書ができない部分が存在します。

>>246
「設計する」という言葉にこだわっているのでは？
「外部仕様を設計する」のならば出来上がったものは「外部仕様書」でしょ。
外部仕様を「策定する」なり「決定する」なりに言い換えるとどうなります？

>>メーカーとしては、自社の基準、書式に従って
自社の基準、書式が決まっていなかったり、各社バラバラなのが問題だと思う。
仕様書、設計書を作らないところもあれば、作ったとしても極端な話、粒度・掘り下げ形が
全然違うんだよね。
各人が思う仕様書、設計書の基準、書式とかってのが今の議論だと思ってましたが、違います？

>>246
> 「どの程度までを仕様とすべきかは、情シス部門のスキルに依存して良い」
> メーカーとしては、自社の基準、書式に従って
> 要件定義書→設計書→設計書→設計書→・・・
例えば、建築の世界だと設計図って全国共通であり、医療の世界だとカルテって書式がある。

要求仕様に関しては様々な形式があってもよいと思うが、
仕様書／設計書に関しては基準と書式を統一して欲しいという思いがある。

そういう意味では仕様書ではUMLが最有力候補かな。
クライアントが理解できるかどうかがネックになりそうだけど。

>>249
ユースケース図とかクラス図あたりまでなら、なんとかわかるかも・・・。
あとは、画面設計書のたぐいって、UMLにあったっけ？

　　∧,,∧　　わかるようなわからないような…
　 ミ；ﾟДﾟ彡
──┼──
　　　人
　 ／　 ＼
　　　　　　　仕様書はコンパイル通せないし
　　　　　　　テストケースも書けないから
　　　　　　　あまり好きく無いんだけど、
　　　基準や書式が統一されたときに
　　　夢物語を書いただけで仕様書を書いたつもりどころか
　　　ソフトを作ったつもりになれる幸せﾄﾞｷｭな
　　　　人を駆逐できたらいいな。

私も一時期、(客も含めて)業界標準の書式があったらいいな　と思っていました。
しかしこの業界、技術の進歩が早い。定めた標準より優れたものがすぐに出てくる可能性があります。
（UMLとて例外ではない）
よって、メーカー側は、その時点である程度メジャーで優れていると思われる書式で設計をしていく。
（＞自社の基準、書式に従って
　これは、全部自社で書式を作るという意味ではありません）
納品物，仕様の証拠として、顧客指定書式の仕様書を別途書く。
これで我慢するしかないのかな　と思うようになりました。
客にこの表記法を勉強して下さい、とは言えないし。
現在、書式の統一ができている分野は、書き方の技術の進歩が少ない分野
なのだと思います。


(今、私が納品している書式も、メインフレーム時代には十分な書式だったのでしょう。)

>>250
> 画面設計書のたぐいって、UMLにあったっけ？
ない。
適当に作って画面コピーで済ませてるが、リサイズされたときの挙動までは表現しきれないな。
まぁ、俺の関わった業務系は画面の大きさがリサイズできない仕様になっていたんで
問題なかったけど。

>>251
仕様書を書いてコンパイルをすると、クラスやメソッドが自動生成されることを
夢想している。メソッドの中身はプログラマが考える。

>>252
> 定めた標準より優れたものがすぐに出てくる可能性があります。
これは俺も考えた。10年前は「フローチャート＝設計書」だったもんな。

> 納品物，仕様の証拠として、顧客指定書式の仕様書を別途書く。
> これで我慢するしかないのかな　と思うようになりました。
表示形式などどうでも良い。スタイルシートを設定すればどうとでもなる。
他社との仕事をしていると表示形式は違えども記載しなければならない内容は大差ない。

例えば、システム全体で書くものについては
・システムフロー
・画面遷移図
・DB
・ディレクトリ構成
・ミドルウェア
・最低メモリ/最低ディスク容量
など
プログラム単位に書くものについては
・プログラム名/プログラムID
・入力ファイル/出力ファイル
・DBのテーブル名
・状態遷移図
・環境変数
・画面サンプル/帳票出力サンプル
今ざっと考えるとこんな感じかなぁ
もちろんDBを使わなかったり、画面/帳票がないシステムは必要ないものもあるけど

＜血液型A型の一般的な特徴＞（見せかけの優しさ・もっともらしさ（偽善）に騙され
るな！）
●とにかく気が小さい(神経質、臆病、二言目には「世間」、了見が狭い）
●他人に異常に干渉し、しかも好戦的・ファイト満々（キモイ、自己中心）
●自尊心が異常に強く、自分が馬鹿にされると怒るくせに平気で他人を馬鹿にしようと
する（ただし、相手を表面的・形式的にしか判断できず(早合点・誤解の名人)、実際に
はたいてい、内面的・実質的に負けている）
●本音は、ものすごく幼稚で倫理意識が異常に低い（人にばれさえしなければＯＫ）
●「常識、常識」と口うるさいが、実はA型の常識はピントがズレまくっている（日本
の常識は世界の非常識）
●権力、強者（警察、暴走族…ｅｔｃ）に弱く、弱者には威張り散らす（強い者にはへつらい、弱い者に対してはいじめる）
●あら探しだけは名人級（例え10の長所があってもほめることをせず、たった１つの短所を見つけてはけなす）
●基本的に悲観主義でマイナス思考に支配されているため性格がうっとうしい（根暗）
●一人では何もできない（群れでしか行動できないヘタレ）
●少数派の異質、異文化を排斥する(差別主義者、狭量）
●集団によるいじめのパイオニア＆天才(陰湿＆陰険）
●悪口、陰口が大好き（Ａ型が３人寄れば他人の悪口、裏表が激しい）
●他人からどう見られているか、人の目を異常に気にする（「〜みたい」とよく言う、
世間体命）
●自分の感情をうまく表現できず、コミュニケーション能力に乏しい（同じことを何度
も言ってキモイ）　
●表面上意気投合しているようでも、腹は各自バラバラで融通が利かず、頑固(本当は
個性・アク強い）
●人を信じられず、疑い深い（自分自身裏表が激しいため、他人に対してもそう思う）
●自ら好んでストイックな生活をし、ストレスを溜めておきながら、他人に猛烈に嫉妬
する（不合理な馬鹿）
●執念深く、粘着でしつこい（「一生恨みます」タイプ）
●自分に甘く他人に厳しい（自分のことは棚に上げてまず他人を責める。しかも冷酷）
●男は、女々しいあるいは女の腐ったみたいな考えのやつが多い(例：「俺のほうが男
前やのに、なんでや！（あの野郎の足を引っ張ってやる！！）」）

インターネットを使って無料でできるお金儲けの方法を紹介します。
基本的な仕組みは、広告を見ることによって報酬をもらえるというものです。
メールなどでスポンサーの広告を見ることにより広告費が視聴者に渡るようになっているのです。
お金儲けサイトはたくさんあるので、どれから始めればいいか迷うと思います。
そこで、すぐに収入がもらえるサイトを紹介します。
僕も４日で９００円ほど稼ぎました
下からどうぞ
http://www.chobirich.com/intorduce/?10653

>>253
＞ない。
ヤパーリそうだよね。
画面・帳票まわりはテストもしにくいし、やっかいだよね。

＞仕様書を書いてコンパイルをすると、クラスやメソッドが自動生成されることを
＞夢想している。メソッドの中身はプログラマが考える。
そういうツール、ラショナルとか出してない？
高いと思うけど。

>>251
書式を決める＝（書かなければならないことの）基準を決めるという意味で使ってた。
仕様書が夢物語しか書いてないのは不幸だよね。不幸にならないためにもそれぞれの仕様書、
設計書に書かなければいけない事、記述の粒度について共通の認識（＝基準）が欲しいと思う。
共通の認識があれば、仕様書レビュー時に基準に満たないものは却下されるだろうと思ってる。

で、基準を満たす仕様書、設計書を書くためにはかなりのスキルが必要って事なんだけど。

各仕様書、設計書に記述すべきと思っている概要はこんな感じ。
要求定義書＝顧客の要求について定義する
基本仕様書＝システムの共通基準（フレームワークは何を使うとか、エラー処理はどうするとか、
　　　　　　　　　応答速度など）を定義
機能仕様書（外部仕様書）＝要求定義書、基本仕様書を受けて、システムで提供する機能、
　　　　　　　　　外部とのI/F（画面、DB論理、ファイル、帳票）の定義
詳細設計書（内部設計書）＝基本仕様書、機能仕様書を受けて、基本仕様の共通基準を満たしつつ、
　　　　　　　　　機能仕様に定義されている機能をどのように実装するかを記述

>>253
画面仕様書にはリサイズしたときの挙動を定義すべき。という基準があれば
いいんじゃないかと思う。
リサイズ不可の画面であれば、それを１行書けばいいんだし。
リサイズ可の画面でリサイズ時の動作が抜ける事の方が致命的じゃないかな？

＞仕様書を書いてコンパイルをすると、クラスやメソッドが自動生成される
そのテのツールは一時期流行ったが、結局どれも主流にならなかったな。
どういう仕様書を書けばどういうクラスになるのか、またそれらのクラスを
どう使うのかというのを理解するのに時間がかかりすぎる事と、そのツールを
使用しない他のプロジェクトでは全く応用が利かないってのが原因だったと思うけど。
もちろん価格面の問題もあったとは思うが・・・

現実的に使えるものとしては、DB構造を読み取ってクラスと対応付けてくれる
レベルまでじゃねーかなぁ。WebObjectsだっけ？

WebObjectsは、実用レベルでDB構造をソースレベルのクラスに吐いてくれるよ。

>>257
> 画面・帳票まわりはテストもしにくいし、やっかいだよね。
どうしても自動化できんものの一つだな。

> そういうツール、ラショナルとか出してない？
知っているが、高すぎて手が出ない。purifyは必要なんで高くても買ったけど、
まだ自分でも必要かどうか分からないものに高い金を出して買うつもりはない。

>>258
> で、基準を満たす仕様書、設計書を書くためにはかなりのスキルが必要って事なんだけど。
さらに基準を満たす仕様書、設計書を読むためにはそれなりのスキルが必要だし、
基準を満たす仕様書、設計書を書ける奴を見分けるためのスキルも
管理者には要求されるな。

> 画面仕様書にはリサイズしたときの挙動を定義すべき。という基準があれば
> いいんじゃないかと思う。
今のところ、リサイズの要求自体が発生していないので基準が読めない。
もし、リサイズの挙動を仕様にするとしたらどうする？
いまのところリサイズ時の挙動を設計できるのってJavaの
レイアウトマネージャぐらいしか思いつかない。
しかし、あの処理をC++とかで実装するのって面倒な気がする。

　 ∧,,∧
　ミ；ﾟДﾟﾐつ
>もし、リサイズの挙動を仕様にするとしたらどうする？
小さいのと大きいのと
画面を2毎くらい貼り付ければヨシと。
>>259さんに同意

>>>257
>> 画面・帳票まわりはテストもしにくいし、やっかいだよね。
>どうしても自動化できんものの一つだな。
やっかいですよね。
いちおう、経謙譲、部品ごとに、テストを手動で行える
サンプルプロジェクトを作ると、かなりバグは減ります。

>>239さんのと同じような死要所ルールが出来かけていますが
それを作りこむのに、倍くらい工数が欲しいこの頃

>>238-242
工程の名称，SLCP-JCF98
http://www.juse.or.jp/software/pdf/17dep4b3.pdf

ドキュメントの名称は>>254のような個々のものを使用し、
その顧客の理解できる種類のドキュメントの集まりを以って仕様書とする
のが私の理想です。

〜(工程名)設計書という名称は、その範囲があいまいなので避けるべきだと
思います。どうしても使用しなければならない時は、情報処理技術者試験
で使われている名称(外部設計，内部設計)がベターでしょう。
（上記SLCP-JS98は全然普及していませんし、>>258の
　基本→機能→詳細は日立臭いです。構造設計があるともっと日立です。）

いま思い付いたんだけど、>>254みたいに　書いた方が良いことを
どんどん挙げていけば、「仕様書に載せたほうが良い項目集」ができるんじゃないか？

まず言い出しっぺとして
・画面入力のチェック
・そのチェックが行われるタイミング
・メッセージ（チェックにひっかかった時のものも含む）
・コントロールのenable,disableが変わるタイミング

>>263
> さらに基準を満たす仕様書、設計書を読むためにはそれなりのスキルが必要だし、
> 基準を満たす仕様書、設計書を書ける奴を見分けるためのスキルも
> 管理者には要求されるな。
うまく言えないけど、効率的・仕様変更につよいソースを書くためにはそれなりのスキルが
必要だし、それを読む・理解するためにもスキルは必要だし、書ける奴を見分けるための
スキルも管理者には要求されるのと同じ事だと思う。
この業界、正当に評価できる人がいないのが一番の問題かと。
で、仕様書や設計書を書く人が駄目駄目だと攻撃されるのは影響範囲が広い（駄目駄目な
プログラマは担当のプログラムだけ破滅に導くけど、駄目駄目なSE（設計や仕様策定者って
意味ね）は多数の（優秀な人も含む）プログラマ、顧客を破滅に導く）ってことだと思う

> 今のところ、リサイズの要求自体が発生していないので基準が読めない。
リサイズ可能なものもあるというのは容易に予想できるから、あらかじめ基準を決めておけば
いざりさいずしてね(^^)って仕変があっても、それが原因でデスマーチになることは防止できる
んじゃないかな？
「こんな事もあろうかと用意しておく」真田さんパターンで（古い？）

>>264
同意していただいてthx

> >>239さんのと同じような死要所ルールが出来かけていますが
> それを作りこむのに、倍くらい工数が欲しいこの頃
工数少ないから文書類書いてる暇はないってのは俺も昔そうだったからわかるけど、
上流（って言葉は嫌いだけど）で時間をきちんとかけた方が、結果的には皆の負担が
へるよ。
きちんと仕様がきまるまで製造をさせない強い意志を持ったリーダーと、バケモノみたいな
スーパーPGがいないとなかなか難しいけど…

この業界って会社単位で文化、標準が決まっていて常識がたくさんあるからね。
「そんな事無駄だよ」って強行に言い張っていても、結果的にうまくいけば「そんな方法が
あったんだ」って実感できる。もっと会社を越えた交流が必要じゃないかな

>>266
・入力となるデータ
・出力するデータ
・参照するデータ（マスタとかね）
・入力データから出力データを作り出すためのロジック

ってのはどうでしょう？
入出力は>>254にも書いてあるけど、ファイルだけでなくパラメータとかDBとかも
含めてデータと書いてみました

　　　　　　　　　　　　　　　　＿＿＿＿＿
　　　　　 ∧,,∧＿__　　　／けさ、歩行しながら
　　　 ／ミ,,ﾟДﾟミ／＼＜　　考えてたのですが
　　／|￣∪∪￣|＼／ 　＼＿＿＿＿＿
　　　 |＿＿＿＿|／
　　　 　,,,,∪∪,,, ,,
設計書(図)と、出来あがった製品の"仕様"書ってのは
全く異なるものだと、思うですが、
現実のソフトウェア開発は、どこでも
これが全く同じく扱われてるすよね。

"仕様"通りのものが出来ると仮定して
プロジェクト進行させるのがそもそも難しい

いわゆるソフトウェアの仕様書は
ソフトを作った事が無い奴が書くことが多くて
(というか、作れない奴が作らせる為に書くことが多くて)
内容が
"夢"非現実的な希望"論理的に矛盾のある機能"あいまいな記述"
が、山盛り。

で、重厚な仕様書をソースを書く前に仕上げてみても
結局は、ﾌﾟﾛｼﾞｪｸﾄ進行するにつけて
”現実の実装コードとは乖離”するわけだから
仕様書はライトウェイトな、記述がよろしいのではないかと
思ったりする次第です。

> 工数少ないから文書類書いてる暇はないってのは俺も昔そうだったからわかるけど、
> 上流（って言葉は嫌いだけど）で時間をきちんとかけた方が、結果的には皆の負担が
> へるよ。
　　　　　　　　　　　　　　　　＿＿＿＿＿
　　　　　 ∧,,∧＿__　　　／
　　　 ／ミﾟДﾟ,,ミ／＼＜　　なかなか一歩が踏み出せないです
　　／|￣∪∪￣|＼／ 　＼＿＿＿＿＿
　　　 |＿＿＿＿|／
　　　 　,,,,∪∪,,, ,, 　　足は付いてるはずなんですが。。
---------------------
書きなれないから、仕様書書く時間を体感的に見積もれなくて
慌てて、"暇がない"って思い込んでいる状態なのかもしれません。
でもとにかく、目の前に実装する事がはっきりと分かっているときに、
仕様書に時間をかける暇はやっぱないです、、(今のは個人でまわしてる実装だし)

ほですが、プログラムが終わっってから仕様書を書こうとすると、
次のプログラムを組めといわれる罠が待ってます･･･(涙

そもそも、技術者同士で話をする場合は会議の段階で
出来上がりのソフトのイメージが、互いに脳内にはっきりと
現れるので、形式ばった書類が無くても意思疎通ができ、
開発は進む(と思われ)んだけど、
そこに、お客さんやエスヨのあいまいな要望が入ってくるから
形式のしっかりした仕様を決めた書類が必要になってくるんだろうな。

(※だからプログラムの分からなさげな、上司が
　仕様書をかけかけといってくるんだよな、、と今気が付いた。）

あと、複数人でやってると、サボル奴が出てくるから、
各人の担当はしっかり決めた方がいい部分はあるかも(今それで苦労中)

> この業界って会社単位で文化、標準が決まっていて常識がたくさんあるからね。
> 「そんな事無駄だよ」って強行に言い張っていても、結果的にうまくいけば「そんな方法が
> あったんだ」って実感できる。もっと会社を越えた交流が必要じゃないかな
　　　　　　　　　　　　　　　　＿＿＿＿＿
　　　　　 ∧,,∧＿__　　　／XPを結果的に認めさせたいのだけど
　　　 ／ミﾟДﾟ；ミ／＼＜　　開発がわかってない人らは
　　／|￣∪∪￣|＼／ 　＼その利点を認識するどころか、
　　　 |＿＿＿＿|／ 　　　　そもそもProjの遂行度の評価が
　　　 　,,,,∪∪,,, ,, 　　　　　出来ないんだなあと、経験してる日々。

しっかりとした仕様書は
「ソフトが完成してからじっくり書くもの！」
と、思うているのですが、やっぱ変でしょうか？
※ただし意思疎通の為の形式ばらないメールのやり取りや
　瞬時に書き変える事が出来る、機能の箇条書き(ｽﾄｰﾘｰｶｰﾄﾞ)
　は設計図として用いたい。

239さんの出していた>>258の基準を私的に勝手に解釈すると、、、、
> 要求定義書＝顧客の要求について定義する
客の夢物語を書いてみる。夢なので、現実にはとりあえず無視る。
どうせ無視るので、適当にかけるので躊躇なく適当に機能を羅列・箇条書きして終了
> 基本仕様書＝システムの共通基準（フレームワークは何を使うとか、エラー処理はどうするとか、
> 　　　　　　　　　応答速度など）を定義
とりあえずシステムの概要を書く
ＹＡＨＯＯの概要だったら、・検索サイト・広告ｲﾊﾟｰｲ・天気予報とか・新聞に変われる情報源
Ｗｏｒｄの概要だったら、・ワープロ・仮想紙
こういう感じかな？
> 機能仕様書（外部仕様書）＝要求定義書、基本仕様書を受けて、システムで提供する機能、
> 　　　　　　　　　外部とのI/F（画面、DB論理、ファイル、帳票）の定義
画面イメージ、画面遷移、DB設計など、適当に書いてみて、
> 詳細設計書（内部設計書）＝基本仕様書、機能仕様書を受けて、基本仕様の共通基準を満たしつつ、
> 　　　　　　　　　機能仕様に定義されている機能をどのように実装するかを記述
「これやる、あれやる、それやる」レベルの箇条書きにしちゃう。


つきつめると
機能仕様＝ユーザーマニュアル
詳細設計書＝プログラム設計書
になれると思うのですが･･･
|,,∧ 　　やっぱ
|Дﾟ彡　 無茶かナア
⊂ﾐ
| ,;ﾞ 　ﾓｯﾄﾓ 大事ﾏﾝﾌﾞﾗｻﾞｰｽﾞ ﾅﾉﾊ
　　　　仕様書 ﾄｲｳ 名 ﾉ ﾕｰｻﾞｰﾏﾆｱﾙ ﾅﾉｼﾞｬﾅｲｶﾄ…

|,,∧　　　またやっちゃった・・・・
|Дﾟ彡
|　U 　　すいません、僕のレスは
|　ﾐ 　　　透明あぼんしてください。
| U
　　ｶｷｽｷﾞ.....ﾏｽﾀ

>>264 >>266
なるほど．．．画面系はあんまり作ったことが無いんで参考になる。
今後の設計に反映させてみよう。

> それを作りこむのに、倍くらい工数が欲しいこの頃
いいえ、通常の3倍必要です。ネタではなく人月の神話にも書いてある
ドキュメント作成の工数+(レビューの時間+レビューの指摘事項の反映)*n回
ドキュメントはコンパイルできないのも原因の一つと思ってたりする。

>>270
> "夢"非現実的な希望"論理的に矛盾のある機能"あいまいな記述"
> が、山盛り。
その「曖昧さ」や「矛盾」を許さないために書式を統一したいと思っている。

> 仕様書はライトウェイトな、記述がよろしいのではないかと
> 思ったりする次第です。
うん、必要最小限でいいと思っているけどその「必要の基準」を今考え中

> そもそも、技術者同士で話をする場合は会議の段階で
> 出来上がりのソフトのイメージが、互いに脳内にはっきりと
> 現れるので、形式ばった書類が無くても意思疎通ができ
それはお互いが共通の書式を持っているから意志疎通ができると考えている。
あと、話をしてみてプログラムができそうな気になってコーディング
始めたらまたいくつか決めなきゃいけないことがあったことって無い？
俺が新人の頃にはよくあって、先輩の仕事を中断させまくっていた。
この場合、チェックリストみたいな表があれば、新人の俺でも適切な
質問ができる可能性があったような気がする。

>>272
> しっかりとした仕様書は
> 「ソフトが完成してからじっくり書くもの！」
> と、思うているのですが、やっぱ変でしょうか？
> ※ただし意思疎通の為の形式ばらないメールのやり取りや
> 　瞬時に書き変える事が出来る、機能の箇条書き(ｽﾄｰﾘｰｶｰﾄﾞ)
> 　は設計図として用いたい。
仕様書がないということは目標が無いことです。
また、仕様変更は目的地が変更されることだから変更された瞬間に反映される
ことが望ましい（現実は難しいけど）
また、プログラマにバグ無しのプログラムを期待するのが現実的でないように
設計者に矛盾がない設計を期待するのも止めて欲しい
俺は実装を始める前に仕様書・設計書は書く。（もちろん完全ではない）
コーディングの最中に矛盾に気付いたらどんどん修正していく。
他人に指摘されたことも常時修正する。
だから仕様書は書き換えやすく、旧版と比較させやすいものであることが
必須と思ってる。

最終的に顧客に提出するときは、顧客の指定した様式に変換できるのが理想だが、
現実は
設計書を紙で出す→矛盾に気付いたら赤入れ→切りのいいとこで反映
という泥臭いことをやっていたりする。

>>273
> とりあえずシステムの概要を書く
> ＹＡＨＯＯの概要だったら、・検索サイト・広告ｲﾊﾟｰｲ・天気予報とか・新聞に変われる情報源
> Ｗｏｒｄの概要だったら、・ワープロ・仮想紙
> こういう感じかな？
これを俺は要求仕様と認識しているのだが。

> つきつめると
> 機能仕様＝ユーザーマニュアル
> 詳細設計書＝プログラム設計書
まぁ最終的にはそうなるんだけど初めからそれを書くのは無理で
いくつかの中間的なドキュメントが必要かなぁと思っている。

>>274
空気読めや。ここはお互いの設計についての思いを話し合う場だ。
俺は別に厨房と思われても構わんが（事実煽っているわけだし）、
君はここで思いを語ってる人達はどっかの厨房みたいに長文ウザイと思う人達と思っているのか？

>276
確かに、コーディング段階になって細かい部分が決まってない点が
出てくる事が多い。その前段階でもある程度チェックはしているけど、
結局そりゃ人間の目でしかないからなぁ。

>276が言ってるように、「何を決めるべきか」っていう事がチェックリスト
みたいになっていてハッキリしていれば、じゃあそのためのドキュメントを
(無ければ)書こうって話になると思う。

んで、Web上を検索してると業務内容を問わず汎用的に使える言語別のコーディング標準とかがあるよね。
そんな感じで、この言語でシステム構築する際に決めておくべき点のリストみたいな物を作れないかと思
うんだが。
要するに、ドキュメントを書く為のドキュメントな。

>>280
メタドキュメント！（・∀・）ｲｲ♪!!

>>272
DelフサギコがXPの有効性を理解しているように、仕様書をきちんと書いた上で開発を
始める事の有効性ってのもあると思っているのよ。
周囲の人が理解してくれないのは有効性をうまくアピールできないからかな…

仕様書作ってから開発しようと言っているけど、>>277の言うように仕様書は変更不可の
ものではなくて、開発時に問題が発生したらきちんと仕様書まで戻って検討・影響範囲を
調べた上で仕様追加・変更するっていうやり方を想定してるんだ。
変更・仕様については内部で決定した後、「これでいいですか？」という形で顧客の承認
をとるし、仕様書も修正する。
開発〜試験の工程にも仕様の検討、仕様書のメンテ、開発メンバーへの仕様の説明、
開発で持ち上がった問題点の吸い上げを専門に行う人がいる。
ソース直すより、設計書直す方が手間がかかるから担当すると死ぬ思いなんだけどね。

でも、この形だと>>279が言うようなチェックリストの役目もはたすしね。

XPで言うところのオンサイト顧客に近い形かなと思ってる。（仕様に責任を持つという部分で）

曖昧なドキュメントは書かないし、レビューでつぶせるような体制を作りたいよね

○○がTureの場合Ａ処理、Falseの場合B処理、それ以外の場合C処理…
とか
××が50未満の場合はD処理、100以上の場合はE処理とか…

例がうまくないけど、こんな意味の仕様書っていっぱいあるもんなぁ。

>>271
> そもそも、技術者同士で話をする場合は会議の段階で
> 出来上がりのソフトのイメージが、互いに脳内にはっきりと
> 現れるので、形式ばった書類が無くても意思疎通ができ、
> 開発は進む(と思われ)んだけど、

根が悲観的なもので、意志疎通していたとしても100%同じ内容が脳内に現れて
ないと思うし、時間や立場と共に各自のイメージは変わっていってしまうと思う。
そうなったときに、共通のイメージはこうだったよね。と簡単に確認できるように
文書化しておきたいってのが始まりなんだよね＞仕様書書こうよっていう事の

Delﾌｻｷﾞｺさんの言っている「仕様書」は、どういったものなのでしょうか？

設計書と同様、仕様書という言葉すら、混乱しています。

例えばこんな感じでしょうかねえ。
1) 顧客の要求仕様を記述した文書
2) プログラムのロジックを記述した文書(specification package)
3) 製品仕様書

〜混乱は整合性のない変化によってもたらされる〜

言葉が一人歩きしちゃったんでしょうな。

企業の枠組みを超えた、規格化、標準化が必要だと思いまつ。＞顧客のためにも

本来「仕様書」って単語自体、それ単体では使えないよな。
要求仕様書なのか、プログラム仕様書なのか、完成品の仕様書なのか・・・
そのへんから決めないと。
「設計書」も同じ。

>>287
そう。
そのために、共通フレーム(SLCP-JCF98)とかも策定されたのでしょうが、
普及しませんでした。

普及を阻害する原因として考えられるのは
1) 現在使っている標準を捨てねばならず、再教育のコストがかかる。
2) 標準を使っていない(w　ので、教育コストがかかる。
3) 現状の業務を標準に合わせられない or 合わせるとコストがかかりすぎる。

といったところでしょうか。

4) 共通フレーム(SLCP-JCF98)の魅力が乏しかった。

>>284
まさにそれがUML、およびUnified Processができてきた出発点だとおもうがどうよ？

ISO辺りでないのかね。そういう規定は。

>>291
UMLは敷居が高い感じがする。顧客、自社、協力会社すべてがUMLで統一されないと
効果は少ないけど、普及するにはまだまだ時間がかかるのでは？

>>293
たしかに敷居は高いけど、MDAつ〜ものも定義してきたってことで、UMLが向かっている方向が仕様書問題を解決する方向と
一致しているような気がしています。
しかし、あと10年はかかるかもなあ...。

IBMとかが積極的に使えば、UMLの普及も加速するのかもしれんが・・・

IBMは基本的にDOA(データ中心型アプローチ)らしいからのぉ。

>>285
>>288
品質管理の世界に要求品質，設計品質，製造品質という言葉がある。
この「品質」には、機能，性能を含む。

「要求仕様」という言葉が一般に使われているが、これは排除すべきだと思う。
情報システムにおける「仕様」とは、顧客とメーカーが合意したものに対して
使われるべき。
「要求品質」を下回る「仕様」で客とメーカーの合意がなされることもある。

（職場で同様の発言してる。そいつが見たらきっと誰だかわかるだろうな。）

>>295
> IBMは基本的にDOA(データ中心型アプローチ)らしいからのぉ。
IBM って組織が大きいから、一枚岩じゃないですぜ。

>>282
> ソース直すより、設計書直す方が手間がかかるから担当すると死ぬ思いなんだけどね。
うーん。一応顧客との「言った、言わない」論争が少なくなったから
前よりは死ぬ思いはしなくなったな。
だいたい俺は無駄なことは嫌いだ。
不毛な「言った、言わない」論争をする暇があったら仕様書を書いていた方がマシだ。

>>294
> しかし、あと10年はかかるかもなあ...。
真面目に取り組むという前提でな。
現在でも、フローチャート＝設計書という組織を俺は知っている。

>>292
ISO9000シリーズの品質管理はあくまでも「自社」で基準を決めて、
その基準を満たしているかどうかを判定するだけ
ISO9000に準拠しているからと言って高い品質を保っているかどうかはわからない、
自社の品質基準が低ければ、低い品質のプログラムが出荷される。

>>296
> 品質管理の世界に要求品質，設計品質，製造品質という言葉がある。
> この「品質」には、機能，性能を含む。
製造業関係の言葉だな。俺は製造業と情報システムは似て非なるものだと思う。

> 「要求仕様」という言葉が一般に使われているが、これは排除すべきだと思う。
> 情報システムにおける「仕様」とは、顧客とメーカーが合意したものに対して
> 使われるべき。
製造業の場合、要求が変更されることはあまりない、
それに対し、情報システムの場合、要求が変更されることは日常茶飯事。
情報システムの場合、製造業と比べ変更コストが低いことも原因の一つかも知れない。
だからXPのような仕様変更を前提としたプロセスが出現した。

> 「要求品質」を下回る「仕様」で客とメーカーの合意がなされることもある。
その通り、そしてこの段階で「金額」と「納期」が決まってしまう場合が多い。
そして、メーカーは仕様を盾に仕様変更を認めたがらず。
顧客は契約を盾に金額や納期変更を認めたがらない。

>>299 補足
ただし、製造業の品質管理には見習うべき点が数多くあることも確か。
特に品質管理を同一のチームでは行わず、別のチームで行うことはやるべきだと思う。

その場合、品質管理チームは仕様を設計チームと同等に理解する必要がある。
現在はデバックは製造や設計よりも低く見られがちだが、デバッグ＝品質管理
は製造、設計と同等の重要な役割だと思う。
その三チームにバランス良く権力を分散することが俺の理想。

>299
>製造業の場合、要求が変更されることはあまりない、
>それに対し、情報システムの場合、要求が変更されることは日常茶飯事。

それを聞いて思い出した。
業務システムにおける「設計」ってのは製造業で言えば「研究開発」にあたる、
って事がどっかのページに書いてあった。

研究開発という作業は当然、製造工程とは別で、同じ枠にに入れるべきでは
ないのだが、それをやってしまっているのがシステム開発だ、みたいな内容
だったと思う。

>>301
製造業では「研究開発」の結果から複数の製品が出来上がる可能性があるけど、
情報システムでは製造の前に必ず「設計」が必要になる。
だから、製造業と同じ考え方（方法論、コスト）では駄目という事？

製造業ではひとつのラインからとめどなく売れる製品が吐き出される。
情報システムでは製品をひとつ作るたびにラインを組みなおす必要がある。
ということか．．．

　 ∧,,∧　　最近は後輩や先輩が
　ミ,,ﾟДﾟ彡　同一Ｐｒｏｊに増員されて
　ミつ日(ﾐ　心が豊かになれるほど仕事に余裕ができますた。

んで、仕様書を書いてみているところです。
手間はなかなかかかりますが、
けっこう、かなーり、な有用だとは感じてきました。

私の勝手な利用方法ですが、
仕様書を書くとき
ＸＰｽﾄﾘｰカドの書き方を頭においています。

雛形があるのですが、それの
全項目を埋めるという無駄な努力を放棄して
適当に必要な所だけを仕上げて
上司のはんこなんて貰う気もなさげな書類として
自分だけ使う文章としていて、今は楽しく書類かけますね。

(ただし、工数はどうやっても増加する･･･)

　 ∧,,∧　　　根本はあいまいな仕様で話を
　ミ,,ﾟДﾟ彡　　濁し、問題を先送りするという
　ミつ日(ﾐ　　　仕事をしている人がいるってこと
　　　　　　　　　だと思う日々です

が、、それはともかく。

>>284さん。そうだと思いますが、文章はｺﾝﾊﾟｲﾙできないので
あいまいなイメージもあいまいなまま記述されてしまいますよね。

>>285さん。>>288さん
えっと…、、そんな感じっす。
意思疎通がへたっぴでごめんなさい。

>>296さん
>「要求仕様」という言葉が一般に使われているが、これは排除すべきだと思う。
ああ、そのとおりだと思いました。
要求仕様：空飛ぶ車についての概要
･･･そんな作れないものの仕様書はいらないっすね。

>>298さん
>不毛な「言った、言わない」論争をする暇があったら仕様書を書いていた方がマシだ。
ﾓﾁﾍﾞｰｼｮﾝが下がりすぎて、チーム崩壊になりそ。

　 ∧,,∧　　　
　ミ,,ﾟДﾟ彡　　
　ミつ日(ﾐ　　　
そうそうそうそう
>>299さんの後半に
激しく同意。

会社の同僚/上司に
読ませてあげたいよ。

>>305
> >>284さん。そうだと思いますが、文章はｺﾝﾊﾟｲﾙできないので
> あいまいなイメージもあいまいなまま記述されてしまいますよね。
コンパイルできるものは動くものだけど、そのコードの動きが目指しているものとあっているか
どうしてそういうコードになったのかってのはソース見ただけじゃ分からないと思うんですよ。
文章は確かに曖昧だけど、何を望んでいるのか、望んだものを実現するために何故その実装を
したのかってのを残しておきたいんですよ。

>>301
> それを聞いて思い出した。
> 業務システムにおける「設計」ってのは製造業で言えば「研究開発」にあたる、
> って事がどっかのページに書いてあった。
ISO9000に限定すると、製造業の「設計」「製造」「検査・試験」と
情報システムの「設計」「製造」「検査・試験」は全く別物
ISO9000の設計は情報システムの「設計」「製造」「検査・試験」を包容し、
ISO9000の製造はメディアに格納する行為を指す
ISO9000の検査・試験はメディアが読みとれるかどうかを確認する作業を指す
詳しくは以下参照
# ただしリンク先にも明記してあるとおり「唯一の解釈方法」ではない
http://www.cam.hi-ho.ne.jp/adamosute/iso9001/softtekiyo.htm

> 情報システムでは製造の前に必ず「設計」が必要になる。
> だから、製造業と同じ考え方（方法論、コスト）では駄目という事？
製造業でも製造の前に「設計」が必要になるが、製造業の場合、製造が
時間がかかるのに対し、情報システムでは媒体にコピーするだけ

また、製造業では完成品を修正することは至難の業だが、
情報システムでは比較的容易に完成品の修正ができてしまう。

>>304
> 私の勝手な利用方法ですが、
> 仕様書を書くとき
> ＸＰｽﾄﾘｰカドの書き方を頭においています。
俺も何人かで話し合って、適当に図や説明をホワイトボードに書き込んでいって、
それを清書して仕様書にしている。
完成した仕様書をレビューして、実装者と意識の統一を図っている。
確かに工数はかかるけど、結合テストなどの後工程で意識のズレがでるよりかは
前工程で顕在化させていた方が早期に対処ができる。

>>285
> 例えばこんな感じでしょうかねえ。
> 1) 顧客の要求仕様を記述した文書
> 3) 製品仕様書
俺は上記は仕様書だと思っている

> 2) プログラムのロジックを記述した文書(specification package)
俺は上記は設計書だと思っている

UMLで言うと
・ユースケース図
・クラス図
・パッケージ
・インターフェース
については仕様書だと思う

・コラボレーション図
については設計書だと思う

・オブジェクト図
・状態図
・シーケンス図
は正直分からない、時と場合により仕様書になったり、設計書になったりする。

>>297
うん。そうですね。
Javaにも力を入れているし、ラショナルを買収するぐらいだから、
今後は方法論も変わってくるんですかねえ。

>>299
最近では、要求が変更されることを前提にソフトウェア開発を行うしか
なくなっているような気もしますね。
たぶん、ソフトウェアというものが、製品というよりもサービスに限りなく
近いからでしょうね。
もちろん、製造業のような部品化が不要なわけではないけど。

>>300
品質管理（レビュー、テストも含めて)を別のチームで行うのは賛成。
テスターとかは軽く見られがちだけど、とても重要な役割だと思います。
またレビューも面倒くさいからといってやらなかったり、手を抜くと、後で
だいたいハマります。

>>303
製造業でも、少品種大量生産から、多品種少量生産、果てはカスタム
メイドの受注生産までいろいろありますので、一概にはいえませんが、
情報システム開発は、ある1回限りの製品のためのラインを作るのに
たとえることができるかと思います。

>302-303
そそ。
コーディング工程に入れば、ある程度は製造業のように線表引いて生産計画立てて・・・
みたいな事もできるだろうけど、実際はその前の段階(ライン作業ではない部分)まで
ラインに乗せようとしている、と。
それがそもそもおかしいんだ、みたいな主張だったような気がする。

>308
ISOにそういう定義あるんだ・・・勉強してみる価値あるかな？
でも
>媒体にコピーするだけ
を「製造」って呼んじゃうのはさすがに違和感あるなぁ。

>311
請負型のシステム開発はほとんどの場合、カスタムメイドにあたる訳っすよね。
製造業ではそういう製品を作るときの手順ってどうやってるのかなぁ。

ここの発言を読んでいると、
「情報処理技術者試験で定義される外部設計と内部設計を行ってできあがったもの」
＝Aとする−−が「仕様」と呼ばれることがほとんどですね。
・・っとここでいったん置いといて・・・

「この共通関数の第１引数、値渡しで良いのになんでアドレス渡しになってるんだろ」
「そういう『仕様』なんだって」；　『』レベルのこと＝Bとする。

今の仕事、Bのドキュメントも納品してるんです。
Aまで満たせば顧客的にはまったく問題ないのに、Bまで納品しているがために
製品はBまで満たさなくてはいけない。
（実装段階でBが変わることが分かったら、早期にBのドキュメント差分を納品する）

>>314のことより、Bまで「仕様」であると考えて、↑↑の方で
「仕様は顧客のスキルにより変化する」
という発言をしました。

Bに適切な呼び方があれば、Aを「仕様」としてみなさんと統一できるのですが。
Bの良い呼び方はありますか？

B=ソースドキュメント
最近では、仕様(A)を満たすソースからツールで生成されることが多いな。

ユニットテストのテストケースってのはBに近いような気が・・・

>>314-315
なるほど、システムがいくつかのサブシステムに分割されている場合、
顧客には設計書に見えるが、サブシステムを担当しているプログラマには
仕様書に見えるドキュメントをどう呼ぶという問題だよね。

その場合、サブシステムに分割した権限と責任を持った人を顧客として
見なさざる得ないし、そうなると仕様書の定義に幅ができてしまうな。

やっぱ仕様書って定義できないのかな、唯一定義できるとすれば
仕様書は設計書の入力であることぐらいかなぁ。

age

分からなかったらソース読め！ソースは何でも知っている。

Bはプログラム設計とか言われるレベル。
プログラミングの前で、内部設計の一部又は前（一部が正しいと思う）
の工程。情報処理試験でいうと以前の
プロダクトエンジニアの担当範囲に相当するんじゃないかな。
当然関数レベルの仕様書を書く前にやるべきこと。
つまり言語仕様を有る程度抽象化した上でのアルゴリズム周りの
設計ね。　

もう A B C D でいいじゃないか。

■■無料レンタル掲示板■■

どんどんレンタルして下さい

ランキングありジャンルも豊富です


http://www.geocities.jp/kgy919/bbs.html

>322
ﾏｼﾞで、どの内容のドキュメントをAとする、みたいな基準があれば助かる。
上で言ってる共通なんちゃらはそれを目指したようだが・・・

／ ＼ ∴ :：*:∴:∴ ∴ :：:∴ ：☆:∴
Σ ＿ ＿ / ＼ く :：* :∴ ∴ :：∴ *:∴ ∴ :：∴ *:∴ @∴ :
く |／◎）､ ∠ｌ　 / ＼ 　| :：*:∴ ∴ :：∴ ι=*●:：:∴ :・ ←ターン>>325
＼ | | 「....;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;|l∫;;+:;::. 　　 └■> ＼　 :：*:∴ @∴ :：*:∴
,／| ＼＿＿ ;;;;;;;;;;;;;;;;;;;;;;;;| |;:*:;;;:;:;;;;,　　 し-/ |:：*:∴ ∴ :：*:∴
／´⌒ヽ＿＿＿＿ ＼|￣￣￣￣￣..|;;;;;;, i￣￣i ﾞ､ :：*:∴@ ∴ :：*:∴
,/´＃＃ ! ヲ＝℃／￣ |;;;;;;;;, / ﾞ､ :：*:∴ ∴ :：*:∴
/_レ‐ｰ――‐"~）_ノ´ )) ヾ;;;;;;;;,,,.. / `i ∴ :：∴ :：*:∴
／ __ r'~ ヾ;;;;;;;;;;;;,,,.トー――――・ 〜＿ ∴ :：∴ :：:∴
/ ＿） ヾ;;;;;;;;;;;;;;,,,,.... ┃ ´｜
| ､ ノ ヾ;;;;;;;;;;;;;;;;;;;;;;;;;,,,,.... ┃ ／
ﾞ､;;;,,.. ￣" ）;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;....（

急遽明日までに外部設計書のテンプレを作らなければならなくなりました。
しかも外部インターフェースについて。
これを作る知識が乏しく、検索もしてみましたが、サンプルとなる物は見つけ
られませんでした。切羽詰まってきましてちょっと泣きが入りかけています。
勝手なお願いですが、何か参考になる文献は無いでしょうか。
宜しければご教授頂けないでしょうか？
お願いします。

>>326
> 外部設計書のテンプレを作らなければならなくなりました。
> しかも外部インターフェースについて。
JavaDoc相当のものでいいんじゃないの

http://www.mtl.t.u-tokyo.ac.jp/~sakai/toku1/JEITA020624.pdf

>>326
画面レイアウトとか？

>>327-329

ご教授、ありがとうございました。
お礼が遅くなりまして申し訳ありません。

何とか徹夜で作成して持っていきました。
しかし、一夜漬けの知識では限界な点が多く、ダメだしの嵐でした。
また書き直しですが、それでも皆さんのお陰でピンチは乗り切れました。
ありがとうございました。

また、お教えを請う事になるかも知れませんが、その時にはどうぞ
宜しくお願いします。

　 　∧,,∧　　 ／　
ミ,,ﾟДﾟ彡 ＜　　こんな感じ？
　 　ﾐ つ旦)~~ ＼　
"・"のある所だけ、文章を記述を記述するです。

要求仕様書----------------------------------------
要求概要
目的・
効果・
要求システム環境
ハードウェア
稼動環境(サーバー/クライアント)・
接続機器等・
ネットワーク構成・
ソフトウェア
OS/WebServer/DBなど・
Office/開発言語環境など・
要求機能概要
業務分析・
要望・
業務改善/導入・
要求機能詳細・
付属書類/画面画像イメージ・
文書履歴・

　ﾊｹﾞｼｸ ﾂﾞﾚﾀ
　 　∧,,∧　　　／　詳細記述が必要な所はあえて
　　ミ；ﾟДﾟ彡 ＜　　詳細項目にはわけませんでした
　 　ﾐ つ旦)~~ ＼　箇条書きで書いてください。
設計仕様書----------------------------------------
機能概要
導入必要システム構成
　　ハードウェア
　　　　稼動環境(サーバー/クライアント) ・
　　　　接続機器等　・
　　ソフトウェア
　　　　OS(Version/ServicePack等)・
　　　　WebServer(Version/ServicePack等)・
　　　　DB(Version/ServicePack等)・
　　　　Office(Version/ServicePack等)・
開発システム構成
　　ハードウェア
　　　　稼動環境(サーバー/クライアント) ・
　　　　接続機器等・
　　ソフトウェア
　　　　OS(Version/ServicePack等)・
　　　　WebServer(Version/ServicePack等)・
　　　　DB(Version/ServicePack等)・
　　　　Office(Version/ServicePack等)・
　　　　開発言語(Version/Update等)・
　　　　ソフトウェア部品詳細・
機能詳細・
付属書類/開発中画面画像・
文書履歴・

　 　∧,,∧　　　／　綺麗に整えたり、追加/修正
　　ミ,,ﾟДﾟ彡 ＜　　してくれるひと、ﾎﾞｯｼｭｰﾄ
　 　ﾐ つ旦)~~ ＼　
　ｵﾚﾆ ﾐｿ ﾖｺｾ

テスト仕様書----------------------------------------
テスト環境概要・
テストシステム構成
ハードウェア
稼動環境(サーバー/クライアント)・
接続機器等・
ソフトウェア
OS(Version/ServicePack等)・
WebServer(Version/ServicePack等)・
DB(Version/ServicePack等)・
Office(Version/ServicePack等)・
テスト手順項目・
付属書類/テスト結果画面画像・
文書履歴・
----------------------------------------

mage

age

ﾌｻｷﾞｺﾀﾝ素晴らしい！感動しますた。

ぬるぽ

なんか微妙に良スレになりつつあるような・・・

ほぼ一ヶ月間マトモな書き込みがないってのはあまり良スレとは言えないかと。

　　　 ∧,,∧　　久々ageで
　　　ミ,,ﾟДﾟ彡
　 　 ﾐ　つ旦)~~
　 〜と,,,~),,~)　

相変わらず、ドキュメント関係で苦労してます。

他人にソース見せない奴ってのは
プログラマとして大体無能だと思いますが

自分が仕様書を書く立場だと逆に
仕様書完成度が低いのがすごく分かるので
他人に見せたくなくなってしまいます。

SEとして、自分はよろしこない行動を
とっているんだなーと、思う事しばしば。
仕事は難しいですね。


ところでインデントが激しくズレすぎているので
次のところにageときました。
http://do.sakura.ne.jp/~junkroom/cgi-bin/megabbs/readres.cgi?bo=lounge&vi=1049735677&res=2

　　　∧,,∧ 　　　ﾏｼｪｰﾘｰ
　　ミ,, ﾟДﾟ彡　
　　 〃つ旦O
　〜ﾐ,,［￣￣￣.］
　　　　 ￣￣￣
それにしても私がみた狭い世界のことだけですが
プログラム組める人ってのは
仕様書を書く時間が
工数にかなり影響する事が
すぐ分かるみたいで、工数を考えて
書かないようにしてる人は多いように
感じてます。

対して、プログラムが組めないSEは
ドキュメント作成に情熱をささげていて
しっかりしたものを作りこんできます。

どっちが、いいのか、悪いのか
まだまだよくわかないのですが
(俺的にﾌﾟﾛｸﾞﾗﾑ組めるので
　後者のｱﾌﾟﾛｰﾁは取らない)

とりあえず、ﾌﾟﾛｸﾞﾗﾑ組めない上司受けは
後者の方が確実によいです。
もちろん客受けも後者の方がよい感じかと。
お仕事は奥深いですなー

詳細設計書って､どの位まで詳細に書いてますか？

>>341

それはあまりにもPG寄りの近視眼になってるぞ。
まず、ドキュメントがないプログラムなど、運用で絶対に躓く。
「なにができて、なにができないのか？」が分からないのに、
目の前のシステムエラーを解決できる事なかろう？

「致命的なエラーです。（435）」
とか出されても、何がどう悪いのか良く分からない。
もっと言えば、「変な挙動だが、それが仕様なのかバグなのか分からない」なんてのもある。

で、結局作ったやつ呼び出して…退職してたら作り直し、となる。
とてつもなくメンテナンス性が低いプログラムにドキュメントがないものが多い。
と言うか、意識してない（作る際に設計レビューも受けないので）ことが多い。

それに、最近は大規模開発では複数のPGが関わる事が多いので、
設計書で意識統一しないと品質的にブレが大きいものが出てくる。
一部の品質が劣化すると言う事は、
即そのプログラム全体の品質の悪化になるわけで。

後先考えないで放置していると、結局自分の首を絞めてるだけ。
そうやって火を噴いたプロジェクトなら数多く知ってるし。
実際、今その火消しに投入されて、
まさにその理由で四苦八苦してるし。(T-T)

>まさにその理由で四苦八苦してるし。(T-T)
　 ∧,,∧　　…ｳﾜｧ…
　ミ；ﾟДﾟ彡
　ミ ⊃⊂ﾐ

>343
言ってる事は非常によくわかる。
問題なのは「運用やバグ探しに役に立つドキュメント」が少ない事なんじゃねぇかな。
結局ドキュメント見るより直接ソース見たほうが早いってシーンによく出会うよ。

>それが仕様なのかバグなのか
仕様書を見ても、その辺の例外的な事が記述されていないケース多くない?
>341が言っているような「プログラムの組めないSE」って、「どう動いて欲しいか」
は書くけど、例外的な事項に関する記述がすっぽ抜けてる奴がすげぇ多い。
もちろん、それをレビューしない体制も問題。
っていうか、それ以前にそんな奴が仕様書いてる事も問題。

そういう体制で動いてるプロジェクトじゃ当然ドキュメントのメンテなんかマトモに
されるはずもなく、更なる混沌へ・・・

何かの本で読んだんだが、仕様書とはプログラムの開発のために書くのではなく、
プログラムの保守のために書くんだそうだ。

この言葉で目から鱗が落ちた気がしたので今UMLのお勉強中・・・

つまり、保守に役立たないドキュメントは仕様書ではない、と。
世の中には仕様書を書いた事無いSﾖがｲﾊﾟｰｲだ!!(・∀・)

>>346
で、UMLには例外的な事項に関する記述がすっぽ抜けないようにできるのかね？
言語を操るスキルや意識が低いとどんな言語を使ってもだめなのさ。

>>343
んー、でも仕様書を信じたばかりにドツボにはまることも多々あり。
まぁ仕様書は、そんな情報もあるという程度かな。

プログラマたる物詳細はソースを見れば一目瞭然。
上位の抽象概念や、設計思想が書かれていた方が助かる。
設計思想が理解できれば、こうやってあるだろと想像がつく。

>>346
仕様書は将来の自分に宛てて書くんだよ（ｗ

盛り上がってるので、ちょっと茶々入れ。

>>346
目からウロコなのはわかるが、あまり正しくはないっしょ。
仕様書というかドキュメントを書くのは、
開発のためでもあるし、テストのためでもあるし、運用・保守のためでも
ある。つーか、保守＝(開発＋テスト)の繰り返し、だし。

>>349
(･∀･) ｶｺｲｲ!!
それにしても、ソースとドキュメントの乖離ってのは、昔から難しい問題
なんだろうなあと思う。

プログラムとは文芸なのだよ。 by クヌース

　 ∧,,∧　　お茶いれ。
　ミ,,ﾟДﾟ彡
　ミ⊃旦(ﾐ~~
>>346
保守の為に。激しく同意です。
保守(運用)ドキュメントがあれば
>>343も苦労しなかったはずです。

>それに、最近は大規模開発では複数のPGが関わる事が多いので、
>設計書で意識統一しないと品質的にブレが大きいものが出てくる。
設計書で意識統一したのでも、日本語はあいまいだったために
品質が著しく低いﾌﾟﾛｼﾞｪｸﾄってのはありました。

ソースをリファクタリングすることで
動作がどんどん理解できてくるですね。

>352
昔自分が書いたコードが恥ずかしくって書き換えるのは
リファクタリングになるのだろーか？

>>353
成長過程ではそれが当然。　というか昔のコードみて恥ずかしくならないようでは
成長しとらんということだわなー。

http://yahooo.s2.x-beat.com/linkvp/linkvp.html

>>341
>>342
>>343
オペレーションをする人（←オペレータだと、汎用機オペみたいだから）
から見えることと、システム他部分とのインターフェイスが書かれていれば、
それより細かいこと＝詳細設計は「ほとんどの場合」書かなくても良いと思う。
詳細設計を自然言語で書くなら、その時間をコーディングに当てた方が早い。
詳細設計の内容を知らなければならない人が コードを読めないというのは、
あってはならないことだから。

では、どんな場合に詳細設計を書かなければならないか。
私の知っている例では「法令に基づいた計算・判定」(メインフレーム系が多い)がある。
通常業務では論理的に考えてわからない計算・判定はない。
だが「法令に基づいた計算・判定」は、「そういう決まり事があるから
そうなっている」であり、論理的必然性がない。
SEは法令を勉強している暇などないので、実装予定の(≠設計した)計算・判定を
詳細設計に書いて、ユーザーにレビューしてもらわなければならないのである。

>>348
ちなみにUMLで、例外事項が抜けるの、どうやって防ぐの？
やっぱり経験しかない？

UMLは、「一番やりたいこと」を表現するにはめっちゃ便利(わかりやすい)だけど、初期化とか例外処理とか特殊なものはぬけることが多い...。

この文書について
　　この文書での表記
　　この文書で使う用語

というのを、要求/設計仕様書の先頭、または概要の所に入れて欲しいっス。

あと、やっぱり文書履歴は、文書の後ろのほうがいいですよね。
うちとこは、表紙の後、目次の前に入れるので、量が増えるともう(泣

すまない。早いとこ載せるべきでしたね。
ttp://www.jisa.or.jp/committee/scals/1999guide/scals/acrobat/99-2.pdf

　（　・∀・）＜　こんなのみつけたっち♪
http://muryou.gasuki.com/moe/hankaku10.html
http://muryou.gasuki.com/moe/hankaku09.html
http://muryou.gasuki.com/moe/hankaku08.html
http://muryou.gasuki.com/moe/hankaku07.html
http://muryou.gasuki.com/moe/hankaku06.html
http://muryou.gasuki.com/moe/hankaku05.html
http://muryou.gasuki.com/moe/hankaku04.html
http://muryou.gasuki.com/moe/hankaku03.html
http://muryou.gasuki.com/moe/hankaku02.html
http://muryou.gasuki.com/moe/hankaku01.html

　　　　　　　　　　 ＿＿＿＿＿＿＿＿＿
　 　∧,,∧　　　／　>>358
　　ミ,,ﾟДﾟ彡 ＜　　修正しときまつ。
　 　ﾐつ旦(ﾐ~~ ＼　
　＠ﾐ　　 ﾐ　　　　￣￣￣￣￣￣￣￣￣
　　 ∪''∪　　でも、忙しいので後日･･･


そんなふうに
修正されないドキュメントが
たぶん、今日も
日本中で作成され続けているんだろな。

Ｉ○Ｍは英数字を全角で記述するのが標準らしいがほんとですか？
信じられん...

見たこと無いよ。Iからくるものも。

今Ｃ＋＋で組んでいるんだが、メンバ関数がすべて static関数
で、派生もしてなきょ継承もない、うざいので こやつの書いたソースの
５％程度を 適当に読んで削って、
「むやみ やたらに static 関数の使用はさけてください。
無駄だったので、ソースは消しておきました。適度に書き換えてます。」
とメールしたら ２日後、
「ソースの管理が難しくなるので、やめてください。」
と言わたぽ。

いや、あんたが指摘するところがあったら言って下さい っていったから
やったまでだし・・・

鬱だ・・・

>>364
Cな人だったのね・・・。あるいはBOCOLな人か。
乙です。

>>364
「品質の管理が難しくなるので、辞めてください。」
といい返せ。

類似スレにも張りましたが。

↓の内部/外部仕様書のところ。
ttp://www.metabolics.co.jp/SoftwareProcess/

>>364
いるよな、そゆ香具師は。
「トラブルになるコードが多すぎです。C＋＋をもうすこし勉強してください。」
（の表現をもうすこし生暖かく）とでもガツンと言ったれ。

よくわからないのだけど、メンバ関数をどうしてわざわざstaticにするの？
１つのclassに恐ろしい数のメンバ関数が存在するっていうのは
なんとなく理由わかるのだけど。

（＾＾）

>364
内容よりもところどころ入ってる半角スペースが気持ち悪い。

　　 ∧＿∧
　　（　　＾＾ ）＜ ぬるぽ（＾＾）

age

━―━―━―━―━―━―━―━―━[JR山崎駅（＾＾）]━―━―━―━―━―━―━―━―━―