タイトル通り、TCPフロー制御アルゴリズムを(人間の)マネージメントに応用した場合、
どのような原則が得られるか、ということを示したエッセイ。
あげられているのは以下のような原則。
- 完全に終わったという報告しか信用しない(選択的あるいは否定的な確認応答を返せない)
- 余力があるかどうかを、部下にしょっちゅう自己申告させる(スライディング・ウィンドウ)
- 余力があると言った奴でも、実績の無い奴は信用しない。しかし、可能な限り速く、能力一杯までタスクアサインする(スロースタート)
- 部下の仕事の速さを測定して、状況再確認のタイミングに生かす(RTTの測定とタイムアウトの計算)
- 納期に遅れた(タスクを落とした)奴の信用度は一気に落とす。しかし、タスクを落とさない、ぎりぎりの能力を速やかに見つける(輻輳回避アルゴリズム)
ここから引き出すことのできるマネージメントルールは以下の通り。
- 終わったという報告以外は信用しない
- 「順調です」や「予定通りです」、などの調子の良い途中経過は無視する
- 何も報告が無いのは、できていないと判断する
- 余力があるかどうかを、部下にしょっちゅう自己申告させる
- 余力があるという言葉は、半信半疑で聞く
- 余力が無いという言葉は、信用する
- 余力があると言う部下でも、実績の無い相手は信用しない
- 徐々にタスクアサインを増やして様子を見る(能力を見極める)
- のんびりしてはいられないので、タスクアサインの量は倍々で増やして、能力一杯を素早く見極める
- 見積りのために、仕事の速さを測定して、平均値と偏差を常に荷重補正して知っておく
- 嘘っぽくても、正規分布を描いて、平均値を中心に平均偏差の4倍の範囲に99%以上が収まることを示して、それを越えて報告が無い場合、遅れていると見なすと宣言する
- 納期に遅れた(タスクを落とした)部下の信用度は一気に落とす
- 以前できていた1/2ぐらいのところまではできると仮定してタスクアサインする
- それ以上に負荷をかけるとまた裏切られる可能性があるので、徐々にアサインを増やして様子を見る
面白い。すごくドライな気がしないでもないが、
パフォーマンスのためにアルゴリズムにかけるのと同じくらいの設計努力で、
マネージメントルールもきちんと検討することも重要なのかもしれない。
面白いですが、人間に与えるタスクの量は、精度も可変幅もそれほど大きくないところが問題ですかね。あとは、納期ミスのペナルティが大きいような仕事で、一挙に2倍の仕事を与えて大丈夫かとか。
2のべき乗でなく、もっと小さな底を使うと良いかも。