前置き
トレードオフ関係にある品質属性を踏まえてのアーキテクチャ考察で悩んでいた時に
思い付きに近い形で立体図形的に捉えることで色々整理がついたので、その内容を以下に残すことにする。
マイクロサービスなどだけでなく、よりミクロな量子のコンポーネント設計の際にも
それだけでなく、そもそもの要求分析をする際のデメリット分析においても大事になってくる考え方なので、是非とも基本にしていただけたらと思います。
前提
アーキテクチャを決定する際の事項として、
優先度の低いような品質属性はいっそのこと無視してしまい、
あらかじめ「この定性的ポイント数以上のものの品質軸でのみ考察する」というものをざっくりでもいいので決めておくといい。
すべての品質属性を盛り込んだアーキテクチャの決定は典型的なアンチパターンである。
あ、あと後述で匠メソッドというワードが出てくるのですが、
その詳細はここで書かないので気になった方は、ググっていただけたらと。
一言でいうと、価値駆動で要求を抽出し、最も関心のある品質変数をあぶり出すことです。
トレードオフマトリクス
代表的な品質属性同士のトレードオフの関係性をまとめたものとして以下がある。
【出展元：ソフトウェア要求 第3版の14章より】
もちろん各プロダクトや外部環境、その組織文化などの影響によって例外的なものもあるけれども、まずはこの品質属性とどの品質属性が共に＋の関係性なのか？
どの品質属性とどの品質属性が－のトレードオフ関係になるのか？程度は把握しておいた方がいい。
個人的には、テスト容易性とメンテ性がなぜともに＋の関係性になるのか？
といったメカニズムは定性的に証明できるようにしておいた方が良い。
ただし注意点として、品質属性Xを10下げたからといって、
反対の位置にあるトレードオフ品質属性Yが10向上するわけではない。
またYを10下げたからといってXが10上がるわけではない。
それは品質属性XとYの重みが同じ程度である保証はないからである。
コンテキストに依って重み付けが変わる
ステークホルダーの関心の強さによってトレードオフ関係にある品質属性同士の重み付けは異なる。
また市場の流行やら、個人情報保護法などの法律の変化といった外部要因や、
自社の内部要因(事業方針の方向性)の影響によっても変わってくる。
例えば安全性とトレードオフ関係にある性能を例に挙げてみると、
自社のあるプロダクトにおいて、安全性と性能の比重の比率が仮に5:2であったとする。
だからといって、自社の他のプロダクトにおいても同じ5:2の比率である保証はどこにもない。
ただし、コンテキストが上記と非常に近いとみなせる別のコンテキストの環境においては、安全性と性能の比重の比率はおおよそ5:2と類推ができる。
なので、完全に重み付けを推測できることは、困難ではあるが、
他の事例や過去の事例(自社でも外部でも)などに同じようなコンテキストのプロダクトがないかな？と調べてみると、過去の品質属性同士の比重がある程度類推できる。
トレードオフ分析をする上で大事な思考
何となにの品質属性はトレードオフと暗記しても、適当に定性分析しても全く意味がない。
テスト容易性とメンテ性の相関関係や、
セキュリティとパフォーマンスのトレードオフ関係などのように
特定のコンテキストに依らず法則的に成立するものに関しては、
自分で証明できるようにしたうえで、他の複数の品質属性を踏まえた場合に、
どのようにして総合的に考えるか？がアーキテクトとしては重要に感じる。
そこで私のおススメの方法を以下に紹介する。
立体的に捉える
トレードオフの品質属性同士の考察をする際にも、
要求同士にトレードオフ関係がある場合に、この天秤図などを思い描いてみるといい。
この天秤で比較できるのは２つのトレードオフ関係にある品質属性同士だけである。
さらに複数の品質属性の観点も考慮しなくてはいけない場合にはどうしたらいいだろうか？
この天秤の真ん中の軸を回転軸とみなして、ちょっとずつ回転させればいい。
たとえば合計6つの品質属性の軸で考察したい場合を想定してみよう。
上図の天秤を60°ずつ回転させたものを真上から見た図として下図のような六角形を思い描いてほしい。
すると下図のような六角形になっている。
丁度正反対の位置にある完全にトレードオフ関係にある要素同士の配置関係は、
この六角形の対角線上、
つまりAとD、BとEなどが強いトレードオフ関係にある状態の配置構成であると言える。
ちなみに正三角形にしたトレードオフ分析として、QCDトレードオフがある。
あの考え方を応用したのがこっちの考え方である。
何がうれしいか？
こうすることによって何がうれしいか？というと、
六角形を描いた平面紙を地面に対して水平に手にもってみてほしい。
その状態で、品質属性Aは現状のまま(つまりAの位置は固定のまま)、
品質属性Bをより向上させようとすると、Cの位置はほぼ動かないとみなせるが、
品質属性F、E、Dたちは劣化してしまうという仮説が図形的に簡単にわかる。
あとはそのうえで「本当にその通りになるか？」を品質テストで実験し、
前提条件である六角形の各頂点にプロットされた品質属性の位置関係を演繹的に検証すれば、そこでの発見をもとにより精度の高い六角形モデルを作成できる。
もしも実験で仮説通り、品質属性F、E、Dたちが劣化してしまうようであれば、
前提として考えた品質属性の配置関係は妥当であったといえる。
逆に仮説通りにはならず、たとえば品質属性Dが向上してしまったとかいう結果が得られたら、今の仮定の配置関係はおかしいということが判明することになる。
このように品質のテストは、単に非機能面において指標を満たせているのか？という検証をするだけの役割にとどまらず、図形的にトレードオフ分析を楽に行うための発見や気づきにもなることを忘れないでほしい。
ただしその配置関係は現時点での品質属性同士の図形的位置関係のスナップショットに過ぎないことを忘れないでほしい。
※時間経過などで配置関係が変わる
内部環境の変化や外部環境(要件の仕様変更)などによって、要素の位置関係は変化していく。
たしかにその影響を受けにくい不変的に近いような品質属性同士の関係はあります。
ただし、それの重みがどの程度のものなのか？まではテストなどを通して定量的な実験をしてどの配置関係にあるか？をその事実から図形モデルに仮説ベースでプロットしていく。
※技術革新でも配置が変わる
品質属性同士のトレードオフ関係は、どうしても技術の制約を受けてしまう。
今現在の技術においてトレードオフ関係であったとしても、
たとえばその技術的制約を取っ払うような革新が起きた際には、
上手の六角形において、AとDの位置関係にあった品質属性が技術革新によって
AとBの位置関係に変わるなんてことも大いにありうる。
大事なのは、仮説を証明するために継続的に品質テストをして図形的配置関係を明らかにし続けることである。
ボトムアップにビジネス側へフィードバック
何かの品質を改善しようとすると、必ずそのトレードオフ関係にある品質属性が犠牲になる。
安直にステークホルダーである顧客に「もっと早くして」と言われたからといって、
それをそのまま実現するなんてことしたら、それに伴う様々な品質属性が低下してしまう。
＋の側面だけを考慮して、その180°向こうから見た－の側面からの考察をしないのは、
アンチパターンである。
失敗しているマイクロサービス化プロジェクトでは、
マイクロサービス化することによる＋の側面だけをみて、データが同期的に整合性担保できなくなるなどの－の側面を十分に考慮できていないことが多々ある。
よって、早くするというパフォーマンス品質向上によって得られる恩恵側からの考察。
パフォーマンスという変数を変化させることに伴って、
パフォーマンスと正の相関関係にある効率性という品質属性観点での恩恵。
対して、パフォーマンスを増加させることで－に働いてしまう複数の品質軸からのビジネス上、－になると思われる脅威シナリオもセットで考える。
こうすることによって、一見うれしさに働くと思われる側面だけでなく、
それに伴う代償としての側面をプリズム的に考えることで、両側面から総合的に見たうえでの価値を考えられる。
匠メソッドにおける価値記述
匠メソッドの価値分析における価値記述では、＋の側面からのストーリーを考えているが、
上記のように個人的には、その＋の側面からだけではなく、
別のモデルとして【脅威記述】という－側面もセットで考えておく。
価値記述を実現するのに、より詳細化していった際にユーザーストーリーの段階で、
重要な品質属性が仮にA、Bの２つだと判明したと仮定する。
その品質属性とはトレードオフ関係にある品質属性C、Dからの脅威シナリオを考え、
ボトムアップに脅威記述へと反映させるのである。
出来上がった価値記述と、脅威記述を見比べて、定性的にポイントをつけてみる。
両者合算して総合点として－になってしまったら、
脅威に対する関心の方が高い。つまりは品質属性C、Dの方が比重が大きいってこと。
補足 -ケイパビリティ間の力学-
事業戦略の要素である、ビジネスケイパビリティ要素同士にもトレードオフ関係の力学は働く。
たとえば戦略要素である【攻撃能力】と【防御能力】。
これらが下位の事業戦術(サービスアーキテクチャを考えるレイヤー)層以下の層で、
必ずどちらかを向上させると、もう片方が下がるという構図であったと仮定する。
この場合には、【攻撃能力】と【防御能力】は互いにトレードオフ関係の力学がメカニズムとして働いていると仮説を立てられる。
このメカニズムはその組織の風土なども反映するので、
他のビジネスでも【攻撃能力】と【防御能力】は互いにトレードオフ関係とは言い切れない。
今回は【攻撃能力】と【防御能力】は互いにトレードオフ関係であると仮定した場合の例を考えてみることにする。
この時に、このトレードオフ関係にある２つの要素を組み合わせた戦略をとる場合、
どのようなアーキテクチャ案が考えられるだろうか？
どちらか一方が強く求められる場合
攻撃能力もしくは、防御能力がもう片方に比べて、非常に強く求められる場合において。
今回は攻撃能力の方が防御よりも非常に強く求められる場合を考える。
ざっくりした比率で言ったら、5:1くらい。
その場合には、もう少ない方をいっそのこと無視した案を最初から考えてもいい。
なぜかというと、これも定性的なポイントにはなるが、
攻撃能力を向上させることで得られる恩恵のリスクポイント数1と、
防御能力を無視することによって発生するマイナスなリスクポイント数5が同等であるので、
よほどマイナスなことが高頻度で起こるとか、それによって事業継続性が大幅に下がるとかでない限りは、1/5の比重なわけだから最初から無視してもいい。
そのうえで、攻撃能力を高める際の重要な品質変数の軸のみに厳選してアーキテクチャ案を考える。
ただし、ステークホルダーの中に比重の非常に少ない方を高めてほしいと叫ぶ方がいた場合には、その方に事業全体では防御能力はわずかしか求められないことを納得してもらわないといけません。
両立が求められる場合
実際にはこちらの方が多くの場面で求められると思います。
この場合には、上記の片方に比重が傾いているアーキテクチャ案はベターな案ではなくなります。
事業全体では攻撃能力と防御能力で大体、5:3程度の比重であるとしましょう。
いきなりマクロなアーキテクチャで評価が難しい場合には、
1段階詳細化したコンポーネントで評価したり、各抽象度に応じたある切り口で評価したり。
ようは具体と抽象を複数の角度で行き来するわけです。
東側からみたマクロなアーキテクチャ～ミクロなアーキテクチャ。
西側から見たマクロなアーキテクチャ～ミクロなアーキテクチャ。
北側から見たマクロなアーキテクチャ～ミクロなアーキテクチャ。
南側から見たマクロなアーキテクチャ～ミクロなアーキテクチャ。
といったように。