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
mashirou1234
July 30, 2019
Programming
1
730
設計忘れからやってはいけない対症療法
ちゃんと詳細設計とか画面定義とかしないと痛い目みるよ、という失敗談です。反面教師にしてください。
mashirou1234
July 30, 2019
Tweet
Share
More Decks by mashirou1234
See All by mashirou1234
PHPUnitしか使ってこなかった 一般PHPerがPestに乗り換えた実録
mashirou1234
0
130
デザインパターンを掘り下げよう ~Singleton Pattern 編~
mashirou1234
3
660
PHP 8.3で追加されたjson_validate()を徹底的に深掘りしてみよう
mashirou1234
1
1.4k
Laravelで共通処理ってどうやるの?
mashirou1234
1
1.5k
改めて見返す「Laravel」とは
mashirou1234
0
340
PHPでドメイン駆動設計を浸透するためにやったことと現状
mashirou1234
0
1k
AWS_Lambda_にCustom_Runtimeで_PHPを導入したシステムに改修を加えて_UT導入まで行った話.pdf
mashirou1234
0
560
設計文化のないチームに文化を広めたが冴えない一手で混沌を招いた話を聞いてほしい.pdf
mashirou1234
0
1.5k
Factfullnessは思考ジャックできる良ツールな件について
mashirou1234
0
190
Other Decks in Programming
See All in Programming
今年一番支援させていただいたのは認証系サービスでした
satoshi256kbyte
1
250
これでLambdaが不要に?!Step FunctionsのJSONata対応について
iwatatomoya
2
3.6k
Monixと常駐プログラムの勘どころ / Scalaわいわい勉強会 #4
stoneream
0
270
MCP with Cloudflare Workers
yusukebe
2
220
useSyncExternalStoreを使いまくる
ssssota
6
1k
責務を分離するための例外設計 - PHPカンファレンス 2024
kajitack
1
540
return文におけるstd::moveについて
onihusube
1
1k
バグを見つけた?それAppleに直してもらおう!
uetyo
0
180
競技プログラミングへのお誘い@阪大BOOSTセミナー
kotamanegi
0
360
rails statsで大解剖 🔍 “B/43流” のRailsの育て方を歴史とともに振り返ります
shoheimitani
2
930
Refactor your code - refactor yourself
xosofox
1
260
testcontainers のススメ
sgash708
1
120
Featured
See All Featured
Why Our Code Smells
bkeepers
PRO
335
57k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
47
5.1k
Testing 201, or: Great Expectations
jmmastey
40
7.1k
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
5
440
Large-scale JavaScript Application Architecture
addyosmani
510
110k
How STYLIGHT went responsive
nonsquared
95
5.2k
Done Done
chrislema
181
16k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.3k
How to Ace a Technical Interview
jacobian
276
23k
Git: the NoSQL Database
bkeepers
PRO
427
64k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
8
1.2k
A Philosophy of Restraint
colly
203
16k
Transcript
設計忘れからやってはいけない対症療法 代口勇真<@yu_mashirou> SekkeiKaigi
はじめに ・DDDなどの設計ではなく仕様設計書の話になりま す。
Typo
Typo
Typo 対処療法 : ☓ ↓ 対症療法 : ◦
LTの目的 • 笑いネタではありませんがネタにしました • 基本設計・詳細設計の大切さ • 巷でよく聞く「仕様書はない/仕様書はソースコード」が発生 する要因は多分こんな感じで起きる(一因) • 一応Happy
End(True End)です。安心してください(?)
結論
結論 _人人人人人人人_ > 論より設計 <  ̄Y^Y^Y^Y^Y^Y ̄ 徹底しないと≪地獄≫が始まる……
ことのはじまり #いつもここから
~前提で進んでいたこと~ ・新規案件で技術検証を行い、採択の上 開発が進むような進行。 ・外部会社との連携が必要になった。 ・期間は2月~5月で検証/開発を経て1次 リリース(予定) ・当初サーバサイドは一人のスタートだっ た。 ・後に増えるのは知っていた。(何人までか は把握していない)
・インフラは別チームに依頼する。
~前提で進んでいたこと~ ・新規案件で技術検証を行い、採択の上 開発が進むような進行。 ・外部会社との連携が必要になった。 ・期間は2月~5月で検証/開発を経て1次 リリース(予定) ・当初サーバサイドは一人のスタートだっ た。 ・後に増えるのは知っていた。(何人までか は把握していない)
・インフラは別チームに依頼する。 ~ 差異 ~ • 実際に増えた人員は2名で3人体制 → フルで動き始めたのは4月から、足並みが若干不安 定な進行 • インフラチームに依頼したら無理と返ってきた(案件 が建て込みすぎて手が増やせない) → 検証しているうちに自チームでインフラも管理しない と厳しいことが判明 • 環境開発を共通化できるようにするタスクが出来た → 一つ前の開発で環境違いで相当時間を取られた記 憶があった → HomeSteadからDocker(Laradock) • リリースは6月末(7月運用開始) →伸びた!
仕事がいっぱい • 最大の誤算はインフラ構築もスケジュールに加わったこと • インフラ構成図など誰も書いたことないので自分が書いた • ローカル環境のDockerに変更する作業もスケジュール圧迫の要因に この時点で一度詳細設計の見直しを行えば地獄だけは避けれたかもしれない(結果論)
「ぼく、何かやっちゃいました?」 #やらかしすぎた
担当したタスクを紹介 今回は全体の構成やら要件定義から詳細設計に落とし込む部分と開発を担当しました。 • 技術検証 – 外部提供されたツールの検証 • AWS構成図作成 • AWS使用料金試算
• AWS要件策定調査 • 環境構築土台準備 • 管理画面開発
あれ? なにか忘れている気が……
担当したタスクを紹介 今回は全体の構成やら要件定義から詳細設計 に落とし込む部分を担当しました。 • 技術検証 – 外部提供されたツールの検証 • AWS構成図作成 •
AWS使用料金試算 • AWS要件策定調査 • 環境構築土台準備 • 管理画面開発 • ? • ?
担当したタスクを紹介 今回は全体の構成やら要件定義から詳細設計 に落とし込む部分を担当しました。 • 技術検証 – 外部提供されたツールの検証 • AWS構成図作成 •
AWS使用料金試算 • AWS要件策定調査 • 環境構築土台準備 • 管理画面開発 • 管理画面・画面定義書 • AWS全体構成表
None
やりました /(^o^)\
この事実が判明したのが 4月中旬終わりのことでした。
※この時点では6月に1次リリース予定でした。
やばいですね☆
やってはいけない対症療法
やってはいけない対症療法 作り忘れたのやばいな…… どうしよう
やってはいけない対症療法 そうだ! 作りながら設計と 画面定義すれば なんとかなるのでは!?
やってはいけない対症療法 そうだ! 作りながら設計と 画面定義すれば なんとかなるのでは!?
やってはいけない対症療法 そうだ! 作りながら設計と 画面定義すれば なんとかなるのでは!? 全体的にスケジュールが遅れた根本的な原因
原因 作り忘れたのやばいな…… どうしよう
原因 作り忘れたのやばいな…… どうしよう この時点で速やかにスケジュールの確認を行い 画面定義書のガントチャートを敷き直すことで 重症で済ませられかもしれない……(結果論)
やってはいけない対症療法 作りながら画面設計も 7割くらいの完成だ! 一度レビューして 貰って先進もうっと
やってはいけない対症療法 大体出来たので 確認お願いしますー
やってはいけない対症療法 大体出来たので 確認お願いしますー ありがとうー 確認して……ん?
やってはいけない対症療法 へっ、そうなんですか? あれ、画面定義書って運用 チームに最初のイメージを 伝えてない気がするけど
やってはいけない対症療法 最初って必要ないって話 だったと記憶してますが それに投稿画面はあるけど 確認するための画面も必要か もね、この感じだと
やってはいけない対症療法 確かに必要という話は開 発チーム内ではしましたが …… 投稿画面はあるのは良いとして 結果を確認するための画面も 必要だと思うけど……
やってはいけない対症療法 これは…… これは……
やってはいけない対症療法 これは…… これは…… 認識齟齬
やってはいけない対症療法 「なぜ認識齟齬が起きたのか」
やってはいけない対症療法 「なぜ認識齟齬が起きたのか」 実は両者とも齟齬は起きていない。
やってはいけない対症療法 @yu_mashirou の解釈 これは…… ・基本的にサーバ・画面設計はお任せするとい う話 →作るのはこっち責任でいいか by @yu_mashirou ・運用側は開発側が用意した管理画面を使用
するという話 →ある程度は融通効くからそこまで時間かから ないやり方にしよう by @yu_mashirou
やってはいけない対症療法 @yu_mashirou の解釈 マネージャーの解釈 ・基本的にサーバ・画面設計はお任せ する話 →早めに運用側に出してイメージを先 行で定着してもらう考えでいた ・運用側は開発側が用意した管理画 面を使用するという話
→画面設計定義書を運用側に提示す る予定だった
やってはいけない対症療法 「なぜ認識齟齬が起きたのか」
やってはいけない対症療法 「なぜ認識齟齬が起きたのか」
やってはいけない対症療法 「課題・疑問点」 • 画面定義書を「どのタイミングで、いつまでにやる必要」があったのか • バッファを確保する考慮をしていたか • 作業の分担に問題はなかったのか • スケジュールの進行の理解はあったのか
やってはいけない対症療法 「課題・疑問点」 • 画面定義書を「どのタイミングで、いつまでにやる必要」があったのか • バッファを確保する考慮をしていたか • 作業の分担に問題はなかったのか • スケジュールの進行の理解はあったのか
やってはいけない対症療法 スケジュール ・期間は2月~5月で検証/開発を経て1 次リリース(予定) →後に6月末リリースになった 対応した日 ・4月中旬 →5月中旬に追加実装画面を追加 画面定義書を「どのタイミングで、いつまでにやる必要」があったのか
やってはいけない対症療法 スケジュール ・期間は2月~5月で検証/開発を経て1 次リリース(予定) →後に6月末リリースになった 対応した日 ・4月中旬 →5月中旬に追加実装画面を追加 画面定義書を「どのタイミングで、いつまでにやる必要」があったのか いつまでにやる必要があった?
・3月上旬から設計する必要があった
やってはいけない対症療法 スケジュール ・期間は2月~5月で検証/開発を経て1 次リリース(予定) →後に6月末リリースになった 対応した日 ・4月中旬 →5月中旬に追加実装画面を追加 画面定義書を「どのタイミングで、いつまでにやる必要」があったのか いつまでにやる必要があった?
・3月上旬から設計する必要があった →3月はインフラ構成図を書きながら検 証していた →先んじて検証ソースを書いていたの で若干先行して開発が進んでいたので 画面を頭の中で組みながら実装してい た
やってはいけない対症療法 「課題・疑問点」 • 画面定義書を「どのタイミングで、いつまでにやる必要」があったのか • バッファを確保する考慮をしていたか • 作業の分担に問題はなかったのか • スケジュールの進行の理解はあったのか
やってはいけない対症療法 @yu_mashirouの考え ・当初からインフラ込みだったのでかな りギリギリのスケジュールの想定でいた (スケジュールも同様) 結果 ・先方都合で1ヶ月くらいずれ込んだの で首の皮一枚つながった状態でどうに かリリースできた バッファを確保する考慮をしていたか
考慮していた? まるで考慮していなかった。 追加実装する前提でないまま開発を進 めていた
やってはいけない対症療法 「課題・疑問点」 • 画面定義書を「どのタイミングで、いつまでにやる必要」があったのか • バッファを確保する考慮をしていたか • 作業の分担に問題はなかったのか • スケジュールの進行の理解はあったのか
やってはいけない対症療法 Aさん 1.開発作業(一番重要な部分) 2.インフラ(Lambda)の構築作業 作業の分担に問題はなかったのか Bさん 1.技術検証作業 2.AWSインフラ構築作業 3.REST API実装(サーバ)
やってはいけない対症療法 @yu_mashirouの作業 1.技術検証 2.AWSインフラ構築(本構築前演習) 3.インフラ構成図作成作業 4.定義書作成作業(インフラ・サーバ) 5.チケット・タスク振り分け作業 6.管理画面開発(サーバ) 作業の分担に問題はなかったのか
やってはいけない対症療法 @yu_mashirouの作業 1.技術検証 2.AWSインフラ構築(本構築前演習) 3.インフラ構成図作成作業 4.定義書作成作業(インフラ・サーバ) 5.チケット・タスク振り分け作業 6.管理画面開発(サーバ) 作業の分担に問題はなかったのか 一人で過剰に作業している
やってはいけない対症療法 「課題・疑問点」 • 画面定義書を「どのタイミングで、いつまでにやる必要」があったのか • バッファを確保する考慮をしていたか • 作業の分担に問題はなかったのか • スケジュールの進行の把握はできていたのか
やってはいけない対症療法 状況 ・ギリギリのスケジュール ・一人で倍以上抱えたタスク ・タスクを消化するために残業 ・初めての作業がほとんど(開発除く) ・他の案件の差し込み対応が2回ほど スケジュールの進行の把握はできていたのか
やってはいけない対症療法 状況 ・ギリギリのスケジュール ・一人で倍以上抱えたタスク ・タスクを消化するために残業 ・初めての作業がほとんど(開発除く) ・他の案件の差し込み対応が2回ほど スケジュールの進行の把握はできていたのか できてない
結果 間に合ったの?
結果 無事リリース 間に合ったの?
結果 実際 ・間に合ったけど問題は残ったりして いた ・1次リリースのために急場でデプロ イしたので大問題に気が付かなかっ た 間に合ったの? アプリケーション側でHTTPSリダイレクト処 理を入れるのを忘れた図↓
結論 _人人人人人人人_ > 論より設計 <  ̄Y^Y^Y^Y^Y^Y ̄ 徹底しないと≪地獄≫が始まる……
自己紹介 - 柚口ましろう(代口勇真) - Twitter: @yu_mashirou - 生態: へんなひと・開発者 -
好物:アイマス(橘ありす)とPHPとCloudFrontと音ゲー 株式会社C-Gardenという会社に設立費用出したのでどうやら役員らしい…… こんな アイコンで活 動 するなど
EOF