「ヒーロー」に注意

どこの企業にも、大抵、「仕事ができる人(ヒーロー)」がいます。一見、誰よりも企業に貢献していそうなヒーローですが、使われ方によっては、作業の流れを悪くしてしまうこともあるんです。

ITの現場でよく見られる例を挙げると、ヒーローがいないと、どのように動いているのか分からないアプリケーションや、スクリプトが大量に生産されているという状況があります。このようなヒーローは、どのように生まれるのでしょうか。

ヒーローは仕事ができるために、皆がヒーローに仕事を任せがちになります。また、ヒーローは仕事ができるので、誰の助けも必要とせずに、一人で仕事をこなしてしまいます。これが繰り返されると、ヒーローにしか、どうやって動いているか分からないものが、大量生産されることになります。

そうやって生み出されたアプリケーションやスクリプトは、ヒーローにしか仕組みが分からないために、それが壊れたときや、新しい機能を追加したいとなったときに、またヒーローの力が必要になります。

こういう状況が続くと、ヒーローがいないと進まないプロジェクトがいくつもでき、ヒーローはいくつものプロジェクトに関わることになります。

この時点で、もし、ヒーローが居なくなったら、皆が困るのは言うまでもありません。でも、それだけではないんです。実は、もうこの時点で、居ようが居まいが、ヒーローは作業の流れを悪くしているんです。

例えば、ヒーローがA、B、Cの三つのプロジェクトに関わっているとします。

ヒーローが、プロジェクトAの仕事をしているとき、プロジェクトBとCの進行はどうなるでしょうか? ヒーローがプロジェクトAの仕事を終わらせるのを待たなければなりません。ヒーローがプロジェクトBの仕事をしているときは、同じように、プロジェクトAとCの進行が止まります。

それに追加して、ヒーローが本番環境の問題解決も請け負った場合、その問題の解決中は、全てのプロジェクトの進行が止まってしまいます。

どの仕事もヒーローが必要なため、ヒーローがいないと仕事が進みません。このような状況だと、どんなに優秀だったとしても、ヒーローは作業の流れの妨げ、つまりボトルネックになってしまうのです。

IT運用についての小説、『The Phoenix Project1』に出てきたブラントが、ちょうどこのようなヒーローに当たります。以下では、同書の物語内でも使われた、ヒーロー対策方を紹介します。

このような状況を生み出さないためには、または、このような状況から抜け出すためには、ヒーローの活動範囲を制限しましょう。

企業にとって、一番大切なプロジェクトはどれでしょうか。ヒーローは、その一番大切なプロジェクトだけに関わらせるようにしましょう。問題の解決も、他の人が請け負いましょう。ヒーローに助けを求めてもいいですが、必ず、問題解決そのものは、担当者がするようにします。ヒーローは、横から助けるだけです。

効率が悪いように思えるかもしれませんが、こうすることによって、一番大切なプロジェクトの進行を確保できる上に、他の社員の教育にもなります。

ヒーローに教育された社員たちは、やがて、自分一人で仕事をできるようになります。そうなれば、全体でこなせる作業の量は増え、流れも早くなり、ヒーローも、最大限に力を発揮できるようになります。実際の状況によって、どれほどヒーローの活動範囲を制限するかは変わってきますが、どの状況であっても発想は同じです。

「仕事ができる人(ヒーロー)」が、実は、作業の妨げになっているかもしれません。それを防ぐため、もしくは、その状況から抜け出すためには、ヒーローの活動範囲を制限し、他の社員の教育を促さなければなりません。そうすることによって、大切なプロジェクトの進行を確保できる上に、他の社員の教育にもなり、全体でこなせる作業の量は増え、流れも早くなることでしょう。

<関連書籍>

  1. Gene Kim, Kevin Behr, George Spafford (2014)『The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win』It Revolution Press(英語の本です。日本語では、『The DevOps 逆転だ!』として出ているようです。)

Shogo Wada

楽しさと実用性の両立が好き。プログラマー。