３ステップで説明！社内SEのプロジェクト管理【要件定義が超重要】

社内SEは「メインの仕事は上流工程」「プロジェクト管理が重要」と聞いたことがあります。実際にプロジェクトの各フェーズにおいてどのような仕事をしているのでしょうか、教えてください。

質問者

上記の疑問に回答します。

社内SEの詳しい仕事内容って、ネット等で探しても、それほど多くの情報を入手できないですよね。

同じプロジェクトに参加していても、「SIerやベンダのSE」とは立ち位置や責任範囲が異なるので、私もSIerからの転職当初は苦労しました。

この記事を読むことで、社内SEの業務内容について理解を深め、職業研究や転職に役立てていただけると幸いです。

プロジェクト開始前

実際にプロジェクトが開始になるには意外と多くのプロセスがありますので、説明していきます。

プロジェクトの発生

そもそも、プロジェクトはいったいどこから発生してくるのでしょうか。代表的なパターンを3つ紹介します。

トップダウン

社長や役員の一声で、業務部門や、情報システム部門を含めた全社横断的なプロジェクト体制が立ち上がることがあります。

DXを全社浸透させるためには、トップダウンでのアプローチが不可欠です。

このような指示があること自体は会社にとってポジティブな事だと思います。

また、情シス（社内SE）にとっても、社内での存在価値を高めるチャンスではないでしょうか。

各部署の利用者からの要望

社内SEの「お客様」である各部署の利用者から以下のような要望があります。

このような依頼があった場合、まずは詳しい話を聞くところから始まります。

システムで利用しているハードウェア、ソフトウェアの保守切れ

システムを構成している

といった製品にはサポート期限が決まっています。

その期限を過ぎると以下のリスクが発生します。

そのため、新しい製品に入れ替える、クラウドへ移行するなどの対応を行う必要があります。

プロジェクト着手準備

RFI作成・提示

新規の案件で委託先が決まっていない場合、

各ベンダが提供する製品・サービス等の情報収集を目的としてRFI（情報提供依頼書）を作成します。

複数の会社にRFIを出したうえで、その回答をみて、RFP（提案依頼書）の提示先を絞り込みます。

RFP作成・提示

利用部門と協業して、ベンダに提示するRFP（提案依頼書）を作成します。

大規模なプロジェクトになるとRFPの作成だけで数ヶ月所要する場合もあります。

ベンダ選定

ベンダから受領した提案書を精査、比較検討を行い、製品や委託先のベンダを決定します。

社内決裁

このプロジェクトにリソース（お金と社内の人的コスト）を投入して良いか、

会社として承認を取る作業になります。

コスト、システム導入の費用対効果等説明が必要になります。

金額にもよりますが、経営会議等、最上位の会議体で審議されることも多いです。

プロジェクト開始後

社内決裁が完了すると、ようやくプロジェクトを開始することができます。

プロジェクト計画

今後、プロジェクトを推進する指針となる

等を整理します。

最終的には「プロジェクト計画書」に落とし込み、プロジェクトメンバー全員に共有します。

ここは外部ベンダに任せず情シス（社内SE)の責任の元、行うことが重要です。

要件定義フェーズ推進

社内関係部署やベンダと連携して

を決定します。

プロジェクトの成否を決めるフェーズの一つであり、前半の山場です。

いわゆる「失敗プロジェクト」は要件定義フェーズでの検討が不十分であることに起因することが多いです。

上記のような事が発生した場合は、情シス（社内SE）の責任は免れないでしょう。

設計／製造フェーズ推進

このフェーズは作業主体が外部ベンダになりますが、社内SEは成果物のレビューと承認を行う必要があります。

テストフェーズ推進

ベンダでのテスト終了後、まずは社内SEが受け入れテストを実施し、

その後業務部門にUAT（ユーザテスト）を依頼します。

社内SEはUATの品質管理やサポートを行います。

このフェーズで手を抜くと、リリース後に不具合が頻発して使えない、といった事になりかねないので、

運用上の様々なケースを想定したテストを実施する必要があります。

移行フェーズ推進

いよいよ、移行（システムリリース）となります。

利用者が混乱を招かないように、事前に以下のような準備が必要になります。

プロジェクト終了後

SierのSEの場合、一つプロジェクトがリリースすると、すぐに次のプロジェクトにアサインされる事も多いです。

しかし、社内SEの場合はリリース後からが本番です。

ユーザが利用を開始して、本来の目的を達成できたかどうかによって、プロジェクトが「成功」か「失敗」かが真に決まるからです。

SIerの立場から見ると、納期も予算も達成できたということで「成功プロジェクト」の扱いを受けていても、

実際は、ほとんど使われることなく、クライアント企業側では、「失敗プロジェクト」になることも多いです。

問い合わせ対応

利用者からの問い合わせ対応を行います。

電話の受付自体は、ITのヘルプデスクが対応してくれると思いますが、

不具合の調査や難しい質問に関しては、開発を担当した社内SEが調査、対応する必要があります。

障害対応

「システムが利用できない」「動きが遅い」「動作がおかしい」

といった場合、以下のような順序で、周りをコントロールして対応にあたるのも社内SEの役割です。

step
1影響範囲の確認

step
2利用者へ障害のアナウンス

step
3原因調査、特定

step
4復旧計画の策定

step
5復旧対応の実施

step
6利用者への障害連絡

特に、重要システムの場合は一刻を争う事態になります。

上記の対応を速やかに実施することがとても重要です。

改修対応

リリース後にバグが見つかった場合や、機能追加等の要望があった場合は、内容、緊急度合い等を確認しシステムの改修を行います。

まとめ

いかがでしたでしょうか。本日は以下について紹介しました。

以上、参考になれば、幸いです。