村上春樹の小説を初めて読んだ（雑文集、職業としての小説家、騎士団長殺し）
私はこれまで、村上春樹の作品を避けてきた。まともに読んでもいないのに。
まわりから聞こえてくる噂から、私の中で村上春樹作品は、（いろいろな方面で失礼な書き方になってしまうかもしれないが）官能小説のようなものとカテゴライズされ、そして未熟な頃の私は、それを自分には不要なカテゴリーだと決めつけて人生を生きてきたように思う。
ところがここ最近の私は、小説というものになぜだか興味が湧いている。そこで語られるストーリーはもちろんなのだが、どちらかといえば、ストーリーの語り方、語る順番、言葉の選び方などといった部分に。「小説技術」とでも言うのだろうか。何らかの意図を伝えるのに必要な構造としての小説、そのような側面にすごく興味が湧いている。もちろん、そこに「設計」と通ずるものがあると個人的に感じているからだ。
そのような最近の傾向もあって、書店へ行くとかなり幅広くいろいろなジャンルの棚を回って、目についたタイトルの本を手にとってパラパラとめくってみる。その時その時で自分の追いかけているテーマやキーワードがあって、そのものズバリではないのだけれど、ふと引っかかる言葉が見つかったりする。過去に気になって調べていたことや、どこかで聞いた言葉が、それとは思いもしなかったタイトルの本の中にたまたま出てきたりする。そういう期待ばかりを求めているわけではないのだけれど。
そんな風にして書店で偶然手に取ったのが『村上春樹 雑文集』だった。手に取る時点で私には若干のためらいがあった。何しろこれまでの人生で、ずっと避けてきたカテゴリーのものだったのだから。しかし私の「小説そのものへの興味」がその時はわずかに勝ったようだった。
この本に収められている、最初のエッセイ「自己とは何か（あるいはおいしい牡蠣フライの食べ方）」は、次のような文で始まる。
小説家とは何か、と質問されたとき、僕はだいたいいつもこう答えることにしている。「小説家とは、多くを観察し、わずかしか判断を下さないことを生業とする人間です」と。
この一文を読んで、私は続きを読まずに本を閉じた。一文を見ただけで、この本を買うことに決めてしまったからだ。
私がこの本と出会った頃、ある人と「ソフトウェア設計者の資質」について話していた。何らかの領域を生きる道として歩いている人に備わる傾向、それがソフトウェア設計という領域ならばどのようなものなのか。何らかの基準なのか、能力なのか。先天的に持つものなのか、後天的に獲得しうるのか。そんな話をしていた時だった。そのようなテーマを脇に抱えていた私は、この「小説家とは」という文に強く惹かれた。
雑文集には牡蠣フライのエッセイ以外にも、エルサレム賞受賞時の挨拶文や、音楽についてのエッセイなどが掲載されていた。短いエッセイからでも、この文章を書く村上春樹という人が、小説というものをどのように捉えているのか、そして小説という構造をどのように生みだしているのかが、垣間見えた。
そうこうしているうちに、村上春樹という作者への興味がだんだんと強くなってきた。もう一冊村上春樹の本を読んでみよう。その時点でも、村上春樹の小説作品はまだ、私にとって「避けたいカテゴリー」に属したままだと感じていたが、この雑文集のようなエッセイはとてもおもしろく、同じようなものが他にあるのではないか、あれば読みたいと思った。そして見つけたのが、『職業としての小説家』だ。
タイトルを見た瞬間に探していたのはこれだと思った。そして、ものすごく興味深く読んだ。この本を読んでいるある時点から、私の中では「村上春樹とはすごい人だ」という認識に変わった。
またソフトウェア設計の話にそれるが、最近学んでいる本で大きなテーマとして取り上げられているキーワードの1つに「長期的」というのがある。「時を超えた」とも表現される。かなり長い時間を基軸として物事を考える姿勢だ。たとえばスチュアート・ブランドのTHE CLOCK OF THE LONG NOWには、1000年や10000年で1まわりする時計を自己の内側に概念として持つことが提案されている。そのような概念的な時計を持つことで、長期的な視点に立てるのだと。
「職業としての小説家」には、いくつか時間にまつわる話が書かれている。物事を語るリズムとしての時間、オリジナリティと時間といったもの。それはこの本のメインコンテンツではないけれど、今の私にはよく響く内容だった。
そして私はついに、このような考えや態度のもとに、この村上春樹が書いた小説は、どのようなものなのか知りたくなった。もうこれは読んでみるしかないと思った。そうして選んだのが、村上春樹のもっとも新しい長編小説『騎士団長殺し』だ。
本屋へよく通う私は、「騎士団長殺し」の存在を発売前から認識していた。どの本屋でも大きくキャンペーンされていたからだ。しかし私はできるだけそれを避けるようにしていたので、どのような内容なのかはまったく知らなかった。
読んでみようというタイミングになって本を手に取った時、そのサブタイトルに驚いた。「第1部：顕れるイデア編」「第2部：遷ろうメタファー編」。私は哲学も大好きなのだ。このサブタイトルを見ただけで、「何、何、どういうこと？」と好奇心を抑えられなかった。この本は最後まで読むだろうと直感し、1部と2部を同時に購入した。
内容には特に触れないが、私のいろいろな感情や知識や魂を刺激してくれるもので、読み終わってとても満足している（だからこうしてブログまで書くことにしたのだ）。
私は騎士団長殺しという物語を読みながら、その背後や物語の中に村上春樹自身を見、それと同時に、自分自身を見ているようだった。この本に至るまでの流れからも、必然的に読まれるべき作品を読んだような気がする。それはとても不思議でもあり、また、それはありふれたことなのかもしれないとも思う。
引き続き村上春樹の小説を読むかどうかはまだ分からない。今回は運良く読まれるべき本に出会えただけなのかもしれない。しかし、もう少し幅広くいろいろな小説を読んでみようという気持ちは強くなった。
Netflix「ワイルドワイルドカントリー」を観た
Netflixオリジナルドキュメンタリー「ワイルドワイルドカントリー」を観た。人から薦められたということは一切なく、Netflixで「自然」の映像を探していたところ、たまたま目にとまったという偶然だった。
「あるカルト宗教の興隆・没落を記録したドキュメンタリー」と聞けば、多くの視聴者は「カルト宗教に入信しない、一般市民」の側に自身を自然と位置づけるだろう。しかし、ワイルドワイルドカントリーは、どちらかといえば、カルト宗教内部にいた人たちへのインタビューに、多くの時間がかけられており、市民側前提で観ようとしていた私は最初戸惑った。カルト宗教の導師であるバグワンが、アメリカのオレゴンへ行く前、インドにいた頃から話は始まるのだが、その頃のバグワンのコミューン（アシュラム＝道場と呼ばれていたそうだ）には、とても活気があり、クリエイティブな活動も活発だったようだ。そこに住む人々は幸せそうだった。やや奇妙な教え（性に対して開放的なこと）もありはしたが、全体的にみて、この宗教がものすごく狂っているとは思えなかった。
そのように思えたのは、この作品の演出によるものなのかもしれない。しかし私が「この人たちはまともな人たちだ」と思えたのには、カルト宗教内部の人としてインタビューに答える人たち、とくにシーラという、一時期教団の実質トップだった女性の話し方などから、聡明さや強さといったことを感じたことも大きい。作品全編を通して、「今現在の」シーラへのインタビュー映像が多く使われる。彼女は過去に教団の内部の人間として、数々の犯罪行為を主導したその人だ。そのような人にも関わらず（いや、そのような人だからなのか）、過去を話す口調に迷いがなく、力強い。
罪を犯した。これは良くないことだ。しかしその行動に至るさまざまな状況で、教団側は常に悪だったのだろうか。教団と一般市民との間に摩擦要素があることは仕方ないことだが、どちらか一方のみを悪と決めつけて良いことではないと思う。もし私がこの市の住民なら、または、教団側の人間なら、どのように考え行動するだろうか。
観て笑って楽しむような作品ではないのだけれど、いろいろなシチュエーションにおかれた人から何かを感じとりたい方にはお薦めかと思う。そして是非最後まで観て頂きたい。
『現場で役立つシステム設計の原則』への些細な批判
増田亨さんの『現場で役立つシステム設計の原則』について、こちらの記事で私の解釈を書いた。（未読の方はご一読いただければ幸い）
背後の原理を理解した上で、私の意見として述べておきたいことがあるので、この記事を書いている。
なお、この批判は、増田さんの方法論の成り立ちの部分に対するものだ。方法論全体を間違いだと否定するものではないし、この方法論によって構築されたソフトウェアや、方法論を現場で利用している方々を否定するものではないことは、どうかご理解願いたい。
重箱の隅をつつくような、細かな話をしているように感じる方もいらっしゃることと思う。しかし、そのようなところにこそ「方法論の機微」が見え隠れするものだと思う。設計や方法論を探求したいと思われている方には、考えを深めるわずかなヒントになるのではないかと思う。
（以下、書名を「現場で役立つ本」、この本で述べられる方法論を「増田方法論」と記載。）
独自進化した「変更容易性」という強すぎる観点
「現場で役立つ本」に書かれた増田方法論における「変更容易性」は、私の解釈では次のような定義だ。
ソフトウェアに変更が必要な時に、ソースコード上で変更しなければならない箇所を特定する時間の短さの度合い。および、変更作業にかかる時間の短さの度合い。
このような定義を前提におけば、増田方法論の理屈はとても分かりやすい。しかし、いくつかの問題が生じていると思う。
1つ目。上のような定義はソフトウェアの変更容易性と呼ばれる考え方の中で、ある1つの狭い領域でしかなく、また、決して主流の捉え方というわけではない。にもかかわらず、増田方法論では変更容易性としてこの観点しか取り上げない。これは、増田方法論の中では、変更容易性という言葉を、一般的なものとは別の意味で採用しているということだ。しかも、本には上のような定義がされているわけではなく、暗黙的にそうなっているというのがまた厄介だ。
すでにある概念を転用するならば、一般的な意味との違いの明示などを丁寧にやることで、無用な混乱を避けられるはずだが、そのようなこともされていない。
2つ目。「ソースコードを変更することがかんたん」という、非常に分かりやすい観点は、その分かりやすさの代償として、他の設計観点を押しつぶしてしまう。どういうことか。ソフトウェアの設計においては、歴史的にさまざまな知見が積み上げられてきた。実績をともなって機能してきた正真正銘の方法論や設計ノウハウがあり、研究されエッセンスが抽出されて、いくつかの設計原則として語り継がれている。そのような設計原則の中には、コードに対するパッと見のかんたんさとは相容れない観点を要求するものがある。たとえば抽象化による情報隠蔽を適用すると、具象部分である細部のコードへトップダウンにアクセスすることは、多少難しくなる。しかしそれでもなお、情報隠蔽にはソフトウェア設計として価値がある。なぜなら、そのような情報隠蔽によってこそソフトウェアの構造が整理され、コードが読みやすくなる側面があるからだ。そしてこれは私個人の意見というわけではなく、多くの人がそう言っていることなのだ。
しかし増田方法論における変更容易性には当てはめづらいように思われる。なぜなら、トップダウンでコードにアクセスしづらくなるということは、増田方法論においては「コードがわかりにくくなる」ことだからだ。したがって、これは私の単なる推測の域を出ないのだが、情報隠蔽やモジュール化、デザインパターン等々、コードが一見小難しくなる設計は、増田方法論においては遠ざけられてしまうのではないだろうか。
結局のところ「ソースコードの変更がかんたん」という観点が、ソフトウェア設計に利用するには強すぎるのだと思う。これを中心に据えてしまうと、設計のための方法論としてのバランスを保てないように思う。
おわりに
増田さんの本に書かれた内容（の私の解釈）に対しての、私の意見を書いてみた。私のこのようなやり方は、一歩間違えば「藁人形論法」に陥ってしまう危険性がある。そうならないよう、解釈がそれ自体きちんと成立するよう誠実に行ったつもりだ。
私の意見の根本的なポイントは、杉本さんの記事で言われていることと同じだと思っている。未読の方は是非ご一読頂きたい。
PHP Mentors -> 「現場で役立つシステム設計の原則」批判 (1) ～何のために、「データとロジックを一体に」するのか？～
『現場で役立つシステム設計の原則』の根幹にある原理
「現場で役立つシステム設計の原則」の「原則」って何だろう？
また、その原則をつなぎ合わせることで得られる設計は、どのような世界観を持っているのだろう？ どのような原理で説明されるのだろう？
ソフトウェアの設計に興味を持つ人間なら、そんな興味がどこからか湧き出てきてしまうもの。そんな思考の結果を記事としてアウトプットしておく。
（以下、書名を「現場で役立つ本」と略記で記載。）
現場で役立つシステム設計の原則 ~変更を楽で安全にするオブジェクト指向の実践技法
- 作者: 増田亨
- 出版社/メーカー: 技術評論社
- 発売日: 2017/07/05
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (1件) を見る
増田さんの「現場で役立つ本」に書かれていることに私の解釈を与えて、本に書かれている方法論の世界観や原理を逆算してみた。そのようにして得られた世界観や原理を元に、「増田さんの方法論とはどのようなものか」を私なりに解説する。
以下では、「現場で役立つ本」で述べられているやり方群を「増田方法論」と呼ぶことにする。
なお、これはあくまで私による解釈だ。増田さんの言いたい本質と一致している部分があるかもしれないし、大きく違うかもしれない。この点ご承知おき願いたい。
増田方法論の根幹原理
現代のソフトウェア開発において、いかに変更に耐えていくのかということは、最も大きな悩みの種だ。したがって、ソフトウェアのソースコードにおける変更の行いやすさ＝変更容易性が、重要なトピックとなる。増田方法論は、ソースコードの変更容易性を高めることを第一の目的としている。
変更するたびに変更が大変になっていく、このソフトウェア変更の負のスパイラルから抜け出すにはどうすればよいでしょうか。
「現場で役立つシステム設計の原則」p.16
増田方法論の基本原則
増田方法論の骨格となる基本原則は、次のとおりだ。
- システムの仕様に影響を及ぼす要素は、すべてドメインレイヤーに集めよ
- ドメインレイヤーのコードを、変更が容易なソースコードとして作成せよ
- 上記2つの原則を、他の設計原則よりも優先せよ
この原則について正しく理解するためには、使われている言葉の意味内容を明確にしなければならない。最も肝となる用語は、最初にも取り上げた「変更容易性」だ。
増田方法論における「変更が容易」なソースコードとは
一口に変更容易性と言っても、定義や実現方法が一つに定められているわけではない。たとえばデータモデルにおける正規化や、歴史的なオブジェクト指向の設計原則などには、変更容易性を高める技術という側面があるだろう。増田方法論では、変更容易性を最も重要な指標として扱っているが、実は変更容易性の捉え方そのものにも特徴がある。
増田方法論における変更容易性は、次のように定義される。
ソフトウェアに変更が必要な時に、ソースコード上で変更しなければならない箇所を特定する時間の短さの度合い。および、変更作業にかかる時間の短さの度合い。
これらの時間が短いことこそ、増田方法論において「変更が容易」な状態なのだ。
ソースコードを整理整頓して、どこに何が書いてあるかわかりやすくする。それがソフトウェアの設計です。
「現場で役立つシステム設計の原則」 p.14
うまく設計されたプログラムは変更が楽で安全です。変更すべき箇所がかんたんにわかり、変更するコード量が少なく、変更の影響を狭い範囲に限定できます。
「現場で役立つシステム設計の原則」p.14,15
増田方法論における変更容易性を促進するための方法
「現場で役立つ本」には、さまざまな方法が紹介されている。それらは基本的に、増田方法論における変更容易性を促進するための方法だ。これらはざっくりと2つにまとめることができる。
- 仕様文章に現れる重要な用語をすべてクラスにする
- ビジネスドメインにおける情報構造の一般形を使う
これらを簡単にまとめておく。
仕様文章に現れる重要な用語をすべてクラスにする
仕様の文章に現れる重要な用語は、漏れなくクラスにしていく。ここで重視されるのが、数量の単位だ。数量の単位は値オブジェクトと呼ばれるパターンを使い、クラスにしていく。こうすることで、値を計算するようなメソッドにおいても、引数や戻り値にプリミティブな値ではなく、クラスを使うことができる。引数や戻り値をクラスにしておくと、メソッド内の処理の前提条件や事後条件の範囲を狭めることができる。前提条件や事後条件の範囲が狭いほど、メソッド内で考慮しなければならない事柄が減り、コードはシンプルになる。同時に、コードを変更した際の影響範囲を限定しやすくなる。結果として、コードの変更を安全に行えるようになる。
ドメインモデルの設計アプローチは、まず部品を特定し、その部品ごとに独立したクラスを設計することです。受注時のルールすべてを扱う大きなクラスは、考えないようにします。数量パッケージと同じように、与信パッケージや基本契約パッケージについても独立して設計します。
そうやって、ある程度の部品がそろってきたら、組み合わせ方を考えます。組み合わせてみながら、個々の部品を調整したり、不足している部品を追加することで、受注ルールに網羅できるだけのドメインオブジェクトが整っていきます。
「現場で役立つシステム設計の原則」p.118
ビジネスドメインにおける情報構造の一般形を使う
ビジネスドメインの情報構造は、概ね次に示す要素に当てはめることで表現できる。
- オブジェクト・・・1つの情報
- コレクションオブジェクト・・・オブジェクトの集合を表す
- 値オブジェクト・・・値や単位を表す
- 区分オブジェクト・・・区分を表す
これらの要素は互いに関係しているため、業務の仕様に登場する用語をこれらの要素に当てはめていくと、業務の概念体系が自然とツリー構造として作られていく。このツリー構造を一旦作ってしまえば、処理として記述すべき業務ロジックをどこに書けばよいのかは、比較的簡単に定められる。
書き方がよくわからない状態で、ドメインオブジェクトを設計しようとしても、時間がかかるばかりです。
その時間を省くには、ドメインオブジェクトの設計パターンを体で覚えてしまうことです。
「現場で役立つシステム設計の原則」p.124
そして、、、
ここに挙げた基本原則や各種方法に従うことで、理想的なソースコードのツリーは、仕様に現れる用語が業務ごとに体系的に整理された状態となるはずだ。そのような状態になったソースコードのツリーでは、業務の体系をたどるようにソースコードをたどることができる。業務用語に関係した処理は、その業務用語に対応するクラス内に書かれているため、どの業務処理のコードがどのクラスに書かれているのかを、瞬時に見つけることができる。一つ一つのクラスは十分に小さく作られ、メソッドの入出力の範囲は小さく明確で、ロジックの重複もない。
かくして、ソフトウェアの変更はとても容易になる。
おわりに
このような記事を書いておいて不思議に思われるかもしれないが、私は増田方法論そのもの、および方法論の伝え方といった点で、批判的立場だ。興味のある方は、批判記事も読んでみていただきたい。
しかし、内容を正確に理解した上で、どのような立場をとるのかは各人の自由だと思う。さまざまな立場から方法論を見つめることで、有益な気付きが得られるものだと思うからだ。この記事がそのような議論の一助になれば幸いだ。
PHPカンファレンス福岡で登壇します！
3月のPHPerKaigi 2018に続いて、6月16日(土)に開催されるPHPカンファレンス福岡2018でも登壇させて頂けることになりました。
トーク概要は以下のとおりです。
- 時刻：【Fusicホール】13:00〜13:45
- 「SOLIDの原則ってどんなふうに使うの？オープン・クローズドの原則編 拡大版」
- 対象：中級
- セッション内容：PHPerKaigi 2018でベストトーク賞の講演の拡大再演版です。理解を深めるためのトピックを追加してお話します。
オブジェクト指向プログラミングを勉強したことのある人なら、一度は聞いたことのあるSOLIDの原則。特にオープン・クローズドの原則って、意味が分からない！ という感想を持った方は少なからずいらっしゃるかと思います。この講演では、PHPのコード例を示しながら、どのような状況でSOLIDの原則を持ち出すのか、および、原則を適用するとコードがどのように変化するのかを、新人PHPerと先輩との掛け合い形式でお話します。
このトークにかける思い
私の「SOLIDの原則ってどんなふうに使うの？」は、講演を聞いていただく参加者のみなさんに、コード設計が効果を発揮する場面を、擬似的にではあるけれども体験してもらえる内容になっています。このような体験によって、コードを設計していく上で重要になる「コードの設計を見る目」を、参加者のみなさんが獲得するきっかけになってほしい。これが私のねらいです。
PHPカンファレンス福岡に参加される多くの方は、PHPerKaigiには参加していらっしゃらない方だと思います。また、ひょっとするとPHPerKaigiで私の講演を聞いて頂いた方が、またいらっしゃるかもしれません。
基本的な内容はPHPerKaigiのときのものと共通になりますが、取り上げるコード（実装要件の部分）は少し変更します。初めての方でも、オープン・クローズドの原則をきちんと理解いただけますし、2回目という方には、より理解を深めていただける内容になるかと思います。
すでに参加募集が始まっています。是非ご参加を！
