クライアントは、実物を見るまで、そして「これは違う」と思うまで自分が何をほしいのかわからない。 (p.80)まあ、そんなものだと思います。新しいことするなら、なおさら。いろいろ考察しますが、結局、そこまで想像力を働かせることはできないし、その間にモックを作るほうが生産的な場合だってあると思います。後戻りがむずかしい建築なんかも、外観モデル（なんていうのか知りませんが）を作ったり、モデルルームがあったりするわけです。
なのでモックを作る、サンプルを作る、というような作業のスピードを上げ、コストを下げるような工夫が必要なんでしょうねぇ。ソフトウェアの場合はコードがあることは、ほとんど機能が揃っている≒開発がおわっているってことなので。
チームが適切に処理できないほどの仕事を受けることは、マネジャーとして卑怯な行為である。個人的な批判を避けるために、チームが成功できない状況をつくっているのだ。マネジャーに最初にノーと言う勇気がなかったために、チームは無理な仕事を強いられたうえ、組織内で評価を落とす。(p.114)これは非常に耳が痛い。痛すぎて、冷静に考察ができない。
この [インタフェースの欠陥が少なくとも2つのコンポーネントに影響する] パターンを知っているチームは、早い段階でインタフェースに取り組む。すべてのコンポーネントのコードをコミットする前に、インタフェースを使うコードのスレッドを構築する。早くから各人のコードを統合し、頻繁にテストする。 (p.43)ダミーでもなんでもいいから、インタフェースは定義しないとだなぁ。ウェブは結合度が弱いんだから、これをやるのはさらにやりやすいはず。
というわけで、まだ半分くらいしかメモができてません。いや、半分おわったのだ。
