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
コドモン開発チーム
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
580
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
スキルを作る、その前に!複数人で使われるスキルを 作るためのプロセス
junkifurukawa
2
180
AWS DevOps Agent スキルをつかいこなそう / Master AWS DevOps Agent Skills
kinunori
2
670
Apache Iceberg が拓く AI 時代のオープンレイクハウス
tomtanaka
0
210
検証フェーズはAIの回答を判断するための学習機会
toru_kubota
2
390
Lambda MicroVMsは常駐サーバーの代わりに なるか? Kiro Crew を動かして検証してみた / Kiro Crew on Lambda MicroVMs
k_adachi_01
2
350
HacobuにおけるFDEとは/登壇資料(戸井田 裕貴)
hacobu
PRO
1
720
AgentCoreで実践するハーネスエンジニアリング
yakumo
1
230
Databricksメトリクスビューはじめてのもくもく会
taka_aki
0
170
TiDBファミリーにDWHが新登場!! TiDB最新情報 / TiDB update 202609
yoshiakiyamasaki
0
190
個別開発で終わらせない。 現場の課題をプロダクトの強さに変える StockmarkのFDE
ktkrhr
0
550
AI駆動開発で仕様はどこまで書くべきか? ― 人とAIの責務境界から考える開発プロセスの実践
takahiromatsui
1
300
The kernel report
ennael
PRO
1
210
Featured
See All Featured
Self-Hosted WebAssembly Runtime for Runtime-Neutral Checkpoint/Restore in Edge–Cloud Continuum
chikuwait
0
850
SEO Brein meetup: CTRL+C is not how to scale international SEO
lindahogenes
2
2.9k
Lightning talk: Run Django tests with GitHub Actions
sabderemane
0
290
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
18k
How STYLIGHT went responsive
nonsquared
100
6.3k
<Decoding/> the Language of Devs - We Love SEO 2024
nikkihalliwell
1
340
Leadership Guide Workshop - DevTernity 2021
reverentgeek
1
380
Building Better People: How to give real-time feedback that sticks.
wjessup
370
20k
30 Presentation Tips
portentint
PRO
1
410
The Limits of Empathy - UXLibs8
cassininazir
1
700
Mind Mapping
helmedeiros
1
390
Evolving SEO for Evolving Search Engines
ryanjones
0
300
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