こんにちは。Engineering Manager の @wozaki です。
2年前のプロジェクトで、プレモーテム(premortem)を実施した例をご紹介します。
プレモーテムとは、プロジェクト初期にチームで集まり「プロジェクトが失敗したとして、その失敗とは? 原因は? どう対策するか?」を話し合うワークショップです。*1
なお、本記事におけるリスクの定義はこちらです。
- 将来起こりうる出来事で、望まない結果を生むもの
- 望まない結果そのもの
目次
- 概要
- 背景
- なぜプレモーテムが打ち手だったのか
- プレモーテムの再設計
- 実施結果
- 参加者の所感
- 最終的にプロジェクトはどうなった?
- 終わりに
概要
- プロジェクトは2つの特性があった
- 初めて協業するステークホルダーが多い
- 開発規模が大きい
- 特性に対する懸念の打ち手としてプレモーテムを採用した
- 各メンバーの視点からリスクを発見し、チーム全体で認識を揃える
- リスク発見と対策検討を序盤に持っていく
- 結果
- チーム全体で重要視するリスクが可視化され、対策のアクションにつながった
- プロジェクト中盤でも再実施すれば良かったかもしれない反省がある
背景
なぜプレモーテムを実施したのか、プロジェクトの特性、特性に対する懸念、対策方針からお伝えします。
下記表がサマリです。特性の捉え方は、あくまでも弊社における過去プロジェクトとの比較になります。*2
| プロジェクトの特性 | 懸念 | 対策方針 |
|---|---|---|
| 1.初めて協業するステークホルダーが多い | 他メンバーが何をリスクに思っているか不明 | 各メンバーの視点からリスクを発見し、チーム全体でフォローできるようにする |
| 2.開発規模が大きい | リスクを多分に含んでいる可能性が高い | リスク発見と対策検討を序盤に持っていく |
特性1: 初めて協業するステークホルダーが多い
10部署以上、25人以上でした。 部署内訳は、コンテンツマネジメント、デザイナー、TPM、QA、事業企画、マーケティング、Data Engineer、Native Engineer、Backend Engineer、Web Engineer などです。
また、本プロジェクトから初めて協業するメンバーが一定いました。 とりわけコンテンツマネジメント部には初めて協業するメンバーが多かったです。 これまでコンテンツの構造を変える改修はほぼ無かったため、コンテンツマネジメント部と Engineer は協業する機会は少なかった経緯があります。
懸念と対策方針
特性1を踏まえて、以下の懸念が出てきました。
- 他のメンバーが何をリスク・不安に思っているのか?
- 自分の部署で許容していたリスクが、他部署にとってはリスクかも? *3
そのため、各メンバーの視点からリスクを発見すること、リスクの温度感の認識をチーム全体で合わせることが必要であると捉えました。
特性2: 開発規模が大きい
上記ステークホルダーの人数で、開発期間が約1年でした。
懸念と対策方針
開発規模が大きく、リリースまでに時間がかかるほど目的不確実性*4を抱え込むことになります。 また、開発規模が大きいほど、どのように作るか不安など方法不確実性が高まります。
つまり様々なリスクを既に内包しているといえます。
ところで、プロジェクトを円滑に納めるのは難しいと毎回思っています。 とりわけプロジェクト終盤に新たに発覚するリスクには悩まされてきました。 期日が迫った終盤だと打つ手が制限され、応急処置が別のリスクを生み出すこともあった気がします。
そのため、プロジェクト序盤からリスクを発見し管理できている。終盤は落ち着いてリリースを迎える。今度こそ、そんなプロジェクトにしたいという思いでした。
なぜプレモーテムが打ち手だったのか
懸念対策の打ち手に、プレモーテムを選定した理由を説明します。
プレモーテムを知った経緯は?
Google re:Work からプレモーテムを知りました。調査を進めるうちに、 チームとともにプロジェクトのプレモーテム演習を行う方法 | Atlassian を発見しました。
それぞれの記事からプレモーテムの目的を確認し、前述の懸念を解決できると考えました。
- このようなディスカッションを通じてオープンに話す機会を持つことで、失敗はつきものであると認識し、実際の失敗に備え、学びを得ることができます。
- プロジェクトのリスクと機会を視覚化し、それをいかに回避 (または対処) するかの対策を立てます。*5
類似の活動は?
ポストモーテム
ポストモーテム ( postmortem ) は、実際に失敗した後から学ぶための取り組みです。今回は失敗前に学びを得たいので採用しませんでした。 弊社におけるポストモーテムの取り組みは @chaspy の 障害対応とポストモーテム を参考にしてください。
インセプションデッキの「夜も眠れなくなるような問題は?」
インセプションデッキとは、プロジェクトの全体像を捉え、メンバーが同じ認識行動するためのドキュメントです。*6
10個の質問と答えから構成されており、質問の一つに「夜も眠れなくなるような問題は何か?」があります。 その質問にチームで回答する際にプレモーテムを活用するといいかもしれません。
プレモーテムの再設計
設計のベース
前述の記事を参考にしました。ドキュメントのテンプレートが参考になるかもしれません。
カスタマイズした点
まずは実験的に @tricknotes さんと二人で実施しました。*7
参考記事の手順をベースとし、時間配分や詰まったポイントをカスタマイズすることにしました。
| 詰まったポイント | カスタマイズ |
|---|---|
| 手順が多い。詰まる | ファシリテーターを用意し、タイムキープや手順説明を行う |
| 期待するゴールが分からない | 最初に実験結果のアウトプット見せる |
| リスクの粒度迷う | 後手順でグルーピングするので、粒度は気にせず出すように伝える |
| プロダクトリリースのみに集中してしまう | リリース後3ヶ月を期間と提示し、運用後の世界にも思いを馳せてもらう |
実験を踏まえた設計
実験を踏まえて設計したものがこちらです。
- ドキュメント: ホワイトボード、付箋
- コロナ渦前の2019年の実施で、当時はオンラインワークショップの知見がほぼ無かったので、ホワイトボードと付箋が常套フォーマットでした*8
- グループ構成: 協業機会が多い部署5人程度
- 一人が十分に発言できる人数にする
- 限られた時間で具体的な会話をするにあたって、文脈が共有されている必要がある。まとめを他グループに発表する機会は設ける
- グループ
- コンテンツマネジメント: 5人
- デザイナー、PM: 3人
- 事業企画、マーケティング: 3人
- Native Engineer: 4人
- Web Engineer、QA: 5人
- 役割: ファシリテーター2人、その他は参加者
- 対象期間: プロダクトリリース後3ヶ月まで
- リスクだけじゃなくて成功も出す
- 成功を考えることで、成功に至らないリスクを想起する
- 成功/リスクを想起するための質問集
- 成功
- プロジェクトが圧倒的な成功を収めたとしたら、どのような状況ですか?
- リスク
- 仕事が遅れたり、リリースの期限に間に合わなくなる原因として何が考えられますか?
- 既にどのような不安を感じていますか?
- 過去のプロジェクトで、どこに盲点がありましたか?
- 誤った方向に進んでいるとき、どれだけ迅速に対応できますか?
- 最大のリスクエリアはそれぞれ、誰が担当できますか?
- 成功
- 時間割
- 休憩含めて90分。詳細は後述
時間割
| 時間(分) | やること | 担当 | 備考 |
|---|---|---|---|
| 0~5 | 目的とやり方を説明する | ファシリテーター | 実施例から最終アウトプットのイメージを掴む |
| 5~15 | 成功/リスクを付箋に書き、ホワイトボードに貼る | 各グループ | - 後工程でグルーピングするので、粒度は気にせず思いつくままに出す - 詰まったら、成功/リスクを想起できる質問集を見る |
| 15~25 | グルーピングし、因果関係を書く | 各グループ | 因果関係を書く中で思いついたら追加する |
| 25~35 | 他グループの成功/リスクに、それぞれ3つずつ印を付ける。(投票する) | 個人 | 成功: 実現可能性がある&影響度が高い リスクが高い: 発生確率が高い&影響度が高い |
| 35~40 | 休憩 | ||
| 40~50 | 投票上位3つ以内の「リスク」に対する取り組みを議論する | 各グループ | 振る舞いでもok。具体的なアクションになると尚良い |
| 50~60 | 投票上位3つ以内の「成功」を実現するための取り組みを議論する | 各グループ | |
| 65~90 | 重視している成功/リスク/対策を、全体に向けて発表する | 各グループ |
実施結果
各グループ毎の実施結果です。 MAI とは本プロジェクトの名前です。
| コンテンツマネジメント | デザイナー、PM | 事業企画、マーケティング | Native Engineer | Web Engineer、QA |
|---|---|---|---|---|
 |
 |
 |
 |
 |
リスクと対策例
数点ピックアップしました。
| リスク | 対策 |
|---|---|
| プロダクトの価値が不明瞭。開発投資したが需要がない | - 価値を整理し、全チームで共通認識を持てるようにする - 価値を検証する方法、必要最小限の価値を小さく作っていく方法を検討する - コンテンツの理想形は持っておくが、優先度をつけて初年度は落とす勇気を持つ。落とした後のリカバリープランを検討する |
| コンテンツのデータ構造が複雑で、コンテンツマネジメントチームが管理できない | - コンテンツマネジメントチームだけでなく、Engineer も交えて管理方法を検討する - 定例でコンテンツマネジメントチームの課題を継続的にヒアリングする |
| バグにより運用が回らない | 小さく開発して、小さくテストする。初期フェーズから QA と一緒に取り組む体制構築する |
参加者の所感
プレモーテム実施後、参加者でプレモーテム自体の振り返りを行いました。
良かった
- 全チームがプロダクトのコンセプトに対して何らかのリスクを感じていることが分かり、今決めなきゃいけないことが改めて明確化されたと気づけた
- 他職種が感じているリスクの温度感を知ることができた
- 小さく作っていくことが Engineer だけでなく、コンテンツマネジメントチームにとっても重要なTRYだと分かった
- リスクを言語化してアウトプットすることで個人のモヤモヤを発散できた
- 普段関わることが少ない方々の意見を聞けた
- トップダウンでプロジェクトの成功リスクを提示されるよりも納得感がうまれた
課題
- 結果だけでなくてどんな会話がされていたのかも知りたい気持ちになった
- 背景や詳細を知らないので、「そうなんだ」でとどまってしまう
- 時間が足りず、ワークショップ内で、全グループ横断での最大成功、最大リスクをピックアップして、目線合わせできなかった
- 「うまく言語化できていないけど重要なリスク」がスルーされてしまう可能性がある
最終的にプロジェクトはどうなった?
勘のいい皆様はお気づきかもしれませんが、本稿は過去プロジェクトを対象としているので結果が出ているのです。
結果、諸手を挙げて万事大成功!!! ...とはなりませんでした。 その後、プレモーテムで挙がったリスク以外も出てきたり、いくつかの方針転換を経て落ち着いた形となりました。
振り返ってみて
課題の理解が進み、新たな課題が生まれつつある中盤に改めてプレモーテムを実施してもよかったかなと思います。 実施した方がいいという意見もあったのですが、全チームが忙しそうなときに開発を中断することに躊躇しました。。
熊とワルツを - リスクを愉しむプロジェクト管理 には、中盤こそ積極的にリスク管理を行う必要があると記載があります。
プロジェクトが道筋を逸れるのは中盤ごろが多いため、そのときにこそ積極的にリスク管理を行う必要がある。問題の原因は、たいていもっと早い時期に発生しているが、問題を認識するのはプロジェクトの中盤ごろからである。それまでプロジェクトはスムーズに進んでいると思っていたのに、何もかもおかしくなってくる。プロジェクトのこの段階を「天罰期」と呼びたい。計画不足、作業の見落とし、不完全な関係づくり、隠れた仮定条件、幸運への過度な依存といった過去の罪が我が身にふりかかってくる時期である。
終わりに
プロジェクトには大小なりのリスクが必ずあります。 *9 *10
また、ステークホルダーが増えるほど、彼/彼女らの視点でのリスクが増えますし、おそらくみんな不安です。
リスクはあるものとして能動的に関わり、チームで認識を合わせて対策を進めることで リスクを愉しむ ことができるのかもしれません。
この記事が我々と同じくチーム開発をする方の一助になれば幸いです。
Quipper では積極採用中です!
- 詳細聞きたい、知見共有したいなどあれば、お気軽にWantedlyからカジュアル面談をご応募ください！
- 選考プロセスへ進みたい場合は https://career.quipper.com/jp/ からご応募お願いします！
*1:Gary Klein 氏によって設計されました https://hbr.org/2007/09/performing-a-project-premortem
*2:類似した特性のプロジェクトの不確実性との戦いは @ohbarye による 新メンバーが多い大型プロジェクトでの不確実性との戦い方 も参考になります。
*3:自分の部署、他部署と感じていること自体が壁があるし、チームとしてプロジェクトの共通認識がでてきていない兆候かもしれない
*4:プロダクトがマーケットに受け入れられるか分からない不安のこと。方法不確実性についても エンジニアリング組織論への招待 から引用
*5:Atlassianの記事は2年前と内容が変わっているため、この文言は存在しない
*6:Jonathan 氏のブログ The Agile Inception Deck 参考
*7:あたかも tricknotes さんが現在も在籍しているようですが、本記事投稿日現在は 株式会社アンドパッドに在籍しております 。
*8:今では弊社の リモートワークの記事 もちらほら出てきました
*9:プロジェクトの本質とはなにか で「不確実性のない仕事はプロジェクトではありません。不確実性がなければ、プロジェクトとして立ち上げる価値が生まれないからです。」という記載があります
*10:Design It! “構築する価値のあるソフトウェアには、リスクがつきまとうものだ。新しいプロジェクトの開始時には、多少でも居心地の悪さを感じなくてはならない。”
