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
なぜフロントエンド開発の見積もりは当たらないのか / how we improve our estimate
Search
dexia2
October 24, 2019
Programming
2
1k
なぜフロントエンド開発の見積もりは当たらないのか / how we improve our estimate
見積もりが大きくずれていたフロントエンド開発プロジェクトの見積もりをいかにして改善したかについて話します。
dexia2
October 24, 2019
Tweet
Share
Other Decks in Programming
See All in Programming
サイコロで理解する統計的仮説検定の考え方
tatamiya
0
170
[技育CAMPアカデミア]アイディアを形に!【超入門】スマホアプリ開発〜リリースまでの流れをご紹介
teamlab
PRO
0
350
Behind VS Code Extensions for JavaScript / TypeScript Linnting and Formatting
unvalley
3
170
ONE WEDGE_company_guide
1wedge_one
0
390
今、知っておきたい! 生成AIエージェントの世界
elith
3
340
Java 22 Overview
kishida
1
170
Rubyでたのしむクリエイティブコーディング/Enjoy Creative coding with Ruby
chobishiba
1
170
甘い香りに誘われてVanilla Extractを1年間運用してみた
miyahkun
1
110
Elm Form Validation
bkuhlmann
0
510
0→1と1→10の狭間で Javaという技術選定を振り返る/Reflecting on the Decision to Choose Java Between Scaling from 0 to 1 and 1 to 10
jaguar_imo
2
370
単体テストを書かない技術 #phpcon_odawara
o0h
PRO
26
7.9k
StoreKit2によるiOSのアプリ内課金のリニューアル
kangnux
0
100
Featured
See All Featured
Imperfection Machines: The Place of Print at Facebook
scottboms
258
12k
The Straight Up "How To Draw Better" Workshop
denniskardys
227
130k
Raft: Consensus for Rubyists
vanstee
132
6.2k
How STYLIGHT went responsive
nonsquared
92
4.8k
I Don’t Have Time: Getting Over the Fear to Launch Your Podcast
jcasabona
20
1.6k
Writing Fast Ruby
sferik
620
60k
Being A Developer After 40
akosma
56
580k
Fantastic passwords and where to find them - at NoRuKo
philnash
36
2.5k
Into the Great Unknown - MozCon
thekraken
10
980
The Brand Is Dead. Long Live the Brand.
mthomps
48
28k
Testing 201, or: Great Expectations
jmmastey
27
6.3k
Building Effective Engineering Teams - LeadDev
addyosmani
27
1.8k
Transcript
なぜフロントエンド開発の見積もりは 当たらないのか STORES.jp
Meetup for Front-end Engineers #1 2019.10.24
自己紹介 小林 礼幸 @dexia2 ストアーズ・ドット・ジェーピー株式会社 ⚙ フロントエンドエンジニア ⚙ 設計、コーディング、会議、諸々のルールを考える人 老荘思想、陽明学を勉強中
全体像 なぜ見積もりに向き合うことになったのか なぜ見積もりは当たらなかったのか 見積もりを改善するために何に取り組んだのか
なぜ見積もりに向き合うことになったのか
見積もりの推移 見積もりの精度が余りにもよくなかった 0.5ヶ月 開発者の経験 機能数 + バッファ 当初の見積もり 次回見積もり 最終見積もり
1.5ヶ月 3.5ヶ月
なぜ見積もりは当たらなかったのか
原因 ステークホルダーの要求を際限なく受け入れた 見積もりを行うタイミングが早すぎた
原因 ステークホルダーの要求を際限なく受け入れた 見積もりを行うタイミングが早すぎた
社内のステークホルダー フロントエンド バックエンド デザイナー ビジネスサイド フロントエンドは多くのチームから要求を受ける
社内のステークホルダー デザイナー 状況に応じた柔軟なデ ザインにしたい ビジネスサイド ビジネス上の定量的な 目標を達成したい バックエンド 技術的な負債を作らな いようにしたい
フロントエンドは多くのチームから要求を受ける
チーム内のステークホルダー ドキュメントを残 してほしい 例外に素早く 気づきたい CIの実行時間を 短くしたい 同じチームからは開発プロセスへの要求を受ける iPhone SE
切りたい 実装を共通化 したい レビュー してほしい
当初聞いていたこと 既存のUIをそのまま移行する WebAPIの動作は基本的には変わらない 共通コンポーネントを使い回せるから早く作れる
実際に起きたこと 既存のUIが大きくリニューアルされていた WebAPIのURLや動作が変更されていた 共通コンポーネントを使うたびに新しい仕様が発覚し、その度に調 査・修正が必要だった
学んだこと ステークホルダーはそれぞれ要求を持つ ステークホルダーが増えれば増えるほど調整コストは大きい 何をやらないかを定義するまで要求は増加し続ける => フロントエンドは中間管理職
原因 ステークホルダーの要求を際限なく受け入れた 見積もりを行うタイミングが早すぎた
フロントエンドの工程 フロントエンドは実装に入るまでの行程が長い 要求定義 デザイン 外部 設計 内部 設計 実装
不確実性のコーン 前工程で行った見積もりは後工程の1/4の精度に落ちる
見積もりと確率 個々の見積もりの誤差は相殺される
見積もりで失敗したこと 個々の見積もりの精度を追求して、確率を考慮しなかった 平均的な見積もりをしたつもりが、最良の見積もりだった 要求・デザインが確定する前に見積もりを行った
学んだこと 見積もりは個々ではなく全体で評価される 見積もりは確率的な幅で表現される どの時点で行われたかによって見積もりの精度は変わる => 見積もりの方法は欲しい精度によって変わる
見積もりを改善するために何に取り組んだのか
スクラムをやってみた
スクラムイベント スプリント 計画 デイリー スクラム スプリント レビュー スプリント レトロスペク ティブ
スクラムが見積もりに貢献できること ステークホルダーを巻き込んだ『場』ができる ⚙ スプリント計画、スプリントレビューに全員参加する ⚙ 要求が見積もり前に確定できる 実績を元に計画・見積もりができる ⚙ 確率的にそれらしい見積もりになりやすい
「その場に参加することで、自分の主観の 限界を超えて、相互主観性、みんなの主観 というものが作られる」 野中郁次郎
見積もりの推移 それらしい見積もりができるようになった 0.5ヶ月 開発者の経験 機能数 + バッファ 当初の見積もり 次回見積もり 最終見積もり
1.5ヶ月 3.5ヶ月 スクラム
参考文献 中鉢 慎『外資系コンサルが教える難題を解決する12ステップ プロ ジェクトリーダーの教科書』かんき出版(2018) スティーブ マコネル『ソフトウェア見積り 人月の暗黙知を解き明か す』溝口 真理子, 田沢
恵他訳 久手堅 憲之監修 日経BP(2006)