Recommended
More Related Content
More from Katsuhito Okada
More from Katsuhito Okada (20)
Recently uploaded
Recently uploaded (12)
モメないプロジェクト管理77の鉄則
- 2. 提案と見積り
- 3. RFI（情報提供依頼書）とその回答 • 回答は後々要件となるため、契約時の洗い直しが必須 • 確認のとれない定量的表現はしない • ユーザの質問内容から「仮説思考」で真のニーズを探る 1
- 4. RFP（提案依頼書） • ユーザの「ワガママ」を真摯に検討する • ユーザの本来の目的を見分ける • 提案依頼書の記述も要件に化けるため、契約時の洗い直しが必須 2
- 5. 提案書 • やること・やらないこと／責任を持つこと・持たないことを明示する • 開発方針（工程）は崩れるので、崩れたらどうするかを書いておく • 提案内容も要件に化けるため、契約前に洗い直しする 3
- 7. 開発範囲／サービス範囲 • 第三者による確認で手前勝手な解釈を排除する • ユーザが作業可能かどうかを検証し、必要なら提言する • ベンダの責任も無限ではないことについてユーザと合意する 5
- 9. 類推見積法 • 参考プロジェクトの経験を数値化して実績データにする • ベテランの「勘」は客観的な変動要素係数（差分）と捉える • ベテランの「度胸」の裏にはリスクテイクがあると認識する 7
- 10. 三点見積法 • 楽観値、期待値、悲観値で見積もる • 統計的手法を利用して3つの値を設定する • 統計数値がなければ、プロジェクトリスクで値を設定する 8
- 11. 契約と法務
- 14. 多段階契約 • ITプロジェクトの単段階契約は危険 • 変化や事件に対応しやすい多段階契約を結ぶ • 概算見積りと基本契約で弱点を補う 11
- 17. プロジェクト管理義務 • 円滑なプロジェクト運営のためにユーザにも提言する • 必要ならプロジェクト中止も提言する • プロジェクトに係る客観的なデータでユーザの同意を得る • ベンダのプロジェクト管理義務をユーザにも理解させる 14
- 19. サービスレベルアグリーメント • 目標の明確化と意思統一のためにサービスレベルアグリーメントを結ぶ • 進捗・欠陥数・稼働率など評価可能な数値や指標で定める • ユーザからの信頼獲得のためにも結ぶ 16
- 23. 要件定義
- 29. 業務要件 • まずは関係者と共に業務フローを書き出す • 整理した業務の開始、終了、入出力、処理・判断、制約を明らかにする • 原則はユーザの仕事だが、ベンダができれば付加価値になる 25
- 31. 非機能要件 • BtoCのシステムでは重要さを増す非機能要件こそ重要事項 • 実績のある切り口で非機能要件を洗い出す • 操作者や接続先システム、接続する他の機械を洗い出し、シナリオを考 える 27
- 37. 新業務フロー • 業務フローは、汚しながら業務要件を明らかにするワークシートで • 具体的なイメージを元に不平・不満・要望と真摯に向き合う • 導入の目的・方針とのトレーサビリティを確認する • プロジェクトの原点に立ち戻るためいつもそばに置いておく 33
- 39. 優先度決めの方法 • 要件の相対的利益と損失を数値化できるならスコアリングマトリクスを • 複数の手法を組み合わせる • 大切なのは他者に説明できること 35
- 44. プロジェクト体制
- 46. プロジェクトマネージャ • 積極的にエスカレーションを行なう • 要件変更はあるものと考える • リベラルと縦社会を使い分ける • 自分のためのメンタを作っておく 41
- 51. プロジェクトマネージャの上司 • プロジェクトマネージャ選任の責任は上司が負う • 常時、プロジェクトマネージャの状態を把握する • 能動的にプロジェクトマネージャを支援する • 必要ならプロジェクトマネージャを交代させる • プロジェクトマネージャをねぎらう事を忘れない 46
- 55. プロジェクト計画と管理
- 59. マスタスケジュール • 以下がわかるように書く • 作業の構造 • 作業間の依存関係 • クリティカルパス • マイルストーン 53
- 60. WBS • 成果物単位で書く • 作業期間を1週間程度まで詳細化する • 最初からすべてを詳細化しない 54
- 61. アーンドバリューマネジメント • 予測コストを分母、出来高を分子にして作業の完了率を求める • 出来高の予実でスケジュールを評価・予測する • コストの予実から完成時コストを予測する 55
- 62. 要員計画 • 予定工数が月に160時間は余裕がなさすぎ • 兼任要員がいるときは、相手のプロジェクトもウォッチしておく • 実績が予定を超えても下回っても検証と是正が必要 • 理由のはっきりしない作業時間増加には要注意 56
- 64. 進捗・状況報告 • 読み手の関心事項を理解する • 客観的な数値や事実を元に書く • 読み手にどんな行動をしてほしいかを意識する 58
- 67. 構成管理 • 世代管理と最新の成果物の維持は当然 • 変更履歴とベースライン管理で成果物間の不整合を防ぐ • 機能ベースライン監査で設計内容の不整合を防ぐ • 物理ベースライン監査でプログラムなどの不整合を防ぐ 61
- 69. 議事録 • 双方の承認印をもらう • 閲覧ルートを書く • 「申し訳ありません」の真意を正確に書く • 議事録は受注側が書く • 議事録修正に係る資料も添付して保管する • 本意ではない記述や修正は厳禁 63
- 75. 開発方式とシステム形態
- 84. パッケージソフトウェア • ソフトの細部やバグまで把握する • カスタマイズ・アドオンは意外に高い • 自習の工数確保が必須 • カスタマイズ要件は収束しにくい 77
- 85. 出典
- 86. 岡田 勝人｜Katsuhito Okada P r o d u c e d b y