こんにちは、ITインフラエンジニアです。
20年以上ITインフラの現場で働いてきた私が、48歳でHPC（高性能計算）業界に転職して5か月が経ちました。
「Linuxの知見があること」という求人に惹かれて入社したものの、最初の数か月は上長との認識のズレに消耗し続けました。「失格です」と言われたこともあります。
でも今は、上長から「ありがとうございました」という言葉をもらえるようになりました。
この記事は、その顛末の記録です。
1. 最初のミッション：様々な環境でPBSを動かす
転職してまず与えられたミッションは、AlmaLinuxやRockyLinux、UbuntuといったLinuxの様々な環境でPBS Professionalを動かすことでした。
PBS Professional（以下PBS）とは、大学や研究機関などで使われるジョブスケジューラと呼ばれる商用ソフトウェアです。
ジョブスケジューラとは、複数の計算処理（ジョブ）を順番に管理して、多数のサーバーに効率よく割り振る「交通整理係」のようなものです。研究者が「このシミュレーションを計算してほしい」と依頼すると、PBSが空いているサーバーを見つけて自動で計算を実行してくれます。スパコン（スーパーコンピュータ）や研究機関のHPC環境では欠かせない存在です。
Podman上でのPBS、最小構成でのインストール、LVM上でのPBS……依存関係エラーと格闘しながら、様々な環境でPBSを動かし続けました。これが私の本来の仕事です。
その傍らで与えられた追加のミッションが、「各社のLinux脆弱性情報が更新されたら知らせること」でした。これが、失敗の連鎖の始まりでした。
2. 最初の失敗：脆弱性情報の報告が遅れた
私はPBSの担当として、RHELのセキュリティページを監視しながら、PBSのマニュアルと照らし合わせて影響を確認してから報告しようと考えていました。
結果、報告が遅れて叱られました。
上長が求めていたのは「RHELのページが更新されました」という一言の速報でした。私がやっていたのはPBSへの影響調査込みの詳細レポートでした。
どちらが「より良い仕事」かは明白です。でも、求められていたのは速さとシンプルさだったのです。
その後、この脆弱性情報の収集業務自体から外されました。理由の説明はありませんでした。
今思えば、最初のミッションは「技術的な成果を求めていたのではなく、指示通りに動くかを見るテストだったのかもしれない」と感じています。そのテストを、私は深掘りしすぎて失敗したのです。
3. 「失格です」と言われた日
その後、カーネル脆弱性（Copy Fail / Dirty Fragなど）への対応を提案した際、私は以下をまとめた詳細資料を作成して提案しました。
- ホストベース認証（HostbasedAuthentication）の無効化の必要性
- SELinux / AppArmorによる多層防御
- PBSへの影響確認のための検証項目
ここで少し技術的な説明をしておきます。
ホストベース認証とは、マシン（ホスト）そのものを丸ごと信用する古い仕組みです。「このマシンから来た通信は全部OK」と玄関ドアを開け放つようなイメージで、現代のセキュリティでは原則「非推奨」とされています。PBSの稼働には一切必要ありません。
一方、公開鍵認証は家の鍵と鍵穴のペアで「この人が本人かどうか」を確認する方式で、PBSが計算ノード間でパスワードなしに通信するために必須なのはこちらです。つまり、ホストベース認証を無効化してもPBSへの影響はゼロのはずでした。
さらに、Wizというクラウドセキュリティ企業もこのタイミングでSELinux / AppArmorの有効化を推奨していました。SELinux/AppArmor は「番犬がすべての部屋の前に立って、誰がどこに入れるかを強制管理する」仕組みです。たとえrootを奪われても「このプロセスはここにしかアクセスできない」というルールで被害を封じ込めます。これらを組み合わせることで多層防御（Defense in Depth）として機能します。
しかし、返ってきた言葉は「論点がずれている」「説明はいいから何をするかだけ言え」、そして「インフラエンジニアとして失格です」でした。
当時は正直、かなり消耗しました。
4. 繰り返された同じすれ違い
冷静に振り返ると、同じパターンが繰り返されていました。
「検証項目を作って報告する」と伝えたにもかかわらず、私は検証項目だけでなく検証結果までセットにして提出してしまいました。上長からすると「承認もしていないのに、なぜもう検証まで終わっているのか」という話です。
- 脆弱性の速報を求められた→影響調査まで終わらせてから報告した
- 検証項目を求められた→検証結果まで出した
- 結論を求められた→根拠と手順の詳細資料まで作った
全部「より良い仕事をしよう」という善意からの行動でした。でも相手には「勝手に先に進める人」に映っていたのかもしれません。
5. 上長が本当に求めていたものは何か
しばらくして、上長との認識のズレが少しずつ見えてきました。上長は一貫して「PBSが売れるか・動くか」だけを見ていたのです。この会社はPBSの代理店として商売をしています。つまり：
- セキュリティ対策の必要性→関心なし（売上に直結しない）
- 多層防御→関心なし（売上に直結しない）
- 脆弱性対策後にPBSが動くか→関心あり（売上に直結する）
上長が私に期待していたのは、「PBSをどんなLinux環境でも動かし続けられる人」であり、セキュリティの専門家ではなかったのです。
「説明はいいから何をするかだけ言え」は、内容の否定ではなくコミュニケーションスタイルへの要望でした。私が作っていた詳細資料は捨てるものでは全くなかった。ただ、渡す相手と順番が違っていただけでした。
6. 気づいた「仕事の粒度」のズレ
今回の件を通じて、相手が求めていた情報の粒度が見えてきました。
意思決定者（上長）が求めていたもの
- 「〇〇を実施します。PBSへの影響はありません。」
- A4・1枚以内、結論だけ
顧客の現場エンジニアが必要とするもの
- なぜその対策が必要か
- PBSへの影響がない技術的な根拠
- 具体的な検証手順
上長には結論だけ先に出す。技術的な根拠は聞かれたとき、または顧客の現場エンジニアが出てきたときに渡す。それだけでよかったのです。
これはどちらが正しいという話ではなく、業界・現場によって「良い仕事」の定義が違うという話です。
7. リモートワークという難しさ
この職場は完全リモートで、上長とはGoogle Meetでしか話したことがありません。オフィスに行くのは荷物の受け取りのときだけです。
対面であれば「この説明、長すぎて飽きてきたな」とか「この話には食いついてくれているな」という非言語情報が取れます。でもGoogle Meetだと画面越しに限られた情報しかない。
「上長が何を求めているか読めなかった」のは、私の読解力の問題だけではなく、リモートという環境のせいでもあったのかもしれません。手探りの時間が長くなるのは、ある意味リモートワークの宿命です。
8. 翌日：さっそく同じ失敗をした話
学びを得た翌日、上長からPBS Professionalのバージョンアップにおける機能追加・変更点をリスト化してほしいという指示が届きました。指示の内容はこうでした。
- AIを使って作成する
- ソースはPBSの管理ガイドとリリースノートのみ
- インターネットの情報は不要
- AIが作成した回答はマニュアルで自分で確認する
- VMでの検証は不要
昨日学んだばかりなのに、私はさっそくやらかしました。提出した成果物に抜け漏れがあり、上長から指摘されました。「私がチェックすると甘くなるので、他の社員にチェックしてほしい」と言いましたが、「他の仕事をしてもらっているからやめてくれ」と言われました。
…「完璧な成果物を、一人で、効率よく出せ」という無茶振りです（笑）。
私はこの問題をITインフラ屋らしく解決しました。サクラエディタで正規表現を使い、PDFからテキストを抽出してチェックシートを作ったのです。正規表現というのは、テキストの中から特定のパターンを自動で見つけ出すルールのことです。料理で言えば「大量の食材の中から調味料だけを自動で選り分けるフィルター」のようなもの。これで抜け漏れをゼロにする仕組みを自分で作りました。
ただ…上長への報告でまたやらかしました。「サクラエディタで正規表現を使って処理しました」と報告してしまったのです。昨日学んだばかりなのに（笑）。上長が聞きたかったのは「抜け漏れの問題を解決しました」の一言だけでした。
学んだ翌日に同じ失敗をする。これが人間というものです（笑）。
9. AIの使い分けで突破口が開いた
抜け漏れの問題を解決するもう一つのきっかけは、NotebookLMへの指示の改善でした。
最初の指示：「2025.2.0から2025.2.1への変更点・改善点をリスト化して」
→バグ修正1件・機能変更1件が漏れた
改善後の指示（Geminiに考えてもらったプロンプト）：「2025.2.0から2025.2.1への変更点・改善点を、要約したり省略したりせず、すべての項目を1つ残らず日本語の箇条書きにしてください」
→漏れ1件だけ
AIへの指示も「粒度」が大事だったわけです。この経験を通じて、道具ごとの使い分けが見えてきました。
| 道具 | 得意なこと |
|---|---|
| NotebookLM | ソースを限定して正確に処理する |
| Gemini | 指示の言葉やプロンプトを考える |
| Claude | 技術的な整合性チェックや議論の整理 |
| サクラエディタ＋正規表現 | 機械的な抜け漏れチェック |
AIも道具ごとに使い分ける。まさにITインフラ屋らしい解決策です。
10. 案件ごとのモードを使い分ける
一連の経験を通じて、上長が案件ごとに求めているモードが見えてきました。
| 案件 | 重視するもの | 理由 |
|---|---|---|
| 脆弱性情報の速報 | スピード | まず把握することが優先 |
| PBSが動くかの検証 | 正確さ | ビジネスに直結するため |
| 機能リストの作成 | スピード×正確さの両立 | AIで速く作り、マニュアルで裏取り |
「スピード重視か正確さ重視か」という二択ではなく、案件の性質によって使い分けているのです。私がこれまで間違えていたのは、すべての案件に「正確さ最優先・深掘り必須」というITインフラ屋のモードを適用していたことでした。
11. 実は認められていた
ある日、同僚から教えてもらいました。上長が別の社員に「あの人は何度もPBSを動かしている」と話していたというのです。
本来のミッションであるPBSの検証を地道にこなしてきた実績を、上長はちゃんと見ていたのです。
面と向かっては「失格」と言い、裏では「何度もPBSを動かしている」と話している。「できて当然」スタンスの照れ屋タイプだったのかもしれません（笑）。
まとめ：「失格」から「ありがとうございました」まで
NotebookLMへの指示を改善し、サクラエディタと正規表現でチェックシートを作り、抜け漏れゼロを確認した上でPBS Professionalの変更点リストを提出しました。
上長から返ってきた言葉は：
「ありがとうございました。確認します。」
「失格」と言われてから5か月。面と向かっては褒めない上長から、初めて「ありがとう」をもらいました。
今回の経験を通じて学んだことをまとめます。
- 技術的な判断は間違っていなかった。伝え方が違っただけ
- 意思決定者には結論だけ。技術的な詳細は求められたときに出す
- 承認のステップを守る。先回りしすぎない
- 案件ごとにモードを切り替える。すべてに深掘りは不要
- AIも道具ごとに使い分ける
- リモートワークでは手探りの時間が長くなる。それは自分だけのせいではない
48歳で転職して、リモートで、手探りで、それでも前に進んでいる。
同じように異業種・異文化へ転職したエンジニアの皆さんの参考になれば幸いです。
