HatenaPocketLINELINE過去に、自分が他のプロジェクトで忙しく、全然マネジメントに関われていない時に、作り込んだ機能で、お客様から問い合わせというかクレームに近いことを言われた事がある。明細の一番上の合算金額は正しいけど、合算金額以外の明細が0円になっています。このままだと証憑と比較できないのですが...僕(仕様を決定した時の議事を確認)過去の検討で、合算金額が正しければ良いと決定した経緯がありますが...お客様とにかく、証憑と正確に照合できないのは困ります。不具合なので修正してください。僕わかりました...ちなみに、僕が過去の議事を参照したのは、「仕様変更じゃないか!」主張したかった訳ではなく、過去の事実確認をしたかったのです。本来の正しい姿を、その場限りのイレギュラーなケースに従って変更してしまうと、後々大変なことになるので...結果的には、そもそもその機能を実装した時は、こちらからの提案というか「この方式でないと実装できないです」という主張をしていたようで、こちらにも問題があるため修正しました。(仕組みがかなり難しいので、当時の予算枠の中ではそれが精一杯だったらしい)ただ、腑に落ちなかったのは、1年以上前に実装された仕組みで、「不具合です」と訴えていた本人が仕様決定時に「その仕様で構わない」と言っていた点。「なんでかな?」というのは気になったので、それとなくお客様側の人達に色々と話を聞くと、どうも2、3ヶ月前にその仕組みを利用する担当者の変更があったようで、前の担当者(連絡してきた人)の申請の時は問題なく部長が承認していたのに、新任の担当者の申請は部長に怒られたらしい。それもかなり強く...まあ...半分いびりだよね。いっても、その新しい担当者は色々と細かいミスを指摘されているようで、その辺りも含めて部長に目をつけられていた見たい。どちらにしろ、仕組みとしては「担当者が誰であっても処理ができる」というのは鉄則なので、半分不具合として修正しました。こんなケースもあれば、すごいイレギュラーなケースの業務処理をしようとして、「システムで変更できないのは不具合だ」と主張されたこともありました。主張してきたのは事業部門の部長さん。発生したケースについては、「10年前に一度あったかなぁ」みたいな内容。そんな業務処理なので、システムを構築した時にはシステム化の対象外としていたのだけれど、「システムの不具合だ」とすごい勢いで主張してきた。これは当時、直接やり取りをしていたシステムの担当者と話した結果だけど、上に書いた通り10年前に一度あったかどうかというレベルの業務処理で、詳細は書けないけど内容がかなりキナ臭かった。業務処理をする担当者は「私を巻き込むんじゃない」というのを、部長に直接言えず「システムが対応していないから処理できません」という主張をしていたので、はないかと結論づけた。(こんな内容は直接確認できないのであくまで憶測です)このケースは機能は修正せずに、データを更新するパッチを当ててその場をしのぎました。イレギュラーな内容をシステム化すると、それがスタンダードになってしまうので辞めておくべきという考えです。角が立つのであまり本質をついた言及は本人達にしませんが、社内システム(基幹システム)というのは色々あるもんです(。...MOLDというものを知った同じようなことを考える人はやっぱりいるのだね。...たまには頭を休める今日はなんとなくやる気が出ない1日だった。コメントをキャンセルメールアドレスが公開されることはありません。コメントデータの処理方法の詳細はこちらをご覧ください。この記事のトラックバックURL最近読んだ本(Amazon商品リンク)このサイトについて「自分が興味のあることを書きながら、それを元に収益化していくことが出来たら、これ程やりがいのあることはないな」という思いで作りました。