パターン、Wiki、XP ~時を超えた創造の原則
読書目的
デザインパターンというコンテクストで必ずと言っていいほど登場する人物「アレグザンダー」とは何者なのか、建築とソフトウェアの類似点はどこか、Wiki＝WikipediaのようなものというWikiへの浅い理解の解消、「時を超えた創造の原則」というサブタイトルの響きのかっこ良さから本書を手にとった。
本まとめ
第１部 建築
・老練な大工は、後で修正できないようなことは決してやらない。だからこそ、自信たっぷりと着実に仕事を進めていく。
・アレグザンダーの出した結論は、利用者と専門家が協力関係を築き、パターンランゲージを作り上げ、適切な設計を現場で一歩ずつ生み出していくという、新しい理論と思想だったのだ。
・アレグザンダーは、自然都市が備えている質のことを「無名の質」と呼んだ。
・「無名の質」という言葉は老子の「道（タオ）」についての教え、「「道」は名づけ得ぬものである」という言葉にインスパイアされたものだと思われる。
・パターン・ランゲージは単なる部品集でも事例集でもなく、利用者と建築家をつなぐためのさまざまな工夫の集積である。パターンはそのための道具の一つなのだ。
・パターン・ランゲージの「ランゲージ」は人間同士のコミュニケーションの道具という意味で付けられた名前ではないのだが、利用者と建築家はパターンを語彙としてコミュニケーションに活かすことが出来るため、利用者と建築家をつなぐ共通言語としても機能する。
・哲学者プラトンは哲学者を建築家にたとえた。思想もまた建築的に作り上げられていくべきだ。
・パターン・ランゲージでは、各々のパターンは上位と下位のパターンとのつながりを持っているが、それらをどのように組み合わせるかについてのルールはない。パターンが適切な形で組み合わされると質は高くなり、生き生きとしたものになるが、組み合わせが不適切だと質は低くなり、生き生きとしたものにならない。
第２部 ソフトウェア開発
・1968年12月、スタンフォード研究所の研究者ダグラス・エンゲルバートは、サンフランシスコで開かれたコンピュータに関する会議で、伝説的なプレゼンテーションを行った。マウスによってポインタを動かし、画面上にウィンドウを開いて対話的にコンピュータを操作するというもので、「GUI」という新しい概念を提示した。
・1984年、AppleはMacintoshを発売。一般的な企業や個人でも変える価格帯で発売されたMacintoshは、研究室でしか使われていなかったGUIを瞬く間に世界に広めた。
・建築の利用者が設計すべきだとアレグザンダーが言ったのと同じように、ベックとカニンガムはシステム利用者に最終設計をしてもらうことにした。
・設計されたユーザインタフェースを見て、二人は非常に驚いた。簡素だが、非常にエレガントなデザインが実現されていたのだ。
・BOF（Birds of a Feather）：特定のトピックに興味を持つ有志の集会
・一般にグローバル変数はプログラムのどこからでも読み書きができるため、使うことが推奨されていない
・オブジェクト指向ではこのような「グローバルな状態」を管理するための専用のオブジェクトを用意することがあるが、そのオブジェクトはアプリケーション全体で一つしか存在しない前提が守られなければ、バグの温床になる。
・ソフトウェア開発において「町」「施工」といった粒度に相当するパターンは何か？
→「施工」に相当するパターン：「実装」
→「町」に相当するパターン：ソフトウェア全体の基本的な構造である「アーキテクチャ」
・「C3プロジェクト」（クライスラー総合報酬プロジェクト：COBOL給与計算プログラムの刷新）が、エクストリームプログラミングの記念すべき最初のプロジェクト。
・「リファクタリング」の著者：マーチン・ファウラーもC3プロジェクトにコンサルタント（タスク分析とテスト支援）として関わっていた。
・C3プロジェクトのプラクティス
→テスティング：実際のコードよりも自動テストのコードを多く書くほど、テストを重視
・プロジェクトの４つの変数は以下。これら４つについて誰が決定権を持っているのかを確認し、彼らが適切な判断を下せるように開発状況と見積もりを報告する
→スコープ：何をすべきか。実装すべき機能。
→品質：求められる正確さやそのほかの「良さ」の基準
→リソース：人員や設備など、プロジェクトに投入可能な制限
→時間：プロジェクトの期間
・ユニットテスト：全てのクラスは、正常に動作するかを確認する自動単体テストを持っていなければならない。クラスを書く前に、まずユニットテストを書くことを推奨する。
・継続的インテグレーションと徹底的なテスト：個々の開発成果を頻繁にコードベースに結合し、ユニットテストを100％パスする状態を常時保つ。
・どうせ必要にならないって！：現在の要求を満たす必要十分なコードだけを書く
・コード所有権：コードの所有権を開発したチームだけに留めない。
・ペアプログラミング：二人一組でプログラミングを行う。具体的な実装イメージをはっきり持っている方がコードをタイプし、もう一人はそれを注意深く見守る。タイプミスや文法間違いなどの細かい視点や、システム全体との整合などの大きな視点で相手をサポートする。進捗が早くなり、長時間スピードが落ちず、質も高まる。
- 週４０時間労働：２週続けて労働時間が超過しないようにする
- プロセスやツールよりも、人と人との交流を
- 計画に従うことよりも、変化に適応することを
- システムを出来る限りシンプルに保つ。状況は変化する。予想で将来に備えた作業をすると無駄になる可能性がある。無駄なことに時間を投資しないように意識する。
- 勇気：プロジェクトがまずい方向に進んでいることに気づいたとき、それを修正するための勇気を持つ。例えば、一日中取り組んでうまく行かなかったコードをいったんすべて捨てて、翌日ゼロからやり直す。また、プログラムの根本的な問題に気づいたとき、今までうまく動いていた他の部分を犠牲にしても、それを修正するための大きな変化を行う。
- 改善：完全であることを目指すのではなく、改善できることから順に改善していく
- 機械：問題を変更の機会としてとらえる
- 冗長性：重要で困難な問題には、冗長性を持って対処する
- 小さなステップ：可能な限り、小さなステップで変更を行う
- ストーリー：顧客の要求は、顧客の目に見える機能単位でシステムがどのように動くのかを記した「ストーリー」と呼ぶ短い文章として表現する
- １週間サイクル：１週間サイクルで作業を計画する。週の初めのミーティング：進捗確認、その週に実装するストーリーを確認。
- ゆとり：どのような計画にも、遅れが生じた場合に捨てることのできる、重要でないタスクをいくつか含めておく。
- テストファーストプログラミング：コードを変更する前に自動テストを作成する。
- 根本原因の分析：５回のなぜ。突き詰めると技術ではなく人間の問題であることがほとんどである。
- コードとテスト：コードとテストだけを成果物として保持し、それらから他のドキュメントを生成する。顧客にとって、本質的に価値があるのはコードとテストだけである。それ以外の無駄は極力省くようにする。
- 結合は、自分たちの開発成果が他の全体と矛盾していないかどうかを検証する作業。この間隔は長くなればなるほど矛盾するリスクが高まるため、数時間置きに頻繁に行うことが推奨される。
- 「テストファーストプログラミング」プログラムの実装は、テストをパスすることを目標に行う。
- リファクタリングと機能の追加や変更を同時に行なってはいけない。
第3部 Wiki
・「キャメルケース」（CamelCase）とは、英単語の１文字目を大文字にして、２単語以上をくっつけたもの。
・World Wide Webの誕生は1991年
・WikiName：キャメルケースによるリンク表現、Wikiの本文中にキャメルケースで文字列を示すと、それがそのままページヘのリンクになり、ページが存在しない場合にはページ作成画面へのリンクとなる。
・Wikiモードで重要視されていた２つの区分：「スレッドモード」、「ドキュメントモード」
・「スレッドモード」：主観的な意見の集積から成り立つ。各自の最後の意見に「--」に続けて署名を残し、それが縦に連なっていく形式。フロー情報。
・「ドキュメントモード」：ページが客観的な記述の集積から成り立っている状態。主観的な記述が排除されている状態。辞書や百科事典のような記述。ストック情報。
・その他のモード：「ハイブリッドモード」「オピニオンモード」「FAQモード」「パターンモード」
・Wikiページのライフサイクル
- 何を記録するためのページかという「宣言文」を記述
- この宣言文に対して、各自が自分の考えを主観的に署名付きで記述。
- 議論が発展し、ページはスレッドモードとして成長
- 議論が合意を得た場合、その合意事項を客観的な記述としてページ情報に残す。：ハイブリッドモード
- 残っていたスレッドモードの議論がある程度沈静化したところを見計らって、ドキュメントモードに誰かが移行する。
・「Wikiマスター」：冷静な視点を持ち、参加者のさまざまな意見を公平に取り上げつつ合意に達する判断力やコミュニケーション能力が求められる。
・Wikiは、誰もが自由に、他の人の記述も含めてどこでも書き換えられます。それが非常にラジカルで、すごいことなのだが、その代わりにそのような環境を維持するためには非常に大きな努力が求められる。
・パターン形式：パターンモードで使われるパターンを記述するための形式
- パターン名：ページタイトルとして、パターンの名前を述べる
- 状況と制約条件：問題となる状況と、その解決のために考慮すべき諸条件について述べる
- それゆえ、（Therefore, ）：太文字で「それゆえ、」と一行書く
- 解決策：問題の解決策について、いくつかのパラグラフで述べる
- しかし、（But, ）：太文字で「しかし、」と一行書く
- 反論：上記の解決策についての反論を述べる
・Wiki設計原則
- 開放の原則：不完全なページやうまく整理されていないページを見つけたら、どの読者でも自分が適切と考える形に編集できる
- 斬進の原則：ページは、まだ書かれていないページも含め、別のページにリンクすることができる。（→Wikiの斬新的成長を促す）
- 信頼の原則：Wikiで最も重要なこと。人々を信頼せよ、プロセスを信頼せよ、信頼構築を可能とせよ。誰もがコンテンツを管理し、チェックする。
- 楽しさの原則：誰でも貢献できる。誰も強制されない。
- 共有の原則：情報、知識、経験、アイデア、視点を共有せよ。
・XPとWikiは、アレグザンダーの建築理論という同じ出発点を持つ、兄弟のような関係にあると言える。
・XPのプラクティスを参考にWikiを記述していくことが出来る。Wikiはドキュメントを記述する環境だが、まるでソフトウェアを開発するかのように考えて使っていくと、うまく発展させていくことができる。
・ドナルド・クヌース：アルゴリズムの研究などで有名なアメリカのコンピュータ科学者。1968年、彼はコンピュータのアルゴリズムをまとめた書籍「The Art of Computer Programming」の第１巻を出版。このシリーズは未だに執筆が続けられている。全７巻を予定しており、現在は第４巻の分冊まで刊行されている。第５巻は2015年出版予定。1938年生まれのクヌースは2015年には77歳を迎える。
・クヌースは、プログラムは「文学」と同じように芸術的な存在として認められるようになるべきだと主張し、「文芸的プログラミング」という手法を提唱した。文芸的プログラミングは、プログラムも一種の文章として、きちんと人間が頭から読める形式として記述する手法。プログラム全体を文章中に埋め込む形で記述する。
・wikipedia.comサイトの立ち上げは2001.1.15
・はてなダイアリーは日本独自のWiki文化の一つ。
・ニコニコ動画では、タグの編集を誰でも行えるようにすることで、タグの編集をあたかもWikiの編集のように扱っている。
あとがき
・XPのプラクティスを入り口として、自分たちの開発プロセスを改善する方法を自分たち自身で考え続け、そこから得た経験をまたプラクティスとして抽出するようにする。
・利用のルールを自分たち自身で考え続けて実践することで、はじめてWikiをWikiらしく使いこなせるようになる。
・デザインパターンもXPもWikiも、取り入れれば改善されるという魔法の手法ではなく、自分たち自身のプロセスを見直し、改善出来る点を改善し続けることによってようやく有効に働くようになる生成的なプロセスである。
