ITエンジニアはかなり多数になってきて分業も進みました。
「XXXエンジニア」のような言い方のXXXにあたる部分が、工程である分類です。
他に扱うものからの分類があります。ネットワークを相手にしていてコードを書いているエンジニアなら、「ネットワークエンジニア」かつ「プログラマー」となります。
ITエンジニアを分類し、個別にそれぞれの記事を書いていきます。
工程ごとのITエンジニア
工程ごとのエンジニアの分類は、業界や会社によって異なることがありますのでご注意ください。
工程には以下のようなものがあります。
- 要件定義
- 外部設計
- 内部設計
- コーディング
- 単体テスト
- システムテスト
複数の工程を担当する方も多いというか、一つだけの工程だけしかやったことのない人はそういません。
工程ごとにきっちりと分ける考え方をウォーターフォールといい、ウォーターフォールを反省し生まれたのがアジャイルです。
設計工程では、お絵描きするのが欠かせません。UMLを正確に書けるようになっておいた方がよいと思います。
>>> 【ITのお絵描きルールUML】UMLを使わない頑ななおじさんたち
要件定義
要件定義とは、ユーザがこういうことをしたいというのをまとめる工程です。
要件定義を遂行する人を「上流SE」「フロントSE」または単に「SE」と言います。
>>> 【要件定義という工程】要求仕様の探検学 設計に先立つ品質の作りこみ
外部設計
外部設計はその製品、システムが、外部から見てどういうものになるかを決めます。
他に「製品設計」「基本設計」などと呼ばれます。もっと細かに分かれていることもあります。
外部設計をやる人を「設計者」「ソフトデザイナ」「デザイナ」「SE」と言います。
ややこしいのは「SE」が要求仕様の人だったり設計者を指したりします。業種、会社によって違いますので注意しましょう。
外部仕様書については、ミッションステートメントをよく考えて書きましょう。
>>> ITエンジニアが仕様書に最も書かなければならない1つのこと
>>> 外部仕様書（製品仕様書、基本仕様書）の書き方 ミッションを中心に据えて [bogcard url=”https://it-engineer-business.tech/ex-spec-mission/”]
>>>【外部仕様書(製品仕様書、基本仕様書)で書くべきこと】
内部設計
内部設計は、その製品をどうやって作るかを決めます。
外部は「どういう製品か」、内部は「どうやって作るか」です。混同しないようにしましょう。
他に「基本設計」「機能設計」「詳細設計」などと呼ばれます。
「基本設計」は外部なのか内部なのかは、プロジェクトごとに違いますので気を付けましょう。
内部設計をやる人は特別な呼び名はなく「設計者」「プログラマ」です。
上の工程か下の工程のおまけ的な扱いが多いかもしれません。
>>> 【内部仕様書(機能仕様書、詳細仕様書）で書くべきこと】
>>> 【オブジェクト指向の考え方】オブジェクト指向は滅びたのか、定着したのか
コーディング
内部設計に従ってプログラムを組む、コードを書く人を「プログラマー」「コーダー」と呼びます。
コーディング、プログラミングについての知識は増えてきたので以下にまとめました。
単体テスト
単体テストは、プログラムが書いた通りに動くを確かめるテストです。
具体的にはデバガでステップ実行するか単体テストフレームワークに従って自動テストを作ります。
「プログラマ」か「テスタ」が行います。
>>> gdbのdebug、単体テスト入門 書評：実践デバッグ技法
>>> 【テスト自動化（単体テストフレームワーク）が根付かないのはなぜか？】
システムテスト
システムテストは、外部設計または要件通りに製品が動くかどうかを確かめる行為です。
「テスタ」が実施します。
会社によっては、最後のテストをする人間ということで「品質保証」「QA」と言ったりして別部署の人がテストを行います。
会社によっては、システムテストとQAのテストが別々に行われることもあります。
>>> 【ITエンジニアにとってのシステムテストの観点】何を考えておくべきか
>>> 「測る」という行為
（作成中）
アジャイル
上記のような工程を短期間で回すのをアジャイルと言います。
アジャイルにはいろいろなやり方がありますが、発想は開発サイクルを縮めることによってより大きな価値（バリュー）を届けようという考え方になります。
よく考えてから始めないと容易にデスマーチになります。
>>> いろいろなアジャイルの考え方
（作成中）
>>> アジャイルと言いつつ単にブラックなだけのプロジェクト
（作成中）
コメント