『現場で役立つシステム設計の原則』への些細な批判

増田亨さんの『現場で役立つシステム設計の原則』について、こちらの記事で私の解釈を書いた。(未読の方はご一読いただければ幸い)

背後の原理を理解した上で、私の意見として述べておきたいことがあるので、この記事を書いている。

なお、この批判は、増田さんの方法論の成り立ちの部分に対するものだ。方法論全体を間違いだと否定するものではないし、この方法論によって構築されたソフトウェアや、方法論を現場で利用している方々を否定するものではないことは、どうかご理解願いたい。

重箱の隅をつつくような、細かな話をしているように感じる方もいらっしゃることと思う。しかし、そのようなところにこそ「方法論の機微」が見え隠れするものだと思う。設計や方法論を探求したいと思われている方には、考えを深めるわずかなヒントになるのではないかと思う。

(以下、書名を「現場で役立つ本」、この本で述べられる方法論を「増田方法論」と記載。)

独自進化した「変更容易性」という強すぎる観点

「現場で役立つ本」に書かれた増田方法論における「変更容易性」は、私の解釈では次のような定義だ。

ソフトウェアに変更が必要な時に、ソースコード上で変更しなければならない箇所を特定する時間の短さの度合い。および、変更作業にかかる時間の短さの度合い。

このような定義を前提におけば、増田方法論の理屈はとても分かりやすい。しかし、いくつかの問題が生じていると思う。

1つ目。上のような定義はソフトウェアの変更容易性と呼ばれる考え方の中で、ある1つの狭い領域でしかなく、また、決して主流の捉え方というわけではない。にもかかわらず、増田方法論では変更容易性としてこの観点しか取り上げない。これは、増田方法論の中では、変更容易性という言葉を、一般的なものとは別の意味で採用しているということだ。しかも、本には上のような定義がされているわけではなく、暗黙的にそうなっているというのがまた厄介だ。

すでにある概念を転用するならば、一般的な意味との違いの明示などを丁寧にやることで、無用な混乱を避けられるはずだが、そのようなこともされていない。

2つ目。「ソースコードを変更することがかんたん」という、非常に分かりやすい観点は、その分かりやすさの代償として、他の設計観点を押しつぶしてしまう。どういうことか。ソフトウェアの設計においては、歴史的にさまざまな知見が積み上げられてきた。実績をともなって機能してきた正真正銘の方法論や設計ノウハウがあり、研究されエッセンスが抽出されて、いくつかの設計原則として語り継がれている。そのような設計原則の中には、コードに対するパッと見のかんたんさとは相容れない観点を要求するものがある。たとえば抽象化による情報隠蔽を適用すると、具象部分である細部のコードへトップダウンにアクセスすることは、多少難しくなる。しかしそれでもなお、情報隠蔽にはソフトウェア設計として価値がある。なぜなら、そのような情報隠蔽によってこそソフトウェアの構造が整理され、コードが読みやすくなる側面があるからだ。そしてこれは私個人の意見というわけではなく、多くの人がそう言っていることなのだ。

しかし増田方法論における変更容易性には当てはめづらいように思われる。なぜなら、トップダウンでコードにアクセスしづらくなるということは、増田方法論においては「コードがわかりにくくなる」ことだからだ。したがって、これは私の単なる推測の域を出ないのだが、情報隠蔽やモジュール化、デザインパターン等々、コードが一見小難しくなる設計は、増田方法論においては遠ざけられてしまうのではないだろうか。

結局のところ「ソースコードの変更がかんたん」という観点が、ソフトウェア設計に利用するには強すぎるのだと思う。これを中心に据えてしまうと、設計のための方法論としてのバランスを保てないように思う。 

おわりに

増田さんの本に書かれた内容(の私の解釈)に対しての、私の意見を書いてみた。私のこのようなやり方は、一歩間違えば「藁人形論法」に陥ってしまう危険性がある。そうならないよう、解釈がそれ自体きちんと成立するよう誠実に行ったつもりだ。

 

私の意見の根本的なポイントは、杉本さんの記事で言われていることと同じだと思っている。未読の方は是非ご一読頂きたい。

 

PHP Mentors -> 「現場で役立つシステム設計の原則」批判 (1) ~何のために、「データとロジックを一体に」するのか?~

PHP Mentors -> 「現場で役立つシステム設計の原則」批判 (2) ~ポリモーフィズムは何のために?~

『現場で役立つシステム設計の原則』の根幹にある原理

「現場で役立つシステム設計の原則」の「原則」って何だろう?

また、その原則をつなぎ合わせることで得られる設計は、どのような世界観を持っているのだろう? どのような原理で説明されるのだろう?

ソフトウェアの設計に興味を持つ人間なら、そんな興味がどこからか湧き出てきてしまうもの。そんな思考の結果を記事としてアウトプットしておく。

 

(以下、書名を「現場で役立つ本」と略記で記載。)

現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法

現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法

 

増田さんの「現場で役立つ本」に書かれていることに私の解釈を与えて、本に書かれている方法論の世界観や原理を逆算してみた。そのようにして得られた世界観や原理を元に、「増田さんの方法論とはどのようなものか」を私なりに解説する。

以下では、「現場で役立つ本」で述べられているやり方群を「増田方法論」と呼ぶことにする。

なお、これはあくまで私による解釈だ。増田さんの言いたい本質と一致している部分があるかもしれないし、大きく違うかもしれない。この点ご承知おき願いたい。

増田方法論の根幹原理

現代のソフトウェア開発において、いかに変更に耐えていくのかということは、最も大きな悩みの種だ。したがって、ソフトウェアのソースコードにおける変更の行いやすさ=変更容易性が、重要なトピックとなる。増田方法論は、ソースコードの変更容易性を高めることを第一の目的としている。

変更するたびに変更が大変になっていく、このソフトウェア変更の負のスパイラルから抜け出すにはどうすればよいでしょうか。

「現場で役立つシステム設計の原則」p.16

増田方法論の基本原則

増田方法論の骨格となる基本原則は、次のとおりだ。

  • システムの仕様に影響を及ぼす要素は、すべてドメインレイヤーに集めよ
  • ドメインレイヤーのコードを、変更が容易なソースコードとして作成せよ
  • 上記2つの原則を、他の設計原則よりも優先せよ

この原則について正しく理解するためには、使われている言葉の意味内容を明確にしなければならない。最も肝となる用語は、最初にも取り上げた「変更容易性」だ。

増田方法論における「変更が容易」なソースコードとは

一口に変更容易性と言っても、定義や実現方法が一つに定められているわけではない。たとえばデータモデルにおける正規化や、歴史的なオブジェクト指向の設計原則などには、変更容易性を高める技術という側面があるだろう。増田方法論では、変更容易性を最も重要な指標として扱っているが、実は変更容易性の捉え方そのものにも特徴がある。

増田方法論における変更容易性は、次のように定義される。

ソフトウェアに変更が必要な時に、ソースコード上で変更しなければならない箇所を特定する時間の短さの度合い。および、変更作業にかかる時間の短さの度合い。

これらの時間が短いことこそ、増田方法論において「変更が容易」な状態なのだ。

ソースコードを整理整頓して、どこに何が書いてあるかわかりやすくする。それがソフトウェアの設計です。

「現場で役立つシステム設計の原則」 p.14

うまく設計されたプログラムは変更が楽で安全です。変更すべき箇所がかんたんにわかり、変更するコード量が少なく、変更の影響を狭い範囲に限定できます。

「現場で役立つシステム設計の原則」p.14,15

増田方法論における変更容易性を促進するための方法

「現場で役立つ本」には、さまざまな方法が紹介されている。それらは基本的に、増田方法論における変更容易性を促進するための方法だ。これらはざっくりと2つにまとめることができる。

  • 仕様文章に現れる重要な用語をすべてクラスにする
  • ビジネスドメインにおける情報構造の一般形を使う

これらを簡単にまとめておく。

仕様文章に現れる重要な用語をすべてクラスにする

仕様の文章に現れる重要な用語は、漏れなくクラスにしていく。ここで重視されるのが、数量の単位だ。数量の単位は値オブジェクトと呼ばれるパターンを使い、クラスにしていく。こうすることで、値を計算するようなメソッドにおいても、引数や戻り値にプリミティブな値ではなく、クラスを使うことができる。引数や戻り値をクラスにしておくと、メソッド内の処理の前提条件や事後条件の範囲を狭めることができる。前提条件や事後条件の範囲が狭いほど、メソッド内で考慮しなければならない事柄が減り、コードはシンプルになる。同時に、コードを変更した際の影響範囲を限定しやすくなる。結果として、コードの変更を安全に行えるようになる。

ドメインモデルの設計アプローチは、まず部品を特定し、その部品ごとに独立したクラスを設計することです。受注時のルールすべてを扱う大きなクラスは、考えないようにします。数量パッケージと同じように、与信パッケージや基本契約パッケージについても独立して設計します。

そうやって、ある程度の部品がそろってきたら、組み合わせ方を考えます。組み合わせてみながら、個々の部品を調整したり、不足している部品を追加することで、受注ルールに網羅できるだけのドメインオブジェクトが整っていきます。

「現場で役立つシステム設計の原則」p.118

ビジネスドメインにおける情報構造の一般形を使う

ビジネスドメインの情報構造は、概ね次に示す要素に当てはめることで表現できる。

  • オブジェクト・・・1つの情報
  • コレクションオブジェクト・・・オブジェクトの集合を表す
  • 値オブジェクト・・・値や単位を表す
  • 区分オブジェクト・・・区分を表す

これらの要素は互いに関係しているため、業務の仕様に登場する用語をこれらの要素に当てはめていくと、業務の概念体系が自然とツリー構造として作られていく。このツリー構造を一旦作ってしまえば、処理として記述すべき業務ロジックをどこに書けばよいのかは、比較的簡単に定められる。

書き方がよくわからない状態で、ドメインオブジェクトを設計しようとしても、時間がかかるばかりです。

その時間を省くには、ドメインオブジェクトの設計パターンを体で覚えてしまうことです。

「現場で役立つシステム設計の原則」p.124  

そして、、、

ここに挙げた基本原則や各種方法に従うことで、理想的なソースコードのツリーは、仕様に現れる用語が業務ごとに体系的に整理された状態となるはずだ。そのような状態になったソースコードのツリーでは、業務の体系をたどるようにソースコードをたどることができる。業務用語に関係した処理は、その業務用語に対応するクラス内に書かれているため、どの業務処理のコードがどのクラスに書かれているのかを、瞬時に見つけることができる。一つ一つのクラスは十分に小さく作られ、メソッドの入出力の範囲は小さく明確で、ロジックの重複もない。

かくして、ソフトウェアの変更はとても容易になる。

おわりに

このような記事を書いておいて不思議に思われるかもしれないが、私は増田方法論そのもの、および方法論の伝え方といった点で、批判的立場だ。興味のある方は、批判記事も読んでみていただきたい。

しかし、内容を正確に理解した上で、どのような立場をとるのかは各人の自由だと思う。さまざまな立場から方法論を見つめることで、有益な気付きが得られるものだと思うからだ。この記事がそのような議論の一助になれば幸いだ。

 

PHPカンファレンス福岡で登壇します!

3月のPHPerKaigi 2018に続いて、6月16日(土)に開催されるPHPカンファレンス福岡2018でも登壇させて頂けることになりました。

phpcon.fukuoka.jp

 

トーク概要は以下のとおりです。

  • 時刻:【Fusicホール】13:00〜13:45
  • 「SOLIDの原則ってどんなふうに使うの?オープン・クローズドの原則編 拡大版」
  • 対象:中級
  • セッション内容:PHPerKaigi 2018でベストトーク賞の講演の拡大再演版です。理解を深めるためのトピックを追加してお話します。
    オブジェクト指向プログラミングを勉強したことのある人なら、一度は聞いたことのあるSOLIDの原則。特にオープン・クローズドの原則って、意味が分からない! という感想を持った方は少なからずいらっしゃるかと思います。この講演では、PHPのコード例を示しながら、どのような状況でSOLIDの原則を持ち出すのか、および、原則を適用するとコードがどのように変化するのかを、新人PHPerと先輩との掛け合い形式でお話します。

このトークにかける思い

私の「SOLIDの原則ってどんなふうに使うの?」は、講演を聞いていただく参加者のみなさんに、コード設計が効果を発揮する場面を、擬似的にではあるけれども体験してもらえる内容になっています。このような体験によって、コードを設計していく上で重要になる「コードの設計を見る目」を、参加者のみなさんが獲得するきっかけになってほしい。これが私のねらいです。

PHPカンファレンス福岡に参加される多くの方は、PHPerKaigiには参加していらっしゃらない方だと思います。また、ひょっとするとPHPerKaigiで私の講演を聞いて頂いた方が、またいらっしゃるかもしれません。

基本的な内容はPHPerKaigiのときのものと共通になりますが、取り上げるコード(実装要件の部分)は少し変更します。初めての方でも、オープン・クローズドの原則をきちんと理解いただけますし、2回目という方には、より理解を深めていただける内容になるかと思います。

 

すでに参加募集が始まっています。是非ご参加を!

eventon.jp

eventon.jp

論理力を鍛えるための本

「自分は論理的思考がニガテなのかもしれない。」

そんな疑念を強く持ち始めたのは、ほんの5年ほど前のことだ。それ以前は、論理的思考がニガテだなど、一度たりとも考えはしなかった。

学生の頃は数学は得意科目。今は職業プログラマーとして食べている。プログラミングというのは、世間的には論理的思考を高度に要求する活動とされている。それを仕事でやっているのだから、知らず知らずのうちに、自分には人より優れた論理的思考力が備わっていると思い込んでしまっていた。なんと非論理的な・・・。

5年前に思い立って論理力を鍛えようと勉強し始めたが、何を学べば自分の論理力なるものを鍛えうるのかなど分からず、手探りしながら右往左往した。それを何年か続けてきて、どのようなことをやると良いのかが何となく見えてきた。同じようなことを望んでいる方向けに、メモとして残しておこうと思う。 

文章の構造を見定める力を鍛える

「論理力」を構成する要素の一つとして、文章の構造を見定める力というのがあると思う。与えられた文章が言わんとしていることを的確に読み取るためには、その文章の構造を分析的に眺めて説明するといったことができなければならない。私が自分に論理的思考力が無いと感じたのは、後から振り返ってみると、この構造を見定めるスキルや感覚の無さを感じていたのだと分かった。

このスキルを身につけるには、実際に文章の分析を繰り返すしかない。とはいえ、上手く整えられた練習問題があれば、自分の段階に合わせて効率よく練習していける。以下の2冊の本には、そのように整えられた練習問題が豊富にある。

論理のスキルアップ - 実践クリティカル・リーズニング入門(アン・トムソン)

論理のスキルアップ―実践クリティカル・リーズニング入門

論理のスキルアップ―実践クリティカル・リーズニング入門

 

この本(練習問題含めて)はまだ半分くらいしか読めていないのだが、それでもとても良いトレーニングになっており、他の人にも第一にお薦めしたい一冊だ。なぜか。文章の論理構造を的確に把握するためには、個々の文の内容と推論の進む方向との関係性のようなものを頭に描く力が必要になる。私の目線からすると、この本では、ある文と別の文とをつなぐ推論にスポットが当てられている。推論がうまくつながる文と、逆につながらない文とを比較して、どのような理由で「つながる」のか、「つながらない」のかを考えられるようになっている。このように「比較しながら考えられる」ことが、とてもよい練習になる。

本書の練習問題から1つだけピックアップする。

練習問題3 理由を見定める

この練習問題は、与えられた「結論」に対する理由が何であるかを見積もるトレーニングである。各問題において、結論に対する理由として適切なものを選び、なぜそれが正しく、他が誤った答えであるのかを述べよ。その理由それ自身が正しいかどうかを気にする必要はない。もし、それが正しいとした場合に、結論を支えるかどうかのみを考えればよいのである。

 

2 結論:ある仕事に対して働き手を選ぶときに、雇い主は、応募者の持つ技術ではなく、性格に基いて、決定を下すべきである。

(a) 性格は時がたてば変わるかもしれないが、技術は時代遅れになってしまう。

(b) 技術を教えるのは簡単だが、性格を変えるのは難しい。

(c) 技術の中には誰でも身につけられるわけではないものが存在するが、性格ならば誰でもよいものを身につけられる。

(p.20、21)

結論として述べたいのは、応募者の技術よりも性格を重視することが、雇い主にとってメリットがある(経済的に等)ということだ。

「論理的な思考のトレーニング」に慣れていないと、回答に迷うだろう。たとえば私たちプログラマーは一般的には持っている技術を重視して欲しいという願望が強いためか、回答 (c) を選んでしまったりする。または諸行無常的哲学を好む人が回答 (a) を選んでしまったりする。この問題は、そういうことを問うているのではない。ここからすでに論理的思考のトレーニングが始まっている。

 論理レーニング101題(野矢茂樹)

論理トレーニング101題

論理トレーニング101題

 

 論理のトレーニングと言えばこの本というくらい有名な本(改訂した「論理トレーニング」や、さらに内容を大幅にリニューアルした「大人のための国語ゼミ」もある)。接続表現(接続詞)からスタートし、それを主要な分析の観点として文章の構造を紐解く力を鍛えるような本だ。この本も私はまだ半分くらいしか読めていない。

前半の接続表現のトレーニングでは、自分が普段何気なく使っている接続詞が結構適当で、文章の意味を取りづらくしていることに気づくことができた。当然文章を書くときにも常に接続詞を気にしながら書くようになり、一定の効果があったと思える。

後半は文章の論証の構造を「論証図」に表しながら分析するというトレーニングになっているが、これが私には難しかった(なので途中で挫折中)。

本書の練習問題から、接続表現の入門問題を1つだけピックアップする。

問5 次の①〜⑦を、この順番で、[  ] 内に示された接続表現を各一回ずつ用いて、一連の文章にまとめよ。ただし、内容を変えない程度に文は適当に変更してよい。

[しかし、すなわち、そして、だから、ただし、たとえば、なぜなら]

 

① 論理トレーニングで大事なのは論理的な文章を数多く読むこと。

② さまざまな接続表現に注意することである。

③ 論理とは言葉と言葉の関係にほかならないが、それを明示するのが接続表現である。

④ 「しかし」という接続詞は多くの場合「転換」を示している。

⑤ 「しかし」の前後で主張の方向が変化している可能性が高い。

⑥ 議論の方向を見失わないためには、「しかし」という接続詞に注意することが必要となる。

⑦ ときに接続表現は省略されるので、その場合には自分でそれを補って読まねばならない。

以前の私は「ただし」という接続詞(や、それを変化させた「ただ」)を多用していて、それがおかしなクセだということにこの本を通して気づいた。

古典論理学の基礎知識

「論理力を鍛える」という文脈では、この記事前半で紹介している練習書で問題にあたると効率が良い。そういうことを知らなかった私は、最初は「論理を学ぶなら論理学」という考えで、論理学から攻めていた。教養として知っておくと何かの役に立ちそうなので、2冊の本を紹介する。

議論の論理―民主主義と議論(足立幸男)

議論の論理―民主主義と議論

議論の論理―民主主義と議論

 

この本のメインコンテンツは第二章の「議論と論争の一般理論」で、トゥールミンモデルを元にした議論についての理論解説が素晴らしい。それは別として、第一章「古典的「議論」論」では、三段論法論がいくつかの例とともに簡潔にまとめられており、論理学を体系的に学んでいない私にはありがたかった。

例えば、アリストテレスの成果によって、三段論法は256通りのパターンが可能だが、そのうち正しい推論(妥当な推論)となるのは24通りだ。それ以外は虚偽である。虚偽にもいくつかの分類がなされているが、そのうちの一つ「不当周延の虚偽」の例文は次の通り。

「失業問題を解決できなかった政府はすべて非難されるべきである(all X is Y)。しかし、ナチス政府は失業問題を解決できなかった政府でない(not Z is X)。それゆえ、ナチス政府は非難されるべきでない(no Z is Y)」

p.60

こんな文章が出てきたら、個々の文の意味や書き手の意図を汲み取る以前に、その「形式」だけで虚偽と判定が下される。三段論法って、ありがたい。

 論理学(野矢茂樹)

論理学

論理学

 

命題論理から始まり述語論理を経て、ラッセルのパラドックス、メタ論理、最後にゲーデルの不完全性定理まで到達する。体系的というわけではないけれど、論理学の方法のエッセンスを積み上げながら学んでいける本。私がなんとか読みこなせたのは第2章の述語論理までなのだけれど・・・。

解説は部分的に野矢氏、道元老師、無門老師の掛け合いで進んでいくというのも面白い。分かって無さそうだった無門老師が突然鋭い発言をしたりする。

また、私はこの本を読んで初めて、証明というのが何をすることなのか分かった気がする。

おわりに

学生の頃にもっと国語を真面目に勉強しておけば良かったという、小並な気持ちもあるけれど、その一方で、大人になってから思い立って勉強するのも悪くないし、遅くもないとも思える。大人になっていろいろ経験した自分だからこそ、本に書かれていることがズシリと腹に落ちるような学び方ができるんじゃないだろうか。

知るを知るとなし、知らざるを知らずとなす、これ知るなり (論語)

 

「哲学思考トレーニング」を読んだ

職場での雑談で「趣味は哲学」などと折に触れてネタのように話している。それに触発されたのか、はたまたそろそろ私を黙らせてやろうとでも思ったのか、真相は定かではないが、アラフォー仲間でもある同僚が『哲学思考トレーニング』読み始めたとのこと。私もKindleで買って読んでみた。

哲学思考トレーニング (ちくま新書 (545))

哲学思考トレーニング (ちくま新書 (545))

 

 

どんな本か?

この本は、「(著者の言う)哲学的クリティカルシンキングを、思考に関する論理や哲学の方法による補強を加えながら、解説したもの」だ。書名に「トレーニング」とあるが、問題が掲載されているようなスタイルではない。

中心にあるのは「(著者の言う)哲学的クリティカルシンキング」であり、この方法によって、いくつかの問いにどのようにアプローチし、分析し、考え、結論を出すのかを、この分量の本にしては比較的丁寧に書いてある。解説は平易で、たまに哲学の用語などが出てくるが、その用語を作った哲学者のエピソードなども手短に書かれているため、親切だ。

このような本なので、たとえば、仕事で参加しているミーティングで、話し合いや議論が苦手だと思っている方や、議論はある程度できるが、もっと鋭く議論を進めたいと思っている方が読むと、新しい視野を開くガイドにはなると思う。

感想

私は哲学を完全に趣味・独学でやっているだけなので、網羅的な基礎知識はない。アリストテレスの三段論法論など良く知っている部分もあったし、逆に懐疑主義だったり科学哲学のあたりは、まともに本を手に取ったことすらなかったので、私としては新鮮な気持ちで読めた。