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
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
930
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
470
品質エンジニアリングと自動化後の世界 / Quality Engineering and the Post-Automated World
daipresents
0
1.2k
アジャイル開発と品質エンジニアリング - QA時代の終わりとQE時代のはじまり / Agile Development and Quality Engineering
daipresents
1
9.3k
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
850
Other Decks in Technology
See All in Technology
認知負荷をGemini で溶かす — GKE 基盤「Orbit」における AI エージェントの実践
sansantech
PRO
1
320
DatadogのBits Chatが開発組織にもたらしたもの / What Bits Chat Has Brought Us
sms_tech
1
280
社内の7割が使うデータ基盤を、 データチーム2人で回すためにやったこと
koh_yoshi
4
1.4k
カートの信頼性を担保するWireMockを使ったe2eテスト
ykagano
0
390
FPGAが実現する遠方宇宙の高空間分解能天体撮影 -大型地上望遠鏡の視力を補正する「補償光学」とは?-
komei_mt
0
370
ハーレムエンジニアリング
kazuma777777
0
180
20260807_第6回_関東kaggler会LT_claw系bot xangiと始める、"寂しくない" kaggle
sugupoko
0
330
オートロックマンションなのに、各部屋は施錠なし!? 攻撃者が組織内ネットワークで大暴れする理由 / The Front Door Is Locked, but the Rooms Are Wide Open: Why Attackers Move Freely Inside Enterprise Networks
nttcom
1
6k
強化学習「理論」入門
enakai00
3
3.6k
AI-DLC実践録_フルサイクル開発への挑戦
miyuc
0
240
AIペネトレーションテスト・ セキュリティ検証「AgenticSec」紹介資料
laysakura
2
9.2k
Head First モブプログラミング / Head First Mobprogramming
takaking22
10
12k
Featured
See All Featured
Code Review Best Practice
trishagee
74
20k
Design of three-dimensional binary manipulators for pick-and-place task avoiding obstacles (IECON2024)
konakalab
0
540
Six Lessons from altMBA
skipperchong
29
4.4k
The Curse of the Amulet
leimatthew05
2
14k
More Than Pixels: Becoming A User Experience Designer
marktimemedia
3
490
<Decoding/> the Language of Devs - We Love SEO 2024
nikkihalliwell
1
290
Marketing Yourself as an Engineer | Alaka | Gurzu
gurzu
0
280
Amusing Abliteration
ianozsvald
1
250
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
234
17k
Navigating Team Friction
lara
192
16k
AI in Enterprises - Java and Open Source to the Rescue
ivargrimstad
0
1.4k
Scaling GitHub
holman
464
140k
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/ からお気軽にどうぞ。