背景
先日、デブサミの後に参加してきたQAイベントでの議論と、
その次の日の業後にあるマイクロサービスメインで扱われている企業のQA部長の方
とディスカッションしてきて感じた内容や発見をここに残す。
前提
ビジネスアーキテクトとして品質管理も担っている自分としては、
ビジネスサイドから品質を考えないなんて言語道断！というマインドがある。
エンタープライズアーキテクチャモデルの4階層を見てもらうのが一番早い。
私たちは、日々手作業のアナログな業務活動に加えて、
情報システムなどを使った業務プロセスと込みで、
全体としてサービス全体を成り立たせて、それをエンドユーザーなどに提供している。
BtoCだろうが、BtoBだろうが、この本質部分は一緒である。
そのビジネスの中で、「ここの連携早くしたい」とか
「この情報は、企業の存続のために死守したい」などという
EAの最上位層であるビジネスアーキテクチャ(BA)層で定義された目的を
残りのデータアーキテクチャ(DA)層やアプリケーションアーキテクチャ(AA)層、
テクニカルアーキテクチャ(TA)層にて実現している。
つまり、各でDA、AA、TA層にて考えるべき品質特性とは、
どこからともなく出てきたものではなくて、出発点はBA層なのだ。
UAF
ビジネスアーキテクチャを考える際に、下図にあるUAFという枠組みを用いると、
非常に論理の乖離などを予防できるし、抽象と具体なレイヤーの一貫性担保、
ステークホルダーとの議論の際に視点合わせの手助けにもなる。
Servicesビューでは、主にサービスを実際に外部から利用する人の視点に立って。
そのServicesの中身には、１つ以上の複数のサービスで構成されていて、
組織内部の人から見れば、そのサービスは自分たちの業務活動の集合で成立している。
内部から見たモデルを考えるのがOperationalビューでの責務である。
Resourceビューでは、１つ１つの構成システムの要件を定義する。
基本的に、Servicesは複数のリソースの提供する機能の集合で成り立っている。
この各ビューでのプロセスや情報に対する指標、
たとえばレスポンスまでの時間 といった指標が、考えるべき品質特性の起点となっている。
注意
もちろん、仮説検証のサイクルと一緒で、
4階層のうち、より下位の層にて上位層の実現が現実的に無理とわかれば、
即座に上位層にその内容をフィードバックし修正をする。
これは案件で自分がよくやっていることだが、
BA層にて「こことここの業務プロセスは別のチームで分担でやらせて、
でもってこんな情報はリアルタイムで常に整合性保ちたい。」
みたいなこと言われたら、
即座にDA、AA層にてその内容が可能なのか？を品質の側面から考え、
「チームを分けずに情報のリアルタイムな整合性を取るのか？
それともチームを分けてリアルタイムな整合性を犠牲にするか？
チームを分けても分けられたチーム間に密な連携がないと両方は取れない。」
ということを図を描きながらステークホルダーに説明したりする。
こんな風にBA層での姿と、他の層での姿の乖離を決して起こさないように、
BA層で定義した姿を実現可能なのか？踏まえながら、適時BAの業務プロセスモデルなどを修正していく。
乖離が起きてしまうと、せっかく時間をかけて考えた品質特性なども
すべて前提から崩れ去る可能性が高いからだ。
発表された内容
ログラスさんでは、QAの方々が積極的にビジネスサイドに関わっていること。
さらにドメインごとの境界付けられたコンテキストでチームを区切るようにしているため、
非機能テストがしやすいとのことであった。
理論の組み合わせ
さらに議論の中で出たのは、
テスト戦略も最もマクロに見た際のKPIを一旦仮決めして、
そこからボトルネックを探しつつ、細かいコンポーネントごとのKPIを定義。
さらにシステムダウンの閾値を探り、
そこを超えないような仕組みを事前につくるという、
徹底されたアーキテクチャ構築の理論が詰まっていると感じた。
たとえばマクロなシーケンス図を描いてみて、その中でパフォーマンス面の
ボトルネックを探してみるていうのは、うんうんうんとなっていた。
BtoB向けのQAをされている伊藤さん曰く、
最初からアーキテクチャ構成を考えつつ、アーキテクチャの脆弱性を出たバグなどから類推しているという。
すでに頭の中で暗算のように演繹法を使い倒して、
アーキテクチャの強みと弱みを見分けているように感じた。
テスト容易性
ログラスさんのお二人が言われていた内容として、感心を覚えたのが、
要求開発フェーズで背景などがない場合には、テスト容易性が低くなりやすいという内容である。
これはQAの二人がビジネスサイドに密に関わっているから出来ることだと感じる。
すでに企画や要求開発フェーズから
「これってテストしやすい状態なの？」という観点で関わっているから、
仮説検証が高速で回りやすく、要求の重大な抜け漏れなどを未然に防止し、
無駄な手戻りを予防できる体制ができているように強く感じた。
そして、改めてやはり機能の内容だけではなく、
その機能を使ってユーザーは誰に価値を届けたいと感じているのか？
背景がないと何をテストしたらいいのか？などは考えようがないので、
改めて背景を大事にしている自分のスタンスは間違っていないと強固なマインドを持つきっかけにもなった。
品質は基本トップダウンで考えるもの
懇親会でのやり取りなどを踏まえてある人に言われたのだが、
品質を考える際に、ボトムアップで考える人が多いそうだ。
どういうことかというと、先程のUAFの例で言うと、
サービス全体で求められる品質という所を起点に、
１つ１つの構成システムの品質というように考えるのではなく、
構成システムの品質からボトムアップに全体の品質を考える人が大勢だという。
同様にして、翌日お会いしたマイクロサービスを扱った企業のQA部長の方も、
各個々のマイクロサービス１個１個の品質管理はできているものの、
それらを複数連携した際の品質マネジメントやテストなどは統制が図れていないそうだ。
これもやはり、トップダウンで品質を考えるのではなく、
ボトムアップで無理やり考えているがゆえだと言われていた。
(※ このQA部長さんはトップダウン思考が得意な方だった)
ボトムアップが完全に悪いと言っているのではない。
あくまでもマクロに見た際の、サービス全体で重要な品質特性の起点となるものは何なのか？を考えた上で、
サービス全体を１段階顕微鏡でズームアップして、
ミクロに見た際の１つ１つのシステムに求められる品質特性として何が挙げられるか？
を考えるのが大前提の基本である。
その上で、実際にリソースレイヤーで書くシステムを連携させた検証を通して、
サービス全体の指標を満たせるのか？を検証したり、
トレードオフ関係にあるもの同士が、互いにそれぞれ指標の最低ラインを満たせるか？
を検証するのだ。
ボトムアップは、あくまでも検証してサービス全体というマクロでの品質指標を
満たせているのか？を考える際の思考回路である。
マクロとミクロレベルでの品質
UAFを見てほしい。
ミクロなResourceビューでは、各構成システムに関心がある。
たとえば、構成システム5個からなるサービス全体があるとする。
ここで各構成システムというミクロに見た際の品質特性が、
マクロで見た際の品質特性に出てくるかというと、Noである。
勿論、各構成システム5個全部で、高い拡張性という特性が定義されてたら
マクロで見た際にも拡張性は品質指標として出てきているはずだ。
何が言いたいかというと、
各構成システムが視えるレベルまで拡大しているResourceビューで視えた品質特性も、
俯瞰してマクロで視た際には小さすぎて視えなくなっている可能性があるということ。
これがボトムアップで品質を考えてしまう際の、最大の罠だと思う。