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

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

• ポケモンGOで考えるリスクマネージメント(1/3) リスク対応の種類

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

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

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

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

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

ウォータフォール

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

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

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

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

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

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

参考：

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

• アジャイル開発の「考え方」と「やり方」を学べ

アジャイル

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

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

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

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

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

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

参考：

• アジャイル開発の理解に必要な３つの視点

• リーンを考える - 無駄と必要なアソビ -

【12/21追記】

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

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

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

CCPM

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

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

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

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

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

参考：

• CCPMのグッときた話 - TOC/TOCfE関西分科会 -

• ボトルネックはお早めに！ -- CCPMのワークショップに参加して TOCcafE@OSAKA -

まとめ

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

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

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

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

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

参考：

• 新技術に踊るなかれ！

• アジャイルを考える - Agile Tour Osaka 2011 -

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

おまけ

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

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

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

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

参考：

• [#agileto2012] 『チェンジ！』の考え方 ～マネしやんと！～