はじめに
こんにちは、エンジニアの川守田と申します。
この記事は社内でアジャイルトレーニングを受けて、自分が気になった妨害リストについてまとめたものです。
妨害リストは軽視されやすい印象があった為、重要性を確認しようと思い、今回取り上げる事にしました。
妨害リスト(Impediment List)とは？
妨害リストとは、一般的に以下のように定義されています。
- 開発する上で進捗を妨げる障害(妨害)の一覧。
- 妨害を取り除くために、基本的にスクラムマスターが妨害をハンドリングする。
- 必要に応じて上位組織に解決を依頼する。
妨害リストを作成することにより、何が問題となっているかを見ることができ（見える化）、チームとして共通の課題意識をもつことができます。
妨害リストの登録例
人やスキルに関する問題
- スキルコンバートしたエンジニアがいるため、ベロシティが上がらない。
- コミュニケーション不足による認識齟齬。
- 病気や怪我等の休みによる人員不足。
- 会議が多い、長い。
プロセスに関する問題
- POが要求を出すのが遅い(スプリント計画になって初めて伝えてくるため、スプリント中に完了しない)。
- テストしても毎回不具合が見つかり手戻りが発生する。
- レトロスペクティブで挙がった改善アクションを優先しがちで、開発作業が進まない。
- デザインが揃っていない（＝Ready）、作業完了で認識のずれが起こる（＝Done）など、条件が不明確。
環境に関する問題
- 開発しているPCの性能が悪く、作業効率が低い。
- CI環境のスペックが低いため、自動テストの処理が遅い。
- 開発している場所の環境が悪い（暑い・寒い・うるさい等）
- 台風等の自然災害による影響
プロダクトやナレッジに関する問題
- コードが複雑化して可読性が低下しているため、毎回調査に時間がかかる。
- 設計書が無く新規参入者が業務を学びにくい。
- 業務知識を学習するのに時間がかかる。
- 作業が人に依存しており、その人じゃないとできない作業がある。
割り込み作業に関する問題
- 障害対応などの緊急作業。
- OSのアップデート対応。
- 別プロダクトからの依頼作業の対応。
- 会社の研修。
実際の妨害リスト
実際にリストを作成する場合は、優先順位や対策内容、担当者、期限を記載するとよいと思います。
妨害リストの運用・更新
スクラムマスターが管理しているものですが、基本的に気づいたタイミングで誰が更新しても問題のないものだと思います。
ただし、更新が滞ってしまう場合があるので、デイリースクラムやスプリントレトロスペクティブ等で定期的に確認する場を設けることが望ましいと思います。
また、妨害リストが運用されない事が一番の妨害になる場合もあります。
そうならないように気をつけましょう。
妨害リストが運用されない理由
- スクラムマスターが兼務の為、妨害リストの運用まで手が回らない。
- 業務優先で対策が後回しになる。
- そもそも対策を検討しない。
- 誰かが対応してくれると他人任せになっている。
- 妨害リストを溜めすぎてしまう。
さいごに
妨害リストはプロダクトバックログなどの作成物に比べると管理の重要性は低いかもしれません。
ただ、スクラムマスターは妨害の排除も重要な役割の１つとなりますので、リスト化して管理しておくべきかと思います。
また、はじめのうちは妨害が多く出ることになるかと思いますが、成熟したチームになれば少なくなっていくのではないかと思います。
私自身も妨害リストについては、運用してないチームを経験したこともあり、さほど重要という認識はありませんでした。
今回、アジャイルトレーニングを受講し、本記事をまとめた事で考えを改めるいい機会になりました。
みなさまにも妨害リストを作成・運用する上で本記事がお役に立てれば幸いです。
