システムエンジニア（SE）という職業について、「一日中パソコンに向かって、黙々とプログラミングをしている人」というイメージを持っている方も多いのではないでしょうか。
しかし、実際の開発現場では、必ずしもすべてのSEがプログラミング業務をメインとしているわけではありません。
「コードを書かないSEは、一体何をしているのだろう？」
この記事では、そんな疑問を解消していきます。
具体的には、以下のようなことについて詳しく解説していくので、是非参考にしてください。
- なぜSEはプログラミングをしないのか
- SEに求められるスキルは何なのか
- SEがプログラミングを求められる場面はどういった時なのか
【本記事の信頼性】
- 執筆者は元エンジニア
- 大手プログラミングスクールのWebディレクター兼ライターを経験
- 自らも地元密着型のプログラミングスクールを運営
受講生から評判の良いプログラミングスクール
スクール |
特徴 |
受講料金 |
| 大手比較サイトで4年連続人気NO.1！受講生からの評判も非常に高く、Web系のエンジニアを目指すならRUNTEQ一択。 | 657,000円 （最大約53万円の給付金が適用される） |
|
| 月単価80万円以上の現役エンジニア講師による指導！一度入会すればサポートは半永久的。 | 498,000円 |
|
| 格安で質の高いWeb制作スキルを習得したい人におすすめ！業界最安級の料金でありながら、コミュニティやサポートが充実。 | 129,800円～ |
|
| 完全無料でプログラミングが学べる貴重なスクール！最短1ヶ月で卒業可能。ゼロスク運営会社への就職もできる。 | 完全無料 |
|
| 長期間に渡って学習し、希少人材を目指す人に最適なスクール！受講料は高いものの、高収入を得られる人材を目指せる。 | 96～132万円 |
【結論】プログラミングをしないシステムエンジニアは多い
まず結論からお伝えすると、実際の開発現場には、日常業務でプログラミング（コーディング）をほとんど、あるいは全くしないシステムエンジニアは数多く存在します。
特に、企業の規模が大きくなるほど、その傾向は顕著になります。
ただし、ここで注意すべきなのは、「プログラミングをしない」ことと「プログラミングの知識が不要」であることは、全く意味が異なるという点です。
コードを書く機会がなくても、システムの設計やプロジェクト管理を行う上で、プログラミングの基本的な知識は不可欠となります。
では、なぜ「プログラミングをしないSE」「プログラミングを担当するプログラマー」といった役割分担が生まれるのか、その理由を詳しく見ていきましょう。
プログラミングをしないシステムエンジニアが多い理由
この項目では、プログラミングをしないシステムエンジニアが多い主な理由について紹介していきます。
基本的には上流工程を担当するから
一般的なシステム開発は、川の流れのように、上流から下流へと進んでいきます。
SEが主に担当するのは、この流れの「上流工程」です。
上流工程は、顧客がどのようなシステムを求めているのかをヒアリングし、システムの全体像や仕様を決定する「要件定義」や「基本設計」といった工程です。
どのような機能が必要か、どのような画面にするか、といったシステムの根幹を決定する、いわば「設計図」を作る仕事と言えます。
下流工程は、上流工程で作られた設計図を基に、実際にプログラミングを行い、システムを形にしていく「詳細設計」「実装（プログラミング）」「テスト」といった工程です。
SEの主戦場はこの上流工程にあるため、必然的に顧客との打ち合わせやドキュメント作成に費やす時間が多くなり、プログラミングから離れることになるのです。
プログラマーとは役割が違うから
上流工程でSEが作成した設計書をもとに、下流工程の「実装（プログラミング）」を専門に担当するのが「プログラマー（PG）」です。
SEとプログラマーは協力関係にありますが、担当する工程と責任範囲が明確に分かれています。
家づくりに例えるならば、顧客の要望を聞いて「どのような間取りにするか」「どのような機能を持たせるか」を考えて家の設計図を描くのがSE（設計士）の役割です。
そして、その設計図通りに木材を加工し、釘を打って家を実際に建てるのがプログラマー（大工）の役割、と考えるとわかりやすいでしょう。
設計士が必ずしも自分で釘を打つわけではないのと同じように、SEも必ずしも自分でコードを書くわけではないのです。
特に大手SIerでは分業体制が明確だから
こうした役割分担は、特に「SIer（エスアイヤー）」と呼ばれる、大規模なシステム開発を請け負う企業で顕著に見られます。
大手SIerが手掛けるプロジェクトは、金融機関の勘定系システムや官公庁の基幹システムなど、関わる人数も予算も非常に大規模になります。
そのため、効率的に開発を進めるために徹底した分業体制が敷かれています。
プロジェクトの全体管理や顧客との折衝、設計書の作成といった上流工程は自社のSEが担当し、実際のプログラミング作業は、協力会社や下請け企業のプログラマーに委託するというケースが一般的です。
したがって、大手SIerに所属するSEは、キャリアを重ねるほどプログラミングの現場から離れ、マネジメントや顧客対応に専念することが多くなります。
システムエンジニアがプログラミングをしない企業の主な特徴
プログラミングをしないSEが活躍する場は、どのような企業に多いのでしょうか。
代表的な企業のタイプをいくつか紹介します。
大手SIer
前述の通り、大手SIerはプログラミングをしないSEの代表的な勤務先です。
金融機関や官公庁などの巨大な基幹システム開発プロジェクトにおける、SEの主な仕事は以下のようなものです。
- 顧客の複雑な業務要件の整理
- 何百人もの開発者を動かすための詳細な設計書の作成
- プロジェクト全体の進捗管理
このように、個別のプログラミングスキルよりも、大規模プロジェクトを動かすマネジメント能力や、顧客と開発チームの橋渡し役となる調整力がより重視される傾向にあります。
ITコンサルティング会社
ITコンサルティング会社に所属するSEも、プログラミングを直接行うことはほとんどありません。
彼らの主な役割は、企業の経営課題を分析し、その解決策として最適なIT戦略を提案することです。
技術的な知見をもとに、どのようなシステムを導入すべきか、どのような技術を採用すべきかを提言しますが、その後の実装は開発を専門とするクライアント企業が担当します。
ITコンサルでは、技術力以上に、経営層を納得させる論理的思考力やプレゼンテーション能力が求められます。
外部委託開発をメインにしている会社
自社内に大規模な開発チームを持たず、システム開発を外部の制作会社やフリーランスに委託している事業会社でも、社内のSEがプログラミングをすることはありません。
こうした企業における「社内SE」の主な仕事は、経営層や事業部門の要望を吸い上げて開発要件を定義し、外部の委託先を選定・管理することです。
外部のエンジニアが作成した成果物が、自社の要求を満たしているかを受け入れるテストなども重要な業務となります。
業務系や基幹系システムを中心に扱っている会社
長年にわたって特定の業界（例：金融、製造、流通など）の業務システムや基幹システムを開発・保守している企業では、ベテランのSEがプログラミングから離れ、顧客の業務知識を活かした要件定義や、若手メンバーの管理に専念するケースが多く見られます。
こうした領域では、最新のプログラミング技術よりも、業界特有の複雑な業務ルールや法律に関する深い知識（ドメイン知識）の方が、システムの品質を左右する上で重要になるためです。
システムエンジニアはプログラミングができなくても問題ない？
結論として、所属する企業や担当するプロジェクトによっては、SEが日常業務でプログラミングをしなくても仕事は成り立ちます。
しかし、だからといってプログラミングの知識が全くなくても問題ない、と考えるのは非常に危険です。
コードを書く「スキル」と、コードを理解できる「知識」は別物です。
たとえ自分が直接コードを書かなくても、プログラミングの基本的な仕組みや考え方を理解していなければ、質の高い上流工程の仕事はできません。
具体的には、プログラミングのことを理解していないことで、以下のような問題が発生する可能性があります。
実現不可能な設計をしてしまう
プログラミングの難易度や技術的な制約を知らなければ、机上の空論で、実装に膨大なコストがかかる、あるいは技術的に実現不可能な設計をしてしまう可能性があります。
結果として、プロジェクトの途中で大きな手戻りが発生し、プログラマーからの信頼を失うことになります。
正確な工数を見積もれない
開発に必要な期間や人員を見積もる際、プログラミングの知識がなければ、その作業の難易度を判断できず、現実離れしたスケジュールを立ててしまい、プロジェクトを炎上させる原因になります。
プログラマーと円滑に話せない
設計の意図をプログラマーに正確に伝えたり、プログラマーから技術的な相談を受けたりする際、プログラミングという共通言語がなければ、円滑なコミュニケーションは図れません。結果として、プログラマーから信頼されない「使えないSE」のレッテルを貼られてしまうでしょう。
システムエンジニアがプログラミングをする場面
もちろん、SE自身が積極的にプログラミングを行う企業や場面も数多く存在します。
特にWeb業界やスタートアップでは、SEもコードを書くことが当たり前とされています。
会社の方針でSEも開発に参加することになっている
Web系の自社サービスを開発している企業や、アジャイル開発を採用している比較的小規模な開発会社では、SEとプログラマーの垣根が曖昧です。
このような企業では、一人のエンジニアが設計から実装、テストまでを一気通貫で担当することが一般的で、むしろ高いプログラミングスキルがSEにも求められます。
「フルスタックエンジニア」としての活躍が期待される環境とも言えるでしょう。
要件定義前に「技術的に可能か」を検証する
新しい技術や未知のライブラリを採用する際、本格的な設計に入る前に、その技術が本当に要件を満たせるのかを検証するための試作品（プロトタイプ）を作ることがあります。
このような技術検証（PoC: Proof of Concept）の場面では、SEが自ら手を動かして簡単なプログラムを書き、実現可能性やパフォーマンスを調査します。
この検証結果が、後の技術選定や設計の重要な判断材料となります。
人材不足で開発要員が足りていない
プロジェクトの途中で、予期せぬ仕様変更やトラブル、あるいはメンバーの離脱などにより、開発人員が不足してしまうことがあります。
そのような緊急時には、上流工程を担当していたSEが、一時的に実装のヘルプとしてプログラミング作業を行うことも珍しくありません。
プロジェクトを円滑に進めるための、柔軟な対応力が求められる場面です。
開発が遅れていて納期に間に合わない可能性がある
プロジェクトの進捗が計画から大幅に遅延し、納期が迫っている場合も同様です。
SEが自ら実装に加わって開発を加速させ、遅れを取り戻そうとすることは、現場では「火消し」とも呼ばれ、しばしば見られる光景です。
プロジェクトの成功に責任を持つ立場として、役割にとらわれずに貢献する姿勢が求められます。
人材価値を高めるためにSEもプログラミングを積極的に学ぶべき
たとえ現在の職場がプログラミングをしない環境であったとしても、自身の市場価値を高め、将来のキャリアの選択肢を広げるためには、プログラミングスキルを学び、磨き続けることを強くおすすめします。
プログラミングを深く理解しているSEは、より現実的で質の高い設計ができ、プログラマーからの信頼も厚くなります。
その結果、プロジェクトの成功確率も高まるでしょう。
また、将来的に転職を考えた際、実装もできるSEは、マネジメント専門のSEよりも応募できる企業の幅が格段に広がります。
Web系企業やスタートアップへの転職も視野に入れることができるようになるはずです。
技術のわかるリーダーとして、より高いポジションや年収を目指す上でも、プログラミングスキルは強力な武器となるのです。
まとめ
この記事では、システムエンジニアとプログラミングの関係性について、開発現場のリアルな視点から詳しく解説してきました。
システムエンジニアという職業は、単一の働き方で定義できるものではありません。
そして、プログラミングはあくまでシステムを作るための一つの手段です。
自身の興味や適性に合わせて、どのような形で技術と関わっていくのか、キャリアプランを考えてみてください。
Follow me!
