6
7

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

はじめに

プロジェクトリーダー経験が半年もいかないペーペーがリスク管理を始めた話です。

おきたこと

ちょっと前にこんなことが起きました

  1. メンバーが体調不良で休み(3日)、プロジェクトが遅れた
  2. 稼働あげても巻き返せない
  3. バッファを使ってリスケする
  4. タスク漏れ、手戻りによりさらにスケジュールが遅れる
  5. バッファがなくなりリスケできなくなる
  6. プロジェクトリーダーがタスクを進める
  7. メンバーの高稼働が続く
  8. ギリギリ単体テスト完了まではこじつけた
  9. 結合テスト仕様書作成中に、テスト実施しきれないことが発覚

そもそも見積りダメじゃんとか、スキル不足とかもろもろ反省点ありますが、お客さんにパツパツ感が伝わっていなかったのが問題。
結果、期限ギリギリ(検品リリース直前)になって調整が入ってしまった。

お客さんとしては状況を正しく把握して、事前に打てる手を打ちたい。
というところから、不安なポイントを洗い出して事前共有するのをリスク管理を通じてやっていきましょう!
というのが経緯。

リスク管理始めました

「うーんうーん」と頭を悩ませたことや、お客さんレビューで叩かれたこと、などなどはすっ飛ばして今、リスク管理としてやっていることをまとめます。

リスク一覧に記載すること

こんな情報を取りまとめています。
リスクの優先度を決め、トラブルを回避・起きてもテンパらないための情報がまとめています。

  • 起きたらどんな嫌なことが起きるか?(QCDのどれか)
  • どのぐらいのダメージがあるか?(影響度)
  • どのぐらい起きそうか?(発生確率)
  • いつから起きそうか?(発生日)
  • どんな予防策があるか?(回避、転嫁、軽減、受容とかは無視してできることを書いた)
  • その予防策はいつごろ打てそうか?
  • リスクが発生したらどうする

基本的には**「品質に影響があり、直近起きる、影響度が高い」**ものから優先度を高くしています。
※優先度はプロダクトによって異なると思います。

リスクの考え方(足し方)

基本的に「不安なこと・見えてないこと」はリスクと捉えていいですが、こんな情報があればより漏れがなくなります。

  • スケジュール(ざっくりでも3ヶ月先は入ってる)
    • リスクを見つけるため、発生日を考えるため
      • 結合、性能テストフェーズが他案件と被っていて環境競合がおきてしまう
      • リリースタイミングなし(お客さん都合でリリース不可)による同時リリース案件数が増える(リリースリスク増)
      • メンバーの入れ替わり、期の変わりはきっと何かある
      • 思ったより仕事がなくて暇しそう、逆に仕事ありすぎて全部出来ない
  • 過去から学ぶ(過去のKPTまとめ)
    • リスクを見つけるため、発生確率、予防策を考えるため
      • 過去どんなことがよく起きているかを参考に、起きやすそうなリスクを考える
      • 過去起きた課題が再発しそうか、または近しい事象が起き得ないか考える
      • 過去起きた課題に対する対策を参考に、予防策を検討する
      • 良いこと(いい意味で予定通りじゃない)もリスク。KEEPもちゃんと見直す
  • メンバーヒアリング
    • リスクを見つけるため、QCD 、影響度 、予防策を考えるため
      • 困るのはみんななので、どれが困るか、どうすると嬉しいか、の意見を大切にしている
      • 予防策打つのはみんななので、どんなことなら出来そうか、いつ出来そうか、の意見を大切にしている
      • 新しい気づきがあってリスクが増えることも多々ある

リスクを見直す

毎週月、金にリスク一覧を見直しています。
肝心なのは**「定期的に見直す」**こと。
個人的な印象ですが、1週間あれば状況はガラッと変わります。

やることはシンプルです。

  • 上記の「リスクの考え方」にそってリスクを追加する
  • 再度、優先度を見直す
  • 課題になったリスクがあるか確認する
  • 予防策の状況確認する

結果〜4つの効果〜

①先を見通せるようになった

ひとつひとつの案件だけではなく、その先、今年度中のスケジュール(ざっくりだけど)が見えるようになった。
いろんな情報が事前に分かるようになり、こちらから「いつまでに決めてもらえないと出来ないですよ」と打ちだせるようになった。
結果、お客さんからの納期ギリギリを攻めるような要望が少なくった。
※残念ながら無くなってはない。

②メンバーの課題に事前アプローチできるようになった

メンバーの抱える不安(リスク・課題)に気づけるようになり、そこへ前もってアプローチ出来るようになった。
結果、メンバーの進捗(生産性)が良くなった。

③過去の問題点を繰り返さなくなった

週次で「過去から学ぶ(KPTまとめ)」を見直すことにより、「こんな課題起きてたんだ。あれ?今回大丈夫?」となり過去起きた事象に近いことをチェックする(リスクと捉える)ようになった。
結果、トラブル数が減り、心の余裕が増えた。

④僕の勤務時間が増えた

良くないことですね・・・
やらねばならないことに気づき対策しているので、単純にやることが増えました。
やり方を工夫しないとね。って状態です。

おわりに

これはリスク管理というのか・・・感じがしますが、過去の失敗を活かして良い感じ!になっているので良しとしてます。

PMBOK的には、リスクマネジメント計画書を作って、リスクの影響、発生率、などを定量的に測れるように定義しなさい。ってなっているようですね。
今回は完全我流でやってしまいました・・・

今後は、そのようなことも参考にしつつ、誰でもできる形に持っていきたいです。
僕が楽するためにも。

6
7
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
6
7

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?