新機能開発の成功/失敗をわける「最初の5日間」の使い方
プロダクトマネージャーのたけまさです。
新機能開発の1週目に何をすれば、
齟齬のない共通認識が作れ、
開発を生産性を高く進められるか？
というトピックです。開発規模は2ヶ月以上を想定。
キックオフから1週間後にチームで３つの共通認識ができている状態を目指しましょう。チームが解決する課題の全体像をつかむことが目的です。
①「誰の何の課題を解決するのか？どのように解決するのか？」の共通認識
②課題解決に関わるステークホルダーとそれぞれの行動の共通認識
②複数競合サービスを比較して、共通機能と固有機能の共通認識
具体的に何をやるべきか？
この3つがおすすめです。作成者はプロダクト成果責任をもつPdM/PO。
または要件作成の役割を担う方です。
①Mini Spec（要件定義書）の作成
②サービスブループリントの作成
③競合プロダクトの機能比較書の作成
検証過程で新しい事実がたくさん手に入るので、何度も更新するものと割り切りが肝心です。早期に一度結論を出して開発方針のスタンスを明確にすることが重要です。
1つ目：Mini Specについて
①Mini Spec（要件定義書）の作成
・目的：これから解決する課題・手段・進め方の見える化
・成果物：解決すべき課題、ユーザーストーリー、KPI、費用対効果、リリーススケジュール、ステークホルダーごとの調整内容、参考資料など
・注意点：開発規模に応じて内容の厚みは変わる。開発するプロダクトに関する情報が１箇所にまとめたHubとなるドキュメント。随時更新。
※ Mini Specとは...ラクスルCPO（@mizushimac_r）がペロリblogで紹介した開発要件の作り方のこと。造語。ググっても原本存在せず。クラウドワークスの方が書かれた以下ブログに詳しい。
2つ目：サービスブループリントについて
②サービスブループリントの作成
・目的：ステークホルダー、プロセス、オペレーションの見える化
・成果物：課題のステークホルダーと各オペレーションをまとめた1枚図
・注意点：きれいな図の作成が目的ではないので、時間の使いすぎに注意。ステークホルダーごとのシーケンスが１枚にまとまった簡素な図で十分。課題に応じて図にする内容はサプライチェーン、バリュチェーン、業務フローなど適切なプロセスを見える化する。デザイナーと作ってもよい。
超絶長いバリューチェーン、大量のステークホルダー、それぞれに複雑なオペレーションが存在するDX系プロダクトの開発でその効果を発揮します。
最初は現状把握を目的に事実ベースで作成するのがおすすめです。
最初に理想で作成すると、ステークホルダーとタスクに抜け漏れが発生して地獄になります。それを防ぐためのサービスブループリントです。
3つ目：競合の機能比較表について
③競合の機能比較表の作成
・作成目的：車輪の再発明の防止。要件作成の時間短縮。
・成果物：共通と固有の機能を切り分けたユーザーストーリーのリスト
・注意点：競合サービスの機能調査とユーザーストーリーのバックログ作成をかねると効率が良い。デザイナーに担当してもらうと、UIまで概ね頭にいれてくれるのでさらに生産性あがる。
複数サービスを調査したら、記述するユーザーストーリーには「共通と固有」の内容が存在することに気がつきます。共通のユーザーストーリーは必須機能、固有のユーザーストーリーがサービス特性を示しています。
GAFAは必ず調査する
似た機能がGAFAにあれば必ず調査しましょう。彼らは世界で一番豊富な資金と優秀な人間を集めてPDCA回しています。圧倒的多数のインターネット体験は彼らのサービスを通して学習されます。
類似サービスが存在しない場合は簡単などの"操作性"や"ターゲットユーザー"など軸をずらして調査をおすすめします。
ユーザーはすでに理解していることを手がかりに、新しい理解を手に入れます。新しい体験に挑戦するサービスでも、ユーザーが理解の階段を登るために何が足がかりになるのか？は比較作業で手に入れることができます。
これらのドキュメント作成のコツ
この3つの共通認識を5日間で終わらせましょう。
最初の20%の時間で、課題の構成要素の主要80%を押さえるイメージです。
まだ誰も手に入れていない事実を、まずはチームで見える化しましょう。
5日で作成するドキュメント作成のコツ
・最初に100%を目指すのではなく、すべて60%程度で手元にある状態
・プロジェクト進捗と共にドキュメント内の情報粒度も細かなるイメージ
・お作法どおりのドキュメント作成が目的ではない、事実の獲得が目的
2週間目に何をする？
1週間目に課題の全体像と解決策の方向性がざっくり見える化できました。
2週目からはそれを磨き込むプロセスです。仮説を事実に変えましょう。
誰と何を磨き込む？
with ビジネス：課題解決の松竹梅プランのビジネスインパクトの試算
with エンジニア：バックログベースで松竹梅のプランの見積もり作成
with デザイナー：松竹梅プランの理想の解決策やプロセスの作成
with ステークホルダー：3ドキュメントを彼らの視点でFBと改善 など
参考記事
それ全体の開発プロセスについてはこの記事で解説しています。
さらに生産性を高めるためのプロダクト開発の注意点はこちら。
この記事が気に入ったらサポートをしてみませんか？