[PM] （ウェブ）開発ミーティングの進め方（先方入り）

社内用のメモ。

開発を進めるにあたり、社内でも社外でも打合せをする必要があります。その打合せの進め方（ウェブ会議）に関してのメモです。Zoom, Google, MS Teamsを想定していますが、他のツールでも基本同じです。

# 開発ミーティングの目的
まずは、開発ミーティングの趣旨を再確認します。なんとなく定例で入っているからではみんなの時間も無駄になってしまいます。

このミーティングの趣旨は意図したものが**予定通りにリリース**されて、サービスが**一定の品質でローンチ**されることが目的です。ずっとオンスケかつ問題なければ毎度とてもスムーズなミーティングとなります。　目指すところはそこですが、当初想定していなかった要素があったり、事情が変わったりもありますので、この事に関して全員で同じ認識をもち、新しい着地点を議論し、承諾をいただく場所です。

**重要なので、もう1度**

1. **当初想定していなかた要素や事情が起きている**ことを**全員（少なくてもステークホルダーのみんな）**が**認識**する
2. 新しい着地点を議論または、あるべき**新しい着地点のロジックを説明**共有する。なんでそうなったかみんながわかるように。
3. **承諾をいただく**。ミーティングの後にチケットやメールなどでＯＫもらってもいいですが、とにかくＯＫをいただくのが目的。


# 事前準備
参加者にはカレンダーから招待メールを送っておく。大半の人はそのまま参加ボタンを押すと各々のカレンダーにスケジュールが設定されます。招待メールの中にアクセス方法を趣旨を明記しておくこと。

- 日時
- ウェブ会議URL
- 予定参加者
- 議題と趣旨、各議題で何分ぐらい使う予定なのかも記載しておくとよし。各議題にて、どう着地したいのかも記載しておくと、進めやすい。
- 前回ミーティングからのフォローアップ事項

この内容メールに記載する＋をBacklogのWikiにこの内容記載してURLを入れておく。当日はそのWikiを議事録として使います。

# いざ開始

いざミーティングの開始。ということで会議の5分前から始めます。

## 参加者の受入れ
ホストの場合は開始5分前に部屋を開けておく
画面共有をする場合は必要なファイルなどがあらかじめ開いてすぐに表示できるようにしておく。

開発ミーティングは開発側からの進捗共有。オンスケなのかそうじゃないのか。オンスケであれば、どうしてオンスケなのかも報告して納得していただく必要があります。

backlogなどで議事録を残す場合は、招待メールと同じ内容を記載して開いておくといい。画面共有したときに参加者全員が議題が見えている状態にしておくこと。

## 参加者が揃っているか確認。

揃っていて、スタートしてもOKなようであれば、**簡潔に今日の議題を説明**　これなしに始めると全体感つかめないので、ここから始めてください。他に追加したい議題がないかどうか確認しておくこと。 時間内にすべてが話し合えるように、時間配分をここで再度確認。後半の議題が時間がなくなるとかがないようにすること。　

:::note warn
進捗管理を行う人は、「あー」とか「えー」とか「うー」とか意味のない声を出さないように、単的に伝えるべきことだけ伝える。ゆっくりしゃべってもいいので、余分な音を出さない。
:::

## 使用しているファイル、議事録はどこに？

画面共有を行う際に、その時使っている資料がどこにあるのか参加している人たちは気になるところです。この議事録はどこどこにあります、ミーティングの後に送信します、このミーティングしようしているファイルはすべて○○に格納してありますなど先に言っておきましょう。

## 進捗報告

進捗の報告はできるだけ定量的に行うのがいいです。

リリースまでどれぐらいのタスクがあるのか。タスクの区分ごとに、共有すること。定例の場合は前回のミーティングと比較して何がどれぐらい動いているのか説明。

ガントチャートを使っているのであればここはガントチャートを使って説明。前回ミーティングからどこが変更されていて、ゴールまでどれぐらいなのかを説明。

PMの仕事は、**オンタイムにならないかもしれないリスクを洗いだし**て**先につぶしておく**事です。すべてがオンスケだからこのままオンスケといかないものです。リスクの高いタスクに関してはできるだけ細分化して追いかけましょう。

別ファイルでガントチャート管理している場合は、ミーティングごとにファイル名をつけて保存しておきます。前回のミーティングで使ったガントファイルはこれ、今回のミーティングで使っているガントファイルはこれ、と分けてみることができるように。

## 進捗具合に関して

進捗具合は25%,50%,75%,100%見たいにわかりやすく割っておきます。ここで、先方にこれれがどのように定義されているか事前に説明しておくこと。

要件まとめ、設計、実装、単体テスト、結合テスト、総合テストという具合に進めているとしたら、要件まとまったら設計できていたら25%、実装と単体テストが終わったら50％、結合テストまたは総合テストが終わったら75%、先方受入れで100%とします。この辺りの割り方は各PMにお任せしますが、先方が同じ認識を持っていることが大切です。私がこの割り振りをしている理由は各ステージにて他の人が確認できる状態にあるからです。プロジェクトの体制や内容によってアレンジしてください。

- 要件まとめて設計ができたら、確認してもらい25％、
- 実装が終わり、単体テストがおわったら、ビルドできて、単体テストケースがパスできていることを確認して50%、
- 問題なく結合できて、総合テストケースにある通りに動いていたら実装問題ないということで75%、
- あとは先方がテストできる環境において、受入れしてもらったら100%としています。

## 手戻りに関して

たいていのタスクは手戻りを含めて計算しません。あるとしたらバッファーと呼ばれる部分かもしれませんが、すべてにバッファーをもつ工数の見積もりは正確度にかけます。なので、やはり手戻りが起きないのがベストです。

後半になればなるほど手戻りが発生しやすくなります。特に結合テストぐらいになるとテストがうまくいかなくて手戻りなどが発生しやすくなります。手戻りを発生させないためには、***とにかく単体テストでつぶしておく***ことです。そして、要件定義と設計に漏れがないように入念に確認をすることです。発生する***手戻りは進捗の後半のほうにありがちですが、その原因となる種は前半にあり***ます。

また、タスク前半部分での手戻りは挽回しやすいですが、後半になればなるほどスケジュールの再調整が難しくなります。

最終的に手戻りが発生しないように、このミーティングを活用してリリースされるものが意図したものであることをコミュニケーションとってください。

# 前回ミーティングからのフォローアップ事項

多くのミーティングで新し確認事項やら、タスクが発生します。その際には次のミーティングで進捗を追いかけられるようにフォローアップタイムを設けておきましょう。長期化するようであれ通常タスクとして進捗を追いかけましょう。

前回のミーティングで話にあがりました○○に関して、今はこんな状況です 
OR
前回のミーティングで話にあがりました○○に関して、このように解決しました

みたいな報告を入れてください。

# ミーティングが早く終わりそう

会議が予定よりも早く進行して予定時間よりも早く終わりそう。こんなときはとっとと終わりにしましょう。1時間のミーティングだから1時間使う必要はないとおもいます。予定が1時間なだけで早く終わる分にはＯＫです。毎度早く終わるようであれば、そもそも予定している時間の短縮を提案しましょう。

# ミーティングの終わりに

このミーティングで発生した追加事項をおさらい
次回のミーティングの時間・場所

# ミーティング後（フォローアップミーティング）

ウェブ会議の時代では会議が終わるとそこで通信がきれて会話がなく、短い時間でいいのでフォローアップミーティングを持つことをお勧めします。たとえば1時間の会議するなら、1時間会議の15分フォローアップで、内部のメンバーの時間は1時間15分とっておきます。

リアル会議だと、会議室を出ながらとか、必要な人を呼んでフォローしたりとありましたが。ウェブ会議は、ミーティング終わった瞬間にみんな別の世界にいるので、散らばる前にPMから指示を出します。特にミーテイング内で発生した新しいタスクなどは誰にアサインするのかフォローアップミーティングで決めてください。

# フォローアップ: メインPM

メインPMの場合は、フォローアップミーティングが終わったら、次回のミーティングの議題を下記始めましょう。まだ全部埋まらないかもしれませんが、今の段階で考えられることを一旦箇条書きで書いておきます。また脳がミーティングマインドのうちにとりあえず書いておいて、そのあとひと休憩したら再度書き始めます。　

# フォローアップ: アシスタントPM

フォローアップミーティング終了から30分以内に、議事録を皆さんに送ってください。とりあえず、その時点できれいにしたものを送ってください。　次回のミーティングの時間とURLも含めて送ってください。