昔、2週間に1回のペースで、読んだ本とか記事をまとめて感想をブログに書くという行為を試みた。しかし、3,4 回続けたところで頓挫してしまった。
1ヶ月ごとなら続けられるのではと思い、再チャレンジ。
雑記
「正解の無いクイズ」面白い
「正解の無いクイズ」というテレ東の番組が面白くて、U-NEXTで一気に観てしまっている。
U-NEXTは12月時点では登録してなかった。だが、トンツカタンが出ている有田ジェネレーションを観るために入会した。元々は1ヶ月でやめるつもりだったが、偶然見つけた「正解の無いクイズ」のせいで結局継続してしまっている。
加納さん・山添さん・呂布さんという、かなり僕得なメンツだった。短くて見やすいし毎回笑ってしまう。 深夜っぽい面子と内容だと思うんだけど（失礼）、なんと放送時間が夕方である。 地上波で実際に観たことはないので、未だに半信半疑。
加納さんで言うと「令和ロマンの娯楽がたり」でも、成立松していて惚れ惚れした。 実際に、くるまもサーヤ特番か何かで、「加納さんのおかげで番組が成立した」とかなんとか言っていた気がする。
以前に契約していたとき、U-NEXTは毎月ついてくるポイントが使い切れないという悩みがあった。
たとえば、スポーツ好きな人とかはSPOTV NOWとか契約するとちょうど良いらしい。ソースは内山昂輝の1クール。
僕はというと、NHKオンデマンドをU-NEXTから購読することで以前の悩みを回避した。書籍の方でたまにお世話になっている「100分de名著」を観てみようと思ったのがきっかけである。
個人的には維摩経の回が面白い。後、本にはない伊集院さんのコメント1つ1つが良い。
audibleを使い始めた
友達がaudibleで原著のハリーポッターを聴いてると話しているのをふと思い出した。
気になって、色んな本のサンプルを聴いてみると、「やはりプロはすごいな」と思わされる聴き心地だった。勢いでうっかり契約してしまった。
今は、だいぶ昔に読んだサピエンス全史を聴いている。やっぱり面白い。うっかり国立科学博物館に行って、地下二階をしっかり楽しんでしまった。
本では、あんまり興味ないところを読み飛ばしたりできる。だが、そういうのができないからこその良さが、朗読にはある気がする。多分。次は有頂天家族を聴こうかな。
日常をTODOリストにちょっとずつ支配させ始めた
「英語のボキャブラリービルディング」「ビタミンDのサプリ飲む」「筋トレ」など、習慣づけたいものがある。しかし習慣づかない。単語帳を何周もして、ちゃんと使い込むという経験をしたことがない。
新年に起こりがちな「今年は変わるぞ」という気持ちが、例年同様に今年も沸々と湧いてきた。その気持ちのまま、Google Tasksに日次でやりたいことを突っ込んだ。正直あまり効果が出るとは思っていなかった。以前に何回もやって続かなかった手法だったからだ。
しかし今回は違った。これは、Google Tasksが仕事でも使っているツールであり、消化しないとという気持ちが自然と働くようになったからだと推測している。
1-2月は登記や太陽光発電の申込などの新居関連のタスクも出てくる頃だったので、役に立っている。
読んだ本
正月の休みを活かしつつ、今月は4冊読んだ。
イシューからはじめよ
本の終盤でも語られていることではあるが、理解できるが実践が難しいような印象はある。
イシューの見立ては難しい。試しに火災保険を選ぶ上で「契約を結んだハウスメーカーと提携している火災保険よりも、大幅にリーズナブルで信頼性の高い保険があるのではないか」と見立ててみた。教科書どおりにスタンスを取りつつ、常識を否定する形で置いてみる。
ただ、スタンスを取ると確証バイアスが働いてしまうのか、致命的な見逃しをしてしまっていた。しっかり見直すと、結果的には「契約を結んだハウスメーカーと提携している火災保険の方がリーズナブルで信頼性や手続きの煩雑さの点でも十分である」という結論になった。
失敗だったなと思ったのは、リスク低い補償は削っても良いんじゃないかと思い調べていたが、リスク低いものは保険料も低いのでそこまで重要ではなかったということだ。これはサブイシューの洗い出しのミスだったかもしれない。
takeaways
- 「イシュー度」の高い問題を絞り込み、時間を浮かせ、解の質を高めていく
- イシューの見極めには「実際にインパクトがあるか」「説得力あるかたちで検証できるか」「想定する受け手にそれを伝えられるか」という判断が必要
- サブイシューを洗い出す際には「何がわかればこの意思決定ができるか」という視点で見る
- 解の質を高めるために作業が、「ストーリーライン」づくりとそれに基づく「絵コンテ」づくり
- 「仮説がすべて正しいとすれば」という前提でストーリーを作る
- 論理的に検証するストーリーを作るときの型は「WHYの並びたて」「空・雨・傘」
- 「空・雨・傘」は馴染みのあるパターン。「雨 = 課題の深掘り」がカギとなる洞察である
- 「聞き手は完全に無知だと思え」「聞き手は高度の知性をもつと想定せよ」
- 「賢いが無知」というのが基本とする受け手の想定
- デルブリュックの教え
DNSがよくわかる教科書
DNSを雰囲気でしか分かってなかったので読みました。
これに関連して WindowsのChromeやEdgeでネットにつながりにくくなる現象、一部の家庭用ルーターが原因かも？ という記事を読んだが面白かった。ホームルーターの性能も重要なんだなあ。
takeaways
- 主要なTLDで利用されているレジストリ/レジストラモデル
- スタブリゾルバ / フルリゾルバ / 権威サーバの関係
- CNAMEに設定したレコードには別のタイプでレコードを作れない
- なのでzone apexのレコードでCNAMEレコードは作れない
GitLabに学ぶ 世界最先端のリモート組織のつくりかた
特に、コミュニケーションガイドラインは、一部には根拠となる研究や調査が示されているというのもあり、定期的に見返したいくらい良い。
もしかしたら色んな既存の本に同じような内容が書いてあるのかもしれないが、それが現実にある成功している企業の実践として見ると素晴らしく思える。自分としては、そもそも関連する領域の書籍をあまり読んだことがないのもあり新鮮さもあった。
Valuesにあった “Short term critical, Long term optimistic” は座右の銘にしたいくらい好き。
takeaways
- 前向きな意図を想定する - Collaboration
- 他人の行動に対して無意識にアンフェアな判断を下してしまうようにできている
- 根本的な帰属の誤り（Fundamental attribution error）
- 創業者のように振る舞う - Collaboration
- 自分の責任を軽くするためにコンセンサスを取ったり、自分一人でできることを無駄に遠回しにしたりすることはコラボレーションではない
- ミスを許容する - Results
- あらゆるトラブルに対して、必ずしも新しいプロセス（再発防止策）を用意するべきではない
- 新しいプロセスを追加すると、そのプロセスを活用するすべてのアクションが非効率になる
- 組織の中でValueが重要な扱いをなされていることを組織の構成員が実感できなくてはいけない
- crucial conversationを行う際のポイントをValueに紐付ける
- 他にも色々ある…
改訂新版 書く技術・伝える技術
レバレッジを高めるためには、ちゃんと文章が書けなきゃねと思い読みました。実際、割と苦手意識がある。
理解はできたが実践までの距離がちょっと遠い本で、ちょっと長めの文章を書く機会があれば、本を読み返しつつ実践していくのが良さそう。
takeaways
- 読み手にできるだけ明確なメンタルモデルを作らせる
- ポイントとなる情報を先に述べ、読み手の予想通りに文章を展開するか
- 各パラグラフ冒頭の要約文だけを拾い読みしても意味が通るようにする
- 若干くどくても既知の情報を文頭に置き、既知から未知の流れを作る
- ひとつの文ではひとつのポイントだけを述べる
- 並列を表す「〜て」「〜り」「〜し」「〜が」などの接続助詞を使うな
気になった記事
10 unexpected ways to use GitHub Copilot - The GitHub Blog
自分が所属している組織ではGitHub Copilotを利用することができる。
10月からマネージャになったため、コードを書く作業から少し縁遠くなってしまった。Copilotもあまり使う機会はないかなと思っていた。
しかし、記事を読んだところ、思っていたより多岐にわたってサポートしてくれることがわかる。
GitHub Copilot in the CLI や Generate documentation for your code がいい感じ。現在Betaで提供されているEnterpriseの機能も良さそう。
SRE Governance - Site Reliability Engineering Leadership
この記事は2020年に書かれたもの。 SRE Weekly に載っていたので読んだ。
authorはEpam Systemsという会社でSREのチーフテクノロジストをしている。以前はFacebookでSREのLeaderをやっていた人みたい。
ざっくり言うと、「SREと各チームのシニアエンジニアを集めて、CoE（Centor of Enablement）グループを作る。」「そして、SLO ReviewやProduction Readiness Review etc…を定期的に行う。」 というのが紹介されている。
SREだけで各種レビューするのは、難しい面があると常々感じている。また、各開発チームの横の繋がりを作る機会も増やせたら良いとも思っている。このアプローチはそれらの点に対する1つの解になっている。
SLO ReviewやProduction Readiness Review の他にも、Tool Standardization やら System Critical Dependency Review やらが紹介されている。
正直「多すぎないか」と思うけれども、Facebookくらい大きい会社だと、このくらい必要なのかもしれない。あるいは、中規模でも必要で払うべき時間と労力なのに、それが現状できていないのかもしれない。
OpenTofu 1.6 General Availability: Open Source Infrastructure as Code - THE NEW STACK
terraformのライセンス変更から生まれたOSSがついにGAになった。
MPL v2.0からBSL v1.1 へと変更し、私たちのようなエンドユーザには影響がないが、競合する提供を行うspaceliftなどの企業が影響を受ける。
この影響がどのくらいあるのか推測できなかったが、Open Source in Numbers: The Terraform License Change Impact on Contribution いわく、community PRの割合は減少傾向にあるようだ。
OpenTofuに利用を切り替える可能性というのは高くないと思うが、注視はしておくべきかもしれない。
ちなみに、最初はOpenTFの予定だったらしいが、商標権の侵害にあたる可能性を恐れてOpenToFuになったらしい。日本語話者にとっては馴染み深くて良い。
