質問

2007年04月01日 02時51分
  • 情報処理の開発員と操作員と分けなければならないか

情シスのオープンナレッジ『Syszo』サービス終了のお知らせ

質問

私の会社の基幹システムは自前で作ったものです。
そのためにシステムの改造、新規開発にかなりの工数を要しています。
内部統制の件で一応はSE(システムエンジニア)とオペレータ(操作員)と分けた職種にしていますが実態は全員、SE兼プログラマ兼オペレータです。
社内のある部門から「情報処理の開発員と操作員を明確に分けろ」と言ってきたのですが私は「開発手順は明確だから要員を分けなければならない事はない」と言って反対しています。
私としては明確に分けると開発・改造時期によって負荷が偏ってしまうし、大規模改造・開発では1人でも多く投入したいので分けたくないのです。

皆さんのところではどうなのでしょう。お聞かせ願えればと思います。

6件の回答があります

回答

参考になるコメントではありませんが、
####
社内のある部門から「情報処理の開発員と操作員を明確に分けろ」と言ってきたのですが私は「開発手順は明確だから要員を分けなければならない事はない」と言って反対しています。
####
この「明確に分けろ」の真意がどこにあるかが、不明ですが、ITそのものの考え方でも、ワークの負荷が掛かった場合、余分なリソースをそちらに回して使うのが当然のような流れであることからして、人材の有効活用の面でも私でもdesato さん同様に考えます。内部統制の制限範囲で許せばという前提ではありますが。
まあ、多くの中小企業の場合は、開発要員とオペレータを持って役割分担でやれるところがまず少ないでしょうけど・・。ちなみに弊社は、運用のみ自社スタッフで、運用は外注です。

2007年04月01日 14時11分

回答

こんにちは
「人件費がそれぞれどのくらいか?」
経理部門や経営陣が知りたいのではないでしょうか?
確かに「SE兼プログラマ兼オペレータ」というが多くの実態であると
思いますし、「SE兼プログラマ兼オペレータ兼管理職」なんていう私です。

工数管理をされていれば、それぞれの業務の工数を明確にすることが
できるのではないでしょうか?
「人」を分ける事が現実的ではないとしたら、せめてどの業務に
どのくらいの工数が掛かっているかを明確にすれば
お互いの落とし処になるのではないでしょうか。

追伸
蛇足ですが
私の情シスは、タイムカード兼工数管理表をエクセルで自作利用しています。
これがあれば必要な時に人員を増やす要素が簡単に説明ができます。

回答

今の会社では自社で開発はしませんので参考にならないのですが、
前職では内部統制がらみもやっていましたのでその時の知識から。

上場企業であれば、内部統制上、職務分掌?の観点から
同一であれば内部統制で問題あり となるのではないかと思います。
ただし、非上場の会社であれば大きく問題になることはないと思いますし、
事後チェックでチェックしているというフローにしておけば
大丈夫だと思います。
上場企業でもきっちりと分けるのではなく、
事後チェックをするというフローにすることで
内部統制上も問題ないとする会社は多いと思います。

回答

IT全般統制における「職務分離」ということですね。
うちの監査法人の場合、「本番環境が許可なく改変されない」統制を整備しろと言っています。
統制面だけ考えれば、運用系要員(システムの安定性に責任を持つ)と開発系要員(システムの短納期リリースに責任を持つ)を分けるのが、相互牽制になるので一番バランスが取れるのです。
が、現実問題として難しい場合、
・本番環境の資産管理をきちんとする
・本番のアクセス権をマネージャーのみが保有し、リリース時には代わりにログインするなどの対応を行う
・または、改変ログを取得し、リリース申請と確実に照合して不突合があれば調査する
などで、統制があると判断できるとのことです。
貴社の監査人が同じように考えられるとは限りませんが、(監査法人ごとに、また監査人ごとに解釈はぶれるようです)ご参考まで。

回答

わたしが以前に勤めていたところでは、開発とオペレータは一応は分かれていました。というか、オペレータには開発の能力がなかったので・・・。

ただ、ご質問の意図としては、開発部隊とは別の専業オペレータ職を作るかどうか、ということだろうと思いますので、これに沿ったかたちで答えますと、人的なコストが掛けられるならば、別にしたほうが良さそうに思います。

というのも、どうしても開発者の視点はオペレータの視点とは違うので、開発者ならやらないようなイレギュラーな操作も、オペレータならやってしまう可能性がありますよね。
しかし、それが逆にイレギュラーな操作に絡むバグや不具合などが長期間放置されてしまうことを防げるという面もあるので、開発者がオペレートまで全部やるよりは、オペレート専門部隊があったほうが良いように思います。

これはまた内部統制の話とは別の次元の話ですね。

2007年04月04日 12時54分

回答

運用と開発を分けた方が良いと思います。しかし、分けることにより、開発が遅くなったり費用がかかったりすることもあると思います。
もし、許されるのなら(多少納期が遅れるあるいは、費用が発生するなど)分けたほうが良いと思います。

開発者して運用する場合、ドキュメントが疎かになってしまいます。当然のことながら、開発が忙しくなると、以前開発したドキュメントの整理などは疎かになり、開発に傾注してしまします。(納期があるので、当然と言えば当然ですが)

開発と運用を分けることで、引き継ぎの資料をきっちりと残すことができます。ドキュメント管理をきっちりと行うことで、開発者と運用者の目で相互チェックができます。この相互チェックが「内部統制」も絡み重要だと考えています。ユーザは、資料を残さない風潮にあると思います。それが積もると、システムのブラックボックス化の原因にもなります。
システム部門のオープン化のためにも、できれば、分けるほうがよいと思います。

経理も、入金と出金の担当者を分けるほうが、不正が発生しにくくなります。しかし、作業効率から考えると入出金を全員で担当するほうが、効率的かもしれません。実際、入金担当者と出金担当者は分けれることが可能のであれば、分けています。これと同じように考えればどうでしょうか?

2007年04月05日 09時08分

あなたもコメントしましょう!