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