Book

DevOpsは最近ではバズワードでもなんでもなくて、 普通に考えなきゃいけない概念になってきました。

と言っても自分の周辺ではまだまだという感があるので、 とりあえず軽い気持ちで読んでみたのが本書です。 あまり考えずに買ったので、物語調で始まった時には少し面食らいました。

内容

ボロボロのIT組織を立て直していくサクセスストーリーです。 新規開発は遅れに遅れ、リリースしたものは障害を繰り返している中で、 最後にはビジネス・開発・運用の流れをスムーズににし、DevOpsで大逆転という内容です。

DevOpsの周辺技術についての解説書ではありません。 組織の根幹を支えるITをどう作り上げて行くか、組織論的な内容です。

特に面白かった所

同じ業界の人間なので、最初のうちはあまりの試練に身につまされる思いでした。 その分、DevOpsに対する甘い考えだけでなく、そこに至るまでの苦労を追体験することができました。 DevOpsに至るまでに組織をどのように変えていかなければならないかを知るいい手がかりになりました。

考えたこと

新たに動くものを立ち上げること、動いているシステムに手を加えるという変化は、 常になんらかの障害と隣り合わせです。 このリスクをコントロールして変化のスピード上げて行ったところが、ビジネスで成功を納める。 当たり前ではありますが、まだまだできていない組織が大半ではないでしょうか。

本書ではそんな当たり前とは程遠い、ITとビジネスが足を引っ張りあってる状態からスタートしています。 こんなダメな状態がよく聞く話だったりして、共感とともに危機感が湧きました。

こんな足の引っ張り合いは、組織的・技術的両面で解決していかなければならないことなのですが、 今の世の中では技術的側面はずいぶん整備されてきたと感じます。 となると、残る難題は組織的な部分なわけですが、ここはなかなか特効薬はありません。 そこでDevOps完成後の理想である「1日10回リリース」みたいな、わかりやすい指標を持つのが、一つの解だなと感じました。

まとめ

物語とはいえ、組織と技術の両輪がうまく回った時にこれだけの良い流れが作り上げられて行くのかと。 翻って自分の周辺を見渡すと、両輪ともまだまだという感じ。 とはいえあがいて見ようかなという勇気を本書がくれたのも確かでした。

昔はWebAPIを作る事が多かったんだけど、ここ数年はすっかりインフラ寄りになって、機能寄りの設計をやらなくなってました。 そんな中に読んだのが、Web API The Good Parts。 技術書の中にはかつての自分の成果物に赤面してしまう本が多々ありますが、この本は赤面度上位に位置しますね。

内容

大きく分けるとエンドポイント、レスポンス、HTTPへの準拠という点に関して細かいところにまで突っ込んだ考察を繰り広げてくれます。 実例なんかもあげてくれるので、理想と現実という部分にも配慮されています。

特に面白かった所

プログラマーならプログラミングをする上で変数の名付けというのには意識を向けるものと思います。 そういった名付けにも通じる内容なのですが、エンドポイントやレスポンスに関して、WebAPIの世界で改めて説明されると新鮮なものがありました。 あとは、最近インフラ屋として関わる事が多いHTTPプロトコルをいかに利用するかという内容。 インフラもアプリケーションも両方経験してきた中で、自分の中の溝を埋めてくれるものでした。

考えたこと

普段何気なく使ってるAPIですが、こういった設計の指針を包括的に提示してくれる本は本当に貴重ですね。 そして何よりも、自分のアプリケーションの知識が時代遅れになっていることを痛感しました。 Rest Level3って知らなかったなー、Martin Fowlerさん、こんなところにも出てくるんですね。

そして、こういったアプリケーションの設計に関する本も読んでおかないと、 その基盤であるインフラに何を求められているのか、どう使われているのか、おざなりになってしまうと感じました。

まとめ

冒頭に書いてある通り、赤面する事この上なかったです。 今後自分の関わるWebAPIはできる限り恥ずかしくしたくないものです。 とりあえず、今のプロジェクトでこの本で学んだことを発表しておきました。