設計の楽しさ

本書、ソフトウェア開発についての本。平たく言うとプログラミングをするときのセオリーとテクニックと心構え、についてで。

で、「モデル」ってよく出てくるんだけど 『現実の複雑な物事を、どういう枠組みで捉え直すか』という名付けや見取り図のこと。

モデルとは簡素化である。 つまり、当面の問題を解決する上で関連する側面を抽象化し、それ以外の詳細を無視することによって行われた、現実に対する一つの解釈なのだ。

未熟時代に買った時は、ただ良いコードを書きたかったからセオリーとかテクニックとかを中心に読んでた。 でもおっさんになった今読み返すと、心構えのほうがグッとくる。 ソフトウェアのエンジニア(おれはその中でもweb / appという狭い範囲) って外から見たら「こういう機能を作ってください」って頼まれて「はい、できました」って作る人と思われがちだけど、それ最後のほうにやるやつで。

基本的なセオリーとかテクニックで「はい、できました」を作るだけだとあんま面白くない。それはそれとして学んどく必要はあるけど。 やっぱ現場のにっちもさっちもいかないクソ汚いだけに見えるたくさんの要望や制約を、お手玉しながら考えるのが楽しい。

最初は大きいのや小さいのや重いのや軽いのや赤いのや青いのや三角なのや四角なお手玉が1,000個くらいある。 実装したり話したりずっとお手玉してると、少しずつお手玉が減っていき、回す軌道も安定してくる。 大きいとか小さいとか見えてたのが、中身と袋のサイズが違ってただけでシュッとしたら同じ大きさになったり、赤と青に見えてたのが見る角度が違うだけで、実は両方とも紫だったり。 で、どのお手玉投げる時の腕の動かし方も同じで済むようになって、脳みそ使わんでよくなるようなモデル(新しい抽象)が出来上がる。

バラバラに見えるものをまとめ直すための「新しい見取り図」を見つけるってことで、本書に出てくるこの、群盲象撫での例がそれ。

二つのモデルが同じ部分に対して別々の見方をしていると、問題はさらに難しくなる。 二人の男が鼻に触れ、一人がヘビと言い、もう一人が消防ホースといっていたとしたら、さらに厄介になっていたはずである。 どちらも相手のモデルを受け入れられないが、それは自身の経験と矛盾するからである。 実際、 二人に必要なのは新しい抽象だ。

ここで言う「新しい抽象」ってのは、うざいこと極まりない無限に出てくる現場の制約や矛盾をぜんぶ呑み込んだ上で、「これしかない」という一本の筋を通すことだ(現実界としてそんな綺麗に1本にはならんけども)。 別々のものに見えていたものが、実は同じ根っこを持っていたと気づくこと。あるいは、まったく違うふたつが組み合わさって、必然の形を見つけること。 この「新しい抽象」を生み出すこと。これすっげえ楽しいの。

具体的に言えば、 実装しながら「うーん、これ設計ちゃうな、何がずれてんのやろ？」「あー、このモデルがイマイチしっくりこねえ。どーすっかな。あーでもねえこーでもねえ、あ、これだ！」

原因がなんであれ、 設計の根本において概念が欠如しているソフトウェアは、せいぜい役に立つことは行えても、その行為を説明することができない機械仕掛けにすぎない。 しかし、オブジェクト設計の真のブレイクスルーが訪れるのは、コードがモデルにある概念を表現した時なのだ。

その新しいモデルを持ってビジネスの人に話に行くと、「言われてみればそうっすね、そうそう、いやむしろそれしかない。」となる。

で、この楽しさって色んな職種に共通してて、 「仕事が楽しい！」って思う時の5割以上はこの「新しい抽象」を生み出せた楽しさなのではと思う。

デザインとか料理とか

design => 設計、意匠や装飾。 日本語に訳すなら第一はまず、「設計」であって。付随するというか「衣装や装飾という意味でも間違いではないよね」くらいの順番だと思ってる。

例えば柳宗理のいう「デザインとは質の改善」であり「デザイナーの本分はアイデアマン」だということ。

私のデザインは豊満なボリュームがあり、すぐそれと分かるという。 しかし、私としては、かたちより中身が問題である。飯を食えば、ひとりでにほっぺたがふくらむものである。ふくらみがどうのということには余り苦労しない。 即ち、かたちは外から与えられるものではなく、 中身から必然に出るものだと思っている。 即ち、中身をどのように、ものにするかという工夫に精力の殆どを使うわけである。 いいデザインの創造とは、 表面上のアピアランスの変化ではない。創意工夫をもって内部機構を改革することである。 デザインの形態美は、 表面上のお化粧づくりからだけでは出て来ない。内部からにじみ出たものである。 本当の美は生まれるもので、 つくり出すものではない。すなわち外見より質の改良である。 アイデアマン、 デザイナーたるべき基本はここに在るのではなかろうか。

柳のやかんのあのかっこよさ。「まじでやかんだ、やかんっつったらこれだ、やかん最終形態やん」感。 あれも柳が「やかんってどういうのが良いんだろう、あーでもねえこーでもねえ」つって工場の人たちと相談しながら用途と素材と形とコストとをずっとお手玉しててある時見つけた「これや！」の用途と素材と形が一番しっくりくる「新しい抽象」だったんじゃないかと思う。

概念のど真ん中を極める「完璧な肉じゃが」みたいな方向もあれば、前提をひっくり返して「いちご大福」や「瞬間湯沸かし器」を生み出しちゃう方向もあるけれど。 どっちに転ぶにせよ、デザイナーであれ料理人であれエンジニアであれ、その必然の形を見つけたときの「これだ！」の快感は同じなんじゃないかと思う。

時折、試している最中に「絶妙の組み合わせ」に出会えるのは、もう、職業上の楽しみになっています。ぜんぶ把握はしていないけれども、野菜には必ず兄弟がいるんですよ。これとこれを組み合わせると、劇的に素材のよさが引きたつような… その兄弟どうしはまだ会っていないことが多いのですが、でも、どこかに必ずいる。 仲人がぼくであるといいなぁと思います。信じられないような組み合わせを発見したい。 そして時には、他人によって汚され尽くしたような平凡な組み合わせを、加熱や調理のタイミングを変えることによって、まったく新鮮な兄弟として再び出会わせてみたい。 何かを組み合わせたり振りかけたりすることによって、別な新しい価値が生まれる。 そこが料理のおもしろさを象徴するものであり、お客さんがあれをまた食べたいなと再び来てくださる原動力なのだと、ぼくとしては考えています

でだ、その「できた！」の楽しみのためには、手をつけ始めたときはひたすらに「うぜー」と思うような、制約が必要なんじゃないかと。主に「仕事」と呼ばれるやつに含まれる制約が。 実際の現場では、予算だったり時間だったりお客さんのリテラシーだったりおれの技量だったり、足りないものがたくさんある。

で、わりとそういうの、そんときは「うぜー」と思うけど腐らずにお手玉やってると、「あ、こんな新しい抽象作れんのね」ってびっくりすることもある。

おれだけの「正しい」では足りない

携わってる仕事に対して、まずは自分(に任せられた職域)にとって何が正しいかってのを考えて、そこに納める基本的な技術は大事だけど、それだけだともったいない。 エンジニアだけで閉じた「きれいなコード」とか「美しいアーキテクチャ」って、確かにキレイではあるけど「はいはい、それね。」になってつまんねーんだよな。 もう一個二個うぜーもん取り込んでひと絞りして「おお、面白い！」出したい。

現場のドメイン（業務や使われ方）のドロドロした理屈に踏み込まずに作ったシステムは、言われた通りに動くかもしれないけど、相手の本当の思考とは一生噛み合わない。 だからこそ、もうちょっと色んなお手玉取り込んで、ぐるぐる回した方がいい。

技術系の人は、しばしば、ビジネスエキスパートをドメインモデルから「遮断する」必要を感じる。 そして、こんなふうに言うのだ「彼らには抽象的すぎる」「オブジェクトが分かってない」「彼らの用語法に従って要求を集めなければならない」これらの言い訳は忘れること。 もちろん、ドメインエキスパートとは関係のない設計上の技術的なコンポーネントはあるが、モデルのコアは、 彼らの関心を引くべきである。 抽象的すぎる?それなら、どうしてその抽象化が適切だと分かるのか?

それはデザイナーにとって、お客さんの「使いやすい」かもしれないし。 料理人にとって、お客さんの「美味しい」かもしれない。 技術の人間としてお客さんを圧倒するようなことではなくて。

「これならわたしも作ることができるかもしれない」 と思いながら、お客さんは食べてくださる。それが大切なのです。 食べ終わった方に「斉須さん、あの煮込み、とてもおいしかった。今度わたしも作ってみますね」と言っていただけるのは、とてもうれしいです。 1,2週間ぐらいして、「できなかった。鍋に入れてやわらかくなるまで煮込んだら、グシャグシャになっちゃった」と言われたりもします。 やってみてはじめてわかる難しさなんです。結果としていいなと思える歯触りのためには、火を落とす時間を決めることと同時に、火を止めてからどのぐらい加熱調理が進行するかも把握しておかないといけない。

自分にとっての「いい設計」「使いやすい形」「美味しい料理」と、 お客さんにとっての「ああ、言われてみれば、それだ」「使ってる時わかんなかったけど、別のメーカーの使ったら使いづらくて戻ってきた」「美味しかったから作ってみようと思ったけど、できなかった。」

本当に優れたモデルや設計って、受け手からすると「努力の痕跡」が見えない。あまりに自然で必然だから、最初からそうだったようにしか思えないのよ。 でもその裏には、火を止めるタイミングや、無数の制約をお手玉し続けた狂気のような試行錯誤がある。

ごりっと技術でどやってするんじゃなくて、そういうスルッと入っていく「プロの上手さ」「ユーザが無意識で使える」が同居してんのが大事で。 前者は自分一人で磨けるけど、後者と混ぜる練習は、やっぱ「うぜー」の制約が無限に入ってくる毎日の仕事の中でしかできない。

自分ひとりの「正しい設計」だと面白さが足んない。チームや現場やお客さんの無意識の「あ、それだ」にはまらせにいってハマったときが楽しい。 なんで、クソだるいけどお手玉しましょう。 エンジニアであれデザイナーであれ料理人であれ、そういう設計が決まったときの快感こそが、「仕事の楽しさ」なんじゃないすかねー。

余談。末端の実装ソルジャーでも、手元の素材とお手玉する設計の余地はある。ってのを別記事で書いてる。

いくら料理長にマイクロマネジメントされたとて、おれの手ときゅうりの間まではマネジメントできない。

ここまで書いて思ったけど、「新しい抽象を作り出す」なんて大げさなこと言わんでも「工夫する」で事足りる。 冷蔵庫の中にあるもんで、うまいもん作るおかーちゃんのように。