システムエンジニアのお仕事
巷で「私の職業はＳＥです」というと、「あ、なんか難しいことをするお仕事ですね」的な感じで、システムエンジニア（ＳＥ）というのは、世間への広まりもあいまって、使い勝手のいい言葉でもあり、システム開発の現場だと一般化していて、会話するのには楽でいいのだと思う。
でもね。
僕は、システムエンジニア（ＳＥ）って職業は不要と思うのです。特に定義が曖昧なので。
一般的によく言われるＳＥのお仕事は、こんなところかな？
- お客様の話を聞いて仕様書（設計書）を作成する
- 作成した仕様書（設計書）を元にプログラマにプログラムを作成してもらう
- 課題管理、進捗管理、リスク管理をする（ただし自分が担当する範囲）
まず、仕様書（設計書）作成
いくら細かいところに気を配って記載して、「良いですね？」「ここからの変更は仕様変更ですよ」と言っても、開発後に動くものをお客さんに見せると「思ってたのと違う」「そんなこと言ったっけ？」「確かにその時そう思ったけど、今見たら違うかなと思った」「専門用語ばかりでこちらは全然理解していませんでした」とか色々言われる。
それこそ、Sierとしてはトップクラスの会社向けで、10億とか100億のプロジェクトをぶんぶん回しているような人でも、平気で言う。
加えてプログラマからは、「ここおかしくないですか？」「えー。こんなの無理ですよ」「書いてある意味がわからない…」など言われてしまう。
意見貰うのは良いことなのだけど、大抵プログラマに仕様書（設計書）が落ちて来た時って、お客さんと散々討議して、時間がないから半ば無理くり仕様書として承認してもらっちゃってたりすることが多いから、プログラマに初めて見せた後で、内容を変更したくないと思う人が多い。
特にお客さんに対し、「ここからの変更は仕様変更ですよ」とかタンカ切ってたりすると、もう顔真っ赤にして「書いてある内容で合意したんだからその通りに作りなさい」的になる。
問題はSEの仕事が、仕様書（設計書）を作る役割のようになっていることだと思う。
お客さんと話して仕様を詰めるのはリーダーの役割
プログラム書くのはプログラマの役割
開発するシステムの規模が小さいなら、一人でお客さんと話して、一人で作っていいと思う。開発するシステムの規模が大きいなら、責任範囲を明確にしてサブシステムごとにリーダーを配置して、その人が作るものを手伝うプログラマを雇えばいいと思う。お客さんとの話を漏らしちゃいけないと言うなら、レコーダーで録音して音声認識ソフトで文字起こしすればいい。
正直、何年もシステム開発の仕事をしていて、システムエンジニア（ＳＥ）っていうのだけはどうしても馴染めない。「プログラミングが苦手だけど、責任感なく仕事をしたい」と言う人向けの職業かなと思ってしまう。
もしかしたら日本の「年功序列」に当てはめたらこうなったのかもね(｡･ω･)ﾉﾞ