---
title: マンガではわからない ソフトウェア開発の真理
tags: 
author: [Hisateru Tanaka](https://www.docswell.com/user/tanakahisateru)
site: [Docswell](https://www.docswell.com/)
thumbnail: https://bcdn.docswell.com/page/KYJ6PWQ7VZ.jpg?width=480
description: PHPerKaigi 2021 のセッションのスライドです
published: March 28, 21
canonical: https://www.docswell.com/s/tanakahisateru/MK3LE5-2021-03-28-123202
---
# Page. 1

![Page Image](https://bcdn.docswell.com/page/KYJ6PWQ7VZ.jpg)

マンガではわからない ソフトウェア開発の真理

# Page. 2

![Page Image](https://bcdn.docswell.com/page/5GJ5KM2E48.jpg)

所長 たなかひさてる @tanakahisateru

# Page. 3

![Page Image](https://bcdn.docswell.com/page/4LE3ZW1E5P.jpg)

20年以上前の古典をマンガにしました 2019 2020 マンガでわかるデザインパターン マンガでわかるアンチパターン (1994) (1998)

# Page. 4

![Page Image](https://bcdn.docswell.com/page/V8EDRKKJGD.jpg)



# Page. 5

![Page Image](https://bcdn.docswell.com/page/4V7PWK3J86.jpg)

人月の神話 〜狼人間を撃つ銀の弾はない〜 新装版 (銀の弾がぬけてて残念な表紙)

# Page. 6

![Page Image](https://bcdn.docswell.com/page/L2JV8VNJQW.jpg)

人月の神話 外科手術チーム アンチパターン デザインパターン 銀の弾はない 本質的困難さと偶有的困難さ

# Page. 7

![Page Image](https://bcdn.docswell.com/page/Z5EG5L5ELR.jpg)

人月の神話 フレデリック・P・ブルックス ソフトウェアの設計と開発に関する原典じゃないかな • IBM System/360 の OS を作った経験にもとづくエッセイ集 • ハードウェアコストのためウォーターフォールが当然だった時代 • ブルックスの法則「遅れているソフトウェアプロジェクトへの要 員追加は、プロジェクトをさらに遅らせるだけである」 • ソフトウェア・アーキテクチャという言葉を最初に使った

# Page. 8

![Page Image](https://bcdn.docswell.com/page/V4JQZYLJP5.jpg)

1975年 初版

# Page. 9

![Page Image](https://bcdn.docswell.com/page/DK743W5E1Q.jpg)

1975〜1976年のできごと 私達が知っているコンピューターが初めて世に出た時代 • BASIC を搭載した事実上初のパソコン、アルテア 8800 発売 • ジョブズとウォズニアックが Apple I を開発 • Z80 CPU の登場 • 田中ひさてる爆誕

# Page. 10

![Page Image](https://bcdn.docswell.com/page/PLJ11Y2JGD.jpg)

それから 20 年… 1995年 改定第2版 現在普及しているのはこの版のほうですね

# Page. 11

![Page Image](https://bcdn.docswell.com/page/8GJW8G2726.jpg)

1995年前後のできごと インターネットというコンピューティングの大転換 • GoF デザインパターン • Windows 95 発売 • Java や Ruby の登場 • 我らが Personal Home Page Tools のソース公開 • 田中ひさてるプロデビュー

# Page. 12

![Page Image](https://bcdn.docswell.com/page/W4EZ8L4J3Y.jpg)

1995年以後 〜近代的なウェブ開発のスタイルまで • アンチパターン 1998 • SOLID 原則 2000 • アジャイルソフトウェア開発宣言 2001 • テスト駆動開発 2002 • ドメイン駆動設計 2002 ← ここ重要 • (Ruby on Rails 2003 〜 ひとつの時代の終焉)

# Page. 13

![Page Image](https://bcdn.docswell.com/page/KY76PWGEVZ.jpg)

人月の神話 外科手術チーム 〜 アンチパターンとの関係

# Page. 14

![Page Image](https://bcdn.docswell.com/page/5G75KMXJ48.jpg)

ブルックスの法則 人数と時間は交換可能ではない • 主流だったウォーターフォールが間違っていることは 75 年時点 ですでに示されていた • プログラマーを追加可能で均一な労働リソースと考えるな • 産業の理論: 後の工程ほど誰でもできる作業になる ←→ ソフトウ ェア開発の妄想 • IT では最終工程の労働力がコンピューター → 考えたらわかる

# Page. 15

![Page Image](https://bcdn.docswell.com/page/V9J2W9QERX.jpg)

外科手術チーム プログラマーは工場労働者より医師に近い職業 • 高度なソフトウェアは人体のように複雑 • 専門的な知識と患者の病状理解が必要 • 執刀する主治医と助手数名の精鋭チーム + 看護や事務など • アーキテクチャ設計、モジュール実装、テスト(当時は手動)、文 書化、その他雑務… 外科手術同様、まったく均一な労働ではな い • にもかかわらず、人月の神話を信じる考えなしの人が増えた

# Page. 16

![Page Image](https://bcdn.docswell.com/page/5DEYL4YJM9.jpg)

アンチパターン: 偉大なるヨーク公 技能の不均一さについて改めて • ヨーク公 = すべての民衆を公平に扱った立派な王様 • …でも公平さはソフトウェア開発を失敗させる • 優秀なプログラマーは少なく、凡庸なプログラマーは超多い • 全員の意見を公平に採用すると、優秀なプログラマーの意見が、 思慮が浅くそれを理解できない多くの人に潰さる • というように、他のアンチパターンの多くも、失敗原因の本質が 思い込みや思考停止だと説いている

# Page. 17

![Page Image](https://bcdn.docswell.com/page/2VJN4YRE8K.jpg)

アジャイル宣言(超訳) 思考停止やめよう運動 • 個人と個人で理解 > 組織的管理手法で • 動くプログラム > 仕様書に全部書いてある • いっしょにがんばる気持ち > 自分だけ損したくない気持ち • 計画は柔軟にね > 最初に言ってたとおりにしかできません • 右は組織の理論による思考停止の正当化 = すでにアンチパターン ですべて問題提起されていた

# Page. 18

![Page Image](https://bcdn.docswell.com/page/GYE9QPZE3P.jpg)

ていうかブルックスは すでに語ってた

# Page. 19

![Page Image](https://bcdn.docswell.com/page/5GE8GXYEDR.jpg)

銀の弾はない 本質的困難さと偶有的困難さ 〜 デザインパターン

# Page. 20

![Page Image](https://bcdn.docswell.com/page/MLELG897R1.jpg)

偶有 vs 本質 • 偶有 • コンピューターの都合で仕方なく必要という意味 • エラー処理、メモリ上限、通信速度… 昔は厳しかった • 本質 • 偶有的な問題をすべて取り去れたとしてもまだ残る部分 • コンピューターを使って解決したい問題そのもの • 時代とともに偶有的困難さは減り、より本質が求められるだろう

# Page. 21

![Page Image](https://bcdn.docswell.com/page/54JMQ6VEW1.jpg)

デザインパターンで理解 疑問: GoFはなぜこんな構成で書いたのか • 「生成」「構造」「ふるまい」の順に書かれている • 生成: AbstractFactory / FactoryMethod / Prototype • ふるまい: Strategy / Iterator / TemplateMethod • 「ふるまい」から先に教えたほうがわかりやすいのに ← NO • OOP の基礎 = 使用と生成の分離 • デザパタはその構成全体でこれを語っている

# Page. 22

![Page Image](https://bcdn.docswell.com/page/ZPJR8PWE9L.jpg)

思考実験: 仕様書とコードの if 比 • コードには仕様説明にない大量の if 文 • 場合の組み合わせが人間の理解を超える → バグ • 要求の元は人 → 本質的に必要な分岐は人が理解できる数のはず • 多くの if は偶有的な条件分岐だ • これを減らすには? → オブジェクトの多態性を活かした判断の前 倒し (ブルックス 1995 OOP = 真鍮の弾丸かも)

# Page. 23

![Page Image](https://bcdn.docswell.com/page/NPEX83V7XY.jpg)

使用 DatabeseDriver query() MySQLDriver PostgreSQLDriver 適切なドライバを1回だけ new するだけで 生成 毎回どっちの DB かで if しなくて済む

# Page. 24

![Page Image](https://bcdn.docswell.com/page/63EKKY5EDY.jpg)

デザパタ = 偶有的関心のコレクション • 抽象による詳細の if 隠蔽こそが OOP の本領 • OOP ができているとき、使用と生成の境界が必ずある • つまり生成は最重要な偶有的関心、構造やふるまいは派生物 • パターンは記述するより認識するほうが大事 • パターン名で偶有的困難を抽象化し、分けて考えることで本質が 残る

# Page. 25

![Page Image](https://bcdn.docswell.com/page/4L73Z9175P.jpg)

そして裸になった本質 固有の問題=ドメインモデル • 「銀の弾はない」 = いくらデザパタ等で偶有的な問題を分離して も、本質的な問題自体は消えない • 現在は70年代と比べれば偶有的困難は明らかに少ないが、いま だにソフトウェア開発は難しい (ツールを使う難しさなんて、ツールがなかった頃の難しさの比じゃないので無視) • なぜなら: 本質的困難さ、つまり、妥当なドメインモデルをデザ インする難しさが絶対になくならないから

# Page. 26

![Page Image](https://bcdn.docswell.com/page/V87DRGKEGD.jpg)

やっぱりブルックスは すでに語ってた

# Page. 27

![Page Image](https://bcdn.docswell.com/page/4VJPW33E86.jpg)

我々は45年間 ブルックスの世界で 同じことを続けている のではないか…

# Page. 28

![Page Image](https://bcdn.docswell.com/page/L2EV84NEQW.jpg)

? 正しいソフトウェア開発のかたちとは?

# Page. 29

![Page Image](https://bcdn.docswell.com/page/Z57G5157LR.jpg)



# Page. 30

![Page Image](https://bcdn.docswell.com/page/V4EQZDLEP5.jpg)

グレゴリーのダルメシアン Gregory R (1970) "The intelligent eye" McGraw-Hill, New York (Photographer: RC James)

# Page. 31

![Page Image](https://bcdn.docswell.com/page/DKJ43Z571Q.jpg)

経験による知識 → 実在しない輪郭線が見える

# Page. 32

![Page Image](https://bcdn.docswell.com/page/PLE11R2EGD.jpg)

人月の神話 (75) 銀の弾 経験 ? 経験 経験 外科手術 わかる人にはこれで十分

# Page. 33

![Page Image](https://bcdn.docswell.com/page/8GEW812J26.jpg)

しかし「プログラマーの経験」の現実は… 怠慢 誤った 教育 失敗体験 未経験 「文字は読めるが意味がわからない」状態 輪郭を認識した人と初見の人では全然違う

# Page. 34

![Page Image](https://bcdn.docswell.com/page/W47Z8P4E3Y.jpg)

人月の神話 (95) オブジェクト指向 デザインパターン アンチパターン ? より狭いフォーカスで具体的な例を大量に ダウンサイジング 開発者人口の増加

# Page. 35

![Page Image](https://bcdn.docswell.com/page/KYJ6PMG7VZ.jpg)

でも情報量がいくら増えても、輪郭線を直接表すことはできない ドメイン駆動設計 銀の弾 ? アンチパターン これでもまだ デザインパターン アジャイル 外科手術

# Page. 36

![Page Image](https://bcdn.docswell.com/page/5GJ5KZXE48.jpg)

? なぜなら

# Page. 37

![Page Image](https://bcdn.docswell.com/page/V9E2WRQ7RX.jpg)

輪郭を引くのは経験知識 = ダルメシアンを知らなきゃ無理

# Page. 38

![Page Image](https://bcdn.docswell.com/page/5D7YLDYEM9.jpg)

マンガでわからない真実 • マンガ = もちろん最強の紙媒体 • 絵ですぐ登場人物を通して感情移入 → 共感できる • が、そもそも共感のもとになる経験は表現できない • 経験 = 反復の中で少しづつ間違えながら学習し得られるもの • スポーツでいうと「頭で理解しようとするな体で覚えろ」

# Page. 39

![Page Image](https://bcdn.docswell.com/page/2VEN46R78K.jpg)

反復訓練の重要さを表した画像 遺伝的アルゴリズムの進化 = 言語化されない経験 これいま面白いと思えるかも経験ですよね。説明しても面白くない。

# Page. 40

![Page Image](https://bcdn.docswell.com/page/GY79QLZ73P.jpg)

真理は開発者の 経験の中にある コード書こう 巨人の肩に立つには自分の足が必要だよ