「ソフトウェアアーキテクチャ・ハードパーツ」の情報リンク～マイクロサービスの設計技法の課題は何なのか

ソフトウェアアーキテクチャ・ハードパーツ ―分散アーキテクチャのためのトレードオフ分析を読んでいて、まだ中身を理解できていない。
ネット上の感想記事を自分用にリンクしておく。

【参考】
『ソフトウェアアーキテクチャ・ハードパーツ』 - Don't Repeat Yourself

（引用開始）
また、最近話題になっていた『ソフトウェアアーキテクチャの基礎』（以降、「基礎」）を執筆した著者陣が書いたもう一冊の本でもあります。
「基礎」はアーキテクトとしての姿勢や、それぞれのアーキテクチャの簡単な概要が中心でしたが、この本はより実践に近く方法論寄りです。「基礎」が「What」を扱うとすれば、本書は「How」を扱うといった関係性でしょうか。
（引用終了）

（引用開始）
現代ではデータをどのように設計し、分割しつつ整合性を保って保管しておくかといった一連の流れの重要度が増しています。この問題についても本書は拾い上げるよう努力しています。[*1]
従来のアーキテクチャの議論では、マイクロサービスはどう分割するかとか、コードの関心事がどうこうとかそういったアプリケーションに限った範囲が中心だったように私は思っています。が、そうではなくデータをどう分割、配置、保管していくかといった問題についても議論に含めるようにしています。
（引用終了）

『ソフトウェアアーキテクチャ・ハードパーツ』完全に理解した - Mirai Translate TECH BLOG

（引用開始）
一言で言うと
「マイクロサービスの大きさと通信方式をどう決定するか」について書かれた書籍です。
（引用終了）

ソフトウェアアーキテクチャ・ハードパーツ - Forkwell Library #12に参加してきた - 天の月

（引用開始）
レガシーで大規模なモノリシックシステムをどう解決していくか？というのを物語形式で紹介してくれているということです。

ソフトウェアの中でも土台となるような部分の決定は「モノリシックなシステムをどう分解していくか？」で前半部分に表現され、「ソフトウェアアーキテクチャをどう決めるか？」は分散システムで直面する難しい問題をどのように決定するか？で後半部分に表現されているということです。

もう少し具体的に言うと、前半部分は戦術的フォークとコンポーネントベース分解を中心に登場人物がトレードオフ分析を行なっている様が描かれており、後半部分は、粒度分解要因と粒度統合要因のバランスによって決定されるという前提をもとに、分解をどこまでするかが具体的に描かれているそうです。
（引用終了）

「ソフトウェアアーキテクチャの基礎」読書感想

【1】「マイクロサービスの大きさと通信方式をどう決定するか」が根本テーマであるとすれば、マイクロサービスの設計上の課題や留意点がテーマになる。

2020年代の現在では、マイクロサービスの実装はAWSなどのクラウド基盤が前提条件だろう。
AWSならEC2ではなく、CloudFormationを使って各種サービスを組み合わせて一体化したシステム設計をするのではないか。
一方、オンプレ環境のシステムでは、弾力的なスケーラビリティ向上、つまりスケールアップやスケールアウトを動的に変更するのは非常に難しい。
逐一サーバースペックをサイジングしてどれだけのスペックを持つべきか見積もりして導入するまでに非常に手間がかかる。

では、マイクロサービスの落とし穴はどこにあるのか？
マイクロサービスの利点や美味しいメリットを得るにはどんな留意点があるのか？

モノリシックな基幹系システムやモノリシックな巨大なシステムをビジネス上の観点でサービスごとに分割して、分散サービス化した時、それぞれのサービスの粒度は小さくなるので運用保守しやすくなる点もあるだろう。
昨今のDevOpsの観点では、小さな開発チームが設計や開発から運用までを担当する流れなので、チームが担当するシステムのサイズは小さい方が実現しやすい。

一方で、複数のサービスを連携して初めて、顧客が満足する1つのユースケースが成り立つような場合、途中でサービスが停止すると成り立たなくなる。
分散サービスのアイデアは20年以上前のCORBAやEJBからずっと言われていては失敗してきたが、クラウド基盤でようやく実現可能な設計手法になった面もあると思う。
僕はまだAWSやクラウド基盤のことは無知なので、今までのオンプレ環境で構築するシステム設計とは違った観点がマイクロサービスの設計にはあるのだろうと思う。

理解できた内容はBlogに残しておこうと思う。

パッケージ原則とクラス原則の違いは何なのか

パッケージ原則とクラス原則の違いについて考える時があった。
直感的なラフなメモ。

【参考】
パッケージ設計の原則を本で学ぶ - Qiita

イラストで理解するSOLID原則 - Qiita

パッケージ原則を見ると、パッケージの凝集度3つ、結合度3つの観点に分けられる。
その内容は、クラス原則であるSOLID原則をパッケージ版に拡張したように思える。

実際、単一責任の原則はパッケージの凝集度に関連するし、開放閉鎖原則はパッケージ版も同様だ。
インターフェイス分離の原則やLiskocの置換原則は、パッケージの結合度に関連してくる。

ただし、その違いはある。
1点目は、パッケージやコンポーネントの観点では、リリースできる単位が再利用できる観点と同一になる原則が最も重要になる。
理由は当たり前で、リリースして他ユーザが使えるようにするからには、他の人が再利用できる観点と同一にならざるを得ないから。

リリースモジュールは単独で動くものである一方、クラスは単独では動作できず、複数のクラスを結合して初めて一つの画面や帳票、バッチなどの機能を形成する。
この違いは大きく、再利用の観点も他者に利用してもらえる観点と、他者に読んで保守してもらえる観点の違いになる。

もう1点は、パッケージとクラスを保守する人の単位が異なる点だ。
クラスを修正する人は基本的には1人であり、コードのレビューアも関わるだろうが、1人が責任を負う。
その修正履歴はコミット履歴に残る。

一方、パッケージを保守する単位はチームや部署の単位になる。
普通は、リリースモジュールの単位はサブシステムであるから、システムごとに担当する部署があるだろう。
大規模な基幹系システムを持つ企業であれば、数多くの部署ごとに担当するシステムが異なるだろう。
つまり、サブシステムというリリースモジュールを保守するのは複数人であり、アプリ層だけでなくフロント層、インフラ層など数多くのメンバーが関わって初めて一つのシステムが動く。

すると、システム単位に開発チームが存在するので、コンウェイの法則に従うことになるだろう。
つまり、アーキテクチャ（システム）は組織に従うわけだ。
この特徴により、サブシステム間が部署間の壁となり、IFとなるので、IF連携は認識齟齬が起きやすいリスクが発生しやすい。
部署ごとにシステムが分かれることにより、システムは局所最適化されやすくなる。

そんなことを考えると、パッケージ原則とクラス原則は同じような観点が多い一方、クラス担当者やシステム担当チームの違いを認識することも必要だろうと思う。

パッケージ設計の原則の意義は変化しているのか

パッケージ設計の原則についてちょっと議論する場があり、色々考えるものがあった。
考えたことをラフなメモ書き。

【参考】
パッケージ設計の原則を本で学ぶ - Qiita

パッケージ設計６つの原則～ポイントは関連性/依存性/抽象度 | プレイン・プログラム

コンポーネントに関する6つの原則 - Qiita

【1】パッケージ原則6個の復習。

1. パッケージ再利用等価原則　Release Reuse Equivalency Principle
* 再利用の粒度はリリースの粒度と同じ
2. 共通閉鎖原則　Common Closure Principle
* クラスは共に変化し、共に存在する
3. 共通再利用原則　Coomon Reuse Principle
* 共に再利用されないクラスを同じグループに入れるべきではない
4. 非循環依存関係原則　Acyclic Depenedencies Principle
* パッケージ間の依存関係は循環してはいけない
5. 安定依存関係原則　Stable Dependencies Principle
* 安定している方向に依存する
6. 安定抽象原則　Stable Abstracttions Principle
* 安定したパッケージは抽象的であるべきだ

【2】パッケージ再利用等価原則が最も基本の原則と考える。

ちょっと昔のJavaシステム開発であれば、リリースモジュールwar/earがリリースの単位であり再利用の単位になる。
サブシステムごとにwar/earをビルドして検証環境でテストした後、オンプレの複数台のサーバー環境ごとに、複数のAPサーバーへwarを手動でデプロイしていた。
ロードバランサーからデプロイするサーバーを切り離して、1つずつwarファイルをデプロイして起動確認し、確認OKならば外部通信できるように設定していた。
つまり、そういう面倒な手動のリリース作業があった。

オンプレのサーバ環境にwar/earファイルをデプロイする単位は普通はサブシステム単位なので、そういう粒度で再利用しやすくする。
その場合、war/earファイルはできるだけサイズは小さい方がAPサーバ再起動時間も短くなるし、リリース作業も短くなるので、リリース作業ミスの確率も減らせる。

特に最近はAWSのようなクラウド環境では、サーバ環境そのものを使い捨てみたいにコンテナから自動生成するので、コンテナ(リリースする単位)のサイズが小さいほどサービスの再起動時間が短くなり、サービス停止時間も短縮化でき、顧客満足度も高くなる。
JavaGoldを取得した時に、モジュールの話で、モジュールサイズをできるだけ小さくしたい要望がある理由がそこにあると聞いて納得したことがあった。

クラウド上の開発がJavaに与えた影響は何なのか: プログラマの思索

Javaのモジュールシステムは複雑性をより増している: プログラマの思索

Javaのモジュールシステムの考え方をまとめてみた: プログラマの思索

【2】ただし、リリースモジュールの保守性や分割についてトレードオフがある点は理解できる。

実際、サブシステム単位にリリースモジュールwar/earをビルドする場合が多いので、普通はリリースモジュールのファイルサイズは非常に大きくなりがちだ。
なぜなら、リリースモジュールには、Apacheの共通ライブラリ、会社特有の共通ライブラリなどのJarという共通コンポーネントを多数含んでいるからだ。
同様に、RailsのようなWebアプリでも、bundlerの中には共通ライブラリGemを多数含んでいる場合が多い。

すると、リリースモジュールのファイルサイズを小さくしたくなる。
簡単に思いつくのは、リリースモジュールから他のサブシステムと共通で使う共通ライブラリは別出しして、デプロイする時は共通ライブラリは再リリースしなくて良いようにしたい。
APサーバ上に共通ライブラリを別で配置して事前ロードしておいたり、別APサーバ上に共通ライブラリを配置するケースも考えられるだろう。

メリットは、リリースモジュールのうち共通ライブラリは既にAPサーバにデプロイされているので再リリースは不要であり、リリースモジュールのサイズを小さくできる。
その分、ビルド作業時間、リリース作業時間を短縮でき、リリース作業ミスのリスクも減らせるだろう。

一方、デメリットは、共通ライブラリに手を加えた場合、既にデプロイ済みのサブシステムのwar/earファイルに影響が発生してしまう。
デグレがないか事前確認が必要だし、共通ライブラリがサブシステムのAPサーバとは別APサーバにデプロイされていて、共通ライブラリが複数のサブシステムから呼び出されているならば、複数のサブシステムに影響が発生してしまう。
共通ライブラリのリリース作業中にAPサーバを停止する事態が発生すれば、呼び出し側の複数のサブシステムで業務停止してしまうリスクが発生する。

また、共通ライブラリにサブシステムA向けのAPIを追加したり改修して、他のサブシステムB向けのAPIは触らない場合であっても、共通ライブラリをリリースする時にサブシステムAもBにも影響が発生してしまう。

だから、一般には、サブシステムごとに共通ライブラリを含んでリリースモジュールをビルドする場合が多いと思う。
すると、たとえば、サブシステムAの共通ライブラリXのバージョンは1.1、サブシステムBの共通ライブラリXのバージョンは1.2、みたいにコンポーネントのバージョンがサブシステムごとに違ってくる場合も発生するだろう。

つまり、サブシステムで利用する共通ライブラリのバージョン管理、構成管理が重要になってくる。
この仕組みがMavenであり、Railsならbundlerなのだろうと思う。
ライブラリやコンポーネントの構成管理というソフトウェアの複雑性をビルド管理の仕組みで補っているわけだ。

【3】では、昨今のアジャイル開発、DevOps、クラウドなどにより、パッケージ設計の原則の意義は変化しているのか？

メタな観点ではパッケージ設計の原則の意義は変わらない。
リリースモジュールは再利用できる単位であることは変わらないし、モジュールの分割方針やデプロイ方針も基本は変わらない。
しかし、具体的なリリース手順や開発プロセスは影響を受けていると思う。

例えば、SaaSビジネスでは、リリース作業時間は極力短くしたい。
リリース作業時間は広義の意味では、顧客に機能を提供するリードタイムと同じ。
BtoCのSaaSビジネスならば、機能改善の要件定義からリリースまでのリードタイムを短縮化する事は売上に直結する。
ちょっとした機能改善を即座にリリースできれば、顧客満足度も上がり、ユーザ数増加が売上につながるから。

また、特に昨今はクラウドでサーバーごとの仮想化するなどして丸ごとコンテナ化し、コンテナを使い捨てみたいにいくらでもデプロイできるから、リリース作業時間はできるだけ短くしたい。

これは、DevOpsの考え方と非常に相性が良いと思う。
DevOpsで開発チームがシステム運用と一体化したプロセスになるし自然にアジャイル開発になるはず。
つまり、アプリ開発者はアプリも開発するし、クラウド上でインフラ基盤もサーバー基盤もコンテナをプログラム化して自動配置できるようにすれば、開発も運用も一体化できるはず。

そして、リリース作業時間と言うKPIを開発チームが毎回計測し監視すれば、改善すべきか評価できるはず。
リリース作業時間、ビルド時間、デプロイ時間などはアジャイル開発の主要なメトリクスの一部と捉えられるだろう。
システム停止やデータ移行の時間も含めてリリース作業時間に3日間かかっていたのを、1時間で終わらせたり、わずか5分で終わらせれば、その分システム停止時間も短くでき、顧客の業務や顧客の操作時間への影響を減らせる。

そんなことを考えると、アジャイル開発やDevOpsという考え方は、サーバの仮想化やクラウドの技術のおかげで進化している部分も大きいのだろうと思う。
こんなことは既に当たり前の考え方と思うけれど、アプリ層の設計技法もインフラ基盤の仮想化技術に相当影響を受けているのではないか、と思う。

QAエンジニアの役割は開発チームのガードレールみたいなものという考え方

@kz_suzukiさんのツイートからQAエンジニアの役割は開発チームのガードレールみたいなものという考え方を知ったのでメモ。

【参考】
自信を失っていた人間が1人目QAとして再スタートを切るお話｜MNTSQ, Ltd.（モンテスキュー）

Kazu SUZUKIさんはTwitterを使っています: 「一人目QA物語はどれも勉強になるな。「最後の砦」意識から、「ガードレール」としてのQAに考えを進化させていく様子が良いなあ。/ 自信を失っていた人間が1人目QAとして再スタートを切るお話｜MNTSQ, Ltd.（モンテスキュー） https://t.co/WL4Do4swkJ」 / Twitter

「ゲームをテストする バグのないゲームを支える知識と手法」の感想: プログラマの思索

（引用開始）
様々な経験を経た結果、「最後の砦」ではなく「開発チームのガードレールと動力」が私の中で目指すQA像になっています。
※「ガードレール」は前職の同僚が言って「これや！！」ってなった言葉でした。

開発のスピードを上げていくために、品質観点から改善点を探し、
スピードを上げすぎたことにより崖から落ちてしまわないように守る人材でありたいと今は思っており、実現のために日々奔走しているところです。
QAは品質にこだわることで開発のスピードを落としてしまいがちと思われがちですが、品質を守ることによってエンジニアの方がより開発しやすく、スピードをあげることができると思っています。
（引用終了）

QAエンジニアのキャリアはあまりイメージが付いてなかった。
せいぜい、開発者やプロマネが開発できなくなってテスト分野に移るみたいなイメージしか正直持っていなかった。

QAという仕事はどうしても開発チームのサポート役という役割になりやすい。
その分、存在意義に悩むだろうなと思ったりもする。

しかし、QAエンジニアは、品質を守る最後の砦という役割だけでなく、品質を守ること開発チームが開発しやすくする環境づくりを支援するという役割がある。
こういう考え方が新鮮だった。
確かに、システム開発のQCDのバランスを保ちながら、品質が良ければ、他の要素は自然に上向く。

心理的安全性はQAエンジニアが守る、という観点もあるのかもしれない。

テストアーキテクチャ設計モデルと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_テストプロセスの概念モデルをもっと抽象化して洗練させれば、テストアーキテクチャ設計モデルとマッピングできるだろうと直感している。
この辺りは気づきを残していく。

パターンカタログよりもモンスターカタログの方が面白いね #jasstkansai

Jasst関西がオフライン開催だったので10年ぶりに参加してきた。
感想をラフなメモ。

【参考】
JaSSTソフトウェアテストシンポジウム-JaSST'23 Kansai

知識は経験よりも大切か、経験は知識よりも勝るのか、SECIモデルは相互作用を語る: プログラマの思索

「大人の学びパターン・ランゲージ」の感想～知識と経験を行ったり来たりするタイミングを大切にする: プログラマの思索

現場の経験知をパターン言語にするコツが分かった　#agileto2014: プログラマの思索

パターン言語の構造と事例集: プログラマの思索

SECIモデルは知識の再利用モデル、または、実践知を生み出すモデルだ: プログラマの思索

【1】今回のテーマは「思考停止」。
正直難しいテーマだったかなと個人的印象を持った。
基調講演の山口鉄平さんの話を聞くと、説明に苦労されている印象があって、本来は「ソフトウェアテストをカイゼンする50のアイデア」本から色んな改善事例を出してもらえるともっと聞きたかったのにと思った。

今の日本の社会情勢であれば、「思考停止」というテーマはたくさんの事象が出てくるだろう。
たとえば、円安やインフレ、少子高齢化による社会保障制度の不安、コロナ補助金不正、マイナンバーカードの名寄せ問題、EV車やAIに対応できていない製造業やIT企業、を見れば「思考停止」の事例はいくらでもあるだろう。
つまり、そういう問題に対し、本来の課題（イシュー）は何なのか、その課題を解決する時に一番効果のある対策は何か、予防策は何か、まで突き止めて考えなければならないのに、前提条件や制約条件を無視した議論がすごく多い。

一般に、日本の組織論で有名な「失敗の本質」本を読めば、日本人の「思考停止」の例はすぐに2つは思いつく。
1つは、個人では意見を持っていても、同調圧力に流されて集団浅慮やリスキーシフトに陥ること。
もう一つは、一般兵士のような下級レベルの労働者や兵士は真面目で優秀だが、戦略の目的に合致しない行動を取っているために、いくら真面目に働いても生産性や投資効果が低いこと。
野中先生が指摘した日本人の弱点は、1945年当時から80年たった今でも変わらない。

akipiiさんはTwitterを使っています: 「日本人が思考停止に陥りやすい例が自分のイメージと違っている気がした。日本人は集団浅慮に流されて自分の意見を言わないとか、一生懸命働くけど生産性を意識せず働く場合が多いんじゃないかな？ #jasstkansai」 / Twitter

こういう思考停止の事例を分析するには、なぜなぜ分析が結局使われると思う。
なぜなぜ分析で自分の言動を問い詰めて、最終的にはその人の油断、プレッシャー、焦りなどの心理背景まで突き止められるのではないか、と思う。

OL参加者の意見として、フレームワーク思考を習慣的な思考と考えて、思考停止になっているのではというツイートもあって面白かった。

akipiiさんはTwitterを使っています: 「#jasstkansai なるほど、フレームワーク思考は習慣的な思考と捉えるのか。SECIモデルならどれに相当するのか？形式知を組み合わせる連結化？形式知を暗黙知にする内面化？」 / Twitter

【2】今日のJasst関西で最も印象に残ったのが、「思考停止からの脱出 ～ あなたの"問い”が自律へと導く ～」ワークセッション。
テーマは「思考停止を題材にして、問題事象をモンスターで書いてみよう」。

「思考停止」というテーマを各人の体験から問題事象を洗い出し、それらの問題事象にモンスターとして名前付けする。
そのモンスターには、名前とモンスターの絵があり、モンスターのプロフィールとして得意技・どんな時・他の特徴という説明文が付与される。
そのモンスターに対し、必殺技でやっつける、という流れ。

僕は「打合せ大好きマン」というモンスターを書いてみた。
伝わるかな？

これはアンチパターンと言えるだろう。
つまり、モンスターの名前はアンチパターン名。
得意技は問題事象。
どんな時は、問題事象が発生するタイミング。
他の特徴は、問題事象の影響事例。
必殺技は、解決策に相当するだろう。
フォースに相当する項目があればなおいいね。

僕もパターンは好きだし、パターンを自分で作れないか、パターンカタログのようなものを作れないか色々考えていた時期があった。
しかし、深く考えるほど難しいなと思う。
モンスターにアンチパターンを当てはめると、ロールプレイングゲームのように気楽な気持ちでパターンカタログを作り出すことができる。

この発想は他のワークショップでも使ってみたいなと思う。
プレインステーションなどのゲーム経験が深い人ほど馴染みやすいかもしれないから。
もっと気楽にパターンを考えてもいい。

【3】久しぶりにオフラインでコミュニティに参加して気づいたことはいくつかある。

1つ目は、参加者に若い人もいるけれど、年齢層が割りと高そうなこと。
アンケートでは、SE経験が10年以上の人が参加者の半分を占めていた。
本来は20～30代の人たちが半分以上を占めていて、経験が少なくてもノリが良くて活気があるのが普通だが、ちょっと落ち着いていた感じ。
久しぶりに会った方と話していたら、最近は若い人が少ないですよ、とのこと。
昨今の日本社会の情勢である少子高齢化が出ているのだろうか？

2つ目は、オンライン開催のチャネルが勉強会コミュニティで必要になってきたこと。
コロナ禍を経て、開催側もオンライン開催の手段がすごく簡単と分かったし、参加者も簡単に集めやすいと分かった。
参加者もオンライン開催であれば、スマホさえあれば作業しながらでも聞ける。
わざわざ交通費を払って時間を拘束させる必要もない。

今後の勉強会の運営は、Jasst関西のようにハイブリッド開催が当たり前になってくるだろうと思った。

「ゲームをテストする バグのないゲームを支える知識と手法」の感想

「ゲームをテストする バグのないゲームを支える知識と手法」を読んだ。
JSTQB FoundationLevelを取得した後に読んだので、ソフトウェアテストの基本を抑えていて、かつ、ゲーム業界特有の考え方や組織、技術に関する話があって面白かった。
ラフな感想をメモ書き。

【1】僕は業務系システム開発しか経験がないので、ゲーム業界のことは知らない。
「ゲームをテストする バグのないゲームを支える知識と手法」を読むと、ゲーム業界特有の特徴がいくつかあると感じた。

業務系システム開発では、機能の網羅性、性能要件やセキュリティ要件などを踏まえた品質担保を重視する。
決められた要件があって、その要件に基づいた機能の網羅性の品質を担保することをすごく重視する。
つまり、当たり前品質の確保にかなり重点を置くように思える。

一方、ゲーム業界の品質は単に機能が網羅されていることが重要視されているわけではない。
UIや面白さなどの魅力的品質がかなり重視される。
だからゲームでバッグのように、開発中のゲームをプレイしてバグを探すように、ユーザが楽しめるプレイを中心に見る。
そこには機能の担保ももちろんあるがUIや楽しさもかなり重視しているように思える。
この辺りは業務系システムがBtoBビジネスに対し、ゲームソフトがBtoCビジネスであることから生じている事情もあるだろう。

しかし、ゲームソフトのソフトウェアテスト専門会社が出現し、品質向上や品質の可視化を目的として目標とする品質を定め、専門的な技術を使ってその品質レベルに到達するために必要なテストを計画したり設計するようになってきたという。
つまり、ゲームソフトでも品質管理や品質保証という考え方がビジネスとして必要になってきたわけだ。

【2】「ゲームをテストする バグのないゲームを支える知識と手法」では、JSTQBのソフトウェアテスト体系に基づき、ソフトウェアテスト7原則、ソフトウェアテストの専門体制、テストの種類、テストの活動、ソフトウェアテストの技術が紹介されている。
ゲーム業界特有のゲームでバッグの話は面白い。
一方で、ゲーム業界に限らず、JSTQBのソフトウェアテスト体系に基づいて内容が紹介されているので、その知識があれば、より理解しやすくなるだろうと思う。

たとえば、テストの体制には、テストマネージャ、テストリーダー、テスト担当者ごとに役割がある。
テストの種類（テストレベル）には、機能テスト、非機能テスト、探索的テストなど各種テストがある。
テスト活動には、テスト計画→テスト分析→テスト設計→テスト実装、テスト管理などがある。
この辺りはJSTQBの話と全く同じ。
換言すれば、こういうソフトウェアテストの専門知識を持ってゲームソフトのテストを専門的に実施しているならば、かなり組織的にテストをやっているわけなので、品質管理や品質保証もかなりレベルが高いのではないかと思う。

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

【3】ゲーム業界のテスターのキャリアマップは興味深かった。

管理系・技術系のキャリアに分かれている。
管理系キャリアは、テストマネージャやテストリーダー。
技術系のキャリアは、テスターから始まり、テスト設計者、自動化エンジニア、ゴッドハンドデバッガー。
この観点は一般的なプログラマやSEのキャリアに似ている。

【301】個人的に興味を引いたのは自動化エンジニア。
彼の役割はテスト自動化ツールを活用してプログラムを実装して自動テストを実現する。
Pythonの利用が多いらしい。
また、昨今はAIを活用したテスト自動化技術が注目されているらしい。
mablとかもそうなのかなと思う。

アジャイルチームのためのインテリジェントなテスト自動化ソリューション | mabl

テスト自動化が今後重要な役割を持つだろうと直感する。
ソフトウェアテストはどうしても手動テストや手動デバッグが多く、人海戦術になりがち。
そういう部分をプログラムそのもので自動化すれば品質が担保されるし、回帰テストによりデグレードも防げるメリットがあるのは誰もが理解する。
一方、テスト自動化は技術の難易度が高いし、やみくもにテスト自動化してもコスト削減効果がさほど得られない話もよく聞く。

テスト自動化の8原則という概念も初めて知った。
この辺りも色んなノウハウがあると思うので調べてみる。

テスト自動化研究会 - テスト自動化の8原則

テスト自動化の8原則について解説

【4】テストエンジニアの年収が記載されていたのも目を引いた。
一般アルバイトなら時給1072円、テストリーダーなら時給1172円。
年収は225万～400万円程度。
テストマネージャなら月給30万～50万レベルとのこと。
今はインフレなのでこれよりも高いだろうが、まだまだ低い気がした。
ソフトウェアテストの専門性が認知されれば、今後も上がっていくのだろうと思う。

JSTQBのテストプロセスの概念モデルを描いてみた

JSTQB Fondation試験を勉強した時に、JSTQBのテストプロセスの概念モデルを描いてみた。
気づきを書き残す。
まだ理解があやふやなので、間違えていたら後で直す。

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

JSTQB_テストマネジメントとレビュープロセス.pdf from akipii Oga

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

【1】JSTQBのテストの専門用語は、普段使っている言葉と意味が違っていたり、別の言葉で置き換えられる時があると分かった。
たとえば、テストレベルはテスト工程のテストプロセス、テストタイプはテストの種類に相当するだろう。

テストオラクル、テストベースなどはJSTQBで初めて知った。
たぶん、テストケースの発生源や出処となる概念を明確に区別すべきという考え方があるのではないか。

テストオラクルの用語定義: プログラマの思索

また、テストプロセスの概念モデルを描いてみて気づいたのは、JSTQBにたくさん出てくるテストの専門用語は、テスト管理ツールやテスト支援ツール、テスト自動化ツールなどのツールで使う場面をかなり意識しているのではないか、と直感している。

たとえば、テストスイートは、一般にテスト自動化ツールに読み込ませるテストケースやテストデータをイメージできる。
テストハーネスはドライバやスタブみたいなものだし、テスト環境そのものも今ならDockerで最初から環境構築を自動化できる。

【2】エラー(誤り) error、欠陥 defect、故障 failureは明確に区別される。

エラー・欠陥・故障の用語定義: プログラマの思索

一般に不具合と言われる事象は故障に相当するだろう。
不具合をバグ、障害と断定しない理由は、実際に調査してみたら、仕様通りで問題ないとか、テスト手順ミスやテスト環境の不備が原因だった、という場合があるからだろう。
不具合は、故障、不正の事象も包み込む曖昧な現象を指す場合が多いと思う。

欠陥があったからといって、故障が発生するわけではない。
欠陥のあるプログラムが実行されて初めて故障が発生する。
欠陥がプログラムに埋め込まれても、テストで発覚せず、運用していても発生しなければ、システムは問題なく動く。
しかし、欠陥そのものは存在しているわけだから、いつかは故障として発生する。
いわゆる潜在バグに相当するのだろう。

欠陥の根本原因の分析はなぜなぜ分析がよく使われるだろう。
しかし、なぜなぜ分析を現場で実際に使ってみると、なかなか効果を出すのが難しい。
メンバの力量にかなり依存するので、原因があらぬ方向に行ってしまいがち。

【3】JSTQBでは、テストチームの役割には、テストマネージャとテスト担当者の2つが少なくとも定義されている。
テストマネージャはテスト計画フェーズで中心的役割を果たす。
テスト実行フェーズ以後の具体的な作業はテスト担当者に任せるようだ。
つまり、テストマネージャはプロジェクトマネージャやストラテジストに近いイメージを持った。

JSTQBのAdvancedLevelはテストマネージャ試験がある。
ただし、業務経験が必須らしい。

【4】テスト管理や品質管理については、TestLinkを試していた頃に随分色々考えていた。

TestLink: プログラマの思索

プログラミングやシステム設計とは異なる考え方を知ったり、試したりするのが面白かった。
残念なのは、テスト管理ツールはほとんどが有償であり、OSSのTestLinkしか試せなかったことだった。

テスト管理ツールTestRail、CAT、QualityForwardの感想: プログラマの思索

テスト管理ツールCAT、TestRail、QualityForwardのオンラインのマニュアルのリンク: プログラマの思索

今持っている問題意識は、2023年の現在、ソフトウェアテストを支援するテストツールはどんな方向に進化しようとしているのか、ということ。
上記の記事にも書いたが、日本のIT企業やユーザ企業が考える品質と、欧米企業が考える品質は異なる。
日本人は機能の細かい品質までこだわるが、現代はアジャイル開発が普及して一般的になっていて、その考え方が時代に合わない部分もある。
アジャイル開発に適した品質とは何なのか？
そして、AIなどを使ってもっとテストそのものを進化させることはできるのか？

この辺りは色々考えてみたいと思っている。

テストオラクルの用語定義

テストオラクルが分かっていなかったのでメモ。
Oracleがなぜこんなところで出てくる？と勘違いしていた。

【参考】
テストオラクル（てすとおらくる）：情報システム用語事典 - ITmedia エンタープライズ

JSTQB-ALのお勉強(2周目) ─ 2.1～2.4 - ソフトウェアの品質を学びまくる2.0

テストオラクルとは何か - ソフトウェアの品質を学びまくる2.0

テストオラクルとは何か？概要や対象物について解説

test oracle - ISTQB Glossary

A source to determine an expected result to compare with the actual result of the system under test.

テストオラクルとは「ソフトウェアテストの正しさや妥当さを判断する根拠となるもののこと。テストケースやテスト項目、あるいはその出処をいう。」
下記の例がわかりやすい。

(引用開始)
テストオラクルになる情報元
「記載例の通り、入力値の積を出力する。例：1*1=1、1*2=2、1*3=3 … 9*9=81」

テストオラクルにならない情報元
「入力値の積を出力する。」
(引用修了)

テストオラクルという概念が必要になってくるケースは、テスト設計ツールやテスト管理ツールだろう。
テスト設計ツールに投入するテストケースの発生源がテストオラクルになる。

たとえば、テスト設計ツールに投入するテストケースは、仕様書や業務マニュアル、ドメイン知識を元に具体的に作られる。
あるいは、「回帰テストの“前回は通った”ことを保証するテストスイートはテストオラクルといえる」だろう。

特に、ツールを使ってテストケースを再利用したい場合にテストオラクルという概念が必要になってくるのではないか。
なぜなら、ツールに投入されたテストケースを管理していくと、発生源となる仕様や要件がわからなくなる場合があるからだろう。

すると、テストオラクルという概念は、テストケースと要件をリンクさせるトレーサビリティの役割を担っているとも言えるのではないか。
TestLinkでも要件カバレッジの機能があったので、最終的には、テスト管理ツールの中に要件管理機能も含まれて、テストケースと要件のトレーサビリティを実現するような機能が埋め込まれることになるのだろうと想像した。

エラー・欠陥・故障の用語定義

エラー・欠陥・故障の用語定義をメモ。

【参考】
48号：エラー・欠陥・故障｜Kouichi Akiyama｜note

ソフトウェア開発におけるエラー、欠陥、バグ、故障、不具合の違いとは

【JSTQB】正しく使えてますか？「不具合」という言葉 | @QA

【0】普段、「バグ」「不具合」という言葉をよく使う。
しかし、現場では定義が曖昧。
JSTQB教科書から抜き出した。

故障（failure）：コンポーネントやシステムが定義された範囲内で要求する機能を実行しないこと。
欠陥（defect）：作業成果物に存在する、要件または仕様を満たさない不備または欠点。
エラー（error）：間違った結果を生み出す人間の行為

自分もよく間違えるので記載しておく。

【1】「欠陥＝故障」ではない。
故障はシステムを動かして正しくない結果が出ること。
欠陥は、システムを作る上で発生し、作業成果物に存在する。

「故障があるから欠陥がある」は成り立つが、「欠陥があるから故障がある」は成り立たない。
故障という結果には必ず発生させた原因（欠陥）がある。
一方、欠陥があるプログラムが実行されなければ故障は発生しない。

たとえば、システム開発フェーズでは発生せず、システム運用フェーズで見つかる運用バグが該当するだろう。
利用ユーザもそういうバグを考慮してシステムを運用する時も多いから、一概に欠陥を全て除去すれば良いとは限らない。

【2】欠陥の多くは人間のエラーによって生まれる。
欠陥の殆どは人の認識違い・理解漏れにより、仕様通りに作られないソースコードが生まれる。

注意点は、エラーは人の認識違い・理解漏れを指すのではなく、結果として出力したもの（仕様書、ソースコード等）に欠陥を埋め込む行為を指す。
JSTQBでは、エラーの基となった認識違い・理解漏れは「根本原因」を指す。

根本原因（root cause）：欠陥の発生源のことで、根本原因が除去されると、欠陥が削減または除去される。

根本原因調査は、同類バグ、類似バグの調査でよく行われる。
1つの欠陥から多数の故障が発生することは経験的によくあるから。

根本原因調査には、なぜなぜ分析がよく使われる。
そこまで欠陥分析しなければ、欠陥を除去したとはいえないからだ。

なぜなぜ分析では最終的に、人の心にある「不注意」「おごり」「バイアス」まで深掘りする。
その理由は、人の行為（エラー）に原因があるという認識が、色んな品質技法を使っても同じような認識にたどり着くからだろう。

【3】JSTQBにある「不正（anomaly）」が理解しにくかったが、48号：エラー・欠陥・故障｜Kouichi Akiyama｜noteの説明が理解しやすかった。

(引用開始)
欠陥（defect）が原因で発生した現象が故障（failure）で、原因は分からないが「（期待値と異なっていて）何かが間違っていそうなもの・こと（＝偽陽性（FALSE-fail result）を含む）」を不正（anomaly）と呼びます。
(引用修了)

「不正は偽陽性の故障である」と理解した。
つまり、出力結果は仕様から得られる期待値と異なっていて何かが間違っているが、出力結果は故障と確定できないし、欠陥もすぐには分からない状態を指すのだろう。
おそらく一般には、「不具合」と言われる事象に含まれているだろう。

たとえば、テストして怪しい現象は全てBTSに登録しておくが、詳細に調べてみると、テストデータを間違えていた、テスト実行操作を間違えたために、故障と誤検出されたことを指すのだろう。

不正を区別する必要がある理由は、バグ密度のようなメトリクスを算出するときに、明確に欠陥であるか否かを区別する必要があるからだ。

なお、開発対象のシステムに欠陥はなく、外部連携されたシステムのデータがおかしいとか、クライアントPCの設定が間違えていた、とか、案件側でコントロールできない原因から発生した事象を指すときも、バグ件数に含めない場合だ多いだろう。

JSTQBの考え方はもう一度見直しておく。