曖昧性との共存 名内 泰蔵(翔泳社)

1.要件定義、見積り、設計
(1)要件の曖昧性を認識する
　①Think beforehand
　　次工程のことを考えながら現在の工程をこなすこと
　②Think of the worst
　　最悪の事態を考えて被害を最小限にする準備をしておくこと
　③Think out the best
　　より楽で快適で効率の良い方法を常に考えること
(2)業務の本質的理解に努める
　what(業務がどのように行われているか(what)だけでなく、なぜそういう業務を行う必要があるか(why)を知ること
(3)何でも見積もり、設計する
　①工程表作成＝基本設計と考えること
　②要員配置計画
　③完全に統括できないもの(他社製品、顧客管理データなど)の調整と作業順序
　④仕様凍結計画(仕様確定順序戦略)
　⑤コンティンジェンシー計画
(4)テスト設計
　基本設計が固まった時点で以下の通りテスト設計に着手する
　①効率的なテストの手順
　②本番でも利用可能なテストツールの作成(DB読み込みツールなど)
　③疎通テスト(主要部分を繋いだモデルケースによる「味見」テスト)の計画
　④網羅性の見積り(組み合わせテストパターンのボリューム把握)
　⑤全端末一斉発信テスト(参加メンバを招集したイベント)の計画
　⑥自動テスト(単体テストの入力データジャーナル化による一斉配信テスト、過去テスト履歴利用による再帰テストなど)の計画、設計
　⑦顧客支援計画(総合、運用試験の仕様、結果判定の参加依頼)
(5)美しい設計を追及する
　①正常性の原則
　　正常、異常共に両立するような設計は行わない
　　めったにない異常処理のために正常処理が性能劣化しないよう設計する
　②コントロール除去の原則
　　PDCAのCを除去しても問題ないようなPとDをしっかり行うこと
　③面仕様の追求
　　例題、サンプル仕様(パターン毎の個別仕様)が仕様の全体を示すものでない
　　統一的な論理で処理できる仕様(仕様の抽象化、汎用性)を考え抜くこと
(6)安定性と操縦性
　　安定性を重視し過ぎると操縦性が悪くなる(例.自転車の補助輪)

2.リスク対応
(1)ステップ数削減のリスク
　①共通化すると共通化した部分の開発工数、テスト工数は増える
　　→コーディング、単体テストの工数は削減できるが、設計や機能確認工数は変わらない
　②共通化設計に失敗すると逆に効率が下がってしまい、総工数として増える場合もある
　③無理やり共通化することで個別に必要な機能が漏れる
　④開発途中からの無理やりの共通化

3.プロジェクト推進
(1)FACTを追求する
　①目で聞く
　　報告は耳だけでなく資料を読んで(目で聞いて)矛盾を見つけること
　②足で見る
　　現地を訪問して(足で)見ること
　③手で考える
　　部下に任せず自分で手を動かし自分で考えること
　　無駄な作業と思えても、それを実際にやることで深く考えること(問題意識)へのきっかけとなる
(2)問題点の顕在化
　トヨタのかんばん方式は中間在庫がないため、前工程に故障が発生すると後工程ラインはすぐ止まってしまうリスクがある
　→積極的に問題点を顕在化させ、一時的に工程を止めても抜本的対策を打つことを重視(大きく騒いで小さく収める)
(3)あきらめない
　①プロジェクト開始時に詳細仕様を書いてみる
　　ほとんど全面書き直しになったとしても、それは自分の先行イメージの改版であるはずだから、その後の変更点として先手管理していける
　②見積りをした時点で仕様書は作成可能
　　契約仕様から何らかの見積りをして契約しているはずなので、RFPを埋めていくシステムイメージ仕様は描けるはず
(4)短工期の幸せ
　短工期にもメリットがあると考える
　①仕様確定が早まる(顧客の納期意識が高いため)
　②仕様膨張が抑えられる(顧客の納期意識が高いため)
　③仕様の優先順位がすぐ明確になる
　④パッケージやテンプレート活用が進みやすい