建築家クリストファー・アレグザンダーの言葉から紐解く、エンジニアが再び“設計の当事者”になる方法 【XP祭り2025 登壇レポート】
『生活にもっとも大きな影響を受ける人の手のなかに、空間を設計する力をとり戻す』
「これは建築家クリストファー・アレグザンダー氏が抱いた夢だとケント・ベックは説明しました。彼は、建築家の関心が、実際にその空間で生活する“施主”の真の願いから乖離しがちであることを指摘しています。
この言葉は、現代のソフトウェア開発に携わる私たちエンジニアにとっても、決して他人ごとではありません」
これは、2025年10月4日に開催された「XP祭り2025」に登壇した、製造ソリューションサービス部 PMの髙橋直規による言葉です。
ウォーターフォール開発に携わっていた10年前は、このアレグザンダー氏の言葉がまったく心に響かなかったという髙橋。
彼は、この言葉の真意に10年越しにたどり着いたという“気づきの旅路”を通して、エンジニアが施主の真の課題解決から遠ざかってしまう構造的な問題を解き明かしました。
-
製造ソリューションサービス部 髙橋 直規
エンジニアやPM、サービスマネージャー（※）として、さまざまなシステム開発案件などに携わった後、アジャイルを専門的に扱うために、3社目として2023年3月SHIFTに入社。現在は、SHIFTの「アジャイル」にまつわるさまざまな案件に入り、プロジェクトマネジメントから実務となるエンジニアリングまで、幅広い領域でアジャイルサービスの浸透／普及に従事している。
（※）複数案件を管理し、滞りなくサービス提供ができるよう責任を担う立場。
目次
なぜエンジニアは“施主の関心”から遠ざかるのか？
私が書籍『エクストリームプログラミング 』をはじめて手にとったのは、2015年ごろのことです。
当時はSESから準委任契約へと私自身の働き方が変わりはじめた時期で、「エンジニアとしてもっと成長したい」という渇望感に満ちていました。
しかし、本に書かれていたベアプロやテスト駆動開発といった内容は、ウォーターフォール開発の深い潮流にいた私にとって、あまりにも遠い世界の話のように感じられました。
正直なところ、そこに書かれていたクリストファー・アレグザンダー氏の言葉も、当時はまったく心に響かなかったのです。
ケント・ベック氏は、アレグザンダー氏の言葉を引用し、「建築家の関心ごとは、施主の関心ごとと一致していない。建築家は仕事をすぐに終わらせて賞を獲得したいと思っているが、重要な情報を見逃している。
それは、“施主がどのように生活したいか”という情報だ」と指摘しています。
この関心ごとのズレは、そのままプロダクト開発における「開発者」と「施主」の関係に置き換えることができます。
10年前の私にこの言葉が響かなかった理由。それは、私自身が施主の関心ごとから物理的にも心理的にも遠い場所にいたからです。
2次請け、3次請けという構造のなかで、私の仕事は与えられた仕様をコードに落とし込むこと。そこに「施主がどのように生活したいか」を考える余地はほとんどありませんでした。
サイロ構造とコンウェイの法則がもたらす「考える人」と「つくる人」の分断
この「施主との距離」を生み出す原因は、個人の意識だけでなく、組織の構造に根深い関係があります。多くの開発組織は、企画、設計、開発、運用といった役割ごとに壁で仕切られた「サイロ構造」になっています。
例えば、書籍『Effective DevOps』では、「サイロ化している環境では、共通理解が欠如しがちだ。全員が共同体に属しているという共通理解があれば、人は修復に向かっていく。」と指摘されています。
開発組織に階層構造や上下関係があると、同じ組織に所属する人たちのなかでも考え方に差異が生まれることがあります。
一部の企画担当者や設計者が施主の近くにいたとしても、その想いや意図が、階層構造の壁を越えて実際にコードを書くエンジニアにまで届くことは稀です。
さらに、「コンウェイの法則」という有名な法則があります。これは「システムを設計する組織は、その組織構造をそっくり真似たシステムを設計してしまう」というものです。
つまり、「考える人」と「つくる人」が組織的に分断されていれば、生み出されるプロダクトもまた、施主の真の課題から分断されたものになってしまうのです。
10年前の私も、まさにこの分断の渦中にいました。設計の意図や背景が十分に伝わらないドキュメントを元に、ただプログラミングを行う。それでは施主の関心ごとを意識することなど到底できませんでした。
施主の想いを形にする、シンプルな解決策
2022年ごろからアジャイル開発に携わるようになり、施主と直接対話し、そのフィードバックを受けながら開発を進める機会が格段に増えました。
1次請けとして、施主の関心ごとを肌で感じられる環境に身を置くようになったのです。
そして今年、『エクストリームプログラミング』を再読し、私は衝撃を受けました。かつては遠い世界の話だと思っていた言葉の一つひとつが胸を打ったのです。
施主との距離が縮まったことで、本に書かれていることの本当の意味を、私はようやく理解することができました。
エンジニアが施主の関心から遠ざかるのは、構造的な問題に起因する。そして、その構造を変え、施主に近づくことこそが重要なのだと。
10年前の私にとって、「設計」とはドキュメントを作成し、レビューし、承認を得るプロセスそのものでした。
しかし、複雑で移ろいやすい施主の関心ごとを、静的なドキュメントだけで捉えることはむずかしく、ドキュメント作成が目的化しやすい傾向にあります。
例えば、『ユーザーストーリーマッピング』の日本語版序文には、「会話と協働こそがエクストリームプログラミングの重要な構成要素」という旨の記述があります。
また、『プリンシプル オブ プログラミング』には、「プログラミング言語に依存しない設計表記を後で誰かがコードに翻訳するよりも、オリジナルの設計者がオリジナルのコードを書いた方がうまくいく」と書かれてあります。
つまり、施主との対話を通じて設計の意図をもっとも深く理解した人物が、自らコードを書くべきなのです。
ドキュメントという中間生成物を介することで失われてしまうニュアンスや背景、熱量を、そのままプロダクトに注ぎ込む。これこそが、施主の想いを形にするもっとも効果的な方法です。
ウォーターフォール開発が主流だった時代、プロダクトがリリースされるとチームは解散、ということも珍しくありませんでした。しかし、一度のリリースで施主の関心ごとが完全に満たされることなどありえるのでしょうか。
『ユーザーストーリーマッピング』は、「あなたの目標は新しい製品や機能をつくることだけではない。将来のポジティブな変化があるからこそ、それをほしいと思うようになる」と説きます。
施主の関心は固定的ではなく、プロダクトを使い、ビジネス環境が変化するなかで、絶えず移ろいつづけます。
この変化に対応するために、「スクラムガイド拡張パック」では継続的な学習とフィードバックの重要性が強調されています。
短いサイクルで「つくって、確認し、適用する」という小さなフィードバックループをまわしつづけること。
これこそが「空間を設計する力」であり、これによってはじめて、私たちは変化しつづける施主の期待に応え、真に価値あるプロダクトを届けつづけることができるのです。
社会や顧客の課題解決に本質的に向き合う「プロダクトエンジニア」というあり方
では、私たちエンジニアはどうすれば、「空間を設計する力」の主導権をとり戻すことができるのでしょうか。
アレグザンダー氏の思想をまとめた『パタン・セオリー』には、「自分たちにとって何が正しいのか、何がベストなのか、これを見出すことができるのは、参加し、デザインするという特別な状況にある当事者だけだ」という言葉があります。
つまり、「空間を設計する力」をとり戻すためには、エンジニアが当事者として施主の課題解決のプロセスに積極的に「参加」し、ともに「デザイン」していく必要があります。
加えて、組織から階層構造や役割分担をなくさなければいけません。
こうしたエンジニアのあり方の変化は、時代の大きな潮流にも後押しされています。多くの企業でプロダクト開発の内製化が進み、エンジニアが設計の当事者として主導権をとり戻しつつあります。
また、単なる技術力にとどまらず、社会や顧客の課題解決に本質的に向き合う「プロダクトエンジニア」というエンジニアのあり方も注目を集めています。
エンジニアが、自らの専門領域を越えてプロダクトの価値創造全体に貢献する。そんな新しいエンジニア像が、いままさに求められているのです。
私は、10年かけて「空間を設計する力」を自分の手にとり戻すことができました。これからの10年間は、その力をどのように使って施主の関心ごとを実現しつづけるか、試行錯誤を繰り返していきたいと思います。
（※本記事の内容および対象者の所属は、イベント開催当時のものです）
