社内システムを自社で開発しているのは珍しいですか？

質問

社内SEとして今年商社に入社いたしました。

大変素人からの視点なのですが、
基本的にはCOBOLやORACLEといったものを使ってできているようです。
バッチ処理はJP1などによるオペーレーションのようです。

しかしCOBOLともなると20年くらい前からあるプログラムもあります。
バッチに関しても、ふれた事がある人にしかわからないような内容になっている場合が多々あります。
いうなれば、書籍検索端末が無い図書館のようなもので、ほとんど人の頭にあるような状態です。
仕様書なんてあればいいほうです。保守、改修はまずソースの解読から始まります。

というような状況で、何がどこにあるのかどういう内容なのかは、すべて人の頭の中です。
資料もほとんど紙面で、調査には時間がかかります。

こんな状況下ですので、改修、保守の作業が私には大変生産性が低いように見えます。

ここで質問です。
1.社内SE、もしくはそれ以外でも、こういった状況は珍しく無いのか。

2.社内のシステム(物流、経理等)を自社で開発している会社は多いのか。
もしくは外注に任せる数が増えたのか。

大変冗長な文章で申し訳ありませんが、よろしくお願いいたします。

回答No.3

ちあき（@Chiaki-F） · ベストアンサー

1.珍しくはないですね
　ドキュメント類を作るのは時間がかかるので
　とにかくシステムを構築するのが先決ってなる場合も多いですし
　最初はきちんと仕様書を作っていたとしても、途中で変更点を書き込み忘れたら
　その仕様書はあてになりません

2.自社開発は多いですよ
　他社に頼むと自社の現状を教えなければいけないので
　嫌がる会社も多々あります
　他社に頼んでいる場合、システムを変更しなければいけなくなった時に
　小回りがきかないし時間がかかります

質問者さんがドキュメント類を新しく作り直したとしても
次に担当される方が更新していかなければ同じ事を繰り返します
会社と話し合い、規約や規定を作って会社として確実に実行していく
仕組みを考えるのが一番ではないでしょうか

お礼

ドキュメントは保守も重要ですよね。
改訂履歴がしっかり書き込まれていない仕様書も多く見ました。
せめてしっかりした書式やテンプレがあればいいのですが。

私は商社のSEなので、物流や経理の点で社員からの要望が結構あります。
確かに外注にまかせっきりだと、こうは上手く回らないでしょうね。

自分にはまだそこまでできるかわかりませんが、自分がたずさわったものだけでも保守できればいいと思っています。

回答No.7

nolix

SI系会社経営18年です。
＞1.社内SE、もしくはそれ以外でも、こういった状況は珍しく無いのか。
普通です。
＞2.社内のシステム(物流、経理等)を自社で開発している会社は多いのか。
理想です。実際、外注に出している会社は馬鹿ばっかりです。
何の技術も身につかず、ビジネスやってる振りばっかりで・・・

質問者さんのCOBOLを馬鹿にしたような質問はあまり頂けませんね。
勘定系、Verifyなど、安全で堅牢であることには間違いありません。
PCサーバーばかりに影響されとこうなるのかな？
某有名自動車製造もCOBOLで数万本のプログラムらしいです。
すべてのルーチンを把握している人間はいないそうな。
インセンティブの計算ですら複雑怪奇らしい。
そんでもって、ERPなんかのせられない。
でも、世界のリーディングカンパニーですよ。
SAP R/3導入したら業界一になれるなんて誰も言っていないし、そんな事実はない。

スモールモディフィケーションで一々、仕様変更書いている方が実際、非効率っす。
まあ、システムの理想と現実、効率化、非効率は相反するものの様ですよ。

私も、RPG、shell,SQL,VC##などやりますが、仕様書は最後ですね。

あなたの言っていることを現実化しようとすると、このご時世だと倒産しますね。
あなたにも、会社にも歴史があります。あなた個人では到底まかないきれないような、歴史がね。
歴史を否定しても未来はありません。

現状を継続し、新しいものに少しずつ置き換えることは、お金があればそのうちできますが・・・
要は、その時勢や時代と会社の状況を良く見聞することから始めないと・・・
伊達に歴史を作り、現存していないですよ。会社は・・・

お礼

＞質問者さんのCOBOLを馬鹿にしたような質問はあまり頂けませんね。
そのような印象を与えてしまったのなら謝ります。
私はCOBOLを馬鹿にすることを意図した文章を書くつもりはありませんでした。

後半の分は若輩の自分には理解が難しかったですが、
仕様書がいつの時代も、あまり重要視されないのは同じようですね。
ありがとうございました。

回答No.6

ultraCS

１　大きな企業は、○○コンピューターサービス(○○にはその企業名が入る)とか○○システムといった系列会社を設立してそこに投げるケースが多いと思います。最初の頃はシステム部門でやりますが、ある程度時間が経つと別会社化する事例が多いと思います。
本社のシステム部の要員は発注元として発注管理する範囲とするか、系列企業に出向する形が多いです。

２　社内のシステム部門が開発をすると言っても、実際には日立、富士通、IBMあたりに丸投げという形も多いです。外注と言っても、こういったシステムは気密性が高いので、元請けは上記のコンピュータ企業や実績のある大きなソフトウェア企業が多いでしょう(下請けは小さなソフトハウスというのは珍しくないけど)。金融系の勘定系はこの形が多いと思います。情報系は１の形(系列に出す)が多いんじゃないかな。

お礼

なるほど、外注といっても同じグループ会社内だったりするのですね。
私のところではグループ外ですが、外注を少し使っています。他は本当に手助け程度(サーバーが壊れたの時等)で、ほとんど自分たちでやっている感じですね。それはグループ内の会社の人が駆けつけてくれます。

先輩の話を聞いていると、外に情報が漏れる事を極端に嫌っているような印象を受けました。
事実その外注さんも十年以上の付き合いのうようで、信頼が置けるのでしょう。

回答No.5

jeee

社団法人日本情報システム・ユーザー協会がアンケート調査結果が参考URLにあります。

参考URL：

http://www.juas.or.jp/project/survey/it09/index.html

お礼

貴重な資料情報ありがとうございます、参考にさせていただきます。

回答No.4

pon2pon2

自社で汎用機購入して、設計、アプリ開発までって
普通はありませんので、
多分、開発と思っている作業は、
実際は単なる運用レベルの内容なのではないかと思います。

多少いじる（既存のプログラムを修正して流用とか）程度であれば、
他社の人間使用して工数かけるほどの仕事でもないので、
自社のオペレータでやってしまうところは多いのでは。
ま、大手であれば、システム管理部門自体、
別会社にして委託なんてこともしてますけどね。

ま、無いもの考えても仕方ないので、
自分が関係したものは、きっちり資料としてまとめておき、
今後、他の人のための参考資料として残していくことが重要かと。
意外に、あとあとになって自分で使用するってことも多いです。
今の自分が作成した資料は、未来の自分からみれば他人が作成した資料と変わらないので、
できるだけ詳細にあとあと読み返してわかるようにしておきます。

ま、基幹系なら、業務の流れがあって、画面があって、
どの処理がどう繋がっていき、どう処理されるかは決まっているので、
そのあたりの流れと実際使用するプログラム名、
各プログラムごとの処理詳細といったものから、まとめていくとよいのではないかと思います。

お礼

＞実際は単なる運用レベルの内容なのではないかと思います。
どの程度までが運用レベルなのか分かりませんが、
主に他社とのEDI連携、社内の物流や在庫管理システムの開発等です。システム自体は多少外注も使ったようですが、自社メインで作ったようです。

＞多少いじる（既存のプログラムを修正して流用とか）程度であれば、
そうですね、今のところ僕に割り当たる仕事はこういう仕事が多いです。

基本的なシステムの説明書や仕様書はそろっていますので、そういう意味では、もしかしたら私の会社はまだドキュメント(大量の古い紙資料ですが)は整理されているほうなのかもしれません。
自分でもちゃんと整理していきたいと思います。

回答No.2

karumakaruma

1.よくあります。
　というか、まだ人がいるだけマシです。
　既に知っている人がいないというのも当たり前。

2.社内開発は多いと思いますよ。
　大企業になれば外注を雇って運用メンテさせるという事も
　多くなりますが、今のご時勢ですから外注もどんどん切られてますね。

お礼

私は今仕様書を作るのに大変時間が掛かっています。
そういうところから、仕様書の作成は敬遠されるのでしょうね。

外注に頼ると、やはり経費の面で問題がありますよね。
社内SEなら悪い言い方をすると、いくらこき使っても安いですからね。

回答No.1

SaKaKashi

1　普通です。
2 会社の規模によります。自社で行っている会社は多いです。外注先が子会社とかは自社と同じことです。

お礼

大変端的な回答ありがとうございます。
やはりドキュメント整理はおろそかにされがちなのですね。
自社で開発することは、人材育成の点から見ても大変手間なことだと思っていましたが、結構多いのですね。