こういった問い合わせに追われながら、ふと気づくと1日が終わっている。月が変わっても、年が変わっても、同じような対応を繰り返している。

私自身も情シス部門に配属された当初、「ITのプロになれる仕事だ」と期待していました。でも現実は、毎日の問い合わせ対応・PC設定・ベンダー折衝に追われ、「このまま5年後、10年後も同じことをしているのだろうか」と不安を感じた時期がありました。この記事は、そんな30代の情シス担当者に向けて書いています。

問題の本質：「忙しい」のに「スキルが積み上がらない」理由

情シスの忙しさは「経験値ゼロの消耗戦」になりやすい。

「忙しい＝スキルが身についている」と思いがちですが、情シスの場合は注意が必要です。毎日の問い合わせ対応は確かに大変ですが、同じ問題の繰り返しであれば、それは「1年の経験」ではなく「同じ1日を365回繰り返しただけ」になってしまいます。

転職市場では、情シスの経験年数より「何ができるか」が問われます。「5年情シスをやっています」だけでは、残念ながら市場価値に直結しません。

原因は3つある

原因① 「反応型」の仕事しかしていない

情シスの仕事は大きく2種類に分けられます。

• 反応型：問い合わせが来たら対応する、障害が起きたら直す
• 創造型：業務効率化の仕組みを作る、セキュリティポリシーを設計する、新技術を導入する

忙しい情シス担当者ほど、仕事の9割が「反応型」になりがちです。反応型の仕事は経験値が積み上がりにくく、その人がいなくなっても誰でもできる業務になってしまいます。

原因② 「広く浅く」になりすぎている

情シスはネットワーク・サーバー・セキュリティ・ヘルプデスク・ベンダー管理……と守備範囲が広い仕事です。これ自体は悪くないのですが、「何でも少しずつわかる人」は、転職やキャリアアップの場面で「何の専門家？」と問われたとき、答えに詰まってしまいます。

「ITゼネラリスト」は貴重ですが、それだけでは市場での差別化になりません。

原因③ 「勉強時間がない」という思い込み

「忙しくて勉強できない」はよく聞く言葉ですが、実態を確認すると「まとまった時間がない」ということであることが多いです。社会人の学習は「1日2時間の勉強時間を確保する」方式では続きません。通勤・昼休み・寝る前の15分といったスキマ時間を積み重ねる方式の方が、継続率がはるかに高いのです。

解決方法：「専門の軸」を1本持つだけでキャリアが変わる

「何でもできる情シス」から「クラウドがわかる情シス」に変わるだけで、市場価値は大きく変わります。

私がおすすめするのは、クラウド（特にAWS）をキャリアの専門軸にすることです。理由は3つあります。

• 需要が確実にある：多くの企業がオンプレミス（自社サーバー）からクラウドへの移行を進めています。「AWSがわかる情シス担当者」は、今後ますます重宝されます
• 資格で証明できる：AWS認定資格（AWS Certified）は、スキルを客観的に証明できる手段です。「AWS Cloud Practitioner（クラウドプラクティショナー）」は入門レベルで、情シス経験者なら2〜3ヶ月の勉強で取得を狙えます
• 現職での実績に直結する：「社内のサーバーをAWSに移行した」「クラウドのセキュリティ設定を担当した」という実績は、次のキャリアステップに直結する強力な武器になります

具体的なキャリアアップのロードマップ

今日からできる具体的なアクション

✅ 今週できること

1. 自分の「反応型/創造型」比率を振り返る
先週1週間の業務をざっと思い出して、反応型と創造型の割合を出してみてください。8割以上が反応型なら、要注意です。

2. スキマ時間の「学習枠」を決める
通勤電車の中、昼休みの15分、寝る前の10分——どこか1つだけ「学習の時間」と決めましょう。毎日15分でも、1年で約90時間になります。

✅ 今月できること

3. AWS Cloud Practitionerの学習を始める
Udemyの模擬試験問題集（1,500〜2,000円程度）から始めるのが最もコスパが高いです。「難しそう」と思っていても、情シス経験者ならすでに知っている概念が多く含まれています。

4. 上司に「AWS関連の仕事を担当したい」と伝える
社内でクラウド移行プロジェクトや、AWSを使ったシステムがあれば、担当させてもらえるよう手を挙げてみましょう。

✅ 半年後を見据えて

5. 小さな「発信」を始める
社内勉強会でAWSについて話す、ブログに学んだことを書く——どんな小さな発信でも、「アウトプット」は学習効率を大幅に高めます。発信することで「AWSを勉強している人」という認知が社内外に広がり、キャリアの選択肢が増えていきます。

まとめ

情シスのキャリアに行き詰まりを感じる原因は、「忙しさ」そのものではなく、「反応型の仕事ばかりで専門軸が育っていない」ことにあります。

• 反応型の仕事9割 → 創造型の仕事を少しずつ増やす
• 広く浅いゼネラリスト → クラウドという専門軸を1本作る
• 「勉強時間がない」 → スキマ時間の積み重ねに切り替える

「このままでいいのか」と感じた今日が、変わるための一番早いタイミングです。

関連記事：情シス必見｜AWSを学ぶべき理由とキャリア価値【30代向け】
関連記事：AWS SAA試験の勉強法【情シス担当者が実践する3つの方法】

情シスに異動してきた当初、先輩からそう聞かれて私は固まってしまいました。「Linuxって一種類じゃないの？」というのが正直な感想でした。

サーバーの調達や構築をベンダーに依頼するとき、「OSは何にしますか？」と聞かれて「えっと……Linuxで」と答えたら「どのディストリビューションですか？」と返されて頭が真っ白になった、という経験はありませんか？

Linuxの種類が多い理由を知らないと、サーバー選定のたびに迷い続けることになります。

この記事では、なぜLinuxにこんなに種類があるのかを、OSの歴史をたどりながら情シス目線でわかりやすく整理します。難しい技術の話ではなく、「なぜそうなったのか」という背景を理解することで、現場での判断がぐっと楽になりますよ。

なぜLinuxは種類が多いのか？問題の本質

多くの情シス担当者がやってしまいがちなのが、「Ubuntu vs CentOS、どっちが優れているか」という比較から入ることです。しかしこれは本質ではありません。

大切なのは「なぜこんなに種類が生まれたのか」という歴史的な背景を理解することです。背景がわかれば、自然と「この用途にはこのディストリビューション」という判断ができるようになります。

種類が多い理由は主に3つあります。

原因① Linuxがオープンソースだから

Linuxは誰でも自由に使え、改造して再配布できるオープンソースのOSです。レシピを公開している料理のようなもので、誰でもそのレシピをベースに自分流にアレンジして配布できます。その結果、世界中の開発者やコミュニティが独自のLinuxを作り始めました。

原因② 用途・目的に合わせて派生が進んだから

「サーバー用途に特化したもの」「デスクトップ向けに使いやすくしたもの」「組み込み機器向けに軽量化したもの」など、用途に合わせて派生バージョンが生まれました。同じ「自動車」でも、トラック・バス・スポーツカーと種類があるのと同じ発想です。

原因③ 企業・コミュニティがそれぞれ独自に発展させたから

Red Hat（レッドハット）やCanonical（カノニカル）のような企業、または世界中の有志コミュニティが、それぞれの判断で機能を追加・改良してきました。その結果、同じLinuxをベースにしながらも、性格の異なるディストリビューションが数多く生まれています。

「Linuxが多い」のは混乱の証拠ではなく、自由と多様性の産物なのです。

LinuxのルーツをたどるとOSの歴史が見えてくる

Linuxの多様性を理解するには、その生い立ちを知ることが一番の近道です。歴史の教科書のように難しくはないので、気軽に読み進めてください。

UNIX（1969年）：すべての祖先

現代のOSのほぼすべての祖先が、1969年にAT&Tベル研究所で生まれた「UNIX（ユニックス）」です。「複数の人が同時に使える」「プログラムを部品のように組み合わせて使える」という革新的な設計で、研究機関や大学に広まりました。

ただしUNIXは有償で、使うには高いライセンス料が必要でした。「会社の金庫に鍵がかかっていて、お金を払わないと中を見られない」状態です。

GNU計画（1983年）：「誰でも使えるOSを作ろう」

1983年、リチャード・ストールマンというプログラマーが「GNU（グヌー）計画」を立ち上げます。「誰でも自由に使えるUNIX互換のOSを作る」という壮大なプロジェクトです。

GNU計画によって、テキストエディタやコンパイラなど多くのソフトウェアが無料で公開されました。しかし肝心の「OSの中核部分（カーネル）」だけが完成しませんでした。

Linuxカーネル誕生（1991年）：フィンランドの学生が世界を変えた

1991年、フィンランドのヘルシンキ大学の学生だったリーナス・トーバルズが、自作のカーネルをインターネットに公開します。「趣味で作っているOSがあるんだけど、使ってみる人いる？」という軽いメッセージとともに。

このカーネルがGNUのソフトウェアと組み合わさることで、「GNU/Linux」という完全な無償OSが生まれました。これが現在私たちが「Linux」と呼んでいるものの誕生です。

1人の学生の「趣味」が、現在の世界のサーバーの90%以上を支えるOSになるとは、誰も予想していませんでした。

ディストリビューションの誕生：Linuxを「使いやすく」パッケージング

Linuxカーネルだけでは、普通の人には使いにくいものでした。そこで「カーネル＋各種ソフトウェア＋インストーラー」をセットにしてパッケージ化したものが登場します。これが「ディストリビューション（distribution＝配布物）」です。

レストランで言えば、「食材（カーネル）」だけでなく「調理済みの料理としてテーブルに出す（ディストリビューション）」イメージです。

主要ディストリビューションの分岐

現在のLinuxは大きく2つの系統に分かれています。

Debian系：Debian Linuxを祖先に持つグループ。Ubuntuが代表格で、個人・開発者・クラウド環境で広く使われています。パッケージ管理に「apt」コマンドを使います。

Red Hat系：Red Hat Linuxを祖先に持つグループ。RHEL（Red Hat Enterprise Linux）・CentOS・Rocky Linuxが代表格で、企業のサーバー環境で長く使われてきました。パッケージ管理に「yum」または「dnf」コマンドを使います。

情シス担当者は結局どれを使えばいいのか

歴史がわかったところで、実務的な話をします。情シスの現場では、用途に応じて以下のように選ぶのが定石です。

迷ったら「AWSならAmazon Linux、それ以外はUbuntu LTS」と覚えておけば、情シスの現場でまず困りません。

今日からできる具体的なアクション

1. WSL2でUbuntuを触ってみる：Windows 11なら「wsl –install」コマンド1つでUbuntuが使えます。まずlsコマンドとcdコマンドだけ覚えれば十分です
2. AWSの無料枠でEC2を起動してみる：Amazon Linux 2023のインスタンスを1台立ち上げてSSH接続するだけで、実感が大きく変わります
3. ディストリビューションの系統図を1枚印刷する：「Ubuntu＝Debian系」「CentOS＝Red Hat系」という関係図を手元に置くだけで、会議中に迷わなくなります

Linuxは「難しいOS」ではなく、「歴史ある自由なOS」です。背景を知るだけで一気に親しみやすくなります。

まとめ

Linuxの種類が多い理由を、OSの歴史から整理しました。

• Linuxはオープンソースのため、誰でも自由に改造・配布できる
• 1969年のUNIX → 1983年のGNU計画 → 1991年のLinuxカーネル誕生という流れ
• 現在はDebian系（Ubuntu）とRed Hat系（RHEL/Rocky Linux）の2大系統が主流
• 情シスの現場では「AWSはAmazon Linux、それ以外はUbuntu LTS」が基本の選び方

「種類が多くて何が何だかわからない」というモヤモヤが、少し晴れたでしょうか。次のステップとして、実際にWSL2やEC2でLinuxを触ってみることをおすすめします。

関連記事：情シスがAWSを学ぶべき理由はこちら

関連記事：LambdaでEC2・RDS夜間停止を自動化する方法はこちら

クラウドって、どこから手をつければいいの？

「クラウドの時代」と言われても、何から始めればいいかわからないのが情シスの本音ではないでしょうか。

「AWSもAzureもGCPも名前は聞いたことがある。でも、うちの会社で何を使っているかよくわからないし、ベンダーに任せているから自分で勉強しなくてもいいか…」

正直、私自身もずっとそう思っていました。

情シスの仕事は幅広く、クラウドだけを勉強している余裕なんてない。日々のヘルプデスク対応、社内システムの管理、セキュリティ対応…やることは山積みです。

でも、ある日気づきました。「クラウドを知らない情シスは、気づかないうちに損をしている」と。

この記事では、私が実際にAWSを学び始めて感じた「情シス担当者がAWSを学ぶべき理由」を3つ、現場目線でお伝えします。

実はここが問題：クラウドを「知らない」と何が困るのか

知らないと、判断できない。判断できないと、ベンダー任せになる。

社内でSaaSツールを導入するとき、基幹システムをクラウドに移行するとき、情シスは意思決定に関わることが増えています。

でも、クラウドの仕組みを知らないまま会議に出ると、こんなことが起きます。

• ベンダーの説明が「なんとなくわかった気がする」で終わる
• 見積もりが適正かどうか判断できない
• セキュリティリスクを自分でチェックできない

これは情シスの怠慢ではなく、学ぶ機会がなかっただけです。だからこそ、今から少しずつ知識をつけていくことに意味があります。

情シスがAWSを学ぶべき理由3つ

理由① 国内企業でのシェアが圧倒的。現場でAWSに出会う確率が高い

クラウドサービスには、Amazon Web Services（AWS）、Microsoft Azure（アジュール）、Google Cloud Platform（GCP）の「3大クラウド」があります。

では、なぜAzureやGCPではなくAWSなのか。

答えはシンプルで、日本国内でAWSのシェアが最も高いからです。

クラウド市場の調査データでも、AWSは国内外で継続的にトップシェアを維持しています。つまり、取引先・委託先・グループ会社がAWSを使っている確率が高く、情シスとして関わる機会が最も多いのがAWSということです。

もちろん、AzureはMicrosoft 365 との親和性が高く、Office製品を使っている企業に向いています。GCPはデータ分析やAI領域で強みを持っています。それぞれに得意分野があります。

ただ、「まず1つだけ学ぶなら何か」という問いへの答えとしては、「現場で一番よく出てくるAWSから始めるのが合理的」です。

私自身、AWS Cloud Practitioner（クラウドプラクティショナー：AWSの入門資格）を取得してから、ベンダーとの会話の解像度が明らかに上がりました。

理由② ベンダーに「言いくるめられない」ようになる

「よくわからないけど、プロが言うなら大丈夫か」は、情シスにとって最大のリスクです。

クラウドの提案を受けるとき、ベンダーはたくさんの専門用語を使います。

• 「このリージョン（地域ごとのデータセンターの拠点）に配置すれば冗長性が確保できます」
• 「IAM（AWSのアクセス権限を管理するサービス）でロールを分けておけばセキュリティは問題ありません」
• 「S3（Amazon Simple Storage Service：クラウド上のファイル保管サービス）に静的コンテンツを置くとコストを最適化できます」

これらの言葉を聞いたとき、「それって本当に適切な提案なのか？」を判断できますか？

AWSの基礎を学ぶと、こうした専門用語の意味がわかり、「それは本当にうちの規模に必要ですか？」と自信を持って質問できるようになります。

過剰なスペックや不要なオプションを見抜けるようになるのは、コスト削減にも直結します。情シスの腕の見せ所です。

理由③ キャリアの選択肢が広がる

「情シスはコストセンター」という時代は、終わりつつあります。

クラウドを使いこなせる情シス人材は、社内でも市場でも価値が上がっています。

AWS Cloud Practitioner を皮切りに、AWS Solutions Architect Associate（SAA：AWSのシステム設計を問う中級資格）などの資格を取っていくと、転職市場での評価も変わります。私自身、現在SAAを勉強中ですが、社内での会話の幅が明らかに広がりました。

また、クラウドの知識があると、社内DX（デジタルトランスフォーメーション）の推進役を担うチャンスも増えます。「言われたことをやるだけの情シス」から、「会社のIT戦略に意見できる情シス」へ、少しずつ変わっていけます。

解決策：まず「概念を知るだけ」でも十分

AWSは、実際に触らなくても「知っているだけ」で役に立つことがたくさんあります。

「クラウドを学ぶ＝プログラミングが必要」と思っていませんか？そんなことはありません。

AWSには、入門レベルの資格として「AWS Cloud Practitioner（クラウドプラクティショナー）」があります。これは技術的な実装よりも、クラウドの概念・サービスの概要・コストの考え方を問う試験です。

つまり、「どんなサービスが存在して、何ができるか」を知るだけでいいのです。

ベンダーとの会話で困らない程度の知識は、この資格を目指して勉強するだけで十分に身につきます。私自身もこの資格から始めました。

今日からできる具体的なアクション

1. AWSの公式サイトで無料アカウントを作る
   AWS無料利用枠を使えば、お金をかけずにサービスを体験できます。まず触ってみることが大事です。
2. AWS Cloud Practitioner の試験範囲を確認する
   AWSの公式サイトや学習サービス「AWS Skill Builder（スキルビルダー）」では、無料の学習コンテンツが公開されています。まず試験の全体像を把握しましょう。
3. ベンダーとの次の打ち合わせで「1つだけ」確認してみる
   「このサービスはAWSのどの機能を使っていますか？」と聞くだけでいいです。答えを調べることで、学習が加速します。

難しく考えなくて大丈夫。知識は少しずつ積み上げるものです。

まとめ

情シス担当者がAWSを学ぶべき理由を3つお伝えしました。

• 理由①：国内シェアが高く、現場でAWSに出会う機会が多い
• 理由②：ベンダーの提案を自分で判断できるようになる
• 理由③：キャリアの選択肢が広がり、社内での立場も変わる

「クラウドは難しそう」と感じていた方も、まずは概念を知るところから始めれば大丈夫です。情シスの仕事にクラウドの知識は、これからの時代の「必須スキル」になっていきます。

一緒に、少しずつ学んでいきましょう。

はじめに

情シスをやっていると、たまに「え、それ本気で言ってる？」と思う問い合わせが来ることがあります。
今日はそんな実体験を一つ紹介します。
情シス歴13年の私が、いまだに忘れられない「伝説の無茶ぶり」です。

事件のあらまし

ある日の午後1時。Teamsにメッセージが届きました。

「お疲れ様です。業務システムについて確認したいことがあります。本日15時までにご回答いただけますか？」

…15時。
今は13時。つまり、2時間以内に回答せよということです。

しかも内容を見ると、業務システムの仕様に関する突っ込んだ質問でした。ベンダーに確認しなければ答えられない内容です。

私の心の中でツッコミが炸裂しました。
「ベンダーに問い合わせる時間、どこにあるの？」

情シスの仕事を知らない人が多すぎる問題

これは決して珍しい話ではありません。情シスあるあるの筆頭格といっていいでしょう。

多くの社員は、情シスを「社内のなんでも屋」「ITの魔法使い」だと思っています。質問すれば即座に答えが返ってくると信じています。

しかし現実は違います。

情シスが問い合わせに回答するまでには、こんなプロセスが必要なことが多いです。

1. 内容を確認・整理する
2. 社内ドキュメントや仕様書を調べる
3. ベンダーや開発会社に問い合わせる（←ここで数日かかることも）
4. 回答をまとめて返信する

ベンダーへの問い合わせが必要な案件の場合、当日回答はほぼ不可能です。

その時、私はどう対応したか

「お問い合わせありがとうございます。内容を確認したところ、ベンダーへの確認が必要です。本日中の回答は難しく、早くて明日以降となります。お急ぎの場合は背景を教えていただけますか？」

するとこんな返事が来ました。

「実は明日の会議で説明が必要で…」

それを最初に言ってほしかった。

背景がわかれば、優先度の判断もできます。場合によっては「会議でその場で答えられる範囲で説明する」という代替案も出せます。

情シスへの問い合わせは、「何を・いつまでに・なぜ必要か」をセットで伝えてほしいのです。

情シスへ問い合わせるときの3つのお願い

この経験から、社内ユーザーの皆さんにお願いしたいことをまとめます。

① 余裕を持って問い合わせてほしい
　業務システムの仕様確認など、ベンダー確認が必要な内容は最低でも3〜5営業日の余裕がほしいです。

② 背景・理由を教えてほしい
　「いつ・なぜ必要か」がわかると、優先度を判断できます。緊急度が高ければ対応の仕方も変わります。

③「今すぐ」は魔法の言葉ではない
　急かせば早く解決するわけではありません。むしろ焦って調べると確認漏れのリスクが上がります。

おわりに

情シスは魔法使いではありません。

でも、適切な情報と適切なリードタイムをもらえれば、できる限り力になりたいと思っています。

今日の話が、情シスと社内ユーザーの相互理解に少しでも役立てば嬉しいです。

情シス歴13年、まだまだ修行中のサラセンでした。