『SIerはヤバイとかやめとけとか、脱出した方が良いと言っている人の勘違い』という記事を読んだ。
要約するとこんな感じ。
- SIerはサラリーマンである。エンジニアではない
- ウェブ系の人がSIerを批判している。自社開発とSIerは違う
何が言いたいのかよくわからない駄文で、やっぱりSIerの中の人はアホなのかなと思ってしまったが、『SIerは何が本当にやばいのか』という記事には割とまともなことが書かれている。
- SIerの中の人はITに詳しくない
- サラリーマンになりきれない「エンジニア」がSIerに入社して絶望している
- チェックリストが多く、そして一度増えたチェックリストは減らせない
- マニュアル文化で、新しいものは何でも古いものとの比較をして、使う前にマニュアルを作成し、上長を説得させなければならない
SIerのマニュアル文化、チェックリスト文化は事実で、これらの作業はクソ面倒くさい。
何をするにもまずは「ドキュメント」にして「説明」しなければならない。
「ドキュメント作り」と「説明」に一ヶ月の半分以上を費やしている人も多く、SIerのヤバさの本質の一つはここにある。
リスク忌避の承認文化
SIerではミスが許されない。
障害を起こしたらお客さんに謝罪にいかなければならない。
謝罪のためには「経過報告書」のようなものを丁寧に書いて、各所に報告する必要がある。
障害を起こしたらその障害の原因や対策、期限を偉い人に説明して、承認をもらわなければならない。
この説明にものすごく時間がかかるし、一度問題が解決してからも延々と説明や報告を続けることになる。
1件の障害だったらいいのだが、こういう障害＆報告は捌ける前に積み重なっていくのだ。
当然、普段の業務を圧迫するし、ストレスも大きくなる。
障害の報告など誰もやりたくない。
誰も幸せにならない。
問題を起こしたら徹底的に詰める文化がある。
結果、責任を分散するために、大量のレビューや承認をもらうことになる。
当然、レビューには「品質を高める」という意図もあるが、レビュー対象となるのはテストコードやソースコードではない。
「報告書」なのだ。
「レビューはしたのか？」
が障害が起こったときに聞かれるお決まりの文句だ。
問題に向き合うよりも、「レビューしたかどうか」に焦点を当てる。
「問題解決」に責任を持たない偉そうな人たちを納得させるために多大なる工数を浪費している。
椅子にふんぞり返って
「レビューしたのか？」
などとほざくジジイは何の役にも立たない。
「仮に」だが、障害の報告をしたときに
「障害が起こったのか！？
どれ、見せてみろ。
このロジックはこう書けばいいんだよ」
などと技術的な問題を解決する方向に動くおっさんがいたとしたら、私のSIerの印象はずいぶん違っていたに違いない。
100人を超える偉そうな人に会ってきたが、技術的な観点で力を発揮したおっさんは一人もいない。
誰もが「ただ報告させるだけ」で、問題解決の役に立った人間はただの一人もいなかった。
こんな連中の承認を得るために、半年以上もかけて「プロジェクト計画書」を作ったり、一ヶ月かけて「結果報告書」を作ったりしているのだ。
恐ろしいほどの生産性の低さである。
伝言ゲームによる生産性低下
SIerのやばさの本質は「伝言ゲーム」である。
関係者がとにかく多く、そして色々な作業を分担している。
多重下請け構造がやり玉に上げられることもあるが、作業を「上流」や「下流」に分けて細かく分担した結果、作業内容を共有するために膨大な資料が必要になる。
上流工程を担当するSIのプロパー社員は、実際のソースコードがどう動いているのかがわからない。
とにかく下流工程を担当する協力会社に作業を投げ、その作業の結果をSIerの偉い人に報告する。
上にも下にも伝言ゲームが発生し、伝言ゲームのために大量の資料を作成する。
SIerの業務はエンジニアリングではない。
ITで何かを作っているのだが、エンジニアリングしている時間は全体の3%にも満たないだろう。
90%は伝言ゲームに時間を費やすことになる。
そうして、社員は疲弊していく。
手を動かしたくない症候群
SIerで年を取っていくと、とにかく「手を動かさないのが正義」という価値観が染み付いていく。
私は40歳以上のSIer社員で手を動かせる人をほとんど見たことがない。
「会議のセッティング」すらできないのだ。
会議のファシリテートもできない。
伝言ゲームしかできないくせに、資料の作成はできない。
「誰かに仕事を投げる」
「投げた仕事を評価する」
しかできなくなる。
SIerの４０代以降の社員の仕事の大半は
- 丸投げ
- 丸投げの詰め
- 丸投げの評価（ただし中身はあんまりわかってない）
みたいな感じになる。
何の価値もないゴミである。
こんな産業廃棄物が年々増えていっているのがSIerの現状だ。
社員の高齢化によるお荷物の増加
上の産業廃棄物問題にも関わってくるが、大手SIerでは社員が高齢化している。
チームの半分以上が「手を動かせない人」になっているチームも少なくない。
若手で手を動かせたり、自分で積極的に周りに働きかけるような人は次々と辞めていき、丸投げしかしない人が会社に残り続けた結果、実働部隊がほとんど減っている。
戦争で前線で闘える人が逃げ出して、司令官（無能）が居残り続けているのがSIerである。
コロナによる社会不安や、SIerの給料の良さもあり、若手の流出傾向はそれほど大きな問題にはなっていない。
しかしながら、今後SIerのレガシーシステムと世の中のモダンなシステムの乖離は大きくなるのは間違いなく、「まともなエンジニアリングがしたい」という若者がSIerを去る流れは加速するものと思っている。
加速してほしいとも思っている。
レガシーシステムで身動きが取れない
SIerではレガシーシステムを刷新する動きが増えてきている。
しかしSIerの社員は頭が良いバカなので、間違ったやり方をものすごく一生懸命やり遂げて、結果ゴミができあがるような作業を繰り返す。
何が言いたいかというと、COBOLのシステムをただJavaに置き換えるだけで、COBOLのスパゲティをJavaのスパゲティに変えるようなプロジェクトが大量発生している。
COBOLをJavaに書き換えれば
「レガシーで動きが重いシステムから脱却できる」
と思っているのだ。
デザインパターンを一つも知らないような社員が
「Javaはオブジェクト指向だから生産性が高まる！」
と勘違いして、問題の本質を何も解決しない、誰も幸せにならないプロジェクトで無駄に時間を過ごしている。
刷新プロジェクトでは古代のCOBOLの「設計書」をJavaの「設計書」に書き換えて、ひたすらExcelのドキュメントを作成している。
まずはテストから書くのが定石なんじゃないか？テストコードをドキュメントにして、テストをGREENにしながらリファクタリングしていくべきなんじゃないか？
と思うのだが、SIerの中の人はテスト駆動開発など全く知らないので、そういう発想にならない。
プロジェクトマネージャーをやる年代の人が馬鹿なのだ。
勉強不足なのだ。
勉強してないから、新しいことを身に付けてこなかったから、これまでの業務でやってきたことをこれからの業務でも続けていく。
だからSIerは変わらない。変われない。
同じことをずっと繰り返す。
20年前と全く同じミスをずっと繰り返す。
ガチガチのウォーターフォールで計画を立てて、計画は崩れていく。
だからSIerはヤバいのだ。
SIerが変わるにはどうしたらいいか？
SIerが変わるにはどうしたらいいかと考えた。
まず、プロパー社員が変わるのは無理だ。
彼らは手を動かせない。
彼らをエンジニアにするには１年以上の期間が必要になるし、1年勉強させる余裕はないだろう。
研修なんてやっても人は変わらないし、「お勉強して学んだつもり」になるのが関の山だ。
ではやはり、中途採用を増やして、入ってきた人に「意思決定」や「プロジェクトのリード」をお願いするのがいいだろう。
だがSIerに転職してくるのは同じようなSI業務しかしたことがない連中ばかりで、ウェブ系のまともな技術者は絶対にSIerには近づかない。
SIerがやばいと知っているからだ。
結局、SIerがやばすぎてまともな人は近づかないし、まともな人は逃げていく。
やばいSIerに中途で入ってくる人はやばい人しかいないので、中途採用による新陳代謝は働かない。
結果、SIerは永遠にやばいまま、変われずに、古くなったシステムを抱えたまま海に沈んていくのである。
お金持ちになりたいすべての人にとって、有用な情報が載っているブログを見つけたので紹介します。
エンジニア転職のリアル
私はこのブログを全部読んで、人生変わりました。
この記事を読んでくれた方にもぜひおすすめしたいです。
