プロが教えるわが家の防犯対策術!

職場で使っているシステムで不具合が起きました。
以前の開発者に連絡を取りましたが
「もう納品して数年たっているので瑕疵としては認めません。
 納品時にはエラーは起きていないので、当方としては完璧なものを納品しました。
 ですので、不具合が起きたのはユーザー側の責任なのではないですか?
 再開発もしませんので、他の業者に勝手に頼んでください」
と、けんもほろろな対応でした。

で、ここまではいいです。特に期待もしていませんでしたから。
(別に無料で治せ、なんてひとことも言ってませんし)

別の業者に頼もうとしていくつかの業者、プログラマに打診し、
「■■■■というデータを処理すると、
 正しくは●●●●、という結果が出てくるはずなのに
 時々、▲▲▲▲という結果になってしまうのです」
というように、プログラムに期待する処理内容と、
入力データ、正しい出力データ、誤った出力データを
提示して、見積もりその他の条件を検討してもらっていたのですが、
その中で
「現状の誤りデータの状況を見てください」
と言っても
「ああ、いいです、結構です、イチから作り直しますんで」
といってかたくなに現状確認をしない人がいます。

こちらが
「いや、プログラムを実行して、入力データと出力結果を
 比較してもらうだけで良いから、見てください」
と言っても
「ああ、いいです、結構です、イチから作り直しますんで」
といってかたくなに現状認識をしません。

これってプログラマという職種に特有の気質なのでしょうか?

相手は
「前の開発者が作った処理結果なんて興味ない。
 一から作るんだから、デバッグじゃないから、
 プログラムを見る必要もなければ処理結果も見る必要ない。
 ■■■■というデータを処理して●●●●が出てくりゃいいんだろ。
 じゃ、そういうプログラムを作るから、前のエラー結果なんて見たって意味なし!」

と思っているのかもしれませんが、当方としてはエラー結果を見てみれば

 「プログラムの不具合の検討もつくかもしれないし、それによって工数も変わってくるかもしれない。
 もっと言えば当方が入力しているデータそのものに誤りがあり、
 その場合は■■■■というデータを処理した結果、▲▲▲▲という結果になるのは当然である、
 ということが判明するかもしれない。
 だから現状の入力データと処理結果を見て欲しい」
といっているにも関わらずかたくなに現状認識をしません。

これってプログラマはみんなそうなのでしょうか?
それともこの人だけがおかしいのでしょうか?
いや、逆に、この
「現状のエラー出力結果を気にしない人」
が普通のプログラマなのであって、
「現状のエラー出力結果を丹念に調べる人」
は異常なプログラマなのでしょうか?

プログラマに詳しい方、お願いします。

A 回答 (8件)

>これってプログラマはみんなそうなのでしょうか?


それともこの人だけがおかしいのでしょうか?

ええとですね、それが普通とは言わなくても多くの人がそうかもしれない。
ちょっと小難しい話になりますが他社さんが納品したシステムは他社さんがソースコードをもっており、質問者さんの会社の場合はそのソースコードをもっているわけではなく完成したシステム(ソフトウェア)として持っているわけでそもそも論としてデバッグできません。
技術上出来る、出来ないではなくしちゃいけないという事です。
だから質問者さんのいう入力した結果、正しい数値、正しくない数値をみても「うん、ここが問題だ」とは思うものの、元のソースコードをデバッグできるわけでもないから別に見なくてもいいという話です。
どこかでプログラムの記述が間違っているか、もしくは入力データの形か、それとも別の処理をしたあとの問題か?いずれにせよ今の段階で新しい業者が詳しくみてもその先がないのです。
だから自分たちが作ったとき同じ問題がでれば質問者さんの報告をよく聞くと思います。
それこそ自分たちで「修正できる」からです。
でも、普通はお客さんの話は聞きますけどね。

ではでは。
    • good
    • 0
この回答へのお礼

ご回答ありがとうございます。

>でも、普通はお客さんの話は聞きますけどね。

そうですね

お礼日時:2023/07/30 08:45

プログラムのメンテナンスはふつうはそれを担当した者がやります。



プログラムの作り方はその人の流儀というか、考え方というか、個性みたいなものがあって、他のプログラマーが作ったプログラムは別の人がいじりにくいんです(私ならこんなふうにはしない、と)。
なので、一から作り直しになります。

そうすると、納品後にエラーやバグ(あるいは改善要望)出る可能性がないとも言えませんから、その後もメンテナンス契約をしばらくは続けないとね。
    • good
    • 0
この回答へのお礼

ご回答ありがとうございます。

お礼日時:2023/07/30 08:46

仕様書どうりなら問題ない

    • good
    • 0
この回答へのお礼

ご回答ありがとうございます。

いえね、前のプログラムも仕様書通りに作ってもらったんですよ。
でもね、時間が経ってきたらだんだん誤った出力がなされるようになったんですよ。
その原因がわからない。
だから修復(実質的には新規開発)するにしても、
「これこれこういうデータを入力したら、仕様通りの出力を得られない。
 それはこの点に落とし穴が潜んでいたのだ!」
ということを見極める必要があると思うんですよね。

例えば、もしかしたら
「時間が経過したら誤り出力をするようになった」
の原因が
「2010年代から2020年代になったから」とか
「平成から令和に改元されたので」
ということだってあり得るじゃないですか。

「オペレータがベテランから新人に変わったから」
という可能性だってあるじゃないですか?

そういうように
「現状の誤り出力の原因はどこなのか?」
を追及せずに
「イチから作りますんで大丈夫です」
と言い張るのはどうかなあ?
 と思うんです。

「ははは、昭和は64年続いた
 平成だって30年続いた。
 だから令和の次の改元なんて向こう30年、
ありはしないんだから杞憂だよ」
って言ってられますか?

改元なんていつだって起こり得ますよ?
(まあ、あんまりいうと不謹慎だからここまでにしますが)

私、間違ってるでしょうかね?
心配性なんですかね?

お礼日時:2023/07/28 16:23

おはようございます。



んー。多くの場合「現状のプログラムの挙動を見ろ」っていうのも立派
な仕事になってしまうんですよ。それに見た結果修正しろという2段階
の仕事依頼になるんですが、お金出せるんですか?

お金出せるんならきっとやってくれると思うんですよ(1段階目の仕事
は症状を見るだけではなく、何故そうなるのか他人の書いたソースを解
析して原因を突き止める事になると思うので、どんだけお金請求される
かわかりませんけども)。

でもきっと、そんなお金出せないですよね?。

だったら「新規に作る」のは悪い方法ではなく、お金の事情でそういう
方向で動くのであれば、「新規で作るプログラムで、以前の不具合が発
生しない確認する意味はない(確認しないわけではなく、普通の動作確
認を行い、それとは別の特別な確認をする必要はないという意味で)」
というのもわかると思うんですが。

いややっぱり確認してくれっていうなら「それもお金出せばやってくれ
る」んじゃないかと思いますけど、ぶっちゃけた話「普通そういう新規
で作るもので、昔の不具合が出ないことを確認するってのは今の開発者
に言うのではなく、納品前の動作確認で、自分で確認する」のがいいん
じゃないかなぁ、と思うんですけども。

そこで不具合が出ても「おかしいよ?」と注文付けられるわけで。

全部君たちに一任する、お金はいくらでも出す、という仕事じゃないん
でしょう? どこで問題無しとする線引をするか、そのためのお金を減
らすにはどうすればいいか、という話だと思いますよ。
    • good
    • 0
この回答へのお礼

ご回答ありがとうございます。

むーん、そうなんですかねえ。
普通の(私の普通、が世間の非常識の可能性もありますが)感覚なら
「今の現状はこんな風になっちゃってるんですよ」
と問われたら、普通は(もういちど言いますが、私の普通が世間の非常識の場合もありますが)
「はい、どれどれ、拝見しましょう」
ぐらいのことは言うと思うんですけどね。

例えば、車やバイクを修理に出すときに、あるいは医者に掛かるときに
「今、こんな不具合や困った症状が出ています」
と言ったら、やっぱり整備工の人やバイク屋のおやじさん、医者は
「はい、どれどれ、拝見しましょう」
って言ってくれると思いますよ。

どんな車屋、バイク屋でも
「うるせえ、俺が治すって言ってんだから、現状がどうのこうのと素人がごちゃごちゃいうな!」
とはねつける不愛想な車屋、バイク屋に修理してほしいと思う人がいるでしょうか?
あるいは
「あんたねえ、”普通は普通は”、というが、
 人間の体を一番よく知ってるのはわれわれ医者だよ、
 ”普通”に一番詳しいのは医者なの!
 医者の言うとおりにしてりゃいいの!
 それともあんた、医者か?」
とシャットアウトする医者に掛かりたいと思う人がいるでしょうか?

まあ、車屋、バイク屋、医者と、プログラマは違う職種だから
車屋、バイク屋、医者に通じる常識と、
プログラマに通じる常識は
違うのでしょうけど。

回答者No1様のお礼コメントにも書きましたが
プログラムが出来上がって(もしくは納品後の検収段階になって)
当方「では、テストします。
 前回開発したプログラムで誤った出力をしてしまうデータを投入してみますね。
はい、やっぱり新しいプログラムでも誤った出力になりました。
 ぜんぜん要望通りにできてないじゃん、
 もう時間ないよ、どうすんの?」
と開発者に問うて、開発者が
「先に言ってくれよ!」
と反論してきても
当方「だから開発前に
 ”現状のエラー状態を見てから着手してくれませんか?”
 って言いましたよね?
 それ、あんた拒否しましたよね?
 ”俺様がイチから作るんだから現状把握なんて必要ない!”
 って。
 なんなら録音聞かせようか?」
ってなことになるんじゃないかと杞憂しています。

お礼日時:2023/07/28 16:06

発注の仕方によります。


現在のプログラムベースでの改修を前提としていても、モジュールごとイチから作り直すのであれば、仕様さえ明らかなら現在の処理結果を確認するのは時間の無駄です。
現在の不具合だけ仕様にあったようにデバッグして修正してほしいのであれば確認するかもしれませんが、それも動作確認ではなくてコードを見れば明らかなのでしないでしょう。

異常とはいいませんが、時間や工数の無駄を嫌う人がITエンジニアにはおおいと思います。
    • good
    • 2
この回答へのお礼

回答者no1様への回答にも書きましたが、要するに
現状の入力データ、正しい処理結果、誤った処理結果を見てもらうことによって

「なるほど、こんな特殊なデータを入力することもあるんだね
 これはプログラム開発前に予め言ってもらってよかったね。
 それが無ければ我々も同じバグを抱えたプログラムを作ってしまうところだった
 やはり現状認識とその対策って必要だよね」

ということになると思うのですが・・・

これはいわゆる

「轍を踏まず」
「他人の振り見てわが振り直せ」

ということでありどんな職種、どんな職場においても
必要なことだと思うのですが・・・

もしかしてプログラムの作成、コンピュータ業界というのは

「他人のプログラムを見たって自分のプログラムの参考にはならない
 だから見るだけ時間の無駄」

「前任者の轍はふまない。だって俺は別の道を往くから」

が業界規範なのでしょうか?

お礼日時:2023/07/28 10:05

素人考えでも、基本はあるだろうけど他社の作ったバグを見つけて修正するより、自社のプログラムに書き換えるほうが、人件費的には一瞬と何日もの差が出るよね。

バグを見つけるって、膨大だと思うよ。全部見るだけで数週間はかかるんじゃない?
    • good
    • 0
この回答へのお礼

回答者no1様への回答にも書きましたが、要するに
現状の入力データ、正しい処理結果、誤った処理結果を見てもらうことによって

「なるほど、こんな特殊なデータを入力することもあるんだね
 これはプログラム開発前に予め言ってもらってよかったね。
 それが無ければ我々も同じバグを抱えたプログラムを作ってしまうところだった
 やはり現状認識とその対策って必要だよね」

ということになると思うのですが・・・

これはいわゆる

「轍を踏まず」
「他人の振り見てわが振り直せ」

ということでありどんな職種、どんな職場においても
必要なことだと思うのですが・・・

もしかしてプログラムの作成、コンピュータ業界というのは

「他人のプログラムを見たって自分のプログラムの参考にはならない
 だから見るだけ時間の無駄」

「前任者の轍はふまない。だって俺は別の道を往くから」

が業界規範なのでしょうか?

お礼日時:2023/07/28 09:56

設計段階でどんな設計をしたかによってプログラムにも反映の仕方が関わるのでは無いでしょうか?



今回の述べている事象であれば、データと関連する条件をマトリックス(表)にまとめれば、その時その時の条件とデータによってメッセージがハッキリ出て来るように思えます
そのマトリックスがテストを行うデータ作りや条件をどのように仕組むとかのベースにもなるでしょう

結論として、設計が有って、その設計を元にプログラミングをするので上流工程がグラついていたら、下流行程はそれ以上の影響を受けますのでキチンと決めるところを曖昧にしていたらファジーなプログラムを作り、責任所在まで出て来そうです
    • good
    • 0
この回答へのお礼

ご回答ありがとうございます。

お礼日時:2023/08/01 18:04

プログラマとしてはそんな感じかと思います。


フロントに立つSEなら、現状把握の調査費用、それ対する回収費用を別で見積もり「調査して作り直すことになると結構費用がかさむ。ほぼ確実に一から作り直したほうが安いと思うけど、それでも調査しますか?」みたいな感じで説明しますね。
    • good
    • 2
この回答へのお礼

ご回答ありがとうございます。

ふーん、そんなもんですか・・・
ええとね、そりゃ他人の作ったプログラムを精査しろ、
デバッグじゃなくてイチから作るにしても、現状を把握しろ、
というのは、依頼された側からすれば
「めんどくさい」
「まさか無料でやれ、ってんじゃないだろうな、もちろん調査工数を上乗せして良いのだろうな、たとえその後にデバッグはなく、イチから作るにしても」
という気持ちがあるのはわかります。

でも、質問文に記載したように
「■■■■というデータを処理すると、
 正しくは●●●●、という結果が出てくるはずなのに
 時々、▲▲▲▲という結果がでることがある」
という現状認識をしっかり行ってくれないと、
同じ事が起きるんじゃないか? と思うのです。

もしそうなった時に
プログラマ「貴方の作ったプログラムでもやっぱり時々誤った結果が出てきます。
 どうしてですか?」
と問うて、その時に
「おかしいですね、元のプログラムでの入力データと処理結果を見せてください。
むむむむ! あれれれれ! 何だこりゃ!
こういうデータを処理することもあるのか!
だったら先に言ってくれよ!
 こういう特殊なデータを処理する時には特殊な処理が必要なんだよ!
 それを言ってくれなきゃ困るじゃないか!」
と言われて
依頼者「だから開発前に言ったじゃないですか。
 現状のプログラムでの入力データを正しい出力結果、誤った出力結果を見て、現状認識、現状判断をしてから
同じミスが出ないようなプログラムを作るように着手してください、ってね」

まあ、このあと
プログラマ「だから先に言えっていったじゃん!」
依頼者「だから先に処理結果を見てくれ、って言ったじゃん!」
の永久ループに陥ると思うのですが。

それともプログラマ(すくなくともこのプログラマ)は
「私は絶対にミスしないプログラムを作れる」
ということでしょうか?

お礼日時:2023/07/28 09:34

お探しのQ&Aが見つからない時は、教えて!gooで質問しましょう!