最近、SIer（システムインテグレータ）業界のツラさをぶっちゃけた負け犬プログラマーさんのブログ記事を読んで、めっちゃ共感したよ。この記事は、日本のSIerが抱える非効率な作業、長時間労働、ガチガチの組織文化なんかをガンガン批判してるんだけど、読んでて「これ俺の体験じゃん！」ってなった。
俺はある中堅SIer（デジタルトランスフォーメーションやクラウドをウリにしてる会社）にフリーランスのAndroid開発者として4ヶ月間入ってたんだけど、この記事のポイントが俺のプロジェクト（業務用荷物配送アプリの開発）とバッチリ重なるんだ。
面白いのは、この記事って数年前のものなのに、俺が最近体験した内容とほとんど変わってないってこと。これだけ時間が経っても同じ問題が続いてるってことは、SIerの伝統的なやり方がいかに強固に根付いてるかってことだよな。
以下では、俺の体験エピソードを詳しく振り返りつつ、最後にSIerのビジネス構造についての考察も加えるよ。一方的にSIerを悪者にするんじゃなく、良くも悪くも成り立ってる理由を考えたい。
ただし断っておくと、これはあくまでたった4ヶ月間、1社での個人的な体験談だ。独断と偏見に基づく内容が多く、批判的な話ばかりになってる。もっとモダンで働きやすいSIerもあるかもしれないし、俺の現場がたまたま酷かっただけの可能性もある。その辺は差し引いて読んでもらいたい。
Excel地獄との闘い – 非効率なプロセス体験記
記事を読んで痛感したのは、古い技術の繰り返し作業と硬直したプロセスがいかに生産性を殺すかということ。俺もまさにこれに苦しめられた。
設計書はExcel方眼紙がデフォで、PlantUMLでUML図作って貼り付けるだけでもダルいのに、テンプレのちょっとした変更（ヘッダー変えるとか）があったら、全部のファイルを手動で直さないといけないんだよ。PCが重くなってイライラMAX！
「PythonでMarkdownからPDF自動生成すれば一瞬じゃん！」って思ったけど、「これがうちの伝統だから」で一蹴。結果、1日中Excelとにらめっこして、仕事してる感だけは出てるけど、何も進まない日々。記事で指摘されてた非効率な作業プロセスって、まさにこのExcel地獄のことだわ。😅
休日出勤でディスプレイ破壊事件 – ワークライフバランスの崩壊
記事で触れられていた労働環境の問題は、俺の休暇中の事件と完全に重なる体験だった。
俺の休みの日（本来の有給みたいな感じ）に、詳しくは忘れたけど「緊急だから作業して」って連絡きて、渋々リモートで対応した。で、最初のタスク終わらせたら、「はい、次これね」って当たり前に新しい作業をぶっこんでくるんだよ。
最初は「何か理由あんのかな」って我慢したけど、また追加タスク来て、ついにブチ切れ！ 会社支給のPCのディスプレイをグーパンで破壊しちゃった。😂 ヤバいよな、後で修理代とか心配したけど、ストレス爆発の瞬間だったわ。
その後日談で、正月休み明けにそのタスク振りまくった人がうつっぽくなって休職。俺のディスプレイ破壊がトラウマになったんかな？（苦笑）記事で書かれてた長時間労働の問題って、こんな過労の連鎖で現実化するんだね。
⚠️当たり前ではありますが、怒っても物に当たってはいけません。筆者も今は反省しています。
存在しないAPIを探せ – 多重下請けの情報混乱
記事を読んで理解したのは、多重下請け構造がいかにコミュニケーションを混乱させ、下位を搾取する仕組みになっているかということ。俺のAPI設計の仕事がまさにその典型例だった。
荷物配送アプリのバックエンドAPI設計書を書けって言われて、過去の似たサービスにあったAPIを前提に作れって指示。でも、調べてみたらそのAPI今回のサービスには存在しねえ！
「ラッキー」と思ってたら、今度は超複雑なAPIを前のと同じ工数で振ってくるんだよ。「間に合う前提で仕事振ってるから」って怒られたけど、間に合うわけないじゃん！ 関係者に聞きまくって何とかしたけど、この適当さは多重構造の情報歪みのせいだと思う。記事で触れられてた多重下請けのコミュニケーション問題って、現場ではこんな風にイライラを増幅させるんだな。
「設計書って守るもの？」- スキル成長を阻む文化
記事から読み取れる「保守的な文化が技術成長や創造性を阻害する」という問題は、俺の体験でも痛感した。
Android開発で、レガシーなライブラリーだらけのコードベースを見て、「1から作るなら最新のJetpackに変えよう！」って提案。奇跡的に上に許可下りて喜んだのに、コーディング始まったらエンジニアの一部が「工数増えるよ」「いちいちめんどくさい」って文句の嵐。
しかも、SIer歴長い先輩が「実際にコーディングって設計書通り作らないと駄目なの？」って聞いてくるんだよ。マジかよ！ 「当たり前だろ、何のための設計書だよ」って心の中でツッコミまくり。😂
この意識の低さは、記事の「保守的な文化」が生むスキル停滞の典型だわ。
監視されるチャット – 他業界との決定的な違い
プロジェクト会議で謎の長老（ベテラン）が設計書の体裁チェックのはずを、関係ない処理追加の話で脱線しまくり。時間切れで何も決まらず、みんな「時間の無駄！」ってチャットで愚痴ったら…そのチャット部屋、監視されてて消された。www
怖えよ、こんな文化じゃ意見も出せないし、成長なんて夢のまた夢だ。
記事でも少し触れられていたWeb系との比較だが、俺は実際にフリーランスになってその差を実感している。モダンなテック企業の方が給与も柔軟性もやりがいも上だというのは本当だと思う。
この経験で得たもの – 無駄じゃなかった4ヶ月
正直、技術的なスキルアップはほぼゼロだった。最新のフレームワークもモダンな開発手法も学べないし、むしろ時代に逆行してる感すらあった。
でも、得たものが全くないわけじゃない。まず、業界の実態を肌で知れたのは大きい。伝統に固められた開発体制、働いてる人たちの頭の固さ、年功序列でコミュニケーションの風通しが最悪な支配体制…これ全部、外から見てるだけじゃ分からない現実だった。
技術面では、PlantUMLやExcel方眼紙での設計書作成方法は一応身についた。まあ、これが役に立つかは微妙だけど、SIer界隈では必須スキルみたいなもんだし。
本当にこれくらいしかないんだけど、考えてみると未経験者や駆け出しエンジニアにとっては、職歴を積むという意味では全然アリかもしれない。フリーランスになるための足がかりとか、転職活動での経験値稼ぎとしては機能するだろうし。
要は、「SIerは技術成長には向かないけど、業界理解とキャリア戦略の一環としては使えなくもない」ってところかな。ただし、長居は禁物だと思うけどね。
なぜSIerは成り立つのか – ビジネス構造の考察
これらのエピソードから、SIerをただの悪者扱いするのは違うと思う。確かに、非効率でストレス溜まるけど、ビジネスとしてちゃんと成立してるんだよ。なぜなら、クライアント側も同じ「伝統」に縛られてるから。
日本の大企業や官公庁って、変化が怖くて「今までのやり方を変えられない」タイプが多い。SIerはそれに合わせて、詳細な設計書やプロセスを提供して「安心感」を売ってるんだ。
たとえば、Excel方眼紙の設計書は合理的じゃないけど、クライアントにとっては「仕事の証」みたいで、漠然とした安心を与えるブランディングツール。レガシー技術の継続も、互換性を重視するクライアントのニーズに合ってる。
良くも悪くも、SIerは「変わらないこと」を強みにしたビジネスモデル。グローバルトレンドから遅れてるけど、国内の需要がある限り続くよ。エンジニアにとってはキツいけど、業界を変えるならクライアントの意識改革からだね。
おわりに
負け犬プログラマーさんのブログ記事は、SIerのツラさをストレートに描いてて、俺の4ヶ月体験と重なるエピソードがいっぱい。笑える（？）カオスな出来事を通じて、SIerの構造を学んだよ。
辞めた今はフリーランスで自由にやってるけど、この体験も無駄じゃなかった。SIerを考えてる人がいても、こういう現実があることを知った上で判断すればいいと思う。伝統的なやり方は時には足枷になるけど、それでも日本のIT業界を支えてるビジネスの基盤でもあるんだぜ。😎
コメント