Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
開発プロセスのつくり方 / How to create development process
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
Dai Fujihara
February 03, 2021
Technology
270
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
開発プロセスのつくり方 / How to create development process
開発プロセスのインプットからアウトプットまでの流れを整理する資料です。
Dai Fujihara
February 03, 2021
More Decks by Dai Fujihara
See All by Dai Fujihara
なぜ自社ではスクラムがうまくいかないのか アジャイルコーチと考える、スクラムのアンチパターン / Why Scrum doesn't work in my company?
daipresents
1
940
CI/CDパイプラインにE2Eテストを統合する / Integrate E2E testing into the CI/CD pipeline
daipresents
0
1.9k
アジャイル・DevOps時代のタスク管理ツール / Task Management Tools for the Agile and DevOps Era
daipresents
0
480
品質エンジニアリングと自動化後の世界 / Quality Engineering and the Post-Automated World
daipresents
0
1.2k
アジャイル開発と品質エンジニアリング - QA時代の終わりとQE時代のはじまり / Agile Development and Quality Engineering
daipresents
1
9.4k
QA組織パターン - 構造ごとのメリットデメリットまとめ / QA organizational structure
daipresents
2
1.8k
人類よ! コードレビューも完全自動化の時代へ?!今風なイケてる静的解析を大活用しよう! / Automated Code Review
daipresents
0
2.6k
アジャイルテスティングが倒せない / I can't beat agile testing
daipresents
5
2.3k
E2Eテスト自動化の本質 - 品質と開発スピードを支えるテスト自動化時代へ / The Essence of E2E Test Automation
daipresents
0
870
Other Decks in Technology
See All in Technology
品質と信頼性を地続きにする
grimoh
0
450
フルカイテン株式会社 エンジニア向け採用資料
fullkaiten
0
12k
人間はどの意思決定を手放せるのか
kawasima
14
7k
Slack上でインフラをトラブルシュートする! Agentic Platform Engineeringの第一歩
teru0x1
5
1.7k
20260912_スクラムにジェネラリストは必要か
ryugen04
0
420
Reactの設計論
uhyo
24
13k
データ_AIの事業の勝敗をわけるもの
nek0128
0
380
Screen Lens - 今見てる画面を翻訳する
komagata
0
320
Claude in Chrome 入門 / Introduction to Claude in Chrome
cielo1985
0
830
研究開発部の紹介 / Sansan R&D Profile
sansan33
PRO
5
25k
アプリをもっと"iOSアプリっぽく"する小さな工夫 / Small Touches That Make Your App Feel More Like an iOS App
matsuji
2
910
Issue 駆動でスペシャリストの意図を届ける、AI 実装のアクセシビリティ向上
thkt
0
110
Featured
See All Featured
Chasing Engaging Ingredients in Design
codingconduct
0
310
Designing for Timeless Needs
cassininazir
1
480
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.8k
Color Theory Basics | Prateek | Gurzu
gurzu
1
470
Typedesign – Prime Four
hannesfritz
42
3.2k
Understanding Cognitive Biases in Performance Measurement
bluesmoon
32
3k
Between Models and Reality
mayunak
4
460
Dealing with People You Can't Stand - Big Design 2015
cassininazir
368
27k
Abbi's Birthday
coloredviolet
4
10k
Crafting Experiences
bethany
1
340
Imperfection Machines: The Place of Print at Facebook
scottboms
270
14k
We Are The Robots
honzajavorek
0
370
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/ からお気軽にどうぞ。