ドラッカー「マネジメント」はスゴ本

　マネジメントの原則がわかる、いわば原液。

　そこらで1,500円で売っている「ビジネス書」は、本書の一部をうす～くのばして「再利用」していることに気づく。広い世の中、「ビジネス書を読むのがシュミ」なんて変わった御仁もいそうだが、100冊のビジネス書より、1冊の本書を使うべし。

　しかしこれ、厚いんだよね。巨大な辞書といったカンジで鈍器にピッタリ。

　もちろん、図書館の期限内で読みきれるはずもなく、痛勤電車に持ち込めるはずもなく、むなしく延長と延滞の日々を重ねてきた。抄訳である「エッセンシャル版」は読んだのだが、ブツ切りの主張が脈絡なく連なっている。

　それが、ありがたいことに分冊版が出た。4分冊になっており、その第1巻を読む。おかげで、彼の考えを順番に追いながら、一緒に考え抜くことができる。すこし読むだけで「気づき」が山ほどでてくる。付せん使うなら、全ページに貼るハメになる（ヘタすると1ページに2つも3つも貼る）。

　だから、本書を「まとめ」ることはできない。目次でお茶にごすことも、ピンときた文句を切り貼りすることもしない。それは既に、どこかの「ビジネス書」がやってきたことだから。功なり名なり遂げて重役椅子に座っているオッサンが、1,500円の自著のためにコピペすることと一緒だから。

　なので、「わたしが陥っていた罠」の話をしよう。以下、本書のレビューではなく、「マネジメント」でガツンと気づかされたことの一例になる。

■1　生産性の罠

　仕事を効率化し、生産性を上げよという。

　そこで、Lifehack本を買ってきて→マネして→やった気になる。これが、「わたしが陥っていた罠」だった。同じ作業を、より短い時間で終わらせることが「生産性を上げる」と思っていた。

　たとえば、プログラムを組んでいるとき。このときは、「時間あたりの行数」が、生産性を測るしるべとなっていた。たくさん書けた日は、よくがんばったんだと自分を評価していた。あるいは、仕様書やマニュアルを書くとき。この場合、枚数が指標となっていた。大量の文書を作っては悦に入っていた。コード行数、文書量、モジュール、ファンクションポイント、クラス… なんであれ、「出来高」で測定するしかない。

　ここに、品質の要素を持ち込んでもいい。「たくさん書ける⇒品質が悪い」のではなく、より短い時間で書けるのだから、余った時間でレビューすればいい。生産性の高い人は、そうでない人が書くコードの量と同じだけの量を、書き上げるだけでなく、洗練させ、テスト済みまでできるのだ――そう信じていた。

　この罠にとらわれていたとき、たった一行の条件文で劇的に性能を向上させたり、1枚のエグゼクティブサマリーを作るのに一日かける人は、その生産性を測ることができなかった。時間と行数は、完全とはいわないまでも、ほぼ等価交換できるものと見なしていたからね。自覚せずとも、人月の神話をつくり出していたわけだ。

■2　生産性とは何か

　ドラッカーの答えはシンプルだ。「生産性は、貢献で測れ」という。そして、何がどう貢献したかについて、マネージャーが注意深く考え直すことで、生産性について正しく定義できると述べている。

　つまり、生産性を定義づけるものは、企業にとっての貢献であり、何を貢献と見做すかは、企業によって違うはず。ホントにコードを量産するだけで許されるような企業なら――もしあればだけど――単位あたりのコード量こそ生産性を測るモノサシとしていいだろう。

　この件を読んだとき、ピンときたのは、ゴールドラットの「ザ・ゴール」だ。危機的状況の工場を立ち直らせたマネージャーの話だ。そこに、こんなエピソードがある。

　―― 製造ラインの効率化のために、あるプロセスに最新鋭のロボットを導入した。しかし、抜本的な向上にいたらなかった。なぜか? マネージャーは試行錯誤の末、特定のプロセス『だけ』改善しても、その前後に仕掛かり中か在庫の山を築くだけにしかならないことに気づく。そして、むしろライン全体の効率を上げるには、最も遅いプロセス（ボトルネック）か、制約条件の一番厳しいプロセスに着目すべきだと悟る（たしか、鎖の強度はその最も弱い環に一致すると喩えていた）。

　そのあたりのスリリングな展開は「ザ・ゴール」を読んでいただくとして、全体最適化を測るための便利な言葉が「貢献」だ。たとえば、あるプロセス改善案をこう考えるわけだ――「その改善はどう貢献するのか?」ってね。きっと、二つの質問が出てくるはずだ。

　　1. 何がどうなれば「貢献」したことになるのでしょう?
　　2. 上の1. ができたかどうかは、どうやって測ればよいでしょう?

　すると、単位あたりの出来高だけでなく、品質や納期、リリース後の話にまで拡張するだろう。不具合率だけでなく、故障率や稼動量、MTBFや量あたりの受注額にも至るかもしれない。「この改善案で○% 増量できます」の発想だけで思考停止している限り、絶対に考えられない。

　そして、貢献を数値化するのはマネージャーの仕事だ。マネージャーは、「何が貢献になるのか」という目で仕事を見るようになる。必然的に、「何に対する貢献? ⇒ 貢献の対象となる目標は何か?」と自問するようになる。

■3　目標による管理

　「貢献」という言葉を使うとき、必ず「○○に貢献した/する」と目的語が必要だ。その目的語こそが、目標になる。そして、目標を決める際、「自社の事業は何か、将来の事業は何か、何であるべきか」という問いを元にせよという。

　この問いは、幾度も読み手に突きつけられる。既存の製品、サービス、業務プロセス、市場、最終用途、流通チャネルなどを体系的に分析し、現在も有用性を備えているだろうか? 今後も顧客に価値を届けているだろうか? 人口構成、市場、技術、経済の見通しに、適合しているだろうか?

　その答えが「ノー」なら撤退せよという。あるいはそれ以上資源を使わずにすます方法を考えろという。この問いを真剣に、体系的に追求し、その答えを受けて経営層が動く必要がある。

　残念ながら、わたしが働いている場所からそうした動きは見えない。しかし、経営層のデスクから個々の仕事場レベルまでトップダウンで振り下ろせる価値観は、本書を通じて見出すことができた。

　わたしの仕事は「システム屋」だから、先に述べた貢献を数字にして、「モノサシ」を設定すればいい。そして、半年ごとに当てなおすことで「生産性」を測定することができる。より少ないコード・不具合でもって、より多い受注額をまかなえばよいのだから。

　極端な話、受注したシステムを作らずに"持ってくる"のが、最も「貢献している」ことになる。あるいは、基幹系だけを共有化させ、あとはカスタマイズを別料金で取る「口利き屋」か（PROBANK?J-BOX21?）。さらに、システムってーのはべつにITだけで成り立っているだけじゃないから、そのオペレータやデータセンターも「込み」で提供するほど一体化するのか。

　社畜の妄想はさておき、「生産性の罠」に気づいたのだから、めっけもの。そんな「罠」がもりもり見つかるので、いわゆるエグゼクティブクラスでなくても読むべし。さらに、本書を読むことで「何を価値として提供するのか」という見方を得る。

　1,500円のビジネス書を100冊読むよりも、本書を使え。