IT業界はB型が多いというのは、本当かウソか

IT業界には「B型が多い」というのは、IT業界のあるあるネタの一つですが、正式に統計をとったという話は聞いたことがありません。
ただの都市伝説なのかもしれませんが、個人的にはこのネタは「あるあるー」です。
以前の職場は自社でパッケージソフトを開発・販売していましたが、開発陣営の6割がB型でした。血液型の分布から考えると、偏っていますよね。
今の職場は受託開発がメインのIT業ですが、一番多いのはB型です。A型不在です。
いずれも、統計といえるようなサンプル数では無いので、そんな事例を後ろ盾にしても説得力は無いかもしれませんが…。
誤解の無いように書いておきますが、血液型の性格判断は全然信じていません。業種の向き不向きも関係ないと思います。
血液型の占いに至っては、占うという行為がよくわからないので、信じる云々という話でもないのです。
ただ、IT関連の特集記事やフォーラムなどでも「うちの職場もB型が多い」という意見を見る機会もあるので、事実として偏りがあるかもしれない。
こうなったら是非一度、全国IT従事者血液型調査を行なって、真偽のほどを明らかにしてもらいたいです。

幽霊社員が数十名

二次請け・三次請けが当たり前なIT業界。
一次請けの企業と聞くと、それなりに大きな会社を想像するかもしれませんが、SEもPGもいない小さな会社が一次請けになることも珍しくありません。
コネさえあれば美味しい仕事を引っ張ることができる業界なので、IT企業としての実体がなくても受注できてしまうのです。

下請けの末端で、実労働をすることになったSEやPGは、一次請けの会社で名刺を作ってもらって、ユーザーと対面するのはよくあることです。
ある会社は、社長1名+事務員1名という超ミニマムな人員ですが、歴代のシステム開発案件に関わったSE・PGは全て社員ということになっていますので、総勢20名近い幽霊社員がいる計算になります。
会社への電話は、約3分の1が幽霊社員宛だそうですが、古い幽霊社員の名前をウッカリ忘れてしまっていると「そんな社員はいませ・・・あ、います」と、妙な応対になってしまいます。
もちろん本人と連絡をとることはできないため、外出中で・・・とか、長期出張で・・・とか誤魔化し続けているそうです。
退職したことにすれば良いのでは?と言ってみたのですが、会社のイメージが悪くなるから嫌なのだそうです。
さすがに無理がありますよね。

🧩 ドサクサ出世したリーダーの功罪 — 組織に“当たり障り”は必要か?

いつの間にか、誰もが「え?」と思う人がリーダーに昇格している。
特にITやサービス業では、「ドサクサ出世」が珍しくありません。

たとえば、

  • 技術知識ゼロなのに管理職に

  • 現場の声を知らないのに会議だけ強い

  • 「前からいるから」「波風立てないから」という理由で昇進

…そんな構図、あなたの周りにもありませんか?

この“当たり障りない人”が出世する組織構造は、短期的には平穏を保てるものの、
長期的にはチームの士気と成長力を削ぐ重大なリスクをはらんでいます。


■ 「ドサクサ出世」とは何か

“ドサクサ出世”とは、
本来の評価基準が曖昧なまま、
タイミングや人間関係、部署再編などの流れに乗って出世してしまう現象のことです。

よくあるパターン

パターン典型的な理由結果
長く在籍している「そろそろリーダーにしてもいいか」年功序列化
衝突を避けるタイプ「あの人は誰とも揉めない」静かだが停滞する組織
上層部に好かれている「上には気に入られてる」下からの信頼が薄い
他に候補がいない「とりあえずこの人で」一時しのぎの昇進

■ 当たり障りのないリーダーがもたらす“副作用”

当たり障りのないリーダーは、表面上は組織を平穏に保ちます。
しかし、その裏で次のような「静かな崩壊」が進んでいきます。

1. 誰も本音を言わなくなる

リーダーが意見を出さないため、部下も発言を控える。
会議は穏やかでも、何も決まらない・進まない

2. 判断が曖昧になり責任が消える

曖昧なまま案件が進み、トラブル時には「誰が決めたのか不明」状態。
最終的に責任が個人ではなく空気に吸収される。

3. 若手が育たない

リーダー自身が技術・知識に乏しいため、教育ができない。
「自分で考えろ」と丸投げが増え、離職率が上がる

4. 現場と経営の乖離が拡大

「現場感覚」を持たないまま、上層部への報告だけがうまい。
結果として、現実を反映しない意思決定が繰り返される。


■ なぜ“当たり障り”が求められるのか

組織が“当たり障り”を好む背景には、次のような心理があります。

  • トラブルを起こさない人=安心感がある

  • 波風を立てない人=「管理しやすい」

  • 意見が強い人=扱いづらい

しかし、これは短期的な安定を買って長期的な停滞を招く危険な構造です。
組織に必要なのは「衝突」ではなく「健全な議論」。
意見の多様性を恐れる組織は、やがて外の変化に適応できなくなります。


■ ドサクサ出世の功罪

見方メリットデメリット
短期的視点組織が荒れにくい/調整がスムーズ新しい挑戦が止まる
人間関係的衝突が少なく、雰囲気が穏やか無関心・惰性が蔓延
管理者側コントロールしやすい自立したチームが育たない
長期的視点経営が安定して見える組織が老化する

■ 真に必要なのは「当たり障り“のない”人」ではなく「当たり前を問う人」

「当たり障りがない」=「誰にも嫌われない」ではありません。
本当に価値あるリーダーは、

  • 必要なときに意見を言える

  • 部下の信頼を失わずに方針を変えられる

  • 改善点を“攻撃”ではなく“提案”として出せる

つまり、当たり前を問い直す勇気を持つ人です。


■ 組織が取るべき3つの対策

① 昇進基準を明文化する

  • 技術・判断・育成の3軸で評価

  • 「在籍年数」だけでの昇進を廃止

  • 評価理由をチームに公開する

② リーダー研修を“義務”にする

  • コミュニケーション、心理的安全性、会議設計など

  • 技術・マネジメント両面から教育

③ 役職よりも“役割”を評価する

  • チーム内でのリード行動を評価軸に

  • 「役職者=リーダー」ではなく「行動者=リーダー」へ


■ 結論:本物のリーダーとは

リーダーとは、「目立たない人」でも「空気を読む人」でもなく、
チームを前に進めるために必要な判断を下せる人。

“当たり障り”のなさで出世したリーダーは、
一時的に平穏をもたらしますが、組織を育てることはできません。

今こそ、**「穏やかさ」より「誠実な主張」**を評価する時代です。
その勇気こそが、20年先も生き残る組織をつくります。

仕事をしないでマージンをもらいたい人がウゴメク業界

IT業界で働く人は、通称「IT土方」とも呼ばれます。
なぜそんな呼び方をされるのか?と尋ねると、人によっては「実際の作業で肉体を酷使するのと同じくらい、ITは脳を酷使するから」と答えてくれます。
まあ、それも通説の一つではありますが、本来は「土木作業員と同じように、IT業界も下請け→孫請け→曾孫請け→・・・というピラミッド型の産業構造になっていて、お金は中間で搾取されまくる。末端の作業員には、雀の涙」というのが真実。
自分が知ってる限り、小規模のIT企業はこのピラミッドの中間(最下層ではないところ)に噛んで、マージンだけ頂こうとする会社の多いこと多いこと……。

今年の頭には、某IT企業が受注した消費税絡みのシステムで開発が滞ってるらしく(というか、できもしないのに受注したらしい)、人員募集の話が出回っていました。
最初にその話が回ってきたのは1月。A社経由で「人員、出せない?」という打診に、こちらも増税対応中なので無理ですとお断り。
その後、2月も後半になってから、B社経由で同じ話が回ってきました。人員が確保できなくて、まだ募集中とのこと。
しかもB社経由で聞いた賃金は、A社よりも2割安でした!

確実に納期は迫ってきてるんだから、賃金を高くしてでも人材確保するべきじゃないのか?と思うのですが、ヨソのシステムが間に合おうが間に合うまいが、そんなことは関係ないんですね。とにかく、いっちょ噛んで小銭を稼ぎたい企業ばかり。
こんな中で、自社の幹部が妙に義侠心にあふれる人だと「うちから人を出します」なんて言うんでしょうなぁ。部下は気の毒に・・・
多少ガメつくても、火中の栗を部下に拾わせない幹部のいる会社でよかったー。

コピペ盗用をチェックしてくれるサイト「剽窃チェッカー」

最近、STAP細胞論文での疑惑から理化学研究所関係者による論文のコピペ(コピー&ペースト)疑惑がニュースなどでよく耳にします。これは以前からも大学生の論文でのコピペ問題などがニュースされているから基本的には論文チェックする専門機関なりが存在してそこで厳密にチェックするようにしてるんだろうなあと思っていたのですが、理研の報道見てるとミイラ取りがミイラになっているので相当杜撰だったんだろうなあと想像に難くないです。
問題はこれほどインターネットが日常に浸透している昨今ではコピペする行為自体を防ぐのはほぼ不可能に近いということです。ならどうするか?コピペしていないかチェックする作業が必須になります。探してみたら有料のツールもありましたが、無料のコピペチェックサイト「剽窃チェッカー」というサイトを見つけたのでご紹介します。

URL

剽窃チェッカー

機能

  • 入力を文(節)単位で区切り、ウェブ上に同一の文字列がないかチェックします。Google Booksへのリンクも生成します。
  • 提出されたレポートに剽窃(コピペ)がないか、簡単に確認できます。
  • 多言語対応。中国語やロシア語でもOKです(ただし、区切り文字は「.」「!」「?」など)。

使える人、使えない人

IT業界の中でも特にコンピューターのソフトウェア関係の仕事について、使える人、使えない人は当然のことながらいます。
基本的にプログラマーとして有能な人はとにかくコンピューターが好きで、好奇心旺盛であればたいてい使える人が多いと思います。
このような人はほっといても自分自身で勉強し知識を深め、結果的に仕事に対して結果を残します。
学歴はあまり関係なく、専門学校卒でも大学卒でも出来る人は出来るしそうでない人もいます。
逆に意外と注意が必要なのが資格をたくさん持っている人です。
情報処理関連の資格はたくさんありますが、資格を持っているからと言って実務に使えるかどうかはまた別の問題で、資格を取ることに熱中しすぎて仕事を疎かにしている場合もあるからです。
このような人は理論的な事は言いますが頭でっかちで使えない情報が多いけど実際に仕事を任せるとなかなか進まないケースが良くあります。
もちろん仕事が出来てその上に資格があれば言うことなしではあります。

プログラムの裏モードについて

私は長らくIT業界においてプログラマーとして働いています。
FA(ファクトリーオートメーション)やゲーム機、事務機など色々な製品を手掛けてきました。
プログラマーにとって最も怖いモノと言えば、製品出荷後にお客様から不具合の報告があることで、いわゆるバグというやつです。
作ったプログラムの難易度や複雑さによってバグが出るかどうかは異なって来ますが、もしもの場合に備えてバグが出た時に何が原因でそうなったのかを解決しやすくするための方法を仕組んでおくのが普通です。
例えばプログラムがどういう順序で動作したのか内部的に記録をとる方法(一般的にログと言います。)とか、プログラムに矛盾が生じたときにランプがいつもと違うパターンで光るようにしたりとやり方は様々です。
もちろん表向きの仕様とは異なるため裏モードなどと呼ばれています。
中にはこの裏モードのプログラムの方が表向きのプログラムより大量な場合もあり得ます。
私もこの裏モードで何回か助かったことがあります。

オフィスでの夜の明かし方

IT業界に勤務していた時の話ですが、やはり納品前になるとオフィスに泊まり込んで作業を行うこともありました。作業自体は深夜の1〜3時に一区切りすることもあるのですが、終電の時間を過ぎると、帰る手段がなくなり、そしてオフィスに泊まる事になるのです。もちろん、お金に余裕のある場合はタクシーで帰るなり、ホテルに泊まるなりできるのですが、いかんせんお金のない20代の頃でしたので私はもっぱらオフィスに泊まっていました。
その際、翌日(正確には本日ですが)の仕事のことを考えて仮眠をとるのですが、そこでちょっとしたコツがありました。それはダンボールを下に敷いた上で、寝袋ないしマットなどを敷いて横になることです。それはたとえ、ソファーの上に寝る場合でもです。ダンボールが一枚でも身体の下にあるだけで、保温効果が異なります。ずばり言いまして、ダンボールが一枚あるだけで温かいのです。そして疲れの取れ具合も違います!

大手企業の「井の中の蛙」っぷりは半端無い

大手通信系の某社で仕事をした時は、本当に最悪でした。

PCを使っている時にエラーが発生すると、エラーの原因が書かれた「ダイアログ」と呼ばれる小さな画面が表示されると思います。
たいていは「OK」ボタンが1つ、メッセージの下に着いていて、内容を理解したらそのボタンを押してダイアログ自体は消すというものです。

メッセージの横には「エラー」「警告」「情報」など、メッセージの深刻度をあらわすアイコンも着いていて、マイクロソフト標準では、エラーは赤、警告は黄色の交通標識アイコンを使う事になっています。
これは一種のガイドラインなのですが、これに合わせておけばユーザは混乱しないで済みますから、フリーソフトの作者などであっても同じルールにのっとっています。

ところが・・・。
この大企業からの注文は、

「エラーメッセージには警告アイコン、警告メッセージには情報アイコンを表示しろ」

という無茶苦茶なものでした。

自分とこのシステムでは、

「エラーなんて発生しない」

とでも言うつもりなのでしょうか・・・?

激しく疑問ではありましたが、それが

 「仕様」

だと言い切られては、言う通りにする以外にありません。

しかし、対処が必要な「エラー」が発生しているのに、より深刻度が低い「警告」アイコンを表示する、というのは詐欺の様な気がしてなりません。
ユーザに対して詐欺を行う「仕様」という事なのでしょうか・・・?

ああいう「一般の常識から外れた」事を敢えてする事で「独自なシステム」を設計した、と思っているならば、まさに噴飯物なのですが・・・世間に名だたる有名企業ですよ?
何億円もかけた「基幹システム」の設計があれって・・・。
いくら何でも、レベルが低すぎる気がするのですが・・・。

いつも時間が足りない—IT現場の「業界病」を抜け出す実践ガイド

システム開発にいると「常に時間が足りない」。ショートカット、多重タスク、コピペ、休日出勤…それでも終わらない。けれど、長時間労働は一定の閾値を超えると生産性が逓減し、むしろ品質や安全を損ないます。スタンフォードの研究でも、長時間になるほどアウトプットの伸びは鈍化(非線形)することが示されています。siepr.stanford.edu

本稿では、時間が足りない“業界病”の原因を分解し、個人/チーム/組織の3レイヤで今日からできる対策をまとめておきます。

症状チェック(3分)

  • 会議と通知でまとまった集中時間(60–90分)が週に2ブロック未満

  • タスク着手→中断→別件→戻る…のコンテキストスイッチが多い(平均、人は中断後もとの作業に戻るまで約23分かかるという報告)Gallup.com+1

  • WIP(同時進行案件)が常に満杯で、リードタイムが読めない(Little’s Law:WIPを絞るとサイクルタイムが短くなる)SixSigma.us+1

  • 残業で“間に合わせる”文化がデフォルト(日本では残業の法定上限:年720h、2–6か月平均80h/月、単月100h未満厚生労働省+1

原因のコア

  1. 中断の連鎖:通知・口頭割り込み・未整備のレビュー動線。集中の“助走”が毎回失われる。Gallup.com+1

  2. WIP過多:同時に抱える案件が多すぎ、平均リードタイムが延びる(Little’s Law)。Project Management Stack Exchange

  3. 長時間依存:時間を足す発想。だが一定時間を超えると限界効用は逓減し事故・不具合リスクも上がる。siepr.stanford.edu

  4. 制度と運用のギャップ:残業上限の法整備は進んだが、現場の“名ばかり管理職”や隠れ残業が問題化。フィナンシャル・タイムズ

解決:今日からやること(3レイヤ)

個人(明日からの儀式)

  • フォーカスタイムを先にブロック:1日90分×2コマをカレンダー死守。

  • 通知の窓口を1つに:Slack/Teamsはバッチ受信(例:毎時0分)。

  • タスクは“着手数<=3”:WIPを数字で可視化。SixSigma.us

  • ポモドーロ×小結:25分集中+5分で「次の最小一歩」を書き残し、中断復帰を早くする(“再開コスト”低減)。

チーム(1~2週間で効く型)

  • WIP制限×カンバン:カラムごとに上限を設定し、詰まり=ボトルネックを議論の起点に。SixSigma.us

  • レビュー予約制:レビューは“いつでも声かけて”をやめ、1日2回のレビュー便に集約(割り込み削減)。

  • 会議は目的と成果物だけ:目的・決定事項・宿題・締切の4点テンプレを全会で共有。

  • リードタイム計測:着手→完了の中央値を毎週確認。増えたらWIPを減らす。

組織(四半期で定着)

  • 残業上限の“運用ルール化”:720h/年・平均80h/月・単月100h未満の法基準に、追加で社内基準(たとえば“単月45h超は要レビュー”)を設ける。厚生労働省

  • 集中時間の全社ルール:全社“Do Not Disturb”帯(例:午前10–12時)を宣言。

  • ロードマップの“捨てる勇気”:四半期ごとにやらないリストを公式化。

  • 自動化と標準化に投資:ビルド・テスト・配布のCI/CD、テンプレ/共通部品の整備。

計測ダッシュボード(おすすめKPI)

  • フォーカスタイム総量(人・週):目標 8–10h/週

  • 中断回数/人・日(DM/メンション/招集)

  • 平均WIP(人が同時に抱えるチケット数)

  • リードタイム(中央値)

  • 残業時間(法上限に対する乖離モニタ)厚生労働省

まとめ

「時間を増やす」ではなく、中断とWIPを減らし、集中と流れを守る。それが、忙しいのに進まない現場を救う最短ルートです。長時間で押し切る発想から脱し、仕組みで前に進みましょう。siepr.stanford.edu+2Microsoft+2


補足:制度・データの要点(引用)

  • 日本の残業上限:年720h、2–6か月平均80h/月以内、単月100h未満。2019年(中小は2020年)から順次適用。厚生労働省+1

  • 長時間労働と生産性:時間が延びるほど限界生産は逓減(Pencavel, Stanford)。siepr.stanford.edu

  • 中断からの復帰コスト:平均23分15秒の再集中時間が報告。