プロダクト開発概要(非エンジニア向け)

下記イベントで医師向けにプロダクト開発業務の概要についてお話しました。
https://docsfjapan2023.studio.site/12#meetup-top

その時の講演資料になります。

Transcript

1. プロダクト開発概要
2. 講演の目的 皆さんが抱えている課題をエンジニアに相談しやすくなる プロダクト開発業務の概要を理解
3. Agenda ITプロダクト概要 プロダクト開発の流れ エンジニアとの協業で意識していること
4. 01 ITプロダクト概要
5. ITプロダクトにはどんなものがある？ • Webサイト(ホームページ ) • Webアプリ(Amazon) • スマホアプリ (Facebook, X) • IoT(Amazon Echo, スマート家電 ) 下記はプロダクトの一例
6. ... データベース Web サーバー API サーバー アプリケーションが動く仕組み クライアント サーバー リクエスト レスポンス 機械学習 サーバー 多くのアプリケーションがサーバークライアント方式 で動作している
7. アプリケーションが動く仕組み クライアント リクエスト レスポンス スマホアプリ プログラム ... データベース Web サーバー API サーバー サーバー 画面描画 プログラム データ処理等 プログラム 機械学習 サーバー 機械学習 プログラム
8. ... データベース Web サーバー API サーバー アプリケーションが動く仕組み クライアント サーバー リクエスト レスポンス 画面描画 プログラム データ処理等 プログラム スマホアプリ プログラム 機械学習 サーバー 機械学習 プログラム iOS/Android エンジニア フロントエンド エンジニア サーバーサイド エンジニア 機械学習 エンジニア インフラエンジニア
9. プロダクト開発の流れ 02
10. Client プロダクト開発工程 KOTO Creative Society 1. 企画 2. 要件定義(細かい挙動の定義) 3. 設計 4. 実装 5. テスト 6. リリース 7. 保守運用
11. Client KOTO Creative Society プロダクトの企画 誰をどんな方法 でどんな状態 にしたいかを定義 ※1 引用: プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで, 及川卓也 他 図1: バリュー・プロポジションキャンバス(※1) プロダクトマネージャー 望み、期待するもの 仕事達成の障害
12. Client KOTO Creative Society プロダクトの企画 最小限の機能を持つプロダクト(MVP: Minimum Viable Product)を定義 プロダクトマネージャー 目的 • できるだけ早くリリースしてユーザーの反応を確認し、仮説検証を行う • 仮説の妥当性を確認した上で開発を進めることで、無駄な開発コストを削減 判断基準 • 最も検証したい仮説は何か？それに必要な機能か？ • その機能を削除するとユーザーがプロダクト価値を感じなくなるか？ • 適切な開発工数であるか？ etc
13. Client KOTO Creative Society プロダクトの企画(機械学習プロダクト) 機械学習プロダクトの場合は追加で下記も検討 プロダクトマネージャー 学習データ 必要な精度 運用コスト AI訓練用データが質・ 量ともに十分か 100%正確なAIは実装 できない 計算コストが高くGPU が必要。クラウド料金 が高騰する
14. Client KOTO Creative Society 要件定義 プロダクトに求められる具体的な機能を定義 エンジニア/プロダクトマネージャー Facebook投稿画面(※2) ※2 引用: https://www.facebook.com/?locale=ja_JP • 機能要件 ◦ ユーザーに提供すべき動作 ▪ 投稿文字数上限 ▪ 0文字での投稿可否 ▪ 使用できる文字種 ▪ 投稿画面に表示する文字数 ▪ エラーとする条件 等 • 非機能要件 ◦ システム品質として求められる動作 ▪ バックアップ ▪ システムログ ▪ セキュリティ 等
15. 設計/実装 デザイナー/エンジニア Figmaによる画面デザイン(※3) ※3 引用: https://www.figma.com/ja-jp/blog/our-approach-to-designing-ui3/ • 外部設計 ◦ 利用者側から見える部分の設計 ▪ 画面設計　等 • 内部設計 ◦ 開発者がプログラムを作るための設計 ▪ データベース構造 ▪ プログラムの処理の流れ　等 • 実装
16. テスト エンジニア Client KOTO Creative Society 単体テスト 結合テスト システムテスト プログラムを役割ごとにわ けた部品で検証 複数のモジュールが連携して正 しく動作するか検証 モジュール INPUT OUTPUT モジュール モジュール システム 全体 システム全体として期待通りの 動作をするか検証
17. 保守運用 エンジニア Client リリース後も下記メンテナンスを実施 • 異常監視 ◦ ツールを用いて以下を監視 ▪ エラー発生 ▪ サーバーの停止 ▪ コンピューターリソースの過剰負荷 • バグ修正 • セキュリティパッチ/バージョンアップ • 機能修正/機能追加　等
18. エンジニアとの協業で 意識していること 03
19. エンジニアとの協業で意識していること Client • 企画段階からエンジニアを巻き込む ◦ プロダクト開発の背景(対象ユーザー像, 解決したいペイン等)を理解してもらう ▪ エンジニアが要件定義等で背景を考慮してプロダクトの詳細を検討できる ▪ エンジニアから工数感の助言をもらえる • 開発を丸投げしない ◦ 開発業務を理解しようとしない企画者は協力を得にくい ◦ 外注する場合も開発業務を理解していないと下記リスクがあります ▪ 相場よりも高い費用を請求される • 要件定義の精度の甘さ等も原因 ▪ 想定と異なる要件のプロダクトが納品される