<   2007年 04月 ( 4 )   > この月の画像一覧

プロジェクト・タイム・マネジメントのベーシック

スケジュールという英単語は、もともと『一覧表』とか『箇条』という意味に近い。箇条書き、の箇条である。そこから転じて、主に米国で時間割や予定表の意味に使われるようになったときく。これをtime scheduleという。だから、PMBOK Guideの初版を作った人たちが、9つの知識領域の中で時間軸上のマネジメントのことを、スケジュール・マネジメントなどと呼ばずに、タイム・マネジメントと呼んだのは、本来の英語感覚からすると元に戻ったわけである。

その、プロジェクトにおけるタイム・マネジメントの基本は何だろうか。大きく7点ほどあげることができる。

(1) プロジェクト全体のタイム・スケジュールの目標、すなわち納期を達成するために、スケジューリングの仕組みを確立し、その水準を維持すること。

(2) プロジェクト組織を構成する各機能単位(グループ)に対して、成果物単位での「完了目標日」を含んだ詳細スケジュールを示し、またそれを保守すること

(3) すべてのスケジュールを、そのアクティビティのWBSレベルの如何にかかわらず、CPM(Critical Path Method=クリティカル・パス法)による詳細なネットワーク・スケジュールの中での位置関係を明らかにし、また影響範囲を追跡可能とすること

ここまでの3点は、Plan-Do-Seeのマネジメント・サイクルの中で、Planすなわちプロジェクト計画段階の作業に属する。いわゆるスケジューリングと呼ばれる領域である。教科書的には、(2)のWBSの列挙や(3)のクリティカル・パス法にもとづいたネットワーク・スケジュールを作成が、よくハイライトされる。しかし、一番大事なのは(1)、すなわち、タイムキープするための体制と仕組みの確立である。

そして、たいていの実務では、マスタ・スケジュールを立案してガント・チャートを書き終えると、その時点で安心してしまいがちである。そのあと、そのガント・チャートは一度も見なおされなかったりする。しかし、本当のタイム・マネジメントはこの後からはじまる。

(4) 進捗とパフォーマンスの記録をとり、それをレポーティングすること

これが、Plan-Do-SeeのDoの部分の中核である。記録し、報告する。これをみな、面倒くさがって怠る。そして、ひとたび問題が発生すると(しかもプロジェクトでは必ず、つねに問題は発生する)、それはプロマネに気づかれぬまま、担当者の胸の内に隠微に広がりはじめる。それを防ぐためには、

(5) プロジェクトの状況をモニタリングし分析して、各アクティビティがプロジェクト全体の要求するスケジュールに合致するよう保証すること

(6) プロジェクトのスムーズな遂行を可能にするような、健全なマネジメントの決定がよってたつべき基準を提示すること

(7) プロジェクトの主要やマイルストーンや完了日に影響する潜在的問題を早期に予見すること。そうした問題はマネジメントや最終顧客が先手を打って防げるように、きちんと報告されること

というSeeにかかわる部分の作業が必要になる。こうしたこと全体が、プロジェクト・タイム・マネジメントである。その中心は、(4)進捗とパフォーマンスの計測、にある。この計測が正確かつ迅速に行なわれるプロジェクトは、ちょうど正確なGPSを積んで運航する船のようなものだ。今どこにいて、どれだけの速力で、どこに向かっているかがつねに把握できている。非常に安心である。

むろん、たとえGPSを積んでいても、海に嵐が発生するのは防げない。すなわちリスクの顕在化である。しかし、待避路をとるのは早く確実になる。これが、タイム・マネジメントのベーシックなのである。
by Tomoichi_Sato | 2007-04-26 23:44 | 時間管理術 | Comments(0)

時間の量から時間の質へ

自分はどちらかというと夜型の人間である。こうして、サイトにアップする文章を書いているのも夜のことが多い。まわりが暗くなり、あたりが寝静まって、音も光もレベルを落としたときが一番、思考に集中できる。以前、『静寂の価値』(「考えるヒント」2004/08/20)にも書いたが、雑音に囲まれBGMをかけながら数式や文章をひねったりするなど、まったくできない。

私の場合、朝一番にその日の仕事のTo Doリストを見ながら段取りと手順を考える(最近はこうした時間管理術の基本を「パーソナルPM」などと呼ぶ人もいるようだ)。その際、込み入った文章をつくる作業はどうしても夕方以降にスケジューリングすることになる。最近は以前より早めに出勤する習慣にかえたが、だからといって朝一番に頭が集中できる訳でもないところがつらい。夕方から用事や会合がある日の多い週は、成果物がなかなか上がらないことになる。だから、私の場合、集中できる夕方から夜の時間をいかに確保できるかが、仕事の能率を左右するわけだ。

それで、昼間は何をするかというと、いわゆる“管理”をしている。これは幸いにも、中間管理職という種類の動物には、いくらでもついて回るような仕組みになっている。プログレス・レポートの数字を集計したり、ミーティングの議事録を整理したり、出張承認をしたり、部下の設計書に些細なミスを見つけてインネンをつけたりといった、高邁ではあるがあまり集中力のいらない軽微な労働である(ジョーダンですよ社長。本気にしないでください^^;)。

しかし、管理職になる以前、すなわち会社の付加価値にもう少し直接的貢献をしていた時代には、昼間も仕様書や設計計算の仕事をしていた。そして、生産性は当然ながら夜間の集中時よりもずっと落ちていた。周囲の雑音や大声が障害になる。なにより、昼間は仕事への割り込みが多い。上司に呼ばれたり電話がかかってきたり。少し能率が上がってきたところで、すぐスローダウンしてしまう。

私の勤務する業界では、仕事量を計る基準として、マンナワー(Man-hour、人時)を使う習わしだ。むろん人日や人月ではかる業界もある。いずれの単位を取るにせよ、人数と時間の積は、人件費コストを算出する指標としては適当だろうが、仕事量の尺度としてはまったく不適当だ。それは、昼間だと2時間かかるフロー図の作成が、夜だと1時間以内でできてしまうことからも明らかだ。ましてや、集団の仕事においてはミス・リーディングでさえある。

あるまとまったプロジェクトが、5人がかりで12ヶ月、つまり60人月かかる、と仮定しよう。この仕事は、倍の10人を投入すれば6ヶ月でおわるだろうか。60人投入すれば一月で、1,800人投入すれば1日で済むか? むろん、そんなバカなことはない。人月という「量としての時間」だけでは、開始から終了までの期間という「線という時間」は出てこないのだ。では、その両者をつなぐ物は何なのか?

その答えは、「並列性」と「タスク集中度」である。並列性とは、その仕事を細かく分けて同時並行に進められる程度である(コンピュータ・アルゴリズムの世界における並列性の概念を思い出せばいい)。たとえば100通の封筒に宛名と切手を貼る仕事は、1人でやるより2人でやる方が2倍効率が良い。他の担当者と関わりなく、各自が進められるからだ。しかし、100枚のタイルに絵を描いて、大きな壁画をつくる仕事では、完全に人数に比例して効率は上がらない。どうしても他人とのインタフェースが発生するからだ。まして、ブロックを下から順に100枚積む仕事となると、並列性はさらに損なわれる。

リソースを追加投入してタスクの期間を短縮することを、PMBOK Guideでは「クラッシング」と呼ぶ。クラッシングが可能になるためには、そのタスクの並列性が高くなくてはならない。一般に力仕事の方が並列性は高い。仕事に内部構造があって、相互の連関性や依存性が高いほど、クラッシングはききにくくなる。システム設計はその典型だろう。

もう一つのポイントである「タスク集中度」は、どれだけ連続した時間を一つのタスクに集中できるかである。“集中”には二重の意味があって、雑音抜きで精神集中できる時間、という面と、複数案件のかけもちをせずに一つの仕事に専念する、という面がある。いずれも、とくに思考を要するタスクにおいて重要である。逆に言うと、ある仕事が50時間を必要とするというときは、それは「連続して集中できる50時間」が必要だ、と意識して使うべきなのだ。細切れな1時間を50回足しても、それは50時間にはならない。それが質のある時間ということである。

時間の量だけでなく時間の質を問題にしたければ、割り込みを許して時間を細切れにしてはいけない。そのためには、直近の予定は固定する必要がある。そして、自分自身を予約してしまうことだ。サラリーマンの場合、これは自分一人の努力だけではなかなか勝ち取れないだろう。だから私は、朝一番にTo Doリストを見て一日のパーソナル・スケジューリングをすることを皆にすすめるのだ。ほんのわずかな時間である。整流のために時間を取らないことが忙しさの原因だということに、みんな早く気づくべきだろう。
by Tomoichi_Sato | 2007-04-19 23:38 | 時間管理術 | Comments(0)

時間、売ります

まだ大学生の頃のこと。サークルの部屋に、卒業した先輩が遊びに来た。役所に勤めて、ぱりっとした背広を着込んだ彼が、こう言うのだ。「働いてみたら、『就労とは自分の労働時間を売ることだ』という経済学のテーゼは、実感とは全然ちがうことがわかったよ。」--つまり仕事とは、使命感をもってするものであって、給料のために自分の時間を売買取引することではないのだ、というのが彼の説明だった。またそうでなければ、とても良い仕事なんてできやしない。そう語った彼の言葉を、今でも覚えている。

やがて、自分も就職した。同業のライバル会社に入社した同期の友人とあったら、彼は「部署に配属になったら、まずタイムシートなる表を説明された。毎日、どの仕事で、何時間働いたかを逐一記入させられる。エンジニアリング会社って、こんなところまで人を管理するのか! とあきれた。」と憤然としていた。これも忘れられないセリフだ。

ところで、私自身の感覚は少しちがった。私は働いた時間をタイムシートにつけることに抵抗はなかったし、自分は会社と契約関係にある、とも思っていた(今でもそう思っている)。たぶんこの二人に共通していて、私に欠けていたのは、“仕事とは使命感ややりがいをもってなすべき創造的活動であり、それに従事している人間は労働時間などで事細かに計って管理されるべきではない”という信念だったのだろう。自分の仕事に対する自負心、といっていいかもしれない。私が『時間管理術』という本を書いて、主人公を新米のマーケティング・マンに設定したとき、じつは最初に思い出したのがこの議論だった。

「ホワイトカラー・エグゼンプション」の議論が最近かまびすしい。ホワイトカラーは裁量範囲の多い、知的で創造的な業務についているのだから、仕事の成果で給与を測るべきであり、工場労働者のように残業したから時間給をいくら、と払うのにはそぐわない--これがホワイトカラーの“エグゼンプション(適用除外)”の主張だ。近年、フレックスタイムや年棒制、裁量労働制などの事例が増えてきたが、それをもっと徹底して、何時間働こうが残業代は一切なし、きまった給料のみ、というやり方である。成果主義とも通底する思想だ。

ところで、このホワイトカラー・エグゼンプションの主張は、上にあげた二人の考えに、内容的に共鳴することをお気づきだろうか。創造的な業務であり、細かい管理にはそぐわない。だからタイムシートなど不要だ、となる。それでは、自分たちの仕事の『成果』はどのように量るのだろうか。本当に計れるのだろうか? まさか仕様書や建議書のページ数が尺度ではないはずだ。

じつは私も新入社員の集合研修で、ある言葉を聞いた。それは、「わが社のエンジニアは、マンアワーという単位で仕事量を計り、その価値を7,500円という値段で顧客に請求してビジネスをしている」という説明だった。「だから諸君。この部屋に100人以上集まって、1時間私の話を聞いているということは、会社は100万円近くのコストとひきかえに、君達の教育に投資しているんだよ。」と言葉は続いた(値段は当時)。

労働者は会社に時間を差し出して時給をもらっている。しかし、会社もエンジニアの時間を売って商売にできる、という感覚は、そのときまで私にはなかった。でも、考えてみれば弁護士なども同じビジネスモデルではないか。勝ち負けの成功報酬や書類のページ数で料金を決めるわけではない(事実、弁護士もふつうタイムシートをつけている)。以来、私は時間を売っているという感覚から離れられない。

医師だって、本来はそうであるはずだ。診察料とは、医師の時間に対する費用のチャージである。その頃から問題になっていた「薬漬け医療」は、結局、医師の診察料が安すぎるために、薬の差益で医療ビジネスを成り立たせざるをえないことから発生していた。もし医師がきちんと診察料を得られる保険の仕組みになっていれば、ていねいに患者を診てもちゃんと引き合うはずなのだ。

およそ『プロフェッショナル・サービス』、プロと名前の付く専門職の仕事とは、そうしたものなのである。成果ではなく、時間を売る。いいかえると、モノではなく、知恵とアドバイスを売る。なぜか。それは結局、その知恵を自分の問題解決につなげられるかどうかが、それを受け取った者に依存するからなのだ。知的な仕事の成果に価値があるかどうかは、作り手だけの問題ではない。じつは作り手と受け手の共同責任なのだ。この点を、多くの議論は忘れている。忘れたまま、見かけだけの成果主義に走っている。

(ちなみに、今どき工学部出の技術者なんて二束三文だが、古代ギリシャでは、医師と法律家と技術者は3大プロフェッションとして尊敬されており、同時に高い倫理も求められていた)

それでも、たいていの会社は成果主義や年棒制に走るのを止めないだろう。1日24時間の限られた持ち時間の中で、どう会社の求める「成果」を発揮するのか、考えなくてはならない時代になったようだ。そのとき大事になるのが、(本の中にも書いたように)「長さとしての時間」と「量としての時間」の区別である。あるいは、質としての時間と量としての時間、といいかえてもいい。今回はこの問題を議論するつもりだったのだが、例によって長くなりすぎてしまった。この続きは、次回書こう。
by Tomoichi_Sato | 2007-04-10 23:42 | 時間管理術 | Comments(0)

日数基準による発注点と安全在庫の計算法

従来の在庫理論は物量、すなわちモノの数量をベースに構築されてきた。部品資材は大量に発注して安く買いたい、発注の手間も省きたい、でも欠品も避けたい--そこでどうすべきかが、問われてきた。これは、生産管理学発祥の地である米国が、抜きがたい大量生産志向をもっていたことと、多少関係があるように思える。

ところで、すでに何度も書いてきたように、在庫とは時間の缶詰めでもある。ストック在庫を持つ理由は、あらかじめ在庫の形で時間を先取りしておいて、受注から納品までの製造リードタイムを短縮したいからだ。これを考えると、在庫理論は物量基準ではなく時間(日数)基準でアプローチしたほうが有用なこともありそうだ。事実、発注点の決め方は日数基準の方が簡単になる。今回はそれを説明しよう。

発注点方式による在庫コントロールが適するのは、ABC分析でBCランクに分類されるような、使用量が比較的小さいものだ。毎日何十個も何百個も使用される部品はむかない。どちらかというと、ぽつりぽつりと消費されていくタイプの品目が適当だ。たとえば、受注生産、それも個別受注生産の企業なら、間歇的に受注があって、そのたびに部品が必要になるから、ストック在庫の部品はこうしたパターンで消費されていくだろう。

個々の受注(=消費)が間歇的で、一定期間でならせば平均的には安定しているが、受注が互いに独立している(周期性もなく団子状態でも来ない)としよう。このとき、受注の間隔をしらべてみると面白いことがわかる。受注間隔を横軸にとり、その頻度を縦軸に(ただし対数で)とって片対数グラフを描くと、右下がりの直線になるのだ。これをポアソン到着という。単発的で比較的頻度の低い出来事はみな、ポアソン到着になることが知られている。たとえば(楽しい例ではないが)地震の生起はこの形になる。だから、大地震の直後には余震が起きやすい。間があくほど、確率は低くなる。しかし間隔の平均値は存在して、実績から計算できる。

さて、いまある部品の消費実績を調べたら、平均τ日の間隔でぽつりぽつりと使用されることがわかったとしよう。一方、この部品を購買手配してから納入されるまでの購買リードタイムはL日だとする。たとえば、鋳物部品で、使用間隔は7.5日間、購買リードタイムは1ヶ月(30日)としようか。

発注点の基準は、購買リードタイム期間中に消費される数量だ。それはL/τで与えられる。この例では4個になる。逆に言うと、4個は30日分に相当する。発注点のレベルを日数で測るなら、それはL日(すなわち30日)になるのである。

ところで、これは安全在庫を無視したときの数字だ。実際には、受注間隔に変動があり、しかも短い期間に続けてくる確率の方が高いわけである。だから安全在庫は必要だ。こちらはどう決めるべきか? そもそも安全在庫とは理屈と現実をすりあわせる潤滑油のようなもので、安全在庫のない在庫管理なんて、オイルを入れずにギアボックスをまわすも同然である。

ところで、平均間隔τ日でポアソン到着する出来事(部品使用)が、一定期間L日内に何回発生するかは、じつはL/τだけで決まる。その確率パターンはやや右に尾を引いた山形になる。上記の例では、次のようなグラフになる。つまり、1ヶ月間に3個消費される確率が約2割、4個消費される確率も2割ある。ぜんぜん出ない確率も、2%ほどある。5個以上出ていく可能性、つまり欠品の危険性も、かなり(37%)ある。

面白いことに、このグラフの形はLとτの比だけで決まるから、L=20日、τ=5日でも同じ結果になる。購買リードタイムの絶対値にはよらないのだ。このグラフの形をポアソン分布と呼ぶ。また、ポアソン分布の標準偏差は平均値の平方根になる、といった性質があるのだが、ここではちょっと忘れておこう。

さて、この例で、欠品の危険率を5%以下におさえたかったら、どうすべきだろうか。答えを先に言うと、発注点を7個におけばよい。すなわち、安全在庫=3個である。ちなみに、発注点(日数基準)をP、購買リードタイムをL、平均使用間隔をτであらわすと、

P = 1.4 L+1.1τ (日)

で近似的に求めることができる。上の例で言うと、約50日分強だ。実に簡単である。このように、日数基準の生産管理理論の可能性は、もっと研究されていい分野だと、私は考えている。
e0058447_0362621.gif

by Tomoichi_Sato | 2007-04-03 00:36 | サプライチェーン | Comments(0)