【IT業界全般】IT業界の仕事
ここではIT業界の仕事について簡単に解説します。
IT業界の仕事とは
ITとはInformation Technologyの略。
直訳すると情報技術。
IT業界の仕事とは、ざっくりと言ってしまうと、情報技術を使ってお客様に対して何かしらサービスを提供する仕事になります。
情報技術と言われてもピンとこない方も多いかもしれません。
要はコンピュータ、あるいはコンピュータ上で動くプログラムを作ること、作ったものを使って何かしらの価値を提供する仕事です。
ではコンピュータとはそもそも何でしょうか。
コンピュータと聞いてパッと思いつくのはスマホやパソコン、タブレットなどでしょうか。
もちろんこれらはコンピュータに該当しますが、実は世の中はコンピュータであふれています。
電車や車や飛行機など、乗り物のもコンピュータが組み込まれていますし、駅の改札や信号などもコンピュータで制御されています。
テレビや冷蔵庫など、家電にもコンピュータが組み込まれていて、今の世の中はコンピュータがなければ成り立たないと言っても良いでしょう。
そういったコンピュータに関するモノづくりをするのがIT業界の仕事です。
インターネットに接続されていれば、SNSやネットショッピングなどをする人も多いでしょう。
インターネットを通じて利用するサービスはサーバーと呼ばれるコンピュータの上で動いており、このようなサービスを作るのももちろんIT業界の仕事です。
ただし、IT業界の中でも職種は様々です。
プログラマー、システムエンジニア、Webデザイナー、プロジェクトマネージャー、ITコンサルタントなど、職種は様々で、必ずしもモノづくりをする人というわけでもありません。
直接モノづくりに関わる人はエンジニアやプログラマーと呼ばれます。
また、一口にエンジニアと言っても、その中でも業種は色々と分かれています。
Web系、業務系、スマホアプリ、組み込み系、AIなど、どんなプログラムを作るかによって細かく分かれてきます。
プロジェクトマネージャーなどは直接モノづくりには関与せず、お客さんやチームのメンバーのマネジメントの仕事がメインになりますが、これももちろんIT業界の仕事になります。
プロジェクトが何かについては次で説明します。
プロジェクト
IT業界の仕事は、ほとんどの場合プロジェクトという単位で行われます。
IT業界に限らず、正社員として働いている人たちは、プロジェクトという単位で仕事をしている人達が多くいます。
ではプロジェクトとはいったい何でしょうか。
簡単に説明すると、「ある目的達成のために、限られた期間の中で行う業務」です。
これだけだと抽象的でイメージしにくいかもしれません。
プロジェクトを理解するためには、プロジェクトではない業務と比較する方が理解がしやすいでしょう。
仕事には、大きく分けて2つの業務があります。
ライン業務とプロジェクトです。
ライン業務とは、日々同じ業務の内容を繰り返すような仕事のことです。
例えば、工場での仕事はそのような仕事になりますし、飲食店や小売店など、いわゆる一般顧客向けのサービスを提供している仕事に多いのがライン業務です。
タクシーやバス、トラックの運転手といったドライバーなどもライン業務にあたるでしょう。
ここで、小売店の場合を考えてみます。
小売店では、一日の中の仕事はある程度決まっています。
品出しをして、レジ・接客業をして、レジ締めをして終了する。
もちろん、他にも細かい作業は色々あるかと思いますし、日によって微妙にやることは変わってくるかもしれません。
また、月末になると棚卸などの特殊な業務も入ってくることでしょう。
しかし、1年を通してやる仕事というのはある程度決まっていて、似た内容の業務を繰り返していくことになります。
これがライン業務です。
一方、プロジェクトというのは、同じことを繰り返すわけではありません。
目的があり、期限があり、決められた期限内に目的を達成するために特定のメンバーが集められて割り振られた業務をこなしていきます。
例えば、建築などが最も分かりやすい例でしょう。
新しい建物を立てる時、どこに、いつまでに、どんな建物を建てるのかが最初に決められます。
その後、完成に向けて、必要に応じて必要なメンバーが集められて、役割分担しながら作業を進める。
これがプロジェクトです。
IT業界も考え方は建設業と同じです。
作るものが建物からソフトウェアという目に見えない製品に変わるだけです。
学生の場合アルバイトとして働くこともあるかと思いますが、アルバイトで行う仕事はほとんど場合ライン業務でしょう。
また、普段生活している中で仕事をしている人と接する機会は、お店の店員や運転手の人など、ライン業務に分類される人たちの方が多いでしょう。
そのため、学生までは仕事のイメージはライン業務の仕事をイメージする人が多いかもしれません。
しかし、社会人として働き始めると案外プロジェクトという単位で仕事を進めている人も多いです。
IT業界の仕事はほとんどがプロジェクトという単位で進むと説明しましたが、一部ライン業務に近い仕事もあります。
それは、プロジェクトが一旦完了してシステムをリリースした後の保守の業務です。
保守の業務は、実際にシステムを使っているユーザーからの問い合わせに対応したり、細かなバグの修正、機能追加などの業務を行います。
規模の大きなシステムになれば、そのシステムの保守を専属で行う人もいます。
バグ修正や機能追加に関しては期限を決められる場合もありますが、内容によってメンバーが変わったり細かなスケジュールを決めたりすることはほとんど場合はありません。
そのためプロジェクトよりもライン業務に近い仕事になるでしょう。
開発工程
ITの仕事、その中でも特にプログラマーやシステムエンジニアと呼ばれる人たちの仕事はどのような仕事をイメージするでしょうか。
パソコンに向かってプログラミングという作業をしてプログラムを作る。
そういうイメージを持っているかと思います。
では、ITの仕事では、作りたいプログラムがあるとき、プログラマーを集めていきなりプログラムを作る始めるのでしょうか。
実はそんなことはありません。
ITの仕事には開発工程と呼ばれるものがあり、いくつかの過程を経てプログラミングという作業に入ります。
具体的な開発工程（開発の流れ）は以下の様になります。
1つ1つを工程とかフェーズとか呼んだりします。
これは一般的な開発工程ですが、プロジェクトによって、あるいは企業によって微妙に変わってくるところはあるかと思います。
BtoB(企業向けのサービスを作る仕事)なのか、BtoC(一般顧客向けのサービスを作る仕事)なのかによっても変わってきます。
ITの仕事のイメージは、スマホアプリとかWebサービスといった、個人のユーザーを対象にした仕事のイメージが強いかもしれません。
しかし、実際にはBtoBの仕事を行うIT企業の方が多いを考えた方が良いでしょう。
話を戻すと、この各工程の中で、ほとんどの人がITの仕事と聞いてイメージするであろうプログラミングというのは実は5の製造の部分だけで、意外にも少ないことが分かります。
ではなぜいきなりプログラムを作り始めることをしないのでしょうか。
これも建築を例に考えてみると分かりやすいかと思います。
建物を作るとき、何もない土地にいきなり大工の職人さんを10～20名集めて、「さあ、いい感じの建物を作りましょう」と言っていきなり作り始めたらどうなるでしょう。
おそらくうまくいかないでしょう。
設計図やコンセプトなどが何もない状態だと、完成形のイメージが人によってバラバラかもしれませんし、役割分担もうまくいきません。
建物を作るなら、まずどんな建物を作るのか。
大きさやコンセプトなどを決める必要があるでしょう。
そこから外観や中の構造、各部屋の間取りなど、色々と決め、設計図を作り、そして誰がどの部分を担当するのかをスケジューリングする。
そこまでしてようやく実際の現地での作業に取り掛かれるのではないでしょうか。
これはIT業界においても同じです。
作るものが物理的なものからソフトウェアに変わるだけで、やはり最初にどんなものを作るのか、その完成形やコンセプトなどを共有する必要があります。
そして画面の外観などを決め、それぞれの機能の対する詳細に落とし込んでいく。
それらを役割分担しながらスケジュールを決めることでようやく実際のものを作り始めることができるのです。
ということで、ここからはそれぞれの工程について説明していきます。
システム企画
システム企画はその名の通り、どんなシステムを作るのかを決める工程になります。
ここはエンジニアというよりもシステムを依頼するユーザー側によって決められます。
対象の企業、あるいは世の中に対してどのような課題があり、それを解決するためにどのようなシステムを作るのかを決めます。
当たり前ですが、システムというのは使ってもらわなければ意味がありません。
価値のあるシステムにするためには、なぜこのようなシステムを作るのかを明確にしておくことは重要です。
要件定義
要件定義は、システム企画で決まったシステムに対して、どのような機能や要件が必要かを決めている工程です。
特定の企業に向けたサービスを作る場合には、使用する企業の担当者の人と打ち合わせをしながら決めていくことになります。
ITの仕事というのは、本質的には問題解決です。
企業が抱える課題をITの力で解決していくのがITエンジニアの仕事です。
そのため、要件定義ではお客さんの企業の抱える課題は何のか、そしてそれを解決するためのどのような仕組みが必要なのかを決めていく必要があります。
そういった意味では要件定義はコミュニケーション力が必要な工程と言ってもいいでしょう。
もちろん、課題をどう解決するのかを決めていくにあたり、ITの知識はもちろん必要ですが、それよりもお客さんの「本当の課題」を引き出すための聞く力、ヒアリング力が必要とされる工程です。
そうやってコミュニケーションを取りながら、必要な要件、機能などを洗い出していく作業が要件定義です。
実際に開発の経験をしていない人にとっては、要件定義はそれほど重要な工程には思えないこともあるかもしれません。
しかし実際には要件定義をきっちり行っておくことは重要です。
後の工程になって必要な機能や要件が漏れていたことが発覚すると、設計からやり直すなど、多くの手戻りが発生してしまいます。
手戻りが発生するとその分大きなコストがかかり、プロジェクトの失敗のリスクが非常に高くなります。
基本設計
基本設計は名前の通り設計を行う工程。
外部設計と呼ばれることもあります。
要件定義で決めたことをもとにして全体像を設計していきます。
基本設計の工程で作成する成果物の一式を基本設計書と呼びます。
基本設計書で何を作成するかについては細かくはプロジェクトによって異なります。
例えば、画面のイメージ（UI）を決めたりします。
画面設計はお客さんと共有することも多いので、お客さんに分かりやすいように図を用いたりしながら作成していきます。
フローチャートを使ってお客さんの業務の流れを図にしたり、UMLと呼ばれるモデリング手法を使って図を作成する場合もあります。
一般的にお客さんはプログラミングに関する専門的な知識は持ち合わせていないことがほとんどです。
そのため、プログラマーでなければ分からないような用語は使わず、ユーザーに分かる用語で作成することが求められます。
建築でいうところの建物の全体の図面を作るイメージに近いかもしれません。
詳細設計
詳細設計は、プログラマー向けの設計の作業です。
内部設計などと呼ばれることもあります。
基本設計を元に、1つ1つのプログラムの詳細を設計します。
詳細設計書は通常はお客さんと共有することは少なく、内部のプログラマーに向けて作成する書類になります。
そのため専門的な部分まで踏み込んで詳細を決めていきます。
特に重要なのは名前の付け方です。
プログラミングでは何かに対して名前を付けることが頻繁にあります。
ファイル名、クラス名、メソッド名、関数名、変数名、テーブル名、カラム名、などなど。
それぞれの名前を適当に決めてしまうと、個々のプログラムを結合して全体を動かしたときに様々なバグの温床になります。
そのためどのような名前を付けるのかをあらかじめ決めておくことが重要になります。
名前に限らず、処理の流れなど、詳細設計書に書いておいた方が良い情報は数多くあります。
細かな情報をどこまで書くかはプロジェクト次第でもあり、設計者次第でもあります。
設計書を細かく書くには、設計者がプログラミングについて知見がある必要があります。
プログラミングに知見のない設計者が設計書を細かく書くと、逆にプログラマーに負担をかけてしまう場合もあります。
製造（プログラミング）
ここまできてやっとプログラミングの作業です。
プログラマーは詳細設計の工程で作成された詳細設計書を見ながらプログラミングを行い、仕様に沿うプログラムを作っていくことになります。
プロジェクトによもよりますが、一般的にこの工程になると一気に人員が増える傾向にあります。
なぜなら、プログラミングはITエンジニアの中でもできる人が多いからです。
一般に、ITエンジニアになると、最初に学ぶものがプログラミングです。
そして、多くの人は現場ではまずプログラミングの工程で経験を積みます。
そして、ある程度経験を重ねて業務の知識や実力が付いてくると徐々に詳細設計、基本設計、要件定義という工程で活躍できるようになってきます。
一般に、プログラミングの工程を行う人をプログラマー、設計や要件定義を行う人をシステムエンジニアと呼ぶことが多いです。
もちろん企業によって、あるいは人によってどのようなキャリアを選ぶかはそれぞれですが、数年間プログラマーを経験して、そののちにシステムエンジニアとしての役割を担う人が多くなります。
ということで、プログラマーはシステムエンジニアに比べて比率が多いため、プログラミングの工程に入るとプロジェクトに参画できる人が増えるのです。
ただし、詳細設計書の質によってプログラムの品質も変わってくるので、そのあたりは注意が必要です。
テスト工程
ここからはテストの工程に入ります。
開発工程の一覧をザっと眺めてみると、テストとつく工程がやたらとたくさんあります。
単体テスト、結合テスト、システムテスト、運用テスト、、、
どれだけテストするんだという話ですが、実はシステム開発というITの仕事において最も時間がかかるのがテストの工程だったりもします。
もちろんプロジェクトにもよるかとは思いますが。
テストというのはいわゆる確認作業の事。
作ったプログラムが仕様の通りにきちんと動くのかどうか確認する作業です。
操作してたらいきなりエラーが出て画面が終了したら困りますね。
エラーが出なかったとしても、設計書の通りに動かなかったら困惑しますね。
使っていて、ユーザーがとても操作しにくいつくりになっていたら困りますね。
速度がとんでもなく遅かったら辛いですよね。
そういった困ったことが起きないよう、作ったものは様々なテストを行う必要があります。
単体テスト
単体テストは、機能単位、あるいは画面単位で行うテストになります。
プログラミングとセットで、プログラマーが実施することも多いです。
結合テスト
結合テストは、その名の通り、それぞれの機能を結合した状態で正しく動くかどうかをテストする工程です。
単体テストでそれぞれの機能や画面で問題がなかったら動くんじゃないの？
と思うかもしれません。
確かに、1人で全てのプログラムを作っているのだとしたら、単体テストで問題がなければ、結合テストでもそこまで大きな問題は起きないかもしれません。
しかし、製造の工程は数名、規模の大きいプロジェクトだと10名以上、20名以上の人数でプログラミングすることもあります。
そうなった時、全員が同じ認識を持ってプログラムを開発している保証はありません。
詳細設計書がきちんと作られていれば、問題は発生しにくいかもしれませんが、詳細設計も1人だけでやるわけではありません。
やはり、それぞれで作ったプログラムを結合したときに初めてわかる不具合も多いのです。
そういう意味で結合テストも重要な工程になります。
システムテスト
結合テストまでは、作ったプログラムが仕様書通りに動くかどうかのテストです。
結合テストまですれば、問題ないのでは？
と思うかもしれません。
しかし、プログラムを作っているときの開発の環境ではうまくいっても、実際にシステムを運用させる本番環境になるとうまくいかなくなることもあります。
また、本番の運用で使う実際のデータを使ってうまくいくかどうか、といった確認作業も必要になるのです。
この、本番の環境に合わせたテストがシステムテストです。
運用テスト
運用テストは、実際にシステムを利用してもらうユーザー自身に使ってもらって問題がないかテストしてもらう工程です。
ここで問題が起きなければ、システムをリリースすることになります。
リリース
実際にシステムをお客さんに引き渡し、使ってもらいます。
保守
一度完成したシステムは、リリースしてそれで終わりではありません。
（そういうケースもなくはないですが。）
リリースした後も細かな不具合が発生する可能性はあるし、新しい機能の要望が発生するかもしれない。
そうなった時にバグ修正や新しい機能の追加をしていくのが保守の工程です。
これは、リリースされた後からシステムが入れ替わるまで続く長い工程です。
以上が開発工程になります。
経験してみないと詳細は分からないかもしれませんが、漠然とイメージができると実際に仕事をするときにスムーズかもしれません。
WBSとスケジュール
スケジュールの重要性
スケジュールとは計画、予定のこと。
おそらく、多くの人はスマホやパソコンのカレンダーアプリやGoogleカレンダーなどに何かしらの予定を入れていることでしょう。
シフト制の仕事をしている人は、出勤日の予定を入れたり。
何かしらのイベントがある日は、イベントの予定を入れたり。
誰かと遊びに行く予定、美容室に行く予定、病院に行く予定、など、色々な予定を1日単位、あるいは数時間単位で入れていることでしょう。
こういった予定の一覧を一般にスケジュールと呼びますね。
スケジュールを考えることは仕事全般において大事なことですが、特にプロジェクトという単位で仕事をするにあたっては、事前にスケジュールを考えることが大事です。
プロジェクトはまずゴールの期日が決まっています。
IT業界の仕事でいえば、作成するシステムの最終的な納品日（リリース日）が期日になります。
プロジェクトではゴールから逆算して、それぞれの工程の完了予定日を決めていくことが大事です。
テストの完了予定はいつなのか。
製造（プログラミング）の完了予定はいつなのか。
という風に、ゴールから逆算して各工程ごとにいつ完了予定のスケジュールを立てていきます。
学生の頃に受験勉強や、資格試験の勉強をしたことがある人なら、試験日から逆算して勉強の計画を立てたことがある人もあるでしょう。
プロジェクトもそれと同じです。
ここからは私の個人的な考えになりますが、スケジュールを立てることは仕事においてとても大事ですが、スケジュール通りに仕事を進めていくことはそれほど大事ではありません。
もちろん、進めている途中で何事も問題が起きず、全てがスケジュール通り順調に進むのであれば、それに越したことはありません。
しかし、多くの場合、仕事というのはスケジュール通りには進みません。
必ず何かしら想定外のことが起きます。
ただ、スケジュールを事前に立てておけば、どこでどうリカバリーするかという対策を立てやすくなります。
仮にスケジュールを立てていなかった場合、どうやって立て直していくかの見通しを立てるのが難しくなります。
何か問題が起きたとしても、安心して仕事を進めることができるように、予めスケジュールを立てておくことが大事になります。
また、スケジュールは作業の効率化を図るという点においても重要な役割を果たします。
いかに速く仕事をこなせるかという点においては、個人の能力ややる気がすごく重要です。
しかし、期限を決めずに何となく始めたしごとは、いかに能力ややる気が高い人だとしても、集中力をキープすることが難しく、なかなか効率が上がらなくなります。
しかし、予め期限を決めておいた仕事は、その期限を意識することで集中力が上がり、結果として仕事の効率が上がります。
まとめると、スケジュールというのは、安心して仕事を進めるため、そして効率よく仕事を進めるために必要なものということです。
重複して伝えますが、仕事をスケジュール通りに進めることが大事なのではなく、仕事を円滑に進めるためのツールとしてスケジュールという手段が重要なのです。
WBSとは
ここで、スケジュールと大きな関係があるWBSについて書きます。
WBSとは、Work Breakdown Structureの略で、プロジェクトの仕事を細かい作業の分割してまとめたもので、作業分割図などとも呼ばれます。
先ほど、プロジェクトはスケジュールを立てることが大事だと書きましたが、実はスケジュールを作成することは簡単なことではありません。
経験のあるエンジニアやリーダーの人でも、妥当性のあるスケジュールを作成するのは非常に難しいのです。
なぜスケジュールを作成するのが難しいのか。
1つの要因としては、それぞれの作業にどれくらいの時間がかかるのかをイメージするのが難しいためです。
ではどうすれば作業の時間をイメージしやすくなるのか。
作業を細かく分けることで、作業時間がイメージしやすくなります。
また、スケジュールの作成というのは期限を決めるだけではありません。
複数人いるチームの各メンバーに対し、どの作業を実施してもらうのか、その役割分担を決める作業も含まれます。
試験勉強の場合、自分一人だけの都合でスケジュールを作成することができました。
しかし、プロジェクトというのは複数人で一つの仕事を進めていきます。
複数人で役割分担しながら時間を管理するため、スケジュールを作成する難易度が高いのです。
誰がいつ、どのくらいの期間でどの作業をするのか。
こういった細かい役割分担とスケジュールの作成というのは、作業が細かく分かれていないとできません。
そのために必要なものがWBSです。
スケジュールを作成するときには、全体の作業を細かく分類分けする作業が重要になるということを知っておきましょう。
プロジェクトの失敗と成功
プロジェクトというのは、成功するともあれば失敗することもあります。
ただし、そのプロジェクトが成功したのか失敗したのかは、成功や失敗の基準によっても異なります。
失敗と考える要因としては、
- 期限内に終わることができなかった
- 予算を大幅にオーバーしてしまった
- 機能を大きく削ってのリリースとなってしまった
- 納品したが、その後障害が多く発生し、クレームが多発した
などなど。失敗と考えられる要因は実に様々です。
成功するか失敗するかはもちろんプロジェクト次第ですが、一般に、規模の大きなスケジュールほど成功させるのは難しくなります。
なぜなら、規模が大きいほど、関わる人の数が増え、そして機能も増えるため、スケジュールの作成が難しくなります。
機能や人数が増えると、想定外のトラブルなども発生しやすくなります。
そうなると、スケジュール通りに進まなくなり、リカバリーすべきことが増え、期限に間に合わせることが難しくなります。
また、プロジェクトに参加するメンバー多くなると、コントロールも難しく、コミュニケーションの時間が増えることで作業を効率化することが難しくなったりもします。
プロジェクトが成功するか失敗するかは色んな要因が重なり合って決まるため、一概にどうこう言えるものではありませんが、一般に規模が大きくなるほど難しくなると考えておきましょう。
PDCAサイクル
PDCAサイクルという言葉をご存知でしょうか。
PDCAは、それぞれPlan(計画)、Do(実行)、Check(確認)、Act(改善)の略です。
これは、この4つのサイクルを回すことで、業務プロセスの改善を図るための枠組みです。
先ほど、プロジェクトというのは、成功するものもあれば失敗するものもあると話しました。
そして、実際にはかなり高い確立で失敗します。
失敗とまではいかなかったとしても、改善すべき点というのはそれなりにあるものです。
全てが完璧で見直すところがないプロジェクトなんでものは、ほぼほぼ存在しないと思っても良いでしょう。
ただ、やはり仕事をしていく上では、1度やってしまった失敗や改善点は次に活かしていきたいものです。
そのための取り組みがPDCAサイクルです。
プロジェクトが終わったら、当初のスケジュールと実績を見比べながら、良かった点、改善すべき点をまとめ上げて、次のプロジェクトに活かします。
PDCAサイクルはプロジェクトに限った話ではありません。
仕事をしていく中では、同じ失敗を繰り返さないようにし、効率化したり、質を上げたりすることが重要です。
必ずしもPDCAという枠組みに当てはめる必要はありませんが、仕事は一度終われば終了ではなく、終わった後に振り返りを行って、改善策を模索していくことが重要だと知っておきましょう。
