人気ブログランキング | 話題のタグを見る

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

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

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

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

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

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

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

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

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

では、仕事というのは、どういう構造をしているのか。仕事で働くとき、その「働き」とは何なのか？　それは次の図のような要素から成り立っている。
コトづくりとは、具体的には何をどうすることなのか？_e0058447_16164291.jpg

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

インプットをアウトプットにつなげる道筋を、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字では、この説明は伝わらない。コトをなすには、コトバを使いこなす技が必要なのである。


＜関連エントリ＞


by Tomoichi_Sato | 2021-04-17 16:21 | B2 スコープ・WBS・プロジェクト組織 | Comments(0)
<< プロジェクト・コード制（別名・... 書評掲載のお知らせ >>

ファン申請

※ メッセージを入力してください