3月も中頃だけど、2月に読んだ本たち。本はいつ読んでいるかというと、通勤時の行きの電車で読んでいる(帰りは仕事している)。電車はだいたい30分で、月12回(週3回)ほどなので、だいたい6時間ほどで4冊読んでいる計算だ。今月読んだ本だとテッド・チャンの"息吹"は素晴らしかった。

CAREER SKILLS　ソフトウェア開発者の完全キャリアガイド

Soft Skillsの続編。Soft Skillsがためになったので買ってみた。ソフトウェアエンジニアとしてキャリアを築くためのノウハウについてより深く踏み込んで書いてある。

キャリアのどの段階にいるかにかかわらず、すべてのソフトウェア開発者が次のレベルに進むためのお手伝いをしたい。ソフトウェア開発者が業界内で名声を築く方法、とり得るさまざまなキャリアパス、読むべき本についてもお伝えする。あなたが次のレベルに進み、さらに特別な開発者になるために役立つサイドプロジェクト、カンファレンス、その他のテーマについても取り上げる。

"はじめに"にも書いてあるけど、読む人の現在のキャリアに応じて読みはじめるべき章は変わると思う。自分の場合は4部ソフトウェア開発者の仕事から読み進めた。そしてこの4部におけるチームワークのノウハウが一番参考になった。

一番重要なことはチームで(さらには会社で)結果を出すことなんだけど、誰でもプライドやこだわりはある。それらを尊重しつつ、チームの支えになる行動のとり方についてヒントが沢山あった。

例えば40章チームでの仕事から：

相手が助けを必要としているという感じにならないようにしてね。たとえば、次にやるべき仕事を探しているときに、ジョーが新機能を開発しているところを見たとするよ。そこでジョーに、「次の仕事に移る前に、ちょっとその新機能の仕事を手伝ってあげようか」などと言ったらどうなるだろう？ジョーは賢く、自信を持っており、他人の助けなどいらないと思っている。そんなジョーなら何と言うだろうか？「いいよ、大丈夫だよ」だろうね。

でも、ジョーにこんな風に言ってみたらどうかな。「ねえ、ジョー、君は当然その仕事を君だけで片付けられるだろうし、僕なんかが入り込む余地はないと思うけど、よかったらいっしょに仕事させてもらえないかなあ。僕もスキルセットを少し上げたいし、この機能のことを理解しておきたいんだ。もちろん、この仕事が終わるまでは、こっちで新しい仕事を始めたりはしないよ。何か手伝わせてもらえることはないかな？」

45章リーダーという立場:

模範を示して指導する本物のリーダーになるためには、前線に飛び込み、戦場でリードする意思が必要だ。自分のチームのために誰もやりたがらない難しくてうんざりする仕事を引き受けなければならない。もっとも単調な仕事であっても、自分ならどんな質を実現できるかを人々に示す必要がある。

他にも自分の考え方をどう売り込むかというこの一章だけで、この本を買う価値はある。

あなたはメンテナンスしやすい優れたコードが書ける新しいフレームワークをアプリケーションのなかで使いたいというアイデアを上司に売り込みたいけれども、上司が気にしているのはプロジェクトのスケジュールだとする。そんなときにはメンテナンスしやすい優れたコードの話をしてはならない。

(中略)
メンテナンスしやすいコードが話題になると、開発スケジュールがさらに長くなるという印象さえ持っているかもしれない。そこで、この新しいフレームワークに切り替えれば、開発にかかる時間が短縮され、プロジェクトの完成を大幅に早めるために役立つという話をしよう。相手に合わせて話の枠組みを決めなければならない。

著者は良くも悪くも正直で、特にアメリカだと批判を浴びることを恐れて人々が触れないようなトピック、例えば女性のソフトウェアエンジニアとしての働き方についても自分の考えをバシバシ書いている。同意できないことも多いので、そこは飛ばして学べる側面だけ吸収するのが正しい読み方だと思う。

はじめて学ぶソフトウェアのテスト技法

テストに関しては日常的にユニットテストからE2Eテストまで書いているし、経験はそれなりにあるけど体系的に学んだことはないので、手にとってみた。

ひとつ印象に残ったことについて触れると、"契約によるテスト"という考え方があった。

契約による設計のアプローチでは、モジュールは、事前条件および事後条件という用語を用いて定義されます。事後条件は、モジュールが何をするかを約束するものです。事前条件は、事後条件を満たすためにはそのモジュールに何が必要かを定義します。
(中略)
事前条件と事後条件は、モジュールとその呼び出し側との間の「契約」を成立させる意味合いを持っています。
(中略)
契約によるテストは、上記の「契約による設計」の考え方にもとづいています。このアプローチでは、事前条件が満足された状況でのテストケースしか作成しましません。

こういうことをコード規約に明示化すると、不要なテストも減らせるし、メンバーが安心して利用できるモジュールが作れそうだなーと思う。

体系的にテスト技法について学びたいという人は一読に値すると思う。一点注意すべきことは、どちらかというとエンタープライズ向けのテスト技法が網羅されていることだ。本書でも述べられているようにWebの場合はコード品質、機能性、ユーザビリティ、パフォーマンスをテスト基準とすることが多い。なので Webやモバイルアプリケーションのテストの書き方を知りたいという人は本書のスコープには当てはまらなそう。

息吹

"あなたの人生の物語"を読んで衝撃を受けて以来、ずっと次回作を待っていて、すぐに買ったんだけど、ついに積ん読を解消できた。

すでに自分の中の2020年ベストSFにランクイン。SFで拡張させた世界観の中で、改めて現実にある問題を見つめ直すストーリーテリングが本当に上手だ。例えば、ソフトウェア・オブジェクトのライフサイクルという中編。ディジエントと呼ばれる仮想空間上で成長するAIが育つ過程を描いた物語だが、そこでは現在社会が直面している課題がそのままに表現されている。

健全なセックスという概念の幅は時代とともにたえず広がってきました。ホモセクシュアリティや嗜虐性行為や複数恋愛は、かつてはどれも、精神に問題を抱えている証拠だと見なされました。
しかし、それらの中に、恋愛関係と両立しえないものはなにひとつありません。
問題は、社会が人間の欲望に異常という烙印を捺すことです。いずれはディジエント・セックスも、それらの例とおなじように、まっとうなセクシュアリティ表現のひとつとして受け入れられるようになると、わたしどもは信じています。

多くの作品の根底にあるテーマは、"全く未知の異なる文化、価値観がお互いに作用するときに、どうお互いが理解/反応し、受容するのか" だと思う。例えば、こんなふうに、自分の価値観の中で"理解"していくところから始まる:

単語がどこではじまりどこで終わるかは、耳で聞いてもわからない。人間がしゃべっているときに発する音は、山羊の脚の皮と同じくらいなめらかで切れ目がないが、単語は、肉の下にある骨のようなもので、単語と単語のあいだの空白は、山羊の脚をばらそうと思ったときに切断する関節部分に相当する。書くときに空白をはさむことで、モーズビーは、自分のしゃべることに目に見える骨をつくっているのだ。

そこには驚きやとまどいなど、さまざまな未知に対する"反応"があるが、その先の"受容"に対する答えについては、読者も異なる価値観に触れた一人として、考えを委ねられている。

以下はこの本で一番好きな一節だ。