使いやすさの指標
- 使いやすさ＝Gain／Cost
- Gain：機能を利用することで得られた時間
- Cost：機能の使うために失われた時間
- Costの例は、マニュアルを勉強したり、覚えたり、探したりするのにかかった時間である。
- 単に機能が多いだけで、それらを使うためのCostが大きいならダメ。
- 単純（simplicity）な機能構成になっていても、機能要素を複雑に組み合わせないとやりたいことができないようではダメ。つまり、明快（straightforwardness）であることも必要。
- 単純明快であるためには、概念的な整合性（conceptual integrity）が必要。概念的な整合性を得るには、意見が一致していて共鳴するところがある少数の人達がアーキテクチャを作る必要がある。設計を単純に分割して多数の人に行わせてしまうと概念的な整合性は得られない。
- 以上から、使いやすいシステムを作るには、少数のアーキテクトでアーキテクチャを作る必要がある。
（著者は、システム設計において最も考慮すべき重要なことは、概念的な整合性だと主張している。）
アーキテクチャとは（実装とはどう違うのか）
- アーキテクチャとは、完全かつ詳細なユーザーインターフェイスの仕様であり、それはマニュアルの記載内容である。
- アーキテクトはユーザーの目線に立つ。販売や製造の立場ではない。
- アーキテクチャは何が起きるか、実装はそれをどう引き起こすか。
- 時計に例えれば、アーキテクチャは文字盤であり、実装は箱の中の駆動源や精度を保つ仕組みである。ユーザーは、文字盤、つまり、アーキテクチャを理解すれば、時計の中身が違っていても時刻を読める。
- 他の例：プログラミング言語の仕様はアーキテクチャであり、対応する実装はコンパイラである。
少数にアーキテクチャをまかせて大丈夫な理由
- アーキテクト以外が良いアイデアや良い機能を提案しても良い。アーキテクトの仕事は、概念的な整合性のためにアイデアや機能を取捨選択することに重きがある。良い機能がたくさんあっても、概念的な整合性がないのなら、使いやすいシステムではない。
- 実装の設計もまた創造的な作業である。使いやすさが最も強くアーキテクトにかかっているように、コストパフォーマンスは最も強く実装担当者の創意工夫にかかっている。
- 諸芸術で言われるように、制約は創造にプラスに働く。アーキテクチャの制約があればこそ、実装担当者は、まだ誰も取り組んでいない目の前の実装に集中でき、その創意工夫が生まれるのである。制約が無いと、アーキテクチャに関することばかりを考え、議論して、実装が進まなくなる。
アーキテクチャの作業時期と実装の作業時期
- 少数でアーキテクチャを作り終わってから、実装担当者達を投入するのが1つのやり方。このやり方をした場合の見積もりに対して開発期間が長すぎると考え、始めから多くの人員を投入したが、開発期間は短くならず品質は下がったというのが著者の経験である。経験では、アーキテクチャ作りに多数の人が関わり、概念的な整合性が低下すると、テスト期間も延びる。
- アーキテクチャが完成する前から実装担当者が出来ることは多くあるので、それを行うというのがもう1つのやり方。プログラムを実行するマシンなどを含めた実行環境を理解する、実行環境に合うアルゴリズムや実装の仕方を検討する、性能目標（処理速度やメモリ消費量）を設定する、必要になるツールを準備するといった作業は、最終的な仕様で実現されるであろう機能の概要だけが分かっている段階からでも始められる作業である。
他の章はこちらから：
「人月の神話」の要点
人月の神話の要点・ポイントをまとめています。原著に基づき、人月の神話の要点・ポイントを主に箇条書き形式でご紹介しています。
picolab.dev
2022.04.18
