プロダクト開発の基本
https://gyazo.com/0f68643e6e77ea1d736c0295f41b6a1c https://www.freepik.com/premium-vector/development-team-member-scrum-master-working-agile-project-product-ownerand-stakeholders-agile_31529449.htm#query=product%20development&position=29&from_view=keyword&track=ais_hybrid&uuid=45dc10d0-21fa-439a-b25e-720be56f17e7
はじめに
--.icon
想定読者
開発者であるかどうか、は問わない（むしろ非Devメンバーにとっての情報がメイン）
スコープ
IN
プロダクト開発に関わる基礎知識
プロダクト開発を伴う案件の全体像
開発の大まかな流れと注意するポイント
OUT
Dev面での専門的な知識の全体像
プロダクトチームの定常的な運営フロー
ディスカバリーなどの全体的なPdMフロー
サマリー
プロダクト開発はざっくり分ければプロジェクトと保守開発があり、どちらもV字モデルに沿って進められる
V字モデルにはレイヤーがあり、同じレイヤーで品質保証を行う必要がある
プロジェクトは多数のステップと多様なステークホルダーと役割分担しつつ進める必要がある
保守開発はステークホルダーが少なく期間も短いことが多く、段階的に検証しながら問題の解消まで導く
開発を伴うプロジェクト
--.icon
プロジェクトの定義
独自のプロダクト、サービス、所産を創造するために実施される有期的な業務（PMBOKの定義） プロジェクト全体の流れ
https://gyazo.com/2be9f33eb5d197d73e25e74c9951ba84
V字の下（真ん中）に進むほど具体的になり、選択肢の不確実性が下がっていく
V字の左（前半）で企画・設計を進めていき、右（後半）でその検証（品質保証）をしていく 各レイヤー（戦略策定と価値検証など、V字の中で高さが同じ行）が対応関係にある
大枠の骨子として、どんな人的・資本的・時間的リソースをどこに割くか、何を捨てるか、方向性を決める
戦略策定で最終的にどのような価値を創出すべきかを定め、価値検証で結果的に創出できたのかを確かめる
そのプロジェクトが「なぜ今やるべきか（Why）」「どうなれば良いか（Goal）」を定める
企画・要求定義で解くべき課題と達成状態・制約を定め、受入テストで問題が解消されているかを確かめる
プロジェクトにおける要求を満たす上で求められる要素と概念、および運用との組み合わせを定める
システム要件定義・運用設計で要求に応えるモデルを定め、総合テスト・結合テストで実態と一致するかを確かめる
要件を満たすために必要なシステムのアーキテクチャや処理フローを定める
システム仕様定義で要件を実現するプログラムを定め、単体テスト・結合テストで整合性・網羅性があるかを確かめる
仕様定義や運用設計を満たしつつ、保守性や再利用性の高いシステムや運用を作り上げる
関係者とその役割
領域ごとの責務
https://gyazo.com/eb41770a498d59de23fb94b195d4404c
ロールごとの責務
PM(PjM) ：プロジェクト全体の結果に責任を持つ
Dev以外も含めて、プロジェクトを成功させる上で必要なことを全てやる
PL(x-PL) ：領域ごとのリードと成果への接続に責任を持つ
Dev（開発PL）・Design（デザインPL）・Ops（運用PL）など、専門知を集めて成功に繋げる
PMO ：プロジェクト推進のプロセスによるインパクトや再現性を高める
基本はPMが全体、PLが個別で推進していくが、切り出すことも可能
Dev ：技術やアーキテクチャの知見を集結し、開発面での課題を解決する
Design ：人間工学や体験設計の知見を集結し、デザイン面での課題を解決する
Ops ：ワークフローやプロセスマネジメントの知見を集結し、運用面での課題を解決する
Mkt ：人間心理や購買行動の知見を集結し、利用促進面での課題を解決する
Research：意思決定を定量的・定性的に支え、より精度と確度の高い示唆を提供する
PJT Phaseと中間成果物
https://gyazo.com/4e3207e1248142640e8f4c6e88bc64b5
ポイント
各ステップで完全に詰めつらないと次のステップに進められない訳ではない
プロジェクトでは不確実性を早期に下げることが鉄則であるため、やや不完全でも次ステップに進める場合がある 一方、言語化や分析など、本来やれば終わるはずの動きをせずに前へ進めようとするとリスクとコストが上がるため注意
3種類の見積もりを使い分ける
見積もりは目的によって求める精度や設定するラインが異なるため、使い分けなければ期待値がズレるため注意
品質保証のマネジメントはPMが責任を持つ
そもそも「プロジェクトを終わらせる」責務を持っているのはPM
プロダクトにおける保守開発
--.icon
保守開発の定義
プロジェクトよりも工期が短くステークホルダーも少ない ∧ 運用ではない（ソフトウェアに変更を加える）案件
有期的な業務であり、プロジェクトの定義にも入るが、業務上ではワークフローが異なることが多いため区別して扱う
関係者とその役割
企画者 ：依頼するメンバー。どんな問題に対してどんな課題を設定したいか、どうなれば良いかを定義する
ここでいう『企画』はV字モデルの企画（狭義）ではなく、要求定義〜要件定義のレイヤーを扱う広義のスコープ
設計者 ：依頼を受けるメンバー。課題をどのように解決するか、そのためにどう変更を加えるかを定義する
ここでいう『設計』はV字モデルの要件定義〜仕様定義を扱う。設計者はDevと兼任することもある
Dev ：実装するメンバー。企画や設計を踏まえて、ソフトウェアに具体的な変更を加えてリリースする
Design ：デザインするメンバー。企画や設計にデザイン要素を含んでいる場合は、デザインを変更する
保守開発の流れ
V字モデルで進んでいくことは変わらない
企画設計のROIや不確実性がプロジェクトより低く、プロダクトへの影響範囲が広くないため、内容は簡略化される
企画者が要求定義した上で、設計者やDesignと議論しつつ要件定義していく
何が解決すべき課題なのか整理した上で、仕様調査などで観点や制約を補足しつつ要件に落とす
設計者が要件定義を固めつつ、DevやDesignと議論しつつ仕様定義していく
アーキテクチャやインターフェースなど、仕様面での論点を解消しつつ実装を進める
複数メンバーによる複数観点でのレビューを通過した上でリリースし、本番環境で検証できれば完了
簡易なデモなどを見る要求レビュー、ソースコードなど詳細を見る技術レビュー、網羅的に見る最終レビュー
レビューを通過すればリリースを行い、リリース後に想定どおり使える・問題が解消していれば終わり
ポイント
解決策を依頼しない。必ず課題を抽出した上で、必要な場合に限り、あくまで一例として、解決策イメージを示す
想定される解決策に引っ張られず、課題を出した上で調査・探索しなければ最適な解決策は見つけられない
課題の背景には問題があり、問題は理想と現状から生まれている。問題を見極め、課題を設定した上で依頼する