アプリを短いスパンでアップデートしてリリースするためには

Slide 1

Slide 1 text

アップデートしてリリースするためには  YUMEMI.grow Mobile #7  アプリを短いスパンで  2023.10.11

Slide 2

Slide 2 text

2 自己紹介  古宮　伸久（コミヤノブヒサ）こみやん  業界  プロジェクト概要  役割・領域  生活協同組合  アプリリニューアル  技術、プロジェクト支援   人材サービス  アプリ継続開発・保守   技術、プロジェクト支援   ITサービス  アプリ継続開発・保守   技術、プロジェクト支援   小売サービス  アプリ継続開発・保守   技術、プロジェクト支援   ITサービス  アプリ継続開発・保守   技術、プロジェクト支援   iOS てっくりーど  ファイナンシャルプランナー    github.com/novr  twitter.com/novr  自動化  一汁三菜を作る  程度の能力  得意領域  能力  アライメント  秩序にして中立  直近の担当プロジェクト 

Slide 3

Slide 3 text

3 1. リリースとは  2. リリースには  3. 改善のために  目次 

Slide 4

Slide 4 text

リリースとは  - ユーザーへ価値を提供する  4

Slide 5

Slide 5 text

5 ユーザーへ価値を提供する  リリースとは 

Slide 6

Slide 6 text

6 LTV(顧客生涯価値)  リリースとは | ユーザーへ価値を提供する 

Slide 7

Slide 7 text

7 リリースとは | ユーザーへ価値を提供する  ベンダーとの取り組みにおける課題 - 誤ったスタート地点「何を作ろう」から始めることにより、ユーザーが不明瞭なまま開発に着手する。 - 誤ったベンダー選定コンペによるベンダー選定では企画ありきなことが多く、プロジェクト進行の詳細が詰まっていないことも少なくない。これにより、プロジェクト動き出してから、両社間でギャップが発生する。 - 「強み」が灯台下暗し自社の強みや価値がお互いに理解できていない。するとプロダクトにも活かせない。 - 不明瞭なプロセス「誤ったベンダー選定」により、プロジェクト進行が手探りの状態。問題が発生したときに、手戻りが難しい。 https://markezine.jp/article/detail/35043

Slide 8

Slide 8 text

リリースには  - 要件からリリースまで  8

Slide 9

Slide 9 text

9 リリースには | 要件からリリースまで  要件何を作るかを決めます。目標やユーザーストーリーから、それらを実現するための機能や制約を作り、優先順位付けをします具体的にどのように作るかを計画します。ユーザーインターフェースやデザイン、データの構造や関連性を考えプログラミング言語やフレームワーク、ツールを選択します開発されたアプリが設計と要件に適合し、ユーザーの期待に応えるかどうかを確認します。機能だけでなくユーザビリティ、セキュリティ、パフォーマンスの確認をしますアプリをユーザーに提供します。アプリストアへの提出、申請を行います。サポートやフィードバック収集、モニタリングを行い、定期的なアップデートを行います要件設計開発検証リリースプログラミング言語やフレームワークを使用してコーディングをします。ユーザーインターフェース、データ連携、アプリの機能を実装します

Slide 10

Slide 10 text

10 リリースには | 要件からリリースまで  設計何を作るかを決めます。目標やユーザーストーリーから、それらを実現するための機能や制約を作り、優先順位付けをしますプログラミング言語やフレームワークを使用してコーディングをします。ユーザーインターフェース、データ連携、アプリの機能を実装します開発されたアプリが設計と要件に適合し、ユーザーの期待に応えるかどうかを確認します。機能だけでなくユーザビリティ、セキュリティ、パフォーマンスなどの確認もしますアプリをユーザーに提供します。アプリストアへの提出、申請を行います。サポートやフィードバック収集、モニタリングを行い、定期的なアップデートを行います要件開発検証リリース具体的にどのように作るかを計画します。ユーザーインターフェースやデザイン、データの構造や関連性を考えプログラミング言語やフレームワーク、ツールを選択します設計

Slide 11

Slide 11 text

プログラミング言語やフレームワークを使用してコーディングをします。ユーザーインターフェース、データ連携、アプリの機能を実装します 11 リリースには | 要件からリリースまで  開発アプリをユーザーに提供します。アプリストアへの提出、申請を行います。サポートやフィードバック収集、モニタリングを行い、定期的なアップデートを行いますサブタイトル設計開発検証リリース要件何を作るかを決めます。目標やユーザーストーリーから、それらを実現するための機能や制約を作り、優先順位付けをします具体的にどのように作るかを計画します。ユーザーインターフェースやデザイン、データの構造や関連性を考えプログラミング言語やフレームワーク、ツールを選択します開発されたアプリが設計と要件に適合し、ユーザーの期待に応えるかどうかを確認します。機能だけでなくユーザビリティ、セキュリティ、パフォーマンスなどの確認もします

Slide 12

Slide 12 text

12 リリースには | 要件からリリースまで  検証具体的にどのように作るかを計画します。ユーザーインターフェースやデザイン、データの構造や関連性を考えプログラミング言語やフレームワーク、ツールを選択しますプログラミング言語やフレームワークを使用してコーディングをします。ユーザーインターフェース、データ連携、アプリの機能を実装します開発されたアプリが設計と要件に適合し、ユーザーの期待に応えるかどうかを確認します。機能だけでなくユーザビリティ、セキュリティ、パフォーマンスなどの確認もしますアプリをユーザーに提供します。アプリストアへの提出、申請を行います。サポートやフィードバック収集、モニタリングを行い、定期的なアップデートを行いますサブタイトル設計開発検証リリース何を作るかを決めます。目標やユーザーストーリーから、それらを実現するための機能や制約を作り、優先順位付けをしますサブタイトル要件

Slide 13

Slide 13 text

13 リリースには | 要件からリリースまで  リリース具体的にどのように作るかを計画します。ユーザーインターフェースやデザイン、データの構造や関連性を考えプログラミング言語やフレームワーク、ツールを選択しますプログラミング言語やフレームワークを使用してコーディングをします。ユーザーインターフェース、データ連携、アプリの機能を実装します開発されたアプリが設計と要件に適合し、ユーザーの期待に応えるかどうかを確認します。機能だけでなくユーザビリティ、セキュリティ、パフォーマンスなどの確認もしますアプリをユーザーに提供します。アプリストアへの提出、申請を行います。サポートやフィードバック収集、モニタリングを行い、定期的なアップデートを行います設計開発検証リリース何を作るかを決めます。目標やユーザーストーリーから、それらを実現するための機能や制約を作り、優先順位付けをしますサブタイトル要件

Slide 14

Slide 14 text

14 リリースには | 要件からリリースまで  アプリ検討時に確認が必要な項目アプリ（iOS/Android）の新規構築、機能追加を行う際に、確認・検討漏れをなくすためのチェックリストを使います

Slide 15

Slide 15 text

15 リリースには | 要件からリリースまで  アプリ設計事例設計や、実現の方法は様々ありますが過去に行った設計や問題の起こった事例などをナレッジとしてまとめています

Slide 16

Slide 16 text

16 リリースには | 要件からリリースまで  開発ツールソフトウェア開発プロセスを合理化し、開発チームの生産性を向上させることができます。自動化、文書化、デザインの一貫性などが効率的な開発を支えます。

Slide 17

Slide 17 text

17 リリースには | 要件からリリースまで  リジェクト事例・対応一覧 iOSやAndroidはリリースに向けて各アプリストアへ申請、審査が必要になります社内で集まったリジェクト事例や対応などをナレッジとしてまとめています

Slide 18

Slide 18 text

改善のために  - できること  18

Slide 19

Slide 19 text

19 改善のために | できること  フェーズ - ユーザーストーリー - 優先順位付け - 適切な要件設定 - 要件の変更管理 - アーキテクチャ設計 - プロトタイピング - ドキュメンテーション - プロジェクトマネジメント - テスト計画 - テスト自動化 - ユーザビリティテスト - リグレッションテスト - バグトラッキング - CI/CD - リリース管理 - バックアウト - ドキュメンテーション要件設計開発検証リリース - コーディング標準 - コードレビュー - ユニットテスト - CI/CD - バージョン管理

Slide 20

Slide 20 text

20 事件は何処でおこっている？  改善のために | できること 

Slide 21

Slide 21 text

21 改善のために | できること 

Slide 22

Slide 22 text

22 改善のために | できること  出典：実践ゲーム製作メモ帳 2＞メテオフォール型開発

Slide 23

Slide 23 text

23 改善のために | できること  出典：実践ゲーム製作メモ帳 2＞メテオフォール型開発

Slide 24

Slide 24 text

24 改善のために | できること  出典：実践ゲーム製作メモ帳 2＞メテオフォール型開発

Slide 25

Slide 25 text

25 推測するな、計測せよ  改善のために | できること  Rule 1. - You can’t tell where a program is going to spend its time. Bottlenecks occur in surprising places, so don’t try to second guess and put in a speed hack until you’ve proven that’s where the bottleneck is. Rule 2. - Measure. Don’t tune for speed until you’ve measured, and even then don’t unless one part of the code overwhelms the rest. 出典：Notes on Programming in C

Slide 26

Slide 26 text

26 改善のために | 指標 

Slide 27

Slide 27 text

27 改善のために | 指標 

Slide 28

Slide 28 text

28 改善のために | できること  問題をみつける  - 問題は何処でおこっている？    - レトロスペクティブ(振り返り会)  - 問題はありません問題    - 朝会    - 一人スクラム  - CI(Jenkins)おじさん  問題を見つけるには？  - 少し先の理想をイメージする  - 現状から理想をとらえる  - 理想と現状の差分を考える    - クリティカルシンキング    - 未来志向で現状をとらえる  今の日常が永遠に続くとは考えない 

Slide 29

Slide 29 text

29 改善のために | できること  フェーズ - ユーザーストーリー - 優先順位付け - 適切な要件設定 - 要件の変更管理 - アーキテクチャ設計 - プロトタイピング - ドキュメンテーション - プロジェクトマネジメント - テスト計画 - テスト自動化 - ユーザビリティテスト - リグレッションテスト - バグトラッキング - CI/CD - リリース管理 - バックアウト - ドキュメンテーション要件設計開発検証リリース - コーディング標準 - コードレビュー - ユニットテスト - CI/CD - バージョン管理うたがえ！