GWを振り返る

読書記録

「はぁ〜、色々とインプットが足りない〜〜足りなすぎる〜〜」って感じが爆発してきたので、今年のGWは「本を読むぞ！」という過ごし方をしていました。

本を読んだ

↓これが変遷です

(気持ち

(前のエントリーを書いた後の感想

(感情

(やるぞ〜！

なお、途中でそういえば？？って思って、「去年のGWって何してたんじゃろ、記憶ないな」つって当時の記録を見てみたら、「あぁ〜物凄く最悪だったんだ〜思い出すんじゃなかった〜〜」ってなったりしていました。色々がある。最悪・・・

で。

ジム行けないから、ってなるといくらでも開き直って家に居られる & 飲みにも行けないから、「誘ってみようかな！？」なんて邪な気持ちも一切生まれない。
結果としては5/2-5/6(日付は変わったが)で6冊を読了できたので、良かったのでは。

ここ数年はまともに読書できてないな〜・・・という気持ちがあったのだけど、4/26-27の土日でも(途中まで読み進めていた本を)読了できたなど、ここ1週間強で少しずつ「集中して1つの話を読む」という訓練が出来たのかなという気がする。

読書の基本フォームみたいなのが見つかって良かった

ちなみに「一気に読めた」のは、コレに依る所が大きいと感じる。
ARIGATO, YAMOTTY3・・・・

というのと、省みるに「長い本を読むぞ！！と思うと、拘束時間の長さに怯んでしまう・・・」「結果的に"あ、長丁場になるなら、ちょっと先にコレやっておこうかな？"に遮られる」みたいなのが、自分が本を読めていない大きな理由の1つだよなぁ〜と思ったので。簡易ポモドーロテクニックを導入してみた。

「簡易」としているのは、「1ポモごとの計画」とかを一切してないから。25分読む、その間は(読書メモや不明な単語を調べる以外は)何もしない、終わったらTwitterとか見ていいよ」という縛りでやった。

ちなみにタイマーはFocusDotsというアプリを使った。

FocusDots: Tomato Timer

FocusDots: Tomato Timer

  • particlemade
  • 仕事効率化
  • ¥250
apps.apple.com

コレがメチャクチャにシンプルで、「25分カウントダウンする」「終わったら5分or15分の休憩もしくは25分カウントダウンを始める」という操作しか無く、今やろうとする簡易な行動管理にはバッチリだった。
(強いて言えば、「次の休憩は5分か15分か？」が分かると嬉しい・・・ただ、それを逆手に取って、「行けそうだったら5分で疲れを感じてきてたら15分で」とマニュアルな感じでよしなに選択してた)

この「PC kindle」+「ポモドーロタイマー」で、読書の基本フォームが出来た気がする。それがデカい収穫の1つ。
カウントダウン開始 → 没入用のBGMを再生する → (本を読む) → 小休止カウントダウン開始 → BGMを切るor明るくてアッパーなのに変える → (意識を切り替える) → 小休止終わり → 次のカウントダウン開始
みたいなループ、メリハリを付けられてよかった。

紙書籍も1冊読めていて、これも「ほんたった」*1を使ったらいけそう、と思った。

www.edisonworld.jp

多分だけど、PCにしろ座りながらにしろ「ハンズフリーにできる」のがデカい要因なんだなぁ〜という感じ。その点はPCもほんたったも変わらない。逆に、スマホやタブレットだと損なわれる体験。

あと、長期戦に備えた際の「リラックスしながら取り組も〜」というのを廃して、しっかり「集中してやろ」ってマインドセット切り替えたのが大きかった。そもそも、デスクも椅子も拘って揃えているんだから、時間が長くなるのは問題ないのだし。
読書を「のんびりやるもの」ではなく「集中して勉強するもの」と見据えたのがね。

↓そうこうした結果 f:id:o0h:20200507052429p:plain

読んだ本の記録↓

キャリア〜〜みたいな本と、チーム〜〜とかコミュニケーション〜〜みたいな本と、そこら辺に密接に関係しそうな技術〜〜な本っていうセレクション。

あ、ブクログも使い始めたよ。昔アカウント作った気がするんだけどな〜どこいったんだろ〜〜

booklog.jp

見出しのprefixは読了日

5.2 SOFT SKILLS　ソフトウェア開発者の人生マニュアル

SOFT SKILLS　ソフトウェア開発者の人生マニュアル

SOFT SKILLS　ソフトウェア開発者の人生マニュアル

ハイライトした部分を見返してみると、とりわけ「バカにされることを恐れるな」が良かったかな〜。
これと「プロであること」の「一線を越えてはならない」の話。これは訳者あとがきでも触れられている。

品質基準は、もっとも重要だと思われる部分だけでなく、コードの隅々のあらゆるところまで徹底させることが重要だ。本物のプロは、T・ハーブ・エッカーが『ミリオネア・マインド大金持ちになれる人』（三笠書房、2005年※4）で言うように、「何をするときも同じやり方でする」ということがわかっているので、自分の仕事のすべての部分が高品質になるようにする。ある部分で品質を下げるようなことをすれば、ほかの部分でも無意識のうちに質が下がってしまうものだ。一線を越えて妥協をすると、元に戻るのは難しい。

ジョン・ソンメズ. SOFT SKILLS　ソフトウェア開発者の人生マニュアル (Japanese Edition) (Kindle の位置No.1268-1273). Kindle 版.

あとは「能動的に遊ぶことが何かを学ぶ上で重要である」というのを説いた「学び方を学ぶ」の章か。

私は、何をやっているのかさえわからないうちに行動を起こすことが、何かを学ぶための方法としてはもっともいいのではないかと感じている。あるテーマについて遊べるくらいの知識が身に付いたら、あなたの頭のなかの創造的で好奇心旺盛な強力な部分を活用できる。私たちは、実際に能動的に遊んでいるときこそ、そうでないときよりも多くの知識を吸収し、意味のある疑問が湧いてくるものだ。

ジョン・ソンメズ. SOFT SKILLS　ソフトウェア開発者の人生マニュアル (Japanese Edition) (Kindle の位置No.3062-3065). Kindle 版.

この辺り、今の自分の行動指針にしたいな〜と考えていたことと重なる三点。

5.3 小さなチーム、大きな仕事　働き方の新しいスタンダード

小さなチーム、大きな仕事　働き方の新しいスタンダード (ハヤカワ文庫NF)

小さなチーム、大きな仕事　働き方の新しいスタンダード (ハヤカワ文庫NF)

hbSAKABA聞いてて言及されていたので、気になって買ってみたやつ。
それに加えて、前職の二代目CTOがDHH好きだったのも「読んでみようかな」と思った要因として大きいw

GW中に読んだ本の中ではコレが1番サクサクと読めたかなー。エッセイ集で、平易で、ワクワクさせるような修辞。

書いてある事は流石にラディカルで「普通の会社にいながら普通のチームの中でどう働いていくか」みたいな意味で全体的には適用できなさそうだけど、読んでいて面白いのは確か。刺激にあふれていた！

手に取るきっかけになった「文化」の部分は心に留めておきたい。
ただし、これだけだと正直ピンと来てなかったかも知れないので、件のpodcastのエピソードを思い出せると良い。

文化はつくるものではない。自然に発達するものである。 (中略) 文化とは方針ではない。

ジェイソン フリード,デイヴィッド ハイネマイヤー ハンソン. 小さなチーム、大きな仕事　働き方の新しいスタンダード (Japanese Edition) (Kindle の位置No.1609-1612). Kindle 版.

その他には、

信じているものが何かをわかっていなければ、すべてが議論の対象になってしまう。すべてに議論の余地がある。しかし何か拠って立つものがあれば、決断は明らかになる。

ジェイソン フリード,デイヴィッド ハイネマイヤー ハンソン. 小さなチーム、大きな仕事　働き方の新しいスタンダード (Japanese Edition) (Kindle の位置No.330-331). Kindle 版.

の箇所と

できるだけ「これについて考えよう」ではなく「これについて決断を下そう」と思うことだ

ジェイソン フリード,デイヴィッド ハイネマイヤー ハンソン. 小さなチーム、大きな仕事　働き方の新しいスタンダード (Japanese Edition) (Kindle の位置No.537-538). Kindle 版.

の箇所と

もし金曜日にひらめいたら、土日を返上してプロジェクトに専念するのだ。インスパイアされている間は二四時間で二週間分の仕事ができるものだ。そういう意味ではひらめきはタイムマシンだ。ひらめきとは不思議なものだ。生産性を高め、やる気をあおる。だが、待っていてはくれない。ひらめきとは「今」のものだ。もし、虜にされたなら、逆に仕事に専念することだ。

ジェイソン フリード,デイヴィッド ハイネマイヤー ハンソン. 小さなチーム、大きな仕事　働き方の新しいスタンダード (Japanese Edition) (Kindle の位置No.1738-1742). Kindle 版.

などの箇所が、どんな会社・どんなチームであろうと「働き方」に効いてきそうな部分。

5.4 チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ

チームが機能するとはどういうことか ― 「学習力」と「実行力」を高める実践アプローチ

チームが機能するとはどういうことか ― 「学習力」と「実行力」を高める実践アプローチ

2016年に買ったっきりで積ん読になっていた本！！
何で買ったんだろうか、キッカケを忘れてしまった、「チームが機能する」のに当時から興味があった・・？
しかし、この連休中に読んだ中でも最も良かったと思える本の1つ。自分にハッとさせられる部分が多かった。(そのため、個別に読後の感想をメモに残したくらいだ)

ただ、正直これが1番読みにくかったかな・・・・
翻訳の品質にも問題がありそうな気はする、あと一文がとても長いので、文節の繋がりを意識しながら読むことになる。これは脳みそが疲れる。
とはいっても、命題に対して徹底して誠実に論じており、すなわち議論が丁寧で(大きな粒度での)繋がりが見えやすかった。

「チームが機能するとは学習し行動する状態になっていることであり」「学習のためには心理的に安全であることが必要であり」「よいリーダーシップとは、心理的に安全である状態を作りつつ目的を与えることである」みたいに理解している。単なる仲良しグループ=「コミュニケーションは多発しているが均質性・同調性が高いから平和なだけ」みたいなのは、リーダーシップの失敗。
その他に、キーワードとして「チーミング」「フレーミング」辺りは抑えておきたい。

逆に「機能していない」とは、「学習と実行が分断されている」状態であり、これは「トップダウン」みたいな構造による支配を行っている組織が典型例。

リーダーが、管理ではなくエンパワーメントするようになったら、適切な答えを与えるのではなく適切な質問をするようになったら、そして規則の遵守を主張するのではなく柔軟性に着目するようになったら、彼らはもっと高いレベルで「実行」できるようになる。

エイミー・Ｃ・エドモンドソン. チームが機能するとはどういうことか 「学習力」と「実行力」を高める実践アプローチ (Japanese Edition) (Kindle の位置No.253-255). Kindle 版.

良いリーダーとは「管理ではなくエンパワーメントする」ものであり、良いリーダーが与えるのは「解答ではなく問い」という気がする。
「答えを与えるリーダー」とは、メンバーを「実行者」としてみなしていると考えられる。

学習しながら実行するというのは、絶え間ない学習を日々の作業プロセスの中に織り込む活動の仕方のことである。ふつう、これはチームの中で生まれ、学習するための組織づくりというリーダーシップの実践によって後押しされる。

エイミー・Ｃ・エドモンドソン. チームが機能するとはどういうことか 「学習力」と「実行力」を高める実践アプローチ (Japanese Edition) (Kindle の位置No.831-833). Kindle 版.

「試行(実行してみて、失敗する) -> 省察(失敗した要因を抽出する) → 学習(アップデートを伴った実行をする)」 みたいなサイクルか。
この「学習」の効果を高めるために、失敗からより良い分析と洞察を導くことが必要になり、それはメンバーの率直な発言によって達成される。よって、心理的に安全であることが重要。

また、チームの位置するレベル(業務の質)によって、「何を学習するべきか」というのが異なってくる。これを「ルーチンの業務」「複雑な業務」「イノベーティブな業務」に分類して論じているのが面白かった。
それぞれ課題は「効率改善」「精度の向上」「未知性の発見」となる。質が異なるだけであり、どのチームにも「学習し実行すること」が必要であり「チーミングが有効である」という話になる。

・・・

色々と面白かったのだけれど、読みながら作ってた読書メモに書いてあった自分の言葉を残しておいてみる。

「コトに向かう」といった表現は割と好んで使いがちだけど、結構曖昧でぼやっとした言い方だな〜って思ってたけど。 もしかして、この「学習しながら実行する姿勢を持った状態」が、コトに向かっている状態なのではないか？狭い意味では「失敗を恐れなくなる(学びの糧になるのだから)」という状態が達成されるし、そこから、ある意味では他人に興味がなくなり、自己防衛や他責の念やそういった行動をとりたいという欲求・モチベーションから解放されて、「より良くやろう」という意識になる、と・・

5.5 エンジニアの知的生産術 ―効率的に学び、整理し、アウトプットする

エンジニアの知的生産術 ──効率的に学び、整理し、アウトプットする (WEB+DB PRESS plusシリーズ)

エンジニアの知的生産術 ──効率的に学び、整理し、アウトプットする (WEB+DB PRESS plusシリーズ)

  • 作者:西尾 泰和
  • 発売日: 2018/08/10
  • メディア: 単行本（ソフトカバー）

「どうやって学んでいくか」「どうやってレベルを引き上げるか」という関心がここのところ強いので、「そういえばメッチャ話題になってたあの本！！」というセレクション。

正直、要素要素については目新しいことはあまり無いか・・・？
ただ、前書きで筆者のモチベーションがどこにあったか？が言及されている通り、「多岐にわたるこの内容を1冊にまとめたのがすごい」。

本の中で触れられていた「U理論」、学生時代に読んだ「出現する未来」でその存在は知っていたのだけど。創発に関する話。また読んでみたいな、などと思いだしていた。

1番勇気づけられて、かつ肝に銘じておきたいと思ったのは以下の部分かな

これは第6章「誰からでも学ぶことができる」（『磨き上げる』節）で学んだ、知識の少ない人からでも学ぶことができるという考え方の裏返しです。自分の知識の絶対量が少なくても、差別化をすれば、他人に教える立場になることができるわけです。

西尾 泰和. エンジニアの知的生産術 効率的に学び、整理し、アウトプットする (WEB+DB PRESS plus) (Japanese Edition) (Kindle の位置No.4825-4827). Kindle 版.

あと、ここも「そうだよねそうだよね」って頷いた部分。

しかし「写経」という言葉が原因で、いくつか誤解もあるようです。「原典に疑問を持ってはいけない」や「雑念を捨てて無にならなければならない」というのは誤解です。それはただでさえ低い写経の学習効率をさらに下げてしまいます注24。書き写しながら、「あれ、これ前にも出てきたな」とか「いつものパターンに似ているけどちょっと違うな」とか考えることが大事です。入力しながら類似点・相違点を発見していくことで、あなたの中でモデル化が進みます。また「なぜこうなっているのだろう」とか「ここをこう書き換えたらどうなるのだろう」という気持ちが湧いてくるととても良いです。それは「疑問を解決したい」「書き換えて試してみよう」という「明確な目的」につながります。思ったことはコメントとして書き残していくとよいでしょう

西尾 泰和. エンジニアの知的生産術 効率的に学び、整理し、アウトプットする (WEB+DB PRESS plus) (Japanese Edition) (Kindle の位置No.875-883). Kindle 版.

プログラムの写経などは、「最も漠然と始められる」タイプのインプットでありつつ、だからといって思考を停止して行って良いものではないーみたいな。

5.5 レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス

これは仕掛りだったやつの、残りを読んだということ。
今ターム唯一の紙書籍でもある。

なんというか、前半部分は読んでいて物凄く心が抉られた・・・レガシーなぁ・・・・・・

開発者側のテクニックというよりは、「プロジェクトがどうあるべきか」という印象。
あとは、散々言われているけど「腐ってしまったものをどう生き返らせるか」ではなくて「どうやって防ぐか」という感じ。

1つだけ、読みながらメモっていた部分を転載

私はリファクタリングを規律だと考えている。コードを変更する標準的なやり方を示すような規律を作る必要があるのだ。つまり、直感だけで他の人に説明できないようなコード修正のやり方ではなく、全員で共通した安全で繰り返し可能な手法が望ましい。

David Scott Bernstein (著), 吉羽 龍太郎 (翻訳), 永瀬 美穂 (翻訳), 原田 騎郎 (翻訳), 有野 雅士 (翻訳) (オライリージャパン) レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス P230

に対して

そう考えると、(コードレベルの)局所的なリファクタリングを進めていく場合、まずは対象となるコードなりクラスなりを慎重に観察して、「どういう戦術を用いるか」というのを説明してから取り組む〜というのがいいのかもな？という気がした。 例えば「現状もの問題はこうなっている箇所」というのを示して、デザインパターンやリファクタリングカタログにあるような言葉 = 「公共のプロトコル」を意識しながら、何をするかを話すみたいな。そうすると「リファクタリング後」の姿も共有できそう。
というのも、リファクタリングあるあるとして「書き換えようとしてみたら大して良くならなかった」がある。それに加えて、ただでさえ「生産しない」活動であるって意味で、リスクを抑えて効果を保証するべき道義があると思うので。

リファクタ、「何をやるか」って説明というか共有するのが難しい事が多いと思うんですよね。
しかも、「カッとなってやった」ていうストレス駆動開発になることが多い気もする。 そのスコープとして「○○クラスを良くする」から踏み込んで「課題を定義し、アプローチを認識させる」というのは(書いてしまえば当たり前なんだけど)良さそうだな、と。

5.6 Clean Architecture 達人に学ぶソフトウェアの構造と設計

Clean Architecture　達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ)

Clean Architecture　達人に学ぶソフトウェアの構造と設計 (アスキードワンゴ)

クリーンアーキテクチャ全く(は言い過ぎか？)通ってなかったのだけど、↓の配信を見ていて「なるほど〜そりゃ魅力的だ〜」というのを感じたので原典に当たろ、と思った感じ。
「依存の方向が片方向になる」というのは言葉としては理解しているけど、配信を見ていて、それよりも「それぞれの責務がめちゃくちゃしっかりするじゃん、これ凄い見通し良くなる=読まなくても分かることが増えるのでは・・・？」というところに興味を惹かれ。(どっちも、感想を持った次の瞬間にはnrsさんに言及されてたw)
で、「SOLID原則に対する実装例という感じで〜」みたいな話だったので、へぇ、オモシレーおじさん！ってなり。

nrs-seminar.connpass.com

想像していたより遥かに読みやすかったし面白かった・・・(少なくとも「チームが機能するとはどういうことか」の日本語よりは読みやすいw) 。びっくりしてしまった。
論理立っていてすごいな・・・というのが率直な感想。

いやー、良かった、クリーンアーキテクチャをカンゼンニリカイシタ！！

これを読んでしまうと、普段触っているソフトウェアは決して「クリーン」とは言えないな、という風に感じざるを得ない。
当初からの自分の立場は↓なのだけど、読後もガラッと変わることはないかな。

本書でも「フレームワークは、それにすべて任せることを前提としているようだ」といった事が(批判的な文脈で)書かれているけど、「そうすることによって得られるメリット(生産性etc)がある」というのは信頼している。

というのが1番大きな比較要素になりそうよなぁ〜・・という感じ。
結局「ソフトウェアは進化し続ける」ものであり、それはハードウェアや顧客要求や開発チームと言った外部要因により急かされ、その場に居留まれなくなるもの。
って考えた時に、予測不可能な将来に対して「選択肢を残す(身動きを取りやすくして、動く時には壊さないで引っ越す)」のがクリーンにするメリットで、「全部ぶっ壊して動くことを飲み込んで(いま考えているやり方が上手く行くのか分からないのだし)、生産性を手に入れる」のがFWに従って考えるメリットか、と思う。前者は「ビジネスルールという抽象の世界で生きる」もので後者は「FWという具体の世界で生きる」みたいな感じと(今の所は)捉えているけれど。
ん～～、って感じ。

とはいえ、対岸の考えを何も知らないでアレコレ言ってるのはダサいのでね、間違いなく読めてよかったし思考を深めたい分野。
「FWと結婚して生きていくって決めたんだ！！！」となっても、取り入れられる要素はあるんでしょう多分。それはちゃんと探りたい。

さて、今ならコレも理解できるかな・・？リベンジしよう

独立したコアレイヤパターン - Shin x Blog

微妙にGWじゃないけど最近のやつ

今年は4月最終の土日ってGWじゃないよね？
ただ、「意識としては「今年のGWに読んだやつ」な2冊。
どちらも、「途中まで読んでたけど中断していた」系。

4.26 天才を殺す凡人 職場の人間関係に悩む、すべての人へ

天才を殺す凡人 職場の人間関係に悩む、すべての人へ (日本経済新聞出版)

天才を殺す凡人 職場の人間関係に悩む、すべての人へ (日本経済新聞出版)

残り35%くらいまで読み終わってたやつ。

「なぜ分かり合えないのか」文脈で読んだような本なのだけど、「無意識に殺している」という視点もあるのか。
ザ・ゴールやもしドラを読んだ時も思ったけど、小説形式があんまり好きではないな自分・・・・w

おそらく自分は「再現性があるようにしたい(説明可能にしたい)」なので、凡人or秀才に分類されるんだろうなー。
出し抜くような行為が好きじゃないので、オフィシャルなやり方で何卒！！という風に動いていると思う普段。
あと「チームが機能するとは〜」が刺さったポイントは「試行し省察を繰り返して良い未来へ繋げる」っていうコンセプトだったので、これは本書の言葉を使えば完全に「サイエンス」w

「そやから、危険なんや。成功の上澄みだけを教科書で学んできた『秀才』は、自分は科学を使いこなせると勘違いする。なぜなら自分で『失敗しまくったこと』がないからや。つまり、失敗したことない秀才が、組織の上に立ち、サイエンスを振りかざしたとき、天才を殺してしまう。ある世界的に有名な科学者は言った。『科学の良さは失敗できることである』と」
—『天才を殺す凡人 職場の人間関係に悩む、すべての人へ (日本経済新聞出版)』北野唯我著
https://a.co/5kM4Sf8

「サイレントキラー」にならないように、みたいなのが掴めると良い。 多分。

4.26 他者と働く──「わかりあえなさ」から始める組織論

他者と働く──「わかりあえなさ」から始める組織論

他者と働く──「わかりあえなさ」から始める組織論

ここから「PCで読むのやってみるか！！」ってなったやつ。
確か残り40%くらいの地点からの再開だったかな？

これもとても良かったな。
「ナラティブ」っていうコンセプトは結構しっくり来た気がする。
月並みに「相手の立場になって考えよ〜」なんて言うけれど、この本はそれを徹底的に説明しようと試みている感じだな、と思った。
客観視する能力って、訓練で身につくものなのだろうか？

何にせよ、「話が通じないな」って思った時に、「自分か相手のどっちかが悪い」というのをジャッジするのは保留し、「お互いのナラティブを交換できるか(橋をかける方法は？)」という風に思考するのはとても前向きだと感じる。

しかし、「こちら側」の何が変わる必要があるのでしょうか。それはナラティヴです。「ナラティヴ（narrative）」とは物語、つまりその語りを生み出す「解釈の枠組み」のことです。

宇田川元一. 他者と働く──「わかりあえなさ」から始める組織論 (Japanese Edition) (Kindle の位置No.328-330). Kindle 版.

ってのと

適応課題を技術的問題だと考え、既存の知識やノウハウで解決しようと問題に挑むと溝に落ちてしまいます。溝がなかったり、溝がはっきりどういうものであるかがわかっていれば、技術的な問題解決は可能です。

宇田川元一. 他者と働く──「わかりあえなさ」から始める組織論 (Japanese Edition) (Kindle の位置No.593-595). Kindle 版.

の辺り。これらを、どのくらい誠実に&冷静に判断できるか。自分の岸から見えている光景に盲目的にならない。
そうすると、本書の言葉を使うと「反脆弱性」といわれるものを備えたコミュニケーションが取れるようになるのかな、と思っている。
理性的な生き物になりたいのう・・・

「どうやって他人と折り合いをつけるか」みたいな命題にはなるのに、「妥協しちゃうってのは駄目だよ」っていうスタンスで書かれているような気がする。
その点がとても良かった。

連休がおわっちゃった〜〜

もっと読みたい本はあったけど、ちゃんと思ってた数は読めたかな。
価格換算すると16000円ちょいですって、ふふふ。 読むスピードは上げたいね〜

とにもかくにも、「勉強量を増やさないとヤバいな」って念が非常に強くなり危機感を覚えているところだったので、「ちゃんと本を読み終えられる」という手応えを感じたのは良かった。
Clean Architectureも難なく読み終えられた〜ってことで、「ちょっと重そうだったな」って怯んでいたのも行けそうなのが嬉しい。
あ、あと酒飲んでない日がほとんどだったな！「本読みたい〜〜」っていうのが強かったし、精神的に充実してたのもある。良いこと。

次は(分量的には軽いけど内容が重い枠・・！)「ソフトウェアテストの技法」かな。「GWに読みかけを回収しよう」枠、こっち読むかレガシーコードからの脱却を読むかって感じだった。今の自分が紙も読めるのか探りたかったからレガシー〜にしたけど。
あと、それからDDD周りの本、アジャイル周りの本、Clean〜の中で言及されていて気になったから、「実践テスト駆動開発(既に持っているし)」、PoEAA辺りを読みたいな。
ってのとGoのやつもやりたいんだが。ユースケース駆動開発もDDD本の実績を解除したら読みたくなりそう。

時間欲しいね。

読書の習慣化に成功したらxUTP今度こそ行ける気がしているんだ・・・

*1:厳密には違う商品だけど。ほんたったも持ってる。