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 to create development process
Search
Dai Fujihara
February 03, 2021
Technology
0
210
開発プロセスのつくり方 / How to create development process
開発プロセスのインプットからアウトプットまでの流れを整理する資料です。
Dai Fujihara
February 03, 2021
Tweet
Share
More Decks by Dai Fujihara
See All by Dai Fujihara
なぜ自社ではスクラムがうまくいかないのか アジャイルコーチと考える、スクラムのアンチパターン / Why Scrum doesn't work in my company?
daipresents
1
770
CI/CDパイプラインにE2Eテストを統合する / Integrate E2E testing into the CI/CD pipeline
daipresents
0
1.5k
アジャイル・DevOps時代のタスク管理ツール / Task Management Tools for the Agile and DevOps Era
daipresents
0
370
品質エンジニアリングと自動化後の世界 / Quality Engineering and the Post-Automated World
daipresents
0
1k
アジャイル開発と品質エンジニアリング - QA時代の終わりとQE時代のはじまり / Agile Development and Quality Engineering
daipresents
1
8.3k
QA組織パターン - 構造ごとのメリットデメリットまとめ / QA organizational structure
daipresents
2
1.4k
人類よ! コードレビューも完全自動化の時代へ?!今風なイケてる静的解析を大活用しよう! / Automated Code Review
daipresents
0
2.4k
アジャイルテスティングが倒せない / I can't beat agile testing
daipresents
5
2.1k
E2Eテスト自動化の本質 - 品質と開発スピードを支えるテスト自動化時代へ / The Essence of E2E Test Automation
daipresents
0
760
Other Decks in Technology
See All in Technology
LINE API Deep Dive Q1 2025: Unlocking New Possibilities
linedevth
1
160
どっちの API SHOW?SharePoint 開発における SharePoint REST API Microsoft Graph API の違い / Which API show? Differences between Microsoft Graph API and SharePoint REST API
karamem0
0
110
コード品質向上で得られる効果と実践的取り組み
ham0215
2
200
グループポリシー再確認
murachiakira
0
160
モジュラーモノリスでスケーラブルなシステムを作る - BASE のリアーキテクチャのいま
panda_program
7
2k
ペアプログラミングにQAが加わった!職能を超えたモブプログラミングの事例と学び
tonionagauzzi
1
140
Javaの新しめの機能を知ったかぶれるようになる話 #kanjava
irof
3
4.9k
React Server Componentは 何を解決し何を解決しないのか / What do React Server Components solve, and what do they not solve?
kaminashi
6
1.2k
SpannerとAurora DSQLの同時実行制御の違いに想いを馳せる
masakikato5
0
570
Go製のマイグレーションツールの git-schemalex の紹介と運用方法
shinnosuke_kishida
1
400
DevinはクラウドエンジニアAIになれるのか!? 実践的なガードレール設計/devin-can-become-a-cloud-engineer-ai-practical-guardrail-design
tomoki10
3
1.3k
Amazon GuardDuty Malware Protection for Amazon S3を使おう
ryder472
2
100
Featured
See All Featured
The Cost Of JavaScript in 2023
addyosmani
48
7.6k
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
4
490
Art, The Web, and Tiny UX
lynnandtonic
298
20k
It's Worth the Effort
3n
184
28k
Speed Design
sergeychernyshev
28
860
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
30k
Building Adaptive Systems
keathley
41
2.5k
A Philosophy of Restraint
colly
203
16k
The Straight Up "How To Draw Better" Workshop
denniskardys
232
140k
[RailsConf 2023] Rails as a piece of cake
palkan
53
5.4k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
45
9.5k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
Transcript
開発プロセス のつくり方 Copyright © 2019- Sekai Co., Ltd. All Rights
Reserved. https://daipresents.com/service/ Dai FUJIHARA @daipresents
はじめに 2 ◦ プロセスは現場ごとに異なるため、カスタマイズは現場に ゆだねられますが、そのベースとなるプロセスの整理・まと めにご利用ください ◦ 特定のプロセスには意思決定が必要になります。その意 思決定については考えられる選択肢を並べてみました。 必要に応じて追加したり削除してください
自分の背丈の確認 3 ◦ Q. 今の開発チームはどういう位置にいますか? • プロダクト価値を高めていくチーム体制やプロセスが 整っています(すごくいいね) • 開発スピードを高めていく段階になっています(いい
ね) • 開発プロセスを安定して回していく必要があります(よ しよし) • 開発プロセスを考える時期がやっときた(がんばろ)
ゴール設定 4 ◦ Q. ゴールをどう設定しますか? • ユーザやPO、開発者の意見をどんどんとりこめるプロ セスを作りたい • POの要求に答えられるプロセスにしたい
• 開発スピードを上げたい • 非効率な手戻りをなくして生産性を高めたい • 安全に確実にプロダクトをリリースしたい
今とゴールのギャップ はなんでしょう? プロセスを考えるときの材料になるはずなので洗い出してみましょう。 5
ステップ 1. インプットを整理する 6 要件、お問い合わせ、ユーザーレビュー、開発フィードバック・・・。 どこからなにがきて、どれはどういった意味があるものなのか? 要件となりうる入力のすべてを整理する。
インプットをさばく 7 なに? どこから? どんな? ビジネス要望 ビジネス、POなど ビジネスのために必要となるもの。 お問い合わせ ユーザーからCS経由な
ど ユーザーの不便や不満や疑問。ユーザーニーズとな りえるもの レビュー アップストアなど アプリレビュー、ご意見など、ユーザーフィードバック となりえるもの バグ ユーザー、自社メンバー など 致命的なものは修正が必須。無視する判断も必要。 お問い合わせやレビューに混ざる可能性がある。 その他要望 自社メンバー 作っていて気がついたことなど。もっとこうしたらよくな るとか。
ステップ 2. インプットから要件 8 たくさんの入力をどうバックログに仕上げていくのか?
インプットから要件で決めるべきこと 9 ◦ 優先度を誰がつけるのか? • どれを誰が? • 優先度をつけたものをどこにどう並べるのか? ◦ 変更をどこまで許容するか?
• 常に変更を受け入れるのか? • スプリント終了や開始のタイミングだけにするか? ◦ やったほうがいいけど後回しになりがちなものをどうさばくのか? • ちょっとずつやるのか? • まとめてやるのか? • 通常作業と同じレベルで扱うのか? 別で管理していくのか?
バックログ完成 要件のバックログなので粒度はまだ荒いです。 10
ステップ 3. 要件から仕様 11 大多数の問題はこの場所におこりがち。なぜ歴史は繰り返してしまうのか? 原因を考え、直視しながら対策を考えるべきです。
要件と仕様のはざま 12 このギャップによる手戻りが一番のムダ。 一番防ぎたいところ。 ギャップ ほしいもの (要件) 作るための ルール (仕様)
要件と仕様で決めるべきこと 13 ◦ 要件を仕様にするために何を決めるか? • デザイン • 状態や画面の遷移 • 技術的実現性
• アーキテクチャレベルの決定 ◦ 仕様をどこまで表現するか? • 仕様のフォーマットをどうするか? • どこまで記述すべきか?必要なのか? ◦ 仕様策定に誰が参加すべきか? • 次ページへ
14 • BizやPOが仕様を決めるなら ◦ 開発は作ることに集中できる ◦ 開発は作るだけに集中してしまう 要件と仕様で決めるべきこと
ステップ 4. 仕様からタスク 15 作るためのルールが決まったので、タスクに分割可能になります。 タスクに分割できると見積もれます。 見積もれるものはテストも可能になります。
16 仕様からタスクで決めるべきこと ◦ 作業レベルのタスク分割 • これが全部終われば次に進める • タスクは個人レベルで管理されればよい ▪ POはユーザーストーリーなどもう少し大きいレベ
ルで確認 ◦ 見積もられ優先順位が明確なタスク • スケジュールができる ◦ タスク分割に誰が参加すべきか? • 作業する人 • 作業する人からの質問に答えられるBizやPO
ステップ 5. タスクからデモ、リリース 17 完成したもののレビューとリリース判断。
ステップ 6. リリース後の フィードバックサイクル 18 ABテスト、問い合わせやレビューといったフィードバックのインプットへのつなぎ込み。
CREDITS - Special Thank! ◦ Presentation template by SlidesCarnival and
Photographs by Unsplash • Photo by Randy Fath on Unsplash 19 お問い合わせは https://daipresents.com/service/ からお気軽にどうぞ。