The Phoenix Projectという本を読んだので適当にまとめます。(日本語版はこっち)

この本は小説形式でDevOpsの手法が学べる本です。アジャイルだとかカンバンだとか開発手法のいろいろな本をよんだのですがいまいち煮えきらなかったので探してたらこの本に出会いました。

Amazon.comではレビューが3800近くもついています(Clean Architectureは415、リーダブルコードの日本語版は132です)。ここまでレビューがたくさんついてるなら読んで損はあるまい。ということで読みはじめました。

読み終わって頭の中に残っていたことを感想も交えてまとめます。なので以下は本のサマリーではありません。記憶違い大いにありえます。私が勝手に解釈をかえたところもあります。大事だと思ったことだけ書いてあるので漏れも大いにあるでしょう。

この本は誰のための本か?

モダンな開発手法を使う企業に務めるWebエンジニアが読んでもよいです。が、企業のIT部門で社内向けシステム、社外向けの製品(Ex: ECサイト、受発注システム)の制作に関わる人がいちばん向いています。作中ではサーバーは一部仮想化しているが、オンプレもあるし、バージョン管理システムっぽいものは使っていないし、チケット管理なんかも社内で作ったシステムを使っています。開発は普通のウォーターフォールです。

製品をさっさと出したいのだけど、なぜかいつの間にかプロジェクトが遅れていく、予算だけ積み上がっていく。働けど働けど仕事終わらず。じっと手を見る。そんな感じです。

何が学べるか

基本的に登場人物が試行錯誤していく課程が書いてあります。ここら辺がまだるっこしい。加えて「これをやったら全部うまく行く」的なことは書いてありません。TOCの理論も重要ですが、「みんなで試行錯誤して改善していく課程を作ること」というのが多分いちばん大事なのかなと思いました。それを教えてくれます。

マネジャーが「アジャイルで行くぞ!カンバン使うぞ!俺について来い!」と言うても上手く行きません。みんなで話し合って問題をひとつづつ解決していくのが重要なのです。なので、この本に出てるツールを全部使わなくてもいいかもな、と思いました。

例えばわざと障害を発生させるカオスエンジニアリングとか、インフラのコード化とかも後半で触れてます。が、別にそこまでやんなくてもいいと思います。必要だとチームで思ったのであればやればいいのです。いくつかの原則を守りながら、みんなで話し合って改善を重ねていくのが一番大事なのです。

大事な原則1 ボトルネック

エリヤフ・ゴールドラットのTOCからとっています。

作業には必ず一番遅いところ(ボトルネック)がある
ボトルネックを早くしない限り成果物は早くでてこない
ボトルネックにかかわらない改善は無意味である
ボトルネックを特定して、キャパをあげ、常に可動するようにすべき

だいたいこんな感じです。詳しくはThe Goalとか読んでみて下さい。生産管理を勉強すると必ずこの本が出てくるぐらい有名です。

例えば、あるチームではレビュワーが1人しか居ないのでコードレビューに一番時間がかかってるとします。そんなチームのメンバーがエディターのショートカット覚えたり、スニペットたくさん作ったりして、早くコードが書けるようになったとしても、あまりスループット上がらないですよね?ボトルネックであるレビューを早くできないか考えたほうがもっと効果があるでしょう。

大事な原則2 マルチタスクはダメ

仕事には大きく分けて4つあるようです。

会社の事業に関わる仕事(ex: 製品を作る)
開発部門に関わる仕事(ex: DBのバージョンアップ)
ちまい修正作業(ex: サーバーの設定変更)
急ぎの仕事(ex: サイトが落ちた!!)

です(これ、私の勝手な解釈です、本とは若干違います)。

上3つはだいたい予定されているものです。見積もりが正しければ計画通りに全部が終わります。急ぎの仕事が入ってくるから永遠に仕事が終わらないのだ、と。そりゃそうですね。トラブルばっかりの職場だと永遠に新機能とかリリースできません。

システムの全容を知っている長老みたいな人が1人いるとします。すべて彼のレビューを通さないとダメ。みたいな環境で4つの種類の仕事を並行してやってたらどうでしょう?長老の前にレビュー待ちが延々と積み重なるだけですね。

作中では「すべての仕事を一旦停止して1の仕事だけやる」、という豪快な判断をしています。そこまでやるこたないだろ、と思いますが重要な仕事を一番早く終わらせる、という意味では正しい判断です。

大事な原則3 仕事を可視化する

GitHubのIssueが延々と積み重なっていったりしませんか?「このバグのIssueなに?」「なにこれ・・・?いつのやつだよ・・・」「あれ?この機能もうないよね。」とか。一回棚卸ししてみたほうが良いですね。

作中でもやる必要のある仕事をひたすらあつめてカードにしてまとめています。その上でやる必要のない仕事は捨てたりしています。で、後半部分で仕事の進捗管理にカンバン・ボード(おなじみ!)を使っています。

仕事を可視化していくと、仕事の完了に必要な課程が見えてきます。「よくやる簡単な仕事だけど意外と人の手がかかる」みたいな仕事も出てきます。例えば作中ではオンプレサーバーに関する変更(だったかな?)をするのにあっちゃこっちゃの人が作業しないといけない様子が書かれています。こういうよくやる簡単な仕事に「長老」が必要だと最悪です。

仕事の可視化を通して属人化を解消していくようなことも必要です。

大事な原則4 Three Ways

仕事はやったらやりっぱなしじゃダメですよね。やり方を改善していかないと。
作中では仕事の進め方に3つの段階があるといいます。

第1段階ではひたすら仕事のスループットをあげること。
第2段階では仕事の課程で知見を吸い上げるフィードバックループを作ること
第3段階では試行錯誤を通じて改善を積み重ねていくこと。

だそうです(ここも私の勝手な解釈が入っています)。

作中でも1,2,3と段階を登ってだんだんとチームが進化していきます。一番大事なのは、みんなが正直に意見を言い合って改善していくことなのかな、と思いました。マネージャーが1人で勝手にいろいろ改善をやってもダメです。

作中ではそのあたりの試行錯誤が非常にまだるっこしいです。途中まで「早く正解を教えてくれよ」とか「やっとカンバンが出てきたか」とか上から目線で読んでました。が、途中で考えが変わりました。

これ、まだるっこしい試行錯誤の課程が一番大事なんだと思います。

カンバンやらGitHubやらDockerやらのモダンな手段をたくさん使ってても、みんなで試行錯誤して改善する習慣がなければ結局パフォーマンスはあがらないわな。と思いました。

続編もあるみたいです。そのうち読むかなぁ・・・