UAS 5に寄稿したものです。

1. 1
1
よいアーキテクチャ、よいライブラリ、よいテスター
Good architecture, Good library, Good tester.
秋山 浩一
はじめに
私は、プログラミング業務を離れてから20年近くになります。現職はソフ
トウェアテストのコンサルタントですが、プログラマからコンサルになる
間に、製品のテストや品質保証に携わりました。
今回は、テスターや品質保証担当としてアジャイル開発に携わった数回の
事例について思い出しながら失敗のポイントと、それだけではなんなので
成功のためにどうすればよかったのかについてタイトルの「アーキテクチ
ャ、ライブラリ、テスター」の3つの切り口で書いてみたいと思います。
1. よいアーキテクチャ
私が経験したアジャイル開発では、開発終了間際に性能や信頼性などの面
で「大きな問題（いわゆるショウ・ストッパーになる問題）」が見つかり
ました。
これは、ひょっとしたらハードウェアが無ければ納品できない組み込み系
のアジャイル開発特有の悩みかもしれません。組み込み系のアジャイル開
発においてはハードウェアをアジャイルに進化させることが困難で、そん
なにたくさんの試作品を作ることはできません。したがって2週間ごとに
納品を繰り返すことはできませんでした。
でも、その後、とある識者から「組込み系でなくても同じ悩みですよ」と
いう意見をいただき、勇気を出して書いています。
さて、上記の「大きな問題」に共通していたことは機能のバグではなく、
非機能（ISO 25010で言うところの機能適合性、性能効率性、互換性、使
用性、信頼性、セキュリティ、保守性、移植性などの品質特性）のバグで
した。

2. 2
2
「機能のバグならすぐに直るけど、（いまさら）パフォーマンスが悪いと
言われてもどうしようもない」というようなことをよく言われました。ま
た、「このアーキテクチャはスケーラビリティが無いのでｘｘを増やして
も無理」（ｘｘには、メモリ、CPU、サーバなどのシステムリソースが入
ります）といったことを言われました。
『実践ソフトウェアアーキテクチャ』を読むと、「QAW(Quality Attribute
Workshop), ADD(Attribute-Driven Design), ATAM(Architecture Tradeoff
Analysis Method), CBAM(Cost Benefit Analysis Method)をすることによ
って品質特性からアーキテクチャを構築したのち、アーキテクチャに対し
て特性のトレードオフやコストの評価をせよ」と書いてありました。つま
り、品質特性に関する問題はアーキテクチャレベルで考えておく必要があ
るとのことでした。
アジャイル開発プロセスにおいてもイテレーションに入る前にアーキテ
クチャをしっかり作っておくことが重要なのではないかと思います。2回
だけの経験ですがQAWとATAMを適用したら上手くいったことがあります。
ADDとCBAMは未体験です。
2. よいライブラリ
アジャイル開発で様々なメトリクスを取っていると、ものすごくコーディ
ングが速くバグも少ない人が数人いることに気が付きました。
ヒアリングしてみると、アジャイル開発だからプログラミングが速いわけ
ではなく、その人たちは、独自で開発した「よい個人ライブラリ」を持っ
ていたのです。たとえば、テーブルライブラリであったり、メモリライブ
ラリであったり、画面・帳票部品のライブラリであったりします。
それらのライブラリは非公開にしているわけではなく、それどころか、そ
の個人ライブラリについて、丁寧なAPIマニュアルをしっかり書いてWiki
などで公開をしている人のほうが多かったのも特徴です。そして、その個
人ライブラリは何年も使い続けているため、バグが無く安定していました。
ところが、不思議なことにその個人ライブラリを（作った人の子分を除き）
使おうとするものはいませんでした。一般的にライブラリの再利用は、そ

3. 3
3
うとう気合が入ったスタッフがいないと上手くいきませんが、そういうこ
とが理由でもなさそうで、要は、「（たとえマニュアルがあったとしても、
それを熟読しないと）よくわからないようなものは使いたくない」という
ことのようです。
ということで2番目の「よいライブラリ」については、各プログラマが開
発する時に、自分のライブラリを充実させてからそれを使ってプログラミ
ングするのがよいのではないかと思っています。
3. よいテスター
アジャイル開発では、開発期間（ひとつのイテレーション）が短いことも
あり、テスターもウォータフォールやV字・W字モデルといった開発プロセ
スモデルにおけるテスターの役割と若干変わってきているように思いま
す。
実際に私が携わったアジャイル開発では各イテレーションで（専任の）テ
スターが出る幕はなく、そこでは、開発者自身がテストを実施していまし
た。この時に問題となるのは、「自らの思い込み」です。
仕様の見落としや勘違いによって作り込まれてしまった「思い込みバグ」
を自らのテストで見つけることは困難です。それらの「思い込みバグ」に
ついては独立した第三者がテストしたほうが（同じ思い込みをすることが
少ないため）見つかる可能性が高くなります。ここで独立とは、技術的、
管理的、財務的に独立ということです。
さて、それではアジャイル開発で、テストをどうしたらよいのかですが、
各イテレーションでは開発者が設計の時に使っていない技術を使ってテ
ストを設計することで上手くいきました。私が行ったのは、原因結果グラ
フと直交表を使った振る舞いに着目したテストを開発者に教育し、そのテ
スト技法を用いて開発者にテストを作ってもらい、そのテストをCIツール
で毎日自動実行したことでした。
これはとても効果がありました。最初は通っていたテストも開発が進むに
つれてテスト用のドライバやスタブが本物のモジュールに置き換わると
フェイルすることがあって、バグの早期検出に役立ちましたし、最終納品

4. 4
4
物に対する総まとめのようなテストでも機能に関する問題はほとんど見
つかりませんでした。非機能に関する問題は１で述べた通り残ってしまい
大変でしたが。
まとめ
以上、大変簡単ですが、私がアジャイル開発で体験したこととその対応策
について書きました。
まとめますと、「1. 各イテレーションに入る前にアーキテクチャの設計
をしっかりやる」、「2. 各プログラマは自分だけが使用するもので構わ
ないのでライブラリをつくる」、「3. テスターは入り込みにくいので開
発者自身が設計とは違うテスト技術を身に着けてテストを実施する」です。
当たり前っぽい話になってしまい恐縮ですが、何かのご参考になれば幸い
です。
本稿の執筆を勧めてくださった細谷さん、自分の中のモヤモヤが少し整理
できました。ありがとうございました。
以上