これまでのIT技術選定の変遷

はじめに

この記事は技術的なハウツーではなく、個人的な記録です。自分向けの備忘録も兼ねて「どういう判断で何を選んだか」を書いておきたいと思います。

Phase 0：技術専門校

未経験からのスタートです。これからはITだ！と思い立ち、しかし完全未経験で就職する自信はなかったので、まずは学校に通うことにしました。

まずOSI参照モデルを学び、ネットワークやデータベースと、順を追って情報技術を体系的に学んでいくやり方で授業は進められました。

何らかのバグや障害に詰まった時に、基盤知識をもとに調査し、腰を据えてテキストを読み、どこで詰まっているかを順番に切り分けていく考え方は、後の業務でもそのまま使えました。後にCCNAより基本情報技術者試験の勉強を優先したのも、こうした思考習慣によるものです。

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

Phase 1：客先常駐SE

初めての実務です。客先常駐SEとして、客先システムの運用から障害のエスカレーション対応、実務サブリーダー的な立場やWeb/Mailサーバー移行、AIシステム開発まで幅広く経験しました。

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

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

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

「最先端かどうか」より「引き継ぎ後に誰が運用するか」を選定の前提条件としました。

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

もう一つの大きな仕事が、IBM Watson AssistantとSlack APIを組み合わせたヘルプデスクbotの開発でした。2人チームで設計・開発・テスト・リリースまでを担当しました。小さな会社ですので、上流工程に関わることもありました。

今であればClaudeやGPTとFunction Callingで似たようなことがずっと簡単にできますが、当時はWatsonが最適解でした。前述の客先案件と並行して進める必要があったため、色々とハードな状況でしたが、なんとか遂行することができました。このプロジェクトは地元の経済誌にDX事例として掲載されました。

Phase 2：現在

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

取得した資格

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

CCNA（英語受験）
CompTIA Linux+（英語受験）
AWS SAA（英語受験）
TOEIC 890

英語での受験にこだわったのは「どうせ勉強するなら一次情報を直接読める状態にしたい」という考えからです。エラーメッセージやドキュメント、英語フォーラムの調査など、至るところで苦しい思いをしており、英語を習得したい思いは強くありました。現在も個人事業と並行し英語塾講師を続けており、技術理解と英語能力の強化に努めています。

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

並行して、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

常に意識していること

無闇に複雑で多機能であるよりも、簡素でわかりやすいものの方が価値があると思っています。普段の生活でも、何かを選択する際は、まず運用の事情から考えることが多いです。行きすぎないように気をつけつつも、必要最小の構成に美しさを感じます。それが、何かとシンプルな構成を選ぶことの動機にもなっています。