全てをスケジューリングする必要はない | タイム・コンサルタントの日誌から
前回の記事で、日本企業はしばしば、過剰に計画したがる傾向がある、と書いた。その主な理由は、先にお金の出入り（予算）を押さえておきたいためと、リスクに対する不安があるためだ。研究開発や業務改革などは、スコープ自体が柔らかくて、行うべきアクションの内容や仕事量が精度よく見積もれないのに、過剰な細部まで先に決めたがるのである。 似たような事情は、プロジェクト・スケジュールや、生産スケジュールにおいても起こり得る。そもそもスケジューリングとは計画作業の一部だから、まぁ当然と言えば当然である。 この傾向は、日本よりも計画重視の傾向が強い米国発で、日本に持ち込まれたのかもしれない。もともとPERT/CPMなどのプロジェクト・スケジューリングの手法は、1950年代に、アメリカで開発されたものだ。 実は同じ頃、生産スケジューリングの理論においても、アメリカで重要な発見がなされた。それは、ジョンソン法と、ジ
成功するプロジェクト計画はこうして立てる | タイム・コンサルタントの日誌から
－－これはプロジェクト・マネジメントを人に教えるとき、わたしが必ず出すクイズの一つだ。実はその答えについて、以前このサイトで書いたことがあるのだが、もう9年も前の記事（笑）なので、覚えておられる読者も少ないだろう。そこで、あらためて考えてみていいただきたい。最初にすべきことは何か？ 相手が学生の場合、「日程を決める」「店を探す」「参加者のリストを決める」等々、いろいろな答えが思いつく限り出てくる。もちろん、どれもそれなりに正しいように見える。でも、求めている答えはそれじゃないです、どんな種類のパーティやイベントの場合にもあてはまる、唯一の普遍的な正解があるのです、とわたしは続けて説明する。しかし、その『正解』が出てくることは、まずない。 一方、相手が企業人の場合は、ほしい答えを言い当ててくれる人が、ときどき、いる。わたしの求める答えとは、『計画を立てる』である。同期3人の飲み会なら、その場
プロジェクトを計画しすぎてダメにする方法 | タイム・コンサルタントの日誌から
「日本企業は、計画しすぎなんです。」——最近、ある外資系戦略コンサルタントから、こんなセリフを聞いた。いわゆるDXに関する話題の時だ。「計画して、それも細かく緻密な計画を立てて、石橋をたたくようにリスクを全て洗い出してから、はじめようとします。そして動き出したら、すぐ進捗率を問題にする。でも、そんなやり方では、イノベーションは動きません。」 たしかにまあ、日本企業、とくに製造業は、まず計画ありきで動いていると言ってもいい。年度計画（いわゆる「予算」）、月度計画、小日程計画・・。建設業も、似たところがある。全体工程表、月間工程表、週間工程表、等々。現場に行くと、計画表は、必ず目立つ位置にはり出してある。 だが、新しいビジネスモデルを創出するような、イノベーティブな試みは、目指すべき目的地が最初から決まっている訳ではない。登るべき山の頂が明確なら、アプローチの経路を地図の上に引き、どこまで登っ
管理とは何か、を明らかにする12の質問 | タイム・コンサルタントの日誌から
何度か書いたことだが、わたしはこのサイトでは原則、「管理」という言葉を使わないことにしている。「管理」という日本語は多義的で、人により文脈により、何を指すのかブレが大きすぎるからだ。「ちゃんと管理しておけよ！」——そんな風に、部下が上司に叱られたとき、上司が求めていたことは何だったのか。部品材料の保管のことなのか、取引の追跡把握（トラッキング）のことなのか、人への作業指示のことなのか。あなたは間違いなく言い当てられるだろうか？ じつはこの稿、最初は製番管理について書こうと思って、内容を考えはじめたのだ。きっかけは、ある知人からの質問であった。『製番管理』とは、数ある生産管理方式の一つである。日本ではかなり広く用いられている方式だ。だが、これを理解しようとすると、どうしても生産形態と生産方式の区分、そしてそれらと生産管理方式との関係への目配りが必要になる。 ところで、生産方式と生産管理方式、
なぜなぜ分析は、危険だ | タイム・コンサルタントの日誌から
「なぜなぜ分析」は、品質管理や労働安全管理などの分野で、よく用いられる手法だ。発生した問題事象の根本原因を探るために、「なぜ？」「なぜ？」とくりかえして掘り下げていく。この問いかけを“5回はくりかえせ”と、よく指導しているため、別名「なぜなぜ5回」とも呼ばれる。元々、トヨタが発祥の地であり、トヨタ生産方式の普及とともに、他の業界や分野でも使われるようになった。 図は、トヨタ生産方式の生みの親である大野耐一氏の著書から一例をとって、図示したものだ。工場内のある生産機械が故障してとまったとき、「なぜ機械は止まったか？」の問いに、「オーバーロードがかかって、ヒューズが切れたからだ」と答えただけでは、じゃあヒューズを交換して再起動すればいい、という答えしか出てこない。 しかし、なぜオーバーロードがかかったのか？→ (2)軸受部の潤滑が十分でないからだ、とほりさげ、 さらに (3)潤滑ポンプが十分組
危機なんて、ほんとに管理できるのか？ーー現場感覚という事 | タイム・コンサルタントの日誌から
わたしのこのサイトでは、管理という言葉を極力使わないようにしている。このことはすでに何回か書いたので、あまり詳しくは繰り返さないが、日本語の管理に対応する英語は、Management, Control, Administrationの3つのレベルがあって、海の向こうでは使い分けされている。これに比べ、日本語の『管理』は語義が広すぎて、何のことを指しているのか誤解しやすい。 それでも、管理が何を指すかは、「管理できていない状態」と比べると、少しは明確になるかもしれない。管理できていない状態というのは、どんなイメージか。 70年代、ようやく少しずつ開放の始まった中国を、私の父が訪れた。父は機械エンジニア出身で、機械メーカーの役員だった。中国でいくつかの大規模な工場を訪れ、当時普及し始めたNC（数値制御）工作機械の、研究と導入について相談を受けたという。 しかしそこの工場たるや、加工品を床の上に
スコープ・組織・スケジュール・コストの間の依存関係 〜プロジェクト・インテグレーション・マネジメントのもう一つの顔 | タイム・コンサルタントの日誌から
うーむ、長いタイトルだな（笑）。そもそも、「プロジェクト・インテグレーション・マネジメント」という用語自体が長い。カタカナで23文字もある。PMBOK Guideの邦訳版のように「プロジェクト統合マネジメント」としても、14文字だ。しかしこれ、”PIM"とかって3文字略語にしても通じないだろうし、致し方ないだろうな。 前回の記事にも書いたが（「プロジェクト・インテグレーション・マネジメントと『鉄の三角形』」https://brevis.exblog.jp/27102305/）、現在のPMBOK Guideには、PMに必要な10のマネジメント知識エリアが列挙されている（初期の頃は9個だった）。そしてその中核となるのが、「プロジェクト・インテグレーション・マネジメント」（ああ長い^^;）である。それは、他の9個の領域のマネジメントを統合する。そして、他の9個の領域には、とくに順序はなく、対等だ
プロジェクト・インテグレーション・マネジメントと「鉄の三角形」 | タイム・コンサルタントの日誌から
各知識エリアは、それぞれが”xx Management"と題されている。つまりQuality ManagementとかCost Managementといったたぐいだ。もっとも上記10個には多少の変遷があり、最初は9個だった。途中からステークホルダー・マネジメントが追加され、さらに最新版ではステークホルダー・エンゲージメント・マネジメントにかわった（ステークホルダーは外部の利害関係者なので、プロマネが直接はマネージできないためだろう）。またスケジュール・マネジメントの用語も、第5版まではタイム・マネジメントだった。 PMBOK Guideには、PMをプロフェッショナルな職域として確立しようとした、先達の叡智がつまっている。中でも一番偉かったのは、最初に「プロジェクト・インテグレーション・マネジメント」なる領域をおいたことだと思う（日本語版では「プロジェクト統合マネジメント」と訳されている）。
わたしはなぜ、「プロジェクト管理」という言葉を使わないのか | タイム・コンサルタントの日誌から
旅先ではいつも、その土地のものを食べるのが習慣だ。だが、ときおり、外国で日本料理屋に入ることもある。そして、たまに面食らうような体験もする。いつだったか、アメリカの日本料理屋で食事を頼んだら、まっさきに味噌汁だけが出てきた。ふつうの街にある店で、来客はアメリカ人が多い。どうやら彼らの概念では、味噌汁はスープだから（Miso soupとよばれる）、真っ先に出すのが当然だということらしい。味噌汁を飲み終えたら、メインのおかずとご飯が出てきて、妙な気分だった。 汁物をsoupと訳するのは、もちろん正しい訳だ。だが日本語で言う汁物と、英語のスープは微妙に違う。たとえば英語では、スープは食べる（eat）という。日本人で、「味噌汁を食べる」という人は滅多にいるまい。ふつうは飲む、を使う。そして、当たり前だが、ご飯と一緒にいただくものだ。
システムズ・エンジニアリングとは何か | タイム・コンサルタントの日誌から
日本にはあまり知られていないが、欧米では確立され重視されている技術の分野がある。それは「システムズ・エンジニアリング」＝システム工学である。 ・・と書けば、“何を馬鹿な”と思われる方が大半であろう。日本にはシステム・エンジニア（SE）と呼ばれる職種の技術者が、少なく見積もっても十万人単位で存在する。それに、大学でもそれなりに教えているではないか。「システム工学」と名のつく学科だって、数十は存在する。それなのに、「あまり知られていない」などとは何ごとか！ そう憤慨される読者諸賢に、それでは、一つご質問したい。貴方が学校で学ばれた「システム工学」の、代表的な教科書をあげていただきたい。これ一つ読めば、システム工学の基礎が大体分かる、読んでいない奴はモグリだ、というような定番の教科書である。システムとは何を指すのか、システムはどのように設計すべきか、設計手法は何があるのか、システムの分析や評価は
「理屈を言うな」という理屈 | タイム・コンサルタントの日誌から
15歳の時の4月。高校の入学式を終えたわたし達・新入生は、各クラスでの挨拶と簡単な自己紹介のあと、体育館に集められた。「オリエンテーション」という行事があると言うことだった。どういう行事かの説明はなかった。 新入生ばかり400人あまりが集められた後、体育館の扉が閉められたが、中には先生達の姿はなかった。壇上には学ランを着た屈強な上級生達が十何人か立って、両手を後ろに組み、胸を反らして立って、わたし達新入生をにらみつけた。どうやら『応援団』という存在らしかった。その中の団長格とおぼしき人が壇上の中央に立って、上半身を腰から前にかがめ、わたし達に向かって、かすれた声で という声を発した。いや、正確には文字化が難しいのだが、とにかく強引に文字にすると、そういう音声だ。何事か、と驚いてきょとんとしているわたし達に向かって、壇上の、そして左右通路の応援団員達が、わたし達に口々に「返事はどうした！」「
パフォーマンス問題へのシステムズ・アプローチ | タイム・コンサルタントの日誌から
なんだかこのところ、納期遅れのクレームが増えている。営業部門から問題提起があったので、工場で原因を調べることになった。製造部や品質管理部、資材購買、生産技術など各部門からキーパーソンを集めて、対策チームを作り、まずは現状分析をはじめた。グラフを作って調べてみると、納期遵守率が落ちてきていることが数字の上でも明白だ。たしかにこれは、何らかの対策を打たねば、客先からの信頼度、ひいては受注競争力の低下につながりかねない。 そこで、最近の納期遅延事例を、それなりの件数とりあげて、原因分析をしてみた。また、メンバーも自分の気づいた経験を共有してみる。その結果、20以上の原因があがってきた。いわく、長納期部品の仕入れが遅れた、出荷前検査で不良が見つかり加工段階から削り直しになった、鋳物材料に欠陥が見つかった、設計の不具合が顧客の承認図レビューで分かった、ツールの不具合で余計に製造時間がかかった、云々・
アカウンタビリティとは「命令責任」である | タイム・コンサルタントの日誌から
「RACIチャート」というものをはじめて知ったのは、90年代半ばのことだ。当時使っていたアメリカのERPコンサルタント会社が、要件定義段階での役割分担をRACIチャートの形にまとめてきて、なるほど、こういう整理の仕方があるのかと知った次第だ。ついでにいうと、「サプライチェーン」という言葉も、同じ時にはじめてきいたのだった。まだ日本ではほとんど知る人のいない概念だった。 RACIチャートとは、業務の上での役割分担と責任範囲（Role and Responsibility）を、分かりやすく整理するための表である。ふつう横軸の欄には、関係者や部門の名前が並び、縦の行には業務を構成するアクティビティが続く。そして、どのアクティビティは誰がどのような役割で関わり、責任はどこが持つかを書く。このとき、
B2B企業にイノベーティブなITは可能か | タイム・コンサルタントの日誌から
あなたは、ある中堅SIerの開発部長だ。会社は受託システム開発をなりわいとしており、有名ではないが堅実な経営を続けている。そんなあなたはある時、突然社長に呼ばれて、こう言い渡される。 「君には明日から、わが社のCIOになってもらいたい。これまで外の顧客の仕事をずっとしてもらってきたが、明日からは経営者の一員として、わが社の情報システムを見てもらうつもりだ。紺屋の白袴じゃないが、我々の社内IT利用は、十分とは言えない。君には是非とも、これまでの外販の経験を活かして、イノベーティブなITの仕組みを作ってもらいたい。単なる業務の効率化だけではなく、新しいビジネスを生み出せるようなITの仕組みを、だ。」 経営者の一員、すなわち役員に抜擢された訳だ。とても誇らしい気持ちになる。しかし社長室を出て自分の席に戻ると、あなたはだんだんと大変な役回りを引き受けたらしいことに、気づき始める。わが社にとってイノ
ハイボールと、本質的安全設計の教え | タイム・コンサルタントの日誌から
『本質的安全設計』という言葉を聞いたことがあるだろうか。世間ではよく安全とか安心とかいったことを話題にするが、安全の意味をつきつめて考えている人は、必ずしも多くない。本質的な安全設計とは、われわれがモノや仕組み（システム）を作る上で、欠くことのできない概念である。今日はこれについて少し述べてみたい。 機械の安全設計については、そのものずばり「機械類の安全性―基本概念，設計のための一般原則」という名前の国際規格 ISO12100 が存在する。このISO規格によれば、機械類の安全は、『設計者対応』と『操作者対応』に分けられる。つまり、作る側による配慮と、使う側（消費者・操作者）による注意の、両方がいるというわけだ。ここまではいいだろう。 では、肝心の作る側（設計者）の対応は、どのように行うべきか。ISO12100は、 （１）本質的安全設計によるリスクの低減 （２）安全防護によるリスクの低減 （
英国史上、最も偉大な技術リーダーに学ぶべきこと | タイム・コンサルタントの日誌から
イザムバード・ブルーネルIsambard Brunel（1806-1859）の名前をご存じだろうか？ 19世紀前半の英国を生きたエンジニアだ。生まれは今から210年前。その時代、英国は産業革命の成功を背景に、猛烈な勢いで勢力を伸ばし、北西ヨーロッパの島国から、世界最大の強国に成長しつつある時代だった。 BBC放送は2002年、「歴史上最も偉大な英国人」100人を選出した。1位はウィンストン・チャーチル。そして第2位がイザムバード・キングダム・ブルーネルだった（日本では「ブルネル」と表記されることも多い）。ちなみに、3位はダイアナ妃、4位がチャールズ・ダーウィン、5位シェークスピア、6位アイザック・ニュートン、7位エリザベス一世・・という具合だ。偉大な科学者や文芸家たちをおさえて、第2位の地位を占めた技術者ブルーネルとは、どんな人物だったのか？ 1835年、首都ロンドンと、大西洋に面する英国
見えない壁に突きあたった中堅エンジニアが学ぶべき、三つのこと | タイム・コンサルタントの日誌から
先週の4月2日(土)に浜松市で、合同シンポジウム「サプライチェーン戦略とプロジェクト・マネジメント」を開催した。主催はOR学会・日本経営工学会・スケジューリング学会で、その配下にある「サプライチェーン戦略研究部会」（主査・日本IBM 米澤隆氏）と、わたしが主査を務める「プロジェクト＆プログラム・アナリシス研究部会」が実行主体だ。 講演者には、倉庫管理システムiWMSの開発元として有名な(株)フレームワークスの渡辺重光会長と、ヤマハの曽根卓朗主席技師のお二人をお招きした。お二人の話はどちらも非常に興味深いもので、渡辺氏はロジスティクスとIoTの広範な展望を話され、曽根氏は通信カラオケの製品開発を題材に、生々しい体験をお話しいただいた。最後にパネル・ディスカッションを行い、わたしもパネラーとして参加した次第だ。 幸い大勢の方に来ていただき、立ち見が出そうになったので椅子を補充したほどだった。製
プロジェクト・マネジメントの目的とは何か | タイム・コンサルタントの日誌から
中堅エンジニアが壁を破って成長するには、何を学ぶべきか。そういう問いに関連して、ここ何回か書いている。初級の仕事を一通りおえて、とりあえず一人前のことはできるようになっても、その先にしばしば壁がある。そこを乗りこえて面白い仕事をしていくためには、もう少しマクロにものを見て、人を動かせるようになっていく必要がある。 今年の1月に、静岡大学と浜松ソフト産業協会の共催によるプロジェクト・マネジメント講座に呼ばれて、初日の講師を務めさせていただいたときも、その話から始めた。集まった方はほぼ全員がIT技術者だった。IT分野は勉強会も盛んで、知識欲に燃えた熱心なエンジニアも少なくない。わたしはたずねた。 「この中で、現在プロマネの仕事をされている方はいらっしゃいますか？」 手を上げた方は全体の1/3もいなかった。ある意味、予想通りではある。プロマネの仕事をばりばりこなしている人は、こうした講座を聴きに
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
プロジェクト計画のロジックとは何か 〜 やはりExcelで工程表を書いてはいけない (2) | タイム・コンサルタントの日誌から
設計の「なぜ」を考える | タイム・コンサルタントの日誌から