Slide 1

Slide 1 text

開発プロセス のつくり方 Copyright © 2019- Sekai Co., Ltd. All Rights Reserved. https://daipresents.com/service/ Dai FUJIHARA @daipresents

Slide 2

Slide 2 text

はじめに 2 ○ プロセスは現場ごとに異なるため、カスタマイズは現場に ゆだねられますが、そのベースとなるプロセスの整理・まと めにご利用ください ○ 特定のプロセスには意思決定が必要になります。その意 思決定については考えられる選択肢を並べてみました。 必要に応じて追加したり削除してください

Slide 3

Slide 3 text

自分の背丈の確認 3 ○ Q. 今の開発チームはどういう位置にいますか? ● プロダクト価値を高めていくチーム体制やプロセスが 整っています(すごくいいね) ● 開発スピードを高めていく段階になっています(いい ね) ● 開発プロセスを安定して回していく必要があります(よ しよし) ● 開発プロセスを考える時期がやっときた(がんばろ)

Slide 4

Slide 4 text

ゴール設定 4 ○ Q. ゴールをどう設定しますか? ● ユーザやPO、開発者の意見をどんどんとりこめるプロ セスを作りたい ● POの要求に答えられるプロセスにしたい ● 開発スピードを上げたい ● 非効率な手戻りをなくして生産性を高めたい ● 安全に確実にプロダクトをリリースしたい

Slide 5

Slide 5 text

今とゴールのギャップ はなんでしょう? プロセスを考えるときの材料になるはずなので洗い出してみましょう。 5

Slide 6

Slide 6 text

ステップ 1. インプットを整理する 6 要件、お問い合わせ、ユーザーレビュー、開発フィードバック・・・。 どこからなにがきて、どれはどういった意味があるものなのか? 要件となりうる入力のすべてを整理する。

Slide 7

Slide 7 text

インプットをさばく 7 なに? どこから? どんな? ビジネス要望 ビジネス、POなど ビジネスのために必要となるもの。 お問い合わせ ユーザーからCS経由な ど ユーザーの不便や不満や疑問。ユーザーニーズとな りえるもの レビュー アップストアなど アプリレビュー、ご意見など、ユーザーフィードバック となりえるもの バグ ユーザー、自社メンバー など 致命的なものは修正が必須。無視する判断も必要。 お問い合わせやレビューに混ざる可能性がある。 その他要望 自社メンバー 作っていて気がついたことなど。もっとこうしたらよくな るとか。

Slide 8

Slide 8 text

ステップ 2. インプットから要件 8 たくさんの入力をどうバックログに仕上げていくのか?

Slide 9

Slide 9 text

インプットから要件で決めるべきこと 9 ○ 優先度を誰がつけるのか? ● どれを誰が? ● 優先度をつけたものをどこにどう並べるのか? ○ 変更をどこまで許容するか? ● 常に変更を受け入れるのか? ● スプリント終了や開始のタイミングだけにするか? ○ やったほうがいいけど後回しになりがちなものをどうさばくのか? ● ちょっとずつやるのか? ● まとめてやるのか? ● 通常作業と同じレベルで扱うのか? 別で管理していくのか?

Slide 10

Slide 10 text

バックログ完成 要件のバックログなので粒度はまだ荒いです。 10

Slide 11

Slide 11 text

ステップ 3. 要件から仕様 11 大多数の問題はこの場所におこりがち。なぜ歴史は繰り返してしまうのか? 原因を考え、直視しながら対策を考えるべきです。

Slide 12

Slide 12 text

要件と仕様のはざま 12 このギャップによる手戻りが一番のムダ。 一番防ぎたいところ。 ギャップ ほしいもの (要件) 作るための ルール (仕様)

Slide 13

Slide 13 text

要件と仕様で決めるべきこと 13 ○ 要件を仕様にするために何を決めるか? ● デザイン ● 状態や画面の遷移 ● 技術的実現性 ● アーキテクチャレベルの決定 ○ 仕様をどこまで表現するか? ● 仕様のフォーマットをどうするか? ● どこまで記述すべきか?必要なのか? ○ 仕様策定に誰が参加すべきか? ● 次ページへ

Slide 14

Slide 14 text

14 ● BizやPOが仕様を決めるなら ○ 開発は作ることに集中できる ○ 開発は作るだけに集中してしまう 要件と仕様で決めるべきこと

Slide 15

Slide 15 text

ステップ 4. 仕様からタスク 15 作るためのルールが決まったので、タスクに分割可能になります。 タスクに分割できると見積もれます。 見積もれるものはテストも可能になります。

Slide 16

Slide 16 text

16 仕様からタスクで決めるべきこと ○ 作業レベルのタスク分割 ● これが全部終われば次に進める ● タスクは個人レベルで管理されればよい ■ POはユーザーストーリーなどもう少し大きいレベ ルで確認 ○ 見積もられ優先順位が明確なタスク ● スケジュールができる ○ タスク分割に誰が参加すべきか? ● 作業する人 ● 作業する人からの質問に答えられるBizやPO

Slide 17

Slide 17 text

ステップ 5. タスクからデモ、リリース 17 完成したもののレビューとリリース判断。

Slide 18

Slide 18 text

ステップ 6. リリース後の フィードバックサイクル 18 ABテスト、問い合わせやレビューといったフィードバックのインプットへのつなぎ込み。

Slide 19

Slide 19 text

CREDITS - Special Thank! ○ Presentation template by SlidesCarnival and Photographs by Unsplash ● Photo by Randy Fath on Unsplash 19 お問い合わせは https://daipresents.com/service/ からお気軽にどうぞ。