進捗会議 の アジェンダ

今回は「進捗会議のアジェンダ」についてまとめていきたいと思います。

アジェンダの必要性

進捗会議に限らず、会議前にアジェンダを作ることで「会議の目的を共有して無駄をなくす」ことができるようになります。

アジェンダ作成するのも時間がかかりますが…アジェンダなしで会議を始めてしまうと「参加人数×会議が延びた時間」のコストがかかってしまいます。 面倒ではあるのですが、プロジェクト全体を考えるとアジェンダは作っておくべきな気がします。

進捗会議のアジェンダ

以下に記載している項目は進捗管理する上で確認すべき内容の一覧ですが、開発規模や開発フェーズによってアジェンダの内容は変わると思います。 「進捗」「品質」「課題」は進捗確認という意味で確認すべきポイントですが、これらは状況によってそれぞれ別会議を設けることがあるようです。

  • 連絡事項の共有
  • 進捗確認
  • 品質確認
  • 課題棚卸
  • 依頼事項の確認

以下では上記項目のそれぞれについて具体的な内容を見ていきます。

連絡事項の共有

主に、以下のような「外から入ってくる情報」を共有します。 また「チームへ向けた注意喚起、改善依頼」などもここで行います。

  • マイルストーン
  • プロジェクト全体にかかわるアナウンス
  • 他チームからの依頼事項
  • メンバーに向けた注意喚起

進捗確認

進捗会議のメインはこの項目だと思います。 計画されたガントチャート（現場では "WBS" と呼ばれることが多い？）に対して実績を確認し、遅延原因を特定、遅延対策を検討、その場で適用可能な対策であれば対策実施の依頼まで行います。

  • ガントチャート

品質確認

「品質レポート」とまとめてしまいましたが…設計フェーズであればレビュー指摘件数やレビュー指摘内容について確認します。 テストフェーズであれば一般的によく聞く信頼度成長曲線や機能別、要件別、混入工程別の障害件数などを確認します。 進捗確認と同じですが、状況確認したうえで、障害が多発している箇所もしくはまったく出ていない箇所について、その原因分析、改善対策の検討、改善対策の実施依頼まで行います。

  • 品質レポート

品質の分析について細かく行い始めるとこれだけでかなり時間がかかることがあるので、必要に応じて別会議を設定するなどの検討をしても良いと思います。

課題棚卸

「期日が切れてしまった」ものと、「実施する予定」のものの2種類を確認します。

  • 期日切れの課題
  • 1週間後が期日の課題

課題も品質と同じで細かく見始めると時間がかかりすぎてしまいます。 また、こちらについては関係ない人たちも巻き込んでしまう危険があるので、後で関係者だけを残した2次会を行うなどをその場で随時判断しながら進めると良いようです（←アジャイルなどの朝会ではこのようにするみたい）。

依頼事項の確認

各メンバーから「他チームへ向けて」や「リーダーに向けて」など「外側へ出ていく情報」について確認します。 これより前に確認している「進捗」「品質」「課題」を踏まえて何か他チーム依頼があれば、ここで整理するとよいと思います。

  • 他チーム依頼事項
  • 不在情報の共有

今回は「進捗会議のアジェンダ」についてまとめました。 「進捗会議のアジェンダ」としてまとめると以下の通りになります。

  • 連絡事項の共有
    • マイルストーン
    • プロジェクト全体にかかわるアナウンス
    • 他チームからの依頼事項
    • メンバーに向けた注意喚起
  • 進捗確認
    • ガントチャート
  • 品質確認
    • 品質レポート
  • 課題棚卸
    • 期日切れの課題
    • 1週間後が期日の課題
  • 依頼事項の確認
    • 他チーム依頼事項
    • 不在情報の共有

今回の記事はお役に立ったでしょうか？お役に立ったならぜひシェアを！！

参考記事

コメント

コメントを投稿

このブログの人気の投稿

進捗遅延 の 原因 と 対策

今回は「進捗遅延の原因と対策」についてまとめていきたいと思います。 「計画は正しい」ことを前提として、遅延原因をベースにその対策はどんなものが考えられるか、以下では具体例を出して見ていきます。 実務上は以下の内容が参考になるかと思います。 スキルミスマッチ 追加タスク発生 他チームタスク未完成 非効率なプロセス 非効率な環境 非効率なメンバー 投入工数不足 スキルミスマッチ アサインしたメンバーのスキルとタスク難易度が一致しないことに起因する遅延。 基本的な対応はフォローを入れて過勤務対応になりますが、これで対応しきれなければメンバーチェンジも考えます。 報告例 「初参画のため立ち上げに（予定以上に）時間がかかっている」 「見積もりが甘かった（思った生産性が出ていない）」 「（担当者スキルに対して）タスク難易度が高かったため」 「品質が悪く手戻りが発生している」 「レビューに時間がかかっている（指摘が多く発生して収束しない）」 対策例 1か月以内に解消が見込める場合 フォローメンバーをつける。 作業内容に関するガイダンスの実施する。 着手前にレビュアーないし詳しいメンバーに修正箇所の説明を行うようにする。 上記作業は追加作業なので過勤務対応とする（＝フォローするメンバーの行うタスクに対する投入工数が減ることがないようにする）。 1か月以上かかるタスクの場合 担当者を変更する。 追加タスク発生 計画時には見えていなかった課題が発見されたことによる追加作業（タスク）が発生したことに起因する遅延。 追加タスクによる遅延は様々な形の "遅延" で表れてくるため、報告も様々になります。 報告例 「他の優先度が高いタスク（課題、レビュー）を対応していた」 「原因不明のエラーが発生した」 「見積もりが甘かった（タスクの漏れがあった）」 「仕様未確定な箇所が見つかった」 「仕様変更が発生した」 「手戻りが発生した」 「残レビューのみです（＝レビュー実施ができていない＝他タスク（課...
続きを読む

はじめに

初回投稿なので、今回はこのブログを始めるにあたってどんなことを記載していくか…についてまとめておきたいと思います。 一言でいえば初心表明ですね。 いずれの項目も今までに書籍や勉強会で学んだ内容を踏まえて吐き出していきたいと考えています。 プロジェクト管理 一言で「プロジェクト管理」といってもその内容は多岐にわたります。 PMBOKで言えばスケジュール、スコープ、コスト、品質、人的資源、コミュニケーション、リスク、調達、ステークホルダー…など。 PMBOK とはいえ、机上の話だけでは面白くないので、もう少し実務よりな内容で記事を書けたらいいな、と考えています。 進捗定例（定例の運営、報告） WBS作成 問題解決 ロジカルシンキング プロジェクト管理の問題解決にも関係しますが、 「漏れダブり」なく考えられることは大切なことかと思っています。 ロジカルシンキングに関しては、一般的な話の組み立て方の考え方を中心に記事を書いていきたいと思います。 時間管理 最近は「業務効率化」などで話題ですね。 「業務効率化」と「時間管理」は密接な関係にある気がしています。 「効率化（＝生産性をあげる）」には自分の時間をいかにコントロールして生産性をあげるかを考える必要があると思っています。 書籍などから学んだこともそうですが、普段生活していて思いついた効率化があれば記事にしていきたいと思います。 クレーム対応 社外の人（お客様筆頭に協力会社など含む）を相手にするときだけでなく、社内でもチーム跨げば社外も同然なので、これも必要な知識な気がします。 数冊読んだ感じだと何かしらの法則はありそうなので、そこを記事にまとめていきたいと思います。 メンバー育成 プロジェクト管理に関連しますが、チームメンバーも集まりたては各人スキルいろいろなので、そこをそろえるためにも育てなければいけないと思っています。 世の中にはだいたい "基本" と呼ばれるものがあるんですね。 教育に関しても実際に書籍で学習したこと、それを適用してみてどうだったか、などを記事にしていきたいと思います。 今回は「このブログで書きたいこと」についてまとめました。ポイントは以下の通りです。 プロジェクト管理 ロジカルシ...
続きを読む