【IT業界の真実】未経験からIT企業に就職される方へ/仕事内容紹介/SES／人気IT企業ランキング ブラック？プログラミング
IT業界の真実・仕事内容 動画解説
◆文字おこし◆
2022年卒の人気IT業界ランキングが発表されました。
日経のWebページになりますが、１位NTTデータ ２位楽天 ３位富士通になっています。
個人的には１位と３位の会社の方には過去非常にお世話になって、
私自身ITエンジニアとして大きく成長させて頂きました。
ただ、学生の皆さんはIT業界に就職して理想と現実のギャップを感じる方が多いのも事実です。会社によっては、長時間労働でブラックと感じる方もいると思います。
IT業界＝プログラミング はなやか 高収入 というイメージを持っている方も多いと思います。
どの業界にも言えることかもしれませんが、はなやかに見える反面、裏では物凄く泥臭い作業を行っています。
詳細は今から話しますが、プログラミングは長い工程の中のほんの一部です。
プログラミング自体はオフショアと言って、海外の企業に発注した方が安いし、IT関連の優秀な人材が多いという理由で、設計書まで日本で作成して、プログラミングは日本企業は行わない場合も多くあります。
IT業界と言っても非常に業務幅が広いので人気度だけで選んでしまうと、本来やりたかった仕事ができない可能性も出てきます。
IT業界の仕事について全体的にまとまった動画がYouTube上にほとんどないので、
これからIT業界就職を目指される方向けに参考になればと思いお話させて頂きます。
例えば顧客が本来欲しかったものはこちらですが、システム担当者が思い浮かべたものはこちら、色んな工程を経て出来上がったものがこちら、請求された金額はこちらとなり、お互いに思い描くものの伝えることの難しさを表現しています。
これが原因で手戻りが発生し、高稼働のブラック企業となってしまう可能性があります。
システム開発の早い段階で、いかにお互いの認識齟齬を無くしていくかということが重要ですが、今日はその解決方法も話していきます。★
官公庁などある程度の規模を持ったシステム開発の大まかな流れを順を追って説明します。
システム開発は、システムで業務を効率化したいお客さんが必ずいます。
例えば、市役所Aが、予防接種の予約をシステム化する例で説明していきます。
市役所Aでは、開発できる人がいないのでNTTデータなどのシステム会社に相談します。
NTTデータはシステムインテグレータを略してSI企業といって、システム開発の取りまとめを行う会社になります。建築業界なら、工務店の様なイメージです。
市役所Aのシステムで実現したい要求事項を確認し、それによってお金を見積もって、後から説明するシステム開発のそれぞれの工程によって必要な人員を算出します。見積り単位として人月という言葉がよく使われます。
１人月は、１名の人が１か月かかる仕事量になります。
１００人月なら１００人で１か月、１０人で１０ヵ月かかる仕事量になります。
１人月当たりの単金を80万円などしてそれに人月をかけて、見積金額とします。
元請けだけでは、人数が足りないので、NTTグループ等に仕事の協力を依頼します。
さらにそのNTTグループで人が足りなければ必要に応じて他の会社に仕事を依頼します。
一般的な用語で、下請けというのかもしれませんが、業界用語では協力会社やビジネスパートナーを略してBPと言っています。
発注関係はありますが、開発能力が下というわけではなく、その会社の持っている強みを提供するという役割です。
業界用語では、システムエンジニアリングサービスを略してSESといって、ソフトウエアやシステムの開発・保守・運用などの特定の業務に対して技術者を派遣する技術支援サービスになります。
この階層図のように実際にシステム業界にいる方はSESとして働いている方の割合は多いです。
一つのシステムでも、画面など利用者に見える部分を作成する、フロントエンジニア
裏側の業務ロジックやデータベース設計を行うバックエンドエンジニア
サーバーやネットワークの環境を構築するインフラエンジニア
出来上がったシステムが正常に動くか日々チェックするシステム運用エンジニアなどの役割があり、システム規模が大きいほど、その中でも体制が組まれて役割が更に細分化されます。
ピラミットの上位の会社に行くほど、またベテランになるほど、開発業務よりは、人員管理のマネジメント業務色が強くなっていく傾向があります。
工程について説明していきます。
システム開発プロジェクトは、要件定義工程、各種設計工程、製造（プログラミング）、各種テストで世の中にリリースされます。
これは物凄くざっくりなので、もう少し詳しく説明していきます。
要件定義工程
要件定義工程はユーザーがシステムに求めるものや、システムに期待される役割や効果を明確にし、それを実現するために必要な機能を定義していく工程です。
一番初めの段階ですが、この工程でシステム開発の成否が決まるといっても過言ではありません。
システム業界の知識だけでなく、お客様の業務に関する知識も勉強する必要があります。
システムを発注する側のお客様は、ITに関しては素人の場合が多いです。
お客様の業務を理解し、それをフロー図などを使って明文化しながら、どの部分をどのようにシステム化していくかということを綿密に詰めていくことが必要になります。
イメージがあっているか確認する手法として、簡易な試作品のプロトタイプが使われることもあります。
また、ここで重要になるのは、データベースの論理設計です。E-R図と呼ばれるデータ項目同士がどのように関係しているかを図示します。たとえば、一人の顧客が予防接種を１回しか受けれないのか２回以上受けれるのかなどデータ同士の紐づきを見ることで、お客様の業務要件を読み取ることもできます。
近年、大量アクセスのサーバダウン、不正侵入などの問題がニュースをにぎわせて、それが起こると企業の信用は一気にダウンします。
非機能要件と呼ばれる、性能や信頼性、拡張性、運用性、セキュリティなどについてもこの工程で詰めておく必要があります。
成果物を、チェックし合う作業をレビューと言います。
作成した資料は、会社内で十分なレビューを行い、指摘事項を修正し、お客様側にレビューしてもらいます。
会議中に出た指摘は必ずメモして、その議事録を正式な文書としてお客様にチェックしてもらう必要があります。
システム業界で良くあるのが、言った言わない問題です。
口頭だけのやりとりだと、あとで口頭でいらないと言われた機能の漏れが指摘された場合、
それが文書として残っていない場合、どちらが追加費用を払うかなど大きな責任問題になることがあります。
すみません、もう一度言わせてください。
議事は全て残して合意を得るのを忘れないでください。
――
設計工程
次に設計工程です。
会社によって呼び方は違う可能性がありますが
ここでは、基本設計、詳細設計、プログラム設計に分けさせてもらいます。
基本設計はユーザーから見える部分の画面のレイアウトやそれぞれの機能の設計になります。
詳細設計は、画面で入力されたデータなどをどのように処理をするか等、主にサーバーサイド側の設計になります。
クライアントとサーバー間でどのようなデータをどのような形式でやり取りするかなどのインタフェース設計も重要になってきます。
システム構築は複数の別会社のシステムを跨る場合が多々あります。
例えば、会計機能はNTTデータ、顧客管理機能は富士通と言った風になった場合、NTTデータ側と富士通側で綿密に連携の調整を行っていないと、リリース直前のテストの段階でインタフェース設計ミスが発覚した場合、大きな手戻りとなってしまう可能性があります。
実際、この会社を跨った連携で不具合が多発する場合が多いので、この段階で十分な打合せとお互いの設計ドキュメントの整合性を確認する必要があります。
その他、運用監視設計も行います。
例えば想定外のデータが送信され、プログラムが異常終了した場合などは、運用部門を通して開発担当に連絡してもらう必要があります。
この、運用担当者などに通知する機能をシステム監視と言ったります。どういった場合にどのようなエラーをログに出力し、監視ツールに拾ってもらうかなども合わせて設計し、テスト工程でテストする必要があります。
プログラム設計は、詳細設計の内容をもとに各プログラムの動作や処理の流れなどを詳細に定義する工程になります。
お客様はプログラム設計は見せられてもわからない可能性が高いので、お客様レビューは詳細設計までとなることが多いです。
これも、レビューによる設計書の不具合 つまり設計バグが指摘されることがあります。
指摘が無ければ良いというわけではなく、過去の類似プロジェクトの数値などから、設計書の量に対する指摘件数が品質管理指標として決められています。
指標より指摘が少なかったら、レビュー方法の妥当性の確認、再レビューなどが行われる可能性もあります。指摘が多かったら原因の特定と、前工程のやり直しの検討が行われる場合もあります。
製造（プログラミング）
ここまでの工程を経てやっとプログラミングを行うことができます。
ただ、最近はフレームワークと言って色んな処理に必要な便利な機能が構造化されていたり、エクセルで作った判定表がそのまま取り込めたり、プログラミングにかかる時間は以前に比べて少なくなっています。
前工程の設計がしっかりできていれば、業務仕様が分かっていなくても設計書が読めて、プログラム知識があれば物は作れるので、海外に発注することも多くなってきています。
プログラミングが終わったら、今までやってきたそれぞれの工程に対する試験を行います。
試験は行き当たりばったりに行うのではなく、事前に試験書を作成し、レビューを行う必要があります。
これも試験毎に、品質管理指標が設けられ、不具合件数が予定より少なかったり、多かったりした場合等、原因の特定が行われ必要に応じて試験書や前工程の成果物の点検を行う場合もあります。
――――
試験工程
各試験工程について説明します。
単体試験は、プログラミングを行った担当者が、プログラムのモジュール単位で行う試験になります。他のプログラムから呼び出される場合や、呼び出す場合もありますが、あくまで単独の試験なので、呼び出される場合はドライバと呼ばれる、呼び出しツールを使ったり、呼び出す場合はスタブと呼ばれる、任意の値を返却するツールを使ったりします。
IF文の条件文などは網羅する必要がありますが、Java開発の場合はJunitなどのテスト効率化ツールが用いられることが多いです。
後続の結合試験は、プログラム同士を組み合わせて、お互いの呼び出しや処理が上手くいくかを確認する試験になります。この工程は、プログラム知識が必要なく、試験書の期待値になるかを確認する試験なので、人が足りない場合はIT業界の経験が浅い人が担当として追加されることがあります。
次に総合試験になります。（システムテストともいわれる）
構築したシステム全体で予定通りの機能を満たせているか、また機能や性能が仕様書通りに構築できているかを検証します。
実際の業務に即した形で行われるので、システムの日付をずらしながら、シナリオ試験も行われます。
複数人で全く同じタイミングで登録した場合に、データの不具合が発生しないかや、ツールを使ったアクセス負荷試験や２系統のシステムをあえて片系落とした場合に処理が上手くいくか、システムの切り替えがうまくいくかなども試験します。
会社間のインタフェース試験もここで行われますが、ここで設計ミスが見つかった場合は、手戻りによる進捗遅延が発生する場合あります。
最近は３６協定などで守られていますが、IT業界がブラックと呼ばれる、原因は試験工程で想定外の不具合が発生し、それが前工程に影響するほど、修正するドキュメントが増え、再度レビューや試験を行います。
それでも、納期に間に合わせるために稼働をあげる必要があるため、残業時間が多くなる傾向があります。
ただ、ここでの不具合を置き去りにしてしまって、世の中に出た後に発覚すると更に大変になるので、１つでも多くの不具合を刈り取る必要があります。
たとえ起こる確率が１千万分の１でも、ユーザが１０００万人いたら毎日発生します。
――
ここまでで、開発会社としての試験は完了で、最後に運用試験と呼ばれる、実際にシステムを使うお客様が行う試験が行われます。受入テストともいわれます。
お客様が最後に設計書のレビューを行ってから、月日がかなり経っているので、お客様の中には、当初要件定義工程では言っていなかった機能が実装されていないといわれる可能性もあります。
一番初めに、議事録をしっかりと言ったのはこの工程での言った言わない問題を刈り取るためでもあります。
この工程で重大な欠陥が発見されるとリリース日程に大きく影響しますが、試験のインプットは要件定義書なので、一番初めの要件定義工程で曖昧な部分を残さないということがいかに大切かということが実感できる工程でもあります。
---------------
ここまでの工程で上手く言ったら、実際にリリースの為のリハーサルを行います。
システム規模が大きくなるほど、リリース手順は複雑になり、担当者間の連携が重要になってきます。
旧システムから新システムに切り替える場合、旧システム担当と新システム担当で連携しながら作業を行うこともありますが、その切り替えに失敗すると両方使えなくなってしまう可能性もあります。
しっかりしたタイムスケジュール、体制を作成レビューし、何時までにだれがどの作業を行わないといけないのか、終わったら誰に連絡するのか、不具合が発生した場合のユーザーへの周知方法、リカバリ案など考えられるありとあらゆる状況に対して対応案を作成しておきます。
リハーサルの結果をもって、リリース判定会議を行い、顧客側の合意を得てリリース本番当日を迎えます。
リリース本番は何もトラブルが無いのが一番なのですが、ある程度の規模のシステムはトラブルが起きるのが当たり前と思った方がいいです。
トラブルが発生した場合の、報告・連絡・相談 復旧に向けての調査・対応が長時間に及ぶことがありますが、これを乗り越えてシステムが安定稼働した時の喜びは何にもかえがたいものがあり、この業界にいて良かったと思える瞬間でもあります。
システム業界というと、工学部などの理系出身というイメージがあるかもしれませんが、文系出身の方もかなり多いです。
ここまで、見てもらったように、プログラミングよりもはるかにドキュメント作成や試験や打合せが多い業界で、年齢が上がり業務幅が広がるにつれてコミュニケーション能力が非常に重要になってきます。作るシステムが変われば、その業界のお客様の業務内容を１から学ぶ必要も出てきて、技術要素だけでなく、各種業界知識も学べます。
大学でプログラミングを習っていても、実践を通して学ぶことが多く、いかに会社に入ってからの勉強を絶え間なく行うかということが重要になってきます。
初めは業界用語もわからないと思いますが、基本情報技術者試験レベルの内容は、浅く広くIT知識が学べるので入社前に理解していた方が良いです。業務で役に立たないとか言われることがありますが、知っていて当たり前のレベルだと思って勉強した方が良いです。
大企業になると、昇進の必須条件になることも多いです。
私は、情報処理技術者試験のおかげでかなりの恩恵が得られています。
ここまでアプリケーションエンジニアの業務を中心に話してきました。
ネットワークなどを支えるインフラエンジニアの業務ついて、
先日大学の試験で論文を作成して高得点頂けたのでここで紹介しておきます。
※ただすみません、これは私の経験から書いているので、佛教大学の方は、この内容は参考までにしてください。丸写しは処分対象なので気をつけてください。
――――
【新しいサービスや機器の導入】
近年はIT化が急速に進んだことで、ネットワーク管理に関する維持・運用コストが以前に比べて増大している。
しかし、ネットワーク機器においても技術革新が進みつつある。その１つとしてSDNがある。
SDNはソフトウェアによって制御されるネットワークという意味で、今まで物理的なネットワーク機器が制御していたものが、仮想機器に置き変わることによって、ネットワークの維持・運用コストを大幅に削減できるというメリットがある。
このような新しいサービスや機器を導入する場合は、そのサービスが既存どの部分に置き変わるのか、それにつながっている機器への影響調査など十分に行わないと最悪の場合、ネットワークが繋がらずサービス停止してしまうリスクもある。
新規にサービス・機器を導入する場合は、十分な事前調査、設計を行い、本番切り替え前のリハーサル等も十分に行う必要がある。
【トラブル対応】
ネットワーク監視等によって、障害（トラブル）が発生した場合、関係者との連絡、ユーザーへの周知の必要性、原因調査等が必要になってくる。
起こりうるトラブルは様々な事象があるが、例えば、スイッチの異常検知、LB片系ダウン、ネットワークトラフィックの増加等あらかじめ起こり得るトラブルのパターンを考えることは可能である。
トラブルが起きた場合、復旧に向けて迅速に対応し、信用を損ねない「体制」をあらかじめ決めておくことが大切である。
２４時間稼働しているシステムは、深夜（業務時間外）にトラブル可能性は高い。監視（運用）部門で対応できる範囲ならいいが、そこで手に負えないパターンの場合、機器ベンダへの連絡体制など、会社を跨った体制を作ることも多い。
つまり、リリース前に十分なトラブル対応に対する体制を作成し、リハーサルできるものはリハーサルをすることが重要である。
【ネットワーク監視】
ネットワーク機器は物理的なものなので故障が起きることがある。また近年は不正アクセスなどが問題になっている。
このような機器の異常や社内・外からの不正アクセス等をチェックするための仕組みである。
監視を行う上で、例えばネットワークトラフィックが80％を超えたら警告、95％ならば重度障害など、監視する上でどのような状況の場合に重度障害として扱うか等、監視を行う上で十分な設計・レビューを行う必要がある。
また、サービスイン当初はユーザー数が少なかったりしても、徐々に増えていってネットワークトラフィックが増加する可能性があるため、監視の閾値などは常に見直す必要がある。
【データのバックアップ】
機器の故障等により、データベースサーバやファイルサーバに格納されたデータが消えたりする場合がある。
また、人為的なミス等によって、データを消してしまったり書き換えてしまったりする可能性もある。
そうした場合、バックアップがあればそのバックアップを取得した時点まで復旧が可能である。
バックアップを取得するということは、データの複製を持つということで、例えば１日１回５世代のバックアップを取得するとなったら、元のデータが１GBとしたら、バックアップ領域だけで５GBも必要になってしまう。
バックアップの取得は行うべきだが、ストレージも有限であるため、どのタイミングでバックアップを取得するか、バックアップ自体を消してよいタイミングをあらかじめ決めておく必要がある
【セキュリティ対策】
ネットワーク管理者としてのセキュリティ対策で一番初めに思いつくのが、
ネットワークの境目に設置するファイアウォールのフィルタリングルールの設定である。
不用意にポートを開放してしまうとそれがセキュリティホールになってしまう。
どのサービスが外部からアクセス可能なのか、アプリケーションエンジニアも交えて設計し必要最小限のIP、ポートのみファイアウォールを通過できるようにする必要がある。
また近年は、社内PCへのセキュリティパッチ自動適用など一元管理できるEDRツールの導入も進んでいる。
暗号化されたメールの添付（マルウェア）ファイル等のファイアウォールで防げないものに関して、社内ネットワークへのマルウェア対策も行うことが重要である。
【ユーザーサポート】
最近はクラウド環境でサービスを提供する業者が増えている。
サービスの利用者側からしてみたら、わからないところを迅速に回答してくれるユーザーサポートの体制は重要である。
近年は、夜間でもチャットベースで調査回答してくれるサービスが多くなってきている。
扱うものは機械的なものでも、こうした人と人とのつながりを意識したユーザー目線でのサポートは企業の信用を勝ち取るうえでは重要な位置づけにある。
【IT業界の真実】未経験から就職される方へ/人気IT企業ランキング ブラック？プログラミング
ここまで私の経験でIT業界の仕事をお話しさせてもらいました。
会社によっては自社で全て行っている場合もありますが、大手SI企業やその関連会社の例として参考にして頂けると幸いです。
最後までご視聴ありがとうございました。
この記事が気に入ったらサポートをしてみませんか？