カテゴリ:時間管理術( 43 )

日誌をつけよう

新入社員の人たちも、集合研修は一段落し、部署に配属されほぼ一月たって、少しずつ職場の環境に慣れてきた頃だと思う。これから何とか自分のペースをつかみ、できれば自分の能力も磨いていきたいと考えている人も多いだろう。

時間管理術』というのは働く人に共通のスキルだ。その中でも、とくに初心の人たちにすすめる事は何か、ときかれたら、わたしは「日誌をつけよう」といつも答えるようにしている。

昔はよく元旦などに、“よし、今年こそは日記をつけよう!”などと決心をする人がいたようだが、今どきはどれほど存在するかわからない。正月に、“今年こそは家計簿をつけるわ”と思い立つ主婦が大勢いると信じて、昔の婦人雑誌の新年号は分厚い「特別製家計簿」を付録にしていたものだ。今どき日記をつけようと決心する人の数は、おそらく家計簿をかなり下回って、マイナーな趣味に属するかもしれない。

ところが世の中の変化とは不思議なもので、文房具店の日記コーナーや婦人雑誌の豪華付録が消滅していくかわりに、日記をつける人はかえって目立つようになった。ネットの世界でのことだ。自分のBlogやFacebookなどのSNSに、日記代わりの文章をアップしている人の数は、(公式な統計が存在するかどうかは知らないが)今では数十万を下るまい。昔風の、紙に書いて、鍵付きの箱にしまっておく、私的で内密な日記はすたれて、オープンで、ちょっと気取った、他人が読むことを最初から意図した日記は増え続けている。これが現代のトレンドというものらしい。

ところでわたしは、あえて逆の提案をするのである。「公開を目的としない、個人的な記録を毎日つけよう。1日に10分、自分の時間をそれに当てよう」と。そして、それをスケジューリングやプロジェクト・マネジメントの訓練として行なおう、と。

そんな習慣が何の役に立つかって? そう疑問に思う人は、Blog的な、私的な日記を想像するからだろう。しかし、私が提案するのは、個人的な記録、つまり『日誌』なのである。

「日記」は(たとえそれがインターネットで公開されようが)基本的に文学の領域に属する。日本では日記文学の長くて立派な伝統があり、またその姉妹として身辺雑記のエッセイも発達している。だからみな、毎日の記録というと、すぐそうしたものを連想する。

これに対して、「日誌」は客観性の領域に属している。自分の主要な関心事、ふつうは仕事の(学生ならば研究の)ことを記す。だから散文的だ。他人が読んでもつまらないし、日誌はそもそも他人に見せることを意図していない。日誌の想定する読者はたった1人、未来の自分なのだ。

船の船長はみな、「航海日誌」をつけている。わたしは航海日誌もつけないような、だらしない船長の船には乗りたくない。同じように、わたしは「プロジェクト日誌」をつけないような、訓練の足りないプロジェクト・マネージャーの仕事はしたくない、と思う。ところで、あなたの知っているプロマネは、日誌をつけているだろうか? なぜ海運の世界では当たり前のことが、ことホワイトカラーのオフィスの世界ではほとんど行なわれないのだろう?

航海日誌に書くことと言えば、どんなことだろうか。わたしも正確には知らないので想像するだけだが、その日の船の位置、進んだ方向と距離、天候、その日の主要な作業項目や出来事、寄港したならば寄港地名と積み卸しの内容、船員や乗客の動静、発生したトラブルや将来起こるかもしれないリスク、などだろう。長く航海していれば、こうしたことをすべて頭の中だけで記憶しておくのは不可能だ。

航海の途中で、「通信機の調子が落ちている・・このところ荒天が続いて傷んだからかもしれない・・そういえば前にオーバーホールしたのはいつだったろうか?」というようなことを考えるとき、日誌がなければ困ってしまう。また、一つの航海が終わったとき、次の航海の計画を立てる場合にも、過去の航海日誌は役にたつ。つまり日誌は、基本的に書いた人間が自分で読んで利用するものなのだ。ならば、プロジェクト・リーダーを目指すあなたも、日誌を付けない理由が何かあるだろうか?

日誌は、鍵付きの小箱入りのノートではなく、パソコンで記録することをおすすめする。理由は簡単、日誌の主要な目的が「過去の検索」にあるからだ。何も立派なデータベース・ソフトである必要はない。ワープロや、テキスト・ファイル+エディタの組合せで十分だ。なぜなら、日誌に記録すべき項目はしだいに変わって行くからだ。仕事を通じて、自分の役割も、範囲も、関心点もかわっていく。人はそれを『成長』と呼ぶ。へたなシステム分析を行って、自分の「管理項目」を固定してしまわない方がいい。あとで必ず窮屈になって、使うのをやめてしまうだろう。

日誌に割く時間は1日にせいぜい10分か15分。それ以上かかるようなら、書くべき項目を減らした方がいい。さもないと、休日や何かの理由で書けない日が3日続いたとき、間を埋めるだけで1時間近くかかってしまい、だんだんいやになってくる。日誌は継続しなければ、何の意味もない。

あなたも、もしも今つけていないのなら、日誌をはじめよう。今つけているのが文学的「日記」だったら、内容に「日誌」も加えよう。その習慣をだれかれに言う必要はない。自分一人で、心の内に宣言すればいいだけだ。

そしてときどき過去を検索したり、読み返してみよう。3ヶ月続けてみたら、あなたは、何となく、気分的な安定を少しだけ感じているはずだ。それがきっと、「成長」というものの実感なのである。
by Tomoichi_Sato | 2012-05-13 23:01 | 時間管理術 | Comments(0)

進捗率にはいろいろな定義が可能である

IT業界の人からときどき聞く発言の一つに、「ITプロジェクトではクリティカル・パス法なんか使えない」という主張がある。わたしはスケジューリングとかタイム・マネジメントの分野で長く仕事をしてきたが、こういう主張をIT分野以外できいた覚えがない。IT業界人は知的な人が多いと思うが、自分達の仕事を“特殊な仕事”だと考える傾向も強いように思われる。無論ある意味では特殊な分野かもしれないが、だとしても1日の作業のあとに2日の作業をした場合、合計3日かかるのは、どんな仕事でも共通ではないか。なぜIT業界の人だけ、“ウチの分野は1+2=3の算数が成立しない”といった意味のことを言いたがるのか? 当初はとても不思議に感じた。

しかし、話しあっていく内に、次第にIT系の人たちの抱える不満、ないし問題がすこしずつ分かるようになってきた。クリティカル・パス法はいうまでもなく、プロジェクト全体を複数のアクティビティにブレークダウン(WBS化)し、各アクティビティの期間と順序依存関係をもとに、全体の工期を推定する手法である。これ自体は非常に論理的な、いわば算法の世界だから、不服を申し立てる人はいない。問題は、そのアクティビティ所要期間の見積にあるのである。10日間のアクティビティA(たとえば設計)の後に20日間のアクティビティB(たとえば実装)をやった場合、全体で30日かかる、と、そこまではいい。難しいのは、設計が本当に10日で終わるのかどうか計画時点で誰も自信を持って見積もれないし、スタートして5日後に設計進捗率=50%になってもちゃんと10日で終わるか不明だし、9日目になって前提条件がひっくり返り「さらに10日かかる」状態になるかもしれない、という点だ。こうした不確実性があるから、「PERT/CPMなんか使えない」という不満が出てくるという事らしい。

ここでの問題を解きほぐすと、実は三種類の別の悩みが混じっていることが分かる。第一は、そもそも計画時点で期間見積をすることが難しいという点。第二に、途中の進捗状況から完了の『見込み日』を推定することが困難である、という点。そして第三が、途中でリワーク(手戻り)によるリスクがある点である。このサイトでは、第一の期間見積の精度向上については「マイルストーンは中点で測れ」ですでに論じたし、第三のスケジュール・リスクについては「時間のムダとり--スケジュールのサバを切り捨てる」でも書いている。そこで、今回は二番目の『進捗率』の信頼性問題について考えてみよう。

情報処理技術者試験に「プロジェクトマネージャ」がある事は、IT業界のかたならご存じだろう。経済産業省の認定資格である。その2004年度の秋季に、進捗率に関するこんな問題があった(以下、筆者が一部改変して引用):

- 10本のプログラムからなるシステムを完成させるプロジェクトがある。1本のプログラムを完成させるには1人月の工数がかかると見積もられた。
- 各プログラムの開発作業は、設計(20%)→コーディング(50%)→テスト(30%)のプロセスからなると推定された。
- 作業開始から15日たった時点で進捗状況を調べたら下記のとおりだった。現時点での進捗率を求めよ
      完了数(本) 予定工数(人月) 実績工数(人月)
 設計      10    2.0      2.5
 コーディング   6    3.0      4.0
 テスト      3    0.9      1.5

なかなか面白い問題である。読者諸兄だったら、どう考えられるだろうか?

問題文には書いていないが、この10本のプログラムは、互いにまったく独立で、相互に連関はなく、作業は完全に平行に進める事ができるらしい(そんなプロジェクトばっかりだったら誰も苦労しないさ、というような批判は置いておく)。

進捗率の計算としては、ぱっと考えて三種類の方法がありそうだ。
(1)完成数基準。最後まで完成した本数の比率を、進捗率とする。つまり
  3/10=30%
(2)予定工数基準。問題文に工数見積の情報があるのだから、きっとこれを使うのだろう。すでに完了した作業の予定工数から計算する。
 (2.0+3.0+0.9)/10=59%
(3)実績工数基準。いや、すでに消費した実績工数のデータで計算すべきだろう。
 (2.5+4.0+1.5)/10=70%

あいにく当時の経産省系の試験はすべて、正解が公開されなかった。だから出題者がどれを念頭においたのかは分からないが、ここで推理してみよう。

念のためにいうが、進捗には、さまざまな定義が可能である。これは決め事の問題であって、その点では原価管理に似ている。同じ会社の同じ製品といえど、いろいろな原価の計算が可能である。原価にただ一つの正解は無い。進捗率も同じだ。しかし少なくとも、合理的な算定方法として合意できることが条件であろう。

完成数基準の計算:3/10=30%、はどうだろうか。これはこれで単純至極な定義であり、問題はないように思える。しかし進捗管理の目的は、「この仕事はいつ終わるのか」を知る事であった。15日目に進捗率30%ならば、完成まで50日かかる計算だから、あと35日必要と言えるだろうか? そうではなさそうである。そもそも、もしこの仕事が理想的な並列で進んだとしたら、ずっと完成本数=0で、最終日にいきなり10本完了、ということになる。横軸に時間、縦軸に進捗率をとってグラフを描いたら、ずっとゼロ%のままで、最終日に100%になる。このようなグラフを用いて、進捗管理(すなわち完了の予測)ができるだろうか? 完成数基準の進捗率はシンプルで分かりやすいが、こうしたケースでは進捗管理には向かないのである。

では、実績工数基準はどうか。この手法の問題点は、すでにお気づきのかたも多いだろう。もし仮に、現在までに9人月かかったとすると、進捗率は90%ということになる。12人月かかったら、120%進捗(?)になってしまう。これは明らかに不合理である。「予算消化率で進捗率は測れない」のであった。

だとしたら、消去法で、『予定工数基準』がこの問題の正解らしいと分かる。でも、なぜこれが正解なのか? それは、“進捗はあとどれくらい仕事が残っているか”で測るのが原則だからである。現時点で、残っている作業の工数は、コーディングが4本、テストが7本であった。ということは、2+2.1=4.1(人月)、すなわち全体の41%の仕事が残っている訳だ。だから進捗率59%が正解なのである。ちなみに、この計算方法は、全部で30個のサブ・アクティビティ単位における完成数基準で、重みづけに計画工数をつかったものだと説明することができる。そして、これこそ、アーンドバリュー・マネジメント・システム(EVMS)の考え方そのものであった。この問題は、だからEVMSの理解を問うのが目的だったらしい(EVMSで完了までの期間をどう推計するかについては、長くなるので別の機会に述べよう)。

進捗率とか原価という概念は、案外危険な概念である。それは数字で示されて、分かったような気になりやすい。しかし、これらは人為的な尺度であって、いろいろな測り方ができ、目的に応じて使い分けなければいけない。間違った使い方をすれば、かえってミスリードなだけである。精度を議論するなら、その定義に立ち返って議論しなければならない。よく「製造業や建設業はモノが出来ていくから、進捗が目に見える」などと言う人がいるが、ことはそれほど単純ではない事を知るべきである。

そして、もう一点。アクティビティの期間にばらつきがあり、推定にリスクがともなう現象は別にIT業界だけに限ったことではない。リスクの無いプロジェクトなどというものはない。これは共通の問題であり、共通の知恵が使えるのである。もちろんITプロジェクトだけはリスクが極端に大きいのだ、と言えば言えよう。でも、だとしたら、PERT/CPMを批判するだけでなく、それに代わる定量的な理論と手法を、なんとかして考案すべきであろう。そして、IT業界の人たちには、それをできるだけの知性と能力があると期待したいのである。
by Tomoichi_Sato | 2012-03-04 23:48 | 時間管理術 | Comments(0)

進捗管理とは何か?

「進捗(しんちょく)管理」は広く使われている用語だが、じつはかなり誤解されている仕事でもある。製造業の基本はQCD(Q=品質、C=コスト、D=納期)であり、それぞれをきちんと管理していかなければいけない。Qを対象とするのが品質管理であり、Cが原価管理(コスト管理)で、Dつまり納期を守るために進捗をきちんとコントロールすることが、進捗管理の任務である、と。まあそこまでは良いだろう。

ところが、この『進捗』なる概念がくせ者なのである。これほど誤解されやすいものはないのだが、わたしがそう言うと、不思議そうな顔をする人もいる。作業がどこまで進んだか、それが進捗ではないか。とてもシンプルだ--そう思う人は、次の例を考えてみていただきたい。

これは国策である「北海道開発プロジェクト」にまつわる話である。ご存じないかたも多いだろうから解説しておくが、戦後まだ間もない昭和25年に『北海道開発法』という法律が制定された。食糧増産ならびに人口問題の解決に寄与するため、未開の沃野である北海道の大地を農業化しようという壮大な構想を実現する法律である。この法律に従って、北海道開発庁(当時)ができ、昭和27年に「第一次北海道開発五カ年計画」なる計画書を策定した。内容は、農業・畜産奨励・土壌開発(機械力による客土)・道路・河川・港湾整備・・・と多岐にわたり、予算は国費だけで800億円であった。半世紀以上前の金額だから、現在でいえば軽く1兆円を超えるだろう。

(余談だが、この『第一次五カ年計画』という用語を聞くたびに、わたしは“まるで社会主義国みたいだなあ”という感じをいだく。旧ソ連や中国などはこの種の五カ年計画が大好きであったが、日本の官庁も実はそうなのだ。北海道開発だけではなく、たとえば「科学技術基本計画」だとか「海洋基本計画」だとか、いろいろな種類のものが現在も多数動いている。「日本は世界でもっとも成功した社会主義国だ」とかつて中国人に揶揄された言葉も思い出す。そしてまた、官僚主義の病弊に悩む点まで共通だ)

さて、当時、北大に中谷宇吉郎という物理学者がいた。氷雪の研究者として有名だがエッセイストとしても知られている。この中谷教授は、北海道開発五カ年計画の最終年となる昭和32年4月に、雑誌・文藝春秋に「北海道開発に消えた八百億円 - われわれの税金をドブに捨てた事業の全貌」というショッキングなタイトルの論文を発表する。この論文の中で、人口増加・食糧増産・農家戸数の増加について詳しく統計数字を分析し、「いずれも達成率ゼロ」であった、と断定したのである。

この論文が出たおかげで、霞ヶ関の北海道開発庁は上を下への大騒動になった、と聞く(そう、この役所の長官は東京の霞ヶ関にいたのである)。そして、開発庁の高官によって、翌月の文藝春秋誌にすぐ反論が掲載される。いわく、
「開発計画は順調に進展している」
「なぜなら、過去の年度で、われわれは順調に予算を消化してきたからだ」--

この論争、どこが行きちがっているかお分かりだろうか? 中谷宇吉郎先生は、目標にどれだけ近づいたかを問うたのに対し、北海道開発庁の反論の方は、“過去にどれだけ頑張ってきたのか”を答えているからである。彼らが怠惰だった、何もしなかった、といえば、それは嘘だろう。とくに現場の人々は努力していたにちがいない。しかし、努力はしても、それが実を結ばなかったのである。では、このような場合、進捗はいくらなのか?

一つはっきり分かることがある。それは、予算消化率=進捗率、ではないという事である。進捗率とは、達成の度合いでなければならない。いいかえれば進捗とは、どれだけ仕事をしたか、で量ってはいけない。「あと仕事がどれだけ残っているか」で量るべきなのである。

進捗管理の目的とは何か。それは『進捗』を「誰かに報告する」ためのものだろうか。そう考えてしまうから、そして、“進捗が上がらないとサボっていると非難される(かもしれない)”と信じるから、進捗管理がねじ曲がるのである。

進捗管理の一番大事な目的は、「この仕事はいつ終わるか」を予測することである。「終わるまでに時間はあと何日かかるのか」「費用はあとどれだけかかるのか」「リソースはあとどれだけ必要なのか」を見つめるために、進捗をはかるのだ。過去に費やした努力も費用も、汗も涙も、直接は関係ない。それは過去の領域に属することがらだ。進捗管理は未来志向の営為なのである。過去の出費や時間を記録する唯一最大の理由は、これまでのトレンドや生産性を知って、今後の予測の参考にすることにある。

たとえていうならば、あなたが知らない街でタクシーに乗っていて、目的地までの進捗を知りたかったら、料金メーターだけを見つめていてもはじまらない。それは過去に走った距離を示すに過ぎない。目指す地点まで、あとどれくらい距離があるかを知るべきなのである。

あるいは、10日分の仕事があったとして、現在、5日経ったからといって、進捗率を単純に「50%」と考えてはいけない。仕事はあと何日分残っているのか、いつ終わりそうなのか、を考えるべきなのだ。あと8日分かかりそうならば、進捗率はあいにく20%ということになる。仮にもし、あと5日分のところまできていたとしても、例えば次の日、顧客の気まぐれや上流側の設計変更のおかげで、実はあと7日かかりそうだ、という状況になったらどうするか。その場合は、「残念ながら今日は進捗率30%まで戻りました」と報告すべきである。

「進捗がマイナスになるような報告なんて許さない」と上司や顧客が言ったらどうするか(そういう残念な人はけっこう多い)。その場合は、“あなたは事実を直視する勇気のない人だな”などと、心の内で思ったりしてはいけない(きっと顔に出るから)。かわりに、「ゴールが遠のいたので、進捗は50%のままです。ただ、そのために生産性が当初予定より下がってしまいました」と答えるべきだ(=現在仕事の半分が残っている建前で、あと7日かかるのだから、この先の生産性は5/7=71%くらいになる計算だ)。もちろん、そんなヘンな計算をするよりも、事実は事実として記録する方が、次回以降の参考になる。事実を直視しなければ、きっとまた同じ失敗を重ねるだろう。どちらがいいか、落ち着いて考えれば分かることだ。

話を戻すと、このような形で進捗をとらえたら、それを工程表に記録(アップデーティング)していく。その方法については前回「イナズマ線と二重線 -- 工程表のアップデーティングとは何か」に書いたばかりだから、ここには繰り返さないけれども、元々の予定線と、現実とを比較する訳だ。

まとめると、進捗管理とは次のような作業になる。
(1)作業の現状を把握する
(2)完了までの残りの作業量/作業期間を推定する
(3)工程表をアップデートして、予定と現実を比較する
(4)予実の乖離問題が見つかった場合は、是正策を講じる
この(1)~(4)のサイクルを、定期的に、全部が完了するまで繰り返すのが『進捗管理』である。英語で言うと、"Progress Control" (あるいは"Schedule Control"とよぶ場合もある)。

管理といっても、ManagementではなくControlの領域に属することに注意してほしい。そしてコントロールの出発点は、事実認識である。もちろん事実の中には一般に、良いことも、そうでないこともある。だから、都合のわるい事実認識を拒む官僚主義は、進捗コントロールの最大の障害なのである。
by Tomoichi_Sato | 2012-02-26 18:41 | 時間管理術 | Comments(1)

イナズマ線と二重線 -- 工程表のアップデーティングとは何か

先日、拙著『時間管理術 (日経文庫)』を読みました、とおっしゃる方にお会いした。まことにありがたいことだ。ところで、その方が「一番勉強になったのは、スケジュールの工程表の上にイナズマ線を引くことでした、これで進捗の状況を見える化するというのは知恵ですね」と言われたので、こっちの方がかえってびっくりしてしまった。ほめられたからではない。この方の会社では、工程表を一度作成したら、それをそのまま、何の追記もアップデートもせずにずっと使い続けるのか、と思ったからである。

念のため書くと、先方は日本人なら誰もが知る一流企業で、業界ではトップ3に入る会社だし(ただしエンジニアリングや製造業ではなくサービス業だが)、その方だって立派な学歴と経験をお持ちだ。そして、プロジェクト的な、非定型的業務にずっと従事されている。だから意外だったのだ。

工程表は、航海士にとっての海図に似ている。工程表もつくらずにプロジェクトをはじめるのは、海図を持たずに航海に出るようなものだ。この方の会社は少なくとも、きちんと工程表をつくって仕事を進めておられる。ただ、どうやらそれを、そのまま最後までアップデートしないまま、使い続けるらしい。ちょうど、海図をもって航海に出るが、その海図に自船の現在位置や進路・速度を一切記入しない航海士のようなものだ。そもそも、工程表のアップデーティングという概念自体をご存じなかったらしい。

工程表というのは、単なる静的な図表ではない。ここでいう「静的」とは、一度作成されたら、基本的にそれで完成しそのまま参照され続ける種類の文書や情報を指す。たとえば契約書・発注書だとか、プロジェクトCharterなどは静的な文書である。他方、必要に応じて、適時改訂されていくべき種類の文書や情報は「動的」なカテゴリーに属する。プログラムのソースコードや詳細設計書などは典型的に「動的」なものだ。一度作成しただけで完了することは、まず無い。レビューや承認やテストや最終納品のたびに、内容が改訂され次第に最終形に近づいていく。

工程表もこのような意味で「動的」な図表なのである。ただし工程表は、必要時の「改訂」ではなく、定期的に「追記・更新」されていく点で、設計書などとは異なっている。ちょうど海図に船の位置と速度を毎日書き込んでいくように、スケジュールの現状を追記していく。これを『アップデーティング』と呼ぶわけだが、海図と違うのは、船の位置は一点で示されるが、プロジェクトの場合WBSのそれぞれのアクティビティ毎に位置を示す必要があることだ。いわば、プロジェクト工程表とは、船団全体を表示した海図のようなものなのである。

この工程表における現在位置と速度の代表的な表示方法が「イナズマ線」表記だ。これはガントチャート上に、ある時点における進み具合を示す縦線を書き込む方法である。各アクティビティの進捗度に応じて、50%進捗ならば横線のちょうど半分の位置の点を、70%進捗なら7/10の位置の点を選んで、縦につなげていくと、稲妻状の折れ線ができあがる。すでに完了したアクティビティは、単にまっすぐに縦線を引っ張る。すると、予定以上に進んでいるアクティビティは、右側に出っ張り、遅れているものは左側に引っ込むから、どこが進んでどこが遅れているかすぐに目で見て分かる長所がある。

e0058447_22392549.gif


プロジェクトでは、定期的に工程表にイナズマ線を追記していく。プロジェクト全体のスパンに応じて適切な間隔(毎週とか毎月とか)で書いていくわけだ。そうすると、工程表のガントチャート(横線中心)に、次第に縦線が加わっていって、格子状になっていく。プロジェクト最後になってふり返ると、どこが遅れどこがうまく進んだかを、マクロに見てぱっと判断できる利点がある。

スケジュールのアップデーティングには、もう一つ「二重線」と呼ばれる記法もある。これは、ガントチャートの各アクティビティに、計画線と実績線の2本の線を上下に重ねて引いて表現する方式だ。計画線は、着手予定日から完了予定日までを線で結び、実績線は、実際の着手日から実際の完了日までを結ぶ。ただし本日時点でもまだ完了していないタスクは、継続を示す短い点線を右に書くか、あるいは完了見込日までの横線にする(わたしはこの方が好きだ)。見込日(Forecast date)とは、「現状のままでゆくと、終了日はこの日付になる」と予測/判断された結果である。

e0058447_22402276.gif


二つの方法には一長一短がある。イナズマ線は進捗のマクロな傾向が見やすいが、遅れたアクティビティが実際にいつ着手したのか分かりにくい。二重線の方は実績をつかまえるには便利だが、定期的に書き加えても経過が分かりにくい。ただ、いずれの場合でも、出発時点での元の計画との対比を主要な目的としている点は共通だ。プロジェクトはなかなか計画通りには進まない。それは経験的事実である。だからこそ、工程表を静的な情報として捉えずに、定期的にアップデートして予実対比していく必要があるのである。

ところが、「見込み日」の概念を知らない企業は世の中に多い。そうした会社では、現実を予想するために、計画のベースライン自体をどんどん変更してしまう。設計の着手が遅れたら、設計の予定日付も変えていく。しかし、この調子で計画を毎日変更していったら、最後に振り返って見たとき、実績は常に計画と一致していたことになる。これで本当に進捗管理といえるのだろうか? 計画のベースラインとは、めったなことでは変えないのが、プロフェッショナルのやり方なのである。
by Tomoichi_Sato | 2012-02-19 22:47 | 時間管理術 | Comments(3)

「探し物」という名前の時間泥棒

ある工場に調査に行った。工場は2階建てになっていて1階に機械加工工程、2階に組立工程がある。ごく典型的な日本の工場レイアウトだ。金属部品を削ったり曲げたりする部品加工は、しばしば大きくて重たい工作機械を使う。だから1階に置く。他方、手作業中心の組立工程はさしたる設備は必要ないので、2階になる。これを逆にすると、2階に重たい機械を並べることになり、床荷重の確保や振動の防止、耐震強度などで建物に余計なコストがかかることになる。ちょうど戸建て住宅の設計でも、冷蔵庫や風呂桶など重い物のある台所や風呂場などは1階に置くのが通例であるように。

ところで、住宅の玄関が1階にあるように、工場の資材・製品の入出荷場も、普通は1階にある。家が斜面の途中にでもない限り、わざわざ2階から出入りするような口は作らない。組立工程は2階にあるわけだから、できあがった製品は1階に下ろし、逆に加工の終わった中間部品類は2階に上げなければならない。こうして、工場には必ず縦の物流動線が必要になる。そして、搬入した素材部品、加工した中間部品、ならびにできあがった製品の置き場所も必要だ。これらをどうレイアウトするかで、じつは工場の生産性はけっこう左右される。

さて、調査に行ったその工場で、組立ラインのそばに立ち、作業の様子を見ることにした。ちょうど生産は最盛期で忙しいはずの時分だった。だが、どういうわけか組立工程の作業者が寸暇を惜しんできびきび立ち働く、という感じを受けない。組立作業は奇妙に断続的に、ある意味では間延びしたテンポで行われていた。働いている人の顔は真剣そのもので、のんびりした表情はない。ただ、見ていると、数名一組で作業班が編成されているのに、その中の1,2名が、つねに作業場から出たり入ったりして持ち場から居なくなるのだ。

しばらく見ているうちに、だんだんと理由が分かってきた。持ち場を離れた作業者たちは、部品か工具のような物を手にして戻ってくるのだ。どうやら何か捜し物をしにいくらしい。この組立ラインには、主要部品は工程担当者が手押し台車で搬送してくる。また主なサブ部品は、作業場横の常備品棚に置かれている。だが、それでは足りない部品がしょっちゅう出るらしい。

組立ラインから中間部品倉庫に回って歩いてみて驚いた。倉庫は組立を待つ部品で一杯で、入らずにあふれた物が、近くのフロアに所狭しと床置きされている。この工場はすべての部品にきちんと現品票をつけているのだが、それでもこの中からめざす物を探すのは一苦労に違いない。中間部品倉庫の位置と大きさが適切でないせいで、こういう状態になっているのだろう。組立工程の作業者は、しばしば捜し物のために時間を奪われ、組立のスピードが落ちる。すると中間部品の消費が減るので、さらに倉庫の物が増え、捜し物がもっと大変になるというダウン・スパイラルが生じている。

あるいは、たぶんこの工場だって、20年以上前に建てられた時にはこれで十分だったのだろう。しかし、顧客の特殊仕様によるバリエーションが増えて、必要な部品の種類が増大し、現場の常備品棚や中間部品倉庫に収まりきれなくなったのかもしれない。いずれにせよ、この工場では組立がボトルネック工程のようだから、工場全体のパフォーマンスが、少なく見積もっても5%くらい落ちている、と推測された。工場のレイアウト設計は、かくも重要な問題なのだが、いまはそこには深入りしない。

わたしが問題にしたいのは、捜し物をしている作業者は、一所懸命に働いていると自分で考えているだろう点だ。たしかに、彼らが仕事をさぼっているとは、誰も非難できない。捜し物が出てこなければ、製品は出荷できないのだから、必要な仕事でもある。だが、この捜し物の時間は、付加価値創造には何ら結びつかない時間なのだ。

ミヒャエル・エンデの童話『モモ』には、“時間どろぼう”なる連中が出てくる。彼らは大人たちをたぶらかして、その時間を盗んでしまう。おかげで人々はゆとりを無くしていつも忙しく生きている。わたしは著書「時間管理術」を書いた際に、タイム・マネジメント能力を向上したいと思うのなら、自分の仕事にとって何が“時間どろぼう”なのかを考えてみるべきだ、として練習問題をつけた。また、タイム・マネジメントについて学生に教える際も、何が自分の“時間どろぼう”だと思うか聞くことにしている。通学時間、TVを見る時間、ネットで費やす時間、答えは様々だ。

この工場の例では、「探し物」が明らかに“時間どろぼう”だった。困ったことに、探す作業は主観的には立派に仕事をしている時間なのだ。タイム・シートをつける職場ならば、当然、作業時間として記録する。でも、企業全体から見ると付加価値時間ではない。その無駄は、部品の適切な置き場所と、探しやすい置き方の工夫を怠ったことで生じる。

そして、わたしたちも同じようなことを、オフィスでしているのではないか、とときどき感じる。わたしの職場のPCのハードディスクにはフォルダが何百も(もしかすると何千も)ある。ファイルサーバのフォルダ数は、その何倍もだ。そしてキャビネットに収められている膨大な書類ファイル群。その中をしょっちゅう、ひっくり返して何かを探している。米国のデイヴンポートという人によると、オフィスワーカーは平均して年間に140時間も、探し物に費やしているのだという。つまり、12ヶ月のうちほとんど1ヶ月は、無付加価値のことで時間を費やしているのだ。

なぜモノが見つからないのか。それは整理整頓の問題だ、という人がいる。たしかに正論だ。だが、「整理」と「整頓」を一口でいっしょにしていいのだろうか。書斎の中の本を、女中は整頓できるだろう。だが、整理は主人しかできない。整頓はいわば物理的な保管場所の整列と、通路の確保である。ところが、整理は「探しやすい」ようにモノを並べることである。整頓がハードウェアの保全の問題だとしたら、整理はソフトウェアの要求定義の問題なのである。整理するためには、最低限、これから使うもの、いつか使うかもしれないもの、そしてもう使い終えたものの認識と区別が必要だ。こういう当たり前の習慣を作らぬまま、やれITだマネジメント・システムだと流行り言葉を弄しても、空しいだけだと思うのである。
by Tomoichi_Sato | 2011-07-30 22:41 | 時間管理術 | Comments(0)

自分自身を予約する

個人の時間管理においては、スケジュールとTo Do Listの統合が一番の課題である。グループウェアとか、パーソナル・スケジューラなどのソフトでも、たいていこの二つの機能は揃えているが、画面は別々にある。ところで、私の同僚は、この問題に、ちょっと風変わりだが、見事な解決をつけていることを、最近知った。

私の課題をもう一度述べておこう。私は基本的に、会社でやるべき仕事のTo Do Listを、一元管理している。また、自分の予定はすべて、グループウェアのカレンダーに入力している。そして、朝、会社の席に座ったら、まずその日にやるべきアクション項目をTo Do Listから拾い出して優先順位をつけておき、また打合や来客などのイベント的な予定を確認する。

問題なのは、この二つのデータが別々に存在していることだ。両者は同じグループウェアに登録しているが、二種類の画面を行ったり来たりしなければならない。とはいえ、To Doという、納期がキーになるデータ項目と、イベントという開始・終了日時が決まっているデータ項目とは、そもそも構造がちがうのだから、これは致し方のないことだと、ずっと思っていた。

しかし、もっと困るのは、私のカレンダーを誰かがのぞいたとき、予定が入っていないと「ああ、佐藤君はこの日は空いているんだな」と思われてしまうことである。じつは、その日はTo Doがたくさんあって多忙かもしれないのに、である。

ところで、くだんの私の同僚は、実に意外な方法でこの問題を解決している。彼はプロジェクト屋だから、とうぜんTo Do Listを毎日抱えているわけだが、自分のカレンダーに、To Do Listの作業項目を、時間枠をとって書き込んでしまうのである。たとえば、「10:00-12:00 マンスリー・レポートを書く」といった具合である。To Doが増えて仕事が多忙になれば、当然カレンダーはどんどん埋まっていく。だから、勝手に他人が予定をのぞいて「彼はこの日はひまそうだから会議を入れよう」などと出来なくなるのだ。まさにコロンブスの卵である。

彼はこの方法を、「自分で自分を予約するのです」と説明していた。たしかにグループウェアには、会議室や機材などの資源を予約する機能がある。この類比で言えば、彼は自分自身の労働時間という資源を予約しているのである。

自己予約することによって、必然的に、そのTo Doのアクション項目が、どの程度の作業時間を要するのかについても、真剣に見積もることになる。また、あとでタイムシートをつける際にも、カレンダーをさかのぼって参照すれば、どの仕事に何時間働いたか、すぐに分かるという仕掛けだ。実に合理的である。

この彼の知恵は、資源の予約とは何か、という問題をあらためて私に考えさせるきっかけとなった。たとえば製造資源の予約という行為である。生産スケジューリングとは、ある意味で資源の予約と確定に他ならない。また、生産予定の予約は、ATP管理すなわち生産座席予約システムともつながっていく。しかし、目に見える機械資源の予約はある意味でわかりやすい。

むずかしいのは、目に見えにくい知的労働力の資源の予約と確定である。私は最近、ホワイトカラーの生産性向上とは、結局、自己管理能力のレベルアップにつきるのではないかと感じてきている。だとすれば、彼のような「自分自身の予約」は、奇抜に見えるけれど極めて良い方法ではないかと考えている次第である。
by Tomoichi_Sato | 2010-07-22 23:56 | 時間管理術 | Comments(3)

時計の針を進めておいてはいけない

あるとき、ビジネス雑誌の編集者の方に、「スキマ時間の活用法」というテーマでインタビューを受けた。日常生活や仕事の上で、10分とか20分、ふと時間ができてしまうことがある。電車での移動時に乗り換え待ちになるとか、アポイント先を訪問したら、思ったより早く終わってしまって、次の予定まで空きが出てしまうときなどである。こうした余裕時間をどう活用するべきか、時間管理術の観点から伺いたい、という質問であった。たとえば外国語の単語学習に充てるとか、メールをチェックするとか、次の訪問先の株価動向をネットで調べるとか、そんな感じの答えを期待されていたようだ。

私は、自分であらかじめ確保した集中できる時間と、外部からイベント・ドリブン的に与えられる時間では、その「質」が違うことを説明し、また自分だったらまずTo Doリストの見直し時間に充てるだろう、と答えた上で、逆に問い返した。「あなたは、本当にそんな小さなスキマまで埋めつくすような時間管理をしたいですか?」

その編集者は笑って、ノーですね、と言われた。実際そこまで几帳面に、あるいは追い立てられるようにして、時間を無駄なく使いたいものなのか、自分でも本音では分からない、とのことなのだ(でも、多分こうしたニッチ時間のマネジメントみたいな記事は読者の興味を少しは引くだろうと想定されたのだろう)。

聞いていて、つい、時計の針を5分か10分、進めておく習慣のことを連想した。腕時計や、家庭の居間の時計の針を、余裕を持つためにちょっとだけ進めておく人は、しばしばいる。だが、私はこのような「時間管理」の習慣には賛成しないし、にもそう書いた。

時計を進めておいてはいけない、という主張は、もともと父の教えだった。時計は時間を計測する計器である。「計器はつねに正確でなくてはいけない」というのが、技術屋だった父の思想であった。体温計を考えてみろ。体温計は正確でなくてはならない。それを、健康のためと称して、体温計が0.5℃くらい高めに表示するよう設定する奴がいたら愚かだ。これが根本にあった考え方だった。

余裕時間のことを、スケジューリング理論ではフロート、ないしバッファーと呼ぶ。もともとフロートとは、あるタスク(アクティビティ)の、期限日までの差を指す。期限までの日数が日で、タスクの作業所要日数が日であるとき、フロート=N-mで表される。フロートは大きければ大きいほど着手の余裕がある(着手日の「自由度」が大きい、という)。フロートがゼロの場合は、本日すぐに着手しなければ間に合わない。

フロートは未知の変動要因(リスク事象)に対応できる能力を確保しておくために必要とされる。私たちは先のことを完全に見通すことはできない。外部から急な飛び込みがあるかも知れないし、自分の側で急に不都合ややり直しが生じるかも知れない。こうした要因のために、現実は計画からしばしばずれていく。それでも、フロート(余裕日数)を持っていれば、こうした変動要因に対応することができるのである。

そして、スケジューリング理論の成果の一つは、フロート日数には加法性が効かない、という法則の発見である。フロートは、まとめて確保した方が、小さく分割して取っておくよりも有効なのである。1日分のフロートを確保いる状態は、2時間分のフロートを12個ばらばらに持っているよりも、ずっと計画からの変動に耐えうるのである。この理由を説明するには多少の数学的知識がいるが、分散には加法性が成り立つが標準偏差は1/2乗則が効いてくる、と言えば少しは想像がつくだろうか。細切れにしたフロートは役に立たない、と言いかえてもいい。それゆえ、フロートをどこにどう配置しておくのが良いのか、という議論が出てくる(これをバッファー・マネジメントとも呼ぶ)

そして、だからこそ私は、時計の針を進めて5分や10分と言った小さな余裕時間をちょこちょことる習慣に賛同できないのである。それよりもあらかじめきちんと時間の使い方を計画しておき、その中にまとまった「使途未定のバッファー時間」を取っておく方が、ずっと有効である。

そこで、スキマ時間の活用の話に戻る。--本当にスキマを埋め尽くしたいですか? とたずねられて、答えに逡巡する人は、たぶん時間管理というものを誤解しているのである。時間管理の目的は、時間に吝嗇になることではない。5分、10分といった時間を節約して、いったい何に活かすのか? インドの文人(ガンジーだったかも知れない)がイギリスの学校を訪問していた時、校長室に「たった今、100m走で従来記録を0.1秒縮める新記録が出ました!」と興奮した知らせが飛びこんできた。するとインド人は「その節約した0.1秒を、その学生さんは何に使うんですか?」とたずねた、という。それと同じことだ。

時間管理の目的は何か。それは、考える時間を作ることなのである。追われている毎日の中では確保しがたい、落ち着いて考える時間を作ること。言いかえれば、傍目には、「何もしていない時間」とみえる時間を作ることだ。私たちには、じっくり考えたいことがいろいろある。新製品のアイデアかも知れないし、ビジネスの行く末かも知れないし、あるいは自分自身の身の振り方かも知れない。だからもし、「使途未定の時間」を幸運にも使わずにすんで、まとまった時間が残ったら、それは是非、考えることに使いたいのだ。そして人間が考え事に集中するためには、最低15分くらいは要る。そのためには、5分や10分の細切れでは足りないのである。
by Tomoichi_Sato | 2010-07-19 22:18 | 時間管理術 | Comments(0)

計画とスケジューリングの区別

計画=予測+意志決定」だ、と以前「計画作業の中心とは」で書いた。それでは、その『意志決定』の具体的な中身とは何か。

それは、簡単に言うと、計画対象となる系の目標値を定め、それを実現するような政策変数を、制約条件下で決めることである。え? ちっとも簡単でない? 言いかえると、可能な選択肢の中から、自分が望ましい結果を得られそうな組合せを決めることだ。これを計画における意志決定という。

例を挙げよう。旅行の計画を立てるとしようか。たとえば週末にふらっと札幌に遊びに行きたいと考えたとする(あなたが札幌に住んでいないとしての話だが)。移動手段は何にしようか。自動車、鉄道、飛行機・・可能な手段の中で、「札幌に行く」という目的を達成できるものを選ぶわけだ。制約条件は、たとえば所要時間とか費用とかだろう。そして、鉄道と決めたら、こんどは時刻表と相談して適当な列車を選ぶ。

宿にかんしても同様だ。気安い友人宅があればそれも良し、なければ数あるホテルや宿泊施設の中から適当なものを選ばなくてはならない。そのときも財布の中身という制約条件と相談になる。そして適度な価格帯のリストの中から考えることになる。この、可能な選択肢の幅広さを『自由度』とよぶことを覚えておいてほしい。『自由度』は計画におけるキー概念の一つだ。

さて列車が決まり、宿が決まると、あとは何を見て回ろうか、という話になる。こうして、次第に旅行のイメージは具体的な、「旅行計画」とよぶにふさわしいものになっていく。可能な選択肢の中から、自分が望ましい結果を得られそうな組合せを決める意志決定を行なったからだ。

この旅行計画において、「移動手段を選ぶ」ことは「週末、札幌に行って遊ぶ」という目的を実現するために、必要な課題の一つである。「宿を決める」も同様だ。このように、目的達成に必要な課題をタスクと呼ぶ(プロジェクト・マネジメント理論では「アクティビティ」と呼ばれることも多い)。計画立案という行為においてはつまり、目的達成に必要な「タスクを洗いだす」(英語でいえばIdentify tasks)というサブ問題を、まず最初に考える。

次に、「タスクにリソースをわりあてる」というサブ問題が来る。『札幌まで移動する』というタスクに対するリソースとして、自動車/鉄道/飛行機というリソースの中から、予算の制約の中で適当なものを選んだ。

そして、時刻表を見て列車を選び、出発時刻や到着時刻を決めることは、「タイムテーブルを作成する」に相当する。これがいわゆる狭義の『スケジューリング』問題である。

以上をまとめると、計画立案における意志決定とは、以下の三つのサブ問題を解く作業に他ならない。
(1)必要なタスクを洗いだす(Identify tasks)
(2)タスクにリソースをわりあてる(Assign resources to tasks)
(3)時間表を作成する(Create timetable)

いいかえれば、スケジューリングとは計画立案のサブ問題であることが分かる。

この3ステップは、個人の旅行計画のみならず、プロジェクト計画から生産計画、販売計画、在庫計画などにすべて共通である。

もっとも、計画問題の性質によっては、いずれかのサブ問題が不要なこともある。たとえば野球チームの監督が決める配員計画などは、ポジションという名前のタスクにひとつづつ担当者を振り分けて終わり、である。これには時間表作成のサブ問題がない。また、リソースの選択肢がなければ、リソースわりあての問題がない、などだ。スケジューリングとは、本質的には(3)のステップが不可欠な計画問題を相手にする仕事なのである。
by Tomoichi_Sato | 2010-07-15 00:04 | 時間管理術 | Comments(0)

時間の中に生きる

久しぶりに、自著『時間管理術』を読み直してみた。古い友人から、「偶然手に取ってみたら案外面白かった」とメールをもらったからだ。そして、おかしなことだが、自分でも案外面白かった(笑)。この本を書いてから3年経つが、中心となるアイデアや技法は無論すべて覚えているものの、ストーリーづくりや話法はけっこう忘れていたからだ。まあ、本の著者なんて案外こんなものである。

自分が読んだら面白いだろうなと感じるような本を書きたい、といつも思っている。共著・編著を含めたら1ダース以上の本を出してきたが、うまく書けたかどうかは、時間をおいて読み直してみるとよく分かる。時間をはさむと、自分はいつも少しだけ他人になるからだ。

私たちは忘れる能力を持っている。嫌なことも、良いことも忘れていく。もちろん、私たちは記憶し続ける能力だって持ち合わせている。それがあるから、一人の人格として継続性を持ちうるのだ。もし一晩寝て起きるたびに、直近の過去のことを一切忘れていたら、私たちはアイデンティティ=自分が誰であるか、を持ち得ないだろう。そんなSFじみた世界では誰も、魂の不滅、なんて宗教的な問題は考えるまい。自分が誰なのか、考える手がかりもないのだから。記憶の連続性こそ私たちの自我の骨格を形作っている。まれに脳の損傷などで長期記憶をもてない人が医学的記録に出てくるが、こうした人も、若い頃の記憶だけは保っていて、だから人格として成立しているのである。

しかし、すべての出来事をずっと記憶し続ける能力があったら、どうなるか。便利だと思う反面、つらい体験や恥ずかしい失敗もすべてリアルに覚え続けているのは、かなり苦痛だろう。なにより、すべての過去が強弱なく同等にならんでいる心的世界では、個性や特徴も生まれてこないにちがいない。記憶の濃淡やめりはりがあって、はじめて意見や好みも出来上がるのである。記憶の濃淡とはつまり、大事なことを覚え、大事でないことは適度に忘れることを意味する。適度な記憶の連続性と、適度に忘れる能力。こうして私たちは自分をとりまく世界に構造や意味を与え、適応していく柔軟性を獲得するのだ。

『時間管理術』のエピローグでは、自分のキャリア・パスのスケジューリングについて悩む若い質問者を登場させた。仕事を続けてキャリアを磨きたい。しかし留学してもっと勉強もしてみたい。留学がキャリアの断絶を意味するなら、早いうちが良いのかもっと後が良いのか、という問いかけである。女性ならばさらに、出産や介護といった事象もキャリアの蓄積に対するリスクとなりうる(この部分の記述は、日経文庫の編集者が慎重を期して、周囲の女性に問題ないかどうかレビューをしてもらった)。

これに対して、タイム・マネジメントの解説役であるY氏(主人公S君の叔父で、引退したコンサルタント)は、こう答える。「それを決めるためには、仕事の面から見た人生の目標と、自分に与えられた時間や境遇の制約を考えなくてはなりません」--これは無論、タイム・マネジメントの一般的な方程式である。その“与えられた時間”をイメージするために、彼は『人生時計』を紹介する。

『人生時計』というのは、0歳の誕生が朝6時に相当し、10歳が朝の8時、20歳が午前10時という風に、10年を2時間刻みで換算した時計である。45歳が、人生の午後3時を示し、90歳で、深夜零時にいたる。1年が12分、1月が1分、12時間でほぼ1秒に相当する。今、自分の年齢が何時何分にあたるかを考え、引退までの時間の長さと、キャリア・パスを考えてみるのである。何十年もの時間を想像するのはむずかしいが、時計の文字盤ならばイメージがわく。そして1、2年のキャリア中断は、10分か20分ほど席を外す程度にしか相当しないのだから、あせらずに大局から計画を立てなさい、とY氏は説明するのである。

この人生時計は一応私の創案だが、似たようなことを考えた人は他にもいると思う。『時間管理術』を読んだ人から、「ギクリとしました」と感想をもらうこともあった。たいてい私たちは、こうした大局観を忘れているからである。なぜ忘れるのか。それは「忘れる能力」のためではない。実は忙しすぎて、考える時間がないからである。仕事も確かに大事だろうが、自分のキャリア・パスを考えることはもっとずっと重要なはずである。それなのに私たちは毎日、“緊急だが重要でないこと”に追われて、“緊急でないが重要なこと”を考えるゆとりをとれなくなっている。

時間管理術の最終的な目的は、考える時間を確保することにある。考えている時間とは、傍から見ると、「何もしていないように見える時間」である。現代社会にビルトインされている様々な“時間どろぼう”(ミヒャエル・エンデの小説「モモ」の登場人物)が、私たちの考える時間を、片端から奪っていってしまうのだ。

私たちは時々立ち止まって、手を休めて、考える必要がある。そういう意味のことを、「静寂の価値」でも、「エントロピーを下げる」でも、「パンのみに生きるにあらず」でも、私は本サイトで折にふれて繰り返してきたように思う。でも、もう一度書こう。私たちには、考える時間が必要なのだ。

e0058447_0311792.gif

by Tomoichi_Sato | 2010-01-03 23:56 | 時間管理術 | Comments(0)

早期着手かジャストインタイムか

期日を決めた督促には、副作用がある。それが『学生シンドローム』と呼ばれる現象である、と前回書いた。学生シンドロームとは、期日ぎりぎりになるまでタスク(アクティビティ)に着手しないで放っておきがちになる、人間の性(さが)みたいな事象である。

もう一つ、人間には悲しい性がある。それは、怒られるのが恐いためにサバを読みがち、という傾向である(・・どうでもいいが、この「性(さが)」って言葉をくりかえし使っていると、なんだか昼のメロドラマの解説みたいになってくるな)。

期日を約束しても、それを守れないと、相手に(そしてたぶん上司にも)怒られる。怒られたら、うれしくない。今度の査定に響くかもしれない。だったら遅れなければいいだろ!、というのは上司の側の論理である。現実にはいろいろな割り込みやトラブルや掛けもち仕事があるじゃないですか。だったら、10日で終わりそうな仕事でも、「20日かかります」とサバを読んで申告しておけばいいか。そうだ、そうしておこう・・

こうして、異なる部署間の期日の約束事には、しばしば余裕日数(サバ)が入り込んでくる。期日は依頼する側が一方的に決められないしきたりだ(当然だが)。タスクを請け負う側の都合や自己申告にあわせる必要がある。

ほぼ同じ種類のタスクを繰り返した場合でも、着手から完了までの所要期間には、いろいろな幅(ばらつき)が出てくるものだ。なぜ、タスクの所要期間に幅が出るのか。理由はさまざまである。ほかとの掛け持ち仕事(マルチタスキング)のために、一部の時間しかさけない、というのが最もありがちな理由であろう。急な割り込み、というのもよくある話だ。必要なインプットの情報や材料の到着が予定より遅れる(上流側の遅れの影響を受けた)、というケースだってある。というわけで、ホワイトカラーの仕事というのは、工場で部品を旋盤で削る仕事と違って、数量×単位時間あたり生産性=所要期間、みたいなスケジューラ的計算は成り立たないのである。と、広く信じられている。

さて、そこで問題です。作りすぎのムダを排除する「ジャストインタイム」(JIT)については、このサイトの読者なら誰もが聞いて知っておられると思う。JIT生産では、作りすぎによる在庫のムダをさけるため、必要な時になるまで作らない。つまり、ぎりぎりまで待って着手することを良しとしている。

その一方で、できることは先に着手するべし(「今日できることを明日に延ばさない」)というポリシーも、よく耳にする。じっさい、『学生シンドローム』を避けるには、後回しにするな、可能ならすぐ着手すべし、と主張したくなる。この二つの指針は、どちらが正しいのか?

この問いかけは、拙著「革新的生産スケジューリング入門―“時間の悩み”を解く手法」でも書いた問題である(第1章『いつ宿題をやるか--最早着手と最遅着手』参照)。スケジューリング理論では、EPST(Earliest Possible Start Time:最近ではESとも略す)とLPST(Latest Possible Start Time:LSとも略す)という二つの重要な概念があるが、前者は「着手可能になった時点ですぐに」、後者は「納期に遅れずに済むぎりぎりの時点で」仕事を始める日時、をそれぞれ指すのである。だから、上の問いかけは、こう言い直すこともできる:仕事はLPSTで着手するのが正しいのか、EPSTで着手するのが正しいのか?

この問題が生じるのは、EPSTとLPSTの日時が異なるからだ。EPST=LPSTならば、どちらかを選ぶ意味はなくなってしまう。ではEPST=LPSTとなる状況とは? それは、クリティカル・パスに乗っているアクティビティである。あるいは、ボトルネック工程にある作業である。これらのタスクでは、上記の問題に悩んでいる余裕はない。最速で仕事をするしかないからだ(ジャストインタイムが徹底している工場では、ほぼ全ての工程がボトルネックに同期化されるよう設計されている)。

問題は、EPST≠LPSTとなる場合である。LPST-EPSTのことを『フロート日数』と呼ぶわけだが、つまりフロート日数のある仕事はどちらが正しいか、ということになる。で、どちらだろうか?

こうした質問を受けたら、反射的に考えるべき事がある。それは、“「正しさ」とは、何のモノサシで測るかによってちがう”、ということだ。

もし「仕掛り在庫低減」がモノサシの場合、当然ながら最遅着手(JIT生産)が正しい答えである。ただし、これできちんと仕事を回していくためには、当然ながら所要期間のばらつきをかなり小さくできている、という前提条件がついている。それなりの作業習熟度(成熟度)が要求されるのである。

逆に、一刻も早く製品ないし成果物を出荷することがモノサシの場合、当然ながら最早着手が正しい答えになる。そして、各タスクは可能なかぎり早く完了させる。完了したら、すぐ次のタスクにバトンタッチさせる。実際には早く終わったのに、報告しないでおくようなことはさせない(なぜそんな事が起きるかといえば、「サバを読んで期日を約束しておいたため、現実は早く終わったのだが、ここで正直に報告すると、次回から短い期日を約束させられるだろう」などと憶測する“頭の良い”人たちが出てくるからだ)。

ついでにいうと、納期遵守が受注後の唯一のモノサシの場合も、最早着手が正解ということになる。これは、じつは顧客に怒られたくない営業部門の場合の論理である。その結果、仕掛り在庫という社内のコスト=利益率低下は不問にされるわけだ。営業部門の目標は売上高であって、利益率は工場の責任である、と考えているような組織では、こうして「早く早く」のかけ声が社内を駆け巡る、という状態になりがちなのである。

ということで、つい寄り道をして、ゴールドラット博士の「画期的な解決法」について書くつもりが、今回もまた書けなかったようだ。続きはまた、ということで。
by Tomoichi_Sato | 2009-11-23 10:35 | 時間管理術 | Comments(1)