人気ブログランキング |

<   2019年 10月 ( 4 )   > この月の画像一覧

お知らせ:BOM/部品表に関する2件のセミナー講演を行います(11月28日・名古屋、12月17日・東京)

11月と12月に、BOM/部品表に関連して、2件のセミナー講演を行います。前者はエンジニアリング・チェーンとPLMに関する話題(無料)で、後者は6月に行ったセミナーのアンコール講演(有償)です。

このところBOM関係の講演依頼が増えているのは、あらためて設計から製造への機能的な橋渡しについて、悩む企業が増えているためではないかと想像します。

製造業ではよく、「サプライチェーン」と「エンジニアリング・チェーン」が生産でクロスする、という説明がなされます。下図はわたしがときどき講演で使ってきたチャートで、横軸は左から右に向かって、物づくりの順番にサプライチェーンが描かれています。生産計画から始まって、調達→生産→出荷→販売→保守、といった流れです。これに対して縦軸は、上から下に向かって、マーケティングからはじまり、企画→製品開発→工程設計→試作→量産準備、という製品開発の流れを示します。これを「エンジニアリング・チェーン」と呼ぶわけですが、両者が交わるのが『生産』です。
e0058447_22231986.jpg
そしてPLM(Product Lifecycle Management)と呼ばれるソフトウェアは、「製品の企画・設計から保守・廃棄にいたるプロセス全般を管理する」仕組みの提供を目的としています。もっとも、PLMソフトは普通、エンジニアリング・チェーンの側をサポートし、生産計画や生産・物流などはSCMソフトウェアが面倒を見ます。両者の統合の要は、部品表/BOMデータベースで、その中にE-BOM→M-BOMが整合性をとって格納されるのが理想形です。

ところが現実には、2つのチェーンの流れは、この図のようなきれいな直交形に統合しにくいのです。それは、もともとこの図が、量産型の製造業を念頭に置いて作られたからです。一方、日本の多くの企業では、もはや受注生産、とくに個別性の強い受注設計生産の形態が主流になっています。したがって、BOMのあるべき姿について、現下の状況に応じて皆が考える必要が出てきている訳です。

2つのセミナーはテーマも内容も異なりますが、この主題をめぐって皆さんと一緒に議論できればと思っています。関心ある方のご来聴をお待ちしております。


<記>

(1) 「BOM/部品表とエンジニアリング・チェーンのマネジメント

日時: 2019年11月28日(木) 13:30~14:35
テーマ: 「BOMで改善! 中小企業の設計効率を上げる業務改革」
主催: エスツーアイ(株)+ダッソーシステムズ(株)
会場: 〒450-0002 名古屋市中村区名駅4-7-1
     ミッドランドスクエア 5F ミッドランドホール会議室A

セミナー詳細: 下記をご参照ください(無料、定員30名)


(2) 「BOM/部品表の基礎と効果的な活用ノウハウ ~演習付~

日時: 2019年12月17日(火) 10:30~17:30
主催: 日本テクノセンター
会場: 〒163-0722 東京都新宿区西新宿二丁目7番1号
     小田急第一生命ビル22F

セミナー詳細: 下記をご参照ください(有償です)



以上、よろしくお願いします。
               (佐藤知一)



by Tomoichi_Sato | 2019-10-28 22:36 | サプライチェーン | Comments(0)

IT、OT、ET、そしてマネジメント・テクノロジー

前々回、そして前回と続けて、本サイトのテーマである『マネジメント・テクノロジー』の領域について、あらためて考えてきた。

マネジメント・テクノロジーは、目に見えにくい領域における技術である。わたし達の文化は、目に見えるもの(五感で感じられるもの)に対しては細部にまで徹底してこだわるが、見えない物事や抽象的概念には、いたって無頓着、という傾向が強い。

たとえばカレー屋さんの場合、料理の味と、その材料やレシピには研究を怠らない。しかし客の注文をどうとってどういう順序でデリバリーするか、何をストックし作る量をどう予測するか、といった店を運営する過程や仕組みには、なりゆきで応対する。これが多くの店のあり方だろう。

カレーの料理法は「固有技術」で,店の運営の仕組みは「管理技術」(マネジメント・テクノロジー)に属する。もちろん固有技術(味)は、いわばビジネスのベースで、これが不味ければ商売は成り立たない。しかし管理技術(運営の仕組み)ができていないと、商機に乗って展開することも、急な環境変動にうまく応対することもできず、気づかぬうちに非効率と機会損失を出してしまう。ここが弱いと、皆が必死に働いているのに、なぜか儲からなくなるのだ。

わたし達の社会は、このマネジメント・テクノロジーの存在と、その重要性を見過ごしてきたことで、長い不況を抜け出せずに来たのではないか。それが本サイトの問題意識だ。

そして、マネジメント・テクノロジーは、隣接する3つの固有技術領域、すなわちIT(Information Technology)、OT(Operational Technology)、ET(Engineering Technology)と少しずつ重なり合いながら、その方向性を広げてきた。では、このIT、OT、ETとは、それぞれどのような技術なのか。
e0058447_15133814.jpg
マネジメント・テクノロジーの領域図(再掲)


ITについては、すでにネットの内外に、数多くの情報があるため、いまさらここでは解説不要だろうと思う。コンピュータのハードウェア設計から始まり、OS、通信ネットワーク、ミドルウェア、データベース、そしてその上で活躍する応用ソフトウェア群(とくに業務系システム)の設計・実装・運用技術までが、ここに含まれる。

本サイトでも、随分前だが、『ITって、何?』という連載をのせた。長い記事になっているが、あそこで書いたコアのメセージは、
ITの本質は、データと情報のサイクルを回すこと
である。データとは定型化された符号の並びで、他方、情報とは人間に意味を与える(不定形な)ものだ。だから情報を機械に与えて蓄積・処理できるようにするには、定型化してデータにすることが必要だ。データは上手に組織化し提示しないと、人間に意味をもたらさない。この双方向をうまく回すのが、IT=情報技術である。

固有技術としてのITの基礎を支える科学は、コンピュータ・サイエンス(計算機科学)である。それは数学・論理学から電子工学さらには言語学まで、様々な科学領域にまたがって存在している。だから、大学のコンピュータ・サイエンス学科を卒業して、専門職としてのITエンジニアになる、というのが米国流の普通のキャリアパスである。日本があまりそうなっておらず、大学にも「計算機科学科」がめったに存在しないのはなぜか、わたしはよく分からないが。

さて、これに対して、OT(Operational Technology)とは何か?

OTについては最近、IoT技術に関連して注目されるようになり、世の中にもいろいろな解説が流布している。ネットでちょっと調べただけでも、以下のようなものが出てくる。

「交通手段やライフラインといった社会インフラにおいて、それに必要な製品や設備、システムを最適に動かすための「制御・運用技術」を意味します。」(キーエンス IoT用語辞典

「データを収集・分析し、経営に生かすテクノロジーがITであるのに対して、ハードウェアに働きかけ、制御・運用を行うためのテクノロジーを言います。(中略)OTの構成要素には、PLC、SCADA、DCS、CNCおよびcomputerized machine toolsといった制御装置と、制御装置と産業用ロボット・パワーサプライなどを結ぶフィールドネットワークがあります。」(Mono-watch IoT用語集

「ガートナーは、様々な装置のオペレーションを高度化する技術のことを、OT(オペレーショナルテクノロジー)と定義している。ファクトリーオートメーション(FA)などが、OTの代表例だ。」(日経コンピュータ World IT Watch 2011-09-01)

こう見ると、社会インフラ向けと言ったり産業機械向けと言ったり、定義には幅があっていろいろだ。最後の米国ガートナー社の定義は2011年のもので、中では一番古い。ちなみに現在はこうかいてある:

"Operational technology (OT) is hardware and software that detects or causes a change, through the direct monitoring and/or control of industrial equipment, assets, processes and events.” (Gartner Glossary)

この定義は英語版WikipediaのOperational Technologyの記事にも冒頭で引用されている(日本語版ウィキペディアの記事は、現時点ではその部分的抄訳でしかない)。

ただ、このガートナー社の定義は、わたしの目から見ると、少しだけ制御系や通信系の仕組みに偏りすぎているように感じられる(ガートナーはIT系コンサルティング会社だから、主な顧客はITエンジニアである)。

たとえば、NC(数値制御)のマシンを対象に入れるのだとしたら、その加工プログラムは、明らかにOTに入るはずであろう。そうなると、そのための切削条件決定や、加工ツール・バイト(刃先)の選定も、OTに含まれなければ、おかしい。搬送やチャッキングや検査の仕組みだって、そうだ。こうした機械工学系の加工技術は、現場の熟練者たちの手中にあって、ITコンサル会社には見えにくいのだろうが。

いいかえると、OTとは加工技術や機械制御といった、直接ものづくりに関わる固有技術だと、広く捉えるべきであろう。もちろんNC装置の加工プログラムや、SCADA, PLC、DCS、MES(とくにLower MES)など制御系も、この領域に入る。

日本のIT分野は世界の最先端に比べて遅れつつある、という認識が最近は広まっているが、それに比して、OTの分野に関しては、まだかなり世界的な強みを維持している。この点は強調しておいていいと思う。NC工作機械やマシジングセンタ、ロボット、物流搬送系設備、制御システムなど、世界トップレベルの企業がごろごろいるのが、この分野だ。

最後に、図の下の方に配置したET(Engineering Technology)に触れておこう。ETとは、製品設計や工程設計・レイアウト設計などに関わる固有技術領域である。ここには、機械・電気・制御・建築・空調・化学プロセスといった、いわゆる工学系技術が活躍する。そしてCAD/PLM/BIMなども、この分野のためのツールだ。

もっとも、IT・OTに比べて、ETという用語はあまり広く用いられていない。調べると、たとえば米ARC社は次のように使っているが、これが唯一の用法という訳でもない。

"ARC defines ET as those technologies that comprise digital models. … In the digital data environment of IIoT, engineering technology, those technologies that create virtual models must be included in the convergence conversation.” (ARC Insights, IT/OT/ET Convergence, May 25, 2017)

じつはETという用語が広まらないのには、別に特殊な理由がある。米国の大学教育コースの中に、”Engineering Technology”という学科が、”Engineering”とは別に設けられているところがあるのだ。たとえば英語版WikipediaでEngineering Technologyをひくと、Engineering Technologistという項目に自動転送されて、こういう説明が出てくる。

"Engineering technologists are more likely than engineers to focus on (post-development) implementation or operation of a technology but this is not a strict rule as they often do design original concepts.” (英語版Wikipedia: Engineering Technologist)

設計よりも実装に近い仕事を受け持つ技術職。日本の高等教育で言えば、高専のカリキュラムに近いのかもしれない。ET(Engineering Technology)というと、米国ではこちらのことを連想するらしいのだ。ともあれ、他に適切な言葉も見つからないため、上記の図ではETと表記しておいた。

そしてManagement Technologyは、OT+IT+ETの三本柱の上に乗っており、一部は重なっているのである。重なった部分は、それぞれ
OM(Operations Management)
EM(Engineering Management)
IM(Information Management)
と呼ぶべき領域である。

そして、これら3つのマネジメント・テクノロジーは、日本ではいずれもほとんど教えられておらず、知られてもいない。理工系はもちろんのこと、いわゆる文系の経営学でも、またビジネススクールでも、ほとんど等閑視されている。米国にはちゃんと、OMやEMを教えるコースを持つ大学・大学院があるのに。

なお、ITと重なる領域を、IM(Information Management)と表記したが、この言葉はプラント・エンジニアリング業界では、ある特殊な狭い領域の業務を指すことがある。本当はより一般的に、DM(Data management)とか、KM(Knowledge Management)などと併用すべき用語に思われる。

そして、図中には、他にもSCM(Supply Chain Management)PM(Project Management)MM(Material Managemen)といった、やはり物づくりに関連するマネジメント・テクノロジーの領域を入れておいた(ただし図中の位置は場所的に散らしているだけで、必ずしもPMがIMとEMの中間にあるという意味ではない)。

ちなみに、上の説明ではOTに属するPLC/DCS/SCADAや、ETに属するCAD/PLMなどを、ITとは別のものとした。だが、これらはみんなコンピュータのハードとソフトで実現するものだから、ITの一部ではないか、という議論もあるだろう。

しかし現実を見ると、業務系システムと、制御系・組込系システムと、科学計算系システムでは、作る人達も売る企業も、業界的に分かれている。技術の要素も相当に違っており、昨日まで製造原価報告書を設計していた人が、今日から偏微分方程式の収束計算を設計できるかというと、まあ無理であろう(逆も真なりだ)。繰り返すが、図中の「IT」は、主に業務システム系の領域を主に意識している。ITとOTの融合が語られはするし、そうした動きを否定するつもりはないが、それは、建築と機械の融合、くらい大変な話であることは理解しておいたほうがいい。

ともあれ、これがマネジメント・テクノロジーの領域の見取り図である。固有技術の領域では、日本の技術者たちはそれなりに優秀だ。みな真面目だし、ほぼ例外なくハード・ワーカーでもある。だが、縦割り組織と分業病におかされているため、固有技術を束ねて、全体をオーケストレーションする部分が弱い。オーケストレーションの技術、それがマネジメント・テクノロジーである。

もちろん、マネジメント・テクノロジーを学ぶとしても、この図の全部に通暁する必要はないし、そんなスーパーマンもいないと思う。ただ、わたし達は、自分が何を知っておらず、どこを探しに行けば先人の知恵を学べそうか、その方角を知るために、こうした地図を必要としているのである。


<関連エントリ>
 →「マネジメント・テクノロジーの領域を知ろう」(2019-10-05) https://brevis.exblog.jp/28610522/
 →「マネジメント・テクノロジーの技術地図を見渡す」(2019-10-13) https://brevis.exblog.jp/28623704/
 →『ITって、何?』https://brevis.exblog.jp/i12/


by Tomoichi_Sato | 2019-10-20 17:36 | ビジネス | Comments(1)

マネジメント・テクノロジーの技術地図を見渡す

前回の記事では、技術(Technology)とは2種類あり、固有技術と管理技術に分類できる、と書いた。わたし達が大学の工学部などで習う技術のほとんどは、固有技術である。これは対象分野に固有の科学法則に基づくテクノロジーだ。これに対し、管理技術(Management Technology)とは、仕事の仕組みそれ自体に関する技術で、たとえば、プロジェクト・マネジメントの分野では、CPM(Critical Path Method)やEVMS(Earned Value Management System)などがこれに相当する。

わたしは大学でプロジェクト・マネジメントを教える際に、いつも「この講義で教える内容は、ほぼすべて社会人になってから学んだことで、わたし自身は大学ではほとんど教わった記憶がありません。だけれど、それでは非効率なので、こうやって大学に来て皆さんに講義をしているのです」と説明している。

実際のところをいうと、大学の学部生レベルでは、プロジェクト・マネジメントの講義をしても、あまり響かない。人と一緒に仕事をして苦労した経験が乏しいからだ。これが大学院の修士課程くらいになると、一度は「卒論」というチャレンジを経験した後なので、少しは話を聞く態度に身が入る。そしてもちろん、一番皆がちゃんと学ぶ姿勢になるのは、社会人大学院生や、企業相手の講義のときだ。

まあ、だからといって大学での講義が全くムダだとは、思っていない。アーンド・バリューだのクリティカル・パスといった概念の意味は忘れても、いざ自分が卒業して、仕事で問題に直面したときに、「そういえば、昔なんだかこれに関連する話を聞いたよな」と思い出せれば、あとは自分で探して調べることができる。

自分が本当にニーズを感じているときほど、良い学びの機会はない。このとき、頭の中に、たとえぼんやりとでも「技術の地図」のイメージが残っていれば、(ああ、あっちの方に探しに行けばいいんだな)と、希望を持つことができる。技術者という人種は、「技術的に可能だ」という希望を持てることが、いちばん大切だからだ。そして優秀な人なら、自分で調べて勉強していく。

しかし、わたし達の社会では、管理技術をほとんど大学で教えないため、そうした技術の地図を知らないまま、世の中に出てしまう。つまり、そもそも「仕事の仕組み」には技術があること、人・モノ・情報などの配置と流し方に、ちゃんと先人たちの叡智と工夫があることを、知らないのだ。その結果、各人がゼロから車輪を再発明することになる。いや、それどころか、「リーダーシップ」「気合と根性」でなんとか乗り切れ、という話がまかり通る。

これに関して、わたしがよく使うたとえは、オーケストラの指揮者である。指揮者という仕事は、ちょっと見たところ、リズムに合わせて棒を振っているだけで、誰でも(楽譜さえ読めれば)できそうに思える。自分では笛を吹くわけでもなければ弦をこするわけでもなく、何の音も出さない。そもそも、管楽器や弦楽器の演奏技術も持っているまい。ただ、オケに指揮棒で指示を出すだけである。

では、指揮にはとくに技術はないのか。指揮者は、どのように育成するのか?

日本の組織では、幹部やリーダーの地位に登っていく人を、「ジェネラリスト」として育てるところが多い。その典型は官庁で、「キャリア職種」と呼ばれるエリート候補生たちは、2〜3年ごとに部署を変わっていく。しかも前職とろくに引き継ぎもしないことが多いので、役人と付き合う民間人たちは、相手が変わるたびに一から説明し直しになる、という。

技術者の場合、専門的な仕事を覚えて一人前のプロとして通用するには、ふつう10年くらいかかる。それがスペシャリストというものだし、医師や弁護士だってそうだ。それなのにキャリアと呼ばれる人たちは、わずか2〜3年の間で、その領域の仕事を概略理解し、何らかの成果を上げて次のポジションに進んでいく。だから、こうした制度は、彼らエリート層の優秀さの証左なのだ、という説明も聞いたことがある。優秀かどうかはともかく、スペシャリストを束ねて指揮するのは、ジェネラリストだ、という思想がそこにある。

こういう話を聞くたびに、じゃあ日本社会では、オーケストラの指揮者もジェネラリストとして育てることになりそうだな、と思う。指揮者のキャリアパスは、まずビオラで3年、次にフルートで2年、さらに打楽器とトランペットなどを経験し、最後に第一ヴァイオリンでコンサートマスターを5年ほど務めた後、めでたく指揮者の地位になる、と。

こんなバカなやり方で指揮者を育てる音楽界は、世界中どこにもない。指揮者は、専門家であり、指揮は専門技術だ。音大には指揮科があり、そこで指揮の理論や技術を学ぶ。それから指揮者の見習いとして、先輩について指揮法の実際的なスキルを学んでいく。たしかに、ときにはピアニスト出身の指揮者やヴァイオリニスト出身の指揮者もいる。だが、彼らだって、ちゃんと指揮法を学んで棒を振っているのだ。ただやみくもに棒を振ればついてくるほど、オーケストラという集団は甘くない。

人が集団で仕事をするとき、とくにその専門分野が多岐にわたり、規模が大きくなればなるほど、専門的なマネジメントの技術が必要になる。そして、そこには理論もあるし、学ぶことも、伝えることも可能だ。

では、そうしたマネジメント・テクノロジーを学ぶとしたら、それはどのような範囲をカバーすべきか。いいかえると、「技術の地図」は全体として、どのようになっているのか。

もちろん、それはかなり広い領域にまたがることになる。プロジェクト・マネジメント(PM)はその一部分にすぎないが、それだけでもPMBOK GuideやP2Mなど、分厚い教科書的な本がいくつも存在する。

そこで、ここでは一般的な製造業における物づくり分野について、その全貌を考えよう。また、マネジメント・テクノロジーを考える際には、隣接する固有技術との関係で理解したほうが分かりやすい。わたしの考える、物づくりに関わるマネジメント・テクノロジーの領域と、隣接する固有技術との関係マップを示しておく。

e0058447_15133814.jpg
隣接する3つの固有技術とは、以下の3つだ:
IT(Information Technology)
OT(Operational Technology)
ET(Engineering Technology)

それぞれが具体的に、どのような種類の技術領域を表すかについては、長くなりそうなので、次回書くことにしよう。
(この項続く)


<関連エントリ>
 →「マネジメント・テクノロジーの領域を知ろう」(2019-10-05) https://brevis.exblog.jp/28610522/
 →「オーケストラの指揮者かジャズ・バンドのリーダーか - プロジェクト・マネジメントの4つの類型を知る」(2014-02-02) https://brevis.exblog.jp/21641066/


by Tomoichi_Sato | 2019-10-13 15:32 | ビジネス | Comments(1)

マネジメント・テクノロジーの領域を知ろう

本サイトの主要なテーマは、(知らなかった人もいるかもしれないが)『マネジメント・テクノロジー』である。マネジメントと言う仕事には技術があって、学ぶこともできるし、蓄積したり磨いたり、人に伝えることもできる。決して気合とか根性とか、生まれつきのセンスとかだけで能力の決まる仕事ではない。そういうことを多くの人と共有したくて、ずっとこのサイトを運営してきた。

そもそもTechnology(技術)には2種類ある。固有技術と管理技術(マネジメント・テクノロジー)だ。固有技術とは、対象固有の科学法則に縛られる領域におけるTechnologyである。たとえば、機械設計、材料開発、システム設計、といった技術がそれに当たる。ちなみに、わたし自身の大学の専門は化学工学(Chemical Engineering)だった。これは化学プラントの設計に関わる工学だが、やはり固有技術である。

これに対して、管理技術とは、仕事の仕組みそれ自体に対して適用すべきTechnologyをいう。「仕事の仕組み」では分かりにくければ、人・モノ・情報などの配置と流し方、と言い換えても良い。たとえば、プロジェクト・マネジメントの分野では、CPM(Critical Path Method)やWBS(Work Breakdown Structure)、生産マネジメントの分野なら、在庫理論とか生産スケジューリングといった技術だ。

こうした管理技術(Management Technology)には業種・分野固有の部分がない。製品開発プロジェクトだろうが橋梁建設プロジェクトだろうが、CPMは当てはまるし、在庫品がダイヤモンドでもトイレットペーパーでも、在庫理論は使える。このため、マネジメント・テクノロジーは業種分野を超えて、汎用的である。だから、まったく畑違いの分野の知恵も、学んでうまく応用すれば、自分の仕事を楽にするために使える。

ところが残念なことに、日本の大学教育では、この『管理技術』の教育・研究を、伝統的に軽視してきた。その1番の証拠は、東大と京大に、学部レベルで経営工学や管理工学の学科が存在しないことである。この2つの大学は、日本の文科省の高等教育政策を映し出す鏡のようなものだ。つまり国の側にも、管理技術という意識が欠けているのだ。

ちなみにかなり以前から、慶応には管理工学科が、早稲田には経営システム工学科があり、東工大にも経営工学科があった。だが、肝心の東大と京大には、ずっと存在しなかった。さすがに、今世紀に入ってからようやく、大学院レベルで、東大に技術経営戦略学専攻が、京大に経営管理専攻が設置された。

だが学部レベルでは、相変わらず存在しない。だからこの二つのエリート大学を卒業してくる人たちは、基本的に、「仕事の仕組みにはテクノロジーがある」ということを理解せぬまま、社会に出て働くわけだ。

なぜ、国の側に管理技術=「マネジメント・テクノロジー」への認識が欠けているのか、わたし自身はよく知らない。ただ、もしかすると、わたし達の国の上の方の人たちは、「管理とは法学部出身者の仕事である」、と考えているのかもしれない。そう疑わせる兆候は多分にある。そうでなければ、なぜこの2つの大学の法学部出の人たちばかりが、中央官庁や政界財界のトップの座をあれほど席巻しているのか。

だが、話を元に戻そう。わたし達の社会では、残念ながら、「マネジメントにも技術がある」という概念が希薄である。だから、マネジメントの上手下手は、まったく属人的なものだ、という思想が強い。その結果、マネージャーの地位は、学歴・年功序列・出身等により選ばれることが多い。マネジメントは「地位に付随する権力・権能」 であって、前もって研修・訓練が必要な技術とは考えられていないのである。

なおここでもう一つ注意しておきたいことがある。それは、『経営』という言葉とマネジメントとの違いだ。本サイトは、「ビジネス・経営」のカテゴリーに分類されている。他に適切なカテゴリーがないから、そうしているだけだが、あまり本意では無い。なぜなら、このサイトでは、ほとんど経営について語ったことがないからだ。わたし自身、経営者ではないし、経営の仕事もしたことがない。

普通、日本語で経営と言うと、会社レベルの組織をまとめて運営する仕事を指す。しかし、私がここでマネジメント・テクノロジーと呼ぶ技術は、もう少し中間層のレベル、言い換えると経営者層と現場をつなぐレベルの技術である。クリティカルパス法だとか、在庫理論だとかいった技術知識は、会社経営のレベルではあまり必要がない(無論、知っているに越した事はないが)。

少し具体的な例で考えてみよう。今、ある所にカレー屋さんが開業した。ご主人はもともとエンジニアだったが、長引く不況と、先の見えない業界にうんざりして、心機一転、脱サラを決意したのだ。昔からカレーが得意料理で、親戚知人に披露すると結構評判が良かったので、自分で店を開こうと思いたったわけだ。

愛想の良い奥さんと二人三脚で、幸い、店は順調に滑り出した。ご主人が料理を作り、奥さんが客の応対をする。1年経つと、ピーク時には店の前に行列が並ぶほどになった。今のスペースは手狭なので、近くに3倍位の広さを持つ店舗の空き家を見つけ、そこに移転することにした。そうなると夫婦2人では手が足りない。厨房とフロアの手伝いに、2人ずつ人を入れた。

ご主人はこれに加えて、持ち帰りのカレー弁当も売ることにした。長年のオフィス勤めで、昼食に皆が苦労していることを知っているからだ。オフィス街に小さな机を並べ、昼の間だけそこでお弁当を見ることにした。当然そこにも人が必要だ。

だが、こうして店の業容を広げていくうちに、少しずつ問題が起きてきた。例えば、お弁当の仕込みの数をどう決めるべきか。作り過ぎれば売れ残るし、数を絞れば利益が出ない。それに、仕込んだカレーだって、賞味期限がある。3日も4日も前に煮込んだカレーをお客様に出すわけにはいかない。

店を広げた際に、カレーのメニューの種類を増やしたことも問題だった。厨房の中で、洗い場と、調理台と、冷蔵庫との導線が錯綜して、3人の人がぶつかりやすくなった。しかもメニューの数を増やしたために、フロアからの注文の聞き取りミスも増えてしまった。注文してから料理を出すまでの時間が長くなったとなじみの客にクレームされたこともある。

おまけに甚だ厄介な、今回の消費税対応。朝から晩まで寝る間も惜しんで忙しく働いているのに、利益は上がらない上に、客足も少しずつ鈍ってきている。カレーの味自体は変わっていない。むしろ腕は上がっている自信がある。だが商売の利益につながらないのだ。ご主人は深夜、自分の席で、ため息をつくことが多くなった。

これが典型的な「仕事の仕組み」の問題だ。今のご主人に必要なのは、カレー作りの品質向上ではない(それは固有技術に属する)。大事なのは、人と物と情報の配置・流し方の工夫である。つまりマネジメント・テクノロジーが足りないのだ。

夫婦2人で小さな店をやっているときには、それはほとんど必要なかった。だが品種を増やし、人を増やし、売り上げと生産量を増やしたときに、次第に目に見えない非効率が生まれてきたのだ。適切な厨房のレイアウト、適切な在庫量の設定と発注、需要の読みと臨機応変な対応、店舗から弁当売り場への搬送、注文と会計のシステムの導入・・こうしたことが必要になるのだ。だがそれを実現するテクノロジーを、どこで学べばいいのか?
e0058447_20141464.jpg
これと同様の問題が、おそらく最初は東京オリンピックの翌年の「昭和40年不況」のときに、多くの中堅中小企業で噴出した。そして、より大規模な形では、高度成長期を終えて、消費者ニーズの多様化と輸出拡大に直面した80年代以降に、日本企業を襲ったのだった。

ただ残念ながら、マネジメント・テクノロジーは、目に見えない領域に属している。そして、目に見える物の品質やディテールには大変こだわるが、目に見えない事には至って無頓着な傾向を、わたし達の文化は持っている。加えて、国家レベルでの認識不足。こうして、バブル崩壊以降の90年代から、長らく不況を出せずにきたのだ。

わたしのこの、ささやかなサイトが、国家レベルの問題を解決できると夢想しているわけではない。ただ、たまたまここを訪れた方のうち、たとえわずか数人でも、問題解決のヒントを提供できればいいと思っている。ネットの世界では、マネジメント・テクノロジーの情報源は、あまりに少ない。話題のほとんどは、固有技術か、さもなくば経営論に行ってしまう。それでは、問題に悩むカレー屋の店主の助けにはならないのだ。

それと同時に、わたし達は、マネジメント・テクノロジーについて、フェース・ツー・フェースで情報交換し、議論する場を必要としているように思う。ネットでの匿名による意見交換は、限界がある。工場作りに関しては、互いに勉強でき議論できる場を、(財)エンジニアリング協会で、立ち上げているところだ。そちらもいずれ近いうちに、より広くアナウンスできるようにしたいと考えている。そうやって、かつての東京オリンピック後と同じ状況に、日本の製造業が今度は陥らないよう、今から準備しようと思っているのである。


<関連エントリ>
 →「マネジメントのテクニックと技術論について」 https://brevis.exblog.jp/22951856/ (2015-04-22)




by Tomoichi_Sato | 2019-10-05 20:24 | ビジネス | Comments(2)