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
俺の/私の最強アーキテクチャ決定戦開催 ― チームで新しいアーキテクチャに適合していくために ...
Search
SHIFT EVOLVE
PRO
March 22, 2026
Technology
890
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
俺の/私の最強アーキテクチャ決定戦開催 ― チームで新しいアーキテクチャに適合していくために / 20260322 Naoki Takahashi
2026/3/22 PHPerKaigi 2026
https://phperkaigi.jp/2026/
株式会社SHIFT 製造ソリューションサービス部
髙橋 直規
SHIFT EVOLVE
PRO
March 22, 2026
More Decks by SHIFT EVOLVE
See All by SHIFT EVOLVE
高速な品質フィードバックを実現するAIテスト設計エージェント構築の要点 / 20260529 Suguru Ishii
shift_evolve
PRO
0
63
SREの仕事は「壊さないこと」ではなくなった 〜自律化していくシステムに、責任と判断を与えるという価値〜 / 20260515 Naoki Shimada
shift_evolve
PRO
1
290
ボトムアップの改善の火を灯し続けろ!〜支援現場で学んだ、消えないための3つの打ち手〜 / 20260509 Kazuki Mori
shift_evolve
PRO
2
1.1k
AI活用時代の事業判断高度化を導くエンジニアリング基盤 / 20260424 Atsushi Funahashi
shift_evolve
PRO
2
150
ネットワーク運用を楽にするAWS DevOps Agent活用法!! / 20260421 Masaki Okuda
shift_evolve
PRO
2
340
プロダクトを触って語って理解する、チーム横断バグバッシュのすすめ / 20260411 Naoki Takahashi
shift_evolve
PRO
1
640
40代からのアウトプット ― 経験は価値ある学びに変わる / 20260404 Naoki Takahashi
shift_evolve
PRO
7
1.4k
事例から紐解くSHIFT流QA支援 ~大規模プロジェクトの品質管理支援、QA組織立ち上げ~ / 20260320 Nozomu Koketsu
shift_evolve
PRO
0
340
欠陥分析(ODC分析)における生成AIの活用プロセスと実践事例 / 20260320 Suguru Ishii & Naoki Yamakoshi & Mayu Yoshizawa
shift_evolve
PRO
0
2.3k
Other Decks in Technology
See All in Technology
Agent Skills設計で柔軟性と硬さのバランスが難しい話
nassy20
0
120
フロンティアAIのゲート化と地政学リスク
nagatsu
0
120
AIの性能が向上しても未解決な組織の重大問題は何か?/An Unsolved Organizational Problem in the Age of AI
moriyuya
3
610
データサイエンスを価値につなげるプロジェクト設計 〜 DS一年目が現場で得た気づき 〜
ysd113
1
170
新しいVibe Codingと”自走”について
watany
5
290
LLMにもCAP定理があるという話
harukasakihara
0
290
SONiC Scale-Up Working Group から探る Scale-UpやUltraEthernet機能の実装方法
ebiken
PRO
0
100
小さくはじめるSLI/SLO ~育てながら組織に定着させる実践知~ / Starting Small with SLI/SLOs: Building Adoption Through Continuous Growth
nari_ex
3
1.5k
Claude Code の Sandbox 機能を Anthropic Sandbox Runtime(srt) で試そう!/lets-play-anthropic-sandbox-runtime
tomoki10
1
530
失敗を経て、Harness Engineering で 大切にしたいことを考える / Learning from Failure: What Matters in Harness Engineering
bitkey
PRO
1
300
Agentic Web
dynamis
1
200
機械学習を「社会実装」するということ 2026年夏版 / Social Implementation of Machine Learning June 2026 Version
moepy_stats
4
1.3k
Featured
See All Featured
Building Better People: How to give real-time feedback that sticks.
wjessup
370
20k
The Curious Case for Waylosing
cassininazir
1
380
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
38
2.9k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.5k
Testing 201, or: Great Expectations
jmmastey
46
8.2k
A Soul's Torment
seathinner
6
2.9k
What does AI have to do with Human Rights?
axbom
PRO
1
2.2k
We Are The Robots
honzajavorek
0
240
Ten Tips & Tricks for a 🌱 transition
stuffmc
0
130
30 Presentation Tips
portentint
PRO
1
320
Navigating the Design Leadership Dip - Product Design Week Design Leaders+ Conference 2024
apolaine
1
340
Deep Space Network (abreviated)
tonyrice
0
170
Transcript
髙橋直規 株式会社SHIFT Copyright SHIFT Inc, All Rights Reserved. 俺の/私の最強アーキテクチャ決定戦開催 ―
チームで新しいアーキテクチャに適合していくために 2026.3.22 PHPerKaigi 2026 #phperkaigi
突然ですが… そのアーキテクチャ、 誰が決めていますか? 2
自己紹介 髙橋直規(幡ヶ谷亭直吉) x:@asagayanaoki • エンジニア歴:18年12か月 • 担当の役割:プロジェクトマネージャー、プロダクトエンジニア • 主催コミュニティ:多摩.dev •
土日の過ごし方:6歳の娘ととにかく遊ぶ 3
本日お話すること https://fortee.jp/phperkaigi-2026/proposal/3bcedde1-0a7e-4a38-bc1b-ecdea674a845 4
背景:アーキテクチャ刷新が必要な状況に 小さな改修が、もう小さくない リリースのために充分な制約を持たないまま作られたシステム。 機能追加を重ねた結果、 小さな改修でも想定以上の時間がかかるように。 構造での整理がうまくいかず、影響範囲が読めない状態に。 そこで、より持続可能なプロダクト成長を実現するために リアーキテクチャ実施。 5
トップダウンでのアーキテクチャ決定 やりたくなかったトップダウンでの進行 リアーキテクチャを推進できるメンバーはいたが、 アーキテクチャの刷新後は 新しい環境にチームで慣れる必要があるため、 「決める人」を限定したトップダウンでの進行は避けたかった。 6
トップダウンでのアーキテクチャ決定 トップダウンでの決定に対する心配 納得感の欠如 学習の鈍化 積もる不満 チームは決定プロセス から疎外され、 当事者意識を持てない。 アーキテクチャの 意図や背景が共有しきれず
チームが適応しきれない。 個人が抱える課題や、 より良いアイデアが 埋もれる。 7
トップダウンでのアーキテクチャ決定 目指したのは「持続可能なチーム開発」 チームで方向性を決める トップダウンにせず、チームで主体的に方向性を決めたかった。 現状へのメンバーの不満や違和感を可視化する 全員に発言機会を設けることで、 現状の不満や違和感を可視化したかった。 8
そこで開催したのが… 俺の/私の 最強アーキテクチャ 決定戦 9
最強アーキテクチャ決定戦 俺の/私の最強アーキテクチャ決定戦開催 全員が発言できる場を設け、 メンバーそれぞれが新しいアーキテクチャを提案する形に。 提案しやすいようにフリースタイルを採用。 提案のハードルを下げるために、 「すべての処理を神メソッドで実現する」アーキテクチャを 最低限のレベルとして設定。 10
最強アーキテクチャ決定戦 統合 議論 提案 提案者が感じる課題感と それを解消する 最強アーキテクチャ発表 決定戦のイベントの流れ 提案に対する質疑応答や 課題感に対する認識合わせ
提案ごとの課題感に対し 新しいアーキテクチャが 解消できるように統合 11
若手エンジニアからも嬉しい提案 中堅エンジニアだけでなく、 若手エンジニアからも改善のための提案が。 最強アーキテクチャ決定戦 提案のアーキテクチャが最適な形じゃなくても、 課題を言語化し、解消法を探すモチベーションがチームを動かす。 ソースコードを変更する際に 影響範囲が見えないので マイクロサービスにしたいと思います 12
最強アーキテクチャ決定戦 アーキテクチャ決定戦の結果報告 納得感の醸成 理解の浸透 前向きな合意 各人の課題を表出し、 論点を統合する形に。 提案と議論により、 なぜそうするかの 目線が揃った。
決定に対して、全員が オーナーシップを確立 13
最強アーキテクチャ決定戦 「やらされる」から「自分ごと」へ 新しいアーキテクチャに適応していくことは大変な作業。 だからこそ、チームで向き合える状態を大切にしました。 14
15