時を超えたプログラミングの道の開始宣言としての「XPはソーシャルチェンジである」
『Kent Beck, Cynthia Andres. エクストリームプログラミング』を読み直しました。
エクストリームプログラミングは、Kent Beck が C3 プロジェクトで実践してうまく言った取り組みを、極端なほど（エクストリーム）にやってみよう、という声かけ、というところまでがこれまでの理解でした。
しかし、クリストファー・アレグザンダーのデザインについての考え方、いろいろアレグザンダーの著書や彼の考え方の建築家による解説・評価を見回ってから見回すと、味わいが変わっていました。
たとえば、XP本では、造園家をメタファーに使っていたりするのですが、そのメタファーの中では、アレグザンダーがデザイン問題についての考察の中で定義した「フォース」という言葉を使用しています。最終的な形に対して様々な文脈・周りのステークホルダーが影響を与える力、といったところです。
フォースという概念定義について深く知りたいと思ったら、 長坂 一郎さんの『クリストファー・アレグザンダーの思考の軌跡―デザイン行為の意味を問う』が参考になります。
読んでぼんやりと学んだこと思ったことを書き連ねていきます。
XPの構造
エクストリームプログラミングは、「ペアプログラミング」などといったプラクティスが目に付きますが、大きな構造としては、価値・原則・プラクティスです。
価値：自分たちにとって何が重要か、評価の軸になるもの。なぜそのプラクティス を行うのかの目的となるもの
プラクティス：価値を具体化したもの。状況によって個々のプラクティスの価値が 高 かったりそうでなかったりする。価値の説明責任を果たす
原則：抽象的な価値と具体的なプラクティスを橋渡しするもので、活動の指針
そして、すべてを網羅することが「XPをやっている」というゼロイチではなくて、あくまで考え方のベースラインのようなものと捉えると良さそう。実際、「プラクティスを適用するかどうかは選択だ」と本書自身が言っている。
価値 Value
XPでは、コミュニケーション・シンプリシティ・フィードバック・勇気・リスペクト、の5つの価値を採用している。フィードバックなんかはアジャイルにやっていると「そうだよね」っていう感じになりますが、勇気・リスペクトというラインナップがソフトウェア技術書で見るのはこの本が初めてだった。
しかし、これだけではないと本書は言っていて、あくまでこれはXPの原動力となる価値になるが、それ以外の価値を組織・チームに合わせて選択しても構わない、と言う。
そして、大事なことは選択した価値に自分たちの振る舞いを合わせることとしています。ただ大事だと言っても、価値は具体的なアドバイスを提供しているわけではない。そこで橋渡しとしての原則があることで、日々行っているプラクティスを通して、自分たちの振る舞いが価値に合っていくという構図になる。
原則
14の原則を提示している。これらの概要をシュッと押さえたい・思い出したいときには ryuzee さんの解説スライドがわかりやすい。
人間性・経済性・相互利益・自己相似性・改善・多様性・ふりかえり・流れ・機会・冗長性・失敗・品質・ベイビーステップ・責任の引き受け、といったラインナップ。
それぞれの詳細は、本を読んだほうが速いが、ふりかえり（Reflection）なんかは、自分たちがどのようにして優れたチームになるか、という一つの指針を与えていると思う。
優れたチームは単に仕事をしているだけではない。どうやって仕事をしているのか、なぜ仕事をしているのかを考えている。
これは、スクラムのフレームワークなんかでは、レトロスペクティブといったイベント名として自分たちの仕事の様を振り返る時間をとったりする。
その際に、「どうやって」・「なぜ」を相互に問うことが重要であるという点をXPの原則は思い出させてくれる。それらを意識する時間であることが、価値に合わせた振る舞いになる鍵だろう。
プラクティス
19のプラクティスから構成されている。
プラクティスは主要プラクティス(primary practices)と導出プラクティス(corollary practices)に分かれる。主要プラクティスはすぐにでも改善に繋がり安全に始められる。導出プラクティスは、先に主要プラクティスを習得して置かなければ難しい。
こういう分かれ方をしていることは、プラクティスの選択において知らないと厳しいだろう。プラクティスに対して批判していたり、失敗したと言っているときに、そもそもその導入プロセスにおいて、この選択の順番を間違ってなかったかは、冷静になって振り返るといいのかもしれない。
よく聞く、ペアプログラミングやテストファーストプログラミングなんかは主要プラクティスの一つとされていたりする。
個人の欲求とチームのニーズのバランス
これは、最近ずっと難しいと感じているが、それは非常に一般的に難しい話なんだと XP 本でも語られていて安心した。これは、原則の１つ目 人間性（Humanity）の説明から引用。
チームによるソフトウェア開発で難しいのは、個人の欲求とチームのニーズの両方のバランスをとることだ。個人の長期的な目標とチームのニーズが合っていれば、多少の犠牲は払うべきだろう。だが、常にチームのために個人の欲求を犠牲にしているようでは、うまくいくはずがない。
小野和俊さんの『その仕事、全部やめてみよう――１％の本質をつかむ「シンプルな考え方」』では、仕事していく上で大切なことについて次のように語ってる。
仕事をしていくうえで大切なのは、よいものを作り上げて世の中に届け、企業を成長させること。そして、みなが生き生きと仕事をして高く評価され、幸福だと感じることだ。
XPは、パタン・ランゲージからInspireを受けて生まれたものの比較軸として、デザイン・パターンをおいたときに、技術だけではなく人にも焦点を当てたもの。そうした側面が、原則の最初に「人」に関する人間性（Humanity）が置かれる点、その中の説明から垣間見える。
なぜ価値、原則、プラクティスを用意したか
その理由は次のように説明している。
XPが価値、原則、プラクティスを用意しているのは、ガイダンス、チャレンジ、説明責任を提供するためだ。たとえば、「仕事の協力がうまくいかないのであれば、人間関係やパフォーマンスが改善するかを確認するために、こうこうこういう理由で、これらのことを試してほしい」と伝えることができる。
これまで仕事を「うまくやってきた」人たちは、素晴らしいアイデアですねといいつつも行動は起こさない、という状態になりがち。でも、価値・原則を自分たちで選択した場合、その価値・原則に照らし合わせた場合どちらの振る舞いが自分たちの価値に適しているか、について議論することができる。
XPの時を超えたプログラミングの道
第23章のタイトルは「時を超えたプログラミングの道」。アレグザンダーの著書をいくつか手にとったことの有る方であれば、すぐこの著書の名前が思い浮かぶと思う。
アレグザンダーは、近代主義の建築を嫌い、建築家の自己中心的な関心事は、そこに住まう人たちの関心と一致しないことを指摘した。
アレグザンダーのデザインプロセスの民主化の志向
ちょっとそこから脱線かもしれないが、脱線じゃないかもしれないと思い、改めて自分の理解を文章にして確認していく自己満足を展開する。
『形の合成に関するノート/都市はツリーではない』では、その現象をデザインの３つの段階と整理した。
図面でデザイナーのイメージの世界だけでデザインを進めるイメージの段階と表現し、直接の設計対象に対して間接的であるがゆえに間違える可能性・そして処理対象の情報量増大には耐えられないという点を指摘した。
そこで彼がダイアグラムなどの概念（後のパタンにつながると認識してる）では、形式的操作の段階、つまりより一般的で抽象的な記号での操作によるデザインプロセスにすることで、デザイン・プロセスを誰もが理解できるようにし、民主化しようとした。
彼は形とコンテクストをすべて記号化し、デザイナーの経験や勘に頼っているこれまでの曖昧なプロセスに代えて、デザイン・プロセスを誰もが理解できるようにグラスボックス化・民主化しようとした。その後アレグザンダーの方法は大きく転回するが、デザイン・プロセスのグラスボックス化・民主化をめざすという目標は現在に至るまで変わっていない。
なお、難波和彦さんの考察文のその後の展開にある通り、具体的な内容を捨象することなく民主的なデザイン・プロセスを実現する方法へと向かうことになる。
アレグザンダーのビジョンとXPのビジョン
さて、脱線かもしれない話を終えて、というか多分脱線だったんだが自分の難波和彦さんの再考文章の読みが勝手に深まったのでちょっと満足しているのだが、それはおいておいて。
アレグザンダーは、「生き生きとした場所をもたらすこと」を目的に据えた。
アレグザンダーはそのための手段として、建築のパターンを収集し、家の設計や構築で繰り返し発生する問題の解決策をまとめた。パターンはそれ自体を目的としたものではなく、設計の専門家とその空間で生活や仕事をする人たちとの力のバランスをとる手段エクストリームプログラミング
そして、アレグザンダーのビジョンの中では、建築家の役割は、空間を使う人の好みや社会的な人間関係を深く理解し、建築家の技術に対する深い理解と結びつけることとした。そして、これらの２つの観点が調和されることで、人間の欲求（コンテクストからのフォースとの適合）を満たすことができる。
ソフトウェア開発の仕事に対して、アレグザンダーが戦ってきたことと同じ状況を目の当たりにしたと Kent Beck は本書籍で語っている。
ソフトウェア開発の仕事を始めたときに、私は力の不均衡を目の当たりにした。それは、アレグザンダーが建築の世界で戦っていたのと同じものだ。私はシリコンバレーで育った。そこでは、エンジニアリングが王様だった。「あなたに必要なものを与えよう。必要かどうかは知らなくても構わない」。よく引き合いに出されたモットーだ。このようにして作られたソフトウェアは、技術的には優れていたが、役に立たないものが多かった。
いわゆる、アレグザンダーが指摘した建築家自己中心的なデザインをされたソフトウェアに対する違和感だろう。
そして、また逆の状況も起きたと言っている。
経験を積んでいくと、正反対の不均衡を目にするようになった。ビジネスの関心事が開発を支配する世界だ。ビジネス上の理由だけで期日やスコープを設定すると、チームの誠実性を維持できない。
そのため、Kent Beck の目的は、「チームが技術とビジネスの関心事に常に調和をもたらせるように支援することである」と表明している。
「エクストリームプログラミング（XP）はソーシャルチェンジである。」
これは、たびたび引用される有名なフレーズだが、「時を超えたプログラミングの道」を読んだあとに振り返ると、チャレンジの表明にも聞こえる。
アレグザンダーは空間の設計者・利用者の力のバランスを取る試みは、最終的に失敗したと評価している。しかし、ソフトウェア開発は建築とは異なり、建築の材料とソフトウェア開発の構成要素が違う。これまでの失敗を再現する理由もないし、これまでの人間関係に縛られてはいけない。
これまでの人間関係とは、自然に影響を受けていた、テイラー主義であると読めると思う。
これは、世界初の生産技術者（industrial engineer）のフレドリック・テイラーが研究して生み出した分野である。彼自信の学説は「科学的管理法」として知られる。
XP では、このテイラー主義がもたらす仕事の社会構造が問題になると指摘している。
ソフトウェア開発で問題となるのは、テイラー主義に伴う仕事の社会構造だ。テイラーが提唱した「時間・動作研究」の儀式や道具こそなくなっているが、我々は無意識にこの社会構造を継承しているのである。その社会構造は、ソフトウェア開発にまったく適していない。
具体的には、計画立案と実行作業の分離・独立した品質部門の設置、といったテイラー主義によるソーシャルエンジニアリングの手順、それが生み出す社会構造に、ソフトウェア開発の社会構造も委ねるべきではないとしている。
そして、建築とソフトウェアはそれぞれ構成要素が異なる。そのため、社会構造をこれまでのやり方に合わせる・継承する必要もない、という主張だと理解した。
ソフトウェア開発は建築ではない。我々の構成要素は、建築の材料とは違う。我々の社会構造は、数千年も変わらない人間関係に縛られてはいない。我々は、ソフトウェア開発において新たな社会構造を作り出し、そのなかで技術的な高みとビジネスのビジョンを結び付け、独自のバリューを持ったプロダクトやサービスを生み出す機会を持っている。これが我々の強みだ。
ソフトウェア開発における、設計者・利用者の力のバランス・調和を生み出す、新しい社会構造を作る、実際に作れる そんなチャレンジがC3プロジェクトで行われたことであり、XPがソーシャルチェンジである所以ではなかろうか。
生き生きと働く
最後の結論では、次のように言っている。
私はプログラマーの生活をよくするためにXPを体系化した。
実際、各章では、疲弊した開発現場の例が度々出されるところから、プログラマーの生活を良くしたいっていう意思があるのか？と感じるところはあり、最後のこのセリフには一貫したものを感じる。
そして、生活を良くするには技術だけでは不十分であり、関係者の人間関係・社会構造を新たに捉え直すべきだと、という思考プロセスだったのかもしれない。
XPの価値は、ビジネスの世界で実践すべきものだ。快適に暮らせる生活を送るだけでなく、関係者全員がお互いにリスペクトした人間関係によって、新しい働き方を開発するのである。活発に積極的に、世界に貢献できるソフトウェアを作り出すのである。創造的にいきいきと働くのである。
以前、『Engineers in VOYAGE ― 事業をエンジニアリングする技術者たち』を読んだ際に、Zucks という会社のある種極端に見えるプラクティスに対して、次のような事を、TDDでおなじみの和田さんが言っていた。
2000 年くらいに XP が出てきたときのことを思い出しました。あのとき、ケント・ ベックが書いた本を読んでも、それだけでは「なんでこのやり方でうまくいくの？」という のが全然わからなかったんです。 XP を解説した本では、いくつかのプラクティスが示されているんですが、一つひとつの プラクティスを見るとすごく無茶なものもあったりします。でも、実はそういう個々のプラクティスが補完しながら、全体の系としてうまく回るようになっているんですよね。 / 第 2 章 Zucks ――― フルサイクル開発者の文化
それぞれのプラクティスも相互に補完し合いながら回るようになっている構造を作り、それをもってビジネスと技術の調和を生み出そうとした。
そういうムーブメントだったんだな、と思うと、XPはちょっと前の話とかでもなく、すごく味わい深いと思うのです。
（以上、自己解釈雑文を終わります）
この記事が気に入ったらサポートをしてみませんか？