このエントリーをはてなブックマークに追加LINEで送る

11.2. 現実のリスク管理

ハッピィ・エンジニアリング表紙

 たいていの開発プロジェクトでは、何らかのタイミングでプロジェクトマネージャやプロジェクトリーダが、リスクとなりそうな部分に対する指摘を行い、技術者がその課題に対処するようなケースが多い。つまり、ある特定のタイミングで、一時的に、経験則によるリスクの発見、評価、対策を行っている。

 

 「やらせる側」のプロジェクトマネージャやプロジェクトリーダが抽出したリスクに対して、「やらされる側の技術者」が対策を検討し実施するというようなパターンである。しかし、それはプロジェクトマネジメントプロセスとして存在しているというよりは、個人的な経験やスキルに依存したものにすぎない。

 

 また、その多くは、リスク対策がリスクの軽減と、危機対策(リスクが問題として顕在化した場合の対策)の両者を含んでおらず、単なる危機対策に過ぎないという側面もある。

 

 さらに、このような任意のタイミングで発生する指示では、リスクの抽出が一時的な作業に留まってしまい、工程ごとのリスクの抽出や監視につながらない。結局のところ、実際のプロジェクトにおいて、リスク管理が根付いているとは言い難い現実があるのである。

 

 逆に、リスクを管理せず、すべてを技術者にまかせっきりにしているプロジェクトも多い。「何か問題があったら、すぐに報告しろ」というようなパターンである。技術者はプロジェクト全体を見渡す立場になく、あくまでも自分の担当している作業を期日までに完了する立場である。技術者まかせにした場合、技術者は自分自身で解決可能かどうかに関わらず解決努力をし、問題を報告しない場合が多い。たとえ報告されたとしても、その問題の内容は技術的な課題に終始する傾向がある。

 

 プロジェクトのリスクを乗り越えなければゴールが見えないはずだが、これらの開発プロジェクトのリスクは、開発会社や技術者との意識共有さえできていないのが現実である。開発チームはプロジェクトのリスクを理解していない。開発チームが認識できるリスクは、自分達のチームが持つ課題管理表だけである。

 

 開発プロジェクト内ですら共有されていないリスクは、当然ユーザ企業と共有されることもない。ユーザ企業は、漠然とした進捗状況を知ることができる程度であり、開発プロジェクトが今後どのように進んでいくのか、潜在しているリスクは何なのか、顕在化された問題は何なのか、について知るすべはない。

 

 しかし、開発プロジェクトのリスクはSIベンダのリスクだけではなく、ユーザ企業のリスクでもある。システムが運用開始に間に合わなかったときの責任はベンダだけにあるわけではない。運用開始の遅れはユーザ企業にとってのマイナスであり、場合によってはユーザ企業の顧客に損害を与えることもある。

 

 「2.4. 人手余って人材足らず」の「ゼネコン構造」に「プロジェクトマネージャはプロジェクトメンバそれぞれの立場、権限、責任を明確にし、対立する利害関係を越え、プロジェクトのゴールを共有しなければならない」と書いた。プロジェクトがゴールに到達するためには、プロジェクトのリスクもユーザ企業、SIベンダ、開発会社で共有し、合理的な判断をしなければならない。

シェアしてくれると嬉しいです!
このエントリーをはてなブックマークに追加LINEで送る

11.2. 現実のリスク管理 ハッピィ・エンジニアリング関連ページ

11.1. リスク管理とは
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
11.3. 文化的な背景
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
11.4. リスク管理への間違った意識
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
11.5. リスク管理を根付かせる
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
11.6. リスク管理のメリット
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。
11.7. リスク管理プロセス
ソフトバンククリエイティブから刊行されたハッピィ・エンジニアリングが無料で読めるサイトです。

ハッピィ・エンジニアリングとは? 書籍を読む プロフィール コンサルティング