個人の Wiki に 2009 年に参加したトークセッションのメモ書きが残っていた。2019年の今読むとまた面白いのでブログの記事として公開してみる。トークセッション自体は 2009 年に行われたものだ。パターン、Wiki、XP ーー時を超えた創造の原則

20090710:トークセッション「時を超えた創造の原則」参加報告。

『パターン、Wiki、XP』という本の刊行を記念したトークセッションへ参加してきました。これらの源流に建築家クリストファー・アレグザンダーの思想と思考と哲学を見出し、ソフトウェア開発との接点を探るという内容でした。

構成は

『パターン、Wiki、XP』の概要説明 (江渡浩一郎さん)
XP とアレグザンダーについてのトークセッション (かくたにさん、懸田さん)

の二部構成。

『パターン、Wiki、XP』について。

Wiki
- qwikweb の開発者
- 機能拡張をするときに機能を追加したのに悪くなることがある.なぜだろう？と考えた
- Wiki の本質を強化する機能は良い機能である
- しかし Wiki の本質って何ですか？
パターン
- デザインパターンで何だろう？
- アレグザンダーのパターンランゲージを元にしたと紹介されるけど、全然違う
- 一番最初のパターンの論文 (ケント・ベックとワード・カニンハムの書いた論文) を読んでみた。おもしろい！
- そこにあった言葉。「コンピュータユーザーは自分自身のプログラムを書くべきなのである」

つまり、本来目指したのは「使う人間のためのパターン」

使う人間が自分のほしいものを表現し実現するためのパターンランゲージを志向していた。

XP
- クライアントと開発現場の関係を根本から見直す必要がある
- オンサイト顧客のような開発に参加するクライアントという関係を築くためには、いついつまでに何を作りますよ。それで支払はいくら発生しますよ。というコミットメントの関係ではむずかしい。
- その関係性自体を変えるよう切り込まないと本質的な解決にならない

Wiki, XP, パターンはあるものでつながっている。それは問題意識。顧客との関係性という問題意識でつながっている。Wiki はパターンや XP の土台になるもの。

クリストファー・アレグザンダー
- 初期と後期で全然言っていることが違う
- 「形の合成に関するノート」(1964)
  - デザインするという行為を数学的な問題に落とし込む
- 「都市はツリーではない」(1965)
  - 自然都市と人工都市の二項対立
- 「オレゴン大学の実験」(1975)
  - 利用者参加の建築へ舵を切る
- 「パターンランゲージ」(1977)
  - 建築は要求条件が多すぎてデザインしきれない
  - 利用者が建築の設計を自分たちで参加できないか
- 「時を超えた建築の道」(1979)
  - パターンランゲージの背景を解説した理論書
  - 「無名の質」
  - 自然都市に表れるような言葉で表現できないけれど何かよいというような質
形を科学することの本質的困難性
- 量や長さを科学することは比較的たやすい
- 一方、形を科学することはむずかしい
- 中谷宇吉郎「科学の方法」(1958)
  - 雪の結晶(という形)を科学した人

パターンは形を科学の対象とすることに挑戦している。(形の要求の再現性にトライしているという意味。)

トークセッション。テーマはXPとソフトウェア開発。

パターンに「それに従えば成功する正解の型」というイメージがついてしまった。

これは本来のパターンの意図していたものとは違ってしまった。

次の言葉を。

そこで今はたとえば「アジャイル」(「リーン」もあるけど、リーンはコンサルの手に落ちちゃったと言われてたり。)

アジャイルマニフェスト。

プロセスやツールよりも個人との対話を
包括的なドキュメントよりも動くソフトウェアを
契約交渉よりも顧客との協調を
計画に従うことよりも変化への対応を

(https://agilemanifesto.org/iso/ja/manifesto.html から引用)

なぜか力をもったチームが自然にできてしまう土壌がアジャイルやXPにはある。

自然に生起するような意味あいでジェネラティブ～(generative)という言い方がアレグザンダーでよくされている。日本語にするなら生成。とか。

デザインパターンは生成の力とは逆行するコンセプトとして広まってしまった。(「必要なことに都度対応し、繰り返し改善しようと変わり続け、自然と育った結果としてのよいデザイン」というようなものではなく、「最初からこうしておけば間違いないよ」という模範解答(しかもケースの中でのバランスやトレードオフのデザインという色合いが薄まった模範解答)として理解されてしまっている。)

では、どんなパターンを探るべきなのか。

ハッカーはパターンを自然にやってしまう。どう開発をするとよいのか。品質を保ち、優れたインターフェイスを備え、拡張性も備えたソフトウェアを開発するためにはどうしているのか。彼らがやっていることに再現性を持たせなければならない。

たとえば、XP はそれに挑戦をしている。

よい開発の文化をつくる。
最小の構造から少しずつ成長する
- 人間もそう。パーツをそろえて組み立てるんじゃない。小さくても動く完結した一揃いの個体があって、少しずつ大きくなる。

XP を見に付けるためには。アートオブアジャイルデベロプメントを読むのがおすすめ。これはアジャイルの本になっているけど、内容は最新のXPの本でもある。

具体的にはどんなことがある？

たとえば「コミュニケーションを改善しよう」という。でもこんなことを言ってもコミュニケーションは改善しない。

XP では具体的にできる小さな行動に落とす。

あいさつをする
朝会（あさかい）をする
ふりかえりをする

一つひとつはツールだけれど、これを文化にする。文化にするとそれは「コミュニケーションが改善された状態」になる。(これもコミュニケーションが改善された状態という形の科学。形は直接目指せないけれど、形を得るためのプロセスに再現性を持たせることはできるはず。という信念のアプローチ。)

いきなりゴールの状態は実現されない。やれることから少しずつやる。繰り返しやる。壁があったら修正してできることに調整する。そうしてだんだんうまくなっていく。ばーっとは変われない。

質疑応答で出た話。

メンテナンサビリティ(保守性)が大事っていうのが言われるのは、それがないと変われない、つまり繰り返しの成長のプロセスを実現できないからかもしれない。変わるために小さな修正の単位(パッチ)をソフトウェアにあてていく。それを繰り返しやっていくためには変化を許容する構造を保ち続けないといけない。