『現場で役立つシステム設計の原則』への些細な批判
増田亨さんの『現場で役立つシステム設計の原則』について、こちらの記事で私の解釈を書いた。（未読の方はご一読いただければ幸い）
背後の原理を理解した上で、私の意見として述べておきたいことがあるので、この記事を書いている。
なお、この批判は、増田さんの方法論の成り立ちの部分に対するものだ。方法論全体を間違いだと否定するものではないし、この方法論によって構築されたソフトウェアや、方法論を現場で利用している方々を否定するものではないことは、どうかご理解願いたい。
重箱の隅をつつくような、細かな話をしているように感じる方もいらっしゃることと思う。しかし、そのようなところにこそ「方法論の機微」が見え隠れするものだと思う。設計や方法論を探求したいと思われている方には、考えを深めるわずかなヒントになるのではないかと思う。
（以下、書名を「現場で役立つ本」、この本で述べられる方法論を「増田方法論」と記載。）
独自進化した「変更容易性」という強すぎる観点
「現場で役立つ本」に書かれた増田方法論における「変更容易性」は、私の解釈では次のような定義だ。
ソフトウェアに変更が必要な時に、ソースコード上で変更しなければならない箇所を特定する時間の短さの度合い。および、変更作業にかかる時間の短さの度合い。
このような定義を前提におけば、増田方法論の理屈はとても分かりやすい。しかし、いくつかの問題が生じていると思う。
1つ目。上のような定義はソフトウェアの変更容易性と呼ばれる考え方の中で、ある1つの狭い領域でしかなく、また、決して主流の捉え方というわけではない。にもかかわらず、増田方法論では変更容易性としてこの観点しか取り上げない。これは、増田方法論の中では、変更容易性という言葉を、一般的なものとは別の意味で採用しているということだ。しかも、本には上のような定義がされているわけではなく、暗黙的にそうなっているというのがまた厄介だ。
すでにある概念を転用するならば、一般的な意味との違いの明示などを丁寧にやることで、無用な混乱を避けられるはずだが、そのようなこともされていない。
2つ目。「ソースコードを変更することがかんたん」という、非常に分かりやすい観点は、その分かりやすさの代償として、他の設計観点を押しつぶしてしまう。どういうことか。ソフトウェアの設計においては、歴史的にさまざまな知見が積み上げられてきた。実績をともなって機能してきた正真正銘の方法論や設計ノウハウがあり、研究されエッセンスが抽出されて、いくつかの設計原則として語り継がれている。そのような設計原則の中には、コードに対するパッと見のかんたんさとは相容れない観点を要求するものがある。たとえば抽象化による情報隠蔽を適用すると、具象部分である細部のコードへトップダウンにアクセスすることは、多少難しくなる。しかしそれでもなお、情報隠蔽にはソフトウェア設計として価値がある。なぜなら、そのような情報隠蔽によってこそソフトウェアの構造が整理され、コードが読みやすくなる側面があるからだ。そしてこれは私個人の意見というわけではなく、多くの人がそう言っていることなのだ。
しかし増田方法論における変更容易性には当てはめづらいように思われる。なぜなら、トップダウンでコードにアクセスしづらくなるということは、増田方法論においては「コードがわかりにくくなる」ことだからだ。したがって、これは私の単なる推測の域を出ないのだが、情報隠蔽やモジュール化、デザインパターン等々、コードが一見小難しくなる設計は、増田方法論においては遠ざけられてしまうのではないだろうか。
結局のところ「ソースコードの変更がかんたん」という観点が、ソフトウェア設計に利用するには強すぎるのだと思う。これを中心に据えてしまうと、設計のための方法論としてのバランスを保てないように思う。
おわりに
増田さんの本に書かれた内容（の私の解釈）に対しての、私の意見を書いてみた。私のこのようなやり方は、一歩間違えば「藁人形論法」に陥ってしまう危険性がある。そうならないよう、解釈がそれ自体きちんと成立するよう誠実に行ったつもりだ。
私の意見の根本的なポイントは、杉本さんの記事で言われていることと同じだと思っている。未読の方は是非ご一読頂きたい。
PHP Mentors -> 「現場で役立つシステム設計の原則」批判 (1) ～何のために、「データとロジックを一体に」するのか？～
