さて、夏のインターンが終わりそろそろ就活生からOB訪問の季節がきました。
この時期に必ず学生さんから必ずくる質問がこれです。
こぶた
システムエンジニア(SE)って何をしてるの?
昨年は50人くらいの大学生と面談をしたのですが
SEが何をするか知っている人は半分もいませんでした。
仕事内容を理解していないのに、就職しようとしているなんて…
だいぶヤバいですよね。
(僕も新卒のころはそうでしたが…)
ということで、SEの仕事内容を実際に近い資料を入れながらやさしく解説します。
先に簡単に説明すると、SEの仕事は大きく5つに分かれています。
このページの目次
SEの仕事内容は、お客さんの要望を叶えるシステム設計をすることです。
まずは、設計が必要な理由を考えます。
設計無しで開発を行うと・・・
おうま
(1ヶ月後)開発できました!
お客さん
やっぱりちがった
せっかくの開発が…
実際の開発現場でもよくある光景で、こうなると揉めます。
「あぁ言ったじゃないか」「こんなイメージではない」
言った言わない問題にさせないためにも、設計をしてOKをもらうプロセスが大事になります。
SEが携わるのが開発以外の5つの工程です。
要件定義 > 基本設計 > 詳細設計 > テスト > 保守
IT業界用語で言うと上の図を「V字モデル」と言います。
この流れでシステム開発を進めていきます。
V字モデルを簡単に言うと
・ブロック毎の作業が終了したら後戻りはダメ
・下にいくほど細かい内容を決めていく
・開発より左側では設計(仕様)を決める
・開発より右側では設計した機能が付いているかテストをする
というものです。
おうま
手戻りをなるべく無くそうって手法です。
僕の今までの現場全てで使われているので「V字モデル」は必ず覚えておきましょう
こぶた
なんとなくわかったけどイメージがつかない
おうま
それじゃ、V字モデルについてもう少し掘り下げていくね
「ログインにSNS認証をつけたい」
とお客さんに言われた場合の、業務とイメージはこちらです。
お客さんもこうしたいという要望は持っています。
しかし、エラーメッセージや登録に失敗した場合など、細かい内容まではイメージを持っていません。
工程毎にヒアリングを重ねて、曖昧な要望を具体的な機能にしていく仕事がシステムエンジニアの仕事です。
ここからは、実際の現場SEがやる内容をもとに各工程を深掘りします。
正直、少し難しいですが、僕の実体験も交えながら解説をしてみます。
▼ システム開発の時間割
要件定義(2ヶ月)
▽
基本設計(1ヶ月)
▽
詳細設計(1ヶ月)
▽
テスト(2ヶ月)
▽
保守(ずっと)
要件定義では、お客さんの要望を文章化して、システムの導入範囲とゴールを決めます。
僕の場合は、週に2回くらいお客さん先に行ってこんな仕事をしていました。
1ヶ月目 | 倉庫や事務所に行ってを見学 事前にもらった要望をもとに提案資料作成 |
2ヶ月目 | お客さんと打ち合わせをしてシステム要望の認識の違いを無くす お客さんと合意がとれたものから資料にして読み合わせをする |
あとで食い違いが発生しないように、しっかりと資料で文章化していく必要があります。
要件定義で決めないといけない代表的なものはこちらです。
ざっくり要件定義で決めること
・システムの全体像と概要
・システム導入の目的
・システム導入後の業務フロー
こぶた
業務フローってなに?
おうま
誰がいつなぜシステムを使うか図にしたものだよ
お客さんといえど100%自社の仕事の流れを理解しているわけではありません。
上の図のような業務フローを作成しながら、導入するシステムの機能に抜け漏れが無いか確認していきます。
出展:IPA情報処理推進機構 機能要件の合意形成ガイド画面編
基本設計では、全てのレイアウトとシステム動作を決めるお客さん向けの設計書を作ります。
ここでも、週に2回くらいお客さん先に行って打ち合わせをしていました。
3ヶ月目 | 画面レイアウトや必要機能を基本設計書に書く お客さんとお打ち合わせで基本設計書に認識違いがあれば修正をする |
SEとお客さんが、要望について話し合える最後の機会です。(プログラムの出来上がりまで数ヶ月打ち合わせは基本的にありません)
基本設計書に書かれていないことは、プログラムの仕様書に書かれません。
ざっくり基本設計で決めること
・帳票/画面デザイン
・画面遷移やエラーなどの細かなシステムの動き
詳細設計では、仕様書と呼ばれる基本設計の内容をより細かくしたプログラマー向けの設計書を作ります。
ここでは、お客さんが意識する必要のない、データベースの設計やクラス設計等を考えます。
これまでの工程と違い、お客さん先に行かずひたすら資料を作ります。
4ヶ月目 | プログラマーがコードをかけるように基本設計の内容をさらに細かくしていきます |
仕様が雑だと、プログラマーから質問がめちゃくちゃ来ますし開発速度が遅くなります。
基本設計で決まった内容を、抜け漏れなく記載する丁寧さが必要です。
ざっくり詳細設計で決めること
・データベースやクラスの設計
・プログラム単位でのフローチャート
テストでは、開発が終わったプログラムにバグがないかを確認します。
プログラムが落ちるもバグですし、設計の内容が組み込めてない場合もバグとなります。
おうま
僕が1番嫌いな作業です…細かすぎて病みそうになります
6~7ヶ月目 |
プログラムにバグがないか確認をしていく |
保守は、お客さんのバグやお困りごとや要望に主に電話やメールで対応をします。
システムの品質が悪いなどでシステムの使い始めがトラブルと、ほぼ毎日電話や調査依頼が来て地獄です。
365日夜間も動くシステムだと、夜中の対応をお願いされることもあります。
8ヶ月~5年 | お客さんの問い合わせ対応をします |
このように、SEはお客さんとの打ち合わせも多い仕事です。
そのため、SEに1番必要な能力は、コミュニケーション能力です。
コミュニケーションを深掘りすると、以下の能力がすごく大事です。
・知的好奇心があること
・無理なものは無理と言える人
例えば、お客さんと話していると業界用語がバンバンでてきます。
EC2、NACCS、B/S、P/L…
正直最初は何を言ってるのか全然わかりません。
こぶた
打ち合わせに出たけど何も分からなかった・・・
おうま
みんなが通る道なので安心してください
ただし…
そこで諦めるか、自分で調べる/お客さんに直接聞いてみるかどうかで見られ方が全然違います。
ここで勉強せず知ったかぶりをする人は、SEに向いていません。
知ったかぶりをしてプロジェクト後半になると、要望のヒアリング漏れが発生し急な追加開発イベントが発生します。
こうなると、休日出勤の可能性もあります。
分からないところは逐一質問することで、仕様の穴を防ぐことが非常に大切です。
プロジェクトが進むにつれて、お客さんの要望は増え続けます。
この要望に対して「はい、やります」と言った瞬間、詳細設計・開発・テストの仕事が生まれます。
▼ 悪循環の例
1.追加要望を素直に受け入れる
2.スケジュールが遅延する
3.急いで作りバグがでる
4.トラブルになり立場が悪くなる
5.要望を受け入れないといけなくなる
6.以下2〜5の繰り返し
1の時点で追加要望に対して「無理」と言っておけば人も納期も守れます。
無理なことは無理と戦える力が無いとデスマーチのプロジェクトを作ってしまいます。
未経験からIT業界に就職・転職したい人に向けて、SEの仕事内容を書いてみましたがいかがでしたか?
最後に今回の記事で、ぜひ覚えていただきたいことをまとめてみます。
・SEは要件定義・基本設計・詳細設計・テスト・運用保守の5つの仕事がある
・SEはプログラミングはせず、打ち合わせ/資料作成が多い
・SEに向いている人は、コミュニケーション能力がある人
調べても専門用語が多い業界ですので、SEについてでも分からないことがあれば、おうまのTwitter(@ouma_chaan)にご連絡ください!
東京で、WebディレクターやWeb制作をしているフリーランスのエンジニア。
情報系大学卒業後、一部上場企業でエンジニアとして7年間働いていました。
大学から10年ほどシステムに関わっていて、今はフリーランスエンジニアとして活動しています。動画配信系のディレクションをしていて、iOS・Android・Web(Rails)のアプリ開発管理をしています。エンジニアとして経験してきたことを、主観を入れながらやさしい言葉でお伝えしていきます。