はじめに
私は大手SIerで20年以上、システム基盤を中心に、OS、ネットワーク、データベースの設計・構築から、大規模プロジェクトの統括まで経験してきました。
このページでは、私自身のキャリアを踏まえながら、システム開発に関わる代表的な職種と、SIerのSEが実際にどこまで担当するのかを整理します。
システムエンジニアになりたいと考えている人の中には、SEの仕事を「設計書を書き、プログラムを作る仕事」と捉えている人もいると思います。
実際のシステム開発では、プログラムを作るだけではシステムは完成しません。顧客の業務を整理して必要な機能を決め、サーバーやネットワークを構築し、データを安全に管理し、障害が発生しても業務を継続できる仕組みまで設計する必要があります。
これらを一人のエンジニアがすべて担当するわけではありません。プロジェクトマネージャー、アプリケーションエンジニア、AP基盤エンジニア、システム基盤エンジニア、ネットワークエンジニア、データベースエンジニアなど、異なる専門性を持つ人たちが役割を分担します。
実際のSIerでは、職種ごとの境界が明確に分かれているとは限りません。一つの技術領域からキャリアを始め、周辺領域へ担当範囲を広げ、最終的に複数の技術チームやプロジェクト全体を統括するSEもいます。
企業やプロジェクトによって、職種名、チーム名、担当範囲の分け方は異なります。この記事では便宜上「職種」と表現しますが、同じシステムエンジニアという肩書でも、実際の仕事内容は大きく異なります。
本記事では、SIerのシステム開発に関わる主なSE職種を取り上げ、それぞれがどの工程・領域を担当し、どのように役割を分担するのかを整理します。
システム開発全体の流れについては、以下の記事で詳しく説明しています。
システム開発は複数の専門領域で成り立っている
システム開発では、利用者が操作する画面や帳票だけでなく、その裏側にあるサーバー、ネットワーク、データベース、認証、監視、バックアップなども設計します。
インターネット上で商品を購入できるショッピングサイトを例に考えてみましょう。
アプリケーションエンジニアは、商品検索、注文、決済、在庫確認といった業務機能を設計します。AP基盤エンジニアは、認証、ログ出力、例外処理、データベース接続など、複数の機能が共通して利用する仕組みを整備します。
システム基盤エンジニアは、アプリケーションを安定して動かすサーバーやクラウド環境を設計します。ネットワークエンジニアは、利用者や外部サービスと安全に通信できる構成を作ります。データベースエンジニアは、顧客情報や注文情報を正確かつ高速に読み書きできるようにします。
図 ショッピングサイト構築を支えるエンジニアの役割
アプリケーション側が大量のデータを短時間で処理する前提を置いているのに、基盤側が小規模なサーバーしか用意していなければ、性能問題が発生します。データベース側が同時接続数を制限しているのに、アプリケーション側が大量の接続を生成すれば、処理の遅延や障害につながります。
システム開発では、各担当者が自分の専門領域を設計するだけでなく、他の領域と前提条件を合わせる必要があります。職種を理解するうえでも、個別の仕事内容だけではなく、他の職種とどのように接続しているかを見ることが重要です。
プロジェクトマネージャー
プロジェクトマネージャーは、プロジェクト全体を成立させる責任を持つ役割です。
一般的には、品質、コスト、納期を管理する仕事として説明されます。現場で求められるのは、進捗表を更新したり、会議を開催したりすることだけではありません。
システム開発では、日々さまざまな問題が発生します。要件が決まらない、製品仕様が想定と異なる、他システムとの接続条件が合わない、テストで不具合が多発する、必要な技術者を確保できないといった問題です。
プロジェクトマネージャーは、発生した問題を把握し、誰が、何を、いつまでに判断するのかを明確にします。担当者間で解決できない問題については、顧客、社内責任者、製品ベンダーなどを巻き込み、必要な意思決定を引き出します。
大規模なプロジェクトでは、プロジェクトマネージャー一人ですべてを管理できません。アプリケーション、システム基盤、移行、運用などのチームごとにリーダーを置き、各チームが抱えている課題やリスクを集約します。大手SIerの大規模案件では、一例として、プロジェクト全体を統括するPMを課長級、各チームを率いるリーダーを課長代理級が担い、その下に主任などの担当者を配置する体制もよく見られます。
プロジェクトマネージャーに必要なのは、すべての技術を自分で実装する能力ではありません。各分野の担当者が説明する内容を理解し、プロジェクト全体への影響を判断したうえで、何を優先するかを決める力が求められます。
技術的には正しい案であっても、予算、納期、要員、契約条件を踏まえると採用できない場合があります。反対に、費用を抑えるために必要な冗長化やテストを削れば、稼働後の障害リスクが高まります。プロジェクトマネージャーは、個別の技術判断を品質、コスト、納期の制約の中で成立させる役割でもあります。
大きな障害が発生した際には、原因を調査して復旧するだけでは終わりません。顧客に対して影響範囲、原因、復旧状況、再発防止策を説明し、必要に応じて組織を代表して謝罪することも、プロジェクトを統括する立場の仕事です。
こうした判断と責任を支えるのが、現場で積み上げた技術経験です。例えば、PMには次のような事項を評価する力が求められます。
- 担当者が提示した工数の妥当性
- 提案されたシステム構成の実現可能性
- 障害が発生した場合の影響範囲
こうした判断をPMが自分の言葉で行うには、少なくとも一つの技術領域で設計や障害対応を経験していることが大きな支えになります。SIerでは、担当者やチームリーダーとして専門性を積み上げた後、複数領域を統括するPMへ役割を広げていくキャリアが一般的です。
実際の更改プロジェクトで、各担当者がどのように関わるのかについては、以下の記事でも説明しています。
アプリケーションエンジニア
アプリケーションエンジニアは、利用者の業務をシステムの機能として実現する役割を担います。
画面や帳票を作るだけではなく、顧客がどのような業務を行い、どのようなルールで処理しているのかを理解する必要があります。
銀行の融資審査システムであれば、申込受付、本人確認、信用情報照会、審査、承認、契約といった業務の流れを理解しなければ設計できません。会計システムであれば、勘定科目、仕訳、決算処理などの知識が必要になります。公共分野であれば、法律や制度の理解が設計に直結します。
主な仕事には、次のようなものがあります。
- 業務要件の整理
- 画面、帳票、バッチ、APIの設計
- データベースへ登録する情報の整理
- プログラム開発
- 単体テスト、結合テスト
- 障害原因の調査
- 利用部門や他システム担当者との仕様調整
プロジェクトによっては、設計を担当する人とプログラミングを担当する人が分かれています。規模の小さい開発では、一人が要件確認からプログラミング、テストまで担当することもあります。
アプリケーションエンジニアにとってプログラミングは重要な技術です。それだけで仕事が完結するわけではありません。顧客の業務を理解し、曖昧な要望をシステムで実現できる仕様へ落とし込む力が必要です。
設計した機能がどの程度のデータを処理し、どのようなタイミングでデータベースや外部システムへ接続するのかも、システム基盤やデータベースの担当者へ伝えなければなりません。
アプリケーションの仕様は、アプリケーションチーム内だけで完結するものではありません。サーバー構成、ネットワーク帯域、データベース接続数、運用時間など、他の領域の設計条件にもなります。
ここではアプリケーションエンジニアの担当領域を概要として紹介しました。仕様の決め方、設計から障害対応までの責任範囲、他チームとの役割分担など、具体的な仕事内容と実務上の判断については、次の記事で詳しく説明しています。
AP基盤エンジニア
AP基盤とは、複数のアプリケーションを共通の方式で開発し、安定して動かすためのアプリケーション基盤を指します。AP基盤エンジニアは、個別の業務機能ではなく、複数の開発チームが共通して利用する仕組みや開発方式を設計します。
主な担当領域は次のとおりです。
- 認証、認可、ログ、例外処理などの共通機能
- データベース接続やトランザクション管理の共通方式
- Javaや.NETなどのアプリケーション実行方式
- Springなどのフレームワークの設計と利用ルール
- 共通ライブラリや部品の開発
- プログラムのビルド、テスト、配備を自動化する仕組み
- コーディング規約や開発標準の整備
- アプリケーション性能の分析
- 開発チームへの技術支援
例えば、100の画面を複数の開発チームで分担して作るシステムで、ログイン状態の確認や操作権限の判定を各開発者が個別に実装すれば、画面ごとに動作や品質が異なり、セキュリティ上の不備も生じやすくなります。
こうした処理をフレームワークや共通ライブラリとして整備すれば、各開発チームは同じ方式で実装できます。業務機能を担当する開発者は、認証やログ出力を一から作る必要がなくなり、業務ロジックの開発へ集中できます。
この役割は、アプリケーションとシステム基盤の接点でもあります。プロセス構成、データベース接続数、タイムアウト、メモリ利用、ログ出力、配備方法などを決めるには、プログラミングだけでなく、ミドルウェア、データベース、ネットワーク、性能、セキュリティまで理解する必要があります。
共通基盤の設計に問題があれば、その影響は多数のアプリケーションへ広がります。利用者からは見えにくい役割ですが、開発生産性、品質、性能、セキュリティを横断して支える重要な専門領域です。
経験を積むと、共通部品の設計にとどまらず、システム全体の技術方針や構成を決めるアプリケーションアーキテクトやITアーキテクトへ役割を広げることもできます。技術的な裁量と責任範囲が広い職種として、市場での評価も高い領域です。
システム基盤エンジニア
システム基盤エンジニアは、アプリケーション、データベース、ネットワーク、運用を支える共通基盤を設計し、システム全体が動く土台を成立させるエンジニアです。インフラエンジニアと呼ばれることも多い職種です。
従来は、物理サーバー、OS、ストレージ、バックアップ装置など、オンプレミス環境を中心に設計・構築していました。現在はAWS、Microsoft Azure、Google Cloudなどのクラウドを利用する案件が増え、物理機器だけでなく、クラウドサービスを組み合わせて基盤全体を設計する役割へ広がっています。
主な検討領域は次のとおりです。
- サーバーやクラウドの構成とサイジング
- 環境設計とOS・ミドルウェアの標準化
- 監視、ログ、ジョブなどの運用設計
- 冗長化、バックアップ、障害復旧
- 見積もり・調達とクラウド利用料の管理
クラウドを利用すれば、サーバー機器を自社で購入し、設置する作業は減ります。一方、可用性、セキュリティ、性能、バックアップ、運用、コストの設計までクラウド事業者へ任せられるわけではありません。
どのサービスを組み合わせるのか、どこまで冗長化するのか、障害時にどの範囲まで自動復旧させるのか、データをどこへ保存するのかといった判断は、利用する企業と開発プロジェクト側に残ります。
システム基盤は、平常時にシステムが動くだけでは成立しません。サーバーやネットワークの一部が故障しても業務を継続できる構成、障害発生時に原因を追える監視とログ、誤操作や災害が発生しても復旧できるバックアップまで設計します。
基盤構成を基盤担当だけで決めることもできません。アプリケーションが必要とする処理量、データベースへの接続数、稼働時間、停止可能時間、運用方法などを踏まえて、必要な性能や可用性を決めます。
調達と費用管理にも、システム基盤エンジニアは大きく関わります。オンプレミスでは、サーバーやストレージ、ソフトウェアの構成と数量を決め、見積もりやライセンス、保守契約を確認します。クラウドでは、仮想サーバー、データベース、ストレージ、通信量などを基に利用料を試算し、稼働後も性能余力とコストを見ながら増強や縮小の時期を判断します。
システム基盤エンジニアは、こうした基盤構成と費用の算定根拠を作り、PMによるプロジェクト予算の策定と管理も支えます。
サイジング、環境設計、標準化、監視、可用性、バックアップ、障害復旧、クラウド利用料の管理など、システム基盤・クラウドエンジニアの具体的な仕事内容と実務上の判断については、次の記事で詳しく説明しています。
ネットワークエンジニア
ネットワークエンジニアは、利用者、サーバー、クラウド、外部システムの間で、安全かつ安定して通信できる仕組みを設計します。
企業のシステムでは、単にインターネットへ接続できればよいわけではありません。
社内端末から業務システムへ接続する通信、データセンターとクラウドを結ぶ通信、外部企業とのシステム連携、運用担当者が管理画面へ接続する通信など、それぞれに異なる条件があります。
主な担当領域には、次のようなものがあります。
- LAN、WAN
- ルーティング
- DNS
- ファイアウォール
- ロードバランサ
- プロキシ
- VPN
- 閉域網
- クラウド接続
- 通信経路の冗長化
- ネットワーク監視
ネットワークの問題は、原因の切り分けが難しいことがあります。
画面が表示されないという事象だけでは、アプリケーションに不具合があるのか、サーバーが停止しているのか、DNSで名前解決できないのか、ファイアウォールで通信が遮断されているのか分かりません。
ネットワークエンジニアには、通信経路やパケットの状態を確認し、どこで通信が途切れているのかを特定する力が求められます。
クラウド環境でもネットワークの重要性は変わりません。画面上の操作でネットワークを構築できるようになった反面、ルーティングや名前解決の設計を誤れば、複数のシステムへ影響が広がります。
アプリケーションが接続する相手、通信量、利用するポート、暗号化方式、接続元の制限などを他の担当者と確認し、システム全体の通信条件を整合させる必要があります。
ここではネットワークエンジニアの担当領域を概要として紹介しました。通信経路の設計、VLANやルーティング、ファイアウォールによる通信制御、冗長化、外部ネットワーク接続、障害時の切り分けなど、具体的な仕事内容と実務上の判断については、次の記事で詳しく説明しています。
データベースエンジニア
データベースエンジニアは、システムが扱うデータを正確、安全かつ効率的に管理する役割を担います。
多くの業務システムでは、顧客、契約、商品、取引、会計などの情報をデータベースへ保存します。
データベースに障害が発生すると、画面が表示できないだけではなく、取引そのものを継続できなくなる場合があります。データが破損したり失われたりすれば、企業活動へ重大な影響を及ぼします。
主な仕事は次のとおりです。
構築と物理設計
データベース製品と構成の選定
テーブル、インデックス、表領域などの設計
初期設定と各種パラメータの設計
性能と容量管理
SQLと実行計画の分析
インデックスや統計情報の管理
性能チューニング
データ容量と増加量の見積もり
セキュリティと運用
ユーザー、権限、ロールの設計
監査要件への対応
監視とログ管理
可用性とデータ保護
冗長化と障害時の切り替え
バックアップとリカバリ
移行と製品管理
データ移行
バージョンアップ
ライセンスと保守契約の管理
Oracle Database、PostgreSQL、Microsoft SQL Serverなど、製品ごとに構造や機能が異なるため、特定のデータベース製品に深い知識を持つエンジニアも多くいます。
データベースエンジニアの仕事は、データベースをインストールして終わりではありません。
どのSQLに時間がかかっているのか、索引が適切に利用されているか、統計情報が実行計画へどのように影響しているか、障害時にどの時点までデータを復旧できるかといった点を継続的に確認します。
アプリケーションの性能問題に見えても、実際にはSQLやデータベース設計に原因がある場合があります。データベース側だけで改善できるとは限らず、アプリケーションの処理方式そのものを見直すこともあります。
アプリケーションエンジニアやAP基盤エンジニアと、SQL、接続方式、トランザクション、処理量などの前提を共有することが欠かせません。
ここではデータベースエンジニアの担当領域を概要として紹介しました。構成設計、性能チューニング、権限・監査、可用性、バックアップと復旧など、具体的な仕事内容と実務上の判断については、次の記事で詳しく説明しています。
運用、セキュリティ、アーキテクトという役割
実際のプロジェクトには、ここまで説明した職種以外にもさまざまな役割があります。
運用エンジニアは、稼働後の監視、障害対応、定期作業、問い合わせ対応などを担当します。運用担当者が稼働後に考えればよい仕事ではありません。監視方法、バックアップ、障害時の連絡、復旧手順、定期作業などは、システム開発の段階から設計する必要があります。
セキュリティエンジニアは、認証、権限、脆弱性、ログ監視、インシデント対応などを専門的に検討します。セキュリティも一つの製品を導入して完了するものではなく、アプリケーション、システム基盤、ネットワーク、運用の各領域にまたがります。
システムアーキテクトは、個別製品の設定だけでなく、システム全体の構造や技術方針を設計します。複数のチームにまたがる技術的な整合性を取り、局所的には正しい設計が、システム全体の問題にならないようにします。
これらが独立した職種として置かれるか、他の担当者が兼務するかは、組織やプロジェクトの規模によって異なります。
小規模なシステムでは、一人がアプリケーション、データベース、クラウド、運用まで担当する場合があります。大規模なシステムでは、同じデータベース領域でも、性能、移行、運用などに担当が分かれることがあります。
職種名だけで仕事内容を判断するのではなく、実際にどの範囲まで担当するのかを確認することが重要です。
ここまでは、システム開発に関わる役割を職種ごとに分けて説明しました。実際のSIerのキャリアでは、これらの役割が一人の中で連続することがあります。ここからは、私自身の経験を例に、技術者がどのように担当範囲を広げていくのかを説明します。
SIerのSEは一つの職種に収まらない
私自身も、最初からプロジェクト全体を管理していたわけではありません。キャリアの出発点は、SolarisやLinuxを扱うインフラエンジニアでした。
OSを設計、構築するだけでなく、Ciscoの資格を取得し、比較的小規模なネットワーク設計も担当しました。当時は現在のクラウド環境とは異なり、物理的なサーバー機器を顧客のデータセンターへ納品し、ラックへ搭載するところまでSIer側で行う案件も数多くありました。
現在のクラウドでは、物理サーバーや電源設備はサービスの裏側に隠れ、利用者が直接意識する機会は減りました。当時のインフラエンジニアは、OSやミドルウェアだけでなく、機器を実際に稼働させるための物理設備まで、設計と構築の対象として扱っていました。
私も、サーバーの台数や消費電力からラックの電源容量を計算し、停電時にはUPSとUPS管理ソフト（PowerChute）を連携させて、OSやミドルウェアを安全に停止する方式を設計しました。
ハードウェアを納品する際には、設計書上の構成を考えるだけでは終わりません。サーバーをラックへ実際に搭載し、電源やネットワークケーブルを接続して、機器が起動するところまで確認します。
LANケーブルを配線するため、吸盤式のフロアリフターを使ってフリーアクセスフロアの床板を開け、床下へ潜ってケーブルを引き回したこともあります。現場では、この吸盤式の道具を「サッカー」と呼んでいました。作業を終えて床下から出ると、スーツが埃まみれになっていたものです。
現在では、こうした作業はデータセンター、施工、ファシリティなどの専門担当へ分業されることが多く、クラウド環境からキャリアを始めたエンジニアには馴染みのない光景かもしれません。
こうした経験を通じて、システムは画面上の設定やソフトウェアだけで動いているのではなく、電源、空調、ラック、ケーブル、機器といった物理的な土台の上で成立していることを理解しました。
その後、Oracle Databaseを大規模に利用するシステムを担当するようになり、データベースの設計、構築、性能チューニングまで行うようになりました。当時のOracle9i Platinum資格も取得し、DBAとして経験を積みました。
ここまでで約10年間です。
OS、ハードウェア、ネットワーク、電源設備、データベースを、それぞれ独立した製品知識として覚えたわけではありません。システムに障害が発生した際、どの層に原因があるのかを切り分け、各領域の設計がどのように影響し合うのかを、実際の構築や障害対応を通じて理解していきました。
例えば、処理が遅いという事象が発生しても、原因がサーバーのCPU不足とは限りません。ストレージのI/O、ネットワーク遅延、Oracleの実行計画、SQL、アプリケーションの処理方式など、複数の可能性があります。
一つの製品だけを見ていては、原因を特定できない障害もあります。異なる技術領域を経験することで、システム全体を一つの構造として見られるようになりました。
その後も肩書としてはシステム基盤を担当するエンジニアでしたが、仕事の中心は個別製品の設計や構築から、システム基盤全体の統括へ変わっていきました。
各技術チームの作業範囲を整理し、必要な要員と工数を見積もり、RFPや提案書を作成します。案件を受注してよいかを判断する社内会議では、技術的な実現性だけでなく、採算、要員確保、リスク、契約条件についても説明します。
入札案件では、幹部に対して案件の概要、顧客の要求、提案内容、受注方針、想定されるリスクを説明し、組織として入札へ参加するかどうかを判断できる材料を揃えます。
この段階になると、自分でOSやデータベースを構築する時間は減っていきますが、技術経験が不要になるわけではありません。
各担当者が提示した工数は妥当なのか、提案している構成に技術的な無理はないか、障害が発生した場合にどこまで影響が広がるのか、顧客の要求に対して過剰な構成や不足した構成になっていないかを判断するには、現場で積み上げた知識が必要です。
見積もりについても、単価と工数を集計するだけではありません。設計、構築、テスト、移行、運用準備に何人必要なのか、各チームの作業にどのような依存関係があるのか、どの部分に不確実性が残っているのかを理解しなければ、現実的な計画にはなりません。
システム開発費用がなぜ数億円規模になるのか、見積もりにどのような作業や費用が含まれるのかについては、以下の記事で詳しく解説しています。
SIerの管理職やプロジェクトマネージャーは、単に人や進捗を管理するだけの仕事ではありません。少なくとも大規模なシステム開発では、技術、費用、要員、契約、顧客との関係を結び付け、プロジェクトとして成立させる役割を担います。
すべてのSEが同じ経歴をたどるわけではありません。アプリケーションや業務領域を起点に、プロジェクト全体を統括する人もいます。ネットワーク、データベース、セキュリティなど、一つの領域を深く追求し続けるスペシャリストもいます。
一つの専門性を深く経験し、隣接する領域へ担当範囲を広げた結果として、複数の専門職をまとめる立場へ進むというキャリアは、SIerでは特殊なものではありません。
職種名だけを見れば、インフラエンジニア、ネットワークエンジニア、DBA、プロジェクトマネージャー、管理職と分かれます。実際のキャリアでは、それぞれが切り離されているのではなく、過去の技術経験を土台として連続しています。
SEになるためにプログラミングは必須なのか
SEを目指す人から、「プログラミングができなければSEになれないのか」と聞かれることがあります。
答えは、目指す領域によって異なります。
アプリケーションエンジニアやAP基盤エンジニアを目指すのであれば、プログラミングの知識は重要です。自分で大量のプログラムを書かない立場になったとしても、設計の妥当性を判断し、障害原因を調査するためにはコードを読める必要があります。
システム基盤、ネットワーク、データベースを担当する場合も、プログラムと無関係ではありません。
運用作業を自動化するスクリプト、データベースを操作するSQL、クラウド環境を構築するコードなどを扱います。現在は、サーバーやネットワークの構成をコードとして定義し、自動的に構築するIaC（Infrastructure as Code）も利用されています。システム基盤やネットワークを担当するSEにも、コードを読み書きする力が求められる場面は増えています。
すべてのSEが、日常的に業務アプリケーションのプログラムを書いているわけではありません。
顧客との要件調整、システム構成の設計、性能分析、障害対応、プロジェクト管理など、プログラミング以外の仕事も多くあります。
「SEになるためにプログラミングは不要」と言い切るのも、「SEは全員プログラマーである」と捉えるのも正確ではありません。自分が目指す領域で、どの程度のプログラミング知識が必要なのかを考えることが重要です。
SEの専門性は一つの領域から築く
システム開発には多くの専門領域があるため、最初からすべてを理解することはできません。
SEを目指すのであれば、まず一つの領域で基礎を身につけることが現実的です。
アプリケーションであれば、一つの業務機能について、設計、開発、テスト、障害対応まで経験します。システム基盤であれば、サーバーやクラウドサービスを構築するだけでなく、監視、バックアップ、性能確認、障害対応まで担当します。
一連の工程を経験すると、自分が設計した内容が、後続工程や他の担当者、稼働後の運用にどのような影響を与えるのかが見えるようになります。
専門性を身につけた後で、隣接する領域へ知識を広げます。
データベースエンジニアがアプリケーションの仕組みを理解すれば、SQL性能の問題をより正確に分析できます。システム基盤エンジニアがネットワークやデータベースを理解すれば、障害時の切り分けが速くなります。
プロジェクトマネージャーも、いずれかの技術領域や業務領域で現場経験を持っている方が、担当者の説明やリスクの大きさを理解しやすくなります。
周辺領域の知識を広げることと、自分の専門性を失うことは同じではありません。何でも少しずつ知っているだけでは、重大な判断を任されにくくなります。
まずは一つの領域で、設計、構築、テスト、障害対応まで責任を持てる水準を目指し、その専門性を軸に周辺領域との境界を理解できる範囲を広げていくことが、SEとして成長する一つの形です。
市場価値は技術を課題解決につなげる力で決まる
特定のクラウドサービスやデータベース製品に詳しいことは、エンジニアとして大きな強みになります。
製品の操作方法を知っているだけでは、システム開発の課題を解決できないことがあります。
顧客が達成したいことは何か、どのような制約があるのか、どの選択肢を採用すれば品質、コスト、納期のバランスを取れるのかを考えなければなりません。
例えば、性能問題に対してサーバーの台数を増やすことは、一つの解決策です。原因がSQLやアプリケーションの処理方式にあるなら、サーバーを増やしてもコストが上がるだけで、問題の根本は残ります。
ネットワーク障害に見える事象が、実際にはアプリケーションの接続管理やDNSの利用方式に起因していることもあります。一つの製品や担当領域だけで問題を捉えると、対策を誤る可能性があります。
市場価値の高いエンジニアは、知っている製品や技術をそのまま当てはめるのではなく、複数の選択肢を比較し、対象となるシステムに適した方法を選びます。
自分の頭の中だけに解決策を持っていても、プロジェクトは動きません。設計書や計画書として整理し、関係者へ説明し、複数のチームが同じ前提で実行できる状態を作る必要があります。
技術的な判断を、顧客、経営層、営業、契約担当者へ説明する場面では、専門用語を並べるだけでは伝わりません。技術上の問題が、費用、納期、業務継続、契約上の責任へどのような影響を与えるのかを説明する必要があります。
専門技術、業務理解、問題解決、説明、調整の力が組み合わさることで、担当できる範囲と責任が広がります。
まとめ
システム開発は、プログラムを作る人だけでは進められません。プロジェクトマネージャー、アプリケーション、AP基盤、システム基盤、ネットワーク、データベースなど、異なる専門性を持つエンジニアが前提条件を共有し、一つのシステムを作ります。
職種名は専門領域を理解するためには役立ちますが、実際のSIerのSEは一つの職種だけに収まるとは限りません。技術者として積み上げた経験を土台に、周辺領域、費用、要員、契約まで担当範囲を広げ、プロジェクト全体を統括する人もいます。
システム開発の目的は、最新技術を導入することでも、プログラムを書くことでもありません。顧客の業務上の課題を理解し、技術を使って実行可能な仕組みに変えられる人材が、現場で求められるシステムエンジニアです。
このnoteで発信していること
このnoteでは、大規模SIerの現場で経験してきたシステム基盤設計、クラウド移行、運用設計、Oracle Database、プロジェクト管理などを、若手SEやシステム開発に関心を持つ人にも理解できる形で整理しています。
成功事例だけを紹介するのではなく、設計時に見落としやすい点、プロジェクトで実際に発生したトラブル、その原因と再発防止まで含めて記録しています。
システム開発の全体像を知りたい方は、まず以下の記事からお読みください。
コメント