「保守しやすい」ことが、良い設計(EoM = Ease of Maintenance)

前２回で、オブジェクト指向を「テスト容易性」と「変更容易性」を中心に再定義したい、という話をした。 従来オブジェクト指向の説明に使われている概念、およびそこから得られる（といわれている）再利用性という品質からではなく、

テスト容易性：　EoT = Ease of Testing
変更容易性：　EoC = Ease of Changing

という２つの概念からが、（現代的な）オブジェクト指向設計の焦点であることを主張してきた。最後、なぜこの２つが必要なのか、というと、それは、メンテナンスのしやすさ（EoM=Ease of Maintenance）を高めるからだ。そして、このEoMこそが、2005年のソフトウェア開発の根本品質だ、と言い切ってまとめたい。

EoMの高い設計が、よいオブジェクト指向設計である。

ということである。今回は、前回書いた、EoT/EoCそして、このEoMについて、ソフトウェア品質との関係を上位から考えてみる。

「ISO/IEC9126」では６つのソフトウェア品質特性が定義されている。 

機能性：ユーザ要求を満足する一連の機能 
信頼性：一定の期間・条件下での所定性能を維持する能力 
使用性：分かりやすさ、使い勝手の良さ 
効率性：一定条件下での性能・資源効率 
保守性：変更、修正のしやすさ 
移植性：別環境への移しやすさ 

この中で、「保守性」に注目したい。その他の品質特性は、この「保守性」に依存している、ということはできないだろうか？ソフトウェアは常に変更にさらされている。Bertrand Meyerは、品質を内部品質と外部品質に分け、外部品質の達成のためには、内部品質が必要だと言った。私は、2005年のソフトウェア開発という文脈では、内部品質であるこの「保守性」にフォーカスすることが最も重要だと考えている。

保守性には、以下の副品質特性がある。 

解析性：障害や改訂の対象箇所の識別しやすさ 
変更性：実際の改訂、障害除去のしやすさ 
安定性：改訂時の予期せぬ影響の出にくさ 
試験性：改訂時の妥当性検証のしやすさ

この中で、解析性、変更性、安定性は EoCに、 試験性は、EoT にあたる。ここまでの議論で、すべての品質特性の依存先を、EoCとEoT に向かわせることができた。そこで、

よい品質のものを作るには、EoMが大切。そして、EoM=EoC+EoT

と言うのがこの議論の結論だ。

特に、アジャイル型の開発では（イテレーション0を除けば）、開発イテレーションはすべて保守フェーズだと捕らえている。「保守」すなわち進化型設計が中心にあり、そのEoMのために重要なのは EoC（変化ヲ抱擁セヨ） と EoT（テスト駆動開発）なのだ。（そして、品質という観点ではないが、後述の Sustainability）

アジャイル開発に限らなくても、システムは「変更される」。むしろ、要求の追加変更がシステム開発を駆動している、と考えてよい。ほとんどのシステムはそのライフサイクルを「保守モード」で過ごす。さらに、技術の推移、ビジネスの存続性、ソフトウェアエンジニアの年齢、などから、システムは、持続可能(sustainable)であることが求められ、かつ、システム開発も持続可能である必要がある。メンテナンスできないソフトウェアは作ってはいけないし（そのために、メンテナンスのドキュメント、トレーニングやペアプログラミングによる情報伝達、自動テストは必須）、開発プロジェクトのマネジメントも、一時の開発ピークで燃え尽きて離職してしまうようなデスマーチ状態を作ったり、開発要員と保守要員をすっぱり交代させるような線引きをするような要員計画をしていはいけない。

（ちょっと議論が品質から外れてしまいました。設計の話をしていましたが、プロセスの話、ピープルの話が混入しています。脱線ついでに、Kent Beck は以前、"forty-hour Week"「週４０時間労働」というプラクティスをXPに入れていました。それが、Sustainable Pace と名前を変え、現在は、Energized Work となっています。Energized Workとは、「仕事」と「自分の活力チャージ」をバランスさせることです。

http://www.threeriversinstitute.org/energized%20work.jpg）

最後に、このように考えるに至った背景にあるのは、現在のビジネス環境およびテクノロジ環境の変化が10年前よりも速くなったことが原因だと思う。10年前は、2年後のカットオーバーや製品発表に向けて、止まった要求をターゲットにして開発する、というモデルで開発すればよかったのかもしれない。しかし、現在はシステム開発における、ビジネス「要求」と開発に利用する「技術」は、ともに急激に変化する。システム開発はその両者を結ぶ活動なのだが、「要求」と「技術」が変化する状況は、揺れる「梯子」に乗って、揺れる「りんご」を掴むがごとしだ。そのような状況においては、「止まった」状態を元に考えることとは、根本的に焦点が違う。変化を嫌ってはいけない。変化こそが現在のビジネス駆動要因であり、すなわち、システム開発駆動要因である。

※EoMはてらださん、から名前を頂きました。ありがとうございました。