ネットの記事やブログなどで、アクセス数が想定以上に急激に増えて、泣きながらもあの手この手を尽くして耐えきったぜという武勇伝的な話があったりするが、この本に書かれているのは、事前に発生し得ることをできる限り事前に想定して、徹底的に検証することで、大きな事故も起こらず乗り切りました、という正反対な内容だった。
前者のようなジェットコースター的な展開は技術的にも読み物的にも楽しいだが、実際仕事をするなら後者のような手堅い展開の方が顧客的にも精神衛生上もいいような気はする。その辺は趣味の問題かもしれない。
以下、内容について適当に感想をまとめると
- まあ冗談半分の感想として、一章で、話がいつの間にか大きくなって（瞬間最大で10000アクセス/秒→連続10000アクセス/秒）、そんな性能必要なの？ と思えるような性能をコミットしてしまったとあったが、SEマネジメント系に一家言ある人たちが聞いたら、「そもそもそこが間違ってる、顧客にとってもベンダーにとっても納得いくラインを交渉して妥協すべきだ」的な話が展開されるんだろうな、と。
- 短い納期にも関わらず性能を出すために新しい技術に手を出したってところはすごいと思った。自分だったら調査している間に納期が来てしまいそうだ。業務では使っていないけど普段から新しい技術へのアンテナを張っていたから選択し得たのだろうか。
- 性能検証のところで、クライアント用途としてAWSのようなスラウドサービスを使うってのは参考になった。機会があったら提案してみようかしら。手持ちの機器では不十分だと説明するのが大変そうだが……。
- 「映画や劇場で携帯電源ＯＦＦにすべきところへ行くと落ち着かない」とか「10分ごとにメールを確認する」とか監視当番の方がついやってしまう行動については共感した。自分も監視当番のときに映画見に行く時って結構罪悪感を感じるのよね。だからと言って見に行かない選択肢をとると、それはそれで業務時間でもないのに行動を拘束されるなんて、と負けた気がする……。
こういった本を読むと、開発、インフラ、運用が一丸となって問題解決に向かう形ができれば、作って提供する側にとってもユーザ側にとっても一番いいんだろうなと思う。
ただ、現実は自分の会社を含めて、多くの場合、会社やら部署の壁（会社の壁より部署の壁のほうが高く厚い場合があるから恐ろしい限りだ）で連携しにくい環境だであることと、またすべての案件で全力投球、専属の人をアサインしていったら、事業がスケールしていかない可能性があるので難しいところだなとも。
新しいサービスを作ったり案件を受注した時にまた読むとよさそう。
