Bridging the gap between intention and execution — from process maturity to test architecture.
Process Maturity and Result Reliability — CMMI and TMMi
業界でよくある誤解は、ウォーターフォールとアジャイルを思想的な対立として位置づける。行動レベルでは対立は現実のものだ。しかし、より深いレベルでは、両者ともにプロセス実行のインスタンスであり、その成果の質は同じ基本変数、すなわちプロセス成熟度によって支配される。
Capability Maturity Model Integration（CMMI）は、ソフトウェア開発ライフサイクル全体にわたる組織のプロセス成熟度を測定・改善するためのフレームワークを提供する。その5つの成熟度レベル — 初期、管理済み、定義済み、定量的管理、最適化 — はアドホックな実行から体系的な自己改善プロセスへの軌跡を描く。
Test Maturity Model Integration（TMMi）はテストプロセス向けの補完的なフレームワークである。CMIがSDLC全体をカバーするのに対し、TMMiはテストのみに同じ成熟度レベル構造を適用する — 初期状態（混乱したあとから考えるテスト）からレベル5（欠陥防止が主要なテスト目標）まで。TMMiとCMMIは明示的に一緒に使用するよう設計されている。
因果連鎖：プロセス成熟度 → プロセス予測可能性 → 結果信頼性。MIM2000のアドバイザリーエンゲージメントでは、CMMI/TMMiレンズを診断的に適用する：クライアントのプロセスが成熟度スケールのどこに位置するかを評価し、品質やスケジュールのばらつきを引き起こしている特定のプロセス領域を特定し、的を絞った改善を推奨する。目標は手直しコストの測定可能な削減であり、認証それ自体ではない。
References: CMMI Institute, TMMi Foundation (R1.2), ISO/IEC 15504.
UML — The Best Standard That Cannot Guarantee Understanding
統一モデリング言語（UML 2.x、ISO/IEC 19501）は、これまで標準化されたソフトウェアシステムモデリングの中で最も包括的な記法であり — 構造的・振る舞い・インタラクションビューをカバーする14種類のダイアグラムタイプを持つ。これほどの広さを達成した記法は他にない。
根本的なパラドックス：UMLは定義された文法を持つ形式的な視覚言語である。その文法への準拠は検証可能だ。しかし、伝達されたモデルの理解は検証できない。シーケンス図は構文的には完璧でありながら、4人の読者に4つのまったく異なる意図された振る舞いを同時に伝えることができる。文法の正確さはセマンティックなコンセンサスを保証しない。
これはテスト分析に直接影響する：テストアナリストに「要件仕様書」として渡されるUMLシーケンス図は、しばしばロールシャッハテストである。各アナリストは記法が埋めない空白に自分自身のシステム前提を読み込む。結果は意図したシステム動作ではなく、アナリストのメンタルモデルをテストするテストケースとなる。
UMLダイアグラムは調整の成果物であり、真実の成果物ではない。すべてのダイアグラムには、記法が暗黙のままにしている決定を明示する書面によるナラティブが必要だ。ナラティブなしでは、形式文法は共有された理解への偽りの確信を生み出す。
References: Fowler — UML Distilled (3rd ed.); Rumbaugh, Jacobson, Booch — UML Reference Manual (2nd ed.); ISO/IEC 19501:2005.
SW Testing Services — Advanced V-Model and Test Architecture
Vモデルは各開発フェーズを対応するテストフェーズにマッピングする。拡張Vモデルはこれに明示的な成果物依存関係とテストアーキテクチャ層を加える — テストシステム自体を設計するエンジニアリング規律。
| Development Phase |
Test Phase |
MIM2000 Service |
| Business Requirements | Acceptance Testing | Test Analysis |
| System Requirements | System Testing | Test Analysis + Test Design |
| Architecture Design | 統合テスト | Test Design + Test Architecture |
| Detail Design | Component Testing | Test Design + Test Data |
| Implementation | Unit Testing | Test Deployment + Execution |
テストアーキテクチャの決定事項：どのレベルで何をテストするか、どのツールを使うか、どのデータで行うか — ITプロジェクト全体のアーキテクチャに合わせて。主要な領域：レベルごとのテスト範囲、テストレベル間の境界条件、テストデータ戦略（ライブサブセット vs モック vs 生成）、環境トポロジー、自動化の境界。
Test Automation — Advantages and Limitations
まずAPI/サービス層で自動化する — 最も安定したコントラクト。UI自動化は安定したセレクターを持つクリティカルなユーザージャーニーのみ。探索的テストは絶対に自動化しない：価値は人間の認知的関与にある。アサーションや範囲が誤っていれば、システムが誤っていても自動化テストはパスする可能性がある — 偽の信頼は自動化なしよりも危険だ。
→ Testing & Engineering Blog — field notes by Petr Žemla, CEO & CTO
ソリューションアーキテクチャ
アーキテクチャ上の意思決定サポート、テクノロジースタック選択、統合パターン設計、スケーラビリティ評価。ビジネス要件と技術実装の実現可能性の間のギャップを橋渡しする。
Detailed content in preparation