準二級.jp

WEB+DB PRESS Vol.63｜gihyo.jp … 技術評論社

ご縁がありまして、もう数年に渡って愛読している WEB+DB PRESS において、Ruby の連載を担当させていただくことになりました。最初にお話をいただいたときは、これまでに連載を担当されてきた先人の面子を見て頭がクラクラしたりもしましたが、お打ち合わせを経て、編集さんからも「この内容ならオーケー」と GO サインも出て、ありがたく引き受けることにしました。全6回の担当、おもしろい記事を書けるように、もうひとりの担当である @kei_s とともに日々をがんばります！

もし記事を読んで「えっ」とか「おおっ」とか「んっ…」とか感じることなどあれば、よかったら著者までお知らせください…！

WEB+DB PRESS Vol.63 竹迫 良範 和田 卓人 角田 直行 はまちや2 上谷 隆宏 青木 俊介 大塚 知洋 生尾 剛士 大和田 純 白土 慧 じゅんいち☆かとう 太田 昌吾 小野 修司 ミック 嶋田 裕二 個々一番 みやけん 清水 亮 おにたま 中島 聡 技術評論社 2011-06-24 by G-Tools

技術評論社さんと

技術評論社の皆さんと一緒にお仕事させていただくのは、RubyKaigi2009 のレポート班で、技術評論社の高橋さん・池田さんと同じチームのメンバーとして gihyo.jp に RubyKaigi2009 スペシャルレポート を書いたところからはじまり、その直後に発売された WEB+DB PRESS Vol.52 (2009) では RubyKaigi2009 のまとめ記事を書きました。翌年の RubyKaigi2010 のときにも、2009 のときと同様に RubyKaigi2010スペシャルレポート を書くことができました。その後、自分は RubyKaigi のレポート班を卒業 (ネガティブな印象を与えないように、脱退ではなく卒業という言葉を使うのはハロープロジェクト由来) する運びになり、RubyKaigi2011 では、現行のレポート班のメンバーたちに「いいから、お前は実行委員の仕事に専念しやがれ。二度とレポート班から出てけー！」と罵声を浴びせられる涙のストーリーがあったとかなかったとか。

そんなこんなで、晴れて自由の身になった自分でしたが、今年も例年以上に技術評論社さんにはずいぶんとお世話になりそうです。どうぞよろしくお願いいたします！

連載開始までのお話

裏話っぽい裏話はぜんぜんないのですが、連載タイトルについては少しだけ書いておきましょう。自分たちが担当する連載のタイトルは「Rubyわくわくナビ」です。かわいらしい挿絵までつくってもらっちゃって、とても嬉しいです。

実は、このタイトルに落ち着くまでに、自分たちが提出したタイトル案は、まるっとすべてことごとくボツになりました。自分の推しタイトルは「Ruby cruising Love」だったのですが、とても静かにスッとお蔵入りしました。

もし他のボツ案に興味があったら、わたしたちに話しかけてみてください。連載の裏側には「記事を書く」以外のこういった時間の過ごし方もあって、めいいっぱい楽しませてもらっています。

ここで一度、謝辞

連載自体はこれからしばらく続いていくので、まずは、今の時点で言っておきたいお礼を。

連載担当の候補者として、自分たちを、技術評論社の編集さんに紹介してくださった人。そんな人がいたような気配がするので、どうもありがとうございました。編集の池田さんにおかれましては、こちらの疑問に丁寧にご回答いただき、不安に思っていることを相談すれば、それを取り去るようにご配慮いただき、おかげさまで、気持ちよく執筆に当たることができました。ありがとうございます。

また、第1回の記事のレビューは、Ruby のコミッタである村田賢太さんにお願いし、すぐにご快諾いただきました。ありがとうございました！レビュー結果を反映させたところ、Ruby に関する記述で、ふわふわしていた箇所が、一気にパキッとしました。頼もしい先輩です。助かりました。

今はこれくらいで、あとは、連載が無事に終わったときにでも。

まとめ

WEB+DB PRESS にて、Ruby の連載を担当させていただくことになりました。タイトルは「Rubyわくわくナビ」です。全6回の連載になります。第1回の記事が WEB+DB PRESS Vol.63 に掲載されています。どうぞよろしくお願いしますー！

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

O’Reilly Japan – ウェブオペレーション

「まえがき」から

かっこよすぎて、もう。

日々、我々は少しずつ賢くなり、少しずつ知恵をつけ、少しずつコツをつかんでいった。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 スクリプトのお話と、その訳注も面白かったです。

謝辞

献本をくださった濱崎健吾さま、どうもありがとうございました。献本の相手として選ばれたことを、心から光栄に思います。執筆という偉業への尊敬と、ありのままの感謝を。

訳者の角さん、編集の高さん、この文章を (自分にとっては極めて親しみやすい) 日本語で読むことができて、助かりました。偉業に感謝します。それと、角さんの訳文を高さんがどのようにハンドリングしているのか、そのプロセスにはとても興味があります。次にお会いしたときに、質問させてもらうと思います。

上記3名さま、RubyKaigi2011 の会場でお会いできそうなので、楽しみにしています！この度は、ありがとうございました！

おしまい。