タイム・コンサルタントの日誌から

書評（はかない連休のための、3つの短い物語）：「二週間の休暇」「鉄の門」「リチャード三世」

今年のゴールデンウィークは、比較的短い。おまけに、パンデミックのために、外出や旅行も制限されている。なんとなく鬱屈した思いを抱えながら、家にいなければならない人も多いだろう。そんな連休のために、3つの短い物語を紹介したい。立派な理論や上手に飾られた業績の紹介ではなく、また長くて分厚い夢物語でもない、割とすぐに読み通せる、でも人生の洞察に満ちた3冊の本だ。

---

『二週間の休暇』 フジモトマサル著

　（Amazon）

何もかも忘れてのんびりしたい。ーー仕事に疲れ、日々の退屈な繰り返しに飽きて、そう思った事のない人は少ないだろう。

この物語はごく何気ない、日常的なシーンから始まる。主人公はまだ20代の、若い女性だ。団地の部屋で目覚め、午後の街に買い物に行く。コロッケを買って、外で夕日を眺めながらそれを食べる。

近所の住民も、店家の主人も、街を行き交う姿も、皆、人間のように歩き話す鳥たちだ。でも、フジモトマサルの独特の、ちょっとほのぼのした絵柄から、それをちっとも不思議と感じさせない。

しかし主人公は、近所の住民とお茶を飲みながら話すうちに、自分が10年前のことも、いや1週間前のことも、覚えていないのに気がつく。自分は誰で、どこから来たのか。

ただ1つ、ふと思い出したのは、子供の頃、友達が教えてくれた「時計が4時44分を指したときに、白い壁に触れると、壁の中を通り抜けて4次元の世界に行っちゃうんだって」と言う言葉だった・・。

フジモトマサルと言う漫画家のことを、わたしは残念ながらこの本を読むまで知らなかった。とても優れた、良い作家だと思う。そして絵も、とてもうまい。素朴に見える描線だが、物事の陰影と、3次元的な奥行きをくっきり描いて、読み手の心を惹きつける。

そしてこの物語の不思議さ。ある種のファンタジーだが、おとぎ話と言うよりも、現代的で、かつ奇妙に身近だ。その点、ちょっと村上春樹を思わせる。事実、フジモトマサルは村上春樹の本の挿画も描いている。でも春樹よりも、もっと細やかな手触りに満ちていて、清々しい。

珠玉のような、という形容詞はこういう本のためにあるのだろう。振り返ってみると、この書評で「珠玉」と言う言葉を使ったのは、レイチェル・カーソン「センス・オブ・ワンダー」（→書評）と、池澤夏樹「スティル・ライフ」（→書評）以来かもしれない。

買うなら講談社から出ている新装版がおすすめだ。装幀が、とても美しい。おまけに、巻末に「給水塔占い」がついている。作中で主人公が、古本屋から買ってきて、自分の性格を占う本だ。これがまたとても面白い。ちなみにわたし自身は、「砂漠鉄塔型」らしい（苦笑）。

作者フジモトマサルは2015年に、40代半ばで病没する。本当に惜しい作家をなくしたと思う。ただしオフィシャルサイト はまだ生きていて、ちょっと不思議な気がする。生と死、この世とあの世を行き来する、この物語の作者らしい味が、まだこの大地にはかすかに残って漂っている。

---

『鉄の門』 マーガレット・ミラー著

　（Amazon）

それは、1940年代の米国ならどこにでもありそうな、幸福な家庭だった。父親は経験を積んだ信頼できる医師、その妻は美しく知的な主婦。息子と娘も成人しており、兄は雑誌の文芸記者。妹はその日曜日、軍人の婚約者がやってきて両親に挨拶し、週のうちに挙式をあげる予定になっていた。そして同居している、父親の未婚の妹。

ただし、妻ルシルは後妻だった。先妻ミドレッドは16年前に、隣接する公園の中で変死を遂げていた。状況から見て、物盗りだったが、犯人はわからず凶器も発見されていない。

その日曜日の朝、ルシルはなぜか、死んだ先妻ミドレッドの夢を見て目覚める。心を抑えて、彼女は大事な1日の暮らしをはじめる。16年間、決して心から打ち解けることのなかった、義理の子供たちと、義妹を前に。

だが彼らの平和な生活は、その日の夕方、風采の上がらない小男が小さな小包をルシルに届けた時から一変する。部屋で叫び声をあげた彼女は突然、失踪。警察が彼女を見つけたときには、錯乱状態に陥って、精神病院の鉄の門の向こうにとどめられ、何者かに怯え続ける状態になっていた・・

マーガレット・ミラーは心理的スリラーを得意とする推理作家だ。夫は同じく推理作家のロス・マクドナルドで、2人が高校で同級生だったらしい。

ロス・マクは最初は普通のハードボイルド探偵小説から始めて、中期以降、次第にアメリカの家庭を舞台にした心理的悲劇に焦点を当て、文学のテイストを増していく。マーガレット・ミラーは夫より作家としてのデビューが早く、最初から心理的な描写と繊細な文体で、文学性の高い作品を次々発表している。

比較的初期の作品である本書もそうだ。しかも終盤のたたみ込むようなサスペンス、結末の意外性など、非常に優れたミステリー作家であることがわかる。

わたしは古本屋で買った、昭和32年刊行の早川ミステリ（松本恵子訳）を読んだが、幸い現在は、新訳が出ている。ただしこの古い本には、江戸川乱歩のかなり丁寧な解説がついていて、面白い。もっと広く読まれて良い作家だと思う。

---

『リチャード三世』 W・シェイクスピア著（福田恒存訳）

（Amazon）

「やっと忍苦の冬も去り、このとおり天日もヨークの身方、あたり一面、夏の気に溢れている、一族の上に低く垂れ込めていた暗雲も、今は海の底ふかく追いやられてしまった。」

この劇は、こんな風に始まる。独白するのは、グロスター公リチャード。後のリチャード3世である。明るい口調で始まる彼のセリフは、途中で急に屈折を始め、

「ああ、俺と言う男は。（中略）歪んでいる、びっこだ、そばを通れば、犬も吠える。そうさ、そういう俺に、戦も終わり、笛や太鼓に踊る懦弱な御時世が、一体どんな楽しみを見つけてくれると言うのだ。」

とつぶやく。言い伝えによれば、リチャード3世はせむしでびっこだった。そこで彼は続ける。「そうと決まれば、道は一つ、思い切り悪党になってみせるぞ、（中略）2人の兄、王とクラレンスの仲を裂き、互いに憎み合うように仕向けようと言うわけだ。」かくて彼は、残忍な陰謀によって、兄や、その幼い王子たちを次々に葬り去り、イングランドの王座に手を伸ばしていく。

『リチャード三世』は、シェイクスピアの描いた2番目の戯曲である。まだごく初期の作品だ。1592年から93年にかけて、ロンドンはペストに襲われ、都市はロックダウン、あらゆる劇場が封鎖された。この劇はおそらくその間に書かれ、封鎖の開けた劇場で初演されたらしい。そして大当たりを取り、彼の出世作となった。

リチャード3世が即位したのは、1483年。つまりシェイクスピアの史劇が書かれたのは、そのわずか100年ちょっと後のことである。観客にとってはまだ、生々しい直近の歴史であったに違いない。比較的短い話なのに、かなり大勢の登場人物がある。観客がついていったのは、まだ語り継がれて間もない歴史だからだろう。そして重要な登場人物は、次々にリチャード3世の毒牙にかかって、殺されていく。

だが、とうとう国王の座を手にした彼は、次第に自分の味方や手下への猜疑心に、さいなまれていく。身内を裏切り続けた彼は、誰も信用できなくなっていくのだ。こうして頂点に向かって駆け上がり、恐ろしい速度で墜ちていく。対称形になったドラマの前半と後半の対比が、作者の腕の見せ所である。そして有名な最後のセリフ、

「馬をくれ、代わりに王国をやるぞ。」

で事実上、彼のドラマは締めくくられる。

英国で最も上演回数の多いシェイクスピアの劇は、「ハムレット」でも「ロミオとジュリエット」でも「リア王」でもなく、この「リチャード3世」なのだそうだ。希代の悪役を主人公にした、この険呑な劇が、なぜイギリス人のお気に召すのかは、よく知らない。

だが確かにここには、権力というものを目の前にした人間の恐ろしさと、徳無き権勢のはかなさが、満ちあふれている。それが疫病と都市封鎖のため、忍苦にじっと頭を垂れていた人々の心を打ったのだ。彼らの中に次第に広がっていったのは、なにより徳と公正さへの想いなのだったから。

プロジェクト・コード制（別名・製番管理）とは何か

前回の記事では、モノづくり産業におけるコト（＝仕事）の構造について考えてみた。仕事はアウトプットを出すために行うものであり、そのためにはインプットがいる。そして進めるためには、する人と、機械設備や場所・ツールといった「リソース」を一時的に割り当てる必要がある。そして、マネジメントするために指示と報告のやりとりも必須だ。

さて、モノゴトを「管理」するとは、どういう意味なのかについても、少し前の記事で考察した。対象がモノであれ金であれ、あるいは人であれ、その第一歩は、管理対象をリストアップして、「台帳化する」ことから始まる。

台帳にモノや人を記載するときには、当然、何らかの管理番号をつけることになる。それが資材台帳とか部品マスタだったら、「品目コード」であり、人員台帳とか従業員マスタの場合は、「従業員コード」ということになる。

したがって、もしもコトをちゃんと管理したかったら、最低限、コトに管理番号を付ける必要がある、というのが、必然の論理展開である。

しかし、目に見えもしない「コト」に、いちいち管理番号なんかつけられるのか？　そんな洒落たこと、してる会社あるのだろうか。まあ、外資系ならいざ知らず、目に見えぬ物事には無頓着な日本社会で、そんな企業がほんとに存在するのか？

もちろん、あるのである。というか、少なくとも製造業では、かなり多くの企業がやっているのだ。それは、「製造オーダー」に対する付番である。製造オーダーとは、製造現場に対して発行する指示書だ。まあ企業によっては、製造指図書とよんだり、ショップオーダーとよんだり、呼び方はいろいろだが、このサイトでは統一して製造オーダーと呼ぶことにしている。

（わたし達の社会では、人の流動性が低いためか、どうも言葉の通用性をあまり大切にしないらしく、こういう用語を標準化したり統一したりする動きはほとんどない。これが実務に近いマネジメント研究を阻害している一つの要因なのだが、まあ余談だ）

ともあれ、ある程度以上の管理レベルの工場では、現場に対して製造オーダーを発行している。紙の帳票の場合がほとんどだが、会社によっては電子的な指示の場合もあろう。いずれにせよ、そのオーダーの帳票イメージのヘッダ部分には、「オーダーNo.」が記載されているはずである。

もちろん、人間は知的で融通無碍だから、オーダーとか指示書などなくても、自分で動く場合がある。実際問題、インプットとなる部品・原材料が、自分の受け持ちの工程に届いたら、それで作業着手する工場だって、かなりある（とくに零細はほとんどがそうだろう）。

また、働くすべての人が、製造オーダーを受け取る訳ではない。「モダン・タイムス」のチャップリンのように、ベルトコンベヤの側で小さな繰り返し作業をする労働者には、いちいちオーダーは発行しない。ただ、ああした量産型の大工場でも、製造ライン全体に対しては、いつからいつまで、何をどれだけ製造しろ、というオーダーは下されているはず（たぶん現場のチーフ宛に）である。

それでは、製造オーダー＝「『モノづくり』というコト」の番号体系は、どうとるべきか。

モノづくりというのは通常、複数の工程からなっている。だから、モノを作っていく各工程（ないし作業Operation）ごとに、番号がいるわけだ。ただし、それらは、[材料a]→[部品A]→[中間製品X]のように連関がある。そうした作業の順序によるつながりを、番号を手がかりに、たどりやすい方が、便利である。

さらに、たいていの工場は複数の品種を扱っている。同じ切削や組立作業でも、扱う対象品目によって、それぞれ少しずつ異なるのがつねだ。ということは、モノにも紐づいている方が便利そうだ。

ただし、その両方を同時に具現化するのは、ちょっと面倒そうだ。図を見てほしい。作業が横に、つらなっている。これは、それぞれの製品を作る流れを示す。製品は1個とは限らず、複数個のロットで作る場合がほとんどだろうが、とにかく、あるまとまりをもって、おそらく別々の納期をもって、流れていく。

縦に並んでいるのは、同種のモノを扱う工程である。つまり、工場内の作業群は、モノという縦軸と、納期という横軸の、マトリクスになっているのだ。それで、管理番号を付番する場合は、縦軸で紐づけていくのか、横軸でまとめていくのか、二種類の選択肢があることになる。

縦にまとめるケースでは、あくまで、作業を扱うモノに紐づける。つまり、各工程が作り出すアウトプット（部品なり中間製品なり最終製品なり）に準じて、発番する。必要ならば、複数の納期にぶら下がった作業を、製造しやすいロットサイズにまとめて、一つの作業にすることもある。あるいは、厳密なロット・トレースが要求される場合、原料のロット番号単位に作業を紐づけることもあろう（その場合、複数の原料ロットに属する作業をまとめることはしない）。

もう一つは、納期に紐づけて発番するやり方だ。納期とは、計画生産の場合は、MPSにおける製品単位の「生産オーダー」で決まる。また受注生産の場合、顧客の個別のオーダー（注文書番号）で定められる。

そのどちらを取るかは、もちろん、その企業のモノづくりの特性と、何を主眼としてマネジメントしたいか、に依存する。図に示したとおり、モノに紐づける方式は、量産型で、比較的繰り返し性の高い企業に向いている。同じモノを各工程で何回も何回も作る場合は、同種のモノを扱う作業同士の紐づけ、比較がやりやすいからだ。たとえば品目AbCdを扱う作業には、AbCd-NNNのように、品目番号を機軸とした管理番号を付番していく。

他方、製品単位のオーダー（注文）に紐づける方式は、多品種・受注型で個別性が高いモノづくりに向いている。個別性が高いと、扱う品目にかなり違いがあるからだ。

個別の注文毎に、設計作業を経て、モノづくりをする形態を、受注設計生産と呼ぶ。英語ではETO (=Engineer to Order）と略す。産業機械だとか、船舶とか、車両とか、航空機などは、ほぼETO形態である。ある意味、それぞれが異なるので、「プロジェクト型生産」と呼んでもいい。

したがって、あらゆる作業コードを注文番号に紐づける方式を、「プロジェクト・コード制」と呼ぶ。別名、「製番管理」ともいう。製番は製作番号の略だ（例によって、「作番」と略す会社もあり、まあ、呼び方は様々である）。各作業への製造オーダー（指図書）は、そのプロジェクト・コード（顧客新の注文書）単位で独立している。A社への部品と、B社向けの部品を、一緒にまぜて加工したりは、原則しない。

こうしたプロジェクト・コード制（あるいは製番管理）は、基本的にETO生産形態の発想であろう。需要予測（見込）にもとづいて、同じモノを繰り返し作っていくケースで、この方式をとっている企業は、ほとんど見たことがない。

プロジェクト・コード制には、いくつか利点がある。たとえば：

(1) 個別原価計算がやりやすい

(2) 個別納期の予測がやりやすい

(3) 設計変更の影響範囲が把握しやすい

各作業に、同一のプロジェクト・コードが紐づいているのだから、(1)は作業原価を足し算するだけですむ。もちろん、各作業は個別納期に紐づいているから、納期予測だってやりやすい。さらに、設計変更が起きた場合でも、その影響範囲は他の注文からは隔離されているから、明確だ。

他方、欠点もある。たとえば：

(1) 共通購買によるコストダウンが難しい

(2) 部品共通化や作業標準化がはかりにくい

(3) 在庫の複数プロジェクト間での転用がやりにくい

何せ、個別に設計し材料発注するのだから、(1)や(2)はいうまでもないだろう。(3)は、在庫がすべて、個別のプロジェクト_コード（注文）に紐づいているから、やっかいである。というか、基本的に、特定の注文に紐づかないストック在庫、という発想自体が、薄くなってしまう。

もっとも、ここまで読んだIT技術者は、内心、「何言ってんだ、品目コードとプロジェクト・コードの複数キーをもつ構造にすれば、作業は縦横どっちにも集計できるじゃないか」と思ったかもしれない。じつは、そうは行かないのである。コード体系は、そのユニークネスのスコープを、管理範囲が定めることに注意してほしい。

受注設計生産ETOの場合、設計の産物として、品目コードが生成される。だが、この品目コードは、プロジェクト・コード内でユニークであれば、用が足りてしまう（作業上、他と混ざらないから）。つまり、会社全体で、品目コードを統一するモチベーションが、設計者に働かないのである。プロジェクトをまたいで品目コードを統一しようとすると、（じつはわたしの勤務先でも経験したのでいうのだが）大変な労力が必要になる。

話を元に戻すが、両者の違いは基本的に、繰り返し性の大小にある。別の言い方をすると、個別に設計作業が必要かどうかといってもいい。自動車部品メーカーのように、受注生産だが、繰り返し性の高いところでは、プロジェクト・コード制（製番管理）は、さほどメリットを生み出さない。

ただし、世の中全体としては、次第に多品種化に向かい、見込生産から受注生産の形態に、シフトしつつある。これは成熟した産業社会における潮流だ。しかしながら、社内が大量見込生産時代の仕組みのままで残っていると、小回りのきく受注生産に対応しきれなくなる。もちろん、逆も真なりだろう（その方が少ないだろうが）。だから、適切な管理方式を選んで設計することが重要なのである。

世の中に管理職と名のつく人は多い。管理が好きな人の割合だって、案外高いだろう。だが、ここに書いてきたような、本当の意味での「マネジメントの仕組み」を理解し構想できる人は、まだまだ足りないのではないだろうか？

＜関連エントリ＞

　 (2021-04-17)

　(2021-03-16)

コトづくりとは、具体的には何をどうすることなのか？

日本人は、目に見えるモノには徹底して細部までこだわるが、目に見えないコトはまったく無頓着で関心を持たない、といわれる。まあ、こうした事には例外もあるが、その傾向が強いことは確かだろう。

その一方で、日本は「言霊（ことだま）の幸（さきわ）う国」だ、とも言われる。言葉には魂がこもっていて、口にするとそれが（良きにつけ悪しきにつけ）実現する、と無意識に信じられている、という訳だ。そうかもしれないな、とも感じる。

たとえば、「モノづくりよりコトづくり」なんて言葉を聞くと、また言霊かなあ、と思う。「コトづくり」とはどういう意味なのか、わたしにはよく分からない。発言している人はもちろん、分かっていらっしゃるのだろう。だが、その意味は、今ひとつ聞き手に伝わってこない。伝わらなくても、こう発言することが大事だ、という意識の方が、先回りして伝わってくる。

つくるべき「コト」って何？　ちょっと定義してくれませんか？　例示だけでもいいんですが。

こうした発言は、近年のいわゆるサービタイゼーション＝「経済のサービス化」のトレンドにしたがって、出てきたのだろう。「モノ売りからコト売りへ」などというスローガンも聞かれる。物販で製品の所有権をユーザに売り渡してしまうのではなく、いわばユーザの手元に製品を貸し付けて、その利用料をもらい続けるサブスクリプション型のビジネスモデルが、これから目指すべき潮流だ、という訳だ。

それはつまり、リソース提供型のビジネス、という意味である。リソースをユーザが占有して使っている間は、利用料をチャージする。販売による一時的な収益ではなく、顧客との継続的な関係と、その関係の改善で（たとえばTeslaのEV車が、ソフトウェアをリモートでアップデートしてくれて、使い勝手がどんどん改善されていくように）、ユーザを釘付けにして、永続的な収入を得よう、ということ、らしい。

でも、それが「コトづくり」なのだろうか。コトってのは、はじめがあったら、終わりがあるんじゃないのだろうか。コトとは、ある種、時間の中に実現されていく過程＝プロセスの事ではなかったろうか？

コトの代表例を、じつはわたし達は知っている。それは『仕事』である。この日本語は、まさに「事をなす」を意味している。仕とは「行う」の意味があり、だから「仕上げ」「仕手」などの言葉がある（仕手は「する人」で、能楽では主役を指す）。

では、仕事というのは、どういう構造をしているのか。仕事で働くとき、その「働き」とは何なのか？　それは次の図のような要素から成り立っている。

「働き」である以上、それは何か付加価値の伴う作用をしている。つまり、アウトプットを生み出す作用だ。そして、全くの無から有を作り出すことは困難だから、普通は何かのインプットをアウトプットに変換する訳である。

インプットをアウトプットにつなげる道筋を、Systems Engineeringではプロセス（過程）とよび、Input-Process-Outputの頭文字を取って、IPOモデルと呼んだりする。しかし、ここでは仕事の要素単位を、プロジェクト・マネジメント分野の用語をとって、「Activity」と呼ぶことにしよう。

Activityをとりまき、構成する要素は、次の5つだ：

1. アウトプット（成果物／完了状態）

　生み出されるべきモノ、情報、または特定の状態をさす。働きとは何らかの有用なアウトプットを生み出すことだから、これが一番重要である。アウトプットは、そのActivityの「完了条件」を意味し、これが生成されれば、その特定のActivityは完了する。なお、アウトプットに「特定の状態」が含まれる理由は、ある条件が満たされれば完了するような仕事もあるからだ（たとえば、部屋の掃除は、部屋がきれいな状態になったら終わりである）。

2. インプット（必要材料）：モノ、情報

　アウトプットがモノである場合、当然ながらインプットとしては、材料としてのモノが必要になる。アウトプットが情報（たとえば何らかのレポートとか設計図とか）の場合は、インプットは情報だけでいいだろう。まれには、作家が創作するときのように、特定のインプットなしに空から考えて何かを生み出す場合も、ないではないが。なお、モノづくりの仕事の場合、通常は材料以外に、どんなものを作るのか（What）を示す情報、たとえば設計図とか仕様書も、インプットとして必要なはずである。

3. リソース（経営資源）：人、ならびに場所・機械設備・道具、等

　仕事はふつう、人が担う。まあ、完全に機械化されたプラント・工場の工程など、人手を介さずにモノの変化が進むケースもあるが、その場合も、監視や制御といった役割で人がつくことが多い。そして、現実の仕事は、ある場所を使い、機械設備も使い、工具や金型やPCといった道具も使う。これらをまとめて、リソース（経営資源）と呼ぶ。その中で一番重要なのは、もちろん働く人（Human resource）である。

　ちなみにリソースとインプットの違いは、仕事の終わりに消費されて無くなってしまうか、あるいは元のまま残って、次の仕事を担えるか、にある。リソースは、Activityの実行する間だけ占有されるが、完了したら開放されて、別のActivityに用いられる。ちょうど化学反応における触媒のように、それ自体はなくならずに残る。そして触媒のように、多少減耗したり劣化するので、ときに賦活・再生が必要である。

4. 制約条件：コスト・納期、技術規格、法規制、環境・安全影響など

　たいていの仕事には、そのやり方（How）に伴う、制約条件が与えられている。端的には、使える予算の上限とか納期である。また技術規格や法規制などもそうだし、当然ながら騒音だのゴミだのを勝手に排出しないような環境面・安全面の制約もある。

5. 指示及び報告：「Management」のために必要

　自営業者の自発的な仕事ならばいざ知らず、組織の中で行われるActivityには、マネジメントのために指示と報告が必要だ。「マネジメント」とは、人に仕事をしてもらう、という意味であり、だから依頼者と作業者の間に、指示と報告がいるのだ。ちょうど鍋の取っ手のようなものである（少し違うかな？）。納期やコスト制約がActivityごとに個別に異なる場合は、それも指示に付随して渡される事が多い。完了時、ならびに異常発生時にも、報告が出される。

なお、Activityの内部には、さらに下位のSub-activityが並んでいて、それが仕事のプロセスを構成しているかも知れない。そういう意味で、Activityは階層的に分解可能である。ただし内部のSub-activityは通常、外部に対しては「遮蔽」されており、いわば、任されている状態にある。マネジメントにおける指示と報告の単位では、原則としてアウトプットの結果のみを問うことになる。

もっとも長期間にわたるActivityで、途中経過がないと依頼者側が不安な場合は、途中報告を求めるケースも多い。その場合は、Sub-activityのどこまで進んだか、などを回答することになるだろう。

以上が、「仕事というコト」の構造である。こういう図を見れば、当たり前だ、そんなの常識じゃないか、と思うかもしれない。だが、この当たり前が、いつでも言語化して取り出せる形で、皆の胸の中に入っているかどうかは、別だろう。不思議なことに、わたしはこのような図を、あまり他で見かけたことがない。

「コトづくり」だとか、コトを設計する、といった場合、当然ながら上記の5要素を、きちんと定義しないといけない。アウトプットは何で、インプットは何と何なのか。使うべきリソースは、誰がどのように割り当てるのか。制約条件は何で、指示の内容とタイミング、そして報告義務はどんなことなのか。

仕事がトラブる原因の多くは、じつは仕事を頼む際に、上記の5要素をちゃんと確認し、伝えていないために発生する。せっかく働いて成果物を提出したのに、「俺が注文したのはこんな成果物じゃない」といわれたり、逆に誰かに仕事を頼んだら、全然違う材料や情報にもとづいて作業していたり。これが部署をまたぎ会社をまたぎ、さらに国境をまたいだりすると、たいてい悶着のタネに発展する。

だから、わたしは学生にプロジェクト・マネジメントを教えるとき、こんな練習問題を出している：

「あなたが誰か家族に『オムレツを作って』と頼むとしましょう。そのアウトプット・インプット・必要なリソース・制約条件を言葉にしてみて下さい」

こういう練習をしてみて、はじめて学生たちは、自分が人に何かやってもらう時に、いかに伝達があいまいだったに気がつく。これは世間で言う「コミュ力」などの問題ではない。仕事というコトの構成要素が、頭に入っているかどうかの問題なのである。

そこで、わたしは続けて言うことにしている。「みなさんが、先生や先輩やバイト先の上司など、誰かに何か仕事を頼まれた際にも、自分からこの5つの要素をちゃんと確認するようにしましょう。そうしないと、せっかく働いたのに、相手に怒られて、やりきれない思いをしかねませんから。」

なお、製造業では、製造の要素として、よく「4M」をあげる。Man, Machine, Material, Methodである。それぞれ、上記の「働く人」「機械設備」「必要材料」に相当する。じゃあ、最後のMethod（方法）はどこなんだ？　5要素にも、上の図にも入っていないじゃないか？　そう疑問に思われた方もおられるだろう。

答えは簡単である。Method（あるいはProcess＝過程）とは、Activityの内部を構成するSub-activityの列で表現されている。逆に言うと、コトを設計するとは、入出力を決めた上で、その内部のsub-activityの構造と制御を決めることなのだ。

これが「コトづくり」って事じゃないの？　違う？

春になると暖かくなること、夕日が美しいこと、花にもの思うこと。そうした「こと」は設計できないし、設計不要だ。わたし達をとりまく事には、自然に生じたのも多い。しかし、人が関わって働きをもつ「コト」は、設計し動かしていくスキルが、たしかに必要だ。

コトは目に見えにくいだけに、無頓着な人が少なくない。だから言語や図式で、目に見えるよう表現した方がいい。ただしキーワード単語だけの言葉は、かえってコトダマ化して、人を惑わすことがある。わたしがいつも長々と文章を書いているのは、それを防ぎたいからだ。残念ながら140字では、この説明は伝わらない。コトをなすには、コトバを使いこなす技が必要なのである。

＜関連エントリ＞

　→「サービス経済から、ふたたび実物経済の時代へ」 (2020-04-23)

書評掲載のお知らせ

お知らせです。

直木賞作家・姫野カオルコさんの、評判を呼んだ著書『彼女は頭が悪いから』が、この4月に文庫化されました。

これを機に文藝春秋社の依頼で、文藝春秋BOOKS「本の話」に書評、

　「わたし達は皆、頭が悪いから」　

　https://books.bunshun.jp/articles/-/6177

を書きました。

マネジメント・テクノロジーとは何の関係もない文章ですが、よろしければご笑覧ください。

佐藤知一＠横浜

管理のシステム化は可能か？

「管理不行届」という言葉がある。時折、新聞などをにぎわす言葉だ。通常は人間を対象にした問題が生じた際に使われる（危険物などの保管で使われる場合も、ないではないが、かなりの問題を起こした場合に限られよう）。多くの場合、組織の構成員が、社会問題になるような不適切な行いをした際に、上長とか代表者などの「管理責任」を問うために使われる。管理のかわりに「監督不行届」という場合もある。

「不行届」という漢字を、「ふゆきとどき」と音訓まぜた読み方にして、しかも送り仮名をつけないスタイルから見て、かなり古い時代から使われている言葉らしい。実際のところ、江戸時代などでも、家中で不祥事があると、大名や重役が幕府から管理責任を問われ、蟄居閉門だのお家断絶などを命じられたようだ（ただし、管理責任を厳しく問いすぎると、問題発生を隠して偽装する、という別の問題行動が生じるのは、江戸時代も今も変わらない）。

ちなみに、国士舘大学の杉野隆氏の研究「『管理』という言葉」（情報システム学会, 2011 ）によると、管理という言葉は元々、「管轄辨理が略されて成立した」という。「管轄」は、皆が知っている通りの意味だ。「辨理」という言葉は、「事務を処理する」（新漢語林）あるいは「弁別して処理する」（広辞苑）ことだという。「管理」の語は、清朝では17世紀末に成立し、日本には18世紀に到来したが、現在のような意味で広く使われるようになったのは、明治以降らしい。

本サイトでは、前々回の記事「管理とは何か、を明らかにする12の質問」 (2021-03-16)と、前回の「管理という仕事をスケールアウトするために」 (2021-03-28)で、それぞれ、「モノの管理」「人の管理」について、そのありようを考えてみた。その結果、両者はよく似た相似形のサブタスクからなる仕事であることが、見えてきた。

さて、「経営資源は人・モノ・金」と、よく言われる（ただし、こういう言い方が通用するのは日本だけらしく、わたしの知る限り、英文の文献では、あまりこの3要素の列挙は見かけない）。ともあれ、モノと人の管理については、考えてみた。お金の管理は、どうだろうか？

お金の管理は、モノの管理と比較的相似形だと考えられる。管理対象を認識し、その数量と状態、そして出入りを把握する。

ただし、お金がモノと違う点は、紙幣・貨幣を個別に追う必要がないことだ。10円玉10枚と、100円玉1枚は交換可能であり、合計した数値だけを「管理」すればよい。お金というのは預金・株式・債券を含めて、ある種の「権利」の表象だからである。

工場などでモノをきちんと管理する場合は、個品を追いかけるために、ロット番号やシリアルナンバーなどを把握する必要がでてくる。しかし、紙幣の番号をいちいち記録しながら出納している会社など、（金融機関の一部業務を除けば）見たことがない。そして紙幣や貨幣には、消費期限がない。修繕の必要も、ほぼない。それは国家が、必要に応じてやってくれる。とても世話なしである。

だから、お金の管理はモノの管理よりもずっと簡単である・・などというと、「それは違う！」と怒る人が大勢出てくると思う。お金の管理が簡単だなんて、とんでもないことだ。お前はお金で苦労したことがないのか？

いやいや、ここでいう「管理」には、「運用」の仕事は入っていないことに注意してほしい。「モノの管理」には、モノを調達したり加工したり消費したり、といった直接業務は含めないのだった。同じように、お金を貸し付けたり投資したり稼いだり消費したりする行為は、ここでいう「お金の管理」には含まない。

もちろん、お金には「利息」や「配当」、さらに市価上昇による「キャピタルゲイン」など、それ自体が時間と共にお金を生む仕組みがある点が、単なる物品の保管とは異なっている。でも物品だって、消費期限や劣化や陳腐化など、時間と共に数量が変化する場合があるから、本質的にひどく差がある訳ではない。

むしろ、お金について、気を遣わなければならないのは、法律で「管理」が要求される点である。課税のための会計が求められるのだ。そして、会計においては、数字の正確性と記録性、そして一貫性などが要求される。これがゆえに、お金の管理＝すなわち経理という仕事に、専門職が発生するのだ。

冷蔵庫や工場倉庫の中が、いかに散らかっていても、そして数量が現実とあわなくても、誰も文句は言われないが、経理の数字が違っていたら、税務署に怒られる。だから「お金の管理は難しい、大変だ」と、多くの人が感じるのである。

かくして、モノ・人・お金の管理業務を、比較して見てきた。そして案外、共通性が高いことが分かった。管理においてやるべき事をまとめて、やや強引に抽象化すると、こんな要素になる：

(1) 対象のリスティング ・・・ 現在

(2) 位置・状態のモニタリング・・・現在（位置・属性）

(3) 動きのトラッキング・・・過去

(4) 当面のフォアキャスティング・・・直近の未来

(5) あるべき姿のデザイニング（個別対象）・・・要求・評価

(6) もっていきたい姿のプランニング（全体）・・・意思・目標

これをよくよく見ると、管理という業務の中は、2つのレベルに分かれそうだ。

一つ目は、(1)〜(3)に表される、管理対象の現在・過去の把握、である。さらに(4)の、確定した直近の予定・見込みも含む。つまり現在と過去と近未来に関して、正確な情報をつかむことだ。

いいかえると、管理という仕事の第一層は、ある意味、情報を処理する仕事＝情報処理業務なのである。

だからこそ、「管理システム」という名前のITシステムが、世の中に生じることになる。対象業務は、生産管理だったり在庫管理だったり、あるいは労務管理・出納管理・文書管理などなど、「人・モノ・金」の範疇を含んで、いくらでも広がりうる。

こうした「管理システム」を構築する際は、とりあえず、情報をやりとりするための画面・帳票が規定される。また、業務手順（プロセス）も、一応規定される。さらに、ふつうは、なんらかの台帳も共有される。つまり、ある程度、業務の手続きに関するルールが形式化されるのである。

さらに、多くの場合は、「管理レポート」なる帳票の類いも出力できるようになっている。この管理レポートとは、まあ履歴のリスティングや多少の集計、そして統計分析などが主体である。統計することを「管理」と呼ぶに値するかどうかはさておき、しばしば、何らかのKPIが測られ、計算出力される訳だ。

もっとも、そのKPIに、標準値があり、正常値の範囲（すなわち問題の検知の基準）と、さらに目標値があるかどうかは、別問題だ。そこまでついていたら、たしかに「管理」の名前に似つかわしいと感じるかも知れぬ。昔、わたしの勤務先で、ある管理職の方が、社内開発した「ドキュメント管理システム」の内容を見て、

「これって、単なる『ドキュメント・ステータス・トラッキング・プログラム』に過ぎないではないか。これでドキュメントを管理できる訳ではない。正しい呼び名で呼ぶべきだ」

と主張していたのを思い出す。情報を正確に処理するだけでは、管理として何かが足りない。そう、その管理者は考えた訳だ。では、その足りないものは何なのか？

そこで、上のリストに戻ってみよう。管理の第二層は、(5)と(6)に表されるように、管理対象を望ましい方向に動かすこと、だと分かる。そして、ここには要求や意思・目標、などの要素が入ってくる。つまり人間に起因する要素だ。

では、誰の要求や意思なのか？　直近のことだけを考えるなら、その直接のトリガーは、上から（あるいはユーザや顧客から）課された、要求・指示であろう。管理担当者は、それを管理対象に翻訳して伝達する訳だ。「対象を動かす」と言ってもいい。

しかし、「あるべき姿」「持っていきたい姿」が、誰か外部からの直近の（納期付きの）要求ではなく、自発的な、より中長期的な将来像である場合こそ、より本来の意味で『管理者』の仕事にふさわしい、と言えるだろう。そういう風に、管理対象を構造化・組織化して、動かすのが、管理業務の第二層、より上層の仕事である。

対象を動かすといっても、対象が単なるモノの場合は、「保管」という言葉がふさわしい。また、対象が機械の場合は、運転とか操縦とか制御と呼ぶ。やはり、人間を動かす場合が、一番難しい。対象が人間の場合、あるいは人間を含む「仕組み」の場合は、結果に不確実性も伴う。

ここでいう不確実性とは、「情報の不正確性」とは違う。だから、管理業務の第二層は、情報システムだけでは片付かない。むしろ、伝え方・動かし方の問題になる。そして、動かし方を全体として見た場合の、有用性・効率性・再現性などが、評価尺度になる。だからこそ、管理者側の価値観と意思が問われるのである。

ところで、以前わたしはこのサイトで、「スマートさ」について、７つの基準を用いた定義を紹介したことがある。それはこんな内容であった。

スマートさ：「全体を考えて判断し、自律的にふるまう」

1. 現在を正確に把握

2. 過去を記憶

3. 将来を予見

4. 意思と目標を実現すべく計画

5. 問題にすぐ気づき解決する

6. 無駄なことはしない

7. 経験から学び、学びの枠を柔軟に拡げる

このリストを、上の6項目と比較すると、(1)〜(4)がほぼ、1.〜3.に対応していることが分かる。(5)(6)はもう少し詳しく4.〜7.に展開されている。だが、どちらも2つの層からなっている。つまり、「管理」という仕事は、上層の部分まで含めれば、「スマートである」ための条件を満たすのだ。

ITによる管理システムは、もちろん管理の仕事のためには必要だ。だが、それだけでは、第1層をカバーしているに過ぎない。それはスマートであるための必要条件だが、十分条件ではない。賢くなりたかったら、自分の側に、主体的な意思と価値観が必要となるのである。

＜関連エントリ＞

　 (2021-03-16)

　 (2021-03-28)

　「『スマート工場』はスマートか？」 (2018-05-26)