「ウェブオペレーション」を読みました

2011-06-26

18章の執筆者である濱崎健吾さまよりご献本をいただきまして、読むことができました！

「まえがき」から

かっこよすぎて、もう。

日々、我々は少しずつ賢くなり、少しずつ知恵をつけ、少しずつコツをつかんでいった。10年前に書いたスクリプトはツールや言語に発展した。我々の周りには産業ができた。知識・経験・ツール・プロセスは技芸になった。我々はそれを「ウェブオペレーション」と呼んだ。

ウェブオペレーションは技芸であり、科学ではない。正規の学校教育・資格・標準は (少なくとも今はまだ) ない。我々のやっていることは、学習にも習得にも時間がかかり、その後も自分自身のスタイルを模索しなければならない代物である。「正しい方法」はどこにも存在しない。そこにあるのは、(とりあえず今は) うまくいくという事実と、次はもっと良くするという覚悟だけだ。

「ウェブオペレーション」という言葉には馴染みがない、という人が多いことでしょう。自分も、この本を読み始めるまでは自分の中に持っていなかった言葉です。それでも、本書に少しでも興味を持った人は「まえがき」を読んでみることをおすすめします。本書を「かっこいい」と感じるかどうかは、それだけで分かると思います。

数々の戦場を生き抜いた戦士たちの戦いの記録

本書は、現場で活躍する人たちの「武勇伝」集でありました。「まえがき」にあった「次はもっと良くするという覚悟」の意味を、読み進める中で深く知っていくことになります。

逆に、本書は、これとこれとこれを覚えておけば大丈夫、という知識や事実の羅列ではありません。日本語版には1章から18章までがあって、それぞれ著者は別々の人たちなのですが、どの章も「あるときは、こうやったら、こういうことが起こった」「このときの経験から、こういうことを学んだ」「次は、こういうことにならないように、こうしてみようと自分は考えている」といった体験談、あわせて、体験から得た知見が綴られています。そしてだいたい「だからお前もこうしろ」ではなく「君には君の現場があるのだから、君が考えて振る舞うんだ」といった論調で全体がまとめられているのです。

それぞれの章には一人称の「ストーリー」を感じました。おかげで、自分にとってはとても読みやすかったのです。

ふと考えてみるとこれは、濱崎健吾さまが、一緒にごはんを食べているときにお話してくれる「最近はこんなことで悩んでいる」「こういうことを試してみたい」「もっとこうしていかなきゃいけないと思う」のストーリーにそっくりなんですね。ウェブオペレーションは、自分の立ち位置からすると、必ずしも専門のド真ん中というわけではないのですが、たとえて言えば、彼に読み聞かせてもらっているかのように内容を吸収することができて、とても楽しかったです。

また、同時に、彼がお話してくれる戦士の物語が、たまたま近くにいた自分がたまたま聞かせてもらえる特別なものではなく、より広く多くの人たちにも届く物語になったことを、心から嬉しく感じています。執筆、お疲れさまでした。

さらに加えて、やはり地獄の角征典さんの訳のおかげで読みやすかったのでした。本文中に「やべ！俺たちカッコいいわ。カッコいいわー」や「リア充」と言った文字列を見つけたときは、思わず声を出して笑ってしまうわけですが、伝わってくる雰囲気は、文章の流れからするとまったく違和感なく受け取れるものでした。さすがだなぁと思いました。

グッときた

本文中の気になった箇所をマークしておきます。

正しいコードの書き方を教えるのではなく、プロダクション環境での失敗から学ぶ環境を作るのだ。

4.5.1「なぜ継続的デプロイが有効なのか?」 4章継続的デプロイ

「根本原因」をもとに評価をするのは、失敗の本質に関する技術的な理解からではなく、結果に対して社会的あるいは文化的な何らかの非難が必要だったものと考えられる。

7.1「いかにして複雑なシステムは失敗するか」 7章いかにして複雑なシステムは失敗するか

一方、開発チームと責任を共有すれば、サイトの安定性やパフォーマンスが良くなることに気付いているグループも多い。開発者を全面的に信頼して、コードのダブルチェックをしなくなれば、開発者は自ずから責任感を持つようになる。

10.3「信頼」 10章開発と運用の協力と連携

お互いに助け合う環境を作るには、障害にあとに非難を禁止した「ふりかえり」を開くとよいだろう。このとき「どんな間違いを犯したのか？」のような質問をしてしまうと、自己弁護に陥ってしまう。「次はどうすればうまくできるのか？」のように質問すれば、みんなが非難をせずに改善案を提案するようになる。

10.5「非難を避ける」 10章開発と運用の協力と連携

ウェブオペレーションについて議論する前に、組織の技術標準が恥ずかしいほど低いということを正直に認めなければならない。ウェブ業界でしばらく働いていれば、それが嘘ではないことだと分かるだろう。わかっていないなら、あなたは本当に幸運か、大事に保護されているか、単なるバカだ。問題は何だろう？あらゆる技術の問題は、人の問題である。そして、解決策も人である。あらゆるバグ・障害・機能停止・復旧は、人によって行われる。

16章アジャイルインフラストラクチャ

「アジャイル」になるかどうかなんて気にするな。「すごい」人を目指せ。技術的な問題を解決するのは人だ。みんなで幸せになろうよ。

16.5「結論」 16章アジャイルインフラストラクチャ

通常、ウェブサービスのインフラエンジニアがユーザの方と接する機会は皆無に近いものだと思われるが、このフォームのおかげでインフラにかかわるユーザの声を直接受け取れるというのは、インフラ構築の指標の材料としても、エンジニアのモチベーションの原動力としても大変役に立っている。

18章日本の料理のインフラ

総じて、自分が身震いとともに読んだ文章というのは「人そのもの」や「人の成長」を対象にしたものであると、こうして全体をざっと眺めてみて気が付くこととなりました。10章の「開発と運用の協力と連携」なんかは、ここでいう「開発」と「運用」をそれぞれまったく別の言葉に置き換えたとしてもそのまま言えるようなことがふんだんに書かれていて、それは、結局はチームの構成単位は「人」に他ならないことのあらわれだと確信します。16章の「アジャイルインフラストラクチャ」では「技術的な問題を解決するのは人だ」と言い切っています。これも、とてもしっくりくるものでした。18章の「日本の料理のインフラ」では「エンジニアのモチベーション」という表現で、人への注目があります。

本書を読み終えた直後に、ちょうど、濱崎健吾さまと面と向かってお話する機会にも恵まれて、技術者が自分の価値を相手に認めさせることと、技術をコモディティ化して自分への依存を排除することと、その間にある葛藤について意見を交わしました。なかなかに頭の痛いお話ですが、自分たちエンジニアにとっては、決して目を背けることはできないトピックであるとも思います。

そうなったときに残るものはなんだろうか、と考えると、自分の「成長」を信じることなのかな、と今は思います。たとえ専門分野が変わったとしても、置かれた環境が変わったとしても、できることといえば、その場での自分の役割をまっとうし、最高を求めて終わりのない旅をすること、くらいですよね。だとすれば、本書「ウェブオペレーション」に綴られているウェブオペレータたちの武勇伝から自分が学び取るべきことは、まさに、そこにあるはずなんです。

さてさて。引用はしないけれど、自動化のための Vim スクリプトのお話と、その訳注も面白かったです。