satoryuの日記

忘れっぽいから覚えてるうちに書いておかないと。

「新訳 科学的管理法」を読んだ。

100年以上前の、しかも工場での生産を対象としたマネジメントの本なのだけど、いろいろマネジメントについて考えることができた。

|新訳|科学的管理法

|新訳|科学的管理法

昨年くらいからエンジニアリングマネージャーというのが流行っていて、そもそもマネジメントとは何なんだろうか、という疑問からこの本を見つけた。 マネジメントと聞くと、ドラッカーのマネジメント なんかを思い浮かべたのだけれど、その本の序文にも科学的管理法について言及されている。なので、この本の副題にあるように、「マネジメントの原点」という本だ。 この本では、それまで良しとされてきたマネジメント手法の問題、労働者の怠惰を挙げ、それに対して科学的管理法を提唱し、それを導入した3つの事例研究を紹介している。

科学的管理法

科学的管理法以前は、「自主性とインセンティブを柱としたマネジメント」が良しとされていた。自主性とは、労働者が自ら仕事について良くしていくという自主性を指していて、そしてインセンティブとは、その自主性の結果による成果に応じて賃金を与えるなどの報酬を与えることを指している。 読んでいてこれで良さそうに思ったのだけれど、ところどころに「労働者は十分な教育を受けていない」といったような記述があったたので、自主的に進めることに限界があったという前提があるのだと思う。 しかし、その管理法の下で労働者の怠惰が蔓延していたことが指摘されている。「効率が良くなり一人当たりの生産量が多くなると職を失うという迷信、時間給であったが労働時間は正確に計測されていなかったことがあったため、ある程度働くことが最善となっていた。 なおかつ、そのような状況にもかかわらず、この管理法が管理者のさじ加減で実施されて、口伝で広められていた。

それに対してテイラーは、科学的管理法における管理者の責務として、

  1. 労働者1人当たり生産量や作業時間など測れるものを様々に計測し、その因果関係を導き出し、
  2. その上で、生産量を最大化するような作業手順の作成、教育、さらには適切な人材の採用を行い、
  3. 労働者と協力しながら最適な手法を現場に浸透させ、
  4. なおかつ責任についても、労働者に負わせるのではなく、適切に管理者も負うこと

を挙げている。その上で、インセンティブについても適切に賃上げやボーナスを与えていくことを推奨している。

感想

第一章が上に書いたように科学的管理法についてと、それが生まれた背景について書かれていて、第二章が事例研究の紹介だった。 自分がいるようなソフトウェア開発への直接の適用は難しい。けれど、マネジメントの原点でもあり、いろいろと考えるための出発点としては非常に面白かった。

適用が難しいと感じたことについて書いてみる。

  • 事例研究にある労働者の作業は生産量や作業に関する数字が計測可能であり、それが成果にほぼ直接結びついている。例えば、検品したベアリングの数や、スコップのサイズとそれですくう量とか、レンガの数や積んでおく資材の距離とか。一方でソフトウェア開発では、これが難しい。行数、カバレッジ率、リードタイムにかかる時間など測れるものはあるが、それらが直接ビジネス価値につながるかというとそうではない*1
  • 作業者1人1人について個別にマネジメントを行うことで、全体の生産性も上がっていくということに基いているが、これらは個別の生産量の総和がチーム*2の生産量になるためだと考えられる。ソフトウェア開発ではやはりこれも難しいので、個別ではなく、チーム単位でマネジメントを実施しないといけないのではないだろうか。
  • 科学的管理法においては、管理者が労働者の作業内容について計測可能な項目と生産量の関係を研究を行う。これは、先に説明したように労働者の自主性では限界があるためだと思う。しかし、現在においては、労働者が自身の作業について計測・研究できないことも無いと思う。
  • また、作業内容についてプランを作るのも管理者の仕事とされている。これはマイクロマネジメントっぽい記述にも見えるが、前と同じ条件の元で考案されたのではないだろうか。もし現在において作業内容を管理者が作成するのであれば、現在のソフトウェア開発に関連する技術について理解している必要がある。
  • そして、上に挙げたように、現在においては個人に対してではなく、チームに対してのマネジメントが必要なので、技術だけでなく人や集団の性質についても理解している必要がありそう。

つらつらと書いてみたのだけれど、マネジメントはそれだけで大変な仕事であるし、相当勉強しなければいけないと思った。 もしこれをエンジニアチームを対象とした場合にどうなるか、ということがきっと昨今のエンジニアリングマネージャーというブームなのかな、と思う。ただでさえ技術の移り変わりやビジネスの環境も変化が激しいので、それらをキャッチアップするのも非常に骨が折れそうなのは目に見えている。

この本の事例研究で書かれていた内容はいずれも、単なる生産量を上げることのためではな、健全な労働環境のもとでの生産量の最大化である。 要するに、労働者のことを、その人の傍で徹底的に観察しているし、それを実施できるための信頼性の構築も含まれている。 どうあれ、せめてこの本で書かれているようなマネージャーの目的が達成され、不本意な人間関係が生まれてしまうことが無ければ良いのかな。

「雇用主に限りない繁栄をもたらし、かつ働き手にも最大限の豊かさを届けるのがマネジメントの主な目的であるべきだ」などという主張は、あまりに当然すぎて、あらためて述べるには及ばないと思うかもしれない。しかし、産業界を広く見渡してみると、雇用主も働き手も、相手と協調するよりむしろ敵対しようとする空気が強い。どちらの側でも大多数の人々が「共通の利害で結ばれた関係を築くのは不可能だ」と考えていることは、火を見るよりも明らかである。

要するに、エンジニアリングマネージャーは難しい*3

*1:受託だと納品までどれだけコストを下げられるか、を考えればいいのだから容易なのだろうかとも考えた。しかし、顧客が納品物でビジネスがまわらなかったらリテンションはありえないので、そこで破綻するのだろうから、やはり難しいのではないだろうか。

*2:この本ではチームについては全く触れていないが、同じ作業を複数人で集まって行っているような記述は書かれている。

*3:雑な締め方w