システムを導入するとは？#3
この本は読やすいので、まとめる意味があるのか？と思いながらも、本を読んで（インプット）してまとめる（アウトプット）するトレーニングとしてまずはやってみます。
要点だけ抽出していますので、短い内容になっています。各章の最後にはAppendixのチェックシートなど実際に利用できる有益な情報がまとまっていますので、それはできるだけファイル化してアップロードしていきます。
参考図書
第3章 失敗しないベンダの選び方
～プロジェクト管理能力の見極め方～
第3章の読み方
この本の素晴らしいところはそのストーリー性だけでなく、最初に要点をまとめてくれているところです。
・第3章は、「ベンダのプロジェクト管理能力」、特に「リスク管理能力」を確認する方法を説明
・リスク管理とは、成功のプロセスを阻害する事柄を事前に予測し、対策と対応責任者を決めて、何か生じた場合でも慌てないようにすること
・リスク管理を実施するのは、発注者とベンダの双方に負担がかかる
・システム導入の成功とは、発注者の望んだ仕様を、品質良く、コスト・納期を遵守して完成させること
・ベンダの管理能力を確かめる方法は「プロジェクト計画書」や「プロジェクト管理計画書」を見て、その管理能力を確かめること
引用：システムを「外注」するときに読む本 ISBN 978-4-478-06579-2 P144～147参照
第3章のまとめ
さらにまとめまでしてくれています。ただタイプしているだけにならないように理解しながら作ってます。
・ベンダの示すプロジェクト管理項目と管理工数が十分か見極める
・信頼できるベンダは、自社内のリスクも含めて発注者側に共有する
・要件の変更や追加を、ただ承諾するベンダにはプロジェクト管理義務違反の恐れがある
・ベンダの示すリスクを発注者側はまずは傾聴する
引用：システムを「外注」するときに読む本 ISBN 978-4-478-06579-2 P180参照
＜3-1＞システム開発には「不測の事態」と「リスケジュール」がつきもの
・システム開発では、不測の事態が発生して当初の予定が狂うことは日常茶飯事で、コストや納期を変えることなく満足のいく機能と性能を備えたシステムを予定通りに完成させることの方が少ない
引用：システムを「外注」するときに読む本 ISBN 978-4-478-06579-2 P149～152参照
＜3-1 所感＞
カスタマイズしたシステム導入は予定通りいかないものです。それを打破するのがパッケージソフトなのかもしれません。
生産管理システムの際にも言及しましたが、大きく業務プロセスを変更するときは、システムに業務を合わせるという決断も必要かと思います。
＜3-2＞プロジェクトを適切に管理するために絶対に外せないポイント
・1つのシステムには、無数の要件が有機的につながっており、1つ要件が変わると他の要件やそれに伴うスケジュール、予算に至るまで全体に影響を及ぼす
・システム開発請負の見積でプロジェクト管理工数がどの程度かも確認する必要がある。大きなプロジェクトであれば8～10%程度が妥当。5%以下ならどこかに抜けがある可能性がある
引用：システムを「外注」するときに読む本 ISBN 978-4-478-06579-2 P152～157参照
＜3-2 所感＞
あまりシステム委託の経験がないとプロジェクト管理費用というのが削減項目となり、危険な値下げ交渉になってしまう可能性があります。
プロジェクト経験者を社内で抱えて、対応することで外注費用を抑えることは可能ですが、一つのプロジェクトの場合は10％程度。と割り切って委託した方が依頼側はかなり楽です。
＜3-3＞要件の変更に追加費用や納期延長を求めてくるベンダは○か×か
・システムベンダはほとんどの場合、費用も期間もギリギリで作業している。スケジュールや要件が変更になってそのままの計画で進めることは通常できない
・スケジュールや要件が変更になって、そのままOKすると、一見柔軟性が高いように見えて、ベンダ側の見込みの甘さを露呈することに等しい
・発注者側もベンダが提示する変更計画や追加見積を受け取って話を聞く度量が必要
引用：システムを「外注」するときに読む本 ISBN 978-4-478-06579-2 P157～164参照
＜3-3 所感＞
丸投げしない。それは相手側の事情を互いに理解し、一緒にプロジェクトを完遂させよう、という協力体制が不可欠であると思います。
一方言うは易しで発注者側も社内調整が多く、関係者も多くなってしまうためベンダにワガママを言わざるを得ないシーンもあると思います。
＜3-4＞トラブルを乗り越えるための発注者の聞く力
・プロジェクト管理において発注者が、専門であるベンダに対して求めることやプロジェクトを安心して進めるたに必要なことはすべて「リスク管理」にあたる
・プロジェクトの円滑な推進を妨げるものはすべて洗出し、ユーザーとベンダが協力して解決するか未然に防がなければならない
・ベンダの中には、すべてのリスクを開示しない会社が多い。特にベンダが自分たちの内部で解決すべき問題は発注者に明かさず抱え込むケースが多い
・ベンダが内部の問題も積極的に開示し、発注者を恐れずに相談することがITプロジェクトのあるべき姿
引用：システムを「外注」するときに読む本 ISBN 978-4-478-06579-2 P167～175参照
＜3-4 所感＞
3-3の所感で、関係者が多くなると発注者側のわがままな内容も増えてくると述べましたが、そのワガママを否定するのではなく、「受けることはできるけどその代わり・・・」とスケジュールや予算の見直しをしっかり提示して後で揉めないベンダを選ぶことが重要です。
＜Appedix：参考資料＞
この記事が気に入ったらサポートをしてみませんか？