経済産業省によるとIT人材は2030年には45万人不足すると予測されています。（参考：経済産業省 IT人材需給に関する調査）
システムエンジニアも人材不足で、多くの企業が採用ページで募集をおこなっています。さくらインターネットでも募集中です。
そんなシステムエンジニアとは、どのような仕事をして、どのようなスキルが必要なのか。現役のシステムエンジニアの方に記事を書いてもらいました。
システムエンジニア（SE）とは
ビジネスにおいては、新規事業を立ち上げたい、現在の業務を効率化したいなどさまざまな要件（要求）が生まれます。システムエンジニアとは、広くは「ビジネス上の要件とITとの橋渡しをして要件を実現する人または職種」のことをいいます。「ビジネスとITとの翻訳者」ということもあります。
一般的に、プログラムを作るプログラマーに対して、システムエンジニアは仕様書（設計書）を作る役割として位置づけられることが多いです。SE(エス・イー)、システムズエンジニアなどとも呼ばれます。
システムエンジニアという用語を耳にしたことはあっても、その仕事内容やキャリアについては、あまり知られていないかもしれません。
その理由として、システムエンジニアの役割が多岐に渡り、企業や個人によっても捉え方がしばしば異なることが挙げられます。
たとえば、これまでシステムエンジニアと呼ばれてきた役割について、現在は次の表のように細分化されています。
ITスキル標準では、IT技術者を「SE」、「プログラマ」といった名称で包括的にくくるのではなく、ビジネスの実状に沿うように職種や専門分野を分類定義し、それぞれレベルに対して個人のスキルを評価する尺度を多面的に提供しています。
システムエンジニアとは、広くは上の表のすべての職種を指します。
特に「ITアーキテクト」「ITスペシャリスト」「アプリケーションスペシャリスト」「ITサービスマネジメント」は、一般的にシステムエンジニアの守備範囲と考えられています。
このように、システムエンジニアが求められる場面は非常に幅広く多様なのです。
システムエンジニアの仕事内容
では、システム開発における一般的なフェーズごとに、システムエンジニアの仕事を見ていきましょう。
図のとおり要件定義からはじまり、設計、開発、テスト、運用の流れとなります。
要件定義「やりたいことをハッキリさせる」
要件定義フェーズの目的は、「何をシステム化したいか」を明確にすることです。
システムエンジニアは、このフェーズで中心的な役割を担います。具体的には、ステークホルダー（関係者）から要件を引き出して、分析・整理した結果を要件定義書としてまとめます。
要件を引き出すには、ヒアリングや調査をおこないます。
ステークホルダーを集めてブレインストーミングをしながら、要件を抽出することがあります。この場合は、システムエンジニアがファシリテーターとなってセッションを進行し、参加者全員が見えるホワイトボードに要件を書き出していく方法がよく採用されます。
要件定義では、最初から明確に説明される要件だけでなく、潜在的な要件も引き出していきます。類似の事例を参照したり、経営課題から業務上の課題へとブレークダウンしたりすることで、言語化されていない要件への気づきを促します。
また、ビジネス上の機能要件に加えて、非機能要件も洗い出します。非機能要件とは、システムが満たすべき性能や品質に対する要件です。セキュリティ、稼働日や時間、処理量や応答時間などに対する要件が相当します。
非機能要件はアプリケーションや業種に関わらず一般化できるため、システムエンジニアは経験値から今回検討すべき項目をピックアップします。
抽出した要件は、一覧にして優先度を付与します。優先度を踏まえて、今回のシステム開発で実現する対象範囲を決定します。
システムエンジニアが中心となってまとめる要件定義書は、この後のシステム開発や運用において、立ち戻って確認すべき「原点」となります。
設計「要件から設計書を作る」
設計フェーズにおいても、システムエンジニアが主体的に活躍します。
システムエンジニアは利用者目線で書かれた要件定義書の内容を、システムを構成するプログラムへと落とし込めるように設計します。
一般的に設計フェーズでは、基本設計から詳細設計へと設計の詳細度を深めていきます。外部設計・内部設計などと呼ぶこともあります。
設計する対象としては、次のようなさまざまなシステムの構成要素です。
- アーキテクチャー（全体構造）
- アプリケーション（スマホやPCで動くアプリ、サーバーで動くアプリケーション・プログラム、機械の中に組み込まれるプログラムなど）
- システムインフラ（サーバーやPCなどのハードウェアとOSやソフトウェアなどとを合わせたアプリケーションを支える土台部分）
- データ
- ネットワーク
- 運用
システムの規模や複雑さによって、全体をひとりのシステムエンジニアが設計することもあれば、各分野の専門のシステムエンジニアが分担して設計することもあります。
どのように設計するかは、システムエンジニアの腕の見せどころと言えるでしょう。システム開発をおこなうITベンダーは標準的な設計手法を定めており、企業にとっての知的財産としています。
また、対象領域やのちに開発で利用するプログラミング言語によって、設計手法を変えることもあります。
設計フェーズでシステムエンジニアが作るのは、仕様書（設計書）です。要件をもれなく仕様書に落とし込み、正しく動作するシステムを後続のフェーズで開発するための重要な成果物となります。テスト仕様書の元にもなります。
開発「設計書をコンピュータ語に翻訳する」
一般的に、開発フェーズにおけるプログラミングはプログラマーが担当します。プログラマーは、プログラムの作成とプログラム単位のテスト（単体テスト）完了までの責任を持ちます。
企業やプロジェクトによっては、システムエンジニアが開発部分もカバーすることがあります。就職や転職の際には、企業がいう「システムエンジニア」のジョブディスクリプション（職務記述書）を確認することをおすすめします。
テスト「設計通りに動くかを確認する」
テストフェーズでは、複数のプログラムを組み合わせた統合テストや、業務の流れの中でプログラムを使ってみる運用テスト、高負荷をかけて応答時間や処理時間が要件範囲内に収まるかを確認する性能テストをおこないます。
システムエンジニアは設計フェーズで作成した仕様書をもとに、テストシナリオやテストケースを洗い出してテスト仕様書を作成します。開発が終わったプログラムは、テスト仕様書に基づいてテストされます。
運用「継続して価値を生み出す」
システムは作っただけでは何の価値も生みません。システムを動かすことによって新たなビジネス要件が実現されることで、ようやく価値を生み出します。
運用フェーズにおけるシステムエンジニアの仕事には、システムが安定稼働を継続して価値を生み出していけるよう、システムを保守していくことがあります。
ビジネスを取り巻く環境は常に変化しています。利用者が増えれば扱うデータ量も増えていきます。これまでになかった新しいセキュリティの脅威に見舞われるかもしれません。
システムの安定稼働は、同じことの繰り返しだけでは実現できません。システムの状態に異常がないかを監視しつつ、新しい要件を取り込んでいくことが必要です。
さらに、企業が目指す方向へとシステムも変わっていくことが求められます。
運用フェーズに入ってからも、システムエンジニアはどのような要件をシステムに取り込むか、分析や要件定義をおこないます。続いて設計・開発・運用をおこないます。
システム開発とは一度作って終わりの一直線ではなく、運用を含めたサイクルの繰り返しなのです。そのサイクルを回していく主役としてシステムエンジニアは位置付けられます。
実際に携わってきた仕事
より具体的なシステムエンジニアの仕事をイメージしていただくために、私が実際にシステムエンジニアとして経験した仕事の中から、いくつかをご紹介します。
アプリケーションを作る
私がシステムエンジニアとして携わってきたアプリケーションは、主に企業の業務を支えるものです。たとえば、要件定義から設計・開発・運用までのすべてのフェーズにたずさわった初期の仕事に、自動車の販売管理システムの刷新プロジェクトがあります。
- 販売会社で日々発生する大量の販売データをどのように収集するか
- データを、どこに、どれだけの期間保管するか
- データをどのような視点で分析するか
- 分析結果をいつまでにどのように見せるか
これらについて、営業部門も巻き込んだチームで要件定義をおこないました。設計・開発でのポイントは、データベース設計とツール選定にありました。
前日の大量の販売データからの分析結果を、翌朝営業や経営層が参照するのに間に合わせるため、適切なサイズと柔軟性を持った中間データベース（データマート）の設計が必要と判断しました。
開発期間を短縮するためにBIツールやパッケージソフトの採用も検討しましたが、当初は処理時間と柔軟性に課題がありました。必要な情報をタイムリーに提供すること、利用者が使いやすいことを重視した結果、データマートの作成にはSQLを駆使し、分析結果は社内で使い慣れたExcelで見せるなど身近なツールを活用することにしました。
洗練された仕組みではありませんが、タイムリーな情報提供と使いやすさが受け入れられて、長く使われ続けたシステムです。
システムインフラを作る
システムインフラとは、アプリケーションを動かすための、必要なサーバーやネットワーク、PC、スマホなどで構成される仕組みです。
システムインフラを設計するにあたって、ベースとなるのは非機能要件です。経営目標や業務上の課題から出てくる要件（機能要件）に対して、非機能要件とはシステムの品質に対する要件です。
非機能要件には、「同時にアクセスできるユーザー数を1000に」「応答時間は3秒以内」「障害が発生してもシステムの停止時間を数分以内に収める」「扱うデータは重要情報として外部から守る」などがあります。
金融や製薬など、業界基準としてシステムの信頼性に求める非機能要件もあります。たとえば「障害が発生してもシステムの停止時間を数分以内に収める」ために、サーバーやネットワークを二重化して、たとえ片方が停止しても、もう片方に即時に切り替わるホットスタンバイ構成としました。
最近はシステムインフラを自前で作らず、クラウドを利用するケースが増えています。その場合はクラウド提供ベンダーのサービスレベルを確認して、非機能要件に見合うプランを選択しています。
システムを運用する
システムを安定稼働させるためには、異常がないかを監視したり、万一障害が発生した際にも短時間で復旧できるようにバックアップを取得することによって備えます。昨今は、さまざまなセキュリティ上の脅威からシステムを守る対策を施す必要性が高まっています。
システム運用に関する取り組みのひとつに、コンティンジェンシープランの作成があります。コンティンジェンシープランとは、震災発生など緊急時の対応手順についてまとめたものです。
大規模システム障害が発生した直後の初期対応、その後の暫定対応と本格復旧のための手順を取りまとめました。ウォークスルーを繰り返して、現実的な手順となっているかの見直しをおこなっています。
この他にシステムエンジニアとしての経験を生かして、IT戦略やIT計画の立案に携わるなど、CIO (Chief Information Officer) を支援する役割を担うこともあります。
システムエンジニアを長く続けていく中で、さまざまな仕事に出会うことがあります。一方、特定の領域を深掘りしていくシステムエンジニアもいます。
自分の希望だけで仕事を選択することはできませんが、多様なシステムエンジニアのタイプのうちどのタイプとしてキャリアを進めていきたいか、キャリアプランを定期的に考えてみるとよいと思います。