モメないプロジェクト管理77の鉄則

1. モメないプロジェクト管理の鉄則77

2. 提案と見積り

3. RFI（情報提供依頼書）とその回答 • 回答は後々要件となるため、契約時の洗い直しが必須 • 確認のとれない定量的表現はしない • ユーザの質問内容から「仮説思考」で真のニーズを探る 1

4. RFP（提案依頼書） • ユーザの「ワガママ」を真摯に検討する • ユーザの本来の目的を見分ける • 提案依頼書の記述も要件に化けるため、契約時の洗い直しが必須 2

5. 提案書 • やること・やらないこと／責任を持つこと・持たないことを明示する • 開発方針（工程）は崩れるので、崩れたらどうするかを書いておく • 提案内容も要件に化けるため、契約前に洗い直しする 3

6. 役割分担 • ユーザにやって欲しいことは具体的にすべて書き出す • 実施者、成果物アウトプットを意識できるまでタスクをブレークダウンして書く • バイネームを記述する 4

7. 開発範囲／サービス範囲 • 第三者による確認で手前勝手な解釈を排除する • ユーザが作業可能かどうかを検証し、必要なら提言する • ベンダの責任も無限ではないことについてユーザと合意する 5

8. ファンクションポイント法 • 他の見積もり法と比較して検証する 6

9. 類推見積法 • 参考プロジェクトの経験を数値化して実績データにする • ベテランの「勘」は客観的な変動要素係数（差分）と捉える • ベテランの「度胸」の裏にはリスクテイクがあると認識する 7

10. 三点見積法 • 楽観値、期待値、悲観値で見積もる • 統計的手法を利用して3つの値を設定する • 統計数値がなければ、プロジェクトリスクで値を設定する 8

11. 契約と法務

12. 請負契約 • 「任せきり」「任されきり」は禁物 • 効率的な作業の恩恵はベンダが受けると認識する 9

13. 準委任契約 • 成果物に責任を負う覚悟をもつ • ユーザが委任者としての責任を果たすように提言する 10

14. 多段階契約 • ITプロジェクトの単段階契約は危険 • 変化や事件に対応しやすい多段階契約を結ぶ • 概算見積りと基本契約で弱点を補う 11

15. 著作権 • 成果物の権利義務について著作権に頼りすぎない • 契約書で個々の権利を明確にする 12

16. 瑕疵担保責任 • 瑕疵担保責任を問われないためにスピード感を重視する 13

17. プロジェクト管理義務 • 円滑なプロジェクト運営のためにユーザにも提言する • 必要ならプロジェクト中止も提言する • プロジェクトに係る客観的なデータでユーザの同意を得る • ベンダのプロジェクト管理義務をユーザにも理解させる 14

18. ユーザの協力義務 • ユーザに協力義務を理解させる 15

19. サービスレベルアグリーメント • 目標の明確化と意思統一のためにサービスレベルアグリーメントを結ぶ • 進捗・欠陥数・稼働率など評価可能な数値や指標で定める • ユーザからの信頼獲得のためにも結ぶ 16

20. 下請法 • まず、元請と下請の関係にあるか確認する • 自社の損害防止のためにも下請法は絶対遵守 17

21. 債務不履行 • 何が債務不履行にあたるかを把握して作業する • 単に作るだけではなく、ユーザがシステムを使えるようにする 18

22. 無償契約 • 無償のサービスでも手前勝手な作業は許されない • 無償のサービスでも作業内容と期間はしっかり契約する 19

23. 要件定義

24. エンドユーザの要望 • ワガママの奥にある真の要望を探る 20

25. 導入の目的 • 要件変更・追加の可否は導入の目的を軸に考える • 導入の目的と要件・機能の関連を文書化する 21

26. 目的達成の方針 • 方針策定には先行事例やパッケージの知見も有効 • 方針と機能を混同せず、機能に振り回されない 22

27. 制約条件 • 制約条件は網羅的なヒアリングで抽出する • 自身の経験から制約の出そうな切り口を設定して調査する 23

28. 前提条件 • 前提条件はリスクと同様に監視する • 要件と同じく変更管理も行なう 24

29. 業務要件 • まずは関係者と共に業務フローを書き出す • 整理した業務の開始、終了、入出力、処理・判断、制約を明らかにする • 原則はユーザの仕事だが、ベンダができれば付加価値になる 25

30. 機能要件 • 時間の許す限り、許さなくても、網羅性、正確性、十分性の精査が必要 • 最低でも5W1Hチェックは行なう 26

31. 非機能要件 • BtoCのシステムでは重要さを増す非機能要件こそ重要事項 • 実績のある切り口で非機能要件を洗い出す • 操作者や接続先システム、接続する他の機械を洗い出し、シナリオを考える 27

32. 性能要件（速度） • 性能要件は数値で表わす • 動作させてみないとわからない性能は前提条件付きで定義する 28

33. 性能要件（データ容量） • ベンダが用意しない機械でも容量の確認は必要 29

34. 性能実験 • ポイントを絞って早期に実施する 30

35. RAS • RASを非機能要件、SLAとして設定する 31

36. セキュリティ要件 • セキュリティ対策はベンダが自発的に提案する • 脅威の類型を知っておく 32

37. 新業務フロー • 業務フローは、汚しながら業務要件を明らかにするワークシートで • 具体的なイメージを元に不平・不満・要望と真摯に向き合う • 導入の目的・方針とのトレーサビリティを確認する • プロジェクトの原点に立ち戻るためいつもそばに置いておく 33

38. 要件の優先度 • 導入の目的・方針に照らして決める • 経営的な視点も大切 34

39. 優先度決めの方法 • 要件の相対的利益と損失を数値化できるならスコアリングマトリクスを • 複数の手法を組み合わせる • 大切なのは他者に説明できること 35

40. MoSCoW分析 • 4つの明確な基準を設定して要件を分類する 36

41. 要件/仕様凍結 • 凍結してもヌケモレを前提にプロジェクトを進める 37

42. 変更管理 • 面倒でも、とにかく逃げない • 変更管理工数を見積ってプロジェクト管理工数に含める 38

43. 妥当性確認 • 受入検証以外にも妥当性確認の場を設定する • 妥当性確認は正式合意であると認識する 39

44. プロジェクト体制

45. ステークホルダー • 漏れなく洗い出し、自覚してもらう 40

46. プロジェクトマネージャ • 積極的にエスカレーションを行なう • 要件変更はあるものと考える • リベラルと縦社会を使い分ける • 自分のためのメンタを作っておく 41

47. プロジェクトスポンサ • プロジェクトスポンサに重責を認識してもらう • プロジェクトスポンサへの報告のしくみを作る 42

48. 要件スポンサ • 要件スポンサには要望の収集と要件承認の責任を持ってもらう • 要件スポンサに代行者はNG 43

49. エンドユーザ • エンドユーザとは、プロジェクト外のこともコミュニケーションをとる 44

50. プロジェクト承認者 • プロジェクトの中止・完了の判断は承認者のみが行なう • 中止の提言はベンダー側承認者が行なう 45

51. プロジェクトマネージャの上司 • プロジェクトマネージャ選任の責任は上司が負う • 常時、プロジェクトマネージャの状態を把握する • 能動的にプロジェクトマネージャを支援する • 必要ならプロジェクトマネージャを交代させる • プロジェクトマネージャをねぎらう事を忘れない 46

52. プロジェクトマネジメントオフィス • PMOには企業人・組織人としての高いスキルが必要 • 技術者志向の人も経験してみるべき 47

53. ステアリングコミッティ • 重要な判断はユーザとベンダのステアリングコミッティで下す • 立場を忘れてプロジェクト成功至上主義者になる 48

54. エスカレーション • プロジェクトマネージャだけで問題を抱え込まない準備をしておく 49

55. プロジェクト計画と管理

56. プロジェクト計画 • プロジェクトで起こるすべてのことを想定して計画する 50

57. プロジェクト管理計画 • プロジェクトで管理すべきすべてのことを計画する 51

58. プロジェクト憲章 • なぜ、このプロジェクトを行なうのかを1枚で理解させる 52

59. マスタスケジュール • 以下がわかるように書く • 作業の構造 • 作業間の依存関係 • クリティカルパス • マイルストーン 53

60. WBS • 成果物単位で書く • 作業期間を1週間程度まで詳細化する • 最初からすべてを詳細化しない 54

61. アーンドバリューマネジメント • 予測コストを分母、出来高を分子にして作業の完了率を求める • 出来高の予実でスケジュールを評価・予測する • コストの予実から完成時コストを予測する 55

62. 要員計画 • 予定工数が月に160時間は余裕がなさすぎ • 兼任要員がいるときは、相手のプロジェクトもウォッチしておく • 実績が予定を超えても下回っても検証と是正が必要 • 理由のはっきりしない作業時間増加には要注意 56

63. スキルアップ計画 • 要員のスキル不足はあたりまえと考える • スキルアップの計画と実施はベンダの義務 57

64. 進捗・状況報告 • 読み手の関心事項を理解する • 客観的な数値や事実を元に書く • 読み手にどんな行動をしてほしいかを意識する 58

65. リスク管理 • リスク抽出のためのチェックリストをつくる • リスク一つひとつに管理計画が必要 59

66. 課題管理 • 課題の放置は禁物。タイムリーに共有する。 • 課題も一つひとつに管理計画が必要 60

67. 構成管理 • 世代管理と最新の成果物の維持は当然 • 変更履歴とベースライン管理で成果物間の不整合を防ぐ • 機能ベースライン監査で設計内容の不整合を防ぐ • 物理ベースライン監査でプログラムなどの不整合を防ぐ 61

68. 会議体計画 • すべての会議のアジェンダと出席者を計画する 62

69. 議事録 • 双方の承認印をもらう • 閲覧ルートを書く • 「申し訳ありません」の真意を正確に書く • 議事録は受注側が書く • 議事録修正に係る資料も添付して保管する • 本意ではない記述や修正は厳禁 63

70. 情報保護管理 • 情報保護も管理計画を立てて行なう 64

71. 品質保証レビュー • 個人の作業を組織が保証する • 5つの観点でプロジェクトを監視 65

72. 開始完了基準 • 完了基準には現実的な逃げ道を作る 66

73. プロジェクト完了基準 • 欠陥や残作業がどこまで許されるかあらかじめ決めておく 67

74. プロジェクト反省会 • 目的を果たしたかを検証し、次につながる知見を得る 68

75. 開発方式とシステム形態

76. ウォータフォール方式 • 滝は逆流する • 工程ごとに成果物の完了と整合性を確認する 69

77. プロトタイプ方式 • 実際に動くものに振り回されない • 進捗、スキルのバラツキに注意 70

78. スパイラルモデル • ユーザと共に進む • 終わらない要望への対処が必須 71

79. アジャイル開発 • さまざまな方式から合ったものを選択する 72

80. レガシーシステム • スパゲティ化・迷宮化への対応を心がける 73

81. クライアントサーバシステム • 全体最適の視点で機能の要不要を見直す 74

82. Web三層構造 • システムの特性を考えてサーバの配置を考える 75

83. クラウドコンピューティング • 導入前にセキュリティや著作権などの課題を精査する 76

84. パッケージソフトウェア • ソフトの細部やバグまで把握する • カスタマイズ・アドオンは意外に高い • 自習の工数確保が必須 • カスタマイズ要件は収束しにくい 77

85. 出典

86. 岡田勝人｜Katsuhito Okada P r o d u c e d b y

モメないプロジェクト管理77の鉄則

Du liest eine Vorschau.

Hier ansehen

モメないプロジェクト管理77の鉄則

Weitere Verwandte Inhalte

Weitere von Katsuhito Okada (20)

Aktuellste (20)