1 仕様書無しさん :2006/06/11(日) 21:05:39
PGにとって、次のどちらの仕様書（設計書）が開発効率が高い？
例１
◆CSVファイル取込処理
（１）ファイル選択ダイアログを表示する。
（２）ファイルが選択されたら処理を行う。
※エラーの場合はメッセージを表示する。
「テキストファイルの読み込みに失敗しました。」
例２
◆CSVファイル取込処理
（１）ファイル選択ダイアログを表示する。
（共通関数：F_GetOpenFile）※関数の仕様については別紙参照。
（２）関数の戻り値が正常（０）ならば処理を行う。
関数の戻り値が異常（−１）ならばメッセージを表示する。
（メッセージID：100「テキストファイルの読み込みに失敗しました。」）
メッセージについては、共通メッセージ一覧を参照。
（３）共通エラーチェックを行う。
例１と例２は共にCSV取込み処理について記述したものであるが、例２では、使用する関数名やメッセージIDが指定されている点で例１と異なる。さらに共通エラーチェックという妙な記述がある。
皆さんの意見を伺いたい。
7 仕様書無しさん :2006/06/11(日) 23:07:46例１
◆CSVファイル取込処理
（１）ファイル選択ダイアログを表示する。
（２）ファイルが選択されたら処理を行う。
※エラーの場合はメッセージを表示する。
「テキストファイルの読み込みに失敗しました。」
例２
◆CSVファイル取込処理
（１）ファイル選択ダイアログを表示する。
（共通関数：F_GetOpenFile）※関数の仕様については別紙参照。
（２）関数の戻り値が正常（０）ならば処理を行う。
関数の戻り値が異常（−１）ならばメッセージを表示する。
（メッセージID：100「テキストファイルの読み込みに失敗しました。」）
メッセージについては、共通メッセージ一覧を参照。
（３）共通エラーチェックを行う。
例１と例２は共にCSV取込み処理について記述したものであるが、例２では、使用する関数名やメッセージIDが指定されている点で例１と異なる。さらに共通エラーチェックという妙な記述がある。
皆さんの意見を伺いたい。
>>1
CSV の仕様も
取り込んだ内容をどこに保持するのかも
書かれていない。
結論: どちらも素人の書いたクソ。
8 仕様書無しさん :2006/06/11(日) 23:35:15CSV の仕様も
取り込んだ内容をどこに保持するのかも
書かれていない。
結論: どちらも素人の書いたクソ。
ドキュメントとして残すべきはCSVファイル取込処理じゃなくてXXデータ取込処理なんじゃないか？
で、データ構造とかパーシステンスとか考慮のうえ記憶媒体をCSVファイル
にするかXMLにするかDBにするか決める、と。
9 仕様書無しさん :2006/06/11(日) 23:53:05で、データ構造とかパーシステンスとか考慮のうえ記憶媒体をCSVファイル
にするかXMLにするかDBにするか決める、と。
共通エラーチェックってのが、例1では踏み込まれて無い内容なので、
比較することが出来ない。
入出力を意識して書いて欲しいよな。仕様書は。
どういうフォーマットの入力を受け付け（はじかなければいけない条件は何なのか）
どのような出力先(DBやファイルや画面)にどのように出力すればいいのか。
そうすりゃ、プログラマは間の処理を記述するのに集中できるってもんだ。
比較することが出来ない。
入出力を意識して書いて欲しいよな。仕様書は。
どういうフォーマットの入力を受け付け（はじかなければいけない条件は何なのか）
どのような出力先(DBやファイルや画面)にどのように出力すればいいのか。
そうすりゃ、プログラマは間の処理を記述するのに集中できるってもんだ。
10 仕様書無しさん :2006/06/12(月) 00:30:47
>>1みたいなドキュメントって、全然必要ない。
いつそのデータが欲しいのかとかデータ構造がどうなっているとか
ファイルフォーマットが破損していたときどういう後処理をしたいとか
そういう情報がわかれば>>1みたいなことは自動的に導き出されるから。
逆にそういう「何がやりたいか」みたいな情報が全く設計書に記述されて
ないからPGはSEに質問を投げまくることになる。
13 仕様書無しさん :2006/06/12(月) 08:55:51いつそのデータが欲しいのかとかデータ構造がどうなっているとか
ファイルフォーマットが破損していたときどういう後処理をしたいとか
そういう情報がわかれば>>1みたいなことは自動的に導き出されるから。
逆にそういう「何がやりたいか」みたいな情報が全く設計書に記述されて
ないからPGはSEに質問を投げまくることになる。
例１は操作仕様書としてみれば及第点。
例２はそれにプログラム仕様書かデータ設計書にかかれるべきものの一部が載ってるメモ書き。
14 仕様書無しさん :2006/06/12(月) 10:35:53例２はそれにプログラム仕様書かデータ設計書にかかれるべきものの一部が載ってるメモ書き。
半角だけなのか
全角をゆるすのか
文字コードは何か
15 仕様書無しさん :2006/06/12(月) 11:20:00全角をゆるすのか
文字コードは何か
う〜ん、>>1は例２を見て「こんなコードに近い記述意味ねーよｗ」とか言って欲しかったのか？
19 仕様書無しさん :2006/06/13(火) 06:47:46>>15
その通り。
別にコーダーを意識して書かれた設計書ではなく、発注したSIerの考えが古くさいだけ。
要は、ドキュメントとソースの体裁を完璧にしたいだけのようなのだ。
ユーザー要件は二の次にされている。
漏れは、ソースは書くものではなく描くものであると考えている。
しかし、漏れのリーダーは、他のプログラマに統一性のないコードを書かれるのを嫌っている。
SIerがうるさいからそうしているというわけ。
ソースを大事にするかユーザ要件を満たすかどっちが大事か分かるだろう。
今回のユーザ要件はきれいにソースを書くことなのか（爆）
22 仕様書無しさん :2006/06/13(火) 10:20:42その通り。
別にコーダーを意識して書かれた設計書ではなく、発注したSIerの考えが古くさいだけ。
要は、ドキュメントとソースの体裁を完璧にしたいだけのようなのだ。
ユーザー要件は二の次にされている。
漏れは、ソースは書くものではなく描くものであると考えている。
しかし、漏れのリーダーは、他のプログラマに統一性のないコードを書かれるのを嫌っている。
SIerがうるさいからそうしているというわけ。
ソースを大事にするかユーザ要件を満たすかどっちが大事か分かるだろう。
今回のユーザ要件はきれいにソースを書くことなのか（爆）
>>19
今回の要件でなく、プロとしての要件
それができないなら単金下げられると考えろ
24 仕様書無しさん :2006/06/13(火) 13:54:14今回の要件でなく、プロとしての要件
それができないなら単金下げられると考えろ
>>19
言いたいことはわかる。
でもそれをするのはPGの仕事じゃなくてアーキテクトの仕事だと思う。
18 仕様書無しさん :2006/06/12(月) 15:24:38言いたいことはわかる。
でもそれをするのはPGの仕事じゃなくてアーキテクトの仕事だと思う。
どっちもダメだけど
どっちか選べとしたら１だろ。
28 仕様書無しさん :2006/06/14(水) 02:06:59どっちか選べとしたら１だろ。
例2の方がマシではあるが
＞（共通関数：F_GetOpenFile）※関数の仕様については別紙参照。
関数名だしてるんだからワザワザ別紙参照とか注釈(ﾟ��ﾟ)ｲﾗﾈ
＞ （メッセージID：100「テキストファイルの読み込みに失敗しました。」）
＞ メッセージについては、共通メッセージ一覧を参照。
これもそう。メッセージIDだけでいいな。
＞ （３）共通エラーチェックを行う。
意味不明
30 仕様書無しさん :2006/06/14(水) 02:52:16＞（共通関数：F_GetOpenFile）※関数の仕様については別紙参照。
関数名だしてるんだからワザワザ別紙参照とか注釈(ﾟ��ﾟ)ｲﾗﾈ
＞ （メッセージID：100「テキストファイルの読み込みに失敗しました。」）
＞ メッセージについては、共通メッセージ一覧を参照。
これもそう。メッセージIDだけでいいな。
＞ （３）共通エラーチェックを行う。
意味不明
ソースが仕様書。一番確実・正確。
31 仕様書無しさん :2006/06/14(水) 03:31:50こんな馬鹿みたいなもんいちいち書くのって、
昔の底辺COBOLerレベルのクズPG寄せ集めのカスプロジェクトだろ。
例２がマシでさらに細かく書けとか言ってる奴らって、
コーディングを、日本語からプログラム言語への変換とか勘違いしてるアホだろ。
頭使うのがコーディングなんだよ。まさかそれで給料貰ってないよね？
だいたい、F_GetOpenFileって何だよこの関数名のセンスｗｗ
32 仕様書無しさん :2006/06/14(水) 06:49:43昔の底辺COBOLerレベルのクズPG寄せ集めのカスプロジェクトだろ。
例２がマシでさらに細かく書けとか言ってる奴らって、
コーディングを、日本語からプログラム言語への変換とか勘違いしてるアホだろ。
頭使うのがコーディングなんだよ。まさかそれで給料貰ってないよね？
だいたい、F_GetOpenFileって何だよこの関数名のセンスｗｗ
>>31
漏れは、「こんなプロジェクトぶっ壊して辞めるか」「仕方なく続けるか」の２択しかないわけで・・・
関数名のセンスの話だが、
例えば、Public Function だからって、PF_GetOpenFIleとかつけるのさ。漏れはキモイとは思いつつ、開発標準だってさ。
Public SubだからPS_SetEnabledとか
あと、ループカウンタにDim intLoop As Integer とか
この辺の事情はどうなんだろか？
34 仕様書無しさん :2006/06/14(水) 10:52:19漏れは、「こんなプロジェクトぶっ壊して辞めるか」「仕方なく続けるか」の２択しかないわけで・・・
関数名のセンスの話だが、
例えば、Public Function だからって、PF_GetOpenFIleとかつけるのさ。漏れはキモイとは思いつつ、開発標準だってさ。
Public SubだからPS_SetEnabledとか
あと、ループカウンタにDim intLoop As Integer とか
この辺の事情はどうなんだろか？
>>31
本気でそう思ってるんなら、お前頭使う場所間違ってるよ。
共通関数を使うと決まっているプロジェクトで
処理一つ一つに「このコーディングに関する共通関数があるかもしれない」と
リストを探すのか？
そんな瑣末な決まりごとこそ無意識に書けるように仕様書に書いてあれば
開発効率は高まる。
どのメッセージIDを使うのかに頭使うより全体のロジックに頭使えよ。
35 仕様書無しさん :2006/06/14(水) 11:09:26本気でそう思ってるんなら、お前頭使う場所間違ってるよ。
共通関数を使うと決まっているプロジェクトで
処理一つ一つに「このコーディングに関する共通関数があるかもしれない」と
リストを探すのか？
そんな瑣末な決まりごとこそ無意識に書けるように仕様書に書いてあれば
開発効率は高まる。
どのメッセージIDを使うのかに頭使うより全体のロジックに頭使えよ。
>>34
そんなことしてるからエレベータが誤動作するんだよ
36 仕様書無しさん :2006/06/14(水) 11:15:08そんなことしてるからエレベータが誤動作するんだよ
>>35
そんなことしててるからエレベータが誤動作する原因がわからないんだよ
47 41 :2006/06/14(水) 15:05:03そんなことしててるからエレベータが誤動作する原因がわからないんだよ
ごめん、ちょっと整理したいんだけど、
>>1の仕様書が書かれる前に
メッセージID一覧とか言うやつと
使用共通関数一覧みたいなやつが
あらかじめコーディング規約にまとまっている、という前提の話なんだよね。コレ？
48 仕様書無しさん :2006/06/14(水) 15:35:27>>1の仕様書が書かれる前に
メッセージID一覧とか言うやつと
使用共通関数一覧みたいなやつが
あらかじめコーディング規約にまとまっている、という前提の話なんだよね。コレ？
>>47
それは前提としてあるだろう。
もう1つ、登場人物を定義したほうがいい。
他人にコーディングさせるんであれば書ける情報はトコトン書くし、自分でやるなら多少の省略もありだろう。
仕様書を書くってのは下の担当者への意思伝達と上位担当者への内容確認と両方出来たほうがいいしな。
50 仕様書無しさん :2006/06/14(水) 18:01:30それは前提としてあるだろう。
もう1つ、登場人物を定義したほうがいい。
他人にコーディングさせるんであれば書ける情報はトコトン書くし、自分でやるなら多少の省略もありだろう。
仕様書を書くってのは下の担当者への意思伝達と上位担当者への内容確認と両方出来たほうがいいしな。
細かい仕様の必要性は、
どれだけPG達が馬鹿か×システム規模、に比例する。
本当に優秀なPG達による１０数人月程度のシステムなら、
XPでほとんど仕様書無しで問題ない。
52 仕様書無しさん :2006/06/14(水) 18:33:14どれだけPG達が馬鹿か×システム規模、に比例する。
本当に優秀なPG達による１０数人月程度のシステムなら、
XPでほとんど仕様書無しで問題ない。
>>50
その考えがまさに開発効率を低めてるんだろうな。
「DB構成見て判断してよ」
「いつもみたいな感じで」
「質問あったらExcelにまとめて。後で聞いておくから」
挙句の果てに
「あぁ、、、そんなことも言ってたな、客。
でもなんとなくわかるっしょ」
53 仕様書無しさん :2006/06/14(水) 19:46:02その考えがまさに開発効率を低めてるんだろうな。
「DB構成見て判断してよ」
「いつもみたいな感じで」
「質問あったらExcelにまとめて。後で聞いておくから」
挙句の果てに
「あぁ、、、そんなことも言ってたな、客。
でもなんとなくわかるっしょ」
>>50は、考えじゃなくて事実を言ってるだけだが。
馬鹿の集団なら細かい仕様書は重要。
天才数人のドリームチームなら不要。
比例って言葉が難しかったか？
55 仕様書無しさん :2006/06/14(水) 20:00:17馬鹿の集団なら細かい仕様書は重要。
天才数人のドリームチームなら不要。
比例って言葉が難しかったか？
>>53
お前の言う「PGの天才」ってのは、
斬新で効率的なロジックを書くことでも、
後々に資産に出来そうなライブラリやフレームワークを作ることでもなくて
顧客の要求を満足に文章化して設計できない馬鹿SEの心を読み取って
アーキテクトの経験のみで何とかしてやる心優しい人のことを言うのかｗ
62 仕様書無しさん :2006/06/14(水) 22:29:14お前の言う「PGの天才」ってのは、
斬新で効率的なロジックを書くことでも、
後々に資産に出来そうなライブラリやフレームワークを作ることでもなくて
顧客の要求を満足に文章化して設計できない馬鹿SEの心を読み取って
アーキテクトの経験のみで何とかしてやる心優しい人のことを言うのかｗ
◆SEはいったいどこまで詳細に記述すればよいかを悩んでいる。
◆客と話はできるがVB.NETなどのIDEを理解していないなど様々なSEが寄り集まっていて、ルールを全体周知しても誤解（データベースの共通関数なのかVB.NETの共通関数なのかも区別できていない）されるなどまとまりがない。
◆せっかくのルールがあっても認識違いで設計書の記述がバラバラとなり、PGはやりにくさこの上ない。
63 仕様書無しさん :2006/06/14(水) 22:32:47◆客と話はできるがVB.NETなどのIDEを理解していないなど様々なSEが寄り集まっていて、ルールを全体周知しても誤解（データベースの共通関数なのかVB.NETの共通関数なのかも区別できていない）されるなどまとまりがない。
◆せっかくのルールがあっても認識違いで設計書の記述がバラバラとなり、PGはやりにくさこの上ない。
そんな香具師はSEやるべきじゃないよ
64 仕様書無しさん :2006/06/14(水) 23:24:41うちはここまでプログラムに近いレベルのドキュメントはSEじゃなくてPGが書くよ。
66 仕様書無しさん :2006/06/15(木) 05:36:11>>64
すなわち必要のないドキュメントである。
もとシンプルな設計書があれば真のPGは実装できる。
ちなみにアメリカにはSEなんて言葉辞書に載っていないし・・・
新卒で即SEを騙ってる（騙らしてる）香具師らをどうにかしてほしい
67 仕様書無しさん :2006/06/15(木) 10:16:55すなわち必要のないドキュメントである。
もとシンプルな設計書があれば真のPGは実装できる。
ちなみにアメリカにはSEなんて言葉辞書に載っていないし・・・
新卒で即SEを騙ってる（騙らしてる）香具師らをどうにかしてほしい
>>66
だから実装できるかどうかとか、真のPGとかどーでもいいから。
「開発効率の高まる仕様書」について語れ。
SEの愚痴なら社長に言え。
73 仕様書無しさん :2006/06/16(金) 07:00:37だから実装できるかどうかとか、真のPGとかどーでもいいから。
「開発効率の高まる仕様書」について語れ。
SEの愚痴なら社長に言え。
>>67
開発効率の高まる仕様書
テーブルレイアウト
ファイルレイアウト
ユーザーインターフェース設計書
イベントハンドリング設計書
これをシンプルな書式で用意する。
65 仕様書無しさん :2006/06/14(水) 23:29:02開発効率の高まる仕様書
テーブルレイアウト
ファイルレイアウト
ユーザーインターフェース設計書
イベントハンドリング設計書
これをシンプルな書式で用意する。
>>1
> 仕様書（設計書）
今更だが、仕様書と設計書は別物だと言う事、分かってる？
68 仕様書無しさん :2006/06/15(木) 11:00:36> 仕様書（設計書）
今更だが、仕様書と設計書は別物だと言う事、分かってる？
ＳＥとＰＧの人数を考えれば答えは自明。
ＳＥとＰＧでどっちが細かいことをちゃんと考えられるか考えれば答えは自明。
しかし、ＰＧが底辺の馬鹿ＰＧなら、ＳＥが手を掛けざるを得ない。
69 仕様書無しさん :2006/06/15(木) 12:37:40ＳＥとＰＧでどっちが細かいことをちゃんと考えられるか考えれば答えは自明。
しかし、ＰＧが底辺の馬鹿ＰＧなら、ＳＥが手を掛けざるを得ない。
SEがこんなに細かく指示するくらいならもうコード書いた方が早いじゃん。
75 仕様書無しさん :2006/06/16(金) 14:43:03>>69
この共通関数を使おう、とか
メッセージID：70は「使用回数は必ず入力してください」なのでそれを使ってくれ、
ってのは「コーディングした方が早いくらい細かい指示」なの？
俺は書く側も作る側もやるんだけど、
書く時はこういう「決まりごと」的なものはなるべく細かく書くけどな。
PGが考えるのはどうすればデータを安全に効率よく遷移させるかっていう
アーキテクト部分じゃないかな。俺はそこは全面的にPGにまかせる。
71 仕様書無しさん :2006/06/15(木) 23:05:22この共通関数を使おう、とか
メッセージID：70は「使用回数は必ず入力してください」なのでそれを使ってくれ、
ってのは「コーディングした方が早いくらい細かい指示」なの？
俺は書く側も作る側もやるんだけど、
書く時はこういう「決まりごと」的なものはなるべく細かく書くけどな。
PGが考えるのはどうすればデータを安全に効率よく遷移させるかっていう
アーキテクト部分じゃないかな。俺はそこは全面的にPGにまかせる。
レビューだとか打ち合わせだとか時間だけ食って、設計書の精度はいっこうに向上しない。
PGは要件仕様書さえあればコーディングできるはずだ。
SEは時間つぶしてるだけ
83 仕様書無しさん :2006/06/16(金) 18:11:05PGは要件仕様書さえあればコーディングできるはずだ。
SEは時間つぶしてるだけ
・テーブルレイアウト
・ファイルレイアウト
・ユーザーインターフェース設計書
きちんと書けていれば楽になる・・ってそれが普通か。
システムの基本要求すら実現できないいい加減な仕様書を渡され、
作り始めても当然進まず、設計者の隣にうんこ座りで
ヒアリングして自分で仕様書を完成させないといけない。
そんな環境にいる自分はやはり底辺でしょうか。
88 仕様書無しさん :2006/06/16(金) 23:16:27・ファイルレイアウト
・ユーザーインターフェース設計書
きちんと書けていれば楽になる・・ってそれが普通か。
システムの基本要求すら実現できないいい加減な仕様書を渡され、
作り始めても当然進まず、設計者の隣にうんこ座りで
ヒアリングして自分で仕様書を完成させないといけない。
そんな環境にいる自分はやはり底辺でしょうか。
標準に則さない間違いだらけの設計書をもらったが、システムとして成り立つように翻訳して実装することは可能な訳さ。
でもね、開発リーダー（開発標準を決めた張本人）が、うるさいわけ。
間違いに気づいたらSEにボトムアップしろと。
間違い大杉で、設計書を作らせるのに手間がかかり、実装する暇がない訳さ。
開発リーダーもSEも何様のつもりなんだか。
89 仕様書無しさん :2006/06/17(土) 02:07:52でもね、開発リーダー（開発標準を決めた張本人）が、うるさいわけ。
間違いに気づいたらSEにボトムアップしろと。
間違い大杉で、設計書を作らせるのに手間がかかり、実装する暇がない訳さ。
開発リーダーもSEも何様のつもりなんだか。
設計書はwhatを書くところで、ソースはhowを書くところ。
90 仕様書無しさん :2006/06/17(土) 08:40:32>>89
しかしながら、whatとhowを両方書いていて、
しかもhowが間違っている上に、リーダーはいったんその通り作れだの、逐一ボトムアップしろだの、うるさい。
設計書以外に開発標準書という妙なドキュメントにもhowがあり、リーダーが作ったテンプレート（これを原則使え客がうるさいから）にもhowがあるわけさ。
何を正として作業を進めてもやはりシステムは完成しない。
それならプログラマがシステムを構築するべく、道を切り開いていかねばならない。底辺PGは辛いのだ。
94 仕様書無しさん :2006/06/17(土) 12:07:23しかしながら、whatとhowを両方書いていて、
しかもhowが間違っている上に、リーダーはいったんその通り作れだの、逐一ボトムアップしろだの、うるさい。
設計書以外に開発標準書という妙なドキュメントにもhowがあり、リーダーが作ったテンプレート（これを原則使え客がうるさいから）にもhowがあるわけさ。
何を正として作業を進めてもやはりシステムは完成しない。
それならプログラマがシステムを構築するべく、道を切り開いていかねばならない。底辺PGは辛いのだ。
設計書を貰ってきたけど
I/F仕様無し、データ仕様無し、U/I仕様無し・・・・・・
どこが詳細設計なんだ・・・・・
これ、要件定義しかしてないぞ
モジュール構成とテーブルレイアウトは月曜提出だってさ＿|￣|○
ER図起こさないと・・・・
ってこれPGの仕事なのか？
95 仕様書無しさん :2006/06/17(土) 12:10:39I/F仕様無し、データ仕様無し、U/I仕様無し・・・・・・
どこが詳細設計なんだ・・・・・
これ、要件定義しかしてないぞ
モジュール構成とテーブルレイアウトは月曜提出だってさ＿|￣|○
ER図起こさないと・・・・
ってこれPGの仕事なのか？
>>94
SEって、スケジュール管理表とにらめっこしてるだけのヤシいるよな
あぁいうヤシは逝ってよし
104 仕様書無しさん :2006/06/20(火) 18:41:41SEって、スケジュール管理表とにらめっこしてるだけのヤシいるよな
あぁいうヤシは逝ってよし
コーディングだけが開発ですか？って事だよ
その手の事を詳細に書くときに発生する矛盾が残るよりも
１つの事象は１つの箇所に書き留める様にすれば、矛盾が起きた場合のリスクが軽減できる
105 仕様書無しさん :2006/06/20(火) 19:13:11その手の事を詳細に書くときに発生する矛盾が残るよりも
１つの事象は１つの箇所に書き留める様にすれば、矛盾が起きた場合のリスクが軽減できる
>>104
個人的に思うのはね、
PGの仕事っていうかキモの部分っていうのは
仕様書を見て、同じプロジェクト内の他の仕様書と合わせて
どういう風にクラスを切っていこうか、とか
ここはインターフェースにするべき、いや抽象クラスにするべき、とか
最終的にどのタイミングでDBに詰めて永続化させるか、とか
ここでトランザクションをかけたら負荷的にどうだろう、とか
そういう技術的な実現方法を考えることだと思うんだよね。
演出家(SE)に対する撮影部(PG)みたいな。
そうすると演出意図(設計意図)を理解するのに台本(仕様書)の他に
配役表(DB構成図)やスケジュール表(コーディング規約)を読み直さないといけない、
ってのは
ドキュメントとしてはまとまってていいと思うんだけど
開発効率としてはどうなんだろうな、と思うわけです。
106 仕様書無しさん :2006/06/20(火) 19:29:58個人的に思うのはね、
PGの仕事っていうかキモの部分っていうのは
仕様書を見て、同じプロジェクト内の他の仕様書と合わせて
どういう風にクラスを切っていこうか、とか
ここはインターフェースにするべき、いや抽象クラスにするべき、とか
最終的にどのタイミングでDBに詰めて永続化させるか、とか
ここでトランザクションをかけたら負荷的にどうだろう、とか
そういう技術的な実現方法を考えることだと思うんだよね。
演出家(SE)に対する撮影部(PG)みたいな。
そうすると演出意図(設計意図)を理解するのに台本(仕様書)の他に
配役表(DB構成図)やスケジュール表(コーディング規約)を読み直さないといけない、
ってのは
ドキュメントとしてはまとまってていいと思うんだけど
開発効率としてはどうなんだろうな、と思うわけです。
>>105
この女優は右斜め45度以外の角度は撮ってはいけない。
この男優は横から撮ると肉のだぶ付きが見えるため撮ってはいけない。
この建物は撮影許可とっていないから枠に入れてはいけない。
色々と制限事項はあるよね。これを台本に書いておくべきだと
ある日男優が病気で急遽出演できなくなり整合性を撮るために一部取り直しする事が決定した
こいつは真正面から撮ると蛙みたいに見えるので常に斜め30度の角度から撮らなくちゃいけない
こういう状況で、お前さんは台本が全て書き直されるのを待つのが効率が良いと言うのだな
107 仕様書無しさん :2006/06/20(火) 19:49:20この女優は右斜め45度以外の角度は撮ってはいけない。
この男優は横から撮ると肉のだぶ付きが見えるため撮ってはいけない。
この建物は撮影許可とっていないから枠に入れてはいけない。
色々と制限事項はあるよね。これを台本に書いておくべきだと
ある日男優が病気で急遽出演できなくなり整合性を撮るために一部取り直しする事が決定した
こいつは真正面から撮ると蛙みたいに見えるので常に斜め30度の角度から撮らなくちゃいけない
こういう状況で、お前さんは台本が全て書き直されるのを待つのが効率が良いと言うのだな
>>106
女優や俳優の角度(取り扱い商品の表示制限)ってのは絵コンテで
事前に詳細に説明するべき所だし、
撮影許可(ライセンス)があるかどうかはさらにその前段階の話でしょ。
ロケハン(使用ツール策定)の段階で判断するもの。
音楽番組でアーティストが病気で急遽他のアーティストに代わったら
演出台本が書き直しになるのは、至極当然のことじゃない。
書いてる時間がなければカメリハの段階で口頭指示が出て、
みんな自分の台本にそれを書き込むよ。
急な制限事項の変更で仕様を書き直してる暇がなければ
緊急ミーティング開いて、今までの仕様書にPGが新たに書き込んだりするじゃん。
つまりさ、SEが「こんな感じになるのが理想」って部分が
PGが頭搾って考えるところでさ、
「こうして欲しい」ってものが明確にある部分は
仕様書に詳細に書いてあった方がPGとしては効率がいいと思うんだよね。
それがSEにとって2度手間になっている場合、
SEとPG、どっちが手間をかけるか、という話だと思う。
111 仕様書無しさん :2006/06/21(水) 00:46:46女優や俳優の角度(取り扱い商品の表示制限)ってのは絵コンテで
事前に詳細に説明するべき所だし、
撮影許可(ライセンス)があるかどうかはさらにその前段階の話でしょ。
ロケハン(使用ツール策定)の段階で判断するもの。
音楽番組でアーティストが病気で急遽他のアーティストに代わったら
演出台本が書き直しになるのは、至極当然のことじゃない。
書いてる時間がなければカメリハの段階で口頭指示が出て、
みんな自分の台本にそれを書き込むよ。
急な制限事項の変更で仕様を書き直してる暇がなければ
緊急ミーティング開いて、今までの仕様書にPGが新たに書き込んだりするじゃん。
つまりさ、SEが「こんな感じになるのが理想」って部分が
PGが頭搾って考えるところでさ、
「こうして欲しい」ってものが明確にある部分は
仕様書に詳細に書いてあった方がPGとしては効率がいいと思うんだよね。
それがSEにとって2度手間になっている場合、
SEとPG、どっちが手間をかけるか、という話だと思う。
アジャイル開発ならそんな設計書自体いらないみたいよ。
112 仕様書無しさん :2006/06/21(水) 00:52:11>>111
そのかわり、触って試せる動く仕様書が必要だけどね。
114 仕様書無しさん :2006/06/21(水) 15:48:19そのかわり、触って試せる動く仕様書が必要だけどね。
>>111
あれは一人でやるにはいいが、ある程度の人数になると負のスパイラルに陥るぞ。
デスマが好きならお勧め。
あれは一人でやるにはいいが、ある程度の人数になると負のスパイラルに陥るぞ。
デスマが好きならお勧め。
オススメの動画
今日の更新一覧
