コトラ（広報チーム） 
社内SEにおける上流工程の位置づけ
上流工程が指す仕事の範囲
上流工程とは、システムを作り始める前に「何のために導入するのか」「どの業務をどう変えるのか」「どの機能が必要か」を決める仕事です。社内SEの場合は、利用部門の困りごとを把握する段階から関わり、企画、要件定義、基本設計、導入計画の作成までを担うことが一般的です。
プログラムを作る作業そのものは社内の開発担当者や外部のベンダーが担う場合でも、業務上の目的や優先順位を決める役割は社内SEに求められます。技術だけでなく、社内業務や組織の事情を理解したうえで判断することが上流工程の特徴です。
企画・起案から基本設計までの流れ
社内SEの上流工程は、現場から寄せられた相談や経営上の課題をきっかけに始まります。まず、現在の業務手順、利用している帳票やシステム、作業時間、ミスが起きやすい箇所などを確認します。そのうえで、システム化によって解決すべき課題を整理します。
次に、導入の目的、対象となる部門、期待する効果、概算費用、進め方をまとめて企画として起案します。承認後は、必要な機能や利用者、データ、他システムとの連携を具体化する要件定義へ進みます。最後に、画面や処理の大枠、権限設定、データの扱い方などを定める基本設計を行い、開発や導入の準備を整えます。
開発担当・運用担当との役割分担
社内SEがすべての作業を一人で担うとは限りません。開発担当者やベンダーは、設計書に基づく開発、テスト、技術的な実現方法の検討を担当します。運用担当者は、利用者からの問い合わせ対応、機器やアカウントの管理、障害時の一次対応などを担います。
一方、上流工程を担う社内SEは、利用部門の要望を整理し、開発側に正しく伝え、導入後の運用まで見通して意思決定する役割を持ちます。開発や運用の担当者が動きやすいように、目的と優先順位を明確にすることも重要です。
社内SEが上流工程を担う重要性
外部のベンダーは技術面に詳しくても、企業固有の業務、社内ルール、部門間の関係性まで把握しているとは限りません。そのため、社内の実情を理解する社内SEが間に入り、業務上の要求を整理する必要があります。
上流工程が不十分なまま開発を始めると、導入後に「現場の使い方に合わない」「必要な機能が足りない」「想定より費用が増えた」といった問題が起こりやすくなります。社内SEが早い段階から関わることで、投資の妥当性を見極め、利用されるシステムにつなげられます。
社内SEが上流工程で担う主な仕事
現場課題の把握と業務整理
上流工程の出発点は、現場で起きている問題を正確に把握することです。利用部門への聞き取りを通じて、誰が、いつ、どのような作業をしているのかを確認します。単に「新しいシステムがほしい」という要望を受け取るだけでは、適切な解決策は選べません。
たとえば、入力作業が多いという相談があった場合でも、原因は入力画面の使いにくさとは限りません。データが部門ごとに分かれている、承認手順が複雑である、必要以上に確認作業が重なっているといった業務上の課題が隠れていることがあります。現在の流れを図や一覧にして整理すると、改善すべき点を関係者間で共有しやすくなります。
システム化の企画・起案
課題を整理した後は、システム化の目的と進め方を企画としてまとめます。企画段階では、何を改善するのか、対象範囲をどこまでにするのか、どのような効果を目指すのかを明らかにします。
また、新しいシステムを導入することだけが解決策とは限りません。既存システムの設定変更、利用手順の見直し、入力項目の削減などで対応できる場合もあります。社内SEは、費用や導入期間、利用者への影響を比較し、目的に合う方法を提案することが求められます。
要件定義と優先順位付け
要件定義では、導入するシステムに必要な機能や条件を具体的に決めます。利用者が行う操作、必要なデータ、帳票、検索方法、承認の流れ、閲覧や編集ができる人の範囲などを整理します。
すべての要望を同時に実現しようとすると、費用や期間が膨らみ、かえって導入が遅れるおそれがあります。そのため、業務を進めるうえで必須の要件、できれば実現したい要件、将来的に検討する要件に分けて優先順位を付けます。判断の基準を共有し、利用部門に納得してもらうことが重要です。
基本設計と導入計画の作成
基本設計では、要件定義で決めた内容をもとに、システムの全体像を固めます。具体的には、画面の構成、データの流れ、他システムとの連携、利用者の権限、処理の手順などを整理します。細かな実装方法は開発担当やベンダーが検討する場合でも、業務の目的に合っているかを確認するのは社内SEの重要な仕事です。
あわせて、導入計画も作成します。開発、テスト、利用者への説明、データ移行、本番開始の時期を定め、必要な担当者を明確にします。繁忙期や決算期など、業務への影響が大きい時期を避ける配慮も必要です。
導入後を見据えた運用設計
システムは導入して終わりではありません。利用者からの問い合わせ先、障害発生時の連絡手順、アカウントの発行・削除の方法、権限の見直し、データの保管方法などを事前に決めておく必要があります。
また、制度変更や組織変更、業務の変化によって、システムには継続的な修正が必要になります。導入後に誰が要望を受け付け、どのように判断し、どの範囲まで対応するのかを整理しておくことで、運用の混乱を抑えられます。
上流工程で求められる社内調整
利用部門との認識合わせ
利用部門は、日々の業務を効率化したいという期待を持っています。一方で、社内SEは費用、開発期間、既存システムとの関係、運用負担などを考慮する必要があります。双方の前提が異なるまま進めると、完成後の認識違いにつながります。
認識を合わせるためには、要望を文章だけで確認するのではなく、業務の流れ、画面のイメージ、利用場面などを具体的に共有することが有効です。打ち合わせ後には、決まった内容と持ち帰り事項を記録し、関係者が確認できる状態にします。
経営層への説明と承認取得
システム導入には費用や人員が必要になるため、経営層や決裁者に目的と効果を説明する場面があります。このとき、技術的な説明だけでは判断につながりにくいため、経営上の課題と結び付けて伝えることが大切です。
たとえば、業務時間の削減、入力ミスの抑制、情報の見える化、法令や社内規程への対応、事業拡大に備えた仕組みづくりといった観点で説明します。期待できる効果だけでなく、費用、導入時の負担、実施しない場合のリスクも整理すると、判断材料として活用されやすくなります。
ベンダーとの要件・費用・納期の調整
ベンダーとの調整では、社内の要望を正確に伝え、見積もりや提案内容が目的に合っているかを確認します。要件が曖昧なまま依頼すると、後から追加費用や納期延長が発生しやすくなります。
社内SEは、見積もりに含まれる作業範囲、対象外となる作業、前提条件、保守の内容を確認する必要があります。また、ベンダーから技術的な提案を受けた際には、現場の業務や運用体制に合うかを判断します。専門用語をそのまま社内に持ち込むのではなく、利用部門が理解できる言葉に置き換えて説明する役割も求められます。
複数部門で意見が分かれる場合の対応
複数部門が利用するシステムでは、それぞれの部門が異なる要望を持つことがあります。一方の部門にとって便利な仕組みが、別の部門には負担になる場合もあります。
このような場合は、個別の要望だけで判断せず、全社としての目的、業務への影響、費用、運用のしやすさを基準に整理します。意見が対立している点と、共通して合意できている点を分けて確認し、必要に応じて決裁者に判断を求めます。社内SEが独断で決めるのではなく、判断の根拠を明確にすることが重要です。
決定事項と変更内容の記録管理
上流工程では、打ち合わせを重ねるなかで要件や優先順位が変わることがあります。変更自体は避けられませんが、いつ、誰が、何を、なぜ変更したのかが残っていないと、後で認識の違いが起こります。
要件一覧、会議記録、承認内容、変更履歴を管理し、関係者が確認できるようにします。特に、追加の要望が費用や納期に与える影響は、その都度ベンダーと確認し、社内でも判断を取り直す必要があります。
社内SEの上流工程で必要な力
業務を理解して課題を見つける力
上流工程では、技術の知識だけでなく、現場の仕事を理解する力が欠かせません。利用部門がどのような目的で仕事をしており、どこに手間やミス、待ち時間が発生しているのかを把握する必要があります。
聞き取りを行う際は、要望だけでなく、現在の手順や例外的な対応、繁忙期の状況まで確認します。現場にとって当たり前になっている非効率な作業を見つけることが、改善提案につながります。
相手に合わせて伝える説明力
社内SEは、現場社員、管理職、経営層、ベンダーなど、異なる立場の相手とやり取りします。それぞれが必要とする情報は同じではありません。利用部門には操作や業務への影響を、経営層には費用対効果やリスクを、ベンダーには具体的な要件を伝える必要があります。
専門用語を多用せず、相手が判断や行動に必要な内容をわかりやすく説明することが大切です。また、一方的に説明するだけでなく、相手の理解や懸念を確認しながら進める姿勢も求められます。
要望を整理して判断する力
利用部門からの要望は、必ずしもそのまま実現できるとは限りません。似た要望が複数ある場合や、他の業務に影響する場合、費用に見合わない場合もあります。
社内SEには、要望の背景を確認し、本当に解決すべき課題を見極める力が必要です。そのうえで、緊急性、重要性、利用者の範囲、費用、実現までの期間をもとに優先順位を付けます。対応しない判断をする場合にも、理由と代替案を丁寧に伝えることが求められます。
プロジェクトを進める管理力
上流工程では、複数の関係者が関わるため、予定や課題を管理する力が必要です。必要な作業を洗い出し、担当者と期限を決め、遅れや問題があれば早めに共有します。
特に、利用部門による確認や承認が遅れると、後続の開発やテストに影響します。社内SEは、関係者に適切なタイミングで確認を依頼し、判断が必要な事項を見える化して、プロジェクトが止まらないように進めます。
技術の選択肢を見極める基礎知識
上流工程を担うために、高度な開発技術を必ずしも自ら使いこなす必要はありません。しかし、提案された仕組みの特徴や制約を理解し、自社に合うかを判断するための基礎知識は必要です。
たとえば、既存システムとの連携のしやすさ、データの扱い方、利用者の増加に対応できるか、情報を安全に扱えるか、導入後の保守を続けられるかといった観点を持つことが重要です。技術の流行だけで選ぶのではなく、業務要件と運用体制に合った選択を行います。
上流工程と日常業務を両立する際の課題
ヘルプデスク対応に時間を取られる課題
社内SEは、パスワードの再設定、機器の不具合、操作方法の質問など、日常的な問い合わせに対応することがあります。問い合わせが集中すると、企画や要件整理のために確保していた時間が失われ、上流工程が後回しになりやすくなります。
問い合わせ内容を記録して傾向を把握すると、よくある質問の案内を整備したり、申請手順を見直したりできます。個別対応を減らす仕組みを作ることが、上流工程に時間を使うための第一歩です。
緊急対応による計画変更の課題
システム障害、情報漏えいのおそれ、利用部門の急な業務変更などが起きると、社内SEは緊急対応を優先する必要があります。その結果、計画していた打ち合わせや要件定義が延期されることがあります。
緊急対応を完全になくすことは難しいため、計画には一定の余裕を持たせることが必要です。また、緊急時の連絡経路や担当分担をあらかじめ決めておくと、一人に作業が集中する状況を抑えられます。
要望が増え続ける課題
利用部門との接点が多い社内SEには、日々さまざまな改善要望が寄せられます。個別に対応を約束してしまうと、作業量が増え続け、重要な取り組みに集中できなくなります。
要望を一か所で受け付け、内容、依頼部門、目的、希望時期を記録する仕組みが必要です。そのうえで、定期的に優先順位を見直し、対応方針を関係者へ共有します。
ベンダー任せになりやすい課題
社内に開発経験者が少ない場合、提案や設計の判断をベンダーに任せきりにしてしまうことがあります。しかし、ベンダーは社内業務の最終的な責任者ではありません。業務上の優先順位や運用上の判断は、社内で持つ必要があります。
ベンダーに依頼する範囲と、社内で決める範囲を明確にします。提案内容については、なぜその方法が必要なのか、他の選択肢はあるのか、運用上の負担はどうなるのかを確認し、社内の目的に照らして判断します。
人手や経験が不足する課題
少人数の情報システム部門では、日常運用、問い合わせ対応、プロジェクト管理を同時に担うことがあります。また、上流工程の経験が少ない担当者にとっては、要件定義や社内調整の進め方がわからず、負担を感じることもあります。
すべてを一度に改善しようとせず、業務の記録、要望管理、会議記録の作成など、再利用できる仕組みから整えることが現実的です。外部の知見を活用する場合でも、社内に判断や運用の知識を残す意識が重要です。
上流工程を円滑に進めるための実践方法
問い合わせ対応と企画業務の時間分け
日常の問い合わせに追われる状況を避けるため、問い合わせ対応の時間と、企画・要件整理に集中する時間を意識的に分けます。担当者ごとに役割を分けられる場合は、一次対応の担当とプロジェクト推進の担当を定める方法も有効です。
少人数の場合でも、会議や要件整理のための時間を予定表に確保し、その時間に対応する作業を明確にします。緊急性が低い問い合わせは、すぐに個別対応せず、受付窓口を通して優先順位に沿って処理する運用を作ります。
要望受付の窓口と判断基準の整備
口頭、メール、会議など、複数の経路から要望を受けると、内容が埋もれたり、対応状況がわからなくなったりします。要望受付の窓口を定め、依頼内容を同じ形式で記録できるようにします。
受付時には、困っている業務、対象者、発生頻度、希望時期、期待する効果を確認します。判断基準として、業務への影響、緊急性、法令や社内規程への対応、費用、他の施策との関係を設けると、優先順位を説明しやすくなります。
関係者との定例会議と進捗共有
上流工程では、利用部門、管理職、ベンダーとの情報共有が欠かせません。定例会議を設け、進捗、未決事項、課題、次回までの対応を確認します。会議の頻度は、プロジェクトの規模や進行状況に合わせて設定します。
共有する内容は多すぎても伝わりにくくなるため、現在の状況、決める必要がある事項、遅れやリスク、次の予定を中心にまとめます。問題が大きくなる前に共有し、必要な判断を早めに得ることが重要です。
ベンダーに任せる範囲の明確化
ベンダーに任せる作業と、社内が担う作業を事前に整理します。たとえば、技術的な設計や開発、テストの支援はベンダーに依頼し、業務要件の決定、受け入れ確認、社内利用者への案内は社内が担う形が考えられます。
役割が曖昧だと、「相手が対応すると思っていた」という抜け漏れが発生します。担当範囲、成果物、確認する時期、承認する人を明確にし、契約内容や計画書にも反映させることが大切です。
小規模な改善から始める進め方
大規模なシステム刷新は、関係者が多く、費用や期間も大きくなりがちです。目的や要件が十分に固まっていない場合は、まず一部の業務や部門で小規模に改善を試す方法があります。
小さく始めることで、利用者の反応や運用上の課題を確認し、本格導入前に改善できます。成果を確認しながら対象範囲を広げることで、社内の理解を得やすくなり、手戻りのリスクも抑えられます。
社内SEが上流工程を担うためのキャリア形成
上流工程に必要な経験の積み方
上流工程の力は、業務と関係者を理解する経験を通じて身に付きます。まずは、問い合わせ対応や運用管理を通じて、利用者がどのような場面で困るのかを知ることが基礎になります。その後、改修案件の打ち合わせ、テスト、導入支援などに関わり、システム導入全体の流れを学びます。
会議に同席するだけでなく、議事録の作成、要望の整理、進捗管理、ベンダーとの確認などを担当すると、調整の進め方を実践的に学べます。小規模な改善案件から主体的に担当し、徐々に企画や要件定義の範囲を広げる進め方が現実的です。
現役社内SEが担当範囲を広げる方法
現役の社内SEが上流工程へ関与を広げるには、日常業務で得た情報を改善提案につなげることが有効です。問い合わせ内容や障害の傾向を整理し、繰り返し起きる問題を可視化すれば、単発の対応から業務改善の提案へ発展させやすくなります。
また、ベンダーとの打ち合わせでは、技術的な内容を確認するだけでなく、要件の背景、運用への影響、費用の前提条件を質問します。自分の担当範囲を広げたい意思を上司や関係者に伝え、要件整理や導入計画の作成など、一部の役割から任せてもらうことが重要です。
転職前に確認したい上流工程の関与度
社内SEへの転職を考える場合は、求人上の職種名だけで上流工程に関われるかを判断しないことが大切です。同じ社内SEでも、問い合わせ対応やインフラ運用が中心の職場もあれば、企画、要件定義、ベンダー管理まで担う職場もあります。
確認したい点としては、情報システム部門の人数、内製と外部委託の割合、担当するシステムの種類、利用部門との打ち合わせ頻度、企画から導入までの関与範囲があります。また、入社直後に任される仕事と、経験を積んだ後に担当できる範囲も確認すると、希望するキャリアとの違いを見極めやすくなります。
企業が上流工程を任せるための育成体制
企業が社内SEに上流工程を任せるには、個人の経験だけに頼らない育成体制が必要です。過去の企画書、要件定義書、会議記録、導入計画などを共有し、業務の進め方を学べる状態にします。
また、経験の浅い担当者には、小規模な案件で要望整理や会議運営を任せ、上司や経験者が確認する機会を設けることが有効です。日常の運用業務に偏りすぎないように役割を調整し、企画や改善活動に取り組む時間を確保することで、上流工程を担える人材を育てやすくなります。
