やぁ！こんにちは。Milkだよ。
昨日は、あの後更に会社から電話がかかってきて＋αであれこれと話をしたんだよ☆
電話中の俺の顔
まぁ、それについては置いておこうね。先ずは病気を治さないとね。
最近質問されたんだけど、SEって結局何やってんだ？って言われたんですよ。
あれ・・・未だにSEって職種は、ちゃんと理解されていない・・・？
まぁ、そうだよね。と言うわけで、SE（システムエンジニア）について軽く説明をしようと思うのです。（あくまで、私の会社の話になるので、色々なパターンは存在します。）
一般の方々のイメージのSE
多分なんだけど、SEは一日中PCと向き合っていると思っている方が多いのではないかな？
そもそも、こんなにオシャンティーな環境ではない！！
おっと。心の叫びがだだ漏れだ。
んで、答えですけど、半分は正解だけど、半分は間違いです。
何故かというと、SEのメインの業務は、設計とチーム運営になるからです。
現実のSE
さて、一旦はビフォアSEについては置いておきます。
簡単に説明しますと、ビフォアSEとは、営業と共にツーマンセルで行動し、案件の受注を行うSEのことを指します。
つまり営業の技術補佐と、システムの見積もりを行います。（まぁ・・・この見積もり金額で、SEと揉めるんだがね・・・）
実際のPJ（プロジェクト）を運営するSEより前の人々なので、ビフォアSEと呼びます。
設計編
案件が受注出来たとしましょう。営業及び、ビフォアSEから案件の概要を聞きます。
また、実際にお客様のところに訪問をして、お客様の思い描くシステムのイメージについてヒアリングを行います。
これが所謂、「要件定義」と呼ばれる工程になります。
この「要件定義」の洗い出しを行った後、これを踏まえてシステムの「設計」に入ります。
実は、この「設計」に関しては、会社ごとに様々なやり方や書き方が存在します。
時々、他のパークから受注出来た時、その他社の設計書を見たりしますが、かなり書き方が異なっていることに驚いたりします。
（後は、あまりに記述が少なくて、設計書の体をなしていないやつとかも多い・・・この場合は爆弾を掴まされたことに後から気づくパターンで真っ青になります。）
例えば、やり方としては、2段階で設計を行うパターンです。
- 機能設計
- 詳細設計
「機能設計」はお客様向けの設計書になります。出来るだけ細かな部分まで表すようにしますが、あくまでお客様が理解できる状態で表現した設計書になります。
「詳細設計」は身内向け、つまりチーム内のPG（プログラマー）が実際にコーディングが出来るように、より細かな動作やエラーについての対処について書き表した設計書になります。
と言うわけで、この「設計」工程はエクセルやワードを使い倒している時間がほとんどです。
意外だったかな？
コーディング編
プログラミングすることをコーディングと言ったりします。皆さんが、想像するのはこの工程でしょう。
しかしながら、規模が大きい案件になると、この部分はコーディング専門の協力会社を雇います。
設計の工程で雇う場合もありますが、それは状況に応じて異なります。
つまりこういう感じの組織図になります。
あくまで一つの例です。PJリーダの下にサブリーダは入るんじゃないの？って思うかも知れませんが、私はサブリーダ兼雑用というか・・・かなりフリースタイルで、チームの全体の最適化を図るというミッションを持って動くことが多かったので、この形で書きました。
（あと、何でかPJリーダの相談役になったりしてたし・・・）
各PGチームに対して、コーディング作業の工程を管理したり、各々の機能についての設計の認識をすり合わせたりということを行います。
ですから、案件の規模が大きくなるに比例して、SEは実際に自分がコーディングする機会は減ります。（人が足りないからです。）
もちろん、小さな案件の場合は、自分でコーディングをやってしまうこともありますよ？
コーディングをする上で、問題が発生したり、設計上の欠点を見つけた場合は適宜対処していきます。また、プロパー（自社の社員）メンバ、及びPGメンバの作業状況を常にモニタリングして、負荷が偏っていないかを調整します。
この作業の間に、プロパーメンバはシステム試験書と言うのを書きます。
システム試験編
システムを構築した後、段階的にですが、システムが正常に動作するかの試験を行います。それが「システム試験」の工程になります。
「コーディング」工程の間に、プロパーメンバは設計書に則って、試験内容と手順について書き出します。
細かくは以下のような試験になります。
- 単体試験
- 結合試験
- 総合試験
「単体試験」とは、プログラムの小さな単位で行う試験です。これはどちらかというとPGメンバが各々で担当します。
「結合試験」とは、出来上がったプログラムを組み合わせて、一つのシステムとして動作させた時に、正常に動作するかを確認します。また、大事なのは、異常事態を発生させ、その時に暴走や挙動がおかしくなったりしないかも確認します。
「総合試験」とは、ユーザ視点での操作を念頭に置き、システムの実際の運用状況を想定した試験を行います。例えば、データ入力を行い、機能間でのデータ連携が正しく行われて、最終的に必要としている計算結果が正常に出力されるかなどです。
この時は、「結合試験」以降は、基本的にはプロパーメンバが試験を実施します。これは、自分の設計通りにシステムが動作しているかを確認するためです。ここで不具合が発生した場合は、PGチームと話し合い、システムの挙動の確認を行って修正をさせます。
さて、試験が完了すればリリースになります。
お疲れ様！！
最後に
と言うわけで、全体を通して見ると、SEと言うのはほとんどコーディングをしていないことになります（笑）
実は、ワードとエクセルと大のお友達なのです。
これぐらい使いこなせないとダメなのです。（ワードとエクセルの話。）
後は、お客様に対する窓口、そしてチーム全体の運営を行います。
難しいことに、PGから上がってくる内容を判断し、システムの欠陥やバグが多く含まれる傾向のあるコード（プログラム）を見つけ出す等の監督役もしなければなりません。
お客様窓口兼チーム運営兼技術監督 が我々SEの仕事になります。
ただし、問題として、最初からSEになってしまうと、技術において力量不足になり、PGからの納品物の品質を正しく評価出来ません。
そして、技術的打開策についても検討出来なくなるのです。
ですから、私個人の意見としては、SEとPGとできっちり分けると言うのは反対です。PG上がりのSE、或いは、SEは積極的にPGに参加しなければならないと思っています。
これは、結果的にコーディングが理解出来ていないと自分がシステムの設計を行う時に、どのようにコーディングしてシステムを実現するかが想像出来ないということになってしまいます。
SEとPG間で摩擦が起きる時は、大抵は技術的な話が噛み合わない場合です。PGとしては技術的観点から無理だと主張しているのに、SEはお客様の要望だからどうにかしろと言って、互いに平行線になってしまうのです。SEは、PGの言っている内容を理解し、本当に無理なのかを判断出来なければなりません。
このように考えると、SEとは、IT技術を常に身に着け続けPGと会話が成立出来るようにし、それと同時にお客様にIT用語を噛み砕いて説明出来るようにするコミュニケーション能力を持っていなければなりません。
そして、チームメンバの状況を正しく判断して、統制を正しく保つという使命もあります。
さて・・・皆もSEに成りたくなってきたよね☆
大丈夫！みーんなこんなにニコニコしながら仕事してるよ！！
一緒にSEを目指そうね☆
