Skip to content セクションへスキップ

💻実務とノウハウ

ソフトウェアエンジニア · 現代生活を動かすコードを書き、テストし、保守する仕事であり、AIが自分自身の日々の作業を自動化していく様子を最初に目の当たりにしている職業の一つでもある。

一目で
指標の濃さ

濃いマスほど、このテーマでその指標が高いことを示します。

最終確認 出典とクレジットメディアクレジット方法論

短い答え

ソフトウェアエンジニアは実際に一日何をしているのか?

多くの日は、新しいコードを書くこと、レビューで他人のコードを読むこと、バグを修正すること、次に何を作るべきかチームメイトと話し合うことに分かれる。会議や計画立案、後輩の指導は新人が思う以上に時間を占める。シニアエンジニアはジュニアエンジニアより自分でコードを書く量が少なく、設計判断やレビュー、他者の障害を取り除くことに多くの時間を費やすことが多い。

ソフトウェアエンジニアになるにはコンピューターサイエンスの学位が必要か?

必須ではないが、依然として最も一般的で摩擦の少ない道である。4年制の学位ではアルゴリズムやデータ構造、システムの概念を学ぶが、これらは独学では習得コストが高い。ブートキャンプ卒業生や独学のエンジニアも採用されており、特に小規模企業ではそうだが、通常は学歴の代わりとなる強力なポートフォリオやオープンソースへの貢献が必要になる。

ソフトウェアエンジニアリングはAIによって脅かされているのか?

一部はすでにそうなっている。現代のコードエディタに組み込まれたツールは、定型コードや初稿のテスト、言語間の変換など、日常的なコードの大きな部分を、日常的に使うエンジニアのために書くようになっている。はるかに自動化が難しいのは、何を、なぜ作るのか、そして実際のユーザーや障害にさらされても生き延びるようにシステムをどう形作るかを決めることである。

ソフトウェアエンジニアの収入はどれくらいか?

国や企業によって大きく異なる。米国では中央値が年間約13万3000ドル、ドイツではおよそ6万9000ユーロ、業界が最も多くの人を雇用しているインドでは全国平均が90万ルピー前後になる。大手テクノロジー企業のシニアやスタッフエンジニアは、株式報酬を含めると全国中央値の数倍を稼ぐこともある。

ソフトウェアエンジニアとプログラマー、開発者の違いは何か?

実際にはほとんど違いがない。肩書きは重複しており、企業によって使い方も一貫していない。「プログラマー」は最も古い用語でコードを書くことを重視し、「開発者」はウェブやプロダクト企業でよく使われ、「ソフトウェアエンジニア」はより古いエンジニアリング分野から借りた規律あるプロセスやテスト、設計の考え方をソフトウェア構築に適用するという意味合いを持つ。求人票でこれらが一貫して区別されることはほとんどない。

採用にコーディング面接は本当に必要なのか?

多くの大手テクノロジー企業では、そうである。共有ドキュメントやホワイトボード上でアルゴリズム問題を解くライブまたは持ち帰り形式の技術面接が標準的な選考手法であり、より上級の職種にはシステム設計面接も加わる。小規模企業やスタートアップでは、有償の試用プロジェクトやポートフォリオレビュー、過去の実績についての会話で代替する可能性が高い。

このセクションから始める - 実務とノウハウ

比較ラボを開く

このページを共有

8時間ずっとタイピングし続けているエンジニアというイメージはおおむね誤りだ。他人のコードを読むこと、原因不明の障害について考えること、技術的なトレードオフをエンジニアでない人に説明することは、新しいコードを書くのと同じくらい──最初の数年を過ぎた人にとってはそれ以上に──仕事の大きな部分を占める。

この職業内で受け継がれる技は、どの言語を学ぶべきかというより、思考の習慣にかかわる。当てずっぽうではなく体系的にバグを探す方法、動いているコードにいつ手を出さずにおくべきか、そしてコードを削除することがその週で最も価値ある仕事だったこともあるという感覚である。

仕事が求める力

889074807083
問題の分解
88
デバッグ
90
システム設計
74
コミュニケーションと協働
80
テストとコード品質
70
継続的な学習
83

問題の分解

曖昧で大きな依頼を、独立して構築・テスト可能な小さな断片に分割すること──大きな仕事で行き詰まるエンジニアと生産的なエンジニアを最も分けるスキル。

デバッグ

当てずっぽうで物をいじって偶然動くようにするのではなく、システムがどこで、なぜ誤動作しているかを体系的に絞り込むこと。

システム設計

初日に動くだけでなく、何年にもわたって安全に変更し続けられるよう、サービスやデータ、チームをどう分割すべきかを選ぶこと。

コミュニケーションと協働

技術的なトレードオフを非エンジニアに説明し、レビュアー向けに変更内容を明確に書き記し、スコープを交渉すること──プロのコードは書かれるよりもはるかに多く読まれ議論される。

テストとコード品質

ユーザーが気づく前に壊れた変更を検知するチェックを書き、次に触る人(多くの場合は数か月後の同じエンジニア自身)が安全に修正できる程度にコードベースを読みやすく保つこと。

継続的な学習

言語やフレームワーク、そして今やAIツールも数年ごとに入れ替わる。最初の仕事を終えた後に意図的な学習をやめてしまうエンジニアはすぐに頭打ちになる。

一日の風景

受信箱、スタンドアップ、トリアージ集中作業:コードを書く昼食レビュー、ペアプログラミング、会議デバッグ、デプロイ、締めくくり勤務時間外(おおむね) 036912151821 24h
  1. 7–9 受信箱、スタンドアップ、トリアージ

    夜間のアラートやメッセージに目を通し、その後チームが取り組んでいることと障害になっていることを話す短いスタンドアップ会議を行う。

  2. 9–12 集中作業:コードを書く

    一日の中で最も保護されたブロックで、理想的には通知を切り、持続的な集中を要する機能や修正の実装に費やす。

  3. 12–13 昼食

    本物の休憩。多くのエンジニアが、多忙な時期に最初に失われるのがこの時間であり、失って最初に後悔するものだと語る。

  4. 13–16 レビュー、ペアプログラミング、会議

    同僚のプルリクエストを読み、難しい問題をペアで解決し、午後に集中しがちな設計や計画の会議に出席する。

  5. 16–19 デバッグ、デプロイ、締めくくり

    その日の変更を仕上げて出荷し、安全に展開されるのを見守り、明日のため、あるいは夜間のオンコール担当者のためにメモを残す。

  6. 19–7 勤務時間外(おおむね)

    私的な時間と睡眠──ただしオンコールの週は別で、電話のアラートが午前3時を予定外の本番障害対応に変えることもある。

ノウハウ

現場で実際に伝えられる技術知 — モチベーション文句ではない。

01

推測せず二分探索する

動いていたバージョンと壊れたバージョンの間のどこかでバグが現れた場合、差分を目で追うのではなく履歴を二分探索する──中間点を確認し、一つの変更だけが残るまで繰り返す。

標準的な二分探索デバッグ手法。Gitのbisectコマンドで自動化される
02

コードを読む前に失敗を読む

完全なエラーメッセージ、スタックトレース、周辺のログ行には通常すでに答えが含まれている。すぐにソースに飛びついて推測するのは、コンピューターが無料でくれた唯一の証拠を無駄にすることになる。

ブライアン・カーニハンとロブ・パイク著『プログラミング作法』(1999年)で繰り返し述べられている
03

変更を簡単にしてから、簡単な変更をする

機能の追加が難しい場合、それは通常、コードがその機能に合わない形になっているサインだ。まず挙動を変えずにリファクタリングし、その機能が小さく明白な差分になるようにしてから、その差分を実装する。

ケント・ベック
04

チェスタトンの柵

理解していないコードや設定値、チェックを削除または簡素化する前に、なぜそれが置かれたのかを調べる。まさにそのおかげで何年も起きていない障害を静かに防いでいるのかもしれない。

G・K・チェスタトン『The Thing』(1929年)、エンジニアリングの民間伝承として採用された
05

コードを削除することは前進である

もはや存在しないコードにはバグがなく、次に読む人を混乱させず、更新の必要もない。使われなくなった経路や機能を削除することは、機能を出荷することと同じように称賛されるべきだ。

ジェフ・アトウッド、Coding Horror、2007年(「最良のコードはコードが無いことだ」)に呼応
06

ラバーダック・デバッグ

助けを求める前に、同僚や無生物にさえ、問題を一行ずつ声に出して説明する。それを正確に言語化する行為そのものが、誰かが答える前にバグを明らかにすることが多い。

アンドリュー・ハントとデビッド・トーマス著『達人プログラマー』(1999年)

仕事の道具

コードエディタ/IDE

Visual Studio CodeとJetBrainsのIDEが主流であり、両方とも今ではAI支援の自動補完やチャットをエディタに直接組み込んでいる。

Git

トーバルズが2005年に作った、業界のほぼ全体が標準として採用したバージョン管理システム。これなしで出荷されるものはほとんどない。

課題管理ツール

Jira、Linear、GitHub Issuesは、バグや機能のバックログを、チームが週や四半期単位で計画できるものに変える。

CI/CDパイプライン

変更のたびにコードをビルド、テスト、デプロイする自動化システムで、リリースを緊張を伴う手作業のイベントから日常的なものへと変える。

AIコーディングアシスタント

GitHub Copilotのようなツールは、今やエンジニアが受け入れるコード行の大きな割合を書いており、日々の仕事をタイピングよりもレビューと方向づけへとシフトさせている。

失敗する理由

履歴書駆動開発

問題に合っているからではなく履歴書に映えるからという理由で流行の言語やフレームワーク、アーキテクチャを選ぶこと。次のチームが保守しなければならない複雑さを残していく。

エラーメッセージを読まない

プログラムが実際に報告している内容を読む代わりに、記憶にある修正パターンに当てはめてしまうこと。これが誤った原因を追いかけて何時間も無駄にすることにつながりうる。

ビッグバン書き直し

動いているシステムを捨てて『きちんと』ゼロから作り直すことは、悪名高いほどリスクの高い動きである。1990年代後半のネットスケープによるブラウザの全面書き直しは、それが会社の市場での主導権を失わせたと広く引用される事例である。

似ている職業

分野だけでなく、6つのスコアが近い職業です。

さらに探す

さらに探す

工学・技術のほかの職業

🤖

AI研究者

機械知能を支えるアルゴリズムを設計・検証する仕事。今やその研究プロセス自体の自動化を競う分野になりつつある。

AI耐性 50
🛰️

航空宇宙エンジニア

地上を離れる航空機・ロケット・宇宙船を設計・解析・認証する仕事で、推測の余地を残さない安全マージンを守り続ける。

AI耐性 74
🌉

土木技術者

川と岩と重力を橋・道路・清潔な水に変える職業――イムホテプ以来、文明を静かに支え続ける仕事。

AI耐性 72
🔌

半導体エンジニア

自動車のブレーキから核ミサイルの誘導システムまで、あらゆるコンピュータや携帯電話の中にあるトランジスタを設計・製造する。地球上でごく一部の工場しか動かせないほど精密な機械を使う仕事だ。

AI耐性 60
🦾

ロボット技術者

感知し、判断し、物理世界で行動する機械を設計する仕事。真の難問は知能ではなく、世界そのものだった。

AI耐性 65
🔐

?????????????????

デジタル攻撃を発見、防止し、対応することで、システム、データ、人々を保護します。

AI耐性 63
📦

MLOpsエンジニア

本番環境で機械学習モデルを訓練・配備・監視・ガバナンスするためのシステムを構築する仕事。

AI耐性 54
🌬️

再生可能エネルギーエンジニア

再生可能な資源を信頼できる電力に変える、風力、太陽光、蓄電、送電網のシステムを設計・構築・改善する。

AI耐性 72