プログラマ経験がないのに仕様書を作成

メーカに入社したばかりで、プログラミング経験1ヶ月（研修）。
研修を終えて配属されましたが、ＰＧは下請けに投げるため
プログラミングはやりません。
それでいきなり仕様書を作ることになりました。
ＰＧ経験なくても仕様書って作れるものでしょうか？

たわけ

どっかで聞いた事ある話

あるあるｗｗ

>>1
漏れなんか2週間研修受けただけで設計書書かされたわ。
2年前にマジで。

>>1
ボロクソ言われながら成長を遂げるという姿を期待してるんではなかろか。
コーヒー飲みながら作業してたら胃に穴が空くな。

氏ね氏ね

使えなさそうな新人を辞めさせたい時によくやる手だな

下請けPGがｶﾜｲｿｽ

>>8
可哀想だから言っちゃダメ！

仕様書なんてただの紙切れ。
優秀なPGには、○○したいプログラム作りたいと
伝えればいいよ。

重要なのはフィーリング。

作る仕様書にもよるわな。
実装直前の仕様書じゃなければ、ある程度論理的に物事が考えられればまあ･･･。

Don't think, feeeeeeeeeeeel!

>>11
そんなのが一番困る
しね

http://www.geocities.jp/air192168/game/g2/index.html
グラディウス２　ノーミスクリアへの道

http://www.braingames.getput.com/
BRAIN GAMES

http://kmc2ppm.sakura.ne.jp/joyful/img/1751.jpg

カニタマイズ

>>16
ﾜﾛﾀ

楽器がひけなくてもプロデューサーにはなれる

>>18
しかし、プロデュースする相手が
「弦を弾いて音を出した事がある」ギタリストと
「鍵盤を押したら音が出た」ピアニストと
(以下同文)

世の中にはな。
弾いたこともない楽器の演奏会を開こうと大風呂敷開いて。
集めた楽団員が>>19仕様の新人ばっかりで。
やっぱり開けないって別の大手楽団の録音ながしてごまかして。

指揮者に責任押しつけるプロデューサーってのもいるんだよ；；；；

風呂敷ってどうやってしまうんだろうな。

・・・・風呂敷か！
泥棒だったのかｙｐ！

しかし仕様書って言葉は知ってても内容さっぱりなんだろね
新人じゃ関数とかサブルーチンの仕様書以外本来書いちゃいけないんじゃないの？
経験数年でそれ以上のことやらされてる奴はご愁傷様。
そこでスキル止まるよ。

参考画像
http://nigauri.sakura.ne.jp/src/up3329.gif

リンクは無視するのが板のルールっぽいのでage

安永

俺もあった…。任されたけど、作り方がわからず画面だけいじってたよ･･･。
無意味に資格とってたから、基本、外部設計すべきか悩んでたんだけど。
どーでも良かったみたい・・・みんな勝手に作ってるから…。
雑誌に載ってるような、ある程度管理された仕事してみたい…。


最近脱ＩＴ気味のぷろぐらまーより

インストールテクノロジー

>>20
だから何？キミちょっと変
こんなところに楽器の例はいいだろ？

ＰＧ経験はなくとも書けると思うけど、あった方がいいという位の差でしかない。
漏れがないように書くにはそれなりに経験値がものを云う。
規模にもよるけど、簡単な単体アプリ程度の仕様書なら十分書けるっしょ。
11にはふざけんなといいたい。

最近は仕様書書かないでしょ。
しかし、外部キーも知らないでＤＢ設計できる？

某企業のソリューション部の作成したＤＢ仕様書では、
テーブルの主キーが全て、「プリマリーキー」と表記されてた。
非常にイヤな悪寒がした。
案の定、プロジェクトはデスマへの道を歩んだ。
（マジ話）

DB知らずに設計しているのは、恐ろしいよね。

俺が見たデスマでは、
テーブルにキーとか制約とか、まるで何も設定されてなかった

テーブルを検索して重複するものがないことを確認
↓
重複がなければレコードを挿入、重複があれば既存レコードを更新
↓
もう一度確認。重複していたら、削除してやり直し。

なんていう、ふざけたプログラムを見て、もうねアホかと。

すべてのフィールドがvarchar2のDBなら見たことあるな。。

コボラ臭のする話だなｗ

更新系、参照系が「？」な奴とかな。
数百万行のテーブルに更新削除しまくっていろんな条件で参照もしまくる。
参照が遅くて使いモノにならず、思い出したかのようにインデックスつけまくり。
少しはマシになったかと思ったら、削除に物凄い時間がかかるようになって
理由がわからず頭を抱え込む。

こんなアホいませんか？

コボラ臭っていうと
RDBなのにリレーションをほとんど使わない
ってところで感じる

俺、テーブル項目が10数個あって、そのうちの8割が主キーに設定されてるテーブル見たよ。

こんなん普通なの？

>>37
たまにある
まあ必要だからそうなってるのかどうかは実際の設計見てないから分からんが

>>37
個数ばっか気にしてないで、設計全体を見て、おかしいところを探せ！！

>>37
問題点は個数ではなく、そうあるべくしてそうなっているか否か、だ。

参考。仕様書相互リンク

良いドキュメント・マニュアル・仕様書を書くスレ
http://pc8.2ch.net/test/read.cgi/tech/1065364445/

小規模開発では仕様書は作るだけ無駄
http://pc8.2ch.net/test/read.cgi/prog/1125913671/

AJAX時代の仕様書とは
http://pc8.2ch.net/test/read.cgi/tech/1140766471/

営業が作った仕様書に
http://pc8.2ch.net/test/read.cgi/prog/1121256149/

良い仕様書、悪い仕様書、普通の仕様書
http://pc8.2ch.net/test/read.cgi/prog/1143906019/

プログラマ経験がないのに仕様書を作成
http://pc8.2ch.net/test/read.cgi/prog/1119776686/

仕様書の量でしか成果を決められない客
http://pc8.2ch.net/test/read.cgi/prog/1143878620/

Excelで仕様書を作る会社の奴の数→
http://pc8.2ch.net/test/read.cgi/prog/1137662854/

　

外部設計ぐらい気合でなんとかなる。

「金もらってるからにはプロなんやからな」
残業代払ってない会社ほど偉そうな事を言う。

ぷろぐらま経験が無い方がまともな仕様書書けるかも・・・

まあ下手な固定概念がないぶん、しっかり取り組めるかもね

プログラム経験のないデザイナーが作った仕様書をみた事がある。
すごく見栄えがよくて、操作性も良さそうに見えるのだが、作るのが困難な仕様が満載だった。
多分、VBのアプリとブラウザの違いを知らなかったのだと思う。
ブラウザなのにツリー表示やリアルタイム進捗状況表示とかが満載だった。
結局、仕様書を手直しして、問題にならない程度に修正したのでどうにかなったが。

最後には「技術者」に手直ししてもらった方がいいぞ。と、マジレス。

>>49
その手の橋渡しをするのがSEって職業のハズ…
ハズなんだ・・・っ

>>49が見たのは多分企画案

>51
いや企画書じゃない。機能仕様書だ。
企画書で全画面の画面仕様書や処理説明を書かないだろう。
内容的には頑張って作ったのが良く分かったので、作った本人に聞いてみた。
そしたらデザイナーとテスターの経験はあるが、プログラム言語を知らないって言っていた。
それなのに上司（営業）に設計書を作れと言われたらしい。
その人は悲惨で、lsすら知らないのにUNIXサーバの環境設定をやらされて、出来なくてクビになったらしい。
上司はWindowsのアプリインストールも、SolarisのAPサーバ設定も同じだと思っていたらしい。

ネタにマジレスされた…

http://www.youtube.com/watch?v=EzUGnKbd6rc
これでも見て気を静めてくれ

>>52

そういう人は結構多い。
死ねよ。

ＰＣアプリ系の仕事、２年くらいやってみたいな・・・

いま組み込みなんだけど
どういう仕事の仕方してるか、興味あるよ。

基本設計仕様書書かされている素人だが。。。
ｻﾊﾟｰﾘわからん、知らない用語の質問したら、先輩にため息つかれて
黙って去られたよ、俺もやる気なくなった orz

その用語は何？

「ユーザ」

『遷移』って何て読むんすか？
『押下』って何て読むんすか？

＃ってｼｬｰﾌﾟっすよね？　あ？　ｲｹﾞﾀ？
ありえねーっすよwwwｻｰｾﾝwwwwwww

>>60
どっちも辞書に載ってない造語だなこりゃ

遷移
押下

IMEででるお

>>63
文字変換データベースには載ってるのか。
ネット上の辞書サービスでは出て来ないぜ

せんい
おしげ

ミリア使いかね

1は無防備マン

せんい、おうか。
ATOK賢い。

おうかだよね！ほっとした〜。
自信ないままずっとそう読んでた。

押下はともかく遷移が読めんとかどういう人生歩んできたんだ？
最近はそんなものなのか？

マジレスすると、辞めて欲しい時に使う手。

>59
マジレスすると、寛容な俺様でもため息つくよ。
でもそのため息は、59に対してではなく、仕事を割り振った59の上司に対してのため息だから気にするな。

つか、NTTデータなど下から上までそんな人ばっかりだぞ。>>1

>>1の会社はDQN会社だ。すぐに転職の準備に取り掛かれ。

>>70
つまり、>>60、>>62は、「状態遷移」という概念を知らないって事だな…

>>75
残念ながらこの業界そういう奴はいっぱいいる
仕方が無いから状態遷移を意識しないで良い範囲だけ作らせる

>>73
マジレスするとNTTデータは下請けに投げて中間マージンを搾取してるだけの会社

NTTデータって中身はコンピュータの会社じゃないじゃん
双日とか伊藤忠とかと同じ業種でしょ

>>75
マジレスすると俺も新卒で入ったときは知らなかったｗ
でも漢字見てりゃなんとなく分かるよな。

遷移は『移』るんだろーな、とか押下は『押』して『下』げるんだろーなとか

>>79
漏れの場合、256倍本のSEDの解説でオートマトンの話が出てきたのが
状態遷移を明確に意識した最初の体験かな。

正直、押下は読めなかった。

オウカ？　自信なし

押下って正式な日本語なの？　国語辞典にはのってないよなぁ・・・

IBM用語みたいなもんじゃないの？
キーボード = 鍵盤装置、みたいな…

押下をオシサゲとか読もうがそれは意味が分かってりゃ構わんが
遷移は読めてほしいなあ

ttp://pc8.2ch.net/test/read.cgi/prog/1149665164/

専用スレがあったんだな

私はプログラム組めなくて
入社２年目でテスターになった。

今、入社５年目だけど俺のノートパソコンには
オフィスしか入っていない。

仕様書はエクセルで作ってるけど
データベース設計とかプログラマにおまかせ。
大人のひとときで設計依頼してます。

インストラクター上がりの自称SEが作成した内部設計書をみた
画面のハードコピーをバーンとはりつけた横に2、3行落書きがあり
1のボタンで検索される…とか書いてあった

担当SEとPGの勤怠が悪いから首切ってみたら
納品すんのに仕様書ないから後書きしたんだと思うが
操作マニュアルしか作った事ないのに無理しないでほしい
あれを納品するのは会社の恥だと思う

時間がないから
仕様書もないに設計しながらコーディングとか

大手の人間ならプログラマ経験なしで仕様書書きなんてざらじゃね

99.9%デスマになるのわかっているが

goo 辞書に遷移も押下も載ってるな
状態遷移は載ってなかった

>>1

どうかその仕様書がうちの会社に回ってきませんように（ー人ー）

>>91
それ死亡フラグだから

IBMによるとクエリーではなくキューリーが正しい読み方らしい
だからASのやつらはキューリーと言う
右側のALTは実行キーというが左側は違う
テーブルはファイル、英数字は全角が美しい

成果物を示せばOK
ひたすら画面（ハリボテ）を作って、これを動くようにしてくださいというスタイルが開発も早いらしい。

http://itpro.nikkeibp.co.jp/article/COLUMN/20070214/261859/
「HTML画面をそのまま仕様書に」，5カ月で1000画面を構築した就職サイトPuffの高速開発手法

>>94
正直な話、ワードで仕様書を何十枚何百枚と作文して
自己満足自信満々で提出してくる企画屋やSEがいるが
そういう仕様書はほとんど役に立たないですね。


そんなものより、例えばWEBシステムなら、
実際にある程度のデザインも入ったHTMLにまで落として
ブラウザで表示できる状態にして持ってきてもらうと
裏側のプログラムを組むのはかなり短時間でできますね。

裏紙に鉛筆で殴り書き
それを元に作ったら、詳細を詰める
工数も工期もかなり短縮できたが
仕様変更時に多いに困りました。

>>94
ネタスレだと思うが、こういうスレが在る

ttp://pc10.2ch.net/test/read.cgi/prog/1171172461/

>>87

私なのか俺なのかはっきりしろ

項番ってなんですかって新人の頃聞いたオレ
みんなにあほ呼ばわりされた。

感覚でわかれよ

みんな！
１は、『漏れは一年目なのに、もうSE、だすげーだろ！！？』
って言いたいということをわかってやってくれ。

そんなん、ザラにおるがな ｗ

話しずれますが
仕様書って数百ページあるとかざらなんですか？
しかも読みズライPC上だけで読まされるとか。
しかも全部覚えなきゃならんわけで。

これ覚えるとか、、朝から晩までやって1週間かかりそうなんですが。
この間に新しいプログラム言語覚えれますよね。。っていうレベル
面食らってしまいました。

オレが今まで習ってきた
文章は読みやすく短く簡潔に書くっていうレベルをはるかに超えている。
小難しい言葉で無理やり短くまとめてぎゅうぎゅうつめてあるような感じ、、

>>102
信じられないかもしれないが、日本語に不自由している人も
多いのが現状なのよ。この業界。

プログラムの保守というクソ仕事で
「ユーザー向け説明pdf３種しかない」ということがありました　どうしろっちゅーねん

顧客の脳内では業務と要件と構造を理解している奴を無料で永久に監禁している事が前提だからな。
変な業界だよ。

>>102
覚えようとするなよ。受験勉強じゃないんだから。
もし覚えないとどうにも作業できないような環境なら、PCを2台要求するとか環境改善をしたほうがいいぞ。

>>106
半泣き状態でしたよ
環境改善ですか。。
言ってみます。

>>1　は期待されてるんじゃないのか？駄目もとでやってみるべき。
そこで苦労してできたものは後々の自分の宝になるはず。
プログラミングにしろ苦労するとその後、ぱっと開ける事がある。

仕様書なんて所々掻い摘んでニュアンスで把握するんだ

>>103
話はまともにできないのに、読むのはもの凄く速いって人も多いな。

プログラム書いた事なくても仕様書書くだけならいくらでもできる。

プログラム知らなきゃ出来ないのは、その仕様を実現するのにどれだけの
工数と人員が必要なのかを適正に見積もる事と、ロジックの難易度にあった
人員のアサインを適切するってことだ。

丸投げで見積もりまで下請け任せなら仕様書なんてｻﾙでも書けるよ。

>>111
仕様書を書くのも丸投げするのはサル以下ということでFA?

>>111
すると、丸投げで見積もりまで下請け任せな仕様書を書いているサルは、
職域が自動化の対象になる日が近いから、転職を考えていた方がよいと？

プログラマ経験なし研修もなし入社１にちめで
簡単な資料だけわたされて仕様書ない状態でコレをこうしてくれって口頭で説明されたお。

2ヵ月後潰瘍だらけになって2ヵ月半働けなくなったがな（´･ω･｀)　
1>> は今生きてるかな。

1>>ってなんだよって自分で書いて泣きたくなった。

先輩も外にばっかりでてて質問しようにもなかなか直にはできないし。
今年新人はいっても何もおしえられないお。ううう怖い。おなか痛い。

ＰＡＤやＨＣＰで、モジュールスペック書くとき、
どのソフト使う？

トレーサビリティマトリックスをWord、Excel以外でつくる人いますか？

プログラムの仕様書ってどんなの？

ザクっと言うと要件仕様書と機能仕様書と詳細仕様書とテスト仕様書

開発者の脳内仕様書を元にその開発者が全部作り上げるうちの会社の場合、
開発者のマとしてのセンスによって品質にばらつきがあるのが問題だ。

仕様書？そりゃお前、ソースに全部書いてあるだろ？

詳細仕様はソースコード嫁、という人に限ってコメントが少ない罠

コメントを嫁、とは言っていない罠

コメントにはしばしば嘘が書いてあるので過度に信用してはならない

ソースコードが詳細仕様書とか言うヤツは、他人が理解出来ない天才か、
単なる自信過剰か、他人のこと(及び後のこと)を考えないアホ

>>119
どっかにサンプルない？

>>125
知らないなぁ。
開発手法とかで何書くか、どう書くか変わってくるし、
俺は自分の会社の昔の仕様書を参考にしたけど、
機密物だから他人に見せられないし。

なんでも良いんなら、UMLでも調べてみたら？
UMLのを全部使うわけでも無いと思うけど。

>>124
本当にその上の工程の仕様書が整ってれば、それでも良いんだけどね。


人から引き継いでメンテする時とか、中途半端な詳細仕様書があるよりも、
コードから適当にツールでドキュメント起こしたほうが、
裏切られることが無くて精神的に優しい罠。
最悪、コメントナシでDoxgenでもいい。嘘だらけの仕様書よりは。


でも、そういう場合は往々にして上の仕様書もまともなのが無いから困る。
上流の仕様書が揃ってなくて本当に「コードだけが正義」とか言う状態はクソ。

>>125
本屋行って「SEのためのドキュメントの書き方」っぽい本見たら多少はサンプル載ってるかも。
＃この手の本、なぜか「プログラマの〜」じゃなくて「SEのための〜」系の名前がおおいんだよね。


でも自分で一から始めるんならともかく、会社とかで大抵はフォーマットあるんじゃないかな〜。

たとえばオープンソースとかで誰でも見られるきちっとした
仕様書とか存在するの？

>>129
どうなんだろ。
コードからツールで起こしたドキュメントを置いてあるヤツはちらほら見るけど。

そもそも所謂システム開発とか商用ソフトウェア開発とかとは発端とか動機とか踏むべきステップとか色々違うからなぁ。

>>118

１．用途・姿形、インプットに対するアウトプット
２．プログラムに実装する場合の制約条件
３．納入・完成判定をするための評価試験項目

プログラム経験が無いと、余程の天才で無い限りは
正しいものを書くなんて無理だと思うんだが。

プログラミング経験があっても抜け・矛盾がない仕様書を書くのは至難の業である。
そして仕様書を受け取ったプログラマも実際に設計・コーディングしてみるまでしばしば抜けや矛盾に気づかない。

>>132 そのために、ＵＭＬとかがあるんだけどな。

万事全てに目が行き届く人間がいたら、ＵＭＬなんていらん。

>>133
んなもん書いてる暇があるプロジェクトなら問題なんて起こらんｗ

暇無いとか言っちゃったら何も出来ん。

第一リリースまでの開発に費やす時間を削減するか、
リリース後の修正に費やす時間削減するかのトレードオフの話な気がする。

要件次第でどっちもあるので、どっちが良いとかの話では無いと思う。

>>135
＞第一リリースまでの開発に費やす時間を削減するか、
＞リリース後の修正に費やす時間削減するかのトレードオフの話な気がする。

そもそもトレードオフって概念があることを知らないようなプロマネやリーダーが
結構な数いそうだけどなぁ。

コンピュータリソースに限らずリソースってのは有限であると意識が希薄過ぎる
人が上にいると色々と大変になるねぇ。

初心者におすすめの本やサイトを教えてください。

WEBアプリを開発しているのですが、仕事＆チームでの開発は初心者ばかりで
開発に関する知識がないのでプロジェクト管理全般をどうすればいいんだ！？状態です。
動作がどうなるべきかがわからないので、機能の詳細をきかれて答えられなかったり、
テストがきちんとできないなどが比較的問題視されています。
とりあえず、よく耳にする”仕様書”なるものがないのがいけないのではないか？
ということで、次のバージョンから仕様書をつくろうぜ！みたいなことになっているのですが
みんな、どういった内容を書けばいいのかわからない状態なのです。
少しでも改善していきたいと思うのですがはっきり言って仕様書とはどういったものかがわかりません。
開発における何かを定義したものというのはわかるのですが…。

皆さんはどうやって学ばれたのでしょうか？入社したところの先輩方からなのでしょうか？

>>137
何がしたいのか書いてみたら？

それが要求仕様書だと思うけど・・・。

>>137
つか
よくそれで開発が成り立ってることの怖さ・・・

>>よくそれで開発が成り立ってることの怖さ・・・
東証もＡＮＡのそうだよ。

>>137
うちは基本「先輩から教わった」だな。

CMMでも勉強してみたら？
ちょっとレベル高すぎるかもだけど。
一応「どんな文書を作るか」が分かる・・・かもしれない。

みなさん、どうもです。
自分は、スレタイどおりの経験値なので（基本情報の試験に運で受かるかどうかレベル）、
ユーザーマニュアルとドッコイの画面機能説明くらいなら書けそうです。
正直、開発するには何を書いていてほしいのかよくわからんのです。
とりあえず、「SEのための仕様の基本」って本を買ってみました。

かろうじてDBのモデル図はあるみたいなんです。
説明がないので、何が入るのかがあまりわからないんですが…。
そういえば、どういうデータが入るべきというのをまとめるのに向いている書式（図）ってあるんでしょうか？

>>139
自分も恐ろしいです…。

>>141
CMM、初めて知りました。うちは…レベル0か1ってところですかね。はぁ。

>>142
とりあえずマニュアル書いてプログラマに渡せ
そのレベルじゃどうせそれ見たってプログラマは問題点を指摘できそうにもないが、
コード書いていけばどうしたらいいのか分からんって局面が必ず出てくるから
そのときはお前に質問するように言っておけばいい。

その質問にどう答えたらいいのかわからなくなったらみんな集めて相談しろ
そうすればそれなりの方策が見つかるだろう

新しいことを決めたらすぐにマニュアルに反映させろ
でないと何がなにやら分からなくなるからな

一人で１日20プログラムのUTをこなすスケジュールを書いて
「SEたるものスケジュール管理ができて一人前だよな」と
自慢する某SE。

残り日数が少なくなると、そのまま後ろにタスク積み上げて
ありえないスケジュールを生み出すあんたの管理能力は
まさに小学生並みだよ。

仕様書の日本語が変

>>145
仕様書の日本語が文法的には正しい