IT業界の仕事

 ※以下の文章は2000年に書いたものなので、現状とは異なる場合があります。

 「あなたはどんな仕事をしているんですか?」と聞かれて、「パソコンスクールのインストラクター」と言うと、なんとなくイメージできると思います。でも「プログラマー」「SE」と言われると、なんとなくわかるけど、実際には何をやっているかわからない、という方が多いかも。そんな方のために、プログラマーとかコンピュータ業界とか今流行りのIT革命などについて、ミニ講座を開いていきたいと思います。

 まずは「プログラマーって何?」ということから。プログラマーというのは、プログラミングする人のことです。プログラミングというのは、コンピュータを動かすために、コンピュータ向けの言葉を記入してあげることです。例えばHPで「ここに絵を表示させたいな〜」と思ったら、「<img src="aaa.jpg">」と入力します。エクセルなどで「このボタンを押したら〜をさせたい」と思ったら、「command1_click()」とか入力します。「それぐらいならやったことあるよ!」という方もいらっしゃると思いますが、HPを作る時のHTML入力も、エクセルやアクセスのVBAも、全部プログラミングです。

 プログラミングで使う言語をプログラミング言語と言って、HPだったらHTML言語、エクセルやアクセスのVBAだったらVBA言語、銀行のシステムだったらPL/I、金融系とか昔のシステムだったらCOBOL、という風に、使用用途・規模によって使う言語が違ってきます。

 また、どのプログラミング言語を使うかで、汎用機系・オープン系・Web開発系、と3つに分かれています。どの言語を使えるかで「○○系プログラマー」と呼ばれたりもします。

汎用機系

 まだパソコンがなかった時代、コンピュータといえばかなり大きなものでした。1946年に開発された世界初のコンピュータ「エニアック」は、なんと30トンもあったし、一部屋まるごと使っていたんですよ!でも、そんなの面倒くさいということで、もうちょっと小さなコンピュータが開発され始めました。

 それと同時に、最初のプログラミング言語は0と1の組合せで記述する機械語だったので、「11010001」とか書いてあっても普通の人はさっぱりわかりませんでした。たぶん作った本人もマニュアルを見ながらじゃないとわからない。そんなの面倒くさいということで、IBMの人が頑張ってFORTRANというプログラミング言語を作ったりもしました。おかげで、今まで10人しかわからなかったものが、50人がわかるようになりました。それでもまだわからないというので、1949年に開発されたCOBOLを始め、BASICとかPL/IとかCとかが開発されてきました。これらの言語はいろいろなシステムで使えるので、汎用機系と呼ばれています。

オープン系

 今は有名になったビル・ゲイツとポール・アレンがBASIC言語をパソコン用に変換して、マイクロソフト社を設立したのが1975年。MS-DOSを発表し、1993年頃やっとWindows3.1を発表しました。MS-DOSと違うのは、GUI(Graphi-cal User Interface)という点です。何それ?という方は、画面左下の「スタート」−「プログラム」−「MS-DOSプロンプト」というのをクリックしてみてください。真っ黒な画面に「C:\WINDOWS>_ 」というのが出てきたと思います。1993年頃までのパソコン(NECのPC9800シリーズとか)は、電源を入れてチェックが終わると、いきなりこんな画面になりました。「どんなファイルがあるかな?」という時に、今はエクスプローラーで簡単に見られますが、MS-DOSだと「C:\WINDOWS>_ 」のあとに「dir」と入力します。すると、ずらーっとファイル名が出てきましたよね?見終わったら、右上の閉じるボタンを押してください。「exit」と入力しても終了しますよ。

 それに比べて、今使っているWindowsはカラフルだし、マウスは使えるし、なかなか便利ですよね。それがGUIです。ユーザー(パソコンを使う人)が、目で見てわかりやすい画面、ということです。でも、1976年にできたアップル社では、早々とGUIのマッキントッシュを発表していたのでした。

 汎用機の言語はUNIXとかMVSなどの専門のOSが必要だったのですが、Windowsが広まるにつれ、Windows上で動くプログラム言語が開発されました。それがVB(VisualBasic)とかVC(Visual C)とか、エクセル・アクセスのVBAです。汎用機の言語は、MS-DOSみたいに真っ黒な画面に向かって、ひたすら入力していくものでしたが、VBやVCはマウスだけで簡単に画面が作れるし、言語を入力してもコメント文は勝手に緑色になってくれるなど、かなりプログラミングしやすくなりました。Windows上でプログラミングできるということは、専門のOSが入っている端末がなくても大丈夫ということで、汎用機系(技術者だけの閉じた世界)に対して、オープン系とかパソコン系と呼ばれています。

Web開発系

 1997年頃から爆発的に流行し始めたのが、インターネット。WWW(World Wide Web)とかWebとも呼ばれています。全人口的にはまだ25%ぐらいしかネットをやっていないようですが、企業ではインターネットを使った事業が盛んになってきています。インターネットバンキングは有名ですよね。インターネットをする時に使うのがブラウザ。Internet Explorer(IE)とかNetscape Navigater(NN)とか、いつも使っているやつです。HPを作る時に、HTMLとかJAVAとかCGIを使います。これらの言語を使って開発するのが、Web開発系です。

 ということで、プログラマーのお仕事は、汎用機系・オープン系・Web開発系、と分かれています。最近の主流はWeb開発で、汎用機系はすたれてきています。COBOLでいろいろ帳票を出して確認していたのが、VBで作った画面で簡単に確認できるようになりました。またインターネットで、全国各地から確認できるようにもなりました。でも、金融など昔からある会社は、当時COBOLやPL/Iで大きなシステムを作ってしまったので、それなりにプログラマーの需要はあるみたいです。私はCOBOLしか使えない汎用機系プログラマーですが、そのうちVBとかJAVAの仕事もできればいいな〜と思っています。

 ※2003追記。2001年にオープン系(VB)を経て、2002年にWeb系(ASP.NET)をやることができました!

 ※09/02追記。2000年の時点では4人に1人しか使っていなかったインターネットも、今はほとんどの人が使えるようになりました。金融システムにおいても、汎用機を減らしてC/SかWebへ移行してきているようです。プログラマーにおいてはWeb開発ができて当たり前の時代になったのでしょう。

プログラマー&SEが働く場所

 使える言語によってプログラマーには3種類あると書きましたが、働く場所によっても分類することができます。大きく分けると、メーカー系・ユーザー系・独立系の3種類です。

メーカー系

 メーカーというのは、NEC・富士通・IBMなど。ただ、例えば富士通ではSE(システムエンジニア)を採用していて、プログラマーとしては採用していません。メーカーにはNECソフトウェアなど、いろいろな子会社があります。

 メーカー本体でいろいろ設計を行い、実際のプログラミングは子会社のプログラマーがやっているようです。文系で富士通に入社した友人は、第二種も持ってないし、プログラミング言語も知らないけど、設計をやっています。

ユーザー系

 銀行・生保・損保・商社など、あらゆる会社のシステム部(電算部)など。会社でNEC・富士通などのシステムやパソコンを使っているので、ユーザーと呼ばれています。大企業だと○○情報システム会社などシステム専門の子会社があり、システム部の仕事をアウトソーシング(全面委託)しているところもあります。親会社も子会社も、どちらもSE職として採用されます。

 ただし親会社の場合は、理系(情報処理関係)の大学・専門学校卒業者のみ。子会社の場合は、文系でもOKです。何故かというと、システム会社だったら研修が充実しているけど、親会社のシステム部は研修する余裕がないから。私は金融系システム会社にいましたが、研修には親会社の新人SEも来ていたし、同じチームで仕事をしていました。

 メーカー系と違って、SE職と言っても最初の5年ぐらいはプログラマーをやります。プログラミングに慣れてきて、設計もできるようになって初めてSEという役職につけます。

 さて、会社では色々な部署で様々なデータを扱っています。これらはシステム部(電算部)、もしくはシステム会社で処理しています。システム会社の場合は、システム開発部と電算運用部に分かれていて、前者はプログラムの開発を、後者はプログラムの実行を行います。金融系などの場合はプログラムの処理を行うのは夜中なので、派遣会社等から来ているオペレータさんが「この処理が終わったら、次はこの処理」と実行してくれます。その間オンライン業務は使えません。だから、インターネットバンキングで夕方以降に振り込むと「翌営業日の振込み」となる訳です。

 中小企業の場合はそれほどデータの量が多くないので、NTTデータなどに委託するか、プログラムの開発・処理から印刷・仕分けまで全部自分たちでやります。全国の支店の担当者が一生懸命入力したデータを受信し、月次プログラムの処理。うまく処理できたら、処理後のデータを使って印刷。普通は連続用紙という15インチ×11インチで、両端に穴があいている紙を使います。ラインプリンターという大きなプリンターを使いますが、紙が無くなる度にダンボールごと設置するので、結構力仕事。おまけにいろいろな種類の紙を使うので、その度にダンボールをひっかえとっかえします。全部印刷して、山のように積み上げたところで、支店ごとの仕分け&発送。

 ※09/02追記。今ではワードなどで印刷することも多いかもしれません。でも、現在自分がもらっている給与明細などが両端に穴が開いていたら紙だったら、上記のように誰かが苦労してプログラムを作り、プログラムを実行し、用紙に印刷して、仕分けをし、無事に自分の手元に届いたということなのです。数字が枠内に収まるように何度もテストを繰り返したり、色々と大変なのですよ〜。

独立系

 システム開発専門の会社のことで、CSKなど。主要株主が個人名であれば独立系、聞いたことのある会社名ならユーザー系。ベンチャー系と呼ばれる中小会社がたくさんあるようで、システム関係の会社の中で一番数が多いです。

 たいていメーカー系・ユーザー系の会社に派遣されることが多く、たまに仕事全体をアウトソーシングしたり、自社パッケージを作ったりと、自分の会社で開発を行うこともあるようです。ちなみに、普通の派遣を一般派遣、会社に正社員として入社して外部に派遣されることを特定派遣と言うようです。

 例えば銀行システム開発では、以下のように派遣されます。孫受け・ひ孫受け、みたいな感じですね。

 派遣会社→小ソフト会社(独立系)→中ソフト会社(独立系)→銀行のシステム会社/銀行システム部(ユーザー系)

 正社員として勤めていたユーザー系会社でも、いろいろな協力会社さんが派遣されていました。あるチームの一員として派遣されてシステム会社の社員と一緒に仕事をすることもあれば、○○ソフト会社で一つのチームとして派遣されてプロジェクトのある部分をどーんを任されることもあります。しかし大抵は、協力会社さんには簡単な部分しかやってもらいません。裏を返せば、協力会社として派遣されると簡単な仕事しかやらせてもらえません。同じ入社2年目でも、仕事量や責任の重さが全然違うように感じました。

 ※09/02追記。後に行った会社で、協力会社の人でも、正社員より仕事ができれば色々と任せてもらえることを実感しました。滅多にない、ラッキーなことだったと思います。

ユーザー系と独立系の長所・短所

 私が働いていた会社についての感想です。一般的には外に派遣される中小独立系で働く方が多く、その方々が言う「一般論」とは異なる場合があります。

大手ユーザー系(社内開発)

長所
  • 教育がしっかりしている。
  • 昔からあるシステムなので、フローチャートやマニュアルも完備されている。
  • 基本設計をした先輩や、システムを使うユーザーと直接話ができるので、後戻りが少ない。
  • プログラマー→5年目からSEと、段階的に成長できる。
  • その業界のスペシャリストを目指すことが可能。
  • 開発の適性がなければ、電算運用やサポートなどの部署に配置転換可能。
  • メーカーに頼らずに済む。
  • 次の仕事の有無・場所を心配しなくていい。
短所
  • 一つの業務知識しか習得できない(異動願いが通ることは少ない)。
  • 一つの言語しか習得できない(最近の新人は、研修でいろいろ学べるらしい)。
  • 1年目でも協力会社(外注)さんの面倒を見なければいけない。

中小ユーザー系(社内開発)

長所
  • 社内のシステムが全てわかる。
短所
  • 社内教育がほとんどない。
  • 一つの言語しか習得できない。
  • 社内でしか通用しない業務知識しか習得できない。
  • 社内にSEが数人だけということも多く、甘やかされたSEもいる。
  • マニュアルなどが完備されていない。
  • きちんと教育を受けたSEがいないので、システムがミスだらけ。

中小ユーザー系(システム部以外)

長所
  • 担当課(現場)なので、業務に詳しくなれる。
短所
  • SEがいない。システムに詳しい人がいない。
  • マニュアル作成からテストまで、全て自分でやらなければならない。

大手独立系(自社開発)

長所
  • メーカーを通さず、エンドユーザーから直接仕事を受注できる。
  • 基本設計をした先輩や、システムを使うユーザーと直接話ができるので、後戻りが少ない。(ユーザー系と一緒)
  • プログラマー→5年目からSEと、段階的に成長できる。(ユーザー系と一緒)
  • その業界のスペシャリストを目指すことが可能。(ユーザー系と一緒)
  • ユーザーにより要望が異なるので、色々な言語を習得できる。
  • 次の仕事の場所を心配しなくていい。
短所
  • 営業さんは仕事を獲得するのに大変そう。
  • 協力会社として派遣されている場合、契約期限がある。
  • 協力会社として派遣されている場合、長くいると、新しく来た他の協力会社の面倒を見なければいけない。
  • ユーザー系と違い、ユーザーは神様なので文句は言えないし、納期は遅らせられない。

中小独立系

長所
  • 色々な業務システムに携わることができる。
  • 色々な言語を取得できる。
  • 人が足りないと、1年目から設計に携わることができる。
  • 色々な会社を見て回れる。メーカーに出向できる。
短所
  • ユーザー系に比べて給料が安い。
  • 営業が仕事を取ってこれないと、ボーナスも低い。
  • 教育期間が短い。
  • メーカー→メーカー子会社→中小独立系、という場合、質問の返事が遅いなど、やりとりが面倒。
  • ユーザー子会社→メーカー子会社→独立系→中小独立系という場合、独立系のSEやプログラマーが優秀な人ではないと、後戻りが多発。
  • 仕事によっては、メーカーやユーザー先で働くので、半年定期が買えない。
  • 外で働くことが多いので、自分の席がない。
  • ある日突然倒産する!!

インストラクターが働く場所

 大きく分けると、個人向けか企業向けか、となりますが、派遣の仕事は企業内インストラクターの場合が多いようです。最近は学校や市民センターでのIT講習会の依頼もあるようです。

 システム会社によってはインストラクターの部署があり、ユーザー先でOA講習をしたり、私たちが作ったシステム導入時の研修を行ったりしていました。

パソコンスクール

長所
  • 常に最新の技術を覚えられる環境がある。
  • パソコン関係のテストが無料で受けられる。
短所
  • マンツーマンの場合、生徒によりかなり気苦労する。
  • 安価が売りのスクールの場合、給料も安く、専門学校でも働く人もいた。

プログラマーとSEとインストラクターについて

その1(00/10/24)

 SEというのはシステムエンジニアの略で、プログラマーの上司です。上記に書いたとおり、メーカー系とユーザー系ではSEになるプロセスが異なるようです。どちらにしても、できるSEが上司だと、できる(わかりやすく効率的なプログラムを作成できる)プログラマーが育ちます。

 できるプログラマーとは、例えば子供(ユーザー)が「カレーを作って!」と言い出した時に、ちゃんと作れるかどうか。じゃがいもとにんじんをまるごと入れても、一応カレーだけど食べにくい。じゃがいもは1/6・にんじんは1/10に切って入れてあげれば、子供も食べやすい。さらに「ゆで玉子ものせる?」と提案できれば、子供も大喜び。プログラムもこれと一緒で、作る人によってきれいなものになったり、手をつけたくないものになったりします。

 できるSEとは、例えば旦那(プログラマー)にカレーの作り方を教えられるかどうか。「じゃがいもは1/6に切って〜」というのは普通のSE。最初に「お肉を解凍している間に、じゃがいも・にんじん・玉ねぎを切ってね」と概略を言ってくれるともっといい。「材料?手順?そんなの、適当〜」というSEは、自分でできるプログラマーだったらその方が自分流にできてラクだけど、そうでないと作れずに困ってしまう。子供も「カレー、まだー?」と困ってしまう。

 子供(ユーザー)にとっては、おいしくて安ければいいのです。システムも、安全・確実・効率的で料金もそれなりのものだったら、誰が作ってもいいのです。でも、実際にプログラマーとして働く場合は、プログラミング技能があって、かつ業務知識も知っているSEの下の方が、かなり働きやすいのは確かです。なんでも質問できるので、いろいろ吸収できるからです。

その2(2002/05/16)

 業界歴5年なのでまだまだプログラマー気分でいたのに、業務を知っているから、と設計書を作るはめになりました。基本設計〜外部設計ができるのがSEだと思っているので、これでSEの仲間入りです。私も周りも初めてのWeb開発なので不安ですが……。

 本や雑誌で勉強はするものの、実際にプログラミングしてみる時間がなくて、設計書作成に追われている。設計書を書きつつも、実際の動きがわからないので、とりあえず適当にプログラミングしてみる。プログラマーさんみたいに、最初からじっくり時間をかけてプログラミングしていないから、どうもうまくいかない。

 プログラミングの仕方を知らないSEは設計なんかするな〜!と、プログラマーだった頃に散々思ったから、プログラミングの仕方を理解した上で設計したいけど、現実はそうもいかないものです。

 設計書作成と同時に、他の方にプログラミングを始めてもらっていますが、その方は「設計の仕方は知らない、VB.NETの作り方は知っている、業務知識は少し」。上司は「設計の仕方は完璧、VB.NETの作り方は50%、業務知識は70%ぐらい」。私は「設計の仕方は50%、VB.NETの作り方は20%、業務知識は95%」。

 そんなわけで「VB.NETでこういう風に作ってもらう」という設計書を書いているわけですが、どちらも中途半端で、上司に実際どうなるかと聞いても中途半端で、プログラマーさんに聞くこともできない。2人が業務の流れについて話しているのを、プログラマーさんが聞いてなんとなく作ってくれて、そのプログラムを見て、また業務の流れを考える。

 設計書を作るSEに必要なのは、プログラミング技能が60%、業務知識が80%ぐらいだと思った、今日この頃。

その3(2002/06/07)

 最近、設計書を作りつつ、協力会社さんにも設計書を作ってもらっています(私も協力会社の立場のはずなのだけど?)。業界経験10年目の方だけど、歳は近いので仕事を頼みやすいのが幸いです。IT業界は高卒・専門卒・大卒・院卒と様々な方がいるので、業界経験1年目の30歳もいれば、業界経験10年目の30歳もいるわけです。中途採用で45歳の新人もいましたね。

 上司は高卒なので、年上の部下に仕事は頼みにくかった、なんて言っていました。確かに私も40歳の新人にはできれば教えたくない。プライドを傷つけないように教えなきゃいけないし、若い人の方が覚えが早いし。そうじゃなくても、私よりも業界経験が長いのに、プログラミングや設計の能力は私よりも下という人が極たまにいるので、なかなか難しいです。このあたりのことがあって、未経験でプログラマーになるなら25歳まで、プログラマー定年35歳(35歳=業界経験10年以上ならSEになっているべき)なんて言われているのでしょうね。

 協力会社として派遣されると、設計はさせずにPG設計&製造&テストのみということが多いから、外部設計&内部設計&DB設計、そして何故かマニュアル作成&職員研修にまで携われたのはとても有難いと思っています。