勘と経験と読経

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

「ソフトウェアアーキテクチャの基礎」を読む 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年だった。もちろん本ブログで紹介しているとおりに大量に書籍は購入しているんだけど、これはいつものことだからなぁ……
老眼に苦しんでいるならご検討いただければ幸いである。

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

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

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

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

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

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

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

MSの以前の文化

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

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

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

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

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

ゼロ年代LonghornWindows Vista)の開発遅延

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

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

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

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

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

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

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

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



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

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

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

「詳解システム・パフォーマンス 第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)をざっと読む

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

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

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

全体的な感想

序文にも書かれているが、本書のポイントは「忙しい人のためのコンパクトな要件定義のアドバイス」となっていることだ。実際、「ソフトウェア要求 第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