Impediments（障害事項）への対応
みなさんこんにちは。@ryuzeeです。
Impediment（障害事項・妨害事項）について、海外で良い記事がいくつかあったのでご紹介しましょう。
Impedimentとはスクラムでよく使う単語で、プロジェクトを進めていく上での障害や妨害になる事項のことです。 人的なもの、プロダクトに関するものなど全てを含みます。 例えば以下のようなものが一例になります。
- 未完了なままの作業
- 情報の不足
- 繰り返しの作業
- 待ち
- 依存先の欠如
- 割り込み
- バグ
- 官僚主義
- 間違った、もしくは不明瞭なコミュニケーション
- 意思決定がなされない
- 間違った推定
- 時間がたりない
- パーツがない
- よく知らない新しい技術
などなど、ほかにもたくさんあります。
当然のことながら、これらの障害事項を把握することは大事ですし、日々の活動の中で優先順位をつけて改善していかなければいけません。
したがって、"The biggest impediment“にあるように**「障害事項を除去することにフォーカスしないことが一番の障害」**ということになります。
障害事項にフォーカスしていないことの兆候としては、以下のようなことが挙げられます。
- 公式な障害事項の一覧が無い。またはどこにそれがあるか分からない
- 障害事項に解決の優先順位を付けていないか、優先順位付けがうまくない
- ふりかえりにおいて良かったことばかりにフォーカスし一番の障害事項にすらフォーカスをあてていない
- ふりかえり後に障害事項のインパクトを減らすためになんらアクションをとっていない
- 障害事項の除去に関するプロセスについてなんら熟考していない
- 誤った障害事項を前提にして作業しすぎている
- 組織の障害事項の管理手法に透明性がない
- 障害事項の除去のために役立つはずのスクラムマスターが適切に配置されていない
- 「なぜこんな障害事項の中で働かなきゃいけないの？本来やるべき仕事をすべきだ」といったひとごとのようなコメント
スクラムに限らず、アジャイルな開発手法においては、短期間のタイムボックス化とそのボックス毎のふりかえり、検証、改善のループが不可欠です。 障害事項をためてしまう、という状況は改善のループが不足していて、生産性の向上は見込めません。
プラクティスを真似するのではなく、思考方法を真似していく必要があるのです。
