客先常駐SEからクラウドエンジニアを目指すまでの技術選定の変遷

はじめに

この記事は技術的なハウツーではなく、自分がどういう経緯でクラウドエンジニアを目指すことになったかの記録です。

自分向けの備忘録も兼ねて「どういう判断で何を選んだか」を書いておきたいと思います。

Phase 0：職業訓練校（2020年9月〜2021年3月）

未経験からのスタートです。ネットワーク・ハードウェア・プログラミングの基礎を半年間学びました。

このフェーズで一番得たのは技術知識よりも「OSI参照モデルで問題を分解する」という思考習慣でした。障害が起きたときにL1からL7のどこで詰まっているかを順番に切り分けていく考え方は、後の業務でもそのまま使えました。

L1（物理）→ L2（データリンク）→ L3（ネットワーク）→ ...
          ↑
   「ここまでは疎通している」と確認しながら上に登る

闇雲なプログラミング言語学習ではなく、体系的な基礎知識の理解を優先しました。 CCNAより基本情報技術者試験の勉強を優先したのも、この思考習慣によるものです。

Phase 1：客先常駐SE（2021年4月〜2022年5月）

初めての実務です。私立高校常駐SEとして、ヘルプデスクのエスカレーション対応から実務サブリーダー、Web/Mailサーバー移行やシステム開発まで幅広く経験しました。

Webサーバー・メールサーバーの移行

老朽化したレンタルサーバーで動くWebサイト/Mailシステムを別のレンタルサーバーに移行するプロジェクトを担当しました。移行先の選定で最初に「AWSではどうか」と調べましたが、このケースでは見送りました。

理由はシンプルで、移行後に自分がいなくなっても担当者が運用できるかという点を重視したためです。AWSはIAM・VPC・EC2など管理すべき概念が多く、引き継ぎ先のハードルが高すぎると判断しました。引き継ぎ先のレンタルサーバーは管理画面が日本語で完結しており、WordPressに特化。メール・SSLも同一パネルで扱えることが決め手でした。

「最先端かどうか」より「引き継ぎ後に誰が運用するか」が技術選定の第一条件だと学んだのはこの経験からです。

IBM Watson × Slackのヘルプデスクbot開発

もう一つの大きな仕事が、IBM Watson AssistantとSlack APIを組み合わせたヘルプデスクbotの開発でした。3人チームで設計・開発・テスト・リリースまでを担当しました。

当時Watsonを選んだのは、既存のシステム契約との整合性と日本語FAQの学習精度が理由です。今であればClaudeやGPTとFunction Callingで同じことがずっと簡単にできますが、Watsonは「その時点での最適解」でした。

このプロジェクトは地元の経済誌にDX事例として掲載されました。

APIの結合設計（WatsonとSlackが両方同時に落ちることを考えた設計）を初めて意識したのもこのプロジェクトでした。

Phase 2：現在（2022年6月〜）

会社を離れた後も、個人事業として活動しながら、独学を続けています。

取得した資格

英語でのIT学習・受験は、グローバルな技術情報へのアクセスという実用的な理由から始めました。

TOEIC 890（英語ドキュメントを読むのに不自由しないレベルの確認として）
CompTIA Linux+（英語受験）
CCNA（英語受験）
AWS SAA（英語受験）

英語受験にこだわったのは「どうせ勉強するなら一次情報（英語ドキュメント・英語フォーラム）を直接読める状態にしたい」という考えからです。

このポートフォリオの開発

独学と並行して、Cloudflare PagesとHonoでこのサイトを作りました。

Next.jsも検討しましたが、静的コンテンツ中心のポートフォリオに複雑な状態管理やインタラクションも不要だったため、React構成はオーバースペックと判断しました。HonoはExpressライクな書き方でCloudflare Workersに乗るため、学習コストと機能のバランスが自分のスコープに合っていました。

// Honoのルーティング: シンプルに書ける
const app = new Hono()
app.get('/api/health', (c) => c.json({ status: 'ok' }))
export default app

AWSの実務経験について

AWS SAAを取得しており、基礎的なアーキテクチャ理解があります。実務ではS3 + CloudFront構成の設計・構築に携わり静的配信基盤の運用経験があります。複雑なネットワーク設計の経験は現時点ではありませんが、基本設計の理解はあり、ドキュメントベースでのキャッチアップが可能です。 Terraformについても基本操作および既存コードの修正経験があり、IaCの運用フローは理解しています。

技術選定について自分が意識していること

Phase 1の客先常駐SE経験から一貫して持っている判断軸があります。

「誰が、どのくらいのコストで運用し続けられるか」

自分がいる間だけ動く構成より、自分がいなくなっても無理なく続けられる構成のほうが価値があると思っています。この視点は、シンプルな構成を選ぶことへの動機にもなっています。