もうCOBOLプロジェクトは辞めた方がいい?あなたのSIerがヤバいかどうかを見抜く方法を教えます

SIerはクソです。

 

仕事が退屈で、やりがいがなく、社員の目が死んでいて、責任の押し付け合いばかりで仕事が進みます。

 

が。

 

クソはクソでも「トグロのようなクソSIer」と、「赤ちゃんのウンチ程度のクソSIer」があって、それはチーム次第です。 

 

あなたがどのチームに配属されるかは運ゲーです(この運ゲー仕様もクソです)

 

この記事ではあなたのチームがどれくらいクソかを見抜くための目安を教えます。

 

クソ度が高かったら転職活動を始めましょう。

 

COBOLを使ったシステムである

SIerのヤバさを見抜くための最もわかりやすい指標が「COBOL」です。

配属された先のシステムがCOBOLで動いていたら転職活動を始めましょう。

 

COBOLがここ20年で成長したウェブサービスで全く使われていないため、COBOLが使えるようになってもエンジニアとしての市場価値が全く上がらない...だけはありません。

 

他にもデメリットがたくさんあります。

 

まず、COBOLの現場は何もかもが古臭いです。

 

プロジェクト管理手法、プロジェクトの進め方、ドキュメント、非合理な風習をかき集めたレビュー会議...etc

 

何もかもが救いようがなく、そして腐りきっています。

 

腐っているのはプロジェクトだけではありません。

人間もダメになっています。

 

COBOLで作られたプロジェクトの中には必ず、「重鎮」と呼ばれる人が既得権として居座っています。

 

ドキュメントが古くなっていて、口伝で業務知識を伝えるわけですから、「そのシステムに詳しい人」が重鎮として残り続けるわけですね。

 

重鎮はやがて必ず既得権となります。

 

ずっと同じプロジェクトにいて、そのシステムにやたらと詳しくなった人は代えが利かない存在になるからです。

 

後から入った人がキャッチアップできるようなドキュメントを作らず、これまで一切技術的負債を解消してこなかったことを悪びれもせず、「長くプロジェクトに居座っているから」という理由だけで増長します。

 

新しくチームに入ってきた人に対して、「こんなこともわからないの?」と偉そうになってくるのです。

 

大学生が小学3年生に向かって「お前ェ!微分積分も知らないのかww 今まで何やってんだww」と馬鹿にするような現象が普通に起こっています。

 

重鎮化した老害は無駄に偉そうで、「人を詰める」ことに喜びを感じます。

 

「自分の王国」を作って他人を支配した気になっているのです。

支配欲は遺伝子に組み込まれた男の本能といってもいいでしょう。

 

誰にも批判されない環境だと人間は簡単に腐ってしまいます。

 

COBOLプロジェクトにはそういう腐った人間がいる確率が非常に高いです。

 

COBOLプロジェクトに入っても他の場所で活かせる学びはありません。

 

プロジェクトの業務を学ぶ方法も「詳しい人に教えてもらう」しかなく、とんでもなく非効率です。

 

つまり完全に時間の無駄です。

 

古いシステムは残り続けます。

 

壊れそうな橋を守り続ける人が必要なように、COBOLのシステムを守り続ける人の需要もしばらくは消えないでしょう。

 

ですが、SIerの社員の仕事はあくまでも「管理」です。

 

COBOLで作られたシステムは基本的に、中身がわかりません。

 

現代のプログラミング言語とはおよそ異なった構文でただでさえ意味不明なのに、それぞれのコードがスパゲティになっているからです。

 

誰かが残したExcelから頑張って中身を推測するのですが、実際のソースコードは読めないのでいつまでも自信が持てません。

 

中身がわからないものをおっかなびっくりと「管理」するのは地獄です。

 

どうやって動いているかわからないものをどう管理するっていうんですか。

 

仕方なく、誰かから聞いた情報をかき集めて、聞いた情報をまとめて、「ノウハウ」として自分の中に残します。

 

体系的な情報はなく、複数人の「詳しい人」から教えてもらったことをノートにメモし、誰にも伝えず、自分だけのノウハウになっていきます。

 

COBOL系の部署は仕事の進め方が古く、動きが鈍く、何の意味があるのかよくわからない資料作りばかりをやらされます。

 

仕事のための仕事を作っていて、穴を掘って埋めることで給料をもらっているような仕事です。

 

馬鹿な仕事で貴重な人生を無駄にしてはいけません。

 

いくら年収が高いSIerに入社したとしても、時間のほうが大切です。

 

いいですか。

 

COBOLのプロジェクトに配属されたらすぐに転職活動を始めましょう。

 

百害あって一利もないです。

本当です。

 

20年以上前に作られたシステムである

先のCOBOLに通じたものがありますが、20年以上前に作られたシステムの「保守担当」もクソです。

 

COBOLでなければ、古いJavaで動いているシステムでしょう。

サーブレットやJSPが使われているかもしれません。

 

ファイル名がDEV_12345.javaみたいな、パット見て何をしているのかよくわからない名前になっていて、ファイルの先頭にコメントで変更履歴が書かれています。

 

バージョン管理システムはどうした...?

 

と、ツッコみたくなるかもしれませんが、古いシステムの部署に「Git」という単語を知っている人は一人もいません。

 

また、コメントでのバージョン管理の他に、Excelファイルには「変更履歴」みたいのもあります。

 

どこまでも人工的に、気合と根性でバージョンを管理していますが、その「変更履歴」が役に立ったことは一度もありません。

 

だって、変更した人はいないんだもん。

 

古いシステムのアンチパターンの塊のようなソースコードを読むと、頭が悪くなります。

 

「SIerの巨大なシステムを稼働させている素晴らしいアーキテクチャを学ぶことができるのだ」

 

とドヤる人もいるかもしれませんが、SIerの巨大システムはしょうもないアンチパターンの塊で、学んだらむしろ頭が腐ります。

 

マイナスに成長します。

 

簡単なことをとても難しくやろうとして、誰にもわけがわからないゴミがゾンビのように動き続けるのです。

 

まるで腐った死体のようです。

 

「2025年の崖」がなんとか言ってもますが、お前たちはもう崖の下にいる。

なぜ気付かない...?

 

20年前のシステムのおもりをする部署に配属されたら、すぐに転職活動を始めましょう。

 

異動せずに10年以上同じシステムを開発している人がチームに数人いる

同じ部署にずっといる人、考え方が古いです。

凝り固まっています。

 

流れない水が腐り濁っていくように、人間も同じところにずっといるとダメになります。

 

異動もせず、転職者も受け入れないので、自分たちのやり方が古くなっていることに気付きません。

 

ぬるいお湯につかった蛙が茹でられていることに気付かないように、中にいる人も変化に気付かず、世間との隔絶に気付けません。

 

同じシステムを担当するのは3年が限度でしょう。

3年もすると、学べることもなくなってきます。

 

新しいことを学び続けましょう。

そっちの方が楽しいですよ。

 

チームの平均業務終了時間が21時以降

本当なら「20時以降でもクソ」と言いたかったのですが、SIerの場合は20時にしてしまうとほぼ全てのチームに当てはまってしまうので、21時としました。

 

残業が常態化しているチームはクソです。

 

残業が当たり前になっているチームでは、残業時間で「部下の頑張り」を評価する傾向が強く、また言葉に出さずとも残業のプレッシャーをかけようとしてきます。

 

また普通の勤務時間が終了する20時以降に大事な話を進める人も多く、そういうチームにいると不健康です。

 

仕事は成果で評価される場所にいきましょう。

 

会議が多くて長い

 SIer全部に当てはまりますね。

会議をしても何も生まれないことの方が多いですし、自分の成長にはつながりません。

 

ダラダラとした会議は眠くて、不毛で、面倒で、精神と体力を消耗します。 

 

自分の仕事時間を確保できる職場で働きましょう。

SIerから出たら、会議は30分がデフォルトになります。

 

無駄な会議もほとんど入らなくなります。

本当です。

 

SIerは社員が暇なので、馬鹿みたいに会議を詰め込もうとするんですね。

会議しないと、自分でできることが何もないからです。

 

チーム全体で「詰める文化」を放置している

世の中には嬉しそうに部下を詰めて、自分の優位性を確認したがるアホがいます。

誰かを「詰める」ことが仕事だと思っていて、何かと細かく批判して、指摘して、意味のない作業を増やそうとする人間がいます。

 

こういう人間が上司になったら即・異動願を出しましょう。

 

レビューばかりで仕事が進まない

何をするにも「有識者にレビューしろ」「レビューの承認を得ろ」「Aさんにレビューしてもらった後、Bさんにレビューして、その後にPMのレビューだ」と、いちいちレビューに階層をつけて、大量のレビューをさせて仕事を進めようとする人がいます。

 

資料にいちいちケチをつけて、資料に何度もケチをつけることで「品質を高めている」と本気で思っているのです。

 

私の以前の職場では「品質」という言葉がよく使われていましたが、彼らのいう「品質」に納得したことはありませんでした。

 

レビューをたくさんして「品質」を高める...というのはわかるのですが、なんでしょう。

 

目的と手段がごちゃごちゃになっているというか、とにかくたくさんレビューをして、一定数溜まった「指摘件数」をクリアしたら品質がいい、みたいな思考回路になっていて、それを一つ一つの資料に対してやるもんだから、とにかく仕事が進まない状態になっていました。

 

資料を作ってあーでもないこーでもないと議論して、肝心のソフトウェア開発は下請けに丸投げして、誰も中身がわからない状態です。

 

品質ってなんだろう?

 

若手に裁量がなく、PMが独裁者タイプ

SIerでは若手に裁量がありません。

オープンワークとかを見ると、「若手から大きな仕事を任せてもらえる」とか書いている人がたまにいますが、勘違いです。

 

PMが考えたプロジェクト計画の中で、人形のように役割を与えられ、その役割を全うするための「ソルジャー」です。

 

立場上では若手から「協力会社のメンバーをマネジメントする」という役割になります。

 

が、別に協力会社をマネジメントするのは裁量が大きいわけでもなんでもありません。

 

「裁量が大きい」とは、自分で考えて、自分で判断して、自分で提案し、自分でプロジェクトを作り、計画し、プロジェクトを動かしていける状態を指します。

 

SIerにはそんな環境はありません。

 

プロジェクトマネージャーの計画通りに仕事を進めることが求められるからです。

 

だから楽しくないのです。

 

全てを自分の思い通りにして、全てを報告させ、全てにおいて自主性を許さない、独裁者タイプのプロジェクトマネージャーがいます。

 

独裁者タイプのPMは社員や協力会社の人を鞭で叩いて無限残業させて無理やり納期に間に合わせるので、社内では優秀とされる人が多いのですが、基本的に頭が悪いです。

 

何でも根性で乗り切ろうとして、プロジェクト計画が遅延するたびに「根性」で乗り切ろうとします。

 

自分の計画通りに進まないと気がすまないから、スケジュールの遅れは許しません。

 

そういう人間と働くのは地獄です。

 

退屈で、ストレスがたまり、PMに承認されなければ何も仕事が進みません。

かといってPMは一日中会議が入っているので、承認されるタイミングはなかなかきません。

 

ヤバイやつの下に入ったら、こっそり転職活動を始めるといいですよ。

良い会社に転職したら、ストレスはなくなります。

 

毎日毎日ストレスを感じて仕事をするべきではありません。

 

嫌な環境から「逃げる」のではなく、良い環境を主体的に「選ぶ」ようにしましょう。

 

限られた時間を有効に使いましょう。