社内SEになりました

社内SEは本当に楽なのか?ユーザー系IT企業とSierとの違いは?これからIT企業への就職や転職を考えている人むけに、ユーザー系IT企業から社内SEに40代で転職した筆者がITエンジニアの仕事内容やプロジェクト管理のノウハウ等をご紹介。

プロジェクト管理のキモ(リスク管理)

プロジェクト管理の中のリスク管理の説明です。

なぜ最初にリスク管理の説明なのか?それは私が一番重要だと考えているからです。

ここで言うリスク管理は、狭い意味でのリスク管理ではなく、本来の意味でのリスク管理です。何が違うのか?まずは狭い意味での(大部分のプロジェクトでは形骸化している)リスク管理から説明していきましょう。

1.プロジェクト管理におけるリスク管理

リスク管理は、リスクを組織的に管理して、損失などの回避または低減をはかるプロセスのことです。具体的には、発生頻度と発生した場合の影響を定量化して、それぞれのリスクに対して影響を極小化する等の対応を実施していきます。

リスク対応は、「回避」「転嫁」「低減」「保有」の4つの種類に分けられます。

回避」は、対策を講じることでリスクが発生しなくなるようにすることです。通常のプロジェクトでは、この「回避」を選択することは滅多にありません。例えば新しくシステムを作る際、その会社ではじめてアジャイルで開発することに決まったとします。この場合「アジャイルに不慣れで、期日までにシステムが完成しない」リスクが発生します。そのリスクに対して、「ウォーターフォールに変更する」という対策が「回避」です。通常はプロジェクト開始前に開発手法は決まっているので、プロジェクト開始後のリスク管理で「回避」が選ばれるケースは少ないです。

転嫁」は、リスクが発生した場合の影響を第三者に移すことです。アジャイル開発の例でいうと、開発そのものを丸ごと外注してしまうことで、リスクが顕在化した際の責任を外注先に移転させることができます。通常はプロジェクト開始前に外注するか内製で対応するかが決まっているので、プロジェクト開始後のリスク管理で「転嫁」が選ばれるケースは少ないです。

低減」は、対策を講じることでリスクが発生した場合の影響を抑えます。先ほどの例でいうと、アジャイル開発の経験豊富なITコンサルをPMOとして雇うような対策が、これにあたります。リスクが消えるわけではないのですが、経験豊富なITコンサルをプロジェクトメンバーに入れることで、リスクの発生確率を下げることができます。

保有」は、何も対策をしないことです。発生頻度が低く、影響も小さいリスクに対して用いることが多いです。

f:id:SystemEngineers:20200526115734p:plain

リスク対応は以上のように4つに分類されますが、私の経験上は「回避」と「転嫁」の対応をしたことは無く、大部分は「保有」で、品質管理部門や上司への体裁を整えるために「低減」となる対応をいくつか実施したりしている程度です。

アジャイルに不慣れで、期日までにシステムが完成しない」リスクに対してのリスク対策の例でいうと、回避や転嫁、低減の対策は、通常はプロジェクトがはじまる前にとられる対策なので、プロジェクト開始時には実施済みとなっています。

f:id:SystemEngineers:20200526115755p:plain

つまり本当にお金をかけて対策をする「回避」や「転嫁」、あるいは「低減」は、プロジェクト開始前に対策が打たれていて、プロジェクト開始後はリスク予算の無い中で仕事の工夫でできるレベルの「低減」と、費用が発生しない「保有」しか選択肢にありません。そのため、通常のプロジェクトのリスク管理は、ほとんど形骸化しているのが実情です。

2.プロジェクトマネージャーのリスク管理

「プロジェクトマネージャーのリスク管理」=「プロジェクト管理におけるリスク管理」ですが、ここでいう「プロジェクトマネージャーのリスク管理」とは、リスク管理表に載せられないリスク管理です。

優秀なプロジェクトマネージャーは、リスクに対しての嗅覚が発達しています。プロジェクトの進行を阻害するような要因を敏感に嗅ぎ付け、リスクの顕在化を未然に防ぎます。プロジェクトマネージャーの仕事は、このリスクを予見し、未然に防ぐことが全てといっても過言ではありません。

ではリスク管理表に載せられるリスクと、載せられないリスクの違いは何か?

超乱暴にいうと人に対してのリスクです。プロジェクトは人の集まりです。問題を起こすのはコンピューターではなく人間です。優秀なプロジェクトマネージャーはプロジェクトメンバーやステークホルダーに対しての嗅覚が敏感です。

例えば、プロジェクトメンバーの中に山田君というキーマンがいたとします。その山田君がプロジェクト期間中に退職してしまいました。優秀なプロジェクトマネージャーであれば、事前に様子がおかしいことを察知して、さりげなく山田君の仕事を別の人でもできるように体制を厚くしておくことで、山田君の退職の影響を小さくすることができます。でもこの「山田君が辞めるかもしれない」なんてリスクは、リスク管理表には載せられません。

別の例でいえば、ユーザー部門の中村さんは、画面の操作性に強いこだわりを持っている人で、今までも受入テストの時に操作性について変更の要望を多く出してきた人です。それなので今回は、要件定義の後半でプロトタイプを作って中村さんに操作性を確認してもらいました。これもリスク管理に「中村さんが操作性で変更要望を出す可能性がある」なんて載せられません。

さらに別の例ではベンダーの設計者の山本さんは、ちょっとロジカルな考えが苦手です。込み入ったロジックの設計の品質が怪しいので、重点的にレビューをして品質を担保しました。これもリスク管理表には「山本さんの論理的思考能力が低いので、設計品質が悪い可能性がある」なんて載せられません。

このようにプロジェクト管理の本質、プロジェクトマネージャーの一番重要な仕事は、リスク潰しが全てといっても過言ではありません。プロジェクトマネージャーの頭の中にあるリスク管理表の精度がプロジェクトの成否を左右するのです。

3.アンテナを張り続ける

リスク管理は、一度リスクを洗い出して対策を打って終わりではありません。

プロジェクトを取り巻く環境は常に変化し続けます。プロジェクトマネージャーは常にアンテナを張り続け、洗い出したリスクの発生確率や影響度に変化がないか、前提条件が変わっていないか等、新たなリスクの予兆を敏感に察知しなければなりません。

以下の図の赤字がリスク対策で、目に見えるリスク管理です。青字の部分がアンテナを張る部分で目には見えませんが非常に重要です。

f:id:SystemEngineers:20200523120807p:plain

4.リスクの洗い出し方法

リスクは、以下のような観点で洗い出しをします。

①プロジェクトの特徴

プロジェクト計画書にプロジェクトの特徴を記載しますが、その他のプロジェクトと異なる特徴の中にリスクが含まれています。稼働率99.999%の高可用性を求められていれば、この要件を満たせないリスクがあります。ただの改修案件でも、構築したベンダーと異なるベンダーが対応するのであれば、そこには実装を理解していないことによるリスクがあります。

②プロジェクトの前提条件

前提条件は神様が保証してくれているわけではないので、前提条件そのものがリスクです。何らかの理由で前提条件が前提で無くなる可能性があります。

③類似プロジェクトで顕在化したリスク

類似プロジェクトで顕在化したリスクがあれば、同様のことが起こる可能性があります。

ステークホルダーが与える影響

顧客や取引先、別プロジェクトなど、自分たちでコントロールができないステークホルダーが、自プロジェクトに影響を与えるリスクがあるかもしれません。

⑤はじめての◯◯

「はじめての開発手法」「はじめてのプログラム言語」など、そのプロジェクトではじめてトライするものは、リスクを抱えている場合が多いです。

⑥難易度の高い開発箇所や不十分な開発体制

難易度の高い開発箇所や不十分な開発体制もリスクを抱えています。

具体例

以下のようなリスクがある場合

f:id:SystemEngineers:20200526162628p:plain

aからeは、どのプロジェクトでもありえるリスクです。このようなリスクは通常はリスク管理の対象になりません。

ただしaからeのリスクも、通常のプロジェクトよりも発生確率が高かったり影響度が大きかったりすると、リスク管理の対象となります。

例えば、2月に本番移行を計画しているプロジェクトであれば、その時期はインフルエンザが流行る時期なので、b「ウイルス蔓延で開発がストップ」に近い「インフルエンザに移行担当者が感染する」というリスクが考えられます。これは通常のプロジェクトよりも発生確率が高いので、リスク管理をしてリスク対策が必要になります。

fからiが通常のリスク管理の対象となるリスクです。

jからmのようなセンシティブなリスクは、リスク管理表に載せることはできませんが、リスク対策は必要です。

5.コンティンジェンシープラン

コンティンジェンシープランとは、リスクが顕在化した場合を想定して、事前に決めておく対応策のことです。

f:id:SystemEngineers:20200526164508p:plain

リリース管理とは別に、リリース計画の中で作成することが多いですが、ITプロジェクトにおけるコンティンジェンシープランリスク管理の一部なので、通常のリスク管理の中でも対策を決めておくと、リスクが顕在化した場合の対応を早くとることができます。

 特にリスク対策が「保有」のリスクに対しては、予めリスクが顕在化した場合の対応を関係者で合意しておくと、顕在化した時に慌てずにすみます。

【振り返り】

今回はプロジェクト管理の中のリスク管理の説明でした。次回はリスク管理に近いところで、課題管理の説明をしていきたいと思います。

①.進捗管理
②.品質管理
③.コスト管理
④.課題管理
⑤.リスク管理
⑥.変更管理
⑦.コミュニケーション管理
⑧.成果物管理(文書管理)
⑨.要員管理
⑩.ステークホルダー管理
⑪.外注管理