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
Dai Fujihara
February 03, 2021
Technology
280
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
960
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
490
品質エンジニアリングと自動化後の世界 / Quality Engineering and the Post-Automated World
daipresents
0
1.2k
アジャイル開発と品質エンジニアリング - QA時代の終わりとQE時代のはじまり / Agile Development and Quality Engineering
daipresents
1
9.5k
QA組織パターン - 構造ごとのメリットデメリットまとめ / QA organizational structure
daipresents
2
1.9k
人類よ! コードレビューも完全自動化の時代へ?!今風なイケてる静的解析を大活用しよう! / 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
880
Other Decks in Technology
See All in Technology
分析作業をどこまで任せるか自分で決められる AIネイティブBI『Golden Analytics』が 良さげな話 /golden-analytics-is-ai-native-bi
shinyaa31
0
120
デザインレビューは自動化できるのか?─ Flutter × Figma で UI 品質保証を考える
techiro
2
790
【dbts2026】AIエージェントの 判断と探索を変える、 データベース エンジニアリング― 既存DBの処理と依存関係から作る、オペレーショナルオントロジー ―
shisyu_gaku
0
160
AIエージェントの監視、思考を見るか行動を見るか / Monitoring AI Agents: Thoughts or Actions
yusukeshimizu
1
150
生き様としてのSRE
hokkai7go
1
170
続・ソフトウェアアーキテクトのための意思決定術: Decision Readiness, Revisited — When AI Changes the Economics of Software Architecture
snoozer05
PRO
9
2.2k
AI時代のエンジニアの情報発信〜個人の発信を組織の力に変える〜
ryo_kawamata
1
7.3k
現場を動かすAIエージェント#2_製造業現場でのAI活用から見た、ハマる罠と実践知
kintotechdev
2
170
なぜ東京にいる私が、新潟の技術コミュニティを運営するのか by 八雲慎之助
yakumo
0
220
視野はAIに、視座は人に / ai-for-breadth-humans-for-perspective
nkzn
6
3.1k
新卒エンジニア、 介護士になる
ryu1013
1
690
公共システムAdventCalendar2026
toru_kubota
0
200
Featured
See All Featured
Primal Persuasion: How to Engage the Brain for Learning That Lasts
tmiket
0
520
SEO Brein meetup: CTRL+C is not how to scale international SEO
lindahogenes
2
3k
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.9k
GraphQLとの向き合い方2022年版
quramy
50
15k
Getting science done with accelerated Python computing platforms
jacobtomlinson
2
570
Evolution of real-time – Irina Nazarova, EuRuKo, 2024
irinanazarova
9
1.7k
Joys of Absence: A Defence of Solitary Play
codingconduct
1
570
Claude Code どこまでも/ Claude Code Everywhere
nwiizo
68
60k
Data-driven link building: lessons from a $708K investment (BrightonSEO talk)
szymonslowik
1
1.4k
エンジニアに許された特別な時間の終わり
watany
109
250k
Introduction to Domain-Driven Design and Collaborative software design
baasie
1
1.1k
Building Adaptive Systems
keathley
44
3.3k
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/ からお気軽にどうぞ。