仕様書‥皆さんの意見をぜひ聞かせて下さい！

質問

私はプログラマーを始めて３ヶ月目で、毎日仕様書や本や先輩を頼りにVBのプログラミングをしています。先日、仕様書作成者にWORKTABLEの参照項目が間違っているのではないかと尋ねた所「あっこれ間違いや。こんなん常識で間違いに気づかなあかん。仕様書に間違いがあるのはあたりまえや。常識常識」と言われました。それを聞き、私はこの人はプロ意識に欠けている、恥ずかしくないのかと思いました。次の日、次に作成する分の仕様書を見ると作成内容にまったくあっていない（参照項目説明など）ものでした。仕方がないので先輩や仲間と考えて、修正しあいました。この世界では、こんなことはあたりまえのことなのでしょうか？

回答No.4

yakumon · ベストアンサー

設計をする者として耳の痛い話ですね。

確かによるある事だと思いますが、物には言い方というものが・・・とも感じますね。
プログラムと同じように設計にもバグがあるんですよ。
とある人のプログラムだけやたらバグが出るという経験はしたことがありませんか？
それと同じようにその設計者だけやたらとバグがあるんです。

優秀な設計者の下で楽してプログラミングするよりも、アホな設計者の下で苦労してプログラミングした方が将来実力が身につきますよ。
どういう設計をするべきなのか痛いほど理解できますからね。

これも自分の能力を伸ばす反面教師と思って精進するのが肝要だと思います。

お礼

ありがとうございます。努力します。

回答No.13

nao_2

あたりまえではありませんが少なくもありません。

＞仕方がないので先輩や仲間と考えて、修正しあいました
ここがちと気になったんで・・・

その先輩や仲間の中には当該設計者は含まれているのでしょうか？
ほかにどう見てもその考えが正解だったとしてもいつも正解とは限らずクセにしてしまっては危険です。
時限暫定措置他項目流用などＰＧ側には思いもよらない意図を含んだデザイン（？）である可能性もあります。
（ケッコウあったりするんですよ経緯知らず後任者泣かせアクロバティックロジックってホント私もズイブン泣かし泣かされしてんかなとチト反省でも瑕疵担保期間超過部分でしたらタダではあんましやりたくないですにゃ）(^^;

開発途上でのお話しでしたらＱＡ票などによる確認作業を盛り込んでみてはいかがでしょうか？（既対応？）

「トラ退治」（注１）の最中で、んな悠長なことやってらんない場面もあったりもしますが、事後でもいいのでできるだけモノに残すことが大事です。
（メールなど履歴が残るほうがベターかも）
どんなにハッキリ聞こえてもしゃべっただけのことは大概忘れたりスグ気が変わったりするもんだと思って自衛しましょう。（録音際は同意必須としてください）

・・・ということで私からできるアドバイスは「揺れない心・・・じゃねーですけど、揺れにめげずに食い下がってみてください」です。
最終利用者利益に意識の基本をおきつつ間に挟まっている方々にもそれなり（？）に敬意を払いつつってのがコツですかね。
ワークシェアなどで間が増えるとさらにタイヘンですが世相も鑑みがんばってください。

（注１）：某六甲系チームや泥酔モノやうしおのパートナーではありません念のため・・・

回答No.12

yakumon

だいぶご機嫌ナナメのようですね。
仕事である以上努力するのは当然ですが、あまり人に多くを求めるのはいかがなものかと思います。

文句を言ったことろでその人がきっちり仕事をするようになるとも思えませんし、上司に働きかけて説教してもらったとしても効果は初めのうちだけでしょう。そのうちあなたの方がうるさい奴と判断されるだけです。

人に何かを求めて怒るよりも、自分を磨くための糧として前向きに仕事することをお勧めします。

設計者はプログラマよりも多くの不確定要素と日夜戦っています。
理不尽な事、不愉快な事、無意味な事、いっぱいです。
もう少し暖かい目で見ていただけると同業者として嬉しいですね。

回答No.11

ARC

大規模なプロジェクトの場合は、仕様の段階で協議に協議を重ね、しっかりとした物を作りますが、資金的な関係で、依頼を受けた尻からいきなり対応にかかる場合もあります。

他の皆さんも仰っているように、仕様書なんてものはプロジェクト次第で、あったり無かったり、しっかりしてたり、イイカゲンであったりするものです。
結局人間はミスをする生き物ですし、実際に作ってみて初めて分かるような問題だってありますし。
私は、仕様書の不備を指摘するのもPGの仕事の一つだと思いますよ。

ユーザに提出する仕様書は結構重要ですから、「良い製品を作る」っていう観点からすれば、プロジェクトチーム全体が協力して事に当たるのが理想なんじゃないかなぁ、って思う今日この頃です。

…っていうか、仕様書書くのもう飽きた。俺にPGをやらせろ～

回答No.10

taisuke555

私は以前、他の人が作ったシステムの改良を頼まれました。
その時に、仕様書がなかったので、プログラムの解析から始まり、大変な目にあいました。

ないよりは、あった方がいいでしょうが、全然違う仕様書があっても混乱するだけのように思います。
その辺を踏まえると、その人の常識は、非常識のようにしか思えません。

何の為に仕様書を書いているのか、もう少し考えて欲しいものです。

お礼

ありがとうございます。
私の気持ちをわかってくださる方がいてうれしいです。

回答No.9

gooco_chan

こんにちは。
悲しいですが、それが現実です。
あまりにも仕様もれが多いときは、そのまま仕様書どおりに作って、
結合テスト時に、不具合がでるようなデータを仕込んでおきました。

案の上、ユーザーテスト時には、設計者は恥をかき、ユーザーが直接、プログラマーに指示を出す始末。（テスト時に、設計者からここの処理どうなっているの？ってしょっちゅう電話がかかってきてました）

私見ですが、私は、プログラマーはもらった詳細設計の世界で完結したものを仕上げればいいと思っています。他のＰＧＭとのインターフェースは設計者の責任。
スキルのあるプログラマーは入力チェックを実装するのはあたりまえといった意見もありますが、この手の処理は全体で統一されていないと、意味がないので、
開発初期段階で、設計者が提示するものだと思っております。

回答No.8

TAGOSAKU7

設計者の日々の流れ

１．やる事いっぱーい
２．がんばる
３．少し時間ができる
４．プロジェクトを持たされる
５．やる事いっぱーい
６．がんばる
７．少し時間ができる
８．プロジェクトを持たされる
・・・
・・・
・・・
∞．持ち抱えプロジェクトいっぱーい

∴時間なーい。気持ちに余裕がなーい。嫌な奴になってしまうー。

ちなみに私は
※３・７・１１・・・番目の「少し時間ができる」の時
タバコのポイ捨てをしない、ちょっとだけいい人になります

※４・８・１２・・・番目の「プロジェクトを持たされる」の時
「最初はグー」と言いながらパーを出し、コーヒーを年下におごって貰う、せこくいやらしい人になります。（今日の出来事）

補足

時間がないのはみんな一緒です。
タバコのポイ捨てをしないのは、喫煙者のマナーで、あたりまえのことです。

回答No.7

taka_pre

その時の状況にもよると思うのですが、
正論で考えればすでにみなさんが回答されているとおり、
プロ意識に欠けるものと言えるかもしれません。

私の身近な例で言うと、
仕様書の作成者とプログラマーが同じ会社の社員である場合、
プログラマーを育成するためにわざと間違えを指摘させるように、
誤りを盛り込むこともあります。

得てしてプログラマーは仕様書に対していかに忠実なロジックを
くみ上げるかが重要ですから、
何も考えず、間違った仕様どおりにくみ上げてしまう人もいるわけです。

これではプログラマーから先の仕事をする上で困ってしまいますから、
仕様の正否を判別できる力ぐらい無いと困ってしまいます。

まぁ、naokodazoさんの質問内容を見ると、
単純にプロ意識に欠けた仕様書作成者としか見えませんが、
そんなケースもあると言うことで回答しておきます。

補足

私も人間ですし、事実失敗もします。けれど、失敗してあたりまえという気持ちを持つのは間違っていると思います。失敗したから責めているのではありません。失敗した時に「しまった」と感じて「次回から１つでもミスを少なくしようと努力するんだ。」という気持ちを持つべきだと思うのです。意識の問題です。

回答No.6

mfuku

「仕様書に間違いがあるのはあたりまえや」という件に関しては、当たり前なわけがありません。
プログラムもバグなどで異常終了するなどが当たり前なわけがないように、仕様書も間違いが当たり前なわけがありません。
そのようなことを堂々とおっしゃられるのでしたら「プロ意識に欠けている」と感じても当然のことだと思います。

ただし、プログラムにもバグが全くないと言うことが、どんなに優秀な技術者でもあり得ないということと同じように、設計者も多少の間違いも仕方ないとは思います。
バグを単体テストや結合テストフェーズで修正していくことと同じように、設計フェーズでの細かいミスも、その後の開発、テストフェーズで修正していくことになるのが普通ですので。
それを「仕様書に間違いがあるのはあたりまえや」と開き直られたら、最悪ですが・・・。

また、間違いは言語道断ですが、仕様書に細かく明記しないが、常識で考えて、仕様書に明記してなくても、プログラムに実装するのが当たり前、ということも多分にあります。
おそらく、その設計者は、口は悪いが、そのようなことをおっしゃりたかったのではないでしょうか？

例えば、DBのあるフィールドが30バイトであるとして、30バイトを超えて入力した時、警告を出す、というような仕様は、わざわざ明記しない場合が多分にあります。
こういったことは、スキルのあるプログラマなら、当然のように実装します。

しかし、まだ新人プログラマだとしたら、そういった常識もまだ判断できるレベルに達しないのが普通ですので、私の場合は、新人用の仕様書と１人前用の設計者は仕様書の記述レベルを全く変えてます。

しかし、なんにしても、新人用であろうと、１人前用であろうと「間違い」は言語道断ですね。

回答No.5

7_11shop

間違って当然と思っているなら、仕様書作成者のほうが、
むしろプロ意識は欠けています。

仕様書に間違いがるのは、よくあることですが、
100％に近づけるように努めてあたりまえです。

また、プログラム経験が浅いならば、違うと思っても独断で決めず、
作成者に確認をとったほうがいいです。
あなたのとった行動は間違いではありません。

・・・常識、常識って言葉もあなたに常識がないという意味で
本当に言ったのでしょうか？
常識を間違ってしまった、照れ隠しのようにも思えますよ。

回答No.3

Te-Sho

仕様書が有るだけまともかも....
この業界に十何年いますが現場により全然違いますね。キッチリした仕様書、更新履歴もちゃんと残っていていつも最新が何処にあるか分かっていると言う現場ももちろんありますが(今の現場はそうです)、まったく仕様書無しなんて言うもの凄いところもあります。そう言った現場が多いかも....
自分だけはちゃんとやったことを残して置けば良い訳で仕様書の間違いは確認しておけば良いですね。
でもちゃんとお客さんに出した仕様書だったら本当は間違っていてもその通りに作らなくちゃ行けないし修正するならお客さんの承認が必要です。きっとそう言うような開発ではないのですね。

私がいた最悪の現場は、私が詳細設計+コーディング、その前に2ヶ月間、機能仕様書と概要設計書をノータリン上司が書いていた。仕様書と設計書を受け取り詳細設計を始めたら、どうもデータの辻褄が合わない。設計書の矛盾を指摘してもデータが運用上発生しないから大丈夫だという。そのままプログラムまで作成・テストしてテストパターン表を作成。提出したら、矛盾したところを指摘されサービスインまでに修正しろだと。一人で基本設計から初めて1週間で終わらせましたよ。その上司がやった2ヶ月って何だったんだろう？って思いますね。ほかにも、いつまで経っても改訂版が舞い込んでくる設計書とか(テスト報告をすると仕様書の改訂が来る。1ヶ月続いたんで発狂したら改訂はサービスイン後と言う話にやっとなった。これも当たり前なんですが....)。
でもそんなところ多いですよ。現場ってそんなもんです。