インフラエンジニアを目指す君へ｜27年経験者が語る“本質”とアプリを学び直した理由
ktgs
インフラエンジニア歴27年。サーバー、ネットワーク、ストレージ、セキュリティ、クラウド、監視、障害対応……本当に色々なことをしてきました。
その中で、これからインフラエンジニアを目指すあなたに、どうしても伝えたいことがあります。
「資格を取るだけでは、この仕事の本質には届かない」
LPIC、CCNA、クラウド資格。どれも価値がありますし、基礎力を証明できます。でも、それはあくまで“スタートライン”です。
ここから先は、現場でしか身につからない世界があります。
インフラエンジニアの本質はサービスの「当たり前」を支える仕事
まず大前提として、インフラエンジニアの仕事は「当たり前を成立させること」にあります。
サーバーが毎日動いていること
ネットワークが安定していること
データが壊れないこと
セキュリティが守られていること
障害があっても復旧できること
ユーザーが安心して使えること
これらはすべて「当たり前」ではありません。インフラエンジニアの判断・設計・運用が支えています。
言い換えるなら、
インフラは、「問題が起きない世界」を生み出す仕事。
派手ではありません。でも、欠かせない仕事です。
「資格＝一人前」ではない理由
インフラ業界には、
「LPICやCCNAを取れば一人前」
「クラウドの資格があれば現場でも通用する」
といった空気があります。
正直に言います。
資格は「入り口」であって、「成果」ではありません。
資格で学べるのは「知識の断片」にすぎません。現場ではもっと複雑で、もっと泥臭く、もっと深いスキルが求められます。
現場が本当に求めているのは「選定力」
インフラエンジニアは、毎日「選択」を迫られます。
OSは何を選ぶ？（RHEL/AlmaLinux／Ubuntu／Windowsなど）
Webサーバーは？（Nginx／Apacheなど）
DBは？（OracleMy／SQL／PostgreSQL／Auroraなど）
監視は？（Zabbix／Prometheus／CloudWatchなど）
バックアップは？（Acronis／Veeam／ddなど）
クラウドかオンプレか？
冗長化をどこまでする？
そして、これらの選択には常に責任が付きまといます。
コスト
安定性
運用性
未来の拡張性
障害時の復旧のしやすさ
チームのスキル
これらを総合的に判断し、「現場に最適な組み合わせ」を提案できる人こそ一人前です。
これは資格では身につきません。経験と知識と責任感で磨かれるスキルです。
インフラ設計は「安定性 × コスト × 運用性」の三角バランス
インフラは「理想」だけを追求すると、とんでもない金額になります。
逆に「コスト」だけを優先しすぎると、障害に弱くなります。
そして「運用性」を軽視すると、現場が疲弊し、いずれ回らなくなります。
インフラの設計は、この3つのバランスがすべてです。
安定性：止まらないこと
コスト：お金という現実
運用性：人が回せること
この3つを全部見るのは、インフラエンジニアの役割です。
アプリエンジニアとは敵ではなく、「視点が違うだけ」
アプリ側とインフラ側のすれ違いは、昔からよくあります。
インフラ側から
このアプリどれくらいのスペック必要？
アプリ側から
うーん、そんなに重くはないと思います…
これは、別にどちらかが悪いわけではありません。
役割が違うから、見る景色が違うだけです。
アプリエンジニアの視点
仕様通りに動くこと
バグがないこと
ユーザー体験をよくすること
ビジネス要件を実装すること
アプリは「実現する技術」が中心です。
インフラエンジニアの視点
どれだけ使われても落ちないこと
障害が起きても復旧できること
セキュリティが守られていること
運用が持続できること
予算に収まること
インフラは「支える技術」が中心です。
どちらも大切です。どちらが偉い・すごいという話ではなく、役割が違うだけです。
だから私は「アプリも学び直した」
実は、私自身も最初はインフラしか知りませんでした。
ですが、あるときこう思ったのです。
「アプリの世界を知らないままでは、最高のインフラは作れない」
そこから私はアプリを学び直しました。
PythonやNode.jsによるバックエンド開発
データベース設計とクエリのチューニング
API設計
フロントエンド（Next.jsなど）
認証・認可（Cognitoなど）
セッション管理
UI/UXの基礎
外部サービスとの連携
コードを書くときも、「なんとなく自己流」ではなく、言語の標準的なスタイルガイドをきちんと読むようにしました。
Pythonなら
PEP 8を読み、コーディング規約に沿って書くTypeScriptなら公式のスタイルガイドや、ESLint＋TypeScript向けルールを取り入れて書く
インフラおじさん（27年目）でも、こうしたコーディング規約を学び直しながらアプリを書き続けることで、
最終的には、自社サービス「ボイテキ！」をリリースできるところまで到達しました。
インフラだけではなく、アプリ側の都合や実装のクセも自分で体験することで、インフラ設計の解像度も一段上がったと感じています。
これは、若いエンジニアにこそ伝えたいことです。
インフラとアプリの垣根は、学べば越えられる。
どちらも理解して初めて、サービスの「全体像」が見えるようになる。
デファクトスタンダードを学ぶことが、プロへの近道
意外と盲点なのが、標準的な考え方（デファクトスタンダード）です。
例えば
IPAの要件定義ガイドライン
非機能要件の整理の仕方
フェイルオーバー設計の基本
SLA / SLOの考え方
運用設計・障害対応フロー
監査対応やセキュリティ標準
インフラ構成の基本パターン
各言語・フレームワークのコーディング規約（PEP 8 や TypeScriptのガイドラインなど）
こういったものを知らないと、設計書や提案書が一気に「なんちゃって設計」になってしまいます。
技術そのものは後からでもキャッチアップできます。しかし、「標準的な考え方」を知らないと、いつまでも属人的で再現性のない設計から抜け出せません。
インフラエンジニアとして長くやっていくなら、こうしたデファクトスタンダードを早いうちに押さえておくことを強くおすすめします。
★まとめ★インフラエンジニアの価値は「選定力・判断力・責任感」に宿る
インフラエンジニアは地味です。表には出ませんし、派手な機能を披露することもあまりありません。
でも、すべてのサービスの「命」を握っているのはインフラです。
資格は入り口
経験は財産
障害は最高の先生
選定力は武器
責任感は信用
そして、
インフラは「未来を守る仕事」です。
この世界に興味があるなら、ぜひ飛び込んでみてください。27年やっても、まだ学び続けるほど奥深くて面白い世界です。
これからインフラエンジニアを目指すあなたへ。
資格だけでも、技術だけでも、経験だけでも、人は育ちません。
インフラは「判断力」と「責任感」と「学び続ける心」で強くなります。
そして、アプリも覚えればもっと強くなります。サービス全体が見えるエンジニアになれます。
ようこそ、このワクワクする世界へ。
インフラおじさん（27年目）より。
Related