SEって何?おいしいの?

この画像はシステム構築における完成までの過程を示しています。後ろで説明する顧客要求と完成物との乖離が、見事にIT業界をディスっています苦笑

社外の人との飲み会で職業を問われ「SE(システムエンジニア)です。」と答えると相手がキョトンとする事が多いです。私自身、会社に入る前まではどんな職業か内容もろくに分からないまま入社しました。入社して数年が経ち、恥ずかしながらまだ明確にではないですが、ぼんやりと全体像が見えてきました。今回は、私が分かる範囲内でSEについて説明します(^^)

SEってプログラマ?

一言でいうと、違います。とはいえ100%そうではないかというとそれも違い、プログラマを兼ねるSEはいますし、システム規模が小さいほどそれは顕著かもしれません。
ぶっちゃけると、SEはほとんどコーディングをしません。コードの事なんかよく分かんね!!ってSEも私の周りには、います…。裏を返せば、プログラムが分かっていなくてもSEはできます笑

システムが出来上がるまで

一般的には以下の過程を踏みます。今回の記事のサムネ画像は、以下の各工程における皮肉をなぞっていますが、実態は近かったりします笑

  1. 要件定義
  2. 設計
  3. 構築
  4. テスト
  5. 運用・保守

要件定義

顧客の業務は多種多様ですが、その業務には多かれ少なかれ課題を抱えているはずです。その課題を解決するのがシステムであり、それを提案するのがSEの仕事といえます。

顧客から業務の課題を聞いて、それをシステム化できるのか検討し、顧客要求・要件を明確にしていきます。

設計

要件が明確になったら、次は具体的な設計書に起こします。設計書といっても様々で、以下のような設計書が存在します。呼び方も様々かもしれません。

  • 画面設計書

ユーザーが操作する画面のボタンやアイコン、画面間の遷移を設計します。

  • 内部設計書

ボタンを押したときなど各動作を設計します。条件分岐や、情報の出どころ(DBのフィールド名)などを記載します。

  • プログラム設計書

内部設計書で記載した処理内容をプログラムベースで具体化します。処理が動作する関数を定義し、その関数への引数や戻り値を明確に記載します。

  • DB構造設計書

DBを使うシステムであれば、その構造を設計します。DB、スキーマ、テーブル、カラムなどを定義していきます。

  • etc…

その他、プロジェクトやシステムによって定める設計書があれば記載します。

開発工程にも色々ありますが、ここではウォーターフォールをモデルとして記載しています(古いですかね…)。アジャイルとかプロトタイプとか色々とありますが、実際の業務ではまだ利用したことはありません。

構築

設計書に起こした内容をもとにプログラムを書いていきます。
ここはプログラマの出番ですね。大手SIerだと、上流の設計だけやって構築以降は下請けに投げていたりします。
ただこれはシステム規模にもよるので、規模が小さいとSEが設計も構築もテストもするなんてことはザラにあります。というか、実際していました。

テスト

さて、構築が終わってシステムが動作するようになったら、次はテストです。テスト内容は予め設計工程で決めておきます。テスター(テストする人。これも下請けに投げたりします。)が、テスト内容に従ってテストをします。テスト結果でNGがあるとその都度修正し、システムの品質を高めていきます。
品質、という言葉は奥が深く(業も深い)、様々なところで関連してくるのでその話はまた今度にでも…。

全体の中のSEの位置

システムを構築するとなったら様々な人が関係します。
営業、顧客、SE、CE、プログラマー と、様々と言いつつこんなもんかも知れませんが。
ざっくりとした仕事の流れは以下です。

  • 営業が商談して仕事を受注する
  • SEが顧客と会話しシステム構築・設定を行う
  • プログラマーがシステムを改修する
  • CEがインフラを整える(ここら辺は微妙か?)

営業が商談時に受注した金額をもとに、SEは作業します。SEが何かしてお金が発生する訳ではなく、決められた金額の範囲内で仕事をして余り分が利益となるわけです、ざっくり言うと。
この見積もりが難しいですよね~、ほんとどんぶり勘定。赤字営業。サビ残のオンパレードと、見事な三連コンボです泣

実際の業務

さて、実際の業務はというと会社によって色々違いますが、私の職場では大きく以下で分かれます。
顧客要求に応じて一からシステムを作り上げていく、というのは今日日珍しいかもしれません。だいたいはPKG(パッケージ)システムとなっていて、ある統一規格のシステムを同種の業務を持つ企業や団体に導入し、業務の課題を解決するのが主だったりします。
繰り返し言いますが、以下の切り分けはシステム規模が比較的大きい場合です。システム規模によっては、以下全てを担います。

  1. システムを作る人
  2. 作ったシステムを導入する人
  3. 導入したシステムをメンテナンスする人

システムを作る人

その名の通りですね。『システムが出来上がるまで』に書いてある通りです。

システム規模が大きい場合は、SEがやることは管理・調整ごとが多いです。プロジェクト進行における進捗管理・問題点管理がメインといってもいいですね。各担当・顧客とのコミュニケーションを密に取るのが大事です。

作ったシステムを導入する人

PKGシステムが出来上がると、それを導入する人が必要です。
顧客が持つ様々な課題を聞き出して、それをPKGシステムで解決できるかどうかを判断します。PKGシステムでは基本的にシステムを改修することはしません。システムが持つ設定の範囲内で、課題が解決するかどうかを判断します。勿論、システムを改修する場合も発生します。そのときは、『システムが出来上がるまで』に沿って機能追加という形で増やすまでです。
設定変えればできるというと簡単に聞こえますが、実際はそうでもないから辛いです。設定を変えて増えるバグ、コレはできないかアレはできないかとう顧客要求に答えられない機能の貧困さ。まあ、こういった話はおいおいに…。

導入したシステムをメンテナンスする人

システムを導入して日が経つと、システムありきの業務運用が円滑になってきます。そうなると導入する人達の出番は終わりです。
しかし、それでSEの出番が終わりではありません。その後のシステムのサポートが必要です。新たな要求、既存のバグ対応、プラットフォームの変更によるシステム改修、法律などの規定変更によるシステム改修などなど。
基本は、問題点を引き続き対応するのがメインですね。

まとめ

いかがでしたでしょうか。何となくでもSEという職業が分かってもらえたなら幸いです。

始めのうちは、仕事やWEB系・ブログの解説など交えて記事を投稿していきたいと思います。ではでは(^^)