【読んでみた】THE PHOENIX PROJECT-The DevOps 逆転だ！-

こんにちは。

今回は技術書とはちょっと違う本のエントリです。

目次

読んだ本

The DevOps 逆転だ!

中身は技術書ではなく、小説になっていて

読み進めていくにつれて、立ちはだかる問題を解決していき

IT部門のあるべき姿が見えてくるようになっています。 

本の目次

第１部　VP就任の余波

第２部　IT運用の仕事

第３部　プロジェクトマネジメント

第４部　ビジネスとIT

第５部　究極の組織 

なんでこの本を読もうと思ったの？

職場の方から「これ読んでみてくださいー」とお借りしました。

ちょうど先日『チーム開発実践入門』読み終わって、

「あー、デプロイ自動化大事だよなー、やりたいよなー」と

思ってた矢先に絶妙なタイミングでこの本を渡してくれたので

「え、この人もしかしてここのブログ見てる？」と内心びっくりしてました（笑）

でも本当にこうやって本を貸していただいて、たくさんの気づきを得ました。

あらためて貸してくださった方にお礼を。ありがとうございました！

要約（あらすじ）

小説なので、ネタバレすると困る方もいらっしゃるでしょうから

表紙カバーに書いてるあらすじを引用します。 

3000人規模の自動車部品製造販売会社パーツ・アンリミテッドで

ミッドレンジシステム運用部長を務めるビル・パーマー。

 彼はある日突然、CEOのスティーブ・マスターズからIT運用担当

VP(バイスプレジデント)に任命された。

社運を賭けた、店頭小売とネット通販を統合する新システム「フェニックス」を３か月以内にリリースせよ。さもないと、IT部門はアウトソーシングする、と告げられる。

とんだ就任に不安を覚えるビルの前に、取締役候補のエリック・リードが現れ、プロジェクトの成功に欠かせない「４つの仕事」と「３つの道」を

見つけるように言い渡される。

ビルは仲間とともに数々の危機を乗り越えるなかで、

開発(Development)と運用(Operation)が一体となっていく

システムを開発させていく「DevOps」に目覚めていく。

 感想・気づき

アメリカのIT現場も悩み事は日本とたいして変わらない？

というのがこの本を読んだ第１印象でした。

自分の勝手なアメリカのIT現場のイメージは、

ITの本場だからいろんな技術を駆使しまくって日本よりもスムーズにプロジェクトが回っていて

「徹夜って何？おいしいの？徹夜するわけないじゃーん毎日定時帰りだっつーのー」

くらいだと思ってたんですが、

悩んでいることはあまり変わらないんだなと思いました。

悩んできたからこそ、いろんな技術や知識体系が生れてきたんでしょうね。

じゃあどうして日本のIT現場はとかくダメだと言われるのか？

アメリカも日本もおんなじ悩みを抱えているのに

どうして日本のIT現場はひどいひどいと言われるのか？

色々考えてふと思ったのはいわゆる「よその会社」という存在ではないかと。

アメリカのシステム開発はもっぱら内製（自社でIT部門をもってシステムを作る）だと

なんかのニュースで見たことがあります（ソースなくてすみません。。。）

今回の本に出てくる「パーツ・アンリミテッド」も自社のIT部門を持っています。

一方、日本では自社で内製しているところもあるけど

いわゆる「SIer」がお客様に要件を伺って、システムを設計し、開発し

プロジェクトを回す（こともある）というスタイルが主流。

うまくいえないけど、プロジェクトの企画、システム設計、開発、運用

各フェーズでいろんな「よその会社」が入り込んで仕事をしているわけです。

パーツ・アンリミテッドのように自社の中でもリソース調整やら他部門との

絡みでめちゃめちゃ揉めるのに、日本みたいによその会社が一枚かんだら

なおのことうまくいかないよなぁ、と。

ベンダーから問題点を改善しようと提案してもなかなか通らないし、

仮に通っても時間を要する。まったくスピード感も出ない。

それ以外にも日本独特の文化が色々阻害してるのもあるんだろうけど。。。

ボトルネックになっているプロセスを見直し、改善しない限り小手先の技術で何かやっても無駄。

世の中には素晴らしい技術が日々すごいスピードで登場します。

が、それを使う「プロセス」そのものがダメだと何をやっても無駄。

• ITを使ってビジネス上の何の課題を解決したいのか？
• スループットを上げるにはどうすればいいか？

根本的なところからIT技術者も入り込んで

一緒に上記の課題を考え、解決してていくことが重要だなと思いました。

フェーズごとで分けたらやっぱあかんと思いました。

こまめなデプロイを可能にするには

バッチサイズ（一度に行う作業量）が大きいと「手戻り」が大きい。

「手戻り」こそが一番の無駄。

 だから、バッチサイズ（一度に行う作業量）を小さくすること。

そして、デプロイプロセスを自動化すればこまめなデプロイを可能にする。

今までやってきたプロジェクト見てて思うことだけど、

リリースするときにあれもこれも詰め込みまくりやもんなー。

そんだけ詰め込んだらそら本番環境でトラブルし、実際トラブってるし

リリースも半年に１回だし（バグ対の緊急リリースは除くがそれでも遅い）

やはりスピード感が出てないですよね。

今の自分ができることは何か？

今の自分は職場で派遣入場しているしがないエンジニアです。

最近は少しずつですが取り纏め的な仕事も任せてもらうようにはなりましたが、

この小説に出てくるビル・パーマーのような大きな権限を持った人間ではありません。

（そもそも運用じゃなくて開発畑の人間ですし）

だから何もできないのか？そんな自分に何ができることはあるか？

この本やこれから学んでいくであろう知恵や気づきを提案という形でOUTPUTすること

なんだろうなと思いました。

テスト自動化、デプロイ自動化、チケット管理、ソース管理・トレース・・・

今後はチーム全体の生産性・品質・保守性を上げる手法を学んで

チームの、ひいてはプロジェクトの役にたっていかねば。

これからももっともっと学んでいきます。