日本のアジャイル開発の先人による話が良かった

日本のアジャイル開発の先人による話が良かった。
ラフな感想をメモ。

【参考】
根回し、本音と建前……透明性が大事なアジャイルは、日本の慣習とどう折り合いをつけるべき？【平鍋健児×市谷聡啓×岩瀬義昌】 - エンジニアtype | 転職type

2000年頃からアジャイル開発がIT業界の技術もプロセスも先取りしていると気づいた人たちが、アジャイル開発を日本で導入し運用し始めてもう20年以上経つ。
ようやくアジャイル開発も日本で知名度が上がってきたが、まだメインストリームでない所が大半だろうと思う。
そんな中で平鍋さん、市谷さんの経験談や気づきに共感する所が数多くあった。
たくさんの経験を踏まえて、日本の風土に合うアジャイル開発のあり方が見えてきたのかな、と思う。

平鍋さんの発言録を読むと、日本人の風土をすごく理解されていて、琴線に触れるような言葉があるなと思う。

たとえば、アジャイル開発は「仲間作りの旅」ですよ、とのこと。
岩瀬さんが言われる通り、スクラムをやっていても、スクラムマスターやプロダクトオーナーはチームに1人しかいないので孤立しやすい。
だから、チーム外のステークホルダーだけでなく、チーム内のメンバーからも突き上げを食らったりする時もある。
そんな時は精神的にも辛い。
日本人の組織やチームはウェットなので、モチベーションアップのためにも、仲間という雰囲気作りが大切と思う。

たとえば、日本の大企業に根回し、建前があって透明性を求めるアジャイル開発と相性が悪い所がある。
しかし、平鍋さんは根回しは好きです、と言われる。
この人が反対するとプロジェクトが進まない、という状況であれば、悪い状況を最小限にするために、その人に早めに話をする（根回しする）のはありでしょ、と。
そういう人には割と感情的な部分もあるだろう。
そういう部分は日本の風土に合った現実的な解決策だなと思う。

アジャイル開発を堅苦しく考えないところがいいなと思っている。

テストアーキテクチャ設計モデルとJSTQB概念モデルの比較

平鍋さんのテストアーキテクチャ設計モデルと、自分が書いてみたJSTQB概念モデルを比較してみた。
気づきをラフなメモ。

【参考】
JaSSTで話題になったテスト設計をモデル化してみた - Qiita

JSTQBのテストプロセスの概念モデルを描いてみた: プログラマの思索

平鍋さんのテスト設計モデル.pdf from akipii Oga

テストアーキテクチャ設計モデルはかなり抽象化されたモデルと思う。
テスト評価層、テストアーキテクチャ設計層、テスト種別層、テストケース層に分かれている。

テストアーキテクチャは、システムアーキテクチャに基づくテスト設計かな？
たとえば、システム特性ごとにテストアーキテクチャは全く異なる。
組み込みソフトウェアであれば生命に関わるようなリスクは極力避ける必要があるから、安全性の観点のテスト設計が多くなるだろう。
一方、マイナンバーカードシステムのようなBtoCの基幹系システムであれば、個人情報保護が非常に重要だから、セキュリティの観点のテスト設計が多くなるだろう。
つまり、テストアーキテクチャはシステム特性に大きく依存しているはず。

テストアーキテクチャはテスト評価層で評価される観点が興味深い。
テストアーキテクチャ記述とステークホルダーが結びついている。
つまり、マネージャ、利用ユーザ、プロダクトオーナー、品質保証部門などの観点でテストアーキテクチャ記述はレビューされて評価される。
ステークホルダーごとにレビュー観点は異なるから、そういう視点が反映されている。
この点は非常に重要だ。
「このテストは誰のためにあるのか」という問いにつながるからだ。

テストコンテナという概念でテスト種別を表す点も興味深い。
最初に見た時、テストコンテナとは何だろう？と思った。
テストコンテナは、コンテナ分割方針によってグループ化されており、コンテナ分割方針はテストレベル、テストサイクル、テストタイプなどがある。
つまり、テストコンテナは、工程や品質特性、テスト期間の観点で組み立てられたテスト方針のように思えた。
おそらく、システム特性に応じたテストアーキテクチャを具体的に実装する場合、具体的にどんなテストが必要になるのか、というテスト内容が含まれていると考える。
すなわち、システムやプロジェクトごとにテスト方針がテーラリングされていることを示しているのだろう。

テストタイプにソフトウェア品質特性が関連付けられているのもミソだ。
つまり、8つのソフトウェア品質特性の観点に対応付けられた非機能テストがあることを示している。
たとえば、性能テスト、負荷テスト、耐障害性テスト、セキュリティテスト、移植性テストなど。
この考え方は「ソフトウェアテスト教科書 JSTQB Foundation 第4版 シラバス2018対応」にもあったから、自分のJSTQB概念モデルに取り入れさせてもらった。

テストケース層でテストスクリプトが中核にあるのは、自動テストを意識されているからだろうと思う。

JSTQB_テストプロセスの概念モデル改善版.pdf from akipii Oga

一方、自分のJSTQB_テストプロセスの概念モデルはかなり具体的だ。
テストプロセス層とテスト成果物層で分けている。

テストプロセス層では、テストプロセスを中核として、テストプロセスを分析する観点が盛り込まれている。
テストプロセスとは、テスト計画～テスト完了までの一連のテスト活動から成り立つ。

そのテストプロセスは、テストレベルという工程ごとにコンポーネントテスト、統合テスト、システムテストなどで具体化される。
また、テストタイプというテスト種類ごとに、性能テスト、負荷テスト、使用性テストなどの品質特性ごとのテストプロセスもある。
一方、テストプロセスはテスト戦略で規定される。
テストアプローチはPJごとのテスト戦略のインスタンスとみなすから、テスト戦略とテストアプローチは継承関係にした。

テスト成果物層は、主にテスト項目書から成り立つテスト成果物だ。
テスト項目書、つまりテスト仕様書は、下記の観点で分解してみた。

テストアイテムとは何か？概要や定義、現場での使われ方について解説

テストケースを各要素ごとにばらす。
・テスト対象＝対象画面・帳票
・テストアイテム＝画面・帳票項目
・テストスイート＝特定のテストサイクルで実行されるテストケースやテスト手順のセット
・テストサイクル＝テストの開始日時、終了日時

「ソフトウェアテスト教科書 JSTQB Foundation 第4版 シラバス2018対応」では細かい内容が多く、現場で使われる用語と違うので、概念モデルを書かないと理解しにくい。

たぶん、自分のJSTQB_テストプロセスの概念モデルをもっと抽象化して洗練させれば、テストアーキテクチャ設計モデルとマッピングできるだろうと直感している。
この辺りは気づきを残していく。