曖昧性とのたたかい 名内 泰蔵（翔泳社）

1.システムビジネスと受注
(1)顧客の予算に合わせた提案と見積り
　・２：４：２：３の法則
　　①要求仕様段階では開発すべき要件は半分しか見えない(2)
　　②全体像が見えた頃には、仕様は倍に膨らんでしまう(4)
　　③しかし、予算は増えない(2のまま)なので、
　　④顧客交渉の結果、両者の中間をとることが多い(3)
　→当初から顧客への提案内容を予算枠の半分で実現する方式を考えておく（それでも倍に膨らめば利益はゼロ）
(2)ブルックスの法則
　遅れているPJへの要員追加はPJを更に遅らせる
(3)出荷までの最適スケジュール(B.W.ベーム)
　T=2.5×(所要人月)**(1/3)
　→所要人月64人月が必要なPJは、2.5×4=10ヶ月の工期で完成するのが理想的

2.見積もり
(1)「精度の高い見積もり」よりも「あとで困らない見積もり」
(2)「作るよりつなぐ」（見積もり対象の削減）

3.スコープの明確化
(1)仕様決定手順をあらかじめ確定しておく
(2)システムにとって致命的な事故は何かヒアリングしておく

4.基本設計
(1)テストファースト
　設計時にテストケースも合わせて作成
　→テストケースが書きやすい設計＝シンプルな設計を目指すこと
(2)失敗時の逃げ道を考えた設計
　①必須機能と任意機能は切り離し可能な設計としておく
　②業務上の異常検知ロジック（例.帳票の合計出力値異常検出ツール）を稼動システムにも組み込んでおく
(3)設計思想の記述
　なぜこういう設計としたのかという理由も合わせて記述
　（データ仕様も同じ：何のためにこのデータが必要で、何を目的としたデータなのか記述）

5.システム開発
(1)レビュー
　こまめに短時間で、遅れているものから
(2)仕様変更のリスク
　要求仕様段階で１だった仕様変更コストをテスト段階で見直すと２０、納入時点で見直すと２００倍かかる（アラン・Ｍ・デービス）
(3)要員管理
　①元々質・量ともに要員が揃ったPJは存在しないと考える
　②あるグループだけ優れた人を配置する一点豪華主義でよしとする
　③マネージャは要員不足の部分のみ集中管理、要員最適グループは権限委譲
(4)開発分担
　表通りは新人、裏通りはベテラン
　・オンライン、表示系、メインプログラムこそ新人
　・バッチ、複雑なインタフェース、共通プログラムはベテラン
(5)外注管理
　①外注へ仕事の丸投げはしても、曖昧仕様の丸投げはしてはならない
　②外注には中間成果物の納入も義務付ける
　③外注への発注自体リスクがあると考える（低コスト高品質が実現できれば内製のみが理想的）
(6)テスト
　①テスト部隊は開発と独立させる
　②テスト方式の設計
　　テストケースの絞込み方法、テスト実行/結果確認（目視チェック）の自動化（ツール設計）など
　③バグ２分の１低減の経験則
　　単体テストでN個バグがあった場合、結合テストでN/2個、総合テストでN/4個残っていると判断する
　④バグの質は修正コーディング量で計測する
(7)保守その他
　①定期保守作業時の現状復帰戻し忘れに気をつける
　②本番切替リハーサル時にこそ障害復帰確認も合わせて実施する
　③通常時だけでなく緊急時（障害発生時）の連絡体制を整備しておく
　④保守要員として残ったSE（事故トラブル以外は時間が空いているはず）には
　　それまでのPJの反省、教訓のドキュメント化、ノウハウとりまとめ（特許申請）実施
　⑤PJ終結後は顧客と合同反省会を行う
　⑥窓口責任者と対策責任者を分離する

　
6.顧客との信頼関係の構築
(1)顧客に担当してもらう作業
　①業務仕様確認（契約内容確認）レビュー
　②運用マニュアル作成
　③総合テストデータ設計とテスト結果の妥当性チェック
(2)顧客側PJ体制の確立を依頼する