ブログ

ryuzeeによるブログ記事。不定期更新

直近開催のScrum Alliance認定スクラムマスター研修のご案内

【書評】ウェブオペレーション - サイト運用管理の実践テクニック

みなさんこんにちは。@ryuzeeです。

訳者の角征典さん(@kdmsnr)より献本いただきました。ありがとうございます。

ウェブオペレーションという言葉は知らなかったのですが、「ITシステム管理の専門分野で、ウェブアプリケーションの開発・運営・保守・調整・修理を含む」ものだそうです。

僕自身は1997年にこの業界にはいって1999年くらいからはWebアプリケーションの開発、運用をずっとやってきて、ウェブアプリケーションをちゃんと動作させることにかなりのパワーを使ってきました。 2002年から2009年までは大手SIerのWebシステム・Webサイト開発部門の管理職で、数十のサイトの開発・運用をしていて、毎晩毎晩熟睡の時間中に携帯電話がなる生活でした。 そのうち夜中に枕元においた携帯が電波を捉えた瞬間に電話がなる前に目が覚める、という技を身につけたほどです。 この本が当時出てたら僕は寝不足にならなかっただろうなと思います。

この本は体型だった知識を与えてくれる本ではなく、複数の寄稿者によるウェブオペレーションに関するエッセンスをまとめたもので生の体験からできています。 今Webサイトやアプリケーションの開発・保守を行っている人にとってはとても役に立つ内容だと思います。 頭から順番に読んでも良いし、つまみ食いでも大丈夫です。

以下個人的に特に興味を引いた点のメモです。

4章 継続的デプロイ

アジャイルな話。 アジャイルな開発においては継続的統合はベストプラクティスの1つですが、さらにWebサイトの運営・構築の場合であれば継続的デプロイもベストプラクティスと言って良いでしょう。

早期のリリース(語弊がないように補足すると、もちろんリリースするためにはテストが完了している必要があります)は早期のフィードバックが得られるし、もちろん投入したフィーチャーからビジネス上の価値を早期に得られます。 早期にリリースするには1つのリリース単位を小さくしたほうが良いです。 変更箇所が多くなればなるほど問題が発覚したときの対処の時間がかかるというのは当たり前の話だからです。 このあたりの話はリーンの話と共通した重要な考え方になります。

そして頻繁にデプロイするためにはテストの自動化とデプロイの自動化が必須です。 テストの自動化自体はやっているところが多いですが、デプロイの自動化までできているところはそれほど多くはありません。 僕のところでは各サーバでコマンド一発でデプロイできるようにしていますが、まだWebのボタンを1個押せば全サーバに同時にデプロイするとか、ボタン1つで全部旧戻しする、とかはできていません。

なお継続的にデプロイするということはいつも同じペースで仕事をするということになります(Sustainable Pace)。 これは精神衛生上非常に良いことだと思います。 ビックバンリリースで胃を痛くしながら神に祈ってリリースするなんてまっぴらです。

10章 開発と運用の協力と連携

本書にある通り、Webアプリケーションの開発部隊とその運用部隊は分離しないほうが良いと思います。 冒頭書いたように僕自身は開発と運用を一貫して行う部門の管理職でしたが、開発をしていたからこそ運用しやすいアプリケーションに少しづつ改善したり、中身をよく知っているから問題の発生時に素早い対処ができました。 (もっとも夜間に問題が起き続けると日中大変なんですが…) 運用部門に紙に書いたマニュアルを渡すだけではサイトの安定運用はできません。 アジャイル屋としての言い方をすれば、サイトを作って運用するのはビジネス価値の実現のためであって、チームはその実現のために最大限の努力をする必要があり、それは社内の組織構造とか役割分担とかいう話以上に優先すべきであるということでしょう。

13章 障害を活用する:ふりかえりの技芸と科学

スクラムであればスプリントの最後に自分たちのプロセスを改善するためにふりかえりをやりますが、Webの運用においては障害が起こったときにはふりかえりは必ず必要です。 障害が0であることに越したことはありませんが、障害が発生したときが自分たちの運用プロセスを改善する大きなチャンスです。 その場しのぎの対応だけじゃ意味がありません。 プロとして一番恥ずかしいのは同じ問題を繰り返し起こすことです。 問題を明らかにして、対応の優先順位をつけてバックログ化します。 そして優先順位の高いものから着手していくと良いと思います。 そしてそのバックログはいつもみんなに見えていることも重要でしょう。

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

この本のアジャイル関係の話をまとめた章です。 筆者によればアジャイルとは「人と技術がかかわる技法」と「人と人がかかわる技法」の2つのバランスをとって活動することだ、としています。 バージョン管理、構成管理、自動デプロイ、監視などなどはもちろん重要なことですが、みんなが利益共同体の一員であるということへの意識や信頼関係も欠かすことができません。 「信頼の負債は、技術的負債やお金の負債より返済が難しい」

最後に

僕はアジャイルの観点でこの本を読みましたが、その他の章も非常に読みやすかったし素晴らしかったと思います。 12章の「ウェブにおけるリレーショナルデータベースの戦略と戦術」はWebアプリケーションを開発する人は是非知っておくべき項目ですし、6章の「監視」もそうです。 コードを書けるだけではWebアプリケーション開発者とは呼べません。 採用の際にこういう話を聞くと、よりその人の能力がよく分かるのではないかと思います。 今までありそうでなかった本。一読をおすすめします。

それでは。

アジャイル開発チーム向けのコーチングや、技術顧問、Scrum Alliance認定スクラムマスター研修などのトレーニングを提供しています。お気軽にご相談ください(初回相談無料)
前の記事 スクラムにおけるイベントと出席者
次の記事 守破離/何が偉大なスクラムマスターを作るのか

プロダクト開発で、こんな課題を感じていませんか?

  • 何を作るべきか、順位の決め方が定まらない
  • プロダクトの方向性をチームで共有できていない
  • 開発組織の体制や役割がうまく機能していない
  • 開発プロセスが形骸化し、目的を見失っている
  • アジャイルを導入したが、組織に定着しない

プロダクトマネジメント、組織構造、開発プロセスの課題について、組織全体の視点から支援します。

お問い合わせ(初回相談無料)

契約を前提にした相談でなくて構いません。相談に際して事前の整理や準備は不要です。

Aligned ―プロダクト開発におけるステークホルダーとの関係性の築き方
ダイナミックリチーミング 第2版
Tidy First?
脳に収まるコードの書き方
プロダクトマネージャーのしごと 第2版
エンジニアリングマネージャーのしごと
チームトポロジー
スクラム実践者が知るべき97のこと
プロダクトマネジメント
SCRUM BOOT CAMP THE BOOK
みんなでアジャイル
レガシーコードからの脱却
Effective DevOps
変革の軌跡
ジョイ・インク
アジャイルコーチの道具箱
カンバン仕事術
Software in 30 Days
How to Change the World