こんにちは、インフラエンジニアのryuです。
インフラの勉強を始めてしばらくすると、たいていの人が同じところで足を止めます。「結局、プログラミングはできないとダメなのだろうか」という疑問です。
求人票には「シェルスクリプトの読み書き」と書いてあったり、「Python歓迎」と添えてあったりします。かと思えば、現役のインフラエンジニアが「コードなんてほとんど書かないよ」と言っていたりもする。どちらを信じればいいのか、分からなくなってしまうのではないでしょうか。
この記事では、その食い違いがどこから来ているのかをほどいたうえで、未経験のうちに手をつけるべき範囲と、まだ手をつけなくていい範囲を線引きします。ゴールは「プログラミングを勉強すること」ではなく、自分の学習時間をどこに配分するかを決めることです。
「必要ですか」に、はっきりした答えが返ってこない理由¶
同じ質問に対して人によって答えが違うのは、聞き手と答え手で「プログラミング」という言葉が指しているものがずれているからです。
たとえば「料理はできますか」と聞かれたとき、家でカレーを作れることを指しているのか、店を出せる腕前を指しているのかで、答えは変わりますよね。プログラミングも同じで、どのレベルの話をしているのかが共有されていないまま、質問と答えが行き交ってしまっています。
開発エンジニアの「書く」とインフラエンジニアの「書く」は目的が違う¶
アプリケーションを作るエンジニアにとって、コードは成果物そのものです。設計して、書いて、テストして、届ける。コードが仕事の中心にあります。
一方、インフラエンジニアにとってのコードは、ほとんどの場合、自分の手作業を減らすための道具です。100台のサーバーに同じ確認をする、毎朝同じログを集める、といった作業を、人間の代わりに実行してもらうために書く。目的が違うので、必要になる技術も自然と違ってきます。
だから、アルゴリズムを競うような力は最初は要りません。求められるのは、やりたい手順を正確に並べて、失敗したときに気づける形にする力です。
求人票の「必須」は、たいてい読める側を指している¶
未経験者向けの求人票にある「シェルスクリプトの知識」は、ゼロから設計して書ける人を探している、という意味であることは多くありません。
現場に入ってまず起きるのは、先輩が何年も前に書いたスクリプトを渡されて「これ、朝に動いてるやつだから中身見といて」と言われる場面です。つまり、最初に必要になるのは書く力よりも読む力なんですね。
読めれば、直せます。直せるようになれば、書けるようになります。順番はいつもこちらです。
現場で動いているコードは、だいたい3種類¶
インフラエンジニアが触れるコードを、目的別に3つに分けて整理してみます。これを分けておくと、学習の優先順位がとても決めやすくなります。
| 種類 | 代表的なもの | 何のために書くか | 未経験のうちの優先度 |
|---|---|---|---|
| 手順の自動化 | シェルスクリプト（bash） |
毎回同じ作業を人の代わりに実行する | 高い |
| 構成の記述 | YAML・設定ファイル・IaC | 環境の状態を文章として残す | 中くらい |
| 情報の加工 | Python | ログやAPIの結果を集めて形を変える | 後まわしでよい |
① 手順の自動化：シェルスクリプト¶
サーバーの上で「このコマンドを、この順番で」と決まっている作業は、そのままファイルに書き出せます。これがシェルスクリプトです。
特別な言語を新しく覚えるというより、いつも打っているコマンドを並べて名前を付けるイメージに近いです。だからこそ、Linuxのコマンドを知っている人ほど習得が速い。Linuxコマンドの基本を先に触っておくと、ここでの伸び方が変わります。
② 構成の記述：設定ファイルとIaC¶
サーバーの台数が増えると、手で設定するのが追いつかなくなります。そこで「あるべき状態」をファイルに書いて、ツールに合わせてもらう方式が広く使われています。
こちらはプログラムというより、決まった書式で状態を宣言する作業です。書き方そのものより、書こうとしている設定の意味が分かっているかが問われます。ネットワークやLinuxの理解が土台になるわけです。
つまり、この領域でつまずく原因はたいてい書式ではありません。サブネットの切り方やサービスの起動順序といった、設定の中身のほうです。コードの勉強をしても解決しないので、ここは素直にインフラそのものを学ぶのが近道になります。
③ 情報の加工：Python¶
障害の調査で数万行のログから特定の時間帯だけを抜き出したい。クラウドのAPIから機器の一覧を取って一覧表にしたい。こういう場面で効いてくるのがPythonです。
ただ、これは「必要になったときに強力な道具」であって、入り口で必須のものではありません。順番としては最後で十分です。
未経験のうちは、シェルスクリプトのどこまでをやればいいのか¶
では具体的に、どこまでを目標にすればいいのでしょうか。私は、次の4つが読めて直せれば、学習段階としては十分だと考えています。
変数、条件分岐、繰り返し、そして終了ステータス。この4つです。
まずは「コマンドを並べただけ」から始めていい¶
いきなり関数や配列を覚える必要はありません。最初の一歩は、手で打っている確認作業をそのままファイルにするところからです。
#!/bin/bash
# 日次の簡易チェック：ディスクとメモリとサービスの状態を並べて見る
echo "--- $(date '+%Y-%m-%d %H:%M') ---"
df -h /
free -h
systemctl is-active nginx
これだけでも立派なスクリプトです。毎朝3つのコマンドを打っていた人が、1回で済むようになります。ここで「自分の手間が減った」という感覚を味わえるかどうかが、続くかどうかの分かれ目になります。
次に、終了ステータスで「成功したか」を見る¶
並べるだけの段階を過ぎたら、次は結果によって動きを変える書き方に進みます。ここでつまずく人が多いのですが、実は考え方はとても素直です。
コマンドは実行が終わると、成功したかどうかを数字で返します。0 が成功で、それ以外は失敗。これを $? で受け取れます。
#!/bin/bash
# バックアップ先に到達できるかを確認してから処理に進む
if ping -c 1 -W 2 192.168.10.20 > /dev/null; then
echo "backup server: reachable"
rsync -a /var/www/ /mnt/backup/www/
else
echo "backup server: unreachable" >&2
exit 1
fi
失敗したときにわざわざ exit 1 を書いているのが大事なところです。何も返さずに終わると、このスクリプトを呼んでいる側は失敗に気づけません。
自動化は、うまくいったときより、うまくいかなかったときにどう振る舞うかで価値が決まる。黙って失敗するスクリプトは、手作業より危ない。
この感覚は、ログの読み方と一緒に育てていくと定着が早いです。スクリプトが残した出力を読む練習と、サーバーのログを読む練習は、ほとんど同じ筋肉を使います。
書く前に、日本語で手順を並べてみる¶
いきなりエディタを開くと、たいてい手が止まります。おすすめは、やりたいことを先に日本語の箇条書きにしてしまうことです。
「バックアップ先につながるか確認する」「つながったらコピーする」「つながらなければ記録を残して止める」。この3行を書いてから、1行ずつコマンドに置き換えていく。そうすると、コードを書く作業が翻訳作業に変わります。
この進め方は、現場の手順書の読み方と確かめ方とも地続きです。スクリプトは、人間向けの手順書を機械向けに書き直したものだと考えると、急に身近に感じられるのではないでしょうか。
書いたものは、自分以外の目でも確認する¶
もうひとつ、早い段階で身につけておくと得なのが、書いたスクリプトを機械にチェックさせる習慣です。シェルスクリプトは書き方が緩いぶん、動いてしまうけれど危ない書き方がたくさんあります。
ShellCheckのような静的解析ツールに通すと、引用符の付け忘れのような典型的な落とし穴を指摘してくれます。指摘の一つひとつが教材になるので、独学の相棒としてかなり優秀です。
そして、書いたスクリプトはファイルとして残ります。残るということは、履歴を管理したくなるということです。この流れでインフラエンジニアとGit・GitHubの基本につながっていくと、学習が一本の線になります。
Pythonは、いつ始めればいいのか¶
「将来を考えるとPythonもやったほうがいいですよね」とよく聞かれます。答えは「やったほうがいい。ただし順番は最後」です。
理由は単純で、Pythonが本当に効いてくる場面に、未経験のうちはまだ出会わないからです。道具は、使う場面を知ってから持つほうが身につきます。
始める合図は「シェルでは苦しい」と感じたとき¶
次のような場面に出会ったら、そこがPythonの入り口です。
ひとつは、JSONを扱い始めたとき。クラウドやネットワーク機器のAPIは、結果をJSONで返してくることがほとんどです。これをシェルだけで処理しようとすると、とたんに読みにくくなります。
もうひとつは、集計が必要になったとき。何千行のログを時間帯ごとに数える、機器の一覧を突き合わせる。こうした処理は、Pythonのほうが短く、あとから読み返せる形で書けます。
最初に覚える範囲も、やはり狭くていい¶
Pythonを始めるとなると、つい入門書を1冊まるごと終わらせようとしてしまいます。でもインフラの用途に限れば、必要な範囲はかなり絞られます。
ファイルを読む、文字列を切り出す、辞書とリストを扱う、for で回す。この4つがあれば、日々の作業の多くは書けてしまいます。クラス設計やWebフレームワークは、必要になってからで遅くありません。
入門の教材を探すなら、まずは公式のチュートリアルを上から順に、必要な章だけ読むのが近道です。全部を読み切ろうとすると、たいてい途中で止まってしまいます。
ここでも、狙いは「Pythonができる人になること」ではなく、「目の前の面倒を減らすこと」です。目的を見失わないようにしたいですね。
逆に、急いで手をつけなくていいもの¶
学習時間は有限です。だから、後まわしにしてよいものをはっきりさせておくことも同じくらい大切です。
競技プログラミングのようなアルゴリズムの訓練は、インフラの現場ではすぐには効いてきません。Webアプリのフレームワークも同じです。どちらも価値のある分野ですが、優先順位は下がります。
それよりも先に効くのは、サーバーとネットワークそのものの理解です。スクリプトが ssh でつながらないとき、原因がネットワーク側にあるのかLinux側にあるのかを切り分けられなければ、コードをいくら書いても前に進めません。
たとえば定期実行をcronとsystemd timerのどちらに任せるかという判断は、コードの上手さとは別の知識です。せっかく書いたスクリプトが動かない原因は、コードではなく実行のさせ方にあることが本当によくあります。
手を動かす場所がない、という人は、仮想マシンでもクラウドの無料の範囲でもかまいません。自分が壊しても誰も困らないサーバーを1台持っておくと、学習の速度がはっきり変わります。
学習の順番に落とし込むと、こうなる¶
ここまでの話を、実際の進め方としてまとめ直します。
最初にLinuxのコマンドを手になじませます。次に、よく打つ組み合わせをスクリプトにまとめてみる。そのスクリプトを定期実行させてみて、失敗したときに気づける形に直す。ここまで来たら、扱うデータが複雑になってきた時点でPythonを迎え入れる。この順番です。
大事なのは、どの段階でも「自分の環境で動かしてみる」ことです。読んだだけの知識は、驚くほど早く抜けていきます。
続けるコツは、週に1本、小さく書くこと¶
まとまった時間を取って一気に覚えようとすると、たいてい続きません。かわりに、週に1本だけ、3行から5行の短いスクリプトを書くことを習慣にしてみてください。
題材は身のまわりで十分です。ディスクの空きを記録する、証明書の期限を表示する、自分のグローバルIPアドレスを確認する。どれも数行で書けて、しかも実務でそのまま使われている処理です。
1本が小さいので失敗してもすぐ直せますし、半年も続けば手元に20本以上たまります。その頃には、スクリプトを書くことが特別な作業ではなくなっているはずです。
InfraAcademyでは、Linuxのコマンド操作からサーバーの構築までをブラウザ上で手を動かしながら進められるようにしています。何を先に学ぶべきか迷ったときは、Linuxの学習ロードマップを順に進めてみてください。コマンドが体になじむほど、シェルスクリプトは怖くなくなります。
ネットワーク側から固めたい人はネットワークの学習ロードマップを、全体像をつかみたい人はインフラエンジニアの学習ロードマップを先に眺めてみるのもよいと思います。
まとめ¶
インフラエンジニアにプログラミングは必要か。答えは「必要。ただし、思っているより狭い範囲で十分」です。
まずはシェルスクリプトを読めるようになること。変数、条件分岐、繰り返し、終了ステータスの4つが分かれば、現場で渡されるスクリプトの大半は読めます。読めれば直せて、直せれば書けるようになります。
Pythonは、シェルでは苦しいと感じたときが始めどきです。JSONを扱い始めたら、そのときが合図だと思ってください。
そして何より、コードは目的ではなく道具です。自分の手間がひとつ減ったかどうかを毎回の基準にしていけば、学ぶ順番はおのずと見えてきます。今日は、いつも打っているコマンドを3行だけファイルに書き出すところから始めてみませんか。
