0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

Googleプロジェクト管理:コーチングで遭遇する可能性のある課題

Last updated at Posted at 2023-01-28

はじめに

わたしが Google プロジェクト管理:プロフェッショナル認定証で得られた素晴らしい体験を、要点をまとめ小さく分割して、わかりやすく簡潔に紹介していきます。

興味があれば、ぜひ "Google プロジェクト管理:プロフェッショナル認定証" を受講してみてください。

コーチングで遭遇する可能性のある課題

今回、アジャイルチームやプロジェクトを管理しているときに、新しいチームであろうと、しばらく前からいるチームであろうと、遭遇する可能性のある、より一般的なコーチングの課題について、次の3つを紹介します。

  1. 安定したプロダクトロードマップの管理
  2. スクラムの不完全な実装
  3. チーム内の安定性の欠如を経験する

1.安定したプロダクトロードマップの管理

アジャイルプロジェクトでは、ほとんどの場合、プロダクトロードマップが変更されます。このような変化に迅速かつ生産的に対応できることは、アジャイルの中核的な価値観です。しかし、プロジェクトに影響を与える変化が大きすぎると、プロダクトロードマップが不安定になる可能性があります。

不安定なプロダクトロードマップの主な原因は、

  • プロダクトの野心
  • プロダクトの思い込み

の2つである。

プロダクトの野心

プロダクトの野心は、プロダクトリーダーがチームが現実的に提供できるものに対して過度に野心的である場合に、課題を提起する。プロダクトオーナーは、顧客や役員に対してプロジェクトを代表する責任がある。なぜなら、プロダクトオーナーはステークホルダーを幸せにしたいからだ。そのため、プロジェクトが提供できるものを過剰に約束してしまいがちです。

では、この課題にどう対処すればいいのでしょうか?ここでは、あなたとプロダクトオーナーとの間で健全なロードマップ管理計画を維持するための3つのアイデアを紹介します。

  • 新しい機会をどのように扱うか、いつレビューと見積もりを行うか、顧客や管理者のコミットメントをどのように行うかについて、前もって合意しておきます。
  • 少なくとも四半期に一度、チーム全体で定期的なロードマップのレビューを設定し、全員が何を期待されているかを知るようにします。
  • プロダクトオーナーと開発チームとの間で知識の共有を促進します。

これにより、プロダクトオーナーは製品の構築にかかる労力を把握し、チームはできるだけ早く変更点を認識することができます。

プロダクトの思い込み

プロジェクトに不確実性がある場合、物事を進めるために何らかの仮定をすることが必要になることがあります。しかし、あまりに多くの仮説をすると、チームの成功が危うくなります。

チームは市場や機会を調査するために最善を尽くしますが、プロダクトの仮説問題に対処する方法として、

  • いくつかの仮説を立て、完璧ではない情報に頼って意思決定 を進めなければなりません。
  • 仮定を文書化し、それを透明化する。このようにして、チームとして前提条件を議論し、それが 安全な前提条件 をであることに同意するか、
  • あるいは、疑問を呈してダブルチェックすることを決定します。もし、ダブルチェックをするのであれば、偏りのないユーザーリサーチ を行うことができます。偏りのないユーザーリサーチは、ユーザーが本当に望んでいることについての情報を収集します。これによって、仮説を確認または否定することができ、自信を持って前進することができます。

2.スクラムの不完全な実装

これは、スクラムの実践が部分的にしか行われていない場合や、適切なサポートやコーチングを受けずにスクラムの実践が行われた場合に起こります。スクラムの役割、成果物、およびアクティビティは、セットで機能するように設計されています。もし部分的にしか実装しなければ、その利点を減らしてしまうことになりかねない。

スクラムの不完全な実装は、多くの問題を引き起こす可能性があります。

  • 明確な役割と責任の所在が分からなくなる 可能性があります。スクラムを完全に導入するには、チームの役割を定義し、その役割を特定の個人で埋める必要があります。例えば、開発者にスクラムマスターを兼任させようとすると、どちらの役割もうまくこなせないかもしれない。開発者には開発チームに入ってもらい、プロジェクトマネージャーにはスクラムマスターになってもらうのがベターです。
  • 時間を節約するために、いくつかのイベントを省略したり、混ぜたりしたくなる もしれませんが、スプリントレビュー、スプリントレトロスペクティブ、およびスプリントプランニングの境界が明確でないと、透明性、検査、および適応を減らすことにつながり、これらはすべてスクラムの利点を完全に体験するために必要なことなのです。
  • チームに必要なスクラムコーチングを提供しないことは、あなたがスクラムマスターとしての役割を果たさないことも意味します。あなたの仕事は、チームがプラクティスの背後にある理由を理解し、その利点を受け入れることができるように、スクラムプラクティスを十分に説明し、コーチングを提供することです。

これらの課題に対する解決策は、スクラムを完全に実装することです。

  • スクラムマスターは、非常に重要な役割です。あなたはコーチですから、チームの活動とスクラムやアジャイルの価値観とのつながりを強化する必要があります。例えば、もしあなたのチームが毎日のデイリースクラムについて不平を言うなら、デイリースクラムの目的がフィードバックを得ること、仕事のブロックを外すこと、助けを求めること、そしてスプリントゴールに集中し続けることの重要性を強化することであることを思い出してください。
  • 役割をきちんと定義し、適切に果たすようにすることもできます。例えば、チームメンバー全員が、自分の役割とチームメイトの役割、そしてそれらの役割がどのように相互作用するかを理解していることを確認します。例えば、
    • プロダクトオーナーは正しいものを作ることを確認し、
    • 開発チームは正しく作ることを確認し、
    • スクラムマスターは速く作ることを確認します。

3. チーム内の安定性の欠如を経験する

チームが大きく変化し、頻繁に人が去ったり加入したりすると、物事が予測できなくなり、仕事の流れが乱れる可能性があります。チームの不安定さに対処するためにできることがいくつかあります。

  • 新しいチームメンバーには迅速な オンボーディングプロセス を用意し、チームの他のメンバーと知り合い、プロジェクトを理解する手助けをします。
  • ペアプログラミング のスタイルを採用し、新しいチームメンバーが同僚とチームを組み、仕事を学び始めるようにします。これは、チームが離脱した場合にも有効で、離脱した部分をパートナーが引き継ぐことができるはずだからです。
  • メンバーの離脱が続いてチームの構成が変わってしまった場合、スプリントの期間を短く してみることです。 こうすることで、チームメンバーは最後のスプリント分の仕事を終えてから帰ることができるのです。
0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?