Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
空間を設計する力を考える / 20251004 Naoki Takahashi
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
SHIFT EVOLVE
PRO
October 03, 2025
Technology
1.8k
4
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
空間を設計する力を考える / 20251004 Naoki Takahashi
2025/10/4 XP祭り2025
https://xpjug.github.io/xp2025.html
株式会社SHIFT
製造ソリューションサービス部
髙橋 直規
SHIFT EVOLVE
PRO
October 03, 2025
More Decks by SHIFT EVOLVE
See All by SHIFT EVOLVE
コミュニティを、仕事にした。‐ 学びの場が会社の価値になるまで / 20260724 Ayana Chandler
shift_evolve
PRO
0
48
越境QA 〜QA歴18年のキャリア~ / 20260724 Masakazu Yoshikawa
shift_evolve
PRO
0
39
fukabori.fm出張版:AI駆動開発でテストエンジニアは不要になるのか / 20260723 Yoshimasa Iwase & Tomoo Morikawa
shift_evolve
PRO
2
48
【実録】「なんちゃってアジャイル」によるプロジェクト崩壊とその教訓 / 20260723 Takeshi Watarai
shift_evolve
PRO
1
25
AIとハーネスで育てるトランスコンパイラ / 20260722 Yasushi Katayama
shift_evolve
PRO
3
780
AWS DevOps AgentでCDKメンテナンスは楽になるのか ~検証から見えた最適解~ / 20260718 Masaki Okuda
shift_evolve
PRO
0
590
AI時代のYAGNI:「爆速で無駄になった機能」からの学び / 20260720 Naoki Takahashi
shift_evolve
PRO
3
520
AIが変えるDevSecOps―開発速度とセキュリティの両立へ / 20260714 Mitsutoshi Matsuo
shift_evolve
PRO
1
85
生成AI活用によるODC欠陥分析の分類高速化の実践と導入効果 / 20260703 Suguru Ishii
shift_evolve
PRO
2
160
Other Decks in Technology
See All in Technology
現場との対話から始める “作る前に問い直す”業務改善
mochico50
1
230
AI時代の開発生産性を捉え直す — 経営と現場をつなぐ「開発組織のオブザーバビリティ」— / AI Dev Ex Conference 2026
tkyowa
1
1.3k
OpenTelemetryにおけるGoのゼロコード・コンパイル時計装について #fukuokago
quiver
0
210
AI時代におけるテストの基礎の再定義 / Rethinking the Fundamentals of Testing in the AI Era
mineo_matsuya
14
4.6k
探索・可視化・自動化を一本化 Amazon Quickでデータ活用スピードを上げる方法
koheiyoshikawa
0
170
プロダクト開発組織の現在地(Ver.2026/07) / product-organization
kaonavi
0
400
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
15
110k
AICoEでAIネイティブ組織への進化
yukiogawa
0
220
10年目を迎えた「ABEMA」がどのように AI 活用を推進して、AI 駆動開発にシフトしているのか / How ABEMA, entering its 10th year, is promoting the use of AI and shifting toward AI-driven development
miyukki
0
370
kaonavi Tech Night#1
kaonavi
0
160
生成 AI 時代にいま一度「問い合わせ」について考えてみる
kazzpapa3
1
130
CDKで書くECSのベストプラクティス、 改めて考え直す2026 #cdkconf2026
makies
3
940
Featured
See All Featured
How Software Deployment tools have changed in the past 20 years
geshan
0
34k
Navigating Algorithm Shifts & AI Overviews - #SMXNext
aleyda
1
1.5k
Designing Experiences People Love
moore
143
24k
GraphQLとの向き合い方2022年版
quramy
50
15k
Site-Speed That Sticks
csswizardry
13
1.3k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
16
2k
Thoughts on Productivity
jonyablonski
76
5.3k
Game over? The fight for quality and originality in the time of robots
wayneb77
1
230
Avoiding the “Bad Training, Faster” Trap in the Age of AI
tmiket
0
200
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
162
16k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
659
62k
The MySQL Ecosystem @ GitHub 2015
samlambert
251
13k
Transcript
空間を設計する力を考える #xpjug 髙橋直規 株式会社SHIFT 2025.10.04 XP祭り2025
自己紹介 髙橋直規 / 幡ヶ谷亭直吉 x:@asagayanaoki 出身:神奈川 / 居住:東京 エンジニア歴:18年7か月 今の役割:PjM、PdE
好きな言語:Java 好きな思考:リーン思考/好きな言葉:ジーニー 好きなマッピング:ユーザーストーリーマッピング 趣味:アナログレコード、映画鑑賞、マンガ、アニメ 土日の過ごし方:6歳の娘ととにかく遊ぶ(10/2誕)
本日お話すること https://confengine.com/conferences/scrummatsuri/proposal/22775
本日お話すること ▪要約 • ケント・ベックが引用したアレグザンダーの言葉を考える。 • 建築家と施主の関心を考える。 • 空間を設計する力を考える。 • エンジニアが設計の当事者になるために何ができるかを考える。
アジェンダ • はじめに:建築家アレグザンダーの言葉から • プロダクト開発とサイロ構造 • 空間を設計する力とは何かを考える • まとめ:設計する力をどのように取り戻すかを考える
はじめに: 建築家アレグザンダーの言葉から
1.はじめに:建築家アレグザンダーの言葉から “アレグザンダーは、建築家の自己中心的な関心事は、 施主の関心事と一致していないと指摘している。 建築家は仕事をすぐに終わらせて、賞を獲得したいと思っているが、 重要な情報を見逃している。 それは、施主がどのように生活したいかという情報だ。 アレグザンダーの夢は、 生活に最も大きな影響を受ける人の手のなかに、 空間を設計する力を取り戻すことだった。” 第23章
時を超えたプログラミングの道
エクストリームプログラミングとの出会い 1.はじめに:建築家アレグザンダーの言葉から
1.はじめに:建築家アレグザンダーの言葉から 『エクストリームプログラミング』をはじめて読んだのは、 2015年頃で30代前半。SESという働き方から準委任への移行期。 エンジニアとして成長を目的に手に取った。 2007 2025 2015 SES(2次請け、3次請け) 準委任
1.はじめに:建築家アレグザンダーの言葉から ウォーターフォールで深い工程をメインに経験していた自分にとって、 エクストリームプログラミングに書かれている内容は、 自分のエンジニアとしての日常からは遠い世界のように思えた。 2007 2025 2015 SES(2次請け、3次請け) 準委任
1.はじめに:建築家アレグザンダーの言葉から 2022年頃よりアジャイルが求められるエンジニアリングに携わる。 それまでのウォーターフォール開発での考え方からの変換が求められる。 2007 2025 2015 SES(2次請け、3次請け) 準委任(主にウォーターフォール) アジャイル
1.はじめに:建築家アレグザンダーの言葉から 2025年、10年ぶりに2度目の通読。 チームや組織での協力の重要性が多くのページが言及されていることに気付く。 コミュニケーションの透明性に対する言及についても 今になって理解することができた。 2007 2025 2015 SES(2次請け、3次請け) 準委任(主にウォーターフォール)
アジャイル
ケント・ベックが引用した一節の紹介 1.はじめに:建築家アレグザンダーの言葉から
1.はじめに:建築家アレグザンダーの言葉から “アレグザンダーは、建築家の自己中心的な関心事は、 施主の関心事と一致していないと指摘している。 建築家は仕事をすぐに終わらせて、賞を獲得したいと思っているが、 重要な情報を見逃している。 それは、施主がどのように生活したいかという情報だ。 アレグザンダーの夢は、 生活に最も大きな影響を受ける人の手のなかに、 空間を設計する力を取り戻すことだった。” 第23章
時を超えたプログラミングの道
1.はじめに:建築家アレグザンダーの言葉から 建築家の自己中心的な関心事は、
1.はじめに:建築家アレグザンダーの言葉から 建築家の自己中心的な関心事は、施主の関心事と一致していない
1.はじめに:建築家アレグザンダーの言葉から 建築家の自己中心的な関心事は、施主の関心事と一致していない 仕事をすぐに 終わらせて、 賞を獲得したい
1.はじめに:建築家アレグザンダーの言葉から 建築家の自己中心的な関心事は、施主の関心事と一致していない 仕事をすぐに 終わらせて、 賞を獲得したい 理想の 生活をしたい
1.はじめに:建築家アレグザンダーの言葉から 建築家の自己中心的な関心事は、施主の関心事と一致していない 仕事をすぐに 終わらせて、 賞を獲得したい 考え方の距離感 理想の 生活をしたい
10年前にこの言葉に触れたが、 なぜ当時は響かなかったのか 1.はじめに:建築家アレグザンダーの言葉から
1.はじめに:建築家アレグザンダーの言葉から 10年前は2次請け、3次請けの状態から1次請けに切り替わったばかりだった。 SESで経験したエンジニアリングは、施主の関心からは遠い場所で行われていた。 2007 2025 2015 施主 SES(2次請け、3次請け) 準委任(主にウォーターフォール) アジャイル
私
1.はじめに:建築家アレグザンダーの言葉から 現在、1次請けでのアジャイル開発に携わり、 施主の関心を知ることができる場所でエンジニアリングを行っている。 2007 2025 2015 私 SES(2次請け、3次請け) 準委任(主にウォーターフォール) アジャイル
施主
1.はじめに:建築家アレグザンダーの言葉から 開発者としてプロダクトの利用者の関心事との距離が縮まった。 その結果、エクストリームプログラミングに書かれている内容が理解できた。
プロダクト開発とサイロ構造
2. プロダクト開発とサイロ構造 “アレグザンダーは、建築家の自己中心的な関心事は、 施主の関心事と一致していないと指摘している。 建築家は仕事をすぐに終わらせて、賞を獲得したいと思っているが、 重要な情報を見逃している。 それは、施主がどのように生活したいかという情報だ。 アレグザンダーの夢は、 生活に最も大きな影響を受ける人の手のなかに、 空間を設計する力を取り戻すことだった。”
第23章 時を超えたプログラミングの道
2. プロダクト開発とサイロ構造 生活に最も大きな影響を受ける人の手のなかに、空間を設計する力を取り戻すには 考え方の距離感 仕事をすぐに 終わらせて、 賞を獲得したい 理想の 生活をしたい
2. プロダクト開発とサイロ構造 “devopsに取り組んでおらずサイロ化している環境では 共通理解が欠如している。 (中略) 意思疎通がないので、失敗する確率のほうが高くなるはずだ。 組織では、進んでいく過程で、 必ず予想外の問題や障害にぶつかる。 しかし、全員が共同体に属しているという共通理解があれば、 人は修復に向かっていく。”
2章 devopsとは何か
2. プロダクト開発とサイロ構造 開発組織に階層構造や上下関係があり、それぞれの階層がサイロ化していると 建築家内でも考え方の距離が生まれる。 考 え 方 の 距 離
感 私
2. プロダクト開発とサイロ構造 考え方の距離感 たとえ一部の建築家が施主の関心事との距離が近くても、 実際の作り手と施主の距離が近いというわけではない。 考 え 方 の 距
離 感 私
2. プロダクト開発とサイロ構造 『エクストリームプログラミング』をはじめて読んだ頃、 施主の関心を意識する余裕はなかった。 参考:IT土方とは?仕事内容と脱出方法、年収を徹底解説 http://aster-link.co.jp/posts/it-dokata/
2. プロダクト開発とサイロ構造 開発に携わる全員がプロダクトの利用者の関心と距離が近い方が良い。 そのためにも、開発者内で階層構造が無い方が良い。
2. プロダクト開発とサイロ構造 “システムを設計する組織は、 その構造をそっくりまねた構造の設計を生み出してしまう、 というのが基本的な主張だ。 この事実がシステム設計の管理において重要な意味を持つことがわかった。 主要な発見は、設計を行う組織を構造化するための基準である。 コミュニケーションの必要性に応じた設計活動を行うべきなのだ” はじめに コンウェイの法則
2. プロダクト開発とサイロ構造 考える人と作る人が異なると、 考える人の考えたことは十分には作る人には伝わらない。 作る人は考えた当事者ではないので、施主の関心から距離がある。
2. プロダクト開発とサイロ構造 たとえ欲しい人の関心が考える人に伝わり、 考える人が施主がどのように生活したいかを考えることができたとしても、 考えたことは作る人には十分には伝わらず、生活したい状況は実現できない。 考え方の距離感 考え方の 距離感
2. プロダクト開発とサイロ構造 『エクストリームプログラミング』をはじめて読んだ頃、 プログラミングレベルからの仕事も少なくなかった。 設計の意図や背景が分からないままにプログラミングを行っていた。 設計ドキュメントにもそれを伝えきる十分な情報は無かった。 参考:https://x.com/t_wada/status/1935866334832914861
2. プロダクト開発とサイロ構造 プロダクトの利用者と開発者との距離は縮めるべきである。 そのためにも、開発者内にも関心を弱める役割分担は設けない方が良い。
空間を設計する力とは 何かを考える
3.空間を設計する力とは何かを考える 10年前、設計といえばドキュメントだった。 施主の関心はドキュメントとして捉えられたのだろうか。
3.空間を設計する力とは何かを考える “会話と協働こそが エクストリーム・プログラミングの重要な構成要素だからです。 書かれたものを投げ合うことよりも、 会話を交わすことが重要なのです。” 日本語版序文
3.空間を設計する力とは何かを考える 施主の関心は複雑である。 理想の 生活をしたい
3.空間を設計する力とは何かを考える 複雑なものをドキュメントとして捉えようとすると、 複雑なものをドキュメントにすること自体が目的になる。 施主の関心を実現することを目的にすべきである。 理想の 生活をしたい
3.空間を設計する力とは何かを考える プログラミング言語に依存しない設計表記を、 後で誰かにコードへ翻訳させるよりも、 オリジナルの設計者がオリジナルのコードを書いた方が うまくいくのです。 1.2 コードは設計書である
3.空間を設計する力とは何かを考える ストーリーを意識し、施主と会話を交わし、 ドキュメントという中間資料を目的化せず、 施主が望むプロダクトを実現していくことが重要となる。
3.空間を設計する力とは何かを考える 10年前、プロダクトリリース後のチーム解散は普通だった。 施主の関心は一度のリリースで満たされるものなのだろうか。
3.空間を設計する力とは何かを考える “あなたの目標は、新しい製品や機能を作ることだけではない。 その機能について会話するときには、それが誰のためのものなのか、 その人たちは(まだ機能がない)現状ではどうやっているのか、 (その機能を提供したら)今後はその人たちを取り巻く状況が どう変わっていくのか、といったことを話題にする。 そうした将来のポジティブな変化があるからこそ、 それを欲しいと思うようになるのだ。” 0.7 大切なのはソフトウェアではない
3.空間を設計する力とは何かを考える 施主の関心は固定されたものではなく、状況に応じて変化していく。 明るい 生活をしたい
3.空間を設計する力とは何かを考える “スクラムチームとステークホルダーは 不確実性(72)を受け入れることができ、継続的な学習と フィードバックに基づくより迅速な調整が可能になる。 発見、開発、価値検証の重複する性質は、より適応的(80)で 価値駆動型のプロダクト開発アプローチを保証する。” 拡張パックにおけるスクラムの役割
3.空間を設計する力とは何かを考える 施主が欲しいと思われるものは一度作って終わりではなく、 作り確認し適応する小さいフィードバックループを回すことで実現していく。
まとめ:設計する力を どのように取り戻すかを考える
“アレグザンダーは、建築家の自己中心的な関心事は、 施主の関心事と一致していないと指摘している。 建築家は仕事をすぐに終わらせて、賞を獲得したいと思っているが、 重要な情報を見逃している。 それは、施主がどのように生活したいかという情報だ。 アレグザンダーの夢は、 生活に最も大きな影響を受ける人の手のなかに、 空間を設計する力を取り戻すことだった。” 第23章 時を超えたプログラミングの道
4.まとめ:設計する力をどのように取り戻すかを考える
“自分たちにとって何が正しいのか、何がベストなのか、 それを見出すことができるのは、 参加しデザインするという特別な状況にある当事者だけなのです。” 絶対的なものの相対性 4.まとめ:設計する力をどのように取り戻すかを考える
空間を設計する力とは、 建築家と施主の関心事の距離を近づけることにより実現可能となる。 そのためには、 階層構造や役割分担をなくし、 プロダクト実現を主目的に、対話を重ね、フィードバックループを繰り返す。 そうすることで、 施主の関心事を実現するための設計する力を取り戻していくことができる。 4.まとめ:設計する力をどのように取り戻すかを考える
現在、プロダクト開発の内製化の流れを背景に、 空間を設計する主導権は当事者の手に戻りつつあり、 その動きは加速している。 また、技術にとどまらず社会や顧客の課題解決に 本質的に向き合うプロダクトエンジニアという エンジニアの在り方への注目も高まっている。 4.まとめ:設計する力をどのように取り戻すかを考える 参考:プロダクトエンジニアとは何者か
10年かかってエンジニアとしての自分の手のなかに、 空間を設計する力を取り戻すことができた。 それをどのように施主の関心の実現に繋げていくかは 今後も試行錯誤が必要だと考えている。 次の10年後もエンジニアリングを継続していきたい。 2007 2025 2015 SES(2次請け、3次請け) 準委任(主にウォーターフォール)
アジャイル 4.まとめ:設計する力をどのように取り戻すかを考える
⚫ エクストリームプログラミング(新訳) ⚫ Effective DevOps ―4本柱による持続可能な組織文化の育て方 ⚫ チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 ⚫
ユーザーストーリーマッピング ⚫ プリンシプル オブ プログラミング 3年目までに身につけたい 一生役立つ101の原理原則 ⚫ スクラムガイド拡張パック ⚫ パタン・セオリー: クリストファー・アレグザンダーの理論に関する序論と展望 ⚫ ソフトウェアファースト第2版 あらゆるビジネスを一変させる最強戦略 ⚫ プロダクトエンジニアとは何者か 参考書籍・記事