社内SEは本当にコードを書けないのか？現場で使う言語と全員のコーディング事情の実態

2026年5月10日

「社内SEはコードが書けなくてもいい」という話、聞いたことがある方は多いんじゃないかと思います。本当のところはどうなのか、気になりますよね。

私の職場で言うと、コードが書けないと仕事になりませんでした。

この記事では、内製型の会社で社内SEとして3年働いてきた私が、自分の職場で実際に使われている言語と、チーム全員のコーディング事情をお伝えしていきます。あくまで一つの会社の話ですが、現場の温度感を知る材料として読んでもらえたら嬉しいです。

「社内SEはコード書けなくていい」は、少なくとも私の職場では違った

ネットで「社内SE コード書けない」と調べると、「社内SEはマネジメントが中心だからコードは書けなくても大丈夫」という情報がよく出てきます。

ただ、私の職場に関して言えば、これはちょっと違いました。

私の会社は、システムを基本的に内製しています。外部に丸投げするのではなく、自分たちで作って自分たちで直すのが基本のスタイルです。そういう環境では、コードが書けないことには仕事になりません。

なのでこの記事は、「社内SEはみんな書ける」と言いたいわけではなく、「内製型の会社では、こういう実態がありますよ」という一例として読んでもらえたらと思います。完全に外注している会社では、また話が変わってくるはずです。

私の職場で実際に使われている言語

私の職場で使われている言語を、ざっくり並べてみます。

COBOL
VBA
VB
C#
Python

こうして書き出すと「いろいろ使ってるんだな」と感じるかもしれませんが、それぞれの位置づけはかなり違います。

メインはCOBOLとVBA。意外かもしれないけど、これが現実

うちの職場でメインで動いているのは、COBOLとVBAの2つです。

私自身、入社する前から「事業会社の社内SEがモダンな言語をバリバリ使っている」というイメージはあまり持っていませんでした。どちらかというと、最新の技術を使っているのはWeb系の会社やSIerのほうだろうな、という感覚のほうが近かったです。なので「COBOLとVBAがメイン」と聞いても、そこまで違和感はありませんでした。

業務の中心は、COBOLで動く既存システムの保守と、VBAで作られた業務ツールの修正・追加です。

私自身、訓練校でJavaを学んでから今の職場に入ったので、最初にCOBOLのソースを見たときは正直かなり戸惑いました。Javaとは書き方の作法もだいぶ違います。独特の読みにくさや開発のしにくさもあって、最初の頃は思うように手が動かなかった記憶があります。今でこそ普通に読めるようになりましたが、慣れるまでには時間がかかった、というのが正直なところです。

ちなみに、職業訓練校でプログラミングを学んだ経験については別の記事に書いています。訓練校の内容が実務にどこまで通用するのか気になる方は、そちらも参考になるかもしれません。

C#やPythonは「個人的に使っている」レベルの話

残りのVB、C#、Pythonは、メインの2つに比べるとかなり扱いが違います。

VBはごく一部の人しか触りません。C#とPythonにいたっては、私が個人的に業務改善のためのちょっとしたツールを作るときに使っているくらいで、会社の業務として組織的に使っているわけではないです。

たとえば、繰り返し作業を自動化するためのツールを自作したり、既存システムのコードの中から特定の単語が含まれている箇所を洗い出すための調査用ツールを作ったり。そういう「自分の作業を楽にするためのもの」が中心です。

こうして並べてみると私の職場では、言語ごとに扱われ方がかなり違うのが分かると思います。これがすべての社内SEに当てはまるとは思いませんが、ひとつの参考として受け取ってもらえたら嬉しいです。

チーム全員がコードを書く。ただし、レベルも守備範囲もバラバラ

私の職場の情シス部門は、10名前後のチームです。そして、そのメンバー全員が、何かしらの言語を使えます。

ただし「全員が同じレベルで全部の言語を書ける」わけではありません。ここはかなり個人差があります。

体感的な分布はこんな感じです。

図解:表 / 言語ごとの社内での扱われ方一覧(COBOL=ほぼ全員、VBA=8割、VB=一部、C#・Python=筆者個人)

レベル感や守備範囲を補足するとこんな感じです。

COBOL：レベルの高低はあれど、基本的には全員が触れる言語
VBA：8割ほどの人が触れるが、簡単な修正までの人と、複雑なツールを一から作れる人で差が大きい
VB：必要に応じて一部の人が触る
C#・Python：私が個人的に業務改善ツールを作るのに使っているくらい

つまり「どの言語を、どの深さで書けるか」は人によって全然違います。COBOLしか書けない人もいれば、COBOLとVBAの両方を高いレベルで扱える人もいる、というのが実態です。

ちなみに、これだけ言語が分かれていると「未経験から入って大丈夫なのか」と思われるかもしれませんが、私の職場には入社時に未経験で配属される人もいます。最初は本を見ながら自分で勉強しつつ、分からないところは先輩に聞く。慣れてきたら業務に直接関係しない簡単なツールを作ってみて、そこから徐々に実務に移っていく、というのが基本の流れです。

未経験から入って、数年かけて書けるようになった人も、私の周りには実際にいます。「今コードが書けないから社内SEは無理」というわけでは、必ずしもないんだろうなと思っています。

体感としては、コードが書ける方が評価は有利だと感じる

ここからは私の主観なので、参考程度に読んでもらえたらと思います。

3年やってきた肌感として、コードが書ける人の方が社内の評価は高くなりやすい、と感じます。もちろんコーディング能力だけで評価が決まるわけではありません。それでも、書ける人とそうでない人を比べると、振られる仕事の幅が違ってくる印象があります。

たとえば、COBOLしか書けない人と、COBOLもVBAも書ける人がいたとします。後者のほうが、当然ながらこなせる業務の範囲は広くなります。VBAで作られたツールの修正依頼が来たとき、自分で対応できるかどうかで動き方も変わってきます。

仕事を振れる幅が広がれば、上の人の手助けにもなります。「あの人に頼めば大体なんとかなる」と思われるポジションは、評価面でも有利に働きやすい。これが私の実感です。

正直、書ける人と書けない人で差はついてしまうな…と感じます。

もちろん、業務知識や調整力、コミュニケーションといったコーディング以外の能力も、評価には大きく関わります。ただ、同じくらいの条件なら、書ける人のほうが一歩リードしやすい。少なくとも私の見ている範囲では、そんな印象です。

コーディング以外の部分、特にコミュニケーション力が社内SEの評価にどう関わるかは、社内SEにとってコミュニケーション力がなぜ重要なのかを書いた記事で詳しく触れています。コードの話と合わせて読むと、評価の全体像が見えてくると思います。

内製化が進む今、「何かひとつ書ける」は武器になると思う

最後に、社内SEを目指している方や、今のスキルで大丈夫か気にしている方へ。

最近、企業のシステム開発を内製化する動きが広がっていると言われます。実際に調査データも出ています。レバテックが2026年1月に発表した調査では、6割超の企業が外部委託から内製化にシフトしているという結果でした。PwCの調査でも同じ流れが見えます。DX成熟度が低いとされる企業群でも、企画から運用までを自社社員で実施している割合は、過去3年で13%→16%→21%と着実に伸びているとのことです。

コストやスピード、ノウハウの蓄積といった理由から、自社で書ける人を社内に持っておきたい、という方向に企業が動いている流れです。

そう考えると、どんな言語であれ、ひとつしっかり書けることは、それ自体が武器になりうると思います。COBOLでも、VBAでも、Pythonでも、何でも。「とりあえず一つ、業務に使えるレベルで書ける」というのは、それだけで選択肢が広がる材料になります。

ちなみに、「自分のコーディング力でやっていけるのか」という不安そのものについては、別の記事で「コードが書けると言える最低ラインってどのレベルか」を3年目の肌感で整理しています。個人のレベル感の話なので、今回の「職場の実態」と組み合わせて読んでもらえると、社内SEの仕事像が少し立体的に見えてくるかもしれません。