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
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
tarohida
September 18, 2020
Technology
0
36
リモートワークをきっかけに、見積もりと進捗について考えてみた
tarohida
September 18, 2020
Tweet
Share
More Decks by tarohida
See All by tarohida
テスト駆動開発試してみた発表
tarohida
0
240
事故について考えてみようの会
tarohida
0
180
Other Decks in Technology
See All in Technology
The_Evolution_of_Bits_AI_SRE.pdf
nulabinc
PRO
0
130
開発組織の課題解決を加速するための権限委譲 -する側、される側としての向き合い方-
daitasu
5
580
類似画像検索モデルの開発ノウハウ
lycorptech_jp
PRO
5
1.1k
マルチロールEMが実践する「組織のレジリエンス」を高めるための組織構造と人材配置戦略
coconala_engineer
3
710
Scrumは歪む — 組織設計の原理原則
dashi
0
120
OCHaCafe S11 #2 コンテナ時代の次の一手:Wasm 最前線
oracle4engineer
PRO
1
110
[JAWSDAYS2026]Who is responsible for IAM
mizukibbb
0
430
マルチプレーンGPUネットワークを実現するシャッフルアーキテクチャの整理と考察
markunet
2
230
NewSQL_ ストレージ分離と分散合意を用いたスケーラブルアーキテクチャ
hacomono
PRO
2
230
情シスのための生成AI実践ガイド2026 / Generative AI Practical Guide for Business Technology 2026
glidenote
0
200
タスク管理も1on1も、もう「管理」じゃない ― KiroとBedrock AgentCoreで変わった"判断の仕事"
yusukeshimizu
5
2.6k
Abuse report だけじゃない。AWS から緊急連絡が来る状況とは?昨今の攻撃や被害の事例の紹介と備えておきたい考え方について
kazzpapa3
1
480
Featured
See All Featured
GitHub's CSS Performance
jonrohan
1032
470k
SERP Conf. Vienna - Web Accessibility: Optimizing for Inclusivity and SEO
sarafernandez
1
1.3k
Odyssey Design
rkendrick25
PRO
2
540
The AI Revolution Will Not Be Monopolized: How open-source beats economies of scale, even for LLMs
inesmontani
PRO
3
3.1k
Conquering PDFs: document understanding beyond plain text
inesmontani
PRO
4
2.5k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3.4k
The Limits of Empathy - UXLibs8
cassininazir
1
250
Navigating Algorithm Shifts & AI Overviews - #SMXNext
aleyda
1
1.2k
Measuring Dark Social's Impact On Conversion and Attribution
stephenakadiri
1
150
30 Presentation Tips
portentint
PRO
1
250
Ruling the World: When Life Gets Gamed
codingconduct
0
170
Everyday Curiosity
cassininazir
0
160
Transcript
リモートワークをきっかけに、 見積もりと進捗管理について考えた
自己紹介
前提 ここ半年ほど担当していたタスク - 自社開発ソフトウェア「X-MON」の開発 - 社内向けWebシステムの開発(Laravelフレームワーク)
リモートワークをきっ かけに?
リモートワークをきっかけに (リモートワーク導入以前...) リモートワークさえ導入されれば、勤務 は天国になると思っていた。
リモートワークをきっかけに (リモートワーク導入後...) そんなことはなかった。
新たなる壁、進捗管理
新たなる壁、進捗管理 リモートワークであっても、進捗に遅れが生じるとしんどい ⇓ いかにこれを解決するか 今まで、リモートワークでないことに全ての原因を帰していたため、気が付かなかったが・・・
新たなる壁、進捗管理 結論: スケジュールがひっ迫しないような見積もりを出せば、 進捗の遅れを防ぐことができる。
スケジュールがひっ迫しない ような見積もりを出す
スケジュールがひっ迫しないような見積もりを出す 締め切りを遅らせるほど、締切に間に合わなくなるリスクは減る ⇕衝突 とはいえ、無限に見積もりを膨らませるわけにはいかない どうすれば...
スケジュールがひっ迫しないような見積もりを出す 『Clean Coder』という書籍が参考に
『Clean Coder』 締切の原則 「締切は絶対に守らねばならない。 『間に合います』と自信を持てるところに、締切を設定する」
『Clean Coder』 ⇨ なぜ? 顧客はこちらの納期を信じ、予定を立てるから。 (システム稼働を前提とした前準備や、プロモーション等にお金を払う) 締切に間に合わなかったということは、顧客に損害を与えるということである。
『Clean Coder』 じゃあ、確実に納期を守るために、 めちゃくちゃに長い見積もりを出してもいいの? ⇓ NO
『Clean Coder』 また、この書籍においては、エンジニアが自分の作業について、(ある程度)正 確に見積もれるということを前提に書かれている (ソフトウェアのプロとしてどう振る舞うか?という話なので) ⇨ 正確な見積もりの元に、締め切りを設定しないといけない
『Clean Coder』 では、実際にどうやって正確に見積もるのか
正確に見積もる 今実施している方法 - 三点見積もり法 + 積み上げ法 + スプレッドシートでの記録
正確に見積もる - 与えられたタスクを、細かく細分化する - それぞれの細分化したタスクについて、三点見積もりを行う - それぞれについて合算し、悲観値を締め切りとする ※三点見積もり:楽観値、標準値、悲観値を利用し、見積もりを行う方法。 それぞれ楽観的に見積もった値、通常完了すると思われる値、悲観的に見積もった値を表す
正確に見積もる
正確に見積もる というわけで、まだかなり幅があり、正確な見積もりをするという点においてはまだ道半ばである。 見積もりにおけるミスもめちゃくちゃ多い - 要件を満たしておらず、手戻りが発生する - デザインパターンに沿わない独自実装を行い、リファクタリング(設計不足) - 初めて触るフレームワーク等について、必要作業時間を甘く見積もりすぎた -
見積もり段階における、実装メソッドの想定漏れ - 環境構築、最終確認、プルリクエストと修正等、見積もりに含めるのを忘れる
メリット
メリット 以下のようなメリット - PDCAサイクルが回せたので、見積もり精度を向上させることができた。 - タスクを自分で管理している感覚が得られた - 進捗把握に役立った - 「質問しにくい...」問題が解消された
PDCAサイクルが回せたので、見積もり精度を向上させることができ た タスクごとに見積もって、都度振り返りを行うことで、 定期的にセルフフィードバックを受けることができた。 以下のような気づきを得られた。 - リリース単位を小さくすると、見積もりは簡易になる。 - 可能な限り作業単位を分割したほうがよい。見積もりが容易になるし、考慮漏れが防げる。 -
やったことない言語、アーキテクチャ利用の場合はかなり余裕をもって見積もったほうがいい。 - ガンガン質問することで、進捗はスムーズになる。 - 考慮漏れしやすい作業工程(環境構築、リファクタリング、最終確認など)
タスクを自分で管理している感覚が得られた 概算見積もりに比べ、根拠を持って見積もりを出すことができること により、自分の見積もりに自信がもてるようになった。 自信があれば、次は進捗管理が不可能なものではなく、管理可能 で、自分でハンドリングできるものであるように感じられるようになっ た ⇨ 主体的に仕事に取り組めるようになった。
進捗把握に役立った 細かくスプレットシートにタスクを羅列し、終わったものから塗りつぶしていく作業を 行うことによって、自分が今どこまで進んでいて(現在地)、ゴールまであとどれくら いなのかを把握しながら仕事を進められるようになった。 ⇨ これも、自信をもって仕事を進めていけるという点に寄与してくれた。
「質問しにくい...」問題が解消された リモートで特に深刻になりやすい「質問しにくくて ...」現象。 PDCAによる気付きから、「ガンガン質問することで、進捗はスムーズになる」ことがよくわかった。 + 締切にはかならず間に合わせないといけないという意識 ⇨ 「相手の都合など知るか、質問しなければ進捗に遅れが出て俺が死ぬ」 という考え方となり、質問や相談のタイミングが早まった。
まとめ - リモートワークをきっかけに、見積もりと進捗管理について考えるようになった。 - 『Clean Coder』という書籍に、見積もりについての大事なこと、考え方が書かれていた。 - 現在は三点見積もり + 積み上げ法という見積もり方法を用いて、見積もりを行っている。
- 見積もり精度については道半ばだが、 PDCAサイクルを回せるので気づきが多い。メリットも多々受けることができた。
今後 このサイクルをぐるぐる回して、見積もりについてのノウハウを溜めていきたい。
ありがとうございました 当発表内容についてはブログにしています ⇨ https://taro-h.hatenablog.com/entry/mitsumori_shinchoku_rw