2021-12-13 22:21:31
「読書は1冊のノートにまとめなさい」というのを読んだ

見るからにアレな感じがしてしまうタイトルだが、割と悪くなかったのでちょっとメモしておく。

Screenshot_20211213-222207

アマゾンをぶらぶらしてたらたまたま目に入ってしまった一冊。曰く、「本を読んだそばから内容を忘れてしまうでしょあなたー!」とのこと。ホントにそのとおり。自分が今年何冊読んだのか、何を読んだのか、なんならオススメは何か、って言われてもすぐ出てこない。

自分としては、本の内容をつぶさに覚えてなくても、何となくエッセンスを吸収して血肉になってるだろうからまあ良かろう、くらいの気持ちでいた。しかしこの本は「そういうなんとなくな読み方ではエッセンスは吸収されてないぞ」と言い切っている。そうかー、まあそう言われればそんなような気はするが、そうかー。

それで、この本では「読書ノート」をつけるとより一層本の内容が記憶に定着していいぞ、と言っている。大仰なものは書かなくてよくて、何月何日に何を読んで何を思ったー、くらいのことを書けばよいと。

確かに、感想を書こうと思ったら読了後にもう一度要所を巡る必要があるかもだし、気になったところを引用したりちょっと気分を言語化したりするのに頭を使う必要もある。この手の営みはただ読むより少し能動的な本との向かい合い方になるような気がする。手を動かすとよく覚えてられるってのも体感的には分かる。ちょっとした感想でよいっていうのであればそんなに大変じゃなさそうだし、やってみてもいいかもしれない。あと単純に「俺ってあのときどんな本を読んでたっけ…」というのを後から見返すのは面白いかもしれないとも思う。

読書ノートの要件

紙のノートが良いという話だが、ノートやペンを常備しておくのも大変なので、やはりここは IT に頼りたいところ。なんか都合の良いツールはあるか。

読書ノートの要件としては、

  • だいたいいつも決まったフォーマットで書ける (日付、タイトル、著者、出版社、感想文、くらいか)
  • 画像貼れる
  • あとから検索したり一覧できると良い
  • 続けていくためにはとにかく手軽に追記編集できると良い

このへん。こう見るとテンプレートを添えた GitHub issue でも良さそうかって気がする。手軽かって言われるとやや重い気もする?けどとりあえずやってみてから考えようと思った。

ということでリポジトリを作ってみた。続くことを祈る。
https://github.com/pankona/reading-note

2021-12-15 追記

先述のリポジトリに、近頃読んだ本をいくらか issue として書いてみたが、なんとなくこれじゃない感を感じてしまった。登録しにくいということはないが、なんというか、なんとなくぱらぱら見返すのには適さないなと思った。ツイッターのタイムラインみたいな見た目で見れると良さそうな気がする。

GitHub issue とってきてタイムラインみたく表示する機能なんて聞いたことないが、どっかにすでにそういうのあったりするかな…?なければ簡単にそういうものを自作してもいいかもなー。

2021-07-18 11:44:36
文章力の基本 ~簡単だけど、だれも教えてくれない77のテクニック

「文章力の基本 ~簡単だけど、だれも教えてくれない77のテクニック」という本を読んだ。

image
こういった本

技術書典11 にサークル参加してみて、自分の文章力のなさみたいなものを痛感してしまったわけでありました。
もうちょっとまともに文章を書けるようにならねばならんなーと妻にぼやいてみたところ、妻が押入れから引っ張り出してくれたのがこの本。せっかく手元にあるわけだし、試しに読んでみるかと思って開いてみたらなかなかこれが面白い。面白いというか、良い文章を書くための即効性のあるテクニックがいっぱい羅列してあって、それでいてひとつひとつがなかなか納得感があり、読んだそばから役に立つ内容であると感じた。

シンプルに書く。短く書く。

「文は短く切る。シンプルに書く。」みたいな TIPS が、例文 (アンチパターンと修正案) と一緒に延々と紹介されていくのが本書の内容。77 個あって多いように思うが一個一個の TIPS はだいたい見開き 1 ページで収まる程度に短くまとまっているのでサクサク読める。一日あれば読み終えることができるくらいの分量。全部覚えていられたらいいが記憶力の関係でなかなか難しいので、何度か読み返す必要がありそう。

この本を読みながら、それにしても僕は普段から余計なことをいっぱい書いているなーと気付かされた。意味のない形容詞だとか枕詞だとかいっぱい並べたり、語尾に「〜みたいな」とか「〜と思う」のようなものをつけて主張を曖昧にして予防線を張ったり、主語を抜かしてみたり。本に書かれているアンチパターンは全部実践していると言っても過言ではなさそう。まさにいま僕が書いたこの一文を見ろ。長い。何が言いたいのか分からん。アンチパターンのバーゲンセールかよ。というこの一文もたぶん無駄だな。

無駄な形容詞

自分が書いた文 (技術書典で出した本や Slack でのやりとり、過去の自分のブログなど) を見返してみると、僕は かなりちょっと基本的に あたりの形容詞を、特別の意味なくなんとなくで付与することがかなりあるようで、ちょっとこれは基本的に基本が出来てないってことじゃないですかね…っなんてかなり思うわけであります。

というようなね。ちょっと気を抜くとすぐこういう文書になってしまう。「“基本的に” と形容する場合がありますが大抵の場合意味はありません」という説明が書かれていて笑ってしまった。確かに意味がない場合が多そう。あってもなくても基本的に文の意味は変わらない。うむ。こういった無駄な形容詞を取り除くだけでも、文書が結構スッキリしそうだな。

思う

自分は「〇〇だと思う」って言い回しを結構使ってしまうんだけど、コンテキストからして推測や非確定なことを述べているのが明確な場合は、いちいち「思う」をつける必要はないよね。わかる。
ただ、事実と推測を並べて述べるようなときはむしろ「思う」を付けておかないと事実なのか推測なのか伝わりにくいってことはありそう。問題は、あきらかに推測ではないのに「思ってる」を使っていることがあること。癖になってるのかもしれない。

自分の文やチャットでの発言を見返すと、「土日は休みだと思います」みたいなことを何故か書いてることもあった。「土日は休みです」で良いよな。何故いちいち「思う」のか。土日がしばしば出勤になり得るようなシチュエーションなら良いのかもしれないが、幸いなことに現職で土日が出勤になったことは一度もない。なのでやっぱり無駄に「思って」ということなんだろうな。

ちょっと意識して文を書いてみている

Slack や GitHub issue 等、文を書くことは頻繁にある。リモート全盛のご時世だっていうこともあって以前よりもその機会は多くなっている。本書の内容を全部覚えているわけではないが、たとえば先述した「無意味な形容詞を省く」、「ひたすら ◯◯ と思う で言い終わるのをやめる」、あたりの工夫は、シンプルなルールなのでサクッと始めることができる上に文書をシャープにする効果が高いと感じる。それだけ自分の書く文書にはこの手の “贅肉” が多いということなのであろうけど…。

一方で、普段のチャットからこのルールをあんまり徹底しすぎるとやや冷たい印象を与えるような気がしないでもない。チャットで口語を使うときと、レポート等でまとまった文書を書くときとではいくらか使い分けたほうがいいのかもねーなんてことも思った。

良い本

小難しいことは書いておらず、何度か読み返して実践すれば確実に良い文書が書けるようになる気がする。しばらくしたらまた読んでみよう。良本です。

2021-06-07 20:28:17
「リーダーの仮面」を読んだ感想

「リーダーの仮面」という本が本屋で平積みになっていたもんで、それじゃあってことで読んでみた感想。

image

自分自身がもっとリーダーらしくあるために等と思って手に取ったわけではない。エンジニアリングマネージャとしての自分の振る舞いになんらか足しになるかもしれない、何かの気付きになればいいかな、くらいの気持ちで読んでみた。割とさっくり読めて1時間~2時間くらいで読み終わった。

賛否両論ありそうな内容だなーと思った。最近のマネジメントの風潮 (ホラクラシーであるとかティール組織であるとか) をそれなりに否定するようなことが書かれている。なのでこれ一冊を読んで「よーしこれの通りにやってみるぞー」みたいに思ってしまったりすると、導入の仕方によっては組織に “合わない” ということもありえそうだなと感じた。目標管理を数字で管理するということも書かれていたが、目標を数字にしにくい仕事 (ソフトウェアエンジニアなんかはそうだと思うんだが) だと適用しにくかったりしないかな、なんてことも思う。

気になった点をちょっとピックアップしてみると、

  • リーダー (ちなみにマネージャと読み替えて読んでいた) はメンバーと距離を置くべきで、仲良しにならないほうがいい (1on1 も否定されていた気がする)
  • なるべく機械的に評価をする。プロセスをことさら評価することはせず、結果を見る。未達ならじゃあ次はどうやって改善するのか、達成ならそれはあたりまえとして扱ってやたら褒めたりすべきでない、というような振る舞いをする
  • メンバーのモチベーションをどうにかしようと思わなくてよい。それはリーダーの仕事ではない (会社とメンバーが成長していればそれでよい)
  • リーダーは短期の成果ではなく未来を見据えて采配する。待つ。

ここにピックアップしたものについて自分はひとつも実践していない気がしていて、本書の言葉を借りれば「リーダー失格」でありそう。1on1 毎週やってるしプロセスめっちゃ見るし (そもそも未達とか達成とかの基準すら定義していない)、モチベーションが大事だと思うのでモチベーション下がる要因とかヒアリングしたりするし。
未来を見据えて~というのはそれはそうだなと思った。うん。

数値で目標を管理するという点は、チームで測っているベロシティなんかは物差しとして使えるのかもしれない。でもこれもなんというか、達成すべき数値目標というよりは “チームの実力測定器” みたいなところあるしな。ちょっと文脈と合わないかもしれない。

仮面をかぶる

やや本を否定するようなことを並べてしまったが、参考になる話も多かった。例えばちょっとメタにとらえて「仮面をかぶる」という話はとても参考になった。
人は誰しも時と場合によって人格を使い分けている。家庭内なら父とか母とかのロールがあるわけだし、転じて職場ならマネージャやプレイヤーだったりする。属するコミュニティによって “ペルソナ” は変わる。組織でマネージャやっていれば場合によっては冷たいことを言わなければならないこともあり、結果として嫌われることもあろうが、それはペルソナの関係上そういうものであって、人格が否定されたわけじゃないから落ち込む必要はないんだよ、と。まあ分かる。

まあ分かるんだが人間そんなに割り切れるもんか?と思わんでもない。コードレビューはコードについて話をしているので書いた人の人格を否定するものではないのだが、それでもあれで心を傷める人類が後を絶たないっていうのと同じことで、ペルソナの話は観念的には理解できるものの、実態としてそこまで人類は高尚ではないよなぁ、と思わんでもない。

とはいえマネージャは仕事を全うするために、嫌われることを厭わず、言うことを言わなければならない場合もあろうというのは確か。自分はもうこれに関しては「嫌われて落ち込んで復活するまでが仕事」くらいのことを思ってたりする。割り切れてないな。もう少し経験を積んだらこのへんの感じ方や考え方も変わるんかねー、なんてことも思いつつ。

自主性に任せること

メンバーの自主性に任せてあまり細かなマネジメントしない、というスタイルにもやや否定的な論調で触れられていた。これだと成長する人は成長するが、そうでない人は置いてきぼりになってしまうよね、と。これはね、分かる気がする。新しい人とかはほったらかしにできるわけないしね。分かる。

割と自分はほったらかしにしがちな自覚がある。ほったらかしで成長する人はそれで良いんだけど、そうでない人に対しては本書で述べられているアプローチが効くパターンありそうかなーって思ったりした。使い分けが大事なのかもしれない。

総評

少なくとも直ちに自分 (と自分のチーム) に取り入れるには合わなそうな部分が多いかも、と感じたものの、なるほどこういう考え方もあるのね、という、リーダー (マネジメント) の考え方のひとつのカットとしては大いに参考になる内容だった。近頃の組織論とは結構切り口が違うと思うので、こういった本があるのも良いよね、って思いましたです。

2020-06-12 10:39:35
「THE TEAM 5つの法則」を読んだのでちょろっと感想

他の EM (Engineering Manager) から「THE TEAM 5 つの法則」という本をオススメされたので読んでみた。
読書感想文を書いておく。

とても読みやすい

内容とあんまり関係ない話ではあるが、スラスラ入ってくる感じの文体で非常に読みやすいと感じた。
理解が難しい箇所がほとんどなくて、読んでいてストレスがなかったのが印象的。本ってしばしば「途中まで読んだはいいもののまた再開するのが億劫で積まれていく」みたいになりがちかと思うが、そういう気持ちにはあんまりならなくて、サクッと再開する気持ちになれたというか、気楽に読めるというのはとても良いと思った。まあ内容に興味があったから早く先を読みたいっていう気持ちだっただけかもしれないが。
およそ 300 ページくらいでそんなに多くないのもあるけれど、サクッと読める感じでオススメ。

モチベーションの話

「モチベーションを出せ!」「気合だ!」等と言われてもモチベーションがあがらない (何なら下がるまである) というのは体感、あるいは体験として感じていたところではあるが、じゃあどのようにすればモチベーションが上がるんですかね、っていうようなことが書かれていてこのへんはとても興味深かった。
書かれていたのは結局のところ、「何にモチベーションを見出すのかは人それぞれだから、モチベーションを高める “それ” をお互いに提供できるように努めような」というような話なのかと理解していて (雑理解かもしれない)、まあそれはそうですよね、って思うところ。

なんだけども、そもそも「各々が何にモチベーションを見出すのか、あるいは何にモチベーションが下がるのか」っていうのをちゃんとチームの人々がお互いに知っているんだっけ?言語化できてるんだっけ?というとあんまりそんな気はしなくて、なのでそのへんの認識を合わせる何らかの催しみたいのはやってみたら面白いかもねぇ、等と思いながら読んでおったわけである。

だいたい「何がモチベーションになるか」なんて自分のことですら良く分かんない事柄ではありそう。

もう少し細かいモチベーションの話

本書には「4 種類のモチベーション」というのが紹介されていて、それは以下の 4 つであると。

  • Philosophy (理念・方針)
  • Profession (活動・成長)
  • People (人材・風土)
  • Privilege (待遇・特権)

これのうちのどれか 1 個にモチベーションを感じるというよりは、4 つそれぞれにどんだけモチベーション感じるかっていう感じで、ダイヤモンド的なグラフにできるようなものなんだろうと思う。
これらの分類分けっていうのはなんとなく"分かる"というか、これを念頭にメンバーの顔を思い浮かべると「あーあの人はこれにモチベーション感じてそうだなー」等と思い当たったりするような気もしてくる。
これを意識しながら 1on1 に望んだりすると、ちょっと相手への理解の解像度が増したりするのかもしれない。現在担当しているロール (マネージャなのか、そうでないのか、とか) によってどの類のモチベーションを感じやすい、みたいなのもありそう。

あとこれは他ならぬ自分自身がどれにモチベーションを感じているか、ってのを考えるのにも役立ちそう。セルフモチベートに用いるというかね。そういうの考えて整理しとくのも大事かと思われる。自分のような「最低賃金がまあまあであれば、あとは Go 書ければだいたい凄く満足するんだけどなー」みたいのは、「待遇そこそこ、活動強め」くらいな感じでモチベーション感じているのかなー、のように分類されるんだろうか。