Linuxの基本操作ができるようになった後、次のステップが見えなくなるエンジニアは少なくありません。
この記事では、20年近くLinuxサーバーを運用し、3,100名以上にLinuxを指導してきた経験から、「コマンドの次に学ぶべきスキル」としてシェルスクリプトを推す理由と、書けるようになった後にどう仕事が変わるかを具体的にお伝えします。
この記事のポイント
・シェルスクリプトは「コマンドの次」に学ぶ最適なスキル
・書けるようになると手作業が消え、現場の評価が変わる
・3,100名の指導経験から見た「伸びる人」の共通点
・最初の1本を書くための具体的なステップ
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
コマンドを覚えた「その先」で止まる人が多い理由
「ls、cd、grep、findあたりは使える。でもそこから先、何をすればいいのか見えない」私のセミナーでは、受講生からこの相談を頻繁に受けます。コマンドを一つひとつ覚えていく段階は、やるべきことが明確です。しかし基本コマンドを身につけた後は、次のステップが急に見えにくくなります。
Docker、Kubernetes、Ansible、Terraform。周りを見渡すとトレンド技術のキーワードばかり飛び交っていて、「自分もそちらに進まなければ」と焦る気持ちもわかります。
でも、20年近くサーバーを運用してきた経験から断言します。コマンドの次に学ぶべきは、トレンド技術ではなくシェルスクリプトです。
理由はシンプルです。コマンドを「知っている」状態から「組み合わせて使いこなす」状態に引き上げてくれるのが、シェルスクリプトだからです。
シェルスクリプトが書けると何が変わるのか
1. 手作業が消える
サーバー運用の現場では、同じ作業の繰り返しが驚くほど多いです。ログファイルの確認、バックアップの実行、ユーザーアカウントの一括作成、ディスク容量のチェック。これらを毎回手で打っているエンジニアと、シェルスクリプトにまとめて一発で実行できるエンジニアでは、作業時間に天と地の差が生まれます。
私がSE時代に経験した話をします。当時、あるプロジェクトで50台以上のサーバーのログを毎朝確認する業務がありました。最初は1台ずつSSHで入ってgrepで検索する、という手作業をやっていました。1日2時間以上かかっていたこの作業を、シェルスクリプト1本で15分に短縮したときの衝撃は、今でも鮮明に覚えています。
2. ミスが減る
手作業にはヒューマンエラーがつきまといます。コマンドの打ち間違い、対象サーバーの取り違え、手順の飛ばし。疲れた金曜の夕方に限って、こうしたミスは起きます。シェルスクリプトにしておけば、一度検証した手順がそのまま再現されます。「今日は疲れているから慎重にやろう」という属人的な判断に頼る必要がなくなるのです。
受講生からよく聞かれる質問に「本番サーバーで怖くてコマンドが打てない」というものがあります。スクリプト化しておけば、検証環境で十分にテストした手順をそのまま本番に持っていける。この安心感は、シェルスクリプトを書けるようになって初めてわかることです。
3. 現場での評価が変わる
「あの人に頼めば自動化してくれる」チーム内でこう認識されると、任される仕事の質が変わります。単純な作業要員ではなく、業務改善の提案者として扱われるようになります。
3,100名以上を指導してきた中で、セミナー後に最も早くキャリアが変わった受講生に共通していたのは、学んだコマンドをシェルスクリプトにまとめて現場に持ち帰った人たちでした。コマンドを「覚えた」だけでは現場の評価は変わりません。「使いこなしている」と思わせるには、実際に業務を効率化した実績が必要です。
シェルスクリプトは「プログラミング」ではない
「スクリプトを書く」と聞くと、プログラミングの経験がない方は身構えてしまうかもしれません。しかし、シェルスクリプトはプログラミング言語とは性質が異なります。極端に言えば、ターミナルで打っているコマンドをファイルに書き並べたものがシェルスクリプトです。普段使っているコマンドの延長線上にあるので、PythonやJavaのようにゼロから文法を覚える必要はありません。
たとえば、毎朝「/var/log/messagesの中からエラーを含む行だけ抽出して、結果をメールで送る」という作業をしているとします。ターミナルで打つなら以下のようなコマンドです。
# /var/log/messagesからerrorを含む行を抽出してメールで送信 grep -i "error" /var/log/messages | mail -s "Error Report" admin@example.com
#!/bin/bash # エラーログ抽出・通知スクリプト grep -i "error" /var/log/messages | mail -s "Error Report" admin@example.com
私が現場で見てきた「シェルスクリプトで評価された場面」
20年近くの運用経験の中で、シェルスクリプトが現場で評価された場面を3つ挙げます。1. 障害対応の初動が速くなった
深夜にアラートが飛んできたとき、寝ぼけた頭でコマンドを一つずつ打つのと、事前に用意した調査スクリプトを実行するのでは、初動の速さがまるで違います。私がSE時代に担当していたシステムでは、障害発生時に確認すべきポイントをスクリプトにまとめていました。CPU使用率、メモリ状況、ディスク空き容量、直近のログ、プロセスの状態。これらを1コマンドで一覧表示できるようにしておいたことで、障害の切り分けが格段に速くなりました。
2. 引き継ぎの質が上がった
運用手順書をWordで書くよりも、実行可能なシェルスクリプトとして残すほうが、引き継ぎの質は確実に上がります。手順書は「読んで理解して、手で打つ」という3段階が必要ですが、スクリプトなら「実行する」だけです。さらに、スクリプトの中にコメントで理由や注意点を書いておけば、なぜその手順が必要なのかも伝わります。ドキュメントと実行手順が一体化するのは、シェルスクリプトならではの強みです。
3. cronと組み合わせて「仕組み」になった
シェルスクリプトが真価を発揮するのは、cronジョブと組み合わせたときです。書いたスクリプトを定期実行させれば、人が介在しなくても業務が回る「仕組み」になります。バックアップの自動実行、ログの自動集計、ディスク容量の閾値監視と通知。こうした仕組みを一つひとつ作っていくと、気づけば自分がいなくてもサーバーが安定して動き続ける状態になっています。
最初の1本を書くための具体的なステップ
シェルスクリプトを書いたことがない方に向けて、最初の1本を完成させるまでの手順を示します。ステップ1：普段の作業を書き出す
まず、毎日または毎週繰り返している作業を紙に書き出してください。「サーバーにログインしてdfコマンドでディスク容量を確認する」「grepでエラーログを検索する」など、どんな小さなことでも構いません。ステップ2：コマンドをファイルに並べる
書き出した作業を、そのままテキストファイルに並べます。先頭行に#!/bin/bash を書き、あとは普段ターミナルで打っているコマンドを1行ずつ記述するだけです。ステップ3：検証環境で実行する
chmod +x で実行権限を付けて、検証環境で動かしてみてください。本番サーバーでいきなり試すのは絶対に避けること。ここは鉄則です。# スクリプトに実行権限を付与 $ chmod +x check_disk.sh # 実行 $ ./check_disk.sh
ステップ4：少しずつ改良する
最初のスクリプトが動いたら、「結果をファイルに保存する」「容量が90%を超えたら警告を出す」といった改良を少しずつ加えていきます。一度に完璧を目指す必要はありません。動くスクリプトを育てていく感覚が大切です。シェルスクリプトで「動かない」と思ったときの対処法
シェルスクリプトを書き始めると、ほぼ確実にエラーに遭遇します。「Permission denied」「command not found」「syntax error」。最初は面食らうかもしれませんが、対処法を知っていれば怖くありません。・Permission denied：実行権限がない。
chmod +x スクリプト名 で解決する・command not found：PATHが通っていない。
which コマンド名 でフルパスを確認し、スクリプト内ではフルパスで記述する・syntax error：if文やfor文の閉じ忘れが大半。
bash -n スクリプト名 で構文チェックできる特に初心者が陥りやすいのは、Windowsで編集したファイルをLinuxに持っていったときに起きる改行コードの問題です。
# 構文エラーがないかチェック $ bash -n check_disk.sh # 改行コードを確認（^Mが表示されたらWindows改行） $ cat -A check_disk.sh | head -3 #!/bin/bash^M$ # check script^M$ # 改行コードをLinux形式に変換 $ dos2unix check_disk.sh
伸びる人と伸びない人の違い
3,100名以上を指導してきた中で、シェルスクリプトの学習で伸びる人と伸びない人には、はっきりとした違いがあります。伸びる人は「まず動くものを作る」ことを優先します。エラー処理が甘くても、変数名が雑でも、とにかく目的を達成するスクリプトをまず1本書き上げる。そこから徐々に改善していくのです。
一方、伸びない人は「きれいなコードを書かなければ」と考えて、最初の1行すら書き出せないまま時間が過ぎていきます。
私のセミナーでは「最初のスクリプトは汚くていい」と必ず伝えています。10行のスクリプトでも、手作業を1つ自動化できれば、それは立派な成果です。完璧なコードは、その後いくらでも磨けます。
まとめ
| ポイント | 内容 |
|---|---|
| コマンドの次に学ぶべきスキル | シェルスクリプト（コマンドの組み合わせ） |
| 手作業が消える | 繰り返し作業をスクリプト化で時間短縮 |
| ミスが減る | 検証済みの手順をそのまま再現できる |
| 現場の評価が変わる | 業務改善の提案者として認識される |
| 最初の1本の書き方 | 普段の作業をファイルに並べるだけでOK |
| 伸びる人の共通点 | まず動くものを作り、後から改善する |
最初の1本は、たった3行でも構いません。普段手で打っているコマンドをファイルに書いて実行する。その小さな一歩が、エンジニアとしての仕事のやり方を根本から変えてくれます。
コマンドの「その先」を学びたいあなたへ
シェルスクリプトを書くには、まずコマンドの基礎が固まっていることが前提です。
「基本コマンドに不安がある」「体系的に学び直したい」という方もいるかもしれません。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
登録10秒／合わなければ解除3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として15年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 前のページへ：「遅い・不安定」が解消されるWSL2｜Windowsでもネイティブ並みのLinux開発環境が実現する
- この記事の属するカテゴリ：Linux学習ガイドへ戻る