DX時代に役立つPMブログのレビュー

マネジメントに四苦八苦して20年。今はマネジメントを教える、楽しい、不思議なものだ!皆さんの参考になれば。

クライアント目線の品質基準を作る手順

2022-11-11 15:42:23 | プロジェクトマネージャー
プロジェクトは、一般的に要件定義・基本設計の最終的な品質保証をITパートナーが主体となり総合テストで行います。

このテストを通じて、システム要件とシステム不具合(バグ)が解消していればシステム視点として品質が合格となります。

そして、最終工程のユーザーテストで、開発されたシステムを試運転し正確な業務運用ができていると判断されたときに、全ての品質条件がクリアーされたことになります。

この品質保証の判断には、ITパートナーとクライアントに大きなギャップが生じます。

それは、システム視点とクライアント視点という品質目線が違うからです。

そのためにも、ITパートナーは総合テストでも『クライアント視点』のテストを盛り込み実行することで、クライアントは安心できて、無用な誤解も避けられるのです。



お疲れ様です、ゆーろーです。

冒頭のメッセージですが、iPMにプロコンサルとして参加してくれているMASA氏が、開発プロジェクトを行う時に、品質基準で注意していたことだそうです。

品質基準は、システム(エンジニア)と業務(クライアント)の2つの視点で作らなければなりません。

クライアント視点の品質基準、どこに着目すれば良いのでしょうか?

エンジニア視点とクライアント視点を、明確に線引きすることでテストの効果が全く違ってくるものです。

さて、

あなたが、PMとして品質基準を作る立場だったとしましょう。

クライアントから、「私達は技術的なことは一切わからない。リリース後に正確な業務運用ができるのかを知りたい」、そんなことを言われたらどうしますか?

今回、このような状況になったPMのお悩みを、MASA氏が解決し、コラムに整理しました↓


それでは、MASA氏のコラムのあらすじを紹介します!

ご興味がありましたら、コラムをじっくりと読んでください。


--------------------
👍 このコラムは

むずかしさ :★☆☆☆☆(PM初心者向け)

ボリューム :★★★☆☆(5分-8分で読める)

気付き学び :★★★★★(顧客目線の品質基準の重要性)

お役立ち  :★★★★★(顧客目線の品質基準の作り方)

仕事の実用性:★★★★☆(今すぐ使える)

--------------------
👀 コラム情報

コラミスト:MASAさん

発信元:iPM navi

配信日:2022年11月08日

--------------------

*iPM naviで配信しているコラムは、プロジェクトマネージャ試験の論文対策の参考にもなると評判です😀


1.こんなお悩み


わたしはSIerに勤める38歳です。

この度、システムエンジニア職からPM職に転身しました。

今回のプロジェクトで初めPMになった未経験者です。

①現在、プロジェクトは総合テストの中盤です。

総合テストはシステム要件をもとにして作成された要件定義書・基本設計書の品質を実機で確認することが目的であるため、システム視点でテストを実施しています。

②わたしは、クライアント主体で実施するユーザーテストへスムーズに引き継げるように、総合テストの中間報告をしました。

③中間報告前にチームで進捗状況・品質状態を確認したところ、スケジュール通りに進行しており、不具合に対しても品質管理プロセスに従い修正していました。

④しかし、クライアントは「わたしたちは技術的なことは一切わからない。リリース後に正確な業務運用ができるのかを知りたい。」とご指摘を受けました。

⑤わたしは、総合テストの位置付けと目的を説明しましたが、お客さまは納得してくれません。

クライアントに、納得してもらえる方法はないでしょうか?

(コラムを読む...)

2.こうやって解決

ポイントポイントはこれ❗️

・クリティカルな業務要件を整理する。

・総合テストで実施すべき業務範囲を確定する。

・テスト範囲を明確にするために、ユースケースを作成する。

・クライアントへユースケースとテスト仕様書を説明し理解を得る


(コラムを読む...)


3.どんなメソッドを使ったのか?

ポイントを掴んだところで、MASA氏が、どのようなメソッドでアプローチしていったかは、PMとして取り入れておきたいスキルの一つです。

また、難易度が高いと言われる『プロジェクトマネージャ試験』の論文対策にも役立ちます。

ぜひこのコラムを読んでください↓


最後まで、読んでくれて有難う御座います。

WBSを変更するルールを作るコツ

2022-11-08 12:36:00 | プロジェクトマネージャー
プロジェクトは未知を既知に変えていく作業です。

そのため、計画段階でWBSを作ってプロジェクトの準備を行います。

WBSがプロジェクト終了まで変更されないことが理想です。

しかし、そんなことは滅多にありません❗️

プロジェクトではWBSが変更されるのは当たり前と捉えましょう。

しかし、WBSが場当たり的に変更されたり、意味なく頻繁に変わったりするプロジェクトでは、メンバーのモチベーションも低下することもあります。



お疲れ様です、ゆーろーです。

冒頭のメッセージはiPM naviで公開されているコラムの一節です。

プロジェクトは未知を既知に変えるという、あやふやな作業であり、スムーズにゴールに辿り着くのは難しいものです。

せっかく、計画段階で念入りに計画を立てても、プロジェクトの実行中は外的・内的要因によって、計画を変更せざるを得ません。

あなたがPMだったとしましょう。

WBSの変更を余儀なくされた時、メンバーのモチベーションを保ちながら、どのように変更手続きをしていきますか?


このような状況になったPMのお悩みを、iPMのプロコンサルであるMASA氏が解決し、コラムに整理しました↓



それでは、MASA氏のコラムのあらすじを紹介します!

ご興味がありましたら、コラムをじっくりと読んでください。



👍 このコラムは

むずかしさ :★★☆☆☆(PM初級者向け)

ボリューム :★★★☆☆(5分-8分で読める)

気付き学び :★★★★★(WBS変更の時の手順)

お役立ち  :★★★★★(WBSの変更手続き)

仕事の実用性:★★★★☆(今すぐ使える)


👀 コラム情報

コラミスト:MASAさん

発信元:iPM navi

配信日:2022年11月04日


*iPM naviで配信しているコラムは、プロジェクトマネージャ試験の論文対策の参考にもなると評判です😀

😲 こんなお悩み

わたしは、飲料会社の情シスに勤務する34歳のPMです。

PM歴は3年になります。

①わたしは、「プロジェクトは紆余曲折するため計画通り進めることが難しい」と感じています。

②そのため、臨機応変に課題や問題に対応するために頻繁なWBS(タスク、スケジュール)の変更はやむを得ないと考えています。

③そのため、わたしは頻繁にWBSを変更することから、メンバーが迷走してしまうことが多く、信頼関係が崩れています。

④前回のプロジェクトでは、頻繁なWBSの変更によって人員コストの超過、嫌気が差したメンバーの途中離脱などネガティブな状況に陥りました。

今後、このようなことがないようにマネジメントを行なっていきたいのですが、WBSの変更に際して注意するべき点を教えてくれないでしょうか?

😀 こうやって解決

ポイントはこれ❗️

・WBSの変更が起こるパターンを洗い出す。

・WBSの変更に伴う新規・変更タスクの作業所用期間の算出方法を準備する。

・WBSの変更に伴う新規・変更タスクの作業工数の算出方法を準備する。

・WBSの変更に伴う新規・変更タスクに必要とされるスキル、割当人数の洗い出し方法を準備する。

・キックオフで『WBSの変更ルール』を説明する。



これらを、しっかり実施することで、プロジェクトを円滑に実行することができるでしょう。

💪 どんなメソッドを使ったのか?
ポイントを掴んだところで、MASA氏が、どのようなメソッドでアプローチしていったかは、PMとして取り入れておきたいスキルの一つです。

ぜひ、このコラムを読んでください↓


最後まで、読んでくれて有難う御座います。