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

Web連載記事のお知らせ

技術評論社のWebマガジン「エンジニア・マインド」に、連載「タイム・マネジメントの心得」第8回 『クリティカル・パスをみつける』を掲載しました。どうぞご覧ください。
by Tomoichi_Sato | 2008-12-20 19:38 | 時間管理術 | Comments(0)

Excelで工程表を書いてはいけない

さる8月、翔泳社主催の「PM Conference 2008」に招かれて講演をした。テーマはプロジェクト・コントロールの技法論で、私が長い間、エンジニアリング業界とIT業界の二足のわらじを履いてきた経験から、両者の比較を論じたものだった。最近のIT業界における「プロジェクト・マネジメント」の認識の普及進展はめざましいものがある。これに対して、エンジニアリング業界は過去10年以上、EVMSの徹底化以外とくに主立った進歩はない。にもかかわらず、両者の違いはいまだ歴然としたものがあり、それはとくにプロジェクト・コントロールの基本であるWBSやコントロール・リストなどの使い方で明瞭だ、というのが論旨だった。

ところで、この講演の中で、「工程表のガントチャートをExcelで書いてはいけない」と強調した点が、どうも多くの聴衆の注意を引いたらしい。終わってからのアンケートでも、そこに関する感想が少なくなかったし、講演後、直接私のところに質問に来られた方もいた。“ じゃあどうしたらいいんだ?”“何か良いツールはあるのか?”というのが率直な疑問らしい。

Excelでガントチャートを書きたくなる理由は、私もよく分かる。まず、事実上すべてのPCにのっており、誰でも読み書きできる。縦横に罫線があり、ガントチャート作成に便利に思える。お絵描きの道具がそろっていて、すぐに矢印を引ける。担当者の名前や作業量なども表に書き込める。必要なら、さらに引出し線だの注釈だの好きなコメントを書いていける。実に便利である。

にもかかわらず私が、Excelで工程表を書いてはいけない、と説明したのには三つの理由がある。第一の理由は、クリティカル・パスが見えないことだ。プロジェクトの出発点から、全作業の完了までの経路の中で、時間的に最長の経路をクリティカル・パスとよぶ(日本語では「隘路」だ)。プロジェクト全体の納期は、このクリティカル・パスの長さに等しい。したがって、プロジェクトの納期短縮を図りたかったら、どこがクリティカル・パスになっているかを見つけ出して、それを短くすることを考える必要がある。

コスト=原価管理の世界では、プロジェクトのコストは、すべてのアクティビティのコストの足し算になる。大小を問わずどのアクティビティで1円節約しても、全体予算の1円節減に直結する。だからコスト・マネジメントでは、基本的にすべてを軽重なく公平に見ていく必要がある。ところがスケジューリングの世界では、クリティカル・パスの長さだけがプロジェクト全体の期間を決める。非クリティカルなアクティビティについていくら期間短縮の努力を払っても、全体には何の影響もでない。そこでタイム・マネジメントでは、重要な管理対象と重要でないものが峻別される。これがマネージャーにとって最も大きな違いだろう。

Excelで工程表を書いてしまうと、ここが見えなくなってしまう。「だったら太線にしたり、赤く表示したらいいじゃないか」というのは浅知恵というものだ。クリティカル・パスは、作業が進むにつれて(その進捗や遅延にしたがい)しばしば他の経路に移ってしまうことを忘れている。このため、潜在的にクリティカル・パスになりやすい経路を、「サブクリティカル・パス」と呼んで、最初から注意しておく必要がある。CPMの技法論でいえば、フロート日数=ゼロの経路がクリティカル・パスになる。そこで、フロート日数が(たとえば)2週間以内の経路をサブクリティカルとして認知しておく、などの工夫がいるのだ。Excelの線表では、このフロート日数が見えてこない。

第2の理由は、先行作業が遅れた場合の影響範囲がわかりにくい、ということだ。実際問題として、プロジェクトというのは遅れるものなのである。これは、最初に作成する工程表が「ターゲット日程」を表しているものである以上、当然のことだ。そこで、実務上問題となるのは、前方の作業が遅れたとき、後ろの方のアクティビティが着手するのはいつになるのか、という点だ。これはとくに、担当者や担当部署が異なるときは悶着のタネだ。ところが、Excelの線表というのは、一つの線を延ばしたら、後ろにつながる線を全部、自分の手で書き直さなくてはならない。当然、ここにはミスが入り込む可能性も出てくる。

3番目の理由は、スコープの追加や、WBSの変更に対応した修正が面倒であることだ。これは第2の理由とも通じるが、部分的な修正が全体の変更につながる、というのがプロジェクト・ネットワークの性質である。これを、書き手がすべて自分の頭の中で追いかけなくてはならない。そして、追加変更は、プロジェクトに宿命的について回るものである。

結局、Excelで書いたガントチャートは、ロジック無き「絵」にすぎないのだ。プロジェクトの工程表とは、背後にロジック・ネットワーク・スケジュールを持っていなければならない。ここが根本的な認識のズレなのである。Excelで工程管理してはいけない。私の主張は、この点にある。

じゃあ、工程表どんなツールで描いたらいいのか?--こういう質問が出てくる点が、まあいかにもIT業界らしいな、と感じてしまう。こちらは考え方の話をしたつもりなのに、いつの間にかツール論になっている。ツールとはさみは使いようだから、上記のことさえ忘れなければ、別にExcelを使うこと自体がわるいわけではない。まあ、不便だが。

それでも、何かのツールを推奨しろ、という話になると、ちょっと困ってしまう。Microsoft Projectは誰もがまず思いつく製品だろうが、いくつか理由があって、私はMS Projectはあまりおすすめしない。たとえば後続のアクティビティをすぐに見つけにくい、だとか、アクティビティ数が増えていくとひどく重くなるとか、は機能的問題だからまだしも、Forecastという概念がないとか、プロジェクト全体の締切というものがクリティカル・パスの長さとは別に規定されているとか、概念自体に違和感を感じる。

米国でのある調査でも、MS Projectはもっとも多く購入されているが、もっとも使われていないプロジェクト・マネジメント・ソフトだという結果が出ている。そもそも、この製品を出しているMicrosoft自体、自社の主力製品をリリースする際、期日変更や早期パッチの常習犯になっていないだろうか。自社のプロジェクトをきちんとマネジメントできない会社の製品を、私はあまり信用したくない。むろん、ツールは使いよう次第。現在この製品で十分うまく仕事を回している人に対してまで、使うのをやめろと主張するつもりはない。限界を知った上で、ツールを使い倒すのが、プロの仕事というものだろう。

じゃあ、そういうおまえ自身は何を使っているのか? そういう質問もあるだろう。私自身は、二つの製品をほぼ毎日使っている。一つは、Primavera Project Planner(略称P3)だ。これはエンジニアリング業界では事実上の世界標準であり、海外のほとんどの顧客から、これを使え、と指定される。P3は、いわば超高級Microsoft Projectであり、とくに1,000以上のアクティビティからなるプロジェクト計画では、ほぼこれ以外に使い物になるソフトはないと言っていい。

そのかわり、これは「プロの使う道具」である。機能が多く、スキルが必要だ。どうしても、スケジュール・コントロール専門職のツールになってしまう。おまけに、世界中で広く使われているVer. 3は英語版だ。最新のVer. 6は日本語も通るが、高くて重くて人気がない。しかも、Primavera社は先月、とうとうOracle社に買収されてしまった。この先、旧バージョンがどうなっていくかは誰にも分からない。いずれにせよ、日本国内での仕事で、かつアクティビティ数が50から100程度の工程表には、P3はおすすめではない。

ちなみに、私がもう一つ使っているのは、ソフトブレーン社の「e工程マネージャー」である。これは、かつて企画段階に私自身が参画した製品なので、私が使っているのは当然だし、ここで何か言っても宣伝にしか聞こえないだろうから、あまり詳しく述べるつもりはない。Ver. 3になってだいぶん良くなったが、改善すべき課題はまだ多いと私自身は感じている。

それにしても、どんなツールが良いのか? という問に対しては、こう答えるしかない。まず、あなた(の会社)は、それにいくら払う用意があるのか。数万円か、数百万円か? それはつまり、プロジェクト・マネジメントの向上にいくら価値を認めるのか、という問いかけである。プロジェクトの失敗で数千万の赤字を出した経験のある企業は少なくない。なのに、プロマネに数万円の工程表作成の道具代を配ればどうにかなるだろう(これだってあわせれば百万にはなるだろうが)、という楽観的なポリシーで運営されているとしたら、“グッド・ラックを”というのが唯一の回答かもしれない。それが「ツール」と言えるのかどうかは自信がないが。
by Tomoichi_Sato | 2008-11-24 10:49 | 時間管理術 | Comments(31)

Web連載記事のお知らせ

技術評論社のWebマガジン「エンジニア・マインド」に、連載「タイム・マネジメントの心得」第7回 『仕事の工程表をつくる』を掲載しました。どうぞご覧ください。
by Tomoichi_Sato | 2008-11-20 23:24 | 時間管理術 | Comments(0)

メーラーを閉じろ

時間管理術」のような本を書き、タイム・マネジメントに関して時おり講演などをしていると、たまに思いもよらぬ誤解にあうことがある。「佐藤さんはきっと仕事が速いんでしょう」というのは、まだかわいい方で(自慢ではないが人並みのスピードでしか仕事はできぬし、文章を書くのは遅い部類である)、「きっと早起きで夜もあまり眠らないはずだ」などというのは、どこをどう押したらそういう理解が出てくるのか不思議に思う。私にとって日常の主要な関心事は睡眠時間の十分な確保であって、寝る間も惜しむ時間管理術など、私の最も好まぬ解決法だからである(『睡眠時間の必要』2007/08/06)。

もともと、時間というのは1日24時間、誰にも平等に与えられている。それをどう、うまく使うかがタイム・マネジメントの要点なのだが、「時間が足りないのは自分が浪費しているせいだ」とはたいてい考えず、“あの人が楽そうに見えるのは、本当に楽な仕事しかしていないか、めちゃめちゃ仕事が速いか、あるいはどこかから時間をよけいに取りだしているからにちがいない”という風な憶測が生まれるらしい。

タイム・マネジメントにおいて一番重要なことは、『着手日を決めて、それを守る』ことで、これは本にも書いたとおりだ。我々は日常、さまざまなタスク=宿題を抱えてすごしている。各タスクには、締切や納期や、(もっとたちのわるい場合)ASAP、つまりAs Soon As Possible「できるだけ早く」という条件がついている。そこで、タスクを完遂するのに必要な期間を見積もって、最遅着手日(LS = Latest Start)を考え、他のタスクとの優先順位を考えながら最早着手日(ES = Earliest Start)との間で実際に着手すべき日を決める、というのが基本だ。

むろん、現実には予期せぬ割り込みや遅れがつきものだから、所要時間の見積には幅ができる。いつも最遅着手日に着手していたのでは、納期を割り込むリスクがあるわけだ。だから最小限のバッファー日数を考えて着手日を決めなくてはならない。これは、工場の生産スケジューリングだろうが、オフィスでのワーク・スケジューリングだろうが共通の原則だ。

ところで、オフィスワークにかぎって言うと、ここに一つ考慮すべき要素が入ってくる。それは『集中度』というパラメータである。知的成果物をつくる仕事には、ある程度の精神的な集中が必要になる。より良い仕事が求められれば求められるほど、「連続して集中して考える時間」が入り用になるのだ。これはどのようにスケジューリングに組み込むべきだろうか?

オフィスワークの仕事量は、ふつう人日や人月で測られる。IT産業はその典型だ(私の属するエンジニアリング産業では、人時で測るのが国際的な慣習になっている)。5人日の仕事とは、すなわち、一人でやったら正味5日かかる分量を示す。これを私は「量としての時間」とよんでいる。この人が、似たような仕事をもう一つ同時に抱えていて、両方を平行に作業していたら、終わるのは10日後になる。5人日の仕事だが、所要期間は10日の長さである。これを私は「長さとしての時間」とよんでいる。コンピュータの世界でいう、ellapsed timeである。そして、多くの場合、同時並行のタスクを二つ持とうが三つ持とうが、個々に必要な人日は変わらない、と仮定する。

ところが、ソフトウェア工学で有名なトム・デマルコは、これはたいへんな間違いだという。
彼は、“ソフトウェアの開発工数とは、集中して考えられる時間の合計で測られるべきだ”と主張している。あるモジュールの開発工数が100時間だとすると、それは、静かに集中して考えられる時間が合計100時間必要だということだし、集中できない細切れの時間が1000時間あったって、そのモジュールは完成しない、と彼はいう。つまり集中して考えることのできる2時間と、10分ずつ細切れになった合計の2時間では、まったく質が異なるというわけだ。

私もこの考え方には、まったく同調する。そもそも、オフィスワークの生産性を下げる第一の要因は、他人からの割り込みなのだ。考え事をしている最中に上司に呼ばれたり、電話が鳴ったり、誰かに話しかけられたりして、集中が途切れると、あとでまたその集中状態に戻るには、かなりよけいな手間と時間がかかる。この間の生産性の低下は、誰がどう補ってくれるというのだ。

しかし、あなたが組織で仕事をしている限り、上司や同僚を切り捨てるわけにはいかない。個室でも与えられていれば別だが、日本ではそんな贅沢はまず望めない。

それでは、どうしたら良いのか? じつは、ここには一つの解決法がある。それは、職場全体で「集中タイム」を設定することである。たとえば、朝9時から11時まで。その間は、会議も招集しない。電話もかけない。部下も呼ばない。ただ皆が、自分の席で仕事に集中するのである。これを実践している会社もある。

そんなこと、ウチの会社では不可能だって? そもそも、外から電話がかかってきたらどうするんだ? --たしかに、そうだ。しかし、昨今、電話というものはずいぶんと少なくなったのも確かである。今や、たいていの仕事の連絡は、電子メールで行われる。ひどいときには、隣の席にいるのに、メールを打ったりしている。同時発信の効用があるからだ。面と向かっては言いにくいことだからメールにしたりすることもある。おかげで、電話のベルが鳴る回数は以前に比べて、ずいぶん減った。

そこで、もう一つの解決法がうかぶ。つまり、メーラーを閉じて、自分で「集中タイム」を自発的に作ってしまうのである。なぜ、オフィスにいる間じゅうずっと、メーラーを開けていなければならないのか。電子メールとはそもそも、非同期的な通信手段である。相手を呼び出して、同時性を強制的につくりだす電話とは質の異なる手段だ。だから、到着したからといってすぐに読みに行く必要も義務もない。さっき送っただろ! と送信者に文句を言われたら、「え、まだ読んでなかった」と答えればすむ。だって、会議で2時間席を空けて、読めない可能性だってあるのだ。いつからメールはリアルタイムな通信手段になったのだ。

ある調査によると、55%の人が、どんなに忙しくても届いた途端にメールを読みに行っている、という。これはじつにもったいないことだ。そんな必要性はないのだ。メールは、そもそも自分の都合で読みに行けばよい。集中したいときは、メーラーは閉じておけばいい。まるで、どこに球が飛んできてもすぐにキャッチしようと、ずっと中腰になっている内野手のように、メーラーを開け続けていることは自分の負担なのだ。

自分が集中したい時間帯は、メーラーを閉じよう。そして、自分が自分の主人になれる時間を作りだそう。
by Tomoichi_Sato | 2008-10-18 18:36 | 時間管理術 | Comments(3)

ロジック・ネットワーク・スケジュールとは何か

昨年『時間管理術』を執筆していたとき、エクササイズ2「『できる人』の仕事ぶりを見て学ぶ」の節で、時間管理の上手い人の条件の一つに“スケジュールのバーチャートを必ず引いている”と原稿に書いた。そうしたら担当の編集者の人から、「こんな人は普通いませんよ。」とコメントされてしまった。結局、そのフレーズは削除することにした。

そうか、そんな人は普通いないのか。それが私の率直な感想だった。というのは、私のまわりで仕事のできる人は、“そんな人”ばかりだからである。仕事の相談をしたら、内容の後に、必ず段取りを決めて、バーチャート(ガントチャート)を描かないと安心できない。そんな人の多いエンジニアリング業界で、私はそれなりの年数働いてきた。しかし、経済新聞社の編集局の人の感覚の方が、たぶんずっと普通だろう。

ところで前にも書いたとおり、最も多くのプロマネが使っているPMツールは、実はExcelなのだという。Excelで何をやっているかというと、タスクリストの管理やコストの集計といいたいところだが、一番ポピュラーなのはたぶんガントチャートによるスケジュール作成だろう。私も、あちこちの会社のプロジェクトで、Excel丸出しの線表をよくみかける。何せExcelの作図機能はある意味、融通無碍だから、Microsoft Projectなどではかけないような注釈やら色分けやらを駆使できるというわけだ。

それがわるいと非難するつもりは毛頭ない。全然ガントチャートを描かないよりは、描いて計画のベースラインとするほうが、ずっと良い。しかし、それで十分だとは言えない。バー・チャートだけでスケジュール・コントロールするのは危険なのだ。なぜなら、単なる線表には、ロジックが無いからだ。プロジェクト・コントロールには、ロジック・ネットワーク・スケジュールが是非とも必要なのである。

ロジック・ネットワーク・スケジュールとは何か。それは、全タスク(アクティビティ)間の論理的順序依存関係をきちんと定義したスケジュールである。基本構造の設計が決まらないと、主要部品の購買に着手できない。主要部品の購買が完了しないと、組立工程に着手できない--こうした順序関係のロジックである。これをきちんと定義していくと、結局プロジェクトのスタート点からゴール点まで、全体として網目のような図表ができる。これをプロジェクト・ネットワーク・ダイアグラムとよぶ。

そして、プロジェクト・ネットワーク・ダイアグラムができると、隘路(クリティカル・パス)が定まる。つまり、本当の納期が見えてくるわけだ。そして、あるアクティビティの着手日や期間を変更したら、後続のアクティビティにどう影響するかも、すべて論理的に決まるし、自動計算もできる。これがロジック・ネットワーク・スケジュールなのである。

図を見てほしい。単純なガントチャートでは、なんとなく階段型にタスクがつながっていると、それらがすべて時系列的におこるのかな、と見えてくる。しかし、実際には図の下のようになっているのかもしれない。この場合、Bの期間が長くなっても、Cの開始には影響しない。Excelで線表を引いているだけでは、AやBに変更を加えた際、後の方をすべて手で直さなければならないばかりか、どこをどう直せばいいのか、すぐに判断できない。タスク数が10や20ならそれでもいいだろうが、50や100を超えたらもうお手上げである。また、各タスクに必要なマンパワー資源を見積もって、その積算を行う、などといった計画作業にも、ロジック・ネットワーク・スケジュールは必須である。

(余談だが、エンジニアリング業界でロジック・ネットワーク作成する際は、Microsoft ProjectではなくPrimavera Project Plannerというソフトが国際的なデファクト標準として使われている。ただしこれはプロの使う道具であって、コントロール対象のタスク数が100-200以下の規模だと、かえってお荷物という気がしなくもない)

いずれにせよ、優れたプロジェクト計画を作るためには、ガントチャートは必要条件に過ぎず、ロジック・ネットワークの定義が十分条件であるということを忘れるべきではあるまい。
e0058447_2392117.gif

by Tomoichi_Sato | 2007-11-25 23:09 | 時間管理術 | Comments(0)

外注のスケジュール・コントロール

カミカゼ・タクシーという言葉があるなら、その運転手にこそふさわしい呼び方だった。ある外国企業とジョイント・ベンチャー・プロジェクトを始める打合せのために、我々は空港からタクシーを拾ったのだった。目的地まで何分かかるかたずねたら、運転手は答える代わりに猛スピードで走り出した。高速道路を時速120km以上で飛ばしながら、混み合う車の列を、ほんの10cm間隔ですり抜けて走る。

「寿命が縮むかと思ったよ。」目的地について、助手席からふらふらになって降りた営業部長はそう言った。「ガイドブックには約40分って書いてあったが、たった15分で来たものな。」

初顔合せの相手と組んでプロジェクトを始める時の気分は、初めての外国でタクシーに乗る時の緊張に、少し似ている。道は分からず、言葉はロクに通じず、しかも荷物も時間も相手に任せきるしかない。ひどい回り道をされて、余計な運賃を請求されるケースも多い。かのカミカゼ運転手は、最短経路を最短の時間で運んでくれて、メーター通りしか請求しなかったのだから、まだ良心的な部類だったと思うべきだろう。

私の勤務先・日揮はエンジニアリング会社だが、プロジェクトの8割近くが海外向けである。国も場所も毎回異なるため、初顔合わせの相手とパートナーを組んだり、初めてのベンダーから重要な資材を買ったりしなければならないことが多い。相手を選ぶときは会社が定めた手順に従い、慎重にも慎重を期するし、契約書や調達仕様書には成果物も納期も品質も支払い条件も、事細かにしばりを入れている。

だが、それでも、予定通りに満足すべきアウトプットが出てくるかどうか、勝手に余計な回り道をされて、追加の手間や費用が発生しないか、ひやひやしながらつき合わなければならない。相手に支払うコストや役務のスコープは、状況を見て増減できる。しかし、時間はいったん失ったら二度と戻ってこない。身柄をあずけてタクシーに乗るのと、同じ気分なのだ。

気心の知れた相手と、くり返し同じ種類の仕事をする時と比べて、初顔合わせのプロジェクトでは、過去の経験値がない分、プロジェクトの進め方に注意が必要となる。では、初顔合わせの相手とのプロジェクト・スケジュールを立案する時は、どうやって期間(納期)の見積をすべきだろうか?

答えは簡単で、相手に聞くしかないのだ。--タクシーと同じである。旅行ガイドブックには目安の時間が書いてあるだろうが、混雑状況次第でいくらでも変わりうる。自社内で仕事をやる場合や、系列企業に発注する場合は、「これこれの期間内でやってほしい」と依頼することができる。しかし、未知の相手と初めて組む場合、過去の経験値の蓄積がないから、向こうの納期回答をまず聞く必要がある。

大事なのは、この時の聞き方である。単に納期をたずねるだけでは不十分だ。必ず、結果に至るプロセスをたずね、そのステップごとに工期を分解して聞く。そして、どこでチェックポイントを入れるか、考えてみる。

たとえば、エンジニアリング業界で資機材を調達する場合、ベンダーに発注書を出してから、納品まで腕組みをして待っているようなことは絶対にしない。資機材のほとんどが個別受注生産品であるため、発注の後にも、
 (1)キックオフ・ミーティング
 (2)設計図面の提出と承認
 (3)主材料の購買手配
 (4)工場での製造開始
 (5)工場立合い検査
 (6)工場出荷
 (7)納入先到着
といったマイルストーンを定めて、それぞれの予定期日をたずねる。このように分解すると、従来経験した類似のケースから見て、相手の見積の妥当性を部分的には検証できるようになる。

無論、こうした方法をとっても、相手の納期回答を完全に信頼して良いものか、確証はできない。そこで、初顔合わせの相手を選ぶときは、納期だけでなく、相手のスケジュール管理能力自体を評価する必要が出てくるのである。

たとえば、「チーム員は毎日、工数実績と進捗を記録していますか」という質問をしてみる。日報や週報を、勤怠管理の一環として、記録させている会社は多い。しかし、たいてい実態は、週1回まとめて書き込むだけだ。実績工数の集計結果が出るのは月1回だったりする。しかも進捗状況までは記録していないケースが多い。理由は、進捗の測り方(業務プロセスやWBS)が標準化されていないからだ。

これでは、プロジェクトが今どこまで進んでいるのか、あとどれだけ工数(費用)が必要なのか、リアルタイムに把握できない。たとえて言えば、たまにメーターを見るだけのタクシーの客と同じで、なりゆきまかせだ。これで予定通りプロジェクトが完了したらおなぐさみである。

ところで、最近はGPSとカーナビを積んだタクシーも増えてきた。自分の位置がリアルタイムに把握でき、到着時刻も見積もりやすい。ならば、現代のホワイトカラーが集まって進めるプロジェクトだって、GPS的な仕組み=進捗マネジメント・ソフトウェアが必要だと、そろそろ気づくべきだろう。

ただし、いかに精密なGPSを積んでいても、偶発的な渋滞が起こるのを防ぐことはできない。プロジェクトでは必ず、計画外のリスク事象が起こる。プロマネはそれを事前に察知して、『渋滞』を避けるよう進路を変える能力を持たなければならない。

そこで、私は、初顔合わせの相手から見積をもらったときに、上記とは別に、相手のプロマネに対して、必ずこう質問することにしている:

 「あなたのスケジュールのクリティカル・パスは何ですか。そして、スケジュールのリスク要因は何と何ですか?」

これに満足に答えられない相手とは、原則として仕事をするべきではない。たとえ仕事をするとしても、こちら側がスケジュール・コントロールにかなり工数を割かなければならないだろうと、覚悟して実行予算を決める。

理由は明らかだろう。クリティカル・パスとリスクを読むこと--これがスケジュール管理能力の最大のポイントだからである。
by Tomoichi_Sato | 2007-09-23 23:42 | 時間管理術 | Comments(0)

心理的バリアーをのりこえる

自分のやるべき仕事を、To Doリストやタスク・リストなどの形に書いておくのは、良い習慣だ--近著『時間管理術』の最初の方でこう書いたら、「近頃の若いビジネスマンはそんな当たり前のことまで、本で勉強しないと分からないのか」とベテランのプロジェクト・マネージャーに、あきれられてしまった。昔はそんなことは自分で編み出すか、先輩から盗んで覚えるのが当たり前だった、ということらしい。

しかし、大学出がまだエリート候補だった高度成長期ならともかく、今やホワイトカラーなど、誰もがありつける、ありきたりの職業となった。徒弟制度的な技術継承もくずれつつある。だから今日では、時間管理術はキャリアアップに必須の、学ぶべき技法だと思う。

自分がいつまでに何をやらなければならないのか、それがどれほどの負荷量の仕事なのか、ホワイトカラー業務の場合はなかなか見えにくい。生産現場だと、製造オーダーや出荷指示といった紙の差立てがきちんとしているし、それが現物と(まともな工場では)対応しているはずだから、仕事量は明確だ。仕事量が可視化できれば、おのずから進捗も計りやすいし、コントロールも可能になる。見えない仕事はいつまでたっても、制御不能のままなのである。

かくいう私も、To Doリストはずいぶん以前からずっとつけている。ところで、こうしてリストをつけて、毎朝・毎夕に更新していくと、ときどき気になることが出てくる。それは、いつまでたってもリストから消えずに居座り続けるタスクの存在である。

タスクは内容の他に、かならず期日(due date)を書くのが原則だ。しかし期日が厳密に決まっていない仕事、「近いうちにやらなきゃならない事」というのも現実には存在する。そうしたタスクは期日をブランクにしたり、あるいは1週間後などの適当な目安を設定することが多い。期日が来たら、私が使っているツールでは自動的に翌日に持ち越しになる(持ち越し不可の設定も可能だが)。こうして、いつまでもTo Doリストに残って消えないタスクがときどき生じる。正直に告白すると、最長で半年以上も生き残っていたタスクがあったと思う。毎日それを見ていると、しだいにTo Doリスト自体をメンテするのがいやになる。

それくらいだったら、さっさとそのタスクを完遂すればいいじゃないか、と思われるだろう。そう。それが正論である。しかし、私自身の中には正論にしたがえぬ部分が若干、あるのかもしれぬ。そして、類似の体験をじつは皆もっているようだ。では、どんな種類のタスクがTo Doリスト残りやすいのだろうか。工数のかかる仕事か、あるいは難易度の高い仕事か。それとも専門領域外の仕事か?

そうではない。私が手をつけずにずるずると先延ばしにする仕事、それは心理的に「面倒くさい」タスクなのだ。工数にも難易度にも専門性の有無にも、直接は関係がない。工数がかかって難しい、しかも経験の少ない分野でも、よろこんで取りかかれる仕事はいくらでもある。困るのは、心理的な負荷の高い仕事の方だ。

経営学は労働を、肉体労働と知的労働に分類している。それはさらに、習熟の要否によって単純労働と熟練労働に分かれる。高度な指先の研磨加工もあるし、単純な伝票処理もあろう。そうしたタスクの工数(負荷)は、肉体か頭脳のどちらかの使用時間で計られるのが決まりだ。ところが、仕事の中には、さほど時間がかかるわけではないが、心理的な負荷の大きなものがあるのだ。

友人の社会学者・石川准氏の本の中で、私は「感情労働」という概念を知った。感情労働とは肉体労働でも知的労働でもなく、感情の消費を要求される仕事をさす。その代表例として、ナースによる看護があげられていた。看護には知的な面も肉体労働的な面もある。しかし、その負荷の大きな部分は、患者に対する感情のプロセスによって生じるという。

同じ事が、どうやらビジネスの世界にもときどき生じるらしい。難しくはないけれど面倒くさい仕事。たとえば顧客への追加交渉だとか、人事考課だとか、あるいは些末な規則のために、細心の注意を払わないと官庁や管理部門からこっぴどく怒られる仕事だとか。こうしたものは心理的なブロックとなって、着手をしにくくするのだ。

それでは、どうすべきか。自分の心理的傾向、すなわち性格をかえるのが一番だが、これはお手軽にはできそうもない。そこで別の方法を考えよう。まず、心理的なブロックの存在に気づくことが第一だ。問題の存在を認識すれば、もう3割は解決に近づいたも同然だろう。

そのために、まずTo Doリストでの繰り越し回数をチェックするといい。もし同一のタスクを、未着手のまま5回以上くりこしていたら(つまりカレンダー日でいえば1週間たっていたら)、それは「心理的バリヤーつきタスク」だと認識する。

つぎに、心理的な障害のあるタスクは、それを小さなサブ・タスクに分解してみる。「顧客に値上げ交渉をする」という仕事が、気が重くて延ばしのばしになっている場合、「交渉材料のネタを準備する」「競合製品の価格リストを作る」「顧客に面談のアポを入れる」などにブレークして、着手してしまうのだ。本にも書いたとおり、少しでも自分自身の背中を押してやるような形にするのがコツだ。

同時に、自分自身で簡単なモットーをかかげるのもおすすめだ。たとえば私は、「迷ったときは積極的な方を選ぶ」というモットーを、先輩から教わった。これは自分自身の背中をちょっと押すのに効果がある。「迷ったときには、念を押せ」というのもある。これは優秀なプロマネからきいたことばだ。コミュニケーションには念を入れろ、との教訓がこもっている。

こうした面倒くさいタスクは、かなりの場合、上司からふってくる。以前、『To Doリストなんか書いている時間がない』(「コンサルタントの日誌から」2007/03/11)にも書いたように、本当はTo Doリストは、作業を指示した人が書き込むべきものである。だがそれは、現実にはなかなか、かなわない。タスクは自分で管理せざるを得ないのだ。それでも、自分の背中を少しずつ押す術を身につければ、少しずつは前に進むことが出来るのである。
by Tomoichi_Sato | 2007-06-05 23:23 | 時間管理術 | Comments(0)

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

スケジュールという英単語は、もともと『一覧表』とか『箇条』という意味に近い。箇条書き、の箇条である。そこから転じて、主に米国で時間割や予定表の意味に使われるようになったときく。これを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)