今回は、「心得」とはちょっと違うような気もしますが、インフラエンジニアを取りまく環境について、ちょっと書いてみたいと思います。
インフラエンジニア不足の原理
筆者が思うに、インフラエンジニアというのは、常に絶対的な不足に悩まされています。それにはさまざまな理由がありそうです。減点法による評価が多い、教育する機会がない、教育するつもりがない、イメージが良くない…などです。
ネットワークにしてもサーバにしても、何かヘマした瞬間にトラブルが起こることがあります。init 6と叩くつもりがinit 0と叩いたり、ルーティングを間違えたりフィルタを間違えたりした瞬間にリモートから何もできない状態に陥ってダッシュする状況は、インフラエンジニアなら誰しも経験しているのではないでしょうか。
運用というのは、うまく動いていてあたりまえ、障害が起こると「何やってんだー！」と言われる世界なので、どうしても経験が少ない人には仕事が任せられないのが普通です。経験を積む機会と言えば、他に誰もいなくて自分がやるしかない状況や、やさしい先輩がそばについて見守っていてくれる中で作業をするときくらいです。つまり、自分から「やりたい。やろう」と思っても、やれないというのが実情です。これはプログラマやデザイナーなどの開発系との大きな違いです。
ただ正直に言えば、昔に比べれば今は恵まれた状況になってきてはいると思います。そこらのPCにLinuxを入れるのもかなり簡単になってきているし、安いVPSサービスも増えてきています。それに、ノウハウやコツもGoogle先生にかなり教えてもらうことができます。とはいえ、そういうところから、実際のサービスで運用するエンジニアになるまでには大きなギャップがあるのも事実です。
状況に任せるのは運次第
筆者のケースでは、この連載で以前にも書きましたが、某アスキーという会社の某サービスで、なぜかサーバエンジニアが自分一人だった[1]ので、好むと好まざるとを関わらず、やる環境にありました。もちろんそれは好む状況だったのは言うまでもありません。ただ情報収集は今よりかなり大変ではありました。
Googleもなかった（AltaVistaはあったけど）ですし、blogのように個人が気軽に情報発信することもなかったので、情報源といえばmanとソース、あとは書籍とNetNewsくらいでした。当時はわからないことを質問すると「man ○○」と言われ、「manってなんですか？」って聞くと「man man」と言われる、というジョークがありました。最近はRTFM（Read The Fucking Manual）とかほとんど聞かないですね。
…昔話をするのは年寄りの証拠です。
某アスキーの次も、某So-netにおいて、サーバエンジニアのリーダーだった人（この人はすごく詳しくていろいろ勉強になった）がほとんど会社に来なかったので、実質サーバ関連については自分がリーダーとして活動することができたので、いろいろ学んでさまざまな経験を積むことができましたし、そのあとの某オンザエッヂのデータセンターにおいては、立ち上げ直後にマネージャとして加わったので、「やりたいけどやれない」という事態になったことは、エンジニア人生でまずないという、かなり恵まれたものではありました。もちろんスキルをつけながらだったので、冷や汗をかいたり、キツい思いをすることもたくさんありましたが。
…昔話をするのは年寄の証拠です。
さてさて、そういう「否応なく追いこまれる状況」に巡り逢えるのは、自分の意思だけでどうなるものでもありません。もし自分が飛び込んだ職場が、すごく仕事ができて責任感があって、でも教育に興味がない人がいたら、もうそこであまりやることはない気がします。
とはいえ、だいたい一般的には、仕事ができる人には任せようかと思うものですし、また、仕事ができると思う人は教育してみたくなる、ということも十分ありえるので、せめて任せられた仕事をこなしているうちに少しずつ任せられていく、というケースが多いのが実情なのではないでしょうか。
前回の「トラブルを利用しろ」でも書いたように、人間少しハードルの高い仕事に取り組んでいるときが一番成長するものです。ただ、トラブルのときはやむをえない（背に腹は変えられない）ことでも、通常運用時には「確実にできるだろうと思われる仕事」しか任されないものです。
サーバエンジニアの面接をすると、10年といったオーダーで同じことしかやってきていない人をよく見かけます。こういう状況は、本人にとっても会社にとっても、（オーバーではなく）国にとっても良くないことです。いまやネットというのは社会のインフラになろうとしている[2]状況においては、そのインフラを安定して運用できる人材というのは宝のようなものです。
自分一人で解決できること
ちょっと五月雨になってしまったので、ここまでの内容をまとめてみます。
- ① ネットはインフラになりつつある
- ② 必要十分なインフラエンジニアがいない
- ③ インフラエンジニアは「正常にいっていて（つまり成果を出してて）あたりまえ」の世界だ
- ④ できるかどうかわからない人には、できれば任せたくない
- ⑤ かといって、自分で経験を積むのはなかなか難しい
①～③はただの状況説明なので、問題は④と⑤ということになります。
それに加えて、なんとなくですが（間違っていたらすみません）、インフラエンジニアは自分が運用する環境を他人に任せたくない性質があるような気がします。
まず、簡単な（？）⑤について考えてみましょう。
自分で経験を積むには、自宅のPCにUbuntuでも入れてガリガリさわってみるとか、VPSを借りてガリガリさわってみるとかなどが考えられます。でも、それでできるのは、基礎の習得までです。数学で言えば、代数を身につけるようなものです。
サーバ構築なんて（本来は）できてあたりまえ、コストを抑えてSPOFのない冗長構成を組んだり、コストを抑えて爆裂なパフォーマンスがでるようにしたり、数百数千のサーバを効率よく管理したり、障害を光の速さで解決したりとか、所謂「できる」インフラエンジニアというのはそういうものです。
（あ、サーバの話ばっかりになっている…）
自分でそういった経験を積むには、自分で大ヒットするサービスでも作るしかありませんが、なかなかそうもいかないでしょう。もちろん不可能ではないので、チャレンジする価値はあります。
ところで余談ですが、上記の中で「コストを抑えて」というのは、あっさり書いていますがとても重要です。そりゃあ、高い金はらえば、冗長構成組んだり爆裂パフォーマンスが出るような環境を作るのは容易です。それをコストをかけずにやるのが重要です。
スケールアップかスケールアウトかという話でいえば、スケールアウトのほうが望ましいわけですが、スケールアウトで行っても、同じ100台で倍の速度を出すというのは「腕」になるわけです。大反対したのに数億のサーバを買って、1年くらいで使えなくなったようなケースもありました[3]。
また、もう10年以上前になりますが、プロバイダ満足度ランキングというのがあって、一位にはある超有名プロバイダが輝いていました。国内でNTTに対抗する会社になるという高い目標を掲げ、なぜかいまNTTの傘下にいる会社ですが、その当時その会社は超大赤字を毎年叩き出していました。冗談混じりで「あんだけ赤字出していいならそりゃ満足度あげられるわー！！」とちょっと負け惜しみを言ったこともあります。もちろん、お金を使えば誰でも満足度をあげられるというわけでもないので、一位になるのは素晴しいことです。
…ずいぶん余談に熱が入ってしまいました。
「人に任せられない」症候群
さて、⑤について考えてみると、上記のようなことになります。そうすると、あと残るのは④というわけですが、ここが一番のポイントだと筆者は思います。つまり、ここまでは全部前置きです。日本に（世界はどうだかよくわかりません）インフラエンジニアが少ないのは、この④が元凶だと思っています。
「こいつに任せるのは不安だから任せない」、これです。この点について考えてみることで、日本のネットワークとエンジニア情勢は劇的に改善していくと思います。
誤解しないでいただきたいのは、「できるかどうかわからない人に任せて障害が起こっても、そっちのほうがマシだ」と思っているわけでは全然ないことです。そんな選択をしたらただの間抜けです。そうではなくて、「できるかどうかわからない人に、障害が起こる可能性を極限まで下げて任せてみる」ことはできないでしょうか。「極限まで下げて」が変数なので、うまい案があればこの値が小さくなるし、下手な案だと高くなります。
これを実行するためには、いろいろなポイントがあります。
- a）任せられる側の気持ち
- b）任せる側の気持ち
- c）方法論
すぐに思い付くのはこの3つです。
まずa）ですが、これはもう、そもそも任せられる側に「面倒だから嫌」とかいう状況を考えてもしょうがない、第1回からずっと書いていますが、そういうのは「向いてない人」なのでここでは相手にしないことにします。世の中には「任せられるならやりたい」「任せてほしい」「任せろ」という人はうじゃうじゃいます。なので、「できれば任せられないで楽をしたい」という人を無視して考えても、十分日本のエンジニア事情を改善することはできます。
次にb）です。b）はc）と密接にからむように思えますが、ここではc）と独立する（依存しない）ケースだけ考えます。わかりやすくいえば「いい方法論があったとして」という前提のもとで考えるということです。これはもう度量としか言いようがありません。
たとえば「うまい方法があったとしてもそれでも任せて問題になる可能性はゼロではない。でもそういう場合は自分もケツを持つ」という覚悟であったりとか、
「自分の可愛い子供のようなサーバやネットワークをまかせたくないなあ」とかそういう狭量なことを思わない懐の広さであったりとか、
「こいつが成長したら自分の立場がなくなるんじゃないか」という論外な馬鹿馬鹿しいことを考えない常識的な判断力とか、そういったものです。
でも実は、ここがネックになっているケースは実にたくさんあるんではないかと思います。そしてこれはエンジニアを育成して増やすという問題にとどまらない、組織やマネジメントの課題であったりもします。正直b）は一番難しい点でしょう。そしてここでは問題提起までに留めておきます。
「エンジニアファーム」への道
最後にc）です。a）は問題外として、b）はかなり根本的なかつ永遠のテーマであるとすると、c）はかなり具体的な課題です。そして「これ」という正解があるわけでもありません。
筆者は某オンザエッヂに転職したときにデータセンターのマネージャに就任しましたが、その当時データセンターには5名のエンジニアしかいませんでした。24時間365日、なんでもやりますお任せください、という謳い文句でサービスが開始していたのに、実際にそれを支えるのは自分を入れて6名という状況だったわけです。数時間ほど途方に暮れましたが、途方に暮れてもしょうがないので、その状況を改善するにはどうすればいいかを考えました。
結論は「やる気はあって潜在的に優秀だが未経験ということでエンジニアへの道を断たれている」人たちを集めて、エンジニア集団というかエンジニアファームを作ろう、というものでした。
当時、「日本にはサーバエンジニアが本当にいない。少ない。もう自分のところで育成するしかない。うまくすれば日本は変わる」とか考えたことをかなり鮮明に覚えています。幸い、集めること自体はそれほど難しくありませんでした。「やる気はあって潜在的に優秀だが未経験ということでエンジニアへの道を断たれている」人達というのは在野にたくさんいるということです。
次の課題は、そういった人たちに、トラブルにならないように作業をさせて覚えさせるにはどうすればいいか、というものでした。そこで次に作業フローを考えました。（当時）全部で8ステップからなる作業フローで、以下のようなものです。
- 起票
- 確認
- 作業計画
- 承認
- 作業
- 承認
- 作業報告
- 承認
担当者がやることの直後に、いちいち「確認」や「承認」という手順が入っています。承認作業というのは、エンジニアをレベル分けしてあるレベル以上にいる人しかできない、というルールを設けました。
また、高いレベルにいる人は承認を省いても良い、というルールも設けました。トラブルの際にはトラブルフローという、通常作業とは違うフローも存在しました。このフローの場合、3．と4．が勝負です。作業内容を作成して、その手順に問題がないか確認する、というものです。実際にやるつもりのコマンドを羅列して、上位者が、その通りにやったらうまくいくかを確認します。もちろん、この方法が最善で万全ということはありません。それでもミスがあることもありましたし、もっと良い方法もきっとあるでしょう。
ただ、ここで言いたかったのは「やる気はあって潜在的に優秀だが未経験ということでエンジニアへの道を断たれている」人達を育成活用するというスタンスや、「できるかどうかわからない人に、障害が起こる可能性を極限まで下げて、任せてみる」ことに取り組んでみるというスタンスなど、が重要ではないか、ということです。
今回の内容は、エンジニアの心構えとは違う内容になってしまいましたが、筆者がずっと危機感を持っていて、また何とかしたいと思っていることでしたので、書いてみました。
