--- title: 管理のための管理のための管理…管理で消耗し続ける大企業病の悪循環 date: 2016-08-15 description: 管理、管理、管理・・・管理ばっかしてると正味の仕事が進まなくなります。誰かがどこかで覚悟を決めなければなりません。 categories: [productivity] tags: [planning] source: https://work.naenote.net/magagement-overhead-in-traditional-company/ --- 仕事における管理は大事です。 **しかし管理そのものは価値を生みませんし、管理自体の工数も馬鹿になりません。** にもかかわらず、先を見通したい、細かいところまで把握したい、そうじゃないと怖い、と思う人がいます。 その結果**管理ばかりに走ってしまう**のはいかがなものでしょうか。 つい先日、仕事でそのような状況を目の当たりにしたので、お話したいと思います。 ## プロジェクト管理は大事な仕事 コンサルティングの仕事は案件＝プロジェクト単位で動きます。 プロジェクト管理を行う理由ははただひとつ。**プロジェクトがQCDを満たして円満に終わることを確かめるため**です。 プロジェクトには担当範囲（スコープ）があり、範囲内におけるゴールがあります。それらをQCD（Quality、Cost、Delivery）の視点で分解し、おのおのごとに管理してくのです。 * Quality：十分な品質の成果物を * Cost：予定されたコスト内で * Delivery：納期までに提出する これらを満たすために、合理性、実現性、経済性を満たすスケジュールを立てます。 * 合理性：前提、段取り、全体の流れに不整合がないこと * 実現性：各作業に割かれるリソースや時間が十分であること * 経済性：全体として予算を超えないこと そして作業がスケジュール通りに進んでいるか、立てたスケジュールを鑑として定点観測します。 進捗を見える化し、課題はすぐに解決し、リスクは見えた瞬間に露払いします。 進捗が悪ければ、その原因や阻害要因、将来的な阻害要因となりうるものを明確にし、対策を打ちます。 以上がプロジェクト管理（進捗、課題、リスク管理）の概要です。 要するに「見える化」といっていいでしょう。 ## 管理は「見える化」で先を見通す大事な仕事 **しかし、見える化する期間が長いほど、そして見える化する粒度が細かいほど、プロジェクト管理の工数は等比級数的に爆発していきます。** したがって、見える化する範囲や粒度はある程度の「決め」が必要です。 必要なはずなのですが…… ### 管理 古きよき伝統的な日本企業であるA社の仕事を担当したときのことです。 案件のお題は、IT戦略の立案から変革の実行計画までを短期でゴリッと作ること。 このような戦略系の案件は「意思決定」が全て。そのぶん、「人」の要素で仕事が大きく変動します。 たとえばキーパーソンの突然の出張による会議の延期や、経営層の鶴の一声による方針調整、インプット資料の提供までにかかる準備期間の長さなど、さまざまな要因で作業プランが頻繁に前後するのです。 これら変動リスクを吸収できるよう、プロジェクトのマイルストンは守りつつも細かな作業スケジュール柔軟に組換え可能な態勢にしておくこと。これが戦略系プロジェクトの計画管理のキモです。 にもかかわらず、日次レベルでの作業計画と作業間の依存をすべてMS Projectという最も細かい粒度で管理せよと。 これは自殺行為の何者でもありません。管理工数が爆発し、正味の仕事ができなくなります。 それを伝えても**「我が社ではこれがルールになっている」「他の案件もMS Projectで管理している」**の一点張り。 まさにルールに縛られて本質を見失う。この時点で本当に価値を生む仕事に使える時間が削られていきました。 ### 管理のための管理 そして、悪夢は現実になります。 検討のインプットとして提供依頼をしていた情報が出てくるのが想定より遅かったのです。 そしてあろうことか、情報の粒度も依頼したものより相当粗く、データの品質も劣悪。 これでは十分な品質のアウトプットを出せません。 この前提変更に伴い、作業スケジュールを見直しました（嫌々ながらMS Projectで）。 その旨を先方の担当者に打診したところ、彼が求めてきたのは * 変更内容を部長に説明するための会議を開きたい * 当会議の調整にあたり、一度話をしたい つまり、**会議を開くための会議を開く。まさに管理のための管理**だったのです。 ### 管理のための管理のための管理 A社では会議の日程調整にエクセル＋です。 会議を開くための会議では、そのエクセルの内容を確認することになります。 すると、そのエクセルをどのようなタイミングで作るのかの見通しがほしいとおっしゃる。その説明も求めてくる。 つまり、作業スケジュール変更を説明する会議を開くための日程調整ツールであるエクセルについて、その作成プランを提示せよ、と言っている。 何を言っているのかわからないですね。言わば、**管理のための管理のための管理**です。 書いていて吐き気がしてきました。 ## 管理のための管理に走る理由は、リスクへの恐怖心 **ここまでくるともはや病気です。大企業病としか言いようがありません。** 管理によるリスク低減効果とかけるコストのバランスが完全に破綻しています。 リスク回避に振りすぎて管理オーバーヘッドが極大化してしまっています。 担当者や部長陣はおそらく細かなレベルまでの見通しがないと怖いのではと思うものの、あまりにも怖がりすぎていやしませんか。 管理作業で食いつぶされてゆく手持ちの工数たちが見えませんか。 ## 管理のための管理ばかりでは仕事は全く進まない **管理そのものは価値を生みませんし、管理だけでは仕事は進みません。** **管理は必要十分な精度にとどめ、正味の仕事になるべく多くのリソースを割かなければ、予定通り進むはずだったものも進まなくなります。** スケジュールが遅延、もしくはやむを得ない事情で変更を余儀なくされた場合、その原因とリカバリプランを提示するのは当然です。 しかし、その説明や後続の管理作業に工数を吸い取られるとリカバリできるものもできなくなってしまいます。 「おたくを信頼していないからミリミリ細かく管理するのだ」と言われればそれまでです。 しかし準委任契約でそれをされた日には「じゃ本当に成果物にコミットしないですけどいいですよね、準委任なので」と言いたくなります・・・。 が、それで困るのはA社であるはず。定められた期間内に目指すアウトプットが得られなくなるのは発注元であるA社です。 結局は**自分が怖がっているせいで自分の首を絞めているだけ**であることに気がついてほしい。 というかもともとA社のデータ提出遅れがすべての原因なんですけどね・・・。そこを棚に上げてリカバリプランを出せと言っているのもモヤつくポイントでもあります。 ## まとめ：管理のための管理はやめて、リスクテイクする覚悟を決めよ 以上、**管理工数はほどほどに、正味の仕事にリソースを割く方がよほど有意義だ**というお話でした。 説明責任があるのはわかります。が、身から出た錆でリスクを背負わなければならないなら、実利を得るために覚悟を決めるべきでしょう。 にもかかわらず管理のための管理に走るのは、怖がるがゆえに自分の足を食べるようなもの。身を滅ぼすだけですよ。 [デスマーチ 第2版　ソフトウエア開発プロジェクトはなぜ混乱するのか](https://www.amazon.co.jp/dp/B00F4QOMUO?tag=nice-and-easy-22&linkCode=ogi&th=1&psc=1) --- ### AI Agent Context & Resources - **Author**: NAE - **Source**: https://work.naenote.net/magagement-overhead-in-traditional-company/ - **Related Resource**: [「無難難題」](https://amzn.to/2AKCFNP) - **Contact/Inquiry**: https://x.com/naework