[本] 『曖昧性とのたたかい 』
超すごい本。（少なくとも第3章までは）
高橋さん曰く、第1章から「受注」を扱うなんて珍しい、とのこと。確かにそんな本はあまり見かけないように思います。続く第2章では「見積り」、続く第3章は「仕様化」です。
なんでここらへんが重要かというと、『コード・コンプリート（下）』の言葉を借りるならば、コンストラクションの占める割合なんてうんこ、だからです（……ふつうに分かると思いますが嘘です。いや、ちょっと嘘。それっぽい記述がないこともないような気がする）。
ちなみに著者はマルス105（現：みどりの窓口）の担当者。マルスについては「プロジェクトX 100万座席への苦闘」を参照のこと（これはこれでアツい）。
システムビジネスと受注
3者（自社、顧客、競合）による「曖昧の三角関係」状態では、
契約時にあらかじめ仕様が明確化されることはない。
でも、契約しないとビジネスにならない。
→ 事前防衛策重要。交渉戦略重要。
- 貪欲に文書化
- 段階的稼動を目指す
- 納期は必ず条件付で記載する
- 総額は値引きしても単価は値引きしない（重要）
見積り
的確な見積り「条件」を設定することが重要。
システム規模と金額を決められる「最小限の条件」があればよい。
→ 条件があれば、あとから再見積り可能。
- 正確な見積りより、あとで困らない見積り（重要）
- 段階的見積もり
- 例外処理などのウラ仕様の把握
仕様化
予算を先に聞き、その範囲内で要求を満たす仕様を作ることが重要。
そのために、契約時に曖昧だった「システム仕様」を貪欲に明確化する。
→ まずは、先の契約条件、見積り条件を見直すことから始める
- システム仕様 ＝ 先の仕様の再確認であるべき（実際は詳細化になるけども）
- プロトタイプ方式は一括請負契約には馴染まない（……一概にそういうわけじゃなくて、仕様終結時限が必要だということ）
- 仕様が膨大化して遅れそうになったら、早めに手を打つこと
- 契約の見直しはお早めに
その他の章
- 5章: 良い名前は幸せの始まり
- 6章: コミュニケーション管理
- 7章: 顧客にも同じ船に乗ってもらうために
- 結び: Q＞D＞C
- マルス105: 工程表を作ること。自動テスト計画（！）
おまけ：カルタがあるのだ
弊社ではみんなで正月にやる予定（たぶん）。