勘と経験と読経

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

V字モデルの深淵を覗き見た気分:UTPPPを読む(前編)

読むのがホネな(積みがちな)技術書やビジネス書を取り上げて2週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第50回。常時、けっこうな量の積読があるのだけれども、知り合いと読書期日を約束することによって消化が捗るという仕組み。過去5回分のログはこんな感じ。

さて、今回取り上げるのは「単体テストの考え方/使い方」(原題はUnit Testing Principles, Practices, and Petternsで、略すとUTPPPらしい)である。けっこうなボリュームがあるので4つの部のうち最初の2部すなわち、「第1部 単体(unit)テストとは」「第2部 単体テストとその価値」をまず読んでいる。

昨年末に発売されて話題となり、冬休みの読書に最適などと言われていた本である。
残念ながら年末年始は他の本を読むに忙しかったので、年明けから読み始めている。

なお本書であるが紙版に加えてKindle版もあるが、直販や達人出版会でコピーが可能なPDF版も販売されているようだ。紹介されているコードを実際に動かしてみたい人などは、直販のPDFを買うのが良いかもしれない。

単体テストの考え方/使い方」前半を読んだ感想

本書はタイトルにこそ単体テストという単語が書かれてはいるが、実際には単体テストとして、次のような概念が学べるような内容となっている(後半を読んでいないのでリストは増えるかもしれない)

類書だと抽象的になりがちなアーキテクチャや設計に関するトピックが、範囲は限定的ではあるが実装と単体テストという具体例を用いて説明されるのが、とてもわかりやすいと感じている。良い本だと思う。

本書を手に取った読者の中には、もしかしたら、本書のことを単体テストによるバグの見つけ方やテスト・データの作り方などについて書かれたものだと思っている人がいるかもしれません。しかしながら、本書は、どちらかと言えば、単体テストがどのようにソフトウェアの継続的な開発を助けるのか、そして、どのように技術的負債として開発の妨げとならないようにするのか、ということを意識して書かれたものとなっています。そのため、単体テストについてほとんど経験のない読者からすると、もしかしたら、本書は思っていたのと違う本なのかもしれません。
単体テストの考え方/使い方」、「翻訳者より」から抜粋

本書の前半から学んだ内容の覚え書き

第1部 単体(unit)テストとは

  • 単体テストに関する議論は「単体テストを書くべきか?」から「良い単体テストを書くとはどういう意味なのか?」に移ってきており、混乱を生じている
  • 本書はエンタープライズ・アプリケーションにこそ最大限に活用できる
    • (⇒自分にとっての重要ポイント!)
  • エンタープライズ・アプリケーションとは何か?
    • ビジネス・ロジックが非常に複雑であること
    • プロジェクトの生存期間が長いこと
    • 適切な量のデータしか扱わないこと(ビッグ・データなどは扱わない)
    • パフォーマンスへの要求はあまり高くないこと(膨大な数のユーザがいるわけではない)
  • ソフトウェア・エントロピー
  • 網羅率の計測方法、使い方、課題、開発者が網羅率の特定の値に縛られることは害であるということ
  • 単体テストの定義
    • 「単体(unit)と呼ばれる少量のコードを検証する
    • 実行時間が短い
    • 隔離された状態で実行される
  • 単体テストにおける古典学派とロンドン学派
    • (⇒このトピックは本書のネタ(ジョーク)のようにも感じられるのだけれどもどうなんですかね)
  • SUT(System Under Test)

第2部 単体テストとその価値

  • プログラミングにおいて、コードは資産ではなく、負債であるということ
    • (⇒技術的負債論は多々あれど、コードそのものを負債と言い切っているのは珍しいような印象をもったがどうだろう)
  • 良い単体テストを構成する4本の柱
    • 退行(regression)に対する保護
    • リファクタリングへの耐性
    • 迅速なフィードバック
    • 保守のしやすさ
  • 単体テストにおける偽陽性(false positive)と偽陰性(false negative)
  • ヘキサゴナル・アーキテクチャ単体テスト
  • ヘキサゴナル・アーキテクチャと関数型アーキテクチャの違い
  • 出力値ベース・テストと状態ベース・テスト、コミュニケーション・ベース・テスト
  • プロダクション・コードの分類
    • コードの複雑さ/ドメインにおける重要性 と
    • 協力者オブジェクトの数

というわけで、後半に続く(まだ読んでいないので2週間後くらいに書く)

「デジタルトランスフォーメーション・ジャーニー」でDXできる? #デッドライン読書会

読むのがホネな(積みがちな)技術書やビジネス書を取り上げて2週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第49回。常時、けっこうな量の積読があるのだけれども、知り合いと読書期日を約束することによって消化が捗るという仕組み。過去5回分のログはこんな感じ。

さて、今回取り上げるのは「デジタルトランスフォーメーション・ジャーニー 組織のデジタル化から、分断を乗り越えて組織変革にたどりつくまで」だ。発売から10ヶ月ほど積んでしまった。

23年の正月を使って読んでみた。なかなかに興味深い本である。

書籍「デジタルトランスフォーメーション・ジャーニー」の概観

さて本書については著者の市谷さんによる2022年のデブサミ講演スライドが公開されているので、未読だればさらっと目を通しても良いだろう。

本書をひとことでまとめるとすると「アジャイル開発手法(スクラム)を組織変革に持ち込んで企業をDXする」本ということになるだろうか。

過去のジャーニー本との違い

本書に先立って、タイトルの似ている2冊の本が出版されている。「カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで(白い本)」と「チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで(黒い本)」である。
カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまでチーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで

さて、今回読んだ「デジタルトランスフォーメーション・ジャーニー 組織のデジタル化から、分断を乗り越えて組織変革にたどりつくまで」は上記の白い本、黒い本と大きく異なる点がいくつかある。

大きな点はストーリー仕立てになっていないということだろう。前作までは「ザ・ゴール」などで採用されている小説部分と解説部分が交互に出てくるという形式であったのに対して、本書は一貫して著者の提唱する「デジタルトランスフォーメーション・ジャーニー」の方法論の説明が続くという形式になっているのだ。

これは、スコープとして「組織変革」という大きな主語を掲げているのが理由であると推測する。架空の企業を題材にしても、本書が取り扱いたいカバー範囲を全て扱うストーリーを考えるのが難しすぎるのだ。別の方法としては特定企業の具体的事例を中心にケーススタディとしてまとめる方法があるが、組織変革というテーマを扱うと企業の根本をさらけ出すことにもなりかねないので、これも難しいだろう。

では、ストーリー仕立てではない理論書として見た場合、本書はどうだろうか。

新造語が多い

今後本書のアプローチが成功してデファクトスタンダード化していけば別だろうが、現時点では本書には沢山の新造語が溢れており、そこは個人的にはあまり好みではなかった。テクノロジー業界のエンジニア向けのプレゼンテーションであれば違和感は無いかもしれないが、ビジネス書として読むのはどうだろうか。Amazonの書評などをみても本書は難解という評があるようだが、新造語の理解に時間がかかるというのも一因ではないだろうか。

例えば類書で、以前に読んだ「リーンエンタープライズ ―イノベーションを実現する創発的な組織づくり (THE LEAN SERIES)」は比較的近しいカバー範囲の本だが(おすすめである)、基本的にリーンの手法をスケールさせているにすぎず理解が難しいということはなかった。

もちろん本書では傾聴に値する様々なノウハウ、知見をたくさん読み取ることができる。個人的には新造語に惑わされることなく、そのノウハウに着目して理解していったほうが良いと思った次第である。

あらためて考える「DXとは何か」

本書ではテーマでもあるDXについて様々な言及がされている。

DXとは単にこれまでの業務をデジタル化するという話でも、何らかのツールを導入するだけという話でもなく、この言葉によって「これからの組織のあり方を変える」という風向きを生み出せる絶好の機会なのです。DXへの期待とは、組織変革への機会と言いかえることができます。
デジタルトランスフォーメーション・ジャーニー 組織のデジタル化から、分断を乗り越えて組織変革にたどりつくまで 第1章 DX1周目の終わりに

ここでいうDXは、いわゆる「黒船」だ。
なるほど、確かにDXを黒船として大きな変革を図るというのはひとつの有効な作戦だろう。
ただ、それだけなのか? それでいいのか? という疑問は残る。

結びに別の本を紹介するというのもナンなのだが、改めて「GDX:行政府における理念と実践」ハンドブックという無料のPDFファイルを紹介してきたい。

著書「Next Generation Government」でデジタル・ガバメントの未来を提⽰した編集者・若林恵⽒の責任編集によるハンドブック「GDX:⾏政府における理念と実践」。そもそもDXとは何なのか、DXで実現できる未来はどんなものなのか、利⽤者起点のデジタルサービスを実現するためにするために必要なあれこれを各国事例を交えながら「⽇本へのヒント」を探りました。
行政におけるデジタル・トランスフォーメーションの推進に関する調査研究 | AIS | 一般社団法人 行政情報システム研究所

本書では著者の若林さんが7万時も使ってDXとは何かを取材を通じて論じていくのだが、いっぽうで結論は単純で拍子抜けだ(冒頭に書かれているのでネタバレではない)。

「ユーザー中心ってことですよ」

「DX」って何ですか?と聞くと、取材をしたどの人も判で押したほうにこの答えを返してくる。なかには「ユーザー」のことばの代わりに「人間」や「カスタマー」といったことばを使う人もいるが、主旨としてはまったく変わらない。要は「供給者」の視点からではなく「受益者」の視点からサービスを開発・運用しろということだ。
(中略)
このことを、少なくとも自分は、相当大きな衝撃をもって受け止めた。なぜなら「DX」という文脈で「それはユーザー中心のことだから。以上」と、明確に言い切るような言説に、少なくとも自分は、出会ったことがなかったからだ。
GDX:行政府における理念と実践 なぜDXを説明するのに7万字も必要なのか、より

一方で、「デジタルトランスフォーメーション・ジャーニー 組織のデジタル化から、分断を乗り越えて組織変革にたどりつくまで」ではあまり「ユーザー」の話は出てこない。議論の主語はあくまで「企業」のようである。このあたりに、一つの大きな課題感を感じたのであった。

さて、次にどんな本を読むかは悩ましい。候補は以下。

あたりはどうだろう。

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

2022年7月~12月に読んだ本のまとめ。カウント対象は期間中に読み終わったものに限り、読みかけの本は対象外としている。あとコミック、漫画雑誌類もけっこう読んでいるのだけれども、これは除外。
この6カ月56冊の本を読んだらしい。2022年通年で読んだ本は125冊だったようだ(わりと平常運転)。いつもどおり半期で読んだ本の中で良かったものをピックアップしてみる。

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

今年の話題の書であり抜群に面白かったのは「同志少女よ、敵を撃て」なのだけれども、この半期で心に残ったのは児童書「エーミールと探偵たち (岩波少年文庫 18)」である。
エーミールと探偵たち (岩波少年文庫 18)
どうして本書を手に取ったのかというと、文学者の池澤夏樹さんとその娘である春菜さんの対談集「ぜんぶ本の話」で紹介されていて、そういえば読んだ記憶が無かったからだ。なお「ぜんぶ本の話」は児童書からSF小説まで多数の書籍が紹介されていて極めて危険な本(読むと、読みたい本が増えてしまう)。

というわけで読んだのだが感想は「読まずに死ねない」である。ネタバレになるので何も言わないが、極めてエレガント!

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

最近SF分野は豊作。シリーズものとして「三体X 観想之宙」も「火星へ」も良かった(そしてそれぞれ続刊が出ているので読まねば)。傑作短編集として「新しい世界を生きるための14のSF (ハヤカワ文庫JA)」も最高だったのだけれども、今回はこれをピックアップしておこうと思う。
サーキット・スイッチャー

完全自動運転車が普及した2029年の日本。自動運転アルゴリズム開発会社の社長・坂本は、仕事場の自動運転車内で突如拘束された。襲撃犯はその様子をライブ配信し首都高の封鎖を要求、さもなくば車内に仕掛けた爆弾が爆発すると告げる……迫真のテクノスリラー
サーキット・スイッチャー

SFとしての飛躍は大きくなく、わりとありそうな近未来の話。特にソフトウェアエンジニア界隈の人は楽しく読めると思う。おすすめ。

教養書のおすすめ

抜群に面白かったのは「東京大学「ボーカロイド音楽論」講義 (文春e-book)」。割と内容が哲学していて面白かったし、解説を読みながら楽曲を聴くというのが楽しかった(そういえば、楽曲や歌詞に集中して音楽を聴くという体験を意識的にやったのも久しぶりだった)。
東京大学「ボーカロイド音楽論」講義 (文春e-book)

なお楽曲リストは著者のYoutubeチャンネルにまとまっているので読書とお供に。

ビジネス書のおすすめ

畑村先生の「新 失敗学 正解をつくる技術」をおすすめしておきたい。最初の失敗学の本「失敗学のすすめ (講談社文庫)」から20年目の正統続編ということもあるが、現代における失敗学の大切さが語られていて考えさせられる本になっていると思う。
新 失敗学 正解をつくる技術

私はこうした活動を通じて、日本の産業の近年の長い低迷の根本原因に、私たちの社会が「これが正しいとしてきた考え方」そのものに限界があるのだと考えるようになりました。私たちは、歴史的に培われてきた考え方ーー「正解」がどこかにあり、それに従って真面目にやっていれば大丈夫というという考え方ーーがあるという文化に染まっているのです。しかも自分たちではそのことに気づいていません
新 失敗学 正解をつくる技術

技術書のおすすめ

年末にすべりこみで読んだ「エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法」が抜群によかった。エンジニアリングマネージャという職種定義がない従来型のSIer的企業に勤めている自分にとってもたいへんに参考になる。取り扱っている話題が網羅的で、自分にとっては後進指導の役に立つと感じられる良書である。
エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法

ちなみにこの本は各章のエピグラフイカすのだけれども、出展とかいずれ調べたりして遊びたい。

この半期の振り返り

この半期というか今年全般で言えば、技術書読みが停滞しているという課題感を改めて感じる。自分はスキマ時間で本を読むことが多いのだが技術書がそこにはそぐわないという点と、まとまった時間は大学講義の視聴や資格勉強にあててしまうというのが背景にはあるのだけれども、ちょっとまずい。また、読みたい技術書の積み(罪)も高まっているので、来年はもっと積極的に技術書読みに振っていきたい。

2022年上半期に読んだ本

  1. 無理ゲー社会(小学館新書)
  2. 地球の未来のため僕が決断したこと 気候大災害は防げる
  3. 同志少女よ、敵を撃て
  4. バビロン3 ―終― (講談社タイガ)
  5. 「データと対話」で職場を変える技術 サーベイ・フィードバック入門 これからの組織開発の教科書
  6. ぜんぶ本の話
  7. 国家はなぜ衰退するのか 権力・繁栄・貧困の起源(下)
  8. 働く人改革 イヤイヤが減って、職場が輝く! ほんとうの「働き方改革」 できるビジネスシリーズ
  9. 回復力 失敗からの復活 (講談社現代新書)
  10. 掃除婦のための手引き書 ――ルシア・ベルリン作品集 (講談社文庫)
  11. 図解 組織開発入門 組織づくりの基礎をイチから学びたい人のための「理論と実践」100のツボ
  12. 5000日後の世界 すべてがAIと接続された「ミラーワールド」が訪れる (PHP新書)
  13. ディオゲネス変奏曲 (ハヤカワ・ポケット・ミステリ)
  14. アトミック・ボックス (角川文庫)
  15. 哲学の最新キーワードを読む 「私」と社会をつなぐ知 (講談社現代新書)
  16. なぜ、あなたがリーダーなのか[新版]――本物は「自分らしさ」を武器にする
  17. Google×スタンフォード NO FLOP! 失敗できない人の失敗しない技術
  18. 三体X 観想之宙
  19. 人間の建設(新潮文庫)
  20. だれのための仕事――労働vs余暇を超えて (講談社学術文庫)
  21. 疫神記 上 (竹書房文庫)
  22. 疫神記 下 (竹書房文庫)
  23. コンピュータの構成と設計 MIPS Edition 第6版 上 ⇒ (★書評1★書評2
  24. コンピュータの構成と設計 MIPS Edition 第6版 下 ⇒ (★書評3★書評4
  25. 知ってるつもり 無知の科学 (ハヤカワ文庫NF)
  26. 進化思考――生き残るコンセプトをつくる「変異と適応」 (海士の風)
  27. クソったれ資本主義が倒れたあとの、もう一つの世界
  28. 床下の小人たち―小人の冒険シリーズ〈1〉 (岩波少年文庫)
  29. 東京大学「ボーカロイド音楽論」講義
  30. エーミールと探偵たち (岩波少年文庫 18)
  31. 新しい世界を生きるための14のSF (ハヤカワ文庫JA)
  32. GREAT BOSS(グレートボス) ―シリコンバレー式ずけずけ言う力
  33. 達人が教えるWebパフォーマンスチューニング 〜ISUCONから学ぶ高速化の実践
  34. invert II 覗き窓の死角 城塚翡翠
  35. 新 失敗学 正解をつくる技術
  36. システム開発・刷新のための データモデル大全
  37. 火星へ 上 (ハヤカワ文庫SF)
  38. 火星へ 下 (ハヤカワ文庫SF)
  39. マスターアルゴリズム 世界を再構築する「究極の機械学習」 ⇒ (★書評
  40. 鉄騎兵、跳んだ
  41. ビジネス書ベストセラーを100冊読んで分かった成功の黄金律
  42. サーキット・スイッチャー
  43. 現代美術史-欧米、日本、トランスナショナル (中公新書)
  44. 図書室で暮らしたい (講談社文庫)
  45. 日本沈没 決定版【文春e-Books】
  46. 22世紀の民主主義 選挙はアルゴリズムになり、政治家はネコになる (SB新書)
  47. 歴史とは靴である (講談社文庫)
  48. 旅行鞄にはなびら (文春文庫)
  49. NOISE 上 組織はなぜ判断を誤るのか?
  50. NOISE 下 組織はなぜ判断を誤るのか?
  51. 哲学思考トレーニング (ちくま新書) ⇒ (★書評
  52. 東京藝大で教わる西洋美術の見かた 基礎から身につく「大人の教養」
  53. モダンエルダー 40代以上が「職場の賢者」を目指すこれからの働き方 ⇒ (★書評
  54. 絶望を希望に変える経済学 社会の重大問題をどう解決するか (日本経済新聞出版)
  55. エンジニアリングマネージャーのしごと ―チームが必要とするマネージャーになる方法
  56. 日本語練習帳 (岩波新書)

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

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

エンジニアの中高年危機について考える1:モダンエルダー

中高年になってしまったので、中高年危機について勉強したり考えている。というわけで何回かに分けて調べたことや考えたことをアウトプットしていきたい。明確な構想を立てているわけではないので、先に進むにつれて考え方も変わるかもしれない。今回は「モダンエルダー」を読んだ感想を中心に書いていく。

中高年とは

最初に中高年の定義について明確にしておこうと思う。

法制度の定義をみると、例えば「高年齢者等の雇用の安定に関する法律」では、「中高年齢者」を45歳以上、「高年齢者」を65歳以上とに分けて設定されている。また「21世紀における国民健康づくり運動」の中でも、45歳から64歳までが中高年として提示されている。
本書においても、中高年の開始年齢をめぐっては、概ね40代後半頃からであると想定している。
中高年の心理臨床〔新訂〕 (放送大学教材) 第1章、より)

「中高年の心理臨床」はだいぶ興味深い本なので次回記事で取り扱う予定である(まだ読み終わっていない)

モダンエルダー(新しい年長者)

というわけで今回取り上げるのはこの本。家族や職場の同僚に表紙を見られると恥ずかしくなるやつ
モダンエルダー 40代以上が「職場の賢者」を目指すこれからの働き方

簡単に紹介すると、こんな本である。個人の感想です。

  • 20代で起業し、最終的には世界第2位のブティックホテルチェーンを経営していた著者が52歳で米Airbnbに転職。転職後はAirbnbのCEOのメンターを務めつつ、ホスピタリティー部門の責任者として活躍。その経験を踏まえて「新しい年長者(モダンエルダー)」の在り方を説明するという本
  • 上記の通り著者はエンジニアじゃない。またAirbnbに入社後もエンジニアをしているわけではない(つまりエンジニア的な文脈はまったくない)
  • 一方で、Airbnbは著者を除けば平均年齢の若いスタートアップだ。そのような組織で年長者がどのような価値を発揮していくのか、また何を学んでいけるのかということが紹介されていて興味深い
  • 「新しい年長者(モダンエルダー)」とは「優れた判断力」「本物の洞察」「EQ」「俯瞰的な思考力」「奉仕の心」を持つ年功者(単なる年長者ではない)であり、デジタル世代の若者を支援する人材像のこと

日経ビジネスのサイトでは本書からの抜粋が一部読めるので、雰囲気を知りたい人はあわせてどうぞ。

著者のチップ・コンリーのTED Talksもおすすめ。大枠を短時間で掴める。
www.youtube.com

なお、この後いろいろ書くけれども、良い本である。取り上げていない箇所でもいろいろ考えさせられる事が多かった。中高年におすすめ。

モダンエルダーは脱・老害の道?

老害というと、高い職位や権力を笠に古い知識をひけらかすというイメージがあるだろう。モダンエルダーはそういう意味では「脱・老害」の道と考えることができる。
本書の著者はメンターンという造語を用いてモダンエルダーの姿勢をこう説明している。

  • チームに対してはインターンとして振舞う(メンバーから素直にデジタル知識を吸収する)
  • メンバーに対してはメンターとして振舞う(自分の持っている知恵をもって、メンバーの課題解決を支援する)

これは「脱・老害」していると言えるのではないだろうか。本書では良きメンターンになるためのアドバイスがたくさん掲載されていて(中高年としては)刺激になる。もちろん自己変革と強い学習マインドセットを要するが、老害になってしまうよりは良いだろう。個人的にもがんばりたい。

モダンエルダーはマネジメントトラックへの道か?

この本を読んでチラつくのはエンジニア「引退」「ジョブチェンジ」だ。モダンエルダーになるのは現場から離れてエンジニアとしてではなく、マネージャーとして働いていく道の選択になってしまうのだろうか。
著者のチップ・コンリーがそもそもエンジニアではないし、エンジニアにもなろうとしていないのだがら、そういう印象を持ってしまうのは仕方がないだろう。しかし、本書をある種の「マネジメントトラックへの道」と捉えて避けてしまうのであれば、それはちょっともったいないような気がしている。

  • どちらにしろ、人は老いる
  • 同世代だけで働くことは難しい。他世代と働く方法について考えないわけにはいかない。中高年は年下の人間と働くことをもっとうまくならなければいけない
    • 著者は本書で、現代は『人間の歴史上はじめて、5世代が同じ職場で一緒に働いている』時代だと書いているし、確かにそうだ
  • 世代間を越えたある種の良いコミュニケーションの方法をモダンエルダーは示している
  • 特に本書では次のようなテーマも扱われているので参考になる
    • 自分より若い権限者(いわゆる年上上司)と、どうやってコミュニケーションしていくか(実例から戦略まで)
    • 自分より若く、自分よりもスキルも高い世代(本書ではDQ:デジタル知性と表現されている)とのコミュニケーション方法

マネジメントトラックを走らない人にも学びが多いのではないだろうか。

中高年の目覚め

自分の一つの興味はエンジニアにとっての中高年危機である。じつは本書でもダイレクトに中高年危機について触れられている箇所がある。

人生の半ばに「中年の危機」が訪れると言う人は多い。だがそれはむしろ「中年の目覚め」だと私は思っている。
人生は楽しいし、これからますます楽しくなっていくはずだ。
モダンエルダー 40代以上が「職場の賢者」を目指すこれからの働き方 第1章、より)

あー、そうなりたいんですよね。幼年期の終わり的な感じで。

次回につづく。

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

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

ふりかえり

  • 今年はけっこう積極的に行けた。子供が中学生になったというのが大きいかもしれない。子供を連れていけないアナーキーな美術展にも行けるようになった
  • リヒターをたくさんみた(ポーラ美術館、東京国立近代美術館国立西洋美術館)。集中的に見ると重層的に興味が出てきて面白い
  • 実は行ったことのなかったポーラ美術館に行くようになった(夏は家族で行ったが、春と秋はバイクで行ったので倍楽しい)
  • 地方の美術館にはあまり行けなかった。これはご時世的にもまだ難しい

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

2022年1月

2022年2月

2022年3月

2022年5月

2022年7月

2022年8月

2022年10月

2022年11月

2022年12月

美術館・博物館を楽しむための参考図書

  • 超有名な美術史の本。内容が面白いのと、大量の図版があるので現代美術以外の美術展に行くときには予習としてちょうどいい。
  • 自分が持っているのはファイドン版のポータブルなものだが、絶版になってしまった。書店にはまだあるかもしれない。定価2100円とお値段もリーズナブル。ネットだとプレミア価格になっているが、だったら河出書房のほうを買ったほうがいい。
  • 世界一売れている美術の本『美術の物語』 | 本の「今」がわかる 紀伊國屋書店

  • この本に限らず、東京国立科学博物館の先生たちは最近出版に力を入れている。本書は今年開催された「化石ハンター展」の舞台裏の紹介でもある。知的好奇心を刺激されまくる良い本。


来年もいろいろ行きたい。地方の美術館どうするかなぁ~

要件定義を専門でやる技術者(Requirement Engineer)に関する雑感

タイムラインに流れていた『もう発注側企業に要件定義能力はないので、要件定義を専門でやる技術者(Requirement Engineer)が世界でも日本でも出てきている』という話に関する極めて個人的な雑感。あるいは記憶のダンプ。

b.hatena.ne.jp

要件定義を専門でやる技術者(Requirement Engineer)の話はいつか来た道

要件定義を専門でやる技術者という話は新しい話ではなく、ゼロ年代後半から議論がされていたものである。
ゼロ年代後半というと、SIerを中心にわりと適切なプロジェクトマネジメント方法論が普及しはじめて、「要求された通りのシステムは開発できるようになってきた」という時代だ。
一方で「システムは開発できるが、要件定義がゴミだと、完成するシステムもゴミ」という問題が残っていて、要件定義の高度化や専門家育成の議論があったのだ。

私もコミュニティの運営に関わっていた「要求開発アライアンス」でもそういった議論は繰り返されてきた(同コミュニティはその出自から、UMLを活用したビジネスモデリングを中心とした議論をしていた)
また別個の動きとして、JISAで要求工学知識体系(REBOK)の整備というのも進んでいて、日本発の取組みとして活発だったころがあったのだ。

要求工学知識体系(REBOK)では 要求アナリスト(Requirements Analyst)という役割を定義していて、要求工学に精通した人材が要件定義に参画すると良いとしていた。ちなみに要求アナリストに求められる能力は以下と定義されていた。

  • 要求工学知識
    • 要求工学の知識
    • 対象とするビジネスや製品に関する知識
    • ソフトウェア開発全般に関する知識
    • プロジェクト管理全般に関する知識
  • 要求工学スキル
    • コミュニケーションスキル、ファシリテーションスキル、交渉スキル、観察スキル、文書作成スキル、分析スキル、組織化スキル、モデル化のスキル、対人スキル、創造性

また欧米ではビジネスアナリシス知識体系(BABOK)の整備も進み、こっちはビジネスアナリスト(BA)という役割が定義されて、PMPのような資格化もされていったという歴史がある。

ふむ、それからどうなったの?

人によって見え方は変わってくると思うが、私の感覚でいうと「流行らなかった」と思う。
振返ってみると以下のような構造があった(個人の感想です)

  • ユーザー企業の観点では、恒常的に要件定義を行うわけではないので「テクニック」には興味があったが、専門家を育成するマインドはなかった
  • SIer的企業の立場で言えば、「要件定義は本業ではない」というマインドがあったと思う。よってやはり専門家を育成するマインドは低かった(大企業だったら話は別かもしれないが、身近なところでは観測できなかった)
  • 要件定義を専門とする小さめの会社はいくつもあったが、規模を大きくしたり、類似の会社が増えるということもなかった

また、その後はアジャイル開発ブームが到来してくるので、開発技術におけるアーリーアダプター的人材はほとんどがアジャイル開発方面に移行していったような印象がある(個人の感想です)

というわけで要求工学の専門家という発想は、当時はあまり広がらなかったのだ

いま、改めて要件定義を専門でやる技術者(Requirement Engineer)について考える

すべて私見である。要求エンジニアのような職種のニーズは高そうだけど、やっぱり流行らなそう

要求エンジニアがいても、要件定義の本質的な難しさは変わらない

特に古いシステムを更改したり統合するというソフトウェア開発のプロジェクトにおいて、要求エンジニアができることは「要求の発掘」である(考古学、文化人類学、そしてリバースエンジニアリング能力が必要)。
そして「要求の発掘」により大量の要求っぽいものが発見されたとして、これを全て精査・厳選しして最終的な要件に変換することは、要求エンジニアには出来ない。これはシステムの使用者(ユーザー)がやらざるをえない。
そういう意味では、要求エンジニアを調達したとしても、ラクになるのは一種の前処理だけである(それでも十分に良いことなのだけれど)。

特に巨大なシステムの要件を定義するための意思決定の労力は、要求エンジニアがいても軽減されない。ここに一つの難しさがあるだろう。

要件定義工程だけの切り出しは難しい

要件定義の本質的な難しさを受け入れたとしても、次に問題となるのは要件定義工程の切り出し方である。話をシンプルにするために、ウォーターフォール型のソフトウェア開発プロジェクトを前提にする。要求エンジニアの支援をうけて要件定義を行うとすると、以下のような問題に直面することになるだろう。

  • 要件定義のアウトプットを、要件定義が完了した段階で評価できない
    • 要件定義書などを単体で評価することが難しい。ソフトウェアが完成に近づいてはじめて、適切な要件定義ができていたかがわかるのだ。ということは、要件定義が終わった段階で要求エンジニアを含むチームは解散、というわけにはいかない。これはリソースやコスト面でかなり厳しそうだ
  • ソフトウェア構築者と要求エンジニアを役割分離すると、要求が最適化できずに結果として作業が増加するという問題がある
    • ソフトウェアを実装する観点からすると、非効率となったりボトルネックになる要求(作り手から見てコスパが悪い要求、その1点を取り下げることで劇的に効率が上がる要求)というものは存在する。そういった要求を調整することでプロジェクトのリスクがコントロールできるのだが、ソフトウェア構築者と要求エンジニアが分離しているとうまく連携できないことがある。要求エンジニアはユーザーが要求しているのだから、効率などは無視して要求を定義するし、構築者は効率が悪いと思っても、すでに定義された要求は充足せざるをえないというマインドになってしまう

要求エンジニアの育成も難しい

エンジニアリングだけではなく幅広い知識が必要とされるので、単純に難しい。さらに加えて修行が難しいという問題もあるだろう。要求エンジニアが必要とされるようなプロジェクトは期間も長くなるので、短期的に大量の経験を積んで成長するといったことが難しいのである

じゃあ、どうすればいいの?

私も知りたい。銀の弾丸はない。

ただ最近考えるのは、

  • ビッグバン的な大規模な要件定義をなんとかして避ける
  • 運用フェーズで手を抜かず、保守性(特に移植性)を向上させる取り組みをして、次の更改のリスクを軽減する

あたりはポイントになるような気がしている。

頭を良くしたいので「哲学思考トレーニング」を読んだ #デッドライン読書会

読むのがホネな(積みがちな)技術書やビジネス書を取り上げて2週間の読書期限を課して読んでアウトプットする仮想読書会「デッドライン読書会」の第48回。常時、けっこうな量の積読があるのだけれども、知り合いと読書期日を約束することによって消化が捗るという仕組み。過去5回分のログはこんな感じ。

今回取り上げるのは「哲学思考トレーニング (ちくま新書)」である。

本書を手に取ったきっかけは以下のブログ記事を1年前に見たからだ。
note.com

分析哲学者による知的主張の作法シリーズ、その2です。日本における分析哲学の権威のひとりによる、哲学を通したクリティカル・シンキング入門(あるいはその逆)です。何を疑い、何を確かなものとして信じるか、価値についての答えの出ない問いにどうやってより確かな解を出すか、といった手法が、極めて洗練された濃縮度の高いやり方で展開されます。よりよく考えるために、これはぜひ読んで欲しい本。
CTOが選ぶ、エンジニアのみなさんに個人的に読んでほしい本|藤村|note

紹介されている通り、新書で267ページというサイズにもかかわらず、極めて濃厚な本であった。

クリティカルシンキングとは

本書が紹介している哲学思考は「哲学的クリティカルシンキング」と呼ばれているものである。

  • 直訳でもあるが、批評的思考ということになる
  • 批評:ある意見を鵜呑みにせずよく吟味すること
  • 本書で扱う哲学的クリティカルシンキングでは、「ほどよい懐疑主義」を目標とした思考法を組み立てることを目標にしている

類似のもので、とくに社会人になると企業研修で学ぶ機会の多い「ロジカルシンキング(論理的思考)」がある。本書の中で触れられているわけではないため自分の考えではあるが、ロジカルシンキングが思考の論理的な正しさを築くベースであるなら、クリティカルシンキングは思考の精度を向上させるような役割と考えることができるだろう。

「哲学思考トレーニング」の感想

というわけで本書はエッセイ形式で事例を交えながら「哲学的クリティカルシンキング」を説明していくのだが、より理解を深める仕掛けもあって、とても良い本だった。

まずは冒頭から最後まで読み進めることによって、「哲学的クリティカルシンキング」の概念や思考のツールなどについて把握することができるようになっている。
そして最後に改めて「哲学的クリティカルシンキング」の流れと思考ツールを俯瞰して、本書を読み直すガイド章が付随しているのである。全体像を把握した上で、このガイドに従ってもう一度読み直すことによって理解が深まるというのは、なかなかよかった。

本書を読む事によって、いままで無自覚的に行ってきた議論や判断の一部は、極めて感覚的で精度が低かったことかわかった。本書で紹介される手法を用いて、自分の一次判断を疑い、洗練することができるようになる気がする。

なによりコンパクトで薄い本なので、自分に合わなくてもダメージは少ないだろう。いったん手に取ってみることをお勧めする。

本書では、さらなるトレーニングのための書籍もいろいろと紹介されている。私はこの本にチャレンジしてみたい(まずは書店か図書館で試し読みしてから)