エンジニアのソフトウェア的愛情

または私は如何にして心配するのを止めてプログラムを・愛する・ようになったか

アレグザンダー祭り:宿題がいっぱい

感想は帰宅して興奮覚めやらぬままに書いたとおりですが、今回は特に「楽しかった」では済まない宿題をたくさんもらった思いです。
土日と頭を冷やしながらその宿題について考えていました。

で。本当はもっとまとまった文章にしたかったんですが、文章を考えているだけで風化してしまいそうなので、恥ずかしいのを覚悟でベタ書きのままアップしました。
(読み返してみても小学生の作文だ…)

Object

「いままでどれぐらいのオブジェクトを書いたか?」「クラスでなくてオブジェクトを」
クラスとオブジェクトの話題は繰り返し目にしたことはあります。それに対するわたし自身の立場は保留で、踏み込んで考えたことはありませんでした。ただスタイルは「クラス指向」です、明らかに。この間、C++からLuaに翻訳したとき、「わざわざクラスを書いている」という感触がありました。そういった感触を感じていたのは、いつものようにクラスを基づいて考えている(自分にとって自然な考え方をしている)という感触と同時に、どうして(クラスを持たない)Luaでクラスを書いているんだろう?という違和感を感じていたんだと思います。


中埜さんのワークショップの中でも、図面を見せたときにはなにも言わなかったのに、実物大の画あるいは模型を見たらどんどん意見が出てきた、という話がありました。

実体がともなわないと、人間は感覚としてわからない?

数日前にgod objectネタをTwitterに書きました。で、どうしてgod objectを頻繁に目にするのか…という考察を書こうと考えていたんですが、言及しようとしているのはobjectなのかclassなのか、わからなくなりました。わたしが目にしたのはメンバ関数:230個、メンバ変数:201個のclassなわけでして。

Pattern/Pattern Language

「いまのソフトウェアのパターンはアレグザンダーのとなえたパターンの価値を失っている」「失った価値を取り戻すべき」
Twitterにも書いたように、パターンというものの表面しか理解してなかったのかもしれない。はじめてGoFのパターン本を読んだときに、こういうとらえかたがあるんだと新しい道具を手に入れた気になっていましたが、その考えどまりでパターンというものを矮小化していたのかもしれません。
人にとってよいと感じる構造の組み合わせを分析した結果、密に集まる組み合わせがあることにアレグザンダーが気がついたのがパターンのきっかけとの話でした(わたしの聴きまちがいでなければ)。つまり、単なる便利な道具ではなくて、よいものを生み出すためのものがパターン。

また、中埜さんと一緒にワークショップをされた笹川さんと懇親会で席を一緒にする機会に恵まれたんですが、笹川さんはパターンの「言語」の部分の大切さを説いていました。パターン単体ではなくてパターンランゲージ自然言語の美しい文章が、ただ単語を並べただけのものではないのと同じように。
それを受けて「パターンは(建築やソフトウエアだけでなく)普遍的に存在するのかもしれない」と言ってみたところ、笹川さんもそうかもしれないと言っていました。

Quality

「QUALITY」。
これほどとらえどころない、そして重要で必須のものはないんじゃないかと思うほど、講演、ワークショップをとおして繰り返されていました。

デマルコの著作「ゆとりの法則」の中でAdobe Photoshopの品質のよい点として9つの項目があり、9番目に欠陥が比較的少ないこと、というのがあります。残りの1番目から8番目の品質のよい点では、どうしてPhotoshopがよい製品と感じるかという点について書かれていました。この内容にずっと違和感を感じていたんですが、ほんの中で書かれていた品質という言葉がqualityの訳語で、それとここでのqualityとが同じものを指しているのだろうと気がついて、ようやく腑に落ちた気がします。

中埜さんいわく、qualityを測る計測器をわたしたちは持っている。上で「実体がともなわないと、人間は感覚としてわからない?」と書きましたが、逆に言うとある条件のもとではその感覚がきちんと機能する…。


iPhoneが出たとたん、日本国内の携帯電話は全部時代遅れになった」「機能があるとかないとか、欠陥が多いとか少ないとか、そんなんでなく、iPhoneはユーザに『iPhoneを使ってるんだ』という感覚(満足感?)を与えてくれる」…という話をときどきするんですが、懇親会の席でもその話をしたところ、同席された方々も大なり小なり同じような感想を持っていることをしりました。たぶん、iPhoneにはあってほかにはない、iPhoneのqualityなんだと思います。

ちなみに、中埜さんもiPhoneをひいきにされているそうで、実際iPhoneを使っていました。というか。二次会の場所へ移動中、ふと見回すと3分の1ぐらいの人(7〜8人?)はiPhoneを使っていて、「どんだけiPhone密度高いんだ!?」と。

Service/Product

「ソフトウェアはproductじゃない、serviceだ」というのは、浸透してきている方だと思っています。ただ、それをいまの仕事の上でどう解釈して対応付ければいいのか未だにわかりません。
メーカーという会社の性質のためか、仕事の上ではソフトウェアは製品の部品の一つのように扱われています。それは単に「もの作り」と「ソフトウェア開発」の考え方の違いという単純なものでなくて、何かがかみ合っていないというか、なんというか。




ここまではまだ考えが及ぶことができたんですが、次の3つは未知の領域のうえに英語力がなくて、まずは知ることからはじめないとならないものです。

Agile & Lean

Lean is for complcated product.
Agile is for complex product.

正直、AgileとLeanの区別がついていません。それぞれかじってはいるんですが…。
Coplien氏の講演のなかでそのちがいについて話があって、その場ではそのちがいはわかるんですが、実際のソフトウェア開発と知識が繋がらない。
「自動車はcopmlicatedで、人間はcomplexだ」と言っていたと思うんですが、そこから理解を深めないといけないのかも。

DCI

一週間前は知らない言葉でした。
このイベントの前日におこわなわれた早稲田大学での講演から手を付けようと思います。

Geometry

もっと英語ができたら、とほんとうに思いました。どうしてgeometryなのか。形のないソフトウェアにどうして幾何学的特性なのか。単にアレグザンダーの言葉を流用しただけ…ではなくて、意図があってgeometryという言葉(と意味)を使っているのだと思いますが。

ソフトウェアには形がない、といえば。「ソフトウェアには物理法則の制限がないんで、どんなにひどいソフトでも動くものは動いてしまう」という話に対し「建築は物理法則と法律でだいたい決まってしまう」と笹川さん。言われればそのとおりなんですが、法律という別の制限があることに気付かされました。


夢見る力

講演とワークショップ以外で。一昨日の感想でも書いたように、今回のイベントは、懸田さんと角谷さんの「夢見る力」が実現させたんだと思います。加えておふたり以外のスタッフの方の「夢見る力」も加わって。
そもそも、オブジェクト倶楽部自体も平鍋さんをはじめとるする方々の「夢見る力」の結果なのかもしれません。

Decade

わたしのlast decadeは…2000年は難治性の病を患うところから始まりました。そこから無理と我慢を、とくに仕事の上で、してきたような気がします。なにもかもが思うようにならず、2005年末には気分障害――ひらたく言うとうつ病――を患ってしまい、昨年夏には一ヶ月ほど休暇をとるはめになりました。未だ全快にはいたっていません。
十年先どころか、一年先はもちろん、一ヶ月先、一週間先さえ見通せない状況もしばしばありました。

社外のイベントやセミナーに参加するようになったのは2005年の末からだったと記憶しています。気分障害を患ったのと初めてイベントに参加した時期とが重なったのは偶然ですが、その後まめに参加していたのは、ひとつには出口を探していたのだと思います。

いまでも出口は見つかっていませんが。
今回のイベントでは「出口を探すなんてしてる場合じゃないぞ、やることいっぱいあるぞ」と言われた感じがします。
気分障害は、原因はともかく、症状自体は身体の(脳の)疾患なので、気持ちでどうこうなるものではありませんが、あとから――十年後から?――見たらここが転換点だったということになるかもしれません。