無料ブログはココログ

« 2016年11月 | トップページ | 2017年1月 »

メンバーに良い成績を付ける - リーダーのベンチマーク -

リーダーがメンバーに良い成績を付けることができたなら、仕事をしている証です。ゆるい評価を与えるのであれば簡単ですが、適切な評価ができないならリーダー失格です。

リーダーの仕事は、 プロジェクトに与えられたリソースで最大の成果を出す事です。メンバーそれぞれの能力や性格を見極めて、場を用意して、能力を活かし、不足している能力を育て、必要に応じて補ったりします。

そこにはリーダー自身のリソースも含まれますので、雑用に追いまくられてボトルネックになる事は許されませんし、(すでに得意な分野なら若い人より優先度は落ちますが)リーダー自身が成長する事も求められます。

そのような多くの努力すれば、プロジェクトは良い成果を出す事ができるでしょう。そして、メンバーに良い成績を付ける事ができます。

もし、メンバーに良い成績を付ける事ができないなら、やるべきことをやっているか、一度、振り返ってみると良いでしょう。そうなってしまったのではなく、そうしてしまったのです(リスクを考慮した段取りで成功に導く)。

リーダーの仕事は、リーダーが自分勝手に思い描くプロジェクトを実現する事ではありません。うまくいく場合もあるかも知れませんが、リーダーもメンバーもストレスの溜まる職場になるだけで、能力は発揮できないでしょう。

日本では誤解の多いサーバントリーダーシップですが、メンバーに良い成績を付けるというベンチマークを使えば、うまくいくのではないでしょうか?

このエントリーをはてなブックマークに追加

コールバック地獄よさようなら。Node-REDで非同期処理を使いこなせ!

Javascriptは非同期イベントドリブン処理が行える効率の良い処理系ですが、いわゆるコールバック地獄という見通しが悪くなる問題があります。Node.js上のビジュアル開発環境であるNode-REDは、機能モジュールであるノードをつなぐことで簡単に非同期処理を扱う事ができます。

ここでは、順次、 並列、待ち合わせといった基本的な処理をNode-REDでどのように書くかを説明します。

非同期イベントドリブン処理のイメージ

お湯を沸かしながらTVを見ることを考えてみます。やかんにお湯を入れて火をつけてアイロンを始めますが、アイロンに集中しすぎて空焚きになる事があります。

そこで、キッチンタイマーを1分ごとにセットして、タイマーがなるごとにチェックします。すると空焚きは防げますが、TVの内容がよくわかりません。マルチタスクは難しいのです。

では、やかんを笛吹きケトルに変えてみます。お湯が沸騰すると笛の音が鳴りますので、都合の良い所で火を消します。音が鳴るまでは気にせずにTVを見ている事ができます。

このように待ち時間がかかる処理の場合に、処理が終わるまでCPUを解放するのが非同期イベントドリブン処理です。タスク(計算機で言うとスレッド、プロセス、コンテナ)を定期的に切り替え無くても良いので効率的に計算機を使えます。

コールバック地獄

Javascriptはこのように効率的な非同期イベントドリブン処理の言語です。しかし、ケトルの笛にあたるコールバックを記述する際にネストが深くなるという欠点があります。

これは、コールバック地獄と呼ばれるもので、検索してみると多くの人が苦しんでいる様子が見えます。そこで、かつては async.js などの非標準ライブラリで順次処理や並列処理の待ち合わせが行われていました。

信じる者も救われるか微妙なPromise

Node.js v0.12 から Promise が標準で使えるようになりました。Promiseは処理の待ち合わせを実現するオブジェクトです。呼ばれた関数が先にオブジェクトを渡しておいて処理終了後にに状態を変える事で、オブジェクトを受け取った呼び出し側がコールバック処理に相当する次の処理が行えます。

Promise は良くできた仕組みで、コールバック地獄を無くします。しかし、少し複雑な処理を書こうとすると、Promiseアンチパターン - くじら公園 などを参考にウンウンうなる事になります。

また、Promiseはデータを受け渡す事ができますが、下流の方の処理に必要なデータを途中の処理すべてが受け渡さないといけません。全体の構造を考えたり、作り直すだけで疲れてしまいます。

そこでNode-RED

以前、このブログでも紹介した Node-RED はNode.js上で動作しますが、様々な処理を簡単に書く事ができます。

順次処理

ノードをつなぐと順次処理になります。前のノードの処理がreturnしたメッセージオブジェクトが、次のノードの入力となります。

Nr_5

結果:

Ans: 0

前段のファンクションノードの記述

msg.payload = 0; return msg;

同一データ個別並列処理

ノードの出力を複数のノードにつなぐと並列に実行されます。もちろん非同期ですので実行順序は保証されません(以降の並列処理も同じです)。

Nr_6

結果:

Ans: 0
答: 0

前段のファンクションノードの記述(新しいオブジェクトを作っていますが、順次処理の記述と効果は同じです。このフローでは問題ありませんが、msgオブジェクトの他のデータが引き継がれないので気をつけてください)

return {payload: 0};

個別データ個別並列処理

ノードの出力の数を増やすと、それぞれのデータが並列に実行されます。

Nr_7

結果

Ans: 0 答: 1

前段のファンクションノードの記述

return  [{payload:0}, {payload:1}];

個別データ同一並列処理(node.send)

ファンクションノードで node.send ()を使うと、複数のブジェクトを非同期出力できます。それぞれのデータが並列に実行されます。

Nrsend_2

結果

Ans: 0 Ans: 1 Ans: 2 Ans: 3 Ans: 4

前段のファンクションノードの記述

for (var i = 0; i < 5; i++) {     node.send({payload: i}); }

個別データ同一並列処理(split)

string, array, objectをsplitノードに渡すと、オブジェクトを分解してnode.send()できます(stringは区切り文字を指定できます)。インジェクトノードで配列を渡しています。

Nrsplit_2

結果

Ans: 0 Ans: 1 Ans: 2 Ans: 3 Ans: 4

待ち合わせ

splitノードで並列化した場合、joinノードで待ち合わせできます。msg.payloadのデータはまとめられます。

Nr_8

結果

[ "Ans: 0", "Ans: 1", "Ans: 2", "Ans: 3", "Ans: 4" ]

おわりに

Node-REDの様々な処理をまとめました。Node-REDは順次処理が基本になっていますので、javascriptに慣れていない方でも様々な処理を簡単に記述できます。

Node-REDはIoTの基盤として知られていますが、httpやwebソケットを含めて様々なプロトコルが扱えますし、Dashboardを使えば簡易なUIであれば簡単に作成できます。ちょっとしたテスト用のサーバなら、容易に構築できます。

Node-REDはJavascriptだからと敬遠されている方もおられるかも知れませんが、ぜひ一度、触ってみてください。

おまけ:非同期あるある

Node-REDのファンクションノードでAWS-SDKなどの非同期処理を呼ぶ場合、非同期処理のコールバック関数のreturnでは次のノードにデータを渡す事ができません。このような場合は、継続するノードが順次処理であってもnode.send()でデータを送ってください。

ちなみにAWS-SDKを呼ぶオーソドックスな方法は、settings.js内でrequireしたものをfunctionGlobalContextにセットしておいてファンクションノード内で利用します。

参考:https://nodered.org/docs/configuration#node-configuration

この記事は、SRA Advent Calendar 2016 の12月24日の記事です。

このエントリーをはてなブックマークに追加

ポケモンGOで考えるリスクマネージメント(3/3) WF、アジャイル、CCPM

ポケモンGOは様々な要素が含まれるゲームです。タマゴの獲得機会喪失をリスクとして考えましたが、リスクへの対応は簡単ではありませんでした。

ソフトウェア開発にも様々な要素があり、それぞれが関連しているほか、時間によってリスクが変化するので、対応は簡単ではありませんでした。

そこで、ソフトウェア開発ではリスクへの対応を単純化できる様に、ウォータフォール(WF)、アジャイル、CCPMといったモデルが提案されています。

しかし、そのモデルから外れ出すとプロジェクトは大きな混乱に陥ります。つまり、リスクへの対応を単純化するはずのモデルにもリスクが存在しています。

今回は、仕様(スコープ)、納期、リソースの観点で、WF、アジャイル、CCPMを定義して、そこに含まれるリスクと対策を考えてみます。

ウォータフォール

ウォータフォールモデルは、開発が進んでからの修正作業が膨大である事から、開発の早い段階で障害を取り除きます。その前提は「要求定義」という工程がある様に、要求仕様が定義、さらに言えば凍結できることです。

開発開始時には仕様のほか、サービスインの前提となる納期が固定され、リソースを状況にあわせて投入します。

しかし、仕様を凍結する事は現実には難しく、仕様がどんどん追加されて混乱します。 仕様が膨らんでも納期は基本的に変わりませんので、リソースをドンドン増やすしてしまってプロジェクトが混乱し、最終的には納期が守れなくなります(CCPMが説明される際に、WFは仕様が固定で納期とリソースが可変と説明されることがありますが、現実はもっと混沌としています)。

このようなリスクに対応するには、リリース計画を見直すことと、仕様を調整します。具体的にはリーンスタートアップでいうMVP(必要最低限機能:Minimum Viable Product))を考慮して複数回リリースにする。各リリースでは仕様を削減する方向で調整する。ということです。

また、仕様のブレを無くすにはプロトタイピングが有効です。作ってみないとわからない所のリスクを低減します。

かつて組み込みソフトウェアでは、販売時がソフトウェアの最終リリースでした。不具合を出した社員が倉庫に連れて行かれ「この商品をどうするんだ」と怒られるような事があったそうです。しかし、プログラムを後から更新できる様になり、製造業においても仕様を削減して予定通りリリースしておき、次のリリースで対応するといった施策が実施される様になっています。

参考:

アジャイル

アジャイル開発にも色々ありますが、ここでは固定期間のタイムボックスを繰り返すXPやスクラムを想定します。XPやスクラムでは、タイムボックスを最小のリリースになる様に仕様を調整して、同じチームで開発します。つまり、納期、リソースが固定で、仕様を可変にして調整します。

タイムボックスを節目として新しく計画されますので、世の中の変化やビジネスのニーズに対応する事ができます。

しかし、一定の機能が必要とされる定型業務では、繰り返し回数が増えて期待される機能の実現が遅れる可能性があります。また、タイムボックスあたりのリソースは固定ですから、繰り返し回数が増えればコストも増える事にもなります。

実現される機能で見れば、アジャイル開発にはこのような問題があります。しかし、その見方は本質的でなく、ビジネスにどれだけ貢献できたかで評価すべきだと思います。

つまり、単発的な開発だと考えているので、時間軸が延びて予算計画が狂います。ビジネスを継続的に発展させる長期的なプロジェクトと考えれば、ビジネスとして成り立たせるために必要な機能から確実に実現できるかどうかが重要でしょう。

つまりアジャイル開発のリスク対策は、本来アジャイル開発に向いたビジネスに対して、きちんと開発するということです。

参考:

【12/21追記】

普及の著しいスクラムは、組織パターンの門番と防火壁の仕組みが組み込まれています。こればスクラムの長所であるとともにリスクでもあります。

具体的には、プロダクトオーナーがボトルネックになる。SMがチーム作りに失敗するとコミュニケーションがうまくいかず情報共有に失敗する。といったことです。

対策は教育、コーチ、コンサルタントの導入などがあります。

CCPM

CCPMはサブチームや個人で取ってしまいがちなバッファに注目し、理想見積もりをベースに計画し、プロジェクト全体でバッファを取る。クリティカルチェーンにリソースを集中する。状況を可視化する。ことで効率的な開発を実現します。

バッファを取って時間軸の自由度を高める事で、個人やサブプロジェクトのバッファを無くして全体で最適化しますので、仕様とリソースは固定、 納期は可変になります。

CCPMを実施する事でプロジェクトの生産性が上がる事が知られています。しかし、バッファ削減の効率化は、必ずしも継続しません。CCPMは分散していたバッファを集中管理する事で効率化するので、一度適用すれば、習熟による生産性の向上以外は見込めなくなるからです。

にもかかわらず効率化を前提にリソースを削減して、クリティカルチェーンにリソースを補う事が難しくなり、CCPMが機能しなくなることがあるようです。

初めのうちは理想見積もりが難しいので、通常見積もりからざっくりと理想見積もり計算するかも知れません。しかし本来のやり方である、きちんと理想見積もりをした上でバッファを設定しなければ、いずれうまくいかなくなるかもしれません。

参考:

まとめ

新しい開発モデルがはやると「守破離」と言う言葉が使われます。まずは言われた通りにやってみる。ということなのでしょう。

しかし、現実はどのような開発モデルであってもリスクはあります。ここに挙げた3つのモデルも、仕様、納期、リソースのそれぞれが固定のものが可変になったり、可変のものが固定になるなど、本来のモデルを表層的にとらえただけでは理解できない問題が生じます。

ソフトウェア開発は複雑な仕事です。何かに書かれた通りに実施するのではなく、本質的な内容を理解し、想定されるリスク、そのバランスと時間による変化を考えないとうまくいきません。

ソフトウェアエンジニアリングがソフトウェア工学のテキストに書かれた事を実践するだけではない様に、リスク管理のテキストに書かれた事を実践するだけではリスクマネージメントできないと思います。

ポケモンGOのリスクに基づいてここまでの議論を進めてきました。ゲームの上手な人と下手な人がいる様に、ソフトウェア開発にも上手な人と下手な人がいます。その違いは、リスク特定、リスク分析、リスク評価からなるリスクアセスメントとリスク対応から構成されるリスクマネージメントへの理解かもしれません。

参考:

この記事は、SRA Advent Calendar 2016 の12月19日の記事です。

おまけ

ポケモンGOでは相棒ポケモンを選ぶ事ができ、歩いた距離に応じてアメをもらう事ができます。ついつい短距離でアメがもらえるポケモンを選んでしまいます。

しかし、無駄のないように相棒を選ぶなら、(1)アメをもらうのに距離が必要、(2)進化に多くのアメが必要、(3)なかなか出逢えないレアなポケモン、から選ぶと良いと思います。また、出逢う可能性を考えて必要なアメの数よりすこし少ない数まで歩くと良いでしょう。

ナップザック問題の様に距離の異なるポケモンを最適に進化させる事は困難です。グリーディアルゴリズムの様に距離の必要なものから選ぶと良いでしょう。また、ポケモンを捕まえられる可能性も考慮すると、少し少なめにすると良いことがわかります。

このようにポケモンGOとソフトウェア開発は、共通点がたくさんあります。真面目に考え過ぎて負担にならない様にしてください。ゲームなので楽しめば良いのです。仕事と同じです。

参考:

このエントリーをはてなブックマークに追加

ポケモンGOで考えるリスクマネージメント(2/3) ソフト開発にあてはめる

前回はポケモンGOを題材にリスクマネージメントにおけるリスク対応の説明をしました(ポケモンGOで考えるリスクマネージメント(1/3) リスク対応の種類)。

リスクへの対応は問題の発生する確率と発生時の被害の積(リスクレベル)で考えられます。しかし、ポケモンGOのリスクをソフトウェア開発にあてはめると、それは簡単なものでないことがわかります。

共有(または転嫁) は難しい

ポケモンGOでタマゴの獲得機会喪失をリスクとして考えて、このリスクを家族に転嫁することを考えました。しかし、リスクを共有するには、スマホのパスワードを公開して操作してもらう必要があり、得られるメリットに相当する金品(あるいはサービス)を提供する必要があるでしょう。

ソフトウェア開発でも同じです。レベニューシェア契約(リンク先はWikipedia)など得られた収益から報酬を払う方法があります。発注側の利益は明確ですが、受注側が適切に利益を得るには計画だけでなく、より詳細な情報提供が必要ですし、運営に発言権が必要になります。

そこで、ポケモンGOで歩く事だけ依頼した様に、品質と納期へのリスク回避に対して一定のコストを払う契約が一般的に行われています。

では内製ならうまくいくかと言うと、必ずしもそうではありません。実は内製であってもゴールが共有できていなければ、担当者の価値観に応じて判断が行われる事になります。評価を気にしない社員もいますし、そもそもそれなりの職位でなければ、収益を評価にあまり反映できないでしょう。

結局、契約も大切ですが、それだけでは不十分なのです。業務を理解して、そこで生じるリスクの低減を共に考える事が必要になります。

リスクには依存関係がある

ポケモンGOのタマゴの獲得機会喪失を考えましたが、これを回避するには常に孵化装置を買う必要がありました。獲得機会を失う事がどの程度の金額に相当するかを考えて、一定のリスク低減であきらめる事になるでしょう。

このように、リスクレベルに応じた対応をすれば良いのですが、実は単純ではありません。

ポケモンGOには「しあわせタマゴ」という30分間得られるXPを2倍にするアイテムがあり、レベルアップ時にもらえたり、購入する事ができます。

Fukasouchi

進化させた時やタマゴをかえした時にも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とは

急に立ち止まってスマホの上で指をスライドしている人がいたら、たぶんポケモンGOです。世界中に存在するポケットモンスター(ポケモン)を集めて図鑑に登録する、博士に送るというミッションを実践しています。

ポケモンは、ポケストップに行くともらえる専用のボールを投げて捕獲します。ポケストップで丸い部分をクルクルすると、ボールだけでなく、ポケモンを手なずける事ができるズリノミや色々な道具、ポケモンのタマゴなどがもらえます。

ポケモンは博士に送ったり、連れて歩くとアメがもらえますし、 ジムでバトルやトレーニングすると星の砂がもらえ、ポケモンを配置するとポケコインをもらう権利が得られます。アメや星の砂をためると、ポケモンを進化や強化する事ができます。

このような様々な経験を積んでXPをためるとレベルがあがり、様々なアイテムをもらえたり使える様になります。このように、ポケモンGOはポケモンを捕まえたり育てたりしながら、ポケモンと共に成長するゲームです。

ポケモンのタマゴと孵化装置(ふかそうち)

ポケモンGOの特徴は、地理情報を使って話題になったイングレスというゲームの技術と、ポケモンのキャラクターやストーリーを組み合わせていることです。それ以外にもアイテムの購入が多いという特長があります。アイテムを購入する楽しさが理解され、他のゲームでも売上が増えたとニュースになっていました。

ポケモンGOのアイテムで最も人気があるのは孵化装置です。 孵化装置にタマゴを入れて、必要な距離を歩くとタマゴがかえってポケモンをゲットする事ができます。 もともと無限孵化装置(むげんふかそうち)という何度も使える孵化装置がありますが、購入できるのは3回だけ孵化できるものです。

タマゴには孵化に必要な距離が、2km、5km、10kmのものがあって、レアなポケモンや進化したポケモンなども含めて、様々なポケモンをゲットできます。

ポケモンGOにおけるリスク

ポケモンGOはレベルを上げながら図鑑を揃えるゲームです。隙間時間に遊ぶのにふさわしいゲームです。その反面、Pokémon GO Plusを使わないとスマホと多くの時間を占有されるゲームです。

かかる時間は楽しんでいる時間でもあるのですが、レベル20を超えてポケモンが100種類を超えるあたりから、ドンドン作業化してしまいます。早く終わりたいと思っている人も少なくないのではないでしょうか。

そこで、余分にかかる時間を損失と考えると、ポケモンGOに様々なリスクのある事がわかります。その中でもタマゴをうまく獲得して孵化させられないとレアなポケモンが得られませんので、多くの時間を失ってしまいます。

タマゴを獲得できないことで時間を失うリスク

とにもかくにもタマゴを獲得しないと行けないのですが、タマゴを得るには以下を満たす必要があります。

  • ポケストップでクルクルする
    ポケストップでクルクルすると3〜5回に1回程度タマゴがでてきます。とにかくポケストップにいかないとはじまりません。
  • 持っているタマゴが8個以下
    タマゴは最大9個しか持てませんので、孵化装置をセットしてドンドン歩いて、孵化させて8個以下にしておないといけません。
  • バッグが空いている
    バッグがいっぱいだと、ポケストップでクルクルしても何もでてきません。荷物を使う、捨てる、バッグをアップグレードするなどして空けておく必要があります。

ここでは持っているタマゴが9個になってタマゴ獲得ができず時間を失うリスクを対象にリスクマネージメントを考えます。

リスク対応

リスクへの対応は問題の発生する確率と発生時の被害の積(リスクレベル)で考えられます。孵化装置を買わないと1日に1時間、5kmほど歩きながらポケモンをしても、1〜2個程度しか孵化できません。4回に1回タマゴがでるとすると、1日に16回ポケストップに寄ったなら、1日当り約半分の確率で問題が顕在化します。1日最大1時間の被害ですからその積である30分はタマゴを獲得できないというリスクが発生します(実際はタマゴから孵化したであろうポケモンによって被害は異なりますが、単純化して考えます)。

この被害に対してどのような対応があるかを考えます。

  • 回避
    「ふかそうち」や「バッグのアップグレード」の購入、道具を捨てるなど万全の対策をとる事で、リスクをほぼ回避できます。購入した孵化装置で1日平均1.5個孵化させれば大丈夫だとすると、2日に1個の孵化装置を買うことになります。月に2,300円ほどかかる計算になります。
  • 低減
    あまりお金をかける事ができないのなら、状況に応じて孵化装置を買う事もできます。たとえば、10kmのタマゴに対してだけ孵化装置を使うだけでも1日1個は孵化させる事ができます(「むげんふかそうち」を短い距離のタマゴに割り当てると、費用を最適化できます。同じコストで多くの「たまご」をかえすことができます。他の対応方法でも有効です)。
  • 共有(または転嫁)
    家族や友だちとリスクを共有する事も可能です。散歩や買い物など出掛ける際に自分のスマホでポケモンGOをしてもらいます。でも、お願いする人に操作されたくないとか、操作までお願いできないのであれば、歩くことだけをお願いして距離を稼ぐという方法もあるでしょう。
  • 保有(または受容)
    遊びなのですから、買わないと決めて、そんなもんだとボチボチやるのもよいでしょう。ジムにポケモンを配置して得たポケコインで孵化装置を購入する事ができますので、時々は孵化装置を使えるでしょう。

おわりに

リスク対応はリスクレベル(問題の発生する確率と発生時の被害の積)に応じて選択されます。今回、リスクが顕在化した際の被害を時間としました。しかし、リスク対応の説明を書いているなかで、同じ時間の被害であっても、人によってその重要度が異なる事に気付きました。

これは、単に時間だけでなく、お金や楽しみの損失という別の被害との相対比較によって対応方法が決まっているからです。つまり、個々のリスクの問題ではなく、バランスの問題なのです。

ソフトウェア開発には様々なリスクがあり、プロセスモデルによってそのバランスが異なっています。次回は、プロセスモデルごとのリスクマネージメントを比較し、ソフトウェア開発の難しさを考えてみます。

おまけ

いわゆるスポットに行くと多くのポケモンが現れますが、バッテリーがすぐに消耗してしまいます。

そこでiPhoneの、設定 -> バッテリ -> 低電力モード を設定し、ポケモンGOの効果音と振動をOFFにしてみましょう。プチフリーズが怒り易くなりますが、バッテリーの持ちが格段に良くなります。

ただし、電車に乗っていて駅に着いても、停まっている事をなかなか認識してくれませんので、気をつけて下さい。

 

この記事は、SRA Advent Calendar 2016 の12月4日の記事です。

このエントリーをはてなブックマークに追加

« 2016年11月 | トップページ | 2017年1月 »