Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
「正解の仕様」を求めて、決断する
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
コドモン開発チーム
PRO
August 24, 2026
Technology
93
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
「正解の仕様」を求めて、決断する
コドモン開発チーム
PRO
August 24, 2026
More Decks by コドモン開発チーム
See All by コドモン開発チーム
ペアプロの価値はコードを書くことだけじゃない
codmoninc
PRO
0
350
スクラムで身についていた動き方を、XPで捉え直してみた
codmoninc
PRO
1
570
AI時代のPHP開発にASTクエリツール で コードベースの地図を作る / ast-query-tool-php-codebase-map
codmoninc
PRO
0
450
コネクションをピン留めさせずに SELECTクエリのタイムアウトを設定した話
codmoninc
PRO
0
440
コドモンに入社してAI活用により、 設計がより重要だと感じた背景
codmoninc
PRO
0
150
実装・設計だけでなく、運用・保守にもAIを広げてみた / We Took AI Beyond Coding and Into Operations and Maintenance
codmoninc
PRO
0
120
AIが無かった頃の素敵な出会いの話
codmoninc
PRO
1
590
5分で問診!Composer セキュリティ健康診断
codmoninc
PRO
0
1.4k
アラート疲れからの脱却 - リソースタグで仕分けるSlack通知戦略 / Breaking Free from Alert Fatigue – A Slack Notification Strategy Using Resource Tags for Routing
codmoninc
PRO
0
56
Other Decks in Technology
See All in Technology
「とりあえず動く」の先へ。 AI時代のチーム開発と内部設計/2026-slsdays
slsops
0
100
Databricksメトリクスビューはじめてのもくもく会
taka_aki
0
150
個別開発で終わらせない。 現場の課題をプロダクトの強さに変える StockmarkのFDE
ktkrhr
0
530
『GOエコノミー 』(相乗りサービス) におけるスペック駆動開発
mot_techtalk
1
170
Meet AgentCore Identity Consent Portal
hironobuiga
3
150
The seven pitfalls of AI (revised version)
ufried
0
180
HolmesGPTで始めるSREエージェント入門!プラットフォームの障害調査はAIにお任せ 〜
leveragestech
PRO
0
130
【データ横丁主催】AI Agentがコンテキストを使って仕事をした後、何が残るのか― 組織の経験を次の判断に引き継ぐ「Agent Memory」
shisyu_gaku
2
310
20260930_Gemma4_Hands-on
tsho
0
210
AIに書かせて、プラットフォームで縛る ― EKSプラットフォームで実践した責任境界と権限設計
elmodev09
1
1.1k
1万名の社員が使う認証基盤で どう信頼性を担保するか?
kairim0
0
170
AI駆動開発で仕様はどこまで書くべきか? ― 人とAIの責務境界から考える開発プロセスの実践
takahiromatsui
1
290
Featured
See All Featured
Context Engineering - Making Every Token Count
addyosmani
9
1.2k
Navigating Weather and Climate Data
rabernat
0
540
It's Worth the Effort
3n
188
29k
Kristin Tynski - Automating Marketing Tasks With AI
techseoconnect
PRO
0
530
30 Presentation Tips
portentint
PRO
1
410
Leadership Guide Workshop - DevTernity 2021
reverentgeek
1
380
How to Align SEO within the Product Triangle To Get Buy-In & Support - #RIMC
aleyda
2
1.8k
What’s in a name? Adding method to the madness
productmarketing
PRO
24
4.2k
Deep Space Network (abreviated)
tonyrice
0
350
Navigating Team Friction
lara
192
16k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
360
31k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
230
23k
Transcript
「正解の仕様」を求めて、決断する ~PHPerKaigi mini #4~ 2026.08.24 せきねこ - CoDMON, Inc.
None
今回のLT 😭 PHP Conference Japan 2026 のプロポーザルで reject されたネタです PHPerKaigiじゃない上にPHP要素もない話ですが…供養させてください!
3
舞台は給付費申請画面刷新プロジェクト • 「給付費申請用データ作成機能」を、連携先システムの更改に合わせて画 面刷新 • プロジェクト開始時の状況 ◦ 連携先のUIだけでなく、業務フロー自体も新しくなる模様 ◦ コドモン側に何をどうする機能があれば良いのか?が分からない
4
プロジェクトを前進させたもの: 「やらない」という意思決定 5
「やらない」という意思決定 • やるものを決める = つくるものが増える • つくるものが増える = 価値は増えるが工期と負債も増 える
• (旧システムは保守工数がかさんで苦しい思いをし た) 6
「やらない」という意思決定を支えたツール ADR(Architecture Decision Record) 意思決定を1件ずつ記録するドキュメント 7
ADRテンプレート 8
CASE1:祝日考慮は必要? 9
CASE1:祝日考慮は必要? 背景 • 保育施設の利用時間は、家庭(園児)ごとに予め決められている ◦ Aさん:7:30~18:30 ◦ Bさん:8:30~16:30 • 認定された利用時間外での利用(=延長保育)は、追加料金が発生する
• 利用時間の定義は曜日によって異なる(平日・土曜・休日) → 「祝日の延長保育利用」は考慮が必要だろうか?? 10
CASE1:祝日考慮は必要? 最初は漠然と「考慮必要かも…」と誰もが思っていた でも、やるとなると • 祝日データの管理が必要になる • コードが複雑になり、テストパターンも増える 11
CASE1:祝日考慮は必要? もし「やらなかったら?」を検討した • 当該機能利用中の施設に影響がないことが判明 ◦ 利用中施設のデータ調査で裏付け ◦ そもそも祝日に保育を実施している保育施設がほぼない • 万一考慮が必要となっても、出力データを施設が修正することで申請業務
は可能 → 結論: やらない 12
勿論「やる」という意思決定を することだってある 13
CASE2:園児識別番号の削除機能は必要? 14
CASE2:園児識別番号の削除機能は必要? 背景 • 保育施設を利用する園児には、自治体が園児識別番号を発行している ◦ マイナンバーの保育施設バージョンみたいなもの ◦ 給付費申請業務でも使用されている ◦ コドモン上で、園児ごとの園児識別番号入力欄がある
• 園児識別番号は変更される場合がある ◦ 市外転出時などに発生 • 旧システムでは出力データの仕様上、入力済番号の削除機能が必須だった 15
CASE2:園児識別番号の削除機能は必要? 新システムでは出力データに影響がない →「削除機能、なくて良いのでは?」と思っていた (「やらない意思決定」の波に乗ろうとしていたかもしれない) 16
CASE2:園児識別番号の削除機能は必要? → 結論: やる • 新システムにおいても、僅少だが入力済番号の削除を要するユースケース が存在することが発覚 ◦ 特定条件下において、給付費申請対象外となる園児がいる •
やらない場合の回避コストが高い ◦ 「給付費申請対象外の園児かどうか」識別フラグを追加 ◦ または、該当園児の園児識別番号データをエンジニアが都度削除 17
CASE2:園児識別番号の削除機能は必要? つくるものは増えたが… • 隠れ仕様のようとはいえ、考慮が必要なケースに対処 できた • 代替案による回避コストを把握したことで「やる」意 思決定に納得感を持てた 18
このプロジェクトでの意思決定実績 ほぼ 毎イテレーションで意思決定 • 約4ヶ月のプロジェクト • 19以上のADR ◦ ADR運用は途中から始めた ◦
記録を忘れてしまった意思決定もそこそこ… • 余談:最近はADR作成コストも下がってきている ◦ 文字起こし〜AIにADRテンプレートを渡して要約〜気になった部分を 修正 19
まとめ 20
まとめ • プロジェクトを前進させたもの:「やらない」という 意思決定 • 意思決定を支えたツール:ADR • 漠然と「やる」→ 「やらなかったら?」も考える •
代替コストを把握→「やる」ことに納得感を持てる 21
おまけ 「やらない」という意思決定以外の実践例はブログにて!! • コドモン Product Team Blog 「正解の仕様が分からない」を乗り越えた、給付費申 請画面刷新プロジェクトの実践例 22
None