mng-teq

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

今回は「進捗会議のアジェンダ」についてまとめていきたいと思います。 アジェンダの必要性 進捗会議に限らず、会議前にアジェンダを作ることで「会議の目的を共有して無駄をなくす」ことができるようになります。 アジェンダ作成するのも時間がかかりますが…アジェンダなしで会議を始めてしまうと「参加人数×会議が延びた時間」のコストがかかってしまいます。 面倒ではあるのですが、プロジェクト全体を考えるとアジェンダは作っておくべきな気がします。 進捗会議のアジェンダ 以下に記載している項目は進捗管理する上で確認すべき内容の一覧ですが、開発規模や開発フェーズによってアジェンダの内容は変わると思います。 「進捗」「品質」「課題」は進捗確認という意味で確認すべきポイントですが、これらは状況によってそれぞれ別会議を設けることがあるようです。 連絡事項の共有 進捗確認 品質確認 課題棚卸 依頼事項の確認 以下では上記項目のそれぞれについて具体的な内容を見ていきます。 連絡事項の共有 主に、以下のような「外から入ってくる情報」を共有します。 また「チームへ向けた注意喚起、改善依頼」などもここで行います。 マイルストーン プロジェクト全体にかかわるアナウンス 他チームからの依頼事項 メンバーに向けた注意喚起 進捗確認 進捗会議のメインはこの項目だと思います。 計画されたガントチャート（現場では "WBS" と呼ばれることが多い？）に対して実績を確認し、遅延原因を特定、遅延対策を検討、その場で適用可能な対策であれば対策実施の依頼まで行います。 ガントチャート 品質確認 「品質レポート」とまとめてしまいましたが…設計フェーズであればレビュー指摘件数やレビュー指摘内容について確認します。 テストフェーズであれば一般的によく聞く信頼度成長曲線や機能別、要件別、混入工程別の障害件数などを確認します。 進捗確認と同じですが、状況確認したうえで、障害が多発している箇所もしくはまったく出ていない箇所について、その原因分析、改善対策の検討、改善対策の実施依頼まで行います。 品質レポート 品質の分析について細かく行い始めるとこれだけでかなり時間がかかること...

今回は「進捗会議」の中でもその「目的」についてまとめていきたいと思います。 毎日、毎週…繰り返していると定型作業のようになってしまってその目的が分からなくなってくる人が出てきたりします（自分も含めて。。）。 どんな会議もそうですが「目的」意識がズレてしまうと無駄な会議となってしまうので、改めてここで整理しておきます。 プロジェクト と 進捗会議 そもそも「プロジェクト」は「決められた内容(品質含む)、工数、納期で新しいものを生み出す」ことを目指します。 この「プロジェクト」が完遂するまでには、規模にもよりますが数週間から数年もの期間がかかります。 当然、プロジェクトゴールまでの期間が長くなればなるほど、ゴールへ不時着することが難しくなってきます。 そこで、プロジェクトを無事ゴールへ向かわせるため、定期的にプロジェクトの現状を確認してゴールに向けて軌道修正を行いながら、ゴールへ近づけていきます。 この「定期的にプロジェクトの現状を確認してゴールに向けて軌道修正を行う」のが「進捗会議」です。 進捗会議 の 目的 とは 上記の「プロジェクト」と「進捗会議」の関係を踏まえると、進捗会議の大きな目的は「予定と実績の差異を確認し、ズレの原因を分析、対策を検討、適用すること」が主なものとなります。 うまく「プロジェクト」をゴールへ導くためという点で「情報共有」「モチベーション向上」「目的意識の共有」なども目的としては含まれるようです。 計画と実績の差異を確認 計画とズレている原因の分析 計画とズレている原因に対する対策の検討 計画とのズレを是正する対策の適用 情報共有 モチベーション向上 目的意識の共有 計画 と 実績 の 差異 さて、上記で「計画と実績の差異」と記載している部分について、普通に考えると「すでに遅延してしまったもの」が思いつきますが、 進捗会議では「すでに遅延してしまったもの（過去）」だけでなく、「これから遅延しそうなもの（未来）」についても確認します。 また、往々にして遅延すると品質も悪くなるので「進捗」だけでなく「品質」についても「計画とのズレ」を確認します。 2つの観点は掛け算になるので、まとめると以下のように4つのズレ（計画と実績の差異）が存在することになります。 進...

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