元Sierが語るIT業界研究

こんにちは、すたびーです！ 
就職活動や転職活動するときにシステムエンジニアの仕事なんてどこの会社も同じで、「なぜ、当社を志望したのですか。」に回答できないと悩んでいませんか？

  
そんな方に向けて、自分の実体験から会社ごとにどのような違いがあったのかを記事にしました！

自分が就職活動していた時は、「システムエンジニアなんてどこに入っても同じ、とにかくシステムが開発したいんだ」と思っていました。ですが、実際、入ってみると、考えてなかっただけで、「自分は一般消費者向けのシステムを開発したかったんだ」とか「Sierとしてではなく、社内SEの立場で開発したかったんだ」とか、自分のやりたいこととのギャップが見えるようになってきました。

違いが分かれば、自分のやりたいことと照らし合わせることができますし、面接官に対して説得力のある回答ができるようになります。

違いを見分ける4つの軸

IT業界を分類すると以下の軸で分類できると思います。

・誰が使用するのか
・開発するのはどんなシステムなのか
・どの工程を担当するのか
・どの立場で担当するのか

早速、それぞれの軸について見てきます。

誰が使用するのか

こちらの軸では大きく２つに分類することができます。

とある架空のA社という会社があるとして、
　・A社の中でA社の社員が使用するシステム
　・A社の顧客に対するシステム
の２つに分類できます。

さらにA社の顧客という部分は
　・A社が取引している別の会社
　・A社がサービス提供している一般消費者（自分を含む）
に分けることができます。

学生時代は志望した会社の一般顧客に対するシステムを作ったり、改善したりしたかったのに、実際はA社の中でA社の社員が使用するシステムを作る会社に入っていました。

開発するのはどんなシステムなのか

自分が最初に入った会社では基幹系システムと呼ばれるシステムを構築していました。
基幹系システムというのはそのシステムが動かないと、会社の売り上げが出ないといった会社の根幹になるシステムです。

実際、私が構築していた基幹系システムは以下のようなものでした。

製造業の会社では以下のような業務で成り立っています。

材料を他社から購入する→購入した材料で製品を作る→作った製品を卸し業者に配送する。
材料の仕入れから製品の配送までのお金の流れを管理する

上記の業務をまとめて管理するERPというシステムを構築していました。
ERPというシステムを１から開発するのは大変なので、SAP社のSAP ERPというパッケージをお客さんのところに導入していました。

自分が導入したシステムで製品が作られ、自分の家の近くのコンビニに並ぶというのは感慨深いものでした。
逆にシステムが止まると、商品の配送が遅れるなどといった事態にもなりますので、ひやひやすることも多々ありました。

どんなシステムで構築するかの観点でいえば、上記の基幹系システムと並んで情報系システムというものがありました。

情報系システムというのは基幹系システム系で作成されたデータを分析するためのシステムです。

例えば、基幹系システムの中には1件1件どの製品がいつ売れたという情報が入っているのですが、1か月単位でみたときには、どれだけの量でいくらの売り上げになったのかというのを集計してみたい、という要求に答えます。

情報系システムはシステムが停止しても、すぐに売り上げが出ないといった事態にはならないので、基幹系システムと比較すると、ピリピリ感は小さくなります。

私自身はかかわっていないですが、他にもECサイトといわれる、一般消費者がWebサイトにアクセスして商品をカートに入れ、注文を受け付けるというシステムを作っている部署もありました。

基幹系システムや情報系システム、一般顧客向けのシステムを稼働させるには、サーバーと呼ばれる普段皆さんが使用されるWindowsのPCよりもハイスペックな機器が必要になります。そのようなサーバーを専門に導入する部署もあります。

私はそのようなサーバーを導入する専門部署にいましたので、この辺は別途詳しく紹介したいと思います。

どの工程を担当するのか

ＩＴシステムを構築して利用できるようにするには、様々な工程をこなす必要があります。1社ですべての工程をこなすことはできないため、複数社で分担して進めています。

それでは早速どのような工程があるか見ていきます。

営業活動

Sierの会社の営業さんが、客先に出向いて、その会社がどのような課題を抱えているかヒアリングします。その課題の中で例えばERPのパッケージを導入することで解決するのであれば、ERPのパッケージ導入を提案します。

営業にいって、その提案がすぐ受け入れられるはずもなく、次のステップは客先からのRFPを待つことになります。

RFPというのは複数のシステム開発会社に向けて、こんなことで困っているのでシステムの提案してください、という依頼になります。

営業さんが頑張ると客先と一緒にこのRFPを作ることができ、この次のステップを有利に進めることができます。RFPの中身がわかれば、並行して提案の準備もできますし、RFPに書ききれない顧客の要望も知ることができます。

RFPは突然に

RFPをもらってSier側は提案するために提案書を作るのですが、このRFPをもらってから提案書を提出するまでの期間がやたら短いのはよくあることです。

2週間で提案してください、と依頼を受けると、徹夜しながらも提案書を作ったことがあります。

提案書を作るだけでもかなりのステップがあります。まずはRFPを読み込んで、ユーザが何をしたいのかを理解して、解決策としてどのようなシステムをいくらで構築するかを見積もる必要があります。

提案時の契約形態（請負契約、準委任契約）にもよりますが、ほとんどの提案では最初に提案した額より費用が上振れすることは許されません。また、規模が大きくなると50人とか100人がプロジェクトにかかわることになるので、それぞれ、どんなスキルの人が何時間働いたらシステムが完成するのかを見積もる必要があります。

また、システムを構築するためには先ほどのサーバーの要素であったり、パッケージのライセンス料なども見積もる必要があります。

そんな提案書を作成し、部署内の偉い人にレビューしてもらうのですが、レビューが一発で通ることはほぼありません。また、金額が大きくなると何人もの偉い人にレビューしてもらうことになり、最初のレビューで指摘されて修正した箇所を次の偉い人にまた指摘されるということもありました。

そんなこんなで何とか提案書を作成できたら、次は顧客に対するプレゼンです。

競合他社と日を分けて、プレゼンを行い、結果を待ちます。提案内容が他社と異なるので、ここの構成を変更したらいくらになるの、といった提案の修正を受けることもあります。

提案が通るとそれまでの苦労も報われます。提案書を一緒に作ったメンバーで打ち上げにいったりもしました。

提案後の要件定義

RFPでどんなシステムを作りたいか聞いていますが、それは作りたいものの概要でしかありません。実際には要件定義という工程で、もっと具体的にどういうシステムを作りたいのかを確認していきます。

ここで注意が必要なのがシステム開発にあまり詳しくない人が要件定義をしてしまうと、実現できない要件定義が出来上がってしまいます。

過去に要件定義を半年かけてやったのに、いざシステム開発しようとしたら実現できないことがわかり、要件定義をやり直すという事態に陥ったことがあります。

要件定義はある程度、どのように実現するかをイメージしながら行うのがポイントです。

設計

基盤設計、外部設計、内部設計、運用設計などがあります。

基盤設計は何人のユーザが同時に利用し、何秒以内に処理結果を返すかといった要件からどのようなスペックのサーバーを準備すればよいかなどを設計します。
他にも一部のサーバーがダウンしても動き続けるための設計や壊れたときにバックアップから復元するための設計を行います。

外部設計はどのようなインプットを受けてどのようなアウトプットを出すプログラムを作るのか、また、プログラム同士がどのように連携するのかを設計します。

内部設計はインプットのデータを受けて、どのように処理すれば設計通りのアウトプットが出せるかを設計します。

運用設計は導入するシステムをユーザがどのように使用するかを設計します。

開発

設計をもとにプログラミングをしていきます。よくプログラマーの単価（給料）が安いと言われることがありますが、内部設計をプログラムに翻訳するだけの仕事だとやはり安くなってしまうと思います。

小さい案件であれば、要件定義から開発までを行ってしまう方もいて、こういう方は単価が高い傾向にあります。

あと、最近はサーバーの性能がよいので、開発時には気づかないのですが、実際に使ってみるとやたらと処理が遅いプログラムというのがあります。

同じプログラマーでも処理速度を考慮したプログラムが書ける人はもっと評価されてもいいのではないかと思います。

テスト

出来上がったプログラムが設計通りに動作するかをテストします。最近ではテストを自動化するためのプログラムを書くといったこともあります。

移行

最近では何もシステム化されていない会社はほとんどなく、何かしらの旧システムから新たに開発したシステムにデータの移行であったり、システムの切り替えを行ったりする必要があります。

移行はシステム停止を短時間で行うため、何度かリハーサルを行ったり、24時間対応の3交代でシフトを組んだりして行います。

運用・保守

新たなシステムに切り替わったすぐはトラブルが多いです。この機能はどういう風に使ったらいいの？といった質問があったり、プログラムが想定とは違う動きをしているといったことがあります。しばらくの間は稼働後フォローというフェーズ（工程）をもうけて、すぐに回答したり、プログラムの改修を行ったりできる体制を準備します。

トラブルが落ち着いてくると、体制を小さくして、運用保守を続けます。
上記の工程は大きめの企業向けの基幹系システム開発工程となります。企業の規模が違ったり、基幹系以外のシステムの場合はもっと違う工程になると思いますので、一例として見てもらえればと思います。

どの立場で担当するのか

これまで説明した工程はSier側の視点での説明となります。工程をただ説明するつもりがSierの大変そうなところばかりフォーカスしてしまいました。やりがいとしては顧客の課題を自分が提案したシステムで解決できるといったところかなと思います。

また、Sierの中でもいろいろな立場があります。
PM、PL、各領域のリーダー、メンバーなど。
この辺りは後日追記したいと思います。

社内SE側の視点で見ると、上記の工程を複数ベンダーで進めるといったときに、ベンダー間のスケジュールの調整や役割分担などの調整、また社内向けの説明など、調整が多いことが特徴です。社内SEのいいところは決定権が社内SE側にあるところです。自分が決めた構成でシステムを運用していけるというところがいいかなと思います。

最後に

長々と書いてしまいましたが、システムエンジニアといっても、どの工程を担当するのか、どんなシステムを担当するのかなどの視点で見ると違いが見えてくるかと思います。

是非、違いを見つけて「なぜ、その会社を選んだのか」の参考にしていただければと思います。