昨今、IT が社会の構造そのものを変える勢いで企業に変革を迫っています。

このようなビジネスの変化を表すキーワードとして2010 年頃からビジネスの世界で使われるようになったVUCAという言葉があります。

VUCAには守りのVUCA対応と攻めのVUCA対応があります。
このコラムでは、守りのVUCA対応についてお話します。

変化を象徴する4つのキーワードの頭文字をとったものです。

① Volatility  — 変動性

クラウド・AI・IoT・ブロックチェーン・・・今まさに ITによるパラダイムシフトが起きており、ビジネス環境は急速に変化しています。

② Uncertainty — 不確実性

ベンチャー企業の台頭などこれまで無かった先行きの読めないビジネス環境は、企業に不確実性への対応を迫っています。

③ Complexity  — 複雑性

システムは肥大化、複雑化の一途をたどり、それはこれからもより一層顕著になっていきます。

ただでさえ、複雑なシステムは変化に追従することでより複雑になっていきます。

④ Ambiguity   — 曖昧性・不明確さ

変化に対応しようとする場合、そこには経験したことの無い問題が発生します。

この前例のない問題に対応するには、すべての判断材料を揃えて判断することは難しいことがあります。

 

変革の必然性とリスクのジレンマ

しかし、急激な変化の対応はリスクも伴います。

旧来から長い年月、多くのお客様を抱える企業は新興勢力のように安全性を犠牲にしてビジネスを推進する訳にはいきません。

リスクが顕在化してしまった一例が、先般の仮想通貨の流出事件です。

新しい勢力の台頭は、既存の歴史ある大企業に大きな脅威を与えます。

しかし、老舗企業は新興勢力のように無鉄砲なことは出来ません。一方で、変革しなければ生き残れません。

つまり、安全に変革するという一見ジレンマのようにも見えるこの2つを両立する必要性に迫られているのが現在の日本の大企業の状況と言えます。

変革の必然性とリスクのジレンマを解決する方法

ビジネスの変化要求に合わせるようにアジャイル開発やクラウド利用が浸透し始めています。

これは、アジャイル開発やクラウド利用が VUCA の特性に合うからです。

これまでのオンプレミスの世界では、VUCA はリスクとして捉えられ、徹底的にその要素を排除してきました。現状、アジャイルやクラウドを先行採用している企業では、ビジネス変化への追従を優先し、安全性には課題がある場合も多いのが現実です。


しかし、リスク収束フレームワーク(RCF) があれば VUCA に対応しつつ、安全性を担保することが可能になります。

リスク収束フレームワ-ク(RCF) が VUCA に対応する方法

まず、RCF が VUCA の各要素へどのように対応するかを見る前に、そもそも品質を保証するために必要な要素を見ていきます。これには以下の 2 つの要素が必要です。


 Ⓐ品質の target(何をどこまで品質保証するのか)を決める
 Ⓑ品質 target は費用対効果・制約・残存するリスクなど様々な要素を総合して判断する

RCF は、まずこの前提条件を満たしています。

非機能要求グレードを始めとした現状の他の手法はこれを満たしていないこと、特にⒷを満たしていません。

次に RCF がどのように VUCA に対応していくのか見ていきましょう。


① Volatility  — 変動性

RCF は、以下のことが出来ることで変動性に対応します。
・変動があった箇所について、新たな品質 Target を決定できる
・それまでの品質 Target への影響が迅速にかつ網羅的に分析できる
・リスク収束マトリックス(RCT)によりプロジェクトのステークホルダーへ簡潔に全体像と影響を説明できる

また、運用フェーズでは継続的にビジネスの変化に追従するために DevOps が必要になるケースがあります。DevOps により継続的にシステムは変動します。RCF が変動性に対応していることで、DevOps によりシステムが常に変化してもリスクはすべて RCF によりコントロールされます。


② Uncertainty — 不確実性

ビジネスの不確実性への対応は、システムの不確実性への対応を要求します。

これまでのオンプレミスでは、確実性が様々な領域で保証されていました。

しかし、この確実性を必ずしも持ち合わせないのがアジャイルやクラウドです。

不確実性は、品質にとって最大の難敵です。

これまでのオンプレミスでは、この不確実性を排除するために様々な努力が積み重ねられてきました。

アジャイルやクラウドは、ビジネスの不確実性に対応出来る代わりに、それそのものが不確実性を持つものです。これはアジャイルやクラウドの品質に対する必要悪とも言えるものです。

しかし、RCF があれば、アジャイルやクラウドの不確実性に対応することが出来ます。

RCF は、品質 Target が明確に出来るため、不確実性というリスクが表面化した際に、その影響を現実的に分析でき、品質 Target との乖離を正しく認識することで対策が施せるようになります。

③ Complexity  — 複雑性

複雑性は、人を混乱させ、正確な判断を鈍らせます。

これまでのオンプレミスでは、複雑性のみに対応すればよかったのですが、現代のシステム開発ではこれに変動性・不確実性・曖昧性などが加わり、更に人々を混乱に陥らせます。

混乱を避けるには、
 ・可視化できること
 ・属人性を排除できること
 ・すべてのシステムに対応できること
 ・すべての検討要素において同じ方法論でアプロ―チできること
が必要になります。

RCF は、この要件をすべて満たしたしているフレームワークです。

どんな大規模システムで複雑なシステムでも RCF はビジネス要求を正確に表現することが出来ます。

これに加えて変動性・不確実性・複雑性・曖昧性に同時に対応できることで、ビジネスの変化に柔軟に対応しつつ品質を保証することができるようになります。

④ Ambiguity   — 曖昧性・不明確さ

システムの品質保証において Ambiguity が発生するケースは、Ⓑに関する事項です。

どのくらいコストがかかるのか、どのくらい効果があるのか、どんな制約があるのか、残存リスクはどんなものがあるのか、すべての情報が正確に揃うとは限りません。

このような不明確な状況においても、その時出来る得る最良の判断が出来るフレームワークが RCF です。

更に入力情報が変われば、リスク収束マトリックス(RCM)の更新によりFIT&GAP 分析と対策立案が容易に行え、RCT によりステークホルダーへの報告性が適切に行えることも RCF の特徴です。


おわりに

このようにRCFは守りのVUCAに対応できる唯一のフレームワークです。

デジタル化時代を乗り切るには、このようなリスクマネジメントが必ず必要になってきます。

何か重大なインシデントが起きてからでは遅いのです。