プログラマの思索

ソフトウェアで出てくる品質はとても掴みどころがなく、測定できたとしても意外に役立たない。
そして、従来のWF型開発が重視する品質に対し、アジャイル開発は別の観点の品質特性を重視することによって、ソフトウェア開発のあり方を変えようとしているように思える。
考えたことをラフなメモ書き。

【元ネタ】
Agile開発が指摘したソフトウェア開発の特徴: プログラマの思索

【1】アジャイル開発の本質は小規模リリースだと思う。
いきなり大きな物を作るのではなく、実際に動くものを小さく作り、小刻みなVerUpによって機能拡張も品質も改善していく手法。
その利点は、顧客やマーケットに対し、不完全であってもいち早くリリースできることで、インパクトを与えることができること。
仕様が完全に固まって作るプロダクトアウトの製品よりも、マーケットの動向に合わせて柔軟に計画や方針を変えていくマーケットインの製品に向いている。

小規模リリースの特長としては、イテレーションの単位でリリースしていく点がある。
定期的なリリースサイクルをプロセスに埋め込むことで、安定してVerUp出来る体制を整える。
小規模リリースを支えるXPのプラクティスで重要なものは、継続的インテグレーションだ。
常時リリース可能なSCMリポジトリがあるからこそ、いつでもリリースできるからだ。
その開発スタイルを支える構成管理手法としては、trunkをメインラインとして目的に応じたブランチを派生させるメインラインモデルがある。

【2】従来のWF型開発では、機能性と信頼性という品質特性を重視する。
つまり、仕様書に書かれた仕様がシステムに全て反映されているかという機能性、そして、製品が壊れにくい、あるいはシステムのバグが少ないという信頼性を重視する。
従来型開発をベースとした論文では、「高信頼性なシステムを作る効率的な開発」という謳い文句がよく出るが、それは重視する品質特性を背景としているからだと思う。

それに対し、チケット駆動開発でアジャイル開発を実践してみて気づいたことは、アジャイル開発で重視する品質特性は保守性と移植性であること。
WF型開発とアジャイル開発は、重視する品質特性が全く違う。

【3】保守性は、機能拡張のしやすさ。
XPでは、リファクタリングというプラクティスによって、ソフトウェアの可読性を上げ、構造を綺麗にする。
見た目の機能は変わらなくても、プログラムの構造がシンプルになることによって、将来の機能拡張を容易にしてくれる。
保守性のメトリクスとしては、ソフトウェア複雑度が有名だろう。
複雑度が大きいほど、そのプログラム保守しづらく、潜在バグの可能性が高い。

複雑度と単体テストケース数の相関関係: プログラマの思索

平鍋さんは保守性をテスタビリティ(テストの容易さ)という概念で説明しようとされていたが、保守性はテスト駆動開発と密接に関係する。
XPでは、リファクタリングの正当性をテスト駆動開発で保証する。
内部構造を綺麗にするための改造作業でデグレードを起こさないために、自動テストで回帰テストしやすくして、デグレードを防ぐ。
テスト対象のプログラムが巨大な塊であったら、メンテナンス(保守)しづらいし、そもそもテストしづらいだろう。

「テストしやすい」ことが、良い設計(EoT=Ease of Testing)：An Agile Way：ITmedia オルタナティブ・ブログ

「変更しやすい」ことが、良い設計 (EoC=Ease of Changing)：An Agile Way：ITmedia オルタナティブ・ブログ

ここで、古くからのテスト手法の一つとして、スタブとドライバという概念が出てくる。
テスト駆動開発では、ドライバやスタブを使って、テスト対象プログラムを簡単にテストできるような戦略を取る。

ソフトウェアテスト - テストドライバとテストスタブ - Weblio辞書

スタブは、テスト対象のプログラムをより小さな部品(サブルーチン)を組み合わせた構造にして、そのサブルーチンをテスト用プログラムとして扱うこと。
JUnitでは、テスト対象のプログラムの内部にあるExceptionのテストのために、Exceptionを故意に発生させるモックオブジェクトを作る時が多いが、それはスタブに相当する。
スタブはオブジェクト指向でない言語でも可能だが、オブジェクト指向言語の方がポリモーフィズムやオーバーロードを使えるのでやりやすい。

ドライバは、テスト対象プログラムを実行するために、外側からテスト対象プログラムを呼び出すためのプログラム。
普通は、サブルーチンのような小さなプログラムを作ったものの、単独では動作しない場合、ドライバに相当するプログラムを作り、入力データを幾つか用意して実行してテストする。
特にCやshのような一昔前のプログラミング言語ではよく使われるだろう。

テスト駆動開発という概念はXPが大きく普及させたけれど、テスト技法と絡めたやり方はあまり見かけない。
境界値分析、同値分析などのテスト技法と合わせて実施しなければ、そのテストが本当に全てのロジックを網羅しているのか、保証しにくいはずだ。

同値分割 － ＠IT情報マネジメント用語事典

境界値分析 － ＠IT情報マネジメント用語事典

【4】移植性は、ライブラリなどの移植のしやすさ。いわゆるポーティング。
移植性のよくある例は後方互換性。
例えば、Windowsなら最新OSでサポートされている機能やセキュリティパッチは過去のOSにも適用される。
この後方互換性維持のためにMicrosoftは多大な苦労を強いられている。
Androidではそもそも後方互換性が怪しいので、スマートフォンメーカーはOSのバージョン単位に開発しなければならないから、製品作りにとても苦労しているように思える。

ポーティングとは【porting】（移植） - 意味/解説/説明/定義 ： IT用語辞典

XPでは、継続的インテグレーションが回帰テストを自動化するので、後方互換性や移植したプログラムが正常動作することを常時保証してくれる仕掛けがある。
後方互換性を維持するための概念として、バックポートという考え方がある。
バックポートは、最新の機能やセキュリティパッチを過去のバージョンにも取り込む移植作業を指す。

バックポートとは【backport】 - 意味/解説/説明/定義 ： IT用語辞典

なぜバックポートが必要になるのか？
それは、過去のバージョンを使っているユーザのために、提供する必要があるからだ。
特にセキュリティパッチは、システムの品質要件に絡むだけでなく、社会的な道義にも関わるので、結構面倒。
WindowsOSもRedmineも、セキュリティパッチというバックポートの作業に大きな負担を感じているだろうと思う。

第3回品川Redmine勉強会の感想 #47redmine: プログラマの思索

【5】ソフトウェア開発のプロジェクトでは、移植性に絡む案件は、リプレース案件とよく呼ばれる。
よくある例は、昔に作ったCobolシステムを最近流行のWebシステムに変えたい、とか、VBで作ったクラサバを最新のWebシステムに変えたい、とか。
顧客としては、機能は同じで中身を最新の技術で作り替えて欲しいだけで、仕様は今動いているシステムを見ればいいのだから簡単でしょ、とよく言う。

だが、リプレース案件は曲者だ。
ほとんどのリプレース案件はデスマーチになりやすい。

システムのリプレース案件が最も危険な理由: プログラマの思索

何故なら、実際に動くシステムには既存バグがあるのに運用でカバーしているので、それを直すべきのか、逐一確認しなければならないし、一度直すとなると仕様を最初から作りなおさなければならない。

あるいは、既存プログラムがあまりにも汚いのでその構造やインターフェイスを作り替えた場合、今までに運用してきて実績という運用品質を捨ててしまうため、とても危険だ。
たとえ汚いプログラムでも、長年の運用の中でたくさんのパッチが当てられて、稼働してきた歴史があるのだから、それらを全て理解できるとは限らないからだ。

【感想】Kanasan.JS prototype.js CodeReading#4: プログラマの思索

また、仕様は同じでも、プログラミング言語もハードウェアもライブラリも変われば、その組み合わせできちんと動くのか、実装するよりもテスト工数が膨れ上がり、そう簡単に作れないからだ。

顧客は簡単と思っても、過去に動いていた機能を最新の環境でも動かすようにするという移植性を担保するのは、頭を使わない割りには、神経をひどく使う。
ソフトウェア開発が何故こんなにも難しいのか、という理由の一つは、移植性を保証するのがとても難しいからだと個人的には思っている。

人間の臓器移植でも、そのまま臓器を移植すると、免疫機能が働いて拒否反応を起こす。
ソフトウェアのライブラリも同様に、インターフェイスが合わなければ改造せざるを得ず、そこから潜在バグが生まれるし、テスト工数が発生し、工数が膨れ上がっていく。

移植性は、再利用性に密接に関係する。
別システムのソースを移植する例のように、再利用な可能なインターフェイスになっていれば、移植するリスクは小さい。
移植性の問題は、いかに再利用可能なライブラリや部品を作れるか、という問題に置き換えることもできる。
すると、ソフトウェアプロダクトラインのように、コア資産と呼ばれる再利用可能な共通部品作りが移植性の問題に大きく関わってくる。

清水吉男さんが提唱するXDDPという派生開発では、移植性という品質特性を重視している。
組込製品では特に保守性や移植性というマイナーな品質特性が実は、プロジェクトの進捗や品質に大きく影響していることは皆薄々気づいているはずだ。

アジャイル開発は保守性と移植性が重要である事実を再発見し、その品質特性に対し、各種プラクティスでその有効性を提示した。
その考え方とその適用方法、適用範囲はもっと研究されてよいものだと思う。