アカウント名:
パスワード:
って書き出しのふざけた仕様書であれば見た覚えが。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
見てみたいもの (スコア:3, すばらしい洞察)
Re:見てみたいもの (スコア:1, おもしろおかしい)
Re:見てみたいもの (スコア:1, 興味深い)
縦横に項目を並べた小奇麗な分岐条件表が仕様書に書いてあったんだけれど、よく見たら SE 氏にとって都合のいい条件が列挙してあるだけで、エラー条件がすっぽりと抜け落ちていたときには、いったいどーしてくれよーかと途方に暮れた。
Re:見てみたいもの (スコア:1, おもしろおかしい)
問題はあるようではどうしようもありませんな。
Re:見てみたいもの (スコア:1)
人類以外の知的生命体向けのプログラムの仕様書。
どういう内容かは私の頭では想像もつきませんが。
Re:M$の仕様書というものを見てみたい (スコア:2, 興味深い)
むしろNDA結ぶ時の権利関係の細かさにうんざりしましたケド。
#外資系のドキュメントは全部英語なので、別の意味で読みにくいっちゃー読みにくいのですが。
概して外資系は仕様書とかドキュメントはしっかりしてる(細かすぎる?)印象があります。
国産の会社の方がヒドいです。まともなドキュメントないトコ多いですね。
#最近まじめにTOEIC対策とか考えてるのでID
途中から小説に変わる (スコア:3, すばらしい洞察)
途中からどころか (スコア:2, 興味深い)
どうみても脚本にしか見えないやつを「仕様書」といって渡されたことあり。
因みに、企画書は前置きと粗筋だけ。
よくこんな企画通ったと思うと不思議というか不気味というか。
--
Ath'r'onならfloatあたりに自信が持てます
Re:途中から小説に変わる (スコア:2, おもしろおかしい)
- 第二部 基本構成 は今秋の発行を目指し、鋭意執筆中です。
ご意見・ご感想は foo@example.jp までお寄せ下さい。 -
# 絶対にイヤだ
いや、別に好きでやってるからいいけどさ・・・。
Re:途中から小説に変わる (スコア:3, おもしろおかしい)
>作者急病の為・・・
編集の上、記入式ゲームブックとして出版される事になりました。
今度の冒険はアナタが主役!いざ、ソースコードの大海へ!
息もつけない面白さ!きっとアナタは、虜になるでしょう!
株式会社ローダン 代表取締役ペリー・ローダン
読者様からの声
面白い!なんて面白いんだ!夏休みの予定を全てキャンセルして
夢中で読みふけってしまいました!寝食を忘れ、童心に帰った!
28歳・システムエンジニア
ページをめくる度に、そこに自分の言葉を記すたびに目頭が熱くなった。
人間ってのは、なんてちっぽけな存在なんだろうと、
宇宙に投げ出されたアストロノーツの気分を味わえました。
26歳・プログラマー
美しいものに触れると、例外なく人々は寡黙になり涙を流すという。
私は読んでないが、部下は皆、そういう状態だったのが印象に残っている。
皆、感動に咽び泣き、嗚咽の声が絶える事は無かった。多分、良著。
31歳・プロジェクトリーダー
Re:途中から小説に変わる (スコア:1, おもしろおかしい)
#・・・しかも、エロ小説だったという罠orz
#上司が問いつめたところ、コードはできた(と本人は思った)ので、ずっとサボっていたようです。
#え、できたコード? 問題外だったのでデスマ中にもかかわらず先輩が一から作り直しました。
やっぱり (スコア:1)
「以下次号へつづく」となるのでしょうか?
Re:やっぱり (スコア:1)
……orz
小説 (スコア:3, おもしろおかしい)
#以前ACで同じような事を書いた気がするのでID
らじゃったのだ
Re:小説 (スコア:5, おもしろおかしい)
名前は未だ無い。
どういう事をしたいのかとんと検討が付かない。
気が付いたら暑苦しい会議室で喧々囂々の遣り取りの的になっていたと言う。
って書き出しのふざけた仕様書であれば見た覚えが。
Re:小説 (スコア:2, おもしろおかしい)
しかもあとで聞くとそれはSEという人間中で一番獰悪な種族であったそうだ。
このSEというのは時々我々を閉じ込めて強制労働させて過労死させるという話である。
しかしその当時は何という考もなかったから別段恐しいとも思わなかった。
(中略)
ふと気が付いて見るとSEはいない。たくさんおった兄弟が一疋も見えぬ。
肝心の仕様書さえ姿を隠してしまった。
1を聞いて0を知れ!
仕様書で指定されていない部分を訪ねたら (スコア:2, 興味深い)
#ナニしろとおっしゃるんで?‥と聞きたかったが自粛。
丸ゴシック (スコア:2, おもしろおかしい)
理由は、好きだから。
結局、契約は結ばれなかったのだが、
それは、丸ゴシックのせいだろうか。
Re:丸ゴシック (スコア:2, おもしろおかしい)
という理由だけでみかちゃんフォントを使って
社内文書を回したことがある。
#丸文字系とか手書き系は案外社内でウケが良い。
Re:丸ゴシック (スコア:1)
発注用の仕様書 (スコア:2, 興味深い)
要件定義と、その後の文章化って、やはり経験を積まないと、なかなかうまくできないですよね。でも、なんにも知識もなく経験を積むより、体系的な知識を身につけてから経験を積めたらと思いました。
私としてはUMLのドメインモデリングとユースケースを重点的に身につければ、発注者側の素養としては十分ではと思ってます。
・・昔、DOAをセールスから進められて勉強してみましたが、ユーザー側ではなく開発側に必要な素養ですね。
手戻りの無い仕様書 (スコア:2, 参考になる)
「手戻りの無い仕様書」と聞いて、
以前読んだ
「リーンソフトウェア開発」(日経BP社)
を思い出して、読み返しました。
「ソフトウェア開発の性質」という部分で、
「開発 と 製造」 の違い
は
「料理のレシピの作成 と 料理の作成」の違い
であり、
前者は反復が価値を生み出し、
後者は反復が無駄を生み出す。
などとあります。
昔、結果として手戻りがほとんど無かった仕様書を書くことができて、
自分自身は達成感に酔っていたのですが、
発注側の担当者の方が今ひとつ嬉しそうでなかった理由は、
反復が足りなかったので、価値も足りなかった
のだろうなと思います。
業界が異なるかもしれませんが、ご参考になれば幸いです。
Re:手戻りの無い仕様書 (スコア:1)
ほとんど同じ文章が何ヶ所にも繰り返し書かれているが、所々違う。
読む方は、どこが同じでどこが違うのかを見比べながら、
それぞれの機能の特徴を見極めるための作業が必要になっている。
間違い探しやないっちゅうねん。
オブジェクト指向の「継承」を勉強して書き直してくれ。
200ページの要求仕様が半分以下になるんじゃないの?
あっでも、もし仕様書のページ数に比例して受注額が決まっていたら...
Re:発注用の仕様書 (スコア:1, 興味深い)
どちらかにだけ必要な知識というものは多くないと思います。
依頼元が不勉強であればそれなりの対応をしますし、
発注先が頼りないときには相応しい対処をします。
もちろんこちらが勉強させていただくこともよくあります。
小説ワロタ (スコア:1)
#厚さとか。
私が今戦っているもの (スコア:1)
Re:私が今戦っているもの (スコア:1)
AVG anti-virus data base out of date
全部嫌だけど (スコア:1)
自分で全部読める形式にしないといけないなんてまっぴらごめん。
ピヨ印@将軍@クラダンX2
Re:全部嫌だけど (スコア:1)
何かしら「仕様」は形として欲しい。
後から「言っていたあの仕様だけど」って言われても
「聞いてないよ!!」 ―っと言うこと多数w
機能発注 (スコア:1)
そういった場合、打合せ議事録を残しましょう。
発注仕様は結構いいかげんで、受注後の打合せで詳細が決まることがあります。
設計図面を提出し発注者から承認を貰っても意味がないことが多く、発注者の
意図どおりに動くまで・・・。
こういうのを、請負(うけまけ)工事と呼びます。
Re:機能発注 (スコア:1)
高飛車な態度でプログラマーに負担を強いる営業マンw
Re:全部嫌だけど (スコア:1)
と、その場で仕様を決める。
実はどんなものにするのか決めてなかった。
#けど、ツッコミいれると「そうだね、その方がいいね」
#と都合の良い仕様にできたから、大きな実害は無し。
・・・ (スコア:1)
Minder
仕様よ仕様。だけどちょっとだけ仕様じゃないの。 (スコア:1, おもしろおかしい)
なにをどうするか相談されたことがありますが、
好き勝手な仕様書をでっちあげることができたので
またの指名をよろしくお願いします。>お客様
Re:仕様よ仕様。だけどちょっとだけ仕様じゃないの。 (スコア:1)
だけど,なにをどうしても納期と予算を超えてしまうの.
逆算すると,2ヶ月以上前から取り掛かっていなければいけないの.
現場もヒイヒイ,偉い人たちはブツブツ言ってるの.
退職者が多く, (スコア:1)
今はその墓を暴いている最中です.
でも,ミイラ取りがミイラになりそうな悪寒.
正直なところ (スコア:1)
Re:正直なところ (スコア:1, 参考になる)
ただソフトウェアのライフサイクルでは、運用期間のほうが開発期間より長くなり、
その間にかなりの頻度で改修、拡張が行われるでしょう。
そのときに文書がないと苦労することになるんじゃないでしょうか。
自分の書いたコードだって一ヶ月もすれば忘れてしまうでしょうし。
と思っているのでなるべく書くようにしてます。
未来の自分のために、ってか。
一発ものだったら作り捨てもありかな。
#「拡張とかないからちゃちゃっと作って」って言われても、大抵修正依頼が来るもんだ
#それも数年後とかにorz
Re:正直なところ (スコア:1)
は、「だから仕様書なんて書かなくていい」という話ではなく、「どうして仕様書はいい加減になるか」という心理分析です:-)
#うちは受託開発系のソフト会社なんで、仕様を作る方も見る方もプログラミングできる人、というのが今回の話の前提。
実際に物を作ってしまうより、指示書を作る方が手間がかかるなんて理不尽だ、と無意識のうちに感じてしまうんでしょう。
あと、「コロコロ変わる物をいちいち文面に起こすのは時間の無駄」という心理もたぶんある。
Re:正直なところ (スコア:1, 参考になる)
>実際に物を作ってしまうより、指示書を作る方が手間がかかるなんて理不尽だ、と無意識のうちに感じてしまうんでしょう。
>あと、「コロコロ変わる物をいちいち文面に起こすのは時間の無駄」という心理もたぶんある。
多分にあるでしょうね。昔は私もそうでした。
そして今もその気持ちを仕事ではぐっとこらえています。
#コードが仕様書だ :-)
#そして2年前の自分で書いた仕様書(コードね)が読めない私 orz
今は、文書を書くことによって発生するデメリット(時間的なコスト)よりも、
- 文書を書くことで自分の考えている内容が整理される
- 人に(斜め読みでもいいから)レビューしてもらうことで、新たな視点が見つかる
- いざというとき丸投げできる:-)
というメリットが得られることを重視し、また「方法、手段」はコードを見ればよいので、ドキュメントには「方針、意図」を残すように心がけています。
あとはドキュメントを書く練習の機会、とも捉えていることくらいですかね。
やっぱり第三者に伝わるようにドキュメントを書くのは経験が必要でしょうし、書けば書くほどこなれてくるものですよね。
高い意識を常に持って書くことで、できあがった成果物、そしてそれを書いた経験は、自分にとって価値あるものになると思っています。
んー。 (スコア:1)
ラジオボタンじゃなくチェックボックスにして欲しいかも。
とりあえず、基本は踏襲。 (スコア:1)
# 仕様書がプログラムになる時代を夢見てもう何年。。。
# でも、その時代が来れば僕はクビか。。。
マクロの基本は検索置換(by y.mikome)
Re:とりあえず、基本は踏襲。 (スコア:2, おもしろおかしい)
Re:その他 (スコア:1)
・カエサル暗号が施されている
・語尾が萌えだ
・時々キャラクターが説明してくれる
・Flashが埋め込んであって豪華だ
・イースターエッグがついている
・社外に流出している
・デザインが大河原邦夫だ
・声優が読み上げてくれる
・おみくじがついている
・ちょっと拗ねた感じ
・「あたり」が出るともう一本
Re:その他 (スコア:1)
鉄拳です。 (スコア:2, おもしろおかしい)
・タイトルが仕様書じゃない。どう見ても「スクラップ三太夫」って書いてある。
・なんかいつも下から人がのぞいてる。
・すごい大きい。ほらちょっと解りにくいけど横の人がこんなに小さく見えてるの。
・ここんとこが迷路になってる。
・ここが、こんな、こんな風になってる。
・あ、これは関係ありません。
・表紙に赤いマジックで「コインランドリー」ってでっかくかいてある。
以上、鉄拳でしたー。
Re:その他 (スコア:1)
実話 (スコア:1, おもしろおかしい)
Re:実話 (スコア:3, おもしろおかしい)
みんな働いてる職場で何度も再生しながらコードを書きました。
わからないところをいっしょに聞きながら質問しました。
次から紙でくれるようになりましたが、上司も私もそのまた上司に怒られました○| ̄|_
#これも実話
なんかもう、いろいろバテバテなんですけど。
Re:実はあった (スコア:1)
顔文字をはじく試験を実施中。
#あえてidで