を少し前ですが聞かれました
性格にもよるし、やりたいことがはっきりしていれば楽なんですけど、漠然すぎるんですよね、
というかSEが何かを分かっていないためそういう質問が来るような気がします。
ざっくりいうと
今回は環境構築は少し横に置いておきます。（CEさんごめんなさい）
システムを作り上げるとき、
①顧客要件を確認・整理する【SE】*1
⇒性能要件も必須です。
②スケジュール・金額を見積もりする【SE/一部プログラマ】
⇒営業への情報提供ですね。
③基本設計書を作成する【SE/一部プログラマ】
④詳細設計書を作成する【SE/一部プログラマ】
⑤プログラム設計書を作成する【プログラマ】
⇒ここでSEがでしゃばると自分みたいに嫌われますが納品物の場合でしゃばります。
⑥コーディング（プログラム）する【プログラマ】
⑦単体試験と呼ばれる作成した部分の試験の項目書を作成し実施する【プログラマ】
⑧他モジュールや他システムとの試験の項目作成試験を実施する【SE】
⇒トラブル時以外プログラマがやってはいけません
⑨システム全体の試験項目を作成し実施する（仕様通りか）【SE】
⇒トラブル時以外プログラマがやってはいけません
⑩納品する【SE】
⑪技術的サポートする【SE/プログラマ】
というのが基本です。*2
もちろん役職や会社によって重複したり、専用の人がいるかもしれません。
が、基本、SEは最初から最後まで、コーディングに関係する部分を除いて全てに関係してきます。
かぶってるいるところはどうしても判断つかない、例えばSEが詳しくない言語やミドルを使う場合、経験者やプログラマに援助を頼みます。
完全に契約で分けるなら⑤～⑦までがプログラマでそのほかはSEです。
インプットは詳細設計書でアウトプットは単体テスト完了したプログラムです。
SEはめんどくさい
新人とかでよくあるのが、SEは提案・要件定義を行い基本設計書を書くまで、と思っている人がいます。へたしたらコンサル志望だと提案までが仕事だと思っています。
そんな人に任せてるシステムは、すでにあるシステムか、ちょっと組み合わせたらできるものだけです。
なのでかなり茨の道です。
とはいえ、なんでそんな大変なのにSEやんのよ、、っていわれるとやっぱりITにより顧客の満足度向上と効率化を実施するためにはそれぐらいのことをしなければいけないのかな、、と自分は思っています。
そして、これが普通にできるようになるとコスト管理がふえていき、そのうち、コストとリソース管理ばかりする管理職になっていきます。
自分はそれは嫌でした。自分で考え自分で作成過程を見たかったのです。
よってすごいいろんな人とコネクションを持つことを嫌う人はSEにはむいていません。
プログラマに向いている人は
要件からコーディングをして動くと達成感を得られる人で、コツコツと作業ができる人です。
与えられた仕様書をもとに決められた環境・言語でそれをどうやったら動くように考えるのが好きな人はプログラマになるべきです。
SEは、たぶんできるだろうという仕様を書いてきます。アホなSEは理想を書いてきて大変な目にあいます。
プログラマがバグ以外で大変な思いをしている現場はSEが腐っています。
もしくはプログラマの力量がたりません。SEにこう直せといわれると恥と思ってください。
実際、自分も火が噴いているプロジェクトでヘルプにきたプログラマにバグを指摘し、回避するための仕様およびフローチャートまで書いているのにどうかけばいいんですか？って聞かれたことがありますが、もうお前帰れ！俺が書くってなります。
どうやったらバグの現象を止められるか考える頭がないとプログラマにはなれません。
もちろん仕様バグもふくまれるのでその場合は仕様が間違っていると言える人でなければなりません。
ただ、与えられた仕様書をコードに翻訳するだけではプログラマではありません。
あとは、もし要件を満たさない場合、改良する努力がSEと一緒に出来る人ですね。
どうしようもありません、書いてる通りにつくりました。
っていわれるとSEからしてみるともうお前いらんってなります。
どこが重いのか、どこがネックなのか、どうしようもないのか、判断材料が欲しいSEにアドアイスしてあげてください。
というか、SEにこう直せ！っていわれたら失格です。*3
文系女子だけど新卒でSEやってます 女の子のお仕事応援コミックエッセイ (メディアファクトリーのコミックエッセイ)
- 作者: しま子
- 出版社/メーカー: KADOKAWA/メディアファクトリー
- 発売日: 2015/02/13
- メディア: 単行本
- この商品を含むブログ (2件) を見る
すくなくとも
SEもプログラマも大変さは違いますが、メインスキルセットが異なるだけで全体のスキルは同じなんです。どこに山をもっていくか？になります。
バグがでたらSEもプログラマも一緒に解決にむけて作業しなければなりませんしいたるところで共同作業になります。
以前にもかきましたが全てが出来るならそれでいいのですが、大規模システムでそれはできません。
なので、迷ってる人は、とりあえずはプログラムも勉強しつつシステム作りってどうやるんじゃろか？自分にはなにがむいているんだろうか考えるといいと思います。
顧客と仕様を考えるのが好きな人はSE
モノづくり専門がいい人はプログラマ
って感じですかね。。どちらに比重をもつか、会社の規模、システムの規模で考えるべきだとおもいます。
本当の悪は
適当なコンサルだけやって放置、研究としょうして実証確認だけして投げる人達です。
商用レベルにまで責任持ってやってくれる人は少なかったです。
こんなことできるからやってみたら？みたいな無責任な人にはならないでください。
予算や違うプロジェクトが開始したので知りませんっていわないでください。
商用でお金もらう現場では最後まで面倒みないといけないのです。しりぬぐいはまっぴらごめんです。
まとめ
最後は完全な愚痴でしたが、SEもプログラマもCEもなにに特化するか？って言うだけの違いでどれにでもなれるはずです。ただ本物のSEを目指すのであれば何か一つにどっぷりつかると身動き取れななくなるので、幅広い知識と経験を活かしたいと思える人がSEを目指してください。業務なのか技術なのかも含めてね。
自分は技術志望のSEでしたが（アーキテクト）、会社やめるまで業務SEでした。会社がゆるしてくれませんでした。
そんなことしてるから業務SEなのにベンダー技術者と夜な夜な悪だくみするようになるんですよ、、そしてなんでコアな技術対策委員会のメンバになれっていわれるんだよ、、ブツブツブツ( ´艸｀)
