プロジェクトのリスクはマネージメントする事で軽減できる

「プロジェクトのリスクをマネージメントするにはどうしたら良いか？」

私は、プロジェクトを任されると、いつもこの疑問にぶち当たってしまいます。
特に、初めてプロジェクトを任された時は、この疑問が重くのしかかって来ました。
なので、今回は、そんな自分へ向けて、解決策を明示したいと思います。

結論を言うと以下になります。

1. 管理
2. 監視
3. 見直し

私は、これまで大きなプロジェクトのマネージメントの経験はありません。
しかし、複数の小さなプロジェクトをマネージメントして来た。
また、その中で、大きな問題は発生してしまい、何度も失敗を繰り返して来ました。
そんな私が、以下で説明していきます。

プロジェクトのリスクはマネージメントする事で軽減できる。

プロジェクトでは、複数のリスクが発生します。 そのリスクを回避する事で、プロジェクトは利益を得るのです。

では、どのようにマネージメントするのかについて、以下で書いていきます。

１．管理

管理する内容は以下になります。

• リスク内容
• 判断基準の作成
• 対応策の作成

リスク内容

プロジェクトのリスクは、経験上、似た内容のリスクが考えられます。
そのため、経験を詰めは、リスク内容は現実的になって来ます。
システム会社ならば、それまでの実績からリスクの一覧は既にあるでしょう。
なので、リスク内容の精査をするだけで、リスク内容の一覧はできるでしょう。

判断基準の作成

こちらも、既にある判断基準を利用できます。
しかし、プロジェクトの規模によって判断基準は変わって来ます。
なので、判断基準は、プロジェクトごとに見直す必要があります。

対応策の作成

対応策については、プロジェクトごとに考える必要があると、私は考えています。
マネージャーによっては、既存の対応策を使用する方もいます。
しかし、プロジェクによって状況が違うため、対応策については、その都度考える必要があると思っています。

２．監視

監視は、上記で書いたリスクの一覧をもとに、プロジェクトを監視します。
プロジェクトの状況が、判断基準を超えないようにすることが重要です。

プロジェクトは、状況が刻々と変わっていきます。
そのため、リスクの判断基準の監視を忘れていると、いつの間にか超えていたと言う状況になるのです。

ただ、マネージャーを経験したことのある方は分かると思いますが、マネージャーの仕事は多いのです。
しかし、リスクが発生してしまうと、大きな損失を被る可能性が高いので、リスクの監視は常に行うようにしましょう。

良い方法としては、定期的に行うことです。
例えば、朝と定時前に判断基準をもとに確認することです。

リスクによっては、数時間間隔で確認する必要があるかもしれません。
その時は、数時間間隔で確認をするのです。

特に、判断基準に近づいているリスクなどは、数時間間隔で監視した方が良いです。

３．見直し

リスク一覧は、定期的に見直すことも必要です。

プロジェクトは、時々刻々と変化しています。
そのため、プロジェクト初期に作成されたリスク一覧は、工程やフェーズによって見直す必要があるのです。

もちろん、対応策についても見直しが必要となります。

私の経験から言うと、工程ごとにリスクは違って来ます。
また、後工程になるほど、対応策が具体的になって来ます。

何故、後工程ほど対応策が具体的になるかと言うと、プロジェクトの初期は、自分のチームで解決する必要があることでも、後工程になるとお客様の状況も分かるようため、お客様を含め解決策を返答することができるのです。

例えば、プロジェクト初期では、試験工程に遅延が発生したとしても、マンパワーでやり切るしかなかったリスクも、後工程になると、お客様に手伝ってもらう対策も打てるようになるのです。

ただし、プロジェクト初期でリスク対策を検討する時に、お客様を当てにするのは間違いです。
十分にコミュニケーションを取った後で、もしもの時は手伝ってもらえる状況が作れた時にお手伝いをお願いする事になります。

なので、それまでに、お客様の状況や立場を十分に理解し、プロジェクトの状況も共有して理解してもらう必要があるのです。

このように、リスクは、工程やフェーズで見直す必要があるのです。

まとめ

今回は、プロジェクトのリスクをマネージメントする方法についてまとめてみました。

結論は、リスク一覧を作成し、プロジェクト中はリスクの監視をします。 そして、工程ごとにリスクを見直しするのです。

こうしてプロジェクトのリスクマネージメントについて書いていると、そんなに難しくないように思えるかもしれません。 しかし、実際にやってみると、これが凄く難しいのです。

私も、これからも試行錯誤していくと思います。

では、今日はこの辺で。

プロジェクト開始前に決めておくこと

これまで、多くのプロジェクトに参加してきました。
しかし、毎回と言って良いほど、プロジェクトの最終段階で炎上している。

原因を分析すると、プロジェクトの開始時にクライアントと決めておかないといけないことを、やってないための場合が多い。

そのため、クライアントの要望が増大し、無理に要望を組み込む事で、品質が大きく低下する状況になる。また、プロジェクトが炎上し、そこに携わるエンジニアに多大な負担をかけることになる。

エンジニアは、ロボットではないし、資源でもない。使えなくなれば、変えれば良いということにはならないし、エンジニアを多く抱え込めばうまくいくわけでもない。

プロジェクト開始前に決めておくこと

少なくとも以下のことについては、プロジェクトを始める前に決めておく必要がある。これを怠ると、プロジェクトの最終段階で、炎上する可能性が高い。

開発理由の確認

まずは、クライアントがシステム開発を必要と考えた理由について、共有する必要がある。詳細を聞き、システム開発が本当に必要なのかを確認する。もしかすると、マクロを作ることで解決できるかもしれない。

ビジネスとしては、システム開発を行う方が利益を得れるので、プロジェクト化したい気持ちは分かる。しかし、使用されないシステムを開発するよりも、必要とされているものを作ることの方が、クライアントにとっては良いし、空いた時間で、別の開発をすることで、結果的に、利益を最大化できる可能性がある。

機能確認

開発理由を充分に共有できた上で、必要となる機能について決めて行くことになる。ここで、決めるのは、開発理由で上がった問題を解決するために必要となる最低限の機能である。

間違えてはいけないのは、外部設計でないことだ。UIは、設計段階で行えば良いし、細かい機能を言い出すと時間がいくらあっても足りなくなる。

ここで決めた機能については、納品する時に実装されていないといけない機能となる。

マイルストーン確認

次に必要となるのは、どの機能をいつまでに確認できる環境に上げるかということだ。開発方法によっても違ってくるかもしれないが、マイルストーンを決めておくことで、どんな仕様をいつまで用意してもらうのかを決めて行くことができるようになる。

また、クライアントからの要望を、どこまで取り入れるかの基準となる。

たまに、開発スケジュールを立てた上でマイルストーンを決めるプロジェクトがあるが、これは、エンジニアの負担をかけることになるし、クライアントからの要望を追加できない。

ウォーターフォールで開発するのであれば、各段階ごとに受けるクライアントのレビューでマイルストーンを決めることができる。

アジャイルで開発するのであれば、どの機能から作って行くか、どの段階でクライアントの確認が必要となるのかでマイルストーンを決めることができる。

ステークホルダ

ここで決めないといけないことは、お互いの窓口だ。クライアントにとって、開発側の窓口は、１つであった方が連絡が取りやすい。開発する側も、クライアントの窓口は１つ良い。それに加え、利害関係にある相手には、状況を共有しておく必要がある。

炎上するプロジェクトの特徴として、開発が進むにつれて、ステークホルダが増えて行く。ステークホルダが増えると、情報の共有に時間が必要となるし、突然、仕様が変更され、後戻りが大きくなる可能性が増える。

複数の企業が参画するプロジェクトの場合は、それぞれの窓口を確認する。

Q&A管理

クライアントと開発者との質問を管理する方法を決める。エンジニアであれば、お馴染みのことであるが、クライアントにとっては、使い方を知らない場合が多い。どのように記載するのか、どのように対応するのか、そして、どのように管理するのかを共有する。

この管理方法を共有できないと、複数の方法で質問がきたりする。ファイル、メール、チャット、電話…。

Q&Aの管理ができないと、プロジェクト後半で、言った、言わないの問題となり、プロジェクトは炎上して行く。

要望管理

多くのプロジェクトでは、要望の管理をしていない。なので、クライアントは、Q&Aに要望を記載する。しかし、Q&Aと要望は別であり、それぞれ管理しないといけない。

これまで、Q&Aに記載された要望は、エンジニアが抜き出して別管理していたところが多いのではないだろうか。

しかし、それでは、エンジニアの時間が開発以外の作業に費やされてしまう。それに、クライアントが要望と感じていないため、不具合となってしまう場合が多い。

リスク管理

これも、多くのプロジェクトで管理されていないのではないだろうか。

リスク管理で必要となるのは、どのような要因がプロジェクトの失敗に繋がるかをクライアントと共有することである。それぞれの要因について閾値を作り、定量的に管理していく必要がある。

そして、リスクが発生した場合の対応方法と共有しないといけない。ここでやっていけないのが、残業や休出で対応するということ。対応方法が、エンジニアに負担をかけて対応するのは、プロジェクト内で行うことであり、クライアントと共有することではない。

そもそもの要因が、クライアントによるものである場合は、エンジニアへの負担を最小限にできるよう対応方法を共有しておかなければいけない。

進捗管理

これは、多くのプロジェクトでやってるよ、と言われるが、それはクライアントと共有できているのでしょうか。月１や週１の進捗会議などで状況報告して終わりではないだろうか。それに、進捗の使い方をクライアントが理解していない可能性もある。

クライアントとしては、開発がどれほど進んでいるか以外に、確認がいつ必要になるかを知りたいのではないだろうか。クライアントは、実作業があるのだから、確認のために予定を早めに立てる必要がある。早めに確認できるのであれば、早く確認したい場合もあるだろう。

プロジェクトとしては、予定と実績を記録しておくことで、分析や今後のプロジェクトの参考にすることができる。

不具合管理

これも、多くのプロジェクトでやってるよ、と言われるのではないだろうか。

しかし、不具合管理で必要なので、出来上がった機能やシステムの品質を上げることである。そのために、必要となる不具合の量など、定量的に閾値を決めて、クライアントの要望する品質を担保する必要がある。

上記の「Q&A管理」「要望管理」「リスク管理」「進捗管理」「不具合管理」については、できれば、リアルタイムでクライアントと共有できるようにしたい。表計算ソフトで共有している場合がよくあるが、これは、内容が入れ子になって、漏れる可能性がある。それに、バージョンによりレイアウトが変わったりするため、共有するためのコストがかかってくる。

環境

これは、プロジェクトごとに作成するタイミングが違うのかもしれない。しかし、どれだけの環境が必要になるのかを、クライアントと共有しておく必要がある。

最低、以下の環境は必要になるのではないだろうか。

・本番環境

・ステージング環境

・開発環境

特に、本番環境をどう運用していくのかを決めておかないといけない。それによっては、本番環境をどこが構築するのか、ステージング環境を開発完了後どうするのかを決めないといけなくなる。

セキュリティの問題もここで決めておいた方がいいのかもしれない。既知のセキュリティ問題と、今後のセキュリティ問題に対する対応についても決めておくと、意識のズレが少なくてすむのかもしれない。

納品物

最終的に納品物について決めておく必要がある。よくあるのが、プロジェクト完了後に設計書が欲しいなどが出てくる場合がある。しかし、納品ようにドキュメントを作成するとなると、コストがかかるということをクライアントと共有しておかなければならない。

ドキュメントやソースコードには、著作権が発生することも、共有しておかないと、後々問題になることが多い。

今回は、私が、プロジェクト開始前にクライアントと決めておかないといけないと考える内容を記載した。と言うよりも、炎上した場合に後悔した内容をまとめた。

こんなプロジェクトやってみたい

これまで携わったプロジェクトは、どれも「やりたい」と思えるプロジェクトではなかったような気がします。

じゃあ、どんなプロジェクトをやりたいのかと聞かれると、困ってしまうのですが、使ってくれる人のライフスタイルが変わるようなシステム開発ができたらいいなと思っています。

例えば、このシステムを使うと、従来の作業時間が短縮されて、残業しなくてすむような誰かのライフスタイルが変わるようなシステム開発ですかね。

これまでのプロジェクトで作ったものも、実際に使ってくれた人のライフスタイルを変えたものがあるかもしれません。でも、実際に開発した私達には、それが伝わって来ないんです。

派遣契約で他社のプロジェクトに入っている場合は、作ったものが世の中に出る頃には、そのプロジェクトには居なかったり、世に出たのかさえ分からないこともよくあります。

ITプロジェクトは、よく建設業と同じでように見られます。しかし、実際のところは、全く違っています。建設業では、作ったのもが目に見える形で残ります。しかし、ITでは、作ったのもは、目に見える形で残るとは限りません。

作業工程も、同じように見えて違っています。

建設業では、設計段階に入ることには、顧客の要求は、ほぼまとめられていて、それを、設計図として起こしていく作業だと思います。

しかし、ITでは、設計段階に入っても、顧客の要求は、まとまっていません。まとまっていない要求をもとに見積もりをし、設計に入ります。そのため、要求がどんどん膨らみ、見積もり範囲を超えてしまうというのはよくある話です。

ITは、もの作りの業界ですが、建設業とは、全く違う考えのもと、作業の進め方や価値を追い求めていく必要があると思います。

何となく、まとまりのない内容となってしまいましたが、結局、ITは、ITとしての価値をまだ見い出せてないのではないでしょうか。その価値を見出だせるようなプロジェクトをやってみなたいなと思っています。