私はプログラマーを始めて3ヶ月目で、毎日仕様書や本や先輩を頼りにVBのプログラミングをしています。先日、仕様書作成者にWORKTABLEの参照項目が間違っているのではないかと尋ねた所「あっこれ間違いや。こんなん常識で間違いに気づかなあかん。仕様書に間違いがあるのはあたりまえや。常識常識」と言われました。それを聞き、私はこの人はプロ意識に欠けている、恥ずかしくないのかと思いました。次の日、次に作成する分の仕様書を見ると作成内容にまったくあっていない(参照項目説明など)ものでした。仕方がないので先輩や仲間と考えて、修正しあいました。この世界では、こんなことはあたりまえのことなのでしょうか?
No.4ベストアンサー
- 回答日時:
設計をする者として耳の痛い話ですね。
確かによるある事だと思いますが、物には言い方というものが・・・とも感じますね。
プログラムと同じように設計にもバグがあるんですよ。
とある人のプログラムだけやたらバグが出るという経験はしたことがありませんか?
それと同じようにその設計者だけやたらとバグがあるんです。
優秀な設計者の下で楽してプログラミングするよりも、アホな設計者の下で苦労してプログラミングした方が将来実力が身につきますよ。
どういう設計をするべきなのか痛いほど理解できますからね。
これも自分の能力を伸ばす反面教師と思って精進するのが肝要だと思います。
No.13
- 回答日時:
あたりまえではありませんが少なくもありません。
>仕方がないので先輩や仲間と考えて、修正しあいました
ここがちと気になったんで・・・
その先輩や仲間の中には当該設計者は含まれているのでしょうか?
ほかにどう見てもその考えが正解だったとしてもいつも正解とは限らずクセにしてしまっては危険です。
時限暫定措置他項目流用などPG側には思いもよらない意図を含んだデザイン(?)である可能性もあります。
(ケッコウあったりするんですよ経緯知らず後任者泣かせアクロバティックロジックってホント私もズイブン泣かし泣かされしてんかなとチト反省でも瑕疵担保期間超過部分でしたらタダではあんましやりたくないですにゃ)(^^;
開発途上でのお話しでしたらQA票などによる確認作業を盛り込んでみてはいかがでしょうか?(既対応?)
「トラ退治」(注1)の最中で、んな悠長なことやってらんない場面もあったりもしますが、事後でもいいのでできるだけモノに残すことが大事です。
(メールなど履歴が残るほうがベターかも)
どんなにハッキリ聞こえてもしゃべっただけのことは大概忘れたりスグ気が変わったりするもんだと思って自衛しましょう。(録音際は同意必須としてください)
・・・ということで私からできるアドバイスは「揺れない心・・・じゃねーですけど、揺れにめげずに食い下がってみてください」です。
最終利用者利益に意識の基本をおきつつ間に挟まっている方々にもそれなり(?)に敬意を払いつつってのがコツですかね。
ワークシェアなどで間が増えるとさらにタイヘンですが世相も鑑みがんばってください。
(注1):某六甲系チームや泥酔モノやうしおのパートナーではありません念のため・・・
No.12
- 回答日時:
だいぶご機嫌ナナメのようですね。
仕事である以上努力するのは当然ですが、あまり人に多くを求めるのはいかがなものかと思います。
文句を言ったことろでその人がきっちり仕事をするようになるとも思えませんし、上司に働きかけて説教してもらったとしても効果は初めのうちだけでしょう。そのうちあなたの方がうるさい奴と判断されるだけです。
人に何かを求めて怒るよりも、自分を磨くための糧として前向きに仕事することをお勧めします。
設計者はプログラマよりも多くの不確定要素と日夜戦っています。
理不尽な事、不愉快な事、無意味な事、いっぱいです。
もう少し暖かい目で見ていただけると同業者として嬉しいですね。
No.11
- 回答日時:
大規模なプロジェクトの場合は、仕様の段階で協議に協議を重ね、しっかりとした物を作りますが、資金的な関係で、依頼を受けた尻からいきなり対応にかかる場合もあります。
他の皆さんも仰っているように、仕様書なんてものはプロジェクト次第で、あったり無かったり、しっかりしてたり、イイカゲンであったりするものです。
結局人間はミスをする生き物ですし、実際に作ってみて初めて分かるような問題だってありますし。
私は、仕様書の不備を指摘するのもPGの仕事の一つだと思いますよ。
ユーザに提出する仕様書は結構重要ですから、「良い製品を作る」っていう観点からすれば、プロジェクトチーム全体が協力して事に当たるのが理想なんじゃないかなぁ、って思う今日この頃です。
…っていうか、仕様書書くのもう飽きた。俺にPGをやらせろ~
No.10
- 回答日時:
私は以前、他の人が作ったシステムの改良を頼まれました。
その時に、仕様書がなかったので、プログラムの解析から始まり、大変な目にあいました。
ないよりは、あった方がいいでしょうが、全然違う仕様書があっても混乱するだけのように思います。
その辺を踏まえると、その人の常識は、非常識のようにしか思えません。
何の為に仕様書を書いているのか、もう少し考えて欲しいものです。
No.9
- 回答日時:
こんにちは。
悲しいですが、それが現実です。
あまりにも仕様もれが多いときは、そのまま仕様書どおりに作って、
結合テスト時に、不具合がでるようなデータを仕込んでおきました。
案の上、ユーザーテスト時には、設計者は恥をかき、ユーザーが直接、プログラマーに指示を出す始末。(テスト時に、設計者からここの処理どうなっているの?ってしょっちゅう電話がかかってきてました)
私見ですが、私は、プログラマーはもらった詳細設計の世界で完結したものを仕上げればいいと思っています。他のPGMとのインターフェースは設計者の責任。
スキルのあるプログラマーは入力チェックを実装するのはあたりまえといった意見もありますが、この手の処理は全体で統一されていないと、意味がないので、
開発初期段階で、設計者が提示するものだと思っております。
No.8
- 回答日時:
設計者の日々の流れ
1.やる事いっぱーい
2.がんばる
3.少し時間ができる
4.プロジェクトを持たされる
5.やる事いっぱーい
6.がんばる
7.少し時間ができる
8.プロジェクトを持たされる
・・・
・・・
・・・
∞.持ち抱えプロジェクトいっぱーい
∴時間なーい。気持ちに余裕がなーい。嫌な奴になってしまうー。
ちなみに私は
※3・7・11・・・番目の「少し時間ができる」の時
タバコのポイ捨てをしない、ちょっとだけいい人になります
※4・8・12・・・番目の「プロジェクトを持たされる」の時
「最初はグー」と言いながらパーを出し、コーヒーを年下におごって貰う、せこくいやらしい人になります。(今日の出来事)
No.7
- 回答日時:
その時の状況にもよると思うのですが、
正論で考えればすでにみなさんが回答されているとおり、
プロ意識に欠けるものと言えるかもしれません。
私の身近な例で言うと、
仕様書の作成者とプログラマーが同じ会社の社員である場合、
プログラマーを育成するためにわざと間違えを指摘させるように、
誤りを盛り込むこともあります。
得てしてプログラマーは仕様書に対していかに忠実なロジックを
くみ上げるかが重要ですから、
何も考えず、間違った仕様どおりにくみ上げてしまう人もいるわけです。
これではプログラマーから先の仕事をする上で困ってしまいますから、
仕様の正否を判別できる力ぐらい無いと困ってしまいます。
まぁ、naokodazoさんの質問内容を見ると、
単純にプロ意識に欠けた仕様書作成者としか見えませんが、
そんなケースもあると言うことで回答しておきます。
この回答への補足
私も人間ですし、事実失敗もします。けれど、失敗してあたりまえという気持ちを持つのは間違っていると思います。失敗したから責めているのではありません。失敗した時に「しまった」と感じて「次回から1つでもミスを少なくしようと努力するんだ。」という気持ちを持つべきだと思うのです。意識の問題です。
補足日時:2002/10/22 17:58No.6
- 回答日時:
「仕様書に間違いがあるのはあたりまえや」という件に関しては、当たり前なわけがありません。
プログラムもバグなどで異常終了するなどが当たり前なわけがないように、仕様書も間違いが当たり前なわけがありません。
そのようなことを堂々とおっしゃられるのでしたら「プロ意識に欠けている」と感じても当然のことだと思います。
ただし、プログラムにもバグが全くないと言うことが、どんなに優秀な技術者でもあり得ないということと同じように、設計者も多少の間違いも仕方ないとは思います。
バグを単体テストや結合テストフェーズで修正していくことと同じように、設計フェーズでの細かいミスも、その後の開発、テストフェーズで修正していくことになるのが普通ですので。
それを「仕様書に間違いがあるのはあたりまえや」と開き直られたら、最悪ですが・・・。
また、間違いは言語道断ですが、仕様書に細かく明記しないが、常識で考えて、仕様書に明記してなくても、プログラムに実装するのが当たり前、ということも多分にあります。
おそらく、その設計者は、口は悪いが、そのようなことをおっしゃりたかったのではないでしょうか?
例えば、DBのあるフィールドが30バイトであるとして、30バイトを超えて入力した時、警告を出す、というような仕様は、わざわざ明記しない場合が多分にあります。
こういったことは、スキルのあるプログラマなら、当然のように実装します。
しかし、まだ新人プログラマだとしたら、そういった常識もまだ判断できるレベルに達しないのが普通ですので、私の場合は、新人用の仕様書と1人前用の設計者は仕様書の記述レベルを全く変えてます。
しかし、なんにしても、新人用であろうと、1人前用であろうと「間違い」は言語道断ですね。
No.5
- 回答日時:
間違って当然と思っているなら、仕様書作成者のほうが、
むしろプロ意識は欠けています。
仕様書に間違いがるのは、よくあることですが、
100%に近づけるように努めてあたりまえです。
また、プログラム経験が浅いならば、違うと思っても独断で決めず、
作成者に確認をとったほうがいいです。
あなたのとった行動は間違いではありません。
・・・常識、常識って言葉もあなたに常識がないという意味で
本当に言ったのでしょうか?
常識を間違ってしまった、照れ隠しのようにも思えますよ。
お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!
似たような質問が見つかりました
- 労働相談 合意済み仕様の商品納入後における仕様変更要求への対応について 5 2023/04/19 09:41
- 会社・職場 今有i期i雇i用で契約していて、もうすぐで入社して2ヶ月になるのですが、 私には勤怠確認と有給等申請 3 2023/07/10 23:05
- その他(悩み相談・人生相談) 仕事への意識 頑張れない自分 初めまして、閲覧ありがとうございます。 私は25歳社会人男です。 仕事 2 2022/07/12 20:29
- その他(悩み相談・人生相談) これって逆ギレですか? 2 2022/04/14 17:06
- 会社・職場 勤怠管理の仕事されている方は大体どのくらいで慣れたのか 会社の人達の対応や私の考えについてどう思うか 2 2023/06/02 00:25
- 大学受験 AO、総合型選抜出願時に使用する活動実績報告書について 4 2022/06/27 01:21
- 不動産業・賃貸業 不動産業の事務職について 3 2022/11/27 01:06
- 会社・職場 仕事のスピードに対する考えかた。 新卒で研修後配属され1ヶ月半です。 私は、ゼネコンの一般事務、経理 2 2022/06/12 20:04
- 知人・隣人 相手からの質問に回答中、「聞かれたことに答えろ」と話を遮られることについて 5 2023/02/12 00:55
- HTML・CSS 依頼したWEBサイトの修正に追加料金がかかる 10 2022/10/24 09:31
関連するカテゴリからQ&Aを探す
おすすめ情報
デイリーランキングこのカテゴリの人気デイリーQ&Aランキング
-
自分の会社は「弊社」「当社」...
-
架電、切電、終話・・・??
-
メーターボックス開け方
-
お客様に対して「お世話になっ...
-
草の単位体積重量について
-
職人さんが架台(かだい)を「が...
-
鉄筋のSD295とSD345
-
一日3回セックスしてますが、み...
-
区費を支払わない人…
-
「建設的」の意味
-
塀は隣の許可がないと境界から5...
-
建築図面の斜線表示やバッテン...
-
岡田茂吉研究所について
-
即答お願いします。 pcの上に重...
-
今 建築業の職人さん めちゃく...
-
昨日この辺りのネットの電線を...
-
基礎のコンクリート部分を勝手...
-
三仏寺投入堂の建築は今の技術...
-
マンションの電波障害、後住者...
-
焼き物のカメの底に穴をあけたい
マンスリーランキングこのカテゴリの人気マンスリーQ&Aランキング
おすすめ情報