進捗はなぜ80%で止まるか

某TLで進捗率が信用できないとか云々とか流れていて、そう言ったことは前に書いたなとこれ

 

fumisan.hatenadiary.com

 

を思い出したのです。で、ほら、流れ的に作業プロセスの重み付けとか作業プロセスの完了条件を明示的にしないとねだとか思うのです。で、そうしたことのレスをつけようと思っていたんですが今回はちょっと流れが違ったのでそれはそれで興味深いなぁ、と。

 

「進捗率の問題は、作業の進捗率の粒度がプロジェクトチームの中でバラバラだからじゃないのか」


「エンジニアによって方向する進捗率が変わるのは心理的安全が確保されていないから最初は順調に進捗しているように報告していて80%で実態と乖離し始めて実績が追いつくまで(80%で)止まるのではないか」


「(心理的安全が確保されていないエンジニアは)正直に進捗を報告することにメリットを感じていないのではないか」


「結局、進捗の見える化をするしかないのでは」

 

などの意見が出てきて(表現は大分言い換えてますよ)、まあそうだよねぇという感じになったのですけれど、割と世間では事を始める際に作業の進め方を合意してから始めないんでしょうか、と素朴な疑問を感じたんですが。

もちろん、中にはそう言った事をやって始める方もおられましたが流れ的にはやりながら修正する方が多いような(感覚で)。

実態をさらけ出すカンバン

このブログのあちらこちらのエントリで書いてきているのはプロジェクトとしてチームの活動をするなら

 

「自分がやっていることを見えるようにしよう」

 

ということです。在るが儘に誰が見ても同じように解釈できるように実情を曝け出しましょう、と。

なのでカンバンなんですよね。それもホワイトボードや壁でやるカンバン。

そういえばどのくらいカンバンについて書いたんだろうとキーワード検索してみたら…

 

fumisan.hatenadiary.com

 

どれだけカンバンスキーなのかって自分でも思いました。まる。

カンバンは粒度を揃える躾

 物理カンバンはチームメンバの視界に入るようにするのは、チームの活動の作業プロセスを揃えるのはもちろんですが、揃えなければメンバによる自己判断が混入してしまい、結果的に進捗のメジャーが作れなくなってしまうため、プロジェクトの進捗の正確性が確保できなくなってしまうという問題を回避するという背景も含まれています。
それを対応するための物理カンバンなのです。

 これってエンジニアにしてみたら自分の経験してきた進捗の捉え方からチームのというかプロジェクトの進捗のルールに置き換えなさい、というお作法を押し付けるように感じられるかもしれませんが、そう感じて正解です。

だって、一人ひとり違う経験をある時期一緒に働くメンバで統一のルールで働くことを強制しているのですから。

つまり、メンバをプロジェクトのルールで躾をしているのと同じです。

ただ、どこのプロジェクトに行ったとしても、あとあと役に立つことがあります。それは進捗の完了によりはじめて作業は完了状態に遷移するということを物理カンバンで覚えることができるということです。

委託先には躾ではなく管理標準として

 注意して欲しいことは、業務委託先と一緒のプロジェクトチームの場合は、委託先には躾とはいえないのでプロジェクトの進捗管理の標準です、として説明しましょう。

業務指示はメンバにはできないので、管理ルールとして伝えて遵守てもらうイメージですね。

 

www.amazon.co.jp