読書ノート - 人月の神話

人月の神話の読書ノートです。

正誤表

本書の正誤表は公開されていません。

ノート

第1章

• プログラミングシステム製品という言葉はかなり古臭い気がする
  • パッケージ製品という概念が生まれる前の時代、古い本だしそこは仕方ない
  • 話の本質は図1.1
• 図1.1
  • プログラミングだけで見積もると失敗するよという感じ
• 作る喜び
  • 現代では、プログラミング好きで書いてる人と、単に職業的に書いてる人がいる気がする
• 作る苦しみ
  • 完成時に時代遅れに見えてしまうことって現代ではそんなに激しくないような。技術の成熟度が今と昔では全然違うと思う
  • アジャイルのプラクティスは解決策では

第2章

• 大規模開発ですべての仕事がうまくいく確率は限りなくゼロに近い、というのは、ウォーターフォールだと特に顕著だね
  • 製造業では「自工程完結」という言葉もあるが、ソフトウェアで完全にやることは困難
  • 参考1 「アジャイルは死んだ」以降に残るものは何か -リーンソフトウェア開発を再評価し、自工程完結で全体観点で改善する
  • 参考2 アジャイルかウォーターフォールか、どちらが品質を「保証」できるのか -トヨタの自工程完結に学ぶソフトウェア開発

• 現代 (単体テスト自動化の時代) では、コーディングフェーズに単体テストもくっつけるかな

• スケジュール変更、Web ではリリース後に更新していくとかできるので選択肢 4 がやりやすい

第3章

• 現代の巨大プロジェクトとは
  • 青い銀行とか・・・
  • コピー機のソフトウェアもけっこうでかい
  • ゾゾタウン 100 人かきあつめとか・・・ (参考: ZOZOTOWN作り直しにつき「40名」のエンジニア求む！ - 株式会社スタートトゥデイ工務店)
• ミルズの案
  • 今はパンチカードもないし自動化も結構されてるしここまでの体制は不要かな
  • 執事もいることだし (Jenkins)
• 大規模化
  • ペアプロなどでスキルの平準化とかするとよい (ペアプロで伸びそうな人ちゃんと取らないといけない)
  • 「アーキテクチャとインプリメンテーションを厳密に区別することが必要」というのは具体的にどういうことだろうか？
  • 実装の詳細にとらわれず全体を俯瞰できるようにしとけということかな？

第4章

• コンセプトの完全性
  • 今でいうプロダクトマネージャみたいな
  • 言われたとおりにどんどんいれてあふれるというか、プロダクトとしてのポリシーに照らし合わせてはじくとかできない
  • ノルマン建築・・・ロマネスク様式の一派
  • 最初からコンセプトを確立することは結構難しい
  • デザイナーとしてはコンセプトを確立させてから作りこんでいくトップダウンな感じ (貴族政治)
  • トップダウンでいきわたらせるにはリーダーシップもいる

第5章

• 自制心
  • 散々セカンドシステムの症例を散々語って解決策は自制心を高めろ、以上、ってちょっとなげやり。
  • リプレース案件あるある。
  • コンセプトの完全性も大事。
  • 「動的メモリ」割り当てって (CPUコアの話ではなく) コアメモリのことだよね。コアダンプとかもいってるし。
  • 自制心とは、爆発しないようにすることかな。

第6章

• 記述された仕様書としてのマニュアル
  • 「ブラーウのシステム/360解説書の付録」見てみたい → これか？ A22-6821-7_360PrincOpsDec67.pdf
  • 「なにができるか」を書くのはかけるけど、「なにができないか」を書くのはすごい難しい
  • お客さんの立場でどう使うか想像しつくさないといけない
• 形式的定義
  • BNF って読みづらいよね・・・
  • 「動いているのが仕様」は避けたい
• 複数インプリメンテーション
  • これやるのは難しい
  • マニュアルが負けるようじゃダメな気がする (統制がとれなきゃダメ)
• 製品テスト
  • 「重箱の隅」「悪魔の代弁者」この書きっぷり、ブルックスさんも QA とバトったのかな？

第7章

• バベルの塔の管理監査
  • 様々な要因は満たしていたのに失敗した->それはコミュニケーションがきっちりできていなかったからです
• プロジェクト手引書
  • 差分の見方　現在はオンラインに手引書等を置くことができるので、ちょっと古いかな
  • 校正の管理がされていない文章の話ですね
  • 実際、Word・Excelで文書を作っている場合にはココに書かれているような管理方法になる
• 大規模プログラム開発プロジェクトにおける組織
  • マネージャー＝アーキテクトのパターンは負担が結構重くなる
  • マネージャーが上司　アーキテクトが右腕の場合が多い かな？
  • アーキテクトが上司　マネージャーが右腕のパターンは余り見ないかも

第8章

• 予告宣告する
  • すごい規模のプロジェクト、どう思って調べるに至ったのか
  • 行数、ワード数、命令数とかで測っているけれど、この時代はライブラリとかも満足にない状態だから、プログラムの規模と一致するはず。この時代でもこれだけ見積もり大変だったってことか
  • 言語翻訳プログラム＝アセンブラ？
  • 図8.3/8.4の「プログラムサイズの月間予測数」ってなんだ？予測した生産性？にしてはグラフが妙に細かい

第9章

• コストとしてみたプログラムスペース
  • 「プログラミングシステムを大きさそれ自体で避難することはだれにもできない」これ組み込み屋はかなり共感かも
  • コスト問題というところは、今ではクラウドの課金がそれに近い気がする。特に GCP
• サイズのコントロール
  • 「トータルシステム的な利用者志向の心構え」大事だと思った
• スペースに関するテクニック
  • 現代のプログラミングではここまでの職人技に頼る機会は減ったと思う
  • メモリスペースと時間のトレードオフとか基本的な概念は今でも変わらないけれど
• 表現はプログラミングの本質である
  • クヌースさんといえば The Art of Computer Programming だよね
  • インタプリタのインタプリタでなぜ小さくなるのだろう？ → 高級言語を作っているとか
  • そもそも「操作卓」とは → 写真がある IBM 1130 - Wikipedia

第10章

• なぜ、形式の整った文書が必要なのか？
  • マネージャー (それもかなりハイレベルの) 視点
  • コンウェイの法則持ち出している
  • 文書 (チェックリスト) がどんどん肥大化していってつらい
  • KPT の管理とかもちゃんとマネージしたい
  • 本書では触れてないけれど、文書のバージョン管理も今では常識

第11章

• パイロットプラントと大規模化
  • スケールアップに関しては、負荷テストとかはやったりするけれど・・・
  • システム移行なら平行稼働で実環境での運用経験は積めたりする
  • オペレーターの誤った入力とかも実環境でしかありえないよね
  • なぜ捨てる必要があるのか？改良すればいいんじゃないか
• 不変なものは、変化そのものだけである
  • アジャイルに通じる話だ
• 変化に備えた組織計画
  • 管理という仕事がより高い権威を伴っている場合＝社会的障壁なのかな
• 1歩進んで1歩さがる
  • プログラムの作成はエントロピーを減らす過程、メンテナンスは増大する過程という説明は面白い
  • メンテナンスは必ずしも増大する過程ではないような。ボーイスカウト原則、リファクタリングが一般的な現代ではチームの問題な気も

第12章

• 高水準言語
  • 今は言語も IDE もセマンティクス上のエラーの検出はかなり高度になっている
• 対話型プログラミング
  • ライブラリ・フレームワーク等充実している現代のプログラミングとは生産性を比べづらい

第13章

• バグを取り除くデザイン
  • 仕様書をテストする・・・形式手法の話ではない
  • 身内レビューではなく、テスター等のレビューが必要、V字モデル
  • GOTO 全滅派、間違ってない気も。ラベル付き break とかも return にリファクタリングしたほうが良い
• システムデバッグ
  • ダミーコンポーネント・・・今でいうモックやスタブかな
  • 変更を統制する・・・変更管理、今はバージョン管理システムの役目

第14章

• スケジュール管理
  • 昔も今も課題変わらないね
  • 後半にハッスルプレイが出てくるけれど、結局根性論か！？
  • モチベーションでパフォーマンス大きく変わるからね
  • 野球の監督は選手選べるけどソフトウェア開発の現場は・・・
• マイルストーン・ミルストーン
  • 具体的かつ明確で測定可能なイベント・・・アジャイルでも同じ
  • マイルストーンの粒度も大事、でかくすぎると危険
  • 調査期間を長めにとって落とし込むとか
  • プロトタイピングをしっかりやるとか
• じゃうたん
  • 上司とマネージャーの話があるが、お客と開発とかでもこういうこと起こる

第15章

• どんな文書が必要か？
  • プログラムを使用するために・プログラムを信用するために に書いてあることは現在でもほとんど通用する
• 自己文書プログラム
  • 図15.3 は(特に⑧)現代ではやりすぎでは？

第16章

• 摘要
  • 「購入できるものをあえて構築しないようにする」の購入って、今ではオープンソースの利用とかも入るかな
• 本質的な困難
  • 複雑性: ソフトウェアを設計するのは本質的に難しいことなんだと
  • 同調性: 日付時刻APIの複雑さとか見ると、人間が生み出した複雑な仕組みへ同調する難しさを示してる気がする
  • 可変性: ハード変更のとばっちり受けたりとかね！
  • 不可視性: 例外とかも含めると相当なものになる
• 今までの戦略的突破
  • 高水準言語: 低水準言語と比べれば確かに飛躍的だ
  • タイムシェアリング: リソースを物理的に独占していた時代と比べれば確かに飛躍的だ
  • 統一されたプログラミング環境: 似たような開発等を繰り返さなくてもよくなったのは飛躍的だ
• Ada とその他の高水準言語の進歩
  • 軍事関係ではまだ使われているみたい
  • 証明支援システム Idris はポスト Ada を狙っているらしい
• オブジェクト指向プログラミング
  • 著者は期待しているといっている、先見
  • 今ならドメイン駆動として発展もしている
• 人工知能
  • 知能ってなんだ？→哲学の世界
• エキスパートシステム
  • 第一次AIブームだ
  • 言葉は聞かなくなったが、アイデアは生きてる
  • BRMS (ビジネスルール管理システム) のもと
• 「自動」プログラミング
  • 仕様を与えるとコード生成してくれる製品いくつかあったような
  • ソフトウェアの複雑さを DB に押し付けられる類のものならある程度使えるという話も
• ビジュアルプログラミング
  • Scratch 等、教育用途では実現されている気がする
  • コレグラフは使いづらい・・・
  • Apient 面白い、Node-RED も
• プログラム検証
  • そうかこの時代は Coq もまだ登場してないのか
  • Caf… OBJ ファミリーは歴史が古いみたい
• 環境とツール
  • 冗長な作業はじゃんじゃん自動化したい
• ワークステーション
  • さすがにこの節の話は古すぎかな
• 購入対自主製作
  • 今なら OSS も
  • 評価するソフトとか
  • 勤怠・給与内製化とかちょっとあれだよね・・・
  • PaaS とかも購入に含まれるよね
• 要件の洗練とラピッドプロトタイピング
  • 1986年で既にこれが提唱されていて、一方現代は・・・
• 漸増的開発 - ソフトウェアを構築ではなく、育成する
• 偉大なデザイナー
  • 偉大なデザイナー＞＞＞優れたデザイナー、優れたデザイナー10人集めても偉大なデザイナーにかなわない
  • ソフトウェアの芸術的な側面かな
  • マネージャーとエキスパートを同列に扱うべしという話にもつながっているね
  • 図16.1 ・・・これは論文に載せるようなものなのか (笑

第17章

• 銀の弾は実在する - これがそうだ！
  • 君たちまだまだ若いなぁみたいなノリ
• 偶有的事項
  • 「副次的とか付随のとかいう意味で使っていた」
  • アクシデンシャル→偶有的・・・訳も難しい
• 困難が「本質的」なら、「希望はない」のか
  • 難しいとは言ったが、無理とは言ってない (ｷﾘｯ
• 複雑性はレベルによる
  • 「きわめて楽観的に考えている」は言い過ぎだが、確かに語っている
• ハレルの分析
  • 「カレンダーについてのあなたの概念的モデルについて聞かせてください」むずい
• ジョーンズの要点
  • 生産性？品質？
• では生産性はどうなったのか？
  • トム・デマルコ、ピープルウェアの人だ
• シュリンクラップされたソフトウェア
  • シュリンクラップとは・・・シュリンクラップ契約 “シュリンクラップ” 云々は単に洒落た言い方をしてるだけかな
• 頭脳の電動工具
  • マイクロソフト Works ・・・オフィスの前身かな？
  • カスタマイズ性大事・・・開発環境とかも
• オブジェクト指向プログラミング
  • デザインよりツールが先行してしまった
  • “真の勇気を必要とする” ね・・・
  • フレームワークは再利用の塊みたいな感じもする
  • フレームワークを適用させる辛み・・・現代の悩みかな

第18章

命題/第1章

• ほんとに3倍*3倍になってる？
  • 派生開発ばっかりなので当てはまらないかも(intptr-t)
    • どこをベース（流用元）を持ってくるかに依存する
• プログラマじゃない人にプログラミングを教えている。プログラミングに試行錯誤は当然だと思うが、失敗が苦痛だと感じて、正解を教えてもらいたがる人が多く感じる(MrBearing)

命題/第3章

• 大げさすぎないか？(MrBearing)
• 大規模プロジェクトでどうしても多くの人員が必要になる場合、人手と設計などのコアに関わるメンバーを最小限にするのを両立させるためには有効な手段なのでは？やったことないけど(LagunaPresa)

命題/第4章

• お客さんありきの仕事だと、コンセプト決めるのはやはりお客さん。n重受けとかだと本当のお客さんにコンセプトを聞くことは現実的にできず、むずかしい(intptr-t)
  • そういう構造はこの本の時代にはなさそう(MrBearing)
  • 例えば他の業界(建築)だと、多重受けになってもコンセプトが確立していて失敗しにくそう(MrBearing)

命題/第5章

*5.4 Windows NT が OS/360 のにのまえね・・・(Windows → Windows NT)

• OS/360 も Windows NT もセカンドシステム症候群かもしれないが、技術的には大きく貢献している気がする

命題/第6章

• 6.6 WIMPインタフェースの例がこことどうマッチしているのかはちょっと読み解けない
• 6.8 電話より E-mail 大賛成！
  • 公表するという意味では (電子) 掲示板のがベターかも
  • Jive とか Salesforce Chatter とかもあり

命題/第7章

• 7.8 物理媒体回し読みの時代ではないよねってことかな
• 7.15 パルナスは遮蔽推進派、ブルックスはさらけ出し派だったが、遮蔽推進派になったとのこと

命題/第8章

• 8.4 最初に書いた100行より後からつけたす100行のほうがずっと労力かかる

命題/第9章

• 9.9 バラ売り → パッケージ化で販売コストが下がるのはそうかも？
• 9.9 そもそもパッケージ化の話って 9 章にあったけ・・・
• 9.10 容量は広がったが速度に関してはどうだろう・・・ → でも SSD はブレイクスルー、キャッシュも大きくできる
• 9.13 確かに今はわざわざ全機能版どかっとでいい
• 9.13 Java EE はでかいからコンパクトなのがあるのは嬉しい・・・(笑) MicroProfile など
• 9.16 「表現はプログラミングの本質」の表現って、もとの英語では何だ？

命題/第11章

• 11.2 ベータバージョンのテストは、リリース直前のテストであることが多く、本章の捨て石とはだいぶ違うものだが・・・
  • ベータテストの結果、(機能などを) お釈迦にすることはあるかな、その場合は捨て石に近い効果があるかも
  • ベータ版がダラダラ続く系は意味違うよね (クオリティの予防線みたいな)
• 11.11 「テーブル駆動」って本文にも出てきたけど何のことかよくわからない
  • 文脈的に (今日の) データ駆動 (設計) の話ではなさそう
  • 構造化プログラミングの出来損ない？goto 文の一覧表を作る的なものかもしれない
• 11.13 明確な番号のついたバージョンね・・・今は Git がある！
• 11.29 どう頑張ってもシステムが腐っていくのを (遅らせることはできても) 防ぐことはできない・・・夢がない内容だ・・・
  • 小手先のリファクタリングだけではなく、大規模なリファクタリングもしていく必要がある

命題/第12章

• 12.13 たしかに、ここ数十年で高水準言語はとても発展した
• 12.16 PL/1 は終わった
• 12.17 バッチは必要。計算処理がすごく向上すれば減るかも

命題/第13章

• 13.4 Stepwise Refinement を「段階的洗練法」と訳しているが、「段階的詳細化法」のほうが一般的
• 13.9 端末セッションの話は現代ではちょっとミスマッチな気も
• 13.13 その前に単体テストしっかりやっとこうね！
• 13.17 この議論は今でも盛ん、たとえば稼働中のサービスにどれだけリリースあげていくかとか
  • フレームワークのアップグレードとか
  • 頻繁なリリースはオペレーション側のサポートも重要
  • 製品・要求品質による使い分けが重要

命題/第14章

• 14.7 チームで遅れてると、自分も遅れても影響薄いしってなることも
  • 異常な状態が続くと慣れてしまうという話ともつながる

命題/第15章

• 15.10 MILSPEC は例外系への要求レベルが高いから仕方ない気もする
  • 医療系とかもね
  • コードよりもフローチャートのほうが例外系目立つ気はする
  • 特許の申請のときフローチャートめっちゃ書いた (擬似コードとか読んでもらえない)
  • ソフト開発のためにフローチャートを書くことはないが、他人に説明するためには必要

第19章

• なぜ、20周年記念版を出すことにしたか
  • 名著は陳腐化しないよね
• コンセプトの完全性とアーキテクト
  • Mac 持ち上げはじめたぞ・・・
  • この頃 (1995) はまだ Windows 最強伝説は半ばだったのかな
• アーキテクト
  • 専任アーキテクト大事
  • ばしっと決めてくれる人がいる、寄せられる
  • 部署またがって開発していると完全性が途切れやすい、管理画面のデザインがバラバラだったり・・・
  • 命名規則が違っていたり・・・
  • 組織構造も変えないと・・・コンウェイの法則にも通ずるかも
• アーキテクチャを、インプリメンテーションと実現から分離すること
  • 境界線はどこ・・・
• アーキテクトの再帰的方法
  • アーキテクトがアーキテクト達の構造を・・・
  • ドメイン境界がはっきりしていないときはうまく分担できないような
  • 捨石にすればいいのだ (笑
• セカンドシステム症候群…
  • 「利用者群」←直訳感ある・・・
• 度数
  • 新機能のユーザー投票とかやってるとこあるよね
• WIMP
  • 20 年以上たったけど WIMP はまだ歴史的遺物にはなってないぞ！
  • スマホのタッチ UI はポインティングは変わっているけれど
• ウォーターフォールは間違いだ！
  • そもそも捨石にする必要があるのはウォーターフォールのせい
• 漸増的構築モデル
  • 全部つながるのは一番最後 → 最初につながる土台をつくる的？
• 漸増的構築とラピッドプロトタイピング
  • プロトタイピングはアーキテクチャとか考えないが、漸増的開発はアーキテクチャに基づく
• 情報隠蔽
  • 情報隠蔽には適切に定義されたインターフェースが不可欠
  • 継承よりコンポジション、この時代ではギリギリまだか…
  • カプセル化 (隠蔽) といってるのは、アクセス修飾子の話かな
  • ポリモーフィズム、カプセル化のそれぞれ単体はオブジェクト指向登場前からありそうだけど、当時ごっちゃになってる可能性ある
• 人月はどの程度神話的なものなのか？
  • 「完了をつねに遅らせるわけではない」というのもその通りかも
  • 「ピープルウェア」絶賛
• 諦める力の力
  • 権限委譲大事というお話
  • 裁量を与えつつ、責任まで丸々押し付けられるとどうかなとは思う
• 最近あった最大の予想外の事件：コンピュータの普及
  • 今だとスマホだな
  • 我々にはターンアラウンド時間など気にする時代が想像し難い
• 全く新しいソフトウェア産業 - パッケージソフトウェア
  • 第4世代言語とは・・・ PL/SQL などの手続き型言語の次の世代の言語の総称らしい (参考: 4GL)
  • ベンダーロックインの良い道具になってる気もする・・・
  • クラウドに最適化した 4GL アプリケーションを開発してデプロイする ← 3GL と 4GL がごっちゃになってるような・・・
  • 結局昔のバズワードなのかもね
  • OS の種類はさらに収斂してる (DEC とかないし)
• 購入して構築する - パッケージソフトをコンポーネントとして
  • メタプログラミング・・・純粋に高位ロジックという意味かな
  • 何でも実行できても結果がテキストで返ってくるだけじゃセンスないよね
• ソフトウェアエンジニアリングの現状と将来
  • ソフトウェアエンジニアリング特有の課題がある、銀の弾丸はない

エピローグ

• 昔は雑誌とか学会も規模が小さかったってことか
• なんと素晴らしい苦境であることか！