esm アジャイル事業部 開発者ブログ

永和システムマネジメント アジャイル事業部の開発者ブログです。

Problem が倒せない

こんにちは、悟空体験アクションRPG を楽しんでる nsgc です。

去年の今頃、Continuous KPTA について紹介しましたが、 KPTA をしていて、いつまでも Problem が残り続けることってありませんか?

私の関わったプロジェクトでは、何度もそういう場面に出くわすことがあります。
1, 2イテレーション位ならまだしも、何ヶ月前からあるの? というものがそのままになっていたりするのです。

なぜこういったことになるのでしょうか?

プロジェクトのコンテキストに依存するところも大きいのですが、これまでの経験したことや伝え聞いた内容からどういうケースがあり、そういう場合にチームはどうしたら良いのか、どうしていったのかを今回は挙げてみました。

Action が具体的じゃない

「KPTA の Action には具体的なものを挙げましょう」、という前提から外れてしまっているケースです。

「XXXの勉強をがんばる」とか「本番作業に気をつける」というお気持ち表明や意気込みだと何をしたら良いのか分からず、いつまでも不安は除けません。
「朝会の後 XXXの読書会をする」、「次回のメンテナンスでは本番作業の手順を用意する」というように具体的で行動しやすい Action にすると着手しやすく、 Problem を早く解決できるかもしれません。

解決まで時間がかかる

Action を実行しているけど、問題解決のための行動がほんの少しずつなので Problem の領域に残ったままになる、という場合もあるかもしれません。

この場合、全部解決するまで KPTA ボード上に残しておく必要は必ずしも無く、少しずつでも改善していっているのならそこから取り除き、別の所で進捗を把握しても良いかもしれません。
タスクとして切り出してプロジェクトの計画に組み込んでいるなら、そっちで成果を追うようにしましょう。

問題が強大すぎる

実現できない Try ばかりのため、着手できる Action が出ない場合は、その Problem はチームで解決できる範囲を超えているのかもしれません。
環境での制約によりどうしようもできない、お客様の社内ルールに手を入れる必要がある、といった場合はなかなか難しいことも多いです。

エスカレーションできるなら偉い人にお任せし、チームの問題からはいったん切り離した方が良いかもしれません。

本当は Problem じゃなかった

ここまでも見てきたように様々な理由で Action に着手できないことはありますが、実は Problem がそもそも Problem じゃない、もしくは Problem では無くなっている事はありませんか?
ふりかえりで挙げた当初は不安や課題であると認識していた。しかし、具体的な改善 Action はなされていないが時間が経つことで、学習や慣れなどを経たためか、何も気にならなくなったというケースです。

もし、チームで誰も困っていないのなら思い切って Problem から除くと良いかもしれません。
きっと、問題だと感じたら、また挙がってくるのですから。

解決のためのコストパフォーマンスが悪い

課題や問題の発生頻度が低く、困り具合が小さいのに対して、それに対する解決策のコストが大きい時にも Problem として残り続けるのかもしれません。

手軽な Action を抽出し実行するか、それが出来ないのならいっそチームとしては Problem を容認しても良いかもしれません。
私達には、もっと他に議論するべき問題がたくさんあるのです。

カイゼンサイクルがまわっていない

ビジネスサイドからの要求が多く、そのため目の前のタスクで手いっぱいになっているケースです。
Action に着手する時間がない。最悪な場合、ふりかえりの時間も取れない場合もあります。

一時的である場合はともかく慢性的にそういう状態になっているのなら、プロジェクト自体の立て直しが必要なのかもしれません。

最後に

残り続ける Problem はこうしてみると実に簡単な原因ばかりに見えますが、なかなかそのことに気付かないことが多いです。
ただ、あらかじめ今回あげたケースがあるということを頭の片隅に置いておくと、客観的に分析し対処できるのではないかと思っております。

もし、私と同じように Problem が残り続けてお困りの方は、上のようなケースにあてはまっていないか検討し、Problem をどうしていくかを考えてみましょう。