はじめに

この記事では、3月にリリース予定の「エンジニア人事制度ver1.1」のPJ過程について紹介します。前回の記事は以下をご参照ください。

エンジニアの人事制度について考える

プロジェクトの工程計画

本プロジェクトでは以下の工程を踏んで進行します。
今回は、プロジェクトでも特に重要な工程である「プレモーテム」に焦点を当てて、その詳細と成果を共有します。

キックオフ
プレモーテム ⭐️
マイスターエンジニア
マルチ・リードエンジニア
テックリード
リードエンジニア
サブリードエンジニア
内部レビュー
経営レビュー
説明会
ポストモーテム

プレモーテムの実施方法

プレモーテムは、プロジェクト開始前に潜在的なリスクを特定し、その予防策を検討する手法です。本プロジェクトではプレモーテムを2つのステップに分けて実施しました。

プレモーテム何それ？という方は、Google re:Workの以下記事をご参照ください。

イノベーションが生まれる職場環境をつくる

※プレモーテム用のテンプレートも配布されています。

ステップ1: 個人でのリスクや懸念の記載

各参加者は個別に潜在的なリスクや懸念を自由に記載します。このステップでは、どのようなリスクでも、たとえ非現実的であっても受け入れます。

※引用元：プレモーテム用のテンプレート

もし明日インターネットが使えなくなったら...もし会社が倒産したら...もし上司が怪物に喰べられてしまったら…
各自に発言の機会を与え、全員でチームのすべてのアイデアを共有します。他人のアイデアを批判せず、冗談が言える雰囲気が大切です。

ステップ2: リスク評価と対策

次に、記載されたリスクについて「影響度」と「発生頻度」を定義し、対応の優先度を決定しました。上位3〜5のリスクについては、具体的な対策を実施することになります。
よりそうでは、以下のようなフォーマットを作ってステップ1、2を運用しています。

プレモーテムで挙がった意見と対策

プレモーテムのセッションで特定された主要なリスク、その評価、および対策を以下に示します。

新規「プロジェクトマネージャー」等級の定義不明瞭さ（影響度: 高、発生度: 高）
- 対応優先度: 1
- リスクや懸念: 評価基準や目標設定の置き方などがちゃんと定義されておらず職務定義が浸透しない。
- 対応内容: 職務定義の明確化と周知。
評価基準と目標設定の不明瞭さ（影響度: 高、発生度: 高）
- 対応優先度: 1
- リスクや懸念: 現実との乖離から、ほとんど誰も見ることが無く、運用されない。
- 対応内容: 役割定義の明確化。

あがった意見はリスト化し、後から確認できるようにします。
プロジェクト終了後に実施するポストモーテム（PJ振り返り）の際に、プレモーテムで事前にリスクとして認識できていたかどうかで、プロジェクトの学びを多く得ることができます。

結論

プレモーテムは、リスクを事前に特定し対策を講じることで、プロジェクトの成功率を高める効果的な手法です。このプロセスを通じて、私たちは「エンジニア人事制度ver1.1」の開発をより効率的かつ効果的に進めるイメージをPJメンバー内で共有することができました。
実施する際は、経営メンバー、マネージャー、メンバーなど様々な役割のメンバーと実施をすることで、異なる視点を得ることができ、PJの成功率が飛躍的に向上します。

引き続き、働きやすい職場づくりのため、エンジニア人事制度の改定に取り組みます！