SE・システム開発って、実際に何をしている仕事なのか
SE（システムエンジニア）と聞いて、何を思い浮かべるか。「プログラミングをする人」「パソコンに向かって仕事をする人」「IT系の仕事」。どれも間違いではないが、実態とは少し違う。
日本のIT業界におけるSEの仕事を一言で言うなら、「システムを作る責任者」だ。プログラミングはその一部であって全部ではない。むしろ、日本のSEはコードを書かない人も多い。プロジェクト全体を設計し、進行を管理し、クライアントとの調整を行い、品質を担保する。そういう役割だ。プログラミングが好きでSEを選んだ人の中には、「コードを書く時間が少ない」と意外に感じる人が多い。
まず、SEと他の職種の違いを整理しておきたい。ここを理解しておかないと、この仕事の本当の姿が見えない。
SEとプログラマーの違いから。プログラマーは、決められた仕様に従ってコードを書く役割だ。SEはその仕様を決める側だ。「何を作るか」を決め、「どう作るか」を設計する。もちろん、規模の小さい現場ではSEがそのままプログラミングも兼ねることはある。スタートアップや小規模なWeb制作会社なら、設計から実装まで一人で回すのが当たり前だ。でも日本の大企業やSIerでは、SEが設計図を描き、プログラマーがそれに沿って実装するという分業が基本だ。この分業体制が日本のIT業界の特徴でもある。
SEとWeb開発者の違いもある。Web開発者は、WebサイトやWebアプリを作ることに特化している。フロントエンド（ユーザーの目に触れる見た目の部分）かバックエンド（サーバー側の処理やデータベースのやり取り）かで分かれることが多い。一方、SEが扱うのはWebに限らない。社内の業務システム、数万人の従業員が使う基幹システム、工場の製造ラインを制御する組み込み系、ネットワークやサーバーのインフラ構築。対象は多岐にわたる。「システム」という言葉が示す通り、組織の業務を支える仕組み全体を設計するのがSEの仕事だ。
日本のIT業界でよく聞くSIer（エスアイヤー）という言葉もある。システムインテグレーターの略で、クライアント企業のシステム開発を請け負う会社のことだ。NTTデータ、日立製作所、富士通、NEC、野村総合研究所などの大手上場企業から、数人の小さな開発会社まで幅広い。SIerで働くSEは、社内のシステムを作るのではなく、他社からの依頼でシステムを作る立場だ。だからクライアントとの折衝や調整の比重が特に大きい。「技術のプロ」であると同時に、「顧客との窓口」でもある。この二面性が、日本のSEの難しいところだ。
では、SEの1日の仕事はどうなっているのか。プロジェクトのフェーズによって大きく変わるが、代表的な流れを追ってみる。システム開発は一般に、要件定義、設計、実装、テスト、運用保守という5つのフェーズで進む。それぞれ見ていこう。
要件定義は、システム開発の最初の、そして最も重要なフェーズだ。クライアント（社内の場合もあれば外部の場合もある）から「こんなシステムが欲しい」という要望を聞く。ただ聞くだけではない。要望の裏にある本当の課題を引き出す。「売上管理システムを作ってほしい」と言われたら、「なぜ今のExcel管理ではダメなのか」「誰がどんなデータをどう使いたいのか」「月にどれくらいのデータが流れるのか」「スマホからも見たいのか」。これらを質問し、システムが解決すべき問題を明確にする。
要件定義は、日本のSEにとって最も神経を使う作業の一つだ。ここで聞き漏らしたことが、後になって「やっぱり〇〇もできるようにしてほしい」という追加要件になって返ってくる。追加要件はスケジュールと予算を押し上げる。最初の段階で、できるだけ漏れなく要望を引き出し、実現可能な範囲を明確にしておく必要がある。この「聞く力」は、プログラミングとは全く別のスキルだ。技術力があっても、この作業が苦手なSEはいる。逆に言えば、要件定義がうまいSEは重宝される。
設計は、要件定義で決まった内容を技術的な設計図に落とし込むフェーズだ。大きく分けて基本設計と詳細設計がある。基本設計では、システム全体の構成、データベースの構造、画面の遷移、外部システムとの連携方法などを決める。詳細設計では、プログラムの内部ロジック、APIの仕様、エラーハンドリングの方法などを詰める。基本設計が建物の全体図なら、詳細設計は電気の配線図や水道の配管図に当たる。
設計は建築でいう設計図と同じだ。設計図が間違っていたら、どんなに丁寧にコードを書いても完成したものは使えない。だから設計には論理的思考力と先を読む力が求められる。「この設計だと3年後にデータ量が増えた時にパフォーマンスが落ちるかもしれない」「このAPIの設計だと他のシステムとの連携で不整合が起きる」「このテーブル構造だと後から項目を追加する時に全画面の修正が必要になる」。先の問題を設計段階で潰しておくのがSEの腕の見せ所だ。
データベース設計は、設計の中でも特に重要な領域だ。システムのデータがどう保存され、どう使われるかを決める。テーブルの構造、項目の定義、インデックスの設計、データの整合性を保つための制約。データベースの設計が悪いと、システム全体のパフォーマンスと保守性に悪影響が出る。「後から直せばいい」と思えるかもしれないが、データベースの構造変更は、影響がシステム全体に波及するため、リリース後の変更は非常にコストが高い。だからこそ、設計段階での慎重な検討が必要になる。
API設計も、最近のシステム開発では重要性が増している。複数のシステムが連携する現代のアーキテクチャでは、APIがシステム間のインターフェースになる。RESTかGraphQLか、エンドポイントの命名規則はどうするか、エラーレスポンスのフォーマットはどうするか、認証・認可の方式はどうするか。APIの設計が適切でないと、フロントエンドの開発効率が落ちるし、外部システムとの連携でトラブルが起きる。API設計は、技術的な知識とビジネス要件の理解の両方が求められる領域だ。
実装は、設計書に従ってコードを書くフェーズだ。SE自身がコードを書く場合もあれば、プログラマーに指示を出して書かせる場合もある。規模の大きいプロジェクトでは、SEは実装の管理に徹する。コードレビューを行い、進捗を確認し、設計との乖離がないかチェックする。小規模な現場では、設計から実装まで一人で完結することもある。
実装で使う言語は案件による。社内の業務システムならJavaやC#が多い。Web系ならPython、Ruby、PHP、Go、TypeScriptなど。インフラ寄りならシェルスクリプトやTerraform。最近はクラウド（AWS、Azure、GCP）の知識も必須になってきている。特定の言語ができることより、論理的に考え、新しい技術を素早くキャッチアップする力の方が重要だ。「Javaしかできない」というエンジニアより、「言語は何でもすぐ覚えられる」というエンジニアの方が、長期的なキャリアで有利になる。
実装フェーズで重要なのがコードレビューの文化だ。チーム開発では、誰かが書いたコードを他のメンバーが確認する。バグの混入を防ぐだけでなく、コーディング規約に従っているか、設計と乖離していないか、パフォーマンス上の問題がないかを確認する。コードレビューは技術的な指摘だけでなく、メンバー間の知識共有の場にもなる。「この関数はこう書くとよりシンプルになる」「このライブラリを使うと同じ処理が3行で済む」。こうした情報交換が、チーム全体の技術力を底上げする。
実装の進め方も、プロジェクトの規模によって違う。アジャイル開発の場合はスプリント（通常1〜2週間）ごとに動くものを作り、フィードバックを受けて次のスプリントに反映する。ウォーターフォール開発の場合は、設計書が完成してから実装に取り掛かる。どちらの開発手法でも、実装は設計との整合性を保ちながら進める必要がある。設計書に書かれていない例外処理や境界条件は、実装しながら考えなければならない。この「設計の隙間を埋める力」もSEに求められるスキルだ。
テストは、作ったシステムが正しく動くかを確認するフェーズだ。単体テスト（ユニットテスト）で個々のプログラムの動作を確認する。結合テスト（インテグレーションテスト）で複数のプログラムが連携して正しく動くかを確認する。システムテストで全体が要件を満たしているかを確認する。ユーザー受け入れテスト（UAT）で、実際に使う人に操作してもらい問題がないかを確認する。テストの段階ごとに狙いが違い、それぞれで違う視点からシステムを検証する。
テストは地味だが、品質を担保する上で絶対に欠かせないフェーズだ。テストでバグを見つけるのは嬉しいことだ。リリース前に見つけたバグは直せるが、リリース後に見つかったバグは実際の業務に影響を与える。金融システムでバグが起こればお金の計算が狂う。在庫管理システムでバグが起これば発注が止まる。だからテストは「手抜きできる工程」ではなく「最も丁寧にやるべき工程」だ。でも現実には、スケジュールの都合でテスト期間が削られることが多く、SEは「どこまでテストするか」の判断を迫られる。
運用保守は、リリース後のシステムを維持するフェーズだ。システムは作って終わりではない。日常的に監視し、エラーが起きていないかを確認する。利用者からの問い合わせに対応する。バグが見つかれば修正する。新しい要望があれば追加開発を行う。セキュリティの脆弱性が見つかればパッチを当てる。OSやミドルウェアのバージョンアップに対応する。運用保守は開発の終わりではなく、システムのライフサイクルの大部分を占める。
運用保守は「地味な仕事」と思われがちだが、実はエンジニアとしての総合力が問われる領域だ。障害が起きた時に原因を特定し、速やかに復旧させる。一見関係なさそうな複数の事象から共通の原因を推測する。利用者からの「動かない」という曖昧な報告から、再現条件を特定する。こうしたトラブルシューティングの力は、経験を積んだSEならではのスキルだ。設計も実装もできるけど、運用保守は苦手というエンジニアは意外と多い。
ここまで書いて気づいた人もいるかもしれない。SEの仕事の中で、純粋にコードを書いている時間は意外と少ないのだ。要件定義の打ち合わせ、設計書の作成、進捗管理の会議、クライアントへの報告、テストの計画と実行、運用のドキュメント作成。人と話し、文章を書き、予定を調整する時間の方が長いことすらある。日本のSEは「技術職」というより「技術を理解したプロジェクト管理職」に近い側面がある。
「SEはコードを書かない」と言うと極端に聞こえるかもしれない。実際には、プロジェクトの規模やフェーズによってコードを書く時間の割合は変わる。小規模なプロジェクトや、実装フェーズに集中的にアサインされている時は、一日の大半をコーディングに費やすこともある。でも全体として見ると、日本のSEの仕事のうちコーディングの占める割合は、多くの人の想像よりも低い。この現実を知った上でSEを選ぶかどうかが重要だ。
日本のSEの年収は、経験年数や企業規模によって大きく変わる。初任給は年収300〜400万円程度。5年経験を積めば500〜600万円。大手SIerや外資系IT企業でマネジメントを担当するようになると700〜800万円以上も珍しくない。最近はクラウドエンジニアやデータエンジニアなど、専門性の高い領域では1000万円を超えるケースもある。ただし、労働時間も長くなりがちで、納期前の残業や休日出勤が発生する現場はまだ多い。IT業界全体で働き方改革が進んでいるが、プロジェクトの納期は待ってくれない。
日本のIT業界には情報処理技術者試験という国家試験がある。基本情報技術者試験、応用情報技術者試験、データベーススペシャリスト、ネットワークスペシャリスト、プロジェクトマネージャーなど。これらの資格は法律上必須ではないが、昇進や評価の基準として使う企業が多い。特にSIerでは、資格の取得がキャリアプランに直結することがある。基本情報技術者試験は入社数年以内に取るのが暗黙の了解になっている現場もある。
SEの面白さは、自分が設計したシステムが実際に動いて、誰かの仕事を助けていることが目に見えることだ。何十万件のデータを一瞬で処理するバッチプログラム、複数の拠点をつなぐ基幹システム、現場の作業員がタブレットで使う業務アプリ。自分の設計が形になって社会で動いている。この達成感は、他の職種ではなかなか味わえない。設計で悩んだ末に解決策を見つけた時の快感、バグを特定して修正した時の安堵感、システムが無事にリリースされた時の達成感。こうした感情がSEのやりがいの正体だ。
日本のSEにはもう一つ特有の側面がある。ウォーターフォール開発とアジャイル開発の違いだ。ウォーターフォールは、要件定義→設計→実装→テスト→運用保守という順番で、一つのフェーズが終わってから次のフェーズに進む。日本の大企業やSIerではこの方式が長年主流だった。一方、アジャイルは、短い期間で設計・実装・テストを一気に回し、少しずつシステムを育てていく方式だ。最近はアジャイルを採用する現場が増えている。
この違いは、SEの働き方にも影響する。ウォーターフォールでは、各フェーズの担当が分かれていることが多い。要件定義専門のSE、設計専門のSE、テスト専門のSE。アジャイルでは、一人のSEが設計も実装もテストも兼務することが多い。どちらが良いかは現場によるが、自分の性格に合った開発手法を選ぶこともキャリアの選択肢の一つだ。ウォーターフォールの厳格な手順が安心な人もいれば、アジャイルの変化の速さが楽しい人もいる。
もう一つ、日本のIT業界で特筆すべきは多重下請け構造の存在だ。大手SIerがクライアントからシステム開発を受注し、中規模の会社に開発を委託し、さらに小規模な会社に委託する。この階層が3層、4層になることがある。現場でコードを書いているのは最下層のエンジニアだが、その上に何層もの会社が挟まっている。この構造が、日本のIT業界の様々な問題の根源になっていると指摘されることが多い。コミュニケーションのロス、要件の伝達ミス、責任の所在の曖昧さ。SEを目指す人は、この現実も知っておいた方がいい。
ビッグファイブで見るSE・システム開発に向いている性格
SEに向いている人を「理系の人」「論理的思考ができる人」と片付けるのは簡単だ。でも実際は、論理的思考だけでなく、忍耐力、好奇心、独力で問題を解決する力などが絡み合っている。ビッグファイブの5つの因子が、SEの仕事のどの部分にどう影響しているのかを整理する。
データを見ると、SE・システム開発の職種は開放性（O）と誠実性（C）が高く、外向性（E）と協調性（A）はほとんど関係ないという特徴がある。開放性の因子スコアへの寄与は0.22、誠実性は0.26。一方で外向性は0.04、協調性も0.04。神経症傾向（ES）は0.16。この配置は「内向的で論理的な職種」の典型的なパターンだ。一つずつ見ていこう。
開放性が高い人：技術の変化を楽しみ、問題に多角的にアプローチできる
開放性が高い人は、SEの仕事で最も大きな武器を持っている。それは「新しい技術に抵抗なく飛び込める力」だ。IT業界は技術の変化が激しい。3年前のベストプラクティスが今はアンチパターンになっていることがある。オンプレミスからクラウドへの移行、モノリスからマイクロサービスへの分解、手動デプロイからCI/CDパイプラインの構築。次々と新しい概念とツールが登場する。開放性が高い人は、こうした変化を「面倒」ではなく「面白い」と感じられる。
技術の変化に対する抵抗感が低いというのは、単なる好奇心の話ではない。キャリアの持続力に直結する。IT業界に20年いると、自分が最初に覚えた技術の半分以上が使われなくなっている。JavaのApplet、Flash、jQuery主体のフロントエンド、XMLによる設定ファイル。当時は当たり前だった技術が、今は歴史の彼方にある。この変化についていくのに必要なのは「新しいものが好き」という感覚だ。開放性が高い人は、この感覚を自然に持っている。
また、開放性の高さは問題解決の柔軟さにも繋がる。システム開発では、予期しない問題に直面することが日常茶飯事だ。設計通りに進まない、既存システムの制約が後から分かる、パフォーマンスが要件を満たさない、外部APIの仕様が開発中に変わる。こうした問題に直面した時、一つのアプローチに固執せず、別の方法を試せるのが開放性の高い人だ。「この設計ではダメなら別の設計を試そう」「この技術では解決が難しいなら別の技術を調べてみよう」「このアーキテクチャではスケールしないなら別の構成を考えてみよう」。この柔軟さは、SEとしての成長速度に直結する。
開放性が高いSEは、仕事の幅も広がりやすい。バックエンドをやっていてもフロントエンドに興味を持つ。業務システムをやっていてもインフラやクラウドに関心が向く。データベース設計をしていても、データ分析や機械学習に手を出す。関心の幅が広いからこそ、プロジェクトの要件に合わせて対応できる領域が増えていく。「Javaのエンジニア」として一生やっていくのも悪くないが、幅が広い方がキャリアの選択肢は増える。
開放性が高い人のもう一つの強みは、自学自習の習慣が身についていることだ。IT技術の多くは、学校や研修で体系的に学ぶというより、仕事で必要に迫られて独学で覚えることが多い。公式ドキュメントを読む、技術ブログを参考にする、OSSのコードを読む、試しに手を動かして動作確認する。この自学のサイクルが自然に回るのが開放性の高い人だ。新しい技術に出会った時、「覚えなきゃ」という義務感ではなく「試してみたい」という好奇心が先行する。この違いが、長期的な技術力の差になって表れる。
誠実性が高い人：ドキュメント、テスト、運用保守を確実にこなす
SEの仕事は、設計書を書く、コードを書く、テストをする、ドキュメントを整備する、進捗を報告する。どれも「やらなくてはいけないこと」の連続だ。しかも、どれか一つでもおろそかにすると、後で大きな問題になる。設計書が曖昧だと実装段階で手戻りが発生する。テストが不十分だとリリース後に障害が起きる。ドキュメントがないと運用保守の担当者が途方に暮れる。進捗の報告が遅れるとプロジェクト全体の計画が狂う。
誠実性が高い人は、こうした「やらなくてはいけないこと」を確実にこなす。期限内に設計書を提出する。テストケースを漏れなく作成する。コードのコメントを丁寧に書く。進捗の報告を毎日欠かさない。どれも派手な仕事ではないが、プロジェクトを成功させるために不可欠な作業だ。チームの他のメンバーから見ると、こうした人がいるプロジェクトは安心感が違う。「この人が担当しているなら、ドキュメントもテストもちゃんとやっているだろう」という信頼が生まれる。
特に運用保守のフェーズでは、誠実性の差が如実に出る。毎日のログの確認、アラートへの対応、定期的なバックアップの実行、セキュリティパッチの適用、稼働率のレポート作成。これらを毎日、毎週、毎月、淡々と続ける。誠実性が低いと、最初はやる気よく始めても次第におろそかになり、気づかないうちにリスクが蓄積していく。「バックアップは取っている」と思っていたら半年前から失敗していた、という事例は現実によくある。誠実性の高い人は、こうした事態を防ぐ。
日本のSIerでの開発では、ドキュメントの重みが特に大きい。設計書、仕様書、テスト仕様書、運用マニュアル、障害対応手順書。一つのプロジェクトで何十、何百ページのドキュメントが作られることがある。これらを正確に、期限内に作成するのがSEの仕事だ。誠実性が低いと、ドキュメント作成が後回しになり、結局プロジェクトの終盤で慌てて書くことになる。急いで書いたドキュメントは精度が低く、後で見返した時に自分でも分からないことがある。
誠実性の高さは、スケジュール管理の面でも活きる。システム開発のプロジェクトは複数のタスクが並行して進む。設計書の作成、プログラマーへの指示、テストの準備、クライアントへの報告。それぞれに期限があり、一つの遅れが全体に波及する。誠実性が高い人は、タスクの優先順位を適切に設定し、期限を守るための逆算ができる。何をいつまでにやる必要があるかを常に意識し、予定通りに進まない時は早めに手を打つ。この管理力は、プロジェクトマネージャーに近い役割を担うSEにとって不可欠だ。
外向性が低くても問題ない：一人で集中できる環境が生産性を高める
SE・システム開発は、外向性が低くても全く問題ない職種だ。データ上も外向性の因子スコアへの寄与は0.04と非常に低い。これは、SEの仕事の大部分が「一人で集中して取り組む作業」で成り立っているからだ。設計書を書く時間、コードを書く時間、テストを実行する時間、ドキュメントを整備する時間、バグの原因を調べる時間。これらは全て、一人で静かに取り組む方が効率が良い作業だ。
会議や打ち合わせはあるが、SEに求められるコミュニケーションは「場を盛り上げる」ではなく「技術的な内容を正確に伝える」ことだ。外向性が高くなくても、論理的に説明できれば問題ない。むしろ、会議の後すぐに一人の作業に戻れる人が生産性を上げやすい。外向性が高い人が「人のいない環境」にストレスを感じるのとは逆に、外向性が低い人は「邪魔されない環境」で力を発揮する。
「人と話すのが苦手だからSEに向いている」という言い方もできる。もちろん、全く人と話さなくていいわけではない。要件定義の打ち合わせや進捗の報告はある。でも、そのコミュニケーションは「雑談」ではなく「情報の共有」だ。人懐っこさや場の空気を読む力は、SEの仕事ではあまり求められない。分かりやすく説明する力と、正確に聞き取る力。この2つがあれば、外向性が低くてもSEとしてやっていける。
協調性が低くても仕事は回る：仕様には妥当性を主張する場面もある
協調性の因子スコアへの寄与も0.04と非常に低い。これは一見意外に思えるかもしれない。SEはチームで働くのだから、協調性も重要なのではないか。確かに、チームのルールに従い、他のメンバーと協力して作業を進めることは必要だ。コーディング規約に従う、バージョン管理のルールを守る、レビューの指摘に対応する。こうした基本的な協調性は求められる。
しかし、SEの仕事には「妥協してはいけない場面」がある。例えば、クライアントから「予算を減らしたいからテスト工程を短縮してほしい」と言われた時。安易に応じるとリリース後に重大な障害を引き起こす可能性がある。この時、SEは「それは品質上危険です」と正直に伝える必要がある。協調性が高すぎると、相手の顔色を見て妥協してしまう。協調性が低めの人は、「嫌われたくない」という感情に引っ張られず、技術的な正しさを主張できる。この「適度な頑固さ」は、品質を守る上で役に立つ。
設計のレビューでも同じことが言える。先輩や上司の設計案に「これでは不整合が起きる」と指摘する場面は、協調性が低めの人の方がやりやすい。協調性が高い人は「空気を読んで」指摘を控えてしまい、後で問題が顕在化することがある。SEの仕事は、論理的な正しさを追求する場面が多い。協調性が低めであることは、その意味ではプラスに働く。
神経症傾向が低めの人：トラブルに冷静に対応できる
SEの仕事には予期しないトラブルがつきものだ。本番環境でエラーが発生する、データの不整合が見つかる、リリース直前に重大なバグが見つかる、サーバーのディスク容量が枯渇する、外部システムとの通信が途絶える。こうした場面でパニックにならず、冷静に原因を分析し、対策を打てるかどうか。神経症傾向が低めの人は、プレッシャーの掛かった場面でも冷静さを保ちやすい。
障害対応の現場では、この差が如実に表れる。本番環境が止まっている状況で、ビジネス側から「いつ直るのか」と矢のように催促が来る。システムのログを確認し、原因を特定し、復旧策を実行する。この一連の作業を冷静に進められるかどうか。神経症傾向が高いと、焦りから見落としが生じ、かえって復旧が遅れることがある。低めの人は、「まずは落ち着いてログを確認しよう」と自分をコントロールできる。
また、SEの仕事は期間の長いプロジェクトが多い。数ヶ月から数年にわたるプロジェクトを、毎日淡々と進める必要がある。途中で成果が目に見えない時期も長い。設計を終えても、実装が終わらないと動くものは見えない。実装が終わっても、テストが終わらないと品質は分からない。神経症傾向が高いと、「本当に完成するのか」「自分の設計で大丈夫なのか」と不安に駆られやすい。低めの人は、目の前の作業に集中し、不安をあまり感じずにプロジェクトを進められる。
ただし、神経症傾向の因子スコアへの寄与は0.16と、開放性や誠実性に比べれば低い。SEに向くかどうかを決める最も重要な因子は、開放性と誠実性だ。神経症傾向は「あった方が良い」程度の影響力だと考えるのが自然だ。
因子の組み合わせで見るSEのキャリア
SE・システム開発の性格適性は、単一の因子ではなく、因子の組み合わせで考えるとより実感に近くなる。開放性と誠実性が両方とも高い人は、理想的なSE像に近い。新しい技術を積極的に取り入れつつ、地味な作業も確実にこなす。学習意欲が高く、かつ慎重。変化を楽しみつつ、変化に伴うリスクを管理できる。こういう人は、アーキテクトやテックリードとして成長していく。
開放性が高いが誠実性が低い人は、技術力はあるが手が抜けがちだ。アイデアは豊富で、新しい技術を試すのも好き。でもドキュメントが雑で、テストは最低限。こういう人は、スタートアップや小規模なチームで、スピード重視の開発に向いている。大企業の厳格なプロセスには馴染みにくい。
誠実性が高いが開放性が低い人は、作業は丁寧だが、新しい技術への対応が遅れがちだ。既存のシステムの保守や、手順が確立している運用業務では高いパフォーマンスを出す。ただ、新しい技術が求められる案件では、キャッチアップに時間がかかる。深い専門性を一つ持つことで、この弱点を補える。
開放性も誠実性も低い人は、SEの仕事に大きな違和感を覚えるかもしれない。新しいことを覚えるのは苦手、コツコツやるのも苦手。SEの仕事の多くが「新しいことの学習」と「地道な作業の積み重ね」で成り立っているからだ。この場合、SE以外の職種を検討した方が良い。技術を活かす仕事はSEだけではない。
この記事の話は、性格の5つの因子（ビッグファイブ）で読み解けます。自分の傾向は5分で測れます。
ビッグファイブ診断を受ける（無料・登録不要）向いていない人が陥りやすいパターン
SE・システム開発に向いていない人が入ってから気づくパターンをいくつか見ていく。「SEは誰でもなれる」と思われがちだが、性格との相性は確実にある。
開放性が低くて、新しい技術の学習が苦痛なパターン
IT業界は、やったことがない技術に毎年のように出会す世界だ。去年まで使っていたフレームワークが非推奨になり、新しいフレームワークに乗り換える。クラウドのサービスがアップデートされて、以前のやり方が通用しなくなる。新しいプログラミング言語が注目を集め、仕事で使う機会が増える。こうした変化が、開放性が低い人には重荷になる。「また新しいこと覚えるのか」「前のやり方でいいじゃないか」という気持ちが強くなる。
このタイプは、ルールが決まっている作業や手順が確立している環境では真面目に取り組む。マニュアルに従った運用保守や、決まった手順のテスト実行、定型業務の自動化スクリプトの保守など。しかし、新しい技術のキャッチアップが求められる場面や、設計の段階で複数の選択肢から最適なものを選ぶ場面で行き詰まる。「昔ながらのやり方」に固執しているうちに、周囲のエンジニアとの技術格差が広がっていく。
これは「勉強不足」という話ではない。本人は分かっているのだ。「新しい技術を覚えた方がいいのは分かっている。でも、今のやり方で動いているのに変えるのが億劫だ」という葛藤がある。開放性が低い人の多くは、新しいこと自体が嫌いなのではなく、新しいことへの切り替えにエネルギーが必要なのだ。この切り替えのコストが、IT業界では常に発生する。だから開放性の低さが、SEのキャリアで大きな障壁になる。
現実問題として、IT業界にいて技術の変化を避けることはできない。開放性が低い人がこの業界で長く働くなら、得意な領域を深く掘り下げて専門家になるという手はある。全ての技術に追いつくのではなく、一つの領域（データベース、ネットワーク、セキュリティなど）に絞って深い専門性を持つ。そうすれば、変化の激しい領域よりも安定した領域で力を発揮できる。データベースの基礎は30年前と今でそれほど変わっていない。ネットワークのプロトコルも根幹は同じだ。深い専門性を持つエンジニアは、変化に振り回されにくい。
誠実性が低くて、ドキュメントやテストが雑になるパターン
プログラミングは好きだ。コードを書いている時は楽しい。アイデアが浮かんで実装して動いた時の快感がある。でも設計書を書くのは面倒だ。テストケースを考えるのはつまらない。ドキュメントを整備する時間は無駄に感じる。進捗の報告は毎回同じことの繰り返しだ。こういう人がSEになると、コードの品質は良くても、周囲への共有が不十分になりがちだ。
このパターンの危険なところは、本人は「仕事をしているつもり」なことだ。コードは書いている。機能は実装している。動くものはできている。でも、設計書がないから他の人がコードを読まないと仕様が分からない。テストが不十分だから、後で修正した時に別の機能が壊れていることに気づかない。ドキュメントがないから、運用保守の担当者がエラーの原因を特定するのに余計な時間がかかる。
特にチーム開発では、誠実性の低さが周囲に迷惑をかける。自分の担当部分の設計書が遅れると、後続の作業が始められない。テストが不十分だと、結合テストの段階で大量のバグが見つかり、スケジュールが押し戻される。自分一人で開発している時は問題にならなくても、チームに入った途端に破綻する。SEは個人の仕事でありながら、チームの仕事でもある。自分の作業の質が、プロジェクト全体に影響する。
日本のSIerでは特に、ドキュメントの質が評価の基準になることがある。コードがどれだけ綺麗でも、設計書が不正確だと評価は下がる。逆に、コードは普通でも、設計書やテスト仕様書が完璧な人は高い評価を得ることがある。この文化に馴染めないと、「コードで勝負したいのに、書類仕事ばかりさせられる」と不満が溜まる。
人と話すのが苦手で、要件定義に苦しむパターン
「SEはコードを書いていればいい」と思って入ったのに、実際はクライアントとの打ち合わせばかり。要件定義の席で、「この機能は本当に必要ですか」と聞かなければならない。「その要望だと予算が足りません」と伝えなければならない。「今のスケジュールでは実装できません」と断らなければならない。こうした対人コミュニケーションが苦手な人は、SEの仕事のうち要件定義フェーズで大きなストレスを感じる。
SIerのSEは特に、クライアントとのやり取りが多い。お客様はシステムの専門家ではないから、「何ができるか何ができないか」を分かりやすく説明する必要がある。技術的な制約を、ビジネス側の人にも理解できる言葉で伝える。要望を実現するためのコストと期間を、現実的な数字で提示する。こうした作業が苦手だと、要件定義のフェーズが毎回辛い。
ただ、この問題は「SEに向いていない」と即断するべきではない。なぜなら、要件定義を担当するのは一般的に上流工程のSE、つまり経験を積んだSEだからだ。入社直後はテストや実装の担当から始まることが多く、要件定義を任されるのは数年経ってからだ。最初は人と話す比重が少ないポジションから始めて、徐々に上流に携わるようになる。コミュニケーションが苦手でも、実装やテストの領域で技術力を磨く道はある。
それでも、日本のSEはどうしても「人と話す」場面が多い。社内の調整、進捗の報告、障害の連絡、メンバーへの指示、他部署とのすり合わせ。完全に一人で黙々と作業できるのは、ごく一部の現場に限られる。この現実を受け入れられないと、ずっとストレスを抱えることになる。
耐性が低くて、長期プロジェクトの途中で燃え尽きるパターン
SEのプロジェクトは長い。小さな改修でも1〜3ヶ月、大きなプロジェクトだと1〜3年かかる。その間、同じシステムと向き合い続ける。途中で仕様変更が入る。思いがけない技術的壁にぶつかる。テストで次々とバグが見つかる。納期が近づいて残業が増える。こうした長期戦の中で、モチベーションを維持し続けられるかどうか。
特に日本のSIerでは、一大規模なプロジェクトに何年もアサインされることがある。最初は「このシステムを作るんだ」とワクワクしても、1年経つと「まだこのプロジェクトなのか」という感覚になる。2年目は仕様変更の対応に追われ、3年目は運用保守のフェーズに入る。新しいチャレンジよりも保守的な作業が増える。ここでモチベーションを切らす人がいる。
この問題は「根性が足りない」という話ではない。長期間同じ対象に向き合い続けることが、性格的に負担になる人がいるということだ。短期間で次々と違う課題に取り組む方が向いている人、変化の多い環境でエネルギーを得る人にとっては、長期プロジェクトの持続が苦痛になる。Web系のベンチャー企業のように、数週間単位でプロジェクトが変わる環境の方が向いているかもしれない。
外向性が高すぎて、一人の作業に退屈するパターン
外向性が極端に高い人も、SEの仕事に違和感を覚えることがある。設計書を書く時間は静かで孤独だ。コードを書いている間は、誰とも話さない。テストを実行して結果を確認するのも一人の作業だ。外向性が高い人は、こうした「一人の時間」にエネルギーが枯渇していく。「もっと人と関わりたい」「チームでワイワヤやりたい」という欲求が満たされない。
このタイプは、社内での雑談や飲み会では中心的な存在になる。チームの雰囲気を良くするし、コミュニケーションも円滑だ。でも、作業に戻った途端に退屈そうにする。集中力が続かず、頻繁に席を立つ。この「一人の作業に対する苦手さ」が、SEの生産性に響く。外向性が高い人がSEをやるなら、ペアプログラミングやモブプログラミングなど、対話しながら進めるスタイルを取り入れると良いかもしれない。
開放性と誠実性が両方低い、最も苦しいパターン
開放性が低く、誠実性も低い人は、SEの仕事で最も苦労するパターンだ。新しい技術を学ぶのが苦手で、コツコツとした作業も苦手。SEの仕事の大部分がこの二つで成り立っていることを考えると、ほぼ全てのフェーズで負担が大きい。要件定義では「どういう技術で実現するか」を考える時に知識のストックが少なく、設計では「こういう選択肢もあるのでは」という発想が出にくい。実装では、使っている技術の理解が浅いため、エラーの原因が分からずに行き詰まる。テストでは、テストケースを丁寧に作る根気が続かない。運用保守では、日常的な監視作業をサボりがちになる。
このパターンに当てはまる人がSEを続けるなら、自分に合った小さな領域を見つけることが重要だ。全てをこなそうとせず、一つの得意な作業に絞る。例えば、決まった手順の運用業務や、マニュアルに従ったテストの実行。こうした定型化された作業であれば、開放性と誠実性が低くても対応できる。ただ、この先キャリアの幅を広げるのは難しくなる。SE以外の職種を検討するのも一つの手だ。
自分がどのパターンに近いかを知る方法
ここまで挙げたパターンのいずれかに「自分に似ている」と感じた人は、ビッグファイブの因子スコアを測ってみることをおすすめする。感覚的な「自分はこういう性格だ」という認識は、客観的なデータと照らし合わせると意外な発見があることがある。「自分は開放性が高いと思っていたけど、実際は低かった」とか、「誠実性は低いと思っていたけど、平均以上だった」とか。感覚とデータの両方を見ることで、より正確に自分の傾向を把握できる。
性格を踏まえたキャリアの考え方
SE・システム開発に向いていないと感じたからといって、「論理的思考ができない」とか「技術に向いていない」ということではない。SEの仕事が求める環境と、自分の性格の傾向が合っていないだけだ。自分に合った形で力を発揮できる環境を探す方向で考える。
SEの要素を分解して考える
「SEが合わない」と思った時、何が合わないのかを分解してみる。要件定義でクライアントと話すのが苦痛なのか、長期プロジェクトの単調さがしんどいのか、ドキュメント作成が嫌なのか、運用保守の繰り返しがつまらないのか、一人の作業が寂しいのか。SEの仕事は複数のフェーズに分かれている。全てが合わないのか、一部が合わないのかで、取るべき方向が変わる。
例えば、コードを書くこと自体は好きだけど要件定義やドキュメント作成が嫌だというなら、実装に特化したポジションを探せばいい。プログラマーやWeb開発者として、設計よりも実装に比重を置いた職種に移る選択肢がある。Web系のベンチャー企業やスタートアップでは、設計から実装まで一人で回すことが多く、ドキュメントよりも動くコードが重視される。SIerの「文書文化」に合わない人は、こうした現場の方が向いていることがある。
開放性を活かす別の道
新しい技術への関心が高く、常に変化のある環境で働きたいなら、Web開発やデータ分析・AIの領域も選択肢だ。Web開発は技術のサイクルが速く、常に新しいフレームワークやツールが登場する。変化を楽しみたい人には刺激的な環境だ。データ分析・AIの領域は、数学や統計の素地があれば、SEの論理的思考力を別の形で活かせる。機械学習モデルの構築やデータパイプラインの設計など、SEの経験が直接役に立つ領域は多い。
Web開発とSEの境界線は、日本では曖昧になりつつある。昔は「Web系＝_lightweight_、SE系＝enterprise」という棲み分けがあったが、今はWebの技術がenterpriseのシステムにも浸透している。Web開発者の仕事について詳しく知りたいなら、Web開発の仕事と性格の記事も参考にしてほしい。
誠実性を活かす別の道
丁寧な作業と正確性が求められる環境なら、品質管理やテストエンジニアという選択肢もある。テストエンジニアは、システムが要件を満たしているかを検証する専門職だ。テストケースの設計、テストの実行、結果の分析、品質指標の報告。地道だが、品質を担保する重要な役割だ。誠実性が高い人は、この作業を確実にこなせる。テストエンジニアの需要は、システムが複雑化するにつれて高まっている。
人と話すのが苦手なら、インフラ寄りのポジションも
クライアントとの打ち合わせが苦手でも、技術的な課題と向き合うのは好きだというなら、インフラエンジニアやネットワークエンジニアの方向もある。インフラエンジニアは、サーバーやネットワークの構築・運用を担当する。ユーザーとの直接のやり取りよりも、システムの裏側の安定性に集中できる。人と話すよりも機械と向き合う方が性に合っている人は、この方向で力を発揮できる。インフラエンジニアも需要が高く、クラウドの普及で重要性が増している領域だ。
開放性が低くても誠実性が高いなら、専門領域の保守運用で
開放性が低いからといって、IT業界で活き場がないわけではない。誠実性が高いなら、既存のシステムの保守運用で高い評価を得られる。金融の基幹システム、製造業の生産管理システム、医療の電子カルテシステム。これらのシステムは長期間稼働し、安定した運用が何より求められる。新しい技術を試す機会は少ないが、代わりに一つのシステムを深く理解し、確実に運用できることが価値になる。誠実性が高い人は、こうした「守る」役割で本領を発揮する。
自分の因子スコアを知る意義
SE・システム開発に向いているかを知る上で、ビッグファイブの因子スコアは一つの材料になる。「開放性が高いから新しい技術への適応が早い」「誠実性が低いからドキュメントやテストをサボりがちになるかもしれない」。こういう読み取りが、自分のスコアを知っていればできる。スコアは傾向であって決定ではない。自分の傾向を知った上で、どういう環境でなら力を発揮できるかを考える材料として活用してほしい。
SEの世界で言えば、開放性と誠実性の両方が高い人は、新しい技術を積極的に取り入れつつ、確実な作業もこなす。バランスの取れたエンジニアになれる可能性が高い。開放性は高いが誠実性が低い人は、アイデアや技術力はあるが、手を抜きがち。逆に誠実性は高いが開放性が低い人は、作業は丁寧だが、新しい技術への対応が遅れがち。どのパターンにも長所と短所がある。自分がどのタイプかを知っていれば、短所を補う工夫ができる。
自分に合った働き方を選ぶ
最後に、SEと一口に言っても働き方は様々だ。大企業のSIerで安定したプロジェクトに長く関わる働き方、Web系の企業でスピード感のある開発に挑む働き方、フリーランスとして案件を選びながら働く働き方。同じ「SE」の肩書きでも、働く環境によって求められる性格も、得られる経験も違う。自分の性格に合った働き方を選ぶことも、キャリアを考える上で重要だ。
自分の性格を知り、それに合った環境を選ぶ。その繰り返しが、長く働き続けられるキャリアを作る。ビッグファイブの因子スコアは、その判断の一つの材料になる。SE・システム開発は、日本のIT業界の根幹を支える職種で、需要は右肩上がりだ。自分の性格と向き合った上で、この職種を選ぶか、別の道を探すか。その判断の材料として、ビッグファイブの因子スコアを役立ててほしい。
日本のIT業界の今後とSEの需要
蛇足になるかもしれないが、SE・システム開発という職種自体の将来についても触れておく。「AIがコードを書くようになったらSEは不要になるのでは」という疑問を持つ人もいるだろう。結論から言うと、少なくとも今後10年程度でSEが不要になることはない。AIは確かにコードを書く能力が向上している。しかし、SEの仕事の大部分は「何を作るかを決めること」と「作ったものが正しく動くことを保証すること」だ。この部分は、ビジネス要件の理解、ステークホルダーとの調整、システム全体の整合性の確認など、人間の判断が不可欠な領域だ。
むしろ、AIの普及によってSEの仕事は「コードを書く」から「AIが書いたコードをレビューする」「AIに指示を与えるための仕様を適切に定義する」方向にシフトしていく。この変化にも、開放性の高さが役に立つ。新しいツールを積極的に取り入れ、自分の仕事の一部をAIに任せる柔軟性がある人ほど、この変化に対応しやすい。開放性が高いSEにとって、AIは脅威ではなく強力な味方になるはずだ。
日本では少子高齢化が進み、システムを支えるエンジニアの不足が深刻化している。DX（デジタルトランスフォーメーション）の潮流で、これまでアナログだった業務をシステム化する需要が急増している。この需要に対してエンジニアの供給が追いついていない。SEの需要は当面続くし、技術力のあるエンジニアの市場価値は上がり続ける。性格との相性さえ合えば、長期的に安定したキャリアを築ける職種だ。