痛みのマトリクス †
要約 †
十分な利益が得られターゲット市場が求められているため、複数プラットフォームのサポートを決定したとしよう。
移植性の困難を最小限にする最も重要なことの一つは、開発やQAが市場の相対優先度を理解していることであり、そのために市場駆動の構成マトリクス(痛みのマトリクス)を作ることだ。
Webベースのシステムを構築し以下のサポートをしたいとする。
- 2つのプラットフォームと5つのOS(Solaris 2.7と2.8、MS Windows NT 3.5.1と4.0とXP Server)
- 2つのWebサーバ(IISとApache)
- ２つのブラウザ(NetscapeとIE)
- 4つのDB(Oracle 8iと9i、SQL Server 7.0と2000)
開発とテストのための可能な組み合わせ総数はOS(5) × Webサーバ(2) × ブラウザ(2) × DB(4) = 80にもなりあまりにも多い。最も重要な構成がカバーされることが保証できる方法で3人でこなせる7〜9つまで切り詰める必要がある。
ステップ1: 構成を減らす †
サポートされているコンポーネントのリストには意味が無いものが多く含まれている。Solaris 2.8でSQL Server 2000を動かしている会社なんて無い! また、マーケテクトが明示的にサポートしない構成を選べる。例えば、重要顧客がSolaris 2.7に移行しないならばOracle 8iはSolaris 2.6のみの対応としたり、その顧客がSolaris 2.7に移行してもシステムが安定している限りOracle 9iではなく8iを使うだろう。
表6-1に不可能な構成を示す。構成の総数は劇的に減っており、Solaris 2.6では1つ、2.7では2つだけになっている。
ステップ2: 構成を順位付ける †
80から39になったがまだ十分に優先順位がつけられていない。次のステップは、他のグループと協力して優先度をつけることであり、これにより物事の様々な洞察を得ることができる。
- 実際にインストールしているか
- 最も収益性が高い、または最も重要な顧客が使っているか
- 次のリリースでマーケティング的に最も販売を促進したいか
- サポート組織が最もサポートしやすいか
- フル機能をテストする必要があるカバレッジを提供する可能性が高いか
様々な手法で上手く優先順位づけが行える。順位付けが終わったら、個々のセルを赤(テストしなければならない)、黄(テストしよう)、青(テストしたいがたぶんしない)に色付けする。
大規模で複雑なソフトウェアの場合、または数字にこだわる開発者やマネージャの場合、数字がよりよい決定につながると信じるならば、各領域を0から1の間の数字で埋め全領域の合計が1になるようにする(表6-2)。
ステップ3: 最終決定を下す †
29は多いのでまだやることがある。このマトリクスを完成させ構成を管理できる数まで絞り込む必要があるため、最低2つのパスをこなす。
最初のパスは、インストールベースの影響を考慮する。20はSolarisを使っており全体売上の53%を占めるとすると、3つのSolaris構成を全てテストし、4から6のMS Windows構成は無視する。
製品マップおよび技術マップ(Appendix B 参照)によるとNT 3.5.1は廃止予定であり顧客も少ないので、NT 3.5.1ベースのIIS、IE、SQL Server 7の組み合わせは(テストしなくても)大丈夫である。
ApacheとNetscapeはテストする必要があることを知っている。さらにほとんどの顧客は長期間NT 4.0ベースであるのでQAはそこに集中させる。
アーキテクチャ的にはデータベースアクセス層はOracleとSQL Server上で同じSQLを使っていることがソースコードレベルで確認できると、Oracle 8iで動作すると他でも動く証拠になる(表6-3)。ただし少なくとも全てのメジャー構成において最低1回はテストすること。
残念ながら、まだ構成数は5つ多い14ある。NT 4.0からIISを除くと4つの構成を取り除ける。最終の表は6-4にリストされている。この構成でテストするか、またはさらに減らす方法を見つける必要がある。
この例は意図的に単純化しており、実際はより多くのバージョンのブラウザ(4〜8)とWebサーバ(2〜4)をサポートし、プロキシやファイアウォールなど他の重要な変数もあり、構成の潜在的な数は劇的に増加する。
優先順位づけるアプローチは構成数が少ない時には上手くいくが、構成要素や各要素の可能値が多いと破綻し始める。これが発生すると、市場ベースの優先順位の前に、より自動化されたアプローチが必要になる。全組み合わせを網羅することなくテストケースをカバーするオールペア法があり、James Bach氏によりwww.satisfice.comにて無料ツールが提供されている。
痛みのマトリクスを理解することでプラットフォームを追加するとシステム関連のトータル負荷が増加することがわかる。
交わす約束に気をつける †
サポートする契約や取引には慎重になろう。かつて「Macintosh OS 8.1以降」対応の契約を引き継いだことがあり、マーケティングチームはコミットしたが、不可能に近いタスクが一気に振りかかるので開発チームは受け入れたくなかった。ポータブルなソフトウェアを作る際には契約には警戒するようにし、少なくともサポートするバージョンとプラットフォームを明確にする。古いバージョンをサポートするならば期限を設けるなど個別のサポートポリシーを明記してもよい。
担当者のつぶやき †
- SolarisだのNTだの時代を感じるが、組み合わせの多さ(iOS、Android、Chrome、Firefox...)とテストの厄介さ(スマホ実機の調達)は何も変わってない。
- 昨今の事情を反映すると、CI/CDのトピックは盛り込まれそう。
- オールペア法のツールでデファクトスタンダードなものがあまり無い気がする。
みんなの突っ込み †
- 表の読み方が一意ではないので注釈が必要だと思いました。また、表の構成についても改善の余地があります。 -- 岡澤?
- 組み合わせの削り方がかなり恣意的なので、総論はいいけど各論が納得いかな感じです -- おかざわ?
