IT業界のお仕事に興味のある方。
今回は、IT業界がどのような手順で仕事をしているのかを紹介していきます。
私は大学生の時に、
IT業界の仕事はほとんどがプログラミングでしょ！
と思っていました。
お恥ずかしい( ;∀;)
ドラマでもプログラミングをする場面がよく映るじゃないですか？
あれはIT業界のほんの一部なんですね。
では、これからウォーターフォールモデルという昔からあるIT業界の仕事の流れを紹介します。
- IT業界の仕事について知りたい
- 就職活動でIT業界を志望している
- 実際に働く人の声を聞きたい
要件定義
では、最初のフェーズは要件定義です。
「え、企画は？」と思われた方。
確かに普通は企画から始まるかもしれません。
ですが、自分のプロジェクトは営業さんが仕事をとってきて、すぐに要件定義のフェーズに入ります。
（私の知らないところで企画がされているかもしれませんが…）
パッケージソフトのカスタマイズの仕事なので、ユーザもある程度はシステムを使った運用を想定できているのです。
ですから、あとはユーザの希望通りの機能を組み込むために、打合せを重ねて仕様を固めていきます。
要件定義での作成書類
要件定義では下記の書類を作成してユーザに見せます。
- 現行の業務フロー
- システムを導入した時の業務フロー
- 要件定義書
現行の業務フローとシステムを導入した時の業務フローを提示して、システム化によってどこがどのように変わるのかを説明していきます。
違いが分かれば、導入した時の効果を想像することができますし、また「こうしてほしい」という要望を聞き出すことも可能です。
そして、肝心なのが要件定義書です。
要件定義書はシステムの概要を説明します。
こちらは第一版は最初の打合せ時にお聞きしたユーザの業務を組み入れて画面のサンプルなどを見せます。
ですが、たいてい一度ではOKはでません。
そこから、こちらとユーザの認識のギャップを埋めていきます。
打合せが終わりましたら、ユーザの要望を再度要件定義書に反映していきます。
これを多くて3～4回ほど繰り返します。
要件定義書を見せてOKをもらえたら次のフェーズへ移ります。
設計
設計工程では主に下記のステップで行います。
まずはUI（ユーザインタフェース）の作成から入ります。
ユーザインタフェースとは、ユーザが操作する画面のことです。
こちらは基本的に要件定義書をもとに作成していきます。
私は機能説明を横に記載しており、見た人がイメージしやすいように書くことを心掛けています。
アプリケーションのベースとなるのが外部設計なので、ここは力を入れるようにすること。
データベースの定義をここに記します。
項目名や制約、備考などを記載できるようにしておき、データベースの作成者はこれを元に実際にデータベースを作成していきます。
ゆくゆくは、ここからマクロなどを流してCREATE文を作成できるといいなぁと思います。
データベースはアプリケーションの基盤となる部分なので、慎重に行うことが重要です。
詳細設計はプログラミングをするための設計書になります。
プログラマーはこれを見てプログラミングをしていきます。
設計者は本当にこの流れでよいのかを検討する必要があるので難しいです。
プログラマーはこれ通りにプログラミングをするので、設計ミスがあるとプログラムも間違えていることになります。
ここは設計者の腕の見せ所です。
設計フェーズは以上の3つが主です。
あとは、細かい設定をまとめたり、エラーメッセージを記載する一覧を作成したりという細かい作業があります。
アプリケーションが上手く完成するかどうかは、この設計にかかっているといっても過言ではないでしょう。
Hachi設計は上司などからレビューを受けて上達するものです。
最初は誰でも上手くいかないので、思い切って挑戦してみよう！
開発
IT業界の業務といえば、そうです「開発」業務です。
現場によっては「製造」と言ったりもします。
（私はあまりこの言い方は好きではありません。なんとなくです……）
開発ではお馴染みのプログラミングをしていきます。
プログラミングをしていくうえで下記のことが重要になります。
- 設計書通りにプログラムを組む
- 保守のしやすいコーディングを心がける
- コメントはしっかり残す
基本的には設計書通りにプログラムしますが、時には設計書が間違っていることもあります。
その時は設計者の方に都度質問します。
これを疎かにすると、導入してからの不具合の元となるので気を付けましょう。
また、保守のしやすさは大切です。
「動けば良い」という考えは捨ててください。
保守をしやすいようにコメントを残しつつ、きれいなコーディングを意識しましょう。
Hachi先輩社員などから教わるのも良しです！
テスト
テストには主に3種類あります。
（厳密にはもう少し多いかもしれませんが。）
- 単体テスト
- 結合テスト
- 受入テスト
単体テスト
単体テストはプログラミングを終えた後、機能単体でテストをすることです。
ホワイトボックステストとも呼ばれ、内部構造に着目してテストをします。
つまり、ソースコードもテストの対象となります。
単体テストを疎かにすると、後の結合テストが進まなくなるので、かなり重要です。
できればこの段階でリファクタリング（ソースコードを整える）をしておくとよいでしょう。
結合テストが終わった段階でソースコードを触るのは少し勇気がいります。
（修正によって動かなくなってしまうかもしれないため）
機能が動くことと、ソースコードが可読性の良いものになっているかのテストを行います。
結合テスト
機能を合体させて行うテストになります。
ブラックボックステストとも呼ばれ、内部構造には着目せず、システムの動作や機能間の動きをテストします。
納品前の最終工程となるため、システムが問題なく動作するかをしっかり見ていきましょう。
結合テストがいわゆる最後の砦で、この工程を終えると後は導入だけです。
導入時に恥をかかないように、結合テストは焦らず慎重に行うことを推奨します。
ユーザ目線でテストを行うことも重要です。
結合テストでは、開発者目線を捨ててユーザ目線でシステムの動作確認を行いましょう。
受入テスト
受入テストは主にユーザがテストを行う工程です。
ユーザがテストをして要件通りかを確かめます。
要件と相違があると、そこを修正していくのです。
受入テストを無事通過すると、いよいよ運用開始となります。
運用後にユーザから不具合の報告を受けることはよくあることですが、ひとまず受入テストを通過すれば最低限はシステムの要件が保証されているので安心です。
保守
保守は本当に重要です！
もう一度言います。
保守は重要です！
保守がないと儲からないぐらい、IT業界では保守が重要です。
保守では、主に不具合の修正から要件の不一致による修正、軽微の改修などを行います。
ユーザは保守費用を毎月支払っていて、大規模な改修でない限り対応することになるのです。
保守は不具合だけでなく、そこからまた新たなシステム改修の受注をできる可能性もあり！
なので、保守の対応の仕方によっては、よきビジネスチャンスとも言えます。
Hachi保守派軽く見られがちですが、とっても重要！
仕事としてはあまり面白くないですが( ;∀;)
まとめ
IT業界の業務の流れを説明してきました。
本記事はあくまで私の経験をもとに書いています。
現場によってはかなり方針が異なるところもあるでしょう。
また、最近流行りのアジャイル開発を行っているとこもあると思います。
その現場に合わせて業務をこなしていってください。
関連記事
フリーランスエンジニアの仕事について語ってます！↓↓↓
Hachiについて知れます(^_-)-☆↓↓↓
コメント