勘と経験と読経

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

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

Work Professional Engineer

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

老眼マジでつらい

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

togetter.com

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

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

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

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

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

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

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

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

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

GlocusentアップグレードLEDネックライト 読書灯 30分タイマー ブックライト 3段階調色＆調光 Type-C充電式＆長時間点灯 読書/もの編み/修理

GlocusentアップグレードLEDネックライト 読書灯 30分タイマー ブックライト 3段階調色＆調光 Type-C充電式＆長時間点灯 読書/もの編み/修理

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

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

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

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

小林製薬 桐灰 あずきのチカラ 目もと用 1個

小林製薬 桐灰 あずきのチカラ 目もと用 1個

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

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

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

Inside MSという視点で「世界一流エンジニアの思考法」を読んだ

book Professional Engineer

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

さて、今回読んだのは「世界一流エンジニアの思考法 (文春e-book)」である。日本のIT業界で有名な著者の牛尾さんが米国に渡りマイクロソフト（MS）のエンジニアとなって感じたことを中心に書かれた本である。

世界一流エンジニアの思考法 (文春e-book)

世界一流エンジニアの思考法 (文春e-book)

Amazon
いろいろと興味深い本書であるが、私はMSの変化を考えるという視点で読んでみた。

「世界一流エンジニアの思考法」の概略

冒頭にも書いた通り、本書は現在MSで働く著者が見聞きした事を中心に、世界一流エンジニアの思考法を考え、それを取り込もうという話である。以下の著者のnote記事がベースとなっているとのこと。

低プレッシャーで自己組織化されたチームで、サーバントリーダーシップなマネージャーのサポートを受けながら、オープンマインドなエンジニアが高い生産性を出す方法は興味深く、傾聴に値する。
と同時に、「おっ、ナデラCEOの改革が進んで、こうなったんだ！」という感想も持ったのだ。

MSの以前の文化

（予めお断りしておくと、実際の内部事情について知る立場ではなく、ここに書くのは様々な書籍等で知った事である。）
わたしの知る限り、著者が見聞きする良質なエンジニアカルチャーは、もとから存在していたものではなかったはずだ。

80年代、Windows NT、デスマーチ

闘うプログラマー［新装版］　ビル・ゲイツの野望を担った男達

闘うプログラマー［新装版］　ビル・ゲイツの野望を担った男達

Amazon

  • まさに「死の行進」（そういう章もある）の元祖的な存在。
  • リリースに向けて死に物狂いになって働く様が記録されている。離婚、逃亡、バーンナウト……。
  • ただ、この時点で最近では当たり前になるような様々なプラクティス（デイリービルドやドッグフーディング）が登場している点も興味深い。

90年代、プロジェクトマネジメント

アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)

アート・オブ・プロジェクトマネジメント ―マイクロソフトで培われた実践手法 (THEORY/IN/PRACTICE)

Amazon

  • プロジェクトマネジメントが重視されていた時代という認識（上記書籍の著者はIE1.0-5.0のPMである）
  • ただし、ものすごい優秀な人がたくさん在席していた時代でもある

ゼロ年代、Longhorn（Windows Vista）の開発遅延

  • Windows Vista - Wikipedia
  • 2003年に出荷される予定だった開発が大きく遅延、2006年の出荷となった
  • 市場からは失敗として評価されていたようだ

10年代、「リフレッシュボタンを押す」改革、クラウドサービスへ

Hit Refresh（ヒット リフレッシュ）

Hit Refresh（ヒット リフレッシュ）

Amazon

  • 2014年、サティア・ナデラ氏CEO就任。それ以前のMSはいろいろ課題があったようだ。「派閥の集合体、縦割りの組織」（「Hit Refresh（ヒット リフレッシュ）」より）
  • ちなみに上記書籍はかなり興味深い良書。この本を読むと当時のMSの状況と課題がよくわかる。

かつてのマイクロソフトの文化は柔軟性に欠けた。社員はほかの社員に対し、自分は何でも知っており、そのフロアの中で最も優秀な人間だと絶えず証明しなければならなかった。期日に間に合わせる、数字を達成するといった責任を果たすことが何よりも重視された。会議は型どおりで、すでに会議の前に詳細が余すところなく決まっていた。直属の上司よりも上の上司との会議はできなかった。上層幹部が組織の下のほうにいる社員の活力や創造力を利用したい場合には、その人間の上司を会議に呼ぶだけだった。階級や序列が幅を利かせ、自発性や創造性がおろそかにされていた。
私は、自分が入社した頃のマイクロソフトの文化をもとに、企業文化改革を進めた。

ここから変えていったのだ。おそらく。そして約10年が経過したということになる。

そして「世界一流エンジニアの思考法」の感想

さて上記を踏まえて、「世界一流エンジニアの思考法」で紹介されているMSの仕事を見てみると、基本的にはナデラCEOが掲げていた当時の課題（先ほど引用した箇所）を反転させるような内容になっているように見えるのが興味深い。
本書は一般ビジネス書ということで、エンジニア以外の人が読むことも多いだろう。「凄いけど、自分たちには難しそう」と考えても心配することはない。なぜなら10年前のMSもそうだったのだからだ。

ただし、テクノロジー企業についてはすこし見方は変わる。著者が日本企業で働いていたのは4年以上前かつ、コロナ禍以前である。その時点から日本のエンジニアの働き方も大きく変わった（変わっていない人もいるのかもしれないけれど）。テクノロジー企業に在籍していて、本書で紹介されている働き方に驚きを感じてしまうのではれば、それはちょっと問題だろう。



なおちょっとだけ苦言を呈しておくと、せっかく良い内容が書かれているのだが、著者の自虐的な表現（自らを三流と評する等）と、見聞きした過去の日本的な働き方への過剰なディスりはちょっと鼻についた。一緒に働いている「世界一流のエンジニア」に習って他者の尊重と多様性の受入れをしてもよかったのではないか。もったいないなぁ。

というわけで本書は読了。次は何を読もうか。
現時点で読みたい積読はこちら。冬休みの宿題をそろそろ選びたい。

詳解システム・パフォーマンス 第2版の16章ケーススタディと動画

Professional Engineer Software Architect

要件定義などの調べものをずっとやっていた反動（？）で、ずっと読みたいと思っていた「詳解 システム・パフォーマンス 第2版」を読んでいる。ちなみに第1版も（事情により）かなり読み込んでいる。第2版はいろいろとアップデートされているので楽しみな本ではあるが、今回は刷新された「第16章 ケーススタディ」について面白かったので取り上げておく。自分のメモを兼ねている。

詳解 システム・パフォーマンス 第2版

詳解 システム・パフォーマンス 第2版

Amazon

「詳解システム・パフォーマンス 第2版」の雑な紹介

Linux上で稼働するアプリケーションのパフォーマンス分析と対応について、極めてディープに説明する本である。だいぶお値段が張るので、まずオライリー日本語サイトで目次をチェックしておくことをお勧めする。
www.oreilly.co.jp

16章 ケーススタディ について

いきなり16章のケーススタディを紹介するのには理由があって、著者が先に読むことをお勧めしているのだ。

16章は、ほかの章とは異なり、ストーリーテリングの方法を使ってパフォーマンスエンジニアの仕事を大きな視野で捉えようとしている。あなたがパフォーマンス分析の初心者なら、さまざまなツールを使ったパフォーマンス分析の具体例としてこの部分を最初に読み、ほかの章を読んだあとでもう1度戻ってくるとよい。

そしてこの16章のケーススタディは、著者のBrendan Greggが2019年のイベントで講演した内容がベースとなっているので見てみると面白い（面白かった）。以下の動画の冒頭10分程である。
www.youtube.com

ざっくりいうと、このような内容になっている。

  • 新しいコンテナベースのプラットフォームであるマイクロサービスをテストしたところ、パフォーマンスが3倍になってしまった
  • 予想外だったし、話がうますぎる。本当？
  • というわけでその原因を調査した（結果は動画を見るか、書籍で確認していただきたい）

実際の調査がどの程度大変だったのか、試行錯誤はあったのかはわからないのだけれども、極めてエレガントに分析していると感じる。

おまけ：第1版のケーススタディとの違い

では「詳解 システム・パフォーマンス」ではどうだったのかも簡単に紹介しておく。

  • 「13.1　ケーススタディ：赤いクジラ」
    • 営業から顧客のサーバを見てくれという、フワッとした連絡が来る。
    • 既存のサポートチケットを見ながら仮説を立てて、状況を分析する。開始時点では状況はよくわからないというのがポイントか。
    • 最終的にはRedisの定期的なディスクに対するフラッシュ処理が原因であることを突き止める（ただし、Redisが何なのかを把握していない状態で）

何が問題であるかも明確でない状態から、本書で紹介されるUSEメソッドなどを用いて診断を進め、最終的に問題のアプリケーションに到達するというストーリーが興味深い。

さて、著者のおすすめのとおり16章を読んだので、いまは冒頭から順次この分厚い本を読んでいるところである。読み終わるのは来年かなー

Software Requirements Essentials（2023）をざっと読む

Requirement Developments book

「ソフトウェア要求　第3版」の著者であるKarl Wiegersの新著が出ていたので、ざっと読んでみる記事（あるいは読んだ記録）。

「私はかつて、過去10年間でベストセラーになった要件エンジニアリングの本を10 冊を読んだことがあります。この1冊には、それらの10冊を合わせたものよりも有益な情報が簡潔に記載されています」-- Mike Cohn

ここまで言われたら読むしかない。

Software Requirements Essentials: Core Practices for Successful Business Analysis

Software Requirements Essentials: Core Practices for Successful Business Analysis

Amazon

もくじ

全体的な感想

序文にも書かれているが、本書のポイントは「忙しい人のためのコンパクトな要件定義のアドバイス」となっていることだ。実際、「ソフトウェア要求　第3版」は良い教科書なのだが読み切るのが難しい。それがここまでコンパクトになっているのには驚きを感じる（あとでもう少し分析する）。一方で、ソフトウェア要求について近年大きな進歩がないということも本書を通じて確認できる。実際に真新しい手法が出てくることはなかった。

とはいえ、最新かつコンパクトということで非常に有用な書籍である。誰か翻訳しないんですかね。

ソフトウェア要求　第3版から何が省略されたのか

上記の通り本書の魅力はコンパクトであることなのだけれども、それでは「ソフトウェア要求　第3版」から何が省略されたのかについて、ざっくりと確認しておく。ただしあまり時間をかけていないので正確ではない点に注意。以下の章タイトルはすべて「ソフトウェア要求　第3版」のものである

  • 第2章 顧客の観点から見た要求　はざっくり省略された
    • 「ソフトウェア顧客の要求に関する権利宣言」「～責任宣言」は好きな話だったのでちょっと残念
  • 第4章 ビジネスアナリスト がない
    • 役割やスキル、育成の話が消滅
  • 第18章 要求の再利用 が削除された
  • 第19章 要求開発に続くもの もない
    • 工数見積もり、プロジェクト計画、実装（設計～コーディング）との連携に関する話がなくなった
  • 第3部 特定の種類のプロジェクト向けの要求（第20章～26章）はない
    • アジャイル型プロジェクト、更改、パッケージなど様々なタイプ別のアドバイスは本書では取り上げられていない
    • なお、アジャイル型プロジェクトについてはむしろメインストリームになっているので全編でフォローされている
  • 第29章 要求連鎖のつながり は省略
    • トレーサビリティに関する話がなくなっている
  • 第30章 要求工学のためのツール
    • 文中でツールに関する言及はされているが、深い掘り下げはなくなった。実際現代でスタンダードとなるようなツールは存在しないということじゃないかと思う
  • 第5部 要求工学の実行（第31章～32章）もない
    • 要求プロセスの改善とリスクマネジメントであるが、これもなくなっている

こうやって振返ってみると、よい圧縮がされているという印象。逆に上記が気になるなら「ソフトウェア要求　第3版」またはそれ以降に出版された参考文献などをチェックすればよいのだろう。

20のコアプラクティス

ここからは、本書で紹介されている20のコアプラクティスに関する覚書である。ざっくり何が書かれているかをメモっている。

冒頭にこう書いてあるのがとても良い。

  • プラクティスに関する2つのアドバイス
    • これらすべてのアクティビティをまだ実行しなくても心配する必要はない
    • 一度にすべてをやろうとしないこと

#1: 解決策を検討する前に問題を理解する

解決すべき問題を理解しなければ、プロジェクトが失敗する場合がある。これを回避するために問題分析を漏らすべきではないという話（手法としては、根本原因分析やなぜなぜ分析が紹介されている）。利害関係者が「製品Xまたは機能Yを構築してください」と提案してきても、それが正しいとは限らないということを理解する。

#2: ビジネス目標を定義する

ビジネス目標、またはビジネス要求を定義する話。複雑であればモデル化する必要もある。本章ではフォーマルなものからライトウェイトなものまでさまざまな文書化のテンプレートなども示されている。

なお、ビジネス目標ヒアリングのための質問リストがサポートサイトでダウンロード可能である。

#3: ソリューションの境界を定義する

「何が入っていて、何が入っていないのか」の境界を確立する話。「どのビジネスプロセス、機能、イベントがソリューションの一部になりますか？どれがその外に残るでしょうか？」そしてコンテキストダイアグラムを描く。より抽象度の高いものとしてのエコシステムマップの作製を検討する。ソリューションの境界を定義できれば、ロードマップ等の計画立案にも役に立つ。なるほどー。

ソリューション境界定義のための質問リストもサポートサイトでダウンロード可能である。

#4: 利害関係者を特定し、特徴づける

ステークホルダーと、その代表者の特定、特徴づけは重要だという話。

利害関係者特定のための質問リストもサポートサイトでダウンロード可能である。

#5: 権限を与えられた意思決定者を特定する

意思決定者の特定、もしくは決定方法について。また、単一の意思決定者がいない場合の対応方法（投票など）について。

#6: ユーザーが必要な解決策は何かを理解する

問うべきなのは「システムに何をさせたいか」ではなく「解決策として何が必要か」という話。これをユーザーから直接引き出すのは難しく、相互作業の要求開発によって求めていく必要がある。ユーザーの目標と、その達成につながるインタラクションによって要件は構成される。ユーザーストーリー、もしくはユースケースを使用する。

#7: イベントと応答を特定する

ユースケースは対話型システムには適しているため、分析対象によっては不足がある。これを補完するためにイベントの分析をする。ユーザーとシステムの対話が中心ではないリアルタイムシステムやミドルウェアシステムなどに適応すると良い。イベント応答表を作成することになるが、必要に応じて状態遷移図で補完する必要がある。

この項は、ちょっと歯切れが悪い印象。しかし実際にここで書かれたケースで困ることがあったので覚えておきたい。普通の要件定義で抜けがち。

#8: データの概念と関係を評価する

データ要件を実施する話。かなり細かく、踏み込んだ内容となっている。

  • データオブジェクトの完全な一覧を作成する
  • 概念データモデルを整理する
  • データの理解を洗練するためにCRUD表を作る（CRUDだけでなく、コピー、リスト、使用、移動、変換される方法も調べる、つまりCRUDCLUMT表を作るべきと提言している）
  • プロセスフロー、またはユースケースとの整合性を確認する
  • データ出力要件を確認する
  • データに関するビジネスルール、品質属性、その他の制約について確認する
  • システム内のデータ移動を確認する必要があればDFDを作る
  • データディクショナリを作る

データ要件確認のための質問リストもサポートサイトでダウンロード可能である。

本項については、「ソフトウェア要求　第3版」と対比しても内容が深くなっている印象。特にデータモデルでは抜けてしまうデータ要件という話は重要だし、かなり参考になるという感想だ。

#9: 品質特性を引き出し評価する

非機能要件の話。非機能要件の重要性は高いが、引き出し方法についての良い方法は存在しない。様々な関連書籍などが示されている。

なんとなく、歯切れの悪い章という印象だ。非機能要件ヒアリングのための2000の質問が「The Quest for Software Requirements: Probing Questions to Bring Nonfunctional Requirements into Focus; Proven Techniques to Get the Right Stakeholder Involvement」という本にあるとのことで興味深いが、電子書籍化されてないようだ。残念

#10: 要件と要件セットを分析する

収集した要件の分析に関して。熟練したビジネスアナリストが個々の要求、および要求全体に関して分析を行うことで大きな価値がつけ加えられるとしている。検討すべき事項のチェックリストがサポートサイトからダウンロード可能だが、本書ではそれぞれの観点についてのアドバイスが充実している。

このプラクティスは「ソフトウェア要求　第3版」では軽く触れているだけ（3.3 良い プラクティス： 要求分析）で、大きく発展されているように感じた。結局のところ、ユーザーから引き出した要求は不完全であるため、様々な観点で検討発展させなければ完全な要求セットにならないという話が展開される。

#11: 要件モデルを作成する

要件はテキストだけでなくモデルとして表現すべきという話。様々なモデルの特徴などが紹介される。

要求モデリング言語RMLや要求マッピングマトリックス(RMM)などは知らなかった。深掘りしたい。

#12: プロトタイプを作成して評価する

ユーザーの「何が必要なのかは言えないが、見ればわかる（これをIKIWISIという）」の対策としてのプロトタイプについて。目的にあわせて「インタラクションデザインのプロトタイプ」または「技術設計プロトタイプ」を使って検証を行うことが説明されている。

#13: 要件に優先順位を付ける

要件の優先順位付けに関する意義、及び効果的な質問や分析手法について説明されている。

#14: 要件を一貫した方法で記述する

要件の文章化について。最も重要な目標は効果的なコミュニケーションをすることであって、スタイルや標準、慣例に準拠することではない。なお本項では「要件ステートメント」のスタイルについての注記となっている（つまりモデルの利用などについての言及はない）。

非機能要件の定義について以下の書籍と「Planguage」という表記法が少しだけ紹介されている。ただ細かい内容は示されておらず、ネットで調べてもよくわからないので、読むしかないか……

#15: 要件を構造化した方法で整理する

要件の文書化について。組織が効果的であると考える標準テンプレートをベースに、プロジェクトに最適な文書化を行うという話。

基本的には「ソフトウェア要求　第3版」で示されているものと大きな変化はない。オープンソースの要求管理ツールについての言及があるが、おそらくは以下だろうか。ちょっと見てみたい。

#16: ビジネス ルールを特定して文書化する

ビジネスルール（ビジネスロジック）の扱いについて。

#17: 用語集を作成する

用語集の作成について。

#18: 要件を確認してテストする

要件の検証に関して。それはレビューとテストで構成される。様々なレビューの手法の紹介。要件のテストについてはチェックリストをチェックするといったものではなくて、ソフトウェアテストそのものをこの段階で実施することについて説明される。

要求のテストについては「ソフトウェア要求　第3版」でも語られていた（要求の妥当性検証）が、さらに拡張されている印象を持った。シナリオテストだけではなく、境界値分析などのソフトウェアテスト手法ですら要件段階で実施することを提案している。

#19: 要件のベースラインを確立して管理する

文字通りの要件のベースライン化について。ベースラインの承認忌避など発生しやすい問題への対策など。

#20: 要件への変更を効果的に管理する

こちらも文字通り、要件変更管理について。

おまけ

本書についての著者のインタビュー

X(Twitter)で本書を読んでいる話を書いたら、以下のポッドキャストが面白いというコメントをいただいたので聞いてみた。かなり興味深い。本書を書いた理由なども語られている。

Karl WiegersのYouTubeチャンネル

上記のポッドキャストで紹介されていたのだが、なんとKarl Wiegersが本書の解説ビデオをYouTubeに上げている。まだ全部見ていないけど本書を手に取る前にチェックしても良さそう。
www.youtube.com

ソフトウェア要求　第3版

ソフトウェア要求　第3版

Amazon

システム設計の現実に触れる「SYSTEM DESIGN INTERVIEW」を読んだ

book Professional Engineer

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

さて、今回読んだのは「システム設計の面接試験」である。微妙なタイトル。原著のSYSTEM DESIGN INTERVIEWの方が有名な気がする。

システム設計の面接試験

システム設計の面接試験

Amazon

先に言っておく

Amazonのレビューにも書かれているが、日本語翻訳の品質には課題がある。わたしは許容範囲だった。試し読みを推奨する。気になる場合は原著を購入するか、オリジナルのオンラインコンテンツを購読すれば良いだろう。

システムデザイン・インタビューとは何か

システムデザイン・インタビューとは、ビッグテックを中心にエンジニアの採用試験で課される課題の一種である。抽象的なシステム仕様に関する質疑応答の中で、どのようなソフトウェアを構築するかを答える形式が一般的のようである。その存在を最初に知ったときは「本当にそんなことをやっているのだろうか」と疑問をもったものだが、実際に海外にいる知り合いが遭遇したという話も聞いたので、実際にやっているのだろう。

というわけで本書「システム設計の面接試験」はその面接対策の本である。全てではないが、各章では候補者と面接官のやりとりなども紹介されていて興味深い。たとえばこんな感じである。

候補者：これはモバイルアプリですか、それとも Web アプリですか、それとも両方ですか？
面接官：両方です。
候補者：製品において最も重要な機能は何ですか？
面接官：投稿できること、友だちのニュースフィードが見られることです。
候補者：ニュースフィードの並び順は、逆時系列純ですか、それとも特定の順序ですか？
面接官：シンプルにするため、フィードは逆時系列でソ ー トされていると仮定しましょう。

こういうやりとりをしながら、システム設計について答えていくのだ。難しい！けど、面白そう！

結果として面白い本になっている

というわけで本書はシステムデザイン・インタビュー対策本として

  • 代表的な課題（例えばWebクローラとか、URL短縮サービス、デカいものであればYouTube）に対し
  • 課題の整理
  • おおまかな設計
  • さらなる深掘り
  • 関連する情報リンク

が提示されるという構成となっている。

英語版だが、チャットシステムの章の内容が公開されているので興味があれば見てみると良い。

この構成が本書の面白味になっている、というのが本書の感想である。

  • よく知られている大規模サービスの大まかな設計イメージが理解できる
  • 様々なアーキテクチャの課題、ハマりどころについてわかる
  • おおまかな見積もりの方法を知れる
  • 実際のプロダクトやコードまでは突っ込まないので、各章の読み味は軽い

というわけで自分としてはだいぶ楽しい本であった。

これはエンジニア教育にも活用できるのでは

と思ったら、いろいろとすでに実践されている方がいた。参考にしたい。

ネット上にはアーキテクチャパターンに関する情報が大量に存在するので、時間をかけて検討調査すればそれなりのシステムデザインを考えることはできるだろう。一方で、白紙の状態で行う最初のディスカッションが重要である。瞬発力というか、構想力を鍛えるためには本書で紹介されているレビューのアプローチは有用ではないだろうか。

関連情報

というわけで本書は読了。次は何を読もうか。最近気になっている本はこんな感じ。

2023/11/14 Findyのイベントで要件定義に関して話します

Requirement Developments

先日公開した「実践要件定義入門以前」と「実戦要件定義入門」の記事からお声がけいただき、少し時間を貰って話をすることになった。X（旧：Twitter）がいろいろと壊れているので、ここでも告知しておく。

findy.connpass.com

先の記事で書かなかった（うまく文章化できなかった）ことを紹介する予定。興味があればご参加いただきたい。

「Gitlabを学ぶ」を読んだ

book Professional Engineer

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

さて、今回取り上げるのは有名な「GitLabに学ぶ 世界最先端のリモート組織のつくりかた ドキュメントの活用でオフィスなしでも最大の成果を出すグローバル企業のしくみ」である。フルリモートで有名なGitlab社について惚れ込んだ著者が同社の働き方を日本企業向けに紹介するという本である（監修にGitlabで働いている方も参加している）。

GitLabに学ぶ 世界最先端のリモート組織のつくりかた ドキュメントの活用でオフィスなしでも最大の成果を出すグローバル企業のしくみ

GitLabに学ぶ 世界最先端のリモート組織のつくりかた ドキュメントの活用でオフィスなしでも最大の成果を出すグローバル企業のしくみ

Amazon

なぜこの本を読もうと思ったのか

Gitlabは先進的な働き方をしている企業として有名で、日本では例えばデブサミで2022年に行われた以下の講演なども話題になっている。

codezine.jp


わたしもこの講演はチェックしていて、いろいろ刺激も受けている。
そしてGitlabはこういった働き方等について、オープンに文書を公開している……のだけれども、内容が膨大なのでパラ読はしたが「あとで読む」状態のまま、ほったらかしにしていたのが実情である。

というわけで、読むのが骨なGitlabのHandbookを見どころを中心に紹介してくれる本書は、大変にありがたい。

全体的な感想

本書の著者の千田さんは、現在はLAPRASという会社で人事責任者をされているそうだ。自社でもGitlab Handbookを参考にした改革を推進されているとのこと。実際に同社もGitlabにならってハンドブックを公開している。

本書はそんな著者が自組織にGitlab的な考え方を導入するにあたって調べまくった（だろう）内容が惜しげなく共有されているという意味で、とても良い本となっている。
ただ、残念な点は 技術者視点がほとんど入っていない というところだろう。目次を見てもわかるが、Gitlab Handbookの中のエンジニアリングの章はほとんど紹介されていないのだ。

とはいえ、足りない観点は自分でGitlab Handbookを読めばいいわけで、まずは読むとっかかりとして本書を足がかりにすればいいんだろう。

Single Source of Truth を日本企業で持てるか

Gitlabでは、Handbookを信頼できる唯一の情報源（Single Source of Truth：SSoT）として全ての情報をHandbookにまとめ、あらゆる判断に利用しているそうだ。実際に著者の企業でも試行中のようだし、他にもテック企業では開発部門などで試行している事例はあるようだ（どこかにまとまってませんかね）

とはいえ、こういった試みが成立しそうなのは小規模な企業とか若い企業に限定されるような気もする。
トラディショナルな日本企業であれば一般的に職務規定や就業規則が必ず存在すると思うのだが、これらはGitlab Handbookとは真逆の存在だ。従業員でも頻繁に閲覧せず、クローズドで、ハイコンテキストなものになっている。ここから転換（反転）してオープンで明確なSSoTを基準としたしごとのしかたを実現するのは、だいぶ難しそう。そういう意味では先ほど紹介した事例のように、まずはエンジニアリング組織を中心にトライしていくのが早道かもしれない。

というわけで本書は読了。次は何を読もうか。最近気になっている本はこんな感じ。