IT版「ザ・ゴール」 – 読書 – The DevOps 逆転だ! 究極の継続的デリバリー

DevOpsという言葉は、Development(開発)とOperation(運用)という2つの言葉を組み合わせた造語です。この言葉は最近流行しているキーワードだったりするのですが、僕が仕事で所属しているチームの業務と密接に関わるキーワードでもあります。チームが、そして僕自身が、これからしようとしていることは一体どんなことなのか、どこに向かおうとしているのか、少しでもそのヒントになればいいなと思い、発売前に予約して読んでみました。

本書を読んで、思ったこと感じたことを、パラパラとメモしておこうと思います。本書は小説なので、ネタバレが嫌な方 はこの記事の続きを読まないほうがいいかもしれません。そんなに大したこと書きません(書けません)が。

The DevOps 逆転だ!    究極の継続的デリバリー
The DevOps 逆転だ! 究極の継続的デリバリー

IT版「ザ・ゴール」

上にも書いたとおり、本書は小説です。ある企業のIT運用 VP(バイスプレジデント)に昇格した主人公が、炎上しっぱなしのIT運用部門やソフトウェア開発プロジェクトを、様々な障壁を乗り越えながら成功へと導いていく物語です。

物語中、主人公は様々な壁にぶち当たります。一人で考えても、チームのみんなと考えても答えが出ない、そんな状況もあります。幸運にも主人公には、そんな時に助言をくれる、頼りになるアドバイザーが存在します。答えを全部教えてくれるわけではなく、主人公自身が考える余地を残してくれる、素晴らしいアドバイザーです。主人公は彼の助言をもとに考え、様々な困難を乗り越えていきます。

この構図は、有名なビジネス書「ザ・ゴール ― 企業の究極の目的とは何か」にとても似ています。主人公と、そのアドバイザーとなる人物の存在。炎上しているプロジェクト(ザ・ゴールだと製品の生産プロセス)。主人公が何かを学ぶたびに、徐々に解決されていく問題。プロジェクトが成功に導かれていく過程。

ザ・ゴールのテーマは「工場の業務改善プロセス」で、本書のテーマは「ITの業務改善プロセス」である、というのが2冊の本が大きく異なる点です。それ以外の点ではすごく似ているのですが、実はこの2冊の本の間には、単に「似ている」だけではない、もう一つのの関連性があります。

TOC(制約条件理論)のITへの応用

ザ・ゴールは、TOC(制約条件理論)の基礎が学べる本として定評があるビジネス書です。今から10年以上前、まだ僕が学生のころに読んで、とても勉強になりました。

TOCは「全体のスループットは、ボトルネックとなるプロセスによって制限される」「だから、ボトルネックのスループットを改善することでのみ、全体のスループットを改善できる」という前提を基礎とした理論です。ボトルネックの前工程を最適化しても、ボトルネック直前の在庫が増えてしまうだけ。ボトルネックの後工程を最適化しても、後工程が暇になってしまうだけ。だから、スループット向上のための改善施策は、すべてボトルネックに対して行わなければなりません。

本書のある場面で、ザ・ゴールやTOCについて、主人公のアドバイザーが言及するシーンがあります。それをきっかけとして、主人公は、TOCに基づいた改善を実施していきます。具体的には、以下の様な施策を実施していきました。

  • ボトルネックの特定(本書の場合は特定の優秀なエンジニアだった)
  • ボトルネックの徹底活用(彼に予定外のタスクや、重要でないタスクをやらせないようにした)
  • ボトルネックのスループット改善(彼の作業効率が改善する見込みのある施策を優先的に実施する)
  • ボトルネックの負荷分散(彼の頭にしかない知識を文書化し、他のエンジニアも彼のタスクをこなせるようにした)

結果として、ザ・ゴールで語られていた、工場の業務プロセスにおけるTOCの活用事例が、ITの業務プロセスに見事に応用され、どんどんプロセスが改善されていきます。主人公が、工場の業務改善のための理論や考え方が、ITに本当に効果があるのかどうか懐疑的になる場面がありましたが、やってみると実際に応用できたのです。ITの業務プロセスを図で可視化すると、工場の生産プロセスそっくりになったシーンがとても印象的でした。

ザ・ゴールと本書の話の構図が似ていることも相まって、TOCは工場だけではなくITにも応用できるということは、僕の頭のなかに強く残りました。

運用からみたDevOps

話を変えて、DevOpsの話題に。

今まで、僕自信がDevOpsのDev、つまり開発の人間だからかもしれませんが、今までDevOpsというキーワードについて考えるときに、無意識に「開発」を主語にして考えることが多かったです。まず、最初に開発があって、その後に運用がある。Web上のDevOps関連の記事も、(そんな頭で読んでいたからかもしれませんが)そういう論調のものが多かったような印象があります。でも、そういった考えや論調は間違いです。

本書の主人公はITを運用する立場の人間です。物語は基本的に運用の視点で進んでいきます。特に物語序盤は、運用からみた開発は「動かないコードをデプロイしろと言ってくる」敵です。そんな視点が、僕にとってはとても新鮮でした。

DevOpsで重要とされているのは、以下の3つの要素です。本書では「3つの道」と表現されています。

  1. 開発から運用へのスムーズな展開・スピードアップ
  2. 運用から開発へのフィードバックループの強化・短縮化
  3. 上記ループを反復/継続することによる学習

つまり、DevOpsが実現するのは、開発が先でも、運用が先でもなく、両方が延々と回り続ける無限ループの世界です。

それぞれの専門領域を大切にしつつも、立場を超えてお互いが密接に関係しあわなければ、理想的な世界は実現できません。物語後半では、最初はいがみ合っていた運用と開発も、密接に関わりあい、お互いが混在した小さなチームを作ることで、重要なプロジェクトを成功へと導いていきます。

そんな世界では、「開発と運用ではどちらが主か?」なんて議論は無意味。あえてかどうかはわかりませんが、運用からみたDevOpsを語る本書は、そんなことに気付かせてくれました。僕自信の認識を正しい方向に変えることができたように思います。

あれ?継続的デリバリーは?

物語の終盤、主人公は1日10回デプロイできる環境をつくることを目標に、さらなる業務の改善を試みます。ここでようやく登場するのが、本書のタイトルにもある「継続的デリバリー」という言葉。

実は、本書では継続的デリバリーの詳細にはあまり触れられていません。バッチサイズを小さくしたり、開発、品質管理、本番環境の構築を自動化したり、それらの環境差異を最小化したり、といった手段の概要については語られますが、詳細については「継続的デリバリー」を読んでね、という感じです。小説で各論を語るのは難しそうですもんね。

本書で、継続的デリバリーの重要性や効果を理解することはできるので、次のステップとして各論を知りたい人は、是非この本も読んでみるのが良いと思いました。(まだ読んでない。)

おわりに

主人公が様々な困難に立ち向かい、周りの人や組織を巻き込みながら、成功への道を歩んでいくというサクセスストーリーは、小説として純粋に面白く、読み始めたら熱中してすぐに読み終わってしまいました。

読むスピードが早過ぎると、内容が頭に残ってないことがよくあるのですが、本書は読み終わった後に、実際に仕事で試してみたいことをいくつか思いつくことができたので、それだけ自分にとって有用な、タイムリーな本だったんだなと思います。実践あるのみです。

こんな滅茶苦茶な読書感想文でしたが、ITに少しでも関わる方でまだ読まれていない方は、是非読んでみてください。きっと、自分の仕事に明日から使える何かを見つけられると思います。

それでは以上です。ここまで読んでくださった方、ありがとうございました。