1. pmの認定試験

     
  2. PMBOKの品質計画プロセスでは、費用対効果分析や品質コストの算出などを行い、「品質マネジメント計画書」「品質測定基準」「チェックリスト」を主なアウトプットとしています。品質マネジメント計画書には、品質を保証・改善してゆくための組織構造や責任分担、手順、経営資源などを定義するのですが、少し概念的なのでこのままでは利用できません。実用レベルに落とすにあたり、弊社のプロジェクト管理手法PYRAMIDでは「品質基準書」を品質計画プロセスのアウトプットとしていますが、今回そのテンプレートを用意しました(図1)。このテンプレートでは、”システム全体”とか”操作性”などのテーマ単位にレスポンスやセキュリティなどの品質基準を設定します。 品質基準書を作成する上で難しいのは、抽象的な項目をいかに具体的な内容に落とすかということです。そもそも「品質=ユーザー満足度」という前提自体があいまいな定義であり、何をもってOKとするかをうまく言い表すのが難しいのです。「更新ボタンを押したときに画面の値がデータベースに反映されること」「検索ボタンを押したときに、検索条件に合致するデータが一覧表示されること」などは非常に重要なことですが、当たり前すぎてわざわざ基準書に書き出す意味がないでしょう。実用的には、人により見解や解釈が異なるような項目、黙っているとおろそかになってしまいそうな項目について明記するという考えに立つのが良いと思います。
[ThinkIT] 第5回:品質管理 (3/4)

    PMBOKの品質計画プロセスでは、費用対効果分析や品質コストの算出などを行い、「品質マネジメント計画書」「品質測定基準」「チェックリスト」を主なアウトプットとしています。品質マネジメント計画書には、品質を保証・改善してゆくための組織構造や責任分担、手順、経営資源などを定義するのですが、少し概念的なのでこのままでは利用できません。実用レベルに落とすにあたり、弊社のプロジェクト管理手法PYRAMIDでは「品質基準書」を品質計画プロセスのアウトプットとしていますが、今回そのテンプレートを用意しました(図1)。このテンプレートでは、”システム全体”とか”操作性”などのテーマ単位にレスポンスやセキュリティなどの品質基準を設定します。

    品質基準書を作成する上で難しいのは、抽象的な項目をいかに具体的な内容に落とすかということです。そもそも「品質=ユーザー満足度」という前提自体があいまいな定義であり、何をもってOKとするかをうまく言い表すのが難しいのです。「更新ボタンを押したときに画面の値がデータベースに反映されること」「検索ボタンを押したときに、検索条件に合致するデータが一覧表示されること」などは非常に重要なことですが、当たり前すぎてわざわざ基準書に書き出す意味がないでしょう。実用的には、人により見解や解釈が異なるような項目、黙っているとおろそかになってしまいそうな項目について明記するという考えに立つのが良いと思います。

    [ThinkIT] 第5回:品質管理 (3/4)

     
  3. image: download

    PMBOKは、プロジェクト管理体系に関する知識を分類し、書類棚を並べたような引き出しに整理しています。この書棚は図1のように、縦9段、横5段、奥行き3段の構造で、それぞれのボックスの中にプロジェクト管理に関する項目が入っています。
via www.thinkit.co.jp

    PMBOKは、プロジェクト管理体系に関する知識を分類し、書類棚を並べたような引き出しに整理しています。この書棚は図1のように、縦9段、横5段、奥行き3段の構造で、それぞれのボックスの中にプロジェクト管理に関する項目が入っています。

    via www.thinkit.co.jp

     
  4. コース概要
    J-SOX法の施行により、プロジェクト・マネジメント計画書相当のドキュメントを要求されるプロジェクトが増えています。また、PMBOK®をもとに計画書を作成したいが、テンプレートは存在していませんかというお問い合わせも頂いています。
    このコースでは、PMBOK®に記述されている各種マネジメント計画書を1種づつ作成し、更に統合することで漏れのない整合性のとれたプロジェクトマネジメント計画書作成を目指します。
     
  5. [ThinkIT] 第7回:コミュニケーション管理 (2/4)
     
  6. コミュニケーション計画プロセス

    表1を見て分かるように、PMBOKのコミュニケーション計画には「ステークホルダー分析」が含まれています。ステークホルダーとは”利害関係者”のことです。組織管理で洗い出したプロジェクト体制図に登場するメンバー相互の関係を分析します。ただし、PMBOKのコミュニケーション管理は、ステークホルダーの企業としての立場をあまり考慮していません。プロジェクト参加者を全てメンバーとして考え、単純にメンバー相互のコミュニケーションを対象としているようです。

    常駐・派遣型のプロジェクトはこれでもかまわないでしょう。ユーザーと開発メンバー、協力会社が同一の場所に集まってプロジェクトを遂行し、人月ベースで対価を支払う方法なら立場の違いはあまり気にしなくても良いと思います。しかし、請負ベースの開発プロジェクトの場合は、”企業間”の立場を考慮した方がしっくりいきます。

    プロジェクトの失敗要因を考えた場合、ユーザーと自社開発メンバーと協力会社それぞれの間でコミュニケーション不足の内容が異なります。また、失敗を防ぐ為の管理ドキュメントテンプレートも、立場の違いにより異なります。そこで弊社のプロジェクト管理手法PYRAMIDでは、図1のようなステークホルダーの立場に分けてコミュニケーション計画を考えるようにしています。

    コミュニケーション計画プロセスでは、プロジェクトを遂行するためのコミュニケーションルールを策定します。コミュニケーション計画の例を表2に示します。ここでは3つのステークホルダーの立場に分けてコミュニケーション計画を立てています。計画には、項目別に「誰から誰へ」「いつ」「どういう頻度で」「どういう情報を」「どういう手段で」というような取り決めを盛り込みます。

    例えばユーザーとのコミュニケーションの場合は、打合せ議事録はどちらが書くか、質問&回答のやり取りはどうするか、仕様変更の伝達方法はどうするか、仕様書のレビュー方法はどうするか、などの取り決めがこれに当たります。

     
  7. コミュニケーション管理のポイントは、「ドキュメントに残す」ことです。言った言わないのトラブルにならないように、必ずドキュメントに残すことにしましょう。そんなこと当たり前だと思うでしょうが、では、きちんと実践できているか振り返ってみてください。ついついプロジェクトが忙しくなると、ドキュメント作成の時間も惜しんで口頭ベースでになりがちだと思います。    そのために、きちんとプロジェクト計画プロセスで”ルール”として定め、さらに”ドキュメントテンプレート”を用意しておくのです。 (via [ThinkIT] 第7回:コミュニケーション管理 (1/4))

    コミュニケーション管理のポイントは、「ドキュメントに残す」ことです。言った言わないのトラブルにならないように、必ずドキュメントに残すことにしましょう。そんなこと当たり前だと思うでしょうが、では、きちんと実践できているか振り返ってみてください。ついついプロジェクトが忙しくなると、ドキュメント作成の時間も惜しんで口頭ベースでになりがちだと思います。    そのために、きちんとプロジェクト計画プロセスで”ルール”として定め、さらに”ドキュメントテンプレート”を用意しておくのです。 (via [ThinkIT] 第7回:コミュニケーション管理 (1/4))