プロジェクトマネジメント(PMBOK) | ミニミニ管理者(プロジェクトマネージャ/システム管理者/社内SE/CIO)の独り言

[ ミニミニ管理者の独り言プロジェクトマネジメント(PMBOK) > ステークホルダーマネジメント計画 ]
スポンサードリンク

ステークホルダーマネジメント計画


ステークホルダーマネジメント


PMBOKにおけるステークホルダーマネジメントは下記のプロセスに従って実施することとされています。


ステークホルダーの特定


前述の主なステークホルダーをもとにプロジェクト関係者の洗い出しです。自社および顧客、さらに供給業者などのプロジェクトに関連する企業の体制図を描き、そこにできるだけバイネームで登場人物を記します。このとき大切なのが、単なる参加者の羅列ではなく、役割も記載しておきます。この体制図をもとに「ステークホルダー登録簿(一覧)」を作成して管理し、プロジェクト関係者全員で共有します。 



ステークホルダー登録簿


ステークホルダー登録簿では、以下のような情報を管理します。

・識別情報:氏名、職位、所属/部署、役割、担当するシステムや工程など
・評価情報:プロジェクトへの期待、プロジェクトから受ける影響など
・分類:関心度と影響度など



例えば、個々のサブシステムの仕様は誰と打ち合わせるか、それらの仕様決定権は誰が責任をもっているのか、プロジェクト全体に関わる重要な問題は誰が方針決定するのか、など必要な役割をすべて洗い出すことでステークホルダー登録簿は「RACIチャート」の基礎情報にもなります。


次に各人物がプロジェクトに対してどのような立ち位置にいるかを「-1〜0〜1」として定量化します。


指標:

  • 関心度:当事者に近いか、利害関係が強いか。
  •     ➡プロジェクトの成功に肯定的か、否定的か
  • 影響度:権限や影響力があり、QCDSなどにポジティブまたはネガティブな影響を及ぼす力がある人物やポジション。


次にこの定量化した立ち位置を4象限のポートフォリオにまとめます。4象限のポートフォリオは、縦軸に影響度・横軸に関心度として表します。


縦軸:影響度

横軸:関心度


ここで、右上の象限(影響度が大きく、関心度も高い)に位置するステークホルダーを重点的に管理します。


次に、左上の象限や右下の象限に位置するステークホルダーを右上の象限に引き上げる活動を行います。



ステークホルダー・マネジメント計画



◎インプット
・プロジェクトマネジメント計画書
・ステークホルダー登録簿
・組織体の環境要因
・組織のプロセス資産


◎ツールと技法
・専門家の判断
・会議
・分析技法

◎アウトプット
・ステークホルダー・マネジメント計画書
・プロジェクト文書更新版



そして、ツールと技法の「分析技法」では、ステークホルダーの関与度の分析について紹介しています。

その中で、ステークホルダーの関与度を、次のように分類しています。そして、その分類結果を、ステークホルダー登録簿に記載することとなります。



・不認識:プロジェクト自体とプロジェクトとの関係(影響)を認識していない
・抵抗:プロジェクトとの関係(影響)を認識しているが、支持しない
・不認識:プロジェクト自体とプロジェクトとの関係(影響)を認識していない
・抵抗:プロジェクトとの関係(影響)を認識しているが、支持しない

・中立:プロジェクトを認識しているが、抵抗も支持もせず、中立である
・支持:プロジェクトを認識し、積極的に支持する
・指導:プロジェクトを認識し、積極的に関与する






スポンサードリンク


■Blog Ranking■
1. ←←サーバー構築・運用ブログあり お奨め:★★★★★
2. (ブログランキング ドット ネット)
3.にほんブログ村 IT技術ブログへにほんブログ村
4.BS blog Ranking
ブログランキングに挑戦中です。あなたもブログランキングに挑戦してみよう!
サーバー構築・運用ブログなんかもありますのでシステム管理者の方にもお奨めのサイトがあり!
ソニーストア
ボーズ・インイヤーヘッドホン

[ ミニミニ管理者の独り言プロジェクトマネジメント(PMBOK) > プロジェクトスケジュール管理技法 ]
スポンサードリンク

プロジェクトスケジュール管理技法

プロジェクトマネジメントにおけるスケジュール管理の方法は様々ありますが、そのうちの一部を紹介します。



スケジュール・チェーン


計画されたアクティビティ所要時間の内容そのものに焦点を当てておくために、作業のないスケジュール・アクティビティである所要時間バッファーを追加する。
 
ネットワークパスのトータル・フロートのマネジメントではなく、バッファー・アクティビティ所要時間と計画されたスケジュール・アクティビティに使用する資源のマネジメントに注力する。
 
 
クリティカルパス 
【critical path】


別名: 最長経路/臨界経路
クリティカルパスとは、プロジェクトの各工程を、プロジェクト開始から終了まで「前の工程が終わらないと次の工程が始まらない」という依存関係に従って結んでいったときに、所要時間が最長となるような経路のこと。


クリティカルパスを表す図式はアローダイヤグラムを利用することが多い。

 
クリティカルパスに含まれる工程に遅延が発生すると、その分だけプロジェクト全体のスケジュールも遅延するため、クリティカルパスに含まれる工程は特に遅れてはならない重要な工程として重視されることになる。


なお、前回ご紹介した「プロジェクトスケジュール管理技法」のうち、ファストトラッキングは、「敢えて、クリティカルパス上の工程で、前の工程が完了する前に次の工程を開始すること。」という高度なスケジュール短縮テクニックです。

 
ガントチャート 
【Gantt chart】


別名: ガント図線表
ガントチャートとは、工場などで人員、工程管理などに用いられる帯状のグラフ。
 
横軸に時間、縦軸に人員、製造設備等を配置し、工程ごとの個別の作業開始日、作業完了日などといった情報を帯状に示す。
 
さらに、工程によってはある工程で出来上がった中間物を別の工程でさらに作業を行う場合があるが、この相互関係は先に行う作業の作業完了日から次に行う作業の作業開始日へと矢印で明示されることもある。


プロジェクトマネジメントでは、マスタースケジュール(大日程)や中日程でガントチャートを利用することが多い。



WBS

【Work Breakdown Structure】


別名:作業分解図,作業分割構成,ワークブレイクダウンストラクチャー
WBSとは、プロジェクトマネジメントで利用される計画手法の一種で、プロジェクトにおける作業を細かい単位に分割し、階層構造などで管理する手法のことである。


WBSでは、最初に必要な作業の洗い出しを行い、可能な限り(アクティビティレベル)細分化し、それぞれの作業について必要なコストや人員配分を割り出す。これによって、作業全体の把握や各作業の体系的つながりの把握を行うことができ、進捗管理や計画の調整に関する精度を向上させることができる。


WBSにおいて細分化された、作業の要素は、ワークパッケージなどとよばれている。


また、WBSとワークパッケージから作成されたプロジェクト遂行のための組織関係図がOBS(Organization Breakdown Structure)と呼ばれている。


【参考文献:IT用語辞典】







スポンサードリンク


■Blog Ranking■
1. ←←サーバー構築・運用ブログあり お奨め:★★★★★
2. (ブログランキング ドット ネット)
3.にほんブログ村 IT技術ブログへにほんブログ村
4.BS blog Ranking
ブログランキングに挑戦中です。あなたもブログランキングに挑戦してみよう!
サーバー構築・運用ブログなんかもありますのでシステム管理者の方にもお奨めのサイトがあり!
ソニーストア
ボーズ・インイヤーヘッドホン

[ ミニミニ管理者の独り言プロジェクトマネジメント(PMBOK) > プロジェクトスケジュールを短縮するテクニック(クラッシング/ファストトラッキング) ]
スポンサードリンク

プロジェクトスケジュールを短縮するテクニック(クラッシング/ファストトラッキング)

プロジェクトマネジメントにおいて大切なことは、どのようにして「QCDSを死守するか?」となります。


特に進捗報告において、「遅延が発生したから・・・」となると、そのリカバリにかかる工数は大きいです。


進捗の遅れを出さないためには、WBSで管理するワークパッケージごとに進捗を管理します。これを報告先に合わせた粒度で上長や関係者、ステコミなどに定期的に報告します。


クラッシング 【crashing】


クラッシングとは、プロジェクトの工期を短縮する手法の一つで、クリティカルパス上の工程に追加の資源(人員、資金)を投入して予定より短い工期で完了すること。
工期の遅れを挽回するために用いられることがある。
 
プロジェクト全体の工期を決定する経路(クリティカルパス)上に存在する工程について、追加資源を投入してスケジュールを早める手法である。
 
その工程の期間が短縮された結果クリティカルパスが変わる場合があるため、一度に極端な短縮は避け、短縮後の計画を事前に確認したほうがよい。
 
また、クリティカルパスが複数ある場合はそれらが同時に同じ期間短縮できるよう複数の工程でクラッシングを行なう。
 
 
ファストトラッキング 【fast tracking】


ファストトラッキングとは、<a href="http://miniminiadmin.jugem.jp/?eid=684" target="_blank">プロジェクト</a>の工期を短縮する手法の一つで、工程が完了する前に次の工程を開始すること。
 
工期の遅れを挽回するために用いられることがある。
 
本来は順番に実行するはずだった各工程について、前工程の完了を待たずに次工程に着手し、一部を並行して実行する方式で、前工程で既に作業が済んだ成果物を利用して次工程の作業を進めるなどの手法が取られる。
 
ファストトラッキング開始後に前工程で重大な変更などが起き、次工程の完了部分がやり直し(手戻り)になるなどのリスクもある。







スポンサードリンク


■Blog Ranking■
1. ←←サーバー構築・運用ブログあり お奨め:★★★★★
2. (ブログランキング ドット ネット)
3.にほんブログ村 IT技術ブログへにほんブログ村
4.BS blog Ranking
ブログランキングに挑戦中です。あなたもブログランキングに挑戦してみよう!
サーバー構築・運用ブログなんかもありますのでシステム管理者の方にもお奨めのサイトがあり!
ソニーストア
ボーズ・インイヤーヘッドホン

[ ミニミニ管理者の独り言プロジェクトマネジメント(PMBOK) > プロジェクトの中止判断 ]
スポンサードリンク

プロジェクトの中止判断

プロジェクトは場合に依り、中長期的にわたることもある。


この間には様々なビジネスにおける環境の変化が起こるのは当たり前のこととして捉えるべきです。


何故なら、ビジネスは生き物のように日々変化しているからです。このビジネスにおける環境の変化といっても外的要因もあれば内部要因もあります。


そのため、これらの事象をリスク管理として行うわけですが、QCDの観点から、おざなりになりがちではないですか?

※リスクの顕在化が少ないと整理しているのも含まれます。


そこで、<a href="http://miniminiadmin.jugem.jp/?eid=684" target="_blank">プロジェクトマネジメント</a>における「プロジェクトの中止判断」は何をもってすべきでしょうか?


英国商務象省の公認の<a href="http://miniminiadmin.jugem.jp/?eid=684" target="_blank">プロジェクトマネジメント資格</a>である「PRINCE2」には、


「ビジネス・ケースの有効性が消滅したら、理由が何であれ、プロジェクトは中止すべし。」


とあります。


これは当たり前のことではあるものの、これまでの投資額が無駄となりますし、更なる対応には追加コストが発生することもあるため、判断に迷うこととなります。


投資額の回収期間によっては、中止しない判断もあり得ますが、一端中止が決まると、責任問題に発展する可能性もあるので慎重にことを運ぶ必要があります。




 


スポンサードリンク


■Blog Ranking■
1. ←←サーバー構築・運用ブログあり お奨め:★★★★★
2. (ブログランキング ドット ネット)
3.にほんブログ村 IT技術ブログへにほんブログ村
4.BS blog Ranking
ブログランキングに挑戦中です。あなたもブログランキングに挑戦してみよう!
サーバー構築・運用ブログなんかもありますのでシステム管理者の方にもお奨めのサイトがあり!
ソニーストア
ボーズ・インイヤーヘッドホン

[ ミニミニ管理者の独り言プロジェクトマネジメント(PMBOK) > 大規模プロジェクトにおけるCCPM(Critical Chain Project Management:クリティカル・チェーン・プロジェクト・マネジメント)の重要性 ]
スポンサードリンク

大規模プロジェクトにおけるCCPM(Critical Chain Project Management:クリティカル・チェーン・プロジェクト・マネジメント)の重要性

CCPM(Critical Chain Project Management:クリティカル・チェーン・プロジェクト・マネジメント)とは


CCPM(Critical Chain Project Management:クリティカル・チェーン・プロジェクト・マネジメント)という管理手法をご存知だろうか。


この「CCPM(Critical Chain Project Management:クリティカル・チェーン・プロジェクト・マネジメント)」とは、「不確実性を管理するため、実作業を伴わない工数をバッファとして確保する。バッファはプロジェクトの各タスクの予算やスケジュールをギリギリに抑え、それをプロジェクト・バッファと合流バッファ(フィーディングバッファ)いうかたちで確保し、プロジェクトバッファはマスタースケジュールの最後尾に設け、リーディングバッファは工程の合流ポイントに設ける」管理手法です。


すなわち、プロジェクトの各タスクの予算やスケジュールを各工程から10〜20%を抑えて、その分をプロジェクト・バッファや合流バッファ(リーディングバッファ)という余裕を設けておくことで、例えばある工程で「工数不足が発覚したら後からバッファを割り当てる」ことや、「あらかじめ工程の合流ポイントにリーディングバッファとして設ける」などにより、遅延を回避します。 


通常、これらの工程はある程度余裕を含んでいます。各工程で見ている余裕を20%とした場合、それらを取っ払ってぎりぎりで計画します。


CCPMの注意


プロジェクトバッファはコストとスケジュールの両方に対して抑制しますが、スケジュールについては「クリティカルパス」を考慮してバッファを設けることをしてください。


なぜ、このような管理手法が必要なのだろうか。これはパーキンソンの法則を活用しています。


それは人は目の前の目標に向かって進む習性があるので、余裕を含んだ計画値を与えたらその計画通りに作業をしてしまいがちだからです。


これを回避する考え方を取り入れたマネジメントがCCPM(Critical Chain Project Management:クリティカル・チェーン・プロジェクト・マネジメント)という管理手法です。


バッファを捻出する


WBSを展開する
個々のタスクの工数を精緻に見積り、合計を正規の計画とする
個々のタスクの余裕分を取り除き、合計をぎりぎりの計画とする

  コストの余裕分は、一律10〜20%

  日程の余裕分は、クリティカルパスを除く工程で10〜20%で、且つ削減後でもクリティカルパスより短くならない数値とする
正規の計画―ぎりぎりの計画=バッファとして準備する


このようにして捻出したバッファですが、誰が消費しても問題にはならないことを全員が共有することです。つまり、バッファがマイナスになって初めて予算オーバーとなります。









スポンサードリンク


■Blog Ranking■
1. ←←サーバー構築・運用ブログあり お奨め:★★★★★
2. (ブログランキング ドット ネット)
3.にほんブログ村 IT技術ブログへにほんブログ村
4.BS blog Ranking
ブログランキングに挑戦中です。あなたもブログランキングに挑戦してみよう!
サーバー構築・運用ブログなんかもありますのでシステム管理者の方にもお奨めのサイトがあり!
ソニーストア
ボーズ・インイヤーヘッドホン

[ ミニミニ管理者の独り言プロジェクトマネジメント(PMBOK) > ステークホルダーとは ]
スポンサードリンク

ステークホルダーとは

ステークホルダーとは、プロジェクトに対して既得権益を持つ人を指し、「プロジェクトの意思決定、アクティビティ、成果に影響したり、影響されたり、自ら影響されると感じたりする個人やグループ、組織」のことです。


主なステークホルダー


・プロジェクトスポンサー、株主
・承認するマネージャ
・顧客(社内・外)

・利用者/業務担当者、業務管理者、部署長

・プロジェクトチーム

・ベンダ(納入業者)やサプライヤ(供給業者)


こうした幅広いプロジェクト関係者と良好な関係を築きプロジェクトを円滑に進めていくことがプロジェクト管理には求められます。


ステークホルダーマネジメントの実施


PMBOKにおけるステークホルダーマネジメントは下記のプロセスに従って実施することとされています。


ステークホルダーの特定


前述の主なステークホルダーをもとにプロジェクト関係者の洗い出しです。自社および顧客、さらに供給業者などのプロジェクトに関連する企業の体制図を描き、そこにできるだけバイネームで登場人物を記します。このとき大切なのが、単なる参加者の羅列ではなく、役割も記載しておきます。この体制図をもとに「ステークホルダー登録簿(一覧)」を作成して管理し、プロジェクト関係者全員で共有します。 



ステークホルダー登録簿


ステークホルダー登録簿では、以下のような情報を管理します。

・識別情報:氏名、職位、所属/部署、役割、担当するシステムや工程など
・評価情報:プロジェクトへの期待、プロジェクトから受ける影響など
・分類:関心度と影響度など



例えば、個々のサブシステムの仕様は誰と打ち合わせるか、それらの仕様決定権は誰が責任をもっているのか、プロジェクト全体に関わる重要な問題は誰が方針決定するのか、など必要な役割をすべて洗い出すことでステークホルダー登録簿は「RACIチャート」の基礎情報にもなります。


次に各人物がプロジェクトに対してどのような立ち位置にいるかを「-1〜0〜1」として定量化します。


指標:

  • 関心度:当事者に近いか、利害関係が強いか。
  •     ➡プロジェクトの成功に肯定的か、否定的か
  • 影響度:権限や影響力があり、QCDSなどにポジティブまたはネガティブな影響を及ぼす力がある人物やポジション。


次にこの定量化した立ち位置を4象限のポートフォリオにまとめます。4象限のポートフォリオは、縦軸に影響度・横軸に関心度として表します。


縦軸:影響度

横軸:関心度


ここで、右上の象限(影響度が大きく、関心度も高い)に位置するステークホルダーを重点的に管理します。


次に、左上の象限や右下の象限に位置するステークホルダーを右上の象限に引き上げる活動を行います。



ステークホルダー・マネジメント計画



◎インプット
・プロジェクトマネジメント計画書
・ステークホルダー登録簿
・組織体の環境要因
・組織のプロセス資産


◎ツールと技法
・専門家の判断
・会議
・分析技法

◎アウトプット
・ステークホルダー・マネジメント計画書
・プロジェクト文書更新版



そして、ツールと技法の「分析技法」では、ステークホルダーの関与度の分析について紹介しています。

その中で、ステークホルダーの関与度を、次のように分類しています。そして、その分類結果を、ステークホルダー登録簿に記載することとなります。



・不認識:プロジェクト自体とプロジェクトとの関係(影響)を認識していない
・抵抗:プロジェクトとの関係(影響)を認識しているが、支持しない
・不認識:プロジェクト自体とプロジェクトとの関係(影響)を認識していない
・抵抗:プロジェクトとの関係(影響)を認識しているが、支持しない

・中立:プロジェクトを認識しているが、抵抗も支持もせず、中立である
・支持:プロジェクトを認識し、積極的に支持する
・指導:プロジェクトを認識し、積極的に関与する






スポンサードリンク


■Blog Ranking■
1. ←←サーバー構築・運用ブログあり お奨め:★★★★★
2. (ブログランキング ドット ネット)
3.にほんブログ村 IT技術ブログへにほんブログ村
4.BS blog Ranking
ブログランキングに挑戦中です。あなたもブログランキングに挑戦してみよう!
サーバー構築・運用ブログなんかもありますのでシステム管理者の方にもお奨めのサイトがあり!
ソニーストア
ボーズ・インイヤーヘッドホン

[ ミニミニ管理者の独り言プロジェクトマネジメント(PMBOK) > EPM(Enterprise Project Management)とは ]
スポンサードリンク

EPM(Enterprise Project Management)とは

EPM(Enterprise Project Management)とは


企業(Enterprise)内の活動をすべてプロジェクトとして捉えて管理するものです。たとえば人事部門であれば、新卒採用、中途採用、給与計算、目標管理、年末調整などさまざまな業務がありますが、こうした業務をそれぞれプロジェクトとして管理することで、業務効率が高まり、無駄な作業を減らすことができます。また、単に組織内の複数プロジェクトを束ねて管理/見える化することを指すこともあります。


そのため、ここではEPMを以下のように定義します。


EPM(Enterprise Project Management)の定義


・企業内の全ての業務をプロジェクトとして管理する

組織/企業/機関/団体のレベル内で発生する複数プロジェクトを束ねて見える化する


ここで、プロジェクトマネジメントを学んでいるかたなら不思議に思うのが、「EPMで管理する業務には定常業務を含むのか?」だと思います。


そう、定常業務といったルーティンワークをプロジェクトとして捉え管理することで、惰性や慢性を排除して、常に改善策や最善策を検討するように意識改革することで、業務効率化され、生産性が向上し、筋肉質な企業として鍛えられます。



EPMの重要性


近年、EPMの重要性が叫ばれています。これまでのように1つ1つの業務をマネジメントしていない状況は言わば「どんぶり勘定」も同然の管理されていない状況です。これでは、業務改善も掛け声ばかりでままなりません。WBSで対象業務のタスクを洗い出し、ガントチャートで進捗をトラッキングし、工数管理でかかったコストを定量化する。業務をプロジェクト化することにより、初めてこうしたプロセス改善が実現して企業の競争力を高めることができるのです。


これまでプロジェクトとして捉えていなかった業務をもプロジェクトマネジメントの対象として管理するEPMを実践することは有効だと考えます。管理部門や営業部門など非開発部門におけるコストとスピードの改善までメスを入れることができるからです。


定常業務をプロジェクト管理するイメージ


例えば、ある定常業務を担う部門での年間計画で以下のような活動をすることでプロジェクトマネジメント(QCD)のうち、スケジュール管理を実施します。


・期初に部門のアクションプランを策定する

・アクションプラン別に今期の取り組みをWBSに分割する

・各たすくに担当者をアサインする

・ガントチャートにスケジュール登録する


その後はWBSをもとに進捗率を週1回程度の進捗報告にて確認し、遅延があればリカバリプランを提示します。




EPMの課題


EPMを実現するにはシステム(ツール)が必要です。管理のための負担が増えたり、見える化するために余計な作業が増えたりするようでは、効率化と情報共有というメリット以上に管理コスト増となり、やる意味が薄れます。
EPMを実践するには、効率的にプロジェクトとして管理できる仕組みに加えて、余計な手間をかけずに自動的に情報が組織で共有される仕組みが必要です。




スポンサードリンク


■Blog Ranking■
1. ←←サーバー構築・運用ブログあり お奨め:★★★★★
2. (ブログランキング ドット ネット)
3.にほんブログ村 IT技術ブログへにほんブログ村
4.BS blog Ranking
ブログランキングに挑戦中です。あなたもブログランキングに挑戦してみよう!
サーバー構築・運用ブログなんかもありますのでシステム管理者の方にもお奨めのサイトがあり!
ソニーストア
ボーズ・インイヤーヘッドホン

[ ミニミニ管理者の独り言プロジェクトマネジメント(PMBOK) > プロジェクトスポンサと変革趣意書を作成する ]
スポンサードリンク

プロジェクトスポンサと変革趣意書を作成する

プロジェクト憲章(会社によってはシステム化計画とか、事柄稟議書などプロジェクトが正式に了承されたら、プロジェクトスポンサにヒアリングする機会を作るべきです。その際にはプロジェクト発足に至る経緯や求めていること、目的などと一緒に以下の観点も議論して、変革趣意書を作成して合意しておけると良いと思います。


変革趣意書のポイント


.廛蹈献Дトの観点からなぜこのプロジェクトをやるのか?
△覆次△い泙海離廛蹈献Дトをやるのか?
問題は以前からあったはずで、このプロジェクトを優先的に取り上げる切っ掛けは何か?
プロジェクトが成功しなかったら何が起こるか?
ぅ廛蹈献Дトをやることによるビジネス上のメリットは何か?
イ笋衒を変えるとしたらどこか?


PMチームで作成して、ユーザーに手を加えてもらい、プロジェクトスポンサに説明し、合意を得る。


なお、プロジェクト憲章と変革趣意書をベースにプロジェクト計画書を作成します。







スポンサードリンク


■Blog Ranking■
1. ←←サーバー構築・運用ブログあり お奨め:★★★★★
2. (ブログランキング ドット ネット)
3.にほんブログ村 IT技術ブログへにほんブログ村
4.BS blog Ranking
ブログランキングに挑戦中です。あなたもブログランキングに挑戦してみよう!
サーバー構築・運用ブログなんかもありますのでシステム管理者の方にもお奨めのサイトがあり!
ソニーストア
ボーズ・インイヤーヘッドホン

[ ミニミニ管理者の独り言プロジェクトマネジメント(PMBOK) > ソフトウェア開発における品質管理と評価方法 ]
スポンサードリンク

ソフトウェア開発における品質管理と評価方法

ソフトウェアの品質の評価にはどのような視点が必要だと考えてますか?

最も使われる評価指標としては設計書やプログラムの不具合(バグ)の数値による評価があるかと思いますが、それだけでは不十分です。また特定の作業フェーズ(WBS)での不具合の件数だけで捉えることだけでも不十分です。

ソフトウェアの品質は種々の要素から評価をし、さらに変動を捉えていくことが必要です。

しかし、それを全ての機能において実施していくことも作業効率の点から好ましくありません。

そこで一般的な「品質」の定義から始め、

「ソフトウェアの品質とは何か、どのような視点で品質を管理し評価していくことが必要であるのか」

を説明いたします。

その後、プログラム品質管理の考えます。


考え方として、品質基準とする各要素の考え方および品質の変動状況の捉え方について深く考える。その考えを元に計画時点で検討すべき事項が何であるかが分かります。

特に品質基準の要素としては、チェックリスト(テストケース)件数と不良(バグ)件数にプラスして管理すべき必要な観点があります。



ソフトウェア品質管理の目的
 

1「ソフトウェアの品質」についての理解を深める。
2「ソフトウェアの品質」を向上させるための方法を理解する。


 
ソフトウェアの品質管理の考え方


1 ソフトウェア品質とは
    −ソフトウェアの品質管理とは
2 ソフトウェアの品質向上の考え方
  −PDCAサイクルを回す
  −初期段階で計画を評価する
3 ソフトウェアの品質管理に必要な要素
  −ソフトウェア品質計画の立案
  −レビュー品質について
  −チェックリスト評価基準とバグ件数の評価基準

ソフトウェアの品質管理と評価


1 ソフトウェア品質を見ていく視点
  −プロジェクトは唯一無二であり、人間で構成されている
      ➡人間がバグを作り出す
  −プロジェクトの目標を焦点に考える

      ➡目標に沿った品質

2 チェックリスト(テストケースリスト)作成の考え方
  −チェックリスト作成と各設計工程の関連
  −チェックリスト作成における留意事項
  ・チェック項目設定レベルと記述レベル
  ・チェックリストの作成は、どの工程で行うべきか
3 ソフトウェア品質評価の考え方
  −評価視点の持ち方
  ・チェックリスト密度と不良件数密度による評価

     ➡開発規模に応じた適正なバグ件数を検出することを目標とする。

     ➡バグ分析時の横展開による類似バグの撲滅

  ・プログラムの特徴・特性・重要性からの評価  
  ・相対評価から傾向を評価する
  −工程別の評価の変動を意識する
4 プログラム改修時の品質評価
  −数値だけで評価できないプログラム改修品質
  −デグレードはなぜ起きる

     ➡構成管理の重要性、設計思想からの品質管理など

5 総合的な品質評価の考え方と留意点
   −バグ0件は品質が良いのか

      ➡試験シナリオが適切でないため、バグを検出できていないと考えるべき。

6.まとめ
  −最初に仮説を立てることが重要
  −ツールによる効率化やチェックリスト適用の利点と欠点
 
 
<品質評価>
プログラムに関する各種データ(規模、工程別のテスト結果等)を見て、品質が保持されているのかどうかを評価します。

なお、「懸念」が残るプログラムがあれば、その理由および品質評価をさらに行なうために確認すべき事項を整理し、品質に問題ありと評価された場合には追加試験を計画します。

※追加試験は品質向上(Q↑)のために、期間延長(D↓)、コスト増加(C↓)となることに留意します。

そのため、このプロジェクトでは「QCDのうち何が最も重要な指標」であるかをプロジェクトスポンサに確認しておき、変革趣意書にまとめておくのも良いと思います。


<a target="_blank"  href="https://www.amazon.co.jp/gp/product/4817192631/ref=as_li_tl?ie=UTF8&camp=247&creative=1211&creativeASIN=4817192631&linkCode=as2&tag=miniminiadmin-22&linkId=9d5f071a80cf7739c3f8e40526ff8db0"><img border="0" src="//ws-fe.amazon-adsystem.com/widgets/q?_encoding=UTF8&MarketPlace=JP&ASIN=4817192631&ServiceVersion=20070822&ID=AsinImage&WS=1&Format=_SL110_&tag=miniminiadmin-22" ></a><img src="//ir-jp.amazon-adsystem.com/e/ir?t=miniminiadmin-22&l=am2&o=9&a=4817192631" width="1" height="1" border="0" alt="" style="border:none !important; margin:0px !important;" />




スポンサードリンク


■Blog Ranking■
1. ←←サーバー構築・運用ブログあり お奨め:★★★★★
2. (ブログランキング ドット ネット)
3.にほんブログ村 IT技術ブログへにほんブログ村
4.BS blog Ranking
ブログランキングに挑戦中です。あなたもブログランキングに挑戦してみよう!
サーバー構築・運用ブログなんかもありますのでシステム管理者の方にもお奨めのサイトがあり!
ソニーストア
ボーズ・インイヤーヘッドホン

[ ミニミニ管理者の独り言プロジェクトマネジメント(PMBOK) > ステージゲート/関門(PMBOK) ]
スポンサードリンク

ステージゲート/関門(PMBOK)

PMBOKやプロジェクト管理におけるステージゲートという言葉をご存知だろうか。このステージゲートは、経営用語として一般的な用語です。


ステージゲート法

ステージゲートは、新規事業や新製品のアイデアが生まれてから、事業化・製品化されるまでに必要なステップと作業ロードマップを与える考え方です。特徴は、開発プロセスの途中の過程で経営判断を行う「ゲート」によってステージに分けていることです。


この方法では、機能組織に合せたステージはなく、ステージは基本的に組織横断的なプロジェクトで構成され、ゲートに進むために必要な作業は並行して行われます。

また、ステージでは技術、市場、資金、オペレーションなどのリスクの管理をするために、必要な情報が収集されていきます。


ゲートのもっとも重要な役割は、評価の低いプロジェクトを中止し、そのリソースを見込みのあるプロジェクトに再配分する。ゲートにおける評価は、ステージで生まれた成果の質、経済合理性などに注目し、それぞれのプロジェクトがどの程度の成功をおさめるかを評価します。イノベーションでは、この評価とリソースの再配分が成功の分岐点になるのです。


このステージゲート法をITにおきかえて考えます。ステージ≒工程やフェーズとすると、「プロジェクトフェーズ/工程の1つが終了したら、そこまでの成果物とパフォーマンスを検討して、プロジェクトを先に進めるかどうかを判断」することになります。


このステージゲートは品質管理や調達マネジメントの観点からも重要なポイントです。


このステージゲートのイメージを工程別に記載します。


システム構築工程別のステージゲート


要件定義工程

要件定義書を作成して、ユーザーを含めて実施するインスペクションによるレビュと合意形成。その結果、要件定義書へのユーザー側の権限者による押印などの承認行為。


設計工程

基本設計書(外部設計にあたる画面定義や画面項目定義、インターフェース定義など)を作成して、ユーザーを含めて実施するインスペクションによるレビュと合意形成。その結果、基本設計書への開発実施責任者などの権限者による押印などの承認行為。

会社によりPMOも参加する。


開発工程

単体試験や結合試験結果報告書に開発実施責任者などの権限者による押印などの承認行為。

会社によりPMOも参加する。


試験工程

システム試験結果報告やシステム間連携試験、接続試験、受け入れ試験などによる機能要件やシステム環境、業務フローによる業務継続性の検証などの結果報告と開発実施責任者などの権限者による押印に加え、受け入れ側による承認行為。

会社によりPMOも参加する。(実際に独自のシナリオにて試験を実施することもある。)


本番移行工程

UAT(受け入れ試験)結果報告と共に本番環境への摘要是非を問う本番環境リリース判定や、システム切替などのタイミングにて実施する移行判定や初回稼働確認による移行完了確認など。









スポンサードリンク


■Blog Ranking■
1. ←←サーバー構築・運用ブログあり お奨め:★★★★★
2. (ブログランキング ドット ネット)
3.にほんブログ村 IT技術ブログへにほんブログ村
4.BS blog Ranking
ブログランキングに挑戦中です。あなたもブログランキングに挑戦してみよう!
サーバー構築・運用ブログなんかもありますのでシステム管理者の方にもお奨めのサイトがあり!
ソニーストア
ボーズ・インイヤーヘッドホン