こんにちは。
先日、あるTwitterユーザさんから、
「プログラミングを勉強してIT業界に行こうと思ったけど、はっしーさんの言うとおり社畜になりそうで怖い」というご相談を受けた筆者です。
自分自身が社畜SEとしてアホほど働かされた経験から、いろいろ脅しのようなツイートをしていたので、笑
ちょーっと怖がらせすぎたかもしれません。反省。
確かに、IT業界は一歩道を間違えるとデスマーチという落とし穴が待ち受けています。とはいえ、筆者もプログラミングが好きですし、それに興味をもってくれた人を追い払うような真似はしたくありません。どうすれば、いわゆる「IT土方」にならずに働けるかについて考えたいと思います。
なおこのブログでは「IT土方」を「過剰な残業(月60時間以上)、休日出勤を強いられるIT技術者」と定義します。
ITゼネコンの一部になるな
日本のIT業界の特殊性を表すのによく使われるのが「ITゼネコン」という言葉です。
これを知らずにIT業界に就職すると、理想と現実のギャップに苦しむことになります。
IT業界のうち、システムインテグレータと呼ばれる業態は、この構造の一部になっていることが多いのです。この構造に組み込まれて働くと、不幸な働き方になる可能性が高いです。まずは 知らないと一生後悔するITゼネコンの構造:SE転職のすすめ さんから引用した以下の図をご覧ください。
一時期話題になった特許庁システムなどの大型基幹系システムは、まさにこの構造の中で開発された(未完成だけど)ものです。
ITゼネコンにおけるレイヤーと、その役割はおおかたこんな感じです。
大手ITベンダー
いわゆる「元請け」と言われる人々です。まずはここが発注元から仕事を取ってきます。この人達は、主に顧客との折衝やマネジメントを担当します。プログラミングを担当することはまずありません。
元請けはクライアントから最初にお金が流れ込むところなので、給料は抜群にいいです。また、コンプライアンスや福利厚生もしっかりしています。サービス残業を強いられるケースは稀でしょう。このレイヤーに入れればIT土方になる可能性は低いです。
ただし、前述のとおり、仕事内容は技術とはかけ離れた部分に限定されます。社員の人たちも、技術とかけ離れた仕事だけどそれでいい、と思っている人が多いということです。
下請け
さて、元請けが発注を受けたわけですが、元請けの社員だけではシステムをつくり上げることはできません。ということで、元請けは設計やプログラミングの仕事を下請けに発注します。一日パソコンに向かって、一心不乱にプログラミングするイメージに近い職場です。
ただし、自分の好きなようにプログラミングできるわけではありません。大抵の場合、元請けから指示されたフレームワーク、コーディング規約、設計などに従って行うことになります。そのフレームワークが洗練されたものであるとは限りません。全然イケてない可能性もあります。なんでオープンソースのあれやこれを使わないんだ?と疑問に思うかもしれませんが、、、そういうものなのです。
さらに、下請けは元請けより給与面で劣りますし、元請けより弱い立場のため、異常な短納期での仕事を強いられる可能性もあります。そうなると「IT土方」の仲間入りです。
プログラムに関わる仕事はできますが、それは趣味プログラミングとは全く異なる、不条理なものになると覚えておいてください。
孫請け、フリー
下請けが人手不足になったとき、さらに投入されるのが孫請け、またはフリーランスの人々です。
ここまでレイヤーが下になってしまうと、もう別の仕事探したほうがいいレベルです。給料は下請けよりもさらに下がりますし、元請けや下請けの仕事の遅れがダイレクトに影響してきます。
この映画をイメージしていただければ良いでしょう。多くは語りません。
ブラック会社に勤めてるんだが、もう俺は限界かもしれない [DVD]
- 出版社/メーカー: アミューズソフトエンタテインメント
- 発売日: 2010/04/23
- メディア: DVD
- クリック: 588回
- この商品を含むブログ (59件) を見る
ということで、技術的な仕事を"幸せに"したいのなら、絶対にITゼネコンの構造に入ってはいけません。
技術を軽視する会社で働くな
情報システムはプログラムの集合体。品質の良いプログラムを組むには、熟練の技術者が不可欠です。ですから、技術を軽視する会社で働いてはいけません。 かならず不幸な目に合います。
具体的には、次のような会社に注意しましょう。
求人広告の言語のスペルが間違っている
たとえば、「JAVAエンジニア募集!」「JAVASCRIPTエンジニア募集!」などと書かれている求人には応募してはいけません。JAVA は Java、JAVASCRIPT は JavaScript です。
プログラマはこういった表記の間違いに敏感です。それが訂正されず求人広告に載ってしまっているのは、人事が技術を軽んじている証拠です。「だれでもいいから人手がほしい」という態度が透けて見えます。
ちなみに筆者は退職間際、社内のプロジェクト説明資料に堂々と「JAVA」「JAVASCRIPT」と書いてあるのを見て、「こらあかんわ」とげんなりした記憶があります、笑
開発用マシンのスペックが低い
社員の方に、開発用マシンのスペックが足りているか確認してみましょう。
「コンパイルのたびにHDDがガリガリ音立ててさぁ……すっげぇ時間かかって大変なんだよね」
なんて返事が返ってきたら、入社しないほうが無難でしょう。
開発者にとってのPCは、料理人にとっての包丁みたいなものです。十分なスペックのPCがあってこそ、エンジニアはストレスを感じることなく、開発に集中できます。それを与えないということは、刃こぼれしまくっている包丁で料理しろと言ってるようなもの。それでいいプロダクトが作れるわけがありません。
マシンにお金をかけられない会社は、その程度のものだと考えましょう。
金融系は避けたほうが無難
これはかなり筆者の主観ですが、金融を扱う部門は避けたほうがいいように思います。
日本の金融システムで主に使われている言語は COBOL です。この COBOL というのは、業界で古くから使われている最古参の言語の一つ。金融のエンジニアはほぼ間違いなくこれを使うことを求められます。たとえ今の最先端がほかの言語であっても。
というのも、金融システムの変更には多大なリスクを伴うからです。なにせ日本中のお金を扱うシステム。計算ミスが起きたら大変なことになります。そのため、「COBOL で今までやってきたけど、Java で全部書きかえよう」なんてことができないのです。せっかく今正常に動いている部分をまるっと変更するなんてリスクが大きすぎる。ですから、COBOL のコードを継ぎ足し継ぎ足しで開発を続けているのですね。
もしあなたが、常に最新の技術を追いかけるようなタイプであれば、金融系は合いません。IT業界に行きたいと思う人は、きっとそれなりに好奇心がある方でしょう。COBOL がその好奇心を満たしてくれるかどうかは……疑問だと思います。*2
まとめ
……と、IT土方にならない方法を考えてみましたが、残念ながら筆者自身、IT業界で幸せに働いた経験がありません、汗
ですが、筆者の知る「IT業界で、技術を活かして、幸せに働いている」方々は、ITゼネコンにはいないし、金融系エンジニアでもないし、なにより、技術を愛しています。
筆者が再就職する際にも、このあたりの条件は重視するつもりです。少しでもIT業界を目指す皆さんの参考になれば幸いと願って、今日は筆を置きます。ではまた。
- 作者: デイル・ドーテン
- 出版社/メーカー: きこ書房
- 発売日: 2015/01/20
- メディア: Kindle版
- この商品を含むブログを見る
*1:知らないと一生後悔するITゼネコンの構造:SE転職のすすめ
*2:反論は認めます。