「SIerで開発してるけど、社内SEになったら開発業務ってどう変わるんだろう…」
「もっとユーザーに近い立場で、事業に貢献する開発がしたいな…」
SIerやSESで開発に携わっていると、キャリアの選択肢として「社内SE」が気になりますよね。しかし、その「システム開発」の仕事内容は、会社によって全く異なり、実態が掴みにくいのではないでしょうか。
結論から言うと、社内SEのシステム開発における役割とは、SIerとは異なり、事業の成功というゴールに向けてプロジェクト全体を動かす「舵取り役」です。
この記事では、社内SEが開発プロジェクトにおいて、企画からリリースまでの各ステップでどのような役割を担うのか、その具体的な仕事内容を徹底的に解説します。この記事を読めば、あなたが社内SEとして開発に携わる未来を、より明確にイメージできるようになるはずです。
この記事を書いた人（マサトシ）
この記事を読むと、こんなことが分かります！
- 社内SEの開発における「ゴール」と「責任」のSIerとの違い
- どんな時に開発プロジェクトが始まるのか（開発案件の4つの種類）
- 企画からリリースまで、各フェーズでの社内SEの具体的な役割と仕事内容
- 開発プロジェクトを成功に導くために本当に必要なスキル
この記事は「業務システム担当」の仕事の中でも、特に「システム開発」フェーズに絞って深掘りする詳細記事です。まずは担当業務の全体像を掴みたい方は、以下の子記事からご覧ください。
＞＞社内SEの「業務システム担当」とは？仕事内容の全体像を4つのフェーズで徹底解説
SIerとは違う！社内SEのシステム開発における「ゴール」と「責任」
社内SEの開発業務を理解する上で、まずSIer/SESとの根本的なマインドセットの違いを認識することが不可欠です。
SIerのゴールが、契約に基づきシステムを「納期通りに納品すること」であるのに対し、社内SEのゴールは、そのシステムを通じて「自社の事業に貢献すること」です。システムはあくまで手段。業務が効率化されたか、売上が上がったか、といったビジネス上の成果が最終的な評価に繋がります。
どんな時に始まる？社内SEが手掛ける開発案件の4つの種類
では、具体的にどのようなきっかけで開発プロジェクトは始まるのでしょうか。社内SEが手掛ける開発案件は、主に以下の4つに分類されます。社内SEは限られた予算と人員の中で、経営層と協議しながらこれらの優先順位を決めていく役割も担います。
- 制度対応案件
消費税変更、インボイス制度対応など、法制度の変更に伴うシステム改修です。対応必須のため、最も優先度が高くなることが多い案件です。 - ユーザー要望案件
「この作業を自動化したい」「新しい機能が欲しい」といった事業部門からの業務改善要望に応える開発です。軽微なものは通常の保守範囲で対応することもあります。 - 戦略案件
AI導入や大規模な業務改革に伴うシステム刷新など、経営戦略に直結する開発です。企業成長の鍵を握る、大規模で影響力の大きいプロジェクトです。 - サポート終了対応案件
OSやソフトウェアのサポート終了に伴うシステム入れ替えやバージョンアップです。セキュリティリスクを回避するために計画的な対応が求められます。
【本編】システム開発における社内SEの役割と仕事内容
ここからは、開発プロセスを時系列で追いながら、各ステップで業務システム担当が担う役割を具体的に解説します。
STEP1：企画・要件定義フェーズの役割
この最初のステップは、「何を、なぜ作るのか」を定義する、プロジェクトの成否を分ける最も重要なフェーズです。
ここでの社内SEの役割は、業務部門の「要望」を鵜呑みにするのではなく、その背景にある「真の課題」を突き止め、本当に価値のあるシステムを構想することです。
- 課題ヒアリングと目的設定：業務部門に深く入り込み、現状の業務フローや課題をヒアリング。「なぜこのシステムが必要か」という目的を明確にします。
- 費用対効果の算出と提案：開発にかかる費用と、導入によって得られる効果（業務効率化、コスト削減など）を算出し、経営層に「投資する価値がある」ことを説明し、承認を得ます。
- 要件定義：システムの具体的な機能要件（何ができるか）と非機能要件（性能、セキュリティなど）を定義します。ここでの定義が曖昧だと、後の工程で手戻りが発生し、プロジェクト失敗の大きな原因となります。
STEP2：設計・ベンダー選定フェーズの役割
要件が固まったら、それを実現するための設計と、開発を誰が行うかを決めるフェーズです。
ここでの社内SEの役割は、技術的な実現性と、事業要求のバランスを取ることです。
- 基本設計のレビュー：システムの全体像や骨格を定める基本設計書をレビューし、要件が満たされているか、将来的な拡張性はあるかなどを確認します。
- 開発体制の決定：この後の開発を外部に委託するか（外注）、自社で行うか（内製）を決定します。この判断は企業の開発方針やプロジェクトの特性によって異なります。
- 【外注の場合】RFP作成とベンダー選定：外部に委託する場合、RFP1を作成し、最適なベンダーを選定・契約します。
STEP3：開発・テスト管理フェーズの役割
いよいよシステムを形にしていくフェーズです。ここでの社内SEの役割は、プロジェクトが計画通りに進んでいるかを管理・監督することです。
- 進捗・品質・課題管理：ベンダーから定期的に進捗報告を受け、遅延や品質の問題がないかをチェックします。発生した課題は迅速に関係者と共有し、解決に導きます。
- 成果物のレビュー：ベンダーが作成した詳細設計書やテスト結果報告書などをレビューし、品質を担保します。
- ユーザー受入テスト（UAT）の計画：開発者側のテスト（単体・結合テスト）とは別に、最終的にシステムを使うユーザー自身がテストを行う「UAT」の計画を立てます。
UATの具体的な進め方については、以下の記事で詳しく解説しています。
＞＞社内SEが主導するUAT（ユーザー受入テスト）の進め方｜計画から実行まで
STEP4：リリース・導入フェーズの役割
開発の最終工程です。ここでの社内SEの役割は、作り上げたシステムを、安全かつ円滑に本番環境へ移行させることです。
- 移行計画の策定とリハーサル：古いシステムから新しいシステムへ、いつ、どのように切り替えるかという詳細な計画を立て、本番前にリハーサルを行います。
- 業務トレーニングの実施：ユーザーが新しいシステムをスムーズに使えるよう、説明会やマニュアル作成といったトレーニングを実施します。
- リリース判定：UATの結果や残課題などを総合的に評価し、システムを本番稼働させて良いかどうかの最終判断を下します。
まとめ：社内SEの開発担当は、事業を動かすプロジェクトの「舵取り役」
ここまで、社内SEがシステム開発において担う役割を、プロセスに沿って解説してきました。
SIerのように「作る」ことの専門家であるのに対し、社内SEは、事業目的の達成のために、技術、ビジネス、人、予算といったあらゆる要素を調整しながらプロジェクト全体を前に進める「舵取り役」と言えます。
もちろん、技術的な知見は不可欠ですが、それ以上にビジネスを深く理解する力、そして社内外の関係者を動かすコミュニケーション能力や管理能力が求められる、非常に挑戦的でやりがいのある仕事です。
社内SEへの転職を具体的に考え始めたあなたへ
社内SEというキャリアに興味が湧いたら、次はいよいよ具体的な転職活動の準備です。でも、「何から始めればいいの？」「自分に合う転職エージェントは？」と迷ってしまいますよね。
そんなあなたのために、転職の成功確率をグッと上げるための記事を2つご用意しました。ご自身の状況に合わせて、ぜひご覧ください。
FAQ：「社内SEのシステム開発」についてよくある質問
Q1. この記事では「作らない」側面が強調されていますが、プログラミングスキルは不要ですか？
A1. 不要ではありません。特にベンダーが作成した設計書のレビューや、技術的な課題の議論において、プログラミングの知識は大きな武器になります。開発を内製している企業であれば、もちろん必須スキルとなります。ただし、外注管理がメインの企業では、プログラミングそのものよりも、プロジェクト全体を俯瞰する管理能力が重視される傾向にあります。
Q2. SIerでの開発経験は、社内SEのシステム開発でどのように活かせますか？
A2. 幅広く活かせます。特に、要件定義、設計、テストといった上流工程の経験や、プロジェクト管理スキルは、ベンダーマネジメントや社内プロジェクト推進に直結します。自身が開発を経験しているからこそ、ベンダーが提示する作業量やスケジュールの妥当性判断も的確に行えます。
Q3. 社内SEの開発業務で、最も難しいのはどのフェーズですか？
A3. 多くの場合、「企画・要件定義フェーズ」が最も難しく、かつ重要です。技術的な難しさというより、様々な立場の関係者の意見を調整し、「何のために、何を作るのか」という合意形成を行う政治力やコミュニケーション能力が問われるからです。ここでの決定が、プロジェクト全体の成否を左右します。
Q4. システム開発を外部のベンダーに委託する場合、社内SEの最も重要な役割は何ですか？
A4. 「発注者」としてプロジェクトを成功に導くことです。具体的には、自社のビジネス要件を正確にベンダーに伝え、期待通りのシステムが予算内・納期内に開発されるよう、契約から進捗管理、品質管理、受け入れまでを主導します。技術的な知見に加えて、コミュニケーション能力、交渉力、プロジェクト管理能力が求められます。
用語解説
- 1. RFP (Request for Proposal)
- 提案依頼書。システム開発などを外部に委託する際に、発注先の候補となるITベンダーに対して具体的なシステム要件や調達要件を示し、提案書の提出を依頼するための文書。