記事一覧

リスクに積極的に向きあうためのリスク管理【成功する アジャイル 開発 #8】 kanban product owner スクラム project management scrum master

YouTube 動画
リスク管理の概念のないプロジェクトの成功はただのまぐれです。 それくらいリスク管理という考え方は重要であり、アジャイル/スクラムではその手法の中にリスク管理の概念が埋め込まれており、リスク管理という概念を特別に意識しなくても自然と行なっていることになります。 今回はそのリスク管理について説明します。 アジャイル開発によってソフトウェア開発プロジェクトの成功確率が向上しました。 しかしその本質を理解しないまま見かけだけのアジャイル開発を始めてしまうとプロジェクトの失敗確率はかえって上がってしまいます。 そうした誤解の多いアジャイル開発について、その本質に迫りながら、具体的な手法の参考を
文字起こし

[音楽]成功する味ある開発第8回目はリスク管理についてお話をしたいと思います早速ですけれども皆さんのプロジェクトはリスク完了されているいますでしょうか

実はこのリスク管理という概念ですけれども私はこのアジャイル開発において最も重要な概念だと思っていますアジャイル開発においては優先するべきものを早くそして

作ったものを次々とユーザーに提供していくということを優先しがちですけれどもリスクという考え方これらおうプロジェクトの中でどのように取り扱うかということを

そのチームが意識しているかどうかによってそのプロジェクトの成功の確率というのはかなり変わってくると思いますここでいうリスクですけれども

問題になっていない可能性のあるものですねですから起こらなかった過去あるいは起こらなかった未来結果的に問題にならなかった現代化しなかったものこれらもね

すべて含めたもんこれがリスクと考えますですのでプロジェクトが成功したプロダクトが高い価値をもたらしたいっ

としてもですねリスク管理をしていないプロジェクトであればたまたまうまくいったと言えますねなぜならドローなリスクがあるかというのを把握しておらず

そしてどういうリスクがあればどういう対処をするのかということをまったく何も考えずに提供したわけですからいわばブレーキがないアクセルだけの車でたまたまゴールインできたということですねそんな車は

長期的にいろんな道を走れるでしょうかリスク管理というのはチーム全体組織全体でアジャイル開発を推進していく中で最も横展開しやすくそしてチームそのもの組織その

ものが成長する上で欠かせない概念だと私は思っていますですので一つのアジャイル開発をしたチームがじゃあまた別のチームにロー how ナレッジを提供しようと思っビジネス特性が違ったりマーケット国政が違ったりあるいはプロ断固特定が違ったり開発者ろ知識属性が違ったり

ということが往々にしてありますのでその場合であれば横展開できるものっての実はあまりないんですしかしーリスク管理をすると言うこの仕組みは予後展開できますこの

リスク管理という概念はアジャイル開発の皆楽プロジェクト管理プロジェクトマネジメント全体でも非常に有益で重要な概念になりますのでぜひ立積極的にリスクカールに取り組んでいただければと思いますではまずそもそもですけれども

なぜリスク管理をするのかこれはリスクを完全にゼロにしようとするためではありません基本的リスクはなくなりませんし

リスクがそもそもないプロジェクトというのはやる勝ちがありません価値のあるプロダクトあるいは価値のある何らかしらのものを取り組もうともプロジェクトには必ずリスクが伴いますですのでリスクはあるものだと認識をしてどのようなリスクがあるのかというのを把握

しておくことが重要ですそれによってそのリスクをリターンにトンペンミ合うのであれば積極的にそのリスクを取りに行くあるいはリスクが見合わないという場合はそのリスクを避ける軽減するあれ予防するといったリスクに対して

道振る舞うのかそういったことを管理していくこれがリスク管理の基本的なスタンスになりますですのでリスク管理となるなれば何かここにもしないようなことをたくさん考えてネガティブなってしまうんじゃないか

とそういったイメージを持たれる人もいるかもしれませんけれどもうまくリスク管理をすることによってプロジェクト全体がどのように今自分たちが動こうとしているのかこの先どのようなリスクに対して対処し

ないといけないのかという事前の準備そういったものに対してその準備が今このタイミングで見合うのかどうかそういったことも考えられますのでむしろストレスはぐっと減ると思います

ですからこのリスク管理を上手くやれてるチームというのは現実に向き合ってそしてそのリスクを許容してきちっときちんと受け入れてそしてそれに対処ができているあるいは対処する必要がないあるいは軽減措置ができているといった状況がうまく共有されていますのでストレスという面においては

むしろ気持ちの準備は整っている状態になりますので十分な精神的なバランスは取れていると思いますそしてここに今もう書き出してますけれどもじゃあ

スタート時にですね同様にしてリスクを把握していけばいいのかというのを簡単にですけれども出してます実際のプロジェクトではもっと詳細に改定もっと詳細にマッピングしていきますので今回はちょっとこのホワイトボードのスペースの関係上高

映像の見やすさの関係上このように簡略化してますけれども実際のプロジェクトでまぁ私が分担当するプロジェクトの中ではもっとたくさんのマップを作りますのでこれはまああくまで考え簡略化したものだと思ってください

プロジェクトの失敗はこの死亡前シーン分析というものからスタートするといいと思いますこれはどうなればプロジェクトが失敗なのかというプロジェクトの c ですねこれをまずはじめに考えますこれはもう最悪のケースを想定して

今回のプロジェクトがフェーズがありますけれどもそれぞれのフェーズでどうなったらプロジェクトが失敗だと見なされるのかということもまず洗い出します

どうなったらプロジェクトはストップするのがありは死んでしまうのか再会をしても取り戻せないのかということを出すわけですねでも時間軸ですからこちらサイドが未来で向こうが過去と考えた場合いいリリースした後実際に製品が使われる出すプロダクトが使われ出すと

例えば性能が足りないとか不具合があるとかですねそういったプロダクトが持つ様々な特性がユーザーサイドを使い出した川で発生しますそれらをこのプロジェクトの失敗というフェーズの中で今回の製品がどうなったらユーザーの業務を止まってしまうのかあるユーザーに対しての多大なる損害を与えるの

かといったものを出していきますそしてビジネスの失敗これはプロダクトがもたらしたものだけではなくてでもそこからさらに影響を与えて波及してこんな風になってしまうとビジネスが終わるんじゃないか例えば会社が倒産する

ですとかあるいはこの部署の予算が大幅に削られるとかですねaプロダクトを出荷して使われてそのさらに後の段階でプロダクトの評価をされた場合に

失敗だったなとそういう評価が下されるそのビジネス的な側面での失敗とは何なのかというのを出しますそしてリリース前ですけれどもこれは開発中に起こり得る失敗ですねもうこれ以上作り続けることができないですとか書い橋が離脱する

予算が足りなくなっていき大幅に削られて足りなくなってしまうあるいは時間がなくなってしまうさまざまなことが考えられると思いますのでどうなるとプロジェクトが失敗するのか死んでしまうのかというその死んでしまうシーンですねおおーー

書き出して書いて貼り出しますそして今度は開発前ですね開発がスタートする前にもリスクはあります例えばアジャイル開発をしようと思っているけれどもアジャイル開発に対しての理解がないなので開発が始められない開発がスタートしない

あるいは men メンバーを集められない人が集まらないそういった開発前にもリスクがあるというのをチームメンバーで認識しておきますそしてその中でこの時間軸で

ふっこのシーンがですねえ大会+できたら今度はその市に向かう全長ですねこれらをさらにこのマップをぐっと広げてつないでいきます

これはのウェディングとのところでも少し触れましたけれども要素を分解してつなぎ合わせてどのようになればなにつながるのかそういったものをマップするとわかりやすいかと思います

ここではちょっとあのその手法に関しては今この段階では割愛押しますけれどもどこかのタイミングでこの死亡前新分析のマップですねこれも紹介したいと思いますはいそしてこのリスクに関するよりより具体的な解説設置したいと思いますけれどもまずリスクというのはこのような

三角形として表現した場合のこのすべてがリスクでありますその中のこの表出した問題もうすでに問題になってしまったものをこれらはその下にある潜在するリスクが上に上がってきたものですね氷山の一角です

ですから問題だけを見てもその下にどのようなリスクがあったのかあるのかそういったものはなかなかこの表面的な問題だけを見ていてもわかりませんですからハークするべきはこの表出した問題からその下にどのようなリスクがあるのかというのを紐解いていくことにもなりますし

それらによってまたこの潜在するリスクというのを想定していく中できっとこのように表出してくるだろうとそのリスクの構造ですねこれらを捉えるというのがリスク管理の中で重要なアプローチになりますですからプロジェクトを進めていく中で

アルトにわかったこと retrospective とかで振り返っているしますけれどもその中の出てきたをわかったこと及ぶリスクですね立エリスが表出した問題これらに対してこういうリスクがあったんじゃないかとか次にこういうリスクが実は

構造的にあるかもしれないので問題としてそのうち出てくる可能性がありますといったことを振り返る中でチームで共有しリスクというものに関してもその構造をあぶり出しますそれをインクリメンタルに

いてレイプ2スプリントの中でレトロスペクティブ取る場で繰り返し更新していくリスというものも常に最新のものに想定を最新のものにしていくということを繰り返していきます

リスク管理の中でねーじゃあどのレベルまでリスク管理をすればいいのかというリスク管理人の対象となる酒精水準ですけれどもまず決めないといけないのはそのプロジェクト projectあるいはチーム組織

とって失敗というのは何で成功というのは何かここはちょっと点数をつけてますけれども20点を切れば失敗あるいは70点を超えれば成功

こういった泥水準であれば失敗でありどの水準であれば成功なのかというのを炙り重きちんきちんとはじめに豪遊取る必要があるんですけれどもこれはスタート時に必ず固定する必要はないですあくまでも必要なのはこのようにしてそもそもこのプロジェクトはどうなると失敗なの

かということをチームがきちんと共有されていることこれが重要ですですから途中でこの20点る水準を支えているですねとても10点にしてみたり30点してみたいということをすること自体は構わないんですけれどもそもそもこれこれではなくどうなんと失敗かということに対して誰もが考えていないと

いうのはダメです成功に関してもそうですねこれ以上のことをすれば成功なんだというそのラインがわからないままとりあえずバックログの上にあるものをやみくもに作っていくというのもあまりよくありませんプライオリティを決めるうえでどこまでが成功でドコドコまでを

以下下回ると成功という呼べないのかこういったものもチームの面ペンバーがですねうまく共有できてそして常にこのはてなという領域があるということも意識しておく人がありますで

リスクに対する対処法ですけれどもこ対処法の種類は2種類ありますひとつが軽減策これは問題が起こった後にその被害を

小さくするという対処法ですねこれはあらかじめトリガーとしてこの被害がが出た瞬間にその被害を小さくしましょうって方法もありますし被害そのものが出るというのはもうしょうがない

という方法で問題を出てしまうんですけれどもその問題が甚大になるところを許容できるレベルにまで軽減しておくというのがこの aの方法ですb はそもそも問題が出ないようにするという方法で予防ですね

でこの映画いいのか b がいいのかというのはその出てくる被害とその被害に対して講じられる対処法のコストですねこのバランスによって選択をしてみてくださいだいたいですけれどもこの予防策の方がコストはかかりがちですいわば発生しないようにするわけですから

事前にですねたくさんの予防策を打たないといけないんですけれどもただ被害が起こるその被害のレベルがですね神代じゃないほど出てしまうというのであれば予防をしておいた方が遥かにコストが甚大する被害に対しては小さくて済むということですねですので被害がとても大きいというものであればこの予防策が選択されるべきです

そしてその軽減策上の軽減策はおっ被害はある程度あるんだけれども許容できる範囲まで軽減することができるそしてその

許容できる範囲まで軽減したことのその水準であったとしてもある程度は稼働させてユーザーが今日できるユーザーの業務に対する被害もある程度までプーできる状態にまで持っていけるというのであればこの a を選択するということになりますa の方がコストが比較的低くて済む

ということが多いですからその出す被害に対してのかけられるコストというのがあまりないというのであればこの軽減策というのを獲るというのもありかえ選択肢としてあるかなと思いますこれらを組み合わせてリスク管理んこれもバックログプロダクトバックログのようにリスク管理表という形で

へリスクをガーッと入れてそれに対処法そしていつ対処したのかそして5その問題が表出したのかそういったことも管理していきながら対処していくという方法オンをとっていくとうまくリスク管理ができると思います

重要なのはリスクというのは必ずあるそしてそのリス君と必ずきちんと向き合うことですね起こらなかった過去だったりあるよ怒れないかもしれない未来ということに対して考えるというのは多少ネガティブになるんですけれども

しかしこの私たちが生きている現実の世界もそうですけれども何が起こるか分からない特にアジャイルの場合だとえ木から次に自分たちが前へ進むわけですからすると様々な問題をが発生しますけれども逆に言うと自分たちが動くことによって問題を早く発見できるわけですよね

ですので積極的にそう問題を拾いながらそしてそれに対する対策軽減策なり予防策なりを打てるようにしておいてそして前に進むスピードを落とさないようにしていく考え出てしまう被害というのをなるべく小さくしていく

この失敗の方に向かわないようにしていく成功する水準の方に向かわせていくということをすることがとても重要ですですからリスク管理をする際retrospective 中もそうですけれどもなるべくメンバーがネガティブにならないようにリスクを自分たちは積極的に摂ることによって成功に向かっているんだというふうに意識を向けられるかどうか

これがとても重要になってくると思いますですのでチームによってはこのリスク管理という言葉を使わないというチームもあったりするかと思いますリスクという言葉が想起するイメージがネガティブなイメージがあるというそういう状況であれば全然違う言葉に言い換えて行ってもいいかなと思いますけれども私は

リスクという言葉は決してネガティブな言葉ではないと思ってますので今回はあえてリスク管理ということを選びましたけれどリスクに向き合ってですね積極的にリスクをとってそしてそれを上回るリターンを取れるようにプロジェクトを成功させていてさせていただきたいと思います

シェア
X LINE
← 記事一覧に戻る