どちらの設計書が開発効率が高いだろうか？

PGにとって、次のどちらの仕様書（設計書）が開発効率が高い？

例１
◆CSVファイル取込処理
　（１）ファイル選択ダイアログを表示する。
　（２）ファイルが選択されたら処理を行う。
　　　　※エラーの場合はメッセージを表示する。
　　　　「テキストファイルの読み込みに失敗しました。」
例２
◆CSVファイル取込処理
　（１）ファイル選択ダイアログを表示する。
　　　（共通関数：F_GetOpenFile）※関数の仕様については別紙参照。
　（２）関数の戻り値が正常（０）ならば処理を行う。
　　　　関数の戻り値が異常（−１）ならばメッセージを表示する。
　　　（メッセージID：100「テキストファイルの読み込みに失敗しました。」）
　　　　メッセージについては、共通メッセージ一覧を参照。
　（３）共通エラーチェックを行う。

例１と例２は共にCSV取込み処理について記述したものであるが、例２では、使用する関数名やメッセージIDが指定されている点で例１と異なる。さらに共通エラーチェックという妙な記述がある。
皆さんの意見を伺いたい。

余裕の２ＧＥＴ

ム板の話題だろ

VB.NETを選択する

とりあえずダブルコートと改行コードと
エスケープの扱いを書けと文句言い
その上で解析面倒、外部システムとの結合面倒なのを力説し
XMLに変更させる

以上

XML房は勘弁してくだちぃ

>>1
CSV の仕様も
取り込んだ内容をどこに保持するのかも
書かれていない。

結論: どちらも素人の書いたクソ。

ドキュメントとして残すべきはCSVファイル取込処理じゃなくてXXデータ取込処理なんじゃないか？
で、データ構造とかパーシステンスとか考慮のうえ記憶媒体をCSVファイル
にするかXMLにするかDBにするか決める、と。

共通エラーチェックってのが、例1では踏み込まれて無い内容なので、
比較することが出来ない。

入出力を意識して書いて欲しいよな。仕様書は。

どういうフォーマットの入力を受け付け（はじかなければいけない条件は何なのか）
どのような出力先(DBやファイルや画面)にどのように出力すればいいのか。

そうすりゃ、プログラマは間の処理を記述するのに集中できるってもんだ。

>>1みたいなドキュメントって、全然必要ない。
いつそのデータが欲しいのかとかデータ構造がどうなっているとか
ファイルフォーマットが破損していたときどういう後処理をしたいとか
そういう情報がわかれば>>1みたいなことは自動的に導き出されるから。
逆にそういう「何がやりたいか」みたいな情報が全く設計書に記述されて
ないからPGはSEに質問を投げまくることになる。

>1を見たときは「なんだこの糞スレwww」と思ったが
わりと良スレになりそうだな

例１
　担当者名　文字列型
　有効日付　日付型
例２
　担当者名　TextBox　文字列型(50)
有効日付　InputMan 日付型

例１と例２は、いずれもコントロールの説明であるが、例２は、コントロールの種類や長さまで指定されているケースである。
いったいどちらが開発効率は良いのだろうか？

例１は操作仕様書としてみれば及第点。
例２はそれにプログラム仕様書かデータ設計書にかかれるべきものの一部が載ってるメモ書き。

半角だけなのか
全角をゆるすのか
文字コードは何か

う〜ん、>>1は例２を見て「こんなコードに近い記述意味ねーよｗ」とか言って欲しかったのか？

PG仕様書ってSEが書くべきなの？

>>1
とりあえずこれだけでCSV取り込み処理をコーディングすることはできない。情報が少なすぎて。
んで、これらを「ダイアログ出して選択させる」とこまで、と考えるなら
事前のミーティングとか会社の状況によるんだろうね。
例2の「共通関数」ってのが会社として何回も実績のある関数なのか、
そのプロジェクトで初めて扱うものなのかによっても違うし。
個人的には(例2)の方がいいかな。

>>12
これ見ながらmaxLengthとか設定するんでしょ。んじゃ例2だなあ。
有効日付にInputMan使うとか、例2じゃなきゃわかんないし。

どっちもダメだけど
どっちか選べとしたら１だろ。

>>15
その通り。

別にコーダーを意識して書かれた設計書ではなく、発注したSIerの考えが古くさいだけ。
要は、ドキュメントとソースの体裁を完璧にしたいだけのようなのだ。
ユーザー要件は二の次にされている。

漏れは、ソースは書くものではなく描くものであると考えている。
しかし、漏れのリーダーは、他のプログラマに統一性のないコードを書かれるのを嫌っている。
SIerがうるさいからそうしているというわけ。

ソースを大事にするかユーザ要件を満たすかどっちが大事か分かるだろう。
今回のユーザ要件はきれいにソースを書くことなのか（爆）

汚いソースだと保守できなくなるだろ？

保守できなくて何がユーザーのためなんだよ

>漏れは、ソースは書くものではなく描くものであると考えている。
￣￣減点 100

>>19
今回の要件でなく、プロとしての要件
それができないなら単金下げられると考えろ

> しかし、漏れのリーダーは、他のプログラマに統一性のないコードを書かれるのを嫌っている。
そりゃある程度は仕方ないだろ。
共通ルーチンあるのにオウンコーディングされてたりしたら最悪。

>>19
言いたいことはわかる。
でもそれをするのはPGの仕事じゃなくてアーキテクトの仕事だと思う。

それよか要求仕様をかっちりしとけ

どちらもつまらない

設計とコーディングの両方をやってるが、>>1なら絶対に例２のほう。
共通関数とはいえ、所詮はそのシステムでのローカルな共通関数であり、
どうしてもそれを使えというならきちんと目立つように書くべき。
できれば太字にしたり下線を引いたりして強調すること。

>>12のケースなら、例２をきちんと表にまとめて別シートで記載すべき
だな。。

例2の方がマシではあるが

＞（共通関数：F_GetOpenFile）※関数の仕様については別紙参照。
関数名だしてるんだからワザワザ別紙参照とか注釈(ﾟ�听)ｲﾗﾈ

＞　　　（メッセージID：100「テキストファイルの読み込みに失敗しました。」）
＞　　　　メッセージについては、共通メッセージ一覧を参照。
これもそう。メッセージIDだけでいいな。

＞　（３）共通エラーチェックを行う。
意味不明

思い出した。
昔、某Iのドキュメントがこんな感じでファイルフォーマットも何もまったく不明な状態で「見積もれ」って指示が来たので
「仕様の詰め」工数上乗せしたらおこられた(´･ω･`)

ソースが仕様書。一番確実・正確。

こんな馬鹿みたいなもんいちいち書くのって、
昔の底辺COBOLerレベルのクズPG寄せ集めのカスプロジェクトだろ。

例２がマシでさらに細かく書けとか言ってる奴らって、
コーディングを、日本語からプログラム言語への変換とか勘違いしてるアホだろ。
頭使うのがコーディングなんだよ。まさかそれで給料貰ってないよね？

だいたい、F_GetOpenFileって何だよこの関数名のセンスｗｗ

>>31
漏れは、「こんなプロジェクトぶっ壊して辞めるか」「仕方なく続けるか」の２択しかないわけで・・・

関数名のセンスの話だが、
例えば、Public Function だからって、PF_GetOpenFIleとかつけるのさ。漏れはキモイとは思いつつ、開発標準だってさ。
Public SubだからPS_SetEnabledとか

あと、ループカウンタにDim intLoop As Integer とか

この辺の事情はどうなんだろか？

>>31
意見書いてるのがコーディング側の人とは限らないぞ。たぶん逆。
>>32
微妙なルールだな。SubとFunctionなんて分ける必要あるのかとか・・・
目的があってこその分類・命名だと思うのだがその辺りがわからんないね。
個人的には、スコープを示すPrefixは使う。ローカル名には特にルールはない。
って感じかな。

>>31
本気でそう思ってるんなら、お前頭使う場所間違ってるよ。
共通関数を使うと決まっているプロジェクトで
処理一つ一つに「このコーディングに関する共通関数があるかもしれない」と
リストを探すのか？
そんな瑣末な決まりごとこそ無意識に書けるように仕様書に書いてあれば
開発効率は高まる。

どのメッセージIDを使うのかに頭使うより全体のロジックに頭使えよ。

>>34
そんなことしてるからエレベータが誤動作するんだよ

>>35
そんなことしててるからエレベータが誤動作する原因がわからないんだよ

>>34
そんなの頭使う内に入らん
そもそも仕様書じゃなくてコーディング規約作っただろうが
それを守れ

あのゲロみたいなハンガリアンの元締めMSですら、もう改心してるのに、
今更なにその名前規約。名前にそんなもんくっつけて何が楽しいの？

っていうか、「動詞動詞名詞」ってどこの言葉？

>>34
共通関数を探すのが、頭を使う、か。スゲェ頭だな。
そんな程度の頭だったら確かに使って貰ったら困るかも知れん。
あと、共通関数をどうするなんてのは、個別仕様じゃなくて、ルール。

>>37>>39
例えば>>1の言う共通関数が50個弱あって、
使用するメッセージがID250まで並んであったとする。

で、使う時どーすんの？「頭使う内入らん」ってことは事前に全部暗記してるの？
それとも探すのはルーチンワークだから手間を惜しまない、てこと？
コーディング規約の「メッセージID一覧」でも引きますか？ｗ

どっちにしても開発効率が下がることには変わんねーよ。
そんなんだから「ドカタPG」って言われんだよｗｗ

>>40
微妙なところだね。
メッセージIDは仕様書に書いてあるとラクでいいと思うけど、
共通関数は事前に軽くチェックしてあればわざわざ書かなくても覚えてるかなぁ。

>>40
馬鹿かお前
その後の開発途中やメンテナンスで莫大なコストを払うこと考えたらその程度の開発効率の低下なんか微々たる物だろ
客は開発には金を払うけど、リリース段階のチューニングとかメンテナンスなんかにはあんまり金を出さないだろ
瑕疵担保責任もある以上、後工程が楽になる様にするのが当たり前

むしろそういうルール守れない奴は切り捨てる方向が正しい

ただメッセージはUI要件だからIDが仕様書に書いてあるのが望ましいな

IDなんてある程度ルール作って、共通のモノ以外、コーディングと共にExcel記入だろ。
仕様時点のIDだけなんて、糞使えないむかつくシステムまっしぐら

>>42
チューニングやメンテ、リファクタリングを楽にする、というのと
共通関数名を仕様書に書く書かないが全然繋がらないんだけど。
書かなかったらメンテがラクになるの？

共通関数を使うのがルールなんだから
仕様書に書いてあればPGがラク、書かなくて良ければSEがラクって話でしょ。
>>40はいちいち関数一覧を引きなおさなくても良いように
仕様書に書いてあるとラクって話をしてるわけで
書いてなければ共通関数を使わなくてもいい、とは一言も言ってないよ。
馬鹿？

>>41
仕様書に使用する関数を書くってのはレビュー時にも使うんだけどね。
「この処理は皆同じことしますよー」ってね。

関数書いてない＝自力でコーディング
となっても文句は言えない。

>>40は「ソースさえあれば仕様書なんていらないYO!」っていう高校生

>>45
つまりおまいは仕様書に共通関数名は書いてあった方が望ましい、と思ってるんだよね｡

じゃあちゃんとレス見直した方がいい。

文章も流れもちゃんと読まずに即書き込む。
そういう注意力のなさがバグを生む。

ごめん、ちょっと整理したいんだけど、

>>1の仕様書が書かれる前に
メッセージID一覧とか言うやつと
使用共通関数一覧みたいなやつが
あらかじめコーディング規約にまとまっている、という前提の話なんだよね。コレ？

>>47
それは前提としてあるだろう。
もう1つ、登場人物を定義したほうがいい。

他人にコーディングさせるんであれば書ける情報はトコトン書くし、自分でやるなら多少の省略もありだろう。
仕様書を書くってのは下の担当者への意思伝達と上位担当者への内容確認と両方出来たほうがいいしな。

>>44
ちがうよ
>>40は煽りたいだけの馬鹿だよ

細かい仕様の必要性は、
どれだけPG達が馬鹿か×システム規模、に比例する。

本当に優秀なPG達による１０数人月程度のシステムなら、
XPでほとんど仕様書無しで問題ない。

だな。
大規模システムを安物PGの人海戦術でどうにかしようってのは、
愚の骨頂

>>50
その考えがまさに開発効率を低めてるんだろうな。
「DB構成見て判断してよ」
「いつもみたいな感じで」
「質問あったらExcelにまとめて。後で聞いておくから」

挙句の果てに
「あぁ、、、そんなことも言ってたな、客。
でもなんとなくわかるっしょ」

>>50は、考えじゃなくて事実を言ってるだけだが。
馬鹿の集団なら細かい仕様書は重要。
天才数人のドリームチームなら不要。
比例って言葉が難しかったか？

>>53
>>53
>>53
>>53

>>53
お前の言う「PGの天才」ってのは、
斬新で効率的なロジックを書くことでも、
後々に資産に出来そうなライブラリやフレームワークを作ることでもなくて

顧客の要求を満足に文章化して設計できない馬鹿SEの心を読み取って
アーキテクトの経験のみで何とかしてやる心優しい人のことを言うのかｗ

天才なんだから両方できるに決まってんだろ。
どういう頭だったら、片方が出来たら片方が出来ないって発想になるんだろう。可哀想に。

>>53みたいな反論する人って、スレタイの意味を理解してないんじゃないかな。
メッセージIDが指定されていなければ、一覧から使えそうなものを探す。
共通関数名が書いていなければ、独自にコーディングする前に
使える関数があるかどうかをチェックしてからコーディングする。

SEにしてみれば一覧に書いてあることからチェックして仕様書に書き込んでいくわけで。

要はその手間をSEとPGのどっちが持つか、っていうことで
PGが馬鹿だから詳しく書いてやらなきゃいけない、ということじゃないと思う。

漏れは >53 じゃないが SE なんて不要だと思う

えー、まとめます。

・SEは馬鹿で面倒くさがり
・PGが手間ひまかけて漁ってくれるなら何もしたくはない。
・天才はなんでも出来て当たり前。
・PGとはSEの面倒くささをどれだけ解消させられるかで馬鹿さ度合いが決まる。

これでよござんすか？>>53様に>>56様ｗｗｗｗｗｗ

いや。
これを見てコーディングするPGの作業時間だけを考えれば
そりゃ例2の方が早いだろうけど、
この資料を書くヤツの作業も考えると、どっちも変わらないし、どっちも無駄。

底辺PGが一匹ファビョってるな
PGが天才ならSEは要らないし、SEが天才ならPGも要らない。
実際、組み込みでは天才でなくてもそうらしいし。

◆SEはいったいどこまで詳細に記述すればよいかを悩んでいる。

◆客と話はできるがVB.NETなどのIDEを理解していないなど様々なSEが寄り集まっていて、ルールを全体周知しても誤解（データベースの共通関数なのかVB.NETの共通関数なのかも区別できていない）されるなどまとまりがない。

◆せっかくのルールがあっても認識違いで設計書の記述がバラバラとなり、PGはやりにくさこの上ない。

そんな香具師はSEやるべきじゃないよ

うちはここまでプログラムに近いレベルのドキュメントはSEじゃなくてPGが書くよ。

>>1
> 仕様書（設計書）

今更だが、仕様書と設計書は別物だと言う事、分かってる？

>>64
すなわち必要のないドキュメントである。
もとシンプルな設計書があれば真のPGは実装できる。

ちなみにアメリカにはSEなんて言葉辞書に載っていないし・・・

新卒で即SEを騙ってる（騙らしてる）香具師らをどうにかしてほしい

>>66
だから実装できるかどうかとか、真のPGとかどーでもいいから。
「開発効率の高まる仕様書」について語れ。
SEの愚痴なら社長に言え。

ＳＥとＰＧの人数を考えれば答えは自明。
ＳＥとＰＧでどっちが細かいことをちゃんと考えられるか考えれば答えは自明。

しかし、ＰＧが底辺の馬鹿ＰＧなら、ＳＥが手を掛けざるを得ない。

SEがこんなに細かく指示するくらいならもうコード書いた方が早いじゃん。

その通り。しかし底辺PGが…

レビューだとか打ち合わせだとか時間だけ食って、設計書の精度はいっこうに向上しない。

PGは要件仕様書さえあればコーディングできるはずだ。

SEは時間つぶしてるだけ

>>67
SES契約（偽装派遣）のため、うちの社長に発言権がありません。

>>67
開発効率の高まる仕様書

テーブルレイアウト
ファイルレイアウト
ユーザーインターフェース設計書
イベントハンドリング設計書

これをシンプルな書式で用意する。

テーブルレイアウトはER図を包含してるのかな。ER図欲しい....。

>>69
この共通関数を使おう、とか
メッセージID：70は「使用回数は必ず入力してください」なのでそれを使ってくれ、
ってのは「コーディングした方が早いくらい細かい指示」なの？

俺は書く側も作る側もやるんだけど、
書く時はこういう「決まりごと」的なものはなるべく細かく書くけどな。
PGが考えるのはどうすればデータを安全に効率よく遷移させるかっていう
アーキテクト部分じゃないかな。俺はそこは全面的にPGにまかせる。

アーキテクト部分…

ルールや規約を細かくするのと、仕様を細かくするのは別の話。
SEの足りない考えで細かく仕様を指定されたら、効率や改善の邪魔

>>76
>>1はどうみても「ルールや規約」の範疇じゃん。
読解力ないな。

で、「SEは俺より考えが足りない」っていう根拠のない自信はどこからくるの？
SEじゃなくてチーム組んでる他のPGが考えた仕様なら納得いくの？

もしかして「お前らは勝手にやれ。俺は俺の考えで組む」っていうタイプ？

読解力ないのか？
>>1は規約を個々の仕様に書いてるんだがね

読解力ないのか？
規約を個々の仕様に書くことは「細かく仕様を指定する」とは言わん。

読解力ないのか？
規約と、規約の適用は違う。

読解力ないのか？
自分で考えた規約を自分が使って欲しい所に適用する旨書き込むことは
「細かく仕様を指定する」とはまったく別次元の話。

遊んでるところ横レススマソ。
>>80
お前の会社のSEは規約を作っておいて、どう使うかはほったらかしなの？

・テーブルレイアウト
・ファイルレイアウト
・ユーザーインターフェース設計書
きちんと書けていれば楽になる・・ってそれが普通か。

システムの基本要求すら実現できないいい加減な仕様書を渡され、
作り始めても当然進まず、設計者の隣にうんこ座りで
ヒアリングして自分で仕様書を完成させないといけない。
そんな環境にいる自分はやはり底辺でしょうか。

>>82
どういう場合に何をどう使うかまで決めておけば、
仕様書全部に同じものをコピペしなくてもいいじゃんって話だろ。

ならば、コーディング規約の適用についても、
それぞれの項目について使って欲しい場所で仕様書に全て書き込みたまえ。

>>85
そんなの事前に打ち合わせろ
一般化するな

ならば、自分で考えた規約なんて事前に打ち合わせろ
特別扱いするな。

標準に則さない間違いだらけの設計書をもらったが、システムとして成り立つように翻訳して実装することは可能な訳さ。

でもね、開発リーダー（開発標準を決めた張本人）が、うるさいわけ。

間違いに気づいたらSEにボトムアップしろと。

間違い大杉で、設計書を作らせるのに手間がかかり、実装する暇がない訳さ。

開発リーダーもSEも何様のつもりなんだか。

設計書はwhatを書くところで、ソースはhowを書くところ。

>>89
しかしながら、whatとhowを両方書いていて、
しかもhowが間違っている上に、リーダーはいったんその通り作れだの、逐一ボトムアップしろだの、うるさい。

設計書以外に開発標準書という妙なドキュメントにもhowがあり、リーダーが作ったテンプレート（これを原則使え客がうるさいから）にもhowがあるわけさ。

何を正として作業を進めてもやはりシステムは完成しない。

それならプログラマがシステムを構築するべく、道を切り開いていかねばならない。底辺PGは辛いのだ。

バカが沸いてるな

間違ってたら指摘する修正するのは当たり前のことだ。

>>91
SEがバカだから間違うわけで・・・
PGにしてみれば、「バカなSEがいてお気の毒ですね」といわれてしまえば、もう手の打ち所がないわけである。

開発効率を下げているのは、「開発効率をあげるために開発標準とテンプレートを作った」とほざく、リーダーとボトルネックSEどもなのさ。

その糞リーダーは「人間に完璧なヤシはいないので、70%もできれば上等」だとほざいているが、実情は30%もできていないかもな

設計書を貰ってきたけど
I/F仕様無し、データ仕様無し、U/I仕様無し・・・・・・
どこが詳細設計なんだ・・・・・
これ、要件定義しかしてないぞ

モジュール構成とテーブルレイアウトは月曜提出だってさ＿|￣|○
ER図起こさないと・・・・
ってこれPGの仕事なのか？

>>94
SEって、スケジュール管理表とにらめっこしてるだけのヤシいるよな

あぁいうヤシは逝ってよし

>>94　>>95
今の現場でも似たようなもんだ。
SE様、設計どころか要件定義もしない。
PGの進捗管理だけがお仕事らしい。

去年の現場のSEさんは優秀だったんだけどなぁ・・・

まあ、完成しないプロジェクトだから、テキトウに残業してもらう物もらってればいいだろ。

SES契約（偽装請負）なので、完成するまで付き合わされる。

漏れはむしろ、他のPGよりも中途半端にまともな人間と評価されているため、えらく持ち上げられ、おだてられて、コーディングマシーンと化しているのである。

漏れは残業は嫌いで、朝一番（８時半過ぎ）に出社して21時までに帰ることを目標としてコンスタントにがんばっているのであるが、同じプロジェクトの馬鹿ばっかが残業しているので先に帰るのになぜかしら抵抗を感じるのであった。

>>98
立派に残業中毒なのに、なんで残業してないとか言うのかな？

>>99
同じSES契約（すでに長期）のヤシで開発寒リーダーのヤシがしょっちゅう深夜残業（マン喫やオフィスで夜を明かしている）や休日出勤してることから（そいつものすごいど阿呆なんだけどね）

漏れの残業は残業と思ってもらえていない。

あげくの果てに土曜日出てくれるかとかいわれそうな雰囲気だ。

ちなみに漏れは、今のプロジェクト以外に別のプロジェクトのプログラム保守（最終試験中）を平行で行っているのだ。

詳しく書かれていると思いきや・・・

例えば、「納品完了伝票の場合編集不可とする」だけ書いている場合がある。

これだけでは、不足である。「発注テーブルの納品完了フラグが納品完了となっている場合」とせめて記述してほしいものである。

こんな記述が抜けていて、後は中途半端にプログラム設計書に近い書き方になっている。

記述量は多いが、情報量は少ない設計書ってどやねん！？

つうか設計書に詳細落とす前に業務の状態を分析した用語辞書やコード定義などを作っておけば
「納品完了伝票」とは何？とが「納品完了伝票が編集不可状態になる」とはどういう事かが決められる。

ようするに業務の分析と用語の定義とがしっかりして無いだけだろ
曖昧な言葉で曖昧に仕様書・設計書を書くから問題がある

それを設計書にいちいち書く必要があるかどうかは別問題

ちなみに用語辞書やコード定義があるのに>>101の様に言うならばそいつはコーダ

>>102
でもさ、スレタイにある開発効率っていう点で考えれば

>それを設計書にいちいち書く必要があるかどうかは別問題

まさにこの問題についてじゃないの？

「納品完了伝票とはどういう状態のレコードを指すか」というのは
打ち合わせや事前ミーティングでなんとなくわかってたり
DB設計書のテーブル構成のフィールドに「納品完了フラグ」ってあれば
「ああ、これが1なら納品完了なんだ」ってのはわかる。

で、「納品完了伝票の場合編集不可とする」と書いてあった場合。
「納品完了伝票って何よ？」とDB設計書を漁るより、一言
。「発注テーブルの納品完了フラグが納品完了となっている場合」の方が
効率はいいわけで。

さらに言うと「編集不可」ってのはレコードが呼び出せない状態を言うのか、
表示はするが中の値を変えることは出来ないという意味なのか、とか。

こういう細かいところを一回一回SEに電話したり他の資料で調べたりするのは
PGの当然の義務なのか、それとも無駄な作業に入るのか。

コーディングだけが開発ですか？って事だよ
その手の事を詳細に書くときに発生する矛盾が残るよりも
１つの事象は１つの箇所に書き留める様にすれば、矛盾が起きた場合のリスクが軽減できる

>>104
個人的に思うのはね、
PGの仕事っていうかキモの部分っていうのは
仕様書を見て、同じプロジェクト内の他の仕様書と合わせて

どういう風にクラスを切っていこうか、とか
ここはインターフェースにするべき、いや抽象クラスにするべき、とか
最終的にどのタイミングでDBに詰めて永続化させるか、とか
ここでトランザクションをかけたら負荷的にどうだろう、とか

そういう技術的な実現方法を考えることだと思うんだよね。
演出家(SE)に対する撮影部(PG)みたいな。

そうすると演出意図(設計意図)を理解するのに台本(仕様書)の他に
配役表(DB構成図)やスケジュール表(コーディング規約)を読み直さないといけない、
ってのは
ドキュメントとしてはまとまってていいと思うんだけど
開発効率としてはどうなんだろうな、と思うわけです。

>>105
この女優は右斜め45度以外の角度は撮ってはいけない。
この男優は横から撮ると肉のだぶ付きが見えるため撮ってはいけない。
この建物は撮影許可とっていないから枠に入れてはいけない。

色々と制限事項はあるよね。これを台本に書いておくべきだと

ある日男優が病気で急遽出演できなくなり整合性を撮るために一部取り直しする事が決定した
こいつは真正面から撮ると蛙みたいに見えるので常に斜め30度の角度から撮らなくちゃいけない

こういう状況で、お前さんは台本が全て書き直されるのを待つのが効率が良いと言うのだな

>>106
女優や俳優の角度(取り扱い商品の表示制限)ってのは絵コンテで
事前に詳細に説明するべき所だし、
撮影許可(ライセンス)があるかどうかはさらにその前段階の話でしょ。
ロケハン(使用ツール策定)の段階で判断するもの。

音楽番組でアーティストが病気で急遽他のアーティストに代わったら
演出台本が書き直しになるのは、至極当然のことじゃない。

書いてる時間がなければカメリハの段階で口頭指示が出て、
みんな自分の台本にそれを書き込むよ。

急な制限事項の変更で仕様を書き直してる暇がなければ
緊急ミーティング開いて、今までの仕様書にPGが新たに書き込んだりするじゃん。

つまりさ、SEが「こんな感じになるのが理想」って部分が
PGが頭搾って考えるところでさ、
「こうして欲しい」ってものが明確にある部分は
仕様書に詳細に書いてあった方がPGとしては効率がいいと思うんだよね。
それがSEにとって2度手間になっている場合、
SEとPG、どっちが手間をかけるか、という話だと思う。

プログラムは構造化したがるくせに、設計書は構造化すると開発効率が落ちるのか？

>>108
構造化されたプログラムなら、呼び出し元に関数名を書かなければ呼び出せない。
>>1では関数名を書いてるのは例２．
例１はいわばアスペクト志向だな。

ｵﾚは設計書を書くときは
「誰が見ても誤解しない仕様をかく」ようにしてるが・・・・
いきなり「これ中国に出すから」とかいわれると・・・・ヴぁー

アジャイル開発ならそんな設計書自体いらないみたいよ。

>>111
そのかわり、触って試せる動く仕様書が必要だけどね。

オレ文章書くのが苦手だから、そっちの方がいいな。

>>111
あれは一人でやるにはいいが、ある程度の人数になると負のスパイラルに陥るぞ。
デスマが好きならお勧め。