BSA
プロダクト開発プロセス：リリース1.0の作成 †
- プロダクト開発プロセスは、プロダクトに関する最も大きな俯瞰的視点である。
- プロダクト開発プロセス（Figure 2.1）はステージに分けられる。ここではPMとエンジニアリングだけを取り上げる。他の活動（ファイナンス、法務、QA、技術文書作成）も同様に重要だが、本書の範囲外。
- ここで想定される実際のPM、エンジニアリングチームの大きさは様々だ。2〜4人のプロダクトマネージャに対し30〜40人のエンジニアということもあれば、1人のプロダクトマネージャに50人のエンジニアが対応することもある。
- 仕事の配分も、PMとエンジニアリングとで異なる。初期フェーズでは、PMの方がエンジニアリングより多くの仕事をするだろう。それは、PMの初期の仕事は目に見えるものを作るからでもあるが、一番の理由はPMが初期に行った決定がプロダクトに大きな影響を持つからだ。
- 輝かしい巧妙なアイディア（bright clever ideas）からプロダクトは始まる。企業によっては、ここをアイディア出し（ideation）というサブプロセスに切り出しているところもある。
コンセプトの提案（Concept Proposal） †
- プロダクトを開発するために十分なモチベーションを確立する。少人数で、ビジネスとテクノロジの両方のデータで正当性を調べる。
プロダクトの提案／ビジネス計画（Product Proposal/Business Plan） †
- プロダクト提案書／ビジネス計画書は、プロダクトを正当化するための主要文書。ここは重要すぎるので、後で詳説する。マーケティングがビジネス計画を練っている間、エンジニアリングは何もしないこともよくある。
開発計画（Development Plan） †
- ビジネス計画承認後、2チームが協力して開発計画を練る。マーケティングは市場ニーズを明確化し、期待されるプロダクトのフィーチャに落とし込む。エンジニアリングはフィーチャ間の依存性調査、アーキテクチャ能力（capabilities）の特定、開発期間の粗い見積もり、必要なリソースの特定をする。マーケティングが必要に応じて、他のチームを巻き込む。
- このプロセスの成果物は、形式的なMRD（marketing requirements document）から非形式なユーザストーリまで。プロジェクト／チームのサイズ、プロダクトの複雑さに形式性の度合いを自然と決めさせるようにすること。重要なのは、開発チームが何をすべきかが明白に示されていること。
- この時点で、開発チームは分析、設計、等の他に必要な成果物も作る。選んだ開発プロセスやプロジェクトの性質によって、ここで何を作るかは変わる。様々なWebベースの共同作業用ツールを試してみることをオススメする（地理的に離れたチームの場合は特に）。
- CockburnのAgile Software Development（2002）がオススメ。この本では、設計ドキュメントを開発チームが生み出す「残りカス（residue）」として、この残りカスをいかに減らすかがポイント、と言っている。私の定義では、「開発チーム」には技術文書とQAも含まれることに注意！
- ちゃんとした開発組織なら、ここで開発を始める前に最終レビューをする。目的は、時間とコストの見積もりから、実現不可能ならプロジェクトを殺すかどうか判断すること。
開発（Development） †
- このステージで面白いのは、エンジニアリングがプロダクトを開発する一方で、PMはプロダクトリリース後のことを考え始めること。このステージの詳細は、既に他の本で論じられているから、ここでは触れない。
- モダンな開発プラクティスでは、システムのデリバリはカスケードまたはオーバーラップする。開発チームが開発を継続している最中にも、動作可能なシステムのバージョンがQA、技術文書、アルファテスター、主要顧客、他の関係者、へ配布されていくイメージ。
最終品質保証（Final Quality Assurance） †
- 様々な活動で構成されるが、基礎はテストにある。バグ傾向、バグ報告、既知の問題へのワークアラウンド、などのデータを元にプロダクトマネージャが、いつ、誰に出荷するかを決定する。
- ワールドクラスのQAマネージャだとビジネス戦略を理解して出荷の決断を助けてくれるが、そうでないならチームにビジネス課題について教育する必要がある。
- QAはテスト以外にも以下に貢献する：
- 合意された開発プロセスへのモニタリングと強制
- テストやその他のメトリクスの収集と公開
- 根本原因分析における開発者の支援
- サポートおよびサービス部門のワークアラウンドへの理解と顧客の問題の再現の手助け
- ソースコード管理システムと日次ビルドプロセスの管理
- テストを容易にするアプリケーション設計についての開発者への手助け
- 要求のテストという観点からの要求管理プロセスへの参加
- 上記は、最終品質保証に限らない。究極的には、QAがこれらにどこまで参加するかは、QAチームのスキルと経験次第。
- モダンな開発ではQAの参加が必然なので、最終品質保証が必要ないという意見もある。理論的にはその通りだが、実際はだいたい最終品質保証をやっていた。最終品質保証を自動化によって排除しようとするよりは、そのステージを活かそう。
コラム：QA自動化の死角に要注意（Beware of QA Automation Blinders） †
- TDDとテスト自動化で最終品質保証が不要と考える人たちもいるが、それは疑問だ。QA自動化の死角があるからだ。
- コピープロテクト機能における、MACアドレスによるフィンガープリント生成の話。
- マルチプラットフォーム開発の話。
- セキュリティの話。
プレローンチ（Prelaunch） †
- 場合によっては、このフェーズは最終品質保証と並行する。1つの特徴は、このフェーズからエンジニアリングの仕事が減り、PMの仕事が増える。エンジニアリングはサービスやサポートに仕事を引継ぎ、メンテナンス／新規開発用のソースコードを準備し、休む。PMはセールス向け資料の準備からアナリストへの説明まで、プロダクトの市場での成功に向けたあらゆる仕事をこなす。
ローンチ（Launch） †
- エンジニアリングは「ゴールデンマスター」作成を祝うが、PMはローンチイベントまでが仕事。やり方は、簡単なプレスリリースからPR専門業者によるスペシャルイベント開催までさまざま。このフェーズでは顧客にフォーカスしたモニタリングとフィードバックが重要。エンジニアリングはパーティから帰って来たら、それらに対応する。
メモ †
