内製システムが老朽化しているが、誰も刷新しようとしない。

上司「うーん、でも利益を産まないシステム改修に工数はかけられないよね」

これ言っちゃう上司の時点で、転職活動を考え始めるかも…

どうしてもやるなら、2の時短効果や、保守コストとかそのへんが刷新に掛かるコストがどの程度でリターン取れるか辺りで攻めていく感じですかねー。あとは、保守が困難なので、自分が抜けた場合に最悪システムが使えなくなる的な事をチラつかせるのもよいのかもしれません。

上司の上司か、上司以外のなるべく技術的に経験豊富な人(分かってくれる人)に相談しましょう。
あなたに必要なのは味方です。
対立の構図を作らずにうまく出来るといいですね。

ざっくり読んだだけのコメントで恐縮なのですが
最早「リプレース」より「フルスクラッチ」で再計画する必要が
あるように見受けられます。

上司が「外部に対する利益」のみを意識しているようなので
「内部原価に関わる工数」が存在することを具体的に
「可能であれば」説明できればと思います。

さて、私が申し上げられる質問の結論としては

③私が取るべき対応(私の考え)

(1) 上記意見交換に登場している「上司」より立場が上の上長に現状をそのまま話す
(2) 独断せず誰かに相談して根回ししておく
(3) 最低限の引き継ぎ事項は纏めておく(退職する場合)

でしょうか。

設計書はほぼ存在していない。

使用部門からはひっきりなしに機能追加依頼があり

■対策案

１　機能追加依頼をこなす。その際、使用部門から業務目的、内容を確認し、設計書を作成する。

２　使用部門からの依頼は上長を経由する。それも文章で受ける。

３　SQL Serverを中心に入出力するシステムを洗い出し、全社のシステム構成を仕様化する。

４　何故、ひっきりなしに機能追加依頼があるか？全社の業務目的、内容の視点で、全社のシステム構成との乖離を捉え新規システム化案を考え提案する。

上司「うーん、でも利益を産まないシステム改修に工数はかけられないよね」

システムの保守や改修に掛けられる工数はあらかじめ計画されていなければなりません。何人日に設定されていますか？

機能追加依頼

受付の際に
・どの程度の改善効果が得られるか
・リスクアセスメント
などが必要です。
基本的に影響度が大きい改修はリスクが高くなります。リスクが高いものは試験を多くする必要があるので工数が増加します。また、法令対応だとやらないと会社が存続できないので受け付けなければなりません。そこから計画された残り工数と費用対効果によって優先度をつけて判断をすることが必要です。
これは「利益を産まないシステム改修に工数はかけられない」と矛盾はしません。
既に複数の連携があってリスクが高い状態ということなので
上手くいけば費用対効果が薄いものは改修しないほうがましと判断されていくと思います。

radian-jp様

回答ありがとうございます。
転職は出来れば最後の手段にしたいですが、自分が抜けた時のことを持ち出してもあんまり響かなさそうなのでどうしようかと思ってます……

dameyodamedame様

回答ありがとうございます。
対立の構図を作りたくはないし、そこまでする責任があるわけでもないのですが、
一番技術がわかる人が上司で、上司の上司はITに全く知識がないんですよね……

syutorum001様

回答ありがとうございます。
上記の通り、上司の上司はITに全く知識がないんですよね……（製造業の社内システム部門で、上のほうにシステムに詳しい人がいない）
退職するにせよしないにせよ、仕様をまとめておく必要はあるかもしれないですね……
一応時間を見つけて要点のまとめを作ってはいるのですが……

HalHarada様

回答ありがとうございます。
上長が私に丸投げという感じなので上長経由で依頼を請けるのは難しそうですが、
他は出来るだけやったほうがよさそうですね。
ひっきりなしに機能追加依頼があるのは、その部門の作業が増えたり管理指標が増えたりするからです。

bunaImage様

回答ありがとうございます。
＞システムの保守や改修に掛けられる工数はあらかじめ計画されていなければなりません。何人日に設定されていますか？
そういった指標は……一切ありません……

＞受付の際に
＞・どの程度の改善効果が得られるか
＞・リスクアセスメント

この辺も部門の発言力が大きく情シスの発言力が小さいので、
「とりあえずやってよ」「改善効果？あんまりないけどこのデータ見れるほうが便利だし」「影響が大きいとか言ってやりたくないだけなんじゃないの？」という感じで、
要望はほぼ全て呑む形になっています。
本当は費用対効果が薄いものはやらない、あるいは延期という方向に進むほうが健全だとは思うのですが……

別の部門や部署でもいいのですが、具体的な対処の話が出来る相談相手が必要だと感じました。ただ、どうしても何とかしたいという熱意がないと、現実的な範囲での改善も無理な状況に見えたので、「そこまでする責任があるわけでもない」と感じているのであれば、改善という方向そのものは諦めていいのではないでしょうか？

その上でご自身のキャリアに必要な業務がまだあれば、それに注力しつつ、転職先を探せばいいでしょう。現状の業務をまとめる作業は中途半端になりそうなら自主的にやる必要はありません。その責務は上司にあるはずです。

要望はほぼ全て呑む形になっています。
本当は費用対効果が薄いものはやらない、あるいは延期という方向に進むほうが健全だとは思うのですが……

組織として指標が無いのは目標もないし評価も出来ない状態だとは思いますが
健全でないならその状態を思う存分活用すべきです。
どんな状態であれ自分の意思を反映させることが心の安定には大切かと思います。

・既存システムの修正は稼働率を低下させる。
効率を考慮して作業効率を落とすのではなく完了報告を遅らせるでもかまいません。
・空いたマージンでリプレースor新システム開発を実施する。

他に修正できる人がいる場合はその人とは連携しないといけませんが、
もしワンオペならボトルネックのさじ加減でどうとでも掌握できるので後はお好きやるのが良いかと思います。

現状のシステムの仕様をまとめるなり新しいシステムの仕様案なりを準備してはどうですか。

リプレイス時には必要になるものですし、開発できない人たちには新旧システムの違いが判るものを提示してあげないとリプレイスの必要性も伝わらないと思いますよ。