ken1flanのブログ

自己紹介・最近やってることなどを書くつもりです。

Software Design輪読会ドリブン読書(2025年版)

はじめに

去年書いた記事を今年版として書き直しました。

Software Design輪読会へは第33回からお邪魔させてもらっていますが、この輪読会を起点に、いい感じに読むリズムを刻んでがうまく回っているので、それを紹介したいと思います。 ひとことで言ってしまえば、ひとりで読んで思ったことをメモにまとめて輪読会の準備とし、輪読会で他の方の思ったことを聴いたり話したりして、感想にまとめているだけではありますが…。 少しだけ気をつけてることをまとめますので、よろしければどうぞ…。

flowchart LR
  SD[Software Design]--読む-->memo[メモ];
  memo--輪読会-->輪読会の感想;

メモ

すべての起点となってるメモですが…。 やっていることは、記事のタイトルを準備して、読みながらブツブツ言ってる内容をほぼそのまま書いています。 輪読会で、他社での事例とわからないこととか、訊いてみたいことも書いておくとよいです。

ken1flan.hatenablog.com

要約をつけるとかは一切しません。大体要約は記事のタイトルにまとまっててくれます。 なので、思ったことや、調べたことのリンクをつけるだけにしています。

なぜこのスタイルになったのかというと…自分が誰かに記事について話すきっかけだけを作れればいいと思ったからでした。 これは、輪読会でちょっときっかけを発言したときに北崎さんや他の経験豊かな参加者たちの超察し力によりよい具合に展開される盛り上がりになっていった経験が何度もあったからでした。 輪読会でなくても、やっぱり同じように話し相手が上手に受け取って、いいように話が転がってくれるだろうことが想像できたので、この形に落ち着きました。

記事タイトルを書くの、大変じゃない?

面倒なことを始めるためには、如何に楽に書き始める環境を整えるかが最も大事だと思っています。その作業手順がココ、最重要ですよ!

…と煽っておきながら、こういう面倒な作業は、ChatGPTにお願いするのがいいと思います。

自分はこんなふうに頼みました。

YYYY年MM月号のSoftware Designのメモをマークダウン形式で書こうと思っています。
各記事のタイトル、サブタイトル、著者をまとめてセクション名にしてください。

↓はYYYY年MM月号の目次ですが、例のように整形してください。

(Software Designの対象号のページからコピーした目次をそのまま貼り付け)

(例: 2024年11月号)
(その前に書いたものを貼り付け)

実際のは長いので折りたたみました。

2024年12月号のSoftware Designのメモをマークダウン形式で書こうと思っています。
各記事のタイトル、サブタイトル、著者をまとめてセクション名にしてください。

↓は2024年12月号の目次ですが、例のように整形してください。

第1特集
落し穴にハマる前に!
シェルスクリプトの基本と罠
コンテナ,クラウド,Web開発,なにかと使える基礎技術
第1章:シェルスクリプトの基礎
利点・欠点・使いどころを認識しよう
…… 滝澤 隆史
第2章:シェルスクリプトの基本文法
実務で頻出の機能を要領よく学ぼう
…… 滝澤 隆史
第3章:シェルスクリプトの使いどころ
CLIコマンドの活用が業務効率化のカギ
…… 山田 泰宏
第4章:落し穴に落ちないシェルスクリプト開発のススメ
ShellCheckとShellSpecで安全なシェルスクリプトを作る
…… 近松 直弘
第2特集
10周年特別
[最新]Swiftの現場
これまでの進化の軌跡&Swift 6レポート
…… 田中 涼賀
第1章:10周年を迎えるSwiftのこれまで
Apple謹製言語の歩みを振り返る
第2章:Swift 6への移行
求められる既存コード変更へのヒント
短期連載
[速習]PHPアプリ開発の現在地
【2】PHPUnitのassertSameとassertEqualsの実装ってどう違うの?
……asumikam
連載
ITエンジニア必須の最新用語解説
【192】Valkey 8.0……杉山 貴章
万能IT技術研究所
【31】結婚式や葬式が決められない!? 旧暦2033年問題――150年前に廃された天保暦に仕込まれた時限爆弾……万能IT技術研究所
FE/AP試験問題に挑戦
【2】情報セキュリティ(技術)……石田 宏実
ドメイン解体新書
【11】セキュリティとパフォーマンスを向上するHTTPSレコード……谷口 元紀
ハピネスチームビルディング
【33】小さなシェアドリーダーシップの発揮を見える化しよう……小島 優介
Cloudflare Workersへの招待
【13】Cloudflare Queuesを使ってバックグラウンドで処理してみよう……Aiji Uejima
ソフトウェアテスト探検隊
【3】シフトレフトテスティングの意義と戦略……Kuniwak
実践データベースリファクタリング
【11】ループされたクエリの倒し方……曽根 壮大
【最終回】レガシーシステム攻略のプロセス
【8】フロントエンドエンジニアから見るZOZOTOWNリプレイスとまとめ・今後の展望……新家 弘久,森 泰樹,高橋 智也,瀬尾 直利
ぼくらの「開発者体験」改善クエスト
【12】テスト体験の改善で,開発者体験を改善……西薗 和希
【最終回】Databricksで勝つデータ活用
【9】Databricksで始めるデータメッシュアーキテクチャ……北岡 早紀,桑野 章弘
実践LLMアプリケーション開発
【15】Human-in-the-loopでAIエージェントの動きにフィードバックを加える(後編)……西見 公宏
AWS活用ジャーニー
【27】AWS WAF……杉金 晋
インターネットの姿をとらえる
【4】ISPとは何者か……土屋 太二
基礎からわかるDetection Engineering
【5】検知ルールの評価とDetection Engineering Program①……石川 朝久
魅惑の自作シェルの世界
【25】引数のシングルクォートの実装とパラメータ展開の準備……上田 隆一
あなたのスキルは社会に役立つ~エンジニアだからできる社会貢献~
【155】バリアフリーに関する情報を誰かの「一歩」に~みんなのトイレマッププロジェクトから見えてきたこと……菅原 洋介(Pen)

(例: 2024年11月号)
## 第1特集 新世代の開発スタイル はじめてのAI駆動開発
### 第1章 GitHub Copilotでラクラクコーディング 単純作業はAIにサクッとやってもらおう …… 森下 篤
### 第2章 AIチャットボットとペアプログラミング 質と速度を両立する次世代の開発手法を体験しよう …… ふじたさん。
### 第3章 ChatGPTでプロトタイプをサクサク生成 AIツールならUIからコードまで自動で作れる …… 鈴木 章太郎
### 第4章 Infrastructure as Codeで生成AIを活用する アーキテクチャ図⇔IaCコードの変換も自由自在 …… 吉波 海斗(つくぼし)
### 第5章 AI駆動開発の将来 AIによる今後の開発スタイルと求められるスキルとは? …… 荒井 康宏

## 第2特集 ランサムウェア対策のアプローチ EDRとマイクロセグメンテーション
### 第1章 ランサムウェアの現状 日本での被害状況と最新の手口 …… 武田 貴寛
### 第2章 エンドポイントセキュリティ EPPとEDRで予防と復旧を両立する …… 福田 俊介
### 第3章 マイクロセグメンテーション 内部に侵入してきた攻撃から守る …… 阿部 久珠幸,金子 春信

## 短期連載 
### [速習]PHPアプリ開発の現在地 【1】PHP超入門 ……びきニキ

## 連載
### ITエンジニア必須の最新用語解説 【191】PGlite ……杉山 貴章
### 万能IT技術研究所 【30】「雰囲気を写す写真」や「ドレス錯視」の謎を解く。――視覚モデルで「色の見え」をシミュレーション! ……万能IT技術研究所
### 【新連載】FE/AP試験問題に挑戦 【1】情報セキュリティ(マネジメント系) ……石田 宏実
### ドメイン解体新書 【10】WHOISの非義務化からひも解く登録者情報公開のしくみ ……谷口 元紀
### ハピネスチームビルディング 【32】データを基に各自で改善点を考えよう(後編) ……小島 優介
### Databricksで勝つデータ活用 【8】データインテリジェンスにおけるAI/BIダッシュボード ……新井 康平
### ソフトウェアテスト探検隊 【2】ソフトウェアテストと論理式 ……Kuniwak
### レガシーシステム攻略のプロセス 【7】検索機能リプレイスの裏側 ……可児 友裕,渡 雄一郎,塩崎 健弘
### ぼくらの「開発者体験」改善クエスト 【11】エンジニアの力を最大限引き出すためにプロダクトマネージャーがすべき3つのこと ……高橋 茉由実
### Cloudflare Workersへの招待 【12】Cloudflare AccessでWebサイトへアクセス制限を追加しよう ……福岡 秀一郎
### 【最終回】あなたの知らないChromeの世界 【10】Privacy Sandboxを巡るWebの今後 ……小河 亮
### 実践LLMアプリケーション開発 【14】Human-in-the-loopでAIエージェントの動きにフィードバックを加える(前編) ……西見 公宏
### AWS活用ジャーニー 【26】AWS Backup ……杉金 晋
### 基礎からわかるDetection Engineering 【4】Detection as Code――SIGMA ……石川 朝久
### インターネットの姿をとらえる 【3】インターネットを支える物理回線の世界 ……土屋 太二
### 魅惑の自作シェルの世界 【24】ブレース展開の例外的処理とエスケープの実装 ……上田 隆一

こんなふうに返してくれるので、コピーして使います。

chatgptの返答

読者アンケートを書く

もうひとつ大事なことを…。

読み終わったら、アンケートに答えるといいと思います。

結構ガッツリ読まないと回答できないような質問内容ですが…すでにちゃんと読んでメモしてるので、5分くらいで答えられると思います。 もしかするとReader's Linkに採用されたり、読者プレゼントがもらえちゃうかもしれません。 (ありがたいことに、自分はいくつか採用されました\(^o^)/)

Software Design輪読会

https://softwaredesign.connpass.com/softwaredesign.connpass.com

メモのところで書いた、訊いてみたいことをいろいろ話すと盛り上がって、もっと楽しく過ごせるのでオススメです…!

輪読会の感想

ken1flan.hatenablog.com

輪読会に出たらすぐに、感想を書くようにしてます。 あんまり細かいことは考えずに、書いているそのときに覚えていることをサッと書くだけにしてます。 誰かに読ませたいというより、自分の記憶定着のための刺激として使っているイメージです。

自分の他の事例: 「プリンシプル オブ プログラミング」読書会

会社のメンバーと自身のスキルアップのために「プリンシプル オブ プログラミング」読書会をやっています。 これもSoftware Design輪読会 と同じように、事前予習のためのメモ、読書会、読書会の感想を書く、というリズムを繰り返しています。 一人で読むより学びが多くて楽しい気がしています。

ken1flan.hatenablog.com https://academist-reading.connpass.com/event/336021/academist-reading.connpass.com ken1flan.hatenablog.com

終わりに

個人的にハマっている、Software Design輪読会ドリブン読書の紹介でした。 スピードは出ませんが、読む楽しさは今までにないくらいありますし、なんとなく終わったあとに成果物ができているのもやった気になれていいかも。

それではみなさん、Software Design輪読会とReader's Linkで会いましょう。

第75回Software Design (2025年12月号) 輪読&座談会 に参加してきました

いつもおせわになっている第74回Software Design (2025年11月号) 輪読&座談会に参加してきました。

softwaredesign.connpass.com

予習

第1特集 ユーザーIDを管理するとは? 今さら聞けないID管理 認証基盤を構築する際に知っておくべきこと

  • 大きなチームだと、認証基盤を担当するチームがいるとのことでした。
    • アナウンスが十分でなかったか、急にテストできなくなって知ったとのことで…。難しいですね。
  • IDaaSを使われている方はいませんでした。
    • 十分大きいところだと、共通基盤チームとかいるし…ウチみたいに小さすぎると、認証基盤と呼ぶほどのものがいらないからかな…。

特別企画 2025年ノーベル物理学賞受賞の背景がわかる 量子コンピュータを支えるしくみ

あなたのスキルは社会に役立つ~エンジニアだからできる社会貢献~ 【167】Code for Manazuru 過疎地域×テクノロジーの可能性

  • お手伝いを地域通貨で発注できるのはちょっとおもしろそうですよね、とみんなでいってました。

SD BOOK REVIEW

ランサムウエア攻撃との戦い方

  • ビールが届かなくなって大変という方が…。
  • ランサムウェア被害、誰でも遭う時代になりましたね…とみんなで言い合ってました。

最後に

今回も刺激的な会で、ひとりで読むよりずっと学びがありました。 また次回も行こうっと。

Software Design 2025/12 メモ

表紙

  • インパラのオスかしら…。
    • 近縁の仲間がいっぱい暮らしてるんで…難しいですw
    • たぶん…ダマガゼルじゃないよね…?
    • 顔の模様がないのと、首ががっしりしててゴツそうだし。
  • ja.wikipedia.org

第1特集 ユーザーIDを管理するとは? 今さら聞けないID管理 認証基盤を構築する際に知っておくべきこと

第1章:デジタルIDを管理するとはどういうことか? ID基盤構築において漏れなく設計/実装するために……森 大輔、山田 達司、水原 智広、菊地 周平、貞弘 崇行

  • ID管理の分類、求められる機能、法律やガイドラインの紹介
  • ライフサイクル
    • …たしかに設計されてません…。
    • 削除されるときまで考えて、ようやくライフサイクルですよね。
    • 不明、確立済み、アクティブ、一時停止、アーカイブ…たしかにどのシステムでもそんなに変わらなそう。
      • ウチ、一時停止とアーカイブがないですね…。投稿サイトじゃないから、必要なさそうだけど…なんか用途あるかなぁ…。
  • ID管理を目的・対象で大きく分けると企業向け(EIAM)と顧客向け(CIAM)の2つっていうのは…なるほどでした。

第2章:認証基盤を実現するための技術とアプローチ CIAMの要素技術とIDaaS、OSS選定の戦略……赤星 拓未

  • CIAMの要素技術とIDaaS、OSS選定の戦略(サブタイトルのままが一番よさそう)
  • 必要になったら、だけど…認証保証レベルごとにできることを変えるのもアリかも…。
  • 同期パスキーとデバイス固有パスキーで認証保証レベルが変わるのか…。
  • アカウントリカバリかあ…ユーザの情報がリッチになるにつれて、狙われやすくなりそう…。

第3章:IDaaSとはどんなサービスか Auth0から学ぶ機能と選定の勘所……宮崎 将太、市川 浩暉、藤井 亮佑

  • Auth0の機能の説明と、共通会員基盤として導入した事例
  • Actionsは結構カスタマイズしやすくなりそうで、よいですね。

第4章:B2B SaaSにおける認証基盤構築の実際 IDaaS採用から内製化まで……樋口 礼人

  • Auth0からAWSのCognitoを使っての認証基盤の内製化の事例
  • 事業急成長で…こりゃスゴイ…。
  • AWSのCognitoか…たしかに安かったと思う…。

第2特集 新時代の脅威に備える AIセキュリティ入門 AIエージェントへの攻撃手法と防御策を押さえよう……川喜田 将之

第1章:AIエージェントにおけるプロンプトをめぐる攻防 エージェントの乗っ取り・暴走・制御不能の事例を知る

  • エージェントの乗っ取り・暴走・制御不能の事例(サブタイトルのまま)
  • 白い背景に白い字…SEO対策…。
  • AIさん、基本的に人がいいんですよね…。
  • AIの言動の責任は単一のエージェントでは絶対やっちゃダメですよね…。ガードレール、必須…。

第2章:AIエージェントに対する攻撃手法 攻撃のメカニズムを解剖する

  • 各種攻撃手法の解説(ほぼサブタイトルのまま)
  • OWASPの2025年 LLMおよびGen AIアプリのリスクと軽減策トップ10
  • データにプロンプトを仕込まれるのは、確認をすり抜けやすくてちょっとイヤですよね…。
    • エージェントに対してやられるともう><
    • データの形式は問わないかあ…。
  • ユーザを喜ばせたいので、言い訳を与えられれば喜んで制約を破ってしまう……ですよね。
  • エディタ内でコマンドを実行できるようになってるエージェントって、めっちゃ怖いんじゃないのって思っちゃう…。
  • データ汚染の手段として、エージェントが参照しているWebページの改ざんとかあるのかあ…。
  • 特殊トークンをデータに埋め込むだと…ちゃんとサニタイズして使えってことかしら…。

第3章:AIを安全に活用するために押さえたい防御策 2つの基本思想と対策すべき5つの観点

  • ガードレール設計と多層防御
  • スイスチーズモデル🧀
  • 三層ガードレール…入力チェック/本体/出力チェック…モデル化されていると、実装しやすくて助かります。
  • AIベンダーが防御機能を提供してるのは助かるかも…。
  • 堅牢なシステムプロンプトって…セッション中にAIと友達っぽくなったら、なんか破れちゃわない?
    • 多層防御がホント大事そう…。

特別企画 2025年ノーベル物理学賞受賞の背景がわかる 量子コンピュータを支えるしくみ……荒木 誠

  • トンネル効果/超電導など量子コンピュータの仕組と、量子コンピュータ上で扱う量子アルゴリズム
  • 今年は記事に!
  • …しかしむずい💦
  • トンネル効果も超電導もずっとしっくりきてないし…。なんなんだろう、この現象…。
  • 暗号どーすんだってずっと思ってたんですが…ポスト量子暗号……ちょっと期待。
  • サンドイッチ攻撃…高度ですね……。
  • あー…チャット欄で長時間話したらどうなるんでしょう……。

短期連載

【最終回】Javaバージョンアップ大作戦 【3】Java 25へのバージョンアップに向けて……杉山 貴章

  • Java21→25の主な新機能
  • なんと…!mainやprintlnの省略…!Nanowar of SteelのHelloWorld.javaが危うい…?!
    • youtu.be
    • 2024年発表なら…その時点で短く書けたバージョンがあったのでは…。
  • コンパイルしないで実行できるようになってる…!
  • 量子耐性の高い暗号化アルゴリズムがサポート…へええ。
  • こうして見てると、ホント、進化が止まらないですね、Java。手堅いバージョンもあるしサポートも長いし、hello worldも短くなったし、結構いいかも。

連載

ITエンジニア必須の最新用語解説 【204】Manus……杉山 貴章

  • 複数LLMを裏で使うタスクランナー/エージェント実行基盤
  • Manus自体がマルチエージェントなのかあ…。
  • サービスとしては最初から、よくあるマルチエージェントの形を取ってくれてるのはとても使い勝手がよさそうです。
  • まるっとタスクを任せる非同期型でDevinに近そう。

万能IT技術研究所 【43】「カメラの標準レンズは50mm」になった理由——人の視力で世界を眺める!? 35mm判カメラ創世記……平林 純

  • カメラ開発の歴史
  • ホント、エジソン、なんでも作ってますよね…。

現実世界を拡張するWebXRプログラミング 【2】WebXRを実現するツールの選択とその動作環境……にー兄さん(堤 海斗)

  • WebXRのためのライブラリやツールの紹介
  • iOSは…レンダリングエンジンがSafariと同じだそうで…WebXRに弱いんですね…。

ドメイン解体新書 【23】「SSLサーバ証明書47日時代」に備えるDNS自動化のススメ……谷口 元紀

  • SSLサーバ証明書の有効期間を短くする背景
  • …たしかにキーが漏洩しても、有効期間が短ければリスクがかなり低減される…これは納得の理由かも。

ネコ、コード、ネコ 【6】社会人になって学ぶコンピュータサイエンス……植山 類

  • 独学と大学のCS比較
  • …たしかに独学だと、網羅しているか不安っていうのはなんとなくわかります。

パッケージマネージャーNix入門 【4】Nixによる開発環境の構築――手元のマシンの宣言的な構築……たけてぃ

  • 開発環境のプロジェクト固有/個人ツール/システム設定の管理方法
  • 開発マシンごと管理するのは…ほしいっちゃほしいんですよねえ…。
  • デーモンの管理とかもあるのはおもしろい…!
  • macOSを宣言的に管理……たしかにいいかも。マシン変えるときに、タイムマシンだとゴミごとの移行になっちゃうしw

技術選定の舞台裏 【4】SUZURIのモバイルアプリ……黒田 駿、八木 仁

  • モバイルアプリの技術変遷、iOSとAndroidのコード統合、CI/CD
  • 初期アプリ、2Dゲームエンジンでできてたとは…。たのしい演出できていいですよね。
  • Android対応のはじまりはFlutter…。めっちゃ見た目にこだわることをしないなら、妥当な気がするんですよねえ。
  • Kotlin Multiplatform ?そんなものが…!

Ruby×静的型付け戦略 【8】AIエージェント時代と型システム……黒曜

  • AIエージェントに型システムを組み込んで開発するためのおすすめの方法
  • 型注釈をコードを保証できるドキュメントと見れば、導入の価値は大きそう。
    • AIにもメリットがありそうなら、人間にだってねぇ。
  • なるほど…rbs inline、どうかと思ってたけど、コードと型注釈が近いから有利に働きそうなのか…φ(・
    • あ…でも、微妙に文法が違うからノイズになるかもしれない…?うーん…。

プログラミング×AIの最前線 【9】AI時代のコードレビュー……木下 雄一朗

  • AIを使ったコードレビューのいろいろ
  • AIコードレビューって…マルチエージェントのシステムでよくつけてる検証器みたいなもんですよね。エージェントに書いてもらって、エージェントにレビューしてもらっておけば、人間が確認する量がだいぶ減りそうだし、結構よさそう。
  • チェックリスト用意してるよ…。人間と同じですよねえ。
  • CodeRabbit、レビューにフローチャートとかシーケンス図がついてくるの?結構価値ありそう…。

実践LLMアプリケーション開発 【27】振り返りによってプロンプトを自己進化させる最適化手法「GEPA」……西見 公宏

  • プロンプト改善をGEPAを使って行ったときの実行手順や結果の例
  • 前号と違う方法でのプロンプト自動改善なのか…。
  • 「DSPyで提供されるオプティマイザの一例」の比較がわかりやすいかも。
    • GEPAはプロンプトだけ、前号のMIPROv2はプロンプトとFew-Show例の両方を最適化だって。
  • 遺伝的アルゴリズムかあ…おもしろいですね。
  • 実行前後の長さの差が…!

AWS活用ジャーニー 【38】AWS Step Functions……杉金 晋

  • ワークフローサービスのStep Functionsの紹介
  • あれ、以前はたしかにLambda経由だったけど、直接になったんですね。

はじめてのオフェンシブセキュリティ 【6】Boot2Rootに挑戦してみよう!(Linux編)……皆川 諒、監修:株式会社エヌ・エフ・ラボラトリーズ

  • あとで。

【最終回】乱数のひみつ 【10】検証可能な乱数(VRF)とは……荒木 誠

  • 予測不可能だが検証可能な乱数VFRの解説
  • 「検証可能」というのは、生成された乱数を第三者が改ざんされていないか検証できること…。これなんか、おもしろいことができそうですね…。
    • プレゼントの厳正なる抽選ができそう…。
  • 応用例にブロックチェーン…使いそうだなって思ったら使ってました。

インターネットの姿をとらえる 【15】DNSの名前解決のしくみ DNSが壊れるとインターネットが壊れる!?……土屋 太二

  • DNSの仕組みと障害対策
  • ルートサーバ、TLDの権威DNSサーバは世界中に分散配置…。
    • めっちゃ疑問ですが……分散されたサーバ自体に改ざんがあったときってどうなるんでしょう?

魅惑の自作シェルの世界 【37】localの実装(前編)……上田 隆一

  • localの実装
  • 関数の中から外の変数の値を書き換えられちゃう><
    • 関数の中から外の変数の値を書き換えられちゃう><
  • 関数を書くときには意識してlocalつけないとダメですね…。
  • そんなにいっぱいあるし、微妙な挙動するなんて…代入コマンド、闇ですね💦

あなたのスキルは社会に役立つ~エンジニアだからできる社会貢献~ 【167】Code for Manazuru 過疎地域×テクノロジーの可能性……佐野 杏

  • 地域通貨アプリマナレージとそれにまつわる活動について
  • 好きな具をもりもり乗せたピザトーストが謝礼って…パン屋おもしろすぎます…。
  • 地域の人にだしてもらった古い写真と地図を結びつけるって、結構おもしろいかも…。

その他

SD BOOK REVIEW

プリンシプル オブ プログラミング 第7章とあとがきのメモ

プリンシプル オブ プログラミング読書メモです。

第7章 法則 ~プログラミングのアンチパターン

7.1 ブルックスの法則

要員追加は「火に油」

  • これ、まだやるひといるの…?
  • チームに入って即動けるひとなんて、そんなに慣れるのに時間かかるのはわかりそうなもんですが…数値だけ見るとできそうになるのか……。
  • どの立場のひとが言い出すんだろう…?

「人」と「月」は交換不可能

  • この「交換不能」について理解することは、人月の交換を迫られたときにちゃんと説明してあげるためにいりますね。

リスケジュールせよ

  • まぁ、遅れているプロジェクトはリスケしかないか…。
  • リスケと合わせて、教育期間を考慮しての人数追加ってどう…?
  • 遅れているプロジェクトはリスケしかないが…リスケが許されないので、無理して人員追加しようとしているような気もしていて……。

生産と出産のアナロジー

  • たしかに絶対必要な時間までは縮められませんねw
  • 1億人でゲームを開発したら、明日リリースできる…わけないよね。

「人」と「人」も交換不可能

  • たしかに、初心者たくさんと上級者ひとりを比べりゃ、交換が難しいことがわかる…。
    • 中間は…判断が難しいですよね。どうするんだろ…?

アンチパターン

その他

7.2 コンウェイの法則

コンウェイの法則

  • こんなに大きなプロジェクトに参加したことがないので、なんとなくそうなのかなぁ…という気持ち。
    • 読書会で大きな組織にいたことのあるひとからの経験談を熱望…!

アーキテクチャはコミュニケーションに従う

  • なんとなくわかる…。

アーキテクチャ設計後に組織編成せよ

  • なんとなくわかる…。
  • これまでの読書会でたびたび、組織を再編成したほうが…といった話の原点かも。

組織とプロセス

  • あ、こりゃそうだ…。

7.3 割れた窓の法則

悪いコードは「蟻の一穴」

  • 悪いコードのほかに、落ちたままのテスト、通らないままのCIなども…。

悪いコードは邪心を引き出す

  • 邪心を引き出す…はまさにそうですよね…。

コードは「清潔」に保つ

  • レビューやツールによるチェックが発達してきてる今は、スコアで出るんである意味やりやすくなった気がします。

人は人を真似る

  • まぁ…わかる……。

7.4 エントロピーの法則

コードは自然と腐っていく

  • 「腐っていく」という表現はあんまり好きじゃないんですが…他にいい言い回しがなくって。
    • 使われないアプリケーションは…「腐らない」ので単純な時間ではないんですが…うまく言えません💦
  • コメントとコードが嘘をつき始める…これは腐ってきてると言ってもいいかも…。
    • コメントが間違ってたり、メソッドやクラスの名前が役割と違ってくると、もう目も当てられない…。

コードは無秩序へ向かう

  • 無秩序に向かうのは、ビジネスの変更に対して、既存のサービスと整合性を取りながらの変更であることが大きな原因じゃないかなあ…。
    • 整合性について、企画段階で忘れられがち(経験上)

コード腐敗の兆候をつかむ

  • 現状Webアプリケーション開発なので、移植性にそれほど気を配らなければならないことが多いです。
    • OSやミドルウェア、開発言語その他多くのものの作者たちに感謝🙏
  • 複雑さに対して、不要な要件を削除したり、既存のものを廃止したりと、開発者以外とも連携を取っていくのがいいと思っています。

アジャイルで腐敗を許さない

  • 要件から実装、テストあらゆるものに対してシンプルを心がける、テストをしやすくするあたりが一番気をつけているかも。

チーム文化で腐敗を許さない

  • 割れ窓理論も同じですね。
  • チームが文化を保つことを外部にもうまいこと説明して、工数を確保しないと維持できないので…。
    • アジャイルのショーケースはホント大事だと思います。

その他

  • うちでは…
    • 開発している箇所の近隣を少しきれいにするように心がけてます。
  • コーディングエージェントを使って、気軽に小さい範囲リファクタリングさせるのもありかも。
    • 小さいが重要…。
    • 大きくすると、混乱を運んでくる可能性が…。

7.5 80-10-10の法則

プログラミングに万能薬はない

  • んー…プログラミング万能薬ではない、のほうがしっくり来るんですが…どうだろう…。

プログラミングの問題領域は広すぎる

  • 提供されるものですべて賄えるなら、そりゃおまんま食い上げですわ…。
  • 実際の業務とツールなりなんなりの間を結びつけるのが、仕事でもありますね。

ツールの使用は適材適所

  • なんでもツールは…自分もどうかと思います。

万能薬より専門薬

  • 「高機能な言語+DSLのメタ層」…Rubyのことか!

80:20の法則

  • 所得の話はえげつないですね…。

その他

  • 80:10:10 もいろいろな場面で適用されてるんじゃない…?

7.6 ジョシュアツリーの法則

名前がないものは見えない

  • この話、ノンデザイナーズ・デザインブックでも読みました!…と思ったら、出典でした。

名前を知ることで存在を知る

  • 特徴は覚えてても…名前を忘れちゃうんですよね……。それでも一応見えるんだけども。
    • 繰り返し使うしかないかぁ…。
  • 名前を知ることで、存在を認識し、共有できるのだったら…チームで読書会をするのは理に適っているのでは…!

ユビキタス言語を使用する

  • そう…わかるんだけど、メンテナンスが……><

バベルの塔

  • この話、おもしろい解釈だとは思う…。

7.7 セカンドシステム症候群

2番目のリリースは機能過多

  • そうですね…。

慣れると「多機能主義」へ

  • これも確かに…。

ユーザーを考える

  • うーん、いつもやってるつもりではありますが…昔どうしてたっけ…?
  • いつのころからか、だれがどんな場面で使うのかをイメージするようになってました。
  • ウチの会社では、リソースが少ないこともあって、同じように考えてくれてると思うんですが。
  • …ほかの環境のときには気をつけないとダメかも。

セカンドシステム以降症候群

  • 無駄な多機能化……撤退が大変だから……。
    • 使う場面をとにかく意識してます。

フィーチャー・クリープ

  • シンプルさ…これにつきますね。

7.8 車輪の再発明

既にあるのに作る

  • 標準ライブラリにあるのに作っちゃう…?それは…なかなかないかも…。

「車輪を知らない」「車輪を作りたい」

  • 「車輪を知らない」…は現状だとどうにもならないかなぁ…。よく調べるしかない…。
    • 仲間が増えれば、その分目が増えるので…期待。
  • 「車輪を作りたい」…個人でやります!

「車輪」以外に注力する

  • 車輪以外にすることいっぱいあるんですよ、そもそも…。

車輪を再発明すべき時

  • ビジネスの核なら…そもそも革新的な何かがあるんじゃ…?実装しない理由がよくわかんない…。
  • 学習は学習だから…やるよね。

7.9 ヤクの毛刈り

本当の問題にたどり着かない

  • ja.wikipedia.org
    • ヤク…そういえばちゃんと知らないや…。
    • 大きく言えば牛の仲間で、バイソンと近い、と。
    • アジアの山奥にいる…え?
  • ja.wiktionary.org
    • なんか2つの意味が書かれてますね…。
      • 本で紹介されてないのは、問題を解決するために一見必要のない行為。
  • ヤクはアメリカでは全く身近じゃないそうで…それゆえにジョークになったのかも。

トラブルは芋づる式

  • トラブルなんだから…芋づるだし、フラストレーションはたまりますよね。

早々に切り上げる

  • 適当なところで、立ち止まって考えなおすのは大事ですね。

「ヤクの毛刈り」に立ち向かう

  • 最近はissueベースだし、毎朝の共有が必然的に考え直したり、書き留めたりするきっかけになってて…悪くないです。

プログラミングの「ヤクの毛刈り」

  • 思考ループは…まぁ、ありますね…。
  • 回ってきたなと思ったら、メモを始めてます…。

あとがき

  • ケアリング

    • コードを読む人、めっちゃ気をつけてる…。
      • 長く務めることが多いので、結局自分であることが多いのも、その理由ではあります。
  • 道徳法則

    • 「使いやすい」はいつも気をつけています。
      • お問い合わせが来て、結局自分のところに質問が来るから…というのもあります。
  • メソテース

    • issueやpull requestに背景というか何を解決したいとかいう情報をなるべく盛り込むようにしています。
    • それを書くようにすることで、バランスを取るための情報を集めている感じです。

第74回Software Design (2025年11月号) 輪読&座談会 に参加してきました

いつもおせわになっている第74回Software Design (2025年11月号) 輪読&座談会 に参加してきました。

https://softwaredesign.connpass.com/event/371882/softwaredesign.connpass.com

予習

第1特集 自分にぴったりのツールを見つけよう AI開発ツール大整理 GitHub Copilot、Claude Code、Devin、Cursor、Amazon Q、Gemini Code Assist

  • 盛り上がりました!
  • みなさん、結構いろんなサービスやモデルを使っているようで……自分も今使っているgithub copilotをもう少し使っていこうという気になりました。
  • 他の方の感想を聞いていたところ、devinが最近急によくなってきて、claudeを使ってたようなものもできるようになってきたとか…。めっちゃ気になってきました。
  • Gemini Code Assistの請求の話はちょっと怖かったです><

第2特集 あなたにもできる 怖くないオンコール対応、障害対応 基本動作と、精神的ストレスを軽減する方法……渡部 龍一

  • 予習してて、よさそうな記事だという印象を持ってたんですが、輪読会の場でも結構良かったという感想が出てきたので、よかったです。
  • あとAIに関しては、手間がなくなる反面わからなくなってしまうこともありそうで、注意が要りそうですねという話も出ました。

万能IT技術研究所 【42】惑星落としで分かれた月が「地球を向き続ける」理由——1stインパクト後の月自転速度シミュレーション……平林 純

  • ふくよりさんがものすごくスマートに説明してくれました。
    • 同じ面を見せてる…けど、首振りしてるんだとか…。全く知りませんでした。
    • note.com

Ruby×静的型付け戦略 【7】静的型検査を支えるRBS関連ツール……遠藤 侑介、栗原 勇樹

  • この連載を読んで、ウチもRBSによるチェックを導入しました!みたいな記事をアドベントカレンダーに書いて欲しいっていわれました…。
  • なるほど、悪くないかもしれません。

AWS活用ジャーニー 【37】Amazon EventBridge……杉金 晋

  • 杉金さん、最初1年くらい…とかおっしゃってたのに、もう3年を越えてる…。
  • また遊びに来て欲しい!

はじめてのオフェンシブセキュリティ 【5】特権アカウントになってターゲットを掌握しよう!(Linux編)……皆川 諒、監修:株式会社エヌ・エフ・ラボラトリーズ

  • これ、めっちゃいい!と盛り上がりました。
  • やってると、結構怖くなりますし。

乱数のひみつ 【9】WebAuthnによる認証と乱数……荒木 誠

  • twitter.comの二要素認証のubikeyなどが使えなくなる話をしたら、ほめられました…。
  • ちゃんとリンクをつければよかったです…。

最後に

今回も刺激的な会で、ひとりで読むよりずっと学びがありました。 また次回も行こうっと。

Software Design 2025/11 メモ

表紙

  • アジアゾウかしら…?
    • 耳が小さい、牙がない
  • 色が渋い緑とオレンジで、とても秋っぽいですね。

第1特集 自分にぴったりのツールを見つけよう AI開発ツール大整理 GitHub Copilot、Claude Code、Devin、Cursor、Amazon Q、Gemini Code Assist

序章:AI開発ツールの概観 さまざまなツールを整理する3つの視点……木下 雄一朗

  • ひとことで
    • 同期/非同期エージェント、GUI/CUI、単一/マルチモデルの3つの視点の説明
  • 自分はまだ同期型としてはちゃんと使えてないような…。
  • 自分がやるのが面倒な、文言変更とかを非同期型エージェントに頼みたい…。

第1章:GitHub Copilot 開発フローに自然に溶け込むサポート/エージェント機能……森下 篤

  • ひとことで
    • GitHub Copilotの使い方全般。
  • VSCodeのモード切替、知りませんでした…。ぐぬぬ…。
  • 著者がどうやってエージェントを使ってるのかは、めっちゃ参考になりました。
  • vscodeのソース管理を使うと、コードレビューしてくれるのか…!
  • エージェントモードと、コミット前のレビューを試してみます。
  • いやあ…まったく機能をわかっちゃいませんでした💦

第2章:Claude Code 思考・実装・改善を支援する対話型CLIツール……driller

  • ひとことで
    • Claude Codeでの開発の様子。
  • 実装計画を立てさせてどうするのかと思ったら…ファイルに記録させるのね…。
    • plansディレクトリに作業ブランチ名.mdとかにするぞ、とCLAUDE.mdに書いといたら、自由に参照しにいってくれるかしら…?
  • /compactで圧縮とかあるのか…。
  • ほかにもいろいろとファイルに書き出させてて…なるほどでした。

第3章:Devin 自律型AIエージェントの機能や活用方法を探る……山河 征紀、中野 誠

  • ひとことで
    • Devinの機能の紹介と実際のワークフロー。
  • セッションが長くなってしまったら初めからやり直したほうが早いそうですが、やり直すためのプロンプトを提案してくれるのはいいですね。
  • Devinが自動でコンテキストを収集するWikiがあるのはおもしろい…!続けて開発すると、精度が上がっていきそう。
  • 調査タスクも頼めて、しかもその調査結果を使ってコード修正にも繋げられるって…スゴイかも…。
  • 導入に向くユースケース、想像したまんまかも。人間があんまやりたくないのが並んでますね💦

第4章:Cursor AIと「協働」する包括的な開発支援の全貌……南部 豪

  • ひとことで
    • Cursorの機能の紹介と、作成過程の例。
  • これもプロジェクト全体の俯瞰機能を持ってるんですね…。
    • DevinのDeepWikiと同じタイプ。これを持っているツールを選ぶと使い込める感じがします。
  • エージェント的な動きをしてくれるのは…ここまでみんなそうなんですね…。
  • 運用調査かー!…ほしいなw

第5章:Amazon Q AWS開発のライフサイクルを加速するパートナー……森田 力

  • ひとことで
    • AWS内外で開発・運用を支援するAmazon Q Developerの紹介。
  • 会話が脱線しにくいような工夫のコンテキストフックはいいかも。
  • AWSコンソール内にいるのは絶対的な強みですね…。
  • Kiro…仕様駆動っていうのがめっちゃ気になります…。

第6章:Gemini Code Assist Google Cloud エコシステムに統合された開発アシスタント……野間 真拓

  • ひとことで
    • Google Cloud内外の開発・運用を支援するGemini Code Assistの紹介。
  • …無料枠が半端ない…。
  • データ保護・IP補償はいいですね。エンタープライズ向けにはめっちゃよさそう。
    • Amazon Q Developerもありました。

第2特集 あなたにもできる 怖くないオンコール対応、障害対応 基本動作と、精神的ストレスを軽減する方法……渡部 龍一

第1章:障害対応とその重要性 サービスの継続性と信頼性を守る最後の砦

  • ひとことで
    • 障害対応関連の知識をざっくり紹介。
  • 「信頼の損失」は数字で見える損失以上に回復が難しく …なんとなく感じてはいます💦
  • 復旧と恒久対応を分けて語るのは、自分もよくやります…。

第2章:障害対応の基本 障害検知から再発防止まで、健全かつすばやい対応のためのポイントを知ろう

  • ひとことで
  • 初動の「不確実性」を許容するのがなかなか…。優先事項は時間、とりあえず報告です!と何度も復唱しときます。
  • インシデントコマンダー…!ああ、アサインすればいいのかあ。
    • 手を動かす人がやると、判断がブレそうなのはめっちゃわかります…。
    • 今度からコマンダーを毎回お願いするようにします。
  • 初動5分のトリアージ
    • アプリリリース起因のときは考えないで戻しちゃう感じですね。
    • インフラ更新のときもそうかも。
    • いずれにしても、考えてあるのが大事かも。
  • ポストモーテム、できてないなぁ…。
  • ポストモーテム、「個人への責任追求」をしがちで、難しいですよね…。
    • やるなら、始める前のお約束を読み合わせるとかしたほうがいいかも。

第3章:障害対応をスムーズにまわす工夫 障害発生時に落ち着いて対応するための日々の取り組み

  • ひとことで
    • 障害対応をスムーズに回すための工夫。
  • 何度もやるなにかの作業は、自分も作業手順書を作っておくことが多いです。
    • 次回も自分がやるんですが…大概忘れてるんで💦

第4章:障害対応に前向きに取り組むために 苦痛な作業を意味ある挑戦へと変える発想の転換

  • ひとことで
    • 障害対応に前向きに取り組むための工夫。
  • Gamedayは…やってみたいけど、準備が大変そう…。
  • 最後にある書籍をチームみんなで読むとか、めっちゃありだと思います。

Appendix:AIを使った障害対応 緊迫した状況でこそAIによる補助が活きる

  • ひとことで
  • AI活用は…やりたい。ざっと指示するだけでログとかの該当箇所とか集めてくれたらめっちゃ助かるし…。
  • …一応、AWSのGuardDutyを入れているんですが…アプリにはないんですよね。ほしいw

短期連載

Javaバージョンアップ大作戦 【2】今からJava 17、21にバージョンアップする人のために……杉山 貴章

  • ひとことで
    • Java17、21の目玉機能と移行前作業、移行先バージョンの選び方、一般的な移行プロセスの説明。
  • 一気に移行するって…アリなのかなぁ…?

連載

ITエンジニア必須の最新用語解説 【203】TanStack DB……杉山 貴章

  • ひとことで
    • TypeScriptでデータを保存・取得をしやすくし、バックエンドのデータストアとの同期もできるライブラリ。
  • かなりよさそう。

万能IT技術研究所 【42】惑星落としで分かれた月が「地球を向き続ける」理由——1stインパクト後の月自転速度シミュレーション……平林 純

  • ひとことで
    • 月が常に同じ側を地球に向けている理由をシミュレーションから考察。
  • ベトナムの月餅を今年食べたんですが、中に卵の黄身の塩漬が入ってて、外だけじゃなくて中も月でした。

【新連載】現実世界を拡張するWebXRプログラミング 【1】WebXRの世界へようこそ!……にー兄さん(堤 海斗)

ドメイン解体新書 【22】Pi-holeで自宅ネットワークを可視化しよう(後編)……谷口 元紀

  • ひとことで
    • Pi-holeを使ってDNSクエリを可視化する記事の後編で、レコードタイプごとに簡単に解説がありました。

ネコ、コード、ネコ 【5】ネコグッズ……植山 類

  • ひとことで
    • 猫を飼うときに使うグッズと特に便利だったものについての説明でした。
  • 爪切りのときにマスクをすると大人しくなってくれるとは…知りませんでした。覚えておきます。

パッケージマネージャーNix入門 【3】Nix基礎——Nixのパッケージ記述とビルド……たけてぃ

  • ひとことで
    • Nixで開発環境を定義して、動かす話。
  • ウチでNixを利用しそうか?
    • 開発環境を定義して、開発者間で共有するのは大変夢があってよさそう。
    • …ですが、Nixの再現性へのこだわりが厳しすぎて、開発PCのOSのバージョンのバラツキを許してもらえなそうで…厳しそうかなぁ…。
    • とはいえ、期待しながらウォッチしつづける感じかも。

技術選定の舞台裏 【3】AIエージェント開発を支えるR&D基盤と技術選定……安井 大晟

  • ひとことで
    • AIエージェントプラットフォーム開発において、組織体制とアーキテクチャ構造などの選択とその理由。
  • www.aiworker.jp
  • 責務分担をちゃんとするほうがいい、というのは参考になりました。
  • LLMのまわりも、細かく細分化すればテストが可能というのも参考になりました。

【最終回】つまみぐい関数型プログラミング 【6】関数型プログラミング言語に触れてみよう……田尻 裕喜

  • ひとことで
  • …使ったことのない上にタイプの違う言語だと、目が滑る…。
  • 落ち着いて見ると、定義が並んでいるだけ、とも見えました。

Ruby×静的型付け戦略 【7】静的型検査を支えるRBS関連ツール……遠藤 侑介、栗原 勇樹

  • ひとことで
    • 静的型解析ツールTypeProfの紹介と動作原理の解説と、型検査周辺ツールの紹介
  • TypeProfで作って、steepでチェックして通ったらとりあえずリポジトリに入れちゃうとかすると、割とサッサと作れそう…。やらなきゃなぁ。

プログラミング×AIの最前線 【8】バイブコーディングによるプロダクト開発実践レポート③(完結編)……木下 雄一朗

  • ひとことで
    • バイブコーディングによる開発の完結編で、β版から本番リリースまでで行った工夫やふりかえり。
  • 長いセッションだと忘れちゃう……。人間だとあんまないと思うけど、LLMだと難しいですね。
  • 複数のLLMを使ったりするのはやっぱ、興味深いですね。
  • フィードバックループも……つい、AIに聞いてヨシとしちゃいがちですが、ちゃんと実行結果をもとにするのがいいのは…まぁ、人間でも同じですよね。

実践LLMアプリケーション開発 【26】DSPyによるRAGアプリケーションチューニング……西見 公宏

  • ひとことで
    • 複数のLLM呼び出しから構成されるアプリケーションの自動チューニングの紹介。
  • …確かに、個別のLLM呼び出しのチューニングはわかるけど、全体はスゴイかも。
  • 通常の機械学習のときと逆で、プロンプトベースの場合は過学習気味になるから学習データより検証データのほうを多くするとのこと……知らなかった、へええ。
  • 最適化後のプロンプト、なんかスゴイ…。自動でここまで変わるの…?うはあ💦

AWS活用ジャーニー 【37】Amazon EventBridge……杉金 晋

  • ひとことで
    • 様々なイベント送信元と様々な送信先を連携させるサービスのEventBridgeの紹介。
  • グローバルエンドポイントって昔からあったかしら…。障害に強くて、いいかもしれません。

はじめてのオフェンシブセキュリティ 【5】特権アカウントになってターゲットを掌握しよう!(Linux編)……皆川 諒、監修:株式会社エヌ・エフ・ラボラトリーズ

  • ひとことで
    • 侵入後に特権アカウントを奪取。
  • 侵入されたら即終わりではなくて、その後に特権アカウントを取得するという段階があると言われたら…確かにそのとおりで…。
  • OSを古いままにせず、普段からアップデートしておくと、こういったときにまた防ぐ手段になるというのがわかりました。
    linPEAS
    root権限奪取
  • lessをroot権限実行て…。

乱数のひみつ 【9】WebAuthnによる認証と乱数……荒木 誠

  • ひとことで
    • WebAuthnのしくみ
  • 機密情報を保存しないっていうのを、情報を保存しないと勘違いして、あれれってなってました。
  • サーバ側でユーザ情報に、ユーザの公開鍵を紐づけて保存してるんですね。そして公開鍵は公開だから機密じゃないと。

インターネットの姿をとらえる 【14】あなたの家のインターネットが遅いのはなぜか……土屋 太二

  • ひとことで
    • インターネット品質の指標とその見方。
  • インターネット品質の指標と、サービスカテゴリの関係が非常にわかりやすかったです。
    • そりゃ、レースや格闘ゲームの対戦は、帯域より遅延のほうが重要ですよね…。

魅惑の自作シェルの世界 【36】代入とコマンドの組み合わせ……上田 隆一

  • ひとことで
    • TZ=GMT dateでちゃんと標準時で出るようにしてる。
  • 変数をレイヤー化して、同じ名前の一番表層のものを使うようにしてたんですね…なるほど。

あなたのスキルは社会に役立つ~エンジニアだからできる社会貢献~ 【166】役割ベースでコミュニティの貢献を可視化~「Toban-当番-」が切り開く分散型運営の未来~……中尾 武

  • ひとことで
    • コミュニティへの貢献を可視化するTobanの紹介、活用事例
  • 実際に使われたプロジェクトの話もあって、ちょっと興味がある…。

その他

SD BOOK REVIEW

  • gihyo.jp
    • CTF形式の演習があるそうで…いいかも。

SD NEWS & PRODUCTS

  • アッ💦

プリンシプル オブ プログラミング 第6章のメモ

プリンシプル オブ プログラミング読書メモです。

第6章 手法 ~プログラマの道具箱~

6.1 曳光弾

最終形にも残る「骨格コード」

  • 全体の流れを早めに通して、狙いを確認する…ということでしょうか。
  • …普段からやってますが、全く意識してなかったです💦

暗闇の中で道筋を照らす

  • これは日々実感してます!

最初に動作する土台を作る

  • アジャイル開発で、常にリリースできる状態を保つ、のもこの考え方に近い?

プロトタイプとの違い

  • 違いは…目的と使用後かしら…。

プロトタイプは試供品と試作品

  • 破棄が前提、だとしたら、あんまりプロトタイプは作ったことがないかもしれません。

その他

  • 読み終わってから、普段動作ってるのか考えてたんですが…
    • ざっくり主題を作る(曳光弾)から、テストを書きながら細かいケアをしてく、TDD的な感じかも。

6.2 契約による設計

「呼び出し側」と「呼び出される側」の取り決め

  • これ、あんまり意識してなかったです。
  • どこにチェック機構を設けるか、について指針になっていいですね。
    • 呼ばれた関数は引数が契約に従っているかチェック
    • 呼んだ側は出力が契約に従っているかチェック
    • …これって、チームで共有してたほうがいい知識ですよね。

「思い違い」の早期発見

  • 早期発見…握りつぶしの反対ですよね。

コメントとアサーションで契約

  • 引数で渡された値を加工しない……今どきは普通にやってますね。
  • 関数のアサーションをそのままユーザの入力チェックに使うな…はそのとおりですね。
  • 入力を厳格にする…はテストをちゃんと書くことにしてると、自然にやりますね。だって書くの大変だもんw

クラス不変表明

  • 「クラスのオブジェクトは常にこういう状態でなければならない」という保証のこと…。
  • あんまり使ったことはないです。

アサーション(表明)

  • Rubyでは言語の機能としては持ってなくて、自作するんだそうです。

トラッシュよりクラッシュ

  • 同意。ダメなときは無理なリカバリをしない。

6.3 防御的プログラミング

「かもしれない」プログラミング

  • ifがあったらelseを常に気にかけるようにしてて、想定外を事前になるべく想定するようにしてます。

開発と運用の安全運転

バリケード戦略

  • わかるようなわからないような…
  • Railsでフォームなどから受け取ったユーザ入力にdirtyフラグがつけられてるようなもの?

アサーション(表明)とエラー処理の区分け

エラー処理におけるバリエーション

  • 確かにこのあたりの手を使いますね…。

エラー処理における「正当性」と「堅牢性」

6.4 ドッグフーディング

ソフトウェアの「味見」

  • 「味見」だとユーザっぷりが足りないような…。
  • 「自ら使う」だけだとちょっと足りないような…。
    • 「日常的に」とか入れたらしっくりくるかも。

ユーザーの視点を手に入れる

  • ユーザとしてちゃんと利用しようとすると、なぜか突然不具合や不便なところを見つけたりする経験がありますね…。
  • 社内システムの場合、業務内容の他に、社内行事などを通じてなんとなく人となりなどを知っておくと…ユーザになりきって使うことができるような気がしてます。
    • でも、デカい現場だと難しそう…。(昔を思い出して。)

自分でユーザーのように使う

  • そりゃそうですねえ…。
  • 自社サービスを使って、ユーザから資金を集めたこともありましたが、これもドッグフーディングですよね。
  • 一方で、サービス運営者・作成者との視点も混ざって持っているので、純粋なユーザではないのはちゃんと気をつけてたほうがよさそう。

6.5 ラバーダッキング

「説明する」というデバッグ

  • 誰かに説明すると解決する、というのを人を使わずにもできるってものですね。

自己解決を促す

  • プルリクエストのセルフレビューのときに、将来何か必要になったときに読まれることを想定して、コメントを残していくときに、ある意味デバッグになってると思ってて…やり始めてから結構コードがよくなった気がしてます。

無機質に説明

  • 同僚はたしかに一番いいけど、いないときもありますもんね。
  • 自分はChatGPTを相手にしてることが多いかも💦

その他

6.6 コンテキスト

「文脈会話」「文脈思考」

  • モジュール名とかクラス名はコンテキストといっていいんじゃないかしら…?
    • だから変な名前をつけるとおかしくなっちゃうというか。

会話や思考を迷子にしない

  • 達人はパターンを知ってるだけじゃなくて、その活用場所を決められるから、というのはそのとおりだと思う…。

コンテキストを示す

  • コンテキストを示す、というのは、モジュール名、クラス名、メソッド名を決めてから書く、みたいな?

コンテキストと作業依頼

  • これ、じゃあどうしたら…。
    • 初心者には事細かに指示し、熟練者には目的を指示するのはわかったけど…中間は?

コンテキストの伝導能力

  • この実験、おもしろいですね。ノンセクションめっちゃ時間かかりました💦

チームはハイコンテキスト志向で

  • そうですね。

コード共通化はコンテキスト志向で

  • まぁ…コンテキストの違うものは似てても違うものですよね。

プログラマコンテキストスイッチ

  • 最近は擬似的な別人になるために、考え事をしているときにわざと中断して、コンテキストスイッチを起こしてます。少し冷静になれる気がしてます。

「システム・シンキング」とドメイン駆動設計

  • めちゃ長い…。

「フロネシス」と全体最適

「関係主義」と障害対応

  • 境目に不具合が起きやすい、みたいな感じですかね?