ソフトウェアの最良の設計について

 最近IPAのESPRといったドキュメント指針を読んでいるのだけれども、一部に微妙な印象を感じている。特にソフトウェア詳細設計書や設計仕様書といった、実装を始める前に実装を固めてさせてしまおうとするドキュメントは、なんだかなと感じる。


 一応、組み込み業界では、ソフトウェアを開発する際、プログラムの詳細設計を先に定義してしまおうという伝統的な文化が残っている。上記のドキュメントも、恐らくそれに立脚したものではないかと想像している。
 こうした文化の根底には、次のような思想があると思う。

  • 最良の設計は最良の設計のスペシャリストの手により実現される
  • 設計の改善は設計のスペシャリストの技術向上で実現される

 もちろんこれは完全否定はできないけど、要求品質が変わらない一方でコードの量が爆発している現状を見ると、現状に見合っていないと感じる。


 とりあえず前提として、設計工程では以下の視点についてよく考える必要がある。

  • 仕様変更があるのは当たり前
  • 設計工程ではすべてのリスク要因を捕捉できない

(これに関しては否定できないと思う。これらを否定することは、自分たちの開発プロセスが仕様変更や不測のリスクに対応できない脆弱なものであると公言することと同義と見なせるので)

 そのため、詳細設計を先にやるプロセスでは、以下のような課題が発生していると思う。

  • 詳細仕様書を修正するプロセスが必要になる。例えば仕様変更があれば実装の修正に先んじて仕様書を書き直し、実装上で何らかのリスク対策を追加すれば後追いで仕様書を書き直さないといけない。なおそれをしない、すなわちドキュメントとコードに矛盾が生じてもほったらかしにするような環境は、そもそも詳細仕様書のようなドキュメントの存在意義を問い直した方がいいと感じる。
  • 詳細設計の段階で、実装のロバスト性や変更容易性などを先読みで確保しなければならない。例えば、将来仕様変更が行われても詳細設計への影響が限定的になるような設計を、先読みして施す必要がある。

 こうした課題は、コードの量が少なかったり、1つのwhileループですべての制御を管理できていたりする時代なら問題なかったかもしれない。
 ただ実装の量が増えコードの複雑度が上がる状況下においては、詳細仕様書のメンテナンスコストは増えていくし、将来の実装の変更容易性なんてものは、追い求めれば追い求めるほどコードの冗長性を指数関数的に増大させる要因になってしまう。現状はそうした問題が悪化して、詳細設計をするメリットが詳細設計工程を運用するデメリットを下回っているようにしか見えない。


 今ではありふれた、曖昧さや変化のリスクが大きい開発では、やっぱり

最良な設計は、継続的なリファクタリングの先にある。それを先読みで実現するのは難しい。


といわざるを得ないと思う。
 そのため、先行した詳細設計工程では、リファクタリング(とそれを支えるテスト)をやりやすくする設計やフレームワーク、規律といった環境作りをやる方が、より本来の目的に合致しているように感じる。具体的にいえば、テストを阻害する依存部の分離、先行したモジュールのふるまい(BDDやEDDでいうbehaviorやExample)テストの設計、頑健なモジュールインターフェースの設計といった対策を、詳細な実装方法を指定するより重視した方がいいと感じる。



 なお誤解のないように言っておくと、自分はドキュメントが要らないとは感じていない。逆にドキュメントを書かずに損しているなと思う機会が結構あるので、これに関しては気が向いたら書こうと思う。