『Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち』を読んだ。
公式情報は、下記の直販サイトを読んでいただくとして。自分は雑に感想を書こうと思う。
Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち（紙書籍＋電子書籍）www.lambdanote.com
等身大の開発者たち
読むのを止められなかった。
自分はあんまり PDF で読書をするという習慣がない。気分の問題でしかないのだけど、紙の本のほうが好きだ。ラムダノート社の本を買うときもPDFと紙書籍の両方を買っている。読むときは紙が届くのを待つ。
それが、今回はちょっと読んでみるかと Google Drive の iOS アプリから PDF を読んでみた。はじめにを読んで、そのまま止まらなくなってしまった。昨晩は（あと一章、もうあと一章...）とか思ってたら4章まで読み終えていた。午前2時くらいになっていたのでさすがに寝て、今日起きてまた読みだして、やっぱり止まらなくてすぐさま全部読み終えてしまった。
何がここまで引きつけたのか。それは等身大の開発者、現場について書かれている本だからだと思う。
自分も一応ソフトウェアエンジニアとして、（改めて言うと恥ずかしいけど）開発の最前線にいる。だから身に覚えのある話がいくつかあった。
正直なところ自分は技術屋というよりもビジネスマンだと思っていて、ソフトウェア開発は事業のためにやっている、という感覚が強い。自分がコードを書くのが好きだとか嫌いだとか、このプログラミング言語やフレームワークは好きとか嫌いとかぶっちゃけどうでもいいとさえ思っていて*1、プロとしてソフトウェア開発をする以上はその事業にあるべきシステムを考えるのが最優先だろうと思っている。
だから事業課題に対して技術で取り組んでいる姿に対してすごく共感を持ったし、自分もかくありたいと思う開発者たちの姿が描かれていた。
生々しい課題解決
さて、口では立派なことを言っているが、正直なところ自分でも最近の自分の業務に対する姿勢を苦々しく思っている。日々問い合わせやアドホックな修正、改善に追われていて、目の前にある巨大すぎてどこから手を付けたものかわからなくなっているような問題*2に目を背け続けている。
そして本書はいくらかの章でそうした巨大な問題に（時間をかけて）向き合って解決した話が書かれている。特に5章のサポーターズのリプレースの話は顕著で、ビジネスとシステムが乖離している状態から、ビジネスに合わせてシステムを再設計し、新システムをリリースするまでのことが書かれている。途中でエンジニアと営業の方とのコミュニケーションが変わった話だったり、新卒採用というドメインの特性を利用してリプレース戦略を立てた話だったり、かなり現場で実践ししたことと、実践するにあたっての背景が詳細に話されている。
全体に共通するのは、「生々しい」ということだ。ECナビ（3章）では半年かけてレガシーシステムをオンプレからクラウドに移行した話とその課題、サポーターズの話では0と1しか入らないはずのカラムになぜか2が入っていて、誰もその経緯も理由も、アプリケーションがどう扱うべきかも知らなくて困ったなど。出てくるエピソードがとにかく生々しい。
生々しさゆえ、読んでいても爽快感を覚えることはない。しかし、事業に向きあう開発者を美化せずに描いているし、そして課題解決の過程がとてつもなく面白い。
現実的なチーム
そして、ちょっと悔しい。
たとえば Team Geek のような本を読んでいても「こんなチームを作れるなんて、俺たちにもできるはずなのに！」とはあまり思えない。海の向こうの法律も文化も何もかも違う人たちと全く同じチームビルディングはできない気がするし、どこか他人事のように思えてしまう。
でも本書は同じ国内で、登場人物も（たぶん）日本人ばかりで、同じ土地で同じ言語を扱って同じような文化のもとで働いている。数億円突っ込んで解決したみたいな再現性のなさそうな課題解決の仕方もない。誰かが何らかの力を割いて、コストパフォーマンスを考慮しながらコツコツと課題を解決していく。
ちょっと自分たちにもできそうな気がするのだ。でも実際には一朝一夕で積み上げたものでもないし、とても難しいものなのだろうと思う。そうした難しいことを、コツコツとやってきた人たちがこの日本にいる。
それがやっぱり悔しい。今の自分だけでは多分できないと思うけど、自分が手も足も出ないような状況にいるわけではないはずだから。自分もそういうチームや組織を作りたいなと改めて思う。
インタビュアーのコメント
自分の気持ちしか書いていないので、自分が本書の魅力的だと思ったところを書く。
ところどころで、和田さんのコメントが的確で、すごくうならされる。例えば、下記のコメントはチームの（ひとつを取り出すとちょっと奇抜とも思われるような）文化を受けてのコメント。
2000 年くらいにXP が出てきたときのことを思い出しました。あのとき、ケント・ベックが書いた本を読んでも、それだけでは「なんでこのやり方でうまくいくの？」というのが全然わからなかったんです。
XP を解説した本では、いくつかのプラクティスが示されているんですが、一つひとつの プラクティスを見るとすごく無茶なものもあったりします。でも、実はそういう個々のプラクティスが補完しながら、全体の系としてうまく回るようになっているんですよね。
Zucks のエンジニアの文化も、そういうふうに回っているのかなと思いました。「ドキュメントがまったくない」とか「全員がフルサイクル」みたいな個々の話を聞くと無茶に思えるのですが、それが組み合わさってうまくいっているような気がします。
（第2章の 73-74p.）
ほかにもいっぱいあるんだけど、いっぱい引用しちゃうと楽しみを奪ってしまうのでこれくらいで。
こうしたコメントで、読者側の頭を整理されるし、また基本的に常に「この話の流れだとそれを聞きたいよね」と思えることを質問してくれているので大きな引っ掛かりもなく読み進められた。これはもう、単純にすごいなと思った。
まとめ
自分はなんだかんだ、やっぱり事業が一番大事だと思っている。お金を稼げない、ひいてはユーザーの価値につながらないのに一生懸命コード書く、というのは（ビジネスの場では）よくないと思う。
2010年代にビジネスをやっていた人たちの体験談、苦労話、これからの展望まで変にきらきらしてなく、生々しい現場感のある話が取り揃えられているのは、とても稀有な本だと思う。
改めて、これからの自分の仕事の姿勢も襟を正して、もっと積極的にものごとに取り組んでいきたいと思った。（開発者に限らず）ソフトウェア開発にかかわる人には、ひとつは琴線に触れるものがある本だと思う。
