「IT専門調停委員」が教える モメないプロジェクト管理77の鉄則
- 作者: 細川義洋
- 出版社/メーカー: 日本実業出版社
- 発売日: 2014/07/10
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (1件) を見る
ついでに言うと、本書に「しおり」のように挟み込まれていた「プロジェクトを泥沼化させないための25ヶ条」というおまけも、本文ほどではないものの、まあまあ良かった。
- プロジェクト費用には、プロジェクト管理費や要件変更対応コストも含める。
- プロジェクトの見直し・やり直しを決定する客観的基準をあらかじめ定めておく。
- ステアリングコミッティを組成して、問題を積極的にエスカレーションしておく。
- マスタスケジュールのマイルストーンを逸脱したら即計画全体を見直す。
- 要件の決定・変更時はプロジェクトの目的に照らして採否や優先順位決定を行なう。
- 要件の書き換え時には、追加・変更or単なる詳細化・修正、どちらなのかを都度合意する。
- 議事録は承認、閲覧履歴を残し、かつ本意ではない修正をしない。
- リスク・課題を毎日洗い直し、バツが悪くても対応を積極的に相談する。
- 成果物の諸権利は著作権法に頼らず、契約書に明記する。
- 要件の追加・変更時には、たとえ断られるとわかっていても、追加見積りを行なう。
- 提案した実現方式に技術的な問題があるとわかったら即ユーザと対応を検討する。
- 設計内容と要件・テストケースの追跡可能性を確保する。
- レビューやテストは、通常よく使用される正常系機能を重点的に行なう。
- 稼動系のバグは、とにかく迅速に対応する。
- スキル不足を隠さず、スキルアップ計画を提示する。
- ユーザが約束を守らないときのリスクをあらかじめ説明しておく。
- 元請ベンダは自社メンバに下請法を徹底する。
- 持ち出すパソコンはすべてHDD暗号化。
- 持つなら飲むな、飲むなら持つな。
- ベンダに発注前作業を決してさせない。
- プロジェクトに関わる組織変更などをできる限り早くベンダに伝える。
- ベンダを妄信せず、作業状況や提案の妥当性を検証する。
- ユーザの作業ミスやバグは人間工学的に不可避と心得え、必要以上に責めない。
- どんなに頭にキても怒鳴らない、脅さない、モノを投げない。
- ベンダにパソコンメモリ類を持ち込ませない。
1〜9は「ユーザ・ベンダ共通の注意事項」で、10〜19は「ベンダの注意事項」、20〜25は「ユーザの注意事項」という位置づけである。注意事項のレベル感はまちまちだが、個人的にはマイルストーンの話（5）は重要だと思った。「マイルストーン」とは通常、「要件定義完了」や「サービスイン判定」といった、これをこの時期までに実現できなければプロジェクト全体のスケジュールや品質に影響を及ぼす、重要な区切りのことを指す。しかし実際にはマイルストーンをオーバーしても何らの対策も取られていないことが多い。
で、よくよく見ると、「部長承認」といったセレモニー的な節目を明示化したり（もし「部長承認を終えないと後続作業を始めない」というガバナンスを効かせているのなら、逆に非常に重要なマイルストーンとなり得るが、実際はそうなっていないことが大半）、「（9月2週目から4週目にかけて）ヒアリング」といった「それただの作業予定でしょ、マスタスケジュールと何が違うの」といったマイルストーンも多い（そもそも幅のあるマイルストーンというのも意味がわからないが）。
プロジェクト管理をしていると、何をマイルストーンに設定するかで、メンバーの意識も大きく変わり得るし、重要だなと思う。
