SEとは?現場17年で見た仕事の実態5つ

SEの一般的な定義

システムエンジニア(SE)とは、顧客の要望をヒアリングし、システムの要件定義や設計を行う技術者のことです。プログラマー(PG)が実際にコードを書く役割であるのに対し、SEはシステム全体の設計や仕様を決める立場とされています。

多くの入門書では、SEは上流工程を担当し、PGは下流工程を担当すると説明されます。要件定義、基本設計、詳細設計がSEの仕事、プログラミングとテストがPGの仕事というのが教科書的な整理です。

実際のIT現場ではどうなのか

現場では、このような綺麗な役割分担はほとんど存在しません。私は17年間SEとして働いてきましたが、実際にはコードも書きますし、テストもやります。逆にPGという肩書きの人が要件定義に同席することもあります。

特に中小規模のプロジェクトでは、SEとPGの境界は曖昧です。朝は顧客と要件定義の打ち合わせをして、午後は自分でコードを書き、夕方には結合テストの確認をする。これが普通のSEの1日だったりします。

大規模プロジェクトになると分業が進みますが、それでもSEがまったくコードを書かないわけではありません。むしろ技術的な判断をするために、実装の詳細を理解している必要があります。設計だけして後は任せるというスタイルは、現場では通用しません。

PGとSEの本当の違い

では何が違うのか。私の経験では、SEとPGの違いは担当工程ではなく、責任範囲と意思決定の有無です。

SEは顧客の要望を聞いて、それをどう実現するか決める立場です。技術的な選択肢が複数ある中で、どれを選ぶか判断します。予算、納期、品質のバランスを考えながら、最適解を探す役割です。

一方、PGは与えられた仕様に従って実装します。もちろん実装レベルでの判断はありますが、システム全体の方向性を決めるのはSEの仕事です。

つまり、SEとPGの違いは上流か下流かではなく、意思決定をするかしないかにあります。現場では両方の作業をやりながらも、最終的な判断をする人がSEと呼ばれているのが実態です。

筆者の経験

私は最初の5年間をプログラマーとして過ごし、その後SEにキャリアチェンジしました。当時は上流工程を担当できることに憧れていましたが、実際にSEになってみると想像とはかなり違いました。

最初に配属された金融系プロジェクトでは、SEという肩書きでしたが、やっていることはほぼPGと同じでした。設計書を書いて、自分で実装して、テストもする。違いは週に一度、顧客との定例会議に出席することくらいです。

私はSEとして17年のキャリアを積んできました。1998年から2015年頃まで、金融、保険、製造、公共など多数の業界でSEとして働いてきました。特に印象的だったのは、2001年から半年間担当したクレジットカード会社のダイレクトメール作成Webシステムです。50名体制のチームで、私は要件定義から設計、実装、テストまで幅広く担当しました。SEの仕事は、教科書にはシステムエンジニアリング全般と書かれていますが、現場では顧客との対話、業務理解、設計、コーディング、テスト、運用引き継ぎまで、幅広い工程を担当します。PGよりも上流工程、PMよりも技術寄り、というポジションです。SEの経験は、後のPL、PMOのキャリアの土台になりました。技術と業務の両方を理解しているからこそ、マネジメント側に立った時にも現場感覚を保てます。

この経験から学んだのは、SEの本質はコードを書くか書かないかではなく、顧客の課題を理解し、それを技術で解決する道筋を示すことだということです。そのためには実装レベルの知識が不可欠で、設計だけできても現場では役に立ちません。

SE経験を積む中で見えてきたこと

17年間SEをやってきて気づいたのは、SEに求められるスキルは時代とともに変化しているということです。以前は技術知識があれば通用しましたが、今は違います。

現在の自動車保険業界の運用保守プロジェクトでは、技術的な判断よりも、関係者間の調整や優先順位付けに時間を取られます。開発ベンダー、保守ベンダー、社内の業務部門、それぞれの立場や事情を理解しながら、プロジェクトを前に進める力が求められています。

技術は当然必要ですが、それだけでは不十分です。ビジネスを理解し、人を動かし、リスクを予測する。こうした能力がSEには必要になってきています。

具体例

実際の現場でSEがどう動くのか、具体的なケースを見ていきましょう。

ケース1:要件定義での判断

あるECサイトの刷新プロジェクトで、顧客から「検索機能を高速化したい」という要望がありました。PGであれば「わかりました、実装します」で終わりですが、SEはそこで立ち止まります。

なぜ高速化が必要なのか。現状の検索速度は何秒で、目標は何秒なのか。ユーザー数はどれくらい増える見込みなのか。こうした質問を顧客に投げかけます。

ヒアリングの結果、実は検索速度そのものではなく、検索結果の精度が問題だったことが判明しました。技術的には全文検索エンジンの導入ではなく、検索アルゴリズムの改善で対応できる案件でした。

このように、SEは顧客の要望をそのまま受け取るのではなく、本当の課題は何かを見極める必要があります。技術的な実現方法を複数提示し、それぞれのメリット・デメリットを説明し、最終的な判断を顧客と一緒に行います。

ケース2:設計段階での技術選定

医療系システムの開発で、患者データを管理するデータベース設計を担当したときのことです。セキュリティ要件が厳しく、個人情報保護のために暗号化が必須でした。

技術的には複数の選択肢がありました。データベース全体を暗号化する方法、特定のカラムだけ暗号化する方法、アプリケーション層で暗号化する方法。それぞれ性能、コスト、運用負荷が異なります。

SEとしての判断は、要件、予算、運用体制を総合的に考慮して行います。このケースでは、運用チームのスキルレベルを考慮し、データベース機能を使った透過的暗号化を選択しました。性能は若干落ちますが、運用負荷が最も低い選択です。

こうした判断は、技術だけでなく、プロジェクト全体を俯瞰する視点が必要です。最新技術を使えば良いわけではなく、そのシステムを誰が運用するのか、予算はどうなのか、納期は間に合うのか。こうした制約条件の中で最適解を見つけるのがSEの仕事です。

ケース3:障害対応での意思決定

現在担当している自動車保険の運用保守では、障害が発生したときの対応判断もSEの役割です。

深夜にシステム障害が発生し、サービスが一部停止しました。原因は外部連携先のAPIの仕様変更でした。このとき、SEは複数の選択肢から対応方針を決めなければなりません。

一時的に手動運用に切り替えて朝まで持たせるか、深夜でも開発チームを呼んで緊急修正するか、それともサービス自体を一時停止するか。それぞれ業務への影響、コスト、リスクが異なります。

私はまず影響範囲を確認しました。停止しているのは見積もり機能の一部で、契約には影響がない。次に、手動運用の実現可能性を業務部門に確認。結果として、朝まで手動運用で対応し、翌営業日に恒久対策を実施する判断をしました。

この判断には、技術的な知識だけでなく、業務への理解、コスト感覚、リスク評価が必要です。SEはこうした総合的な判断を、限られた時間の中で行う必要があります。

筆者独自の考察

ここまで見てきたように、SEの仕事は教科書で説明される上流工程担当者という定義とは大きく異なります。私が17年間SEをやってきて感じるのは、SEという職種は時代とともに変化し続けているということです。

SEに本当に必要なスキル

一般的にはSEには技術力が必要だと言われますが、私はそれだけでは不十分だと考えています。もちろん技術は基礎として不可欠です。しかし、技術だけあっても良いSEにはなれません。

私が思うSEに必要な能力は、大きく3つあります。1つ目は課題発見力です。顧客の言葉をそのまま受け取るのではなく、本当の課題は何かを見抜く力。2つ目は選択肢を示す力です。技術的な実現方法を複数提示し、それぞれのメリット・デメリットを説明できる力。3つ目は意思決定力です。限られた情報、時間、予算の中で、最適な判断をする力。

この3つは、技術書を読んでも身につきません。現場で経験を積み、失敗を重ねながら習得していくものです。

SEのキャリアパスについて

SEからのキャリアパスとして、プロジェクトリーダー(PL)やプロジェクトマネージャー(PM)が挙げられます。私自身もSEからPMO、そして現在は複数プロジェクトのマネジメントを担当しています。

ただし、SEからPLやPMになることが唯一のキャリアパスではありません。技術を深めてスペシャリストになる道もありますし、コンサルタントになる道もあります。

私が考えるのは、SEという職種にこだわるのではなく、自分が何を実現したいのかを明確にすることです。顧客の課題を解決したいのか、技術を極めたいのか、組織を動かしたいのか。それによって進むべき方向は変わります。

私の場合は、プロジェクト全体を見渡し、様々な課題を調整しながら前に進めることに面白さを感じたため、PMOという道を選びました。技術は今も勉強し続けていますが、それはマネジメントの判断材料として必要だからです。

これからSEを目指す人へ

SEを目指す若い方からよく相談を受けますが、私はいつも同じことを伝えています。最初はとにかくコードを書くことです。

SEになりたいからといって、いきなり上流工程だけやろうとするのは間違いです。実装経験がないSEは、現場では信頼されません。設計がどれだけ実装に影響するのか、この技術選定がどれだけ運用負荷を増やすのか、それは実装経験がないと理解できません。

私自身、最初の5年間をPGとして過ごしたことは、その後のSEキャリアに大きく役立っています。コードが書けるSEは、開発チームとのコミュニケーションもスムーズですし、技術的な判断にも説得力があります。

SEは技術者である前に、課題解決者です。顧客の困りごとを理解し、それを技術で解決する。そのためには幅広い知識と経験が必要です。焦らず、一つひとつのプロジェクトで学びを積み重ねていくことが、結果として良いSEへの近道だと私は考えています。

読者が実務で使えるチェックリスト

あなたが現在SEとして、あるいはこれからSEを目指す立場として、実務で確認すべき項目をまとめました。以下のチェックリストを定期的に見直すことで、SEとしての成長を確認できます。

チェック項目	確認内容	目安
実装経験	直近1年でコードを書いたプロジェクトはあるか	最低でも年2〜3案件
要件定義スキル	顧客の要望から本質的な課題を引き出せているか	ヒアリング時に「なぜ」を3回以上問えているか
技術選定能力	複数の技術選択肢を提示し、メリット・デメリットを説明できるか	1つの課題に対し最低3つの選択肢を用意
意思決定経験	限られた情報で技術的な判断を下した経験があるか	月1回以上の判断機会
ビジネス理解	担当システムの業務目的や収益構造を説明できるか	顧客の業務フローを図示できるレベル
コミュニケーション	技術的な内容を非技術者に説明できるか	専門用語を使わず3分で説明可能
継続学習	新しい技術や手法を定期的にキャッチアップしているか	月1冊以上の技術書または週3本以上の技術記事

このチェックリストで3つ以上該当しない項目があれば、意識的にその分野の経験を積むことをお勧めします。SEとしてのスキルは、特定の技術知識だけでなく、課題解決力、判断力、コミュニケーション力の総合力です。バランスよく成長することが、長期的なキャリア形成につながります。