大学院では理論天体物理を専攻し、パルサー(高速で自転する中性子星)を研究していました。今はSEとして10年目、AWSを使ったシステム開発の現場にいます。

「物理をやっていた人がなぜSEに?」とよく聞かれます。「研究経験って仕事で役に立つの?」とも聞かれます。結論から言うと、役立つ部分ははっきりあります。ただ、そのままでは通用しない部分もあります。

この記事では、両方を現場目線で正直に書きます。進路に迷っている理系の院生や、研究からエンジニアへの転身を考えている人の参考になればうれしいです。

大学院では何をしていたか

修士課程で取り組んだのは、パルサーの理論研究です。観測データそのものではなく、物理モデルを立てて計算し、観測と比べられる予測を出す側の研究でした。

道具の中心はモンテカルロシミュレーションです。乱数を使って膨大な数の試行を計算機で回し、結果を統計的に解析します。

テーマは、パルサーが放つ電波の統計的な性質です。理論で予想される振る舞いと観測が合わない点があり、その原因を計算で探りました。計算にはPythonとFortranを使っていました。

今振り返ると、毎日やっていたのは「物理」というより「モデルを作り、コードを書き、結果を疑って検証する」ことでした。これが、後で効いてきます。

なぜ研究者ではなくSEを選んだか

博士課程に進んで研究者を目指す道もありました。それでも修士で就職し、SEを選びました。

きっかけは研究の中でHPC(高性能計算機)に触れたことです。計算機の力で研究が大きく進むのを見て、こうした仕組みを作る側に回り、多くの人の役に立ちたいと考えるようになりました。

就職先には大企業を選びました。社会への影響が大きいシステムに関われば、それだけ多くの人に影響を与えられると考えたからです。

入社時点で、業務システムやクラウドの知識はほぼゼロでした。最初は、分からない用語が飛び交う会話についていくのに必死でした。分からない言葉を一つずつ調べて、意味を押さえるところから始めました。

物理の経験が現場で役立ったこと

天体物理の知識そのものを仕事で使う場面は、ほぼありません。役立っているのは、研究の中で身についた考え方です。

  1. 複雑なものをモデルに落とす力:物理では、本質に関係ない要素を削って単純化します。システム設計でも、要件の中から本当に効く制約を見抜く場面で同じ頭を使います。
  2. 桁で考える癖:天文学では「だいたい何桁か」をまず押さえます。性能見積もりやコスト試算で「この構成で1日何件さばけるか」をざっくり出せるのは、この癖のおかげです。
  3. 結果を疑う習慣:シミュレーションが期待どおりの結果を出したときほど、バグを疑いました。テストや障害調査で「たまたま動いているだけでは?」と考えられるのは強みです。
  4. 英語の一次情報を読むことへの抵抗のなさ:論文を読んでいた経験から、英語の公式ドキュメントを直接読むことに抵抗がありません。クラウドや生成AIのように変化が速い分野では、これが大きな差になります。

振り返ると、研究でやっていたのは「事象を観測し、原因を分析し、解釈し、検証して、特定する」という一連の流れでした。私の研究も、「理論どおりのはず」という前提を疑うところから始まっています。

現場の障害調査も、まったく同じ流れで進みます。ログやメトリクスで何が起きたかを観測し、原因の仮説を立て、検証して特定する。研究の型が、そのまま仕事の型になっています。

苦労したこと、役立たなかったこと

逆に、研究のやり方がそのままでは通用しなかった場面もあります。

  • 自分が読めればいいコードの書き方:研究用のコードは自分一人が読めれば十分でした。チーム開発では、他人が読んで直せるコードと設計書が求められます。
  • 正解を突き詰めたくなる癖:研究では納得いくまで掘り下げるのが美徳です。仕事では、期限と予算の中で「十分に良い」ところで止める判断が必要でした。
  • 調整と合意形成:研究は基本的に自分と指導教員の間で完結していました。顧客や他チームと仕様を詰めていく仕事は、最初は大の苦手でした。

一番苦労したのは、言葉で論理を組み立てることでした。研究では、物理現象を数式で語ることができました。数式は言葉を使わない論理なので、正しければそれで通じます。

ところが社会に出ると、仕様の説明も報告も提案も、すべて言葉で筋道を立てて伝える必要があります。数式での論理には慣れていても、言葉での論理が足りていない。それに気づいてから、意識して鍛えるようになりました。

理系の院生・研究者志望だった人へ

専門分野がITと無関係でも、SEになるのは十分に現実的な選択です。研究で鍛えた「モデル化する」「検証する」「一次情報を読む」力は、そのまま武器になります。

就活や転職では、研究内容そのものより、次の3点を具体的に話せるかが大事だと思います。

  • どんな問題を、どう単純化して解いたか
  • 結果をどうやって検証したか
  • コードを書いた経験(言語、規模、何を計算したか)

一方で、チーム開発と「ほどほどで止める判断」は、入社後に意識して身につける必要があります。研究の癖が強みにも弱みにもなる、と知っておくだけで、最初の数年はかなり楽になるはずです。

このサイトでは、現役SEの目線でITの学び方とキャリアを書いていきます。