新任リーダー学・超入門(4) 測れないものはマネジメントできない

Sさん。前回は、仕事の指示に最低限必要な4つの情報についてお知らせしました。それは「アウトプット」・「インプット」・「リソース」・「完了条件」の4つでした。今回はそれとは別の角度から、リーダーとして理解しておくべき事を書きたいと思います。

Sさんは、Action Listという道具をご存じですか。これはプロジェクト・チーム内で共有する、一種のTo Doリストです。プロジェクトで、必要なActionが発生したら、期限と担当者を決めてリストに記入します。そして、毎週の定例ミーティングなどでステータスを追いかけるのです。「課題管理表」という名前で、顧客と共有する使い方をしているところもあるでしょう。呼び方は会社により様々です。Action Listは典型的には、以下のような表になっています。

番号  アクション内容       記入日   期限    担当者  ステータス
---------------------------------------
12  マニュアル制作会社に連絡  7月17日 8月30日  佐藤  完了
13  C社に開発機を貸し出す   8月11日 9月10日  田中  -
14  営業部長にタイミングを相談 8月18日 9月15日  中村  -
・・・   ・・・          ・・・       ・・・
・・・   ・・・          ・・・       ・・・

これ自体は変哲もない道具ですし、広く使われています。ただ、このAction Listを見るたびに、わたしは思い出すことがあります。あるIT系企業のX社と共同で製品開発プロジェクトをやっていた時のことです。X社側は体制をかためるために、新たに一人、経験者を雇ってソフト開発チームのリーダーにすることにしました。Kさんというのが、彼の名前です。30代だったでしょうか。前は準大手のSIerにいて、X社に転職してきたそうです。

Kさんの初仕事は、週次のミーティングで挙がった作業項目をAction Listにまとめる仕事でした。ところが、数日後にメールで送られてきたAction Listを見て、思わずわたしは部下と顔を見合わせため息をついてしまいました。その表は、Microsoft Wordの表機能で作られていたのです。

「ダメですね。これじゃ、使えないや。」わたしの部下は気短に言い捨てました。
「うん。・・ちょっと、うまくないかもね。」と、わたし。

なぜそう思ったか、おわかりでしょうか。Action Listは、わたし達が想定していた事と、現実の要求事項の間のギャップを調整するための道具です。だからプロマネやリーダーは、毎日これを眺めて暮らすことになります。その時、Action項目は全体でいくつあり、その中で未完了の項目はどれくらいあるのか、また一番期限に遅れているのはどれか、誰が一番多く抱えているのか、などを必ず気にかけるはずなのです。

ところが、Wordの表では、こうした数の分析がすぐにはできません。ということは、このK氏は、そうした見方に気を回したことが一度も無かったらしい事を暗示しています。普通だったら、こうした表はExcelその他、データ処理のしやすい道具で作るでしょう。

Actionの中には重いのも軽いのもあるのに、単純に数なんかかぞえる意味なんかあるのか? そう反論する人もときにいます。でも、そういう人だって、お宅は何人家族ですかと聞かれて、“大人も赤ん坊もいるのに、そんな質問に意味はない”とは答えますまい。日本の経済成長率はOECDの順序で何番目か、という質問に、“大国も小国もあるのにナンセンス”と言うでしょうか。

もしActionの手数に違いがあるというのなら、ABCとか松竹梅でもいいから、重みをつけて加重計算すれば良いだけです。問題は、自分のプロジェクトの状態やパフォーマンスについて、数値化しようという意識が少しでもあるかどうかなのです。

数字はいつも見ているさ、だって予算もスケジュールも工数も、しょっちゅう確認しているし、上からうるさく言われるじゃないか--K氏だって、聞けばこう反論してきたかもしれません。ところで、それは顧客や上司から要求されるから見ていたのでしょうか。要求がなくても、自分から測ったでしょうか。

測れないものはマネジメントできません。何かの状況をつかみたかったら、そして向上させたかったら、それを測るためのモノサシと基準が必要です。「あと少しです」「頑張っています」「出来は良いですよ」--こうした『言葉による形容』では、主観による比較から抜け出せず、検討しても決着がつきません。何かをどうにかしたかったら、改善や変革をしたかったら、対象を数字で測る習慣をつけるべきです。測りにくい対象でも、多少強引にでも数値化するマインドこそ、マネジメント・テクノロジー化への第一歩なのです。

そして、どのような時にはどのモノサシを選ぶべきか、その精度はどの程度の粗さか、それで何を見たいのか、つねに意識していかなければなりません。

K氏は残念ながら、一月ちょっとでその会社を辞めていきました。穏和な性格で頭もそれなりにいい人です。上司との折り合いその他、いろいろ事情もあったのだとは推察しました。彼は辞めていく時、わたしにだけメールを送ってきました(別の会社だから、かえって言いやすかったのかもしれません)。その中で彼は、憤懣やるかたないという調子で、「私の仕事は、工程表をつくるという事だったというのです!」と書いていました。

しかし、「当たり前じゃないですか。それが貴方の仕事ですよ」というのが、読んだわたしの感想でした。SE上がりのK氏は、開発プロジェクトのリーディングを、設計の指導か何かのように考えていたのでしょう。工程表作りなど、本筋とは無縁な管理的雑用だと。でも、それは勘違いです。それはちょうど、映画の助監督に採用された人が、現場の段取りやキャストとの調整をわきにおいて、脚本のストーリーばかりに首をつっこむようなものです。デザイン(What)とマネジメント(How)は別物であって、小さなプロジェクトではチーフ・デザイナー自身がリーダーを兼務することもありますが、それは脚本兼監督みたいなもの。デザイナー=リーダーが、本来の姿だと思うのは誤解です。

工程表作りは、立派なHowのプランニングです。そして、現実のスケジュールがプランからどれだけずれているかを測って監視していく。遅れたら原因の問題をつきとめ解決していく。これがリーダーに求められるマネジメントの仕事です。Sさんも、これから自分が仕事をリーディングしていかれる際は、「何をもってこの仕事のパフォーマンスを測ろうか」という視点を心にとめておかれるよう、おすすめいたします。
by Tomoichi_Sato | 2011-08-26 23:07 | プロジェクト・マネジメント | Comments(1)
Commented by 株の入門 at 2011-10-20 17:53 x
とても魅力的な記事でした!!
また遊びに来ます!!
ありがとうございます。。
<< 書評: 「不確実性のマネジメン... 書評:「見えないものと見えるも... >>