無料ブログはココログ

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

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

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

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

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

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

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

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

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

コールバック地獄よさようなら。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日の記事です。

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

SRA Advent Calendar 2016 に参加します

Advent Calendarというのは、クリスマスが来るのを待ち望むためのカレンダーのことです。最近はアドベントカレンダーにあわせて、みんなでブログを書くイベントになっています。

様々なコミュニティで行われているほか、比較的オープンな会社でもカレンダーを作る様です。

SRAでもだれか言い出さないかと思っていましたが、なんと隣の席の人が言い出してくれました(わーい)。

ということで、今年は SRA Advent Calendar 2016 に参加予定です。みなさん見てくださいね。

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

ランチェスターの法則にソフトウェア開発を学ぶ

はじめに

ランチェスターの法則(Wikipedia)はオペレーションズ・リサーチの数理モデルの一つで戦闘を2つのモデルで表現したものです。

この法則はランチェスター経営やグー・パー・チョキ理論などで知られていて、導入期などで力を一点に集中させる弱者戦略(グー)、 成長期の後半で多様な展開(ボリューム)で勝負する強者戦略(パー)、伸びが鈍化し衰退しだすと多様化を整理する(チョキ)。

ソフトウェア産業で考える

これはソフトウェア産業にもあてはまります。自分たちの立ち位置と世の中の情勢で戦略を考えます。

立ち位置は会社の規模ではありません。マーケットに対して強者であるか、弱者であるかの判断が必要です。

ソフトウェア産業は顧客の経営状況に影響を受けます。従来は新しい予算の切り替わるまでの期間が長く、半年から1年ほど遅れて影響が出ていました。

近年は世の中の情勢に応じて予算が変更される様になりましたので、これにあわせて利益重視(グー)、売り上げ重視(パー)、縮小(チョキ)を変更しないといけません。

参考:ランチェスターの法則と売り上げ、利益、利益率

ソフトウェア開発を考える

ソフトウェア開発においても同じような状況があります。プロジェクトの開始時期は、コミュニケーションや構成管理の基盤を作る、横展開の元になるひな形の開発し品質を向上させる、自動化を進めて手作業を減らす、など効率化を狙った施策を取ります(グー)。

やがて効率化の施策がすすむと、ガンガン開発するフェーズに入ります(パー)。しかし想定外の事象が起きた場合は見極めが必要です。

上司の視点で見ると、ついつい人を投入したくなると思いますが、状況をきちんと見極める必要があります。場合によっては戦略を転換して、必要に応じてスパイクやプロトタイピングといった「グー」戦略も必要でしょう。

ソフトウェア開発でも「チョキ」の戦略が最も難しいでしょう。プロジェクトが収束に向かう時、人を減らす必要もあるでしょう。あらかじめどのように引き継ぐか、誰を育てるかを考えて開発を進める必要があります。いわゆる「段取り8分」です。

参考:実装優先時の考慮点 その1 - プロトタイピングとスパイクソリューション -

状況を把握するには

いかにアンテナを張るかが重要です。顧客とのちょっとした会話が重要です。信頼を得て、関係を良好に保ち、時にはストレートに話して理解していただくと良いでしょう。

開発者の状況もよく見ておく必要があります。出勤時間や退勤時間、休み時間の過ごし方など、ちょっとしたことから、前向きに取り組めているか、負担になっていないか、を見極めます。

「現地現物」と言いますが、ほんの少しの時間であっても直に接して、状況を感じ取る事が重要です。

参考:[#TiDD] プロフェッショナルは本物で確認する

おわりに

ソフトウェア開発と戦略的な考え方は共通点があると思っていました。ランチェスターの法則を見直すと、そこにも戦略的な要素がありました。

グー・パー・チョキの分類はわかり易いので、今の状況を考える際にがどれに当てはまるか考えてみてください。色々と見えてくるかも知れません。

もし、上司がおかしいと思っても、それを愚痴のネタだけで終わらせないで下さい。あなたには、説得する、異動・降格を待つ、昇進して追い越す、転職する、といった選択肢があります。

ランチェスターの法則は様々なものに当てはめる事が可能です。現在のポジションと状況に応じて未来を選択してください。

参考:[#agileto2012] 『チェンジ!』の考え方 ~マネしやんと!~

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

バタバタするのは、リスクマネージメント、オプション確保、連携の失敗

プロジェクトマネージメントの旨い・下手は明らかに存在します。それは、数少ない大切なポイントを実践しているかどうかで、ほんの少しの判断ミスが徐々にプロジェクトを窮地に追い込んでいきます。

まじめに頑張っているのに、プロジェクトがバタバタしてしまう。仕方が無いのかも知れません。でも、ふりかえって考えるとこんなポイントを忘れていないでしょうか?

リスクマネージメント

今起きている問題は予見していたでしょうか?「あぶないなぁ」とは思っていたなんてことはないでしょうか?

リスクに対して「まぁ、大丈夫だろう」とか「問題が起きたら考えよう」などと思っていると、どんどん後手に回ってしまいます。

予想できるリスクは、発生する要素を避ける、発生確率を低減する、外部に転嫁する、許容して対策に必要なバッファを確保する事が可能です。

オプション確保

そんな事を言われても全てのリスクに対策なんてできない。それはそうです。ではどうするか?背水の陣を避ける事です。

対策できていないリスクや予見しえない問題が生じた際に、逃げ場が無くならない様に選択肢を残しておく事です。

あらかじめ計画できる事もありますが、なかなかそうもいかないかも知れません。でも、なるべく選択肢を減らさない様にする事はできます。

リーンソフトウェア開発で最終責任時点(リーンソフトウェア開発 - 決定をできるだけ遅らせる)と呼ばれるそれ以上決定が遅れると問題が生じるタイミングを見極めて、可能な選択肢を残す事で、プロジェクトを柔軟に運営する事ができます。

スムーズな連携

プロジェクトにマイルストーンを設定したり、タイムボックスを適用すると管理が容易になります。しかし、とりあえず目先の目標をこなしていただけではうまくいきません。

全体の作業を俯瞰して、より効率的なパイプライン([#agile] 「リーン開発の現場」を読んで その2 - パイプラインとスケールアップ -)を構成する必要があります。

それはマイルストーンに向かう作業間の連携だけでなく、より長期的な視点でのデシジョンです。今の報告を良く見せる事に執着せず、トータルで効率が良くなる様に作業間の連携を構成します。

おわりに

「あいつがやるといつもうまくいく」とか「頑張っているのにうまくいかない」という状況は、運だけではありません。大切なポイントを押さえているかどうかです。

このポイントは様々な事にあてはまります。プロジェクトマネージメントが旨い人は、他の事もうまくできるでしょう(何を大切にするかは対象次第ですが、、)。

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

セミオープンという選択肢!ヘッドホン PHILIPS Fidelio L2BO

高級ステレオで良い音をガンガン鳴らして楽しみたいものですが、そうもいかないのでヘッドホンの部屋聞きで楽しんでいます。

と言っても普段使いのカナル型のインナーイヤホンは、断線する可能性のある消耗品と考えて程々の品質で我慢しているためか、圧迫感を感じて長時間だと疲れるので、いわゆるヘッドホンを使っています。

以前使っていたヘッドホン

気楽に聞くのでオープンエアーが圧迫感が無くてベストでした。大体1万円ぐらいから良い音になり、2万円ぐらいになると個人的にほぼベストの音で聞けます。とはいえ、いつかは壊れたり、劣化するので、コストパフォーマンスから中間の1万5千円程度のaudio-technica ATH-AD700を使っていました。

このヘッドホンはいわゆるドンシャリではなく、スーッと抜ける感じで音が広がって、耳への当たりも優しくお気に入りでした。でも、リビングの家族の近くで仕事をしながら音楽を聴いている時は音漏れが大きくて不評でした。

装着時の負担が少なかったので、あきらめがつくほど長期間使っていました。しかし、あるとき、片側の音が出なくなりました。ユニットの中で断線した様です。

密閉型の試聴

そこで、新たなヘッドホンを探す事になったのですが、オープンエアー型はお気に入りだったもののもう少し音漏れの少ないものを探す事にしました。

量販店で色々と聞いてみました。密閉式の数万円のものはとんでもなく良い音がしましたが、安価なものは少しこもったようなは感じのものが多い様でした。

1万5千円程度の中ではオーディオテクニカ USBヘッドホン ATH-D900USBが程々に良かったです。メーカーに愛着もあったのですが、本来はPCと接続するためのヘッドホンなので、使わない機能が気になって今回は見送りました。

セミオープン型

自宅で色々と調べていると、セミオープン型が目に留まりました。名前は知っていたのですが、実物は聞いた事がありませんでした。

セミオープン型は商品が少なかったので順番に見ていると、PHILIPS Fidelio L2BOは音の解像度が高いと良い評価でした。前のヘッドホンがオープン型で抜ける感じが気に入っていましたので、興味がわきました。

悪い評価としては、低音が弱め、苦手な曲がある、との事でしたが、点数はさほど悪くなく、買う事にしました。

かなり良いヘッドホン

商品が届いたので開封すると、オス・オスのヘッドホンケーブルが長短2本ついていました。ヘッドホンにはイヤホンと同じ形状のジャックがついていて、外出時にはリモコン付きの短い方を使う様です。

装着感はATH-AD700に比べると強めですが、コンパクトなので周囲にぶつかる事が少ないです。最初はスピーカ部分を端まで伸ばしてしまって強い圧迫感を感じましたが、頭にあわせて短くすると程良い感じになりました。比較的頭が大きい方なので、よほど頭が大きい人でなければ大丈夫でしょう。

楽しみにしていた音はとても良くて満足です。解像度が高く、抜けるような感じです。いわゆるドンシャリの感じは無く、フラットに近いと思います。曲との相性はあまり感じません。ごくまれに低音が「トン」高音が「ジャリ」と感じる事がありましたが、すぐに慣れてあまり感じなくなりました。

良い音で音楽を聞きたかったので、とても良い買い物をしたと思っています。

おわりに

そもそも試聴にいく必要もなかったのかも知れませんが、色々と聞くと自分の好みの音がわかると思います。今回はその好みを基準として選んだので、自分にあった商品と出逢う事ができました。

このヘッドホンは音が良いだけではなく、ケーブルが取り外せるので断線の不安も少なく、長くつきあう事ができそうです。

Photo_2

おまけ:ケーブルレスでの利用

家の中でウロウロする時はL字コネクタとオス・オス変換コネクタを使ってBluetoothレシーバをつないでいます。

見た目はB級SFに出てきそうなデザインですが、ケーブルレスにできるので重宝しています。iPhoneを買い替えたら役立ちそうです(オス・オスのL型コネクタがあれば少しはマシかもしれません)。

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


Redmineが得意なプロジェクト

Redmineの機能を考えると、どのようなプロジェクトに向いているかがわかります。

プロダクトライン

Redmineのチケットは全てのプロジェクトで通番になっています。他のプロジェクトのチケットを容易に参照できますので、プロダクトラインの開発時の様に過去のプロジェクトの参照が必要な場合に有利です。
参考:『Redmine実践ガイド』に書き忘れた事 - 管理を容易にするチケット番号の一意性 -

System of Systems あるいは トップダウンに分解できる

Redmineのプロジェクトとチケットは、それぞれの親子関係を持つ事ができます。 System of Systems と呼ばれるような、複数のプロジェクトから構成されるシステムも小さな単位に分割して管理できます。
参考:[#TiDD] チケットによる情報の関連付け(チートシート)

多様なコミュニケーションが必要な大規模システム

Redmineには他のITSにもあるWikiのほか、フォーラムやニュースなどの情報共有の仕組みがあります。また、ガントチャートによる可視化やREST APIなどシステム連携機能もあります。大規模システムにも対応できる多様な機能が標準で用意されています。(大規模な開発が多いので参考にある様に「説明会を開くべし」と言う意見が多いのでしょうね)
参考:[#redmine] Remineを活かしたプロセス支援 - 失敗しないプロセス支援 - #rxtstudy

作者のJPL(Redmine.jpブログ)は、このような開発をしているのかも知れませんね。

ちなみに上記に当てはまらない、一度限りのプロジェクト、単独システムあるいは構成が変わり易いシステム、チケットで十分あるいは小規模な場合は、Redmineにこだわらなくて良いプロジェクトと言えるでしょう。

なお、Redmineの特徴を説明しましたが、ITSの導入には知見者あるいは導入意欲を持った人の存在が必要になります。また、過去の資産をどうするかということも、ITSを選択する際の重要なポイントの一つでしょう。

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


«[#UAS] Ultimate Agile Stories の寄稿5本を一挙公開!