設計忘れからやってはいけない対症療法

by mashirou1234

Slide 1

Slide 1 text

設計忘れからやってはいけない対症療法代口勇真<@yu_mashirou> SekkeiKaigi

Slide 2

Slide 2 text

はじめに・DDDなどの設計ではなく仕様設計書の話になります。

Slide 3

Slide 3 text

Typo

Slide 4

Slide 4 text

Typo

Slide 5

Slide 5 text

Typo 対処療法 : ☓ ↓ 対症療法 : ○

Slide 6

Slide 6 text

LTの目的 • 笑いネタではありませんがネタにしました • 基本設計・詳細設計の大切さ • 巷でよく聞く「仕様書はない/仕様書はソースコード」が発生する要因は多分こんな感じで起きる（一因） • 一応Happy End(True End)です。安心してください(?)

Slide 7

Slide 7 text

結論

Slide 8

Slide 8 text

結論＿人人人人人人人＿＞　論より設計　＜￣Y^Y^Y^Y^Y^Y￣　　徹底しないと≪地獄≫が始まる……

Slide 9

Slide 9 text

ことのはじまり #いつもここから

Slide 10

Slide 10 text

Slide 11

Slide 11 text

~前提で進んでいたこと~ ・新規案件で技術検証を行い、採択の上開発が進むような進行。・外部会社との連携が必要になった。・期間は2月～5月で検証/開発を経て1次リリース（予定）・当初サーバサイドは一人のスタートだった。・後に増えるのは知っていた。（何人までかは把握していない）・インフラは別チームに依頼する。 ~ 差異 ~ • 実際に増えた人員は2名で3人体制 → フルで動き始めたのは4月から、足並みが若干不安定な進行 • インフラチームに依頼したら無理と返ってきた(案件が建て込みすぎて手が増やせない) → 検証しているうちに自チームでインフラも管理しないと厳しいことが判明 • 環境開発を共通化できるようにするタスクが出来た → 一つ前の開発で環境違いで相当時間を取られた記憶があった → HomeSteadからDocker(Laradock) • リリースは6月末（7月運用開始） →伸びた！

Slide 12

Slide 12 text

仕事がいっぱい • 最大の誤算はインフラ構築もスケジュールに加わったこと • インフラ構成図など誰も書いたことないので自分が書いた • ローカル環境のDockerに変更する作業もスケジュール圧迫の要因にこの時点で一度詳細設計の見直しを行えば地獄だけは避けれたかもしれない（結果論）

Slide 13

Slide 13 text

「ぼく、何かやっちゃいました？」 #やらかしすぎた

Slide 14

Slide 14 text

担当したタスクを紹介今回は全体の構成やら要件定義から詳細設計に落とし込む部分と開発を担当しました。 • 技術検証 – 外部提供されたツールの検証 • AWS構成図作成 • AWS使用料金試算 • AWS要件策定調査 • 環境構築土台準備 • 管理画面開発

Slide 15

Slide 15 text

あれ？なにか忘れている気が……

Slide 16

Slide 16 text

担当したタスクを紹介今回は全体の構成やら要件定義から詳細設計に落とし込む部分を担当しました。 • 技術検証 – 外部提供されたツールの検証 • AWS構成図作成 • AWS使用料金試算 • AWS要件策定調査 • 環境構築土台準備 • 管理画面開発 • ? • ?

Slide 17

Slide 17 text

担当したタスクを紹介今回は全体の構成やら要件定義から詳細設計に落とし込む部分を担当しました。 • 技術検証 – 外部提供されたツールの検証 • AWS構成図作成 • AWS使用料金試算 • AWS要件策定調査 • 環境構築土台準備 • 管理画面開発 • 管理画面・画面定義書 • AWS全体構成表

Slide 18

Slide 18 text

No content

Slide 19

Slide 19 text

やりました／(^o^)＼

Slide 20

Slide 20 text

この事実が判明したのが 4月中旬終わりのことでした。

Slide 21

Slide 21 text

※この時点では6月に1次リリース予定でした。

Slide 22

Slide 22 text

やばいですね☆

Slide 23

Slide 23 text

やってはいけない対症療法

Slide 24

Slide 24 text

やってはいけない対症療法作り忘れたのやばいな…… どうしよう

Slide 25

Slide 25 text

やってはいけない対症療法そうだ！作りながら設計と画面定義すればなんとかなるのでは！？

Slide 26

Slide 26 text

やってはいけない対症療法そうだ！作りながら設計と画面定義すればなんとかなるのでは！？

Slide 27

Slide 27 text

やってはいけない対症療法そうだ！作りながら設計と画面定義すればなんとかなるのでは！？全体的にスケジュールが遅れた根本的な原因

Slide 28

Slide 28 text

原因作り忘れたのやばいな…… どうしよう

Slide 29

Slide 29 text

原因作り忘れたのやばいな…… どうしようこの時点で速やかにスケジュールの確認を行い画面定義書のガントチャートを敷き直すことで重症で済ませられかもしれない……（結果論）

Slide 30

Slide 30 text

やってはいけない対症療法作りながら画面設計も 7割くらいの完成だ！一度レビューして貰って先進もうっと

Slide 31

Slide 31 text

やってはいけない対症療法大体出来たので確認お願いしますー

Slide 32

Slide 32 text

やってはいけない対症療法大体出来たので確認お願いしますーありがとうー確認して……ん？

Slide 33

Slide 33 text

やってはいけない対症療法へっ、そうなんですか？あれ、画面定義書って運用チームに最初のイメージを伝えてない気がするけど

Slide 34

Slide 34 text

やってはいけない対症療法最初って必要ないって話だったと記憶してますがそれに投稿画面はあるけど確認するための画面も必要かもね、この感じだと

Slide 35

Slide 35 text

やってはいけない対症療法確かに必要という話は開発チーム内ではしましたが …… 投稿画面はあるのは良いとして結果を確認するための画面も必要だと思うけど……

Slide 36

Slide 36 text

やってはいけない対症療法これは…… これは……

Slide 37

Slide 37 text

やってはいけない対症療法これは…… これは…… 認識齟齬

Slide 38

Slide 38 text

やってはいけない対症療法「なぜ認識齟齬が起きたのか」

Slide 39

Slide 39 text

やってはいけない対症療法「なぜ認識齟齬が起きたのか」実は両者とも齟齬は起きていない。

Slide 40

Slide 40 text

やってはいけない対症療法 @yu_mashirou の解釈これは…… ・基本的にサーバ・画面設計はお任せするという話 →作るのはこっち責任でいいか　　　　　　　　　　by @yu_mashirou ・運用側は開発側が用意した管理画面を使用するという話 →ある程度は融通効くからそこまで時間かからないやり方にしよう　　　　　　　　　　by @yu_mashirou

Slide 41

Slide 41 text

やってはいけない対症療法 @yu_mashirou の解釈マネージャーの解釈・基本的にサーバ・画面設計はお任せする話 →早めに運用側に出してイメージを先行で定着してもらう考えでいた・運用側は開発側が用意した管理画面を使用するという話 →画面設計定義書を運用側に提示する予定だった

Slide 42

Slide 42 text

やってはいけない対症療法「なぜ認識齟齬が起きたのか」

Slide 43

Slide 43 text

やってはいけない対症療法「なぜ認識齟齬が起きたのか」

Slide 44

Slide 44 text

やってはいけない対症療法「課題・疑問点」 • 画面定義書を「どのタイミングで、いつまでにやる必要」があったのか • バッファを確保する考慮をしていたか • 作業の分担に問題はなかったのか • スケジュールの進行の理解はあったのか

Slide 45

Slide 45 text

Slide 46

Slide 46 text

やってはいけない対症療法スケジュール・期間は2月～5月で検証/開発を経て1 次リリース（予定） →後に6月末リリースになった対応した日・4月中旬 →5月中旬に追加実装画面を追加画面定義書を「どのタイミングで、いつまでにやる必要」があったのか

Slide 47

Slide 47 text

やってはいけない対症療法スケジュール・期間は2月～5月で検証/開発を経て1 次リリース（予定） →後に6月末リリースになった対応した日・4月中旬 →5月中旬に追加実装画面を追加画面定義書を「どのタイミングで、いつまでにやる必要」があったのかいつまでにやる必要があった？・3月上旬から設計する必要があった

Slide 48

Slide 48 text

やってはいけない対症療法スケジュール・期間は2月～5月で検証/開発を経て1 次リリース（予定） →後に6月末リリースになった対応した日・4月中旬 →5月中旬に追加実装画面を追加画面定義書を「どのタイミングで、いつまでにやる必要」があったのかいつまでにやる必要があった？・3月上旬から設計する必要があった →3月はインフラ構成図を書きながら検証していた →先んじて検証ソースを書いていたので若干先行して開発が進んでいたので画面を頭の中で組みながら実装していた

Slide 49

Slide 49 text

Slide 50

Slide 50 text

やってはいけない対症療法 @yu_mashirouの考え・当初からインフラ込みだったのでかなりギリギリのスケジュールの想定でいた（スケジュールも同様）結果・先方都合で1ヶ月くらいずれ込んだので首の皮一枚つながった状態でどうにかリリースできたバッファを確保する考慮をしていたか考慮していた？まるで考慮していなかった。追加実装する前提でないまま開発を進めていた

Slide 51

Slide 51 text

Slide 52

Slide 52 text

やってはいけない対症療法 Aさん 1.開発作業（一番重要な部分） 2.インフラ（Lambda）の構築作業作業の分担に問題はなかったのか Bさん 1.技術検証作業 2.AWSインフラ構築作業 3.REST API実装（サーバ）

Slide 53

Slide 53 text

やってはいけない対症療法 @yu_mashirouの作業 1.技術検証 2.AWSインフラ構築（本構築前演習） 3.インフラ構成図作成作業 4.定義書作成作業（インフラ・サーバ） 5.チケット・タスク振り分け作業 6.管理画面開発（サーバ）作業の分担に問題はなかったのか

Slide 54

Slide 54 text

やってはいけない対症療法 @yu_mashirouの作業 1.技術検証 2.AWSインフラ構築（本構築前演習） 3.インフラ構成図作成作業 4.定義書作成作業（インフラ・サーバ） 5.チケット・タスク振り分け作業 6.管理画面開発（サーバ）作業の分担に問題はなかったのか一人で過剰に作業している

Slide 55

Slide 55 text

やってはいけない対症療法「課題・疑問点」 • 画面定義書を「どのタイミングで、いつまでにやる必要」があったのか • バッファを確保する考慮をしていたか • 作業の分担に問題はなかったのか • スケジュールの進行の把握はできていたのか

Slide 56

Slide 56 text

やってはいけない対症療法状況・ギリギリのスケジュール・一人で倍以上抱えたタスク・タスクを消化するために残業・初めての作業がほとんど（開発除く）・他の案件の差し込み対応が２回ほどスケジュールの進行の把握はできていたのか

Slide 57

Slide 57 text

やってはいけない対症療法状況・ギリギリのスケジュール・一人で倍以上抱えたタスク・タスクを消化するために残業・初めての作業がほとんど（開発除く）・他の案件の差し込み対応が２回ほどスケジュールの進行の把握はできていたのかできてない

Slide 58

Slide 58 text

結果間に合ったの？

Slide 59

Slide 59 text

結果無事リリース間に合ったの？

Slide 60

Slide 60 text

結果実際・間に合ったけど問題は残ったりしていた・１次リリースのために急場でデプロイしたので大問題に気が付かなかった間に合ったの？アプリケーション側でHTTPSリダイレクト処理を入れるのを忘れた図↓

Slide 61

Slide 61 text

結論＿人人人人人人人＿＞　論より設計　＜￣Y^Y^Y^Y^Y^Y￣　　徹底しないと≪地獄≫が始まる……

Slide 62

Slide 62 text

自己紹介 - 柚口ましろう(代口勇真) - Twitter: @yu_mashirou - 生態: へんなひと・開発者 - 好物:アイマス(橘ありす)とPHPとCloudFrontと音ゲー株式会社C-Gardenという会社に設立費用出したのでどうやら役員らしい…… こんなアイコンで活動するなど

Slide 63

Slide 63 text

EOF