IT、OT、ET、そしてマネジメント・テクノロジー | タイム・コンサルタントの日誌から
前々回、そして前回と続けて、本サイトのテーマである『マネジメント・テクノロジー』の領域について、あらためて考えてきた。 マネジメント・テクノロジーは、目に見えにくい領域における技術である。わたし達の文化は、目に見えるもの（五感で感じられるもの）に対しては細部にまで徹底してこだわるが、見えない物事や抽象的概念には、いたって無頓着、という傾向が強い。 たとえばカレー屋さんの場合、料理の味と、その材料やレシピには研究を怠らない。しかし客の注文をどうとってどういう順序でデリバリーするか、何をストックし作る量をどう予測するか、といった店を運営する過程や仕組みには、なりゆきで応対する。これが多くの店のあり方だろう。 カレーの料理法は「固有技術」で，店の運営の仕組みは「管理技術」（マネジメント・テクノロジー）に属する。もちろん固有技術（味）は、いわばビジネスのベースで、これが不味ければ商売は成り立たない
自社の生産形態をデザインする | タイム・コンサルタントの日誌から
ときおり頼まれて、生産スケジューリングの話を人前でする。生産計画やスケジューリングについて困っている方が、製造業には多いのだろう。中堅中小の工場はいうに及ばず、結構な大企業の工場に行っても、Excelの生産日程表を現場に配って、現場のリーダーたちが個別に指示采配しているケースを、よく見かける。 Excelだから悪いと決めつけるのは早計かもしれないが、現場の状況に応じて臨機応変に修正するには、どうしたって時間がかかる。だから納期や機械稼働に変動の多い工場では、機動的に指示変更が出せない。出せないと、需給のタイミングがずれて、欠品や在庫が増えることになる。かくて納期遅れが多いのに、無駄な在庫も多い、という現場ができ上がる。 そこで、何か良い知恵はないかとお集まりの皆さんに、わたしが必ず最初にする話が、『生産形態』の種別の説明だ。なんだか肩透かしを食らったような気がすると思う。生産方式と生産形態
パン屋問題の解決、または中小製造業の生き残る道 | タイム・コンサルタントの日誌から
あなたは町のパン屋さんである。以前は都会でエンジニアとして働いていたのだが、やむを得ぬ事情で郷里のパン屋を継ぐことになった。店は昔ながらの商店街にあり、店の奥では職人が小さな工場（こうば）でパンを焼いている。ところで、地域のチェーンストアからサンドイッチ製造の仕事を依頼されたのだが、受けてみたら大変な仕事だった・・という事情までは、前々回の記事「下請け型受注生産という日本的形態を考える」https://brevis.exblog.jp/28051644/ に書いた通りだ。 何が大変かって？ チェーンストアは、コンビニの向こうを張って、いわゆる「JIT納品」（ジャスト・イン・タイム納品）を要求してくる。1日4回、FAXで注文が来て、2時間以内に納品しなければいけない。おまけに製造後6時間以内の品であること、という鮮度指定もついている。ところが注文を受けてからカツを揚げてサンドイッチを作ってい
エンジニアリングと技術とインテグレーションと | タイム・コンサルタントの日誌から
以前、「英国史上、最も偉大な技術リーダーに学ぶべきこと」https://brevis.exblog.jp/24622591/（2016-08-28）と題する記事で、イザムバード・ブルーネルのこと書いた。19世紀前半のイギリスで活躍した、傑出した技術者だ。たまたまロンドンに来る用事があったので、ブルーネルが作ったパディントン駅を見た。とても美しく、かつ機能的な、優れた建物である。改良の手は入れているだろうが、建築物としての骨格は、おそらく最初のままだと思われる。実物を見て、あらためてブルーネルという人の天才的なセンスを感じた。 そのパディントン駅から多少歩いた公園・ハイドパークの南側に、「アルバート記念碑」が立っている。大英帝国の最盛期を作ったビクトリア女王が、亡き夫君のアルバート公を記念して建造を命じた、巨大なモニュメントだ。こちらはネオ・バロック様式で、すごく美的だと思うかどうかは、見る
わたしはなぜ、「プロジェクト管理」という言葉を使わないのか | タイム・コンサルタントの日誌から
旅先ではいつも、その土地のものを食べるのが習慣だ。だが、ときおり、外国で日本料理屋に入ることもある。そして、たまに面食らうような体験もする。いつだったか、アメリカの日本料理屋で食事を頼んだら、まっさきに味噌汁だけが出てきた。ふつうの街にある店で、来客はアメリカ人が多い。どうやら彼らの概念では、味噌汁はスープだから（Miso soupとよばれる）、真っ先に出すのが当然だということらしい。味噌汁を飲み終えたら、メインのおかずとご飯が出てきて、妙な気分だった。 汁物をsoupと訳するのは、もちろん正しい訳だ。だが日本語で言う汁物と、英語のスープは微妙に違う。たとえば英語では、スープは食べる（eat）という。日本人で、「味噌汁を食べる」という人は滅多にいるまい。ふつうは飲む、を使う。そして、当たり前だが、ご飯と一緒にいただくものだ。
人材配置・昇進のレベル０からレベル2まで | タイム・コンサルタントの日誌から
わたしが主宰する『プロジェクト＆プログラム・アナリシス研究部会』では先日、「プロジェクト・マネジメントの1日研修トライアル」という催しを開いた。これは、わたし達の研究部会の中にある「PM教育分科会」というグループが、オリジナルに開発中の研修プログラムについて、希望者を募って“βテスト”を実施したものである。参加者がいるか心配だったが、幸いにも10数名の方が申し込まれ、休日を丸一日つかってわたし達の研修プログラムを体験し、有用性を検証していただいた。 その内容はまだ開発中のため、ここで詳しくは述べないが、社会人向けの、初中級者レベルのコースとして設計したものだ。もちろん世の中には、すでに多数のPM研修がある。だが、その多くはPMBOK Guideなどの知識を座学で学ぶ、資格試験対策である。あるいは逆に、ケーススタディの討議中心で、しばしばプロジェクトの火消しなどの題材を扱っている。だが、そも
設計思想（Design Philosophy）とは何か | タイム・コンサルタントの日誌から
Kさん、久しぶりにメールありがとうございました。お元気とのこと、何よりです。ご活躍中の様子が、行間からあふれていました。生産管理の現業をかかえた上に、新規システム導入プロジェクトのメンバーの一員としてアサインされたとは、たしかに大変だろうとお察ししますが、それだけKさんが周囲から期待され一目置かれていることの証左だと思います。 ところで、Kさんからメールをいただくたびに、難しい宿題を投げられたように感じるのですが、今回は格別です。『設計思想に関して』のご質問とは！ なるほど、たしかに新しい基幹業務システムを考える出発点として、“その設計思想はどうあるべきか”を問うのは、とてもオーソドックスかつ当然の発想と思います。自分達が製品を設計開発するときも、成功した製品には明確な設計思想があった。だから、プロジェクトを成功させたければ、当然システムにも設計思想がなくてはならないはずではないか。－－設
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
