無料ブログはココログ

標準は諸刃の剣

標準と聞くと仕事を楽にするもの、組織に必要なもの、 あるいは、 面倒臭いもの、 厳しいもの、と考える方がおられるかも知れません。これはどちらも真っ当な意見で、標準には良い面があるものの、悪い面もあります。

標準の効果

ここで参考になるのはプロセスモデリングのゴールでしょう([#TiDD]失敗しないチケット駆動開発 - プロセスモデリングの視点から+告知 -)。標準を理解し、共通の行動を前提に改善し、必要な作業が行われているか管理し、ツールによる自動化やガイドできます。

つまり開発者を支援して、一定のレベルへの底上げや組織的な改善が可能になります。

思考停止の罠

組織活動に便利な標準ですが、思考停止に陥りがちです。厳しく管理することで標準に従うことに集中してしまい、より良いものを追求しなくなってしまいます。また、柔軟な開発ができなくなるので、 開発の負担になって生産性が低下してしまうこともあるでしょう。

より難しい問題は、技術者の成長を止めてしまうことです。実際に大規模開発でうまくやっていた人が、小規模で比較的自由な開発でプロジェクトをうまく管理できないこともあります。なぜその標準が必要なのかをキチンと理解していなかったのでしょう。

良い標準

このような問題が生じにくい標準を考えてみます。標準で全てを縛るのではなく、その重要度によって規則、推奨、参考情報に分けると良いでしょう。単純な共通化ではなく、判断条件と共に複数の選択肢を示します。

良い標準は学びになります。その標準がなぜ良いか、どのような条件で有効か、その理由が説明されているなら、標準に振り回されること無く、自ら判断して実施できるでしょう。

標準を活かすには

どんなに良い標準でも、言われるままに実施しているのでは仕事をこなしているだけです。確認が可能なら、きちんと原本を読んでください。思わぬ発見があるかも知れません。

標準はそれぞれの組織や業務に応じて決められたものですので、定められた制約を守らないといけません。反面、制約を守っていればそこに工夫の余地があります。ソフトウェア開発と同じです。

(参考)詳細設計書を後回しにした話:Win-Winプロセス(ウォータフォール編)

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

決定をできるだけ遅らせる -「現場で役立つシステム設計の原則」深読み -

増田さんの「現場で役立つシステム設計の原則」に関して様々な議論があり、私も立食とコース料理 -「現場で役立つシステム設計の原則」批判の一考察 -を書いたあと、様々な議論をさせていただきました。私なりの本の読み方が見えてきたのでまとめておきます。

この本はアジャイル開発(以下アジャイル)がベースになっていると思います。特にリーンソフトウェア開発のプラクティスである「 決定をできるだけ遅らせる」(リーンを考える - 無駄と必要なアソビ -) の考え方が透けて見えます。

この考え方は上流工程をもつ従来の開発方法(ウォーターフォールと呼ぶとリリースが1回とか工程間で判定会議がいるとされることもあるのでこう表現します、以下、従来法)とは大きく異なる考え方です。

従来法の考え方

従来法で上流が重視されます。これは、ベーム先生の後工程になると修正工数が指数的に増えると発表されたからです(「要求は変化する。Boehm は間違っていた、と DeMarco が暴いた。」というYourdon のブログ:An Agile Way:オルタナティブ・ブログ)。後工程になれば修正が大変だからと上流工程で頑張ることで、開発のリスクを減らそうとした訳です。

話はそれますが、ベーム先生はその後の繰り返し開発やアジャイル開発につながるスパイラルモデル(リンク先はWikipedia)を提唱されたり、後述の「アジャイルと規律」を執筆されるなどアジャイル開発に貢献もされています。IEEE Softwareの紙面でケント・ベックさんとXPについて議論されていたので、からかわれたのじゃないでしょうか。

決定をできるだけ遅らせる

話を戻して「決定をできるだけ遅らせる」というのはYAGNI(You aren't gonna need it)に通じる考え方です。従来法とは逆に、変更の可能性を考慮して、どうしても決めないといけない時(最終責任時点)まで決定遅らせるというプラクティスです。

例えば車のドアのところのデザインがかわる可能性がある場合、ドア部分の金型を削ってしまわずに少し残しておくといった対処で、後から変更が生じた際に調整できるように決定を遅らせるというプラクティスです。すべての事を決定しておかずに余裕を持たす事で、選択肢を残せます。

従来法のソフトウェア開発に置いても、決めきれない内容はペンディング、TBD、TODOなどといって後回しにしたり、手軽な方式に仮決めしておきますよね。それを時間切れだからとあきらめてするのではなく、変更の可能性を意識して選択肢を残す目的で実施するようなイメージです。こうすることで多大な手戻りのリスクを減らします。

「現場で役立つシステム設計の原則」の深読み

このような視点で読むと、仮決めする際のデフォルトが示されているように思います。オブジェクト指向はこう理解して、こう言う風に考えるとうまくいく、短いイテレーションも乗り切れるよ。という風に読めてきます。

上記は私の勝手な忖度ですが、増田さんの講演資料にある批判に対する回答を読むと、増田さん自身も決定を遅らせる考え方をもたれていることがわかります(現場で役立つシステム設計の原則)。

この5ページの「すべてのカラムが Not Null は非現実的?」に対して「実際にやっている、特に困っていない、SQL のスキル+ IDE サポート」という回答からも、決定を遅らせるスタンスが感じられます。

批判を考える

このように考えた上で、この本に対して書かれている批判を考えると、とても良い指摘ではあるものの、「決定をできるだけ遅らせる」こととと対極にある「はじめのうちからしっかり作る」ことを勧められている様に思います。

もちろんリスクを減らす目的で決定をできるだけ遅らせているのであり、「はじめのうちからしっかり作る/設計する」方がリスクが減るのであれば、実施すべきでしょう。

kent4989さんのブログ勘と経験と読経でその方法が紹介されていました(アジャイルとデータモデル、DB進化設計のこと)。アジャイルにこだわるならイテレーションゼロで吸収する。それ以外なら前段階で供給開発、あるいは、RUPなどの反復開発手法の併用を勧められています。最近ではたなかこういちさんが、アジャイルでスタートアップも、軌道に乗ったらUPへ移行すべきときが来る、というものかもしれないと言われています。

2017/9/8追記
アジャイルにこだわる方法としてFDD(リンク先はWikipedia)もあります。
[#Agile] FDDはアジャイル開発、ハイブリッドアジャイルは、、
[#TiDD] 手分けするより助け合い - FDDとチケット駆動開発 -

2017/9/14追記
この本の特徴の一つは決定を遅らせる際のシンプルなデフォルトを示していることです。イテレーション(スプリント)をうまく回せるか不安だった方や、ベロシティ(開発速度)が上がらなくて困っていた方には、大いに参考になるでしょう。

その方法は独特です。批判の多くは一般的な方法を主張し、その良さを指摘したものです。批判の実践はこの本に書かれたシンプルさを損ないますので、どちらを優先すべきか良く判断すべきだと思います。

もし、批判を読んで今までの開発が不十分で問題だったと思われるなら、批判は一部だけを示したものですので、より広く検討して上述の実施方法などを検討する必要があるでしょう。

アジャイルにこだわるかの判断

批判を別にしてもアジャイルにこだわるべきかどうかは考えておく必要があります。平鍋さんのブログデータモデリングなきアジャイル開発は危ういか?では、プロジェクトや製品の文脈によって変わるとされていますし、上述のたなかこういちさんのブログでも「バックオフィス側の管理業務」など業務が大きな要素であることは間違いないと思います。

一方、ベーム先生の「アジャイルと規律」ではアジャイルの5つの重要要因として、規模、重要度、 変化の度合いといった業務に関わる要員のほか、人、文化が挙げられています。

人に依る違い

設計に関して渡辺さんが「システム設計と創造性」の中で“まずは「システムが扱う現実の全体をぼやーっと理解する」ことを目指せばよい”とされていて、私もそうしています。

しかし、ふと思い出すと小学生のことです。私は作文の時間の半分以上をあーでもない、こーでもないと書く内容を考えていました。成績は悪くはなかったのですが、私よりもできる人の中には、作文の時間にすぐに書き出す人もいました。設計でも同じ様に人によって作りながらの方がうまくいく人がいるかも知れません。

そう思うと、書籍アジャイルサムライに

と書かれていたことが設計にも言えるのではないかと思います。

おわりに

増田さんの本に関しては、上記のような視点でとても興味深く読ませていただきました。できれば、続編あるいは改訂版のような形で、アジャイルとリファクタリングによる進化のさせ方について、もっと書いていただければと思っています。

なお、個人的なアジャイル開発に関する考えは、[#Agile] アジャイル開発の課題と対策 その1に書いています。現場でスクラムやXPの様なタイムボックス型管理をしているアジャイル開発はしていませんが、いわゆるモダンアジャイルを実践しているつもりです。

2017/9/8追記

アジャイルマニュフェストはオブジェクト指向の有名人が集まって決めたので、なるほどと思いました、サブタイトルからもオブジェクト指向からの説明の方がしっくりくるかも知れません(私には書けませんが)。

これに関連して「アジャイルプロセスでは、本質的なデザインやアーキテクチャに関する意思決定をできるだけ遅らせることができます。」というマーチン・ファウラー氏の言葉を見つけてニワトリとタマゴの関係だと思いました。

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


アジャイルジャパン大阪サテライト2017の感想

SS2017のポストイベントがなくなったので、 急遽スタッフとして参加しました。


(1)キーノート:シンアジャイル(Joshua Kerievsky)

モダンアジャイルについての説明。タイトルはAgileJapan2017のタイトルにあわせて変更されたようです(シン・ゴジラをまねた?)。

個人的にアジャイル開発のタイムボックス管理は、作業タイミングを固定化するので超短期開発にはフィットしないと思っていました。Kerievsky氏は早くからタイムボックスを守るよりも顧客のメリットを考えようと言われていたそうです(そのとおり!)。

提案する新しい4つの原則は従来のアジャイルマニュフェストに対応しながらも、顧客やソフトウェアの安全性に配慮したものでした。

講演概要
http://www.agilejapan.org/session.html#session01

Agile 2016の基調講演: モダンアジャイル
https://www.infoq.com/jp/news/2016/08/agile2016-modern-agile

チェンジビジョン/英和システム 平鍋さんの説明
https://anagileway.wordpress.com/2016/10/07/modern-agile-jp/


(2)ヴァル研究所 新井さんの講演

アジャイルを社内に広げる際の話。みんなが積極的になるように色々と工夫された中で、権限(部長)があるので、一部の活動が社内評価と連動するようにした。と言われていたので懇親会で質問させていただきました。

質問は、社内の仕組みと連動すると、義務感ややらされ感が出ると思うが、どのようにバランスをとられているか?

答えは、社員には積極的なできる人と、受身の人と両方いて受身の人も働いてもらわないといけない。ルールを決めても相手によって変えている。とのこと。

つまり、ルールはがちがちにせず、運用時に人を見て、たぶんチームによっても変えているのでしょう。エンジニアは、ついつい一貫性が気になりますが、個人個人を良く見ると言うことが重要だと思いました。

ちなみに、「上から見てなので、みんながどう思っているかはわからないですけどね。」と謙虚に言われていたのが印象的でした。


(3)コニカミノルタの久保さんによるエモイ話

人はなぜ生きているのか?それは人生を楽しむためである。

なぜ苦しみがあるのか?それは、いつかより人生を楽しめるからである。

いい人である必要は無い。人の顔色ばかり見る必要は無い。わかってあげるだけでいい。

そう、生きているだけで素晴らしい。

そう思いました。

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

Node-REDから見えた未来 - 変わるもの、変わらないもの - SS2017 WG13

ソフトウェアシンポジウム(SS2017)では、前回紹介した論文発表のほか、ワーキンググループにも参加しました。

ワーキンググループでは各グループのテーマに沿って、参加者がそれぞれのポジションを発表して議論します。私が参加したのはWG13「ソフトウェア開発の現状と今後の発展に向けたディスカッション」で「Node-REDから見えた未来 - 変わるもの、変わらないもの -」を発表しました。

Node-REDは高機能なノード(モジュール)がたくさんあり、それらを組み合わせて高機能なシステムを効率的に開発できます。また、簡単にデバッグできるほか、デプロイが一瞬で、開発から確認の繰り返しを素早く実行できます。

このような環境を使っていると、面倒臭いことがなくなり、ソフトウェア開発に重要な作業を中心に実施する様になります。この重要なことはみなさん合意できますよね。という発表でした。

しかし、Node-REDのデモのインパクトが大きかったのか、Node-REDに対する質問で持ち時間が終わってしまいました。Node-REDを知ってもらえたので、良かったことにしておきます。

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

Visual開発ツールNode-REDの導入によるプロセスの変化と考慮点 - SS2017 -

ソフトウェアシンポジウム2017(SS2017)で経験論文の発表をしてきました。経験論文とは研究論文の様に新規性はないものの、事例報告の様に経験を報告するものですが、問題設定や結果・考察を整理してより有効性や信憑性を高めて論文にまとめたものです。

今回はVisual IoTツールと呼ばれているNode-REDのアンケート結果を報告しました。ソフトウェア開発にツールは欠かせませんが、その導入報告はあまりありません。上流のツールであれば、コンサルタントに依頼することもできるかも知れませんが、下流のツールは小さい規模から始めることが多く、導入経験は他の人にも役に立つと思ったからです。

発表ではNode-REDの基本、長所・短所の説明と共にデモもしました。基本的な Hello World のノードを入れ替えてPathをセットするだけで、そのビジネスロジック(文字列の代入)をそのままWebサービスにできる様子をお見せしました。

このようにNode-REDは確認しながら開発するので短期間に品質の高いソフトウェアを作ることができ、アンケートにもある様に非同期処理が簡単に扱えます。その反面、ある程度の規模になれば、データやアーキテクチャなどの設計をきちんとしておかないと複雑になってしまいます。

そういった知識を持ち、ふさわしいプロセスで開発しないとうまくいかないことがアンケートからわかりました。まとめると

  • ツールの知識やノウハウを共有 する
  • 特性を活かした設計を行う
  • 実装を繰り返して常に確認する
  • 主体的にプロセスを変更し、品質 を上流から作りこむ

となり、これは、モダンアジャイル

  • 人々を尊重する
  • 安全な状態を前提とする
  • 素早い実験と学習
  • 価値を継続的に届ける

の基本理念と対応していて、Node-REDの良い導入が開発のアジリティ(機敏さ)を高めると考えられます。詳しくは以下の論文を読んでください。
(実は最終原稿の段階でモダンアジャイルの基本理念と対応していることに気付いたので追加しました)

Node-REDから見えた未来 - 変わるもの、変わらないもの - SS2017 WG13 につづく

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

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

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

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

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

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

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

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

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

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

ポケモン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日の記事です。

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

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

はじめに

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

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

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

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

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

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

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

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

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

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

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

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

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

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

状況を把握するには

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

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

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

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

おわりに

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

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

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

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

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

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

より以前の記事一覧