NaeNote

読者です 読者をやめる 読者になる 読者になる

NaeNote

気楽に生きたい外資コンサルのブログ

管理のための管理のための管理のための…管理で消耗し続ける大企業病の悪循環

仕事術 仕事術-生産性
このくらいシェアされています
スポンサーリンク
【お知らせ】 12月12日(月)まで!Amazonが本気の割引セール「CYBER MONDAY SALE」を開催中。会場はこちら!

付箋 フローチャート ホワイトボード 黒マジック 開発 予定

こんにちは、NAEです。

なにごとも管理は大事です。しかし管理そのものは価値を生みませんし、管理自体の工数も馬鹿になりません。

しかしながら、先を見通したい、細かいところまで把握したい、そうじゃないと怖い、という思う人がいます。その結果管理ばかりに走ってしまうのはいかがなものでしょうか。

つい先日、仕事でそのような状況を目の当たりにしたので、お話したいと思います。

今回はそんなお話。

プロジェクト管理

コンサルティングの仕事は案件=プロジェクト単位で動きます。

プロジェクトには担当範囲(スコープ)があり、範囲内におけるゴールがあり、それを目指すためにQCD(Quality、Cost、Delivery)の視点で管理を行います。(細かく言うとEarned Value ManagementやらCPIやらいろいろありますが、ここでは割愛します)

  • Quality:十分な品質の成果物を
  • Cost:予定されたコスト内で
  • Delivery:納期までに提出する

これらを満たすために、合理性、実現性、経済性を満たすためスケジュールを立てます。

www.naenote.net

そして作業がスケジュール通りに進んでいるか、立てたスケジュールを鑑として定点観測します。

それがプロジェクト管理(進捗、課題、リスク管理)です。進捗が悪ければ、その原因や阻害要因、将来的な阻害要因となりうるものを明確にし、対策を打ちます。

www.naenote.net

管理は「見える化」で先を見通す大事な仕事だけど

さて、プロジェクト管理を行う理由ははただひとつ。プロジェクトがQCDを満たして円満に終わることを確かめるためです。

だからこそ進捗を見える化し、課題はすぐに解決しなければならず、リスクは見えた瞬間に露払いするのです。

しかし、見える化する期間が長いほど、そして見える化する粒度が細かいほど、プロジェクト管理の工数は等比級数的に爆発していきます。

したがって、見える化する範囲や粒度はある程度の「決め」が必要です。

必要、なんですけどね・・・。

管理

さて、ここで登場するのは、以前こちらの記事で登場した古きよき伝統的な日本企業であるA社です。

www.naenote.net

ぼくは主に担当しているプロジェクトがあるので、そちらをメインに持つかたわらA社の案件も見ている状態なのですが、驚きました。

そう、A社案件のお題は、IT戦略の立案から変革の実行計画までを短期でゴリッと作ること。

このような戦略系の案件は「意思決定」が全てです。そのため、キーパーソンの突然の出張による会議の延期や経営層の鶴の一声による方針調整など、「人」の要素による変動がものすごく大きいんです。

それ以外にも、インプット資料を受領できるタイミングや手に入る情報粒度など、さまざまな要因で作業プランが頻繁に前後します。

そのような変動リスクを吸収できるよう、プロジェクトのマイルストンは守りつつも細かな作業スケジュール柔軟に組換え可能な態勢にしておく、という濃淡の付け方が非常に重要です。

以上の性質からして、戦略系プロジェクトにおいて日次レベルでの作業計画と作業間の依存をすべてMS Projectで管理するというのは自殺行為の何者でもありません。

それを伝えても「我が社ではこれがルールになっている」「他の案件もMS Projectで管理している」の一点張り。

まさにルールに縛られて本質を見失う。この時点で本当に価値を生む仕事に使える時間が削られていきました。

管理のための管理

そして、悪夢は現実に。

検討のインプットとして提供依頼をしていた情報が出てくるのが想定より遅かったのです。そしてあろうことか、情報の粒度も依頼したものより相当粗く、データの品質も劣悪。これでは十分な品質のアウトプットを出せません。

そのため、前提変更による作業スケジュール変更という位置付けで計画を組み直しました(嫌々ながらMS Projectで)。

その旨を先方の担当者に打診したところ、彼が求めてきたのは

  • 変更内容を部長に説明するための会議を開きたい
  • 当会議の調整にあたり、一度話をしたい

つまり、会議を開くための会議を開く。まさに管理のための管理。なんだこりゃ。

管理のための管理のための管理

A社ですので、会議の日程調整は当然エクセルです。

会議を開くための会議では、そのエクセルの内容を確認することになります。

すると、そのエクセルをどのようなタイミングで作るのかの見通しがほしいとおっしゃる。その説明も求めてくる。

つまり、作業スケジュール変更を説明する会議を開くための日程調整ツールであるエクセルについて、その作成プランを提示せよ、と言っている。

何を言っているのかわからないですね。言わば、管理のための管理のための管理です。

書いていて吐き気がしてきました。

管理のための管理に走る大企業病の理由は、リスクへの恐怖心

ここまでくるともはや病気です。大企業病としか言いようがありません。

管理によるリスク低減効果とかけるコストのバランスが完全に破綻しています。

リスク回避に振りすぎて管理オーバーヘッドが極大化してしまっています。

担当者や部長陣はおそらく細かなレベルまでの見通しがないと怖いのではと思うものの、あまりにも怖がりすぎていやしませんか。

管理作業で食いつぶされてゆく手持ちの工数たちが見えませんか。

管理のための管理ばかりでは仕事は全く進まない

管理そのものは価値を生みませんし、管理だけでは仕事は進みません。管理は必要十分な精度にとどめ、正味の仕事になるべく多くのリソースを割かなければ、予定通り進むはずだったものも進まなくなります。

スケジュールが遅延、もしくはやむを得ない事情で変更を余儀なくされた場合、その原因とリカバリプランを提示するのは当然ですが、その説明や後続の管理作業に工数を吸い取られるとリカバリできるものもできなくなってしまいます。

おたくを信頼していないからミリミリ細かく管理するのだ、と言われればそれまでですが、準委任契約でそれをされた日には「じゃ本当に成果物にコミットしないですけどいいですよね、準委任なので」と言いたくなります・・・。

が、それで困るのはA社であるはず。定められた期間内に目指すアウトプットが得られなくなるのは発注元であるA社です。

結局は自分が怖がっているせいで自分の首を絞めているだけであることに気がついてほしい。

というかもともとA社のデータ提出遅れがすべての原因なんですけどね・・・。そこを棚に上げてリカバリプランを出せと言っているのもモヤつくポイントでもあります。

まとめ:管理のための管理はやめて、リスクテイクする覚悟を決めなさい

以上、管理工数はほどほどに、正味の仕事にリソースを割く方がよほど有意義だというお話でした。

説明責任があるのはわかります。が、身から出た錆でリスクを背負わなければならないなら、実利を得るために覚悟を決めるべきでしょう。

にもかかわらず管理のための管理に走るのは、怖がるがゆえに自分の足を食べるようなもの。身を滅ぼすだけですよ。


とはいえ、行き過ぎない適切な管理=見える化には、組織の潜在能力を引き出すチカラがあります。管理をしないことは、逆に罪なのです。

www.naenote.net

スポンサーリンク