課題 阿藤さんが1.0、伊藤さんは1.3、江藤さんは0.7の処理能力がある。 チームのひと月当たりの処理能力を1.0とした場合、将来懸念されることを書き出しなさい

1人で作業をしているのであれば、作業が遅れても能力の問題なのか作業見積もりの甘さが起因しているかは割と曖昧に処理されるけれど、2人、3人と人数が増えてチームになると人の比較が生じるので無意識に作業の処理能力が比較されるようになります。阿藤さんを1.0とした場合、伊藤さんは1.3倍、江藤さんは0.7倍と。

処理能力をチームの単位で見るように視点を変えると、チームに在籍するメンバ全員の処理能力を評価することになります。ある期間の処理能力、通常は月を単位にどのくらいの処理能力があるかを定量化することになります。

ひと月あたり、阿藤さんが1.0、伊藤さんは1.3、江藤さんは0.7の処理能力がある場合、チームとしては3.0で、

一人当たりにすると

3.0/3人=1.0

となる、と思うわけです。

現場でもそうなのか、ということが問いかけなのです。

課題

阿藤さんが1.0、伊藤さんは1.3、江藤さんは0.7の処理能力がある。

チームのひと月当たりの処理能力を1.0とした場合、将来懸念されることを書き出しなさい

さあ、どうでしょうか。簡単すぎますかね。図式化してみましょう。

阿藤さん　1.0　***** *****
伊藤さん　1.3　***** ***** ***
江藤さん　0.7　***** **

伊藤さんはチームのひと月当たりの処理能力1.0より0.3多く処理できるわけです。でも、江藤さんは0.7とチームのひと月当たりの処理能力より0.3少ない作業しかできないわけです。

多くの人は、だったら伊藤さんが江藤さんの足らない0.3をカバーすれば解決じゃないかと思うでしょう。

ベロシティで考えてもそうなりますよね。バックログが丁度3.0になるように作業見積もりがハマれば、ですけど。

ところで、処理の単位が１であったとしたらどうなるのでしょうか。

阿藤さん　1.0　***** ***** |　　 完了！
伊藤さん　1.3　***** ***** | ***　完了…　0.3はアイドルしてしまう
江藤さん　0.7　***** **　 | 　　未完了…　0.7でひと月終わってしまう

なんと、江藤さんが担当する作業は完了しないのです。終わらすためにはあと0.5月程度が必要になるのです。ひと月当たりで0.7の処理能力なので残り0.3を処理すのには、あと半月は必要になりますね。

深く考えずに平均でチームの処理能力を設定してしまうと処理能力の高い伊藤さんに負荷がかかるし、江藤さんには処理能力が遅いというプレッシャーが掛かります。

対策としては、次の策があげられるでしょう。

• 作業を分解する。
• 作業を標準化する。
• メンバであれば誰でも予定作業ができるスキルレベルを身につける。

作業を分解するのはメンバの処理能力の違いをカバーするためです。作業を標準化するのはメンバの誰が作業をしても同じ作業品質の結果を得られるようにするためです。メンバが同じスキルを身につけるのは、この作業は阿藤さんしかできないというボトルネックを作らないためです。

ザ・ゴール ― 企業の究極の目的とは何か