20年前、SE - システム・エンジニア という職種は花形とみなされていました。今はどうでしょう？ 私自身は今でも SE という職種には花があると思っています。ところで、私が SE と認識している業務は、次のようなものです。
- お客様の業務フローをヒアリングする。（インタビュアーとしての能力）
- 業務フローの問題点を把握する。（業務知識と洞察力、推理力、想像力）
- IT を使った業務フロー改善を検討する。（他社より一歩進んだITの知識、経営者からみた効果）
- お客様にプレゼンテーションし、信頼を得る。（プレゼンテーション能力、真摯さ）
- 責任をもってプロジェクトを推進し、成功に導く。（リーダーシップ）
- プログラマへの適切な指示、進捗管理、納期調整。（関係者との調整能力）
これらをすべて満たした人材にとって、SE という仕事は実に魅力的です。お客様に提案し、いっしょになって業務改善に取り組む。現場からは「こまごまとした業務が整理されたおかげで、本来やらなければならなかったテーマに取り組めるようになった。」と喜ばれる。経営陣からは「現場が生き生きとなって、結果としてお客様満足度が向上し、売上・利益ともに向上した。」と感謝される。こういう経験ができた人は大きく成長します。IT の知識が役に立ったと実感できる瞬間です。
しかし現実には、このような経験ができたという話は滅多にきかなくなりました。多くの企業にとって SE とはプログラマの管理者か、上からの指示を部下に伝えるミドル層か、外注先（最近ではオフショア先）の管理を行う職種を SE と呼んでいるようにみえます。
なぜ、こうなってしまったのか。
私は、経験を積んだプログラマのキャリアパスが SE である、という誤った認識が背後にあると感じています。その理由も単純で、人月制度の下でお客様から高い単金をいただくためにはプログラマの次に SE という名目を与えないと売上があがらないという仕組みのためです。SE という肩書きで単金を上げることができるという（SIer にとって重要な）動機付けがあったわけです。
しかし本来、能力の高いプログラマと、能力の高い SE は求められるスキルが違います。業務アプリケーション開発の世界で「プログラマ = 下流工程」と位置づけてしまったところが問題でした。さらに何故そうなったかを追求すると、そこには「システム開発は人海戦術である」という考え方があります。人を多く投入すれば、システム開発は成功するというのはすでに時代錯誤のはずですが、いまだにそうやって仕事をしているところが多い以上、SE という業務内容がそれにあわせて変わってしまったのは必然ともいえます。
それでも私は、冒頭にあげた能力をもっていることを示す職種 - その呼び方は今や SE ではないのかも知れませんが - の必要性がなくなることはないと思っています。
SE が、本来あるべき仕事内容に戻るためには開発の構造的な問題である人海戦術方式を見直すことが必要です。少数の開発陣で大規模システムを構築すること。このテーマに正面から取り組み、成功させるノウハウを蓄積したところが「次の時代を担う SIer」になると確信しています。
