LoginSignup
ra_risu
@ra_risu

Are you sure you want to delete the question?

Leaving a resolved question undeleted may help others!

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

こんな時どうしたらいいんだろう……

①現状
内製した社内システム(Access)がある。
開発したのは20年以上前で、担当者は既に退職しており、設計書はほぼ存在していない。
現状は私(社内SE)一人が引継ぎなしに担当者になっている。
使用部門からはひっきりなしに機能追加依頼があり、そのたびに古くから存在するシステムにソースを追加したり、他の社内システムと連携(CSVの入出力やSQL Serverへの取り込み)したりしている。

②課題
なにせ20年以上昔のシステムなのでコードはスパゲティだし処理速度も非常に遅く、新規機能の追加もA画面をいじればBテーブルとCレポートとDクエリとEクエリと連携先のExcelとSQL Serverに変更を反映する必要があるというような有様なので、機能を追加するたびにデグレが起きないか非常に気を遣う(そして、利用部門はちょっとした変更だから短期間で出来ると思っている)
どのみち老朽化したシステムなので近いうちにリプレースが必要であり、現状の利用部門からの依頼をひたすらこなしている状況は将来の移行作業における作業や工数を自分たちで増やしているようなものである。
よって、私は新規機能の追加の凍結と、新システム(私が内製する)への刷新を提案した。

上司「うーん、でも利益を産まないシステム改修に工数はかけられないよね」
利用部門「まあ、今は処理速度が遅いし、早くなるんならそっちのほうがいいよね」

③私が取るべき対応
どうすればいいんだ……?
1.一応技術者として説明はしたので、それで決断しないのは知ったこっちゃないと考える。
2.処理速度の向上などによる時短効果をまとめたり根回ししたりして、どうしても新システムに刷新する。
3.その他

2しても結局内製するのは自分だから自分の仕事が増えるだけなんだけど、この状況をほったらかして後任に丸投げするのも気が引けるんだよな……
刷新するといういずれやらないといけない決断を先延ばしにして部門の要望を実装し続けることで、結局移行時の作業量やリスクを自分たちで増やし続けているこの状況が良いこととは全く思えないし、かといって平社員の社内SEが自分一人で勝手に移行できるわけもないし……

0

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

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

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

4Like

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

2Like

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

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

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

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

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

でしょうか。

3Like

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

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

■対策案

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

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

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

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

2Like

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

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

機能追加依頼

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

2Like

radian-jp様

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

dameyodamedame様

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

syutorum001様

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

HalHarada様

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

bunaImage様

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

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

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

3Like

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

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

3Like

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

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

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

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

1Like

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

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

1Like

Your answer might help someone💌