SIerにおけるSEの仕事内容＜各フェーズ毎＞【保存版】

SIerは様々な企業のお客様に対しシステムの導入や運用のサービスを提供することが主な業務で、現場ではSEが主役となり活躍しています。大企業ほど、大抵は何らかのSIerにITシステムを任せているのではないでしょうか。

しかし、実際には外から見てもSIerのSEが具体的にどのような仕事をしているか、意外と分からないものです。そこで本記事では、SIerにおけるSEの仕事内容や仕事内において注意すべき点などを各フェーズ毎に細かくご紹介します。

【目次】

1. SIerにおけるSEの仕事の流れ
2. 要件定義〜設計フェーズの仕事内容
3. 構築〜テストフェーズの仕事内容
4. 移行フェーズの仕事内容
5. 運用フェーズの仕事内容

SIerにおけるSEの仕事の流れ

①プロジェクトへの配属

SEは、大抵は何らかのプロジェクトに配属されてから仕事をします。SIerの規模が大きいと、業務効率化の観点から予め人事上のユニットが複数プロジェクトのタスクを担当する役割になっていることがありますが、あくまでお客様から見れば、一つのプロジェクトの中の一人の要員として所定の役割を担当するということが基本的な考え方です。

配属先を探す際はSIerの社内ルールに沿って様々な条件でマッチングが行われますが、正式な配属の段階になると、プロジェクト責任者やプロジェクト・マネージャーとともに、体制図やWBSで仕事内容を明文化する作業を行います。

ここで大切なのは、自ら役割と責任を明確にすることです。自身の仕事内容を決めるのが一番の目的ですが、後にSEとしての経験を記述する場面でも必要となります。この部分が曖昧なままプロジェクトが始まらないよう充分にすり合わせをすることが最初の仕事となります。

②要件定義〜運用をリードする

役割やタスクを体制図やWBS等に落とし込んだ後は、いよいよプロジェクトが始まりますが、SEはプロジェクト・マネージャーを中心に全フェーズに渡りプロジェクトの遂行そのものを担当します。

近年はアジャイルな進め方も浸透しつつありますが、依然として多くのお客様ではウォーターフォール・モデルが主流なため、通常は要件定義、設計、構築、テスト、移行および運用の順番でフェーズを区切り、前から順にタスクを進めていきます。

構築フェーズが始まるまでは上流工程と呼ばれ、打ち合わせや文書作成の仕事が中心となります。それに対し構築フェーズ以降は下流工程と呼ばれ、上流工程のアウトプットを元にしたシステム構築作業が中心となります。

なお、SEはしばしば上流あるいは下流どちらの経験を有するか問われるケースがありますが、SIerが実際のプロジェクトの現場で上流や下流といった用語を使うことはほぼ無く、よほど大規模なプロジェクトでない限りは一人のSEが上流工程から下流工程まで一貫して担当することが多いです。
そのため、プロジェクトを担当するにあたってはどのフェーズで何をすべきか最低限の知識は必要ですし、SIerで何らかのプロジェクトを担当すれば、大抵一通りの知識を身につけることができます。

要件定義〜設計フェーズの仕事内容

要件定義フェーズや設計フェーズでは、要件定義書、設計書、テスト仕様書といったシステムの元となる文書が主な成果物です。そのため、これらの文書を順に仕上げていくことがここでの主な仕事ですが、ITシステムの要件や設計はSIerが独断で決めるものではなく、お客様との対話を重ねて作り上げていくものです。

また、システム構築後のテストはSIerが主体で実施する場合が殆どですが、中にはユーザー部門のお客様に協力いただくテスト項目もあるため、やはり対話が肝になります。

そのため、通常このフェーズでは定例会議の形式で検討の場を主催し、何度もお客様と協議を重ねていきます。
会議自体はプロジェクト・マネージャーがファシリテーターとなる場合が多いですが、各トピックの会議資料作成や会議の場での発言は各SEで分担して行われます。

構築フェーズの準備

設計フェーズに差し掛かると、構築フェーズの事前準備も必要になります。

ひとたび要件や設計が決まれば、構築の前にシステムを実現するためのハードウェアやソフトウェアなどの資源の調達を始めることになります。それらをお客様が調達するケースもあればSIerが資源提供するケースもありますが、納品のリードタイムを考慮して、構築が始まる前に然るべき場所に納品できるようサポートすることはSEの仕事です。

ありがちなのが、プロジェクトの契約時点で必要な資源の洗い出しは概ね完了していても、要件定義や設計を進めるうちに差異が発覚する、ということです。そのような場合でも、後続のスケジュールを確保しながら設計と調達物との整合性を保ち、忘れずに文書に反映することが求められます。

構築〜テストフェーズの仕事内容

システムを実際に作る

今まで机上中心だった仕事は、構築フェーズになるとシステム作業のような手を動かす仕事中心となります。最近はクラウド上にシステムを構築するケースも増えてきていますが、基幹システムのようにミッション・クリティカルなシステムはまだオンプレミスを選択することも多いため、インフラ構築を含むプロジェクトであれば、お客様サイトあるいはSIerが保有するデータセンターへ赴いて作業することもあります。

更にそういった重要なシステムは災害対策の一環で日本の東西に分散設置することもあるため、作業分担によっては物理的な移動が多くなります。その後は、高レベルのセキュリティーが求められるお客様では引き続きオンサイト作業が続くこともありますが、お客様が許可する場合は初期構築と同時に遠隔から作業できる環境を整えることもあるため、リモートで構築作業を継続します。

構築が終わればテストを行う

設計に沿って構築が終われば次はテストフェーズですが、単体テストのように範囲が限られるテストは構築作業の一貫として実施してしまっていることが殆どです。

実際のテストフェーズでは、各自が担当範囲の作業結果を持ち寄って進捗を確認し、テストの前提となるコンポーネントの準備が揃ったところで次の結合テスト等を進めていきます。テストフェーズでは、システムの動作確認にとどまらず、ユーザーによる受入確認や運用担当者への運用引き継ぎも行いますし、随時テスト結果をお客様に報告する必要もあります。

そのため、黙々と作業だけをしている訳ではなく、要件定義や設計フェーズほどの頻度ではないものの、やはりお客様との定期的なコミュニケーションは続きます。

どんなプロジェクトも最初から最後までスムーズ進むことは稀で、特にテストフェーズではシステムに大きな問題が発生する場合や、既に決定した内容でも諸事情でお客様から急遽仕様変更を要求されることもあります。

それでも一つずつ冷静に状況を整理し対処することや、要求に振り回されずに常にベストな解を提案することがSEに求められます。言い換えれば、そういう時こそSEの腕の見せ所となります。

移行の準備

このフェーズでは次の移行や運用フェーズに向けた準備も進める必要があり、移行計画書、移行手順書、運用手順書、操作手順書といった成果物の作成も行います。

移行計画書や移行手順書は移行フェーズの中で作成することもありますが、各種手順書はテストの中で使用するため、テストに合わせて作成するのが通例です。

構築やテストの作業はどうしても長時間拘束されがちですが、その合間を縫ってこれらの文書を完成させていく必要があるため、SEのワークロードとしては高くなります。特に大きな問題が発生するとその対応に手を取られ、ユーザー受入テストや運用引き継ぎに割く時間を削減せざるを得ないこともありますが、実はここでユーザーや運用者をおろそかにしない対応ができるかどうかがプロジェクト成功の鍵を握っています。

プロジェクトとしてはスコープ内のタスクを完遂し移行作業を無事に終えることができれば成功と見なされますが、お客様から見ればシステムは運用を開始して初めてその価値を発揮するということを忘れてはなりません。

移行フェーズの仕事内容

最後の仕上げ

テストが一段落ついたのも束の間、システム導入プロジェクトにとって、最も緊張が高まるのがこの移行フェーズです。新規システムであればサービス開始日からお客様が混乱なくシステムを利用できていなければなりませんし、システム更改であれば既存業務に影響を与えてはなりません。移行作業にミスがあればお客様に多大なご迷惑をおかけすることになるため、移行フェーズでは移行作業に向けて万全の対策を検討します。

具体的には、移行に関する全作業を明確にするために、移行計画書、移行タイムチャート、移行手順書、フォールバック・プランといった文書に全て計画を落とし込むところから始まります。また、移行作業のリスクが高ければ移行リハーサルを実施することもあり、お客様に協力いただきながら実際の流れに即した作業を行うことで、タイムチャートや移行手順書を精査し、本番移行リスクを極力減らします。

ここでようやく最後の仕事である本番移行作業を残すところとなりますが、その前に、比較的大規模なプロジェクトでは稼働判定やサービスイン判定と呼ばれる最終チェックを行う場を設けることが多く、例えば全要件が正しく実装されているか、移行後の体制は万全か、といったことを判定基準書に纏めてお客様にご報告し、最終的な承認を得ます。

成功裏にサービスインするまでが仕事

本番移行作業は数時間で終わることもあれば、年末年始やゴールデン・ウィーク等の休日を利用して何日にも渡ることがあります。移行作業に失敗するとこれまでの苦労が水の泡となるため、SE個人の判断で行動することはせず、まず全員が移行手順書に沿って確実に作業を進めることが最も重要な仕事になります。

移行作業が終わり、無事にシステムがサービスインとなれば運用開始となりますが、通常、一定期間は導入プロジェクトとしてのアフターフォローは続きます。サービスイン当初は何らかの問題が発生することが多いため、きちんと運用に乗るまでは責任を持った対応が必要です。

プロジェクトが終わる毎に振り返りを行う

プロジェクトがクローズとなればSEの仕事はひと段落ですが、今後のために、このタイミングで一度振り返りを行うことが推奨されています。

具体的には、自身にどんなタスクがアサインされたのか、あるいはどんな課題に直面したのか、それらをどう考えどう対処したのかを記録する行為です。

後になって自身の昇進のために必要となる場合もあれば、経験事例としてフィードバックを求められることもあるため、記憶が薄れないうちに書き留めておきます。

運用フェーズの仕事内容

SIerは運用アウトソーシングとして担う

ITシステムが無事にサービスインを迎えても、家電のようにそのまま使い続けられる訳ではありません。例えば何らかの障害が発生した場合は、何も対処しなければいつかシステムは使用できなくなってしまいます。そこで運用フェーズでは、予め定めたサービスレベルに則り、システムがサービスを提供できる状態に保つ作業を継続して行います。

SIerのシステム導入プロジェクトは通常は移行までがスコープですが、同じSIerが引き続き運用を担う場合があります。ただし、その場合は構築と運用は別のプロジェクトが担当することが多く、ここから先は運用アウトソーシング・プロジェクトの範疇となります。

企業のシステムはハードウェアの保守が切れるまで運用し続けることが多いため、システム単位で見たときの運用フェーズは5年やそれ以上といった長期間に及ぶことがあります。運用アウトソーシングでは複数のシステムを纏めて運用するケースが殆どですので、あくまでこの期間は一つのシステム毎の目安ですが、いずれにせよ数年といった長期の契約となるプロジェクトが殆どですので、運用アウトソーシング・プロジェクトのSEは一つのお客様のシステム運用を何年も続けることが多いです。

ITILベースのプロセスに則った仕事が主体

SIerがシステムの運用を行うにあたっては、大抵は自社が定めるITILベースの運用プロセスに則ります。例えば、インシデント管理、問題管理、変更管理のようなプロセスです。各プロセスの詳細は割愛しますが、例えば障害が起こればインシデントとして記録し、再発防止が必要であれば問題として管理し、変更作業が必要であれば変更リクエストを上げてレビュー手続きを進める、という事をします。

システム導入プロジェクトのSEは所定の成果物を期限内に納品することに注力するのに対し、運用アウトソーシング・プロジェクトのSEはプロセスやルールに則り日々行動するイメージです。

運用の仕事は幅広い

しかし、プロセスに則って行動するだけが仕事でもなく、プロジェクトのスコープによっては、お客様のIT部門が行うようなタスクのほぼ全てを担うこともあります。そのため、運用フェーズではお客様との長期のリレーションが築かれます。特定のお客様や業界に興味があれば、運用からスタートするのも良いかもしれません。

=================

＜SEのキャリアパスに関する記事＞

【保存版】エンジニア(SE)からコンサルタントに転職・活躍するまでのAtoZ
https://www.axc.ne.jp/column/axis-column/2018/0227/se_cous.html

「2次受けSIer」からコンサルファームへ年収アップでの転職成功事例
https://www.axc.ne.jp/column-career-change-case/2015/0914/571.html

=================

今回の記事では、SIerにおけるSEの仕事内容についてご紹介しました。

キャリアでお悩みの方は、ぜひアクシスコンサルティングにご相談ください。