【SI業界】IT業界の残業時間事情をまとめてみた【就活生向け】
ぼくが新卒で就活したとき（2010年頃）、一番気になったのは年収と残業時間だった覚えがあります。 年収は調べればすぐに出てくるのですが、残業についてはこれといった情報がありませんでした。
当時調べた結果として、IT業界は残業が多いという情報はあるものの、部署次第という情報も多く、もやっとしたまま就活をしていました。
実際にIT業界に入って5年ほど経ち、内部事情がわかってきたので、IT業界の残業時間について実際のところをまとめてみたいと思います。あくまでぼくが知っている範囲ですが、情報系の大学院出身なので比較的IT業界の知り合いは多いと思います。
SIer勤務6年目のぼくの残業時間
まず今のぼくの残業時間は月に80時間程度です。
今まではプロジェクトによって0時間〜100時間ぐらいの間でした。全期間の平均は50時間ぐらいでしょうか。
50時間というと、水曜日に定時（18時）であがったとして、その他の日は21時に帰宅という感じです。 これぐらいなら体や心を壊すこともなく、健康的な生活ができます。
80時間だと毎日22時帰宅になるのでキツくなってきます。 個人的にはここがひとつの目安になっています。
ちなみに残業をしたとして、残業代が実際にもらえるかですが、これは完全に上司やプロジェクト次第となります。
ぼくは今まで上司に恵まれていたのか、おおよそ残業は付けられていました。
プロジェクト予算が足りなかったり、自分が悪いからと自制したりで、付けられない人もたくさん周りにはいますが…
業界による違い
ここからIT業界の残業時間についてお話していきますが、まずはIT業界とそれ以外の業界という観点で見ていきます。
以下の①のサイトを見ていただくとわかるのですが、業界別残業時間ランキングで「SIer、ソフト開発」は13位で月あたり52.66時間となっています。 ②のサイトも参考になるので載せておきます。
①ホワイトカラーエグゼンプションが狙い撃ち?残業時間の長い業界・職種ランキング
②残業の多い仕事、残業の少ない仕事。業界別の残業時間の傾向まとめ
これを見ると、残業時間が多いのはIT業界だけではないとわかります。IT業界が少ないとは言えませんが…
実際、周りのIT業界以外の大企業で働いている人に聞くとだいたい残業時間は同じようなものです。
感覚ですが、業界というよりは企業の大きさによって、ある程度の偏りはあるように思います（大企業の方が残業時間が多い）
会社による違い
ここからはIT（SI）業界にフォーカスして話していきます。
IT業界と言っても、元請けのSIerや下請け、Web系と様々ですが、ぼくは元請けのSIer勤務なのでそこを中心に話します。
SIerの残業時間だと以下のサイト（元情報は2chだと思う）は自分が知っている中では信憑性がある方だと思います。あまり具体的な数字は載っていないですが…
[人気順] 就職偏差値ランキング | 就職偏差値ランキング委員会
結局のところ、ネット上の情報だと限界があるので、気になるなら先輩等の社会人に聞いてみるのが一番いいと思います。
部署による違い
SIerの会社に入ったとして、後はどの部署に入ると残業が少ないのか気になりますよね。
よくネットでは残業時間なんて部署次第と言いますが、実際どうなのでしょうか。
部署ですが大体お客様の業種等でわかれることが多いです。例えば金融業界の地方銀行を担当する部署や製造業界の自動車メーカーを担当する部署など。
まず金融業界全てが忙しく製造業界が暇というように業界レベルで残業時間に大きな差があるわけではありません。
どちらかと言うと担当するお客様によってある程度の違いはあると思います。 例えば地方銀行の担当は比較的保守案件が多く暇なことが多いが、メガバンクの担当は新規案件が多く忙しいことが多い等といったことはあると思います。
これも景気（企業のIT投資が多いか少ないか）や時期によって大きく変わりますが。
結果として残業時間が多い部署を避けたいと思うなら、具体的な業種や会社を希望すると、残業が少ない部署に配属される可能性はあるかもしれませんね。業界レベルでの希望では結局運次第です。
プロジェクトや職種等による違い
ここからはあまり個人の裁量の余地はないですが、プロジェクトや職種等によっても残業時間は異なります。
特にプロジェクトは、上から決められたところに配属されるだけなので完全に運次第です。
プロジェクトの残業時間を決める要素はいくつかありますが、見積り時の工数（どれだけ余裕があるか）やプロジェクトの難易度、メンバーのスキルレベル等が要素としてあります。
このような要素によってそのプロジェクトでの忙しさが決まってきます。
要はうまく行けば余裕を持って仕事ができますし、うまく行かなく問題プロジェクトになるといわゆるデスマ状態になるということです。
また開発工程によっても違います。
例えば調整ごとが多い上流工程（要件定義や総合テスト）はPMが、設計やテストではSEが、製造ではプログラマーが忙しいことが多いと思います。
なお一般的にはリーダー層になるほど忙しい傾向があります。
まとめ
IT業界の残業時間についてまとめてみましたが参考になったでしょうか？
就活の時は残業時間が気になりますが、社会人になってみると意外に気にならなかったです。
少しぐらいの残業なら大丈夫だと思うなら、慣れてしまうので気にしなくて良いと思います。
（慣れるのが良くないという議論もありますが…）
ただし本当に残業が嫌ならIT業界は避けた方が無難でしょう。
ある程度の大企業に入ろうと思うと残業は避けては通れないと思いますので、有名な会社は諦めたほうが良いかもしれませんね。
そんなにうまい話しはなかなかないということです。
最後に就活生に一言。
人生が決まります。本気を出しましょう。
面接官の気持ちになって考えてみるのが採用への近道です。
実際の現場をイメージして、自分ならどんな人と仕事がしたいですか？
【SI業界】システム開発の流れ～マスタスケジュールとメンバー数の推移、各工程作業～【就活生向け】
【本記事は、SI業界志望の就活生等の初心者向けの内容です】
前回の記事でシステム開発の概要や体制図、メンバーの役割を説明しました。今回はシステム開発のマスタスケジュールとプロジェクトメンバーの人数の推移、そして各工程の作業内容について説明していきます。
ありきたりな工程作業の説明は省き、できるだけシステム開発のイメージが湧くように現場のプロジェクトをイメージして説明します。
マスタスケジュールとプロジェクトメンバー数の推移
システム開発では、まずはじめに「要件定義」と呼ばれる工程から始まります。
ここではお客様からどんなシステムを作りたいのかをヒアリングし、要件定義書としてまとめます。
（具体的な作業内容は本記事の下部にまとめます）
要件定義書が完成すると次は見積りに入ります。「見積り」ではお客様からの要望をどのぐらいの期間・人数でこなせるか見積り、お客様と金額の交渉を行います。
交渉の結果、以下のようなマスタスケジュールとプロジェクトメンバー数でプロジェクトを進めることが決定します。 ここでやっとシステム開発のプロジェクトの全貌が見えてきます。
システム開発の各工程作業内容
上記のマスタスケジュールをご覧いただくと分かる通り、システム開発のプロジェクトではメンバー数が大きく変動します。
これは各工程で必要とされる作業内容と作業量が異なるからです。
それでは実際に各工程の作業内容を見て行きましょう。
プロジェクトメンバー数の推移と合わせて見てもらえるとイメージが湧きやすいかと思います。
ちなみに本記事では一般的な工程の定義ではなく、具体的な作業イメージでまとめます。
※一般的な工程作業については「システム開発 工程」等でググってみてください。
| 工程名 | 主な作業内容 | 説明 |
|---|---|---|
| 要件定義 | ・お客様との打合せ ・要件定義書作成 ・見積り作成 |
要件定義書と見積りを作成することがゴールになります。 お客様に聞きたいこと（要件定義書の記載内容）を整理して、何度も繰り返し打合せを行います。 |
| 基本設計（BD） | ・基本設計書作成 ・内部レビュー ・お客様レビュー |
要件定義書をインプットに、お客様に見える画面や帳票等の詳細を定義します。 機能単位に担当者を決めて基本設計書を作成し、チーム内部でレビューを行います。 レビューは指摘を取り込んで何度も実施することが多いです。 内部でのレビューが終わったらお客様にもレビューしてもらいます。 |
| 詳細設計（DD） | ・詳細設計書作成 ・内部レビュー |
基本設計書の内容をどのようにPGMで実現するか検討し、PGM単位で詳細設計書としてPGが作成します。 それを基本設計を担当したSEがレビューします。お客様は出てきません。 なお記載のレベル感はプロジェクトによって全然違います。 |
| 製造・単体テスト （M/UT） |
・プログラム作成 ・単体テストケース作成 ・単体テスト実施 ・単体テストケース/結果レビュー |
詳細設計書をもとにPGがプログラムを作成します。 完成したらテストケース（パターン）を作成し、PGM単位で詳細設計書通りに動くことを検証します。 SEはテスト結果のレビューや各種ルール作り、テストで発見したバグ対応等を行います。 |
| 結合テスト（IT） | ・結合テストケース作成 ・結合テスト実施 ・結合テストケース/結果レビュー |
単体テストでPGM単位で検証を行いましたが、その範囲を機能単位での検証に拡大します。 結合テストでは基本設計書通りに動くことを検証します。 基本設計レベルの検証のためテストケースをSEが作成し、テスト実施をPGがやることが多いと思います。 |
| 総合テスト（ST） | ・総合テストシナリオ作成 ・総合テストケース作成 ・総合テスト実施 ・総合テストケース/結果レビュー |
総合テストでは要件定義の内容通りにシステム全体が動くのかを検証します。 具体的には要件定義で作成した業務フローをもとに、まずテストシナリオ（テストの流れ）を作成します。 それをさらに詳細な確認ポイントを記載したテストケースに落とし込みます。 開発側のテストとしてはこれで終わりになるので、ここでバグを出し切る必要があります。 |
| 受入テスト（RT） | ・お客様のテストのヘルプ ・お客様問合せ対応 |
受入テストは基本的にお客様でのテストなので、開発側が主体的に実施する作業はありません。 テストを実施するための準備を手伝ったり、問合せ対応を行ったりします。 ただお客様がシステムに詳しくない場合など、ケース作成から開発側でやることもあります… |
各工程作業の成果物サンプルまとめ
上記の説明だけで分かれば天才です。実際のサンプルを見ないとよくわからないと思うので、各工程で作成する成果物について、具体的なイメージが載っているサイトを紹介します。
＜要件定義書＞
Kaleido Modeling » rcp-srs-01:要件定義書
※記事中央の「でき上がりサンプル」を見るとサンプル（PDF）が見れます。
＜基本設計書＞
［画面設計］画面の構造は物理的・論理的に示す
※記事右上の「連載目次へ >>」を見るとさらにたくさん見れます
＜詳細設計書＞
詳細設計書はプロジェクトによって全然違いますが、いくつか見たことあるようなサンプルがあったので紹介します。
＜単体テストケース＞
[ThinkIT] 第6回：単体テスト仕様書＆報告書 (3/3)
＜結合テストケース＞
以下サンプルで「シナリオ」や「ケース」という言葉が使われていますが、プロジェクトによって使い方が違います。そのためあまり言葉を気にせず、どんなことを実施しているかという観点で見ていただいたほうが良いと思います。
[ThinkIT] 第7回：結合テストと総合テスト (1/3)
＜総合テストシナリオ／ケース＞
あまり良いサンプルが見つかりませんでした。良いサンプルがあれば紹介頂けると幸いです。
総合テストは業務の流れをベースに動作を確認するのが目的なので、業務のパターンがシナリオになります。さらに業務のパターン毎に何を確認するか（画面や帳票、データなど）を記載したものがケースとなります。
まとめ
今回はプロジェクトのマスタスケジュールやプロジェクトメンバーの人数の推移、そして各工程の作業内容についてまとめました。なんとなくプロジェクトの全体像と流れがわかってもらえると嬉しいです。
はじめは分からないことだらけだと思いますが、一つ一つ順を追って理解していけば全体像がつかめてくると思いますので、根気よく確認していってください。
今後は各工程の詳細やその他のトピックについて、もう少し掘り下げた内容をまとめていきたいと思いますので、よろしければご覧頂ければと思います。
SI業界は知識集約型ではなく労働集約型の産業であり、これにより日本のシステムはダメになっている。
IT業界と聞くと、学生や他の業界の人は最先端のことをやっているすごい人たちという印象があると思います。というより良く言われます。
ですが、SI業界に限るとこれは大きな勘違いです。*1
IT業界の2つの分類（SI業界とWeb業界）
そもそもですが、IT業界といっても大きく2つの分類があります。
SI業界（主に法人からの受託開発）とWeb業界（主にWebサービス等の自社開発）です。
SI業界の代表的な会社としては、NTTデータ、富士通、日立製作所、野村総研(NRI) 、日本IBM、アクセンチュアなどがあります。
Web業界について定義が難しいですが、代表的な会社としてはDeNA、グリーなどが挙げられると思います。この業界はベンチャー企業が多いです。
この2つの業界はプログラムを作るという点では共通していますが、仕事の仕方や考え方など全く別の業界と言ってもいいほど異なる点が多いのです。
2つの業界の違いについては、以下のサイトが参考になります。
next.rikunabi.com
SI業界は知識集約型ではなく労働集約型の産業である
ではSI業界がなぜ労働集約型と言えるのか。
すごくおおまかに結論をいうと、
スキルが高くない人でも開発できるように昔から使われている"枯れた"スキームを使って、難易度は低いが作業量が多いシステムを提案する傾向にあるからです。
これにはいくつか理由があると思います。
- 高スキルな人を少人数集めるよりも、低スキルの人をたくさん集めるほうが楽（SI業界にはスーパーな人はなかなかいない）
- 新しい仕組みや高難易度な仕組みを使うとプロジェクト失敗のリスクが高い
- SIerに最新技術に精通している人が少ない（技術力的にそのような提案ができない）
- ユーザから機能要件は出てくるが、それをどのような技術を使って実現しても問題ない事が多い（見栄えや使い勝手、保守性、拡張性等はないがしろにされることが多い）
この結果、現状の日本では使い勝手が悪く保守性や拡張性に乏しいシステムがたくさん出来上がっていると思います。
ビジネスとしてやるからにはリスクを削減することが大事ですが、仕事している立場からすると新しい技術って夢があって楽しいですよね。それがなかなかSI業界とマッチしないことはとても残念です。
ご参考までに労働集約型と知識集約型の違いについては、以下のサイトがわかりやすくまとまっています。
synapse-diary.com
どうしたら負のスパイラルから脱却できるのか
今のSI業界では何年か毎にシステムを作り直し、毎度使い勝手の悪いシステムが出来上がっている状態だと思っています。
このような現状は日本全体として無駄が多く、とってもよろしくない状態です。
この状況を脱却するためにどうすれば良いかひとまず色々と案を出してみました。
- ユーザがよりITに精通し、長い目で見てシステムの企画を行う。もしくは一度本気を出して内製化する（これらが一番の近道だと思っています）
- SI業界の社員を成長させてデキる人を増やす（高学歴の新卒が入ってきても現場では作業者として仕事をしていることも多いです。これでは成長できません。）
- 待遇や文化を変えて、優秀な人材のSI業界→Web業界の流出を防ぐ（実際、私の周りの優秀な人は転職してしまった人が多いです）
- スキルが高くない人でもいい感じのシステムが作れるようなフレームワーク等の仕組みを作る（無茶苦茶言ってますが）
- 受託開発のこの現状が変えられないのであれば、クラウド関連のサービスに移行する
最後に
この記事が「SI業界をより良くするにはどうすれば良いか」を考えるきっかけになれば幸いです。
*1:全てのSI業界がそうというわけではないですが、大多数は当てはまると思います
【SI業界】システム開発の流れ～プロジェクト概要と体制図～【就活生向け】
【本記事は、システム開発の流れがイメージ出来ていないSI業界志望の就活生等の初心者向けの内容です】
前回の記事でそもそもシステムとは？を説明しましたが、これからのいくつかの記事でシステム開発の流れと作業内容について説明していきます。
si-yasan.hatenablog.com
今回は例として用いるプロジェクトの概要と体制図、メンバーの役割についてお話しします。
システム開発プロジェクトの概要
システム開発の流れを理解してもらうために、前回の記事に記載した通信販売会社の例（架空のもの）を用いて説明したいと思います。
今回モデルとするシステム開発プロジェクトは、以下のとおりとします。
- プロジェクト目標 ：通販サイトと売上集計表等の帳票作成処理を作成する
- 開発期間 ：１年
- 開発工数 ：１２０人月（１ヶ月あたり平均１０名）
※システム基盤構築は開発対象外とし、アプリケーション開発のみを対象とする
大体１人月１００万の売上とすると１億２０００万円の中規模プロジェクトですね。
ちなみに「人月」は人数×月を表しています。１人が１ヶ月働いて１人月です。
プロジェクトの体制図とメンバーの役割
プロジェクトの体制としては、以下のようなパターンが典型的だと思います。
いくつかのチームに分割され、それぞれのPL配下に複数名のSEやPGのメンバーがいるようなケースですね。
この体制図では４種類の人達がいますので、それぞれの役割についてまとめておきます。 *1
PM（プロジェクトマネージャ）
プロジェクトのリーダーですね。だいたいSIerの部課長クラスでしょうか。
大まかなスケジュールや方針を決めたり、PLへ期限付きで大まかな作業内容の指示出しをしたり、協力会社と調整してメンバー確保を行ったりします。ちなみにコスト面（お金）を意識する人はこの人ぐらいです。PL（プロジェクトリーダー）
いわゆるチームリーダーです。SIerのプロパー社員の中堅層（協力会社の場合もあり）が配置されます。一つのサブシステムを任され、チーム内の数名～十数名をまとめる役割になります。
PMは管理や調整で手一杯のため実質的にはこの人が開発の中心メンバーとなります。SE（システムエンジニア）
色々な定義があると思いますが、SI業界だと上流工程（設計）を任せられるメンバーはこのように呼ばれます。この業界では、見積の際にSEが何名、PGが何名とメンバーを確保しますが、SEはPGよりも単価が高くなっており、結果的に優秀な人がこう呼ばれています。（例えばSEは１人月100万、PGは80万など）要は見積もり上のメンバーの分類となります。なおSEにもプログラミングが出来る人とそうでない人がいます。PG（プログラマー）
プログラミング専門のメンバーです。少しコミュニケーション能力に難がある傾向にあります。なおすごく優秀なプログラマーは単価が高くなるためSEに分類されていると思います。またPGは協力会社の更に下請けのメンバーになることが多いです。これがよく言われる多重下請けですね。。。
まとめ
今回はプロジェクトの概要と体制図、メンバーの役割についてまとめました。
作業内容を説明していないのでイメージしにくいと思いますが、作業イメージが湧いてから見てもらうとさらに理解が深まると思います。
次回はシステム開発プロジェクトのスケジュールと各工程の作業内容についてお話したいと思いますので是非ご覧ください。
*1:厳密にいうとPMとPLは役割、SEとPGは職種の名称になりますので少し異なる観点になります
【SI業界】そもそもシステムって何よ？【就活生向け】
【本記事は、システムって何？というSI業界志望の就活生等の初心者向けの内容です】
現在SIerで仕事をして6年ですが、今考えるとぼくが就職活動をしていた時はSI業界の仕事について全然わかってなかったです。 多分これから就職活動する人たちも、同じような悩みを抱えていると思うので、自分の知っていることを伝えていきたいと思います。（自分の経験によるもののため偏り等あると思います）
初回としてはタイトルの通り「そもそもシステムって何よ？」をお話していきます。
そもそもシステムって何よ？
IT業界のことを調べていくとシステムっていう単語がたくさん出てきますが、具体的なイメージを持っている人は多くないと思います。 じゃあシステムの意味はというと「仕組み」となります。うん、全然よくわからないですね。
ということでイメージを持ってもらうために、具体例を出して説明したいと思います。
今回は通信販売会社が「一ヶ月の売上を商品毎に集計したい」という場合を想定してみます。
ITの仕組み（システム）を使わない場合の通販の業務フロー
このフローで特に大変なのは、毎月の売上集計表の作成です。
何万もの伝票があるとすれば、これを手作業でやるのは現実的ではないですね。
*1
ITの仕組み（システム）を使う場合の通販の業務フロー
このように手作業に限界がある場合は、ITの仕組みを使って自動化してコスト（人件費）を削減した方が良いですね。そのために以下のような仕組みを作ります。
この場合、誰の手も借りずに全て自動化できてしまいます。
このようにITの力で業務の仕組み作りをしましょう！というのがシステム開発になります。
システムの構成イメージ
じゃあ実際にITを使ったシステムってどんなものなの？
というと、よくあるシステム構成のイメージが以下となります。*2
ITの知識がない人は少し厳しいかもしれませんが、普段使っているスマホやパソコンに照らし合わせて見て頂けるとわかりやすいかもしれません。
システム開発の作業概要
システムのイメージがわいてくると、システム開発って具体的に何するの？となると思います。
詳細は今後お話しするとして、大きく分けて2つの作業があるので概要だけ説明します。
アプリケーション開発
今回の例でいうとWebの画面やサーバ上で動くアプリ（PGM）を作成する作業です。
実際にはプログラムを作る人だけでなく、計画をする人や管理する人、プログラムを作成するための設計書を作る人など色々な役割分担があります。基盤構築と比較してかなり多くの作業量が必要になりますので、対応する人数も多くなります。システム基盤構築
今回の例でいうとサーバ自体を組み立てて初期セットアップをしたり、ネットワークを繋げたりするお仕事です。より技術的な知識が必要になってきます。
（適当なことを言って怒られそうですが、パソコンを買って、いろんなアプリをインストールして、フレッツ光を契約して設定する、みたいな感じ）
まとめ
「システム」についてまとめてみましたが、イメージ湧きましたでしょうか？
IT関連は難しい単語ばかりではじめは苦労すると思いますが、日常で利用しているもの等の理解しやすいものに置き換えながら順序立てて見ていけば理解できると思います。
こんなことがわからない！こんなのまとめてほしい！等ありましたらコメント頂ければと思います。
今後やる気次第でまとめてみます。
