勘と経験と読経

略すとKKD。ソフトウェア開発やITプロジェクトマネジメントに関するあれこれ。

「ソフトウェアアーキテクチャの基礎」を読む Part.3(完結)

読むのがホネな技術書やビジネス書を取り上げて2週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第63回。同僚と読書期限を約束することによって積読が確実に減るという仕組み。過去記事はこちら

さて、今回は「ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ」の完結編(第3部)だ。けっこう分厚いので3回(×2週間)に分けて読んだ。今回は「第III部 テクニックとソフトスキル」を読んでいく。

過去2回の記事はこちら

「ソフトウェアアーキテクチャの基礎」全体の感想

今回で最後まで読めたので、本書全体の感想を先に述べておこう。

  • 個人的には、アーキテクチャに関する鉄板本は「ソフトウェアシステムアーキテクチャ構築の原理 第2版」だったが、今後は本書をスタンダードにしたいと思う。アーキテクトを名乗るなら読んでおいてほしい本だ
    • もちろん構築の原理も良い本だ(特にビューポイント/観点集として)。しかし同書はどちらかというとアーキテクチャを静的なものとして扱っているきらいがある。現在のアーキテクチャの多くは動的なものだ
  • レガシーなものからモダンなアーキテクチャまでの概論を包含しており、包括的で見通しが良い。ここから始めると良さそう(もちろん深掘りするためには別の検討は必要になる)
  • 目指すべきアーキテクト像もモダンである。ファシリテーターであり、コラボレーターであり、プレゼンターであるというのは重要な指摘ポイントだと思った(この点は本記事の後半でも触れる)

第III部 テクニックとソフトスキル

今回読んだ第III部であるが、読む前には一抹の不安があった。なんというか、類書を沢山読んでいるので「また似たような話かー」となる懸念があったのだ。しかし、それは杞憂だった。

ひとことで言えば、アーキテクト像もちゃんとアップデートされている。全体の感想で書いた通りだが、ファシリテーターであり、コラボレーターであり、プレゼンターであることについて書かれているのが興味深い。

ファシリテーター

本書ではアーキテクチャそのものが動的なものであり、アーキテクトだけが構築していくわけではないというコンセプトに従っていると理解している。その上で、例えばアーキテクチャのリスクを分析する際には「リスクストーミング」という手法でメンバーと共にリスクを特定し改善する方法が示されている。

アーキテクトが単独でシステムの全体的なリスクを決定することはできない。一人ではリスク領域を見落とす可能性があるし、システムのすべての部分について完全な知識を持っているアーキテクトはほとんどいないからだ。そこで役に立つのが、リスクストーミングだ。
ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ、20章 アーキテクチャ上のリスクを分析する より

コラボレーター

同様に、チームでのコラボレーションに関するテクニックについてもいくつかの章が割かれている。「22章 効果的なチームにする」では、アンチパターンとしてのアーキテクトタイプとして「コントロールフリーク(すべての決定をアーキテクトが行う)」「アームチェアアーキテクト(コーディングをせず抽象的な決定ばかりする)」を示したうえで、チームに適切な制約と境界をつくり出してコラボレーションすることの重要性が語られていて興味深かった。

またチームとの境界を定めるためには、トレードオフスライダーに似た「コントロール量の尺度(メーター)」を用いて、どこまでコントロールするのかを調整するという話はかなり面白い。

プレゼンター

著者はアーキテクトに政治的な状況への対応力が必要であると述べる。

本書の冒頭で、アーキテクトに期待されることを挙げたが、その最後に、ソフトウェアアーキテクトは企業の政治的な状況を理解し、その政治的な状況を切り抜けられなければならないという期待を挙げた。このような期待が挙げられる理由は、ソフトウェアアーキテクトが下すほぼすべての決定には異議が唱えられるからだ
ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ、23章 交渉とリーダーシップのスキル より(下線は本記事の筆者)

下線の箇所は、なるほどと膝を打ったところである。

その上で、利害関係者との調整のために

現代のアーキテクトに求められるもう1つのソフトスキルは、PowerPointKeynoteのようなツールを使って効果的なプレゼンテーションを行う能力だ
ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ、21章 アーキテクチャの図解やプレゼンテーション より

という主張があるのも納得である。

なお著者の一人であるNeal Fordさんは「Presentation Patterns: Techniques for Crafting Better Presentations (English Edition)」という本も執筆しているからか、プレゼンテーションの方法については楽しいアンチパターンがいくつも紹介されていて興味深かった。いつかこの本も読んでみたい。

エンジニアリングモデルとコントラクタモデルと納期のはなし

牛尾さんの「納期がなぜ生産性をぶち壊しにしているのか?」という記事を読んで考えたこと。あるいはインターネットが屑情報ばかりになってしまう現象への個人的な抵抗。

牛尾さんの記事では、特に日本では重視されがちのようにみえる「納期」というものがソフトウェアエンジニアの生産性に悪影響を与えるということ、現所属および周囲の北米企業では「納期」の少ない良い環境であることを示している。その論には強い異論はないのだけれども、「納期」というキャッチーな(?)用語を使ってしまっているので、論点の見通しが少し悪いようだ。

そこで、いろいろな見方があると思うが「文化」の話と「現場」の話に分けて、関連書籍などを紹介しながら論じてみたい。

エンジニアリングモデルとコントラクタモデル(文化の話)

納期という単語に反応すると「それは契約の話なのでは」となってしまいがちだが、もう少し抽象度を上げると企業文化の話になるだろう。というわけで「要件最適アーキテクチャ戦略」で紹介されているエンジニアリングモデルとコントラクタモデルについて紹介したい(なおこの本自体は正しくモノリスを作るDDDの本である。詳しくは以下の過去記事を参照)。

ちょっと長いが引用してしまおう。ちなみに引用部分を書いたのはリーン開発本で有名なMary Poppendieckさん。

 この機会に、コントラクタモデルの対極にあるエンジニアリングモデル手法をソフトウェア開発に取り入れるという考えを紹介したい。まず、典型的なコントラクタモデルについて考えてみよう。このモデルでは、従業員と実際の請負業者のどちらで使われるとしても、開発者には担当する作業が正確に指示され、少しの失敗も許されない。エンジニアリングモデルでは、仮説に基づく実験を使って、学習と改善を行いながら複数の選択肢を検討する。
 SpaceX とTesla はエンジニアリングモデルを採用している。対照的に、ほとんどのソフトウェアプロジェクトはコントラクタモデルを採用している。この対立する2 つのアプローチを並べてみた場合、ソフトウェア業界全体での1 人あたりのイノベーションを最大化するのがどちらであるかは明らかである。
 SpaceXペイロードを宇宙に打ち上げるコストを劇的に削減し、ブースターロケットを回収して再利用するという主要目標を――― 予定を大幅に短縮した上で達成した。どうやってなし遂げたかというと、SpaceX は近年まで宇宙探査の唯一の資金調達法とされていた政府との請負契約を結ばなかった。(中略)というのも、あらゆることについて耐えがたいほど詳細な検討を重ねるのではなく、とにかくいろいろなことを試して未知の未知を発見しようとしたからである。エンジニアリングのアプローチとしてはかなり典型的なものだが、コントラクタモデルでは決して許されないものだ。SpaceX チームによれば、墜落させて問題を見つけ出すほうが、リスクがなくなるまで待っているよりもずっと安上がりだったそうだ。
要件最適アーキテクチャ戦略(P.43)

私の理解する限りにおいては

  • エンジニアリングモデル:仮説に基づく実験を使って、学習と改善を行いながら推進する。アジャイル的なアプローチ(納期はない)
  • コンストラクタモデル:請負契約に基づき、計画駆動で推進する(納期はある)

ということだろうと思う。「要件最適アーキテクチャ戦略」ではもちろん目指すべき形はエンジニアリングモデルとされている。一方でエンジニアリングモデルを選択するということは企業の戦略であり、文化の変革の話であり、リスクを取る選択をすることになるだろう。このリスクが取れるのであれば「納期のないエンジニアリング」は実現できるのだ。

逆に言えば、リスクを取らずにコンストラクタモデルの文化を続ける会社で「納期のないエンジニアリング」を実現するのは(不可能ではないだろうか)難しい。
(ちなみに、Space Xがめちゃくちゃリスクを取っている話は自伝「イーロン・マスク」に描かれている。波乱万丈すぎて面白い本だった)

納期と期日と目標(現場の話)

牛尾さんの記事で気になったのは、以下の箇所である。

日本にいた時には何でも納期が付いて回ってた気がする。凄ーくちいさな仕事を頼まれても「〇〇日までにお願いします」と納期が付いてくる。今からするとなんにでも納期が付いて回る感覚だ。
納期がなぜ生産性をぶち壊しにしているのか?|牛尾 剛

「〇〇日までにお願いします」は、わたしの感覚で解釈すると期日か、単なる要望である。これを納期と捉える感覚には違和感がある。
ただ、実際には特に日本の現場ではこういった言葉の誤用・乱用が多いのも事実だ。例えば納品物と成果物、善管注意義務プロマネ義務、プロトタイプとMVPなどなど。ソフトウェアエンジニア的には様々な用語の定義に敏感であってほしいものだが、仕様と技術用語以外はルーズになってしまうのは割と不思議である。

実際のところ、納期(または納品日)は契約で定めるものであり、守らなければならないコミットメントである(これを守らなければ債務不履行になる)。逆に言えば納期だけは特別な約束であり、それ以外の日付はそこまで厳格なものではないし、調整余地も多いはずである(もちろん納期だって適切な手続きを取れば変更できる)。納期(コミットメント)を達成するためには様々なタスクに分解しマネジメントする必要があるが、分解したタスクの終了予定日は納期ではない。遅れたら他で取り返せば良いし、そういったリスクも含めて管理する方法はいろいろあるだろう(個人的にはTOC理論が好き)。

ちなみに現在も有用な古典的名著である「ソフトウェア見積り 人月の暗黙知を解き明かす」では第1章で「見積り、ターゲット、コメント」は異なるものだと言っていた。同じ話だ。

 辞書にある「見積り」の定義は、厳密な意味では正しい。見積りとは、プロジェクトにかかる期間やコストを予測することだと言ってよい。だが、ソフトウェアプロジェクトの見積りとは、ビジネスのターゲットと、コミットメントと、コントロールとの間の相互作用である。(中略)
 ターゲットが実現したいビジネス目標の記述であるのに対して、コミットメントとは、定義された機能を、特定の品質レベルを確保しながら期日までに納品するという約束を意味する。コミットメントと見積りが、同一のものを指すこともあるが、コミットメントが見積りより挑戦的だったり保守的だったりすることもある。言い方を変えると、コミットメントと見積りが同一でなければならないと考えてはいけない。そもそも同じものではないのだ。
ソフトウェア見積り 人月の暗黙知を解き明かす (P.4)

雑なまとめ

というわけで

  • 所属する企業の文化を確認しよう。コントラクタモデルな文化の企業やプロジェクトで納期不要論を主張しても仕方がない。転職しよう
  • 日付の話が出たらそれは「納期」なのか「期日」なのか「目標」なのかをちゃんと確認しよう。勝手に目標を納期と誤解してあたふたするな(相談すればなんとかなることもあるよ)

そんじゃーまた

「ソフトウェアアーキテクチャの基礎」を読む Part.2

読むのがホネな技術書やビジネス書を取り上げて2週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第62回。同僚と読書期限を約束することによって積読が確実に減るという仕組み。過去記事はこちら

さて、今回は前回につづき「ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ」である。けっこう分厚いので3回(×2週間)に分けて読んでいる。今回は「第II部 アーキテクチャスタイル」を読んでいく。

アーキテクチャスタイル

本書における「アーキテクチャスタイル」の定義は以下のようだ。

これは一般的な定義と同一のよう。

ただ、パタンランゲージの話と(自分は)混同しがち。気をつけよう。

ほとんどのアーキテクチャスタイルは、繰り返し現れる特定のパターンに気がついたアーキテクトたちによって、後から命名される。次に来る大きなムーブメントを決めるような、秘密のアーキテクトグループが存在しているわけではない。むしろ、アーキテクチャスタイルの流行は、ソフトウェア開発のエコシステムが変化していく中で、多くのアーキテクトが共通の意思決定をしていることを表している。人々に模倣されるようなアーキテクチャスタイルは、ソフトウェア開発のエコシステムの変化に対処し、そこから利益を得るための共通で最善の方法から生まれてくるのだ。

本書で紹介されるアーキテクチャスタイル

「第II部 アーキテクチャスタイル」では以下のようなアーキテクチャスタイルが紹介される。巨大な泥団子から話が始まるのがすき。

「スペースベースアーキテクチャ」はほとんど遭遇したことのないやつ。あと「サービスベースアーキテクチャ」はこういった名前付けを知らなかった。
それぞれのスタイルに対しての評価が付されているのは興味深い。

第II部で興味深かった記述

9章 基礎

10章 レイヤードアーキテクチャ

16章 オーケストレーション駆動サービス指向アーキテクチャ

  • いわゆるSOAのことだが、メタクソにいわれていておもしろい

もしかすると、このアプローチが魅力的なものに聞こえたかもしれない。しかし、実際には、こうしたアプローチのほとんどが失敗に終わった。トランザクションの動作をオーケストレーションツールにオフロードすることは良いことのように聞こえるが、トランザクションの粒度を適切なレベルで見つけ出すのは、ずっと難しいものだった

このアーキテクチャで最も致命的だったのは、技術による分割を重視したアーキテクチャ構築が非現実的であると実感したことだった。

  • まあ、言いたいことはわかる。実際に難しかった。

次回は「第III部 テクニックとソフトスキル」である。アーキテクチャではなく、アーキテクトという職業について語られていると思われるので楽しみだ。

「ソフトウェアアーキテクチャの基礎」を読む Part.1

読むのがホネな技術書やビジネス書を取り上げて2週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第61回。同僚と読書期限を約束することによって積読が確実に減るという仕組み。今年も、たんたんとやっていきます。過去記事はこちら

さて、今回から取り扱うのは「ソフトウェアアーキテクチャの基礎 ―エンジニアリングに基づく体系的アプローチ」である。読もう読もうと思っている間に2年経ってしまった(発売は2022年03月)。けっこう分厚いので3回(×2週間)に分けて読んでいく。

なぜいま「ソフトウェアアーキテクチャの基礎」なのか

ソフトウェアアーキテクチャに関する様々な事項が「変化」したからである。第1章ではこう書かれている。

なぜ今、ソフトウェアアーキテクチャの基礎を扱う書籍なのか。ソフトウェアアーキテクチャの範囲は、刻々と変化するソフトウェア開発エコシステムの一部だけに留まらない。新しい技術や手法、能力……実際のところ、この10年で、こうしたすべてのものは変化していっている。ソフトウェアアーキテクトは、そうした刻々と変化するエコシステムの中で意思決定をしなければならない。意思決定の判断基準を含めて、すべての物事が変化していっているのなら、アーキテクトである私たちは、以前にソフトウェアアーキテクチャについて書かれた記述が前提としていた中核的な公理さえも見直さなくてはならない。

本書以前のソフトウェアアーキテクチャの教科書と言えば、「ソフトウェアシステムアーキテクチャ構築の原理 第2版」がある(原著:2012年 訳書:2014年)。良い本である。しかし……

本書の冒頭でも同じようなことが端的に触れられている。

長年にわたり、ソフトウェアアーキテクチャの定義は「後から変更するのが難しいもの」という皮肉なものだった。しかし、マイクロサービスアーキテクチャの登場によって、現在は変化こそが第一級の設計上の考慮事項となった。

今回読んだ範囲(1章 イントロダクション+第I部 基礎)の感想

今回は3回に分けて読んでいく。第1回の範囲は「第I部 基礎」の終わりまで。次回は第Ⅱ部、そして最終回は第Ⅲ部の予定である。
第I部までは、アーキテクトの役割、考えるべきことについての説明が行われている。図も多くわかりやすい本という印象である。現代のソフトウェアアーキテクチャに関係する人は読むべき内容だし、知識のアップデートが必要な人にも役立つ内容となっているのではないか。

  • 1章 イントロダクション:とても良い。ソフトウェアアーキテクチャとは何かと、アーキテクトの期待役割が説明される
    • とくにアーキテクトの期待役割に「アーキテクチャを継続的に分析する」と「最新のトレンドを把握し続ける」「さまざまなものに触れ、経験している」が含まれているのが良い。
  • 第I部 基礎

第Ⅱ部からは代表的なアーキテクチャパターンが語られるようだ(まだ読んでいない)。第I部で紹介された考え方を用いて展開されると期待しているので楽しみである。

名言、金言について

本書で面白いと思ったのは、著者たち自身、もしくは著者が見聞きした達人の名言や金言がいろいろな場所で紹介されていることだ。今回読んだ範囲で面白いとおもったものを記録しておく。

  • 「未知の未知があるため、すべてのアーキテクチャはイテレーティブにならざるを得ない。アジャイルはそのことを理解して、より早く未知の未知に対処するようになっている」Mark Richards(著者)
  • アーキテクチャとは、Googleで答えを見つけられないものだ」Mark Richards(著者)
  • アーキテクチャには正解も不正解もない。あるのはトレードオフだけだ」Neal Ford(著者)
  • プログラマーは利点はわかっているが、トレードオフはわかっていない。アーキテクトはその両方を理解する必要がある」Rich Hickey(プログラミング言語Clojureの生みの親)
  • アーキテクチャに間違った答えはない。高くつくものがあるだけだ」Mark Richards(著者)

さて、それでは次は、第Ⅱ部 アーキテクチャスタイル にとりかかろう。つづく

2023年に行った美術館・博物館展示のまとめとふりかえり

2023年に行った美術館・博物館展示をまとめてみる記事。instagramライフログ的な記録はつけているのだけれども検索しにくいのでまとめてみたのと、ふりかえりをしようと思ったのだった。美術館や博物館に行くのは半分趣味だけど、年をとっても感性と知的好奇心が死なないように自分にとって理解困難なものに触れる機会を大切にしている。脳の筋トレ。

昨年の振返りはこちら

ふりかえり

2023年に行った美術館・博物館展示のまとめ

2023年4月

来年もいろいろ行きたい。

2023年下半期に読んだ本まとめ

2023年7月~12月に読んだ本のまとめ。カウント対象は期間中に読み終わったものに限り、読みかけの本は対象外としている。あとコミック、漫画雑誌類もけっこう読んでいるのだけれども、これは除外。
この6カ月では70冊の本を読んだらしい。2023年通年で読んだ本は132冊だったようだ(昨年より7冊多いだけなので、割と平常運転である)。老眼鏡を新調したのが良かったかもしれない。

いつもどおり半期で読んだ本の中で良かったものをピックアップしてみる。

文芸書のおすすめ(一般編)

この本を知ったきっかけは、町田市民文学館で春に行われた今日マチ子さんの 「『わたしの#stayhome日記』2020-2023展」で、京マチ子さんと辻村深月さんの対談を拝聴したことだった。京マチ子さんの展示もコロナ禍をテーマにしたものだったが、本書もまさにコロナ禍がひとつのキーワードの本である。実際にコロナ禍に学生時代がぶつかった現役世代の苦しみと悲しみを知ることは出来ないが、本書を読むことによって共感することはできる。そして共感しておくことは大事だとも思うのである。
youtu.be

文芸書のおすすめ(趣味のSF編)

昨年話題になった本ではある。第2次世界大戦中にコンピューター、インターネット、携帯電話が存在しナチスがそれを活用していたらという設定のSF小説である。読み終わった後に思い出すのは「HHhH プラハ、1942年 (創元文芸文庫)」(本書もお薦め)であり、結局のところナチスというもの自体が衝撃的な異質な存在であるということである。この半期にはアーレントや、夜と霧なども読んでいおり、いろいろ考えることがあった。加えて本書は現代の風刺・批評にもなっている。第2次世界大戦が舞台にもかかわらず、現代を感じるのだ。今年前半に「監視資本主義―人類の未来を賭けた闘い」を読んでいたので緊張を感じる。ともかく、脳を刺激する良いSF小説ではないだろうか。

教養書のおすすめ

動物たちは何をしゃべっているのか? (WPB eBooks)
愛聴しているポッドキャスト「ゆる言語学ラジオ」で紹介されていたので手に取った本である。シジュウカラ語を研究している(?)研究者・鈴木俊貴先生とゴリラ研究者の山極先生の対談本ということだが、対談故にテーマである動物の話だけではなく、こぼれ話も含めて大変に面白く、楽しい本。我が家は庭に巣箱をかけていて毎年シジュウカラが巣をかけており、日常的にもシジュウカラ語に親しんでいるということもあるのだが、たいへんに楽しめた。とりあえず以下の動画を面白いと感じた人は手に取ってみると良いのではないだろうか。
youtu.be

ビジネス書のおすすめ

一般的にはソフトウェアエンジニア向けの技術書になるのだが、あえてビジネス書としてお勧めしたい一冊である。現代ではすべての仕事にデジタル知識が必要となっているという意味で、ソフトウェア開発をしていない人にもお勧めしたい点がたくさんある一冊だと思う。詳しくは以前に書いた以下の記事も参照いただきたい。

どんな本か確認したいのであれば以下の動画の6分~40分を見ると良いだろう。
www.youtube.com

技術書のおすすめ

こちらも数年前に話題になっていた本だと記憶しているが、やっと読んだら大変に良かった。ただし翻訳には難があるので注意である。書籍のテーマは、ビッグテック企業で行われていると呼ばれている面接時の「システム設計をテーマにした試験」対策である。例えば「動画配信システムのアーキテクチャを考え、いま説明してください」というような面接試験が行われており、その時にどう考えて回答するかのヒントが説明されている。これが転じて(転職活動に関わらず)技術者の脳トレに良さそうなのだ。本書はコードまでは踏み込まず、アーキテクチャレベルでどう考えているかに注力しているのもコンパクトで良い。いろいろと技術者的な知的好奇心が満たされる良い本だった。
以下にも感想を書いている。

この半期の振り返り

今年は夏休みを中心に「読みたかった名著」を読めたのが良かった。おすすめ書籍では取り扱わなかったが「カラマーゾフの兄弟」「夜と霧」「茶の本」は何れも名著であり、読まずに死ねなかった。一方で、まだまだ読みたい本は沢山ある(それどころか積んである)。来年上半期には積読を解消して、夏休みから下半期にかけては他の大著にもチャレンジしたい。

2023年下半期に読んだ本

  1. NSA 上 (ハヤカワ文庫SF)
  2. NSA 下 (ハヤカワ文庫SF)
  3. アメリカ紀行 (文春文庫)
  4. 絵のある人生―見る楽しみ、描く喜び― (岩波新書)
  5. ガーンズバック変換
  6. 人が増えても速くならない ~変化を抱擁せよ~ ⇒(★書評
  7. ツインスター・サイクロン・ランナウェイ (ハヤカワ文庫JA)
  8. 基礎からわかる 論文の書き方 (講談社現代新書)
  9. カラマーゾフの兄弟1 (光文社古典新訳文庫)
  10. 祖国とは国語(新潮文庫)
  11. 文学は予言する(新潮選書)
  12. すべては1人から始まる――ビッグアイデアに向かって人と組織が動き出す「ソース原理」の力
  13. 老神介護 (角川書店単行本)
  14. レペゼン母
  15. ソフトウェアテストをカイゼンする50のアイデア
  16. 残月記
  17. スーパーユーザーなら知っておくべきLinuxシステムの仕組み
  18. この夏の星を見る (角川書店単行本)
  19. 動物たちは何をしゃべっているのか? (WPB eBooks)
  20. カラマーゾフの兄弟2 (光文社古典新訳文庫)
  21. ケアとは何か 看護・福祉で大事なこと (中公新書)
  22. そして、よみがえる世界。
  23. DX失敗学 なぜ成果を生まないのか ⇒(★書評
  24. 運動の神話 上
  25. プロジェクトぴあの(上) (ハヤカワ文庫JA)
  26. プロジェクトぴあの(下) (ハヤカワ文庫JA)
  27. わたしたちの登る丘 (文春文庫)
  28. バリューサイクル・マネジメント ~新しい時代へアップデートし続ける仕組みの作り方
  29. カラマーゾフの兄弟3 (光文社古典新訳文庫)
  30. 中動態の世界 意志と責任の考古学 (シリーズ ケアをひらく)
  31. スタッフエンジニア マネジメントを超えるリーダーシップ ⇒(★書評
  32. 運動の神話 下
  33. 無情の月 上 (ハヤカワ文庫SF)
  34. 無情の月 下 (ハヤカワ文庫SF)
  35. 今を生きるための現代詩 (講談社現代新書)
  36. 社会を知るためには (ちくまプリマー新書)
  37. 1973年に生まれて 団塊ジュニア世代の半世紀
  38. カラマーゾフの兄弟4 (光文社古典新訳文庫)
  39. プロダクトマネージャーのしごと 第2版 ―1日目から使える実践ガイド ⇒(★書評
  40. 科学哲学の冒険 サイエンスの目的と方法をさぐる (NHKブックス)
  41. カラマーゾフの兄弟5~エピローグ別巻~ (光文社古典新訳文庫)
  42. 夜と霧 新版
  43. システム運用アンチパターン ―エンジニアがDevOpsで解決する組織・自動化・コミュニケーション
  44. 文にあたる
  45. 安野光雅作品集
  46. GitLabに学ぶ 世界最先端のリモート組織のつくりかた ドキュメントの活用でオフィスなしでも最大の成果を出すグローバル企業のしくみ ⇒(★書評
  47. マルドゥック・アノニマス 1 (ハヤカワ文庫JA)
  48. マルドゥック・アノニマス 2 (ハヤカワ文庫JA)
  49. ドリーム NASAを支えた名もなき計算手たち (ハーパーBOOKS)
  50. 大人のいじめ (講談社現代新書)
  51. システム設計の面接試験 ⇒(★書評
  52. 入門 モダンLinux ―オンプレミスからクラウドまで、幅広い知識を会得する
  53. 鋼鉄紅女 (ハヤカワ文庫SF)
  54. どこからが病気なの? (ちくまプリマー新書)
  55. Software Requirements Essentials: Core Practices for Successful Business Analysis (English Edition) ⇒(★書評
  56. 新装版 七回死んだ男 (講談社文庫)
  57. 社会を変えるには (講談社現代新書)
  58. 鏖戦【おうせん】/凍月【いてづき】
  59. 茶の本
  60. 戦争の地政学 (講談社現代新書)
  61. 因果推論の科学 「なぜ?」の問いにどう答えるか (文春e-book)
  62. 世界一流エンジニアの思考法 (文春e-book) ⇒(★書評
  63. 学校では教えてくれない! 国語辞典の遊び方 (角川文庫)
  64. 美学への招待 増補版 (中公新書)
  65. 勉強の哲学 来たるべきバカのために 増補版 (文春文庫)
  66. すべて真夜中の恋人たち (講談社文庫)
  67. シャーロック・ホームズとシャドウェルの影 クトゥルー・ケースブック (ハヤカワ文庫FT)
  68. シャーロック・ホームズとミスカトニックの怪 クトゥルー・ケースブック (ハヤカワ文庫FT)
  69. 今を生きる思想 ハンナ・アレント 全体主義という悪夢 (講談社現代新書100)
  70. mRNAワクチンの衝撃 コロナ制圧と医療の未来

過去の読書ふりかえり記事

あと過去にこんなのも書きました

2023年に買ってよかった老眼対策グッズ

2023年に老眼対策グッズを買ってQoLが向上したという話。遠近両用メガネと読書灯とアイケアグッズについて。

老眼マジでつらい

もともと視力は良い(現在も裸眼で両目1.2)のだけれども、40代後半で老眼がひどくなった。最初は+1.0のリーディンググラスを愛用していたが、在宅勤務比率が今年に入って下がり(といっても半分も出社していないのだけれども)、眼鏡のかけはずしも面倒になってきた。特に通勤電車の読書時と、オフィスにおけるワークスペース間の移動(個人スペースと会議室の行き来)の時のストレスが大きい。あと、車を運転している時(当然リーディンググラスはかけていない)に、(もちろん停車して)スマートフォンで地図を確認するときに、読めないんだこれが。

togetter.com

というわけで難儀をしていたのだ。

遠近両用レンズの眼鏡を買った

そこで買ったのが遠近両用レンズの眼鏡である。
ネットでいろいろ調べた結果、眼鏡市場のストレスフリー遠近レンズを選択したが、これは正解だった。
www.meganeichiba.jp

  • 検査の結果、レンズの上側は素通し(度なし)で、下側は+1.75の設定にしている。
    • 本当はもう少し強いレンズが最適とのことだったが、遠近両用メガネの初心者ということもあり弱めの設定で作った
    • 眼鏡市場は「見え方保証」という制度があり6カ月以内であったらレンズの交換が無料で可能とのこと。というわけで購入6カ月前に再検査してレンズの交換ができるようだ

作ったメガネをかけはじめての感想は一言でいうと「老眼なくなった」である。

  • 老眼の見づらさを感じることはほとんどない
  • 遠近両用レンズ特有の視界のゆがみは(レンズの良し悪しはわからないのだけれども)特に気にならない。気持ち悪くなったり、酔ったりすることもなし
  • 唯一気になるのはホコリの不着などによるレンズのよごれだが、拭けば済む話なのでたいしたものではない

というわけで、このメガネが今年買ってよかった最大のものである。
来年は同じ設定のサングラスの購入も考えたい。

ネックライトタイプの読書灯も買った

視力の問題はメガネで解決したのだけれども、自宅の読書体験の向上を図るべく購入したネックライトタイプの読書灯も素晴らしく良かった。
購入したのは有名なこちら。

Amazonで10万評価がついている理由がよくわかる。読書に限らず使い方さまざまで超便利な glocusent『ネックライト』/佐藤誠二朗 | マイナビニュース

  • 自宅でのみ使用。物理書籍を読むときに使用しているが、ラップトップPC作業の時なども、明るさが気になる時には補助的に付けている
  • 本当に明るい。そして老眼になると明るさと読みやすさがものすごく相関することがよくわかる
  • 使用時には気にならないが、意外と大きいので置き場所には少し困っている
  • 別に気にならないが、ライトとバッテリーが使用時にうっすら発熱する

就寝時にホットアイマスクを使うようにした

いろいろと工夫しても、一日が終わるとけっこう目が疲れている。というわけで就寝時にはこちらのホットアイマスクを使うようにしたら、なんとなく調子が良い。

あずきのチカラ 目もと用 - 製品情報 - 小林製薬株式会社

  • 1年程度くり返し利用できるタイプ(250回使えるらしい。毎日使うわけではないので、1年たったら交換しようと思っている)
  • レンジで30秒温めるだけ
  • なんとなく、重みがあって心地よい

というわけで、振返ってみると老眼対策グッズばかりが思い出される2023年だった。もちろん本ブログで紹介しているとおりに大量に書籍は購入しているんだけど、これはいつものことだからなぁ……
老眼に苦しんでいるならご検討いただければ幸いである。