ポケモンGOで考えるリスクマネージメント(2/3) ソフト開発にあてはめる
前回はポケモンGOを題材にリスクマネージメントにおけるリスク対応の説明をしました(ポケモンGOで考えるリスクマネージメント(1/3) リスク対応の種類)。
リスクへの対応は問題の発生する確率と発生時の被害の積(リスクレベル)で考えられます。しかし、ポケモンGOのリスクをソフトウェア開発にあてはめると、それは簡単なものでないことがわかります。
共有(または転嫁) は難しい
ポケモンGOでタマゴの獲得機会喪失をリスクとして考えて、このリスクを家族に転嫁することを考えました。しかし、リスクを共有するには、スマホのパスワードを公開して操作してもらう必要があり、得られるメリットに相当する金品(あるいはサービス)を提供する必要があるでしょう。
ソフトウェア開発でも同じです。レベニューシェア契約(リンク先はWikipedia)など得られた収益から報酬を払う方法があります。発注側の利益は明確ですが、受注側が適切に利益を得るには計画だけでなく、より詳細な情報提供が必要ですし、運営に発言権が必要になります。
そこで、ポケモンGOで歩く事だけ依頼した様に、品質と納期へのリスク回避に対して一定のコストを払う契約が一般的に行われています。
では内製ならうまくいくかと言うと、必ずしもそうではありません。実は内製であってもゴールが共有できていなければ、担当者の価値観に応じて判断が行われる事になります。評価を気にしない社員もいますし、そもそもそれなりの職位でなければ、収益を評価にあまり反映できないでしょう。
結局、契約も大切ですが、それだけでは不十分なのです。業務を理解して、そこで生じるリスクの低減を共に考える事が必要になります。
リスクには依存関係がある
ポケモンGOのタマゴの獲得機会喪失を考えましたが、これを回避するには常に孵化装置を買う必要がありました。獲得機会を失う事がどの程度の金額に相当するかを考えて、一定のリスク低減であきらめる事になるでしょう。
このように、リスクレベルに応じた対応をすれば良いのですが、実は単純ではありません。
ポケモンGOには「しあわせタマゴ」という30分間得られるXPを2倍にするアイテムがあり、レベルアップ時にもらえたり、購入する事ができます。
進化させた時やタマゴをかえした時にもXPがもらえますので、アメが貯まったら同時に孵化装置をセットします。孵化の直前に「しあわせタマゴ」を使って一斉に孵化させ、貯めておいたアメでまとめて進化させると、多くのXPを得る事ができます。
しかし「しあわせタマゴ」を有効活用するには、孵化装置を使わずにタマゴを残しておく必要がありますので、(よほど運が良くない限り)タマゴの獲得機会を失わないとタマゴを揃える事ができません。
つまりリスクに依存関係がある場合は、いずれかのリスクの問題化による被害を 保有(または受容) する必要があります。
基本的には、それぞれのリスクレベルを計算して優先度を決めれば良いはずです。しかし、次に示す様にリスクレベルが時間によって変化するなら、単純に優先度を決める事ができません。
ソフトウェア開発でも、 スケジュール遅れを取り戻そうと残業を強いると品質の低下が生じる可能性が高まるなど、 リスクの依存関係が多く存在します。
時間によって変化するリスクレベル
ポケモンGOにおいて「タマゴを獲得できないことで時間を失うリスク」を議論してきました。ポケモン図鑑を揃えるにはタマゴをかえしてレアなポケモンを得る必要があるからです。
しかし、時間を失うようなレアなポケモンとは、図鑑に載っていないポケモンの事です。レアなポケモンをどんどん捕まえれば初めてのポケモンが減ってゆくので、たくさんのタマゴを獲得する必要があります。ソフトウェア障害の信頼度成長モデル(SRGM)のようにサチッていく(リンク先はgoo辞書)イメージです。
その一方で多くのXPを獲得してレベルを上げると、新しいアイテムが使える様になって進化したポケモンを捕まえ易くなります。実際は次のレベルに上がるのに必要なXPも多くなるのですが、新しいポケモンの減り方に比べると直線的な変化です。
参考:「ポケモンGO(Pokémon GO)」のレベルアップに対するユーザーの不満が噴出、課金なしでは難しいという声も - GIGAZINE
つまり、図鑑が埋まってくるとタマゴを得る価値が下がり、孵化させてXPを得る方が効率的になります。つまり、時間によってリスクレベルが変化して、対策の優先順序が変わるのです。
ソフトウェア開発でも同じです。関連するモジュールが多い機能は手戻りのが生じた場合の被害が大きく、開発初期では、手戻りのリスクレベルは開発が遅れてしまうリスクレベルよりも高いでしょう。しかし、開発が進んでくると手戻りのリスクレベルよりも開発が遅れてしまうリスクレベルが徐々に高くなるでしょう。
この2つのリスクレベルが入れ替わるタイミングが、いわゆる最終責任時点です。リスクレベルを下げられる様に、ギリギリまで選択肢を残します。
参考: リーンソフトウェア開発 - 決定をできるだけ遅らせる
おわりに
ポケモンGOにあてはめて、ソフトウェア開発のリスクマネージメントを考えました。ソフトウェア開発のリスクマネージメントも、決して簡単ではありませんでした。
それぞれに対応する状況の様に、請負開発や進捗管理だけでなく、そもそもリスクを考慮しなければ良い計画を立てる事ができません。
このようなリスクマネージメントの視点で考えると、ウォーターフォール型開発だけでなく、アジャイル開発やCCPM(Critical Chain Project Management)の弱点や対策が見えてきます。
次回は、その辺りを書いてみたいと思います。
この記事は、SRA Advent Calendar 2016 の12月11日の記事です。
« ポケモンGOで考えるリスクマネージメント(1/3) リスク対応の種類 | トップページ | ポケモンGOで考えるリスクマネージメント(3/3) WF、アジャイル、CCPM »
「私のアジャイル」カテゴリの記事
- One fact in one placeとチケット駆動開発 - Software Processes are Software, Too -(2021.12.21)
- マルチスレッド処理と進捗管理・配員・作業分割/割り当て- Software Processes are Software, Too -(2021.12.20)
- カプセル化と組織パターン - Software Processes are Software, Too -(2021.12.20)
- Greedy algorithmと2割8割の法則 - Software Processes are Software, Too -(2021.12.12)
- 「任せて、任せず」「魚を与えるのではなく"釣り"を教えよ」(2021.08.16)
この記事へのコメントは終了しました。
コメント