Capability Based Planning について

Enterprise Architectureの方法論であるTOGAFにCapability Based Planningという考え方が紹介されている。

システム開発のプロジェクトでは、如何に実現するか？（HOW）に議論が行きがちである。
例えば、ソリューションの選定、機能比較。特に画面イメージは理解しやすく、意見しやすいため、要件定義の初期あるいは、企画段階からどんなものがいいかなどという議論に時間が費やされることもある。

企画段階や要件定義の初期で重要なことは、なんのために（WHY）、何をしたいか（WHAT）である。あくまでもアプリケーションは手段（HOW)なのである。

Capabilityは、ビジネス上の業務遂行能力（WHAT)を定義したものである。手に入れたいCapabilityがあって、その実現のためにアプリケーションが存在するという点を明確にしやすいメリットがある。

TOGAFの解説では、Capability Based Planningの進め方として、
MAP　→　ASESS　→　PLAN　→　CONTROL
が紹介されている。

MAPでは、手に入れたいCapabilityと現状の業務・アプリケーションをマッピングする。
当然、現状では足りない箇所も出てくるが、まったく無から新しいCapabilityを作ることは稀で、殆どが現状の業務やアプリケーションを活用したり、発展させて実現することになる。

ASSESSでは、実現したいCapabilityから見て、現状を評価する。
Capabilityには成熟度がある。また、Capabilityは分解することもできるので、要素ごとの成熟度を色分けしてマッピングすると現状と理想のギャップがわかりやすくなる。
Capabilityの要素としては、アプリケーションの機能や連携といった能力や業務上の能力などが含まれる。

PLANでは、フィージビリティスタディとセットで最初に目指す成熟度のレベルを検討する。これ以降は、一般的なプロジェクト管理と変わらない。

一般にシステム改修・導入のプロジェクトでは、現状分析から始められることが多いが、分析フェーズにやたらに時間が掛けられるわりに、後から振り返るとあまり役に立てられないというケースが多い。

それに比べて、Capability Based Planningのトップダウンのアプローチは有効に見える。現状分析は、ASSESS＝最初からTOBEとのギャップとして、明確に定義されている。

成熟度という考え方も重要だ。現代のシステムは導入はほとんど始まりであり、そこからチューニング・改善していくことこそが重要だからだ。