IT業界に勤務していた時の話ですが、やはり納品前になるとオフィスに泊まり込んで作業を行うこともありました。作業自体は深夜の1〜3時に一区切りすることもあるのですが、終電の時間を過ぎると、帰る手段がなくなり、そしてオフィスに泊まる事になるのです。もちろん、お金に余裕のある場合はタクシーで帰るなり、ホテルに泊まるなりできるのですが、いかんせんお金のない20代の頃でしたので私はもっぱらオフィスに泊まっていました。
その際、翌日(正確には本日ですが)の仕事のことを考えて仮眠をとるのですが、そこでちょっとしたコツがありました。それはダンボールを下に敷いた上で、寝袋ないしマットなどを敷いて横になることです。それはたとえ、ソファーの上に寝る場合でもです。ダンボールが一枚でも身体の下にあるだけで、保温効果が異なります。ずばり言いまして、ダンボールが一枚あるだけで温かいのです。そして疲れの取れ具合も違います!
「IT業界の裏話」カテゴリーアーカイブ
大手企業の「井の中の蛙」っぷりは半端無い
大手通信系の某社で仕事をした時は、本当に最悪でした。
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
原因のコア
-
中断の連鎖:通知・口頭割り込み・未整備のレビュー動線。集中の“助走”が毎回失われる。Gallup.com+1
-
WIP過多:同時に抱える案件が多すぎ、平均リードタイムが延びる(Little’s Law)。Project Management Stack Exchange
-
長時間依存:時間を足す発想。だが一定時間を超えると限界効用は逓減し事故・不具合リスクも上がる。siepr.stanford.edu
-
制度と運用のギャップ:残業上限の法整備は進んだが、現場の“名ばかり管理職”や隠れ残業が問題化。フィナンシャル・タイムズ
解決:今日からやること(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秒の再集中時間が報告。
IT業界はコンピューターに精通していない人も多い
システムなどの開発が主な仕事となるIT業界ですが、実際にはコンピューターに詳しくない人も非常にたくさんいます。
プログラマーなどは、コンピューターのエキスパートと思われていますが、実際にはプログラム言語を使うだけならそれほど高いPCスキルは必要ない場合が多いです。
稀に非常にPCスキルの高い人もいますが、IT業界の大半は未経験入社が多いのでそこまでコンピューターを勉強していない人も非常に多いです。
実際に事務で使うEXCELやWORDなども、ほとんど使わないまま仕事をしている人もたくさんいます。
逆に資料しか作らないSEもいるため、EXCELしか使えませんといった人も中には存在します。
非常に敷居が高いと思われているIT業界ですが、実際には学生レベルで入社しても数年でものになることが多いです。
もちろん現場によって違いはありますが、大手のIT企業などは設計しかしないことも多いので、一般の人とコンピューターの知識が大差ないことも多々あります。
意外かもしれませんが、IT業界といってもそこまでPCスキルは高くなくてもコミュニケーションスキルが高ければ何とかやっていけることも多いです。
とにかく細かい上司
IT業界に所属していますが、とても細かい上司がいます。
連絡はすべてメール連絡で、またとても細かい30分単位のスケジュールをエクセルシートに立て
部下にはそこへの記入を義務付けます。
1分でも遅れると、エクセルシートは文字通り警告の真っ赤に染まり、その状況を添付した叱責の自動メールがすぐに飛んできます。
部下はそれに対する現状と改善案を記して上司にメール報告を義務付けられます。
とにかくコピペのような定型文メールがメール魔で一日15通は飛んできます。
そして、それらに目を通さずに何かの拍子に聞きかえそうならば、もうそのことは伝えてある、時間の無駄だの一点張りです。
とにかく管理が大好きですが決して助けてはくれませんし、何より融通が利きません。
メールの文章なども自分でエクセルマクロを利用して自動化しているようで、まるで人間味のない文章です。
システム開発をやっていると細かくなるのは当然ですが、あそこまで極端になってまで上に行きたくないなあと思う次第です。
真のボスと陰のボスと裏のボスと表のボスと本当のボス
私がIT業界に身を置く様になって、20年以上が過ぎました。
裏話をしようと思えば、実名入りでいろいろと可能なのですが・・・差し障りがあるとマズいですしね。
念の為に、自分が「結局は関係しなかった」プロジェクトについて書く事にしましょう。
その時、自分が案件の内容を聞きに行ったのは、通信系の超有名企業でした。
自社内のソフト開発だけでなく、外部からの依頼を受けての開発にも乗り出した模様で、自分にしてみれば「どんな人がどう仕切っているのか」見てきてやろう、という感じでした。
と言うのは、こういう大手企業のプロジェクトは、「中身は他社」というケースがほとんどだからです。
その大企業の系列中のIT系子会社が請け負っていたり、さらにその関連企業が請け負っていたり、さらにその子会社、さらにその関連会社、さらにその「知り合いの会社」・・・。
例えて言うなら「シェフ誰々監修」のコンビニ商品の様な感じでしょうかね。
実際の仕事のほとんど全てを、全く別な人たちが行っているワケです。
ところが。
プロジェクトの責任者と言って面接に出てきたのは、全く別の会社の人でした。
自分でも名前を知っている派遣専門の会社です。
業界では「雇われマネージャー」は珍しくありませんが、ちょっと年齢的に若過ぎないか・・・と思っていたら、どうも話が変。
聞けば、プロジェクトのマネージャーは、他にも3人ほど居るそうで・・・。
(一般企業で言ったら、「社長が3人居ます」みたいな感じですかね)
どうやら、大企業から最初に一人、マネージャーを出したらしいのですが、この人がまるで仕事ができない。そこで、その下に二人、補佐をつけたら、この二人の意見が合わない。最終的に、誰にも任せる事ができなくなって、外部からマネージャーを呼んだ、というのが真相な様です。
無論、そんなプロジェクトでマネージャーをやりたがる会社は少なく、「若手リーダーの箔付け」に利用したい派遣大手某社が名乗りを上げた・・・というのが真相な様でした。
では、その雇われ君にマネージャーの仕事ができるか、と言ったらそれも無理なので、彼の下で
「マネージャーとしての実作業」
を行う、ゴーストライターの様な人材を募集していた模様です。
まぁ、悪いとは言いませんけど・・・仕事を出したお客さんが気の毒ですね。
超有名企業に仕事を出せば安心だ、と思っているのだと思いますけど・・・中身は、こんな感じでしたからね。
それにしても、あのプロジェクトは、あの後、どういう感じで進んだんでしょうね・・・?
良く、ロールプレイングゲームなどで、
「ボスを倒したと思ったら、真のボスは他に居た」
なんて展開がありますが、そんな生易しい物ではありません。
倒しても倒しても、
「ボス、何人居るんだよ!?」
なんてシナリオにしたらと悪口を言われるに決まっていますが・・・これが「現実」だという点、どう思えば良いのでしょうね?
IT業界の労働環境
IT業界の企業の労働環境は、一見華やかに見えますが一部の大手や特殊な技術が要される企業を除けば、まだまだ改善すべき点がたくさんあると思います。
しかし、ITというものの本質を考えれば、なかなか楽になるとは考えにくいというのが現状です。
ITは情報処理技術によって世の中のシステム化に貢献し、効率をよくして便利にすることが主たる目的です。
コンピュータに演算を任せ世の中をとにかく効率的にして人間は楽をしていこうという算段です。
しかし、コンピュータ自身は今のところシステムを自動で構築することはできず、人間がシステム構築にかかわらなければなりません。
ここに大きな障害があるのです。
コンピュータの演算は人間界よりもずっと予測可能、コントロール可能であるように見える、もしくはそうであって欲しいという人間の願望が強いのでコンピュータ業界の人間はコンピュータに合わせがちにどうしてもなってしまうのです。
ですが実際のコンピュータはしばしば故障しますし、人間はコンピュータの挙動をすべて把握するには頭がついていきません。
ここに大きな齟齬が発生しているため、IT業界では常に人手不足・時間不足に陥りやすくなっています。
システム開発のスケジュール
下流のシステム開発の会社で働いていますが、とにかく残業だらけです。
システム開発の計画通りに物事が進んでいないということです。
システム開発の現場では工数という用語がよく用いられます。工数1人日と言えば、人が1日=8時間でその作業をこなさなければならない
という意味です。
計画を立てるものにもよりますが、実際は一つのプログラムを作る際も非常に細分化されたスケジュールがたてられている場合が多く
一つの細分化されたプログラム構築が0.125人日=1時間などと設定されている場合もあります。
このスケジュール設定は顧客にも細かくチェックされる場合が多く、顧客はしばしばシステム開発はもっと簡単に出来るものだと思っている為、時間に対してお金がもらえないのです。
そして、この予定に対して少しでも遅れると上司から注意されたりする場合があります。
とにかく時間に細かく効率化が求められるのがソフトウェア開発業界ですが、大概は開発作業は遅れて残業続きになります。
それは予定が常にカツカツな状態で立てられているからです。
凄腕プログラマーでなければどんどん遅れていき大概は、自己責任として残業でカバーします。
予定に遅れるのは自分が悪いからだと思っている人がとても多いのです。