PROGRAMMING WORK

SEの仕事内容をわかりやすく解説【現役8年目】

仕事
悩み人
エンジニアの仕事が気になる・・・具体的に何をするの?

こういった疑問に答えます。

 

この記事を見ているあなたは、仕事としてのエンジニアが気になっていると思います。

仕事にするとなるとかなりの時間を注ぎ込むことになるので、失敗したくないですよね。

 

この記事を書いてる僕は現役8年目のSEです。

プログラミングスクールの先生とは違って、実務の経験をベースに書いています。

 

調べてみるとよくある教科書的な記事とはちがう部分もありますが、ぜひ参考にしてみてください。

 

SEの仕事の全体的な流れ

ウォーターフォール

SEの仕事は基本的にウォーターフォールモデルで進められていきます。

 

ウォーターフォール=滝です。

ウォーターフォールモデルでは、いくつかの工程(フェーズ)があり、基本的に前工程が終わると後戻りはしないという作り方になります。

滝は一度落ちたら後戻りできないことから、こんな名前になっています。

とはいえ、どうしても実現したい要望は前のフェーズに戻って盛り込むこともあります。このあたりは納期までの残日数と余力を考慮してお客さんと調整しながら進めていきます。

 

他には小さな単位で作ってリリースして、作ってリリースして、、、と繰り返していくアジャイル開発という開発手法もあります。

ネットを調べてみると、「ウォーターフォールは古い。今はアジャイルだ」という論調の記事が散見されますが、僕はアジャイル開発をしたことがありません。

 

おそらく顧客の声を聞いて即時反映が求められるような軽快なサービスはアジャイルなんでしょうね。

僕みたいな「ほかの企業の業務系のシステムを作る」というどっしりとした開発ではほぼウォーターフォールです。

 

システムエンジニアの仕事のフェーズ

前置きが長くなってしまいましたが、システムエンジニアの作業工程を並べると、このようになります

 

  • 要件定義
  • 基本設計
  • 詳細設計
  • 開発
  • テスト
  • リリース

 

ひとつずつ解説していきます。

 

各フェーズの仕事内容をわかりやすく解説

基盤

ここからは各フェーズの仕事内容について、わかりやすく解説していきます。

 

その前に一点補足なのですが、要件定義よりも前の仕事のはじまりでいうと、お客さんから「システムでこういうことがしたいんやけど、何人でどれぐらいの期間かかるか見積もって?」という依頼が来てからはじまります。

あとは営業をかけて、「何かシステムでしたいことないですか?」とつついてからはじまることもあります。

 

仕事の発生のイメージが湧かないと整理しにくいと思ったので、補足でした。

 

1:要件定義

要件定義では、開発するシステムでどのようなことをするのかを決めます。

 

「この画面で商品の情報を管理したい」

「この画面で顧客情報を入力させたい」

など、そのシステムにどのような機能を持たせるかを決めます。

 

 

この工程は超重要です。

 

なぜなら、対応するスコープが決まるからです。

 

こちらとしては10個の機能を持たせる想定で見積もってスタートしても、お客さんが20個機能を持たせたいと考えていたら、後から仕様追加の嵐となります。

 

なにが問題かって、10個の機能をつくる分しか人員もスケジュールも確保していないので、必然的に残業をして終わらせることになります。

デスマーチ突入ですね。

 

なので、この工程はめちゃくちゃ大事です。

 

2:基本設計(外部設計)

基本設計では、要件定義で決めた「何をするか」を設計書に落とし込みます。

プロジェクトによっては外部設計とも言われますが中身は同じです。

 

画面のレイアウト、入力チェックの種類、エラーメッセージの内容、DBの項目と表示条件などを決めます。

 

ざっくりいうと実際の見た目や操作感など、ユーザーが使うときに気になるところですね。

DBの項目については、下手な作り方をすると表示速度に影響が出る場合があるのでこれも基本設計です。

 

基本設計までは結構お客さんもしっかり確認してきます。

システムの顔になる部分なのでそれはそうですよね。

 

この工程も後から仕様追加を招かないために重要な工程になります。

 

3:詳細設計(内部設計)

詳細設計は、基本設計に落とし込んだことをよりプログラミングに近い形で設計書に落とし込みます。

 

ちょっとイメージしづらいかも知れませんが、どのようなインプット(Input)をもらって、どのような処理(Process)をして、どのようなアウトプット(Output)を返すか、といったIPOという成果物を作ることもあります。

 

ここまで来ればお客さんもそんなにしっかりとは確認してこないですね。

お客さんからすれば、ちゃんと動けばある程度それでいいので。

 

4:開発

ここまできて、いよいよプログラミングです。

 

詳細設計書を基にコーディングをしていきます。

 

大体複数人で開発をすることが多いので、コーディングガイドや構成管理ツール(GitやSVN)を駆使して、システム内でバラバラな作り方にならないように工夫します。

 

システムは作って終わりじゃなくて、リリース後何年も使われて、その間も要望に応じて改修が入ります。

その改修のときに十人十色な作り方をされているとかなり改修しづらいです。

 

なので、複数の画面で同じようなことをさせる場合は、共通で使える処理を作ってみんなそれを呼び出すなど、共通化を図ることになります。

共通にできない場合はコーディングガイドに則って開発を行って同じような作り方にしておく、といった感じです。

 

5:テスト

テストにはいくつか種類があります。

  • 単体テスト(UT)
  • 連結テスト(IT)
  • 総合テスト(ST)
  • 受入テスト(UAT)

 

単体テスト(UT)は自分が作った画面だけ動かして仕様通りの動きをしているか確認します。

UTはデータを変えたりやデバックコード入れたりして確認することができます。

 

連結テスト(IT)は、内部連結テスト(ITa)、外部連結テスト(ITb)に分けることができます。

 

内部連結(ITa):自システム内での連結テスト

外部連結(ITb):外部システムとの連結テスト

 

内部連結では、たとえば入力画面→確認画面→完了画面など、自分のシステム内で動かして想定通り動くかを確認します。

 

外部連結では、クレジットカード決済など外部のシステムと繋いで想定通り動くかを確認します。

 

総合テストではウォークスルー形式で実際に使用される方法を想定して同じ動きをやってみます。

連結テストまでは「テストケース」を作って単発で確認する感じですが、総合テストでは「テストシナリオ」といって、文字通りシナリオを複数考えてそれ通りに動かします。

 

受入テストでは、総合テストまで終わったシステムをお客さんに引き渡し、お客さんの方でグリグリ動かしてもらいます。

大体問題がない想定でお渡しすることになるので、待っている間はかなり緊張します。笑

 

確認してもらっている間はリリースに向けた準備をします。

 

6:リリース

最後のリリースでは、これまでテスト環境と呼ばれる一般ユーザーからは繋ぐことができないところで動かしていましたが、一般ユーザーも繋ぐことができるようにします。

ここまできてひとつのプロジェクトが終わりです。

 

システムエンジニアとプログラマーのちがい

疑問

このちがいは気になる人がいると思います。

 

これを分けるとすると、こうなります。

SE:上流工程を担当

PG:下流工程を担当

 

ちなみに、基本設計までが上流で、詳細設計以降が下流です。

 

基本設計までがシステムを規定しているのに対して、詳細設計以降はその規定されたシステムを実現するための動きになります。

なので、基本設計までがシステムをエンジニアしてるって感じですね。

 

まとめ

打ち合わせ

マナブさんやマコなり社長の登場で注目されているプログラミング。

 

実際にそれを職にするとなると慎重になりますよね。

それは感覚として合っていると思います。

 

この記事が少しでも多くの人に役立てば幸いです。

 

それでは!

 

 

-PROGRAMMING, WORK
-,

© 2020 eureka