2022-07-26

文化心理学、思考様式とソフトウェア設計について考える

以前に読んだ「教育心理学特論 (放送大学大学院教材)」が面白かったので、改めて心理学について学んでいる。あらためて基礎からというつもりで導入科目の「心理学概論 (放送大学教材)」の授業を受けているのだけれども、講義中「文化心理学」の紹介で紹介されていた思考様式の話が興味深かったので、調べたり考えたことについて記す。

以前に読んだ教育心理学特論に関する記事はこちら
- 教育心理学はソフトウェア開発に活用できるか（教育心理学特論を読み終えて） - 勘と経験と読経

文化心理学とは

文化心理学 - Wikipedia

欧米を中心に発展した心理学は実際には研究対象の母集団が欧米の白人男性に集中しているという問題がある。これを問題と考えて提唱された文化心理学は、心理学の文化的側面（欧米とアジア圏などの文化差）に着目した心理学の研究分野である、というのがざっくりとした自分の理解である。

文化と視点、注意配分

「心理学概論 (放送大学教材)」の授業で紹介されている文化と視点に関する研究成果が興味深かった。
おそらくこの論文が中心となっているもの。

Inaugural Articles: Culture and point of view - PMC

欧米文化圏と東アジア文化圏の視点には明確な違いがあるということを、実験で確認していて興味深い。実験結果は省くとして、以下のような差異があるようだ。

欧米文化圏
- 世界観と認識法
  - 分析的世界観
  - 物事はそれ自体で定義される。だから世界を理解するためには、一つ一つの現象に内在する安定した性質を見極める必要がある
東アジア文化圏
- 世界観と認識法
  - 包括的世界観
  - 物事は常に変化し他の現象と複雑に結びついている。だから世界を理解するためには、そうした複雑な現象すべてに目を向ける必要がある

東アジア文化圏の考え方はコンテクスト思考
欧米文化圏の考え方はオブジェクト思考

おや、急に（ITエンジニアにとっては）なじみ深い話になってきたぞ……

自らの経験等から：ソフトウェア設計における欧米と日本の違い

この話を聞きながら思い出したのは、以前にビジネスモデリングの勉強会で聞いた次のような話である

日本人が（ビジネス）クラス図やダイアグラムを書く時には、全体像と配置にものすごくこだわりがち
欧米人はダイアグラムの全体像や配置にはかなり無頓着（読めればよい）

最近だとソフトウェア設計におけるダイアグラムを作成するツールとして、PlantUML とか mermaid など簡易なテキストで記述する方法がメジャーになりつつあるが、これらのツールのひっかかるところはオブジェクトの配置が自動的という点である。便利ということはわかるのだけれども、全体的な配置が気になってしまうのも、東アジア圏的発想なのかもしれない。

またヨーロッパ系のエンジニアと仕事をしたことも少しあるのだけれども、やっぱりダイアグラムは読めればいいや、という扱いだったような気がする。

当時はそんなものかと思っていたけれども、文化心理学の話を聞いた後で考えるともうちょっと根深いものだということがわかって興味深い。

日本文化とソフトウェア設計の関係性に関する研究もあるようだ

少し調べてみると、同志社大学の金田先生という方が言語論的アプローチで類似の研究を実施していて興味深い。

ただこれらの研究のベースは言語学的アプローチであり、文化心理学とは切り口は異なるようだ。

言語的相対論 - Wikipedia

いろいろ考えたこと

ソフトウェアエンジニアの多くは、欧米文化圏の分析的世界観で形作られたツール（言語）や手法などを学び活用している事が多い。そうであれば文化心理学が提示する特性差の存在は認識しておいたほうがよさそう
一方で学習と経験を通じてエンジニアは欧米文化圏の分析的世界観に染まっていくということもあるだろう
- 上流工程で見られる、非エンジニアとエンジニアのコンフリクトの一部は、分析的世界観（エンジニア）vs 包括的世界観（非エンジニア、ユーザー等）の対立という側面もあるのではないか
ソフトウェア設計では、いかにして既存の包括的世界観から分析的世界観に（非エンジニア、ユーザー等を）移行させるかということも考えるべきという気がしてきた
- 現在主流になりつつある様々なプラクティス（アジャイル開発に由来するものや、ドメイン駆動設計に由来するもの等）が意図せずこの壁を越えている可能性も感じる

金田先生の論文の結びで書いてあった以下の文章が興味深い。

本稿の基本的な問題意識は，欧米で開発されたモデリングツールが，母語（英語）が持っている認知言語的構造を反映している点である．結果として，洋と和の文化の中でアイデンティティを失っている日本外交の世界が，そのまま，情報システム屋の姿かも知れない．
では，どうしたら良いのだろうか．難問である．ただ，いくら母語の違いがあるからといって，欧米のテキストを否定してみても仕方がない．ただ，欧米のテキストには，母語に伴う「説明されていない部分」があるはずである．その事を無視して，「習うより慣れろ」的な，徒弟的教育方法だけで，モデリングを理解させることはできるのだろうか．我々は，「SE の育成は徒弟的関係」と思い過ぎていたのではないだろうか．

日本文化に基づくソフトウェア工学の理解 ―オブジェクト指向とGTAを例として―

文化心理学をもうちょっと学びたい

以下の本が詳しいらしい（教科書に参考図書として掲載されている）

あと一般書ではあるがこの本も関係しているようだ

うーん、ネットは広大だわ

2022-07-17

パタヘネを読む２（第３章〜第４章） #デッドライン読書会

book Professional Engineer

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

さて、前回に引続き。通称パタヘネすなわち「コンピュータの構成と設計　MIPS Edition　第6版　上」を読んでいく。1スプリントで2章ずつ読んでいく計画で、今回は2スプリント目である。

パタヘネ第３章〜第４章を読んだ感想

うすうす気づいていたけれども、コンピュータは計算機械であることを改めて認識する章だった。難しい。
4章を読みながらまず思い出していたのは、SF小説「三体」に出てくる人列コンピュータである。仮想現実世界で複雑な計算を実施するために秦の始皇帝から三千万人の兵士を借り、それぞれに手旗を持たせて 1 辺 6 キロメートルの正方形に並べ、巨大な人列コンピュータを作るという箇所があるのである（読んでいない人にはまったく意味がわからないと思うけど）。この部分を切り出した短編「円　劉慈欣短篇集」も出ている。
そういえばと思って調べてみたら、マインクラフトでCPU作っている人はぞろぞろいた。
- マイクラで4bitCPU
- マインクラフトで1HzのCPUを作り上げた猛者が登場、テトリスや関数のグラフ化も可能 - GIGAZINE 　壮大すぎて笑った
こんな本もあった（未読）「CPUの創りかた」
そういえばこれをやりたいと思っていたことを思い出した：NANDゲートを使って自力でイチから回路を組み立てる「NandGame」レビュー - GIGAZINE
と、本を読むのがちょっとツラかったので現実逃避することも多かったですが、ちゃんと目を通しはしました
そういえばSpectreやMeltdownの話を期待していたけど、あまり出てこなかったな（投機的実行の話は少しでていた）
前回同様、各章の末尾の演習問題はスキップ。

次回

次の2週間は、第５章〜第６章を読む予定。

5.容量と速度の両立：記憶階層の利用
- メモリの話ですね。目次を見る限り仮想マシンとか仮想記憶の話も出てくるので面白そう
6.クライアントからクラウドまでの並列プロセッサ
- いちばん楽しみにしている章である。Google TPUも対象になっている。

2022-07-02

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

book

2022年1月～6月に読んだ本のまとめ。カウント対象は期間中に読み終わったものに限り、読みかけの本は対象外としている。あとコミック、漫画雑誌類もけっこう読んでいるのだけれども、これは除外。
この6カ月は69冊の本を読んだらしい（例年より2割増し程度）。自分はストレスが強いと本をたくさん読む傾向があるので、ストレスが高かったのかもしれない。読んだ本の中で良かったものをピックアップしてみる。

文芸書のおすすめ（一般編）

ふりかえってみると、一般ジャンル（つまりSF以外）の小説作品はあまり読んでいなかった。一方でノンフィックション作品はいろいろ読んでいて、その中でも「極夜行 (文春文庫)」が素晴らしかったと思う。心が動かされた。2018年の大佛次郎賞受賞作で、当時から気になったので「いつか読む」リストに放り込んでいたけど4年もたってしまった。登山家で作家の著者が「完全に人間界から隔絶された真っ暗闇の極夜」を目指すという狂気すら感じる作品である。メイド・イン・アビス的というか、もう、すごい。

あとこれは画集というかイラスト集なのだけれども、今日マチ子さんのStayhomeシリーズは気に入っていて何度も見返している。

すでに忘れつつある初期の頃のコロナ禍、そしてあまり記憶にないオリンピックなどの非日常な日々を思い出しつつ、この時代の特殊感をうまく封じ込めている作品集になっている。作品は基本的にInstagramで全て見れるのだけれども、書籍という形で眺めるほうが好き。

文芸書のおすすめ（趣味のSF編）

たくさん読んでた。ソフトウェアエンジニアのファンが多いニール・スティーヴンスンの「7人のイヴ」もやっと読んだし、大長編SFシリーズ「天冥の標」も最終巻まで読み切った。昨年のSF大賞受賞作「博物館惑星」シリーズも読んで、あと最近話題の「プロジェクト・ヘイル・メアリー」も読んだ。以前から気になっていたカズオ・イシグロの「わたしを離さないで (ハヤカワepi文庫)」も読んだ。うーん、なにがおすすめだろうか（全部おすすめではある）。まあ、やっぱりこれか。

何を書いてもネタバレになるので中身については何も言えないのだけれども、中学2年生の娘にも読ませたら大変感動していた。そして理数系の勉強の重要性を再認識していた。作戦大成功である。

教養書のおすすめ

鉄板のマイケル・ルイス「最悪の予感　パンデミックとの戦い」はもちろん面白かったが、実はまだ上巻した読んでいない「国家はなぜ衰退するのか　権力・繁栄・貧困の起源（上）」がめっぽう面白かった。ずいぶん前にセールの時に電子積読していたのだけれども、こんなに面白いのであれば早く読むのだったと後悔した。非常に有名かつ面白い「銃・病原菌・鉄」に通じる面白さがある。

はやく下巻を読まなければ。

ビジネス書のおすすめ

この上半期は仕事上でいろいろな課題があって、そのため読んだビジネス書がけっこう多い。困ったらとりあえず図書館に言ったり本を買って読むタイプだ。
あえて1冊選ぶとしたら、有用性という観点では「ＮＶＣ　人と人との関係にいのちを吹き込む法　新版 (日本経済新聞出版)」が良かった。

マイクロソフトCEO、ナデラ氏絶賛。
世界60カ国以上、100万人超の人たちに読まれている「話し方」の教科書。

NVCさわりだけは知っていたような気がするが、改めて考え方を学ぶと得るものが多かった。本書を読んだ後、すこしは話し方を変えたし、衝突を減らすことができたような気がする。

関連してこちらも読んだらよかった。1on1入門は所属組織で勧められて読んだもの、フィードバック入門は1on1入門で紹介されているものだ。

この2冊については別の記事を書いているので興味があればどうぞ。

フィードバックと1on1について考える 2022 - 勘と経験と読経

技術書のおすすめ

そういえばこの半年、アジャイル開発手法に関する本を読んでいない！　まあ興味が離れているってことかもしれない。
いくつか読んだ中で、抽象度は高いが「チームトポロジー　価値あるソフトウェアをすばやく届ける適応型組織設計」の有用度が高かったと思う。

本書についての感想は別の記事を書いている。

この半期の振り返り

全般的には、本を読みすぎである。冊数が増えてしまう理由は

強いストレスで、酒に溺れるかわりに本に溺れている
図書館の予約図書の回転が早かった（常時予約枠マックスで予約をしているのだが、待ち行列により自分の借りる順番になるのはランダムである）。

というあたり。下半期は少し読書ペースは押さえて、別の事（旅行に行ったり、映画を見たり）をやろう。

なお、6月末にO’Reilly Learning platformのアクセス権が無くなった。
agnozingdays.hatenablog.com
技術書についてはサブスクで読んでいたものも多かったが、これが出来なくなるので技術書の読み方もまた変わってくるような気がする。

2022年上半期に読んだ本

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

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

2022-06-26

パタヘネを読む（第１章〜第２章） #デッドライン読書会

book Professional Engineer

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

さて、今回からは新シリーズである。通称パタヘネすなわち「コンピュータの構成と設計　MIPS Edition　第6版　上」を読んでいく。いまのところ1スプリントで2章ずつ読んでいく計画だ。

ヘネパタとパタヘネ

ところで本書「コンピュータの構成と設計　MIPS Edition　第6版　上」は通称パタヘネと呼ばれているわけだが、ヘネパタと呼ばれている別の本が存在する。「コンピュータアーキテクチャ[第6版]定量的アプローチ」である。

上記は最新の第６版だが、私が読んだのは第５版だ。どうでもいいけど第６版で翻訳版の出版社が変わっており、Kindle版がなくなった（第６版はPDFは買えるようである）。権利の関係かもしれないが、驚くべきことに第５版のKindle版も販売を中止しているようだ。これはどうなんだ・・・

歴史的には、「コンピューター・アーキテクチャ」（通称ヘネパタ）の後に「コンピュータの構成と設計」（通称パタヘネ）が刊行された。
「コンピュータの構成と設計」（通称パタヘネ）が刊行された後に、「コンピューター・アーキテクチャ」（通称ヘネパタ）は改定されて役割分担が見直され、重複が減るようにされている。
著者は区別がつくように「ヘネパタ」「パタヘネ」にしている（まえがきでそういう話が書かれていて笑った）。
現在の「コンピューター・アーキテクチャ」（通称ヘネパタ）は「コンピュータの構成と設計」（通称パタヘネ）を読んでいることを前提としているが、そうではない読者のための付録がついている（お世話になった）。
「コンピュータの構成と設計」（通称パタヘネ）はタイトルの通りプロセッサを中心とした内容を扱っている。『並列コンピュータ上でプログラムを効率よく実行することをプログラマが望むのであるならば、少なくとも向こう10年間、ほとんどのプログラマはハードウェアとソフトウェアのインターフェースを理解しなければならないだろう』（パタヘネのまえがきより）
「コンピューター・アーキテクチャ」（通称ヘネパタ）は副題の方が大事で「定量的アプローチ」すなわち性能をどう評価するか、という点が主題である。ただし性能を評価するためにはコンピュータ・アーキテクチャを理解せなばならぬ、ということで切り込んでいく本だったはず。私が読んだ第５版ではマルチコアチップやクラウドコンピューティングにも言及されていて大変面白かった印象がある。
その他の参考
- Hennessy&Patterson Computer Architecture 6th Ed. 翻訳のページ | Amano, Kondo Lab

パタヘネ第１章〜第２章まで読んだ感想

まあ知ってたけど、難しい。大学の教科書という趣。
各章の末尾に演習問題が大量についているのだけれども、それを丁寧にやるほどの時間は取らなかった。
少し記憶があいまいなのだけれども、ヘネパタはダウンロード版の付録までは翻訳されていなかったように思う。一方でパタヘネはダウンロード版の付録もしっかりと翻訳されたものが提供されていて、非常に助かる。いっぽうで電子書籍なのだから付録も統合して提供してくれたらよかったのに、とは思う。
本書を読み解く参考資料
- youtu.be
- 書籍「30日でできる! OS自作入門」
- 書籍「詳解システム・パフォーマンス」

各章の感想

1.コンピュータの抽象化とテクノロジ

抽象度が高くて面白く読める章。

「ポストPC時代へのいざない」として、パーソナル・モバイル・デバイス（PMD）すなわちスマートフォンやタブレット、あとウエアハウス・スケール・コンピュータ（WSC）すなわちクラウドなどについても言及されている点は興味深い。
コンピュータの構造の例示も、Apple iPhone Xs Maxが対象となっている。分解して構成要素を示すだけでなく、論理基盤、A12チップの集積回路の構成と深掘りしていくところはワクワクした。
プロセッサおよびメモリを製造する技術、うっすら理解していたけど一連のプロセスをちゃんと把握したのは初めて。改めて人類すごい。

2.命令：コンピュータの言葉

いきなり難しい、というか読み進めるのに時間がかかる章。以前に読んだ「30日でできる! OS自作入門」に助けられた。

コードからマシン語、そしてそのマシン語の実行まで、という話。
最終的には、C言語およびJavaのコードから実行までがフォローされている。
いっぱいMIPSのアセンブリ言語を読むことになる。ここを理解するのに時間がかかる。アナログ人類の限界を感じる。
- MIPSアーキテクチャ - Wikipedia

次回

次の2週間は、第３章〜第４章を読む予定。

3.コンピュータにおける算術演算
- 嫌な予感はある。たぶんビットをたくさん見ることになりそう
4.プロセッサ
- ここは抽象度が高そう。楽しく読めるといいなぁ

2022-05-30

「セキュア・バイ・デザイン」を読んだ（3） #デッドライン読書会

book Professional Engineer

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

さて、今回は3回にわたって読んできた「セキュア・バイ・デザイン」の最終回である。

今回は「第3部: 応用編　第12章: レガシー・コードへの適用」から最後まで、いわゆる総集編とまとめである。いやはや、この本は難しかった！

全体を通じての感想

第3部を読んでやっと(?)、著者の主張する「セキュア・バイ・デザイン」の意味を理解できたような気がする。というか（DDDの概念をある程度知っているのであれば）後ろから読んだ方がよかったかもしれない。
先頭から読んでいくと本書はドメイン駆動設計を推奨する本のように見えるが、実際は逆で、現代的なセキュリティ的品質をソフトウェアの設計に練りこんでいくならDDD的なアプローチをすべきという話だったということだ。やっと腹落ちした感。
そして、本書が提唱する「セキュア・バイ・デザイン」は、最近バズワード的に使われている「セキュリティ・バイ・デザイン」や「DevSecOps」とも（私の理解としては）まったく異なることがわかる。
- （私の理解では）「セキュリティ・バイ・デザイン」や「DevSecOps」は上流工程や運用において恒常的にセキュリティを意識することであるが、あくまで外付け／外部から強化するアプローチだと考えている。
- 一方で本書「セキュア・バイ・デザイン」はユビキタス言語的な世界観の中で、慎重にソフトウェアを設計する（組み立てる）中でセキュリティを達成するという……あー、うまく言語化できない。極めて地道なアプローチである。

しかし、感想文パート2でも書いたけど、これを実現するのはめちゃくちゃ難しいんじゃないだろうか。だいぶ長期戦でチームでアプローチしないと実現できない、という意味ではプロジェクトで採用するのは難しく、プロダクト開発の中で少しずつ近づいていくしかないような気がする。

セキュリティとログの関係について

第3部で一番興味深かったのは、ログの取扱いのあたり。「第12章: レガシー・コードへの適用」「第13章: マイクロサービスでの指針」でもログの扱いについてけっこうな言及がある。
まあ確かに、設計／実装段階で一番意識が不足して、セキュリティが破れてしまうポイントの一つ（盲点）ではあると思う。
最近だとlog4shellの問題もあったばかりだしな……というわけで、このあたりはけっこうメモを取ったのだった。

そしてセキュリティに関する知識を常にアップデートしなければならないという

最終章の「第14章: 最後に：セキュリティを忘れるべからず！」では、結局のところセキュリティを設計に組み込んでいくためには、セキュリティに関する知識の継続的なアップデートが必要であるという身も蓋もない事が語られる。「セキュリティの分野を研究することが重要です」まあ、そうなんだけど……

というわけでなんとか読み切ったのだが、なかなか面白いが内容も難しく、簡単には身につかないような本だった。
さて、次は何を読もうか……

2022-05-15

GoogleのSRE本の続編(?)「インシデントの解剖学」を読んだ

Project Management Postmortem book

最近よく聞いているSRE系のポッドキャスト e34.fmのep17で紹介されてた、GoogleのSRE本シリーズの最新作(?)「Anatomy of an Incident（インシデントの解剖学）」を読んだメモ。ポストモーテム（検死解剖）から展開して、Anatomyは解剖学というわけだ。

sre.google

本書は書籍の体裁をとっているが、無料でPDF/EPUB/MOBIがダウンロードできる。O'reillyのサブスクにも収録されている。
learning.oreilly.com

全般的な感想

インシデント管理に特化した最新のまとめ小文書という印象。インシデント管理の周辺は適応課題というか悩ましいことが多いので興味深い。GoogleのSRE本やエンジニアリング本は良い本なんだけど、インシデント管理まわり以外の話題も多くて読むのも骨だから本書を手始めにすると良さそう。一方で、あまりディープなことが書かれているわけではない。

ちなみに、インシデント発生時の対処方法であるインシデントコマンドシステム（本書でも推奨されている）について興味があれば「システム障害対応の教科書」がとてもよかったのでオススメしておく。

興味深いと思ったのは、インシデント対応メンバーの燃え尽き症候群を防止するために、ものすごく配慮をしているという点だ。Googleではパンデミック以降に大きなインシデントの増大があったそうだが、そのあたりの学びが反映されているのだろうか。対応期間も3日以内と制限され、様々なケア（事前の訓練も含まれる）がほどこされている。確かに現代においてはエンジニアが最も重要かつ希少なリソースであるため、ここを守ることに注力するのは正しいような気がする。

各章に関する覚え書き

1. Introduction（はじめに）

失敗は避けられない。変化は常に予想できない。よって準備が重要
COVID-19パンデミックによってGoogleはインシデントの増大にさらされたが、10年以上にわたるインシデント管理への投資によってサービスの提供の継続ができた
Googleにおけるインシデントの定義：単独で処理できずエスカレーションされたもの、即時要対応、組織的な対応が必要
インシデント管理ライフサイクル：準備、応答、緩和と回復

2. Practicing Incident Response Readiness (Preparedness)　インシデントレスポンスの準備

災害ロールプレイングにより、インシデント対応のトレーニングを行う：GoogleのDiRTプログラム
レスポンダーの訓練：技術面、精神面、感情面での準備が必要
Using SRE and disaster recovery testing principles in production | Google Cloud Blog

3. Scaling Incident Management (Response)　大規模インシデント管理

階層的なレスポンダー：コンポーネントレスポンダーとSoSレスポンダー
Googleにおける2種類のSoSレスポンダー：Product focused IRTと、Tech IRT
共通プロトコル、信頼、尊重、透明性
バーンアウト対策：対応期間の制限（3日以内）で人を守る

4. Mitigation and Recovery　緩和策と回復方法

インシデントの影響の計算：TTD、TTR、TBF、Impact
TTD、TTRの短縮とTBFの延長のために投資する各種の手法
Shrinking the impact of production incidents using SRE principles—CRE Life Lessons | Google Cloud Blog

5. Postmortems and Beyond　ポストモーテムおよびその後

"Googleでは、Ben Treynor Slossが四半期ごとに「Google’s Greatest Hits and Misses」というレポートを発行して、過ちから学ぶことができる力を与える文化を育んでいます"
- 読みてぇ！が、ちょっと調べた感じでは公開はされていないっぽい
ポストモーテムでは、インシデントにおける根本原因とトリガーを区別する
システム思考（holistic systems thinking）

6. The Mayan Apocalypse: A Real-World Example　マヤの黙示録（現実の例）

これかな？
- https://status.cloud.google.com/incident/cloud-networking/19009
- An update on Sunday’s service disruption | Google Cloud Blog

7. Conclusion and Moving Forward　結論および今後について

インシデント管理に投資する
人の問題に対して備える
改善を繰り返す。ヒロイズムに陥らないようにする

2022-05-11

エンプラ技術者の知識継承がうまくいっていないかも、という話

Professional Engineer Project Management Software Architect

最近読んだ「Web世代が知らないエンタープライズシステム設計」はとても刺激的で良い本だった。企業の情報システム部門およびエンタープライズシステムを受託開発するSIerの中堅技術者は必読だと思う。ただ、書籍タイトルは中身を分かりにくくしている気がする。「エンタープライズシステムアーキテクトが知るべき16のこと」という感じの本だ。

さて、同書の冒頭で書かれている、エンタープライズシステム設計に関するノウハウ継承が世代間でうまくいかなたったのではないか、という問題提起が気になったので、考えたことを書いてみようと思う。

何がエンタープライズ システム開発のノウハウ継承を阻んだのか？

「Web世代が知らないエンタープライズシステム設計」では、2つの要因によって00年前後にエンタープライズシステム開発のノウハウ継承が阻まれたという仮説が提示されている（ノウハウ継承の場であるワイガヤが失われたという文脈）。提示されている2つの要因はこれだ。

要因1：技術パラダイムの転換（メインフレームからオープンシステムへ）
要因2：目標管理制度の導入と労務管理の適正化（残業規制）

私見だが次の2つの「波」を受けた時から議論をする雰囲気、すなわちワイガヤが失われていったのではないか。1つの波はオープンシステムである。企業でしか所有できなかった大型汎用機（メインフレーム）を使う時代から個人でも買えるPCで開発し、動かす時代がやってきた。もう1つは日本企業に目標管理制度が導入され残業規制が厳しくなったことである。

「Web世代が知らないエンタープライズシステム設計」はじめに、より引用

うーん、どうだろう……

要因1：技術パラダイムの転換 ⇒ 大小のパラダイムシフトに翻弄されたというのはあるかも

本書では大きな技術パラダイムの転換、すなわちメインフレームからオープンシステムへの移行が大きな要因だったと書かれている。しかし実際にはそれ以外にも様々なパラダイムシフトの波状攻撃によって、中核となる技術者の関心が発散してしまったというのが実際のところではないかと思う。

そういえば、「モダン・ソフトウェアエンジニアリング」でもJacobsonが似たような事を言っていた。

今日のソフトウェアエンジニアリングは、未熟なプラクティスによって重大な妨害を受けている。具体的な問題として、以下が挙げられる。

エンジニアリングというよりファッション業界でよく見られる一時的な流行の蔓延

妥当性のある広く受け入れられた理論的基盤の欠如

違いがほとんどないにもかかわらず人為的に誇張された無数の手法とその派生形

信頼できる実験的な評価と検証の欠如

業界の慣行と学術研究の分断

「モダン・ソフトウェアエンジニアリング」第2章ソフトウェアエンジニアリングの手法とプラクティス、より引用

ソフトウェアエンジニアリングについては進歩が早いだけでなく、流行もあるので、常に新しいことを学び続ける必要がある。
というよりもむしろ、学ぶことが好きな人にとって、常に新しい学習要素が供給され続けるという状況である。
その結果として、企業情報システムの構築方法という極めて重要度が高いスキルの「深掘り」や「継承」が劣後してしまったんじゃないか、というのが自分の意見だ。

要因2：目標管理制度の導入と労務管理の適正化 ⇒ 共感は出来るけど、もっと包括的な仕事環境の変化が原因なんじゃないか

本書では、目標管理制度、成果主義の導入と残業規制により、技術者が他のプロジェクトメンバーとの意見交換や切磋琢磨しなくなったのが、もう一つの技術継承阻害要因だったと論じている。
これは確かにそう、とも思うのだけれども、より具体的には「フィードバック入門耳の痛いことを伝えて部下と職場を立て直す技術 (PHPビジネス新書)」で指摘されている問題のほうが大きく影響していそうな気がする。

こうした状況に対して、「私の育て方に問題があるのだろうか？　私はマネジャーに向いていないのでは……」と自分自身を責めている人もいるでしょう。自分の部下に、メンタルをやられて、休職する人が出てくれば、なおさら自分に非があるのではないか？　と思ってしまうかもしれません。今の中間管理職の悩みは、非常に根が深いものがあります。　
しかし、そんな悩みを抱える中間管理職の方に、まずは、こうお伝えしたいと思います。
「若い部下が育たないのは、あなたのせいではありません。過剰に自分自身を責めないでください。それは、職場環境の変化によって構造として生まれている現象なのです」と。

「フィードバック入門耳の痛いことを伝えて部下と職場を立て直す技術 (PHPビジネス新書)」第一章なぜ、あなたの部下は育ってくれないのか？、より引用

同書では、

雇用の安定性（長期雇用、年功序列）によって部下を育成する余裕があった
長時間にわたって同じ空間（オフィス～アフター5）で行動をともにしていた。育成を促進する濃密な空間があった
組織がフラット化し、マネージャーの若年化、大量生産が起こったため、上司に学ぶ期間が減った
プレイングマネージャーが常態化し、成果を求められるようになったことから、育成余力が減った

などという分析がされている。コレジャナイ？

ちなみに同書は要は、過去は自然に人が育ったが現代では期待できないので、意図して育てるしかない。ではどうすれば、という話が続くのだが強くお勧めしたい

じゃあ、どうすんの？

では、現代のわれわれは、どうすべきなのだろうか。
そんなことがわかっていれば、やっているのだけれども、今のところ私は「これ」という策は見つけられていない。

ただ、少なくとも、何もしなければ人は育たないということだけは確かなのだ。

文化心理学とは

文化と視点、注意配分

自らの経験等から：ソフトウェア設計における欧米と日本の違い

日本文化とソフトウェア設計の関係性に関する研究もあるようだ

いろいろ考えたこと

文化心理学をもうちょっと学びたい

パタヘネ第３章〜第４章を読んだ感想

次回

文芸書のおすすめ（一般編）

文芸書のおすすめ（趣味のSF編）

教養書のおすすめ

ビジネス書のおすすめ

技術書のおすすめ

この半期の振り返り

2022年上半期に読んだ本

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

ヘネパタとパタヘネ

パタヘネ第１章〜第２章まで読んだ感想

各章の感想

1.コンピュータの抽象化とテクノロジ

2.命令：コンピュータの言葉

次回

全体を通じての感想

セキュリティとログの関係について

そしてセキュリティに関する知識を常にアップデートしなければならないという

全般的な感想

各章に関する覚え書き

1. Introduction（はじめに）

2. Practicing Incident Response Readiness (Preparedness) インシデントレスポンスの準備

3. Scaling Incident Management (Response) 大規模インシデント管理

4. Mitigation and Recovery 緩和策と回復方法

5. Postmortems and Beyond ポストモーテムおよびその後

6. The Mayan Apocalypse: A Real-World Example マヤの黙示録（現実の例）

7. Conclusion and Moving Forward 結論および今後について

何がエンタープライズシステム開発のノウハウ継承を阻んだのか？

要因1：技術パラダイムの転換 ⇒ 大小のパラダイムシフトに翻弄されたというのはあるかも

要因2：目標管理制度の導入と労務管理の適正化 ⇒ 共感は出来るけど、もっと包括的な仕事環境の変化が原因なんじゃないか

じゃあ、どうすんの？

2. Practicing Incident Response Readiness (Preparedness)　インシデントレスポンスの準備

3. Scaling Incident Management (Response)　大規模インシデント管理

4. Mitigation and Recovery　緩和策と回復方法

5. Postmortems and Beyond　ポストモーテムおよびその後

6. The Mayan Apocalypse: A Real-World Example　マヤの黙示録（現実の例）

7. Conclusion and Moving Forward　結論および今後について