読みたい本がたくさんあるんだ〜〜！って気持ちのままに迎えた連休ということで、本を読みました。
↓1年前
daisuki.nichiyoubi.land
最近の本の読み方
タイトルとか、Twitter眺めてて言及されてた本とか、本を読んだら紹介されていた本とか、「何となく興味を持った」とか「コレはどっかで読む可能性があるんじゃないか？」と思った本をば〜って買っていくスタンスになっているので。
どちらかというと、「1冊を丁寧に読む」っていうよりも「どんなことが書いてある本なのかを知る」みたいな読み方をする割合が増えているかも？という気がする。
(もちろん、じっくり読んだりちゃんと理解して掴もうとする本もある)
年末年始のアドベントカレンダー期間に「とりあえず読了だけはする」と決めて付き合った本が何冊もあったり、4月に入門〜基礎レベルのプログラミングの本を1日？半日？で8冊ほど目を通したり・・・というのを体験したので、なんというか「読み流す」みたいな読み方が上手くなった気がする。感覚を掴んだよな。
そういえば昔から「雑にやっても大事なことだったら何度もでてくるし定着するでしょ」っていう思考なので、まして今みたいに積ん読が膨れ上がっている状態だと、こういう風な読書のモードを簡単に取り出せるっていうのは良いことなのかもなーって感じ
雑感
4/29-5/8までで10冊読んだので、ペースにしてちょうど1日1冊くらいかなー。
前から読んでいてこの期間に読み終わったものもあるし、逆にこの期間に読み始めて今も読書中のものもありつつ。
あと、「1冊は読み終えられるように軽そうな本を挟む」みたいな事もしてた。この辺り、去年のGWに結構たくさん読んだな〜っていうのが1つの目安にしてたなぁ。
ソフトウェア設計、コーチング、PjM、DevOps、PdM、ファシリテーション、「他人に勧められるかな？」目線でレベル的に自分にとっては易し目な本・・・と、自分の興味のあるものを我儘に手にとった感じ🤗
あと洋書が段々と自分の読書リスト(実際に読んだ本)に含まれてくるようになったのは嬉しいな。
これもアドベントカレンダー2021に訓練みたなものができた点だと思う。
アナリシスパターンを読み切るぞ！！！って思ってたけど、結局まだまだ途中だなぁ。
読んだ本の記録↓
読了順に
Domain-Driven Design in PHP
猫も杓子もDDDじゃないですか、っていうことで「
PHP利用者にはグッと来やすい」みたいな書評をどこかで見かけたような見かけなかったような気がして積んでた本。
GW初日(その前日の夜だけど)に読み始めて、この期間では1番最初に読み終えて。
いや〜〜〜コードがPHPだとすごい分かりやすいな！？脳みそが楽だ！！！みたいな気持ちになった。
直近でアジャイルソフトウェア開発の奥義 第2版 オブジェクト指向開発の神髄と匠の技を読んだ際に「コードが視覚を通じて脳みそに届いて理解に至るまで」の摩擦係数がすんごい高ぇ〜・・・みたいな経験をしたばかりなので、この「ざっと全体俯瞰してもポイントや言いたいであろう事が目に飛び込んでくる」くらいの読みやすさはとっても気楽で嬉しかった。
それもあって、かつ難易度としてもそんなに高くなくわかりやすかった気がする。
コードが具体的、ある程度の「DDDとは」的な所の端折りを許したことで「つまり何」がテンポよく出てくる、みたいな感覚。
どうしても「養殖物」なコードではあると思うのだけど、「集約」とか「ドメインイベント」とか「ドメインサービスとアプリケーションサービス」とかの戦術的DDDを扱う上で出てくる掴みにくいような概念も、自分にとってはスッと頭に入って来やすい感じがしたなぁ。
それは「PHPだから」もあるだろうし、「説明も簡潔だから」ってものあるだろうし、それこそ「何度も似たような本を薄く広く読んできたから解像度が上がる」って効果も感じつつ。
動作可能なサンプルコードもGitHubに上がっているということで、本書にて触れられていないコードとか全体のつながりは補える。
勉強がてら、CakePHPで書き換えてみたいなーって思ったり。
なるほど感が多かった1冊。DDDの「入り口の次」くらいに良いんじゃないかなー
最近、社内でもDDDだったり設計に興味ありそうな人がチラホラ目に入ったり、あと「PHPのコードリーディングを練習してみたい・良い題材がほしい」って人も居たりするので、勉強会してみても面白そうだ。
PMBOK対応 童話でわかるプロジェクトマネジメント
yokohamanortham.63 で言及されていた本。
anchor.fm
まず「なんで童話で語ろうとしたんだwww」っていうお茶目さを感じつつ、全体的にそういった軽快さで記述されているので、読み心地としては軽いしとっつきやすいんじゃないかな〜！という印象。
これ1冊で「プロジェクトマネジメントができるぞ！！」というものではないけど、例えば「自分が参加しているPJでマネージャーがどういう事を考えていそうか、何に気を遣っていそうか」が薄っすらと感じ取れるようになったり、自PJの「なんとなく上手く行ってないかも？やりづらいかも？」を観察するためのメガネにはなってくれるかも。
問いかける技術 ― 確かな人間関係と優れた組織をつくる
組織開発系の本、ということでいいのかなー。
「問いのデザイン」とか「問いかけの作法」とか(どちらも同じ著者だけど)が「どうやって引き出すか」というよりも、こちらは「どうやって向き合うか、聞き手の態度として何が大事か」のような、より内省的な話を扱っているような印象。
(同著者の「企業文化」「人を助けるとはどういうことか」も積んでる、面白そうだから読みたいんだよなー)
この本は「謙虚に問いかける」という事を重視していて、「謙虚さとはなにか」「なぜ大事なのか」といった話を展開している。
ただ単純に「相手に大して丁寧な態度で接する」みたいな話だけではなくて、もっと受容を重んじるような、「自分の意見を出したり主張したり誘導することなく、本当に相手の中にある/出そうとしているモノを引き出す」といったような話。 相手に興味を持つ、先入観を排除する、「聞く」のに集中する・・・
面白くて新鮮だったのは、「思考プロセスに影響を与えるようなの問い」がアンチパターンとされている点。
例えば「内面に何を持っているのか」とか「根底にどういった思考や価値観があり、そういう思考に至っているのか」といったような、会話(=発言など、表面にできていているもの＝コンテンツ)を生み出している原因だったり過程だったりといったレイヤーに意識を向けるような問いのこと。
「よく聴く、相手を立てる」みたいな実践であるはずのコーチングにおいて、こうしたものこそが「相手への興味の向け方」とされているような感じがあり、明確に違うなーと。
もちろん「どっちが良い、悪い」という話ではなくて「適切に使い分けるべき」という話になるのだけども。
いわく、このような問いかけは「本人は思おもよらなかったことを考えさせる」ような方向づけになってしまい、相手の考えようとしていた事柄の道筋に大きな影響を与えてしまう。言ってしまうと「思考プロセスを乗っ取る」「会話の主導権を握る」ような状態に陥ってしまうのではないか、と。
問いや会話の実践を通じて、信頼関係を築いていく事を指向した1冊。
今回はちょっと駆け足気味に読んでしまったけど、分量もそんなに多くないので、またどこかで再読したいなー
アサーションとかアサーティブコミュニケーションっていうのを初めて知ったのはどこだったっけか・・・というのがパッと出てこないのだけど、どこかでしっかり修めてみたいなと思っている分野の1つ。
こうした考え方を知ることは、単純に「他者と上手くコミュニケーションをとる」みたいな事にも効果を発揮すると思うのだけど、もっと抽象的な部分での「自分が自分を大切にできているか」「何にこんなにも傷つけられているんだろうか」を取り出す力が育まれるのかな〜という気がする。
その点で言えば、第3章「考え方をアサーティブにする」で触れられているものが大事そうな感じも。
フォーカシング
コーチング、カウンセリング文脈の本を引き続き読んで見る。
フォーカシングはとてもおもしろいし強力だなぁ・・・と思うのだけど、自分の場合、マインドフルネスやU理論みたいな「実際に自分が感じてみないと、どういう感覚なのかを掴むのが難しいもの」という引き出しにフェルトセンスは入っているような。
自分の場合、コーチングを習う過程で少しは体験していたので、最後まで「面白いなー」って気持ちを維持しながら読めた気がする。
フォーカシング、「自分の内面や感覚に意識を向けて、何が起きていてどんな事を感じているのか・・？を知ったり理解したりする」みたいな話で。これが出来ると、例えば「なんでそんなにイライラしてしまうのかが分かった！！」とか「私が本当に望んでいたのはこういう事だったのかも！」みたいな感じで、気持ちや感覚がほぐれたりと。
特に印象的だったのが、
うなくフォーカシングができているときにはどんな感じが出てきてもうれしく感じるものです。「死んでしまえ！」という内面の感じが聞こえてくるかもしれません。これをおだやかに、理解を示しながら吟味することになるでしょう。たぶん「おや、面白いな。宣告されてる感じだ。道理で行き詰まってるという感じがしてたんだ─もしそこにこんな感じがずっとあったのだとしたら。(後略)」
(P51)
のあたり。
こういう、「めちゃくちゃ憤っているのは自分自身」であるはずなのに、その感情の変化や激しい反応自体も切り離して客体化していくことで、そこから踏み込んで「何がそうなれるのか」についても理知的に分析できるーっていう作用の仕方にはすごいパワーを感じる。
これもまた、「こういう考え方もあるんだな」っていうのを知っているだけでも救われる面はあるのでは？といった1冊。
コミュニティ・オブ・プラクティス
実践コミュニティの話。
会社で考えようとしていたことに関連して、連休の狭間に「ちょっと明日のミーティングに持ち込もうとしているネタについて、うまい説明ができると良いなー」ってことで優先度を上げて読了。
「お互いに知見を共有し合う、同じ領域に興味や課題感を持つ人同士で集まって研究や学習をすすめる」って意味でのコミュニティと、「実際に起きた出来事や行動から得た知識や考察を重んじる、得た知見は現場で活かす」って意味での(理論知でない)実践を、ということで「実践共同体」とか「実践コミュニティ」「プラクティスコミュニティ」とか「PoC(s)」とか言われているものについての本*1。
「ユニコーン企業のひみつ」で紹介されているSpotifyモデルでいうところの「ギルド」とかもコレの1つなんじゃないかな？って思っているのだけど、どうなんだろう。
あとLeSSでも触れられていたり。
調整と統合 - Large Scale Scrum (LeSS)
「こういう取り組みがあるんだな」というのを知るためには十分な1冊だなーと感じる反面で、そもそもの性質として「上手くいくやり方を紹介する教科書的な本」っていうのは難しい話題なのかもな、とも感じた。
事例研究を集めて統合した内容にはなっているけど、かといって「どこにでも当てはまる公式」なんてのは無いよなー人や状況に応じて観察して最適化していくしかないよなー・・みたいな。
他方で、「企業活動としてやらなければいけないこと」みたいなのは抑えている気がして、例えば「業績や評価とどう結びつけるか」「組織内でどう位置づけるか」などなど。
逆に、(例えばアジャイル系な本とか組織開発系な本であるような)「個人としての喜びをどう描くか、どうエンパワメントしていくか」みたいな側面はあまり触れられていないような印象も受けた気がする。最近割とそういった本ばかりを読んでいたからなのだろうけども。
こういったトピックについて興味がある人は目を通してみても良いかもしれない、ただ「やってみるしかない」「上手くいくかどうかは、まずリーダーシップを」(あと上役の理解と支援！)的なところなので、端から端までしっかり読んで頭に入れる〜〜っていう必要性は薄いのかも。
どうやっていくか？という面では、むしろ、Fearless Changeとか学習する組織とかに必要なことが散りばめられているかも。
The DevOps 逆転だ！究極の継続的デリバリー
システム運用アンチパターンのまえがき(だっけな)で触れられていたので買った本。
ビジネスフィクションで描かれた「最悪な状態からどうやってDevOps的なコンセプトの実践・実装で大きな成功を勝ち取っていくか」を紹介する本であり、「DevOpsとは〜」とか「○○のプラクティスを紹介します！」といったものではなく。前情報なく読んでみると面食らうかもw
ある意味では「理念」「価値観」「哲学」といったものをまざまざと描き出して伝えてくれる1冊でありつつ、全てが物語の中で展開しているので、「ここから何を(具体的なプラクティスや進め方として)学ぶか」については、読者自身がしっかりと要約したり抽象化する必要がありそうかな？っていう印象。
中身としては(対立者がめちゃくちゃ最悪でストレスが溜まる、っていうのを除けばw)スルスルっと読めるし「あるある」的な内容もふんだんに盛り込まれているし、読み物として楽しめる内容でもあったし〜で面白かった
現場で役立つシステム設計の原則 〜変更を楽で安全にするオブジェクト指向の実践技法
良いコード／悪いコードで学ぶ設計入門―保守しやすい 成長し続けるコードの書き方をGW前(配信開始日)に読んだことをきっかけに、未読だったな〜と思って手にとった本。
今の所の自分だと、何かめちゃくちゃ目新しいことを学ぶぞ・・・！という期待よりも、「何か会社とかで若手に勧めやすい本があるといいな」「他人に説明する時に分かりやすい文章とかを吸収したいな」という期待が強めだった。
読んでみて、評判に違わず「色々な人にオススメして良さそうだな、早い段階で出会ってほしいな」という印象に。
これ1冊で「設計が出来るようになる、引っ張っていける！！」っていうものではないにせよ、大事な心構えが埋め込まれていると思うし、「ガンバに持って帰って実践する」のに能う本だなーと。
「業務ルールにしっかり目を向けておけ！」みたいな点が強調されていたり、「データベースとアプリケーションコードがどういう関係になるべきか (変な癒着を避けないといけない)」という罠っぽいところも抑えてあったりと、抑えているポイントが気持ちよかった。
どっかで読まないとな〜〜って思って読めていなかった1冊、これが読めてよかったな。。
必ずしも全面同意ではないものの(モジュール(というかクラスか)についてのスタンスなど)、考えは明快で力強いな！！と思うものがとても多く。
あと英文も読みやすかった印象！
Deep Moduleって単語はこの発表で初めて聞いたものだったのだけど、やっぱりオリジナルを読むと「なるほどな！！」感がまた1つ変わってくると言うか。
あと、個人的には、コメントについての考え方がとてもおもしろかった。
General puserposeとSpecial purposeも共通性可変性分析に通ずるものを感じたし、レイヤー分けとか”Pull Complexity Downwards"とかに繋がっていったりと。
複雑性とは何か？という定義(解釈)についても、シンプルによく言い切っているな〜って感心して納得したり。
仕事でコードレビューをする際に机の片隅に置いておきたいし、そういう仕事をする人には1回読んでみてほしいなぁとも感じる。
名著と名高いだけあるなー
本の最後に「Summary of Design Principles」「Summary of Red Flags」が載っているのも助かるし、著者の想いとか願いとか苛立ちみたいなものを感じる
プロダクト・レッド・オーガニゼーション 顧客と組織と成長をつなぐプロダクト主導型の構築
ば〜〜っと駆け足気味に読み流した感じ。より思想的な部分、哲学的な部分を期待していたけど、どちらかというと「数字をどう設定するか(何をインジケーターとして扱うか)」だったり「運用をどうするか」みたいな具体の話の方が、この本においては面白かった印象。
そういう意味では、少し物足りなかったり期待が満たされなかったのかも。
組織文化やコアとなる精神といったもので、「根本的に今とは考え方を変えないと強くなれないぞ！！！」と思わされるようなガツンとくる衝撃は無かったかもなー的な。個人的には、プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届けるの方が好きそう。
「製品開発、サービス提供」の分野については、いくつかのコンテキストで同様に語られることがある気がする。セールス、マーケ、プロダクト(開発)、顧客リレーション・・・例えばカスタマーサクセス系の本を読むとセールスだったり顧客リレーションが多かったり。その意味でいうと、この本はマーケティング畑の本かな？って何となく感じた。
翻訳者ご本人のスライドが https://speakerdeck.com/ykmc09/product-led-organization にあるので、先にコチラに目を通してから本書を手にとって見ると、より面白そう！
