IT業界の仕事の流れ
ここでは、IT業界の仕事の全体の流れを説明します。
ライン業務とプロジェクト
まず、IT業界の仕事内容を理解する前に、
仕事の種類を把握しておきましょう。
仕事は、大きく2つに分けられます。
- ライン業務(定常業務)
- プロジェクト(案件)
の2つです。
IT業務はどちらに分類されるでしょうか。
正解はプロジェクトです。
プロジェクトを説明する前にライン業務から説明していきます。
ライン業務は、常に流れている業務のことで、
基本的に同じことを繰り返す仕事のことです。
お店で働く人をイメージするとよいでしょう。
お店で働いている人は、
商品を発注し、商品を仕出しして、お客さんが来たら接客をします。
1日1日、やることは微妙に変わってくるとは思いますが、
1年を通して大体やることは決まっています。
お店以外でも、工場や事務で働いている人もライン業務に該当します。
一方でプロジェクトとは、
ある目的のために決められた期間で活動する業務のことです。
ITの仕事、特にシステム開発の仕事は基本的にプロジェクトに該当します。
4月～6月まではAプロジェクト、7月～10月まではBプロジェクト、
という風に、一つのプロジェクトが終わったらまた次のプロジェクト、
というサイクルで仕事をします。
プロジェクトによって、求められる成果物、期間、メンバー、働く場所などが変わります。
開発工程
IT業務内容はプロジェクト毎に細かい部分が異なります。
とはいえ、プロジェクトの開始から終了までの一連の流れは大枠決まっています。
主な流れとしては
といった流れです。
それぞれの要素を「工程」と呼びます。
ITの仕事というと、パソコンの前でプログラミングしているイメージが強いかもしれません。
しかし、プログラミングの作業というのは、
ここでいうと「製造」と「単体テスト」の部分で、
IT業界の仕事全体の中でいうと実はそれほど多いわけではありません。
プロジェクトによもよりますが、全体の2～3割程度だと考えていいでしょう。
要件定義
要件定義は、お客さんからヒアリングをして、
要件定義書にまとめる工程を指します。
要件定義で求められるのは、「聞く力」と「問題解決力」です。
ITの知識はもちろん必要ですが、それよりも重要なことは、
お客さんにとっての本当の課題は何か、を導き出すことです。
課題と、それに対する解決が適切でなければ、
価値のあるシステムを提供することはできません。
聞くことに徹して、課題を洗い出し、解決策となるシステムの機能要件をまとめる作業が要件定義です。
UMLやフローチャートなど、図を使って分析をすることもあります。
基本設計
要件定義書を元にシステムの設計を行う工程です。
外部設計と呼ばれる場合もあります。
基本設計では主にユーザーの使い勝手に関する設計を行います。
例えば、画面のレイアウトや、画面遷移などです。
基本設計で作成した設計書は、お客さんにも提出するのが一般的です。
なので、プログラムに関わる細かい仕様などは記載せず、
お客さんが理解できる内容で、
分かりやすく書くことが求められます。
詳細設計
基本設計書を元に、実際にプログラミングができるレベルの細かな設計書を作成する工程です。
内部設計と呼ばれる場合もあります。
これは、プログラマーの人が見るもので、お客さんには提出しません。
なので、プログラマーの人がそれを見てプログラミングができるものを作成する必要があります。
Excelを使って作成されることが多いですが、書き方は人によってもプロジェクトによっても様々。
要は、プログラマーの人がその資料を見てプログラミングできる資料を作ることが大事です。
製造
いわゆる、プログラミングをする工程です。
プログラマーが活躍するのはこの部分です。
プログラミングのことは、製造と呼んだり、実装と呼んだり、呼び方もいろいろです。
テスト工程
プログラムというのは作って終わりではなく、そのあとにテストが必要です。
プログラムが出来上がっても、それが正しく動かなければ使い物になりません。
正しく動くかどうかを確かめるため、そして不具合を発見するためにもテストが必要です。
一言にテストと言っても、いろいろな種類があり、
単体テスト、結合テスト、システムテスト、運用テスト
などに分かれます。
実はシステム開発はほとんどの場合テストが最も時間のかかかる工程になります。
なぜそこまでテストに時間をかけるかというと、
プログラムというのはそれだけ不具合が発生しやすいものだからです。
人間の手で作っている以上、絶対に完璧というのはありません。
ですが、使ってもらう以上不具合はできるだけ少ない方が良いです。
そのために、多くのテストを実施するのです。
単体テスト
単体テストは、画面単位やファイル単位でプログラムをテストする工程です。
製造の工程に含まれている場合も多く、ほとんどの場合プログラマーの人が実施します。
詳細設計書に書かれている内容を元に、単体テスト仕様書と呼ばれる資料を作成し、
その仕様書を元にテストを実施していきます。
単体テストは英語ではユニットテストと呼ばれます。
プログラミング言語によっては、単体テスト用のツールが用意されていることもあります。
Javaの場合はJUnitというツールがよく使用されます。
XXUnit(XXは言語や環境によって異なる)という名前で提供されていることが多いです。
結合テスト
単体テストは、画面単位でのテストですが、
結合テストでは、全体を通してのテストになります。
画面単位ではうまくいっても、全体で連携を取ろうとするとうまくいかない場合もあるので、
単体テスト後に全体で整合性が取れているかを確認することが必要になります。
それを確認するのが結合テストの工程です。
システムテスト
システムテストは、実際にシステムをリリースする環境で、
実際のデータを使ってテストする工程です。
通常、結合テストまでの工程は、プログラムを開発している環境で実施します。
しかし、開発環境と実際にシステムを運用する環境が同じとは限りません。
なので、リリースする前に実際の環境で動作を確認する必要があります。
また、開発の時は、テスト用のデータを使って開発をする場合がほとんどですが、
実際のデータを使って不具合が出ないとも限りません。
本番の環境を使って問題がないかを確かめるのがシステムテストです。
運用テスト
運用テストは、システムをリリースする前にユーザーに使ってもらう工程です。
システム開発では、リリースした後にユーザーから「思っていたのと違う！」
なんて言われることも珍しくありません。
実際にリリースして大きなトラブルが発生しないように、
事前にユーザーにテストしてもらう工程です。
様々な開発モデル
システム開発の大まかな流れは上記で説明した通りですが、
開発の流れとは別に、開発モデル呼ばれるものもあるので、
それについても軽く紹介します。
ウォーターフォールモデル
ウォーターフォールとは、水が上から流れ落ちていく様子を表していて、
つまり、最初に要件定義を実施して、それが終わったら基本設計を実施します。
基本設計が終わったら詳細設計に入り、それが終わったら製造に入ります。
このように、開発工程を上から順番に実施していく開発モデルをウォーターフォールモデル、と言います。
このモデルでの欠点は、後になって要件定義での要件漏れや修正が発生した場合に、
手戻りが多くなるという点です。
プロトタイプモデル
プロトタイプとは、試作品のことです。
先にプロトタイプを作って、ユーザーに確認してもらいます。
そこで問題がなければ、開発工程を進めていく、というモデルです。
スパイラルモデル
スパイラルモデルは、システムを機能単位で分けて、
それぞれの機能でプロトタイプによる開発を行う手法です。
プロトタイプモデルとスパイラルモデルは、
先にユーザーに確認してもらえる分、
ウォーターフォールモデルより手戻りは少なくなります。
ただ、実際にプロトタイプモデルで開発していたプロジェクトを見たことがありますが、
試作品を作ることにかなりの労力を使っていて、
正直、大変そうだな～と思ったりしました。
開発工程や開発モデルで、アジャイル型開発や、DevOpsという言葉もよく出てきます。
これらは開発モデルというより、開発における思想のようなものです。
詳しくは掘り下げませんが、勉強しておいて損はないです。
プロジェクトで失敗しないためには
ここまでで
- プロジェクトについて
- 開発工程について
- 開発モデルについて
を紹介しましたが、最後にITのプロジェクトについて大事なことを書いておきます。
多くのITプロジェクトに共通している性質は、「失敗する」ということです。
失敗した原因はプロジェクトによって様々で、一概には言えません。
その中で一つだけ言えることは、多くのプロジェクトは同じ失敗を繰り返す、ということです。
過去に似たようなプロジェクトで似たような失敗を経験した。
にもかかわらず、同じ失敗を繰り返します。
なぜ同じ失敗を繰り返すのか。
これも、要因は様々考えられます。
個人的な見解で一つだけ言えるのは、プロジェクトが失敗すると分かった時点で、
諦める人間が多いという事です。
たとえ失敗しても、最後まで全員が全力で取り組んだプロジェクトであれば、
次に二度と同じ失敗をしないように工夫を凝らすはずです。
しかし、途中であきらめたプロジェクトは、次のプロジェクトに活きません。
これからIT業界で働く人は、自分が取り組んでいるプロジェクトが失敗するとしても、
最後まで全力で取り組んで同じ失敗を繰り返さないようにしましょう。
